EP.1〜3 では、読めなくなったをどう解読し、仕様を復元し、安全網を張るかという「技術の話」をしてきました。EP.4 はいったん技術から離れます。移行方針を決めるのは、最終的には経営の投資判断だからです。エンジニアがどれだけ美しい再設計を描いても、それが「いくらかけて、何を得て、何を諦めるか」の言葉に翻訳されなければ、経営は判断できません。この記事は、その翻訳のやり方 ── 塩漬けと作り直しを同じ土俵に並べ、選択肢を整理し、1枚に落とすまで ── を扱います。
「技術的にはこちらが正しい」ではなく「投資として、この会社にとって今どれが妥当か」を、非エンジニアの意思決定者と共有できる状態にすること。前提として、対象システムの現状把握が済んでいることが望ましいです（未着手なら レガシー再生 EP.1 コード考古学の6ステップ を先に）。
1. 塩漬けは「無料」ではない ── 維持コストの全体像
移行を検討する最初の壁は、たいてい「今も動いているのだから急ぐ必要はない」という声です。ここで反論の材料になるのが、塩漬け維持の隠れコストを金額として見せることです。稼働しているシステムは、静かに、しかし毎月確実にコストを発生させています。目に見える保守費だけでなく、次のような費目を積み上げます。
- 保守工数：改修・問い合わせ対応にかかる人月。属人化していると『その人が辞めたら止まる』という値付け不能なリスクも含む
- 障害コスト：年間の障害発生回数 × 1回あたりの対応時間 × 人件費。加えて、止まった間の逸失売上
- リスク：OS・言語ランタイム・ミドルウェアのサポート切れ。セキュリティ更新が止まった瞬間から、事故は『いつか』ではなく『時間の問題』になる
- 機会損失：新しい要件（新チャネル連携、データ活用、規制対応）に応えられず取り逃す売上。これが実は最大の費目になりやすい
- の利息：改修のたびに余計にかかる工数。負債の元本を返さない限り、この利息は毎年膨らむ
重要なのは、これらを「年額」に揃えて一列に並べることです。とくには、借金の利息と同じで返さなければ毎年払い続ける性質を持ちます。「今年の改修が去年より高くついた」という現場の実感は、この利息が効いている証拠です。塩漬けの総コストは、放置する年数だけ積み上がっていきます。
塩漬けの年間コスト（例としての置き方） = 保守人件費（人月 × 単価） + 障害コスト（年間発生回数 × 平均対応時間 × 単価 + 逸失売上） + EOL 対応の前倒し費用 ÷ 残存年数 + 機会損失（応えられず失注・遅延した案件の粗利） + 技術的負債の利息（同種改修が年々増える分の差額）
※ 数字は自社の実データで置き換える。桁が合えば初回は十分。会計上、既存システムの多くは償却済みで、損益計算書に費用として現れません。だから『タダで動いている』ように錯覚します。しかし実際には人件費・障害・機会損失として社内のどこかが払い続けています。見えないだけで、請求書は毎月発行されているのです。
2. 選択肢を6Rで整理する
「塩漬けか、作り直しか」という二択は、実は粗すぎます。その間に複数の中間解があり、それを整理する枠が 6R です。もともとクラウド移行の文脈で使われてきた分類ですが、レガシー全般の方針決めにそのまま使えます。全システムを一律に扱わず、サブシステム単位で6Rのどれを当てるかを決めるのがコツです。
| 方針(R) | 内容 | 初期コスト | リスク | 向いている対象 |
|---|---|---|---|---|
| Retain（現状維持） | あえて今は触らない | 低 | 低（ただし負債は増え続ける） | 変更頻度が低く、EOL がまだ先のもの |
| Retire（廃止） | 使われていない機能を捨てる | 低 | 低 | 利用実績のない機能・重複システム |
| Rehost（そのまま移設） | 中身は変えず基盤だけ移す（リフト） | 低〜中 | 低 | ハードや契約起因で急ぐが、中身は当面維持でよいもの |
| Replatform（土台の載せ替え） | アプリはほぼ据え置き、OS/DB/ランタイムを更新 | 中 | 中 | EOL 回避が主目的で、業務仕様は変えたくないもの |
| Refactor（部分改修） | 内部構造を段階的に作り替える | 中〜高 | 中 | 変更が多く、負債の利息が重い中核 |
| Replace（刷新） | 作り直す/SaaS等に置き換える | 高 | 高 | 仕様が陳腐化し、負債返済より作り直しが安いもの |
この表の効き目は、「全面刷新（Replace）以外にも道がある」と経営に見せられることにあります。とくにが差し迫っているだけなら、Replatform（土台の載せ替え）で数年の猶予を買い、その間に本丸を Refactor する、という組み合わせが現実的な落としどころになることが多いです。の勘定系やに業務ロジックが埋まった DB など、仕様がコードにしか残っていない領域ほど、いきなり Replace は危険 ── まず EP.3 で作ったで現行の振る舞いを固定してから動かします。
3. 段階移行 vs 一括刷新の損益分岐
作り直す方針（Refactor / Replace）を選んだとして、次の分岐が「一気にやるか、少しずつやるか」です。ここはコストとリスクのトレードオフがきれいに出る論点なので、経営に説明しやすい部分でもあります。
- 一括刷新（ビッグバン）：新システムを作り切って、ある日いっせいに切り替える。二重運用の期間が短く総額は抑えやすいが、切替当日に全リスクが集中する。失敗時の影響が最大化する
- 段階移行：機能ブロックごとに新へ移し、新旧を並走させながら少しずつ切り替える。1回あたりの失敗が小さく後戻りできるが、新旧併存の間は二重コストと統合の手間がかかる
損益分岐の考え方はシンプルです。段階移行の追加コストは主に「二重運用が続く月数 × 月あたりの二重コスト」。一括刷新の期待損失は「切替失敗の確率 × 失敗したときの影響額」。この2つを並べ、業務が止まったときの打撃が大きい基幹ほど、多少割高でも段階移行に倒す ── という順序で説明します。段階移行の具体的な進め方は、旧システムを少しずつ包み込んで置き換えるとして EP.5 ストラングラーパターン で詳しく扱います。
『止まると事業が傾く』基幹は段階移行が原則。『止まっても数時間なら耐えられる／規模が小さい』ものは一括刷新の方が総額で得なことが多い。全システムを同じ方式で移そうとしないこと ── ここでも機能ブロック単位で方式を混ぜてよい。
4. 経営が意思決定できる「1枚サマリー」
ここまでの材料を、意思決定者が5分で読める1枚に凝縮します。技術用語を並べた資料は、それだけで判断を止めてしまいます。載せるのは次の5点に絞ります。
- 1現状の年間コストと3年後の見通し：塩漬けを続けた場合、負債の利息と EOL でコストがどう膨らむか
- 2推奨案と、対抗の2案：6Rのどれを、どのブロックに当てるか。1案だけ出さず必ず比較で見せる
- 3投資額と回収の絵姿：初期費用と、それが何年でペイするか（削減できる保守費＋取り戻せる機会損失）
- 4やらなかった場合のリスク：セキュリティ、事業継続、人材（保守できる人がいなくなる日）
- 5意思決定してほしいこと：今回の稟議で何にGoを出すのか（全部ではなく、最初の一歩でよい）
経営が知りたいのは『技術的に正しい答え』ではなく『この会社が今、限られた予算で何にGoを出すべきか』です。1枚に落とせない提案は、まだ意思決定できる形になっていません。
5. 落とし穴 ── 判断を歪める3つのバイアス
最後に、移行方針の議論を毎回のように狂わせる3つの罠を挙げます。どれも「悪意」ではなく「善意の技術者」や「慎重な経営」から自然に生まれるものなので、名前を付けて共有しておくだけで防ぎやすくなります。
汚いコードを毎日触っていると『全部作り直したい』という衝動が働きます。しかし全面刷新は6Rの中で最も高コスト・高リスクな選択。まず Retire（廃止）で対象を減らし、Replatform で時間を買えないかを先に検討するのが順序です。作り直しは『それ以外に安い道がないと確認できたとき』の最終手段。
『これまで積み上げてきた資産だから捨てられない』は、意思決定を過去に縛る典型。判断すべきは『これから先、どちらが安く価値を生むか』だけ。過去の投資額は、今日の選択の損得には入れない ── これを口に出して合意しておくと議論が前に進みます。
『正確な試算が出るまで決められない』も罠。試算の目的は予測ではなく選択肢の順位付け。桁が合えば初回は十分で、精度は有力2案に絞ってから上げる。完璧なスプレッドシートより、来週の稟議に載る1枚のほうが価値があります。
移行方針は「技術の正解」ではなく「投資の妥当解」です。塩漬けの隠れコストを金額化し、6Rで選択肢を広げ、段階移行と一括刷新の分岐を示し、1枚に落とす ── この順序を踏めば、エンジニアの直感が経営の意思決定に翻訳されます。試算のモデル作りや、6Rの割り当て・段階移行の設計を伴走してほしい場合は レガシー刷新・資産化支援 をご覧ください。次回 EP.5 では、段階移行の実装パターンであるを扱います。続編はこのシリーズへの読者リアクションに応じて随時追加していきます。
この記事の感想を教えてください
あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。