製造業の基幹システムがブラックボックス化したときの対処法｜見える化から保守体制見直しまでの実践ステップ【2026年版】
「このシステム、今は動いているけど、何をしているか誰も説明できない」。製造業の基幹システムを長年運用していると、そんな状態に陥ることがあります。いわゆるブラックボックス化です。
「動いているうちは問題ない」と思いがちですが、ブラックボックス化した基幹システムは、障害が起きたときの対応コスト・復旧時間を増大させ、保守ベンダーの変更やシステム刷新をも困難にします。本記事では、基幹システムのブラックボックス化が起きる原因と、情シスが取るべき対処ステップを、いきなりの全面リプレイスではなく「見える化」から着手する現実的な方法で解説します。
目次
想定読者
本記事は、次のような方を対象に書いています。
- 工場の基幹システム（受発注・在庫・生産管理・原価管理等）を長年同一ベンダーで保守しており、「中身を知っている人がいない」状態になっている情シス担当者
- ベンダーロックインを感じており、ベンダー変更やシステム刷新を検討しているが、どこから手を付けてよいか分からない方
- 担当者の異動・退職でノウハウが失われており、属人化・ブラックボックス化の解消を急いでいる方
ブラックボックス化とは何か：4つの典型状態
「ブラックボックス化した」と言っても、その深刻さには段階があります。自社のシステムがどの状態にあるかを確認してみてください。
レベル1：ドキュメントが古い・実態と不一致
設計書や仕様書は存在するが、実際の動作と一致していない。改修を重ねるたびにドキュメントが更新されなくなり、実態と乖離が生じている状態。担当者が変われば説明に時間がかかるが、根気よく調べれば対処できる。
レベル2：ドキュメントが存在しない
仕様書・設計書・DB定義書が紛失または最初から作られていない。ソースコードと担当者の記憶だけで運用が続いている状態。改修のたびに「触ると何に影響するか分からない」という状況が発生しやすい。
レベル3：詳しい人がいなくなった
設計を知っている社内担当者やベンダー担当者が異動・退職し、誰も詳しい説明ができない状態。レガシー言語（COBOL、AS/400のRPG、VB6など）で書かれており、読める技術者がベンダー内でも限られている。
レベル4：完全な依存状態（ブラックボックスの最深部）
ソースコードさえ自社で保有しておらず、現ベンダー以外は一切触れない状態。契約や慣例で「現ベンダー以外に見せられない」となっていたり、著作権の帰属が不明確になっていたりする。改修の見積もりを断れず、料金交渉もできない典型的なベンダーロックイン状態。
なぜブラックボックス化が進むのか：製造業特有の背景
長年の改修の積み重ね
製造業の基幹システムは、工場の変化（製品追加、ライン変更、販売先の仕様変更等）に合わせて、少しずつ改修が加わります。その際、「とりあえず動くようにした」「設計書を更新する時間がなかった」という判断が積み重なり、気づいたときには設計書と実態の乖離が大きくなっています。
ベンダー担当者の入れ替わり
5〜10年以上の長期契約の中で、ベンダー側の担当者が複数回入れ替わります。引き継ぎが不十分なまま担当が変わるたびに、「設計の背景」や「なぜこの実装にしたか」という文脈が失われていきます。
レガシー技術と人材の不足
COBOL、RPG（AS/400）、PL/I などのレガシー言語は、現在の新卒エンジニアが学ぶ機会が少なく、対応できる人材が年々減少しています。「詳しい人が高齢で、退職が近い」という状態が、ブラックボックス化のリスクを一気に高めます。
「動いているから触らない」という文化
製造業では、動いているシステムを変えることへの心理的ハードルが高い場合があります。「触って壊したら生産に影響する」という懸念から、必要最低限の改修しか行わず、整備が後回しになりやすい環境があります。
放置するとどうなるか：具体的なリスク
障害時の復旧が長期化する
ブラックボックス化したシステムで障害が発生すると、原因の特定に時間がかかります。ログを読める人が限られており、「どのバッチが何に影響しているか」が分からないため、最悪のケースでは数時間〜数日の生産停止につながることもあります。
改修コストとリードタイムが膨らむ
「ここを変えると何に影響するか分からない」ため、小さな改修でも大規模なテストが必要になります。見積もりが増大し、納期が延び、現場の要望に追いつかないという悪循環が生まれます。
保守ベンダー変更が困難になる
他社に保守を移そうとしても、ドキュメントがなく、現ベンダーしか知識を持っていないため、引き継ぎ先を見つけられない状態に陥ります。「変えたくても変えられない」というロックインが完成します。
担当者が「人質」になる
社内・ベンダー問わず、「このシステムを知っている唯一の人」が退職や異動をすると、その時点でリスクが顕在化します。「その人に頼み込む」「高額な引き留め」が発生するケースも現実に存在します。
対処の基本方針：「一気に直さず、見える化から」
ブラックボックス化を解消しようとして、よくやってしまう失敗が「いきなりの全面リプレイス」です。見える化されていないシステムを全面的に作り直そうとすると、影響範囲が読めないため工数・コスト・リスクが膨らみ、プロジェクトが頓挫するケースが多くあります。
現実的な対処の順番は次のとおりです。
- 重要度と影響範囲を把握する（スコーピング）
- 現状の「見える化」（ドキュメント整備）
- 保守体制の見直し（継続か変更か）
- 段階的なモダナイズ（必要に応じて）
対処ステップ1：重要度と影響範囲の把握（スコーピング）
まず、どのシステム（または機能）が「ブラックボックス化している」かを一覧にし、業務上の重要度と障害時の影響範囲を整理します。
優先度マトリクスで対象を絞る
| 重要度 | 障害時の影響 | 対処の優先度 |
|---|---|---|
| 高（コア業務に直結） | 大（生産停止・出荷停止） | 最優先で見える化 |
| 高（コア業務に直結） | 中（運用でカバー可能） | 早期に対応 |
| 低（周辺機能） | 大（連携先に影響） | 中期的に対応 |
| 低（周辺機能） | 小（業務に直接影響しない） | 余力があれば対応 |
製造業での例：
- 最優先：受発注処理、在庫引き当て、生産計画の計算バッチ
- 早期対応：原価集計、月次締め処理
- 中期対応：帳票出力、データ連携（販売管理↔会計）
- 後回し可：一部レポート、参照系画面
対処ステップ2：現状の「見える化」（ドキュメント整備）
見える化の目標：「完璧」ではなく「概要が分かるレベル」
ブラックボックス状態から、いきなり完璧なドキュメントを作ろうとするのは非現実的です。目標は「第三者（新しい担当者や別のベンダー）が、システムの概要を理解できる状態」です。
見える化で作成・整備するもの
システム全体図（コンテキスト図）
- このシステムが何をするためのものか
- 他のシステムとどう連携しているか（入力・出力の方向と内容）
- 主なユーザー・部署はどこか
業務フロー（As-Is）
- 主要な業務（受注から出荷まで、月次締めなど）の処理の流れ
- どの画面で入力し、どのバッチが処理し、どのシステムに連携するか
バッチ・ジョブ一覧
- バッチ名、実行タイミング（日次・月次・週次等）、おおよその処理内容、出力先
- 依存関係（Aが終わった後にBを実行する、など）
主要テーブル一覧（概略）
- 重要なテーブル（受注、在庫、製品、顧客等）とそのおおよその項目・関係
- 完璧なDB定義書でなくてよい。ER図の概略レベルで構わない
過去の障害・改修の記録
- 過去に起きた障害の原因と対処内容
- 主な改修の経緯（「いつ、なぜ、何を変えたか」）
見える化の進め方：誰から情報を集めるか
ドキュメントがない場合は、人からヒアリングして記録することが必要です。
- 現行ベンダーの担当者：設計の背景、よくある問い合わせ、過去のトラブル対処
- 社内のキーユーザー（現場の業務担当）：業務の流れ、「いつ、この画面を使う」という実態
- 社内の前任の情シス担当（退職者含む）：可能であれば、記憶にある限りの経緯
- システムが生成したログ・ファイル：動いているものを観察して仕様を逆引きする（リバースエンジニアリング）
ここまで読んで「自社のシステム、まずどこから手を付けるべきか相談したい」と感じていたら、現状ヒアリングからお気軽にご相談ください。
対処ステップ3：保守体制の見直し（継続か変更か）
見える化がある程度進んだタイミングで、現行の保守体制を続けるか、新ベンダーに切り替えるかを判断します。
現ベンダーを継続する場合
見える化の成果物（システム全体図、バッチ一覧、業務フロー）を現ベンダーに共有し、以下の改善を求めます。
- SLA（対応時間・復旧目標）の明文化と見直し
- 今後の改修・保守作業に際したドキュメント更新義務の設定
- 保守料の妥当性確認と交渉（見える化で「何をやってもらっているか」が明確になると交渉しやすくなる）
新ベンダーに切り替える場合
見える化が進んでいると、新ベンダーへの引き継ぎが格段に楽になります。「システムの概要を理解できる資料がある状態」と「何もない状態」では、引き継ぎにかかるコストと期間が大きく変わります。
ブラックボックス化が深刻な状態のまま（レベル3〜4）でベンダー変更に踏み切ると、引き継ぎ先が理解できないまま保守を引き受けることになり、切替後のトラブルリスクが高まります。見える化と並行して、または見える化がある程度進んだ後に保守体制の変更を検討するのが現実的です。
対処ステップ4：段階的なモダナイズへ（必要に応じて）
見える化と保守体制の見直しが完了したあと、必要に応じて段階的なモダナイズ（システム刷新）を検討します。
ブラックボックス化したシステムをいきなり全面リプレイスしようとするのではなく、見える化で得た情報をもとに「どこから手を付けるか」を優先度とリスクで切り分けることが大切です。
段階的モダナイズの進め方例：
- 周辺システム（帳票・連携）から着手：影響範囲が小さく、リスクを限定できる
- コアシステムのAPIラッパー化：コアシステムはそのまま動かしつつ、外部からAPIで呼べる層を追加する
- 段階的なDB移行：古いDBから現代的なDBへ段階的に移行（AS/400のDB2 → PostgreSQL等）
- 最終的なコアリプレイス：十分な準備と見える化が進んだ段階で、本体の刷新に踏み切る
よくある質問
Q. 見える化を進めようとしたが、現ベンダーが資料を出してくれません。どうすれば良いですか？
A. まず契約書で、ソースコードや設計書の著作権・引き渡し条件を確認してください。自社発注のシステムであれば、原則として著作権は自社にあることが多いです。それでも協力が得られない場合は、見える化作業に対する報酬を提示して追加契約を結ぶか、ソースコードや動作から仕様を逆引きするリバースエンジニアリングを別会社に依頼する方法もあります。
Q. ドキュメント整備にかかるコスト・工数の目安を教えてください。
A. 対象システムの規模・複雑さにより大きく異なりますが、中規模の基幹システム（5〜10機能、数十画面）で、概要レベルのドキュメント整備に3〜6ヶ月、担当者のリソースを月30〜50時間程度使うケースが多いです。ベンダーに依頼する場合は、調査・ドキュメント作成費として数百万円規模になることもあります。
Q. ブラックボックス化したシステムを全面リプレイスしたほうが早くないですか？
A. ブラックボックス化したまま全面リプレイスに挑むと、要件定義の精度が下がり（「現行で何をしているか」が分からない）、工数見積もりが膨らみ、想定外の追加開発が発生するリスクが高くなります。「見える化してからリプレイス」が、結果的に早道であることが多いです。どうしても急ぐ場合は、小さな範囲でパイロット的にリプレイスを試みて、リスクを確認してから拡大していく方法を推奨します。
Q. ブラックボックス化の解消と保守ベンダー変更は、同時に進めても良いですか？
A. 同時進行は難しいケースが多いです。ベンダー変更の引き継ぎに「見える化されたドキュメント」が必要なためです。見える化を先行させ、ある程度の資料が揃った段階でベンダー変更を進める順番が、トラブルを防ぎやすいです。ただし、規模の小さい周辺システムは、見える化と並行してベンダー変更を進められることもあります。
製造業の基幹システムのブラックボックス化は、放置するほどリスクが大きくなります。しかし、対処の順番を誤ると（いきなり全面リプレイスを試みる等）、さらにコストとリスクが膨らみます。
本記事でご紹介した4ステップを振り返ります。
- スコーピング：重要度と障害時の影響範囲を整理し、優先順位を決める
- 見える化：完璧を目指さず、「概要が分かるレベル」を目標にドキュメントを整備する
- 保守体制の見直し：見える化が進んだタイミングで、現ベンダー継続か変更かを判断する
- 段階的なモダナイズ：見える化の成果を活かし、周辺から段階的に刷新する
「動いているうちに、見える化と保守体制の見直しを進める」ことが、将来の選択肢を広げる最善の方法です。
c3index に相談する
シースリーインデックスは、製造業のお客様の基幹システムの棚卸し・ドキュメント整備・保守ベンダー変更時の引き継ぎ支援を行っています。「ブラックボックス化したシステムをどこから手を付ければよいか」「現行ベンダーとの関係をどう整理すれば良いか」など、現状ヒアリングから一緒に整理することも可能です。
お気軽にお問い合わせください。
システムの保守・運用を任せられる体制をお探しでしたら、システム保守・運用でご相談を承っています。
