 |
チームを発足させ，その組織を編成する際に，いろいろなサブチームを作ることは少なくない。これは，プロジェクト・マネージャ（PM）として必要な素養「三つのN」の一つである“NetEnabler”としては非常に重要なことである。しかし，サブチームをより詳細に分割することに腐心するばかりに，かえって機能性を失うことは少なくない。特に人数の少ないプロジェクトでサブチームの数ばかりが多くなり結果的に担当者が複数のチームを兼務する例や，一つのチームの人数が1～2人のチームをたくさん作る例は多い。このように組織化ばかりを気にしすぎると，結果として組織の分割損が発生し，かえって能動的な動きができなくなる。
このプロジェクトは朝飯前だとIさんは考えていた
Iさんはこれまで数多くのプロジェクトを経験してきたベテランのPMである。最近では実績を買われ大規模プロジェクトのPMをいくつか経験していた。今回，Iさんは50人月程度のプロジェクトを担当することとなった。数百人～数千人規模の大規模プロジェクトと比較すると小さなプロジェクトである。Iさんにとっては朝飯前だと考えていた。
早速，Iさんはチームを発足させるべくチーム編成を行うことにした。最初に，システムの特性に応じた組織図のフレームの作成に取りかかった。規模は小さいと言いながらも，既存メインフレームとの連携を含んだオープン系システムであった。そこでIさんは図のようなフレームを準備した。
 |
| 図●Iさんが作成した組織のフレーム |
このフレームに沿って要員の手配と割り当てを考えようとしたのである。しかし，システム規模的には小規模な開発である。すべてのチームに潤沢に要員を割り当てることは困難である。そこでIさんは各チームにSEを一人ずつ割り当てて組織を編成したのである。
プロジェクトがスタートし，要件定義から基本設計までは順調に進んだ。しかし，詳細設計フェーズで異変が起きた。チームごとの進捗度合いにかなりの開きが生じてしまったのである。さらに，基本設計レビューが終わったチームから優先的にプログラマを配備したために，後から完了したチームに配備すべきプログラマが不足してしまったのである。先に配備したプログラマをほかのチームに回そうにも，各リーダーSEが自分の担当分が遅れるリスクを憂慮し，手放そうとしなかったのだ。
