生産性の高い「精鋭チーム」で大規模システムをつくろう
本日は、「第3章：外科手術チーム」について解説します。本章の前提として「コンセプトの完全性こそが、システム開発における成功の鍵である」というものが置かれています。これについては、次回の「第4章：貴族政治、民主政治、そしてシステムデザイン」で詳しく触れますので、一旦は”所与”として肚にお納めください。
連載記事一覧は、コチラの最下段から
少数精鋭の方が生産性が高いのは「当たり前」
本章では、外科手術チームのような専門集団で開発にあたるべきだと述べられます。その大前提となるのが「少数精鋭の方が、大量のメンバーで臨むよりも生産性が高い」ということです。
ただし、これは規模が小さい時の話です。本書内の試算では、5,000人年の仕事に、10人の精鋭チームで取り組んだ場合、10年で完成すると計算しています。それでは「時間がかかりすぎている」と言わざるを得ません。つまり「少数精鋭で取り組めば、（生産性が高いので）トータルコストは押さえられるけれど、開発期間が長くなりすぎる」と言っているわけですね。
少数精鋭で大規模システムに取り組むために
そこで、ハーラン・ミルズが提唱した考え方が取り上げられます。一言でいえば「いくつかのカタマリ（セグメント）に分解して、それぞれを少数精鋭で取り組もう」ということです。
その際に、各セグメントに割り当てるチームが「外科手術チーム」のような、専門性を持ったメンバーで構成された”一心同体型チーム”であるべきだ、と言うのが、本章の主題です。
外科手術チームは、執刀医と副執刀医の関係が”肝”
この外科手術チームの構成要素については、いろいろと詳しく述べられるのですが、ここでは、簡単に触れるに留めます。なぜなら、これらって、僕にしてみれば、あまり本質じゃないんですよねー。
外科手術チームの構成
- 執刀医：チーフプログラマ。自分でコードも書くし、文書も作る。責任者。
- 副執刀医：経験は浅いが、執刀医のスキルセットを持っていて、対等に議論したり意見交換ができる。スキルはあるので、仕事を分担されたらそれを担当してこなす。
- 管理者：プロジェクト管理上のバックオフィス機能を担当。人事とか昇給とか設備の手配とか。
- 編集者：執刀医の文書作成を支援。
- 2人の秘書：管理者と編集者、それぞれに秘書をつける。
- プログラム事務係：技術記録全般のメンテナンスを担当。各プログラムの更新記録をすべて記録し、メンバー全員に共有化する。
- ツール製作者：執刀医が求める”生産性向上のためのツール”をつくったり、メンテナンスする。
- テスト担当者：テストケースをつくったり、デバッグ用テストデータをつくったりする。テストの計画や環境準備も行う。
- 言語エキスパート：執刀医の”デザイン能力”とは別のスキルである”言語の特性を活用して、問題をうまく解決する能力”で執刀医をサポートする。
まぁ、非常にいいことが書かれてはいるので、是非、原典にあたっていただきたいとは思うのですが、なぜ本質じゃないと思っているのかというと、このチームの概念においてもっとも重要なのは「執刀医と副執刀医の関係性」だと理解しているからです。その他は、些末なんですよね。（いや、もちろん重要なんですよ。相対的に些末なだけで）
執刀医と副執刀医は、討議においては対等で、意思決定においては主従であるべき
執刀医と副執刀医は、保有するスキルセットは同じです。従って、（もちろん、経験の差による違いはあれど）同じような判断ができ、同じような作業ができます。
この2人が、同じ情報を保有することによって、全デザイン及び全コードについて「同じ理解」をすることが可能です。これは「コンセプトの完全性を保つ」ということにおいて、非常に重要です。なぜなら、コード記述は執刀医と副執刀医が役割分担をして実施しますので、この2人の「理解が異なっている」という状態は、コンセプトの完全性が保たれないリスクをはらんでいるのです。
さらに、執刀医と副執刀医が主従関係にあることが重要です。議論においては対等で良いのですが、意思決定段階では「どちらかの決定」が尊重されなければなりません。ある時は執刀医の判断基準に従い、別のある時は副執刀医の判断基準に従うということになると、コンセプトの完全性が損なわれるリスクが高まります。（当然ながら、どちらか一方の意見ではなく、バランスをとる、ということでも”完全性”から乖離していくのは避けられません）
チームを横断した「コンセプトの完全性」を維持する
上記のように、執刀医と副執刀医の関係性をクリアにすることによって「セグメント」を担当するチーム内での「コンセプトの完全性」は担保されます。
その次に考えなければいけないのは、チームを横断したシステム全体での「コンセプトの完全性」です。先述したとおり、5,000人年の大規模システム開発に10人で取り組むと10年かかるわけですから、複数チーム（たとえば20チーム＝200人）で開発に臨むことが求められます。
そこで求められるのは「執刀医」同士のコミュニケーションであり、コンセプトに対する共通的な理解です。
本章では、「執刀医間での調整を図ることが重要だ」というところで筆を置かれてしまいます。ただ、このチーム間でのコンセプトの完全性担保のために「インターフェースの統一」などの打ち手が求められてくるわけですね。そのあたりについては、「第7章：バベルの塔は、なぜ失敗に終わったか？」で触れていくことにしましょう。
（次回、第4章の読み解きはコチラから）
連載記事一覧は、コチラの最下段から
