この記事の要点
マイグレーション前のソースコード解析とは、移行対象のプログラム資産を棚卸しし、規模・複雑度・依存関係・移行難易度を定量的に把握する作業です。目的は「正確な見積もり」と「移行方式の判断」の材料をつくることにあります。本記事では、評価すべき8項目と、静的解析とAIを組み合わせた5ステップの進め方、アウトプットのチェックリストを解説します。
マイグレーション前のソースコード解析とは、移行対象となるプログラム資産をすべて洗い出し、規模・複雑度・依存関係・非互換要素を数字で把握する作業です。ひと言でいえば、「どこが、どれだけ、なぜ難しいのか」を移行前に明らかにする工程です。
レガシーシステムの移行では、見積もりの超過や移行漏れの多くが「コードを十分に調べないまま計画を立てた」ことに起因します。ソースコード解析を先に行えば、移行方式の選択、工数の見積もり、テスト範囲の設計を、勘ではなく根拠にもとづいて決められます。
本記事は、レガシーシステムアセスメントの評価7領域を解説した記事のクラスター記事です。ここでは、その中でも「ソースコード」に焦点を当てて掘り下げます。
1. マイグレーション前のソースコード解析とは？
ソースコード解析は、単にコードを「読む」作業ではありません。まずは目的と、よくある誤解を整理しておきましょう。
1-1. 目的：見積もり・移行方式・リスクの判断材料をつくる
マイグレーションにおけるソースコード解析の目的は、次の3つです。
- 見積もりの根拠をつくる：移行対象の本数・行数・難易度を数値化する
- 移行方式を決める：リホスト・リライト・リビルドのどれが適切かを判断する
- リスクを先に洗い出す：非互換要素や隠れた依存関係を、移行前に把握する
つまり、ソースコード解析は「移行計画の土台」です。ここが曖昧なまま進めると、後工程すべてが不安定になります。
1-2. 「コードリーディング」と「ソースコード解析」の違い
コードリーディングは、人が一部のプログラムを読んで仕様を理解する作業です。一方、ソースコード解析は、資産全体を網羅的に計測し、比較・分類できる状態にする作業です。
数十万〜数百万行のレガシー資産を、人の目だけで網羅的に読むことは現実的ではありません。そのため、ツールによる定量的な計測で全体像をつかみ、重要な箇所だけを人が深く読む、という役割分担が基本になります。
1-3. ソースコード解析を省略すると起きること
ソースコード解析を十分に行わずに移行を始めると、次のような問題が起こりがちです。
- 移行途中で「ソースが存在しないプログラム」が見つかり、計画が止まる
- 使われていないコードまで移行し、工数とテスト費用が膨らむ
- 外部システムやファイル連携の存在に後から気づき、結合テストで障害が多発する
- コードに埋め込まれた業務ルールを見落とし、本番で計算結果がずれる
経済産業省も、レガシーシステムの複雑化・ブラックボックス化がDXの足かせになっていると指摘しています（経済産業省「レガシーシステムモダン化委員会総括レポート」）。ブラックボックス化の背景については、システムのブラックボックス化の原因と解消ステップもあわせてご覧ください。
2. マイグレーション前のソースコード解析で評価すべき8項目
では、具体的に何を評価すればよいのでしょうか。HBLABでは、マイグレーション前のソースコード解析で次の8項目を必ず確認しています。
① 資産の棚卸し：言語・本数・行数・ソースの有無
最初に確認するのは、どの言語のプログラムが、何本、何行あるかです。あわせて、本番で動いているモジュールに対応するソースが存在するか、最新版かを確認します。ソース紛失や、本番とソースの不一致は、レガシー資産では珍しくありません。
② 未使用コード（デッドコード）
長年改修を重ねたシステムでは、呼び出されていないプログラムや、到達しない分岐が大量に残っています。移行前にデッドコードを特定して対象から外すだけで、移行・テストの工数を大きく減らせるケースがあります。
③ 複雑度：循環的複雑度・ネスト・巨大プログラム
分岐の多さ（循環的複雑度）、ネストの深さ、1本あたりの行数を計測します。複雑度が極端に高いプログラムは、自動変換の精度が落ちやすく、テスト工数も増えます。
④ 重複コード（クローン）
コピー＆ペーストで作られた類似コードは、移行時に共通化するか、そのまま移すかの判断が必要です。重複の量は、リファクタリングを含めるかどうかの判断材料にもなります。
⑤ 内部依存：呼び出し関係と共通部品
どのプログラムがどのプログラムを呼び出しているか、共通部品（サブルーチン・COPY句・共通クラス）がどこで使われているかを把握します。共通部品の変更は影響範囲が広いため、移行順序の決定に直結します。
⑥ 外部依存：DB・ファイル・外部システム・ミドルウェア
ソースコードから、アクセスしているテーブル、入出力ファイル、外部システムとの連携、利用しているミドルウェアを抽出します。これらはコードの外にも広がっているため、アセスメントの評価領域としてDB・バッチ・運用と合わせて確認するのが確実です。
⑦ 非互換要素：ベンダー固有構文・EOLライブラリ・文字コード
移行先の言語・環境で動かない要素を洗い出します。たとえば、特定ベンダーの拡張構文、サポートが終了したライブラリ、EBCDICやShift_JIS前提の文字処理、外字などです。非互換要素の数と種類は、移行難易度を決める最大の要因です。
⑧ 業務ロジックの所在：ハードコード・設定値・帳票
税率や締め日、例外処理などの業務ルールが、コードのどこに埋まっているかを確認します。業務ロジックの継承については、COBOL移行で業務ロジックを守る方法で詳しく解説しています。
| 評価項目 | 主な指標 | 移行への影響 |
|---|---|---|
| ① 資産の棚卸し | 言語別の本数・行数、ソース有無 | 見積もりの基礎 |
| ② デッドコード | 未参照プログラム数・比率 | 移行対象の削減 |
| ③ 複雑度 | 循環的複雑度、行数 | 変換精度・テスト工数 |
| ④ 重複コード | クローン率 | 共通化の要否 |
| ⑤ 内部依存 | 呼び出し関係、共通部品の利用数 | 移行順序 |
| ⑥ 外部依存 | テーブル・ファイル・外部IF数 | 結合テスト範囲 |
| ⑦ 非互換要素 | 固有構文・EOL部品の件数 | 移行難易度 |
| ⑧ 業務ロジック | ハードコード箇所 | 仕様継承のリスク |
3. マイグレーションに向けたソースコード解析の進め方：5ステップ
8項目を漏れなく評価するには、順序が重要です。ここでは、HBLABが実際のマイグレーション案件で用いている5ステップを紹介します。
Step1. 資産を収集し「ソースと本番の一致」を確認する
まず、リポジトリやファイルサーバーに散らばったソース、JCL・シェル、設定ファイルを1か所に集めます。そのうえで、本番環境のモジュールとソースのバージョンが一致しているかを確認します。ここでの不一致は、後工程で必ず問題になります。
資産がそろったら、次はツールで定量データを取ります。
Step2. 静的解析ツールで定量データを取る
静的解析ツールを使い、行数、複雑度、重複、呼び出し関係、テーブル・ファイルへのアクセスを機械的に抽出します。人手での集計に比べ、網羅性と再現性が高いのが利点です。
Step3. 呼び出し関係と影響範囲を可視化する
抽出したデータをもとに、プログラム間の呼び出し関係図やCRUD図（どのプログラムがどのテーブルを作成・参照・更新・削除するか）を作成します。可視化することで、業務担当者や経営層とも議論しやすくなります。依存関係にもとづいて移行単位（ウェーブ）を分ける考え方は、AWS規範ガイダンス「ウェーブベースのリファクタリング：分析フェーズ」でも紹介されています。
Step4. 移行難易度でプログラムを分類する
計測結果をもとに、プログラムを移行難易度で分類します。分類があると、自動変換に任せる範囲と、人が重点的に設計・テストする範囲を切り分けられます。
| ランク | 特徴 | 主な対応 |
|---|---|---|
| A（低） | 複雑度が低く、非互換要素なし | ツールによる自動変換＋サンプル確認 |
| B（中） | 一部に非互換要素・外部依存あり | 自動変換＋個別修正＋重点テスト |
| C（高） | 複雑度が高い、業務ロジック集中、ソース不一致 | 再設計・リライトを検討、業務担当者と仕様確認 |
Step5. 解析結果を移行方式と見積もりに反映する
最後に、ランク別の本数・行数をもとに工数を見積もり、移行方式と移行順序を決めます。どの領域から着手するかの考え方は、モダナイゼーションの優先順位と範囲の決め方が参考になります。
自社のソースコード資産、どこに移行リスクが潜んでいるか把握できていますか？
HBLABの無償AI診断では、ソースコードを解析し、規模・複雑度・依存関係・非互換要素を可視化します。移行方式や見積もりを検討する前の判断材料としてご活用ください。
4. ソースコード解析にAIをどう活かすか
近年は、生成AIをソースコード解析に組み合わせるケースが増えています。ただし、AIに任せてよい部分と、そうでない部分があります。
4-1. AIが得意なこと：要約・仕様の下書き・分類の補助
生成AIは、プログラムの処理概要の要約、設計書の下書き、類似プログラムのグルーピングなどを短時間でこなせます。数千本規模の資産でも、全体の「あたり」を素早くつけられるのは大きな利点です。
4-2. 静的解析と組み合わせる理由
一方で、生成AIはもっともらしい誤り（ハルシネーション）を含むことがあります。そのため、行数や呼び出し関係などの「事実」は静的解析で確定し、AIはその事実を前提に要約・説明を行う、という役割分担が安全です。AI活用の工程別の考え方は、マイグレーションのAI活用：できること・限界と品質担保で解説しています。
5. ソースコード解析だけでは見えないもの
ソースコード解析は重要ですが、それだけで現行システムのすべてが分かるわけではありません。
- DB：ストアドプロシージャ、トリガー、ビューに埋まったロジック
- バッチ・ジョブ：ジョブネットの実行順序、再実行ルール、日付処理
- 外部連携：API、ファイル連携、EDIの相手先と仕様
- 運用：手作業による補正、運用担当者だけが知る例外対応
これらは、ソースコード解析の結果と突き合わせながら、現行システム全体の調査として確認する必要があります。調査結果をどう報告書にまとめるかは、アセスメントレポートが答えるべき10の問いをご覧ください。
6. ソースコード解析のアウトプット：チェックリスト
マイグレーション前のソースコード解析が完了したら、次の10項目がそろっているか確認しましょう。
- 言語別のプログラム本数・行数一覧
- ソース有無・本番との一致確認結果
- デッドコードの一覧と除外判断
- 複雑度の上位プログラム一覧
- 重複コードの比率と共通化方針
- プログラム間の呼び出し関係図
- CRUD図（プログラム×テーブル）
- 外部インターフェース・ファイル一覧
- 非互換要素の一覧と対応方針
- 移行難易度ランク別の本数と見積もり
7. HBLABのソースコード解析・アセスメント支援
HBLABは、AIを活用したマイグレーションを、アセスメントから移行・テストまで一貫して支援しています。
HBLABのAI Assessment Toolは、ソースコード解析を起点に、技術調査、評価、移行戦略、業務仕様の整理、コード変換、単体テスト、結合テストまでの7工程を支援します。静的解析で事実を確定し、AIで要約・仕様化を高速化し、最終判断はエンジニアと業務分析の専門家が行う、という体制で品質を担保しています。
移行方式の比較やサービスの全体像は、HBLABのモダナイゼーションサービスをご覧ください。
ソースコード解析から移行計画まで、まとめて相談しませんか？
「資産が多すぎて全体像がつかめない」「見積もりの根拠を示したい」といったお悩みに、HBLABがソースコード解析とアセスメントでお応えします。
8. ソースコード解析に関するよくある質問
ソースコード解析にはどのくらいの期間がかかりますか？
資産の規模や言語によって異なりますが、ツールによる計測自体は短期間で終わります。時間がかかるのは、ソースの収集・本番との一致確認と、結果の解釈・分類です。まずは対象範囲を絞って試行するのがおすすめです。
ソースが一部見つからない場合でも解析できますか？
はい。見つからない部分を明確にしたうえで、実行モジュールや入出力データ、業務担当者へのヒアリングから仕様を補完します。ソースがない部分は、移行難易度を高く見積もるのが安全です。
静的解析ツールだけで十分ではないのですか？
計測には静的解析ツールが最適ですが、業務ロジックの意味づけや、移行してよいかの判断はツールではできません。ツール、AI、人の3つを組み合わせることで、精度とスピードを両立できます。
まとめ
マイグレーション前のソースコード解析は、資産の棚卸し、デッドコード、複雑度、重複、内部・外部依存、非互換要素、業務ロジックの8項目を評価し、移行難易度で分類して見積もりに反映する工程です。静的解析で事実を固め、AIで理解を速め、人が判断する体制で進めましょう。HBLABは、移行を成功に導くソースコード解析を支援します。
