セカンドシステム症候群とは？『人月の神話』の原文と具体例・防ぐ方法

セカンドシステム症候群（英語では second-system effect、second-system syndrome とも）とは、最初のシステムを成功させた設計者が、2番目のシステムで1作目に入れなかった機能や工夫をまとめて盛り込み、肥大化させてしまう傾向を指します。フレデリック・ブルックスが1975年の著書『人月の神話（The Mythical Man-Month）』第5章「The Second-System Effect」で名付けました。この記事では、第5章の原文とブルックス自身が挙げたIBMの3つの事例、ソフトウェア史でよく引かれる実例、そして基幹システムのリプレイスで同じ失敗を避けるための確認項目を順に説明します。

まとめ（先に結論）

• 定義：1作目の成功で自信を得た設計者が、1作目で「次回」に回した機能や装飾を2作目に詰め込み、過剰設計にする傾向。ブルックスは「2番目のシステムは、人が設計するもののうちで最も危険なシステムである」と書いています。
• 原典：『人月の神話』初版（1975年・Addison-Wesley）第5章。事例はIBM 709（704の後継）、Stretch、OS/360の3つで、OS/360を「典型例」としています。
• 3つの型：機能の装飾（使われない機能が増える）、前提が変わって不要になった技術の磨き込み（OS/360のリンケージエディタ）、同じ要求を「今度こそ洗練された形で」作り直そうとする過剰な汎用化（Multics当事者の証言）。
• ブルックスの処方：機能ごとに「メモリ m バイト・1回 n マイクロ秒まで」と価値の上限を決めること、2つ以上のシステムを経験した設計責任者を置くこと。
• リプレイスでの使い方：現行機能を利用実績で棚卸しし、「次回やりたかった要望」を1件ずつ審査し、機能ごとに工数と保守費の予算を付ける。ただし利用頻度だけで削ると、年1回の決算処理のような必須機能を落とします。

セカンドシステム症候群の定義と原文

ブルックスが症候群を説明する段落は短く、論点はほぼ全部ここに入っています。原文（1975年版 p.55）と筆者訳を並べます。

An architect's first work is apt to be spare and clean. He knows he doesn't know what he's doing, so he does it carefully and with great restraint.

（設計者の最初の作品は、簡素で無駄がないものになりやすい。自分が何をしているのか分かっていないと自覚しているので、慎重に、強く自制しながら作るからだ。）

This second is the most dangerous system a man ever designs.

（この2番目こそ、人が設計するもののうちで最も危険なシステムである。）

出典：Frederick P. Brooks, Jr., The Mythical Man-Month, Addison-Wesley, 1975, p.55（20周年記念版も第1〜15章は同じページ。日本語訳は筆者）。

ブルックスの説明では、1作目を設計している間にも「飾り」や「工夫」は次々に思いつき、それらは「次回」用に取り置かれます。1作目が完成し、その種類のシステムを作れるという自信がついたところで、取り置いた案がすべて2作目に流れ込みます。3作目以降は、複数の経験を突き合わせて「どのシステムにも共通する性質」と「その案件だけの事情」を区別できるので危険が下がる、というのが彼の見立てです。

章の冒頭にはオウィディウスの一節「小さなものに小さなものを足せば、大きな山になる（Adde parvum parvo magnus acervus erit）」が掲げられています。一つひとつは小さな追加でも、積み上がると山になる、という章全体の要約です。

英語での呼び方と日本語訳

原典の章題は「The Second-System Effect」です。ハッカー用語辞典のJargon File の second-system effect 項は、別名として「second-system syndrome」を挙げ、「小さく洗練されて成功したシステムの後継を設計するとき、成功に気をよくして、機能満載の巨大な怪物を設計してしまう傾向」と説明しています。同項は、この語の由来をIBM 70xx系の簡素なOS群からSystem/360のOS/360への移行としています。日本語では「セカンドシステム症候群」「第二システム効果」と訳されます。

日本語版は、国立国会図書館の書誌によると、2014年4月に丸善出版から『人月の神話』（訳：滝沢徹・牧野祐子・富澤昇）として出ています。これはピアソン桐原が2010年に出した新組新装版の再刊で、さかのぼると1996年のアジソン・ウェスレイ・パブリッシャーズ・ジャパン版（増訂版）、2002年のピアソン・エデュケーション版（新装版）があります。丸善出版版のISBNは978-4-621-06608-9です。

ブルックスが挙げたIBMの3つの事例

