情報システムは、ハードウェア、OS、ミドルウェア、アプリケーションなど、いくつもの階層にまたがる複数のコンポーネントを組み合わせて構築されており、各レイヤーのベンダーごと、製品ごとに保証期間が定められています。この期限の終了が、いわゆる「EOS（End of Support：サポート終了）」や「EOL（End of Life：寿命の終了）」です。 情報システムの正常な稼働を続けるためには、EOSやEOLに計画的に対応し、適切なタイミングで各コンポーネントのリプレースを実施するLCM（Life Sycle Management：ライフサイクル管理）を日頃から行ってこくことが重要な要件となっています。 EOSなどに従ったリプレースの場合、計画を立てて入念な準備を持って実行することができますが、システム導入やリプレースへの要求が突然降ってかかるケースもあります。例えば、経済産業省が警鐘を鳴らした「2025年の崖」で指摘するようなデジタルトランスフォーメーションへの対応です。 複雑化・ブラックボックス化した既存の基幹システム（レガシーシステム）を温存したままでは、そのメンテナンスばかりにコストや人的資源が費やされてしまい、新しいデジタルテクノロジーやビジネスモデルの導入に資源を投じることができなくなってしまいます。結果としてグローバル競争で太刀打ちできなくなるという問題です。 この場合、システム全体のモダナイゼーション（近代化）を見据えた、かなり大がかりなリプレースが発生するのが一般的です。またこれは経営戦略にも関わってくるため、危機感を持った経営層からトップダウンで、急いで対策を要求されるケースもあります。 しかし、すぐにリプレースを行おうとしても、うまくプロジェクトが進まないケースもあります。例えば、「複雑化した現行のシステムを把握できていない」「現場やユーザーのニーズに個別最適に対応しすぎたため、必要な要件やビジネス課題も言語化されていない」という状況です。 そのような中で無理に新たなシステムの導入を進めても、「膨大なコストや期間がかかった」「ビジネス上のメリットをもたらさなかった」「業務現場に浸透しなかった」「ユーザーから不満の声が上がった」などの事態をもたらしたり、また最悪の場合、ビジネスを脅かすようなセキュリティの脆弱性をもたらす可能性もあります。

こうしたシステムリプレースにおける混乱はなぜ起きてしまうのでしょうか。その要因は企業文化から、IT戦略、体制までさまざまであり、明確な答えはありませんが、ITシステム構築に対する考え方もその1つであるでしょう。 例えば、2025年までに多くの企業がリプレースを行うと予想されるSAP ERPを例にとって考えてみましょう。 実は、同じSAP ERPを基盤としながらも、欧米企業と日本企業の間には、その使い方に大きな違いがあります。欧米企業の多くは、SAP ERPが提供する基本機能に自分たちの業務をできるだけ合わせようとします。どうしてもカスタマイズやアドオン開発が必要になった場合も、社内のIT人材で対応するのが一般的です。 これに対して日本企業の多くは、逆に自分たちの業務にSAP ERPを合わせるために、カスタマイズやABAP言語を用いたアドオン開発に膨大な投資を行ってきました。しかも、その作業の大半を外部のSIベンダーに依存しているのが実態です。 複雑なカスタマイズやアドオン開発を長年積み重ねた場合、社内にその背景をわかる人間が退職したり、うまく引き継ぎが行われなかったり、ドキュメントも残っていなかった場合、SAP ERPを基盤とする基幹システムの中身はブラックボックス状態となっていきます。またそれを維持する費用もどんどん膨らんでいくという悪循環に陥ってしまうのです。 複雑化し、しかも現状が把握できない状態からシステムリプレースを行うには、重要な要件や機能の抜け漏れが発生してしまう可能性もあります。これによって、システム導入後に予想しないトラブルや問題が起こってしまうことにつながってしまうのです。

全2回　リスクという観点から考えるシステムリプレースへの取り組み方 《第2回》 システムリプレースに必要な考え方と社内との関わり方 《第1回》 システムリプレースのリスクや課題を認識しておく