モダナイゼーションの優先順位と範囲は、アセスメント結果をもとに「範囲」「優先順位」「順序」の3つを分けて決めることで、迷わず着手できるようになります。
📌 この記事の要点
アセスメントで分かるのは現状までです。計画に変えるには「どこまでやるか（範囲）」「どれを先にやるか（優先順位）」「どの順番で進めるか（順序）」の3つに答える必要があります。本記事では、範囲を3区分で線引きする方法、6つの評価軸による重み付けスコアリング、最初に移行するシステム（パイロット）の選び方、Wave計画への落とし込みを解説します。後半では20システムのモデルケース、よくある5つの失敗、稟議資料に入れるべき項目も紹介します。
モダナイゼーションの優先順位と範囲は、3つの別々のステップで決まります。 まずアセスメント結果をもとに範囲の境界線を引き、次にビジネス価値・技術リスク・外部期限でスコアをつけ、最後に依存関係に沿って実行順序を決めて6〜12か月単位のWaveにまとめます。
最初に着手すべきなのは、最も重要なシステムとは限りません。 重要度は中程度で、依存が少なく、効果が見えやすく、問題があれば元に戻せるシステムが適しています。最初のWaveで得た実績と社内の信頼が、その後の基幹系刷新を支える土台になります。
本記事は「レガシーシステムアセスメントの評価7領域と進め方」の続編として、「評価が終わったら、何から始めるか」に焦点を当てます。
モダナイゼーションの優先順位と範囲は「3つの別々の意思決定」
多くのプロジェクトでは、「何をやるか」と「どの順番でやるか」を一度の会議でまとめて決めてしまいます。その結果、計画はロジックではなく、その時いちばん声の大きいシステムに引きずられがちです。3つの意思決定を切り分けることが、ぶれないロードマップへの第一歩です。
「範囲」「優先順位」「順序」の違い
3つは似た言葉ですが、答える問いも、必要なインプットも異なります。
| 範囲 | 優先順位 | 順序 | |
|---|---|---|---|
| 答える問い | 何をモダナイズし、何を残すか | どれを先にやる価値があるか | 実際にどの順番で進めるか |
| 主なインプット | 棚卸し結果、事業戦略 | ビジネス価値、技術リスク、期限 | 依存関係マップ、体制、業務カレンダー |
| アウトプット | 対象／対象外／影響を受ける領域の一覧 | 優先順位スコアシート | Wave計画・ロードマップ |
優先順位が高いからといって、先に着手できるとは限りません。 たとえば販売管理システムのスコアが最も高くても、顧客DBを他の5システムと共有しているなら、先に顧客データを切り出す必要があります。だからこそ、優先順位と順序は別々に決めるべきなのです。
一括刷新（ビッグバン）が失敗しやすい理由
この違いを踏まえると、「すべてを一度に入れ替える」計画がなぜ失敗しやすいかが見えてきます。ビッグバン型は3つの問いを同時に解かなければならず、たった1回の切り替え日にすべてを賭けることになります。
- リスクが1点に集中する：本番切り替え時のデータ不整合ひとつで、業務全体が止まりかねません。
- コストと期間が膨らむ：複数年のプロジェクトでは、完了前に事業要件が変わってしまいます。
- ノウハウが失われる：現行システムを知る担当者が、途中で退職・異動するリスクがあります。
経済産業省「DXレポート」も、システムの複雑化・ブラックボックス化がDXの大きな障壁になると指摘しています。レガシーシステムを刷新すべき時期を見極めたら、段階的に進めることがほぼ前提と考えてよいでしょう。
アセスメント結果がそのまま計画にならない理由
アセスメント報告書が示すのは、各システムの状態です。どこから始めるべきかまでは教えてくれません。「ビジネス価値×技術的健全性」のマトリクスは、システムを維持・強化・刷新・廃棄の4つに分類するだけです。「刷新」に10システムが入っていれば、「どれから？」という問いはそのまま残ります。以降の章で、この問いに答えていきます。
モダナイゼーションの範囲を決める前に揃えるべき情報
地図が描けていない状態で、境界線は引けません。範囲を決める会議の前に、次の3つの情報を揃えておきましょう。これらはまさにアセスメント工程のアウトプットです。
システム・業務・データの棚卸し結果
棚卸しは、システムの一覧表をつくることではありません。各システムがどの業務を支え、誰が使い、どれくらいの頻度で変更が入り、マスタデータがどこにあるのかを把握します。業務の視点が抜けると、スコアリングでビジネス価値を見誤ります。
依存関係マップ（システム間連携・バッチ・共有DB）
一覧表と並んで、実行順序を左右するのが依存関係です。次の3点を明確にします。
- システム間のオンライン連携（API、直接呼び出し、中間ファイル）
- 夜間バッチのジョブチェーンと実行順
- 複数システムが読み書きしているDB・テーブル
特に詰まりやすいのが共有DBです。 1システムだけを入れ替えるつもりが、実際には十数システムを巻き込む原因になります。
ドキュメントが無い場合 — リバースエンジニアリングで補う
20〜30年稼働しているシステムでは、設計書が古くなっていたり、失われていたりすることが珍しくありません。その場合は、ソースコードから構造・依存関係・業務ルールを逆に読み解く必要があります。具体的な方法は、ピラー記事の「ドキュメントが無いシステムをどう調べるか」で解説しています。AIが大きな効果を発揮する領域でもあります（後述）。
モダナイゼーションの範囲の決め方 — 境界線を引く4つの切り口
地図が揃ったら、次は境界線を決めます。モダナイゼーションの範囲は、必ずしも「システムA・B・C」という単位である必要はありません。目的に応じて、切り口を選びます。
範囲を切る4つの切り口
| 切り口 | 例 | 向いているケース |
|---|---|---|
| ① システム単位 | 在庫管理システムを刷新 | 比較的独立したシステム |
| ② 業務ドメイン単位 | 受注〜出荷の業務全体 | 複数システムにまたがる業務改革をしたい |
| ③ レイヤー単位 | インフラだけクラウドへ、データ層だけ統合 | 主な課題がインフラのEOLやデータの分散 |
| ④ 機能単位 | 価格計算モジュールだけを切り出す | 大規模なモノリスを少しずつ置き換えたい |
③は手法の選択と直結します。インフラだけを移すならマイグレーション、アプリケーションの構造まで変えるならモダナイゼーションです（詳しくは「モダナイゼーションとマイグレーションの違い」）。実際のプロジェクトでは、2つの切り口を組み合わせることが一般的です。 たとえば「受注ドメイン」×「アプリ層＋データ層」といった形です。
「対象」「対象外」「触らないが影響を受ける領域」の3区分
切り口が決まったら、構成要素を一つずつ分類します。多くの計画書は「やる／やらない」の2列しかありません。しかし、想定外のコストが生まれるのは、たいてい3つ目の領域です。
- 対象：刷新・書き換え・移行する構成要素。
- 対象外：現状のまま残すもの。理由と見直し時期を明記します。
- 触らないが影響を受ける領域：刷新はしないが、範囲に隣接しているため、インターフェース修正・再テスト・バッチ調整が必要になるもの。
たとえば受注管理システムを刷新する場合、会計システムは対象外です。しかし会計へ渡すファイル形式が変われば、会計側でも回帰テストが必要になります。3つ目の領域を最初に明示しておくと、テスト工数と関係部門との調整コストを正確に見積もれます。
「現行踏襲」をどこまで許すか — スコープ肥大化を防ぐ線引き
日本のプロジェクトで特に多いのが、「現行踏襲」という要件による範囲の肥大化です。一見安全に見えますが、範囲は2つの方向に膨らみます。
- 誰も使っていない機能まで再現してしまう：「不要」と言い切れる人がいないためです。
- 「ついでに改善」が積み重なる：作り直すなら、と新しい要望が途中で追加されていきます。
効果的なのは、範囲定義書の中にルールを明記することです。
- 実際の利用状況を測る：ログやアクセス頻度を確認してから、機能を残すかを判断します。
- 業務改善は後のWaveに切り分ける：今回のWaveは機能同等性の確保に絞ります。
- 範囲変更の承認プロセスを決める：誰が承認し、コストとスケジュールへの影響をどう扱うかを定めます。
範囲を広げすぎ／狭めすぎのサイン
線を引いたら、次のサインでセルフチェックしましょう。
広げすぎのサイン
- 1つのWaveが12か月を超える
- 範囲の全体像を5分で説明できる人がいない
- 半数以上のシステムが「影響を受ける領域」に入っている
狭めすぎのサイン
- 完了しても、根本課題（EOL、属人化）が残る
- 刷新部分より複雑な「つなぎ」の仕組みが必要になる
- 経営層に報告できるほどの効果が出ない
モダナイゼーションの優先順位のつけ方 — スコアリングの方法
範囲が決まったら、その中でどれを先にやる価値があるかを決めます。ピラー記事の2×2マトリクスが「各システムに何をするか」を示すのに対し、ここで紹介するスコアシートは「どれを先にやるか」を示します。
出発点：ビジネス価値×技術的健全性の4象限
まず、すべてのシステムを維持・強化・刷新・廃棄の4象限に配置します。読み方の詳細は「ビジネス価値×技術的健全性マトリクス」をご覧ください。
なお、このマトリクスはモダナイズするシステムの優先順位づけです。EOLや脆弱性、属人化といった個別の問題に優先順位をつけたい場合は、「レガシーシステムの問題点と優先順位の決め方」が参考になります。
スコアリングに進むのは、「刷新」と「強化」に入ったシステムだけです。「廃棄」に入ったシステムは、早めに処理しましょう。廃棄はコスト削減につながり、依存関係マップもシンプルになります。
6つの評価軸で重み付けスコアを作る
4象限から一歩進んで、詳細なスコアをつけます。各評価軸を1〜5点で採点し、自社の戦略に合わせた重みを掛け合わせます。
| 評価軸 | 評価の問い | 重み（例） |
|---|---|---|
| ① 業務影響度 | 改善すると、売上や業務効率はどれだけ変わるか | 25% |
| ② 技術リスク | EOL、脆弱性、保守できる人材の不足はあるか | 25% |
| ③ 依存関係（依存が少ないほど高得点） | 接続しているシステムはいくつか、DBを共有していないか | 15% |
| ④ 変更頻度 | 業務側から頻繁に改修要望が来るか | 15% |
| ⑤ データ移行の容易さ（容易なほど高得点） | データの量・品質・複雑さはどうか | 10% |
| ⑥ 体制・ナレッジ | 業務を理解する人、テスト結果を承認できる人がいるか | 10% |
これらの評価軸は、AWS規範ガイダンス「アプリケーションの優先順位付けプロセスを定義する」が示す、ビジネスと技術の両面から評価する考え方とも一致します。重要なのは、採点の前に重みを合意しておくことです。 結果が出てから「うちの部門のシステムのほうが重要だ」という議論になるのを防げます。
優先順位スコアシート（サンプル）
架空の5システムで採点した例です（各1〜5点、合計＝Σ得点×重み）。
| システム | ① 業務影響（25%） | ② 技術リスク（25%） | ③ 依存の少なさ（15%） | ④ 変更頻度（15%） | ⑤ データ容易性（10%） | ⑥ 体制（10%） | 合計 |
|---|---|---|---|---|---|---|---|
| A. 受注管理（COBOL） | 5 | 5 | 2 | 4 | 2 | 3 | 3.90 |
| B. 在庫管理（VB6） | 4 | 4 | 4 | 3 | 4 | 4 | 3.85 |
| C. 社内ポータル（Java Struts） | 2 | 4 | 5 | 3 | 5 | 4 | 3.60 |
| D. 会計（SAP ECC） | 4 | 4 | 2 | 2 | 2 | 2 | 3.00 |
| E. 社内帳票（Access） | 2 | 3 | 4 | 2 | 4 | 3 | 2.85 |
最高得点はシステムAです。ただし次の章で見るように、最高得点のシステムが最初に着手するシステムとは限りません。
外部期限から逆算する — SAP 2027年問題・OS/DBのEOL・保守契約更改
スコアとは別に、動かせない期限があります。これらはスコアの結果よりも優先される「制約条件」として扱います。
- SAP 2027年問題：SAP ERP 6.0（ECC）の標準保守は2027年末に終了します。
- OS・DB・ミドルウェアのEOL：たとえばWindows Server 2016の延長サポートは2027年1月に終了します。
- 保守契約・ハードウェアリースの更改時期：逃すと、さらに3〜5年の更新が必要になる場合があります。
- 法制度の変更：特定の日付までに対応が求められるケースです。
進め方としては、まず期限を時間軸に並べ、必要な期間を逆算します（アセスメント＋設計＋移行＋並行稼働テスト）。Wave 1以降に始めると間に合わないシステムは、スコアにかかわらず前倒しします。
🟡 自社システムの範囲と優先順位を、まずデータで把握する
スコアシートの精度は、インプットの精度で決まります。HBLABのAI診断は、ソースコード（Java／C#／VB.NET／COBOL）を解析し、モジュールごとの移行準備度・難易度・想定工数・移行ロードマップをまとめた12〜18ページのレポートを、24時間以内にお届けします。
モダナイゼーションの順序を決める — 依存関係とWave設計
スコアが出たら、それを実行順序に変換します。この段階で最終的な決定権を持つのは、スコアではなく依存関係です。
優先順位≠実行順序 — 依存関係が順番を決める
先ほどの例に戻ると、システムA（受注管理、COBOL）は最高得点ですが、依存関係が多く、データ移行も難しいシステムです。Aから着手すると、チームは最も難しいシステムに取り組みながら、モダナイゼーションの進め方そのものも学ぶことになります。リスクが二重に重なる状態です。
技術的な順序の原則は、次のとおりです。
- インフラ・基盤（クラウド環境、CI/CD、テスト環境）
- データ（共有DBの分離、マスタのクレンジング）
- アプリケーション
- 連携・運用の最適化
データを切り出す前にアプリケーションを書き換えると、二度手間になりやすくなります。
最初の1本（パイロット）の選び方：5つの条件
順序は依存関係で決まると分かったところで、次の問いは「最初の1本をどれにするか」です。パイロットに必要なのは、最重要であることではなく、成功でき、学びを得られる条件がそろっていることです。
- 重要度が中程度：経営層が関心を持つ程度には重要で、トラブル時に基幹業務を止めない。
- 依存が少ない：インターフェースが少なく、基幹系とDBを共有していない。
- 効果が見えやすい：保守コスト削減や処理時間短縮など、数字で示せる。
- 体制がある：業務を理解する人と、テスト結果を承認できる人がいる。
- ロールバックできる：問題があれば旧システムに戻す手段がある。
先ほどのスコアシートでは、システムB（在庫管理、VB6）が5つの条件をすべて満たします。得点は2位ですが、依存が少なく、データ移行も容易です。パイロットとしては、AよりもBが適しています。
Wave 0：基盤・テスト資産・ゴールデンデータを先に整える
パイロットよりもさらに前に、準備のためのWave 0を設けることをおすすめします。ロードマップの解説ではあまり触れられませんが、以降のすべてのWaveのスピードを左右する工程です。
- 移行先の環境：クラウドや新基盤、CI/CDパイプライン。
- テスト資産：回帰テストケースと、新旧の結果を比較するためのゴールデンデータ。詳しくは「ゴールデンデータを使ったマイグレーションテストの進め方」をご覧ください。
- 共通ルール：コーディング規約、レビュー手順、受け入れ基準。
Wave 0の期間は通常1〜3か月で、アセスメントの仕上げと並行して進められます。
Wave 1〜Nの組み方（6〜12か月単位）と見直しのタイミング
Wave 0とパイロットを起点に、以降のWaveは次の原則で組み立てます。
- 1つのWaveは6〜12か月とし、終了時に測定できる成果を設定する。
- 依存関係の強いシステムは同じWaveにまとめる。一時的な「つなぎ」を作らずに済みます。
- 基幹系（Aなど）はWave 2〜3に置く。前のWaveで得た経験とツールを活かせます。
- Waveごとにスコアシートを見直す。事業戦略も、実際の難易度も変わるためです。
ストラングラーパターンで「止めずに」切り替える
止められない大規模システムには、ストラングラーフィグパターンが有効です。新システムを前段に置き、機能ごとに少しずつトラフィックを移し、最終的に旧システムが呼ばれなくなった時点で廃止します。範囲の切り口のうち、④「機能単位」と特に相性のよい方法です。
モデルケース：基幹系を含む20システムの範囲と順序を決める
※以下は手法を説明するための架空のモデルケースであり、特定のお客様の事例ではありません。
ここまでの枠組みを通しで見るために、20のシステムを持つ製造業を想定します。会計のSAP ECC、COBOLの受注管理、VB6の在庫管理、そして複数の社内Webアプリケーションがある企業です。
ステップ1｜4象限で分類：廃棄3（機能重複・利用者僅少）、維持5、強化4、刷新8。
ステップ2｜範囲を線引き：強化と刷新の12システムを対象に。受注管理または会計と連携している6システムを「影響を受ける領域」に。
ステップ3｜スコアと制約：受注管理が最高得点。SAP ECCは2027年末の期限があるため、スコアは中程度でも早期着手が必要。
ステップ4｜Waveを編成
| Wave | 期間 | 内容 |
|---|---|---|
| Wave 0 | 3か月 | クラウド環境・CI/CD・ゴールデンデータの整備、重複3システムの廃棄 |
| Wave 1 | 6か月 | パイロット：在庫管理（VB6→C#）＋社内Web 2本 |
| Wave 2 | 9〜12か月 | 共有顧客DBの分離、SAP移行を並行して開始 |
| Wave 3 | 12か月 | 受注管理（COBOL→Java）をストラングラーパターンで段階移行 |
ポイントは、Waveごとにリスクを段階的に引き上げ、チームの実力も一緒に高めていくことです。最も難しいシステムに取り組むのは、組織の準備が最も整ったタイミングです。
モダナイゼーションの優先順位と範囲でよくある5つの失敗
枠組みがあっても、プロジェクトは次のような点でつまずきがちです。
- 「ついでに全部」と範囲を最大化する：計画が実質的なビッグバンになります。
- 最重要システムから着手する：経験のないチームが最大のリスクに向き合うことになります。
- 簡単なものだけ先に片付け、本丸が残る：後のWaveほど難しくなり、予算も尽きていきます。
- 依存関係を無視してWaveを切る：一時的な「つなぎ」を大量に作り、維持し続けることになります。
- 着手後に範囲が膨らむ：現行踏襲と追加要望をコントロールできていない状態です。
失敗2と3は正反対に見えますが、根本原因は同じです。優先順位と順序を切り分けていないことです。パイロットの5条件と、基幹系をWave 2〜3に置く原則が、どちらの失敗も防ぎます。
決めた優先順位を社内で通す — 稟議資料に入れるべき項目
どれほど良い計画でも、承認されなければ実行できません。情シス担当者が稟議資料・社内説得資料をまとめる際は、次の項目を盛り込みましょう。
| 項目 | 記載内容 |
|---|---|
| 範囲 | 対象／対象外／影響を受ける領域の一覧と、その理由 |
| 優先順位の根拠 | スコアシート、合意済みの重み、期限による制約 |
| Wave計画 | 各Waveの目標と完了基準 |
| 段階的な投資 | 詳細な承認はWave 0〜1のみ、以降のWaveは概算で提示 |
| やらない場合のリスク | 保守コスト、EOLリスク、人材流出リスク |
Waveごとに予算を承認する形にすると、一括の大型投資よりも経営層が判断しやすくなります。稟議と合意形成の進め方は、ピラー記事で詳しく解説しています。
AIで範囲と依存関係の可視化を加速する
ここまでの工程で最も手間がかかるのは、依存関係マップの作成と難易度の見積もりです。ドキュメントが無い場合はなおさらです。この部分こそ、AIで大きく時間を短縮できます。
AIによるコード解析・依存関係抽出でできること／限界
AIはソースコードを解析し、モジュール構成、呼び出し関係、DBアクセス、業務ルールを抽出できます。手作業なら数週間かかる作業です。一方で、ビジネス価値の判断はAIには代われません。 重みの設定、期限による制約、最終的な意思決定は人が担います。詳しくは「マイグレーションのAI活用｜工程別にできること・限界」をご覧ください。
HBLABのAI Assessment Tool
HBLABのAI Assessment Toolは、ZIP形式のソースコード（Java、C#、VB.NET、COBOL）を受け取り、24時間以内にレポートをお届けします。
- モジュールごとの移行準備度スコアと難易度
- 想定工数と自動変換率の見込み
- 移行ロードマップの提案
これらは、スコアシートの③依存関係・⑤データ移行の容易さ、そしてパイロット選定のインプットになります。さらに評価だけで終わらず、技術調査・評価・戦略策定・業務仕様の整理・コード変換・単体テスト・結合テストまでの7ステップを支援します。
HBLABのモダナイゼーション支援
HBLABは、範囲と優先順位の整理から、移行・テストまでを一貫して支援します。ベトナムのオフショア開発体制と、AIを活用した移行プロセスを組み合わせているのが特長です。
- モダナイゼーションパッケージ：VB6/VBA→C#/Python、Java Struts→Spring Boot、COBOL/RPG→Java/Python、Lotus Notes→intra-mart/SharePoint、ネイティブアプリ→Flutter。
- 実績：Java Struts→Spring Boot 約20万行を9か月で移行。VB→ASP.NET 約60万行をAI活用で1年かけて移行。
- AI活用の効果：工数30〜50%削減、期間約40%短縮。
- 強み：提案力、PoCのスピード、ご期待に応えるレスポンスの速さ。
- 対応業界：銀行、保険、証券、官公庁、製造、物流。
🟡 範囲と優先順位の整理から、一緒に始めませんか
どのシステムから着手すべきか迷ったら、HBLABがソースコードを解析し、最適な範囲と順序をご提案します。
👉 AI診断を無料で試す ｜ 無料相談を予約する
よくあるご質問
Q1. モダナイゼーションの優先順位と範囲を決めるのに、どれくらいの期間がかかりますか？
A. アセスメント結果がそろっていれば、範囲の線引き、重みの合意、Wave計画の作成まで通常1〜2か月程度です。アセスメントが未実施の場合は調査期間が加わりますが、AIツールを使えばソースコード解析の部分を短縮できます。
Q2. アセスメントをせずに優先順位を決めてもよいですか？
A. 暫定的なリストはつくれますが、予算承認に使うことはおすすめしません。依存関係マップや難易度のデータがないと、途中で実行順序が崩れやすくなります。
Q3. 最初のWaveに基幹システムを入れるべきですか？
A. 通常はおすすめしません。最初のWaveは、重要度が中程度で依存の少ないパイロットが適しています。例外は、基幹系に動かせないEOL期限がある場合です。その場合は早期に並行して着手し、ストラングラーパターンでリスクを抑えます。
Q4. SAP 2027年問題を抱えている場合、何を優先すべきですか？
A. 2027年末から逆算し、遅くともいつ着手すべきかを確定させましょう。あわせて、SAPと連携している周辺システムを洗い出してください。これらは「影響を受ける領域」に入り、大きなコストが発生しやすい部分です。
Q5. 優先順位は途中で変えてもよいですか？
A. 変えてかまいませんし、むしろ見直すべきです。各Waveの終了時にスコアシートを更新しましょう。ただし、範囲の肥大化を防ぐため、変更はあらかじめ決めた承認プロセスを通して行います。
まとめ
アセスメント結果を実行計画に変えるには、3つの意思決定に分けることが大切です。範囲は3区分で線引きし、優先順位は6つの評価軸と期限の制約でスコア化し、順序は依存関係に沿ってWaveにまとめます。 Wave 0と適切なパイロットから始め、基幹系に向けてリスクを段階的に引き上げていきましょう。最初に正しく決めたモダナイゼーションの優先順位と範囲こそが、プロジェクトを完遂へ導く土台になります。
