基幹システムが改修できなくなる理由　旧ERPカスタマイズ塩漬けの見極め方

長年の個別改修が積み重なった基幹システムは、動いてはいても手を入れられない状態に陥ります。危険なのは「壊れている」ことではなく「触れる人がいない」ことです。

長年の改修依頼が積み重なった基幹システムのイメージ

「動いているのに直せない」旧ERP問題の正体

旧ERPの本当のリスクは、稼働が止まることではなく、必要な改修に誰も着手できなくなることにあります。

私たちが無料診断でヒアリングをしていると、「システムはちゃんと動いています」と答える経営者ほど、実は最も危険な状態にあるという傾向が見えてきます。動いているという事実が、内部のカスタマイズがどこまで積み重なっているかを覆い隠してしまうからです。導入時の標準機能はとうに姿を変え、部門ごとの個別要望に応じた追加開発が層のように積み重なり、今の担当者は「なぜこの画面がこう動くのか」を説明できません。仕様書は更新されず、当時の開発担当者はすでに退職済み、あるいは委託先自体が解散しているケースも珍しくありません。

この状態で新しい改修依頼が来ると、開発側は「どこに手を入れれば影響が及ぶか把握できないので、まず全体を読み解く工数から見積もる」という回答になります。改修そのものより調査に時間がかかり、費用も工数も膨らむため、結局「触らない」判断が積み重なっていきます。これが塩漬けの始まりです。

表面上の動作と内部構造の複雑さのギャップ

なぜ改修不能になるのか　カスタマイズが積み重なるメカニズム

改修不能の正体は、初期導入時の設計と、その後の個別最適化の要求が層を成して積み重なり、誰も全体像を追えなくなることです。

導入時点では、ベンダーもユーザー企業側も、標準機能でどこまで業務をカバーできるかを把握していました。しかし運用が始まると、現場から「この部署だけ集計項目を増やしたい」「この帳票にこの列を足したい」という個別要望が次々と上がります。要望自体は小さな改修でも、それぞれが独立して積み重なっていくと機能同士の依存関係が複雑に絡み合い、ある改修が思わぬ別の機能に影響を与えるようになります。

この積み重ねが3年、5年、8年と続くと、初期導入時のドキュメントはすでに実態と乖離し、改修のたびに「口頭で聞いた仕様」がその場しのぎで実装され、記録に残らないまま次の担当者に引き継がれます。結果として、システムを理解しているのは「長年触ってきた特定の1〜2名」だけという状態になり、その担当者が異動・退職した瞬間に、誰も手を出せないブラックボックスが完成します。

• 個別要望への場当たり的な対応が繰り返される
• 仕様書・設計書が更新されないまま改修が重なる
• 理解している担当者が属人化し、退職で知見が失われる

初期導入から現在までのカスタマイズ積層のイメージ

塩漬けを放置した先で起きること　制度改正・退職・障害が重なるリスク

塩漬けの本当の怖さは、平時ではなく「変化が必要になった瞬間」に牙をむくことです。

たとえば法制度が変わり、対応必須の改修が発生したとします。通常運用であれば数週間で終わる改修でも、内部構造が不明な塩漬けシステムでは「影響範囲の調査だけで数ヶ月」という事態になりがちです。制度対応の期限には猶予がないため、間に合わなければ手作業での帳尻合わせを強いられ、ミスや二重入力のリスクが常態化します。セキュリティパッチの適用も同様で、古い基盤の上に積み重なったカスタマイズがあるため「パッチを当てた瞬間に別の機能が動かなくなるのでは」という恐れから、パッチ適用自体を見送る判断が続きがちです。

さらに深刻なのは、システムを唯一理解していた担当者の退職が重なるケースです。実際の相談現場で見えてくるのは、退職の意思表示から実際の退職日まで数ヶ月しかなく、引き継ぎ資料を作る時間も後任が理解する時間も足りないまま「システムを知る人がいなくなる日」を迎えてしまうという構図です。ここまで来ると、些細な障害対応すら外部の新規ベンダーに「一から解読してもらう」費用が発生し、通常の保守対応とは桁が変わる調査費用がかかることになります。

平時と制度改正発生時での対応可否の違い

属人化した担当者に依存している状態のイメージ

塩漬けでいい部分と危険水域を見分ける判断基準

すべてのカスタマイズを一律に「危険」と扱う必要はありません。判断基準は、制度改正の影響を受けるかどうかと、改修の発生頻度の2軸です。

