InfoQ で How Netflix Maps Thousands of Microservices in Real-Time が話題になりました。Netflix のような規模では、どのサービスが何を呼び、どこが落ちると何が止まるのかを、人手で把握するのは不可能です。だからこそ依存関係を 継続的に・自動で可視化する基盤を持っています。重要なのは、これが 大規模特有の問題ではなく、システムが少し複雑になった時点で誰にでも起きるという点です。
受託システム開発の現場では、「改修したい箇所がどこに影響するか誰も分からない」「退職した担当者しか全体像を知らず、触るのが怖くて塩漬け」「障害が起きても影響範囲が特定できない」という事故が後を絶ちません。受託でシステムを支える立場では、これは 「ドキュメントを書くか」ではなく、「依存関係を可視化し、改修と障害対応の前提を整え、運用に組み込んだ状態で引き渡せるか」を設計に組み込む課題だと捉えています。これまで 継続プロファイリングによる可観測性の受託（GH Media） で扱った 運用の可視化、イベントストリーミング統治の受託（GH Media） で扱った 連携の整理、Adaptive Hedging による SRE 受託（GH Media） で扱った 信頼性の確保と接続して、本記事では 「システム棚卸し・依存関係可視化支援」を 受託パッケージとして整理します。
なぜ「いま」依存関係の可視化なのか
| 観点 | 属人・不可視 | 可視化（2026） |
|---|---|---|
| 全体像 | 退職者しか知らない | 図で誰でも把握 |
| 改修 | 影響範囲が読めない | 依存から影響を特定 |
| 障害 | 原因切り分けに難航 | 連鎖を辿って特定 |
| 引き継ぎ | 口頭・記憶頼み | 可視化資産で継承 |
| 更新 | 一度きりで陳腐化 | 継続的に最新化 |
| 成果 | 触るのが怖い | 安心して改修できる |
つまり 「動いていること」と「全体像が分かること」は別物であり、受託でも 「依存関係を可視化し、継続的に最新化し、運用に組み込んで引き渡す」ことが品質の前提になりました。これにより 「安心して改修できるシステム」を成果物として保証できます。
受託案件で活きる 3 つの構造変化
構造 1: 「属人」から「可視化資産」へ
担当者の記憶に頼ると引き継ぎで崩壊します。受託では 依存関係を図と一覧で資産化し、誰でも全体像を把握できる状態を提供します。
構造 2: 「勘で改修」から「影響範囲特定」へ
影響が読めない改修は事故を生みます。受託では 依存から影響範囲を特定し、改修前にリスクを見える化します。
構造 3: 「一度きり」から「継続更新」へ
手書き図はすぐ陳腐化します。受託では 可能な範囲で自動収集・更新し、常に最新の地図を保つ設計を提供します。
受託で提供する「システム棚卸し・可視化支援」5 フェーズ
フェーズ 1: 棚卸し（1〜2 週間）
- システム・サービス・外部連携の洗い出し
- データベース・バッチ・ジョブの把握
- 認証・決済・通知など共通基盤の特定
- ドキュメント・知見の所在確認
フェーズ 2: 依存関係の収集設計（1 週間）
- 依存情報の収集方法（コード解析 / 通信ログ / 設定）
- 可視化の粒度（サービス / モジュール）
- 重要度・影響度の評価基準
- 更新頻度と自動化の方針
フェーズ 3: 可視化・整理（2〜3 週間）
- 依存関係マップの作成
- 単一障害点・循環依存の抽出
- 改修ホットスポットの特定
- リスク・課題の一覧化
フェーズ 4: 改修・対応設計（1 週間）
- 影響範囲を踏まえた改修計画
- 単一障害点の緩和方針
- 監視・アラートの補強提案
フェーズ 5: 継続運用（継続）
- 依存マップの定期更新
- 変更時の影響レビュー
- 新規連携の地図への反映
受託向け技術スタック標準セット
| レイヤ | 推奨技術 | 代替 |
|---|---|---|
| 収集 | 静的解析 / 通信トレース | 設定・手動棚卸し |
| 可視化 | 依存グラフ / サービスマップ | 図表 + 台帳 |
| 可観測性 | 分散トレース / メトリクス | アクセスログ |
| 管理 | 構成情報の一元管理 | スプレッドシート |
| 更新 | CI 連動の自動収集 | 定期手動更新 |
| 共有 | 社内ポータル / Wiki | ドキュメント配布 |
どの案件に必要か / 不要か
| 必要な案件 | 優先度が低い案件 |
|---|---|
| 全体像を知る人が退職した | 単一の小規模アプリ |
| 改修の影響範囲が読めない | 構成が単純で把握済み |
| 障害の原因特定に時間がかかる | 障害がほぼ起きない社内用 |
| 引き継ぎ・保守移管を控える | 廃止予定のシステム |
| 複数システムが連携する | 外部連携がない |
受託契約に書く 6 つの条項
| 条項 | 内容 | 顧客が確認すべきこと |
|---|---|---|
| 対象範囲 | 棚卸し対象のシステム | 範囲の合意 |
| 成果物 | 依存マップ / 課題一覧 | 納品形式 |
| 収集方法 | 解析 / ログの扱い | データの扱い |
| 更新 | 最新化の頻度 | 運用範囲 |
| 引き渡し | 手順 / Runbook | 保守体制 |
| 継続運用 | 定期更新 | 運用費用 |
価格モデル — システム棚卸し・可視化パッケージ
| プラン | 金額 | 対象 | 内容 |
|---|---|---|---|
| 棚卸し診断 | 35 万円〜 | 小規模 | 洗い出し + 依存マップ初版 |
| 可視化パッケージ | 120 万円〜 | 中規模 | 収集設計 + マップ + 課題整理 |
| 本格可視化 | 230 万円〜 | 中〜大規模 | + 自動収集 + 改修計画 |
| Lite 保守 | 6 万円〜 / 月 | 小規模 | 定期更新 |
| Standard 保守 | 18 万円〜 / 月 | 中規模 | + 変更影響レビュー |
顧客側 ROI 試算（中堅企業の基幹連携想定）
| 項目 | 既存（属人・不可視） | 可視化 | 差分 |
|---|---|---|---|
| 改修見積 | 不確実で過大 | 影響特定で適正化 | 見積精度の向上 |
| 障害対応 | 切り分けに難航 | 連鎖を辿り短縮 | 復旧時間の短縮 |
| 引き継ぎ | 属人で高リスク | 資産で円滑 | 移管リスクの低減 |
| 塩漬け | 触れず放置 | 安心して改修 | 改善の再開 |
| 年間効果 | — | — | 改修・障害対応の工数削減と塩漬け解消 |
可視化パッケージ（120 万円〜）でも、改修見積の適正化と障害対応時間の短縮で十分に正当化できます。
ハマりやすい 5 つの落とし穴
落とし穴 1: 一度だけ図を書いて終える
すぐ陳腐化します。継続更新を設計します。
落とし穴 2: 粒度を細かくしすぎる
読めない図になります。重要度で粒度を調整します。
落とし穴 3: 隠れた外部連携を見落とす
障害の盲点になります。通信ログからも収集します。
落とし穴 4: 単一障害点を放置する
可視化だけで満足します。緩和策まで提案します。
落とし穴 5: 共有しない
担当者の手元で死蔵されます。社内で参照可能にします。
90 日アクションプラン
| 週 | アクション |
|---|---|
| Week 1〜2 | システム・連携の洗い出し |
| Week 3 | 依存収集・可視化方針の設計 |
| Week 4〜6 | 依存マップ作成 + 課題抽出 |
| Week 7 | 改修計画 + 単一障害点の対応設計 |
| Week 8〜13 | 定期更新 + 変更影響レビューの運用開始 |
まとめ — 「動いているが分からない」から「安心して改修できる」へ
依存関係の可視化は、巨大企業だけのものではありません。受託でシステムを支える立場では、依存を可視化し、継続的に最新化し、運用に組み込んで引き渡す 「システム棚卸し・可視化支援」が、塩漬けを解き安心して改修できる状態を届ける新しい主力サービスです。
弊社では棚卸し診断 / 可視化パッケージ / 本格可視化 / Lite / Standard の各段階で本パッケージを提供しています。「全体像を知る人がいなくなった」「改修の影響範囲が読めない」「保守を引き継ぎたい」というご相談は お問い合わせフォーム からお気軽にどうぞ。
