# システムのブラックボックス化解消｜費用と外注手順 - 公開日: 2026-09-20 - 監修: 代表取締役 兼 StockSun創業メンバー 板橋 晟星 - URL: https://www.geek-bridge.com/public/column/system-black-box-recovery-cost システムのブラックボックス化は、いきなり全面刷新せず、まず資産・構成・業務影響を調査して「安全に触れる範囲」を明らかにすることが重要です。一般的な調査費用は30万〜300万円程度、文書化やテスト整備を含む解消費用は100万〜1,000万円以上が目安です。 ## ブラックボックス化を解消すべき状態と判断基準 ブラックボックス化とは、システムの仕組みや変更方法を理解できる人が限られ、担当者の退職や委託先の変更によって保守・改修が難しくなっている状態です。資料が古いことだけではなく、「誰が、何を確認すれば、安全に変更できるか分からない」ことが本質的な問題です。 発注者は、次の項目に複数該当する場合、現状調査を優先した方がよいでしょう。 - システムを理解している担当者が1人しかいない - 退職した社員や現在の委託先に質問しないと仕様が分からない - ソースコードの保管場所や最新版が分からない - 設計書と実際の動作が一致していない - サーバー、クラウド、ドメイン、外部サービスの契約名義が不明である - 障害時に確認するログや連絡先が整理されていない - 小さな改修でも影響範囲を調べるために長期間かかる - テスト環境がなく、本番環境で確認せざるを得ない - バックアップはあるが、復元できるか試したことがない - 古い技術や製品を利用しており、対応できる技術者が減っている - 開発会社から見積もりの根拠や作業内容が十分に説明されない 特に優先度が高いのは、売上、受発注、決済、顧客対応など、停止すると事業に直接影響するシステムです。利用頻度が低く代替手段もある社内ツールと、24時間利用される基幹システムでは、同じブラックボックス化でも対応の緊急度が異なります。 ### 解消方法は4つに分けて考える ブラックボックス化への対応は、全面的な作り直しだけではありません。調査結果と残存利用期間に応じて、次の方法を選びます。 |対応方針|適している状況|主な実施内容|注意点| |---|---|---|---| |現状維持と最低限の保全|近く廃止予定で、変更需要が少ない|バックアップ、アカウント整理、障害時連絡先の整備|現状維持が長期化するとリスクが残る| |可視化・文書化|動作は安定しているが、仕様や構成が不明|構成図、機能一覧、データ定義、運用手順の作成|資料を作るだけでは変更時の安全性を証明できない| |部分改修・リファクタリング|継続利用したいが、一部の構造が複雑|問題箇所の整理、テスト追加、監視改善|範囲を広げすぎると費用が膨らみやすい| |段階刷新・全面刷新|保守限界、事業要件の変化、製品終了が重なる|新環境への移行、機能再設計、データ移行|現行仕様を無条件で再現すると刷新効果が薄れる| リファクタリングとは、利用者から見える機能を大きく変えず、プログラム内部を保守しやすく整理することです。全面刷新より低コストになる場合がありますが、基盤自体が古い場合や利用終了が決まっている場合には適しません。 ## ブラックボックス化解消の費用相場と期間 費用は、システムの規模よりも「どこまで情報が残っているか」「本番以外で安全に確認できるか」に左右されます。最初から総額を固定するのではなく、現状調査と改善実施を分けて予算化するのが現実的です。 一般的な目安は次のとおりです。実際の費用は画面数、連携先、データ量、技術、利用時間帯、セキュリティ要件によって変動します。 |依頼内容|費用の目安|期間の目安|主な成果物| |---|---:|---:|---| |資料・契約・アカウントの棚卸し|30万〜100万円|2〜4週間|資産一覧、アカウント一覧、不足資料一覧| |ソースコード・構成・データの現状調査|80万〜300万円|1〜2カ月|調査報告書、構成図、課題・リスク一覧| |設計書・運用資料の再整備|100万〜500万円|1〜4カ月|機能一覧、画面・データ・連携仕様、運用手順| |テスト・監視・バックアップの整備|150万〜700万円|2〜6カ月|テスト仕様、監視設定、復旧手順、実施記録| |重要部分の改修・リファクタリング|300万〜2,000万円以上|3〜12カ月|改修済みシステム、テスト結果、更新後の設計資料| |段階刷新・全面刷新|1,000万円〜数千万円以上|6〜18カ月以上|新システム、移行データ、運用・保守資料| これらは単純にすべて加算するものではありません。例えば、小規模な社内Webシステムで資料とソースコードが残っていれば、100万〜400万円程度で可視化と最低限のテスト整備まで進められる可能性があります。一方、複数システムとの連携があり、停止できない業務システムでは、調査だけで数百万円になることもあります。 ### 費用を増やす主な要因 見積もりが高くなりやすい条件は次のとおりです。 - ソースコードが複数の場所にあり、最新版を特定できない - 本番環境しかなく、調査用環境の構築が必要である - 夜間処理や定期実行処理の一覧がない - 外部サービスとの連携仕様や契約情報が不明である - データベースの項目名だけでは意味を判断できない - 個人情報、決済情報、機密情報を扱っている - 24時間稼働しており、確認や切り替えの時間が限られる - 既存担当者へのヒアリングができない - 古い言語、独自フレームワーク、サポート終了製品を利用している 発注のご相談を受ける立場では、「URLと管理画面だけを見て総額を出してほしい」というご要望をいただくことがあります。しかし、外から見える画面だけでは、データ構造、定期処理、外部連携、障害時の影響を把握できません。無理に総額を出した見積もりは、多額の予備費を含むか、後から追加費用が生じやすくなります。 不明点が多い場合は、調査工程を準委任契約（＝作業の遂行に対して報酬を支払う契約）にし、期間と予算上限を設定する方法が適しています。調査後に範囲が明らかになった部分について、改めて固定金額の見積もりを取得します。 ## ブラックボックス化を解消する外注手順 安全な進め方は、「資産の確保、現状調査、優先順位付け、安定化、段階改善」の順です。調査前に大きな改修へ着手すると、想定外の停止やデータ不整合を招く可能性があります。 ### 1. 事業上の重要度と目標を決める 最初に、ブラックボックス化を解消して何を実現したいのかを決めます。目標によって必要な調査範囲が変わるためです。 主な目標には次のようなものがあります。 - 担当者の退職前に引き継げる状態にする - 現在の開発会社への依存を減らす - 新機能を安全に追加できる状態にする - 内製チームが保守できる状態にする - 数年後の刷新に向けて現行仕様を把握する - 障害時の復旧時間を短くする あわせて、停止した場合の影響、代替業務の有無、今後の利用予定年数を整理します。すべてを同じ粒度で調べるのではなく、事業影響の大きい機能から優先するためです。 ### 2. 自社が保有する資産とアクセス権を確保する 外注先へ調査を依頼する前に、可能な範囲で次の情報を集めます。 - ソースコードと保管場所 - サーバー、クラウド、ドメイン、証明書の契約情報 - データベースとバックアップの所在 - 開発環境、テスト環境、本番環境へのアクセス方法 - 外部サービス、API、メール配信、決済などの契約情報 - 過去の設計書、議事録、障害記録、見積書 - リリース手順と作業担当者 - 現在の保守契約と知的財産権の条件 - 社内外の関係者と連絡先 アクセス権限は必要最小限にし、共有アカウントをそのまま渡すのではなく、調査担当者ごとのアカウントを発行します。操作履歴を残せる状態にすることも重要です。 ### 3. 本番環境を変更せずに現状を調査する 初期調査では、原則として本番環境へ変更を加えません。資料、ソースコード、ログ、データ構造、画面動作、関係者へのヒアリングから、次の内容を確認します。 - システム全体の構成と通信経路 - 主要機能と利用部門 - データの登録元、更新処理、出力先 - 外部システムとの連携 - 定期処理、バッチ処理（＝決まった時間や条件でまとめて実行する処理） - 認証、権限、個人情報の扱い - バックアップと復元方法 - 監視項目と障害通知先 - 改修頻度と既知の不具合 - サポート終了技術やセキュリティ上の課題 この工程では、不明点をなくすことだけが目的ではありません。「調べられなかった項目」と「追加調査に伴うリスク」も成果物に含めます。断定できない内容を推測で設計書へ記載すると、新しい誤解が生まれるためです。 ### 4. 対応方針と優先順位を決める 調査結果をもとに、課題を次の3段階に分けます。 1. 直ちに対応する課題：バックアップ不能、重大な脆弱性、契約切れなど 2. 計画的に対応する課題：テスト不足、複雑な処理、属人化したリリースなど 3. 許容する課題：利用終了が近く、改善効果が費用に見合わない箇所 すべての技術的な問題を直す必要はありません。事業への影響、発生可能性、対応費用、今後の利用期間を比較し、対応しない判断も記録します。 ### 5. 文書化と安全装置の整備を先に行う 大きな機能改修の前に、最低限の文書、テスト、監視、バックアップを整えます。これらは変更による問題を早く発見し、元の状態へ戻すための安全装置です。 最低限そろえたい成果物は次のとおりです。 - システム構成図 - 機能一覧と利用部門 - 主要画面・主要データの説明 - 外部連携と定期処理の一覧 - 環境・アカウント・契約の管理表 - リリース手順と切り戻し手順 - 障害時の連絡・判断フロー - バックアップと復元の手順・確認記録 - 重要機能のテスト項目 - 未解決課題と改修時の注意点 運用担当者が参照する資料の構成や更新ルールは、[システム運用マニュアルの作り方｜外注費用と手順](https://www.geek-bridge.com/column/system-operation-manual-outsourcing)でも詳しく解説しています。 ### 6. 小さな変更で検証してから段階的に改善する 資料を作成しただけでは、本当に安全に変更できるかは分かりません。影響の小さい改修を選び、調査、実装、テスト、公開、監視まで一連の流れを実施します。 この試行によって、次の点を確認できます。 - 新しい担当者が資料を使って影響範囲を判断できるか - テスト環境で本番に近い確認ができるか - リリース手順に不足がないか - 問題発生時に元へ戻せるか - 資料を誰がどのタイミングで更新するか 内製化を目指す場合でも、最初から全作業を社員だけで行う必要はありません。社内にシステム責任者を置き、外注先と共同で調査・改修しながら、レビューやリリース判断を徐々に引き継ぐ方法が現実的です。 自社システムの調査範囲や優先順位を整理したい場合は、[開発のご相談はこちら](https://www.geek-bridge.com/#contact)からご相談ください。 ## 見積もりと外注先を比較するポイント 外注先は総額だけでなく、調査方法、納品物、本番環境への配慮、調査後の選択肢で比較します。ブラックボックス化したシステムでは、安い固定見積もりよりも、不明点を明示して段階的に見積もれる会社の方が信頼しやすい傾向があります。 ### 見積書で確認する項目 見積書には、少なくとも次の項目が記載されているか確認してください。 - 調査対象となるシステム、環境、機能 - 対象外となる範囲 - ヒアリングの対象者と回数 - ソースコード、データベース、インフラの調査範囲 - 本番環境に対する作業の有無 - 成果物の名称、内容、更新可能なファイル形式 - 定例報告の頻度と報告方法 - 調査中に重大な問題を発見した場合の連絡方法 - 追加調査が必要になった場合の単価と承認手順 - 納品後の説明会、引き継ぎ、質問対応の範囲 - ソースコードや作成資料の権利と保管場所 「調査一式」のような一行見積もりでは、会社ごとの範囲を比較できません。構成図を作るだけなのか、データの流れや外部連携まで確認するのかによって、成果物の価値は大きく異なります。 調査工程では、時間単価または人月単価だけでなく、予算上限を設定する方法も有効です。例えば、最初の1カ月で重要機能を優先調査し、その結果を見て次の工程を承認する形にすれば、際限なく調査費用が増えることを防げます。 ### 開発会社の見極めチェックリスト ブラックボックス化の解消を依頼する会社には、新規開発とは異なる能力が必要です。次の項目を確認してください。 - 他社が開発したソースコードの調査経験がある - 不明点を推測で埋めず、確認済み・未確認を区別して報告する - 本番環境を調べる際の変更管理とバックアップ方針がある - 調査結果を非エンジニアにも説明できる - 現状維持、部分改修、刷新を中立的に比較できる - ドキュメントだけでなく、テストや復旧確認まで提案できる - 自社が利用している技術やクラウドに対応できる - 資料やソースコードを発注者管理の場所へ保管できる - 社内担当者への知識移転を契約範囲に含められる - 調査後の開発を必須条件にせず、調査だけでも依頼できる 契約前には、担当予定者と面談することをおすすめします。営業担当者の説明が明確でも、実際に調査する技術者が参加しなければ、調査方法やリスク対応の実効性を判断しにくいためです。 ### よくある失敗と回避策 **失敗1：最初から全面刷新を前提にする** 現行システムの不満だけで全面刷新を決めると、必要な機能の見落としや不要な機能の再実装が起こりやすくなります。先に現状調査を行い、廃止できる業務と残すべき業務を分けます。 **失敗2：設計書を作って完了とする** 設計書は作成時点から古くなり始めます。実際の改修で利用し、リリース時に更新する運用まで決めなければ、再びブラックボックス化します。資料ごとに管理責任者と更新タイミングを設定してください。 **失敗3：現在の委託先を排除して調査する** 契約や関係性に大きな問題がなければ、現在の委託先が持つ情報は重要です。責任追及を目的にせず、事実確認と引き継ぎに協力してもらう方が効率的です。ただし、アカウントやバックアップを一社だけに依存した状態は先に見直します。 **失敗4：依存先を別の会社へ移すだけになる** 新しい開発会社だけが仕様を理解し、自社に情報が残らなければ、ブラックボックス化は解消されません。自社名義のアカウント、自社管理のソースコード保管場所、定期報告、資料更新、社内担当者への説明を契約に含めます。 **失敗5：通常運用と並行して無計画に変更する** 調査中の小さな設定変更が障害原因になることがあります。調査と変更を区別し、本番変更には申請、承認、バックアップ、切り戻し、実施記録を必要とするルールを設けます。 ## まとめ - ブラックボックス化とは、資料不足だけでなく、安全な変更方法を組織として説明できない状態です - まずソースコード、環境、アカウント、契約、バックアップなどの資産を確保します - 一般的な現状調査は30万〜300万円程度、文書化や安全装置の整備を含めると100万〜1,000万円以上が目安です - 不明点が多い場合は、調査と改修を分け、調査工程に予算上限を設定します - 全面刷新だけでなく、現状維持、可視化、部分改修、段階刷新を比較します - 設計書に加え、テスト、監視、バックアップ、復旧・リリース手順まで整備します - 外注先は、他社システムの調査経験、本番環境への配慮、成果物、知識移転の方法で選びます - 自社名義のアカウントと自社管理の資料・ソースコードを持ち、別の会社への依存に置き換わることを防ぎます ## よくある質問 ### 設計書やソースコードがなくてもブラックボックス化を解消できますか？ 完全な資料がなくても調査は可能ですが、通常より時間と費用がかかります。まずは本番環境を変更せず、画面・データベース・ログ・実行ファイル・関係者へのヒアリングから現状を復元し、改修可能な範囲を判断します。 ### 現在の開発会社にはいつ伝えるべきですか？ 原則として協力を依頼した方が円滑ですが、その前に自社名義の契約、アカウント、ソースコード、バックアップの保有状況を確認します。関係悪化や停止リスクがある場合は、新しい支援会社や専門家と移行手順を決めてから伝えます。 ### ブラックボックス化したシステムは全面的に作り直すべきですか？ 必ずしも全面刷新が最適とは限りません。事業上重要な機能、障害リスク、今後の利用年数、改修需要を調査し、文書化、部分改修、段階刷新、全面刷新を比較して決めます。 ### 現状調査だけを開発会社へ外注できますか？ 外注できます。むしろ不明点が多い場合は、改修や刷新と分けて現状調査を依頼する方が、見積もりの精度と提案の比較可能性を高められます。調査範囲、納品物、予算上限、調査中の本番変更禁止を明確にしてください。