Brooksは1975年に第二システム効果について書いた。そして私が参加してきたすべての チームは、書き直しが第六ヶ月に機能するプロトタイプなしで動いている頃に、通常それを 再発見した。罠は良いシステムを望むことではない — 古いものが偶然で持ちこたえていたと 信じることだ。この記事は「とりあえず書き直そう」という会話を強制的に通す チェックリストだ。
第二システム効果が実際に何であるか
Brooksの主張 — 誰もがパラフレーズしていて、私もそれに含まれる — は、設計者が 構築する二番目のシステムが最も過剰設計されるというものだ。最初のシステムは制約の 下で構築された。それが何が重要かを設計者に教えた。二番目で、設計者は解放感を感じ、 「死体がどこに埋まっているか」を知り、ついに正しくやれる。撃ちすぎる。以前に 拒否したすべてのフィーチャーを追加する。結果は出荷が難しく、保守が難しく、 置き換えが難しいシステムだ — しかも最初のものの三倍の時間がかかる。
Brooksが強調しなかったが、50年の証拠が明確にしたこと：第二システム効果はほぼ 常に書き直しだ、グリーンフィールドではない。そして書き直しはほぼ常に同じ六つの 理由で失敗する。
六つの警告サイン
チームの誰かが「とりあえず書き直そう」と言ったとき、今はこの六つの問いをこの順序で 聞く。答えが間違っていれば、書き直しは死ぬ。かもしれないではない。死ぬ。
1. 正確な本番の痛みを指差せるか？
「コードが扱いにくい」ではない。「テストが遅い」でもない。「フレームワークが古い」でもない。 具体的な本番で可視の動作が欲しい：レイテンシのスパイク、繰り返し起きるバグクラス、 現在のアーキテクチャがそれを高くするせいで三回延期した機能。
答えが本番の痛みではなく開発者体験の痛みなら、書き直しは失敗する。なぜなら 第二システムの開発者も、誰もまだ列挙していない独自の開発者体験の痛みを持つから。 既知の形の痛みを未知の形の痛みとトレードしている。
2. 元々構築した人に話したか？
元の設計者はなぜあの奇妙に見えるものがそこにあるかを知っている。70%の時間、 答えはコミット履歴にない四年前の本番インシデントだ。聞かなければ、彼らが直した バグを再実装するだろう。私はこれが自分に起きるのを二回見た。
元の設計者が去っていれば：インシデントのポストモーテムを探せ。 それも存在しない なら：自信を半分に落とせ。 書き直そうとしているコードは見えない方法で荷重を 支えている。
3. 計画に「ウォーキングスケルトン」があるか？
最初の二週間でエンドツーエンドで何かを出荷しない書き直しは、永遠に何も出荷しない。 計画は第14日のマイルストーンを持つべきだ。「一つの本物のリクエストが旧パスを シャドウしながら、0%のトラフィックで新しいシステムを本番で流れる」というものだ。 計画が「まず新しいデータモデルを構築し、次に新しいAPI層を、次に新しいUI層を」で 開くなら — おめでとう、2026年に滝のような計画を書いていて誰も気づいていない。
Bytroで私たちのイベント駆動モダナイゼーションがうまくいったのは、第二週から ライブシャドウを走らせたからだ。すべてのリクエストが旧と新の両方のシステムを 通った。毎晩アウトプットを比較した。差異がスペックだった。
4. 「完了」のための明確なメトリクスがあるか？
「旧システムが消えた」はメトリクスではない。「99%のリクエストが新しいシステムで 提供され、p99がベースラインの10%以内で、エラーレートがフラットまたは低い」は メトリクスだ。完了のタイミングを知らなければ、永遠に完了せず、チームは二つの システムの間を永遠に振り子する。
第二システム効果の破滅は新しいシステムが悪いことではない。組織が今や二つの システムを保守していることで、書き直しの「完了」が永久に四半期先にある。 三年間その状態で走っている会社を見た。
5. 新しいものが構築されている間、旧システムを誰がオーナーするか？
地味な答え：新しいものを構築するはずだった同じ人々が。 書き直しの計画が 静かに旧システムのフリーズに依存しているなら — 「18ヶ月間フィーチャーの追加を 止める」 — 書き直しは出荷前に死んでいる。
旧システムは新しいものが構築されている間に独自の重要なバグフィックスを蓄積する。 それらのフィックスを前へ持ち越すか（つまり二回構築する）、18ヶ月分の増分フィックスを 欠いた新しいシステムを出荷するか（つまりドロップイン置き換えではない）のどちらかだ。
6. ロールバックストーリーは何か？
1%のトラフィックで新しいシステムをオンにした瞬間、p99が2秒になったら何が起きるか？ 誰が気づく？何をするか？ダッシュボードはあるか？アラームはあるか？ロールバックは 一つのコマンドか、再設定して再デプロイか？
速いロールバックのない書き直しは賭けだ。賭けは時々支払うが、通常はエンジニアが 正しいためにキャリアを定義する理由があった場合だ。他のすべての場合、停止を説明 しなければならない人のためのレジュメ生成イベントだ。
実際に楽しんだ書き直し
キャリアでスムーズに進んだ唯一の書き直しはBytroのモダナイゼーションだった。 開始前にその六つの問いに答え、ほとんど「はい」と答えたから機能した：
- 本番の痛み： リアルタイムゲームバックエンドでのイベント順序がマッチ参加で プレイヤー可視のデシンクを引き起こしていた。定量化済み、ユーザー報告済み、 優先度1。
- 元の設計者： まだチームにいて、書き直しに積極的に関与。死体は可視だった。
- ウォーキングスケルトン： 第二週、一つのエンドポイントが新しいイベントバスを 流れた。第六週、五つのエンドポイント。第十二週、クリティカルパス。
- 完了のメトリクス： 99%のマッチが新しいパスで参加、p99がベースライン内。 約11ヶ月でヒット — 計画から二ヶ月遅れ、珍しく近かった。
- 移行中のオーナーシップ： 同じスクワッドが両方のシステムを所有し、旧への 非重要な変更をフリーズした。プロダクトは新しいパスへの毎週の進捗を見せたから これに同意した。
- ロールバック： 一つのフィーチャーフラグの切り替え。フラグは週次でテストされた — 定義されただけでなく、テストされた。本物のオンコールドリルで。それが 第八ヶ月にコーナーケースが現れたときに救ってくれた。
他の死を見た書き直しはその六つのうち3以上を見逃した。反例を一つも知らない。
2026年バージョン
2026年の書き直しには新しい誘惑がある：「AIがただ書き直す。」 昨年この サイトだけで約3,400コミットのAI支援開発を走らせ、静かな部分を言う：AIは 第二システム効果から守ってくれない。 書き直しへの誘惑は、最初のドラフトが 無料に感じるとき、むしろより簡単に耽溺できる。
AI支援開発が安価にできること：マイグレーションパスのスパイク — 一つのエンドポイント に対して48時間バージョンの新しいシステムを構築し、何が痛いかを見て、捨てる。 それは驚くほど未使用のテクニックだ。ほとんどの書き直しはスライドデッキを基に コミットする。AIを使ったスパイクはデッキのコストで一週間の本物の証拠を与える。
この記事から一つだけ：書き直しをスライドデッキから始めさせるな。 スパイクし、 スパイクを捨て、それから決めろ。
通常自分で気づくこと
私はこの記事全体を書き直しに抗して書いた。同時に今、Fulcrumを 動かしている — 私の作業方法に合う既存のランタイムがなかったから構築した エージェントコントロールプレーン — これは厳密に言えば既存のツールの上に 構築できたものの書き直しだ。
自分のチェックリストを通した。本番の痛みは本物だった（既存のツールはマルチ エージェントランを私が望む方法で調整しなかった）。設計者と話した（私。履歴も 書き留めた）。ウォーキングスケルトンは第一週に出荷した。明確な完了メトリクスがある。 旧スクリプトベースのワークフローと新しいものの両方を所有する。ロールバックは 「Fulcrum CLIを閉じてシェルエイリアスに戻る」だ。
六つのうち六つ。だから書き直しを許可した。三つしか出なければ棚に上げていた。 それがバーだ。使えば書き直しは出荷される。無視すれば、新しいシステムがなぜ 「もうすぐ完成する」かを18ヶ月説明し続けることになる。