システムのブラックボックス化とは｜見分け方と担当者がいなくなる前に残すもの

システムのブラックボックス化は、中身を説明できる人が社内に一人しかいない状態から始まります。技術責任者のいない会社の経営者向けに、自社のシステムや業務ツールがそうなっていないかの見分け方と、担当者がいるうちに残しておく説明・手順・所有者・権利関係を、CTO代行の経験からまとめました。

2026年10月23日

執筆者

運営者・AIエンジニア／ IT歴36年以上

要約

システムのブラックボックス化は、中身を説明できる人が社内に一人しかいない状態から始まります。古いシステムだけでなく、最近作った業務ツールやAIで作ったツールでも起きます。
見分けるには、システムごとに「説明できる人は何人いるか」「その人が明日いなくなったら、どれだけ止まり、何が起き、直すのにいくらかかるか」を確かめます。
担当者がいるうちに、何をするシステムか、なぜそう作ったか、作業の手順、所有者、権利関係、バックアップからの戻し方を、社内の決まった場所に残します。

受発注や顧客管理のシステム、見積もりを作るExcelのファイル、社員がAIに作らせた集計のツールを思い浮かべてください。毎日の業務で使っているのに、中身を分かっているのは担当者一人だけ、というものはないでしょうか。技術責任者（CTO）のいない会社では、こうした状態に気づける人がいません。担当者が辞めたり長く休んだりして、初めて問題が表に出ます。

この記事では、自社のシステムや業務ツールが一人しか分からない状態になっていないかを見分ける方法と、担当者がいなくなる前に何を残しておくかをまとめます。見分ける観点と残すものは、私自身が事業の譲渡を打診されたときに確認された点や、資料のないシステムを引き継いだ経験から決めたものです。

システムのブラックボックス化とは何か

システムのブラックボックス化とは、システムが中でどう動いているのか、なぜそう作られているのかを、社内の誰も説明できなくなった状態です。動いてはいても、直し方も、止まったときの戻し方も分かりません。

その手前にあるのが属人化です。属人化とは、仕事のやり方や知識が特定の人に頼りきりになっている状態をいいます。説明できる人が一人だけなら、その人がいなくなった日に、属人化はブラックボックス化に変わります。

経済産業省は、ブラックボックス化をレガシーシステム（古くなり、事業の足かせや高いコストの原因になっているシステム）の問題の1つに挙げています。中小企業では、投資の体力に加え、経営としてのITの理解や人材の不足が目立ちます。

これは古いシステムだけの話ではありません。国の協議会の資料も、メインフレーム（大型の基幹コンピューター）をやめたあとで、再びレガシーになる可能性を指摘しています。去年作ったばかりのツールでも、説明できる人が一人しかいなければ、ブラックボックスになりかけていると考えてください。

なぜ一人しか分からない状態になるのか

多くの場合、怠けた結果ではなく、便利な道具を使いこなした結果として起きます。

職場にExcelが入り始めた頃、使いこなせる社員が関数やマクロ（決まった操作を自動で行わせる仕組み）で、自分専用の見積書を作り込むのを私は見てきました。作った社員が休みや異動でいなくなると、ほかの誰も数式の意味が読めず、どこを直せばよいのかも分からなくなりました。Wordでも同じことが起きています。便利な道具が出ると、人はまず自分のために使います。その工夫は会社の財産にならず、個人の手元に積み上がっていくのです。

今、同じことがAIで起きています。Claude Code（AIに指示して、プログラムや業務用のツールを作らせるサービス）のような道具で、社員が自分の業務ツールを作れるようになりました。ただ、今回作られるのは資料ではなく、仕事の進め方そのものです。本人のパソコンの中だけで動くAIツールは、ほかの人への引き継ぎを考えて作られてはいません。どの社員が、どんな手順でAIに何をさせているのかが周りからは見えず、作った社員が休めば、その業務も止まります。影響はExcelのときより大きいと、私は考えています。

AWS は、インターネット経由でサーバー（データやプログラムを置いて動かすコンピューター）などを貸し出す、Amazon のサービスです。そのAWSが公開している運用の手引きにも、避けるべき例として次の状態が挙げられています。

