ベンダーにリプレースを提案されたとき、自分で判断するための確認リスト

「そろそろシステムを作り直した方がいいですよ」と言われたとき、どう判断すれば良いのでしょうか。費用の見積もりは出てきた。でも、本当にそれが必要なのか、今がそのタイミングなのか、なかなか判断がつかない。そういったご相談をいただくことがあります。

この記事では、リプレース提案を受けたときに自分で検討を深めるための確認リストをまとめます。「作り直す」という判断に踏み込む前に確認しておきたいことを整理することが目的です。リプレースを否定するのではなく、判断の根拠を自分で持つための手順です。

なぜリプレース提案が出やすいのか

ベンダーの立場からすると、古いシステムの保守を引き受けるより、新しく作り直す方が工数を見積もりやすく、受注規模も大きくなります。これはビジネス上の合理性であり、悪意ではありませんが、事業者様にとって最善の選択かどうかとは別の話です。

提案の背景を理解したうえで、自分なりの判断軸を持っておくことが重要です。

なお、リプレースと再生（現行システムを保守できる状態へ戻すこと）の考え方の違いについては、レガシーシステム再生とは？リプレースの前に現行システムを活かす選択肢で詳しく説明しています。

確認リスト1：現行システムの状態を把握できているか

リプレースを判断するには、まず現行システムの状態を知ることが出発点です。以下の点が把握できているか確認してください。

システムの全体像

どんな処理をしているか（機能の一覧）が分かるか
データがどこから入って、どこへ出ていくか整理されているか
他のシステムやサービスと接続している箇所があるか

問題の所在

現在、具体的にどんな不具合・不満が起きているか
それは「古さ」が原因か、それとも設定ミス・運用の問題か
障害が起きやすい箇所はどこか

技術的な制約

OS・ミドルウェアのサポートが切れているか、あるいは近く切れる予定があるか
セキュリティ上の問題として具体的に指摘されていることがあるか

現行システムの状態が把握できていない段階でリプレースを決定すると、新しいシステムに同じ問題が引き継がれるリスクがあります。まず現行を把握することが、判断の前提です。

確認リスト2：提案の根拠を確認する

ベンダーから提示された提案の根拠を確認します。「なんとなく古いから」という理由だけで進める提案は、リスクがあります。

根拠として確認したいこと

「古い」とはどういう意味か。具体的にどの技術・バージョンが問題なのか
セキュリティリスクを理由にしているなら、どの脆弱性が問題なのか
保守コストが高いと言っているなら、どの作業にどれだけのコストがかかっているか
現行システムのどこを調査した結果、リプレースが必要と判断したのか

提案書に「システムが古い」「技術的負債がある」と書いてあっても、具体的な根拠が示されていない場合は、追加の説明を求めることをお勧めします。根拠を説明できないベンダーは、現行システムを十分に調査していない可能性があります。

確認リスト3：費用・期間・移行リスクの実態を確認する

リプレースの見積もりを見るとき、開発費用だけに目が行きがちです。しかし、実際のコストはそれだけではありません。

見積もりに含まれているか確認すること

データ移行の費用と作業工数
並行稼働期間（新旧システムを同時に動かす期間）のコスト
現場スタッフへの教育・習熟期間のコスト
新システムへの業務ルールの再現・検証にかかる工数
移行後のバグ対応・調整期間

また、期間についても確認が必要です。

開発完了から本番稼働まで、どれだけの期間が必要か
その間、現行システムのサポートは継続されるか
遅延した場合の対応はどうなるか

現場スタッフにとって、慣れた操作画面が変わることは生産性への直接的な影響があります。慣れるまでの時間や操作ミスのリスクといった現場コストは、開発費用の見積もりには含まれないことがほとんどです。

確認リスト4：リプレース以外の選択肢が提示されているか

リプレースが唯一の選択肢として提示されている場合、他の選択肢も検討したかどうか確認してください。

現行システムを部分的に改修する選択肢は検討されたか
問題のある箇所だけを修正・整理する選択肢は提示されたか
現行システムの仕様を整理し、保守できる状態へ戻す選択肢は検討されたか
クラウド移行や環境更新だけで対応できる可能性はあるか

提案の選択肢が「リプレースか、現状維持か」の二択しか示されていない場合、その間にある段階的な改善、保守性の回復、部分的な改修といった選択肢が検討されていないことがあります。こうした選択肢の具体的な考え方については、レガシーシステム再生とは？リプレースの前に現行システムを活かす選択肢で詳しく説明しています。

判断の目安：リプレースが妥当なケースとそうでないケース

以下はあくまで目安です。個別の状況によって判断は異なります。

リプレースを検討すべき状況

OSやミドルウェアのサポートが既に終了しており、セキュリティパッチが当たらない状態が続いている
業務の仕組み自体が大きく変わり、現行の設計が根本から合わなくなっている
現行コードの品質が著しく低く、改修するたびに別の箇所が壊れる状態が続いている
動作環境の移行が技術的に困難で、新規構築の方が現実的と判断できる根拠がある

まず現行システムの整理を検討すべき状況

「古い」「担当者が退職した」「ベンダーが変わった」という理由だけでリプレースを勧められている
現行システムの仕様や構造をベンダーが十分に調査していない
費用・期間・リスクの面でリプレースの実行が難しい
現行システムは動いているが、誰も全体を把握できていない状態

まとめ

リプレース提案を受けたとき、すぐに「やる・やらない」を決める必要はありません。まず現行システムの状態を把握し、提案の根拠を確認し、リプレース以外の選択肢も検討します。この順序で考えることで、判断の精度が上がります。

今回の確認リストは、個別の判断手順をまとめたものです。リプレースせずに保守しながら使い続けるという選択肢については、レガシーシステム保守とは？古いシステムを安全に使い続けるための考え方で整理しています。

「本当にリプレースが必要なのか、それとも現行を整理すれば使い続けられるのか」という段階からでもご相談ください。現行システムのコード・構成・業務ルールを調査し、取れる選択肢を整理します。レガシーシステム保守のページ、またはお気軽にお問い合わせください。