少数で開発できるならそうすれば良いが、そうできない規模の開発もある。
少なくない人数で開発するにはチーム編成の工夫が重要となる。
前提の整理
少数の優秀な開発者で開発できるならそうした方が良い。
多数の平凡な人達より、少数の優秀な人達で開発した方が良いと、コンピュータの学会の集まりに来るような人達は皆そう思っている。その主な理由は以下の2つである。
- 生産性に大きな個人差がある。ある研究事例では、プログラマの生産性の最低と最大では10倍の開きがあった。
- 第2章で述べたとおり、関わる人数の増加は開発コストを増加させる。コミュニケーションのコストとコミュニケーション失敗の埋め合わせ（つまりシステムデバッギング）は、主要な開発コストである。
また、単なる大量動員で開発すると、コストは上昇し、開発は遅れ、効率は悪化し、出来上がる製品は統一感に欠けるというのは、過去の事例（OS/360、Exec 8、Scope 6600、Multics、TSS、SAGEなどなど）が示すことでもある。
優秀な開発者でも少数では開発できないほどの規模は存在する。
- OS/360のピーク時では、1000人が関わり、3年間で5000人年が投じられた。
- 7倍優秀な10人が、コミュニケーションコスト減によりさらに7倍生産的に働いたと単純に仮定しても、7 * 10 * 7 = 490であり、10年間かけても5000人年には満たない。
ミルズの案：一人の主開発者を皆が助けるチーム編成
以下のように、仕事を上手く分化・特化させ、開発の根本的な部分は1人が行い、それをその他の人達が助けるチーム編成。
例えるなら、外科手術において1人の執刀医が手術するのを麻酔科医や看護師が助けるのに近い。
主開発者：根本的に開発を行う人。チーフプログラマ。手術で例えれば執刀医。
- 行うことは、機能や性能に関する要件や要求の定義、設計、コーディング、テスト、及び、ドキュメント作成。
- 主開発者は、優れた才能、10年に及ぶ経験、システムに関する知識、及び、アプリケーションに関する知識（応用数学やビジネスデータ処理）が必要。
副開発者：主開発者を代行可能な補佐役。航空機運航で例えれば副操縦士。
- 主開発者のどの仕事も行えるが、経験は少ない。
- 主な役割は、主開発者と一緒になって、設計を考えたり、議論したり、評価したりすることである。ただし、副開発者の意見に従う義務は主開発者にはない。
- チーム間の調整では、チームの代表をしばしば務める。
- 全てのコードについてよく知っている。
- 他の設計ができないかを調査する。
- 主開発者に何かあったときの保険でもある。
- コーディングをしても良いが、書いたコードの責任を持つのは主開発者である。
事務官：主開発者が開発に集中することを可能にする人事や庶務のプロ。
- 主開発者は人事や総務の面でもチームのトップであるが、開発に集中するため、そういった仕事（人、物、金、場所など）の実務のほとんどを事務官が行う。
- 1人の事務官が2チームを担当できるが、法律、契約、報告、または財務に関して、顧客から相当な量の要求がある場合には、1人で1チームを担当しても良い。
編集者：ドキュメント作成の監督者。
- 主開発者が書いたり口述筆記させたりした原稿に対して、校正、評価、修正、引用箇所や参考文献の整備、改版の管理などを行って良いドキュメントにする。
秘書2人：事務官と編集者、それぞれに対する秘書。
- 事務官秘書は、事務関連の書類を扱う。
開発庶務係：開発環境の整備・運用やプログラム製品の全ての技術情報の記録・管理などを行う人。
プロジェクト管理や開発環境の整備・運用のために以下のような業務を行い、全てのチームメンバーに対して、必要な開発環境が利用でき、必要な情報が閲覧できるようにする。
- ファイルの管理（バージョン管理システムやバイナリファイル保存方法などに関する整備と運用）
- ビルドシステム運用
- テストシステム運用
- ビルドやテストの管理（計画と結果の記録の管理）
上記のうちバッチ化（自動化）されていない部分について手を動かすのも、開発庶務係の仕事である。
（残存しているバグやどのバージョンでバグが修正されたかの情報の管理であるバグ管理について著者は言及していないが、プログラム製品の全ての技術情報を管理するとしているので、バグ管理も開発庶務係の仕事に含まれると考えて良いだろう。）
ツール担当者：チームのニーズに合ったツールを用意する人。
- プログラミングやデバッグのためのツールについて、主開発者の要望を基に、チームに合ったツールを提供する。ツールが常に問題なく利用できるように、ツールの用意（必要があればカスタマイズや作成を行う）・メンテナンス・アップグレードを行う。
テスタ：テストケースの作成とテストフレームワークをセットアップする人。
- 製品仕様などからテストケースを作成したり、主開発者が日々行うデバッグのためのテストデータを作成したりする。
- テストの順番の計画やコンポーネントテスト（単体テスト）に必要なフレームワークのセットアップも行う。
言語技師：開発に使用する言語のエキスパート。
- 難易度が高かったり、不明点があったり、トリッキーであったりするような処理について、その言語において適切で効率的なやり方を見つけるのが仕事。
- そのために2、3日を使ってちょっとした研究を行う。
- 一人で2、3チームを担当可能。
ミルズの案の効果
- チームには10人が関与するが、開発するシステムについて考える主体は1つと言って良い（主開発者の単独作業か、副開発者と2人の共同作業）。
- チーム内のコミュニケーションの仕方が単純明快であるため効率的（下図参照のこと）。
- ベーカーの論文によって、このチーム構成案がうまく行ったことが報告されている。
- 仕事の分割がなく主副関係があることの効果（以下の従来との比較を参照のこと）。
「プログラマ2人による従来の開発」（以下「従来」）と「主開発者と副開発者による開発」（以下「主副」）との比較
- 従来：2人で仕事を分割し、それぞれで設計と実装を行う。
- 主副：主開発者と副開発者の両方が、設計でもコードでも全体を知っている。これにより、リソース調整のための労力は軽減される。また、出来上がったものが概念的に整合していること（conceptual integrity）が確保される。
- 従来：2人は対等であり、考え方や立場の違いは、話し合われたり妥協されたりする必要がある。そして、仕事は分割されているので、両者が関わる全体の戦略やインターフェイス部分にこれらの違いは集約される。つまり、どちらのメモリスペースがバッファに使われるのかといったことから、戦略やインターフェイスが出来上がってしまうのである。
- 主副：仕事が分割されていないので立場による違いは起きない。考え方の違いに対しては主副の関係から主開発者が一方的に決着をつける。
スケールアップの方法
ミルズ案の10人のチームを20用意すれば200人が投入できる。チーム内で10人が7つの専門領域で働いていても、開発するシステムを考える主体は1つなので、各チームの担当部分の概念的整合性（conceptual integrity）は劇的に改善している。よって、200人中のたった20人の主開発者がどう調整を行えば良いかを考えれば良い。
この調整に必要なテクニックの詳細は後の章で述べるが、要点は以下の通り。
- システム全体にも概念的な整合性が必要。よって、1人のシステムアーキテクトによるトップダウンの設計が必要。
- アーキテクチャと実装を明確に区別し、アーキテクトはアーキテクチャに専念する。
（組織構成、特に主開発者と事務官の関係は、ミルズの案に限られるわけではない。詳細は第9章の「Organization in the Large Programming Project」とそれに続く項を参照のこと。）
他の章はこちらから：
