まず,取材に基づいた情報から,Googleにおいて新サービスが市場導入されるまでのあらましをまとめておく。これがGoogleの製品開発プロセスと寸分違いないという確証はないが,これから進めていく同社の開発組織マネジメントについて議論するベースとなるモデルとして提示しておきたい。

1.アイデア・メーリングリスト

 当時2000名を数えた(今はおそらく3000名をはるかに超えているだろう)ソフトウエア・エンジニア(以下エンジニア)は,新サービスのアイデアや,既存サービスの改良,不具合の修正など,あらたな開発に結びつくあらゆるアイデアを自由にメーリングリスト(以下ML)に投げることができる。上げられたアイデアの一つ一つに対して,すべてのSEは数段階の評価を下すことができる。画面上,各アイデアが記述されたエリアの右端に,個々のアイデアの評点をチェックするエリアがあり,その評点が集計されている。

 評点の基準は,最も高い評価としては「アイデアとして優れており,Googleとしてぜひ取り組むべき」,低い評価としては「アイデアとしては面白いが,Googleがやるべきことではない」,最も低い評価としては「アイデアとして陳腐であり,Googleとしてやるべきでは無論ない」といった段階があるという。

 当然,こうした評点は集計されているはずであり,アイデアとその属性ごとにランキングすることが可能だろう。誰がどのようなアイデアを出したかも一目瞭然のはずである。ここにアイデアの自然淘汰のしくみが組み込まれている。

2.20%プロジェクト

 アイデアに自信のある起案者は,目をつけたエンジニアのもとを回って自分のアイデアを売り込んだりする。人気があり,エンジニアの関心を惹くアイデアを基に「暫定プロジェクト」が立ち上がる。いわゆる「20%ルール」の下,エンジニアは自分の労働時間のうち80%は既に正式プロジェクトとして立ち上がっている既定の仕事に費やし,残り20%は創造的なサービスを産み出す研究開発的活動をすることが「義務付けられている」。「暫定プロジェクト」とは,この20%側のプロジェクトのことである。

 暫定プロジェクトの段階で,すぐにプロトタイプのコーディングが始まる。いわゆる大企業にありがちな,「製品企画書が本社マーケティング部門会議でのプレゼンを経て,正式にゴーサインが出てから」コーディングを開始するのではなく,いきなりどんどんと自由に発想を形にしてしまう。

3.20%から80%側へ

 各エンジニアが自分自身の「20%」をどのような暫定プロジェクトに充て,何をやっているかは,記載が義務付けられているウィークリーレポートを通じて2000名(当時)の全エンジニアが共有している。当然プロジェクトマネージャーもその情報を共有しており,20%の中でも特に有望と思われるものを80%側に格上げする。そこで初めて多くの予算が正式に配分される。

 この時,Googleが公にしている分野別リソース配分政策(エンジニアの人数配分),すなわち7割がサーチ技術と広告ビジネス,2割が関連サービス領域(ツールバーやローカルサーチなど),1割が入力補助ツールなど(Google Suggestなど),という原則に基づいて80%側のプロジェクトの領域別バランスを見ながら,格上げの判断がなされているだろう。

 ベスト100プロジェクトというランキングが常に更新され,社内で公表されているという。このランキングのアルゴリズムは....何だと思われますか?

4.Google Labを経てGoogle Betaへ

 80%側のプロジェクトで一応の完成を見たサービスは,Google Labで公開される。「どれだけのユーザーが価値を感じてアクセスし,ダウンロードしてくれたか,リアルタイムで立ち上がり曲線が分かります。その反応が悪ければそのプロジェクトはfull launchに至らずに停止されます」。ここでもアイデアは自然淘汰されていく。ここを卒業できずに消え去っていったサービスも多い。

 その結果しだいで,Google Beta版としてより本格的なリリースとなる。

 次回以降は,この開発プロセスを支える情報共有のメカニズムを紹介し,その効果を分析していく。