レガシーシステムはいつ入れ替えるべきなのか｜判断を分ける5つの兆候

「そろそろ替えどきかもしれない」——基幹システムの担当者から、そんな相談を受けることがあります。理由を聞くと、たいてい「導入から15年経ったから」「画面が古いから」。でも、それだけでは投資の説明がつきません。経営会議で「なぜ今なのか」を問われたとき、年数はいちばん弱い根拠です。

物流・生産管理の現場でシステム刷新の支援に立ち会ってきた立場から言うと、替えどきを示すのは年数ではなく、日々の業務の中に出ている“兆候”です。

まず1分だけ：“老朽化”は年数では測れない

レガシーシステムとは、古い技術で作られ、改修や連携が難しくなったまま使い続けているシステムを指します。ここで大事なのは、稼働年数そのものは老朽化の証拠にならないという点です。20年動いていても業務に過不足なく応え続けているシステムもあれば、5年で身動きが取れなくなるシステムもあります。判断材料にすべきは「何年か」ではなく、「今どんな症状が出ているか」です。

判断を分ける5つの兆候

私が現場で確認するのは、次の5つです。どれか1つでも心当たりがあれば、まずは事実を集めてみることをお勧めします。

①改修の見積が毎回跳ね上がる

同じくらいの規模の改修なのに、去年より今年、今年より来年と見積工数が伸びていきます。これはコードが複雑になっているのではなく、担当者が「壊さないように恐る恐る触っている」証拠であることが多いです。見るべきは金額の絶対値ではなく、同規模案件の工数の伸び率。3回続けて伸びていたら、個別対応の限界です。

②仕様を知る人が1人しかいない

「その仕様、〇〇さんに聞かないと分からない」——この一言が出る頻度を数えてみてください。属人化そのものは珍しいことではありません。問題は、その人が異動・退職したときに止まる業務が具体的に何かを、誰も洗い出せていない状態です。ここは基幹システム刷新は“新しくすれば解決”じゃないとも重なる論点で、人に依存した仕様理解そのものが刷新対象になります。

③データを外に出せない

取引先や他部門から「このデータを連携してほしい」と言われたとき、即座に「できません」と答えていないでしょうか。原因がシステムの制約なのか、単に誰も試していないだけなのかを分けて考える必要があります。見るべきは、連携要望に対して「できません」で終わっている件数と、その代わりに人手で埋めている作業時間です。

④サポート終了が決まっている

これは5つの中でいちばん分かりやすい兆候です。OSやミドルウェア、パッケージ製品のサポート終了日は公表されています。終了後は脆弱性対応が止まり、障害が起きても直しようがない状態で使い続けることになります。カレンダーに落とし込んで、逆算で検討を始める期限が見えているかどうかを確認してください。

⑤業務側の変更を断念し始めている

いちばん見えにくいのがこれです。「システムでは対応できないので、今のやり方を続けます」という判断は、失敗として報告されません。むしろ現場の工夫として静かに承認され、議事録にも残らないまま定着していきます。要望自体が出なくなったら、それは業務側がすでに諦めているサインです。

兆候が出てから動くと何が起きるか

ここまでの5つは、どれも「出てから気づいても手遅れ」というわけではありません。ただし、兆候が出そろってから動き始めると、選べる選択肢が急に狭くなります。サポート終了の期限が迫った状態で検討を始めると、比較検討に使える時間が数か月しかなく、結局「今と同じ機能を持つ製品への置き換え」という消去法の選択になりがちです。業務を見直す余地のない、いちばん高くつく替え方です。

投資額の面でも同じことが起きます。平時に段階的に検討していれば分割できた投資が、緊急対応では一括で必要になります。システム投資はいくらまで出していいのかという問いは、本来は業務の重要度と改修コストの推移から逆算するものですが、兆候が出そろってからでは「今動かせる予算の上限」だけが基準になってしまいます。判断の主導権を、自社が握れなくなるということです。

一段深く：本当のコストは“迂回路”の棚卸しにある

デザイン思考の基本は、今ある制約をいったん外して、目的から見直すことです。基幹システム刷新でこの考え方を当てはめると、いちばん見えてくるのは、老朽化そのものは実はそこまで高くつかないという事実です。高くつくのは、業務側が「システムでできないから」と作ってきた手作業の迂回路が、いつの間にか正式な業務として定着していることです。

迂回路は最初、誰かの善意の工夫として始まります。エクセルで台帳を作り直し、確認の電話を一本余計にかけ、締め処理の前に手で数字を突き合わせます。どれも小さな負担なので、誰も問題として報告しません。ところが数年経つと、その迂回路自体が「うちのやり方」として引き継がれ、新しい担当者はそれを疑うことなく踏襲します。

刷新を検討する段になって初めて、この迂回路が何本あり、どこまでが業務要件で、どこからが単なる回避策なのかを解きほぐす作業が発生します。ERPは“高機能が正解”じゃないという論点も、根はここにあります。機能を足しても、迂回路が何であるかを把握しないまま導入すれば、新しいシステムの上に同じ迂回路が作り直されるだけです。

だからこそ、替えどきの判断は「システムの寿命」ではなく「迂回路がどれだけ積み上がっているか」で考えるべきだと私は見ています。棚卸しに時間がかかるほど、実は替えどきをすでに過ぎている可能性が高いということでもあります。

よくある質問

Q. 結局、何年使ったら替えどきですか？

A. 年数だけでは判断できません。5つの兆候のうち、特に②仕様の属人化と⑤業務側の断念は、稼働年数に関係なく早い段階から進行します。年数はサポート終了時期を確認する材料として使い、判断の主基準にはしないことをお勧めします。

Q. 兆候が1つだけなら、まだ様子見でいいですか？

A. 兆候の数よりも、それぞれの深刻度を見てください。特に④サポート終了はカレンダーで期限が決まっているため、1つでも該当すれば検討の着手時期は逆算で決まります。他の兆候は、まず事実（見積の推移や属人化の実態）を集めるところから始めれば十分です。

まとめ

レガシーシステムの替えどきは、「古いから」ではなく、5つの兆候（見積の高騰、属人化、データ連携の断念、サポート終了、業務側の変更断念）のどこに当てはまるかで見えてきます。そして本当に高くつくのは老朽化そのものではなく、その裏で積み上がった迂回路です。まずは自社の業務の中に、この5つのどれかが静かに進行していないか、確認してみてください。

基幹システムの刷新時期や投資規模の考え方については、お問い合わせからお気軽にご相談ください。

この記事を書いた人

小林悠真（こばやし・ゆうま）／LF&L株式会社 代表取締役。九州大学で音響設計・音楽マネジメントを学びデザイン思考を培った後、ヤマトシステム開発・バンテックで物流／生産管理、ラクスル等のITスタートアップで事業開発・SCM構築を経験。製造業・物流業のDXコンサルタントとして、現場の1歩から経営システムまでの全体最適を支援する。テューバ奏者・LFコンサート代表理事も兼務。