社内独自の集計ロジックや、対外的な制度に縛られない帳票出力など、外部要因に左右されない範囲であれば、多少ブラックボックス化していても実害は限定的です。無理に手を入れるより、動いている状態を維持する塩漬けの方が合理的な場合もあります。一方で、税制・会計基準・労働関連法などの制度改正に連動する機能は話が別です。ここが不透明なまま塩漬けにされていると、制度改正のたびに対応の可否すら判断できない状態が続き、気づかないうちに未対応のまま運用してしまうリスクを抱え続けることになります。

自社のどの機能が制度改正の影響範囲に入っているかを判断するには、まず現状のカスタマイズ内容を棚卸しし、影響範囲を外部の目で確認するのが安全です。感覚だけで「たぶん大丈夫」と判断していると、実際に制度改正が来たタイミングで初めて対応不能に気づき、選べる選択肢も対応期間も一気に狭まります。迷ったら、初月無料の経営AI診断でシステム構成と業務フローを可視化し、どこが本当に危険水域なのかを一緒に洗い出すところから始めるのも一つの手です。

判断軸	塩漬けでよい傾向	危険水域の傾向
制度改正の影響	ほぼ受けない（社内独自ロジック）	税制・会計・労務など直結する
改修頻度	年1回未満	頻繁に改修依頼が発生
理解者の人数	複数名で分担できている	特定の1〜2名に依存

塩漬けでよい領域と危険水域を分けるマトリクス

今日からできる3ステップ　棚卸し・ドキュメント化・段階移行

改修不能な状態から抜け出す最初の一歩は、大規模な刷新ではなく、現状把握のための棚卸しです。

まず取り組むべきは、現在稼働しているカスタマイズ内容の棚卸しです。誰が、いつ、何のために追加したかが分かる範囲だけでもリスト化すると、どこが制度改正の影響範囲に入るかが見えてきます。次に、棚卸しで洗い出した内容のうち、属人化している部分から優先的にドキュメント化します。すべてを一度に文書化しようとすると挫折するため、危険水域と判断した機能から着手するのが現実的です。最後に、危険度の高い機能から段階的に標準機能や新しい基盤への移行を検討します。全面刷新を急ぐ必要はなく、影響範囲の大きい部分だけを切り出して先に移行する段階移行の方が、現場の負荷も費用も抑えられます。

この3ステップは、社内の担当者だけで進めようとすると、日々の業務に追われて手がつかないまま数年が過ぎてしまうことが多いテーマでもあります。自社のどこが危険水域に当たるのか判断に迷う場合は、初月無料の経営AI診断で現状のシステム構成を可視化し、棚卸しの優先順位づけから一緒に整理していく進め方が現実的です。

1. 棚卸し: 稼働中のカスタマイズ内容と担当者・目的を洗い出す
2. ドキュメント化: 危険水域と判断した機能から優先的に文書化する
3. 段階移行: 影響範囲の大きい機能から順に標準機能・新基盤へ移す

塩漬け状態から抜け出すための3ステップ

まとめ

旧ERPの本当のリスクは停止ではなく、改修できない状態に気づかないまま制度改正や退職が重なることです。まずは現状のカスタマイズを棚卸しし、危険水域を見極めるところから始めてください。自社だけで判断がつかない場合は、初月無料の経営AI診断（通常30万円相当）で現状を可視化し、改善提案までご一緒します。

よくある質問

カスタマイズを減らして標準機能に戻すことはできますか？

可能ですが、まず現状のカスタマイズがどの業務要件に紐づいているかを整理する必要があります。すでに形骸化した要望であれば標準機能に戻せますし、今も必要な要件であれば標準機能側の設定でカバーできないかを先に検討します。段階的に見直すことで、全面刷新より費用と現場の混乱を抑えられます。

関連記事

• 業務システムの属人化を放置すると起きること 引き継ぎ・保守体制の作り方 — 関連: 属人化と引き継ぎリスク
• FileMaker等レガシー業務システムの限界と移行判断　属人化と保守終了のリスク — 関連: レガシーシステムの移行判断
• 会計・販売管理ソフトのサポート終了リスク 塩漬けと移行の判断基準 — 関連: 老朽システムの塩漬けリスク
• 中小企業の基幹システム(ERP)費用相場とスモールスタートの考え方【2026】 — 関連: 基幹システム刷新のコスト感
• 経理エクセルの属人化リスク　担当者退職で起きるブラックボックス化と対策 — 関連: 属人化とブラックボックス化