システム刷新の納期は、技術選定だけでなく、経営判断・稟議・体制構築に大きく左右されます。経営層の意思決定や社内合意にかかる時間によって、完了時期は数ヶ月から、場合によっては1年以上変わります。
スケジュールを引くときは、開発作業だけでなく、次の上流工程の期間も確保しておきます。
- 刷新時期の判断：老朽化や事業上の制約を見極める。
- 稟議と予算：投資判断に必要な承認期間を見込む。
- 体制と合意：経営層・IT部門・業務部門の準備期間を置く。
▼全体ガイドの記事
・システム刷新の完全ガイド
レガシーシステム刷新の種類・工程・費用・会社選定までの全体像については、無料ホワイトペーパー「レガシーシステム刷新の完全ガイドブック」で詳しく解説しています。
システム刷新の開発期間を左右する前提（経営判断としての位置づけ）
システム刷新の開発期間を正しく見積もるには、「技術的にどう作り替えるか」より先に、「経営としていつ踏み切るか」を明確にすることが出発点になります。老朽化したシステムは動き続けるため、着手の時期を逃しても表面上は業務が回ってしまいます。そのぶん意思決定そのものが先送りされやすいという、特有の難しさがあります。
開発期間の見積もりに入る前に、自社が「今すぐ着手すべきタイミング」にあるかを見極めることが、後続のスケジュール全体の精度を左右します。
いつ刷新に踏み切るべきか「5つのサイン」と2025年の崖
経済産業省のDXレポートは、老朽化・複雑化・ブラックボックス化したシステムを放置し、DXを推進できなかった場合のリスクを警告しています。2025年以降、年間最大12兆円という現在の約3倍にあたる経済損失が生じる可能性があり、これがいわゆる「2025年の崖」です。自社が刷新に踏み切るべき時期かどうかは、5つのサインに当てはまるかで見分けられます。
1つ目は事業戦略への不適合で、新規事業や市場の変化、データ活用の要請に既存システムが追従できない状態です。2つ目は保守費用の高騰で、IT予算の多くがシステムの維持・運営に割かれ、軽微な改修にも高額な費用がかかる状態です。3つ目はセキュリティとコンプライアンスの危機で、OSやミドルウェアのサポート終了（EOS）が迫り、脆弱性が放置されている状態です。
4つ目は外部連携の欠如で、クラウドやAPIとの連携ができず、AIやIoTといった新技術の導入が進まない状態です。5つ目は深刻な属人化で、古い言語の技術者が退職・高齢化し、システムの中身を理解できる人材が社内にごく一部しかいない状態です。いずれかに当てはまれば、今すぐ現状分析を始めるべきタイミングです。
技術手法（5R）と姉妹記事の参照先
リホストやリファクタリングなど5つの技術的アプローチは、IT部門・エンジニアの視点で使い分ける技術手法（HOW）です。一方で本記事は、なぜ・いつ刷新に踏み切るかという経営判断とプロジェクト推進の視点に重心を置き、技術選定が固まった後、あるいは並行して進めるべき意思決定プロセスを中心に取り上げます。
対象システムに適した手法や、手法ごとの開発期間・難易度の詳細は、姉妹記事「システムのモダナイゼーション」シリーズで技術手法別に解説しています（完全ガイドは別途ご参照ください）。
規模別・工程別に見る開発期間の目安
刷新に踏み切るべきタイミングを見極めたら、次は具体的なスケジュールの全体像を描く段階です。開発期間は対象範囲の規模と進め方によって大きく変動するため、まずは規模別・工程別の目安を押さえることが、計画立案の第一歩になります。
規模別の全体期間（小規模3〜6ヶ月〜大規模12〜36ヶ月）
システム刷新の全体期間は、対象範囲の規模によって大きく3段階に分けられます。小規模（対象アプリケーションが1〜3本程度で、クラウドのIaaS移行が中心）の場合は3〜6ヶ月です。中規模（対象アプリケーションが10〜30本程度で、対象範囲の分割やリプラットフォームを伴う）は6〜12ヶ月、大規模（全社基幹システムやメインフレームの刷新を含む）は12〜36ヶ月が目安です。
さらに、進め方によっても期間に幅が出ます。既存を廃棄してゼロから構築するリプレイスは6ヶ月〜2年、インフラ中心のクラウド移行は3ヶ月〜1年、業務領域ごとに段階を分けて進める段階的改善は1年〜3年を見込む必要があります。
まず対象システムがどの規模帯に当たるかを把握しておくと、経営層に説明するための大まかな期間感がつかめます。
フェーズ別の期間配分（アセスメント〜本番移行）
規模別の全体期間は、工程別に分けると見通しが立ちます。標準的なプロジェクトは4つのフェーズで進み、1つ目のアセスメント・移行性診断（現状分析）は1〜2ヶ月です。
2つ目の設計・移行方式決定・要件定義は1〜3ヶ月、3つ目のパイロット移行・検証（開発・テスト）は2〜4ヶ月、4つ目の本番移行・運用開始は3〜6ヶ月が目安です。
なお、システム構築そのもの（実装からリリースまでの工程単体）は一般的に3〜9ヶ月程度とされています。工程別の期間配分を経営層と共有しておけば、「今どのフェーズにいて、あと何ヶ月かかるのか」が分かり、途中経過での余計な不安や横槍を防ぐ効果も期待できます。
稟議・予算承認プロセスが工期に与える影響
システム刷新のスケジュールで見落とされがちなのが、実装の前段階にあたる稟議・予算承認の期間です。数千万円から数十億円規模の投資になる案件では、この意思決定の巧拙が、実装フェーズ以上にスケジュール全体を左右することも少なくありません。
経営層コミットメントと稟議を通すためのポイント
稟議・予算承認にかかる期間を一律に示すデータはありません。それでも、迅速な意思決定と予算確保の基盤になるのは、経営層の強力なコミットメントです。
稟議を遅滞なく通すには、「古いシステムを新しくする」といった現場目線の説明ではなく、経営に直結する定量的なKPIを設定して示す必要があります。たとえば「月末の締め処理時間を30%削減する」や「データを一つにまとめて在庫ロスを年間500万円削減する」といった目標です。
また、RFP（提案依頼書）で複数ベンダーから精緻な見積もりを取り、費用対効果（ROI）とコストの妥当性を数値で示すことも欠かせません。経営層が最も恐れるのは、巨額の予算超過とシステム停止リスクです。そこで、影響の少ない部門や機能から始めるパイロット導入（PoC）のロードマップも示し、段階的に進める安全な計画だと伝えることが、稟議を通すスピードに直結します。
稟議承認の遅れが招くスケジュールへの影響
稟議が滞ると、着手が後ろ倒しになります。さらに、承認を待つ間も保守費用の高騰やセキュリティリスクは進み続けるため、「2025年の崖」で示されるような放置コストが積み上がっていきます。
稟議承認が長引く案件ほど、担当者の異動や経営層の交代によって前提条件がリセットされ、説明をやり直すところから再スタートせざるを得なくなるケースも珍しくありません。
稟議のスピードを最も左右するのは、経営に直結するKPIと段階的な進め方を、セットで示せているかどうかです。準備を怠ると、実装フェーズが始まる前の段階だけで、数ヶ月から半年以上の遅延が発生することもあります。
プロジェクト体制構築とステークホルダー合意形成の期間
稟議が通った後、あるいは稟議と並行して進めるべきなのが、プロジェクトを推進する体制の構築です。
体制構築にかかる期間そのものを示すデータはありません。ただ、構想立案・アセスメントフェーズにあたる最初の1〜2ヶ月間で、確実に完了させるべき最重要タスクと位置づけられています。
PMO設置と経営層・IT部門・業務部門の三者体制
プロジェクト体制の中核は、経営陣直下のプロジェクトマネージャーを中心に、各業務部門から選出したキーマンで構成するPMO（プロジェクト管理組織）を設置することです。
IT部門に任せきりにする「丸投げ」は、システム刷新が失敗する典型例とされています。そこで、経営層・IT部門・業務部門の三者が「将来のあるべき姿」を起点に目標を共有し、全社横断でプロジェクトを推進する体制を早急に構築することが求められます。
PMOがスケジュール管理と部門間調整をまとめて担えば、後述する要求の食い違いや意思決定の遅れといった遅延要因を未然に防げます。一方で、体制構築を後回しにして実装フェーズに入ると、途中で判断すべき事項が滞留し、結果としてPMOを後追いで設置する羽目になるケースが少なくありません。
合意形成に時間をかけることが後工程の遅延を防ぐ理由
体制構築の初期段階で意思統一に丁寧に時間をかけることが、後々のトラブルやスケジュール遅延を防ぐ最大の鍵になります。
経営層・IT部門・業務部門は、投資対効果、技術的な実現可能性、日々の業務のしやすさという異なる評価の観点を持っています。そのため、初期段階で目標のすり合わせを省くと、実装が進んだ後に「聞いていた話と違う」という食い違いが表面化し、要件の後戻りを招きます。
一見すると、合意形成に充てる1〜2ヶ月は遠回りに見えます。しかし、この期間を確保することが、実装フェーズ以降の手戻りを減らし、結果的にトータルの納期を短縮することにつながります。
納期を左右する遅延要因と対策
稟議や体制構築のプロセスを丁寧に踏んだとしても、実装フェーズに入ってから生じる遅延要因は別に存在します。経営・PMの視点で押さえておきたい代表的な遅延要因は、大きく4つに整理できます。
経営判断の遅れ・部門間調整・要件定義の曖昧さ
1つ目の遅延要因は、経営判断の遅れと部門間調整の難航です。現場の意見が一致せず、各部門が異なる要求を持ち出すと方向性が定まらず、最終的な意思決定が遅れて、プロジェクト全体のスケジュールに深刻な影響が及びます。PMOによる強力な統制がなければ、スケジュールもコストも制御不能に陥りかねません。
2つ目は要件定義の曖昧さと仕様変更です。導入目的が不明確なまま進めると、開発途中で仕様変更や追加要件が頻発し、スケジュールが大幅に悪化します。
特に、開発フェーズのなかでもテスト以降の設計変更は遅延の最大要因となるため、「追加要件は原則として運用開始後に対応する」といった厳格なルールを、あらかじめ策定しておくことが求められます。
データ移行の過小評価とベンダー選定ミスという実務リスク
3つ目はデータ移行の過小評価で、不要データの整理（データクレンジング）や不整合の解消に手間取り、移行作業が大幅に遅れるケースが多発しています。データ移行は実装フェーズの終盤に位置することが多く、ここでのつまずきは、それまで順調だったスケジュールを一気に押し流してしまう厄介な遅延要因です。
4つ目はベンダー選定のミスで、プロジェクト管理能力が不十分なベンダーを選ぶと、納期が半年以上遅延する事態も実際に発生しています。そこで、選定では価格だけでなく、類似プロジェクトでの実績や進捗管理体制を厳格に評価することが、この種の遅延を防ぐ最も確実な対策です。
みずほ銀行では2021年2月、システムの複雑化・属人化・リスク認識の不足からATM障害が起き、通帳とカード約5,000枚が取り出せなくなりました。原因区画の特定から再立ち上げ完了までに8時間を要しました。また、スルガ銀行と日本IBMの間では、業務要件に合わないパッケージ選定と要件定義の甘さからプロジェクトが白紙撤回となり、最終的に日本IBM側に約42億円の賠償命令が下されています。
まとめ
ここまで、開発期間・スケジュール・納期について、経営判断の前提から遅延要因と対策まで順に見てきました。
開発期間を正しく見積もるには、技術的な移行作業としてだけでなく、経営判断とプロジェクト推進のプロセスとして捉えることが鍵になります。
全体期間は小規模で3〜6ヶ月、大規模で12〜36ヶ月が目安ですが、稟議・予算承認と体制構築という上流工程を丁寧に踏むかどうかで、実装フェーズ以降の遅延リスクは大きく変わります。
技術的な移行手法の詳しい選び方は、姉妹記事「システムのモダナイゼーション」もあわせてご参照ください。そのうえで、経営とプロジェクト推進の両面から計画を練ることをお勧めします。
▼全体ガイドの記事
・システム刷新の完全ガイド
▼開発を相談する前に読みたい無料ホワイトペーパー
・レガシーシステム刷新の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。