大規模システム開発の開発期間・スケジュール・納期について

「全社の基幹システムを刷新したい」「グループ全体のERPを統合したい」——数十億円規模の投資と、数十名から数百名のメンバー、そして1年から3年という長い時間を要する大規模システム開発を検討するとき、発注担当者が最初に直面するのが「そもそもどれくらいの期間がかかるのか」「なぜこんなに時間が必要なのか」という問いです。大規模システム開発は、数百万円・少人数・数ヶ月で立ち上げる小規模開発とは、単に規模が大きいだけの違いではありません。関与する部門やベンダーが増え、意思決定の経路が複雑になり、一つの遅延が全体に連鎖するという、スケールそのものが生み出す非連続な複雑性を抱えています。小規模開発のスピード感覚をそのまま持ち込むと、「なぜ要件定義だけで半年もかかるのか」というミスマッチが必ず生まれます。

本記事では、システム開発全般の一般論でも、小規模開発の単なる拡大版でもなく、「大規模というスケールの制約」そのものが生むスケジュール上の固有課題に焦点を当てて解説します。要件定義が長期化する構造、WBS・PMBOK・PMOによる進捗ガバナンス、ビッグバンリリースを避けるためのフェーズ分割、そして複数ベンダー・複数チームが協働するマルチベンダー体制でのスケジュール調整まで、大規模ならではの論点を具体的な数字と失敗事例とともに整理しました。エンタープライズ規模のプロジェクトを控えた発注担当者の方が、現実的な期間感を持って開発会社やSIerと対話できるようになることを目指しています。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

▼全体ガイドの記事
・大規模システム開発の完全ガイド

大規模システム開発の期間・規模感

大規模システム開発のスケジュールを考えるうえで、まず前提として押さえておきたいのが、期間の長さが「作業量の多さ」だけで決まるわけではないという点です。数十名から数百名が関与し、企業の屋台骨を支える基幹システムやERPを構築する大規模開発では、関係者間の調整・合意形成・整合性の確保に膨大な時間が費やされます。小規模開発のように「作りながら決める」「一人の判断で方針を変える」という進め方は通用せず、入念な事前準備と厳格な工程管理がプロジェクト全体の成否を握ります。ここではまず、大規模システムとはどの程度の規模を指すのか、そして工程ごとにどれだけの期間が配分されるのかを確認していきます。

大規模システムに明確な定義はありませんが、一般的には「予算5,000万円から1億円以上、開発期間12ヶ月から2年以上をかけ、数十名から数百名の体制で構築する、企業や社会の基盤を支えるシステム」を指すことが多いです。具体例としては、全社統合ERP、金融機関の勘定系システム、製造業の生産管理基幹、大手ECサイトの受注・在庫・決済基盤、官公庁の行政システムなどが該当します。これらに共通するのは、複数の部門・複数の既存システム・複数の拠点が絡み合い、一部の停止が事業全体に波及するミッションクリティカルな性質を持つという点です。小規模システムが「予算が限られている」「人手が足りない」という制約を出発点にするのに対し、大規模システムは「関係者が多すぎる」「影響範囲が広すぎる」という制約を出発点にします。この違いこそが、スケジュールの立て方を根本的に分ける理由です。大規模開発を小規模の延長線上で捉えるのではなく、スケールが非連続な複雑性を生むという前提を理解しておくことが、現実的な期間設定の第一歩になります。

大規模開発の期間配分を理解するうえで参考になるのが、独立行政法人情報処理推進機構（IPA）が示すウォーターフォール開発の標準的な工程配分です。それによると、要件定義にプロジェクト全体の約25%、設計からテスト・リリースまでに約75%が費やされます。全体が2年（24ヶ月）の大規模プロジェクトであれば、要件定義だけで約6ヶ月を要する計算です。小規模開発なら数日から数週間で固める要件定義に、大規模ではその十倍以上の時間がかかります。これは作業をサボっているからではなく、後工程での手戻りが致命的なコスト増を招くため、上流工程で徹底的に仕様を固め切る必要があるからです。数百名が動き出したあとで要件の抜け漏れが発覚すれば、その修正には膨大な工数と費用がかかります。だからこそ大規模開発では、要件定義という「見えにくい期間」に十分な時間を確保することが、結果的に全体の納期を守る近道になります。発注側は「まだ設計に入らないのか」と焦るのではなく、上流工程の重みを理解して腰を据えて臨む姿勢が求められます。

