大規模システム開発を実現する外科手術チーム ー 人月の神話
妥当なスケジュールで大規模システムを構築する際に効果的なチーム構成はどうしたら良いのだろうか。1963年から1966年、IBMのOS/360のプロジェクトは、1000人を超える人々が、プログラマ、タイピスト、マシンオペレータ、プログラム事務係、秘書、マネージャー、サポートグループなどとして従事していた。このプロジェクトを少数精鋭で実現しようとした場合、リリースまで10年以上の時間がかかってしまい、時代遅れなテクノロジーになってしまう。効率性とコンセプトの完全性の観点から見れば、デザインと製作は少数精鋭で行いたい。だが、大規模なシステムでは、製品をタイムリーに発表できるように、できるだけ大量の要員を投入する方法が望ましい。
ハーラン・ミルズによる案は、新鮮でクリエイティブな解決策を提供している。彼は、大規模な仕事の各セグメントにチームで取り組むことを提案している。ただしチームと言っても、全員で豚を解体するようなものではなく、外科手術チームのように編成されたチームでなければならないと言っている。つまり、メンバー1人ひとりが問題を切り分ける代わりに、1人が執刀して他のメンバーはそれを助け、効果と生産性が上がるようにするのである。
執刀医
ミルズはこれをチーフプログラマと称している。チーフプログラマは自ら機能と性能を定義し、プログラムをデザインし、コーディングし、テストして文書を書く。チーフプログラマになるには、優れた才能と10年に及ぶ経験を持ち、システムとアプリケーションに関する知識――例えば、応用数学やビジネスデータ分析やその他の分野の知識――を相当豊富に持っていなければならない。
副執刀医
これは執刀医の分身で、いずれの仕事もこなせるが、まだ経験が浅い者である。主な役目はデザインを一緒になって考え、話し合い、評価することである。執刀医は彼にアイデアをぶつけるが、その助言に従う必要はない（拘束されはしない）。時にはコーディングさえすることもあるが、そのコードについては一切責任を負わない。
管理者
執刀医はボスであり、人事や昇給、設備などについての最終責任者でなければならないのだが、こうしたことに時間を割くことはほとんど許されない。そこで金銭・人員・設備および機械を管理し、組織内の別の管理部門との調整役インターフェースも務める専従の管理者が必要となる。F・T・ベーカーによれば、管理者が特定チームの管理業務にかかりきりになるのは、そのプロジェクトに関して利用者・製作者間で法定義務、あるいは契約、報告義務、もしくは財務上の要件が本質的にある場合に限られる。そうでない場合は1人の管理者で2つのチームの面倒を見ることができる。
編集者
執刀医には文書を作成すること、そして最大限明瞭に書く責任がある。これは外部記述と内部記述の両方に当てはまるものだ。しかし、編集者が執刀医の書いた下書きや口述原稿を集め、これを評価・手直しして参照や参考文献を付け、いくつかの修正版を通して内容を充実させ、製作の機構全体が概観できるようにする。
2人の秘書
管理者と編集者それぞれには、秘書が必要である。管理者の秘書はプロジェクトに関する通信文と製品とは関係ないファイルを取り扱う。
プログラム事務係
この役目は、プログラミング製品ライブラリ内にあるチームの技術記録全般のメンテナンスを責任もって行うことにある。秘書としてのトレーニングを受けていて、マシン読み取り可能ファイルおよび人間が読むファイルの両方に責任を持つ。すべてのコンピュータ入力はこの事務係に提出され、必要があればそこでログ（記録）が取られて入力される。
ツール製作者
ファイルやテキストの編集、そして対話型デバッグ機能は今やすぐ使えるようになっているので、そのためのマシンやマシン操作を専門に行う要員が必要となることはめったにない。しかし、こうした機能が満足できる応答性と信頼性をもって提供されなければならないのは当然のことであり、執刀医が自分が使うそうした機能の適切さを判断する唯一の人間でなければならない。その基本的な機能の適切さを保証し、チームが必要とする特別なツール――たいていは対話型コンピュータの機能――の製作とメンテナンスおよび改良を責任もって行うツール製作者が必要になる。
テスト担当者
執刀医は、自分がプログラムを書いている最中にその1構成部分をテストするため、および終わってから全体をテストするために使う一連の適当なテストケースを必要とする。したがって、テスト担当者は、機能仕様からシステムテストケースを考案する挑戦者であると同時に、日々のデバッグ用にテストデータを工夫するアシスタントでもある。彼はまたテストの順番を計画し、単体テストに必要な環境の準備もする。
言語エキスパート
執刀医は主としてシステムデザイナーであり、表現を考えるものだ。言語エキスパートは、難解であいまいな、あるいは扱いにくい物事の処理に、言語を巧妙で効率よく使う方法を見出すことができる。優れた技法を見つけるには、ちょっとした（2、3日の）時間が必要になることはしょっちゅうである。1人の言語エキスパートで2、3人の執刀医をサポートできる。
どのように機能するのか？
上記のように定義したチームは、いくつかの点で必要項目を満たしている。10人チーム（そのうちの専門家7人）が1つの問題に取り組んでいるのだが、システムそのものは1人、ないしは一心同体の2人が考え出したものである。特に注目してもらいたいのは、従来のように編成された2人のプログラマチームと執刀医・副執刀医チームとの相違である。まず、従来型チームではパートナーで作業を分けて、それぞれが分担したところのデザインとインプリメンテーションについて責任を持つようになっている。手術チームの方では、執刀医と副執刀医それぞれが全デザインおよび全コードについて理解している。これにより、仕事のコンセプトが間違いなく統合されるのである。第二に、従来型チームではパートナーは対等とされ、避けられない判断の相違については十分話し合うか妥協するかしなくてはならない。作業とリソースが分担されているのだから、判断の違いは全体の戦略とインターフェースに限られるものの、例えばどちらのスペースをバッファに使うかといった関心のありようが異なることによって、判断の違いが生じてしまう。外科手術チームの方では、そういった関心の相違が全くなく、判断の相違については執刀医が一方的に決着をつける。この両者の違い――問題を分けないことと主従関係――が、外科手術チームを一心同体で動けるようにしているのだ。
大規模化する
大規模化の成功は、各部分でのコンセプトの完全性が根本的に改善されるかどうかにかかっている。すなわち、デザイナーの数が7分の1になるかどうかである。そうならば、問題解決に200人を投入しても、そのうちたった20人の執刀医間の調整を図るという問題に直面すればよいことになる。とはいっても、この調整の問題については独自のテクニックを使わなければならず、これについてはこの後の章で述べる。ここでは、システム全体もまたコンセプトの完全性を要するのだということ、そしてシステムアーキテクトがトップダウン方式ですべてをデザインしなければならないと言うにとどめておく。仕事が管理できるようになるには、アーキテクチャとインプリメンテーションを厳密に区別することが必要であり、システムアーキテクトはアーキテクチャから逸脱せぬよう細心の注意を払わなければならない。
感想
コンセプトの完全性を守るために、考え、判断する権限を持った開発者を限定する外科手術チームの方式は自然発生的に生まれたものだと考える。
弱み
この方式では明確に役割分担がされる一方、執刀医の離職などのリスクや空いた時間で各メンバーができることが限定されるなど、柔軟性に欠ける点が弱みと考える。
現代で通用するか？
この書籍は1975年に出版されたが、現代ではプログラム事務係はバージョン管理システム、ツール製作者はOSSに置き換えられるだろう。
時代遅れになった役割を除けば、チーフプログラマ・サブチーフ・管理者・編集者・テスト担当者・言語エキスパートの構成は現代でも一般に受け入れられる構成に思える。
チームトポロジー
以前読んだチームトポロジーでは、ストリームアラインドチームが顧客に価値を届ける中心的なチームとなり、イネイブリングチームが新たな技術を取り入れ、コンプリケイテッドサブシステムチーム・プラットフォームチームが複雑なシステムをサービスとして提供する。
ストリームアラインドチームは執刀医に類似し、イネイブリングチームが言語エキスパートに類似しているように感じた。
(ではストリームアラインドチームは執刀医の集まったチームなのかというとそうではないだろう。執刀医はコンセプトを体現する唯一の頭脳として機能することを指すため、執刀医が同じチームに複数いる、というのはそもそもおかしな話である)