Googleの開発プロセス

昨日に続きますが、ディベロッパーサミットでgoogleの開発プロセスについて聴講してきました。Googleは一味異なるプロセスや組織をお持ちのようです。請負開発をされている方には新鮮なのではないでしょうか。工藤氏はGoogleのインフラ寄りの話、小松氏は開発プロセスの話で講演されていました。サービスインフラも開発プロセスも私にとっては身近な話ですが、ここでは、小松氏の講演について書こうと思います。講演では、極めて異例/エキセントリックというプロセスは話されていませんでしたが、以下は、特徴的と感じました。

1. 異なる観点から複数のレビューを実施していること。いわゆるperspective-based readingを実施しているそうです。役割分担型レビュー（reviewというよりはおそらくinspection）で、セキュリティやユーザインタフェースの観点から見たデザイン/ソースコードの妥当性検証/不具合・不整合部分の指摘（レビュー）を実施しているそうです。perspective-based reading自体は他でも効果が認められており、一般に入手可能なものとしてBasili教授らの報告があります。
2. 単体テスト用のコードを書くことを必須としていること。現実には全ての単体テストをテスト用のコードで実施するのは難しそうに思えますが、構成管理システム（版管理システム）を管理するライブラリアンのような役目のメンバがいて、単体テスト用のコードと実際にサービスに使うコードの両方が揃っていないとソースコードを版管理システムに登録してくれないことがあるそうです。
3. リリースエンジニアというリリースに伴う作業全般を担当してくれるエンジニアがいる。サービスのリリースには固有の知識や多数の作業が伴うので、なるほどと思う内容でした。
4. プロトタイピング。サービスの初期段階はモックアップ作成だそうです。そこから設計がスタートするという感じです。請負のように顧客やユーザがやりたいことを持っているわけではないので、当たり前といえば当たり前のように思います。現実には、稟議や企画書を書いて請負業者に話をするところからスタートするのが一般的だとすると（少なくとも国内では一般的なはず）light weightといえるでしょう。

工藤氏は、BigTableやChubbyといったGoogleのインフラ部分の要素技術について講演されていました。こちらも興味深く、「RDBのように汎用化/抽象化しすぎるとそれを使う開発者側は、どういう使い方をすればどういうインパクトがあったり、どういう利点があるかがわからなくなる」という話が印象的でした。