第5章の事例はすべて、ブルックス自身が関わったIBMの機種とOSです。著者紹介によれば、彼はSystem/360のプロジェクトマネージャで、設計段階のOS/360ソフトウェアプロジェクトの責任者も務め、それ以前はStretchとHarvestの設計者でした。

709については「命令セットがあまりに豊富で、日常的に使われたのはその約半分だけだった」と書いています。Stretchについては、クリストファー・ストレイチーの書評「とてつもなく巧妙で、とてつもなく複雑で、きわめて効果的だが、同時にどこか粗雑で無駄が多く、洗練されていない」を引用しています。

OS/360の設計者は、1410-7010用ディスクOS、StretchのOS、マーキュリー計画のリアルタイムシステム、7090用のIBSYSなどから集まっており、「2つ以上のOSを経験した者はほとんどいなかった」とブルックスは書いています。そのうえでOS/360を症候群の「典型例（prime example）」と呼び、常駐する日付更新ルーチンのうち26バイトを閏年の12月31日（366日目）の処理に充てたことを挙げ、「それはオペレーターに任せてもよかった」と述べました。メモリが高価だった時代に、まれな処理のために常駐領域を使ったことへの指摘です。

症候群が現れる3つの型

第5章は症状を2種類に分けています。これに、2作目を経験した当事者による別の見方を加えた3つで点検すると、リプレイスの要件を見直すときの漏れが減ります。

機能の装飾が積み上がる型

709の命令セットやOS/360の閏年処理がこちらです。1作目で見送った案を「せっかく作り直すのだから」と全部入れる結果、使われない機能が増え、開発量とテスト量が膨らみます。現代の業務システムでは、刷新のたびに出てくる「ついでにこれも」の要望がこの型にあたります。

前提が変わった技術を磨き込む型

ブルックスはもう1つの症状として「基本的な前提の変化によって存在意義を失った技術を、さらに洗練させる傾向」を挙げました。例はOS/360のリンケージエディタです。プログラムのオーバーレイ（限られたメモリにプログラムを差し替えながら載せる技術）を外部から構成でき、再コンパイルなしで構成を変えられる、史上最高水準のオーバーレイ機能でした。しかしOS/360はマルチプログラミングと動的なメモリ割り当てを前提とするシステムで、静的オーバーレイとは相容れません。彼はこれを「最後にして最も見事な恐竜」と表現しています。

リプレイスに置き換えると、紙の帳票レイアウトを新システムで1ミリ単位まで再現する、夜間バッチを前提にした締め処理をAPI連携の新基盤でも同じ形で作り込む、といった判断がこの型にあたります。旧システムで苦労して作った部分ほど、前提が消えていても残したくなります。

今度こそ正しく作り直したくなる型

MITのMultics開発に加わったトム・ヴァン・ヴレックは、回想記「Multics Phase One」で「Multicsは私たちにとって最初の2作目だった（Multics was our first second system）」と書いています。そのうえで、症候群は2作目に機能を無茶に足すことではなく、ほぼ同じ要求を「今度は洗練された完全な形で」満たそうとすることだ、と説明しています。1作目で継ぎはぎで足した機能を2作目では基本設計に組み込もうとし、その洗練と柔軟性のために設計判断が難しくなり、性能が出て早く統合できる単純な設計にたどり着きにくくなる、という見方です。

リプレイスでは「機能は現行どおりでよいが、今度は汎用的に作りたい」という要望がこれにあたります。機能の数は増えていなくても、設定で何でも変えられる共通基盤や、将来の拡張に備えた抽象化が膨らむと、同じ失敗になります。

ソフトウェア史でよく引かれる実例

ブルックス以降、全面的な作り直しや大型のメジャーバージョンが難航すると、セカンドシステム症候群の例として語られてきました。ただし原因は1つではないので、一次情報で経緯を確かめたうえで並べます。

Netscape 6は、ジョエル・スポルスキーが2000年4月6日の記事「Things You Should Never Do, Part I」で取り上げた例です。6.0が最初の公開ベータに入った時点で、前のメジャー版4.0から3年近くが過ぎ、5.0は存在しませんでした。彼はコードを一から書き直す決定を「ソフトウェア企業が犯しうる最悪の戦略的失敗」と書いています。こちらは機能の盛りすぎというより、動いているコードを捨てた判断への批判です。

