アセスメントレポートが移行前に答えるべき１０の問いと見極め方

アセスメントレポートは、移行前に「このシステムを、どの方式で、いくら・どの順番で移すか」を決めるための判断材料です。単なる調査結果の一覧ではありません。

レガシーシステムのアセスメント全体の流れ（評価7領域・進め方・費用）は、レガシーシステムアセスメントの評価7領域と報告書の中身で解説しています。本記事はその中でも、「アウトプット＝レポート」をどう読み、どう使うかに絞ります。関連テーマはモダナイゼーション記事一覧からもご覧いただけます。

アセスメントレポートとは？「調査結果の一覧」との違い

アセスメントレポート（アセスメント報告書）とは、現行システムを調査・評価した結果をまとめ、移行の意思決定に必要な答えを示す報告書です。まず、よく混同される「調査結果の一覧」との違いから整理します。

レポートは「判断材料」— 移行の可否・方式・費用・順番を決める文書

現行システム調査では、ソースコード、DB、バッチ、外部連携などを洗い出します。しかし、洗い出しそのものはゴールではありません。

経営層や情シス部門が本当に知りたいのは、次の4点です。

• このシステムは移行できるのか（可否）
• どの方式で移すのか（方式）
• いくら・どれくらいかかるのか（費用・期間）
• どこから着手すべきか（順番）

この4点に答えていない文書は、アセスメントレポートではなく「資産台帳」にとどまります。

では、資産台帳と判断材料の差は、具体的にどこに表れるのでしょうか。

調査で終わるレポートと、判断につながるレポート

両者の違いは、「事実」と「解釈」と「推奨」が分けて書かれているかにあります。

この違いを踏まえて、次章ではレポートが答えるべき具体的な問いを見ていきます。

移行前にアセスメントレポートが答えるべき１０の問い

ここからが本記事の中心です。10の問いはそれぞれ、①レポートに何が書かれているべきか、②確認すべき根拠、③危ないサイン（🚩）の3点で整理しています。

最初の3つは、システムの「中身」を正しく把握できているかを問うものです。

問い1：移行対象の本当の規模はどれくらいか

「100万ステップのシステム」と言われていても、実際に動いている資産はその一部であることが少なくありません。レポートには、総資産・実稼働資産・未使用資産（デッドコード）の内訳が必要です。

• 書かれているべきこと：言語別LOC、プログラム数、画面・帳票・バッチ数、デッドコード率
• 確認すべき根拠：静的解析の結果と、稼働ログ・ジョブ実行履歴との突き合わせ
• 🚩危ないサイン：「総LOC」だけで、未使用資産の判定がない

デッドコードを除外できれば、移行範囲そのものが小さくなります。規模が分かったら、次はそれらが「どうつながっているか」です。

問い2：何が、どこと、どうつながっているか

移行で最も多いトラブルの一つが、見えていなかった連携の切断です。1つのモジュールを移したことで、別システムの夜間バッチが止まる、といった事態が起こります。

• 書かれているべきこと：モジュール間の依存関係図、外部IF一覧（API・ファイル連携・DB直接参照）、ジョブネット
• 確認すべき根拠：コード解析による呼び出し関係＋ジョブ定義＋運用担当者へのヒアリング
• 🚩危ないサイン：「外部連携：12本」と数だけ書かれ、方向・頻度・データ形式が不明

依存関係の次に問うべきは、システムの中に埋まっている「業務の知識」です。

問い3：業務ロジックはどこに、どれだけ埋まっているか

仕様書が古い、担当者が退職した——いわゆるブラックボックス化したシステムでは、業務ルールの正本はソースコードの中にしかありません。

• 書かれているべきこと：抽出した業務ルールの件数と一覧、ルールごとのコード上の所在
• 確認すべき根拠：抽出ルールを業務部門が確認した記録（レビュー済みかどうか）
• 🚩危ないサイン：「業務ロジックは複雑」とだけ書かれ、件数も所在もない

経済産業省の「レガシーシステムモダン化委員会総括レポート」でも、ユーザー企業にはシステムの可視化を進めることが求められています。レポートは、その可視化の出発点です。

業務ロジックを把握できたら、次はその処理対象である「データ」です。

