この記事は、長年使っている基幹システムの中身を誰も説明できない状態にある会社に向けたものです。従業員10〜20名程度で、情報システム担当がおらず、作った人も保守していた人も既にいない状況を前提にしています。
この状態を解説した記事は多くありますが、そのほとんどが「可視化してドキュメントを整備し、段階的に刷新する」で終わります。兼任者しかいない会社では、その入口にすら立てません。この記事は何から判定し、どの選択肢を選ぶかを扱います。
結論
ブラックボックス化した基幹システムは、古いから直すのではありません。止まったときに耐えられない領域から順に手を付けます。技術の状態ではなく、事業への影響が優先順位を決めます。現状把握はドキュメント整備ではなく、人・契約・データ・復元の4点だけで足ります。期限は調べれば日付で確定します。そのうえで、触らない・延命・部分改修・刷新・外部へ逃がす、の5つから選んでください。
基幹システムのブラックボックス化とは
言葉の意味
基幹システムのブラックボックス化とは、長く使っているうちに中身を説明できる人がいなくなり、手を入れたくても入れられなくなった状態を指します。情報処理推進機構(IPA)はレガシーシステムの主な症状を「運用を継続させる維持保守や機能改良を行いたくても行えなくなってしまった状態」と説明し、同じページでユーザー企業の61%がレガシーシステムを保有していることにも触れています(IPA DX SQUARE「ITシステムのモダン化とは?」 2026年9月5日確認)。珍しい状態ではありません。長く事業を続けてきた会社ほど、程度の差はあれ同じものを抱えています。
なぜ起きるのか
ブラックボックス化は、ある日突然起きるものではありません。導入してから何年もかけて必要な改修を一つずつ積み上げた結果、どの機能がどの都合で足されたのかが誰にも追えなくなります。加えて、改修のたびに仕様書を直す手間は後回しにされやすく、手元の資料と実際の動きが少しずつ食い違っていきます。資料が実態を表さなくなった時点で、読んで確かめる手段が失われます。
次に人が抜けます。詳しい担当者が退職や異動でいなくなると、資料に書かれていない前提が一緒に持ち出され、残った人は画面の操作方法しか知らない状態になります。困ったときは保守ベンダーに聞くしかなくなり、判断そのものを外部へ預けたまま年数が過ぎます。その間に機器とOSも古くなり、部品の調達やセキュリティ更新の期限が近づいて、動かし続けること自体に手間と費用がかかり始めます。
何が危ないのか
危ないのは古いこと自体ではなく、止まったときと直したいときに選べる手が残っていないことです。障害が起きても原因を切り分けられる人がいないため、復旧が数日から数週間の単位へ延びます。小さな改修でも影響範囲を読めず、調査から始めるぶん見積もりも期間も膨らみます。保守を頼んでいる相手を替えようにも、引き継ぐ材料が無いので次の会社は現物調査から見積もることになり、実質的に相手を選べなくなります。処理の中身を誰も追えない状態では、入力ミスや不適切な操作が起きても、誰にも気づけないまま数字だけが積み上がることもあります。これは統計として確認したものではなく、中身を追える人がいない以上は当然に起こりうる、という論理上の帰結です。
ブラックボックス化は、たしかに望ましい状態ではありません。ただし、望ましくないことと、今すぐ手を付けるべきことは別です。解説記事の多くは古さや分からなさという症状から語り始めるため、読み終えても自社がどれだけ危ないのかが判定できません。この記事では順序を逆にします。技術の状態ではなく、止まったときに何がいくつ止まるかから始めます。
判定は4つの層で行う
ここからは4つの層に分けて判定します。止まったときの影響、いま確認できる4点、危なくなる日付、そのうえでとれる手、という順序です。上から埋めていくと、最後の層で選ぶ選択肢が自然に絞り込まれます。途中の層を飛ばすと、根拠のないまま刷新か延命かを選ぶことになります。
第1層|止まったら何が止まるか
先に、自社が当てはまるかを確かめてください。全体像を最初から最後まで説明できる人が社内にいない。改修を頼むたびに想定していなかった影響が出る。手元の仕様書が実際の動きと合っていない。保守ベンダーに聞かないと変更の可否を判断できない。この4つのうち1つでも思い当たるなら、ブラックボックス化は既に始まっています。原因を細かく分析するより先に、この第1層から手を付けてください。
最初に決めるのは、そのシステムが明日から使えなくなったときに何が起きるかです。1つずつ、日数と金額で書いてください。
| 止まるもの | 何日耐えられるか | その先で起きること |
| 受注の記録 | 例:3日 | 納期回答ができない。受注機会を失う |
| 出荷指示 | 例:1日 | 出荷が止まる。当日分から影響 |
| 請求の発行 | 例:2週間 | 入金が翌月へずれる |
| 在庫の把握 | 例:1週間 | 欠品と過剰発注が同時に起きる |
| 過去データの参照 | 例:無期限 | 困るが、業務は止まらない |
この表を作ると、同じシステムの中に、即日致命的な領域と数週間耐えられる領域が混在していることが分かります。全体を一度に何とかしようとして動けなくなる原因は、ここを分けていないことです。
耐えられる日数が短い順に並べてください。それが対処の優先順位です。技術的にどこが古いかは、この段階では関係ありません。
第2層|4点だけ書き出す
次に現状を把握しますが、ドキュメントの整備はしません。兼任者しかいない会社で数か月かかる作業を前提にすると、そこで止まります。書き出すのは次の4点だけです。
| 確認すること | 見る場所 | 分からない場合 |
| 誰が触れるか | 直近の改修を誰に頼んだか | 「今は誰もいない」と書く。それが答え |
| 契約は誰の名義か | 保守契約書、請求書、ライセンス証書 | 請求明細から支払先をたどる |
| データを取り出せるか | CSV出力、バックアップ機能の有無 | 画面から1件でも書き出せるか試す |
| 復元を試したことがあるか | バックアップからの復旧実績 | 試していないなら「未確認」と書く |
4点目が最も重要です。バックアップを取っていることと、そこから戻せることは別です。試していない復旧手段は、無いのと同じ扱いにしてください。
この作業を誰が担うか、外部にどこまで出すかの線引きは情シス不在の中小企業がまず整えるもので扱っています。担当者の知識が本人の中にしかない場合は属人化を解消する業務棚卸しの進め方を先に読んでください。
第3層|危なくなる日を1枚に並べる
「早めに対処を」と書かれた記事は多くありますが、いつまでが早めなのかは書かれていません。期限は調べれば確定します。
| 期限の種類 | 確認先 | 分かること |
| サーバー機器の保証期限 | 購入時の書類、保守契約 | 故障時に部品が手に入るか |
| OS・データベースのサポート終了日 | 提供元の公開情報 | セキュリティ更新が止まる日 |
| 保守してくれている人の在籍 | 契約先の担当者、退職予定 | 頼める相手がいなくなる時期 |
| 繁忙期 | 自社の売上推移 | 作業してはいけない期間 |
| 取引先のシステム変更 | 取引先からの通知 | 連携が切れる時期 |
| 製品 | 期限 | その先で起きること |
| Windows Server 2016 | 2027年1月13日に延長サポート終了 | セキュリティ更新が止まる |
| Windows Server 2019 | 2029年1月10日に延長サポート終了 | 同じくセキュリティ更新が止まる |
| SQL Server 2016 | 2026年7月15日に延長サポート終了済み。有償のExtended Security Updatesは2029年7月17日まで | 追加費用を払わない限り更新が来ない |
| SAP Business Suite 7 | 標準保守は2027年末まで。任意の延長保守は2030年末まで | 保守料に上乗せが要る |
ここに並べたのは代表的な製品です。自社が使っている版の期限は、必ず提供元の公開情報で確認してください。同じ製品名でもエディションや適用状況によって日付が変わることがあり、保守業者からの伝聞をそのまま期限として扱うと、1年単位でずれます。確認先はWindows Server の2016と2019、SQL Server 2016のライフサイクル情報、およびSAP のメンテナンス方針です(いずれも2026年9月5日確認)。
先に挙げた5種類の期限を日付で並べると、いちばん早い日付が実質的な期限になります。多くの場合、それは技術の古さではなく人の在籍です。
今すぐ動けなくても構いません。いつまでに決めるかは、今日決められます。
第4層|とる手は5つある
ここが判断の中心です。選択肢は刷新だけではありません。
| 選択肢 | 選んでよい条件 | 選んだ場合に必ずやること |
| 触らない | 耐えられる日数が長く、期限までまだ余裕がある | データの取り出し手段と、復元の実績を確保する |
| 延命する | 期限が近いが、業務を変える余力がない | 機器やOSだけ替える。中身は触らない |
| 部分改修する | 止まると致命的な領域が特定できている | 対象を絞る。全体に手を広げない |
| 刷新する | 業務側も変えられる。予算と期間を確保できる | 旧環境をいつまで残すかを先に決める |
| 外部サービスへ逃がす | その業務が自社固有でない | 移せない業務の扱いを先に決める |
「触らない」を最初に置いているのは、それが正式な判断だからです。耐えられる日数が長く、期限にも余裕があるなら、今は何もしないという選択が最も合理的です。ただし何もしないことと、備えないことは違います。データを取り出せる状態と、復元できる実績だけは確保してください。
改修か刷新かの判断はシステムは改修か刷新か、刷新を選んだ後の移行と旧環境の扱いはレガシーシステムの移行計画で扱っています。外部サービスへ移す場合の連携設計はSaaS連携で二重入力をなくすを参照してください。
作り直す場合、次に同じ状態を作らないための確認項目はAIで作ったシステムは保守できるかにまとめています。
次の相手へ渡すものを、先に揃える
どの選択肢を選んでも、いずれ誰かに見てもらう場面が来ます。そのときに渡せるものが無いと、調査だけで費用と時間がかかります。第2層の4点に加えて、次を集めておいてください。
| 渡すもの | どこにあるか | 無い場合の代わり |
| 画面の一覧 | 実際に操作して書き出す | 使う人にメニューを読み上げてもらう |
| 帳票・出力物の実物 | 印刷したもの、PDF | 画面の写真でよい |
| 1か月分の実データ | エクスポート機能、画面のコピー | 件数と項目名だけでも書き出す |
| 過去に改修した箇所 | 見積書、請求書、メールの履歴 | 「いつ頃、何を直したか」の記憶を書く |
| 動いている環境の情報 | サーバーの画面、契約書 | 保守業者への支払明細をたどる |
完璧である必要はありません。画面の一覧と帳票の実物があるだけで、見てもらう相手の初期調査は大きく短縮されます。逆にこれが無いと、相手はまず現物調査の見積もりを出すことになります。
これらは選択肢のどれを選んでも無駄になりません。「触らない」を選んだ場合でも、いつか必要になる材料です。
「標準化すればよい」が通らない場合
刷新の解説では「業務をシステムに合わせて標準化する」と書かれます。しかし特注対応そのものが売上になっている会社では、標準化は商品性の放棄になります。
この場合、標準化できない業務を無理に合わせるのではなく、その業務だけを対象外にして残す判断が要ります。全体を1つの仕組みに寄せる前提を外してください。
同じ理由で、対象が1本の基幹システムとは限りません。業務システムと表計算ソフトと紙が混在しているのが実態です。まず、どこまでを対象にするかの線引きから始めてください。第1層の表を作ると、その線は自然に決まります。
この論点の出どころ
既存システムの中身が分からなくなるという論点は、2018年9月に経済産業省がまとめた『DXレポート ~ITシステム「2025年の崖」克服とDXの本格的な展開~』を起点に議論されてきました。情報処理推進機構(IPA)は、その後の状況や課題を調査し、「DX白書2021」「DX白書2023」、現在の「DX動向」として公表しています。その調査とは別に、IPAはレガシーシステムのモダン化についての解説のなかで、ユーザー企業の61%がレガシーシステムを保有していると示しています(2026年9月5日確認)。
IPAが2026年7月に公表した調査のポイントでは、国内企業におけるDXは普及し、AI導入は着実に広がっている一方、業務効率化の段階から新たな価値創出やビジネス変革へと発展させることが今後の重要な課題であることが示された、とされています。
つまり議論は、入れ替えたかどうかの段階から、その先で何が変わったかの段階へ移っています。ブラックボックスの解消も、置き換えることが目的ではなく、止められる時間と戻せる手段を取り戻すことが目的になります。
出典
- 情報処理推進機構(IPA)「DX動向 企業等におけるDX推進状況調査分析」 2026年9月2日確認
- 情報処理推進機構(IPA)「DX動向2026調査のポイント 広がるAI導入、DXは変われるか」(2026年7月16日発表) 2026年9月2日確認
よくあるご質問
ブラックボックス化しているかどうか、どこで判断すればよいですか
全体像を説明できる人が社内にいない、改修のたびに想定外の影響が出る、仕様書が実際の動きと合っていない、保守ベンダーに聞かないと変更の可否を判断できない。この4つのうち1つでも思い当たるなら、程度の差はあれブラックボックス化していると考えてください。判断の入口はここまでで十分で、次は止まったときに何が何日で止まるかを書き出す作業へ進みます。
仕様書がありません。作るべきですか
完全な仕様書は不要です。IPAは仕様を復元して文書化することで保守性を確保できるとしていますが、それは相応の工数を前提とした話です。まずは画面と帳票の一覧、そこで何が起きるかの1行説明にとどめてください。それだけでも、次の相手へ渡す材料になります。
元のベンダーと連絡が取れません
先に確保すべきは、ソースコードの所在、サーバーへのログイン手段、データのバックアップの3点です。交渉より保全が先です。これらが確保できていれば、別の会社へ引き継げる可能性が残ります。
何もしないままで本当によいのですか
耐えられる日数が長く、期限に余裕があるなら、今は問題ありません。ただし「触らない」を選ぶ条件は、データを取り出せて、復元を試したことがある状態です。この2つが無いなら、それは「触らない」という判断ではなく、単なる放置です。
費用はどのくらいかかりますか
費用の公的な相場データは、当方が確認した範囲では見当たりませんでした。事業者が公開している数値も、対象規模と作業範囲が異なるため自社の見積もりにはなりません。判断材料になるのは金額そのものより、止められる時間・移行するデータの範囲・切り戻しの方法の3点を揃えたうえでの比較です。他社の記事にある期間や金額も、多くは各社が自社の経験から置いた推定で、公的な裏付けはありません。日付として確認できるのは製品のサポート期限だけなので、第3層に載せた期限の表から逆算してください。
今週やること
今週着手するなら、第1層です。そのシステムが明日から使えなくなったとき、何日で何が止まるかを書き出してください。1枚できれば、急ぐべきかどうかが分かります。
現在お使いのツールを前提に整理することもできます。お問い合わせはこちらです。
ここまでの整理を踏まえて、無料診断で現在の段階を確認できます。
無料診断をはじめる