この記事では、サーバーやOSの保守期限が迫り、基幹システムをどうするか決めたい企業に向けて、判断すべきポイントを実務目線で整理します。マクティズムでは、いきなり作り直すのではなく、延命・部分改善・パッケージ活用・周辺開発・スクラッチ再構築のどれが現実的かを、現行業務と帳票・データから確認することが重要だと考えています。
この記事で分かること
- 保守期限とサーバー構成を確認する
- 現行システムの業務範囲を棚卸しする
- 帳票・バッチ・外部連携を洗い出す
- サーバーだけ変えて済むか判断する
- 延命・DB改善・再構築を比較する
- 移行時期と並行稼働を設計する
- 早めに開発前診断を行う
まず結論
結論として、古い基幹システムのサーバー保守終了前にやるべきことで最初に見るべきなのは、システムの古さそのものではなく、業務への影響、保守できる体制、データ量、帳票・連携の複雑さ、今後の変更予定です。まだ動いているから大丈夫と考えがちですが、保守期限や担当者退職、パッケージ不適合が見えている場合は、検討開始が遅れるほど選択肢が狭くなります。まずは現状を棚卸しし、作り直す範囲と残す範囲を切り分けることが必要です。
よくある背景・失敗しやすい理由
このテーマで相談が増える背景には、古い基幹システムのブラックボックス化があります。設計書が一部しか残っていない、帳票の意味を説明できる人がいない、サーバーやデータベースの保守期限が近い、パッケージを検討したが標準機能では現場業務が回らない、といった状況です。現場では業務を止めないためにExcelやAccess、CSV加工で補うことが多く、その場しのぎの対応が積み重なるほど、再構築時の調査範囲とリスクが大きくなります。
サーバー保守終了に限っていえば、最も多い失敗は「期限が迫ってから動き出す」ことです。同じハードウェアやOSの保守終了は同業他社にも一斉に訪れるため、直前になるほど機器の調達やベンダーの対応枠が埋まり、費用も交渉しにくくなります。結果として、本来なら再構築を選べたはずの会社が、時間切れでサーバー更改だけを選ばざるを得ない、という状況が起こります。
確認すべきポイント
ここからは、保守終了までに確認しておくべき項目を順に整理します。上から順に進めることで、「サーバーだけ入れ替えれば済むのか」「この機会に作り直すべきなのか」の判断材料がそろう構成にしています。
1. 保守期限とサーバー構成を確認する
保守期限とサーバー構成を確認するは、古い基幹システムのサーバー保守終了前にやるべきことを検討するうえで見落としやすいポイントです。単独では小さな課題に見えても、基幹システムでは受発注、在庫、請求、帳票、会計連携など複数業務に影響します。まず現状の使われ方、関係する部署、止められない処理、今後も残すべき運用を確認してください。この段階で無理に結論を出すのではなく、延命で足りる部分と再構築が必要な部分を分けて整理します。
2. 現行システムの業務範囲を棚卸しする
現行システムの業務範囲を棚卸しするは、古い基幹システムのサーバー保守終了前にやるべきことを検討するうえで見落としやすいポイントです。サーバーを入れ替えれば済むように見えても、実際には受発注・在庫・請求・生産のどこまでを現行システムが担っているのかが社内で共有されていないことがよくあります。画面単位ではなく業務単位で棚卸しし、移行対象から外してよい機能がないかもあわせて確認します。
3. 帳票・バッチ・外部連携を洗い出す
帳票・バッチ・外部連携を洗い出すは、古い基幹システムのサーバー保守終了前にやるべきことを検討するうえで見落としやすいポイントです。夜間バッチ、取引先とのEDIやCSV連携、会計システムへの受け渡しなど、普段は意識されない処理ほど移行時に問題になります。月次・年次でしか動かない処理まで洗い出したうえで、移行スケジュールに反映することを重視しています。
4. サーバーだけ変えて済むか判断する
サーバーだけ変えて済むか判断するは、古い基幹システムのサーバー保守終了前にやるべきことを検討するうえで見落としやすいポイントです。アプリケーションが新しいOSやデータベースのバージョンで動作するか、開発言語やミドルウェアがサポート対象かによって、更改だけで済むか作り直しが必要かが分かれます。まず検証環境で現行資産が動くかを確認し、リフト（移行のみ）で延命できる可能性から検討します。
5. 延命・DB改善・再構築を比較する
延命・DB改善・再構築を比較するは、古い基幹システムのサーバー保守終了前にやるべきことを検討するうえで見落としやすいポイントです。サーバー更改は一時的な延命にはなりますが、5年後に同じ判断を迫られる点は変わりません。更改費用と再構築費用を単年ではなく5〜10年の総額で比較し、どのタイミングで作り直すのが最も無駄が少ないかを整理します。
6. 移行時期と並行稼働を設計する
移行時期と並行稼働を設計するは、古い基幹システムのサーバー保守終了前にやるべきことを検討するうえで見落としやすいポイントです。月末の締め処理や繁忙期を避け、旧環境と新環境をいつまで並行稼働させるかを先に決めておく必要があります。切替日から逆算して、データ移行・検証・現場教育の期間を含めた移行計画を立てることをおすすめしています。
7. 早めに開発前診断を行う
早めに開発前診断を行うは、古い基幹システムのサーバー保守終了前にやるべきことを検討するうえで見落としやすいポイントです。保守期限の直前になるほど、更改しか選べない、相見積もりを取る時間がない、といった形で選択肢が狭まります。期限の1年〜1年半前に現状・費用感・段階導入の進め方を資料化し、社内稟議や他社比較にそのまま使える状態にすることを推奨しています。
自社で整理できること・外部に相談すべきこと
社内でまず整理できるのは、業務範囲、画面、帳票、困っている作業、保守期限、利用部署、関連するExcel・Access・CSVです。一方で、影響範囲が複数部門にまたがる、データ移行や外部連携が絡む、パッケージ比較が必要な場合は、外部の開発会社と一緒に現状整理した方が安全です。
整理の際は、資料を完璧に揃えることを目的にしないでください。画面のスクリーンショット、実際に使っている帳票の現物、担当者の口頭説明があれば現行調査は始められます。保守期限という動かせない締め切りがある以上、資料作成に時間をかけて着手が遅れるほうがリスクです。
判断表
| 状態 | まず検討すること | 注意点 |
|---|---|---|
| 軽微な不具合・一部帳票の変更 | 延命・保守・部分改修 | 本体再構築の前に影響範囲を確認 |
| データ量増加・動作遅延・バックアップ不安 | DB改善・性能改善 | 根本的な業務課題が残らないか確認 |
| パッケージ標準で業務が合う | パッケージ導入 | 帳票・例外処理・データ連携を事前確認 |
| パッケージで足りない機能が明確 | パッケージ＋周辺開発 | 責任範囲と連携仕様を明確にする |
| 独自業務・例外処理が多い | スクラッチ再構築 | 要件整理と段階導入が重要 |
| 判断が難しい | 開発前診断・刷新ロードマップ | 社内稟議や他社比較に使える資料化を行う |
この表は初期の方向づけです。実際には、受発注はパッケージ、生産管理はスクラッチ、帳票出力は当面延命、といった組み合わせになることも珍しくありません。保守期限までに全体を移行しきれない場合は、期限が迫っている環境から順に移す段階的な進め方も選択肢になります。
相談前に準備しておく情報
相談前にすべての資料を揃える必要はありません。ただし、現行システム概要／利用部署・人数／画面一覧／帳票一覧／データ項目／外部連携／保守期限／困っている業務／パッケージ検討状況／想定予算・時期 などが分かると、初回相談の精度が上がります。
あわせて、保守終了の正確な期日、現在のサーバー・OS・データベースのバージョン、社内の意思決定と稟議の流れ、絶対に止められない業務や時期（月末の締め処理、繁忙期など）を共有いただけると、移行時期まで含めた現実的な提案ができます。
マクティズムの見解
サーバー保守終了は、単なるインフラ更新ではなく基幹システムの見直しタイミングです。現行システムが新環境で動くかだけでなく、今後も業務に耐えられる設計かを確認すべきです。
実務上おすすめしているのは、保守期限の1年〜1年半前に現状を棚卸しし、「更改で延命する」「更改しつつ段階的に作り直す」「この機会に再構築する」の3案を費用と期間で比較できる状態にしておくことです。判断そのものは後からでも構いませんが、比較材料がないまま期限を迎えると、選べるのは最も費用対効果の低い選択肢だけになりがちです。
また、サーバー更改を選ぶ場合でも、その5年の間に何を整理しておくか（帳票の統廃合、Excel運用の見直し、データの整理）を決めておくと、次の再構築が大幅に楽になります。更改を単なる先送りにせず、次の一手の準備期間として使うことをおすすめします。
サーバー保守終了は、多くの企業にとって数年に一度しか訪れない見直しの機会です。動いているものをあえて触るのは負担ですが、期限という区切りがあるからこそ、社内の合意も取りやすくなります。まずは現状を一緒に棚卸しするところから、無理のない範囲で進めていければと考えています。
よくある質問
保守期限が近い場合、いつから相談すべきですか？
規模によりますが、半年〜1年以上前から現状整理を始めることをおすすめします。
要件がまとまっていなくても相談できますか？
はい。現状の課題や分かる範囲の資料から、まず何を確認すべきか整理できます。無理に要件を固めてから相談する必要はありません。
仕様書や設計書が一部しかなくても相談できますか？
はい。画面、帳票、データ、業務フロー、操作手順などから現行調査を進められます。
いきなり大きな開発を依頼する必要がありますか？
いいえ。初回相談、簡易棚卸し、開発前診断・刷新ロードマップから段階的に進められます。
パッケージとスクラッチのどちらがよいか相談できますか？
はい。標準機能で合う範囲、周辺開発で補う範囲、スクラッチが必要な範囲を比較します。
500万円〜1,000万円規模の部分改善から相談できますか？
はい。DB改善、性能改善、帳票・データ連携、バックアップ自動化など部分改善から相談可能です。
相談後にしつこい営業はありますか？
ありません。まずは現状を整理し、必要な選択肢と進め方をご提案します。
