この記事では、今の基幹システムを使い続けてよいか、作り直すべきか迷っている企業に向けて、判断すべきポイントを実務目線で整理します。マクティズムでは、いきなり作り直すのではなく、延命・部分改善・パッケージ活用・周辺開発・スクラッチ再構築のどれが現実的かを、現行業務と帳票・データから確認することが重要だと考えています。
この記事で分かること
- サーバーやOSの保守期限が近い
- 開発会社・保守会社がなくなった
- 仕様書がなくブラックボックス化している
- Access・Excelでの運用が限界
- データ量増加で動作やバックアップが不安
- パッケージが自社業務に合わない
- 帳票・CSV・サブシステムが増えすぎている
まず結論
結論として、基幹システム再構築が必要になる7つのサインで最初に見るべきなのは、システムの古さそのものではなく、業務への影響、保守できる体制、データ量、帳票・連携の複雑さ、今後の変更予定です。まだ動いているから大丈夫と考えがちですが、保守期限や担当者退職、パッケージ不適合が見えている場合は、検討開始が遅れるほど選択肢が狭くなります。まずは現状を棚卸しし、作り直す範囲と残す範囲を切り分けることが必要です。
よくある背景・失敗しやすい理由
このテーマで相談が増える背景には、古い基幹システムのブラックボックス化があります。設計書が一部しか残っていない、帳票の意味を説明できる人がいない、サーバーやデータベースの保守期限が近い、パッケージを検討したが標準機能では現場業務が回らない、といった状況です。現場では業務を止めないためにExcelやAccess、CSV加工で補うことが多く、その場しのぎの対応が積み重なるほど、再構築時の調査範囲とリスクが大きくなります。
もう一つの背景として、担当者の交代や退職があります。長く使われている基幹システムほど、動かし方や例外処理の意味を知っているのが特定の担当者だけ、という状態になりがちです。その方が異動・退職した時点で、システムそのものは動いていても、変更できない・判断できないという別の問題が発生します。設備の老朽化だけでなく、社内で説明できる人がいなくなることも、再構築を検討すべき重要なサインです。
確認すべきポイント
ここからは、基幹システム再構築が必要になる7つのサインを一つずつ見ていきます。1つだけ当てはまる場合は延命や部分改善で対応できることも多い一方、3つ以上重なっている場合は、再構築を前提にした検討に入ったほうが結果的に費用も期間も抑えられる傾向があります。自社がどれに当てはまるかを確認しながら読み進めてください。
1. サーバーやOSの保守期限が近い
サーバーやOSの保守期限が近いは、基幹システム再構築が必要になる7つのサインを検討するうえで見落としやすいポイントです。単独では小さな課題に見えても、基幹システムでは受発注、在庫、請求、帳票、会計連携など複数業務に影響します。まず現状の使われ方、関係する部署、止められない処理、今後も残すべき運用を確認してください。この段階で無理に結論を出すのではなく、延命で足りる部分と再構築が必要な部分を分けて整理します。
2. 開発会社・保守会社がなくなった
開発会社・保守会社がなくなったは、基幹システム再構築が必要になる7つのサインを検討するうえで見落としやすいポイントです。保守を受けられる会社がない状態では、障害時の復旧やOS更新・法改正への対応が自社任せになり、業務停止のリスクが一気に高まります。まずソースコード・データベース・サーバー環境の引き継ぎ可否を確認し、他社が構築したシステムでも保守を引き継げるかどうかから判断します。
3. 仕様書がなくブラックボックス化している
仕様書がなくブラックボックス化しているは、基幹システム再構築が必要になる7つのサインを検討するうえで見落としやすいポイントです。設計書が残っていなくても、画面・帳票・データ項目・実際の操作手順から業務ロジックを再現できるケースは少なくありません。いきなり全面刷新を前提にせず、現行調査で「何が分かっていないか」を明らかにしたうえで再構築の範囲を決めることを重視しています。
4. Access・Excelでの運用が限界
Access・Excelでの運用が限界は、基幹システム再構築が必要になる7つのサインを検討するうえで見落としやすいポイントです。同時利用時の不具合、ファイル破損、サイズ上限、担当者しか触れないマクロやクエリが出てきた場合は、運用でカバーできる限界を超えているサインです。全体を作り直す前に、データベース部分だけをSQL Serverなどへ移行して延命できないかも合わせて検討します。
5. データ量増加で動作やバックアップが不安
データ量増加で動作やバックアップが不安は、基幹システム再構築が必要になる7つのサインを検討するうえで見落としやすいポイントです。夜間バッチが終わらない、月次処理に時間がかかる、バックアップを取り切れないといった症状は、業務量の増加に当初の設計が追いついていないことを示します。遅延している処理とデータ量をまず実測し、性能改善で足りるのか、構造から作り直すべきなのかを切り分けます。
6. パッケージが自社業務に合わない
パッケージが自社業務に合わないは、基幹システム再構築が必要になる7つのサインを検討するうえで見落としやすいポイントです。標準機能に業務を合わせられず、カスタマイズや運用回避が増えるほど、導入費用だけでなく将来の保守費用も膨らみます。合わない部分が本当に自社固有の業務なのか、単にこれまでのやり方なのかを整理したうえで、周辺開発で補う範囲を決めることをおすすめしています。
7. 帳票・CSV・サブシステムが増えすぎている
帳票・CSV・サブシステムが増えすぎているは、基幹システム再構築が必要になる7つのサインを検討するうえで見落としやすいポイントです。取引先ごとの帳票やCSV加工、部門ごとのサブシステムが増えるほど担当者依存が強まり、変更時の影響範囲も読みにくくなります。増えすぎた連携を一度棚卸しし、本体に統合すべきものと個別に残してよいものを分けるところから着手します。
自社で整理できること・外部に相談すべきこと
社内でまず整理できるのは、業務範囲、画面、帳票、困っている作業、保守期限、利用部署、関連するExcel・Access・CSVです。一方で、影響範囲が複数部門にまたがる、データ移行や外部連携が絡む、パッケージ比較が必要な場合は、外部の開発会社と一緒に現状整理した方が安全です。
社内で整理する際は、完璧な資料を作ろうとしないことがポイントです。実際の相談では、画面のスクリーンショット、普段使っている帳票の現物、担当者の口頭説明があれば、現行調査は十分に始められます。むしろ、資料を整えることを目的にしてしまうと着手が遅れ、保守期限や担当者の退職に間に合わなくなるほうがリスクです。
判断表
| 状態 | まず検討すること | 注意点 |
|---|---|---|
| 軽微な不具合・一部帳票の変更 | 延命・保守・部分改修 | 本体再構築の前に影響範囲を確認 |
| データ量増加・動作遅延・バックアップ不安 | DB改善・性能改善 | 根本的な業務課題が残らないか確認 |
| パッケージ標準で業務が合う | パッケージ導入 | 帳票・例外処理・データ連携を事前確認 |
| パッケージで足りない機能が明確 | パッケージ＋周辺開発 | 責任範囲と連携仕様を明確にする |
| 独自業務・例外処理が多い | スクラッチ再構築 | 要件整理と段階導入が重要 |
| 判断が難しい | 開発前診断・刷新ロードマップ | 社内稟議や他社比較に使える資料化を行う |
この表はあくまで初期の方向づけです。実際には、受発注はパッケージ、生産管理はスクラッチ、帳票出力は既存を延命、といった組み合わせになることも珍しくありません。全体を一つの方式で決めきるのではなく、業務単位で最適な方式を選び、段階的に移行していく設計のほうが、費用面でも現場の負担面でも現実的です。
相談前に準備しておく情報
相談前にすべての資料を揃える必要はありません。ただし、現行システム概要／利用部署・人数／画面一覧／帳票一覧／データ項目／外部連携／保守期限／困っている業務／パッケージ検討状況／想定予算・時期 などが分かると、初回相談の精度が上がります。
あわせて、社内での意思決定の流れ（誰が判断し、いつ稟議を通す必要があるのか）と、絶対に止められない業務・時期（月末の締め処理、繁忙期など）を共有いただけると、移行のスケジュールまで含めた現実的な提案ができます。
マクティズムの見解
マクティズムでは、基幹システムが古いからといって、すべてを一度に作り直すべきとは考えません。まず現行業務・帳票・データ連携・例外処理を棚卸しし、延命、DB改善、パッケージ活用、周辺開発、スクラッチ再構築を切り分けるべきだと考えています。
実際のご相談でも、7つのサインのうち複数が同時に当てはまっているケースがほとんどです。その場合でも、すべてを同時に解決しようとすると費用も期間も膨らむため、業務停止リスクが高い部分から優先順位をつけ、段階的に移行する進め方を基本としています。
また、再構築の判断は「システムが古いかどうか」ではなく、「今後3〜5年の業務変更に耐えられるかどうか」で考えるべきだと考えています。まずは現状を棚卸しし、どこまでを作り直し、どこを残すのかを整理したうえで、費用感と進め方を検討することをおすすめします。
基幹システムは、作って終わりではなく、業務の変化に合わせて10年単位で使い続けるものです。だからこそ、再構築の検討では「今の不便をどう解消するか」だけでなく、「今後どこが変わりそうか」を織り込んだ設計が欠かせません。まずは現状を一緒に棚卸しするところから、無理のない範囲で進めていければと考えています。
よくある質問
要件がまとまっていなくても相談できますか？
はい。現状の課題や分かる範囲の資料から、まず何を確認すべきか整理できます。無理に要件を固めてから相談する必要はありません。
仕様書や設計書が一部しかなくても相談できますか？
はい。画面、帳票、データ、業務フロー、操作手順などから現行調査を進められます。
いきなり大きな開発を依頼する必要がありますか？
いいえ。初回相談、簡易棚卸し、開発前診断・刷新ロードマップから段階的に進められます。
パッケージとスクラッチのどちらがよいか相談できますか？
はい。標準機能で合う範囲、周辺開発で補う範囲、スクラッチが必要な範囲を比較します。
500万円〜1,000万円規模の部分改善から相談できますか？
はい。DB改善、性能改善、帳票・データ連携、バックアップ自動化など部分改善から相談可能です。
相談後にしつこい営業はありますか？
ありません。まずは現状を整理し、必要な選択肢と進め方をご提案します。