問い4：データは移行に耐えられる品質か

データ品質の問題は、移行の後半で見つかるほど高くつきます。文字コード、外字、NULLの扱い、コード値の揺れ、参照整合性の崩れなどが典型です。

• 書かれているべきこと：テーブル数・データ量、品質課題の種類と件数、クレンジングの要否
• 確認すべき根拠：サンプルデータのプロファイリング結果
• 🚩危ないサイン：データ量だけで、品質についての記述がない

ここまでの4つで「中身」が見えました。続く3つの問いは、それを「どう移すか」の判断につなげるものです。

問い5：どこが難しいのか、なぜ難しいのか

難易度は「高・中・低」のラベルだけでは使えません。モジュールごとに、難しい理由が書かれているかが重要です。

• 書かれているべきこと：モジュール別の難易度と主要課題（例：独自フレームワーク依存、EOLライブラリ、複雑な帳票）
• 確認すべき根拠：難易度の採点基準が明示されていること
• 🚩危ないサイン：全体の難易度が「中」の一言で終わっている

理由が分かれば、モジュールごとに適した移し方も決められます。

問い6：どの移行方式が妥当か

移行方式は、システム全体で1つに決める必要はありません。むしろ、モジュール単位で方式を変えるのが現実的です。

代表的な考え方に、AWSが整理した「6R」があります（リホスト、リプラットフォーム、リファクタリング、再購入、廃止、保持）。AWSの規範ガイダンス（6R移行戦略）でも、アプリケーションごとに戦略を選び、繰り返し見直す進め方が示されています。

• 書かれているべきこと：モジュールごとの推奨方式と、その理由
• 確認すべき根拠：方式ごとのメリット・デメリット比較、却下した選択肢とその理由
• 🚩危ないサイン：最初から特定の方式（例：全面リライト）ありきで書かれている

方式の違いについては、モダナイゼーションとマイグレーションの違いと選び方も参考になります。方式が決まれば、ようやくコストの話ができます。

問い7：工数・費用・期間はどれくらいか（前提と幅つきで）

経営層が最も注目するのがこの項目です。だからこそ、一つの数字だけが独り歩きしないよう、前提条件と幅が書かれている必要があります。

• 書かれているべきこと：工程別（変換・テスト・データ移行など）の概算工数、費用レンジ、期間
• 確認すべき根拠：見積もりの前提（対象範囲、自動変換率、テスト範囲）と、含まれないもの
• 🚩危ないサイン：「総額◯◯円」だけで、前提も精度（±何%か）も書かれていない

なお、マイグレーションではテスト工数が大きな割合を占めます。テスト範囲の前提が曖昧な見積もりは、後から大きくぶれます。費用の次は、その数字を狂わせる「リスク」です。

問い8：どんなリスクがあり、どう潰すか

リスクは「列挙」ではなく、影響度・発生可能性・対策のセットで書かれているべきです。

• 書かれているべきこと：リスク一覧（技術・データ・体制・スケジュール）、影響度、対策、オーナー
• 確認すべき根拠：EOL（サポート終了）の時期、セキュリティ課題、特定担当者への依存度
• 🚩危ないサイン：「リスク：仕様不明箇所あり」のように、対策のないリスクが並んでいる

先送りした場合のコスト・リスクの考え方は、レガシーシステムのリスクと先延ばしのコストで詳しく解説しています。最後の2つの問いは、「実行」に向けたものです。

問い9：どの順番で進めるか、最初の一手は何か

一括移行は、規模が大きいほどリスクも大きくなります。レポートには、段階的に進めるためのロードマップと、最初に着手する範囲が示されているべきです。

• 書かれているべきこと：Wave（段階）分けの案、各Waveの対象と期間、最初のパイロット範囲
• 確認すべき根拠：優先順位の根拠（ビジネス価値・技術的健全性・依存関係）
• 🚩危ないサイン：「フェーズ1：全体移行」のように、分割の考え方がない

順番の決め方そのものについては、レガシーシステムの問題点と優先順位の決め方も参考にしてください。そして、多くのアセスメントレポートで抜け落ちているのが、最後の問いです。

問い10：移行後の「正しさ」をどう証明するか

