Googleのプロジェクト・マネジメント手法を考える

もう夜の10時27分だ。私はこのごろ、夜11時をすぎたらパソコンの画面はなるべく見ないように心がけている。率直に告白するが、中年になると、体力(とくに視力)が一日持たないのだ。ちゃんと夜眠らないと、翌朝になっても回復しない。

でも、そう言いながら、昨晩は会社で11時半近くまで仲間と仕事をしていた。残業は嫌いなのに、三連休までつぶして働くのは、まことにクレイジーである。どうしてクレイジーかというと、私が現在プロジェクト・スケジューリングの仕事をしているからだ、という理由に行き着く。大きな海外プロジェクトがはじまった。もうすぐ顧客も来日して我々のオフィスに駐在をはじめる。あと一月以内にプロジェクト・マスター・スケジュールを確定させる約束だ。その時までの間は、当面、フロントエンド・スケジュールで皆を動かさなければならない。で、そのフロントエンド・スケジュールを期日までに仕上げるために、夜遅くまで残業していたという訳である。スケジュール作成の仕事が、期日を守れないのでは、シャレにもならないではないか。

そう言いながらも、ふと考える。なぜ、プロジェクトには期日があるのだろう。無論、それは契約条項でそう決まっている(決めさせられた)からだ。顧客は、今からきっかり3年半後に、新工場で量産を開始したい、と内外に宣言している。それは株主や政府への約束でもあり、また融資の条件でもあるのだろう。だから、我々のプロジェクトの完成が1日遅れるごとに、巨額のペナルティを課すという条件がついている。

タスクやアクティビティに期日など設けるべきではない。そう主張する人々もいる。その代表格は、TOC理論(制約条件の理論)で有名な、ゴールドラット博士だ。彼は、『クリティカル・チェーン』という、プロジェクト・マネジメントの新しい手法を提唱した。その中で、彼はアクティビティに期日を設定することの有害性を指摘して、“学生シンドローム”という用語を作った。これは、提出期限の直前にならないと宿題をはじめない、学生の習性を皮肉った言葉だ。ちょうど夏休みの宿題を8月の最後になってからやりはじめる小学生のように、人々は仕事に着手しようと思えばできるのに、締切が近づかないとはじめない。これがプロジェクトの納期短縮を阻害する。そう彼は主張する。

そのかわりに、彼が推奨するのは、「できるだけ早く」という督促の方法なのだ。が、なんだかこれではフライパンから火の中へ飛び込んだみたいだ。そもそも、クリティカル・チェーンが劇的な納期短縮を売り物にしているのだから、当然かもしれないが、だまされたような気がしないだろうか。(このクリティカル・チェーン・プロジェクト・マネジメント=CCPMについては、近いうちにきちんと書きたいと思っている)

では、CCPM以外に、誰か期日設定について批判的なことを言っていないだろうか、とネットを探していたら、Steve Yeggeという人が書いたGoogleでのプロジェクト・マネジメント手法に関するBlog記事にたどり着いた(これは「Fine Software Writing」の中でも、青木靖氏による素晴らしい翻訳で読める)。これが、じつに興味深い。

Yeggeによると、Google社内でのプロジェクトの進め方は、こうだ。だれか(誰でもいい)素晴らしいアイデアを思いついた人間が、プロジェクトを立ち上げる。そうしたら、優先度のついた作業のキューを管理できるサーバを用意する。プロジェクトが進むにつれて、いろいろな人が、自分の思いついたアイデアを実現するためのタスクを、このキューに投げ込む。Yeggeはこれを「アイデアやバグを投げ込むゴミ捨て場のような場所」と呼んでいる。そして、このプロジェクトに興味を持った人間は、誰でも、そのキューから自分のやりたいタスクを拾い出すことができる。そして、何か作業する。その結果、見事に終わるかもしれないし、あるいは何か別のタスクを生み出すかもしれない。そうしたら、その新しいタスクをキューに返す。

Googleでは、この作業キューが空になった時、「プロジェクトの完了」という定義になっている。キューはプロジェクトの進行につれて、最初はどんどんふくれていくだろう。だが、多くの人がかかわってくるにつれて、しだいに増え方の速度は減っていく。ついには新規追加より拾い出しの方が多くなり、最後には空に近づく。ちなみに、Yeggeによると、開発者は、いつでも好きなときに、プロジェクトを変えることができる。誰も何も理由を聞いたりしない。そこにあるのは、自発性の法則だけ、ということらしい。

したがって、Googleでは、ガントチャートも日程表も、作業の期日も何もない。目に見えるようなプロジェクト管理の仕組みは一切ない。後ろから技術者のお尻をひっぱたくような『管理』はしないということだ。そして、開発者はつねに自分の就業時間の20%を、自分のメインのプロジェクト以外で、やりたいことに使うよう強く促されている。

どう? 素晴らしいだろうか。ここで働いてみたい? この記事を読んで、そう思う人が大勢いても、不思議ではない。すでに3年前の記事だから、事情は変わっているかもしれないが、あるいはこうした組織の本質は変わらないようにも、思える。

ただし。Googleについて、一つだけ理解しておいた方がいいことがある。この会社は不思議な会社で、情報システムを確かに開発しているくせに、それを売ってはいないのだ。製品は、基本的にタダで提供する。そして、彼らは、その製品に集まってくる人々の数を担保に、広告収入で食べているのである。

彼らの素晴らしい製品の数々は、タダである。だから、基本的にユーザは、いついつまでに持ってこいとか、こんな機能は好きじゃない、とか文句を言うことができない--むろん社会的に有害な機能があれば別だが。そのおかげで、Googleは“いつ次の新製品を出荷するか”を、一切コミットしないで済んでいるのである。これは、極めて類例の少ないビジネスモデルであって、自社用であれ請負であれ通常の情報システム開発プロジェクトとは異なっているのである。

それで? --答えは、円環を描いて元のところに戻ってくる。プロジェクトを動かすものは、ステークホルダの期待なのである。ステークホルダとは、通常は、プロジェクト・チーム員を除く、プロジェクトの利害関係者をさす。一番はユーザであり、あるいは発注者(予算承認者)であり、そして上級管理者達だ。彼らから無縁で、自分の作りたい面白い物だけを開発していたい、そう思う技術者は多いだろう。だが、エンジニアの給料はふつう、(上司の手を通じて)顧客が払ってくれているのである。そして、顧客がGoogleの広告スポンサーほどは寛大でない時、あなたには(そして私にも)やはりプロジェクトの工程表が必要になるのである。
by Tomoichi_Sato | 2009-10-13 23:02 | プロジェクト・マネジメント | Comments(1)
Commented by kdmsnr at 2009-10-14 02:23 x
CCPMの話、楽しみにしています。
<< 静寂の価値 需要の「読み」が必要になる時 >>