「基幹システム刷新を、何から始めればいいのか」——中堅企業の経営者からよく出るご相談です。多くの解説記事は「現状分析→ベンダー選定→…」と流れを並べるだけで、各ステップで経営者が何を判断し、誰に任せ、何を見届けるべきかまでは踏み込んでいません。本記事では、汎用機・オフコンからオープン系・クラウド基盤への移行プロジェクトに 25 年携わってきた立場から、基幹システム刷新の進め方を 7 つのステップに分け、各ステップでの意思決定の流れを整理します。
進め方が見えないまま着手していませんか？ 7 ステップの整理は専門家との対話が早道です。 無料相談 ＞結論：基幹システム刷新は『7 つのステップ』で進める
本記事の結論を先に示します。基幹システム刷新は、以下の 7 つのステップ で進めるのが、中堅企業の経営者にとって最も無理がなく、失敗を回避しやすい流れです。
- 経営判断の整理：なぜ今刷新するかを経営層が言語化する
- 現状把握・業務棚卸し：システムと業務の見える化
- 目的とゴールの明文化：刷新後にあるべき状態を定義
- 方式選定：リプレース／リライト／リホストの判断
- ベンダー選定と要件定義：パートナーと要件詳細化
- 設計・開発・テスト：構築と検証
- 本番稼働と定着化：稼働後 90 日の支援を含めた完了
多くの解説記事は「5 ステップ」または「6 ステップ」で説明していますが、クオンツは 『ステップ 1：経営判断の整理』と『ステップ 7：稼働後の定着化』を独立した工程として明示 しています。この前後 2 ステップを軽視するプロジェクトが、現場で最も失敗しているからです。
なぜ「7 ステップ」で進めるのか
基幹システム刷新が失敗するパターンを見てきた経験から、失敗には共通点があります。「現状分析からいきなり始める」「稼働させたら終わり」 という、前後 2 ステップを欠いた進め方です。
現状分析の前に「経営判断の整理」がないと、プロジェクト中盤で「そもそも何のために刷新するのか」が現場と経営層でズレ、スコープが肥大化したり、追加投資の判断ができなくなったりします。一方、稼働で終わってしまうと、本番直後の問い合わせ・不具合対応・業務定着の支援が手薄になり、「使われないシステム」が出来上がります。
本記事の 7 ステップは、この 前後 2 ステップを意図的に独立させた ものです。経営者として、各ステップで何を判断すべきかを意識して進めていただくと、プロジェクト全体の見通しが格段に良くなります。
基幹システム刷新の 7 ステップ詳細
ステップ 1：経営判断の整理（所要 1 ヶ月）
最初に、経営層自身が 「なぜ今、刷新するのか」 を言語化します。技術的な必要性ではなく、経営課題としての必要性です。
判断軸の例：保守終了の迫り具合、業務効率の低下、属人化・ブラックボックス化のリスク、業務変化への対応コスト、競合との差別化要素など。経営層が答える問いであって、情シスや現場が答える問いではありません。
このステップを 1 ヶ月かけて整理すると、後続のすべての判断が一貫します。逆にここを飛ばすと、ベンダー選定で「何を基準に選べばいいか分からない」「ベンダーの提案に流される」状態になります。
ステップ 2：現状把握・業務棚卸し（所要 1〜3 ヶ月）
業務とシステムの両面で現状を見える化します。システム側は機能の使用頻度、データ構造、外部接続、保守状況など。業務側は実際に動いているプロセス、属人化している作業、Excel で代替されている業務、現場の不満点など。
ここで重要なのは、「ベンダーに任せず、自社で実施する」 ことです。社内の業務責任者と情シスがチームを組んで、2〜3 ヶ月かけて棚卸しします。コンサルや外部支援を入れる場合も、最終的なまとめは自社で持つようにしてください。
ステップ 3：目的とゴールの明文化（所要 2〜4 週間）
ステップ 1 の経営判断と、ステップ 2 の現状把握をつなぎ、「刷新後にあるべき状態」を文書化 します。これが要件定義の前提となる「あるべき姿（To-Be 像）」です。
ゴールの例：販売管理と在庫管理がリアルタイム連携している、月次決算が 5 営業日以内に締まる、外部 EDI と直接接続している、属人化していた発注業務が標準化されている、など。「業務がこうあってほしい」を経営層・現場・情シスで合意 するのが、このステップのゴールです。
ステップ 4：方式選定（所要 1〜2 ヶ月）
ステップ 3 のゴールを実現するために、どの方式で刷新するかを決めます。中堅企業で現実的な選択肢は 3 つです。
- リプレース（パッケージ導入）：業務をパッケージに合わせる。費用 3,000 万〜8,000 万円、期間 10〜14 ヶ月
- リライト（再構築）：業務独自性を活かして作り直す。費用 8,000 万〜2 億円、期間 18〜24 ヶ月
- リホスト（オープン化）：物理的な延命のみ。費用 2,000 万〜5,000 万円、期間 8〜12 ヶ月
判断軸は「業務独自性の強さ」「時間的猶予」「予算規模」「業務改革をどこまで伴うか」の 4 つ。経営層が方式を決める ステップであり、ここでベンダーの言いなりにならないことが、後の主導権を握る鍵になります。
ステップ 5：ベンダー選定と要件定義（所要 3〜5 ヶ月）
方式が決まったら、RFP（提案依頼書）を作成し、複数ベンダーから提案を取ります。「対話できるベンダーかどうか」 を最も重視してください。価格や機能比較表だけでなく、現場ヒアリングへの参加意欲、業務理解の深さ、過去案件の失敗からの学びなどを、対話を通じて見極めます。
選定後、要件定義に入ります。ここで 『Fit to Standard（パッケージ標準に業務を合わせる）』vs 『カスタマイズで業務を再現する』 の判断軸を、要件定義の入口で明示することが重要です。判断軸がないと、現場の「これも、あれも」が積み重なり、カスタマイズが肥大化してプロジェクトが破綻します。
ステップ 6：設計・開発・テスト（所要 6〜12 ヶ月）
要件定義に基づき、ベンダー側が設計・開発を行います。経営層の役割は、節目ごとの判断とリスク管理。具体的には、基本設計レビュー、詳細設計レビュー、結合テスト結果レビュー、ユーザー受入テスト（UAT）の合否判定です。
「テストを後で取り戻せる」と考えるのが、最も危険な誤解です。テスト時間を削るプロジェクトは、ほぼ確実に本番直後に障害を出します。経営層が「期間を縮めるよりテストを厚くする」判断を支持することが、稼働後のトラブル回避に直結します。
ステップ 7：本番稼働と定着化（所要 3〜6 ヶ月）
本番稼働は、プロジェクトの終わりではなく 「定着化フェーズの始まり」 です。多くのプロジェクトはここで力尽きますが、稼働直後の 90 日が、新システムが現場に根付くかどうかの分水嶺になります。
このフェーズで経営層が見届けるのは：問い合わせ件数の推移、現場の不満度、業務 KPI の改善傾向、ベンダーのサポート対応の質、追加カスタマイズ要求の妥当性、など。稼働 3 ヶ月時点で「投資対効果が見え始めているか」 を経営層が判定する。これが 7 ステップの締めくくりです。
各ステップで経営層が関わる『意思決定の流れ』
7 ステップを通じて、経営層が判断すべき意思決定ポイントを整理します。
| ステップ | 経営層の意思決定 | 所要 |
|---|---|---|
| 1. 経営判断の整理 | 刷新の必要性・優先度・投資判断 | 1 ヶ月 |
| 2. 現状把握 | 棚卸しの範囲とリソース投下量 | 1〜3 ヶ月 |
| 3. ゴール明文化 | To-Be 像の最終承認 | 2〜4 週間 |
| 4. 方式選定 | リプレース／リライト／リホストの選択 | 1〜2 ヶ月 |
| 5. ベンダー・要件定義 | ベンダー決定、Fit to Standard の方針 | 3〜5 ヶ月 |
| 6. 設計・開発・テスト | 各レビューの合否、追加要件の判断 | 6〜12 ヶ月 |
| 7. 稼働・定着 | 稼働可否、定着化評価、投資対効果判定 | 3〜6 ヶ月 |
通算 14〜30 ヶ月（標準は 18〜24 ヶ月）。「短期で済ませたい」気持ちは分かりますが、各ステップに必要な時間を縮めようとすると、必ず別のステップに歪みが出ます。経営者として、各ステップの時間を確保することが、最大のリスク回避策 です。
進め方を間違える 4 つのパターン
最後に、進め方を間違えた結果プロジェクトが破綻した、典型的な 4 パターンを共有します。
パターン 1：ステップ 1 を飛ばして、いきなりベンダー提案に乗る
「動いてはいるけど、そろそろ刷新したい」と漠然と思い、ベンダーから来たデモや提案に乗ってしまうケース。経営判断の軸がないため、要件定義以降で「これは違う」が頻発し、手戻りが連続します。
パターン 2：ステップ 2 をベンダーに丸投げする
現状把握をベンダーやコンサルに任せてしまうケース。業務の本当の問題は社内の人間にしか分かりません。外部に整理されると、表面的な事象だけが「課題」として上がり、本質を見逃します。
パターン 3：ステップ 5 で Fit to Standard を曖昧にする
「パッケージ標準に合わせる」と決めたはずが、各部門から「これだけは現行通りに」が積み重なり、結果としてカスタマイズが当初見積もりの 2〜3 倍に膨らむケース。『標準に合わせる領域』『独自性を残す領域』を要件定義の入口で経営層が明示 しないと、ほぼ必ず発生します。
パターン 4：ステップ 7 を計画していない
稼働まではしっかり計画されているが、稼働直後の問い合わせ対応・業務定着支援の予算と体制が組まれていないケース。本番直後の数ヶ月は問い合わせが爆発するため、ここを軽視すると現場の不信感が一気に高まります。
まずは「次の一歩を整理する」から
ここまで、基幹システム刷新を 7 ステップで進める方法と、各ステップでの経営層の意思決定ポイント、よくある失敗パターンを整理してきました。
実際のプロジェクトでは、自社の状況に応じてステップの所要期間や深さを調整する必要があります。「自社の場合、ステップ 1 をどう整理すればいいか分からない」「ステップ 4 の方式選定で迷っている」 という段階でのご相談を、株式会社クオンツでは無料で受け付けています。
汎用機・オフコンからオープン系・クラウド基盤への移行プロジェクトに 25 年携わってきた経験から、机上の整理ではなく、お客様の現場と並走するスタイルで、次の一歩の選択肢を整理します。難易度の高い案件ほど燃えるタイプ なので、複雑なケースほどお声がけください。
