「へ?たのめも」 さんとこのエントリーにあった「Google のソフトウェア・エンジニアリング 」を発見。Google Developer Day Tokyo での鵜飼さんのプレゼンがわかりやすくまとめられていました。
最近、あるきっかけで異様にGoogleへの興味が沸いてきているのですが、その理由はおそらく企業としての興味というよりも中の人たちの文化的な部分に対する興味なんだろうな、と実感。
いくつか注目した点をピックアップ。
Google のプロジェクト・チーム
- 開発はデザイン、コーディング、テスト、改善、デモの運用まで上流から下流まで同じチーム(同じ人)が全部やる
- チームは少人数 (2?6人)。これ以上に増えると、プロジェクトのフォーカスを絞ってチームを分割
２?６人っていうのがバランスがよさそう。なるべくフォーカスは絞ってシンプルでコンパクトにってことですね。
Google のソフトウェア・ライフ・サイクル
Design Doc
- Google で必ず書くことになっているドキュメント
- プロジェクト立ち上げ時の 1?2週間をかけて書く。ある程度ポイントが書けたら、もうコーディングへ。
- 一般的にはあんまり長くない。詳細を書かなきゃいけなくなったら、それはまた別プロジェクトになることが多い
- Design Doc の内容
- プロジェクトの背景、目的
- おおまかな設計(コードを見ただけでは判らないような、アーキテクチャ)
- プロジェクトの参加者(このプロジェクトに関して、誰に連絡を取ればいいのか)
- セキュリティやプライバシーについての考察(問題と対処方法)
- テスト、モニタープラン(運用時の考慮。障害の発見と復旧手法など)
- レポジトリ上の位置やサーバのアドレスなど
- コードを書いていると解離していくので、できるだけ解離しないようにアップデート
ふむふむ。 自分達はいままで「企画書」と呼んでいた部類のドキュメントのことですね。ひとりで取り組むことが最近多いけど、それでもやっぱりDocを書いて残す習慣付けをしていた方が、今後会社を大きくしていくためにも良さそうだ。
自分の社内のプロジェクト管理に限らず、ちょうさん達とやっている「わくわくオープンラボ」にもうまく取り入れていけないかな。
Google のコーディング
鵜飼さんは普段、毎週 0?20個のパッチを書く。年間 3万5千行くらい。シニア・エンジニアやフェローになると、もっと書いていて、Google では、偉い人ほどコードを書きまくっている。
ハンパねぇ?
- ユニット・テストは必須。ユニット・テストを自動で実行するシステムもあり、テストが通らなくなると「直せ」 とメールが飛んでくる
- "testing on the toilet"。テストに関する intergrouplet が、トイレの壁に 「テストのコツ」を書いて貼っている。単体テスト普及活動の一環。
ユニットテストは大事。 おろそかにしてしまうことが多いけど、継続していくシステムの場合はユニット単位でのシステムのクオリティが重要だと実感。
Google の開発方針
- パフォーマンス重視(まず計測、とにかく計測、良いアルゴリズムの採用、コーディング・テクニックの積み重ね)。 Google グラフ書くのが好き。数値化重要。
- スケーラビリティ重要(いずれは Google Product になるのだから当然)。 たくさんのマシンで並列化できるように
- 信頼性(Google はマシンが大量にあるので、ハードウェアは毎日壊れる。レプリカを作ってデータは多重に持つ。 障害監視と自動的な障害復旧に力を注ぐ)
模索中ではあるのだけど、シンプルで汎用的に使える数値化の基準とか、可視化の方法がないかとここんところ悩み中。 Googleくらいになるとノウハウが詰まってそうだから、こんど知人にノウハウを聞いてみよう。