大規模プログラム開発プロジェクトにおける組織

以下の書籍に、題意のことが書かれていたので抜粋します。

• 組織の目的は、必要となるコミュニケーションと調整作業を減らすこと
• マネージャーとアーキテクトのそれぞれの役割

を再認識するために以下を掲載しました。

人月の神話―狼人間を撃つ銀の弾はない (Professional Computing Series)

　プロジェクトにn人の要員がいる場合、各二人のコミュニケーションについては、（n^2 - n）/ 2通りのインターフェースがあり、潜在的には、調整を必要とするグループの総数は約n^2通りとなる。組織の目的は、必要となるコミュニケーションと調整作業を減らすことだから、組織は、上記のようなコミュニケーション問題に対する根本的な取り組みが必要なのだ。
　コミュニケーションを不要にする手段は、作業の分割と機能の専門化である。組織が木構造のようになっているのは、作業の分割と専門化が適用された際、詳細なコミュニケーションの必要性を減少させたいことを反映している。

その後、以下のように文章は続きます。

　コミュニケーションはネットワーク構造なのだ。多くのエンジニアリング研究組織では、組織体系が木構造では適切さを欠くケースが多いので、スタッフグループ、特別チーム、委員会、あるいはマトリックス型の組織まで生み出した。
　そこで、木構造のプログラム開発組織を考察し、その下位の木構造が効果的であるために備えていなくてはならない必須要素を検証してみよう。その必須要素とは、以下のとおりである。

1. 使命
2. 制作主任（マネージャー）
3. 技術主任（アーキテクト）
4. スケジュール
5. 作業分担
6. 各部分間のインターフェース定義

”制作主任”とは、以下のように書かれています。

　制作主任とは何だろうか。彼はメンバーを収集し、仕事を分け、スケジュールを立てる。また、必要なリソースを手に入れ、不足することのないようにする。つまり、その主な役割な、チームの外、すなわち上層部や横とのコミュニケーションを図ることである。また、チーム内のコミュニケーションおよび報告の様式を確立する。最後に、スケジュールどおりことが進んでいることを確かめ、状況の変化に応じてリソースや組織を動かす。

”技術主任”とは、以下のように書かれています。

　では、技術主任はどうだろうか。開発するデザインを考え、下位部分を決定し、外側からどのように見えるか記述し、内部構造を描く。デザイン全体の統一性やコンセプトの完全性を提供して、システムの複雑さに歯止めをかける。技術的な問題が発生したら、個別にその解決策を考えだすか、あるいは必要に応じてシステムデザインを変える。
（中略）
彼のコミュニケーションは、主としてチーム内に向けられる。そして、その仕事は完全に技術的なことに終始すると言ってよい。