手順が文書になっておらず、ばらばらのスクリプト（決まった作業を自動で行う短いプログラム）が、担当者個人のパソコンにだけある
スクリプトの使い方を知っているのが数人だけか、チームの中の暗黙の知識になっている
古い手順を見直す時期なのに、誰が見直すのかがはっきりせず、作った本人はもう組織にいない

AWS は、手順ごとに所有者を決めていない場合の危険度を「High」（高い）としています。

自社のシステムがブラックボックスになっていないか、どう見分けるか

見分けるときの基準は、「担当者がいなくなっても事業が回るか」です。

私は日本で、ライブドアから自分の事業の譲渡を打診されたことがあります。そのとき重点的に確認されたのは、システムの権利関係（自社で開発したものか、他社の製品を使う権利を買ったものか）、一部の個人だけが扱える部分の有無、そして将来の拡張性でした。中でも、担当者が抜けても事業を続けられるかという点は、その後の私の組織づくりに大きく影響しました。事業を買う側は、この点を厳しく確かめるのです。

自社のシステムや業務ツールも、同じ観点で見てみましょう。技術用語は要りません。私は技術が分からない経営者に説明するとき、「コスト」「リスク」「時間」の3つの言葉に置き換えています。次の問いに、システムごとに答えてみてください。

確かめること	問い方
説明できる人	このシステムの中身と直し方を説明できる人は、社内に何人いるか
いなくなったとき	その人が明日いなくなったら、どれだけ止まり（時間）、何が起き（リスク）、直すのにいくらかかるか（コスト）
手順の置き場所	日々の操作や、止まったときの対応の手順は、その人の頭やパソコンの外にあるか
権利関係	自社で開発したものか、他社の製品を使う権利を買ったものか
外注先への依存	ベンダー（システムを作って納めた外注先）にしか分からない部分はないか

説明できる人が一人しかいない、手順がその人の手元にしかない、という答えが1つでもあれば、ブラックボックス化の手前にいます。

最後の問いは見落とされがちです。技術責任者のいない会社でよくあるのは、経営者が技術面で妥当かを判断できないまま、外注先の言い値や説明をそのまま受け入れてしまうことです。あとで高すぎる保守（システムが動き続けるよう、不具合を直したり更新したりする作業）の費用や、ほかへ移れないシステムに気づくという形です。社内の誰も分からず、外注先だけが分かっているシステムも、自社から見ればブラックボックスです。システムを分かる社員が一人だけで、その人が辞めた日から誰も対応できなくなった会社も、私は複数見てきました。

AIで作ったツールにも、同じ基準を当てはめます。AIに言葉で指示してツールを作らせるやり方（バイブコーディング）について、私は壊れたときにどれだけ被害が出るかと、内容を理解して説明できる社員がいるかの2点で扱いを決めています。社内の誰も中身を説明できないまま、基幹業務（受注、会計、在庫など、会社の中心になる業務）に組み込むことはしません。AIに作らせてよいものとよくないものの分け方は、バイブコーディングのリスク｜AIに作らせてよいもの・いけないものと、誰が確かめるかの決め方で説明しています。

担当者がいなくなる前に、何を残すか

担当者がいるうちに残しておくものは、何をするシステムか、なぜそう作ったか、作業の手順、所有者、権利関係、バックアップからの戻し方の6つです。どれも、その人がいなくなってからでは聞き出せません。

何をするシステムで、どう組み立てられているか

私自身、開発したシステムでは、画面を形づくる部品の作り（コンポーネント設計）と、API（システム同士がデータをやりとりするための決まりごと）の仕様を文書にしています。担当が替わったとき、次の人が最初に知りたいのは、どこに何があり、ほかのシステムと何をやりとりしているかだからです。

技術者向けの細かい文書から始めなくてもかまいません。GitHub（プログラムを保管・共有するサービス）は、README（プログラムと一緒に置く説明書き）に書く内容の例を挙げています。何をするものか、なぜ有効か、どう使い始めるか、どこで助けを得られるか、誰が管理しているか、の5つです。Excelのファイルや業務ツールでも、まずこの程度の説明を1枚にまとめておくと、引き継ぐ人が最初に迷わずに済みます。

なぜそう作ったのか

