「12 ヶ月で稼働できますか？」——基幹システム刷新の検討初期に、経営者から最もよく出る質問です。結論から言うと、中堅企業の刷新は 12～24 ヶ月 が標準。さらに、これは『要件定義から稼働まで』の期間で、その前段の 検討フェーズ（経営判断・RFP 作成・ベンダー選定）に 3～6 ヶ月 が別途必要です。本記事では、フェーズ別の期間目安、規模・方式別の総期間、延びる典型要因、短縮のポイントを整理します。
自社のスケジュール、現実的ですか？ 経験ベースで期間設計の妥当性を一緒に検証します。 無料相談 ＞結論：中堅企業の標準期間は『12～24 ヶ月』
中堅企業（売上 30～300 億円、従業員 50～500 名）が基幹システム刷新を行う場合、要件定義から本番稼働までの標準期間は次のとおりです。
| 規模・方式 | 標準期間 | 備考 |
|---|---|---|
| リプレース（パッケージ導入） | 10～14 ヶ月 | Fit to Standard 中心の場合 |
| リライト（業務改革を伴う再構築） | 18～24 ヶ月 | 業務プロセス再設計を含む |
| リホスト（オープン化のみ） | 8～12 ヶ月 | 機能はそのまま、基盤のみ移行 |
| 段階移行（フェーズ分割） | 18～30 ヶ月 | 会計→販売管理→生産管理 等で分割 |
これらは 要件定義開始からの期間 です。この前段に 検討フェーズ（経営判断 → 現状整理 → RFP → ベンダー選定 → 契約）で 3～6 ヶ月 必要なため、経営層がスタートを切ってから稼働までの実時間は 標準で 15～30 ヶ月 になります。
フェーズ別の期間目安
刷新プロジェクト全体を 6 フェーズに分け、それぞれの目安期間と中身を整理します（リプレース型・中堅中規模を想定）。
| # | フェーズ | 期間目安 | 主な内容 |
|---|---|---|---|
| 0 | 検討フェーズ | 3～6 ヶ月 | 経営判断・現状整理・RFP・ベンダー選定・契約 |
| 1 | 要件定義 | 3～4 ヶ月 | 業務分析・標準/独自仕様の仕分け・要件確定 |
| 2 | 設計 | 2～3 ヶ月 | 基本設計・詳細設計・データモデル設計 |
| 3 | 開発・カスタマイズ | 4～6 ヶ月 | パッケージ設定・カスタマイズ開発・帳票作成 |
| 4 | テスト | 2～3 ヶ月 | 単体テスト・結合テスト・UAT・運用テスト |
| 5 | データ移行・並行稼働 | 1～2 ヶ月 | 本番データ移行・並行運用・稼働判定 |
| 6 | 稼働後の定着化 | 3 ヶ月 | 運用サポート・追加教育・チューニング |
フェーズ 1～5 を合算すると 12～18 ヶ月。これに検討フェーズ（3～6 ヶ月）と定着化フェーズ（3 ヶ月）を加えると、経営判断から成果獲得までの実時間は 18～27 ヶ月 になります。「12 ヶ月で稼働」という設計は、要件定義以降の期間しか見ていない可能性が高いので注意してください。
規模別・方式別の期間
規模別（リプレース型・パッケージ導入）
| 従業員規模 | 要件定義 ～ 稼働 | 検討含む総期間 |
|---|---|---|
| 50～150 名 | 10～12 ヶ月 | 13～18 ヶ月 |
| 150～300 名 | 12～14 ヶ月 | 15～20 ヶ月 |
| 300～500 名 | 14～18 ヶ月 | 17～24 ヶ月 |
方式別の期間特性
- リホスト：機能はそのままで基盤のみ移行するため、要件定義が比較的軽く、最短 8 ヶ月程度から可能
- リプレース：パッケージ標準への業務適合がメインで、Fit to Standard の比率が高いほど短期化
- リライト：業務プロセス再設計を伴うため要件定義が重く、18～24 ヶ月が標準
- 段階移行：1 フェーズあたり 6～10 ヶ月、全体では 18～30 ヶ月
期間が延びる『5 つの典型要因』
当初の見積もりから期間が延びる典型的な要因を 5 つ整理します。スケジュール設計時にこれらをリスクとして織り込んでおくと、現実的な計画になります。
要因 1：要件定義で『決め切れない』
要件定義フェーズで「現状再現にするか／Fit to Standard で進めるか」を経営層が決め切れず、議論が長引くケース。要件定義が 1 ヶ月延びると、後続フェーズもまるごと 1 ヶ月後ろ倒し になります。
要因 2：ベンダー選定の遅れ
複数ベンダーから提案を取り、比較・交渉している間に、想定の倍以上の時間が掛かるケース。3 社から 6 社に増やすと、選定だけで 2 ヶ月以上延びる。社数は 3 社に絞り、RFP の質を上げる方が効率的です。
要因 3：テスト不足による稼働延期
テスト段階で次々と問題が見つかり、当初の稼働予定日に間に合わないケース。テスト消化率が 50% の段階で稼働判定はできない。テスト期間を 2～3 週間延ばす経営判断が、最終的な被害を最小化します。
要因 4：データ移行の想定外
過去 10～20 年のデータを新システムに移行する際、想定外の例外データ・データ品質問題が発覚し、移行作業が長引くケース。データ移行はフェーズ 1（要件定義）の段階から並走 で進めるのが鉄則です。
要因 5：経営判断の停滞
スコープ変更・追加予算・体制変更などの判断が経営層レベルで止まり、現場が動けないケース。ステアリングコミッティーが意思決定の場として機能 していないと、判断のための判断会議が増えて期間が延びます。
期間を短縮するための『3 つのポイント』
ポイント 1：検討フェーズで決め切る
要件定義に入る前の検討フェーズで 「何をやるか／何をやらないか」を経営層が決め切る。検討に 3～6 ヶ月かけても、要件定義以降が短縮されれば総期間は短くなります。逆に、検討フェーズを 1 ヶ月で済ませると要件定義が 6 ヶ月に延びがちです。
ポイント 2：Fit to Standard で要件を絞る
パッケージ標準で吸収できる業務範囲を最大化することで、開発・カスタマイズ・テストの工程が大幅に短縮されます。カスタマイズ比率を 30% 以下に抑えた プロジェクトは、ほぼ標準期間内に収まります。
ポイント 3：段階移行を選ぶ
逆説的ですが、一度に全部移行するより 会計 → 販売管理 → 生産管理 のように段階移行 する方が、各フェーズが独立して進められるため『現場の混乱が少ない＝結果的に早い』ケースがよくあります。総期間は延びるものの、各業務領域の稼働は早くなります。
まとめ｜『期間』は経営判断の質で決まる
基幹システム刷新の期間は、技術的な要因より 経営判断のスピードと質 で決まります。スコープを決め切る、ベンダーを選び切る、稼働判定を下す——これらの判断が遅れるたびに、プロジェクトは数週間～数ヶ月単位で延びます。経営層がプロジェクトに対して「いつでも判断する用意がある」状態を維持できるかが、期間の長短を分けます。
株式会社クオンツでは、『現実的な期間設計』『スケジュール短縮の判断ポイント』『遅延リスクの可視化』 のご相談を、無料で受け付けています。汎用機・オフコンからオープン系・クラウド基盤への移行プロジェクトに 25 年携わってきた経験から、貴社の業種・規模・方式に合わせた現実的なスケジュールと、短縮のポイントを一緒に整理します。机上のコンサルではなく、お客様の現場と並走するスタイルで、次の一歩の選択肢を整理します。
