大規模システム開発の期間と納期は、部門間の合意形成、進捗管理、段階的なリリース、ベンダー調整を踏まえて組むと現実的になります。小規模開発の速さのまま進めると、要件定義に半年かかることに戸惑い、計画がずれてしまいます。
全体像は、大規模システム開発の完全ガイドもご覧ください。
▼全体ガイドの記事
・大規模システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
大規模システム開発の期間・規模感
大規模開発の期間は、作業量だけでなく、関係者の多さによって大きく変わります。基幹システムやERPでは数十名から数百名が関わり、調整、合意形成、整合性の確保にも時間がかかるためです。
大規模開発では、数十億円規模の投資と1年から3年の期間が必要になる場合があります。一方で、数百万円・少人数・数ヶ月で立ち上げる小規模開発とは、規模だけでなく複雑性も異なります。発注側はまず、規模の目安と工程ごとの期間配分を確認します。
小規模開発のように、作りながら決めたり一人の判断で方針を変えたりする進め方は、大規模では通用しません。そのため、入念な準備と厳格な工程管理が成否を左右します。
大規模システムの規模の目安
大規模システムに明確な定義はないものの、一般には、予算5,000万円から1億円以上、期間12ヶ月から2年以上、数十名から数百名で構築する基盤システムを指すことが多いです。
前段の規模の目安に当てはまる代表的なシステムには、次のようなものがあります。
- 全社統合ERP
- 金融機関の勘定系システム
- 製造業の生産管理基幹
- 大手ECの受注・在庫・決済基盤
- 官公庁の行政システム
これらには、複数の部門や既存システム、拠点が関わり、一部が止まると事業全体に波及するという共通点があります。小規模開発では予算や人手が制約になりやすいのに対し、大規模開発では関係者と影響範囲の広さが制約になります。
この違いがスケジュールの立て方を分けます。小規模の延長で考えず、規模が大きくなると複雑性も段違いに増えると理解することが、現実的な期間設定の第一歩になります。
工程別の期間配分と要件定義の重み
要件定義の期間と準備を考えるうえで、独立行政法人情報処理推進機構（IPA）が示すウォーターフォール開発の標準配分が参考になります。
- 工程配分：IPAの標準配分では、要件定義が約25%、設計からテスト・リリースまでが約75%を占めます。
- 期間の目安：全体が2年（24ヶ月）なら要件定義は約6ヶ月で、小規模開発の数日から数週間と比べて十倍以上です。
- 手戻りの影響：数百名が動き出した後に要件漏れが見つかると、修正に膨大な工数と費用がかかります。
- 上流工程の役割：仕様を徹底して固めます。後工程の手戻りが致命的なコスト増を招くためです。
- 発注側の準備：要件定義という見えにくい期間も確保することが、納期を守る近道です。設計を急がず、腰を据えて進めます。
要件定義が長期化する構造と合意形成
大規模開発で最も期間を読みにくいのが要件定義です。経理・営業・製造・人事・情報システムなど、多数の部門がそれぞれ異なる要望を持ち込むためです。
小規模開発では発注者が1〜2名のため、意思決定も要件確定も速く進みます。一方で、大規模開発では関係者の多さそのものが、要件定義を長期化させる構造的な要因になります。合意形成に時間がかかるのは、各部門が自部門の事情を優先しやすいからです。
全体最適と部分最適の衝突・サイロ化
要件定義では、全体最適と部分最適がぶつかります。たとえば、次のように部門間で利害が対立します。
- 営業部門：顧客情報の入力項目を増やしたい
- 経理部門：入力項目をできるだけ簡素にしたい
各部門は自部門の業務効率を優先しがちで、システム全体の整合性や運用のしやすさは後回しになります。このように部署ごとに利益を優先する状態を、サイロ化と呼びます。関係者が増えるほどサイロ化は深刻になり、合意形成に時間がかかります。
調整役は、要望を聞いて優先順位を付け、必要に応じて一部門に妥協を求めます。
合意後でも別部門の反対で覆ることがあり、要件定義は行きつ戻りつします。そのため、要件定義を1ヶ月で終わると見積もると、初期段階から予定が崩れるおそれがあります。
部門横断チームによる意思決定の集約
長期化を防ぐには、意思決定の仕組みを先に設計しておくことが大切です。具体的には、各部署から権限と責任を持つ代表者を選び、全体最適を担う部門横断チームを作ります。
- 代表者の権限：会議の場で自部門を代表して決める
- 最終決裁者：対立時に判断する経営層やプロジェクトオーナーを決めておく
- 未決事項の共有：決定済みと未決を分け、誰がいつ決めるかを一覧にする
代表者が要望を持ち帰って次回会議で回答する運用を繰り返すと、意思決定は遅れます。そこで、技術検討だけでなく、「決め方を決める」ことに力を注ぎます。
合意形成の仕組みがうまく機能するかどうかで、要件定義の期間は大きく変わります。
大規模プロジェクトの進捗ガバナンス
数十名から数百名が同時に働くと、誰が何をどこまで進めているかを把握し続けることが課題になります。小規模なら全員で共有できますが、大規模では不可能です。
そのため、体系的な進捗管理の手法と、それを専任で運用する組織が必要です。その中心になるのが、ウォーターフォールの採用と、WBS・PMBOK・PMOによる管理です。
大規模でウォーターフォールが主流となる理由
大規模な基幹システムでは、アジャイルよりウォーターフォールが主流です。主な理由は、全体の納期と予算を予測しやすいことです。
数十億円規模で数年に及ぶ計画では、発注企業は経営層や株主に時期と金額を説明します。アジャイルは柔軟ですが、納期と総額を固定しにくく、大規模投資の意思決定とは相性が良くありません。
特に、次のような案件では、ウォーターフォールが適しています。
- 官公庁システム：法律や条例で要件が固定されている
- 大規模案件：100名以上が関わり、全体の整合性管理を優先する
近年は、基盤や共通アーキテクチャを前半にウォーターフォールで完成させ、その上の機能群をアジャイルで作るハイブリッド型も増えています。
手法の良し悪しよりも、納期と予算の見通しをどう確保するかで選びます。
WBS・PMBOK・PMOによるクリティカルパス管理
PMBOK（Project Management Body of Knowledge）は、プロジェクト管理の国際的な知識体系です。プロジェクトには明確な開始と終わりがあるという有期性を前提に、計画・実行・監視を厳格に進めます。
WBSをもとに、納期と管理責任は次のように整理できます。
- WBS（Work Breakdown Structure）：作業を小さく分け、担当・工数・依存関係を明確にする
- クリティカルパス：納期に直結する経路です。1日遅れれば全体も遅れるため、資源投入を優先します。
- PMO（Project Management Office）：規模とともに管理の難しさが指数関数的に高まるため、現場を熟知したキーマンを据えて調整します。
発注側が全体を統制し、報告会を遅延の予兆を早く捉える場にすることが、スケジュールを守るうえで欠かせません。
フェーズ分割と段階的リリースのスケジュール
準備したものを全社で一度に本稼働させるビッグバンリリースは、危険です。想定外の不具合が起きれば、事業全体が止まりかねません。
大規模開発では、リスクを避けるためにフェーズを分け、段階的に本番へ移す方法が推奨されます。一斉切り替えの危うさは、次の失敗事例からも読み取れます。
ビッグバンリリースの失敗リスク
ビッグバンの危険性を示すのが、ドイツの製菓大手HARIBOの事例です。基幹システムのSAP移行では、周辺連携やテストを十分に考慮しないまま稼働しました。
その結果、システム間のデータ連携に失敗し、生産はできても出荷指示を出せない事態になりました。店頭で商品が品切れになるほど、売上機会を失いました。
個々のシステムが正常でも、連携に不備があれば全体が止まります。一斉切り替えのリスクは小規模とは比べものにならないため、発注側とベンダーで共有しておく必要があります。
疎結合アーキテクチャと段階的リリース
影響範囲を限って移行するため、発注側と開発会社は段階的にリリースを進めます。
- 機能ブロックや対象拠点・業務ごとにシステムを分割する
- 一部の拠点や部門で先行稼働させ、問題を洗い出す
- 安定を確認してから対象を広げる
技術面では、疎結合アーキテクチャが役立ちます。ERP本体には極力手を加えず、拡張や周辺システムとの連携はAPIなどで外部に実装する考え方が主流です。
疎結合なら、あるシステムの改修や障害が他へ波及しにくく、機能単位でリリースを分けやすくなります。
段階的リリースは、一見すると期間が延びるように見えます。しかし、段階的な切り替えは大規模障害からの復旧リスクも抑えるため、より確実で安全な計画です。
マルチベンダー体制のスケジュール調整
大規模システムは、自社の人員や単一のベンダーだけでは構築が難しく、複数のSIベンダーが参加するマルチベンダー体制が一般的です。
異なる会社の複数チームが並行して開発するため、調整は複雑になります。遅延の連鎖を防ぎ、各チームを同期させる仕組みが欠かせません。
遅延の連鎖とクリティカルパスの依存関係
各社のシステムやモジュールは互いに依存しており、一方が未完成だと、他社の連携テストも止まります。遅延や要件の不整合が連鎖することが、最大のリスクです。
小規模では遅延が一つのチームにとどまりますが、大規模ではドミノ倒しのように全体へ広がります。そのため、発注側は各社任せにせず、依存関係全体を統制します。
- 経路の監視：クリティカルパスを常に把握し、その上にあるベンダーの進捗を最優先で見る
- 仕様の確定：インターフェース仕様を早く決め、他社の完成待ちを減らす
インターフェース仕様とは、システム間でデータをどう受け渡すかを定めたものです。その仕様を早く確定させることが、遅延の連鎖を抑えます。
複数チームを同期させる仕組み
複数チームが動くと、コミュニケーションが課題になります。アジャイルでも、開発者が10名程度を超えるとチームを分ける必要があり、連携が難しくなります。
- 全体朝会：代表者が個別チームで解決できない課題を共有する
- 横断会議：責任者同士で進捗速度と課題をすり合わせる
- 統合の準備：専門チームで疎結合に分割し、CIで統合と自動テストを早く始める
継続的インテグレーション（CI）は、早い段階から統合と自動テストを回す取り組みです。大規模開発の成功事例でも、多く採用されています。
同期の仕組みがなければ、結合時に仕様の食い違いが噴出し、統合フェーズで破綻します。そこで、足並みを揃える活動をあらかじめ予定に組み込みます。
スケジュール炎上の典型と発注側の役割
大規模開発では、予定どおりに完遂できず炎上や頓挫に至る例が続いています。その多くは、技術力よりも管理や発注側の関与に原因があります。
実例から遅延や破綻の型を読み取ると、発注側が担うべき役割が見えてきます。
丸投げによる炎上と大型頓挫の事例
米国レンタカー大手のHertzは、進捗や品質管理をSIベンダーに丸投げし、ユーザーとベンダーの認識がずれました。さらに、直前になって発注側の設計要望と成果物の違いが判明し、法廷で責任を争いました。
ドイツの小売大手Lidlは、SAPベースのERP移行で独自要件に固執しました。追加開発を重ね、約7年間で約660億円（5億ユーロ）を投じたものの、頓挫しました。
大規模では一度ずれると軌道修正が難しく、被害が天文学的に膨らみます。小規模ならやり直せる失敗も、大規模では企業経営を揺るがす損失になり得ます。
発注側が確保すべき統制体制
発注側はベンダーに丸投げせず、自ら全体をコントロールします。具体的には、プロジェクトオーナーとPMO機能を置き、推進体制を組みます。
- 合意形成：要件定義で部門間の判断をまとめる
- 全体調整：複数ベンダー間の依存関係を調整する
- 進捗統制：進捗とクリティカルパスを監視する
- 意思決定：重要な判断を発注側の責任で行う
ベンダーに任せるのは実装で、全体の進め方を決めるのは発注側です。発注側の担当者は、要件確認や成果物レビュー、テスト参加も担います。
統制に必要なのは、資金に加えて、専念できる人材と時間です。数十億円規模の案件を本業と兼任しながら統制することはできません。
専任の推進体制には、ベンダーと対等に議論できる知識と権限を持つ人材を置きます。発注側の関与の深さが、開発の成否を左右します。
まとめ
大規模開発は予算5,000万円から1億円以上、期間12ヶ月から2年以上が一般的です。要件定義には全体の約25%を充て、2年の案件では約6ヶ月を要します。
期間が長くなる背景には、多数の部門による合意形成があります。そこで、部門横断チームで全体最適を判断し、意思決定を進めます。
進捗は、WBS・PMBOK・PMOを使ってクリティカルパスを管理します。また、疎結合アーキテクチャによる段階的リリースは、一斉切り替えのリスクを抑えます。
マルチベンダー体制では遅延が連鎖しやすいため、発注側が依存関係を見渡し、チームを同期させます。
Hertz、Lidl、HARIBOの事例が示すとおり、発注側の統制と関与が、開発の成否を分けます。推進体制と意思決定の仕組みを整え、実績あるSIerと現実的な日程を調整します。
▼全体ガイドの記事
・大規模システム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。