「このシステムが何をしているか、聞ける人間がいない」「改修しようとしたら、担当ベンダーに『ソースコードの内容はこちらでも把握しきれていない』と言われた」「障害が起きたとき、何が原因か突き止めるのに3日かかった」——これらは、基幹システムのブラックボックス化が深刻な段階に達したときに起きる典型的な出来事です。本記事では、システムがブラックボックス化する経緯、担当者退職後に何が起きるか、今から取れる対策5選を整理します。
『自社の基幹システム、中身を説明できる人が限られている』とお悩みですか？ 25 年の経験でリスク診断と対策を一緒に整理します。 無料相談 ＞システムのブラックボックス化とは？｜定義と「業務のブラックボックス化」との違い
システムのブラックボックス化とは、「基幹システムの処理内容・設計・業務ロジックが組織内で把握されておらず、なぜそう動くのか誰も説明できない状態」です。
| 種類 | ブラックボックスになっているもの | 主な原因 |
|---|---|---|
| 業務のブラックボックス化 | 業務手順・判断基準・例外処理のルール | 担当者の暗黙知・マニュアル不整備 |
| システムのブラックボックス化 | プログラムの処理内容・データ構造・システム間連携 | ドキュメント不整備・長年の改修・COBOL/古い言語 |
業務のブラックボックス化は「人の頭の中」にある問題ですが、システムのブラックボックス化は「コードの中」にある問題です。担当者が退職しても「コードは残る」のに「誰もコードを理解できない」という、ある意味で業務のブラックボックス化より深刻な状況を生み出します。
基幹システムがブラックボックス化する3つの経緯
経緯 1：長年の改修による「継ぎ接ぎ」の積み重ね
システムは最初に作られた設計から、法改正・業務変更・機能追加のたびに改修が加えられます。「急いでいたからドキュメントを更新しなかった」「ちょっとした修正だからコメントを書かなかった」という判断が何百回と積み重なった結果、「コードは最新だが、なぜその処理になったかの背景を誰も知らない」という状態になります。
経緯 2：COBOL・古いプログラミング言語による可読性の低さ
COBOLや古いRPG・VBAなどで書かれたシステムは、現代のプログラマーが読んでもロジックを理解しにくい設計になっています。さらに、これらの言語を理解できる技術者が市場から減少しており、「コードを読める人自体がいない」という状況に陥ります。
経緯 3：外注先の変更・廃業による設計情報の喪失
システム開発を委託した外注先が廃業・事業縮小・担当者交代により、「このシステムの詳細を知っているのはもういない」という状況になります。外注先に設計書・仕様書を保管していた場合、その外注先が廃業すると設計情報が失われます。
基幹システムがブラックボックス化するとどうなる？
ブラックボックス化が進んだ基幹システムで起きる具体的な問題を整理します。
| 状況 | 具体的な事象 | 経営コスト |
|---|---|---|
| 障害が発生したとき | 原因の特定に数日かかる。「何を直せば治るか」が分からない | 業務停止の機会損失＋緊急対応費：数百万円/回 |
| 改修が必要なとき | 「ここを変えると他のどこに影響するか分からない」という恐怖で改修できない | 改修見送りによる機会損失・法改正対応遅延 |
| 移行プロジェクトを始めるとき | 「現行システムが何をしているか」を解析する工程が必要になり、費用・期間が増大 | 移行費用が通常の1.5～2倍に増大 |
| 担当者が退職したとき | 「このシステムのことを聞ける人間がいない」状態で運用が続く | 次の障害が起きたときの対応コストが青天井 |
今から取れる対策5選
対策① 現行システムの棚卸し（今すぐ・費用ゼロ）
稼働中のシステムの一覧・構築年・担当者・設計書の有無・最終更新年を表にまとめます。「設計書がない・10年以上更新されていない」システムがブラックボックス化候補です。情シスが1～2週間で完了できます。
対策② 担当者へのヒアリング・ドキュメント化（今すぐ着手・50万～300万円）
システムを熟知した担当者が在籍しているうちに、「このシステムは何をしているか」「なぜこの処理になっているか」をヒアリングして文書化します。担当者が退職した後では不可能になる対策のため、最優先で実施してください。
対策③ ソースコード解析・リバースエンジニアリング（300万～1,500万円）
担当者がいない場合、COBOLコード等を解析して処理フロー・データ構造を文書化します。AIツールを活用することで工数を30～50%削減できるケースがあります（詳細はCOBOLソースコード解析の記事参照）。担当者在籍中のヒアリング（対策②）より費用がかかるため、可能な限り②を優先してください。
対策④ 設計書・仕様書の整備・更新ルールの確立
「改修したら設計書も更新する」というルールを組織として定着させます。「改修はするが設計書は更新しない」という習慣が、ブラックボックス化の最大の原因です。改修承認のフローに「設計書更新の確認」を組み込むことが最も効果的です。
対策⑤ 基幹システムの刷新（根本解決）
ブラックボックス化が深刻なシステムは、解析・文書化よりも「新しいシステムに刷新する」方が長期的なコストが安いケースがあります。特に、構築から20年以上経過・COBOLで書かれている・担当者がいないという状況が重なる場合は、刷新を本格的に検討してください。費用目安：3,000万～2億円（規模・手法次第）。
対策を進める上での失敗パターン
失敗：「移行してからドキュメントを整備する」という発想
「今のシステムのドキュメントは古いままでいい。新システムを作れば解決する」という考えは危険です。現行システムの業務ロジックが分からないままでは、新システムの要件定義ができません。移行プロジェクトの要件定義で「現行システムのリバースエンジニアリング」という工程が必要になり、費用・期間が大幅に増加します。
失敗：担当者退職後にリバースエンジニアリングを依頼した
「コードを読めば分かるだろう」という期待でリバースエンジニアリングを依頼しても、コードから「なぜその処理になっているか」の理由（ビジネスロジックの背景）は読み取れません。担当者在籍中にヒアリングで得られた情報は、退職後には永遠に失われます。
まとめ｜「動いているシステム＝安全なシステム」ではない
- システムのブラックボックス化とは：「処理内容・設計・業務ロジックが誰にも分からない状態」。業務のブラックボックス化より深刻なケースが多い
- 発生の3経緯：長年の改修による継ぎ接ぎ・COBOL等の可読性の低さ・外注先の廃業/変更
- 放置した場合：障害対応コスト青天井・改修できない・移行費用1.5～2倍・担当者退職で詰み
- 対策5選：①棚卸し（費用ゼロ）②担当者ヒアリング（最優先）③ソースコード解析④設計書更新ルール確立⑤システム刷新（根本解決）
業務レベルのブラックボックス化については、業務がブラックボックス化する原因と解消の4ステップのガイドをご参照ください。COBOL・メインフレームのソースコード解析については、COBOLソースコード解析のガイドも合わせてご覧ください。
株式会社クオンツでは、『基幹システムのブラックボックス化診断』『担当者ヒアリング・ドキュメント化支援』『ソースコード解析から移行計画立案まで』のご相談を、無料で受け付けています。汎用機・オフコンからオープン系・クラウド基盤への移行プロジェクトに 25 年携わってきた経験から、貴社の規模・業種・システム状況に合わせた現実解を一緒に整理します。机上のコンサルではなく、お客様の現場と並走するスタイルで、次の一歩の選択肢を整理します。