要件定義が長期化する構造と合意形成

大規模システム開発でスケジュールが最も読みにくくなるのが要件定義フェーズです。小規模開発では発注者が1〜2名なので、意思決定は速く要件も短期間で固まります。ところが大規模開発では、経理・営業・製造・人事・情報システムなど多数の部門がひとつのシステムに関与し、それぞれが異なる要望を持ち込みます。この「関係者の多さ」こそが、要件定義を長期化させる最大の構造的要因です。ここでは、なぜ合意形成に時間がかかるのか、そしてどうすれば長期化を最小限に抑えられるのかを整理します。

大規模開発の要件定義で必ず起きるのが「全体最適 vs 部分最適」の衝突です。たとえば、営業部門が「もっと詳細な顧客情報を入力できるようにしたい」と要求する一方で、経理部門は「入力項目はできるだけシンプルにしてほしい」と主張するなど、部門ごとの利害が真っ向から対立します。それぞれの部門は自分たちの業務効率を最優先に考えるため、システム全体としての整合性や運用のしやすさは後回しにされがちです。この「各部署が自部門の利益を優先する」状態はサイロ化と呼ばれ、ステークホルダーが増えれば増えるほど深刻になります。調整役はそれぞれの要望を聞き取り、優先順位をつけ、時には特定部門に妥協を求めながら合意へと導かなければなりません。この合意形成に奔走する時間こそが、要件定義を長期化させる正体です。しかも、いったん合意した内容が別の部門の反対で覆ることも珍しくなく、要件定義は一本道ではなく行きつ戻りつを繰り返します。この構造を理解せずに「要件定義は1ヶ月で終わるだろう」と見積もると、スケジュールは初期段階から崩れてしまいます。

サイロ化による要件定義の長期化を防ぐには、意思決定の仕組みを事前に設計しておくことが不可欠です。有効なのが、各部署から責任と権限を持つ代表者を選出し、全体最適に責任を負う部門横断的なプロジェクトチームを組成することです。ここで重要なのは、代表者に「その場で決める権限」を持たせることです。要望を持ち帰って部門内で再検討し、次回会議で回答する、という進め方を繰り返すと、意思決定の速度は致命的に遅くなります。代表者が自部門を代表して即断できる体制を作り、対立した際の最終決裁者（経営層やプロジェクトオーナー）をあらかじめ定めておくことで、要件定義の停滞を最小化できます。また、「何が決まっていて、何がまだ決まっていないのか」「その未決事項を誰がいつ決めるのか」を一覧で可視化し、関係者全員で共有することも効果的です。大規模開発では意思決定そのものがボトルネックになりやすいため、技術的な検討以上に「決め方を決める」ことにエネルギーを注ぐ必要があります。この合意形成のガバナンスが機能するかどうかが、要件定義フェーズの期間を大きく左右します。

大規模プロジェクトの進捗ガバナンス

数十名から数百名が同時並行で作業する大規模開発では、「誰が何をどこまで進めているのか」を把握し続けること自体が大きな課題になります。小規模開発ならメンバー全員が顔の見える距離で進捗を共有できますが、大規模ではそれが不可能です。そのため、体系化された進捗管理の手法と、それを専任で運用する組織が必要になります。ここでは、大規模開発でウォーターフォールが主流となる理由と、WBSやPMBOK、PMOといった進捗ガバナンスの仕組みを見ていきます。

