プロジェクトを管理しないという発想：自己組織化プロジェクトの育て方（1）（2/4 ページ）

[山根圭輔，アクセンチュア]

2. いまどきの開発プロジェクト〜なぜ、昔は良かった式の話になるのか

　最近、火事になる問題プロジェクトが増加している、という話をよく聞きます。そんな話題の際、プロジェクトが難しくなった原因として必ず語られるのが、『システム開発が複雑で、変化が激しいものになってきた』ということです。「うん、確かにそうだ。昔とだいぶ変わったよな」と納得して、「では、どうする？」という話題に移りがちですが、ここでちょっと立ち止まって考えてみます。「複雑で変化が激しい」とはいったいどういうことでしょう？

図1 システムの複雑さ

　メインフレームが中心だった時代には、メインフレームのOSとその上で構築するアプリケーション（画面系、バッチ系、帳票系の3種類）、および実行するユーザーといった構成が一般的でした。ここで、登場する“もの”を数えてみると5つです。

　現在の典型的なWebアプリケーションを考えてみるとどうでしょう？ OS、データベース、それにミドルウェアとなるサーバ群がアプリケーション、Web、レポートなどに分かれています。この上にフレームワークが乗り、その上にやっと構築するアプリケーションが乗っかります。Javaなどの場合、仮想マシン（VM）も忘れてはいけません。さらに既存の他システムが存在することがほとんどですので、これらも数に入れてやる必要があります。登場する“もの”は、条件によってだいぶ数が変わるでしょうが、大まかにいって15といったところでしょうか。

図2 ステークホルダーの複雑さ

　次に、システム開発に登場する、利害関係者（ステークホルダー）の複雑さを考えてみます。メインフレーム時代では、OSとハードウェアのベンダはほぼ同一ですから1人と考えられます。さらに、システム部ユーザー、社内ユーザー、そしてシステム開発を請け負うベンダというのが典型的な構成でしょう。登場する“もの”の種類は4つでした。

　現在の場合どうでしょう？ システム部ユーザー、社内ユーザー、システム開発を請け負うベンダという構成に変わりはないとしても、いまでは、そこに加わる関係者がにわかに増えます。オフショア開発をすれば、中国やインドのサブベンダ、ハードウェアとOSのベンダが別々であることは珍しくありません。運用監視をアウトソースしていればそのサービスベンダ、ミドルウェアにも種類ごとにベンダがいます。それから、ホストの時代には考えられなかった一般ユーザーというのも考えなければならないでしょう。これも条件によって変わりますが、おおむね登場する“もの”の種類は10、といったところでしょう。

図3 イベントの複雑さ

　昔と変わったものはまだあります。「変化が激しい」ということを定量的に表すにはどうしたらいいでしょう？ 仮に、「ある一定期間に訪れるイベントの数」というのを変化の激しさとして表すのはどうでしょうか？ 要件定義→設計→開発→テスト→リリース、と1つずつイベントを越えるごとにプロジェクトの環境は変化していきます。さらにビジネス環境の変化はこれらのフェイズと何ら関係なく、大きなイベントとして随時発生するでしょう。

　残念ながら、過去と現在のプロジェクトフェイズ期間を比較する良いデータを見つけることができませんでした。そこであくまで仮説ですが、ある一定期間というのを半年間とすると、昔はその程度の期間であれば要件定義と設計の一部分が終了する、といったところでしょうか。登場するイベント数は2となります。

　一方、現在であれば、半年間で要件定義〜リリースまで一通り済ませてしまうということもざらにあるでしょう。そして半年の間にビジネス環境が変わってしまうということもあります。定量的に、といっておきながら、定性的な仮説がたくさん入ってしまって申し訳ありませんが、取りあえず仮に登場するイベント数を5としましょう。

キーワードは、『何もかも、粒がたくさん増えた！』

　以上、昔といまのシステム開発に登場する“もの”の数の違いをまとめると下のようになります。

	昔	今	昔と今の比較
システムの複雑さ	5	15	3倍に増加
ステークホルダーの複雑さ	4	10	2.5倍に増加
イベントの複雑さ	2	5	2.5倍に増加

　実際には、いまも昔も要素の複雑さが絡み合うのがプロジェクトの常ですから、単純に足し合わせてみると、

	昔	今	昔と今の比較
開発プロジェクトの複雑さ合計？	11	30	約3倍に増加

　登場するものの数が約3倍というのが、昔に比べたいまのプロジェクトの複雑度を表しているといえるのでしょうか？ 現実には違います。登場するものの数が増えることによってそれらの関係性が増えるのですが、この関係性の複雑さこそが、多くの問題の原因なのです。

　例えば、ステークホルダー数が増えれば増えるほど、コミュニケーションを取るべき組み合わせは指数関数的に増えます。システムモジュール数が増えれば増えるほど、そのインターフェイスの組み合わせもやはり指数関数的に増えることになります。試しに、上記に登場する“もの”同士がそれぞれ関係するネットワークの組み合わせを数えると、途端に組み合わせ数が爆発し、昔といまの差分は非常に大きなものになります。

	昔	今	昔と今の比較
システムの複雑さ	10組	105組	約10倍に増加
ステークホルダーの複雑さ	6組	45組	約8倍に増加
イベントの複雑さ	1組	10組	10倍に増加

　単純に足し合わせてみると、

	昔	今	昔と今の比較
開発プロジェクトの複雑さ合計？	17組	160組	約10倍に増加！！

　登場する“もの”が3倍に増えると、10倍の関係性の増加に膨れ上がってしまいました。

　さて、以上から、『昔に比べていまは、10倍複雑な環境となっている』というつもりはありません。これまで挙げてきた数字は、感覚的に正しい気もしますが、あくまで感覚値にすぎません。ポイントは、

• 昔といまを比較するのに、アプリケーションのコンポーネントなど、数えた『もの』＝『粒』の質の違いについては言及していない
• 登場する『もの』＝『粒』が増えるとその間の関係性（ネットワーク）は指数関数的に増加する

という2点に集約されます。

　実際のところ、現在のアプリケーション・コンポーネントが、20年前と何か画期的に違うアルゴリズムを利用しているかというと、そんなことはありません。どちらかといえば、1つのモジュール内で記述されるロジックの複雑度はどんどん下がっているはずです。となると、現在のプロジェクトの問題点である『複雑さ』とは、プロジェクトを構成する『もの』＝『粒』が増えたことによる粒同士の関係、すなわちネットワークの爆発にあるとはいえないでしょうか？