オルタナティブ・ブログ > 森崎修司の「どうやってはかるの?」 >

計測できそうでできない多くのこと。エンピリカル(実証的)アプローチで。

Googleの開発プロセス

»

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

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

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

Comment(0)