大規模の基幹システム開発では、アジャイル開発よりもウォーターフォール開発が採用されることが依然として主流です。その最大の理由は、全体のスケジュール（納期）と予算の予測可能性にあります。数十億円の投資と数年の期間を要するプロジェクトでは、経営層や株主に対して「いつ・いくらで完成するか」を明確に説明する責任が発注企業にあります。アジャイルのように「作りながら要件を変えていく」進め方は柔軟性が高い反面、全体の納期と総額が固定しにくいため、大規模投資の意思決定とは相性が良くありません。とりわけ、法律や条例で要件が固定されている官公庁のシステムや、100名以上の開発者が関わり全体の整合性管理が最優先されるプロジェクトでは、ウォーターフォールが適していると明確に区別されます。ただし近年は、基盤や共通アーキテクチャをプロジェクト前半にウォーターフォールで先行して完成させ、その上で動く機能群をアジャイルで開発するというハイブリッド型も増えています。重要なのは「どちらが優れているか」ではなく、大規模というスケールの制約下で納期と予算の見通しをどう確保するか、という観点で手法を選ぶことです。

大規模開発の進捗を統制するために用いられるのが、プロジェクト管理の国際的な知識体系であるPMBOK（Project Management Body of Knowledge）に基づくガバナンスです。プロジェクトを明確な開始と終わりを持つ有期性の業務として捉え、厳格な計画・実行・監視のプロセスを敷きます。その中核となるのがWBS（Work Breakdown Structure）で、プロジェクト全体を管理可能な小さな作業単位まで分解し、各作業の担当・工数・依存関係を明確にします。このWBSを土台に、全体の納期に直接影響する一連の作業経路である「クリティカルパス」を可視化し、そこに遅延が生じないよう重点的に管理します。クリティカルパス上の作業が1日遅れれば、全体の完成も1日遅れるため、優先的にリソースを投入して守り抜く必要があります。そして、これらの管理を専任で担うのがPMO（Project Management Office）です。規模が大きくなるほどプロジェクト管理の難易度は指数関数的に高まるため、現場を熟知し全体最適の観点から現実的な落としどころを見出せるキーマンをPMOに据え、発注側がプロジェクト全体をコントロールし続ける体制が欠かせません。進捗管理を単なる報告会にせず、遅延の予兆を早期に検知して手を打つ仕組みとして機能させることが、大規模スケジュールを守る鍵になります。

フェーズ分割と段階的リリースのスケジュール

大規模システムを「ある日を境に一斉に全社で切り替える」というビッグバンリリースは、非常にリスクの高いスケジュール設計です。準備してきたものが一度に本番稼働するため、想定外の不具合が起きれば事業全体が止まりかねません。だからこそ大規模開発では、いかにリリースを分割し、段階的に本番へ移行していくかというスケジュール設計が重要になります。ここでは、ビッグバンリリースの危険性を実際の失敗事例から確認し、段階的リリースを可能にするアーキテクチャの考え方を見ていきます。

ビッグバンリリースの危険性を象徴するのが、ドイツの製菓大手HARIBOのケースです。同社は基幹システムをSAPへ移行する際、倉庫管理システムなど周辺システムとの連携やテストを十分に考慮しないまま本稼働を迎えてしまいました。その結果、システム間でデータが正しく連携されず、「製品は生産できても出荷指示が出せない」という事態に陥り、店頭で自社商品が品切れになるほどの深刻な売上機会損失を被りました。これは、大規模システムが単体で完結せず、多数の周辺システムと複雑に依存し合っているために起きた典型的な失敗です。個々のシステムが正しく動いても、それらをつなぐ連携部分に不備があれば全体は機能しません。しかもビッグバンリリースでは、この連携不備がすべて同時に噴出するため、原因の切り分けも復旧も極めて困難になります。大規模開発では「一度に全部を切り替える」ことのリスクが小規模とは比較にならないほど大きいという認識を、発注側とベンダーが共有しておくことが重要です。

