Google のソフトウェア・エンジニアリングから感じたことと、やってみたいこと

Google

Google Developer Day Tokyo の鵜飼さんのプレゼンより、「Google のエンジニアはどうやって開発しているのか?」


へ〜たのめも:Google のソフトウェア・エンジニアリング

まとまっていて、わかりやすい。個人的に気になったものをピックアップしてみる。

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

  • チームは少人数(2〜6人)。これ以上に増えると、プロジェクトのフォーカスを絞ってチームを分割

いまは3人でインフラ構築をやっている。これくらいのだと、いろいろなメリットがある。

  • コミュニケーションが取りやすい
  • ギャップがあっても、すぐに修正ができる
  • メンバーの意見が聞ける

当たり前っぽいことだけど、大規模開発になると、どれも問題になりやすいと思う。

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

  • イノベーション重視。デザイン・フェーズで方向性が決まったら、さっさとコーディング

設計とコードは乖離するもの。作ってみないと、わからないことは多い。

DesignDoc

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

これ、すごくいいなと思った。
これくらいの粒度なら、しっかりとアップデートしていくことができるかもしれない。
システムを作る上で、ずれてはいけないものを書いておくことができるかも。

Googleのコーディング

  • 誰かが書いたコードは、必ず他の人にレビューを受ける。開発者とレビューアーがお互いに合意した時点で、はじめてチェックイン

コードレビューはとても重要だと思う。設計レビューをしても、実装はずれてしまう。コードレビューをすれば、その可能性をかなり小さくできるはず。
コードレビューが必ずあるということは、コーディングの前から人にコードが見られることを意識することになる。
酷いコードは見せられないよね。

Google の情報共有

  • 一部屋に2〜4人。同じ部屋で開発。ちょっとしたバッドノウハウをすぐに後の人に聞けるので、個室よりもいい

チームの人数と一緒で、これもいい。わからないことに、ひとりでずっとはまることがなくなる。周りのひとを巻き込むのも大事だと思う。
ひとりで生みの苦しみを味わうのもよい経験だけど、メンバーから効率的に知識を吸収するのも大事。

Googleのエンジニア気質

  • 自分で改善すべき点を見つけて改善する。直すべきところを見つけて直す。「でも、それ僕のプロジェクトじゃないから」はダメ。不具合を報告するだけではなくパッチを書くことが推奨

大企業になればなるほど、こういう文化は少ない気がする。
自分のプロジェクトじゃないから関わらない、というのは個人の問題に見えるけど、本当はその組織の問題だと思う。
積極的に関わっていくことが、よいことで、推奨すべき行為だという共通認識がないと難しい。


仕事を通じて感じたことと、個人で開発をして感じたことが、ちょうど半分ずつくらい。
いったいどんなプロセスを経て、こんな組織を作ることができたんだろう。そっちにもすごく興味がある。


このエントリーを書いていて、なんとなくGoogleとTOYOTAって似てるのかなと思った。
# TOYOTAのことはあまり知らない。なんとなく頭に浮かんだ。

とりあえずGoogle先生に聞いてみたら、こんなのがヒットした。

ちゃんと分析すれば、意外な共通点なんかが見つかるかもしれないな。