この記事の要点
現行システムの依存関係調査とは、プログラム同士のつながりだけでなく、DB・バッチ・API・インフラ・データ・運用まで含めた「依存」を洗い出し、移行や改修の影響範囲を明らかにする作業です。本記事では、調査すべき6つのレイヤー、資料・ログ・ヒアリングを組み合わせた5ステップの進め方、成果物とチェックリストを解説します。
現行システムの依存関係調査とは、プログラム、DB、バッチ、外部システム、インフラ、運用のあいだにある「つながり」をすべて洗い出し、変更や移行の影響範囲を明らかにする作業です。
マイグレーションで起きる障害の多くは、コードそのものではなく「コードの外にある依存」から生まれます。夜間バッチの実行順序、他システムへのファイル連携、DBのトリガー、担当者が手作業で補正しているExcelなどです。依存関係調査でこれらを事前に把握しておけば、移行順序やテスト範囲を根拠をもって決められます。
本記事は、レガシーシステムアセスメントの評価7領域を解説した記事のクラスター記事です。プログラム資産の評価については、マイグレーション前のソースコード解析もあわせてご覧ください。
1. 現行システムの依存関係調査とは？
まずは、なぜソースコードの調査だけでは足りないのか、依存関係を見落とすと何が起きるのかを確認しましょう。
1-1. ソースコードだけでは依存関係の全体像が見えない理由
ソースコード解析で分かるのは、主にプログラム間の呼び出し関係と、プログラムからDB・ファイルへのアクセスです。しかし実際のシステムでは、依存の多くがコードの外に定義されています。
- ジョブ管理ツールに定義された実行順序や起動条件
- DBのストアドプロシージャ、トリガー、ビュー、DBリンク
- ファイル転送ツールやEDIの設定、他システムとの受け渡しルール
- ミドルウェアやOSの設定、認証基盤との連携
これらはソースを読むだけでは見つからないため、別の方法で依存関係を調べる必要があります。
1-2. 依存関係の見落としで起きる典型的なトラブル
依存関係調査が不十分なまま移行すると、次のようなトラブルが起きがちです。
- 切り替え後に、他部署のシステムへのファイル連携が止まっていたことが判明する
- バッチの実行順序が変わり、月次処理の集計結果がずれる
- 共有していたマスタの更新タイミングが変わり、別システムでエラーが出る
- 担当者がExcelで行っていた補正作業が、移行後に誰にも引き継がれていない
こうした問題は、結合テストや本番切り替えの段階で発覚するため、手戻りのコストが非常に大きくなります。
2. 依存関係調査で対象にすべき6つのレイヤー
依存関係を漏れなく洗い出すには、システムをいくつかのレイヤーに分けて調べるのが効果的です。HBLABでは、次の6つのレイヤーで依存関係調査を行っています。
2-1. アプリケーション・DB：テーブル、ストアド、トリガー
どのプログラムがどのテーブルを作成・参照・更新・削除しているか（CRUD）を把握します。あわせて、ストアドプロシージャやトリガーに埋め込まれた業務ロジック、他DBを参照するDBリンクも確認します。
2-2. バッチ・ジョブ：実行順序、起動条件、再実行ルール
ジョブネットの先行・後続関係、起動時刻、営業日カレンダー、異常時の再実行ルールを洗い出します。バッチは「どの順番で動くか」自体が仕様であり、移行時に最も壊れやすい依存の一つです。
2-3. API・外部インターフェース：連携先とデータ仕様
社内外のシステムとのAPI連携、ファイル連携、EDI、メール送信などを一覧化します。連携先ごとに、方向・頻度・データ形式・文字コード・担当部署を記録しておくと、移行後の結合テストがスムーズになります。
2-4. インフラ・ミドルウェア：OS、MQ、帳票、認証
OSやミドルウェアのバージョン、メッセージキュー、帳票ツール、認証基盤、ライセンス条件などへの依存を確認します。移行先で同じ製品が使えない場合、代替手段の検討が必要です。
2-5. データ：共有マスタ、コード値、データの流れ
複数のシステムで共有しているマスタやコード値、データがどこで生まれ、どこへ流れていくかを整理します。データの依存は、データ移行テストの範囲を決める前提にもなります。
2-6. 運用・人：手作業、EUC、属人ノウハウ
システムの外で行われている手作業、ExcelやAccessで作られたEUC（エンドユーザーコンピューティング）、特定の担当者だけが知る例外対応も、立派な依存関係です。ドキュメントにもコードにも残っていない依存は、ヒアリングでしか見つかりません。
| レイヤー | 主な調査対象 | 主な情報源 |
|---|---|---|
| アプリ・DB | CRUD、ストアド、トリガー、DBリンク | ソース、DB定義、データ辞書 |
| バッチ・ジョブ | 実行順序、起動条件、再実行 | ジョブ定義、実行ログ |
| API・外部IF | 連携先、方向、頻度、形式 | IF仕様書、通信ログ、転送設定 |
| インフラ・MW | OS、MQ、帳票、認証、ライセンス | 構成管理表、設定ファイル |
| データ | 共有マスタ、コード値、データの流れ | テーブル定義、実データ |
| 運用・人 | 手作業、EUC、例外対応 | 運用手順書、ヒアリング |
3. 現行システムの依存関係調査の進め方：5ステップ
6つのレイヤーを効率よく調べるには、「機械的に取れる情報」から先に集め、最後に人への確認で補うのが基本です。ここでは、HBLABが実案件で用いている5ステップを紹介します。
Step1. 調査の目的と範囲を決める
最初に、「何のために、どの範囲を、どの粒度で」調べるのかを決めます。全面移行なのか一部移行なのかによって、調べるべき依存の深さが変わります。範囲の決め方は、モダナイゼーションの優先順位と範囲も参考になります。
範囲が決まったら、まずは人に聞く前に、機械的に取れる情報を集めます。
Step2. 設定・定義・ログから依存関係を機械的に抽出する
ジョブ定義、DBのデータ辞書、ファイル転送の設定、cron、ファイアウォールの許可ルール、通信ログなどから、依存関係を機械的に抽出します。ドキュメントは古くなっていることが多いため、「実際の設定」と「実際のログ」を優先するのがポイントです。
Step3. ソースコード解析の結果と突き合わせる
抽出した依存関係を、ソースコード解析で得た呼び出し関係やCRUD図と突き合わせます。設定にはあるのにコードから参照されていないもの、コードにはあるのに実行ログに出てこないものは、要確認の対象としてリストアップします。
Step4. 関係者ヒアリングで「書かれていない依存」を補う
業務担当者、運用担当者、連携先システムの担当者にヒアリングし、手作業やEUC、例外時の対応などを確認します。Step2〜3で作った一覧を見せながら質問すると、「そういえば月末だけ別のファイルを送っている」といった情報が引き出しやすくなります。
Step5. 依存関係マップと影響度評価を作る
最後に、レイヤーをまたいだ依存関係マップを作成し、依存ごとに影響度と変更の難しさを評価します。この評価が、移行順序とテスト計画の土台になります。
| 評価 | 例 | 対応方針 |
|---|---|---|
| 影響度：高／変更：難 | 複数システムが共有するマスタ、基幹バッチ | 移行計画の初期に方針決定、並行稼働・段階移行を検討 |
| 影響度：高／変更：易 | 外部へのファイル連携（形式は変えない） | 連携先と事前合意し、結合テストで重点確認 |
| 影響度：低／変更：難 | 古いミドルウェア依存の補助機能 | 廃止・代替の可否を業務部門と判断 |
| 影響度：低／変更：易 | 社内向けの通知メール | 通常の移行・テストで対応 |
現行システムの依存関係、どこまで把握できていますか？
HBLABの無償AI診断では、ソースコードと設定情報を解析し、プログラム・DB・外部連携の依存関係を可視化します。移行範囲や順序を決める前の判断材料としてご活用ください。
4. 依存関係調査のアウトプット（成果物）
依存関係調査の結果は、移行計画・設計・テストの各工程で繰り返し参照されます。最低限、次の成果物をそろえておきましょう。
| 成果物 | 内容 | 主な利用工程 |
|---|---|---|
| 依存関係マップ | レイヤーをまたいだ全体のつながり | 移行方式・移行順序の決定 |
| CRUD図 | プログラム×テーブルの操作 | 設計、データ移行 |
| インターフェース一覧 | 連携先、方向、頻度、形式、担当 | 結合テスト、切り替え計画 |
| ジョブフロー図 | 実行順序、起動条件、再実行 | バッチ移行、運用設計 |
| インフラ・MW依存一覧 | 製品、バージョン、代替案 | 基盤設計 |
| 運用・EUC一覧 | 手作業、Excel/Access、担当者 | 業務設計、移行後の運用 |
これらの成果物をどのように報告書にまとめるかは、アセスメントレポートが移行前に答えるべき10の問いで解説しています。
5. 依存関係調査を効率化する3つのコツ
依存関係調査は範囲が広く、人手だけでは時間がかかります。精度を落とさずに効率化するコツを3つ紹介します。
5-1. 実行ログ・通信ログで「実際に使われている依存」を確かめる
設定やドキュメントに残っていても、すでに使われていない連携は少なくありません。一定期間の実行ログや通信ログを分析すれば、本当に動いている依存と、廃止できる依存を切り分けられます。
5-2. AIで設定ファイルやジョブ定義の読み解きを速める
大量のジョブ定義や設定ファイルは、生成AIによる要約・分類と相性がよい領域です。ただし、AIの出力は必ず実際の設定・ログと照合します。AIをリバースエンジニアリングに活用する方法は、AIリバースエンジニアリングとレガシー設計書の復元手順で詳しく解説しています。
5-3. 調査結果を移行順序とテスト計画に直結させる
依存関係調査は、調べて終わりではありません。影響度の高い依存は移行順序の判断に、インターフェース一覧は結合テストの計画に、そのまま引き継ぎます。テスト計画の全体像は、マイグレーションテストの進め方をご覧ください。移行単位を依存関係にもとづいて分ける考え方は、AWS規範ガイダンス「ウェーブベースのリファクタリング：分析フェーズ」でも紹介されています。
6. 現行システムの依存関係調査チェックリスト
依存関係調査の完了前に、次の12項目を確認しましょう。
- 調査の目的・範囲・粒度が合意されている
- CRUD図（プログラム×テーブル）がある
- ストアドプロシージャ・トリガー・ビューを確認した
- DBリンクなど他DBへの参照を確認した
- ジョブフロー（先行・後続・起動条件）が図になっている
- 営業日カレンダー・再実行ルールを確認した
- 外部インターフェース一覧（方向・頻度・形式・担当）がある
- 文字コード・データ形式の違いを確認した
- OS・ミドルウェア・ライセンスへの依存を確認した
- 共有マスタ・コード値の利用先を確認した
- 手作業・EUC・例外対応をヒアリングで確認した
- 依存ごとの影響度評価と対応方針が決まっている
7. HBLABの現行システム調査・アセスメント支援
HBLABは、AIを活用したマイグレーションを、現行調査から移行・テストまで一貫して支援しています。
HBLABのAI Assessment Toolは、ソースコードや設定情報の解析を起点に、技術調査、評価、移行戦略、業務仕様の整理、コード変換、単体テスト、結合テストの7工程を支援します。機械的な抽出とAIによる整理で調査を高速化し、依存関係の意味づけや影響度の判断は、SA（システムアーキテクト）とBA（業務分析）の専門家が担います。
サービスの全体像は、HBLABのモダナイゼーションサービスとマイグレーションサービスをご覧ください。
依存関係調査から移行計画まで、HBLABにご相談ください
「ドキュメントが古く、つながりが分からない」「どこから移行すべきか判断できない」といったお悩みに、現行システムの依存関係調査とアセスメントでお応えします。
8. 依存関係調査に関するよくある質問
依存関係調査とソースコード解析の違いは何ですか？
ソースコード解析は、主にプログラムの中身と、プログラム間・プログラムからDBへのつながりを調べます。依存関係調査は、それに加えてバッチ、外部連携、インフラ、運用まで含めた、システム全体のつながりを調べる作業です。
ドキュメントがほとんど残っていなくても調査できますか？
はい。ジョブ定義、DB定義、設定ファイル、実行ログなど「実際に動いている情報」から依存関係を抽出し、ヒアリングで補完します。ドキュメントがない場合ほど、ログの分析が重要になります。
依存関係調査はどのくらいの期間が必要ですか？
システムの規模や連携先の数によって異なります。まずは移行対象の範囲を絞り、機械的に抽出できる部分から始めると、短期間で全体像をつかめます。
まとめ
現行システムの依存関係調査では、アプリ・DB、バッチ・ジョブ、API・外部連携、インフラ・ミドルウェア、データ、運用・人の6レイヤーを、設定・ログ・ソース・ヒアリングを組み合わせた5ステップで調べます。成果物は移行順序とテスト計画に直結させましょう。HBLABは、移行を成功に導く現行システムの依存関係調査を支援します。