ビッグバンリリースのリスクを回避するために、大規模開発ではフェーズ分割と段階的リリースが推奨されます。システム全体をいくつかの機能ブロックや対象拠点・対象業務に分割し、影響範囲を限定しながら順次本番へ移行していく進め方です。たとえば、まず一部の拠点や一部門で先行稼働させて問題を洗い出し、安定を確認してから対象を広げていくことで、万一の障害が全社に波及することを防げます。これを技術的に支えるのが疎結合アーキテクチャです。近年は、ERPパッケージ本体には極力手を加えず、必要な拡張や周辺システムとの連携をAPIなどで外部に切り出して実装する考え方が主流になっています。疎結合であれば、あるシステムの改修や障害が他システムへ波及しにくく、機能単位での段階的なリリースがしやすくなります。段階的リリースは一見すると全体の期間が延びるように思えますが、ビッグバンリリースで大規模障害を起こして復旧に追われるリスクを考えれば、はるかに確実で結果的に安全なスケジュール設計です。「一度に完璧に」ではなく「小さく確実に積み上げる」という発想が、大規模開発のリリース計画の基本になります。

マルチベンダー体制のスケジュール調整

大規模システムは、自社のリソースや単一のベンダーだけで構築することは困難です。そのため、複数のSIベンダーが参画するマルチベンダー（混成チーム）体制が組まれるのが一般的です。しかし、会社の異なる複数のチームが並行して開発を進めるという体制は、スケジュール管理を著しく複雑にします。ここでは、マルチベンダーゆえに起きる遅延の連鎖と、複数チームをどう同期させるかという大規模開発特有の課題を見ていきます。

マルチベンダー環境では、各ベンダーが担当するシステムやモジュールが複雑な依存関係で結ばれています。あるベンダーのシステムが完成しないと別のベンダーが連携テストに進めない、という関係が随所に存在するため、一つのチームでスケジュールの遅延や要件の不整合が発生すると、連携する他チームの進行にも連鎖的に遅延が波及します。これがマルチベンダー特有の最大のリスクです。小規模開発なら遅延の影響は一つのチーム内に留まりますが、大規模ではドミノ倒しのように全体へ広がります。この連鎖を防ぐには、全体の納期に直接影響する作業経路であるクリティカルパスを常に把握し、その上にあるベンダーの進捗を最優先で監視することが必要です。また、ベンダー間のインターフェース仕様（システム同士がどうデータをやり取りするか）を早期に確定させ、各ベンダーが他ベンダーの完成を待たずに開発を進められるようにすることも遅延連鎖の抑制に有効です。発注側は「各ベンダーが自分の担当さえ守ればよい」という発想を捨て、ベンダーをまたぐ依存関係全体を俯瞰して統制する役割を担わなければなりません。

複数チームが並行して動く大規模開発では、チーム間のコミュニケーションが最大の課題になります。アジャイルを取り入れる場合でも、開発者が10名程度を超えるとチーム分割が必要になり、その分だけ連携の難易度が上がります。これを解決するために、大規模開発では複数チームを同期させる工夫が導入されます。たとえば、各チームの朝会に加えて「チーム代表者による全体朝会」を段階的に実施し、個別チームでは解決できない課題を吸い上げて全体で対処します。また、複数チームを束ねる責任者同士が定期的に集まり、各チームの進捗速度や課題を共有する横断会議体を設けることも有効です。さらに、プロジェクト前半にアーキテクチャ専門チームを編成してサブシステム間を疎結合に分割しておき、継続的インテグレーション（CI）によって早期から統合と自動テストを回す取り組みも、大規模開発の成功事例の多くで採用されています。こうした同期の仕組みを設けずに各チームが好き勝手に開発を進めると、結合の段階で仕様の食い違いが噴出し、統合フェーズで破綻します。複数チームの足並みを揃える仕掛けを、スケジュールにあらかじめ組み込んでおくことが大規模開発では不可欠です。

