誰かが決めなければ、みんなが不幸になる
前回ご紹介した「第3章：外科手術チーム」の前提として語られていた”コンセプトの完全性こそが重要である”という内容についてしっかりと論じられるのが、今回ご紹介する「第4章：貴族政治、民主政治、そしてシステムデザイン」です。
連載記事一覧は、コチラの最下段から
コンセプトは「完全」でなければならない
本章では、コンセプトが完全であることが重要であると述べられます。この部分は19章でも触れられていたものの、解説記事では説明をすっ飛ばしましたが、”20年たっても相変わらず正しかった”としてブルックス氏がわざわざ取り上げているトピックの一つですので、今回の解説でしっかりと理解していただければと思います。
まず、「コンセプトの完全性」を理解するために、ヨーロッパの大聖堂を例にとって説明されます。少し長いのですが引用します。
ほとんどのヨーロッパの大聖堂は、いろいろな時代にわたってさまざまな建築家によって立てつづけられてきている。各建築家が建てた部分間で、構想や建築様式の相違がみられる。後代の検知羽化は、様式の変更や好みの違いを反映させるため、それ以前の設計を「改良」したいと思うものだ。（中略）その結果、神への賛美と同じくらいに建築家の奢りを物語ることになる。
これに反し、ランス大聖堂の統合された建築様式は見事な対照を見せている。見るものは、ここの美しさ同様にそのデザインの見事な調和に心を動かされる。（中略）この完全さは8世代にわたる建築家の自己犠牲に依っていられたものであり、全体が統一されたデザインになるよう、彼らはそれぞれ自分のアイデアを犠牲にした。その結果、そこには神への賛美のみならず、堕落した人間をおごりから救出する神の力が示されることになった。
自我の発露は全体最適を損なう、ということですね。皆がコンセプトを尊重すれば全体が調和します。建物は仮に美しさが損なわれても”簡単には壊れない・崩れない”などの最低要件を満たせばあまり困りませんが、システム開発におけるコンセプトの崩壊が即ち「最低要件を満たさない」ということを意味しますので、注意が必要です。
コンセプトの完全性が損なわれると、何が起こるのか？
コンセプトの完全性を損なうことの怖さについて、ブルックス氏は、OS/360の外部仕様書の作成に関する、自らの経験を語ります。（以下は、田中による要約です。）
アーキテクチャのマネージャーの主張
- 10人の部下で仕様書を書くと、仕様書の完成までに10か月かかる。（当初予定よりも3ヶ月長くかかる）
制御プログラムのインプリテーションマネージャーの主張
- アーキテクチャチームの協力を得ながら、自分たちで仕様書を作らせてくれれば、スケジュール通りに終わらせられる。
- 品質も、実用的なレベルに落ち着かせることができる。
- アーキテクチャチームに任せると、部下150人が何もしないで時間を過ごすことになる。
アーキテクチャのマネージャーの反論
- 制御プログラムチームに仕様書作成を任せても、結局は3ヶ月遅れてしまう。
- さらに、品質も、ずっと落ちてしまう。
さて、このやり取りを見て、あなたなら、どちらを信じますか？
ブルックス氏の判断は「制御プログラムチームに任せる」だった、が・・・
ブルックス氏は、制御プログラムチームに任せることに決めました。が、その結果は、惨憺たるものでした。
アーキテクチャのマネージャーはいずれの点でも正しかった。そればかりか、コンセプトの完全性がとれなかったために、システムは開発にも変更にもはるかにコストのかさむものとなり、私はデバッグの時間にさらに1年かかると見積もらざるを得なかった。
この判断ミスの、決定的な理由は「スケジュールに間に合うという魅惑的な言葉」と「150人に仕事を与えるべきだという切実な訴え」だとブルックス氏は自戒します。
コンセプトの完全性は、どうすれば守れるのか
上記の事例を反面教師とするならば、採択すべき選択肢は「10人のアーキテクチャ・チームに仕様書を書かせる」ということになります。これは「エリートに集権する貴族政治」と言えます。
貴族政治は、昨今の「みんな平等がいいよね主義」に基づけば、忌避される思想です。ただ、忘れてはいけないのは、民主政治はすなわち衆愚政治となる可能性をはらむということです・・・という政治論は横に置いておいたとしても、少なくとも、ソフトウェア開発においては「民主政治はコンセプトが散らばる」ことを意味します。
もちろん、ブルックス氏も、民主的なやり方が悪いと言っているわけではありません。例えば、アイデアの数・種類に関して言えば、限られたメンバー（貴族）だけで考えるよりも、民主的に全員から集めていった方が色々なものがでてくるでしょう。これは民主的アプローチの良い側面です。しかしながら、それは往々にして「コンセプトの崩壊」を招きます。
前回（第3章の解説＝連載第9回）の何用にもあったように、討議は”執刀医と副執刀医で対等に行う”べきですが、意思決定は”執刀医が単独で決める”べきなのです。
「船頭多くして船山に上る」という諺がありますが、まさにそれですね。また、これは（システム開発に限らず）世の中の事業企画や事業立ち上げにおいても同じことです。3人程度で討議してコンセプトを固めないと、いつまでたっても”何をやるのか”が決まりません。さらに言えば、大勢の声を集めてコンセプトを作るというのもオススメできません。民主主義は無責任を生じさせます。何かを”決める”という行為は、ごく限られたメンバーが強い意志と責任を持って行うべき作業です。（好き嫌いの問題ではなく、物事を効率的に進めるためにはその方が良い、ということです）
貴族政治に対する不信感
とはいえ、「貴族政治」とか「エリート主義」というものに対する世の中の反発は激しいです。僕も30代の半ばを過ぎてから「まぁ、人には得意分野というものがあるので、特定領域に優れている人が、その領域を担当した方がいいよね」と思えるようになりましたが、20代の頃は「俺の方ができるのに！」とか「もっと、こんなアイデアを取り入れた方がいい！」という自己主張のカタマリでした。若いって、そういうことですよね。てへ。
それを踏まえて、ブルックス氏は、貴族政治に治する批判に関する「3つの異議」を取り上げて、どう考えるべきかを解説します。
上図内にサマりましたが、3つの異議と、それに対する回答です。
- エリートだけが作ると、実現性を無視した”理想の機能”が盛り込まれて困る → 起こり得る！だから次章で解説します
- アーキテクトが創造的楽しみを独占するのか。実現者は創意工夫できないぞ → 妄想です。インプリメンテーションも十分”創意工夫”の余地があります
- 仕様書ができるまで、実現者は指をくわえて待ってるなんて無駄だ → 妄想です。ただ待ってるだけじゃなくて、やるべきことは沢山あります
ひとつめはその通りだ、としたうえで、2つめ・3つめは「妄想だ」と切り捨てます。
2つめは「平等主義」という悪癖と、「下流工程」という言葉のもつ悪いイメージが影響しているのだと思います。上流工程だけがクリエイティブなわけじゃありません。下流だってとってもクリエイティブです。上流が得意な奴に蒸留を任せて、下流が得意な人は下流を”エレガント”にこなすことが全体最適のためには最良の選択です。（関連記事：上流（ビジネス）と下流（システム）の切り分け）
3つめは、本来的には、待ってるのが嫌ならそれまで雇わない、ということが最良の選択だと言えるでしょう。ただし、現実世界の建築とは異なり、ソフトウェア開発においては、納期圧縮が至上命題として常に存在するため、”仕様策定（上流）”と”製作（下流）”をオーバーラップさせようという方向に強いインセンティブが働きます。そのため、早い段階から、可能な範囲の製作に取り掛かることになります。要するに、上流工程をみんなで終わらせるのではなく、下流工程（の先行開発可能な部分）に早期に着手するべきなのです。
「垂直分割」が短納期開発の鍵
この「プロジェクトの前半で、インプリメンテーションに着手する」ということは、反対に「プロジェクトの後半に至ってもアーキテクチャも仕事がある」ということを意味します。
この考え方を、ブルックス氏は「垂直分割」と表現しています。
コンセプトの完全性には、システムが1つの原理を反映していること、および、利用者から見た仕様書が少人数で考えられたものであることが必要である。しかし、作業が、アーキテクチャとインプリメンテーションと実現とに実際には分けられるからと言って、そうしたデザインのシステム開発に余計に時間がかかることは無い。（中略）要するに、広範囲にわたって水平分割された作業が垂直分割によって顕著に縮められ、結果としてコミュニケーションが非常に単純化され、コンセプトの完全性が促進されることになる。
バリューチェーンの考え方において、水平統合、垂直統合という言葉があります。ご存知の通り、上流から下流を一気通貫でつなぐのが「垂直統合」で、流れの中の”ある一部分”を幅広く抑えるのが「水平統合」ですね。一方、今回は「水平分割」「垂直分割」と表現されています。ややこしいのですが、「水平分割＝水平統合」「垂直分割＝垂直統合」と考えるのが良さそうです。（うおー、ややこしいー！！！）
つまり、システム開発の「上流（アーキテクチャ）」「下流（インプリメンテ―ション）」と”水平方向に分割”されている作業を、上流から下流までの”垂直方向に分割”するべきだと言っているわけです。
具体的な”垂直分割”の例としては
- システム機能の概要（アーキテクチャ） → モジュール境界やテーブル構造の設計（インプリメンテーション）
- 完璧なシステム機能を含んだ「外部仕様書」（アーキテクチャ） → サブルーチンの慣習や管理技法、個別のアルゴリズムの設計（インプリメンテーション）
などが、本章のなかで挙げられています。尚、正直なところ、この部分は引用するをためらわれるくらいに読みやすくもなければ理解しやすくもないので苦労することと思いますが、頑張って原典にあたっていただければと思います。
以上が、「第4章：貴族政治、民主政治、そしてシステムデザイン」の読み解きとなります。次回は、今回の”コンセプトの完全性”と同様、19章でブルックス自身が「20年経っても間違っていなかったと自信をもって言える」と述べている「セカンドシステム症候群」について解説します。（なお、本章において貴族政治のリスクとして挙げられた、アーキテクチャが機能を盛り込みすぎる、という懸念についての回答にもなります。）
連載記事一覧は、コチラの最下段から