ソースコード（プログラムの本文）を読めば、何をしているかは、時間をかければ分かります。しかし、なぜそう作ったのかは、コードからは分かりません。私は、設計の意図と処理の考え方を、よくある質問と答えの形（FAQ）にまとめ、引き継ぎの資料にしています。

「なぜこの項目は手で入力するのか」「なぜ月末だけ別の処理をするのか」のように、あとから来た人が聞きそうな問いを担当者に挙げてもらい、その答えを書いてもらいましょう。

作業の手順（手順書）

日々の操作や、止まったときの対応は、手順書（runbook）にします。AWS によれば、手順書は特定の結果を得るために文書にした手順で、最も簡単なものは作業のチェックリストです。手順を一つずつ書いた文書が1枚あれば、まずは十分です。

AWS が避けるべき例として挙げているのは、記憶に頼って作業を進めること、同じ作業を人によって違う手順で行い結果も違ってしまうこと、システムを変えたのに手順書を直さず、ずれたままにすることです。書いた手順書は、所有者を明記して決まった場所に置き、チームの別の人に実際にその手順で作業してもらって確かめるよう勧めています。

手順を前もって書いておく効果は、障害のときにも表れます。Google によると、対応の手順を事前に記録しておけば、MTTR（障害から復旧までの平均時間）はその場しのぎの対応よりおよそ3倍改善します。

誰が所有者か

システムや手順ごとに、所有者を決めて書いておきます。所有者とは、その内容に責任を持ち、変わったときに直す人です。AWS の手引きは、手順ごとに所有者を決めておくと、新しく入った人が早く仕事をこなせるようになり、チームの間で担当を移すときの影響も小さくできるとしています。GitHub にも、CODEOWNERS というファイルで、プログラムのどの部分に誰が責任を持つかを決めておく仕組みがあります。

所有者を書くときは、作った本人のほかに、中身を説明できる人の名前も書いておきましょう。そこが空欄なら、そのシステムはまだ一人しか分からない状態です。

権利関係

自社で開発したものか、他社の製品を使う権利を買ったものかを書いておきます。事業の譲渡を打診されたときの技術面の確認で、重点的に見られた項目の1つです。担当者がいなくなったあとで、そのシステムを誰が直してよいのか、作り直してよいのかを判断する材料になります。

バックアップからの戻し方

バックアップを取っていることと、そこから戻せることは別です。私がこれまでに経験した中でいちばん大きな障害は、ディスクの故障でした。バックアップを検証していなかったため、元に戻すまでに丸一日以上かかっています。それ以来、バックアップから実際に戻せるかを定期的に試しています。戻し方の手順も、担当者の頭の中ではなく、手順書に残しておきましょう。

残したものを、どこに置くか

置き場所は、社内の誰もが見られる1か所に決めます。AWS は、知識をまとめて置く場所がなく、各自が自分のパソコンでメモを管理している状態を、避けるべき例として挙げています。社内の wiki（社員が書き込んで共有できる、ウェブ上の資料置き場）があっても、情報を管理する仕組みがなければ、中身は古くなっていきます。AWS の資料では、部門をまたいだチームが四半期ごとに、更新されていないページを洗い出し、保管に回すか更新するかを決めている例が紹介されています。

AIで作ったツールも同じです。Claude Code では、プロジェクトの指示を CLAUDE.md というファイルに書くと、バージョン管理（ファイルの変更履歴を残し、前の状態に戻せるようにする仕組み）を通じてチームで共有できます。Claude Code の公式ドキュメントは、このファイルには個人の好みではなく、プロジェクト全体の決まりを書くよう勧めています。共有しない個人の設定は、CLAUDE.local.md という別のファイルに分けます。社員がAIに何をどうさせているのかを、本人のパソコンの外に出しておけるということです。

AIで作業を一つずつ速くするだけでは足りません。社内の誰もが使えるアプリや仕組みに整え、会社全体に広げることが大事だと、私は考えています。便利なツールほど、個人の持ち物のままにせず、会社の仕組みとして活用しましょう。

何から始めるか

最初にすることは、社内のシステムや業務ツールの一覧を作り、今の状態を見えるようにすることです。協議会の資料も、IT資産（会社が持つシステムや機器）の棚卸しと可視化を必須としています。一覧には、前の章の表の問いへの答えを書き込んでいきます。

