第11回：慣れてくると、やりすぎるのが人の常｜本気で読み解く”人月の神話”（第5章「セカンドシステム症候群」）

やりすぎない、という強い心が大切

人月の神話【20周年増訂 新装版】

本日は「第2章：セカンドシステム症候群」について解説していきます。

連載記事一覧は、コチラの最下段から

「鍛錬」と「自制心」が鍵

本章では、アーキテクトが積むべき「鍛錬」と、持つべき「自制心」について語られます。このうち、特に、前回ご紹介した第4章における「コンセプトの完全性」の話でも書いた通り、自我の発露は全体最適を妨げますので「自制心」に関する記述が多くなっています。まずは「鍛錬」についてザックリとサマっておきます。

鍛錬について：

• 鍛錬とは、コミュニケーション（対話）の方法である
• インプリメンテーションにも”創意工夫”があるが、それは、実現者の責任範囲であることを理解し、実現者には「指示」ではなく「提案」するに留める
• 但し、「提案」できる実現方法案を、つねに用意しておく
• 出てきた改善案は、積極的に受け入れる

これは、アーキテクトに限らず、ありとあらゆる「創造的な現場」でリーダーが気を付けるべきことだと言えそうです。「訳者あとがき」の解説でも述べたとおり、非常に普遍的ですね。

鍛錬については以上です。続いては、本章の大半を割かれる「自制心」に関して読み解いていきましょう。

セカンドシステム＝2回目に開発するシステム

自制心については「セカンドシステム症候群を克服する」という見出しが用意されています。章題でもある、この「セカンドシステム症候群」という言葉をまずは理解しておきましょう。

まず、セカンドシステムとは、その名の通り「２つめのシステム」です。つまり、「1回作ったものと、同じようなものを作る」というシチュエーションを指しています。ブルックス氏は、この2回目に作るときに失敗するリスクが高まる、として「セカンドシステム症候群」と名付けて警鐘を鳴らしているわけですね。

最初のシステムは、慎重に作る

人は、何事にも、初めて取り組むときには慎重に取り組みます。失敗したくないですものね。その結果「ミスする可能性」が低くなります。

最初の仕事をデザインしていくとき、次から次へとフリルやら飾りやら余計なものが思い浮かんでくるのだが、それは「次回」使おうととっておく。そうこうするうちに最初のシステムが完成して、アーキテクトには確固たる自信とその手のクラスのシステムに対する経験が備わり、二度目のシステムの開発の準備ができる。

ええ。そういうものです。自転車だって、乗り始めはドキドキしますよね。コケないように、慎重に乗るわけです。坂道をブレーキいっぱい握りしーめてーゆっくりーゆっくりーくだってくーって感じですね。

二度目のシステムの罠

しかしながら、そうして得た自信と経験に、落とし穴があります。

一般的に、二度目のシステムはデザインし過ぎる傾向がある。このとき、最初のシステムデザインでは注意深く外したアイデアと装飾を使う。結果はオビディウスの言ったように（ちりも積もれば*）「山」となる。

*田中追記

その、具体的な例として、IBM709アーキテクチャが挙げられます。

7090で実現されたIBM709アーキテクチャを考えてみよう。これは非常に好評を博した過剰な飾りが無い704の改良型、すなわちセカンドシステムにあたる。命令セットがあり余るほど豊富で、通常使用されるのはその半分ほどにすぎなかった。

まぁ、ありがちですよね。何事も「慣れたころが危ない」んですよ。車の運転でも、恋愛でも、システム開発でも同じですね。そんな数多ある「慣れたころが危ない」もののなかでも、システム開発は「2回目」が危ないのだとブルックス氏は説きます。

二度目のシステムこそ、デザインするもののうちで最も危険なものである。三度目以降のシステムをデザインするときには、それまでの経験によってシステム一般の性質についてそれぞれ裏付けることができるだろうし、システムごとで違うものは、特殊で一般化できない経験の部分だとわかるものだ。

