業務システムの改修は「壊れてから」では遅く、「壊れる予兆」が出た段階で動き出すのが理想です。けれども現実には、日々の業務に追われて予兆を見逃し、ある日突然システムが止まって慌てて発注、という流れになりがちです。本記事ではシステム改修のベストなタイミングを「予兆を捉える3つの軸」で整理し、3年単位の改修ロードマップに落とし込む考え方を経営者目線で解説します。
この記事の結論（3行）
- 改修タイミングは「壊れてから」ではなく、動作遅延・OSサポート切れ・属人化の3つの予兆で判断する
- 予兆を見逃すと改修費用が1.5〜2倍、業務停止リスクが3〜5倍に跳ねる
- 3年単位で「軽改修・中改修・大改修」のロードマップを引いておけば、突発発注を避けられる
なぜ「壊れてから改修」は最悪の選択肢か
中小企業の業務システムは「動いているうちは触らない」運用になりがちです。けれども壊れた瞬間に業務が止まり、復旧と並行して改修発注を進める二重対応に追われ、通常時の1.5〜2倍の費用がかかります。
- 要件整理が雑になり、リリース後の追加改修が増える
- 業務停止中はベンダーの足元を見られ、価格交渉力が落ちる
- 移行作業が現場の通常業務を圧迫する
この3つはいずれも予兆段階で動いていれば回避できます。経営者が予兆を捉える視点を持っているかで、改修プロジェクトの成否が決まります。
要件整理が雑になる
業務停止下では「とにかく早く動かしてほしい」が最優先になります。本来1〜2ヶ月かける要件整理を2〜3週間に圧縮することになり、リリース後に追加改修が積み重なります。
価格交渉力が落ちる
ベンダーから見ると業務が止まっている顧客は交渉力の弱い相手です。複数社見積もりを取る時間がなく、通常時より2〜3割高い見積もりを受け入れることになります。
移行作業が現場を圧迫する
旧データの整合性確認・移行スクリプト作成・現場の再教育を、業務を回しながら同時並行で進める展開になり、現場負担が3〜5倍に膨らみます。
改修タイミングを判断する3つの予兆
ここからは具体的な予兆の話です。業務システムの改修タイミングは、以下の3つの軸で定量的に判断できます。
| 予兆 | 判断基準 | 動き出すべき時期 | |---|---|---| | 動作の遅延 | 主要画面の表示が3秒以上 | 3秒超を3ヶ月連続で観測した時点 | | OSサポート切れ | OS/DBの公式サポート終了 | 終了1年前 | | 属人化 | 1人しか触れない領域が3割以上 | 3割を超えた時点 |
このうち1つでも基準を超えていれば、改修プロジェクトの企画を開始するタイミングです。3つ全てが揃ってから動くと、もう「壊れる側」のフェーズに入っています。
予兆1: 動作遅延が3秒超で3ヶ月連続
業務システムの主要画面（受注入力、在庫確認、顧客検索など）の表示が3秒を超えてきたら、データ量の増加に対してシステムの設計が追いつかなくなっている合図です。1〜2回なら一時的な負荷ですが、3ヶ月連続して観測されるなら構造的な問題です。改修を企画する1年の準備期間を確保するため、この時点で動き出してください。
予兆2: OSサポート切れの1年前
WindowsやLinuxディストリビューション、データベース製品の公式サポートには明確な終了日があります。サポート切れ後はセキュリティパッチが配布されなくなり、脆弱性が放置される状態になります。終了の1年前にはアセスメントを開始し、半年前にはベンダー選定を済ませる流れが現実的です。直前に動き出すと、ベンダーの予約が取れず半年遅れになることも珍しくありません。
予兆3: 属人化が3割を超えた
「このシステムの○○機能は××さんしか触れない」領域が、機能全体の3割を超えてきたら危険信号です。退職や異動で1人がいなくなった瞬間に、システムの一部がブラックボックス化します。この時点で改修を企画し、ドキュメント整備と並行して再構築を進めるのが安全策です。属人化の度合いを項目別に整理してから判断する流れをお勧めします。
経営者目線で考える「3年単位の改修ロードマップ」
業務システム改修を場当たり的に発注すると、毎年「想定外の出費」が経常費用を圧迫します。3年単位で「軽改修・中改修・大改修」を組み込んでおけば、年度予算に織り込めて経営判断が楽になります。
経営者がロードマップを引く視点は3つです。第一に、毎年やる軽改修（50〜150万円）・2〜3年に1度の中改修（300〜800万円）・5〜7年に1度の大改修（1,000〜3,000万円）のサイクルを定義する。第二に、各サイクル直前年度に予算を積んで突発発注に備える。第三に、軽改修と中・大改修の発注先を分けない方針を取る（情報共有のコストが下がるため）。
このサイクルが回り始めると、改修は「業務を進化させる定期投資」に変わります。年間保守費用も20〜30%下げられるケースが多くなります。
ぷらすわんの実例：A社の改修タイミング判断
ぷらすわんがご支援したA社（仮想事例・卸売業）は10年使っている受発注システムで「動くが画面が遅い」「DBサポートが来年切れる」「触れるのは情シスのBさん1人」という3つの予兆が同時に出ていました。3軸の判断基準を当てはめると、いずれも改修開始の閾値を超えていました。
まず1ヶ月で現状アセスメントを実施し、3年単位のロードマップを描きました。1年目は中改修（500万円）で遅延とDB更新を済ませ、2〜3年目は軽改修（年100万円）で属人化解消、4年目に大改修（1,500万円）でアーキテクチャ刷新という流れです。これで「壊れてから発注」と比較して総コストを2,000万円ほど圧縮できる見込みです。改修タイミングを診断することで、予兆がどの閾値に当てはまっているかを把握できます。
改修タイミングを見極める5つの実践
最後に、改修タイミングを「壊れる前」に捉えるための、5つの実践的なポイントをお伝えします。
- 主要画面の表示時間を毎月1回測定して記録する
- OSとDBのサポート終了日を年度カレンダーに明記する
- 属人化マップを半年に1度更新する
- 改修予算を年度ごとに「軽・中・大」の枠で確保する
- ベンダーとの保守契約に「アセスメント年1回」を含める
この5つを社内ルーチンに組み込めば、改修タイミングを見逃すリスクが大幅に下がります。
表示時間の月次測定
ストップウォッチで構いません。主要3〜5画面について「ログインから画面表示まで何秒か」を毎月1回測り、Excelで時系列管理してください。3ヶ月連続で3秒を超えたら企画開始の合図です。
サポート終了日のカレンダー化
OS・データベース・基幹フレームワークの公式サポート終了日を年度経営カレンダーに明記してください。終了1年前のマスに「アセスメント開始」と書き込んでおけば、自動的に動き出します。
属人化マップの半年更新
機能ごとに「触れる人」を一覧化したマップを半年に1度更新してください。マップの作成自体が、社内のリスク可視化につながります。
「軽・中・大」の予算枠
年度予算に軽改修50〜150万円、中改修300〜800万円、大改修1,000〜3,000万円の枠を用意してください。未使用分を翌年度に繰り越せば突発発注に備えられます。
保守契約に年1アセスメント
保守契約に「年1回のアセスメント実施」を含めておくと、第三者視点で予兆を捉える機会が生まれます。アセスメント結果について業務改善・システム見積もりAI適正診断で他社見積もりと比較するのも有効です。
まとめ
業務システム改修のタイミングは「壊れてから」ではなく、動作遅延・OSサポート切れ・属人化という3つの予兆で判断します。基準を満たした時点で企画を開始すれば、価格交渉力を維持しつつ要件整理に時間をかけられます。さらに3年単位で「軽改修・中改修・大改修」のロードマップを引けば、突発発注を避けて年度予算に織り込めます。改修を「業務を進化させる定期投資」として扱えば、長期コスト構造が大きく変わります。