止められない基幹システムを段階的に刷新したい企業にとって、最初から大きな開発を決める必要はありません。まずは現行業務・帳票・データ・連携・保守状況を整理し、延命、部分改善、パッケージ活用、周辺開発、スクラッチ再構築のどれが現実的かを見極めることが重要です。
マクティズムでは、作り直しありきではなく、止めないことを前提に、先に切替単位を決めることを重視して進め方を整理します。
この記事では、現在の基幹システムを止めずに使い続けながら、段階的に新しい仕組みへ移行する方法を整理します。システムを止められない事情と、刷新の必要性の板挟みにある企業の担当者・経営者に向けた内容です。
この記事で分かること
- 基幹システム見直しで確認すべきポイント
- 延命・部分改善で済むケース
- パッケージ活用や周辺開発を検討すべきケース
- スクラッチ再構築を検討すべきケース
- 相談前に準備しておく情報
まず結論｜すぐに作り直す前に現状を整理する
基幹システムは、受注・出荷・在庫・請求・生産・会計連携など、複数の業務にまたがります。そのため、表面上の不具合だけを見て判断すると、後から帳票、データ移行、外部連携、現場運用で想定外の問題が出ることがあります。
まず必要なのは、現行システムの全体像を把握することです。特に、どの業務が止まると困るのか、どの帳票が実際に使われているのか、どのExcel・Access・CSV運用が周辺に残っているのかを確認するだけでも、再構築の方向性はかなり明確になります。
「止められない」は制約であると同時に設計の前提
基幹システムを止められないのは、業務が動いているからです。この制約は段階的な刷新の障害ではなく、設計の出発点として受け入れるべきものです。「止めないこと」を前提に置いた瞬間、切替単位の設計、新旧の共存期間中のデータ連携、切り戻しの手順という三つの必須テーマが明確になります。止めないための技術は確立されており、正しく設計すれば実現可能です。
先に切替単位を決める——粒度が成否を分ける
段階刷新で最初に決めるべきは、何を単位として切り替えるかです。業務単位（販売→在庫→請求）、拠点単位（A拠点→B拠点）、機能単位（入力系→帳票系→連携系）。どの粒度で切るかによって、新旧の共存期間中に必要な一時的連携の複雑さが変わります。一時連携のコストを含めて最も総コストが低い切り方を選ぶのが原則です。
このテーマでよく起きる問題
このテーマでよく起きる問題は、技術的な問題に見えて、実際には業務整理の不足から起きていることが多いです。たとえば、同じ機能でも部署ごとに運用が違う、帳票は同じ名称でも用途が違う、CSVの出力タイミングが担当者依存になっている、といったケースです。
この状態でパッケージを入れたり、スクラッチで作り直したりすると、開発途中で追加要件が増え、費用と期間が膨らみやすくなります。
よくある失敗は、保守しながら刷新するつもりが、保守の作業に追われて刷新が後回しになり続けるケースです。保守と刷新を同じ担当者が兼務すると、日々の障害対応や改修依頼が優先され、刷新のタスクは常に後ろに回されます。保守チームと刷新チームを分ける、あるいは曜日や期間で明確に役割を分けることが必要です。
また、新旧共存期間のデータ連携を「とりあえずCSVで」と安易に設計し、両方のシステムでデータの不整合が発生するケースも多くあります。一時的な連携であっても、どちらを正とするか、更新の方向はどちらからどちらか、同期の頻度はどうするかを設計しておかないと、二重メンテナンスの地獄に陥ります。
さらに、刷新の各段階の完了基準を決めていないと、「もう少し安定するまで次へ進まない」というブレーキが永遠にかかり続けます。完了の条件を数字で定義し、満たされたら次へ進む判断を自動的に行える仕組みを作ってください。
自社で確認できるチェックポイント
段階刷新を計画する前に、次の点を確認しておくと、切替単位の設計が具体的になります。
- 現在のシステムで実際に困っている業務を1つずつ書き出す
- 画面・帳票・CSV・バッチ・Excel補完作業を棚卸しする
- 利用部署、利用人数、締め処理、止められない業務を確認する
- サーバー、データベース、外部連携、バックアップの状態を確認する
- 現行システムを残す部分、直す部分、作り直す部分を分ける
- パッケージで足りる業務と、周辺開発が必要な業務を分ける
- 初期費用だけでなく、保守・追加改修・移行リスクも比較する
段階刷新ならではの棚卸しポイント
基本のチェックリストに加えて、業務間・拠点間のデータのつながり（どの業務のデータがどこへ流れるか）、保守の負荷が最も高い業務（障害頻度・改修要望の多さ）、刷新の優先度が高い業務（老朽化・業務影響の大きさ）、そして保守チームと刷新チームの人員見通しを確認してください。保守負荷が高い業務を先に刷新すれば、後続の段階では保守の手が空き、刷新に振り向けられるリソースが増えるという好循環が生まれます。
段階刷新では、各段階の投資とリターンを個別に評価できることが大きな利点です。第一段階で効果が出なければ計画を見直し、効果が出れば自信を持って次へ進める。この「途中で止められる安全装置」は、全面一括の刷新にはない構造的な強みです。
段階刷新中の現行システムの保守では、「新システムに移る予定の業務」に対する大きな改修を避ける判断も必要です。近い将来作り直す部分に投資しても回収できないため、障害対応と最小限の維持に絞り、改善要望は新システムの要件として蓄積する運用にすると、投資の無駄を防げます。
また、段階刷新の進捗を社内に定期的に発信することも忘れないでください。数年にわたる取り組みでは、成果が見えないと「いつ終わるのか」という不満が生まれます。各段階の完了ごとに改善効果を数字で共有し、次の段階への理解を得る発信が、計画の持続力を支えます。
延命・部分改善で対応できるケース
段階刷新の第一歩は、大きな開発である必要はありません。次のような着手が効果的です。
- 対象業務が限定されている
- 帳票やCSV連携の一部改善で足りる
- データベース改善やバックアップ自動化で安定運用できる
- 利用者が限られており、現場への影響が小さい
- 将来の全面刷新までの橋渡しとして改善したい
まず、保守負荷が最も高い業務を特定し、その業務だけを新しい仕組みに置き換える。たとえば、帳票出力や連携処理が頻繁に障害を起こしているなら、そこだけを先に切り出して構築するだけで、保守チームの負荷が目に見えて下がります。
また、新しい仕組みを作る前に、現行システムのドキュメント化を先行して進めるのも有効な第一歩です。ドキュメントが整えば、後の段階で要件定義と移行の精度が上がります。
費用の目安は、各段階の規模によって異なりますが、第一段階は500万〜1,500万円・3〜6か月が典型的です。新旧の一時連携の開発費を忘れずに含めてください。全段階の累計では、一括刷新より1〜2割高くなることが一般的ですが、リスクの分散と途中判断の余地というメリットで十分に釣り合います。
パッケージ活用・周辺開発・スクラッチ再構築を検討すべきケース
段階刷新の各段階で、方式の選択肢は次のように変わります。
- 保守期限が近く、現行環境を長く使えない
- 開発会社がなく、改修や障害対応が難しい
- Access・Excel・古いDBではデータ量や運用に限界がある
- パッケージ標準機能が業務に合わない
- 周辺システムや帳票が増え、全体像が分からない
- 今後も機能追加や外部連携が増える見込みがある
パッケージ活用が向くケース
パッケージを核にする場合は、パッケージ本体の導入を一つの段階に据え、前段にデータ整備、後段に周辺連携を配置する形が自然です。パッケージの導入自体を一括で行い、段階性は前後の周辺で確保する考え方です。
周辺開発で補うケース
周辺開発を積み重ねて実質的に刷新する「ストラングラーパターン」は、段階刷新の最も典型的な方式です。古い機能を新しい周辺に一つずつ移し替え、最後に古い本体を停止する。移行のリスクを最小化できます。
スクラッチ再構築が向くケース
スクラッチで全面再設計する場合でも、リリースを業務単位に分けることで段階性を確保できます。設計は全体で行い、構築と稼働を段階で分ける。設計の一貫性と導入のリスク分散を両立する方式です。
マクティズムの見解
マクティズムの見解として、既存基幹システムを保守しながら段階的に刷新する方法では「何を作るか」より先に「何を残すか、何を直すか、何を作り直すか」を決めることが重要です。
特に、止めないことを前提に、先に切替単位を決めることを意識しないまま進めると、パッケージを入れても周辺Excelが残ったり、スクラッチで作っても現場が使いにくかったりします。相談段階では、資料が完全にそろっていなくても問題ありません。画面、帳票、運用メモ、担当者の記憶を集めるところから始めるべきです。
段階刷新の相談では「止められない」という制約を前向きに受け止めることから始めます。止めないための設計は、止められる計画より堅実で、途中判断の余地があるからこそ失敗に強い。この考え方をお客様と共有したうえで、一緒に一段ずつ登る計画を作ります。焦らず、でも止まらず。段階刷新の本質は、この持続する歩みにあります。
相談前に準備しておく情報
段階刷新の相談では、現行システムの構成と保守の負荷状況、業務間のデータの流れ、刷新の優先度の高い領域、保守と刷新に割ける人員の見通しが分かると、初回から切替単位の設計を具体的に話せます。
実務では、現行調査で保守負荷と刷新優先度の両面を評価し、開発前診断で切替単位の候補と一時連携のコストを比較したうえで、各段階の完了基準を含めた計画に落とし込む流れをおすすめしています。
段階刷新が完了に近づくにつれ、保守の負荷が段階的に下がり、チームの余力が生まれます。この余力を次の段階に振り向ける好循環が回り始めたとき、計画は安定軌道に乗ったと言えます。
止められないシステムを変えるのは、走りながらエンジンを交換するようなものです。確かに難しい仕事ですが、段階を踏めば確実に前に進めます。そしてすべての段階を終えたとき、「止めずにここまで来られた」という達成感は格別です。
進め方は、保守負荷と刷新優先度の評価、切替単位の設計、一時連携の設計、第一段階の構築、完了判定と次段階の判断、の繰り返しです。各段階の完了を確認してから次へ。この規律が段階刷新の生命線です。
段階刷新は長い道のりですが、一段ずつ登ることの安心感と達成感は一括にはない魅力です。走りながら変える力を身につけた組織は、次の変化にも柔軟に対応できます。
段階刷新の力は、完走の確度にあります。一段ごとに効果を確認し、止める選択肢も持ちながら進む。この安全装置付きの進め方だからこそ、最後まで走りきれるのです。
一段目を登り終えたとき、「次もいける」という確信が生まれます。その確信が、計画を最後まで支える燃料になります。
止められないシステムを変える難しさを乗り越えた経験は、組織にとってかけがえのない財産になります。
一段ずつ、着実に。その歩みの先に、止めずに完走した誇りが待っています。
焦らず、止まらず。その規律が段階刷新を完走に導きます。
よくある質問
保守期限が近い場合、いつから相談すべきですか？
規模にもよりますが、基幹システム再構築は1年〜1.5年以上かかることがあります。保守期限が見えた時点で現状整理を始めるのが安全です。現行の構成と保守で困っている箇所が分かれば十分に相談を始められます。
要件がまとまっていなくても相談できますか？
はい。分かる範囲の業務内容、現在困っていること、使っている画面や帳票から整理できます。完璧な資料よりも、現状の困りごとを早めに共有することが大切です。はい。段階刷新の第一歩は、保守負荷の高い部分の改善から始めるのが最も効果的です。
すぐに全面再構築する必要がありますか？
いいえ。延命・部分改善で足りる場合もあります。まずは残す部分、直す部分、作り直す部分を切り分けます。段階ごとにパッケージと個別開発を使い分ける設計も含めて、一緒に判断します。
パッケージとスクラッチのどちらがよいか判断できますか？
はい。業務が標準機能に合うか、帳票や例外処理をどう扱うか、将来の保守性まで含めて比較します。はい。ドキュメント化や一領域の先行構築など、小さな第一段階から対応しています。
500万円〜1,000万円規模の部分改善から相談できますか？
はい。データベース改善、帳票・連携、バックアップ自動化など、段階的な改善から始められる場合があります。止められない不安をお聞かせください。止めないための設計から一緒に始めましょう。
相談後にしつこい営業はありますか？
ありません。現状を確認したうえで、必要な進め方を整理します。無理に大きな開発を勧めることはありません。
