14.project+architecture

変幻する実行可能知識 14

プロジェクトのアーキテクチャ

アーキテクチャと言えば, 普通はプロダクトの, あるいはソフトウェアのアーキテクチャを思い浮かべるわけだけれど, システムやソフトウェアを作っていく過程ではプロジェクトのアーキテクチャ, つまり開発に主体的に関わっている人たちの集合がどのように形作られるか, もとても重要な要素になる.

なんでこんなことを言い始めたかというと, たまたま「フューチャー・オブ・ワーク」(トマス・W・マローン, 高橋則明訳, 2004, ランダムハウス講談社) を読んだからなのだ. なんで, こんな本を読んだかというと, マローンはMITで「プロセス・ハンドブック」 (Organizing Business Knowledge: The MIT Process Handbook, Malone他編, MIT Press, 2003 はその解説と周辺論文集) というプロジェクトをやっていて, たまたま仕事の都合上それを参照する必要があったからなのだが, プロセス・ハンドブック自体は大して面白いものではない. プロセスのパターンまでも行っていなくて, プロセスのタクソノミ (分類) 程度と考えるとよいだろう. つまりプロセス・ハンドブックそのものはアーキテクチャというよりは, プロセス・アーキテクチャのネタ帳みたいなものだ.

そのマローンが, 「フューチャー・オブ・ワーク」ではプロセスのアーキテクチャについて語っている. 前の1/3は直線的で楽天的な民主主義/自由主義/市場主義礼賛で, ちょっとうんざりではあるのだけれど, 全体的には我々のプロジェクトのアーキテクチャにとっても興味深い点がないわけではない. 彼が語るアーキテクチャというのは「定義された」アーキテクチャではなく, 「創発的な」アーキテクチャとでも言うべきものだ. 標語的に言えば「厳格な階層性からゆるやかな階層性へ」「命令と管理から調整と育成へ」. 同じような視点は「能力構築競争 - 日本の自動車産業はなぜ強いのか」(藤本隆宏, 2003, 中公新書) や「適応型ソフトウェア開発 - 変化とスピードに挑むプロジェクトマネジメント」(ジム・ハイスミス, ウルシステムズ(株)監訳, 2003, 翔泳社) などにもある. 藤本が暗黙知や深層的な文化, ハイスミスが複雑適応系に主に依拠しているのに対して, マローンは市場というメカニズムを重視しているように思える.

例えば, 普通プロジェクトにはその成功に対して最終責任を負う人間が一人いて, プロジェクト・マネージャとか呼ばれる. もちろん一人では何も作れないから, メンバを集めてきて, 彼らにマネージャが持つ権限を少しずつ渡す代わりに, マネージャが考えたとおりにソフトウェアを作らせるわけだ. 例えばマネージャの下にはチーフ・アーキテクトがいて, その下にはアーキテクトがいて, さらにその下にプログラマがいたりする. このような階層的な組織では上のものが下のものにすべきことを命令し, 管理する. それはそれでいいような気がする. 何が問題なのだろうか?

問題のひとつは, そのようなプロセス・アーキテクチャでは複雑で常に変化するような状況にうまく対応するのが難しい点だ. 何をするのにも, 長い経路と (変化に対して相対的に) 長い時間がかかり, それが蓄積すれば組織は変化に対応できなくなっていく. もう一つの問題は, 全員のモチベーションを維持しにくい点だ. マネージャはともかくとして, 末端のメンバはプロジェクトが成功することによってどんな褒賞が得られるのだろうか?

これをまったく逆に考えてみよう. あるプロジェクトがやってきた. 誰がこれをやるかをマネージャとか管理職が頭から決めるのはやめにしよう. 代わりにそのプロジェクトを持ってきた, あるいは始めたい誰かがそのプロジェクトに参加してくれそうな人を社内公募したり, 説得して回ったりする. メンバがそのプロジェクトに参加するかどうかは強制力ではなく, 自由意思なのだけれど, 自由意思を働かせるためにはそのプロジェクトに関する情報が完全に公開されていることと, そのプロジェクトが成功した場合の参加者に対するご褒美 (金銭とは限らない, 名誉とかかもしれない) がはっきりしている必要がある. メンバはプロジェクトに投資をするわけだ. 誰も投資しないようなプロジェクトは成立しない. これだけでも誰かさんの頭の中だけででっち上げられたような, 無謀なプロジェクトに突入するリスクはずいぶん減らせる. メンバには投資を回収するために働くモチベーションがあり, 成功するためには何でもする. マネージャはメンバを働かせるのではなく, 成功するために働いてもらうという立場になる.

ソフトウェア・プロジェクトには見積もりというやっかいな問題が必ずついて回る. 普通はチーフ・アーキテクトとか, リーダがえいやっと見積もりを出しているだろう. もしかしたらCoCoMoとか, 機能ポイントとか使っているかもしれないけど, いずれにしろ「不完全な情報をもとに誰かが未来をえいやっと決める」ことには変わりない. そして予測は必ず外れる (マーフィーの法則). 外れた理由は「思った通りにみんなが動いてくれなかったから」ということになる.

これも真逆に考えてみよう. 見積もりはみんながする. 見積もりに参加するものには少なくともプロジェクトに関する情報を隠したりはしない. 情報さえ与えられていれば, プロジェクト・メンバでなくてもよい (多様な立場の人間がいた方がいい). そしてご褒美が必要だ. だからプロジェクト終了時に実際の値に近い見積もりをしたものほど, いっぱい配当がもらえることにする. そして見積もりを出し合って賭をするのである (!). もちろんマローンは上品な大学教授だから, 賭とはいわず, 先物取引市場と呼ぶのだけれど:-) 「フューチャー・オブ・ワーク」にはこれによってきわめて精度の高い予測が得られたという事例が報告されている.

面白いのはなぜそのような予測をしたのかという明示的な知識はここでは示されないし, 必要でもないということである. どんな背景知識, 形式知, 暗黙知があるにせよ, それから得られた結果がすべてという世界なのだ. その辺が今までのナレッジ・マネジメントの考え方とはまったく異なっている. 今までのナレッジ・マネジメントはとりあえずどんどん知識を集めましょう, えーとそれからどうしましょうか? という世界なのだから. かといって見積もりに参加する一人一人にとっては, やはり知識が, 形式知, 暗黙知にかかわらずとても重要なのである.

このような訳の分からないものをプロジェクトのアーキテクチャと呼んでいいのだろうか? それは分からない. コードのリファクタリングの繰り返しの結果現れるものをプロダクトのアーキテクチャと呼んでいいかと問うのに似ている. しかし実はリファクタリングの結果や創発的な組織が表面的にアーキテクチャ (形) を成しているかどうかとは別に, このようなやり方がうまくいくためには, 共通するもっと深いレベルのアーキテクチャが存在しているような気がする. それは情報や知識が公開されていること, フィードバックがあること, 価値感を共有していること, 助け合い協調し合うためのメカニズム, 人を育てられる環境などである. それはどんなやり方をするにしろ, うまくやるために必要な深層のアーキテクチャなのかもしれない.

2005.11.26
山田正樹 (メタボリックス)

Comments