先に要点
- 古いシステムを捨てられないのは、単に判断が遅いからではなく、レガシーシステム が業務の中核に深く入り込んでいるからです。
- 問題は 「古いこと」 そのものより、「止めると困る」 「誰も全体を把握していない」 「置き換えコストが読めない」 状態です。
- 実務では、全部一気に捨てるより、危ない部分から切り分けて進める方が現実的なことが多いです。
なんでそんな古いシステムをまだ使っているの？
現場の外から見ると、こう思うことはかなりあります。
でも実際の会社では、古いシステムをやめたい気持ちはあっても、簡単には捨てられません。
それは単に保守的だからではなく、業務、責任、予算、移行の怖さが全部つながっているからです。
この記事では、古いシステムを捨てられない理由を、感情論ではなく実務の事情として整理します。
まず、何が問題なのか
古いシステムが残ると聞くと、技術が古いからダメ と考えがちです。
もちろん古い言語や古いミドルウェアは問題になります。
ただ、現場で本当に重いのは、次のような状態です。
- そのシステムが日々の業務に深く入り込んでいる
- 一部の人しか仕組みを分かっていない
- 触るたびに別のところが壊れそうで怖い
- 置き換えの全体像と費用が読めない
- 失敗したときの責任を誰も取りたくない
つまり、古いシステム の問題は、技術だけではなく 業務に食い込んでいること にあります。
1. 業務がそのシステム前提で回っている
古いシステムを捨てられない最大の理由は、業務フローがすでにそのシステム前提で固まっていることです。
たとえば、次のような状態です。
画面
毎朝この画面を見て処理を始める
CSV
このCSVを出して別部署へ渡す
帳票
この帳票が会計監査で必要
バッチ
このバッチが止まると翌日の集計が回らない
こんな状態だと、システムは単なる道具ではなく、業務そのものの一部になります。
そのため、置き換えは 新しい画面を作れば終わり ではなく、業務手順、帳票、連携、教育まで含めて見直す話になります。
2. 仕様が人に埋まっている
古いシステムでは、仕様書より 長年触ってきた担当者の頭の中 に知識が入っていることが多いです。
これはかなり危ない状態です。
なぜなら、表面上は動いていても、
- どのボタンがどの業務ルールを前提にしているか
- 例外処理がどこに埋まっているか
- 他システムとの暗黙の連携が何か
が分からないからです。
この状態で一気に作り直そうとすると、今の仕様を再現したつもりなのに業務が止まる ことが起きます。
3. 置き換えコストが見積もりにくい
古いシステムは、見た目以上に周辺が複雑です。
画面の数、帳票、バッチ、権限、夜間処理、マスタ管理、外部連携、運用フローまで含めると、想定よりかなり広がります。
しかも、調べるほど これも必要だった が増えやすいです。
このため、経営や管理側から見ると、「いくらかかるのか読みにくい」「いつ終わるか読みにくい」「そのわりに現状も一応動いている」という判断になりやすく、刷新が後回しになりやすくなります。
4. 新しくすると一時的に不便になる
新しいシステムが長期的には正しくても、移行直後はたいてい不便が出ます。
- 画面の場所が変わる
- CSV の列順が変わる
- 印刷レイアウトが変わる
- 入力ルールが変わる
- 権限申請が増える
こうした変化は、技術的には改善でも、現場には 今までより使いにくい と感じられやすいです。
そのため、刷新は 技術的に良くなるか だけでなく、利用部門が受け入れられるか まで見ないと進みにくいです。
5. 責任の所在が曖昧になりやすい
古いシステムの刷新は、意外とここが大きいです。
誰が最終的に決めるのかが曖昧だと、話は止まりやすくなります。
IT部門
危ないと思っている
現場
変えるのが不安
経営
費用対効果が見えにくい
ベンダー
段階的にやろうと言う
全員に理由があるので、反対している人だけが悪いわけではありません。
ただ、責任を持って どこから変えるか を決める人がいないと、古いまま延命されがちです。
6. 技術的負債が大きくても、今すぐ困るわけではない
古いシステムには、たいてい 技術的負債 が積み上がっています。
でも、技術的負債は 今日すぐ売上が止まる 形では見えにくいです。
そのため、「新機能追加のたびに遅い」「障害対応がじわじわ重い」「テストがなくて毎回怖い」といった形で苦しさは増えていても、目先の業務が回っている限り後回しにされやすいです。
じゃあ、どうすれば現実的なのか
実務では、全部捨てるか、そのまま延命するか の二択で考えない方がうまくいきます。
たとえば、次の順で見る方が現実的です。
全部捨てるか延命するかの二択にしない
- 1まず危ないところを見つける
担当者依存、障害時の影響、保守契約やサポート終了、セキュリティ面から優先順位をつける。
- 2いきなり全面刷新しない
画面・帳票・連携・バッチのように分けて進める。
- 3仕様の棚卸しを先にやる
今このシステムが何をしているかを、画面一覧・業務フロー・連携先・例外処理・帳票で整理する。
1. まず危ないところを見つける
- 担当者依存が強い
- 障害時の影響が大きい
- 保守契約やサポート終了が近い
- セキュリティ面で危ない
こういう部分から順番に見た方が、刷新の優先順位がつけやすいです。
2. いきなり全面刷新しない
古いシステムは、全部一気に置き換えるより、
- 画面だけ分ける
- 帳票だけ先に整理する
- 連携部分だけ切り出す
- バッチだけ別管理にする
のように分けて進めた方が安全なことが多いです。
3. 仕様の棚卸しを先にやる
作り直しより前に、今このシステムが何をしているか を整理するだけでも価値があります。
ここで役立つのが、画面一覧、業務フロー、連携先、例外処理、帳票の棚卸しです。
設計の前段で認識を揃えたいなら、要件定義で最低限決めることは？ のような整理も相性がいいです。
古いシステムを捨てられない問題のよくある質問
Q. 何年使ったら 古いシステム ですか？
A. 一概には言えませんが、ハードウェア保守切れ、OS / DB / 言語のサポート終了、設計者・実装者が誰もいない、のどれかに当てはまれば、年数に関わらず 古い 扱いになります。
Q. レガシーシステムを刷新する一番のリスクは何ですか？
A. 何をしているか正確に分からないまま作り直す ことです。仕様書が古い、現場で口頭運用、例外処理が膨大、などで、新システムが旧システムの一部の機能を満たせず止まることが多いです。
Q. 一気に作り直すべきですか、段階的に置き換えるべきですか？
A. 段階的が原則です。Strangler Fig パターン で、外側から新システムに置き換え、旧システムを徐々に縮小していく方が、リスクとコストの両面で安全です。
Q. ベンダーロックインから抜け出すには？
A. データの自社保有、API による疎結合、標準技術への寄せ替え、内製比率の段階的引き上げ、が現実的な手段です。一夜にしては抜けられないので、5年計画 のような長期視点で動きます。
Q. COBOL や VB6 のような古い技術は本当に置き換えるべきですか？
A. 必ずしも置き換えが正解ではありません。動いている、変えない方が安い 場合は維持が合理的です。ただし、人材確保、改修コスト、セキュリティリスクを定期的に見直す体制は必要です。
Q. 経営層に刷新の必要性を伝えるには？
A. 数字で示すのが効果的です。現状の保守費用 ÷ 年 障害頻度と影響範囲 業務改善で削減できる工数 セキュリティリスクの想定影響額、を比較すると判断材料になります。
Q. 刷新プロジェクトでよくある失敗は？
A. 仕様の棚卸しを飛ばす、全部 1リリースで切り替える、現場ヒアリングが浅い、旧システムを並行稼働させない、責任分担を曖昧にする、です。これらを避けるだけで成功率はかなり上がります。
まとめ
古いシステムを捨てられないのは、判断が弱いからでも、現場が怠けているからでもありません。
そのシステムが業務の中核に入り込み、仕様が人に埋まり、置き換えコストと責任が見えにくいからです。
だからこそ、実務では 全部をすぐ捨てる より、レガシーシステム の中で危ないところを見つけ、順番に切り分けていく方が現実的です。
古いこと自体を責めるより、どこが危ないのか どこから分けられるのか を見始める方が、次の一歩につながりやすいです。