システムのブラックボックス化の原因と解消方法
「長年使っている基幹システムを改修したいが、どこを直せばよいか誰にも分からない」「見積もりを依頼したら、まず調査に数か月かかると言われた」。こうした状態は、システムのブラックボックス化と呼ばれます。システムは毎日動いているのに、その中身を説明できる人がいないため、改修にも移行にも踏み出せなくなってしまうのです。
この記事では、システムのブラックボックス化とは何か、なぜ起きるのか、放置するとどのような問題が生じるのかを整理し、ブラックボックスを解消するための具体的な進め方と、再発を防ぐ仕組みづくりまでを解説します。
- ブラックボックス化とは、システムの中身や仕様を誰も正確に説明できない状態のこと
- 主な原因はドキュメント不足・担当者の退職・場当たり的な改修の積み重ね
- 解消は「現状調査→可視化→方針決定」の順に進め、いきなり作り直さない
- 再発防止には、改修のたびに資料を更新するルールと契約上の取り決めが欠かせない
目次
システムのブラックボックス化とは？
システムのブラックボックス化とは、システムが「どのような仕組みで」「どのようなルールで」動いているのかを、社内でも保守会社でも正確に説明できる人がいない状態のことです。入力すれば結果は出てくるものの、その間でどんな処理が行われているのかが見えないため、箱の中が見えない「ブラックボックス」にたとえられています。
経済産業省が2018年に公表した「DXレポート」でも、既存システムの複雑化・ブラックボックス化が、企業のデジタル化を妨げる大きな要因として指摘されました。これは大企業だけの問題ではなく、中小企業の業務システムでも同じように起きています。
ブラックボックス化の度合い
| 段階 | 状態 | 改修への影響 |
|---|---|---|
| 軽度 | 設計書は古いが、分かる担当者が在籍している | 担当者に聞けば対応できる |
| 中度 | 設計書がなく、一部の機能だけ分かる人がいる | 改修のたびに調査が必要 |
| 重度 | 設計書も分かる人もなく、ソースコードだけが残る | 小さな修正にも時間と費用がかかる |
| 最重度 | ソースコードすら手元にない | 改修は困難で、再構築が前提になる |
ブラックボックス化が起きる主な原因
ブラックボックス化は、ある日突然起きるものではありません。日々の運用の中で少しずつ進行していきます。
特に見落とされやすいのが最後の「業務ルールの埋め込み」です。たとえば「特定の取引先だけ締め日が違う」「一定金額以上は承認が必要」といったルールが、業務マニュアルには書かれず、プログラムの中にだけ残っていることがあります。こうなると、システムを理解しないと業務そのものを説明できないという状態になります。
ブラックボックス化を放置するとどうなるか
ブラックボックス化したシステムを放置すると、次のような問題が起き、時間とともに深刻になっていきます。
さらに、現在の保守会社しか中身を分からない状態だと、費用交渉や体制変更の選択肢が狭まります。開発会社の撤退や担当者の退職が重なると、システムを誰も触れなくなる恐れもあります。
関連記事開発会社が倒産・撤退したらシステムはどうなる？対処法
ブラックボックス化を解消する進め方
ブラックボックスを解消するというと、「新しいシステムに作り直す」ことを想像しがちですが、中身が分からないまま作り直すと、必要な機能やルールが抜け落ちて失敗する原因になります。まずは現状を見える形にすることから始めます。
- 資産の棚卸しソースコード、設計書、サーバー構成、アカウント、関係する外部サービスなど、手元にあるものを一覧にする
- 現状調査（解析）ソースコードやデータベースを解析し、画面・機能・データ構造・外部連携を洗い出す
- 業務ルールの抽出プログラムに埋め込まれた計算ルールや例外処理を洗い出し、業務担当者と照らし合わせる
- ドキュメントの作成機能一覧、画面遷移、データ項目定義など、最低限の資料を整備する
- 方針の決定保守を続けるのか、部分的に作り直すのか、全面的に刷新するのかを判断する
方針の選び方
| 方針 | 向いているケース |
|---|---|
| ドキュメント整備して保守継続 | システムが業務に合っており、技術的にもまだ使える |
| 部分的な作り直し | 一部の機能だけが複雑で、問題が集中している |
| 全面的な刷新（リプレイス） | 技術が古く、業務にも合わなくなっている |
現状調査には、システムの規模によって1〜3か月程度かかるのが一般的です（目安）。一見遠回りに見えますが、この調査結果は刷新する場合の要件定義の材料にもなるため、無駄にはなりません。
再びブラックボックス化させないための仕組み
一度解消しても、運用の仕方が変わらなければ、数年後にまた同じ状態に戻ってしまいます。再発防止には、次のような仕組みを取り入れることが効果的です。
- 改修時の資料更新をルール化：改修のたびに設計書や機能一覧を更新することを、保守契約の作業範囲に含める
- ソースコードを自社で管理：最新のソースコードを自社が管理する保管場所に置き、変更履歴を残す
- 発注者側の窓口を育てる：システムの全体像を説明できる社員を、少なくとも1人は置く
- 業務ルールを文書化：システムに組み込んだルールを、業務マニュアル側にも記載する
- 定期的な棚卸し：年に1回程度、資料と実際のシステムにずれがないかを確認する
また、保守会社を変更する予定がなくても、「別の会社が引き継げる状態か」を基準に資料の充実度を確認しておくと、ブラックボックス化の兆候に早く気づけます。引き継ぎに必要な資料がそろっていれば、保守会社との関係が対等に保たれ、費用や対応品質についての相談もしやすくなります。
よくある質問
- ブラックボックス化したシステムは作り直すしかないのでしょうか？
- 必ずしもそうではありません。ソースコードが残っていれば、解析して資料を整備することで、保守を続けられる場合も多くあります。まずは現状調査を行い、保守継続・部分改修・全面刷新のどれが適切かを判断しましょう。
- 現状調査にはどれくらいの費用と期間がかかりますか？
- システムの規模や資料の残り具合によりますが、期間はおおむね1〜3か月程度が目安です。費用は調査範囲によって変わるため、まずは対象範囲を絞って見積もりを取るのがおすすめです。
- ブラックボックス化を防ぐために、発注者が最低限やるべきことは何ですか？
- ソースコードと設計書を自社で保管すること、改修のたびに資料を更新してもらうことの2点です。これを保守契約の作業範囲に明記しておくと、確実に実行されやすくなります。
まとめ
システムのブラックボックス化は、ドキュメント不足や担当者の退職、場当たり的な改修の積み重ねによって少しずつ進行します。放置すると、改修費用の増加や障害時の復旧遅れ、保守会社の変更困難といった問題が深刻になります。解消するには、いきなり作り直すのではなく、資産の棚卸しと現状調査で中身を見える化し、そのうえで方針を決めることが大切です。そして、資料更新のルール化とソースコードの自社管理で、再発を防ぎましょう。
この記事に関連するサービス
システムリプレイス
老朽化したシステムやサポートが終わるシステムを新しく置き換えます。仕様書がないシステムも、画面・データ・プログラムの解析から対応し、段階的な移行で業務を止めずに切り替えます。 サービスの詳細を見る
