参考：「Google のエンジニアはどうやって開発しているのか?」

「へ?たのめも」 さんとこのエントリーにあった「Google のソフトウェア・エンジニアリング 」を発見。Google Developer Day Tokyo での鵜飼さんのプレゼンがわかりやすくまとめられていました。

最近、あるきっかけで異様にGoogleへの興味が沸いてきているのですが、その理由はおそらく企業としての興味というよりも中の人たちの文化的な部分に対する興味なんだろうな、と実感。

いくつか注目した点をピックアップ。

Google のプロジェクト・チーム

• 開発はデザイン、コーディング、テスト、改善、デモの運用まで上流から下流まで同じチーム(同じ人)が全部やる
• チームは少人数 (2?6人)。これ以上に増えると、プロジェクトのフォーカスを絞ってチームを分割

２?６人っていうのがバランスがよさそう。なるべくフォーカスは絞ってシンプルでコンパクトにってことですね。

Google のソフトウェア・ライフ・サイクル

• アイデアが出たら、Design Doc と呼ばれるドキュメントを書く

Design Doc

• Google で必ず書くことになっているドキュメント
• プロジェクト立ち上げ時の 1?2週間をかけて書く。ある程度ポイントが書けたら、もうコーディングへ。
• 一般的にはあんまり長くない。詳細を書かなきゃいけなくなったら、それはまた別プロジェクトになることが多い
• Design Doc の内容
  • プロジェクトの背景、目的
  • おおまかな設計(コードを見ただけでは判らないような、アーキテクチャ)
  • プロジェクトの参加者(このプロジェクトに関して、誰に連絡を取ればいいのか)
  • セキュリティやプライバシーについての考察(問題と対処方法)
  • テスト、モニタープラン(運用時の考慮。障害の発見と復旧手法など)
  • レポジトリ上の位置やサーバのアドレスなど
• コードを書いていると解離していくので、できるだけ解離しないようにアップデート

ふむふむ。 自分達はいままで「企画書」と呼んでいた部類のドキュメントのことですね。ひとりで取り組むことが最近多いけど、それでもやっぱりDocを書いて残す習慣付けをしていた方が、今後会社を大きくしていくためにも良さそうだ。

自分の社内のプロジェクト管理に限らず、ちょうさん達とやっている「わくわくオープンラボ」にもうまく取り入れていけないかな。

Google のコーディング

鵜飼さんは普段、毎週 0?20個のパッチを書く。年間 3万5千行くらい。シニア・エンジニアやフェローになると、もっと書いていて、Google では、偉い人ほどコードを書きまくっている。

ハンパねぇ?

ユニットテストは大事。 おろそかにしてしまうことが多いけど、継続していくシステムの場合はユニット単位でのシステムのクオリティが重要だと実感。

Google の開発方針

模索中ではあるのだけど、シンプルで汎用的に使える数値化の基準とか、可視化の方法がないかとここんところ悩み中。 Googleくらいになるとノウハウが詰まってそうだから、こんど知人にノウハウを聞いてみよう。