先に要点
- 古い業務システムを誰も触れなくなるのは、技術的に古いからだけではなく、仕様・運用・責任が見えなくなるからです。
- 特に多いのは、属人化、口伝の仕様、テスト不足、影響範囲不明、止めたときの業務影響への恐怖です。
- その結果、問題があっても「怖いから触らない」が最適行動になり、改善より延命が選ばれやすくなります。
- 解決には全面刷新の前に、画面、機能、連携、運用、担当者、障害履歴を小さく見える化することがかなり効きます。
社内の古い業務システムについて、こんな空気になることがあります。
- 触れる人が一人しかいない
- 直したいけど怖くて触れない
- ちょっと変えるだけでも時間がかかる
- 詳しい人が辞めたら本当にまずい
この状態になると、システムは動いているのに、実質的には 誰のものでもない危ない資産 になります。
しかも厄介なのは、急にそうなるのではなく、少しずつそうなっていくことです。
この記事では、古い業務システムを誰も触れなくなるのはなぜかを、技術だけでなく、組織と運用の問題として整理します。
古いから触れないのではなく、見えないから触れない
まず大事なのはここです。
「古い技術だから触れない」と思われがちですが、実務ではそれだけではありません。
本当に厄介なのは、次のようなものが見えなくなっている状態です。
- 何のためにある機能なのか
- どこに影響するのか
- 誰が使っているのか
- 止まると何が困るのか
- どこまでが本当の仕様なのか
つまり、コードやサーバー以前に、システムの輪郭そのものがぼやけている ことが問題です。
古いシステムが危ないのは「年数」より「見通しの悪さ」です。中身が古くても、仕様・運用・担当が整理されていればまだ扱えます。逆に新しめでも中身が見えなければ、すぐ触れないシステムになります。
誰も触れなくなる理由1: 属人化している
一番分かりやすいのはこれです。
長年の運用で、
- この画面はこの人しか分からない
- 障害対応はこの人に聞くしかない
- SQLの修正はこの人しか怖くてできない
という状態になります。
最初は「詳しい人がいて助かる」なのですが、時間がたつと、その人の頭の中にしかない仕様が増えていきます。
すると他の人は、調べるより聞いた方が早くなり、さらに知識が広がらなくなります。
そして、その人が異動したり退職したりすると、一気に 誰も触れない 状態になります。
誰も触れなくなる理由2: 仕様が文書ではなく口伝で残っている
古い業務システムは、仕様書がゼロではないことも多いです。
でも実際に困るのは、生きている仕様が文書ではなく口頭で運用されている ケースです。
たとえば、
- このボタンは月末だけ使い方が違う
- このコード値は昔の取引先だけ例外
- この帳票は営業部だけ列順を変えている
- このエラーは一度閉じてやり直せば通る
のようなことが、現場の慣れで回っている状態です。
こうなると、画面を見ても仕様が分からず、コードを見ても理由が分かりません。
結果として、変更するとどこが壊れるか読めなくなります。
誰も触れなくなる理由3: テストできる形になっていない
システムは、変更できるかどうかより、安全に確かめられるかどうか の方が大事です。
でも古い業務システムでは、ここがかなり弱いことがあります。
よくあるのは、
- テスト環境がない
- 本番に近い検証データがない
- テスト観点が人によって違う
- 帳票やバッチの確認手順が決まっていない
という状態です。
この状態では、少しの修正でも 壊してしまうかもしれない という恐怖が勝ちます。
だから直せるかどうか以前に、確認できないから触れない になりやすいです。
誰も触れなくなる理由4: 影響範囲が読めない
古い業務システムは、思った以上に周辺へつながっています。
- 会計システム
- 在庫管理
- CSV連携
- 帳票出力
- メール通知
- 手作業の運用フロー
こうした連携や運用が長年積み重なっていると、ひとつの修正がどこに波及するのか分からなくなります。
たとえば「この入力項目を1つ増やしたい」だけでも、
- DB項目追加
- 画面修正
- CSV出力変更
- 外部連携影響
- 帳票レイアウト変更
- 手順書修正
まで広がることがあります。
影響範囲が読めないと、みんな保守的になります。
その結果、「今困っていないなら触らない」が合理的に見えてしまいます。
誰も触れなくなる理由5: 業務を止めたときのダメージが大きい
業務システムは、きれいに作り直すより、まず止めないことが優先されがちです。
これは悪い判断ではありません。
特に、
- 受発注
- 請求
- 勤怠
- 在庫
- 社内申請
のような業務に直結していると、少しの不具合でも現場が止まります。
すると現場としては、
- 今のままでも回っている
- 触って壊れる方が困る
- 改善より安定が大事
となりやすいです。
この空気が続くと、改善の必要性は分かっていても、毎回先送りされます。
その結果、ますます古くなり、さらに触れなくなる、という循環に入ります。
誰も触れなくなる理由6: 改修コストが読めない
古い業務システムでは、改修見積もりが読みにくいです。
なぜなら、仕様、影響範囲、テスト、運用変更が見えていないからです。
そのため、
- 直すのにいくらかかるか分からない
- どこまでやれば安全か分からない
- 小改修のつもりが大きな案件になる
という不安が強くなります。
この状態だと、改善の相談が出ても、結論が いったん保留 になりやすいです。
見積もりのズレやすさについては、システム開発の見積もりはなぜ外れやすい？ もかなりつながります。
実務で起きやすい悪循環
| 状態 | 次に起きやすいこと |
|---|---|
| 詳しい人が限られる | その人に依存して知識が広がらない |
| 文書が古い / 少ない | 仕様確認に時間がかかる |
| テストが弱い | 変更が怖くなる |
| 影響範囲が見えない | 小改修でも保留になりやすい |
| 改修が後回しになる | さらに複雑化して触れなくなる |
こうして見ると、誰も触れなくなるのは怠慢というより、触るほど危険に見える構造ができている からだと分かります。
では、どうやって抜け出すべきか
ここで大事なのは、いきなり全面刷新から入らないことです。
実務では、まず 見える化 の方が効きます。
1. 画面と機能を棚卸しする
何の画面があって、誰が使い、何のためにあるのかを一覧化します。
この時点で「誰も使っていない機能」や「役割が重複している画面」が見つかることがあります。
2. 連携先と運用フローを整理する
どのCSV、どの帳票、どの外部システム、どの手作業とつながっているのかを出します。
ここが見えるだけでも、影響範囲の怖さはかなり下がります。
3. 障害履歴と怖いポイントを集める
現場や保守担当に、
- 触ると怖いところ
- よく壊れるところ
- 毎回手作業で逃がしているところ
を聞いておくと、優先順位がつけやすくなります。
4. 小さい改修で安全な成功体験を作る
いきなり大改修ではなく、
- 表示文言の整理
- 使われていない機能の削除
- 手順書の更新
- テスト観点の明文化
のような小さい改善から始めると、触れる状態に戻しやすいです。
たとえば古い販売管理システムでも、最初から全面リプレイスを狙うより、まず「どのCSVがどこへ渡るか」「月末処理で誰が何を手で補っているか」を見える化した方が前に進みやすいです。現場の例外運用が見えると、どこから直すべきかも決めやすくなります。
ベンダーに頼むときも丸投げしない方がいい
古い業務システムほど、外部ベンダーへ頼りたくなります。
もちろんそれ自体は悪くありません。
ただし、ここでも 全部いい感じに調べて直してください だと危ないです。
古いシステムは背景事情が多いので、外から見えるコードだけでは判断できないことがかなりあります。
このあたりは、ベンダーに丸投げすると何が起きる？ の話ともつながります。
まずは自社側で「何が怖いのか」「どこまで分かっていて、どこが分からないのか」を整理してから依頼した方がうまく進みます。
まとめ
古い業務システムを誰も触れなくなるのは、単に古いからではありません。
属人化、口伝の仕様、テスト不足、影響範囲不明、業務停止への恐怖、改修コストの不透明さが重なって、触らない方が安全 に見える状態になるからです。
だから対策も、いきなり全面刷新だけではありません。
実務ではまず、画面、機能、連携、運用、担当、障害履歴を見える化して、少しずつ「触れる状態」に戻す方が効きます。
レガシーシステムの本当の問題は、古さそのものより、誰も説明できず、誰も安全に変えられないこと です。