この「一般化」のくだりは、ビジネス経験においても同じです。何が一般化できて、何は一般化できないのかを体系的に理解できるかどうかが、仕事ができるかどうかの分かれ目だと言えるでしょう。いや、ほんとに。

セカンドシステム症候群の最たる例として、ブルックス氏は自身の関わったOS/360を取り上げて熱く語りますので、そのあたりは是非、原書をお読みいただければと思います。その経験を受けて、ブルックス氏が至った結論は極めてシンプルです。

「今回が、3回目以降のアーキテクトを雇え」。ええ、金言ですね。膝より深い水に入らなければ溺れない、的なアレです。（笑

なお、アーキテクト自身は2回目を避けて通れませんので、「すべての機能に”数値”をつける。即ち、処理時間と必要メモリを明確化することでボリューム感を常に把握する」というアドバイスをしています。ただ、このあたりは、近年のマシン性能の向上によりある程度解決されている部分もありますので、どちらかというと「コンセプトの主題からの距離が遠い機能は実装しない」のような、より強固な”自制心”が求められているのかもしれません。やはり、どこまでいっても、銀の弾はありませんね・・・。

「セカンドシステム」≠「パイロットシステム」

尚、19章でブルックス氏が反省の弁を述べていたように、セカンドシステムとパイロットシステムとは別物です。19章から引用します。

第5章で説明している「セカンド」システムとは、実地テストを済ませた二度目のシステムのことであり、追加された機能や装飾などをもたらす後継システムのことである。これに対して第11章の「セカンド」システムとは、実地テストされる最初のシステムの構築を試みる、2回目のトライのことなのだ。それは、新しいプロジェクトを特徴づけるスケジュールや才能、無知といったすべての制約のもとで構築される。すなわし、乏しい経験で行わなければならない制約なのだ。

ということで、本章＝第5章でとりあげた「セカンドシステム」と、第11章ででてくる「セカンドシステム（＝パイロットシステム）」は別物なのだな、と記憶の片隅に留めていただければと思います。詳細は、第11章の解説の際にとりあげましょう。

ビジネスサイドの人は、常に「セカンドシステム症候群」だ

ここで、非常に残念なお知らせがあります。というのも、システム開発において「ビジネスサイドの要件を出す人たち」の多くは、常に、つまり、ひとつめのシステムであろうと四つめのシステムであろうと「セカンドシステム症候群」を罹患しています。この事実は、システム開発サイドの人にとって悲しい出来事であるのは言うまでもないのですが、実は、ビジネスサイドの人にとっても極めて不幸な状態です。

ビジネスサイドの住人には「やりたいこと」「実現したいこと」が沢山あります。彼らは、それを、しっかりと頑張って（漏れないように）システムサイドの住人に伝えます。しかし、その数か月後に、自分が最も大事だと思っていたもの（そして、あんなに頑張って伝えたもの）が優先度を下げられてしまい、半年後のシステムリリースには実現されないと聞かされるのです。

この事態を招く原因が、「なんでもかんでも積み込みたいという思い」であり、それはアーキテクトにとっての「セカンドシステム症候群」に他なりません。このことに、ビジネスサイドの人が気づくことが、幸せなシステム開発の第一歩です。そのためには、システムサイドの人は「それらを全て入れるとシステムが破綻するのだ」ということをしっかりと説明して（つまり、論理的に構造化して、言語化する、ということですね）、ビジネスサイドに優先順位をつけさせる・トレードオフを選択させる、ということを行うことが重要です。

ちなみに、意識的に「何を得るか」ではなく「何を捨てるか」を選択してもらうように気を付けるだけで、世の中は少しだけ平和になると僕は思います。

以上、最後は少し横道にそれましたが「セカンドシステム症候群」についての解説でした。次回は、「第6章：命令を伝える」です。宜しくお願いします。

連載記事一覧は、コチラの最下段から