チームを組織化する目的は，チームをより能動的に動かし，個人の成果だけではなくそこから発生するシナジー効果を最大限に発揮させることである。プロジェクトの状況がうまく行っていようがそうでなかろうが，組織を固定化するプロジェクト・マネージャ（PM）がいる。一度決めた組織で何があろうともやり遂げるという強い意志なのかもしれない。しかし，システム開発プロジェクトの目的は，システムを完成させ納期までに動かすことである。チームの組織化はその目的を達成するための手段にほかならないのである。

Gさんはこれ以上ない組織編成をしたはずだった

　Gさんは入社5年目の中堅SEである。入社後1年間はプログラマとして活躍したが，その後はもっぱらサブリーダーとして経験を積んできた。今回，中規模のシステム開発プロジェクトのPMとして抜擢され意気軒高としていた。

　GさんはPMに就任して最初の仕事とばかり，プロジェクトの組織編成に取りかかった。編成にあたっては，先輩PMの意見を聞き，また自身も書籍などで研究した上で，入念に設計した。その甲斐あってプロジェクトは開始から順調なスタートを見せたのだった。

　基本設計フェーズが完了し，詳細設計フェーズに移る段になったときのことである。これまで在庫管理機能を担当していたサブリーダーのHさんが急きょプロジェクトを抜けることになった。Hさんは要件定義フェーズから一貫して在庫管理機能を担当しチームを引っ張ってきた貴重な戦力であった。Gさんは，ほかのサブリーダーを集めて今後の進め方を協議した。

　各サブリーダーの意見は，組織編成を見直しし，Hさんが抜けた穴を何とかカバーしながらプロジェクトを進めるというものだった。しかし，これはGさんの思いとは全く別のものだったのだ。Gさんの思いとはこうだ。「今回のプロジェクト組織は，発足時に入念に設計した組織である。従ってこれ以上の組織はあり得ないはずだ。また自分は常日頃から「初志貫徹」をモットーにしている。よって，組織を変更することなくこの危機を乗り切りたい」。

　結局，各サブリーダーはこのGさんの強い意志に動かされ，組織編成を替えることなくそのまま詳細設計以降のフェーズへと突入したのだった。しかし，Gさんの思いとは裏腹に，プロジェクト自体は思ったように好転しない。それどころか，実装フェーズが終わるころには在庫管理機能のチームだけが，遅延することとなった。

　そこで，Gさんは再度サブリーダーと協議した。遅延を挽回するための特別チームを編成すべきとの意見が大勢を占めた。しかし，ここでもGさんは持論を貫き，在庫管理機能チームの遅延は，同チームに割り当てた新リーダーが解決すべきとし，外部からプログラマを増員するという方法を打ち出したのだった。結局，これが命取りとなり，プロジェクトは大幅に遅延してしまった。

　Gさんが失敗した原因は，ただ一つ。自身が設計した組織に固執したことにある。せっかくサブリーダーを集めて会議を開き，問題解決のためのアイディアが出たにもかかわらず，これを聞き入れることができなかったことが最大の問題点なのだ。

プロジェクトは生きている

　プロジェクトは生き物である。それは，プロジェクト組織を構成する最も大きな要素が「人」であることに由来する。すなわち，プロジェクトが発足してすぐの頃は，初めて顔を合わせるメンバーもおり，PMが各メンバーの属性（スキルや性格）を把握していないだけでなく，各メンバー間のフォーマル/インフォーマルな関係も生まれていない。生まれたての卵と同じで，どう育つかによって無限の変化を見せる。プロジェクトにおける組織とは，この卵に対して今後どのように育てのるかを示すフレームに過ぎない。

　プロジェクトを育てる養育係となるのがPMなのだ。従って，PMはプロジェクトが育つ（進行する）状況に応じて，最適なフレーム（組織）を提示する義務がある。もちろん，当初設定したフレームを最後まで利用できる場合もある。しかし，大規模プロジェクトなど，ある程度の期間を要するプロジェクトの場合には，最初に設定したフレームがそのプロジェクトの完了時期まで固定化できるような場合は極めて少ない。