開発者の集合はどのように形作られているか：ソフトウェア開発をちゃんと考える（2）

ソフトウェア開発の効率性を考えていると、いつかは必ず人の問題に突き当たる。プロジェクトチームという開発者の集合はどのように形作られ、どのように動いていくものなのだろうか。そこには必ず何らかの機構（メカニズム）があるはずだ。（＠IT編集部）

» 2005年12月21日 12時00分 公開
[山田正樹，メタボリックス]

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

　なんでこんなことをいい始めたかというと、たまたま「フューチャー・オブ・ワーク」を読んだからなのだ。なんで、こんな本を読んだかというと、 著者のマローンは米マサチューセッツ工科大学で「The MIT Process Handbook Project」［注］というプロジェクトをやっていて、たまたま仕事の都合上それを参照する必要があったからなのだが、プロセス・ハンドブック自体は大して面白いものではない。プロセスのパターンまでも行っていなくて、プロセスのタクソノミ（分類）程度と考えるとよいだろう。つまり、プロセス・ハンドブックそのものはアーキテクチャというよりは、プロセス・アーキテクチャのネタ帳みたいなものだ。


　そのマローンが、「フューチャー・オブ・ワーク」ではプロセスのアーキテクチャについて語っている。前半の3分1は直線的で楽天的な民主主義・自由主義・市場主義礼賛で、ちょっとうんざりではあるのだけれど、全体的にはわれわれのプロジェクトのアーキテクチャにとっても興味深い点がないわけではない。

　彼が語るアーキテクチャというのは「定義された」アーキテクチャではなく、「創発的な」アーキテクチャとでもいうべきものだ。標語的にいえば「厳格な階層性から緩やかな階層性へ」「命令と管理から調整と育成へ」。同じような視点は「能力構築競争 - 日本の自動車産業はなぜ強いのか」（藤本隆宏）や「適応型ソフトウェア開発 - 変化とスピードに挑むプロジェクトマネジメント」（ジム・ハイスミス）などにもある。藤本が暗黙知や深層的な文化、ハイスミスが複雑適応系に主に依拠しているのに対して、マローンは市場というメカニズムを重視しているように思える。

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

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

　これをまったく逆に考えてみよう。あるプロジェクトがやって来た。誰がこれをやるかをマネージャとか管理職が頭から決めるのはやめにしよう。代わりにそのプロジェクトを持ってきた、あるいは始めたい誰かがそのプロジェクトに参加してくれそうな人を社内公募したり、説得して回ったりする。メンバーがそのプロジェクトに参加するかどうかは強制ではなく、本人たちの自由なのだけれど、自由意思を働かせるためにはそのプロジェクトに関する情報が完全に公開されていることと、そのプロジェクトが成功した場合の参加者に対するご褒美（金銭とは限らない、名誉などかもしれない）がはっきりしている必要がある。

　つまり、メンバーはプロジェクトに投資をするわけだ。誰も投資しないようなプロジェクトは成立しない。これだけでも誰かさんの頭の中だけででっち上げられたような、無謀なプロジェクトに突入するリスクはずいぶん減らせる。メンバーには投資を回収するために働くモチベーションがあり、成功するためには何でもする。マネージャはメンバーを働かせるのではなく、成功するために働いてもらうという立場になる。

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

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

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

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

今回読んだ本
▼「フューチャー・オブ・ワーク」（トマス・W・マローン、高橋則明訳、2004、ランダムハウス講談社）
▼「能力構築競争 - 日本の自動車産業はなぜ強いのか」（藤本隆宏、2003、中公新書）
▼「適応型ソフトウェア開発 - 変化とスピードに挑むプロジェクトマネジメント」（ジム・ハイスミス、ウルシステムズ（株）監訳、2003、翔泳社）

「ソフトウェア開発をちゃんと考える」バックナンバー

Copyright © ITmedia, Inc. All Rights Reserved.

注目のテーマ