  |
はてなキーワード: バックエンドとは
インフォトップとかで商材を売ってる側です。
最近の副業ムックとかでこちらのお客さんも増えたところは喜ばしいのですが、
同時に、実績上がらないから詐欺だ、返金だと騒ぐ人が増えてきてるのも事実です。
ということで、ボヤキます。
でもそれは、ノウハウ実践をサポートするためであって、それがないとノウハウが機能しないことはありません。
そのおまけばかりに気を取られて、こちらの配布スケジュールを変更しろとか、配布が数日遅れただけで返金しろとか、勘弁して下さい。
２・ほかの参加者の事も考えてほしい
こちらも、みんなに実践してもらった結果、うまく伝わってない部分はテキストや動画を変更したりする必要がありますし、
多くのユーザーが使うことで見つかるソフトウェアのバグなどがあったりするので、大変助かっている一面があります。
しかし、そこでたまにいるのが、商材を罵倒して「詐欺だと思い始めたけどもう少し頑張ってみる」みたいな人。
貴方にジャストフィットな教材じゃなかったのは100歩譲って謝るけど、それって公共の場でいう事かな?と。
少なくとも、10万円単位のお金を払って、その商材の罵倒を見る権利を買いたかった人はいないはずです。
その方はお暴れになるのが収まらなかったので、こちらから公共の相談窓口、弁護士と経由し、ご自宅に警告文をお届けしました。
テキスト上の暴言は、２ちゃんねるあたりでよろしくお願いします。
３・別にBE買わなくてもいいんですよ。
物事にはバックエンド（以下、BE)という、より高い利益率の物を売る営業手法があります。
カミソリの替刃とか、プリンタの替えインクなんかが代表的ですね。
情報商材でもBEの手法はかなり主流の手法として存在してまして、これがかなり高額。
最初に3000円のちょっとしたものを買ったら、その奥に深ぁい世界が広がっていて、知りたければ30万円追加ね、という感じです。
問題は、これをやり過ぎてる業界で、アレルギーがる方が多いという事。
「BEの販売はありますか？あるのなら行きません」という内容の返事をもらいます。
だったら来なくていいから。こっちも商売なんで、慈善事業なセミナーやってるわけないじゃない。
それ以上にBEまではいらないなと思ったら、不要ですって帰ってもらっても構わないんですよね。
だってその場合、必要性や有用性が伝えきれなかった、自分たちの負けだもの。
とりあえずセミナー見て、どんな目新しいことやるのかな？とか
自分にどんな役に立つことなのかな？って体験しに来てください。
気楽にね。
そのとき、かなり強引なBEの押し売りがあったら、そのセミナー開催者はヤバい連中ですが
そこまで強引なのはごく一部です。時間がないからと言ってすぐに帰ってもらえれば大丈夫です。
買うまで返さないタイプの人は、その場で110番かけて帰りましょう。
なんかね、情報商材ってちゃんと使えばちゃんと効果を出すものなので
もうちょっと気楽に見て、気楽に買ってもいいんじゃないかなって思います。
あと、売る側も必死過ぎるのがいるので、そこは落ち着いてやってほしいなと。
LP(セールス用ページ）も、マジかい!?っていうのが結構ありましすね。
ソフトウェアエンジニアが転職するときに気をつけること http://anond.hatelabo.jp/20160629082647
これを書いたあとしばらくして転職したので、その後の話でも。
とはいっても、この「気をつけることリスト」は結局使わなかった。知り合いのエンジニアがはじめたベンチャーに行くことにしたからだ。
ベンチャーだからIRなんてないし、社長が知り合いだから技術への考え方や開発スタイルは知っているし。だから話としては開発しているサービスの内容と将来性、あとは待遇を聞いたくらいかな。まあ、将来性については自分で判断するしかないんだけどｗ
ちなみに知り合いの会社だからといって「気をつけることリスト」を無視したわけでもない。基本的なスタンスはこれを書いた当初と変わらないし、このリストにある項目について自分の中で納得したうえでの転職だよ。
これははっきりと断言させてもらうけど、この「気をつけることリスト」と照らしあわせたうえで転職したいと思える会社は、都内だったら普通にあるよ。
意識が高いのかどうかはよくわからない、というか周囲と比較すると自分はむしろ意識が低いほうだけどね。好きなこと以外の勉強をあまりしないし。それが自分の弱いところなんだよな。
gitのいいところは、ツールとして優れているというよりGitHub, GitLabなどのgit serverと統合されたウェブサービスがよく出来ているところだと思う。
特に、いわゆるpull-request駆動開発、つまりある程度のコミットのまとまりをpull-requestなどでCIしたりレビューしながら開発できるようになったすばらしい。
だからまあ、pull-request駆動ができるならバックエンドのバージョン管理システムはgitでなくてもいい。逆にいえば、gitを使っている会社でもpull-request駆動できる環境がなければ片手落ちだ。
そりゃ聞くよ。聞くべきでしょう。わざわざ書かなかったのは、さすがに自明だと思っていたから。
ベンチャー特有というと、株の扱いくらいかな。このれはちょっと前にバズってた記事があるので読んでおくといいんじゃないだろうか。
なにかしらOSSを公開していなければ転職は絶対ありえないというわけではないけど、判断材料になるのは確かだし、そういう会社を積極的に探したほうがいいとは思う。
かつ、稀というほど少なくもないと思う。特に昨今のWeb系企業であれば、OSSを開発してるところは沢山ある。そういうのは採用のためのアピールも兼ねてると思うんだけどね。
あとそういう意味では、最近はエンジニアブログを持っている会社もあるからそういうのはチェックしたほうがいい。会社のレベル感や雰囲気を知るにはちょうどいいと思う。
いわゆるWeb業界のエンジニアやってて10年経って、めでたくおっさんクラスタの仲間入りと言って過言でない年齢になりました。
定期的に "エンジニアの生存戦略" とか "キャリアが云々" みたいなのが話題に上る一方、みんなが気にしているのにあまり出てこない "おちんぎん" の実態について、私個人が10年でどのように変遷してきたかというのを書いてみようと思いました。
ここでいう "年収" は、源泉徴収票にある支払金額にある金額のことを指します。つまり、実際に得ている金額ということですね。
2006年: 350万円
2007年: 源泉徴収票紛失で不明、たぶん2006年と変わらないくらい
2008年: 440万円
2009-2010年: 400万円
2011年: 600万円
という感じです。
これをどう思うかは人それぞれだとは思いますが、参考にできそうな人がいたらどうぞ。
入社して数年
月収は30万円くらいだが、今まで一度も自分が給料分の仕事をしている実感がない
というのも自分は会社ではあるサービスのバックエンドに携わっており、
さらにいえば、そのサービスはどの利益がどこ由来ものなのかも測定できないくらい複雑に色々なものが絡み合っている
サービスと言ってもなんてことはない
単純なサイトだが、一人でコツコツ改善してり、機能追加したりしている
今では1日に500人以上がそのWebサイトを訪れてくれている
１ヶ月前にアフィリエイトを導入した
今月は現時点ですでに4000円程の利益が出ている
思った以上に好調だ
月30万働いて得るよりも自分一人の力で0から作ったサービスが生み出す4000円の方が嬉しい
自分が会社でやっていることが30万円も生み出しているとは甚だ思えない
自分がいなくても会社の利益は1円も変わらないのではないかと時々思う
というかいないほうが経費が減ってむしろいいのではないだろうか
どうして30万稼ぐのはこんなにも簡単で、こんなにも難しいのか
http://anond.hatelabo.jp/20160125000902
この増田は文章上手い。俺は元増田みたいに自分の言葉でうまく文章書くことが出来ない。俺みたいな奴が情報商材で一儲けとか考えたのは間違いだった。元増田見て、ああ、こういうやつがあの時儲けてやがったのかと思い知らされた。ただ、こいつ信者すぎてちょっと情報偏ってるんじゃねえかと思った。
俺は木坂健宣がすごいやつだとは思うが信者ではない。どちらかというと損させられたと思ってる人間なので、ネガティブな情報ものせておく。
・まず、高額セミナーの内容だが正直大したことがない。
http://aku-soku-zan.com/?p=472
【守コース】
【破コース】
人間セミナー全３回（撮影なし、東京会場と沖縄会場の２セット開催）
【離コース】
・人間セミナー３回（撮影なし、東京会場と沖縄会場の２セット開催）
パーソナルセミナー３回、開始時期は各自の希望に合わせ個別に対応
・個別サポート（半年間、個人面談３回、メール・スカイプ相談回数無制限）
価格：５０万円
・爆死した高額商品も多い
音声やＤＶＤと様々な形で数万円から数十万円の高額教材を販売したが
その内容はネットビジネス大百科を若干掘り下げたか別の視点で切り口を開いたものという程度であった。
１万円という価格のネットビジネス大百科に対し、その後のバックエンド商材があまりにも陳腐だった
とくにNBAはやばかった。これはさすがに信者でも金返せっていうやつがいた。
http://www.insiderscoachingclub.com/nba/
木坂健宣のコンサルを受けた人の体験談聞く限り、ブランディングは上手いがコンサルとしてすごい能力があったりするわけではないかもしれん。
とはいえ、この人は木坂をけなしつつ別の人の商材のアフィリエイトやってるんであんまり信用しないように。
「１億回失敗したって、１回成功すればいい。なんて、６０万円もの大金を受け取っているコンサルタントの言葉とは思えませんね。１億回の失敗を１００回、１０回に抑えるのがコンサルの仕事だと思うんですけど。」
「でも、こういう抽象的なアドバイスだけを淡々として６０万円ものお金を取って、何だかんだでコンサルを成立させていた木坂さんはある意味スゴいですね。あと、そんなコンサルで満足させてしまうレベルのブラディングを足立さんの中に作ったところも普通に凄いと思います。」
みんな大好きPostgreSQL。
複数DBマルチテナントシステムを構築するなら忘れてはいけないコネクションプーリング。
大量コネクションを扱うなら都度forkやpre-fork式ではちょっと辛い、イベントベースが好ましい。
もうお分かりですね。pgbouncer1.6の話題です。
PostgreSQL界隈では有名なコネクションプーリングの実装が2つあります。 pgpool-II と pgbouncer。
ざっくり言うと高機能の pgpool-II に対して、軽量・大規模向けの pgbouncer という棲み分けがあると言えるでしょう。
pgpool-II は最近は日本の トレジャーデータ社の Prestogres ( https://github.com/treasure-data/prestogres ) という痺れるようなプロジェクトのベースとして採用されていることで名前を聞いたことのある方もいるのではないでしょうか。
pgbouncer は少し古いですが LastFM( http://www.lastfm.jp/user/Russ/journal/2008/02/21/zd_postgres_connection_pools:_pgpool_vs._pgbouncer )の事例が有名でしょう。Instagram も使ってますネ。
pgbouncerは現行のバージョンは1.5系で、最新は1.5.5です。1.6系は8月1日にリリースされ、複数DBマルチテナントシステムに向けた大規模な機能強化が行われています。
この1.6系では複数DBマルチテナントシステム開発者にとって嬉しい機能がたくさん搭載される予定です。本番運用に投入する前に一足お先にリリースノートを読んで夢を感じましょう。
本バージョン、2013年ぐらいからリリースノートは準備されているのにさっぱりリリースされなくて関係者をやきもきさせていました。（想像）
本記事では以下のリリースノートをもとにザックリ読み解いたものです。
http://pgbouncer.github.io/2015/08/pgbouncer-1-6/
・接続ユーザーやパスワードハッシュをDBからロードできるようになった
・プーリングモードの設定をデータベース毎、ユーザー毎に設定できるようになった
・データベース毎、ユーザー毎にコネクションの最大接続数を制御できるようになった
・新しいコネクション確立を避けるための DISABLE/ENABLE コマンドが追加された
・新しい推奨のDNSバックエンド c-ares が追加された
・設定ファイルに include ディレクティブを追加した
新しく以下のパラメータが追加された
1.5までのpgbouncerは userlist.txt というテキストに静的に接続ユーザを書かなければいけませんでした。
これは動的に接続先ユーザーが増えるようなマルチテナントシステムを構築するのに不向きという事です。
タイトルがすべてを物語ってます。柔軟にできますねぇ('∀`)
ただ、私にはちょっと有用な利用シーンが思いつかなかったです。
たとえば分析用ユーザーではトランザクションなんて使わないので statement モードにしてコネクションの消費を抑えたりできるという事でしょうか。
max_db_connections と max_user_connections という設定が追加されます。
テナント毎にユーザーを分けているような複数DBマルチテナントシステムにとって必須といえる機能です。
特定のユーザーのリクエストにコネクションをすべて占有されてしまい、他のユーザーにサービスできないという事態を避けることができるようになるでしょう。
特定のデータベースの新しいコネクション確立を抑止・再開することができます。
c-ares は名前解決の非同期化を行うためのライブラリです。c-aresは名前解決をブロックしないし、いろいろな方式の名前解決に対応している唯一のプロダクトとのこと。
名前解決をブロッキングしてしまうようではpgbouncerのような大規模向けシステムでは役に立たないのだというpgbouncerの強い意志を感じる。
というか、ドキュメントを見る限り pgbouncer は名前解決にかなりこだわりを持っているらしい。それだけそこが重要ということでしょう
（個人的には困ったことがないのでそこまでだわる理由はよくわからない。）。
UNIXドメインソケットで接続しているクライアントと、TCPまたはUNIXドメインソケットで接続しているサーバーでremote_pidを取得できるようになりました。
tcp serverの場合、pid はキャンセルキーから取得できる。（？ドキュメントから意味が読み取れず）
キャンセルキーとは何でしょうね。ちょっとリリースノートからは判断できませんでした。
pg_cancel_backend とかに使えるPIDだよという事なのでしょうか。
DBの数なんてもはや何台あるかわからない。ホスト名の解決はもはやDNSで行っておるよという皆様にとって必須の機能。
…なのでしょうが、ちょっとこの機能が必要となるようなシステムとはどんなものなのか、私も未経験なのでよくわからないです。
この設定は application_name_add_host=on にすることで有効となる。
今や接続元アプリケーション名がWebだとかBatchだとか区別できるだけで問題が解決するような時代ではない。
どのホスト(ポート)レベルで区別しないと。という事なんだろう。
「おお、Webサーバーから死ぬほど重いクエリが飛んでる、今すぐ調べないと！で、どのWebサーバーよ？100台あるんだぜ」みたいなときに助かりますね。
設定ファイルが大規模化してくると、切り出して整理したいという要望はどうしてもでてくるもの。
データベース毎、ユーザー毎に設定できる項目が増えてきたので必要になったという事でしょう。
以降はバグフィックスとかクリーンアップだとかで自分はあまり興味がないので各自読むように。
本番運用に突撃するPostgreSQL界の猛者の報告待ってます。
想像力が貧困でなえる。某ラノベからかいつまんだ上に劣化させたレベル
元々の店舗での業務システムは脇から見ている限り作りこまれたものだった。
（配送センターの商品在庫とかトラックの空き状況やスケジュール確認ができてその場でオーダー入れたりとか）
ログイン前からタイムアウトのステート管理とかFB連携のごちゃごちゃとか、カートの状態確認（配送スケジュール手配やらも含むだろう）を
回していて処理できずに過負荷状態なのかなぁと
バックエンド側を担っているCTCもスケールさせてとりあえずの対応をしといて「うちの責任じゃない」を貫いている状態なのかと
任天堂のスマホ参入についての記事がいろいろ出てるけれど、岩田社長はゲーム系メディアのインタビューは
基本的に受けてくれないので突っ込んだ話が出てこない。
日経ビジネスの井上理記者はゲーム業界に詳しい方で、岩田社長の覚えもめでたくよくインタビュー記事を書いておられる。
しかしその記事は溢れる任天堂愛にほっこりするばかりで、厳しい部分にはノータッチでなんとももどかしい。
（後半の記事で詳細が話されるかもですが、厳しい質問は出てこないはず）
http://business.nikkeibp.co.jp/article/topics/20150319/278932/
そこで、某西田宗千佳氏などのインタビューお断り系のズバズバ切り込むメディアが訊きそうなことについて考えてみた。
あえて嫌味っぽく痛いところを突いてみたつもり。
スマートデバイスにどのようなソフトを出すべきか、どんな課金方法にすべきかといった課題を解決するためには数年の検討を
必要としたが、それは決して遅くないと伺いました。
しかし、モバイル業界はコンシューマー業界よりも環境の変化が早い世界であり、経営判断の遅さが命取りになりかねません。
事実、パートナーであるDeNAさんはブラウザゲームからネイティブアプリへの変化への対応が遅れ、一線を退いたという過去を
持っておられます。
「スマホは順調だがコンシューマーへの動線ができず、コンシューマーの売上が落ち込む」
といった現在想定しているシナリオとのズレが出てきたときの方向修正をどのようにイメージされておりますでしょうか。
それとも、変化が起きてからまた数年を費やして熟考するのでしょうか？
任天堂の強みはハードソフト一体型ビジネスであり、それを生かせないスマートデバイスでは長期的なビジネスを持続することは
困難だから決して手を出さないと繰り返しおっしゃってこられました。
しかし、他社のハードウェアが前提となる環境でも任天堂の強みを発揮できるとの結論に至り、今回スマートデバイスへの
そこから想像できることは、コンシューマービジネスにおいても、ソフトの内容や料金体系その他の課題について真剣に
考え抜くことで、ハードソフト一体型ビジネスに拘わる必要はないという「答え」を導き出せるのではという検討も
当然なさっておられるのではないかということです。
減少が続く自社ハードでの独占に拘らず、マイクロソフトやソニーなどの他社ハードにソフトを供給することは、
任天堂ユーザーの全体数を増加させることにつながります。それは今回のスマホ展開の目的でもある「ゲーム人口の拡大」
数年後、
「ずっと否定してきたが、実は前からソフト専業化について考えてきた。ようやく全体像がまとまったので今回発表することができた」
「時は来た」
というお話を聞かせて頂ける可能性があるのではないでしょうか。
2014年の5月、10月に行われた決算発表会で、それぞれ新興国への展開の進捗に関する質疑応答がございました。
そこで、先進国向けのプラットフォームを持っていくだけでは価格の面で難しいので、新興国向けの製品を開発中であるというお話がありました。
今回発表された「コードNX」は、この新興国向けに開発中の廉価ハードだと考えてよいのでしょうか。それとも、平行して2つの製品の開発を
行っているのでしょうか。
スマートデバイスにおけるDeNAとの役割分担に関する説明の中で、DeNAはバックエンドのサーバー周りのシステムの開発を任せるが、
ソフト開発はIP貸しではなく任天堂自身が中心となって行うというお話がございました。
現在、任天堂は携帯機と据置機の2つのゲーム専用機プラットフォームを展開しておられますが、ソフトの発売スケジュールに大きな空白が
しばしば発生し、定番タイトルの投入により一時的に販売が上向くことがあっても勢いを維持できずに失速するという状態が続いています。
現在の2つのプラットフォームへのソフト供給に苦しむ中、スマートデバイス、コードNXを加えた4つのプラットフォームの維持に必要なソフトを
供給していくための具体的な施策をお持ちであればぜひお聞かせください。。
あるいは、開発リソースには限りがあり、ソフトの品質や数を大きく増やすことは困難であるため、増えた分だけどこかを削るといった
方針なのでしょうか。
ゲーム専用機への情熱を失っていないことをアピールすることを目的として今回コードNXについて発表されたとのことですが、
「スマートデバイスやコードNXに注力する分だけ、現行の家庭機向けの開発リソースは減らされるのではないか」
「Wii Uと3DSは早期に終息に向かい、ソフトが出なくなってしまうのではないか」
おそらくこのWebサービスの売上はゼロに限りなく近いと思ってるんだよね。
毎月のサーバ維持費をペイ出来てんのかコレ？ってレベル。そもそもマイナー過ぎて2ちゃんねるですら検索してもヒットしない。
何故運営しつづけられてるかと言えばおそらくはもう1つのWebサービス(こっちも滅茶苦茶マイナー)の売上を持って来てるじゃないかなと考えてる。
もし大改修の許可が下りるのであれば人件費込みで1,000万円から、とことんやって3,000万円の予算が必要。どんなに低く見積もっても800万円以上の予算は必須。
各方面への営業は俺がやるから良いとして、絶対的にIT技術者の数が足りてないと思う。少なくともフロントエンド人員1名、バックエンド人員2名が欲しい。
売上が○○倍になりますよという表現が既存の売上が少なすぎて使えないから、アクセス数ベースで考えると10万倍には間違いなく膨れ上ると思う。
そのアクセス数からWeb広告収入の試算で出すしか無いかも知れない。どこから手を付けて良いもんだかわからないくらい酷すぎるんだよマジで。
次には、サービス提供者がユーザに使ってほしい機能への誘導しやすさとかもあるかもしれない。
http://anond.hatelabo.jp/20131126161353
http://d.hatena.ne.jp/chintaro3/20131125/1385374085
UIってサービスが持ってるデータに対して見せたい度合いの強弱で決定されるものだと思う。仕様変更や高速化でデータモデルやフローが変わったらUIも変わるのが当たり前、むしろ変えない方がどうかしてる。
UIが変わってユーザが脊髄反射で抗議するのって、新しいデータフローへの学習コストに対する嫌悪感の裏返しだし、嫌悪感をUIのせいにして「デザインくそ氏ねばか」「デザイン変えたっていいだろあほ」っていうのちょっと違うと思った。
UIよりまず先んじて、裏にあるデータやAPIや処理速度のことをちゃんと見てあげないと新しいデザインもクソもない。もちろんデータとUIが乖離していれば「あほばか」と罵る対象になると思うけど。
UIを通して開発者が言う「ここを見ろ」「こう使え」というメッセージを受け入れられないなら、使うのをやめればいいだけじゃないかと思う。それでも前のUIがいい、前のデータモデルやフローがどうしても気に入ってるなら自分で作ればいいのに。
試用期間3ヶ月が過ぎようとしたある日(5/27)の事。社長からいきなり「今月一杯で辞めてもらう」という宣言を食らった。通例解雇の予告は30日前に行われねばならず、いくらなんでも急過ぎるだろと思ってしまう。ここからは入社してからの経緯を簡単に話そうと思う。
今回入社したのは社員数10人未満の小さい会社だった。まずCakePHP+MySQLを使ったCMS回りの機能の追加の他、初めてJavaScriptやJQueryを担当する事となった。全く触った事の無い言語だった。基本を覚えながら、分からない事は先輩に聞きながらの作業で、いよいよ一案件が完成し、JQueryのほうも○×ゲームを作る位は覚えた。
しかしながら既存のソースコードの改修が苦手なのもあって、案件のJavaScript回りで時間がかかってしまった。例えば最後の案件はJavascriptのクラスを使った案件だった。上記のリンクのコードを見れば分かると思うが、自分はオブジェクト指向が苦手で、Javascriptのクラスの仕組みをする事が出発点だった。
最終的に「一つのトップページで一ヶ月をかけるのは費用対効果で、君を雇う意味が無くなってしまう。大きい企業なら補填が聞くのだが」と言われてしまったわけだ。労働契約の面では配置転換が出来ない事による普通解雇に当たるはずだ。
しかし仕事面では「俺じゃなくお前のせいだろ」と言ってやりたい。ある案件のホームページは途中まで自分が作っていた。しかし三月中旬、突然上の思いつきで仕様変更が入り、プログラムの大部分を修正しなくてはならなくなってしまった。先輩にも「無理なら無理と言っていいんだよ」と言われた程だった。その案件そのものの期限も一ヶ月延びたのもあり、他の案件でやらねばならない事も後ろに伸びてしまった。それがずるずる来て今日に至る。
「家は小さい会社だから何でも出来る、やりたい人を募集している。ミスマッチだ」と言われたが、フロントエンド/バックエンドの両方できる人ってそういないと思う。無論できる人もいると思うが、それが出来るような人は今の会社に来ないと思う。
かくいう俺も俺はそこまでプログラムが得意ではないし、何でもできる訳では無い事を考慮してくれればありがたかった。正直やってられない気持ちで一杯で、この業界から身を引く事を真剣に悩んでいる。
誹謗中傷というのはどのように行われるのかという事に興味があり調べながら、ついでに特定の個人を示して誹謗中傷しているコメントを抽出してそのアドレスをはてなの問合せ窓口に投げた。そんな作業の中で一つ気付いたことがあるので匿名ダイアリーを借りて記しておく。
はてなのコミュニティに属している人は、人気ブロガーであったコンビニ店長こと、MK2氏と、彼を執拗に批判する匿名ダイアリーのあるユーザが存在している事をご存じだと想う。それを追っていくと、MK2氏のエントリーを擁護する、あるいはMK2氏を中傷する匿名ダイアリーのエントリーについて批判的なブックマークコメントを残した人物に対して個別にIDを示して「ゴミクズ」という非常に特徴的な語を用いて中傷している人物がいることが観測できる。文体も非常に似ていて、文体を統一するマニュアルでもなければ同一人物である可能性が高いと思われる。さらに文体以外にも特徴があり
ここではっきりと書いておくが、イケダハヤト氏がこれをやっていると言う陰謀論を唱えるわけではない。何故ならばイケダハヤト氏は文筆業であり、有料でその考え方を文章にして販売している人物である。そう言う人物がこのような行動をとることはまず無いと考えている。漫画家がタダでマンガを書かないのと同じだ。プロはそれが商品である事を承知しており、商品の価値を下げるような真似はしないのだから。（私は彼が人格者であるから行うわけがないと言うほど彼の事を存じ上げないし、著作も読んだ事が無いのでこう言う言い方になる。彼の人柄をよく知る人が人格面からそんな事をするわけが無いと主張する事を否定するものではない）
では何かと言うと、これらの批判を繰り広げているのは
なのではないかと推測したと言うことである。さらに言えば、イケダハヤト氏に憧れて彼のようにネットで話題になりたいと文章をしたためているが、おそらくはてなブックマークでも、Twitterでもほとんど話題になることが無く、少なくともMK2氏の執筆したエントリーほどは注目を集めないことに不満を持っているのでは無いだろうか。
そして、そこでコンビニ店長たるMK2氏である。これらの事から、以下の様な妄想をここで披露する。
3行でまとめると
ノマドの立場というのは自由であるが、しかし無保証である。私はノマドワーカーを選ぶ人々は不安定な経済状態になって無保証になることそのものを目的にしている人はいないように思っている。自由をまずは目的にしているはずだ。だから最終的には、ある程度の自由を得ながら・・・自分の好きなことをしながら、経済的・生活的には安定することを目的としているのでは無いかと考える。
まず一つ目が職人としての成功である。腕一本で多数の所から仕事のオファーを連続して受けるケースだ。職人における安定とは、仕事が連続してくることであろう。しかしそのままでは仕事に縛られる事になるので、多数の仕事の中から自分がやりたい仕事を選ぶことができなければノマドという働き方を選んだ意味が無い。さらに価格交渉をしてより高い報酬を得る、そしてその報酬の分以上の利益を相手にもたらすことでさらに次の仕事に繋げる。こういったポジティブなサイクルを繰り返えして安定して収入を得るのが一つのゴールであろう。
もう一つの成功としては、自らの仕事を資本にして、自らの自由になる組織を作るという事だと考えられる。
職人のケースでは、多く受けた仕事のうち、やりたくない仕事はただ断っただけであった。しかしこれを自らが抱える別の人物に出せば、その分の仕事を受ける事ができるようになる。このようにして仕事をできるだけ断らずに、しかし自分でこなすのでは無く他者の手をかりて実行していくという形である。これは最終的には会社組織という事になるのだろう。こちらの特徴は組織化することでいくら組織の長であるとしても組織のしがらみを持つ事にはなる。しかし個人で行うよりは圧倒的に大きな事ができるようになる。大きな力を手に入れるというのは即ち出来る事が増え、出来る事が増えると言う事は自由になるという事である。
コンビニというのはフランチャイズ展開している自営業の集まりである。古い人間であるならば近所の酒屋が次々とコンビニに変わって行った時代を知っているだろうし、もう少し下ってくれば、独立系スーパーが店じまいをした後、アパートが建設され、その1階にできあがっていくコンビニという風景を見たことがあるだろう。今では大手コンビニチェーンがドミナント出店を行う際に、大々的にオーナーを募集するTVCMも流れている事も目にするはずだ。
このように、CVSは基本的にはオーナー制のフランチャイズ経営をとっている。このフランチャイズ制というのが何か、あるいはコンビニにおける商売の仕方は何かと言う事はネット上に無料で見ることのできる優良な文章がいくつもあるのでそれらを参照していただきたいと思うが、要するにコンビニのオーナー店長というのは、ブランドを借りて自主独立した店主であり、古い言い方をすれば一国一城の主なのである。
コンビニ経営は言うほど簡単では無い。全国的に統一されたマニュアルが有り、商品供給などのバックエンドはしっかりしている。しかし、それだけである。経営者はコンビニ本部への上納金を稼がなければならないという話はもちろんのこと、バイトの管理は重要で生半可なコミュ力ではできない。さらに地域との溶け込みも実は大切で、悪い評判が出るとまず固定客からいなくなると言う性質がある。
そんな中で、MK2氏のエントリーを見る限り（つまり実態はともかくMK2氏のエントリーから読み取れる店の雰囲気としては）非常によく成功しているように見えるのである。有り体に言えば勝ち組だ。優秀な奥さんがいて、信頼できる部下もおり、業務の工夫が功を奏して経営も安定しているように見える。これを勝ち組と言わずなんと言おうか。にも関わらず彼は会社員では無い。自ら決定権があるある程度自由にできる組織を持つ人である。
本来であれば、MK2氏のような人物は、ネットでは可視化されない。ましてや「はてな村」と揶揄されるような黎明期から続く雰囲気を色濃く残す部分に現れてくることはまず無い。彼らは現実世界で成功しており、地元の付き合いなどもそつなくこなし、それらについて忙しいのだから、このような趣味を持つ必要も無いはずだ。IT技術者のように、ネットの技術が自らの業務に密接に繋がっているわけでも無い。だからこのような成功者は、目に見えないはずだった。
しかし、MK2氏は、いわゆるオタク趣味を持ち、その方面からネットに進出してきたのである。さらに当初はサブカルチャーを中心にしていたが、だんだんとコンビニの経営者であると言うバッググラウンドから、それらに留まらず独自の視点を持った考察を行ってきた。また一般に長文が嫌われる傾向のあるインターネットにおいて、長文であっても読ませる文章であると言う評価を得るに至った。
自らの成功したいという欲望と、認められたい自己顕示欲。この二つが強すぎながらもどちらも持たざる人物にとっては、その両方を持ちながらさらに注目を集めるMK2氏の存在は非常に苛立たしいものだったのではないだろうか。
コンビニを潰すことはできない。であるならば、執拗に個人攻撃を繰り返すことで自分が唯一存在できる場所からMK2氏を排除したいと言う動機があったのでは無いか。あるいは個人攻撃をしていると言う自覚も無いのかも知れない。自らを高められないものが陥りやすい心理として、相手を批判する事で、相対的に自分の地位を上げようとする行動がある。
自らは特にすごくも無いのに、よりすごい能力を持った人物を批判する事で「偉い人を批判できる俺は彼より偉い」と言う錯覚を得たいがための行動である。あるいは格上の人物であっても批判する事によって注目を集める事ができるのでそれに酔ってしまった行動では無いか。
ネットで見られる多くの誹謗中傷と言った類いではこのように「妬み」としか言いようが無い感情に基づいているものが多く見受けられる。今回もこのケースなのでは無いだろうか。
対処法としては無視するのが一番なのだが、なかなか対処が難しいのは事実である。またこのような妬みを原動力とするものについては、単なる愉快犯と異なり、反応するしないに関わらずどんどん一方的にこじらせていく事も多い。もちろんその過程で反応したりすれば、一気に吹き出すことになるだろう。
このようなケースについて、何か良い対処法はないだろうか。一番に考えつくのは、頭を冷やす時間をとることなのだろう。妬み批判したところで自分は何も変わらない、むしろどんどん墜ちているということを自覚させるだけの時間を与えることだ。しかしそれを与える方法が難しい。どのようにしたらよいのだろうか。
もうすぐ30歳になるのに、昨年末で職場がなくなりハローワークに行っても求人が無いので
PHP ruby Nginx WordPress Bootstrap を使ってWebサービスを作りました。
今までバックエンドしか作ったことがなく、フロントエンドをやりたかった。
趣味でやっていて目標の物を作ったら満足し、継続してやらない。
なので今まで覚えてた事を忘れて一からやり直す事が多かった。
とゆう勢いで…
Bootswatch
Mechanize
スクレイピングしなきゃ！
いつもスクレイピングはSimple HTML DOM Parser
http://t-taira.hatenablog.com/entry/20120429/1335658939
「なにこれRubyすごいこんな数行で」
RubyでスクレイピングしたデータをMYSQLに保存までは完成。
次はサイトをどうしようかと考え…
cakePHPかな…
WordPressに決定。
一番時間がかかった…
デザインは昔からまったく出来なかったので Bootstrap に。
http://webdesignrecipes.com/first-time-wordpress-origin-theme/
ここを見ながらテーマに落としていくのは簡単でした。
WordPress初めてなのですごく参考になりました。
http://kray.jp/blog/wordpress-tuning/
http://tech.aainc.co.jp/archives/3022
Webサービスを作って公開するのが、こんなに楽しいとは思わなかった。
次はCakePHPとかフレームワークを覚えて新しいサービスを作りたい。
ruby on railsもいいな
でも、早く再就職したいです…
http://www.yamdas.org/column/technique/hatenablog.html
なお、タイトルに PART I とあるが、このネーミングはメル・ブルックスの『珍説世界史 PART I』にちなんだもので、PART II 以降は存在しない。つまり、あなた（ソフトウェア企業）が絶対すべきでないことは、Joel Spolsky にとってこの文章に書かれることだけなのだ。それは何か？
まぁ、そんなわけないんだけどね。
「最近のはてなの体たらくへの失望感に名前を付けたい」というだけの文章にマジレスするのも我ながらどうかと思うし、気持ちは分からなくもないんだが、最近は「はてブ」以外全く使ってない俺でも、長年お世話になってきたはてなに対してそれなりに愛着というものがあるわけで、ディスられるばかりの流れに少しばかり反抗を試みたい。これは、それだけのエントリだ。
というわけで、以下に書くのは、技術の話でも倫理の話でもない。どうか気軽に読んでほしい。
実例を挙げる。
今やワールドワイドな影響力を持つ勝ち組ソーシャルサービスのTwitterだが、彼らは、ここ数年でバックエンドの大半をスクラッチから完全に書き換えた。しかも、RubyからJavaへと、使用言語すら変更してしまった。
http://d.hatena.ne.jp/teppei-studio/20110709/1310168002
もう一つ。Tumblrも、LAMPアーキテクチャからJVMベースへ切り替えた。その過程で、Twitterがオープンソース化した技術を取り入れたりもしている。
http://blog.kyanny.me/entry/2012/02/19/002256
『「古いコードはクズだ」というのは錯覚だ』というJoelの意見は、一面では正しいが、他の面では間違っている。なぜなら、あるソフトウェアに求められていること（要件）は、時間と共にどんどん変化するからだ。
書き直そうが、書き直すまいが、一番ダメなソフトウェアとは「ユーザの要求に応えられないソフトウェア」だ。規模や環境の変化によって古い技術の技術的限界に直面したり、ビジネス環境の変化に追随する必要が出てきたのなら、「スクラッチから書き直す」のは立派に一つの選択肢だ。
はてなダイアリーの最初のバージョンがどういうものかは俺もよく知らないが、おそらく「LAMP」がエッジなキーワードとして持て囃されていた頃に書かれたプロダクトなんじゃないかな（間違ってたら突っ込みを）。それから時代は下り、Ruby on Railsに代表されるCoCなフレームワークの登場を経て、今や大規模分散や非同期を前提としたアーキテクチャが当たり前の時代。当然改修はしているだろうけど、MySQLを職人芸で負荷分散していた時代からは大分遠いところに来たのは間違いない。
何より、はてなダイアリーといえば「はてな記法」とカスタマイズの自由度の高さがウリだったわけだが、これらの存在が、今や機能追加や改良の妨げになっているとしても不思議じゃない。
はてなブログ開発の動機として「今どきの技術で、最初からやり直す」というのがあるのは間違いないが、それは「スクラッチからの書き直し」だから悪手なのだろうか。結局のところ、レガシーコードのメンテナンスを続ける場合と比べてどちらがより低コストか、という話の結論によるとしか言えない。
はてダのソーシャル要素といえば「トラックバック」と「idコール」と「キーワードリンク」だったわけだが、全部Twitter（とTogetter）に持っていかれたよね、という話。
だから、「はてダver.2」や「ブログ2.0」を望む声が大きいのは理解できるけど、ぶっちゃけ、そんなもんに開発リソースを突っ込んでも勝ち目なんか無い。んで、それに代わるアイディアを持ってる奴はどこにもいないと。だから、既存コードの改良ではなくスクラッチから書き直し、スモールスタートでフィードバックを受けながら方向性を考えていく、という方向性はそんなに間違っていないと思う。
ただ、現状を放置すると「それTumblrでできるよ」という話にしかならん、というのはその通りで。それ以外だと、もしgithubがblogサービスを始めたりすると、かなり客を持っていかれるのではないかという予感はする。いっそのこと、Tumblrのデッドコピーから始めるのが一番早いのかもしらんね。
少し別の話を。
これは、Twitterのgithubレポジトリだ。上でも書いた通り、Twitterはサービスをスクラッチから書き換えた。で、その過程で開発した内部向けのフレームワークを、どんどんオープンソース化している。彼らが、内部の技術をきちんと体系化して再利用可能にしていることの証左と言える。
一方、はてなのgithubレポジトリ。正直、サンプルとかプラグインばかりですね、と。
色々と理由はあるんだと思うが、一つ思うのは職人芸頼りで自分たちの技術を体系化するという部分が弱いんじゃないか、ということ（はてな発のオープンソースで広く使われてるのって何かあったっけ？）。
先ほどから散々「書き直していい」と主張しているが、誰かが言っていた通り、技術の本質を捕まえきっていない状態でフルスクラッチをやっても、失敗する可能性は高い。はてなブログがどちらなのかは、中の人にしか分からないことだけど。
はてなが経営的にあまり状況がよろしくない、という推測はおそらく当たっているのではないかと思う。
タイムラインで、誰かが「まっとうな方法で収益化する方法を真面目に考えるべきだった」と言っていたのを見た。それをしていれば、今回のような事態を招くことは無かったのだろうか。
だが、「まっとうなビジネスモデル」とは何だろう。実際問題として、ここ最近成功しているネットサービスのビジネスモデルで「ターゲティング広告」と「マスなユーザベースから抽出したビッグデータを解析して売る」以外で何か有力なものはあっただろうか。FacebookにせよTwitterにせよ、収益化の原動力はユーザ行動解析だったりするわけだ（彼らがオープンソース化に積極的なのは、インフラ技術が差別化の源ではない、という面もある）。
まぁ、あとはガチャだが、どちらにせよ現状では高木先生の逆鱗に触れるようなものしかないよね。
そんなわけで、それらに代わる第四のマネタイズモデルを思いついた人は、ぜひ近藤さんに教えてあげると良いんじゃないかな。あればだけど。
今後はてながどうなるかは分からないけど、一つ希望したいことがあるとすれば、故伊藤計劃氏のダイアリーがこの先も保全されることを望みたい。
それは、エントリを全て魚拓しろ、という話ではもちろんない。彼の生前に書かれたエントリは、当時の「はてな」という生態系を構成する一部でもあるわけで、そこから切り離して文章だけをアーカイブしてもあまり意味がない。
さんざん叩かれてるんで「見積もり金額がバラバラなんていう非常識な事態」が起きる最大の原因は「発注者が素人すぎて、発注内容が何を買いたいのかも良く分からない中身、なんていう非常識な事態」だから、ということは理解出来たと思う。
とはいえ素人が一朝一夕に発注仕様をまとめるなんて無理。どうしてもその業務が投げ出せないなら
1.その手の予約システムはweb上にくさるほどある。片っ端からアクセスして予約して使ってみる。
2.そのシステムで予約やらキャンセルやら、その他色々な機能を使ってみる。
3.最後はキャンセルしてばっくれろｗ キャンセル料くらいは勉強代とあきらめて自腹でｗ
4.自社のやりたい業務内容に近く、備えてる機能に不足がないシステムが見つかるまで１－３を繰り返す。
5.「実はこんな感じのシステムが欲しいんです」でURLつけて各業者に再見積もり依頼。最低限それに会場数やら頻度やら分かってる全ての数字はつける。
6.こんな依頼の仕方をしたら逃げる所や、リスクを積んで一気に数倍値上げしてくる所が出るだろうが、それが正当なので諦めれ。
7.実システムを例にした所で、しょせんユーザーサイドからいじって判る部分だけだと業者が見積もりにあたって想定したシステム機能は主にバックエンド関連で漏れ落ちだらけのはず。
そのままの金額で作ろうとすると、仕様変更で金が膨らんで後で上に怒られる（もしくは使い物にならないシステムできあがり）のは目に見えてるので、まずは出てきた見積もりの倍くらいの予算感と考えるといい。
8.見積もりで真ん中高めくらいの所を数社呼んで話を聞く。一番仕様の相談に親身になってくれそうなところを選定。
9.選んだ所にぶっちゃけて、リスク積んだ高めの見積もりを出して貰って、それで契約。
10.上には選定経緯や価格の妥当性を追求されるだろうがなんとかしろ。気の利いた業者だと他社の相見積もりくらい用意してくれることもある。
11.実際に仕様を決めるのは価格交渉しながら、とか契約が済んだ後から本格的に・・・という話になるが、わりとそういう業界なので気にしなくて良い。
9.でぶっちゃけてついてくる業者なら、最低赤字にならん数字は出してるはずなんで少々の仕様不備や決定遅れに対する無理は利くはず。
12.拡張性とメンテ頻度は案外費用に大きく利くし、業者側も想像がつきにくい所だから、その辺は自社の担当部門と良く話し合っておけ。
13.業者に仕様書を突きつけられても良く分からないのが関の山。仕様書は仕様書として実際の機能についてはユーザー画面と運用サイドの画面遷移ベースで話し合って合意しておくのがたぶん一番両者間の誤解が少ない。
随分業者に有利な選定方法に見えるかもしれんが、素人が発注して失敗しないようにするなら「これは儲けられそう」と思わせて業者を味方にするしかない。
ガチでメーラとWordとExcel,パワポ（しかも2003（笑））、teraterm、FFFTP位しかつかわねーからさ
あいつら本気でXP(笑）、メモリ1GBで足りてるとか思ってるからタチがわりーわ。
・コードがかける若手SE（笑）がEclipseとかMySQL、Oracle,Chrome,Firefox,IE,Java,.netと使うからある程度スペックが欲しい。(と言っても今時の５万で買える普通スペックで良い。。）
↓
・若手が新しいPC寄越せと要求
↓
・年食ったコードがかけないSE（笑）はOffice2003（笑）位しか使わないし、めんどくさいから要らないと抜かす
↓
・先輩がいいって言ってるのにお前らが要求するのか？とか言って取り合わない。
↓
・ほんとに必要な最前線の若手にまともなPCが行かない、その結果朝にパソコン起動してメーラとEclipseが起動するのに１５分かかる環境の出来上がりｗｗｗ
一方部課長以上の役職には全員Androidタブレットが支給され
お飾り部長には組織移行都度に新PCが卸される（結局何してるかもしらんがｗOfficeとIEしかつかわねーくせによｗｗｗ）
そりゃ社員がセットアップするし、何も入ってねぇから環境移行もし易いもんなｗｗ
もちろんAndroidタブレットはメール確認するくらいにしか使わないｗｗｗ
iPadやAndroidタブレットのブラウザ、メールをちょこっと触った位で最新になったと思い込むめでたい老害達。
そのHTML5とサーバサイドの開発するのは俺たち若手SEなんだがなｗｗｗｗ
でも結局使わないし飽きて部長のタブレットは机の中に入れっぱかおきっぱ。
クラウドクラウド、SalesforcrSalesforce
クソウォーターフォール維持しながらスピード感がとか寝言ぬかしてんじゃねーぞｗｗヴォケが。
上の承認が～承認が～って要件定義が～ってお前らクソ共の承認があってスピードも何もねぇだろうがｗｗｗ
その上テストドリブンしようとすると、要件が固まってないだろ！とか抜かすし、殺すぞ。
結果アホ共が思いつきで言い放った言葉は忘れない
SalesForceのパンフレットに開発は１月を目処に実装する、みたいな文言を間に受けて
え？じゃあ、プロトタイピングとかテストドリブン型とかでやるの？とか聞くと、
いや、客の要件をしっかり聞いて要件をしっかり洗い出して～上司の承認をしっかりと得て手戻りがないように～とか抜かすｗｗｗｗｗｗ
おい、お前それ今までとかわらねーじゃねーかｗｗｗｗｗ
あーいうのは少人数チームで全員が開発者としてプログラムが十二分に書けて仕様書とかの書類を最低限にして
要件定義や決定権限の大部分を現場に委任して優先順位の高い項目からを集中してやるから出来るのであって
日本のほとんどのアホSI企業の典型的なコードの書けないExcel書くだけの御用聞きSE（笑）なんて邪魔以外の何者でもないｗｗｗ
そんなゴミSE（笑）が多くを占める会社で出来る事じゃねーんだよｗｗｗｗ
あーいうゴミ共は居るだけでどーでもいい好みでの文句をグダグダいうから余計に作業が遅くなるｗｗｗ
こういうクソみたいなことばっかりやってるから古い日本企業はダメなんだよ、ゴミどもが、さっさと潰れろ。
そして俺はクソSI業界を見限ってソーシャルゲーム業界に転職準備をしているのであった（完）
http://anond.hatelabo.jp/20120207005408
まなめはうす恐るべし
ちなみに私のPCのスペックはPen4 1.6Ghz メモリ1GB HDD 30GBです。
これでメインはJavaのStruts2とSpring Eclipse3.7で組んでます。
これより低い奴出てこいや…
とりあえず一部間違えていたので訂正ｗｗｗ
１．HDDは37GBでした。ごめんなさい、実際に見てみたら間違えてました。でもいつもSVNチェックアウトするときとかデカイzipを落とす時はいつも何か消してからしています。
２．ケースはチェーンで鍵がかけられているので開けられません(^p^)よって自分での拡張は不可
後、時々あった。
PGなんてのはゴミがやる仕事だからそんなの気にかける方がゴミ
とか
とか
コードを書かなきゃいけない時点で大手ではない
ちなみにT○SとかI○M、NT○の人もコード普通に書いてたよ。
ってか書くとこは書くでしょｗｗ
んで上みたいな考えの人はそれで構わないでしょう。
そうやって思っててコードやプログラム部分なんてどうでもいい。
フロントエンドやバックエンドが発達しても設計書レベルや提案レベルに落としこむ場合に実コードの知識なんて影響しない思うならそれでどうぞって感じ
いつまでも何でもバッチ処理（笑）にこだわる人も良くいますしねｗｗｗｗ
私からしたらいつまでコードの書けないSE（笑）が成り立つか逆に聞きたい位ｗｗｗ
ま～コードがかけないSE（笑）からいつも馬鹿にされてるのを知ってるから、コードがかけるSE（笑）はどんどん逃げてっているんですよね～
わざわざプログラム（笑）とか馬鹿にされてまで居るものじゃねーよｗｗｗ
現在どんどんSI業界から出来る人が率先して辞めてるからｗｗｗ
ただでさえ人材不足のクソSI業界にいつ影響が表面化するか（もうしてるか？）楽しみですNE!
私は先に役に立たない大量の船頭しかいない泥船から抜け出しますｗｗｗ
戻って来ることもないでしょう！多分！
それではアデュー！
この努力は僕が Google に来る為に Amazonを離れた2005年半ばも続いていた。でももっとずっと進化していたよ。 Bezos が命令を出してから僕が離れるまでの間に、 Amazon は全てにおいてまず最初にサービスを考える企業へと文化的に変化していった。外部の日の目を決して見ることの無いような、スタッフへの内部的なデザインも含めて、今ではそれがデザインというもの全てに対しての基本的なアプローチになっている。
その時点では、彼らはもはや解雇の恐怖からそうしているわけではなかった。つまり、もちろんビビってはいたけれど、ドレッドヘアの海賊 Bezos 様にご奉仕するのは日常生活の一部だからね。そうじゃなく、彼らはそれが正しいことだと理解したから、サービスを提供しているんだ。確かに SOA のアプローチには長所も短所もあるし、短所を書き出してみたら切りが無い。でも全体として、 SOA ドリブンのデザインというものこそが、プラットフォームを可能にする、これは正しいことだ。
これが、 Bezos が彼の指令書で企んだことだった。彼はチームの健康状態なんて興味もなかったし（今もそうかも）、使われている技術もそうだったし、結局の処のどう取りかかるかなんて結果ができあがるまで気にもしていなかった。けれど Bezos は、 Amazon 社員の大多数が理解する前に、 Amazon はプラットフォームにならなければならないということを悟っていたんだ。
だって考えてもみてよ。なんで一オンライン書店が、拡張可能な、プログラマブルなプラットフォームになる必要がある、なんてことを考える？。そうだろ？
ともかく、 Bezos が気づいた最初の大きなポイントは、本を売り、出荷し、色々とやる仕組みが、素晴らしいコンピューティングプラットフォームに再利用でき得るということだ。だから今、彼らには Amazon Elastic Compute Cloud があるし、 Amazon Elastic MapReduce があるし、 Amazon Relational Database Service があるし、その他たくさんの aws.amazon.com で見つけられるサービスを持っている。しかもこれらのサービスは大成功した企業のバックエンドを努めていたりもする。 reddit なんか僕のお気に入りだね。
もう一つ、彼が理解した大きなポイントは、常にいつでも正しい、そんなものを作ることはできないということだ。これは Larry Tesler が、ママはこのくそったれサイトを全く使えないよと言ってのけたりでもした時に、 Bezos にピンと来るものがあったんだと思う。誰のママのことを言ったのかははっきりしないし、そんなことは問題じゃ無い。問題は、誰のママだろうとそのウンコサイトを使えないってことだ（訳注：アドバイス thx ！）。実際、僕自身、そこで5年ほど働いていたわけだけど、あのサイトは胸がザワザワするくらいひどいと思う。でも僕はその気が散るようなサイトに慣れてしまって、トップページのど真ん中あたりの数万ピクセルに集中できるようになったんだからね。
とまあ、実際の処 Bezos がどうやってその理解、一つのプロダクトで、全ての人にとってふさわしいものを作り上げることはできないということに、たどり着いたのかは定かじゃあ無い。でもその方法は問題じゃ無くて、彼は理解してるってことが重要だ。実のところこの現象には正式な名前だってある。そう、それはアクセシビリティと呼ばれるものだ。コンピューティングの世界で最も重要なものだ。
君は思うかも知れないね。「はあ？つまりそれって、目が見えない人や耳が聞こえない人のあれ？あのアクセシビリティ？」ってね。まあ君だけじゃないと思う。とにかく世間には、アクセシビリティってものを正しく理解していない、君みたいな人たちがいっぱいいっぱいいるんだから。ただそこにたどり着いてない人たちがね。だから、アクセシビリティを理解していないのは、目の見えない人や耳の聞こえない人や手足が不自由な人やその他障碍のある人の責任じゃないように、君の責任じゃない。ソフトウェアが（この場合アイデアウェアといった方が正しいかもしれない）何らかの理由で誰かにとってアクセシブルでないというとき、それはソフトウェア自身の、あるいはアイデアの伝え方そのものに責任があるんだ。それがアクセシビリティの失敗というやつなんだ。
人生における重要なその他もろもろと一緒でさ、アクセシビリティには邪悪な双子がついている。小さいときにパパとママの偏った愛情で見捨てられて、今や同じくらいの力を持つまでに育った宿敵って奴がね（もちろんアクセシビリティには宿敵はたくさんいる）。それはセキュリティだ。一体全体こいつらが仲良くやっていること何てあるかい？
でも、僕は主張したい。アクセシビリティは実際の処セキュリティより重要だということを。だって、アクセシビリティを0にダイアルするってことは、何のプロダクトも持たないってことさ。セキュリティを0にダイアルしたって、そこそこのプロダクトを持つことはできるだろう？ Playstation Network みたいにさ。
まあつまりですね、僕はみんなが分かってくれないんだったら一冊丸々この話題で本を書くことだってできるよ。分厚くて、僕が働いてた会社のありんことピコピコハンマーのエピソードで一杯の面白いやつをね。でも僕がこの話を公開しなかったら、みんなが目にすることも無いだろう。そろそろまとめに入らなきゃ。
Google がうまくやれていない最後の一つは、プラットフォームだ。僕らはプラットフォームを理解していない。僕らはプラットフォームを自分のものにしていない。みんなの中にできている人はいるだろう。でも、そんな君はマイノリティだ。辛いことだけれど、これはこの6年で僕にはっきりと感じられた。僕は競争相手のプレッシャー、 Microsoft や Amazon や最近じゃ Facebook なんかが、僕らを一斉に目覚めさせて、ユニバーサルにサービスを始めるのを期待したりもした。アドホックな、中途半端なやり方じゃなくて、多かれ少なかれ Amazon がやったようにだ。一度に全てを。マジで。偽りなしに。今その瞬間から最優先事項として扱うというように。
でも、そうはなっていない。10番やら11番めくらいのプライオリティだね。いや15番かも？。知らないけど、とにかく低い。真剣に取り組んでいるチームもいくつかあるけど、多くのチームは考えてもいない。一度もだ。ごく一部の人々がちょっとした規模でやっているだけだ。
多くのチームに、彼らのデータと処理に対してプログラマティックにアクセスできるような、ちょっとしたサービスを提供させるのだって大変だ。彼らのほとんどは、俺達はプロダクトを作っているんだ、って思っているからね。そんでもってそのちょっとしたサービスなんてのはみじめなもんさ。 Amazon の教訓に戻ってリストを見てくれよ。そんで今すぐ使えるサービスを持ってきて見てくれ。僕が知る限りでは、そんなものはない。小ビンってのは便利かもしれないけどさ、そんなの車がいる時だけだろ？（訳注：この人、 Stubby という小瓶のビールと、 stubby という「ちょっとした・不格好な」という形容詞をひっかけてしゃべってます）
プラットフォームが無ければ、プロダクトなんて使い物にならない。いやもっと正確に言うならば、プラットフォームの無いプロダクトは、いずれ同等の機能を持ったプラットフォーム化されたプロダクトに、取って代わられる。
Google+ ってのはまったくまさに、エグゼクティブリーダーシップのとても高いレベルから（やあ Larry 、 Sergey 、 Eric 、 Vic 、やあやあ）枝葉の使いっ走りまで（やあ、君だよ）、全くプラットフォームを理解していないっていう良い例だ。そう、僕らはみんな、全く理解できていない。プラットフォームの黄金律ってのは、自分のドッグフードを食えってことだ。 Google+ プラットフォームってのは惨めなまでに後知恵だ。ローンチ時には一つたりとも API が無かった。そんで最後にチェックしたときには、僕らが提供してたのはわずかばかりのほんのちっぽけな API さ。ローンチの時、あるチームのメンバーが行進してきて僕にそれを説明してくれた。だから僕は訊いたんだ「でさ、これはストーカー用 API？」って。彼女はむすっとして、「ええ」ってだけ言った。いやジョークなんだよ…いや…ジョークじゃ無いんだ…僕らが提供する唯一の API は、誰かのストリームを読み出すだけ…。うーん、僕が間違ってたのか？
Microsoft はこの20年間ドッグフードルールで知られてる。この時代の彼らにとっての文化の一つなのさ。デベロッパにドッグフードを食わせて、僕らだけ人間のご飯を食べようってわけにはいかない。それは単に短期の成功のために長期のプラットフォーム価値を損なう行為だ。プラットフォームってのはまったく長期的な視点が必要なんだよ。
Google+ は脊髄反射の代物さ。 Facebook が成功したのは、彼らがすばらしいプロダクトを作ったからだって言う、まあ実に近視眼的なものの見方の結果として生まれたものだ。でももちろん彼らが成功したのはそんな理由じゃ無い。 Facebook は他の人たちにも何かをさせてあげられる、プロダクトの美しい集合全体を作り上げたから、成功したんだ。だから Facebook はみんなにとってそれぞれ違うものだ。 Mafia Wars に全ての時間を費やす人もいれば、 Farmville で遊ぶ人もいる。何百の、いや何千の、質の高い、暇つぶしができるってわけさ。つまり、みんなのためにふさわしい何かが必ずあるんだよ。
僕らの Google+ チームは、プロダクトを出した後のマーケットを見てこう思った。「おっとっと、我々もいくつかゲームが必要みたいだな。さっそくどこかと契約して、我々のために作ってもらおう」。これが信じられないくらい間違った考え方だってことが、君にもわかってきたかい？。問題なのは、僕らが、人々がほしい物を予測して、それを提供しようとしているということだ。
そんなことは出来ないんだよ。現実的にはね。確実にやる方法なんてない。もちろんコンピューティングの歴史全体を見渡せば、それを確実に信頼性を持ってできる人間ってのがごく数人いることにはいる。 Steve Jobs がそうだろう。でも、僕らの処には Steve Jobs はいない。悪いけど、いないんだよ。
Larry Tesler は、 Bezos が Steve Jobs じゃないってことを口説いたかもしれない。でも Bezos には分かっていた。全ての人にふさわしいプロダクトを提供する為に、彼が Steve Jobs になる必要はないっていうことを。インターフェースとワークフローこそが、人々が気に入り、安心感を得るものなんだっていうことを。彼はサードパーティの開発者にそれを可能にするだけで良かった。そうすれば、後の事は自動で進んでいく。
僕の言っていることが、あまりにも明白なことだろって感じているみんな（多かったらいいな）には申し訳ない。とにかくもうびっくりするほど自明なことなんだ。ただ、僕らがそれをやってないってことを除いてはね。僕らはプラットフォームを理解していない。プラットフォームを持っていない。アクセシビリティを理解していない。アクセシビリティを持っていない。これらは基本的には同じことだ。なぜならプラットフォームがアクセシビリティを解決するからだ。プラットフォームがアクセシビリティなんだよ。