PHP 6は、次のメジャー版の名前を決めたPHP RFC「Name of Next Release of PHP」に経緯があります。2005年に始まった新メジャー版の試みは、Unicodeの実装の難しさから2010年に放棄され、2014年の投票で次の版はPHP 7と名付けられました。言語全体にUnicodeを組み込むという大きな目標を一度に背負った点は、第5章の構図に近い例です。

Perl 6は、Raku公式FAQによると、最初の安定仕様v6.cを実装したRakudo 2015.12が2015年12月25日に公開され、2019年10月から「Raku」という名前に変わりました。後継の版としてではなく、別の言語として独立した結末です。

Python 3は、python.orgの「Sunsetting Python 2」によれば2006年に着手され、2008年には2015年でのPython 2終了を告知、2014年にそれを2020年へ延期しました。サポートは2020年1月1日に終わり、最終版2.7.18は2020年4月20日に出ています（PEP 373）。3.0自体は2008年12月3日に出ており（PEP 361）、機能の詰め込みで完成が遅れたわけではありません。3.0の公開からPython 2のサポート終了までは約11年あり、python.orgはその事情を、移行しない利用者が多く、Python 2とPython 3を長く並行して保守してきたと説明しています。機能を盛りすぎて完成が遅れた例ではないので、セカンドシステム症候群の典型として扱うのは不正確です。

第5章と第11章「1つは捨てる計画を」の違い

『人月の神話』には「2番目」が出てくる章がもう1つあり、混同されやすいところです。第11章「Plan to Throw One Away」は、化学工場のパイロットプラントのように、最初に作るシステムは試作として捨てることになると述べ、「1つは捨てる計画を立てよ。どのみち捨てることになるのだから（plan to throw one away; you will, anyhow）」と書いています。

第11章の「2つ目」は、1作目を試作として捨てたあとの本番版です。第5章の「2番目」は、1作目が完成して成功したあとの後継です。前者は経験不足を補うための作り直し、後者は経験と自信が過剰設計を招く局面で、危険の種類が逆です。

さらに1995年の20周年記念版で追加された第19章（「The Mythical Man-Month after 20 Years」）には、出版元Pearsonの見本PDFの目次によると「The Second-System Effect: Featuritis and Frequency-Guessing」という節と、「Don’t Build One to Throw Away—The Waterfall Model Is Wrong!」「An Incremental-Build Model Is Better—Progressive Refinement」という節があります。ブルックスは20年後に、第11章の「捨てる前提の作り方」を撤回し、少しずつ作って育てる進め方を支持しました。第5章の症候群についても、節題に「featuritis（機能の詰め込み）」と「frequency-guessing（頻度の推測）」を並べており、20年後にこの2つの観点から論じ直したことが分かります。試作と捨て方の考え方はプロトタイプの意味とプロトタイピングの種類・進め方で扱っています。

ブルックスが示した2つの処方

第5章は「2作目は避けられない」という前提に立ちます。誰でも一度は2作目を設計するので、処方は「避ける」ではなく「自覚して抑える」方向です。

設計者の自制：機能ごとの資源予算の設定

原文は「目を開かせる規律は、小さな機能の一つひとつに価値を割り当てることだ。機能xは、メモリ m バイト、1回の呼び出しあたり n マイクロ秒以上の価値はない、と」です（capability x is worth not more than m bytes of memory and n microseconds per invocation）。この値は初期の判断を導き、実装中も全員への目安と警告になる、と続きます。

メモリとCPU時間が今ほど貴重でなくなっても、考え方はそのまま使えます。いま上限を付けるべき資源は、開発工数、テスト工数、年間の保守費、画面の応答時間です。「この帳票出力には2人月まで」「この検索は応答2秒以内に収まらないなら作らない」と、機能単位で予算を書いておくと、追加要望が来たときに比較の物差しになります。

マネージャーの対策：2つ以上のシステムを経験した設計責任者の配置

プロジェクトマネージャー向けには「少なくとも2つのシステムを経験したシニアアーキテクトを据えること」と書かれています。加えて、2作目特有の誘惑を知っていれば、設計の細部まで基本方針が反映されているかを確かめる「正しい質問」ができる、としています。

リプレイスの体制に当てはめると、要件定義の責任者を「旧システムを作った人」だけにしない、ということです。旧システムの設計者を責任者にする場合も、他案件の設計経験と、旧システムで見送った要望の採否を確認します。別の刷新案件を経験した人を設計レビューに入れると、その案件だけの事情と一般論を切り分けやすくなります。

リプレイスで症候群を防ぐ確認項目

