「システムのブラックボックス化やサポート終了（EOL）を見据え、刷新の必要性は痛感している。しかし、膨大なレガシー資産のどこから手を付け、どのような投資対効果で経営陣を説得すべきかが見出せない」
こうした課題を抱えるDX推進担当者や情報システム部門は少なくありません。基幹システムの刷新は、単なる技術の置き換えではなく、業務の棚卸しと事業継続リスクの極小化を両立させる経営プロジェクトです。
本ガイドでは、刷新の検討フェーズから、客観的な数値に基づく移行判断、さらには社内承認を確実に通過させるための合意形成手順まで、実務に必要な論点を体系的に解説します。
刷新するかどうかを決める｜5つの判断軸
刷新の判断は「単にシステムが古いから」という主観的な理由では経営陣の承認を得られません。稟議を通過させるためには、現行システムを放置・延命し続けた場合に生じる損失やリスクを客観的な数値で立証する必要があります。
実務上、以下の5つの判断軸のうち2つ以上に該当した段階で、具体的な検討プロジェクトを開始することが推奨されます。
| 判断軸 | 具体的な兆候とビジネスリスク |
| ハードウェアEOL | サーバー、OS、ミドルウェアのサポート終了期限が2年以内に迫っている。セキュリティ脆弱性の放置や機器故障時の事業停止リスクに直結し、最も先送りが許されない期限です。 |
| 要員の高齢化 | システムの全容を把握している担当者が社内に1から2名しかおらず、定年退職や離職が間近に迫っている状態です。仕様のブラックボックス化により、障害発生時の復旧が著しく困難になります。 |
| 改修コストの上昇 | 軽微な画面変更や税率改定でも調査や見積もりに数週間を要し、改修費用が対効果に見合わなくなっている状態です。継ぎ足し開発によるスパゲッティコード化が開発効率を阻害しています。 |
| 他システム連携の限界 | クラウドSaaS、API、外部プラットフォームとの自動連携ができず、CSV出力や手作業による転記作業が日常化している状態です。全社的なDX施策やデータ活用のボトルネックとなります。 |
| 法制度対応 | インボイス制度、電子帳簿保存法、業種固有の法改正など、対応期限が厳格に定められた改修が継続的に発生している状態です。旧アーキテクチャでは法改正への追従自体が困難になります。 |
現行資産の調査｜最初の90日
基幹システム刷新プロジェクトにおける総費用の大半は「再構築・移行するコード量や機能数」に比例します。そのため、最初の90日間で取り組むべき最重要タスクは、「新システムに引き継がない資産（デッドコード・休止機能）を特定し、捨てる決断を下すこと」です。
過去10年から20年にわたり改修が繰り返されたレガシーシステム（COBOL、RPG、VB6など）では、全コードの30%から50%がすでに使われていない画面や重複バッチ、不要ロジックであるケースも珍しくありません。
最初の90日で実施すべきアプローチ
- 非侵入型のコード静的解析
本番環境を停止させず、既存資産のソースコードを対象に静的解析を実施します。
- AIを活用した可視化とドキュメント復元
ドキュメントが形骸化している場合、レガシー資産解析AI（BIZ ModAI等）を活用してソースコードから依存関係マップ（Code Dependency Map）を自動生成し、埋もれた業務ロジック仕様を抽出します。
- 利用実績に基づく資産の仕分け
DBのアクセスログや実行ログと照合し、「日常稼働」「四半期・年1回稼働」「完全停止（移行対象外）」に客観的に分類します。
この90日間の現状分析を固定スコープ・定額（Fixed Price）で先行実施し、正確な現行仕様書と移行スコープ確定リストを成果物として確保することが、後続の設計・開発フェーズにおける予期せぬコスト膨張を防ぐ防壁となります。
移行方式の比較｜リホスト／リライト／段階移行／パッケージ
システムの重要度、業務の独自性、残された許容期間に応じて最適な移行方式を選択する必要があります。
| 方式 | 概要 | 向いているケース | 注意点・トレードオフ |
| リホスト（リフト＆シフト） | 業務ロジックや言語を変更せず、稼働基盤のみをクラウド環境等へ移設する方式。 | ハードウェアのEOLが目前に迫り、最短納期でシステム稼働を維持することが最優先のケース。 | システム構造やコードのブラックボックス化は解消されず、技術的負債や高額な保守コストがそのまま残ります。 |
| リライト（モダン言語への書き換え） | 既存の業務ロジックを抽出し、Java、C#、Python等のモダンなオープン言語およびWeb基盤へ再構築する方式。 | 業務手順や独自ロジックに自社の競争優位があり、今後10年以上安定稼働させる明確な前提があるケース。 | 移行初期費用が大きくなります。現行調査の精度が設計・開発の見積もり精度を直接左右するため、事前のコード解析が必須です。 |
| 段階移行（フェーズドマイグレーション） | サブシステム単位や業務ドメイン単位で優先順位をつけ、順次新システムへ切り替えていく方式。 | 24時間365日稼働など、一括切り替えに伴う全面的な業務停止リスクが許容されない大規模基幹システム。 | 移行期間中は新旧システムが併存します。新旧間のデータ二重書き込みやリアルタイム同期の設計・運用負荷が高まります。 |
| パッケージ導入（ERP／SaaS） | 標準パッケージ（SAP、IFS Cloud、Odoo等）を導入し、業務プロセスをパッケージ側の標準に適合させる方式。 | 会計、人事、標準購買など、業界標準のベストプラクティスに自社業務を合わせられる領域。 | アドオン開発が増えるとスクラッチ開発と費用差がなくなります。「Fit to Standard」を徹底できるかが成否を分けます。 |
概算費用の考え方｜なぜ見積もりが3倍違うのか
同じシステム概要資料を提示しても、ベンダー各社から提示される概算見積もりに2倍から3倍の開きが生じる主因は、「仕様確定の解像度」と「見積もりに織り込まれるリスクバッファ」の違いにあります。
・移行対象資産の絞り込み度合い
現行のステップ数をそのまま全量移行（100%移行）前提で見積もるベンダーと、コード解析によりデッドコードをあらかじめ除外（例えば実質60%移行）して見積もるベンダーでは、工数規模が根本から異なります。
・仕様不明箇所のバッファ設定
仕様書が存在しないレガシー資産に対して、リスクをすべて工数バッファとして上乗せするベンダーと、AIツール等による事前解析で仕様復元工数を低減させるベンダーとで大きな価格差が生まれます。
・オフショアおよびハイブリッド体制の活用度
すべての工程を日本国内の人月単価で試算するか、要件定義・設計・品質管理と製造・テストの実装工程を最適に分担するかによって、プロジェクト総コストは大きく変動します。
体制の組み方｜社内・ベンダー・開発拠点の役割分担
基幹システム刷新を成功に導く体制の要諦は、「誰がどこでコードを書くか」ではなく、「誰が仕様解釈と品質基準の最終責任を負うか」にあります。
当社では、日本法人が上流コンサルティング、要件定義、アーキテクチャ設計、プロジェクトマネジメント（PM）、および品質ゲート（受入検証）を一貫して担い、製造・自動テスト・マイグレーション実装はベトナム側の協力会社である開発チームが分担するデュアル体制を採用しています。
- 発注側（社内プロジェクトチーム）
業務要件の優先順位付け、業務オーナー（現場責任者）の合意形成、現行業務プロセスの見直し（捨てる業務の判断）。
- 統括側（日本法人・PM/BA）
業務要件からシステム設計への落とし込み、非機能要件の策定、課題管理、品質ゲートにおける受け入れ判定。
- 実装開発チーム（ベトナム側の協力会社）
CMMI Dev/Services Level 3やISO 27001等の国際標準に準拠したセキュアな開発環境における、コード変換、単体・結合テスト、パフォーマンス検証。
よくある失敗パターン
プロジェクト中断や大幅な予算超過を招く原因の多くは、技術力の不足ではなく、進め方やプロジェクト構造の不備に起因します。
- 現行調査の軽視とスコープ膨張
ドキュメントがない状態で開発に着手し、実装終盤になって未知の仕様が次々と発覚して手戻りが発生する。
- 年1回・四半期バッチの検出し漏れ
日常運用で稼働しない特殊な決算バッチや集計処理を見落とし、本番切り替え後の最初の締め処理で業務停止に陥る。
- 業務オーナー不在の要件定義
情報システム部門主導で進めるあまり、実際の業務責任者の承認を得ずに設計を進め、受け入れテスト段階で大量の仕様変更要求が噴出する。
- 新旧併存期間におけるデータ同期設計の破綻
段階移行において、データ同期のタイムラグや不整合のリカバリー運用手順を定義しておらず、業務現場に多大な負担を強いる。
社内承認で必ず聞かれる項目
社内承認や経営会議の場で議論を紛糾させず、承認を前進させるためには、以下の5点に対して定量的かつ論理的な回答をあらかじめ用意しておく必要があります。
- 放置した場合の損失コスト
現状維持を選択した場合のハードウェア保守料、属人化による障害発生時の事業停止損失額を具体的に提示できているか。
- 移行対象外とする資産の削減率
コード解析等に基づき、どの程度の不要資産（デッドコード）を削ぎ落として開発投資を圧縮したかをパーセンテージで明示できているか。
- 本番切り替えに伴う業務停止許容時間
土日や連休を利用した切り替え計画において、業務停止時間を何時間以内に抑えられるか。
- 移行失敗時の切り戻し（ロールバック）手順
万一本番稼働で致命的な不具合が発生した場合、旧システムへ何時間で復旧可能か、データの巻き戻し手順が確立されているか。
- 稼働後の保守運用体制とコスト削減効果
新システム稼働後、保守要員を何名体制とし、年間ランニングコストを従来比で何%削減できるか。