スケジュール炎上の典型と発注側の役割

大規模システム開発は、スケジュール通りに完遂できずに炎上・頓挫する例が後を絶ちません。その多くは技術力の問題ではなく、プロジェクトマネジメントと発注側の関与の問題に起因します。ここでは、大規模プロジェクトが遅延・破綻する典型的なパターンを実例から確認し、それを避けるために発注側が担うべき役割を整理します。

大規模プロジェクトの炎上を象徴するのが、米国レンタカー大手Hertzのケースです。同社はシステム開発の進捗管理や品質管理をSIベンダーに丸投げしてしまい、ユーザーとベンダーの認識が一致しないまま開発が進みました。その結果、リリース直前になって「発注側が求めていた設計とベンダーが作っていたものが全く違う」ことが発覚し、最終的に法廷で責任のなすり付け合いに発展する大失敗となりました。また、ドイツの小売大手Lidlは、レガシーシステムからSAPベースのERPへ移行しようとしましたが、独自の業務要件に固執して大規模な追加開発を重ねた結果、約7年間で約660億円（5億ユーロ）を投じた末にプロジェクトそのものが頓挫しました。これらの事例に共通するのは、いずれもスケールの大きさゆえに一度歯車が狂うと軌道修正が効かなくなり、被害が天文学的な規模に膨らむという点です。小規模開発なら「やり直せばよい」で済む失敗が、大規模では企業の経営を揺るがす損失になります。

これらの失敗が示す教訓は明確です。大規模開発では、発注側がプロジェクトをベンダーに丸投げせず、自らが主体となって全体をコントロールし続けなければならないということです。具体的には、発注側にプロジェクトオーナーとPMO機能を置き、要件定義の合意形成、マルチベンダー間の調整、進捗とクリティカルパスの監視、そして重要な意思決定を発注側の責任で担う体制を構築します。ベンダーに任せてよいのは実装作業であって、プロジェクト全体の舵取りではありません。また、発注側の担当者は、要件の確認、成果物のレビュー、テストへの参加など、想像以上に多くの作業を担うことになります。大規模開発において発注側が確保すべきは、資金だけでなく「プロジェクトに専念できる人材と時間」です。本業と兼任の片手間で数十億円のプロジェクトを統制することはできません。専任の推進体制を組み、ベンダーと対等に議論できるだけの知識と権限を持った人材を配置することが、スケジュールを守り抜くための最後の砦になります。発注側の関与の深さこそが、大規模開発の成否を分ける最大の要因なのです。

まとめ

本記事では、大規模システム開発の開発期間・スケジュール・納期について、「エンタープライズ規模・数十〜数百名・長期間」というスケールの制約が生む固有の課題に焦点を当てて解説しました。大規模開発は予算5,000万〜1億円以上、期間12ヶ月〜2年以上が一般的で、要件定義だけで全体の約25%（2年なら半年）を要します。この期間の長さは作業量ではなく、多数の部門が関与する合意形成の難しさに起因し、全体最適と部分最適の衝突を部門横断チームで裁くガバナンスが求められます。進捗はWBS・PMBOK・PMOによってクリティカルパスを可視化しながら統制し、ビッグバンリリースを避けて疎結合アーキテクチャによる段階的リリースを設計することが安全なスケジュールの基本です。さらに、複数のSIerが参画するマルチベンダー体制では遅延が連鎖するため、依存関係全体を発注側が俯瞰して同期させる必要があります。HertzやLidl、HARIBOの失敗が示すように、大規模開発の成否は技術力以上に発注側の統制力と関与の深さに左右されます。大規模システムの開発を検討されている方は、まずは自社の推進体制と意思決定の仕組みを整えたうえで、実績のあるSIerと現実的なスケジュールをすり合わせていくことをお勧めします。

▼全体ガイドの記事
・大規模システム開発の完全ガイド

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。