仕様書がなく、作った人もいない「ブラックボックス化したシステム」の現状は、ソースコード、データ、利用者という三つの情報源を組み合わせることで、かなりの部分まで復元できます。どれか一つだけに頼ると必ず抜けが出ますが、三つを突き合わせれば「システムが実際に何をしているか」「業務がシステムに何を期待しているか」「その二つのずれはどこか」が見えてきます。そこまで把握できれば、改修を続けるにしても、作り直すにしても、確かな前提のうえで判断できるようになります。
ブラックボックス化の解消というと、すべての仕様書を一から作り直す大がかりな作業を想像するかもしれません。しかし実務で必要なのは、完璧な設計書ではなく、次の判断に使える粒度の現状把握です。リプレイスの見積もりを取るためなのか、保守会社を乗り換えるためなのか、障害対応を属人化させないためなのか、目的によって調べるべき深さは変わります。目的を決めずに調査を始めると、時間ばかりかかって成果物が使われないという結果になりがちです。
この記事は、仕様の分からない社内システムや自社サービスを抱えて、作り直しや保守体制の見直しを考えている事業責任者や情報システム担当者に向けて書いています。ブラックボックス化が起きる理由、現状把握の進め方、ソースコード・データ・利用者それぞれからの調べ方、成果物の形、よくある失敗を順に整理します。
システムがブラックボックス化する理由
ブラックボックス化は、誰かの怠慢というより、長く使われるシステムに自然に起きる現象です。理由を知っておくと、調査で何を重点的に見るべきかが分かります。
最も多いのは、改修の記録が残らないことです。最初の開発時には設計書が作られていても、その後の改修は急ぎの対応として行われ、設計書の更新が追いつきません。数年たつと、設計書と実際の動きが別物になり、誰も設計書を信用しなくなります。
次に多いのは、担当者の交代です。社内の担当者や開発会社の担当者が入れ替わるたびに、口頭で伝えられていた知識が少しずつ失われます。特に「なぜこうなっているのか」という理由は文書に残りにくく、残った人は「触ると怖いから触らない」状態になります。
三つ目は、システムの外側で業務が変わることです。現場がシステムの不足をExcelや手作業で補い、その運用が当たり前になると、システムの本来の使い方と実際の使い方がずれていきます。この場合、ソースコードを読んでも業務の実態は分かりません。
現状把握の目的と調査範囲を先に決める
調査に入る前に、何のために現状を把握するのかを決めます。目的によって必要な成果物と深さが変わるからです。
| 目的 | 必要な成果物 | 調査の深さ |
|---|---|---|
| リプレイスの判断・見積もり | 機能一覧、データ一覧、外部連携一覧、非機能の現状 | 機能の有無と規模感が分かる程度 |
| リプレイスの要件定義 | 上記に加え、業務ルール、計算式、例外処理の一覧 | 一つひとつの処理の中身まで |
| 保守会社の乗り換え | 構成図、運用手順、障害対応の履歴、デプロイ手順 | 日々の運用を引き継げる程度 |
| 障害対応の属人化解消 | 構成図、監視の設定、よくある障害と対処手順 | 障害時に動ける程度 |
| セキュリティの点検 | 利用している部品とバージョン、アクセス権限、通信経路 | 弱点の有無が分かる程度 |
目的が複数ある場合も、まず一つに絞って小さく始め、成果物を使いながら範囲を広げていくのが現実的です。保守会社の乗り換えを目的とする場合の引き継ぎ資料については、保守会社を乗り換える手順も参考にしてください。
現状把握の進め方：全体の手順
ブラックボックス化したシステムの現状把握は、次の順番で進めると効率的です。外側から内側へ、広く浅くから狭く深くへ、という流れを意識します。
- 環境の把握：システムがどこで動いているか（サーバー、クラウド、ドメイン、契約）、誰が管理者権限を持っているかを確認する。
- 構成の把握：画面、データベース、バッチ処理、外部連携、ファイルの置き場所など、システムを構成する要素を洗い出して構成図にする。
- 利用実態の把握：誰がどの画面をどのくらい使っているかを、アクセスログと聞き取りで確認する。
- 機能一覧の作成：画面、帳票、処理、連携を一行ずつ一覧にし、利用状況と重要度を書き込む。
- データの把握：主要なテーブルの意味、件数、関係、データの品質を確認する。
- 業務ルールの復元：重要な機能について、計算式、条件分岐、例外処理をソースコードから読み取り、業務担当者と確認する。
- 成果物の整理と検証：まとめた資料を関係者でレビューし、抜けや誤りを直す。
最初の環境の把握は軽視されがちですが、実は最も重要な工程の一つです。サーバーの契約者が退職者の個人名義になっている、ドメインの更新先が分からない、管理者のパスワードを誰も知らない、といった問題は珍しくなく、これらは調査より先に解消すべきリスクです。
ソースコード・データ・利用者の三方向から仕様を復元する
手順のうち、機能一覧の作成と業務ルールの復元では、三つの情報源を使い分けます。ソースコードは「システムが何をできるか」、データとログは「実際に何が行われてきたか」、利用者は「業務として何が必要か」を教えてくれます。それぞれの得意と不得意を理解し、一つの情報源で分かったことを別の情報源で確かめる姿勢が、正確な現状把握につながります。
| 情報源 | 分かること | 分からないこと |
|---|---|---|
| ソースコード | 処理の流れ、計算式、条件分岐、連携先 | その処理が今も必要か、なぜそうなっているか |
| データとログ | 利用頻度、データの量と品質、使われ方の傾向 | 処理の意図、システムの外で起きていること |
| 利用者 | 業務の目的、例外の扱い、システム外の作業 | 処理の正確な中身、本人が意識していない動き |
ソースコードから仕様を読み解く
ソースコードは、システムが「実際にどう動くか」を知るための最も正確な情報源です。ただし、すべてを読み込むのは現実的ではないため、読む順番と深さを決めて取り組みます。
最初に確認するのは、ソースコードの全体像です。使われている言語とフレームワーク、ディレクトリの構成、ファイルの数、外部ライブラリの一覧とバージョンを把握します。ここで、サポートが切れた部品や、すでに入手できないライブラリが見つかることもあります。また、本番で動いているコードと手元にあるコードが一致しているかも確認してください。本番サーバー上で直接修正され、管理されているコードと食い違っているケースは少なくありません。
次に、画面やURLの一覧からたどって、主要な処理の入り口を特定します。利用頻度の高い機能、お金や在庫に関わる機能、外部にデータを送る機能から優先して読み、処理の流れと業務ルールを書き出していきます。
近年は、AIを使ったコード解析も現状把握の有力な手段になっています。ソースコードをAIに読ませて、処理の概要、関数ごとの役割、データの流れを要約させると、人が一から読むよりも短い時間で全体像をつかめます。ただし、AIの要約には誤りが含まれる可能性があるため、重要な業務ルールは必ず人がコードと実際の動きで確認してください。AIは調査の速度を上げる道具であり、確認の責任まで任せられるものではありません。
ソースコードから読み取った内容は、利用者の言葉に置き換えて記録します。「status が 3 のとき」ではなく「出荷済みの注文のとき」と書くことで、業務担当者が内容を確認できる資料になります。
データとログから実態をつかむ
データベースには、システムがどのように使われてきたかの記録が残っています。ソースコードが「できること」を示すのに対し、データは「実際に行われてきたこと」を示します。
まず、テーブルの一覧と件数を出し、それぞれが何を表しているかを推測します。テーブル同士の関係を図にしたER図を作ると、データの全体像が把握しやすくなります。データベースから自動で図を生成するツールもあるため、最初のたたき台は機械的に作り、意味づけを人が加えていくと効率的です。
次に、データの中身を見ます。使われていない項目、想定外の値が入っている項目、同じ意味の項目が複数ある箇所などを確認します。たとえば「備考」欄に特定の書式で情報が書き込まれている場合、それはシステムに足りない機能を現場が補っている痕跡です。こうした発見は、新しいシステムで追加すべき機能の手がかりになります。
アクセスログや操作ログが残っていれば、画面ごとの利用頻度や、利用が集中する時期を確認します。直近一年間で一度も使われていない機能は、リプレイスの対象から外す有力な候補です。ただし、年に一度だけ使う処理もあるため、ログの期間が短い場合は聞き取りで補います。
データを調べる際は、本番データベースを直接触らず、コピーした環境で作業するのが原則です。個人情報や機密情報が含まれる場合は、調査に関わる人と扱いのルールを事前に決めてください。
利用者ヒアリングで業務の実態を補う
ソースコードとデータだけでは、「なぜその機能があるのか」「システムの外で何が起きているのか」は分かりません。そこを補うのが利用者へのヒアリングです。
ヒアリングは、部署や役割ごとに行い、次のような質問を用意しておくと話が具体的になります。
- 一日、一週間、一か月、一年の中で、このシステムを使う場面はいつですか
- システムから出したデータを、そのあと手で加工していますか
- システムに入らない情報を、別のファイルや紙で管理していますか
- 「この操作をするときは必ずこうする」という決まりごとはありますか
- システムが止まったら、どの業務が一番困りますか
- 逆に、なくなっても困らない画面や帳票はありますか
ヒアリングでは、口頭の説明だけでなく、実際の操作を見せてもらうことが効果的です。担当者が無意識に行っている手順や、画面の外で開いているExcelファイルなど、説明では出てこない情報が見つかります。可能であれば、画面を共有してもらいながら一連の業務を最初から最後まで通してもらってください。
ヒアリングで得た情報は、ソースコードとデータから作った機能一覧と突き合わせます。利用者が「使っている」と言う機能がログにない、逆にログでは頻繁に使われているのに誰も言及しない、といった食い違いは、さらに確認すべきポイントです。食い違いを一つずつ解消していく過程で、業務とシステムのずれが具体的に見えてきます。このずれこそが、作り直しの際に最も価値のある改善のヒントになります。
成果物の形：どこまで文書にするか
現状把握の成果物は、目的に合わせて必要なものだけを作ります。リプレイスの前提を作る場合、次の文書があれば十分なことが多いでしょう。
- システム構成図：サーバー、データベース、外部サービス、連携の流れを一枚で示したもの
- 機能一覧：画面・帳票・バッチ処理・外部連携を一行ずつ並べ、利用頻度と重要度を書き込んだもの
- データ一覧：主要なテーブルの意味、件数、主な項目、品質上の問題を書いたもの
- 業務ルール一覧：重要な計算式、条件分岐、例外処理を業務の言葉で書いたもの
- 運用作業一覧：定期的な手作業、障害時の対応、システムの外で補っている作業
- 課題一覧：調査中に見つかったリスク、不明点、確認待ちの事項
従来の仕様書のように細かな形式を整える必要はありません。表計算ソフトや共有ドキュメントで、誰でも更新できる形にしておくほうが、その後の改修やリプレイスで使い続けやすくなります。大切なのは、作って終わりにせず、今後の改修のたびに更新するルールを決めておくことです。
具体的な場面の例：退職者が作った在庫管理システム
架空の一般例として、ある小売業の会社で、社内のエンジニアが十年ほど前に作った在庫管理システムが使われ続けている場面を考えます。そのエンジニアはすでに退職しており、設計書は残っていません。動作が遅くなってきたため作り直しを検討したものの、開発会社からは「現行の仕様が分からないので見積もれない」と言われてしまいました。
この会社は、まずサーバーの契約と管理者権限を確認し、退職者の個人アカウントで管理されていた設定を会社のアカウントに移しました。次に、ソースコードをAIで要約して画面と処理の一覧を作り、データベースから自動生成したER図に意味づけを加えました。アクセスログを確認すると、画面の半分近くが一年以上使われていないことが分かりました。
さらに、倉庫と店舗の担当者にヒアリングを行い、実際の操作を見せてもらったところ、棚卸しの差異を調整するために毎月Excelで集計し直している作業が見つかりました。これは、システムが返品の扱いを正しく処理できていないことが原因でした。
こうして作った機能一覧、データ一覧、業務ルール一覧、課題一覧を開発会社に渡したことで、見積もりの前提が揃い、複数社の提案を比較できるようになりました。調査に数週間をかけたことで、リプレイスの範囲を必要な機能に絞り込むこともできています。
ブラックボックス解消でよくある失敗と避け方
目的を決めずに網羅的な仕様書を作ろうとする。 時間がかかるうえ、完成するころには一部が古くなっています。目的に必要な成果物だけを作り、使いながら広げてください。
ソースコードだけを見て仕様を決める。 コードは「何をしているか」は示しても、「それが正しいか」「本当に必要か」は示しません。業務担当者との確認を必ず挟みます。
本番環境で直接調査する。 データの誤更新やシステムの停止につながります。調査はコピーした環境で行い、本番への接続は読み取り専用の権限に限定してください。
管理者権限や契約の確認を後回しにする。 調査より先に、サーバー・ドメイン・外部サービスの契約者と管理者を会社のものにしておく必要があります。担当者が急に不在になってからでは手遅れになることがあります。
調査結果を一人の担当者が抱え込む。 調査そのものが新たな属人化を生んでは意味がありません。成果物は共有の場所に置き、複数人でレビューします。
現状把握のチェックリスト
- 現状把握の目的と、必要な成果物を決めている
- サーバー、ドメイン、外部サービスの契約者と管理者権限を会社として把握している
- 本番で動いているソースコードと管理しているソースコードが一致しているかを確認した
- 使用している言語、フレームワーク、主要ライブラリとそのバージョンを一覧にした
- 画面・帳票・バッチ処理・外部連携の機能一覧がある
- 主要なテーブルの意味と関係を図にした
- アクセスログや操作ログで、機能ごとの利用状況を確認した
- 部署・役割ごとに利用者ヒアリングを行い、実際の操作を見た
- システムの外で補っている作業を洗い出した
- 重要な業務ルールを、業務担当者と確認した
- 調査中に見つかったリスクと不明点を課題一覧にまとめた
- 成果物を共有の場所に置き、更新のルールを決めた
よくある質問
Q. ソースコードが手元にない場合はどうすればよいですか？
まず、過去の開発会社やサーバーの管理者にソースコードの所在を確認し、契約上の権利も確かめます。どうしても入手できない場合は、画面の操作、データベース、出力されるファイル、ログから外側の振る舞いを記録し、それを要件として作り直すことになります。この場合、細かな業務ルールの再現には利用者との確認がより重要になります。
Q. 現状把握にはどのくらいの期間がかかりますか？
システムの規模、ソースコードやデータの状態、ヒアリングできる人の数によって大きく変わります。目的を一つに絞り、まず機能一覧と構成図までを作ってみると、残りの作業量の見通しが立ちます。
Q. 現状把握を開発会社に依頼してもよいですか？
依頼することは可能で、リプレイスの前段として調査だけを先に発注する進め方は有効です。その場合も、業務ルールの確認や利用者ヒアリングの調整は発注側の協力が欠かせません。成果物の著作権や利用の範囲は、契約時に確認しておきましょう。
Q. 現状を把握したあと、何を判断すればよいですか？
改修を続けるか、部分的に置き換えるか、全面的に作り直すかを判断します。判断の基準はシステムを作り直すべきタイミング：改修とリプレイスの判断基準で整理しています。作り直す場合の進め方はシステムリプレイスの進め方をご覧ください。
Otsumuに相談できること
システムの規模が小さく、社内にソースコードを読める担当者がいて、業務担当者の協力も得られる場合は、この記事の手順に沿って自社で現状把握を進められます。目的を一つに絞り、構成図と機能一覧から始めれば、外部に頼まなくても次の判断に必要な材料は揃うことが多いでしょう。
一方で、ソースコードを読める人が社内にいない、データの量や連携先が多い、調査と並行して日々の運用も回さなければならない、といった状況では、外部の力を借りたほうが短期間で確かな現状把握ができます。調査の質は、その後のリプレイスの見積もりと品質に直結するからです。
Otsumuは、ソースコード・データ・利用者の三方向からの調査を、AIを活用したコード解析と組み合わせて短期間で進め、リプレイスや保守体制の見直しに使える成果物にまとめます。調査から作り直し、運用・改善までを一気通貫で支援することもできます。進め方はシステムリプレイスのページで紹介しています。費用は対象範囲に応じて個別にお見積もりします。
どこから手をつければよいか分からない段階でも構いません。30分の無料相談で、いまのシステムの状況をお聞かせください。
この記事について
Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。
執筆：Otsumu株式会社 ／ 編集日 2026.10.01