「新システムは旧システムと同じ動きをするのか」。これは、移行プロジェクトで最も多く問われる質問です。アセスメントの段階で、何をもって「同じ」と判定するかの方針が示されているべきです。

• 書かれているべきこと：テスト観点の方針（現新比較の対象、ゴールデンデータの候補、回帰テストの範囲）
• 確認すべき根拠：問い3で抽出した業務ルールと、テスト観点が対応づけられているか
• 🚩危ないサイン：「テストは移行フェーズで検討」とだけ書かれている

テストの進め方は、マイグレーションテストの進め方｜ゴールデンデータと4つの品質軸で詳しく解説しています。

🟡 自社のシステムで、この10の問いにどこまで答えられますか？

HBLABの無償AI診断では、ソースコードのZIPをアップロードするだけで、規模・依存関係・移行難易度を自動で解析し、24時間以内に診断レポートをお届けします。費用・登録は不要です。

👉 無償AI診断でアセスメントレポートを受け取る

良いアセスメントレポートと危ないレポートの見分け方

10の問いに「答えているように見える」レポートでも、中身の質には大きな差があります。ここでは、受け取った側がチェックすべき観点を整理します。

7つのチェック観点

特に重要なのは、根拠・前提・未調査範囲の3点です。この3点が欠けたレポートは、稟議の場で「この数字の根拠は？」と聞かれた瞬間に使えなくなります。

こんなレポートは要注意：5つのレッドフラグ

• ツールの出力をそのまま貼っただけ：数百ページの解析結果があっても、解釈と推奨がない
• 最初から結論ありき：調査前から特定の方式・製品が前提になっている
• 数字が丸すぎる：「約50%削減」など、算出過程が追えない
• 業務部門が登場しない：業務ロジックの妥当性を誰も確認していない
• テストへの言及がない：移行後の品質をどう担保するかが空白

見分け方が分かったところで、次に気になるのは「AIでどこまで作れるのか」ではないでしょうか。

AIで作るレポート、人が仕上げるレポート — どこまでAIに任せられるか

近年は、AIでソースコードを解析し、アセスメントレポートを短期間で作成するサービスが増えています。AIは強力ですが、AIが得意な部分と、人が判断すべき部分ははっきり分かれます。

AIが速くできること

• LOC・プログラム数・デッドコードの集計
• モジュール間の依存関係の抽出と可視化
• ソースコードからの業務ルール候補の抽出
• 自動変換できる割合の推定、難易度の一次判定

これらは、人手なら数週間かかる作業です。AIを使えば、初期の全体像を短時間でつかめます。

人が決めなければならないこと

• 抽出した業務ルールが「業務として正しいか」の判断
• ビジネス上の優先順位と、移行方式の最終決定
• リスクの受容可否と、社内体制を踏まえた計画
• 未調査範囲をどこまで追加調査するかの判断

つまり、AIは「事実」を速く集め、人は「解釈」と「推奨」に責任を持つという分担です。先ほどの比較表でいえば、「判断につながるレポート」にするのは人の仕事です。

AIをマイグレーションの各工程でどう使うかは、マイグレーションのAI活用｜工程別にできること・限界と品質担保で詳しく解説しています。

アセスメントレポートを受け取ったら：社内で使う３つの場面

アセスメントレポートは、受け取って終わりではありません。社内では主に、次の3つの場面で使います。

場面1：稟議・経営層への説明

経営層が見るのは、主にサマリです。「移行すべきか」「いくらか」「やらないと何が起きるか」の3点を1〜2ページで示せるかが鍵です。稟議資料の組み立て方は、ピラー記事の「稟議と合意形成」の章でも解説しています。

場面2：RFP作成とベンダー見積もりの比較

アセスメントレポートがあれば、各ベンダーに同じ前提で見積もりを依頼できます。前提がそろうことで、見積もりの比較が初めて意味を持ちます。

場面3：移行計画・テスト計画への引き継ぎ

問い9のロードマップは移行計画に、問い10のテスト方針はテスト計画に、そのまま引き継ぎます。ここで断絶が起きると、アセスメントにかけたコストが無駄になります。

受領後すぐに確認したいチェックリスト