手順書は、すべてを一度に書こうとしないことです。AWS が最初の手順書に向くとしているのは、ある程度定期的に行い、手順が短く、失敗しても影響が小さい作業です。作る手間も小さく済みます。

他社のシステムを引き継いだあとはどうするか

すでに担当者がいない、あるいは他社が作ったシステムを引き継ぐことになった場合は、何かを直す前に、中身を調べる工程を設けます。

私は以前、資料が一切なく、ソースコードにコメント（プログラムの中に書く、人向けの説明）もほとんどないシステムを引き継いだことがあります。コードを読み解くところから始めるしかありませんでした。それからは、引き継ぎの案件では必ず、何かを直す前に、今の状態を見えるようにするためだけの調査の工程を入れています。調べて分かったことは、この記事で挙げた6つの形で残していきます。資料がない状態からの引き継ぎの進め方は、他社システムの引継ぎで失敗しない進め方｜資料がない状態からの手順で説明しています。

技術を選ぶ段階で防ぐには

これから新しくシステムを作るなら、技術の選び方でもブラックボックス化を防げます。

私が日本でASP（広告主と、広告を掲載するサイトの運営者を仲介する事業）を立ち上げたときは、当時流行していた独自のフレームワーク（システムを作るときの土台になる仕組み）を選びませんでした。あえて、使い古された LAMP構成（Webのシステムで長く使われてきた、定番のソフトの組み合わせ）にしています。扱える人を採用しやすく、資料も多いので、一部の人だけが分かるシステムになりにくいからです。担当者が替わってもシステムが止まることはなく、数年以上運用したのちに事業を売却できました。

外注先から新しい技術を提案されたら、「新しいかどうか」ではなく、「誰でも触れるかどうか」を確認してください。

よくある質問

Q: 担当者が辞める予定はありません。それでも準備は必要ですか。

必要です。辞めなくても、長く休んだり異動したりすれば同じことが起きます。Excelの見積書が誰にも分からなくなったのも、作った社員が休みや異動でいなくなったときでした。担当者がいて、話を聞けるうちが、いちばん残しやすい時期です。

Q: 外注先に任せているシステムでも、社内で何か残す必要はありますか。

あります。外注先しか中身が分からなければ、保守の費用や作り直しの判断を、外注先の言い分のまま受け入れることになります。協議会の資料も、内製化を「ベンダーとの協力体制への移行」と位置づけています。すべてを社内で作るという意味ではなく、外注先に任せきりにしないということです。少なくとも、何をするシステムかの説明、所有者、権利関係は、自社の手元に置いておきましょう。

Q: 手順書を書く時間がありません。何から手をつければよいですか。

定期的に行い、手順が短く、失敗しても影響が小さい作業を1つ選び、手順を一つずつ書くところから始めましょう。AWS は、こうした作業が最初の手順書に向いているとし、手間も小さいとしています。書けたら、担当者以外の人にその手順書だけで作業してもらい、迷ったところを直します。

まとめ

システムのブラックボックス化は、中身を説明できる人が社内に一人しかいない状態から始まります。古いシステムだけでなく、最近作った業務ツールやAIで作ったツールでも起きます。
見分ける基準は「担当者がいなくなっても事業が回るか」です。システムごとに、説明できる人の数、いなくなったときの時間・リスク・コスト、手順の置き場所、権利関係、外注先への依存を確かめましょう。
担当者がいるうちに、何をするシステムか、なぜそう作ったか、作業の手順、所有者、権利関係、バックアップからの戻し方を残します。
残したものは社内の決まった1か所に置きます。AIで作ったツールの指示も、本人のパソコンの外で共有しましょう。
最初の一歩は、社内のシステムと業務ツールの一覧を作り、今の状態を見えるようにすることです。

無料相談のご案内

PH Tech AI は、社内に技術責任者がいない中小企業・スタートアップの、技術の判断と開発体制づくりを支援しています。自社のシステムや業務ツールが一人しか分からない状態になっていないか、担当者がいるうちに何を残しておくべきかを、一緒に整理します。無料でご相談いただけます。まずはお気軽にお問い合わせください。