業務システムの刷新は、発注側にとっても開発側にとっても「2作目」になりやすい案件です。第5章の原文を手がかりに、要件定義の段階で使える確認項目を表にしました。

使い方の要点は、追加要望を断るための表ではなく、入れる理由を言葉にさせるための表だという点です。「今回入れないと何が困るか」に具体的に答えられた要望は、費用・納期・保守負担を比較して採否を決めます。答えが「せっかくだから」なら、今回の対象から外します。

一方で、利用実績だけで機能を削るのは失敗のもとです。年1回の決算処理、年度切り替え、監査対応の出力などは、利用回数が少なくても止められません。OS/360の閏年処理は「オペレーターに任せてよかった」とされましたが、それは人手で代替できたからです。利用頻度が低い機能は、削る前に「誰が、何で代替するのか」を決めておく必要があります。

もう1つの防ぎ方は、一度に全部を置き換えないことです。旧システムの周りに新しい機能を少しずつ立ち上げて置き換えるストラングラーフィグパターンの移行手順を使えば、2作目の要件を一度に確定させる必要がなくなります。ブルックスが1995年版で支持した段階的な作り方とも合う進め方です。刷新の進め方を誤った実例は基幹システム刷新の失敗事例5件の工程別の分解にまとめています。移行方式の選定や現行機能の棚卸しから相談したい場合は、当社のシステムマイグレーション・リプレイス支援でも対応しています。

YAGNI・KISSとの違い

セカンドシステム症候群は、似た教訓を持つ設計原則と並べて語られます。違いは、原則が「どう作るか」の規範であるのに対し、症候群は「いつ、誰が危ないか」を示す経験則だという点です。

マーティン・ファウラーの解説「Yagni」（2015年5月26日）は、YAGNIを「You Aren’t Gonna Need It」の頭字語で、エクストリーム・プログラミング由来の標語だと説明し、将来必要になると見込んだ機能（presumptive feature）を今は作らない考え方だとしています。YAGNIはどの時点の開発にも当てはまる規範で、症候群は「1作目が成功した直後」という時期と人に注意を向けます。両者は対立せず、2作目の要件を審査するときにYAGNIの問いを使う、という組み合わせになります。KISSの由来と実践例はKISS原則の意味・由来と実践例を参照してください。

よくある質問

セカンドシステム症候群とは何ですか？

最初のシステムを成功させた設計者が、2番目のシステムに1作目で見送った機能や工夫をまとめて盛り込み、過剰設計にしてしまう傾向です。ブルックスは『人月の神話』第5章で、2番目のシステムを「人が設計するもののうちで最も危険なシステム」と書きました。

second system syndrome と second-system effect は同じ意味ですか？

同じ現象を指します。原典の章題は「The Second-System Effect」で、Jargon File は「second-system syndrome」を別名として挙げています。日本語ではセカンドシステム症候群、第二システム効果と訳されます。

セカンドシステム症候群は誰がいつ提唱しましたか？

IBMでSystem/360とOS/360の開発を率いたフレデリック・ブルックスが、1975年刊行の『人月の神話』第5章で論じました。OS/360を自らの経験に基づく典型例として挙げています。ブルックスは1999年にACMチューリング賞を受け、2022年11月17日に91歳で亡くなりました。

3番目のシステムなら安全ですか？

ブルックスは3作目以降を、経験を突き合わせて一般化できる段階としていますが、数えるのはシステムの世代ではなく設計者の経験です。旧システムを知らない人が新たに設計すれば、その人にとっては1作目や2作目になります。

システムのリプレイスで防ぐにはどうすればよいですか？

現行機能を利用実績で棚卸しし、「次回やりたかった要望」は入れる理由を1件ずつ確かめ、機能ごとに工数・保守費・応答時間の上限を決めます。設計レビューには別の刷新案件の経験者を入れ、可能なら段階的に置き換えます。利用頻度が低くても決算や監査の処理は削れないので、削る前に代替手段を決めておきます。

関連記事

• 基幹システム刷新の失敗事例と回避策｜出荷停止と訴訟に至った5件を工程別に分解
• レガシーシステム脱却の判断基準と進め方｜経産省調査が示す停滞要因と費用の見積り方
• ストラングラーフィグパターンとは？レガシー移行の実装手順と切り戻し設計を解説
• マイグレーションとは？リプレイス・モダナイゼーションとの違いと発注判断を解説
• プロトタイプとは？意味・語源・略し方とプロトタイピングの種類・進め方