• ☑ 10の問いすべてに、回答または「未調査」の明記があるか
• ☑ 主要な数値に、根拠と前提が書かれているか
• ☑ 見積もりに精度（幅）が示されているか
• ☑ 業務ルールの抽出結果を、業務部門が確認したか
• ☑ 経営層向けサマリが独立して読めるか
• ☑ 最初の着手範囲と、次のアクションが明確か

一つでも「いいえ」があれば、作成元に追加の説明を求めましょう。

HBLABの無償AI診断レポートで分かること

HBLABでは、AIによる解析と、BA/SAによるレビューを組み合わせたアセスメントを提供しています。その入口として、ソースコードをアップロードするだけで受け取れる無償AI診断をご用意しています。

診断レポートの主な内容

• サマリ：モダナイゼーション準備度スコア、解析行数、抽出した業務ルール数、AIによる自動変換率の推定
• モジュール別一覧：LOC、依存関係、難易度、主要課題
• 本格版で追加される内容：全モジュール一覧、工数見積もり、移行ロードマップ

安心してお試しいただくために

• ZIPファイル1つ（50MBまで）をアップロードするだけ。一部のモジュールだけでも診断できます
• 事前の打ち合わせ・見積もりは不要。24時間以内にメールでレポートをお届けします
• アップロードしたファイルは3日以内に自動削除。AIモデルの学習には使用しません
• ISO 27001・Pマーク取得済み。ご希望に応じて事前にNDAも締結できます

実際のプロジェクトでは

VB6からC# .NETへ移行した物流システムの事例では、約12万LOC・45画面・30帳票を解析し、約35%がデッドコードであることが分かりました。その結果、移行範囲を約3分の1削減できています（出典：HBLAB Migration Assessment Service 解説ウェビナー）。これは、問い1「本当の規模」に正しく答えることが、そのままコスト削減につながった例です。

🟡 まずは、自社システムの現状を「見える化」しませんか

10の問いのうち、規模・依存関係・難所・業務ルールは、無償AI診断で最初の答えが得られます。その先の方式・費用・ロードマップは、HBLABのBA/SAが一緒に整理します。

👉 無償AI診断を申し込む（24時間以内にレポートをお届け）

本格的なアセスメント・モダナイゼーション支援の詳細は、HBLABのモダナイゼーションサービスをご覧ください。

よくあるご質問

Q1. アセスメントレポートは何ページくらいが適切ですか？

規模によりますが、経営層向けサマリは1〜2ページに収めるのが理想です。技術詳細は付録として分けます。HBLABの無償AI診断レポートは12〜18ページ程度です。

Q2. ソースコードだけでアセスメントレポートは作れますか？

規模・依存関係・難易度・業務ルール候補は、ソースコードの解析だけでも把握できます。ただし、稼働状況やデータ品質、業務上の正しさは、ログやデータ、業務部門へのヒアリングで補う必要があります。

Q3. 設計書がほとんど残っていないシステムでも大丈夫ですか？

大丈夫です。設計書がない場合こそ、ソースコードから業務ロジックを復元するアセスメントの価値が高くなります。復元したルールを業務部門が確認する工程を必ず入れましょう。

Q4. AI診断と本格的なアセスメントの違いは何ですか？

AI診断は、ソースコードから「事実」を素早く集める入口です。本格的なアセスメントでは、そこにBA/SAによる解釈・推奨、工数見積もり、ロードマップが加わり、稟議や計画にそのまま使える形になります。

Q5. アセスメントと移行の実装は、同じベンダーに任せてもよいですか？

任せること自体は問題ありません。ただし、レポートの根拠・前提・未調査範囲が明記されているかを必ず確認してください。そうすれば、他社見積もりとの比較にも使えます。

まとめ

移行前のレポートは、調査結果の一覧ではなく、移行の可否・方式・費用・順番を決めるための判断材料です。規模、依存関係、業務ロジック、データ品質、難所、方式、費用、リスク、順番、そして移行後の正しさの証明——この10の問いに、根拠と前提つきで答えているかを確認しましょう。

AIは事実を速く集め、人は解釈と推奨に責任を持ちます。この分担ができているかも、良いレポートを見極めるポイントです。

まずは自社システムの現状を知るところから。無償AI診断なら、24時間以内に最初のアセスメントレポートを受け取れます。