Tweet
読みました。
感想をば。
全体を通して思ったのは、やはり扱うデータの量がここまで増えるとほんのささいなことでも顕著に影響が出てくることがあるのであるということ、そういうときは予期せぬ問題が起こる可能性があるということを再認識。
まだまだ私の感覚は、効率化などというところではそういう大規模なものとはかけ離れていると思います。
まだまだ趣味プログラマを脱せてないということですね。
GFS,Bigtable,ChubbyやMapReduceなどのGoogleの分散システム周辺の知識がちゃんと理解してなかったので、だいぶまともに理解できたような気がします。
実際に触ってみないと完全に理解できない不便な頭をしているので、Hadoopとかでオープンソース実装になっているものは実際にきちんと触ってみようかと。
Cubbyのマスターノードを決定するアルゴリズムとしてPaxosというのが紹介されていたのですが、どこが効率的かなどがイマイチ実感できなかったので、その他文献を調べてみて理解を深めようかと。
Paxosアルゴリズムの「提案(Propose)」→「約束(Promise)」→「受諾(Accept)」→「承諾(Acknowledge)」というフェーズがなんかおもしろくて。
各システムの合意を得るためのアルゴリズムっていう言い回しがなんとなくエヴァのMagiっぽくておもしろく感じるんだと思います。
やはり開発スタイルについて記述されているところには、参考になることが多かったです。
プロジェクトに参加するということひとつにおいても、自主性に任せられていてそれぞれの社員が自分自身で選んでプロジェクトに参加できるというのはアメリカらしいなと思いました。
新しいWebサービスができるまでの流れとして、「アイデア出し」→「基本設計」→「デモをつくる」→「Google Labs, beta」という流れはとても参考になります。
3段階目のデモを作る過程ではデモが全社的に公開され、様々な意見/評価が集められる仕組みを採用していて、さらにTechTalkなどでデモを頻繁に行うこともできるそうです。
やはり、どんなアイデアも机などで議論してこねまくってるよりもデモ(たたき台)をつくることが重要であるということだと。
「とりあえず動くもの(たたき台)を作って、とにかくたたきまくってもらう」というのはこれからも心がけていかなければならないところですね。
もちろん、たたいてもらっている人への感謝の気持ちも忘れないで。
もう一つ、情報共有というのがとにかくしっかりしているんだろうと思いました。
メーリングリスト、ドキュメント、TechTalk、TGIF(Thanks God! It’s Friday!、自由参加の集会のようなものだそうです)というところからもGoogleがいかに情報共有を大切にしているということが伝わってきます。
「無料のカフェテリアで食事」というのも「会社がお金は出すからごはんはみんなで食べて情報共有の場としてくれ」という会社の思惑があるような気がします。
Face to Faceのコミュニケーションはやはり大切であるということですね。
ただ、Googleは逆に仕事をするときは集中できるように開発者ごとに部屋(?)のようなものに分けられているので、「集中するときはとにかく集中でき、コミュニケーションをとるときはとにかくコミュニケーションをとれる環境」というメリハリが大切ということでしょう。
社内での情報共有とコミュニケーションの問題は感じるところが特に大きかったです。
社内であっても情報漏洩リスクの問題と密接にからんじゃうシチュエーションも多いと思うので、難しい場合も多いんでしょうね。
私は、社内であれば開発に関するノウハウはとにかく共有した方が技術力という面から見てメリットが大きいと思いますが。
もちろんそういう技術的なノウハウは社会にオープンにしていくのがベストだとは思うんですが、企業としてなんでもかんでも公開できるわけではないですしね。
本の内容とは全く関係ないですが、本を読むときはやはり付箋が必須ですね。
なくて困った。
Tweet