受託開発の開発期間・スケジュール・納期について

自社にエンジニアを抱えず、外部のシステム開発会社にシステム構築を委託する「受託開発」を検討するとき、発注担当者が最初に直面する疑問が「完成までにどれくらいの期間がかかるのか」という点です。受託開発では、要件定義から設計、開発、テスト、納品・検収までの一連の工程を外部ベンダーに委ねることになりますが、その全体スケジュールは自社が主体的に握るものではなく、ベンダーとの契約形態や役割分担、そして発注者側の意思決定スピードによって大きく左右されます。「経営層に納期を報告しなければならないのに、提示された見積もりの期間が妥当なのか判断できない」「なぜこの機能にこれだけの月数がかかるのか、説明を受けても腑に落ちない」といった悩みは、外部委託の経験が浅い担当者ほど強く感じるものです。

本記事では、特定のシステム種別の各論ではなく、システム開発を外部へ委託する「受託開発」という発注形態に共通する開発期間・スケジュール・納期の考え方を、発注者の視点から体系的に解説します。内製と受託で期間の捉え方がどう変わるのか、規模別の開発期間の目安、工程ごとの期間配分、請負契約と準委任契約が納期に与える影響、そして納期遅延の典型的な原因と発注担当者が取るべき対策までを、具体的な数字とともに整理しました。外部ベンダーと現実的なスケジュール感を共有し、納期をコントロールできる発注者になることを目指した内容です。

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

▼全体ガイドの記事
・受託開発の完全ガイド

受託開発における開発期間・納期の全体像

受託開発の期間を考えるうえでまず押さえておきたいのは、「開発期間」とは単にベンダーがコードを書いている時間のことではない、という点です。発注を思い立ってから実際にシステムが稼働するまでには、社内での企画・予算取り、RFP（提案依頼書）の作成、複数ベンダーへの声かけと相見積もり、提案評価と発注先の決定、契約締結という「発注前の準備期間」が存在します。この準備だけで1〜3ヶ月を要することも珍しくなく、ここを見落とすと「開発会社に頼めばすぐ動き出す」という誤った前提でスケジュールを引いてしまいます。受託開発におけるスケジュール管理とは、ベンダーの作業期間だけでなく、この発注前フェーズと、後工程の検収・移行までを含めた全体を発注者がマネジメントすることに他なりません。

自社のエンジニアで開発する内製と、外部ベンダーに委託する受託開発では、スケジュールを左右する要因が根本的に異なります。内製では、開発するメンバーが業務やシステムの背景を理解しているため、要件のすり合わせにかかる時間が短く、優先順位の変更にも柔軟に対応できます。一方で、社内のエンジニアは通常業務や他プロジェクトと兼任していることが多く、専任リソースを確保できなければ開発が慢性的に後ろ倒しになりがちです。受託開発では、ベンダーがプロジェクトに専任チームをアサインするため、着手後の開発スピード自体は速くなる傾向がありますが、その代わりに「発注者とベンダーの間の認識合わせ」に相応の時間が必要になります。仕様を言語化してドキュメントに落とし込み、レビューし、合意する。この往復のコミュニケーションこそが受託開発の期間を決める最大の変数であり、発注者が要件をどれだけ明確に提示できるかで、同じシステムでも完成時期が数ヶ月単位で変わってきます。つまり、受託開発の期間短縮とは「ベンダーを急かすこと」ではなく、「発注者側の意思決定と要件提示を滞らせないこと」だと理解しておく必要があります。

受託開発の全体期間は、対象となる業務範囲やシステムの複雑さによって大きく異なりますが、規模別のおおまかな目安を持っておくと、ベンダーからの見積もりが現実的かどうかを判断する物差しになります。小規模なシステム（簡易な顧客管理、予約受付、必要最小限の機能に絞ったMVP＝実用最小限の製品など）は、開発期間の目安が1ヶ月〜6ヶ月程度、費用は50万〜1,000万円程度が一般的です。部署をまたぐ業務システムや会員管理システム、外部ツールとの連携を含む中規模システムでは、3ヶ月〜12ヶ月程度、費用は300万〜5,000万円程度が目安となります。企業の基幹システム刷新や、高度なカスタマイズを伴うSaaS、複雑な既存システム群とのAPI連携を含む大規模システムになると、6ヶ月〜2年以上、費用は1,000万円〜1億円以上に及ぶこともあります。注意したいのは、これらはあくまで着手後の開発期間であり、前述した発注前の準備期間や、稼働後のデータ移行・現場定着の期間は別途見込む必要があるという点です。ベンダーが「3ヶ月でできます」と提示したとき、それが要件定義を含むのか、既存データの移行を含むのか、検収期間を含むのかを必ず確認しましょう。同じ月数でも、含まれる工程が違えば実際にシステムを使い始められる時期は大きくずれます。

受託開発の工程別スケジュールと期間配分

受託開発のスケジュールを正しく読み解くには、全体をいくつかの工程に分解し、それぞれにどれだけの期間・工数が割かれるのかを理解しておくことが有効です。工程配分の相場を知っていれば、ベンダーの見積書を見たときに「どこかの工程が不自然に圧縮されていないか」を見抜けるようになります。特に発注者が軽視しがちなのが要件定義と検収の工程ですが、この2つはプロジェクトの成否と納期遵守を大きく左右する、発注者自身が主体的に関与すべき工程です。

独立行政法人情報処理推進機構（IPA）のデータによると、標準的なウォーターフォール型開発における工期（期間）の比率は、おおむね「要件定義に約25%、設計からテストまでに約75%」とされています。一方、費用（工数）ベースで各工程の割合を見ると、要件定義が約10〜12%、設計・環境構築が約22〜24%、開発（実装）が約48〜50%、テストが約15〜17%という配分が一つの目安になります。ここで注目すべきは、要件定義は工数ベースでは1割程度にすぎないのに、期間ベースでは全体の4分の1を占めるという点です。これは、要件定義が発注者とベンダーの合意形成を伴う工程であり、機械的な作業ではなく「意思決定の往復」に時間がかかるためです。発注者側の回答が遅れれば、この工程はいくらでも延びます。逆に言えば、要件定義を計画的に前倒しで進められれば、プロジェクト全体の納期を守れる可能性が大きく高まります。見積書を確認する際は、要件定義に全体の1割以上の工数が確保されているか、テスト工程が5%以下に極端に圧縮されていないかを必ずチェックしてください。これらが不自然に少ない見積もりは、後工程での手戻りやバグ多発によって、結局は納期遅延を招くリスクをはらんでいます。

受託開発では「ベンダーに任せているのだから、こちらは待っていればよい」と考えてしまう発注者が少なくありませんが、これは危険な誤解です。プロジェクトの各工程には、発注者が主体的に手を動かし、意思決定を下さなければ前に進まないポイントが数多く存在します。要件定義フェーズでは、現場業務のヒアリングへの協力、画面や帳票のイメージの提示、優先順位の判断が発注者に求められます。設計フェーズでは、ベンダーが作成した基本設計書のレビューと承認が必要です。開発フェーズでも、仕様の確認事項に対する回答や、途中デモへのフィードバックが求められます。そして検収フェーズでは、受け入れテスト（UAT）を発注者自身が実施し、システムが要件を満たしているかを判定します。これらの局面で発注者の回答や承認が遅れると、その間ベンダーは手を止めて待機することになり、この「待ち時間」がスケジュール遅延の大きな原因になります。しばしば発注者は「ベンダーの作業が遅い」と感じますが、実際には発注者側の意思決定待ちで停滞しているケースが非常に多いのです。プロジェクト開始時に、いつ・誰が・何を判断するのかという責任分担表（RACIなど）を作成し、発注者側の宿題に期限を設けておくことが、待ち時間を減らし納期を守る近道になります。

契約形態と開発手法が納期に与える影響

受託開発の納期を語るうえで避けて通れないのが、ベンダーとどのような契約を結ぶか、そしてどの開発手法で進めるかという論点です。同じシステムを作る場合でも、契約形態と開発手法の組み合わせによって「納期の拘束力」と「仕様変更への柔軟性」のバランスが大きく変わります。発注者はこの特性を理解したうえで、自社のプロジェクトの性質に合った契約と手法を選ぶ必要があります。

受託開発の契約は、大きく「請負契約」と「準委任契約」に分かれ、この違いが納期の意味合いを根本的に変えます。請負契約は、受注者（ベンダー）が「仕事の完成」を約束し、成果物の引き渡しによって報酬が発生する契約です。あらかじめ合意した納期までに成果物を完成させられなかった場合、ベンダーは債務不履行責任を負い、発注者は損害賠償を請求できる立場になります。したがって、「この機能を、この期日までに、確実に完成させたい」という納期が明確な案件では、請負契約が適しています。一方の準委任契約は、仕事の完成義務ではなく「業務の遂行」を目的とし、専門家として適切に業務を行う善管注意義務を負う契約です。完成そのものは約束しないため、厳格な納期で縛ることには本来向いていませんが、その代わり仕様変更が起きやすいプロジェクトやアジャイル開発に柔軟に対応できます。発注者が押さえておくべきなのは、「準委任契約だから納期が守られない」わけではなく、「準委任契約では納期の遵守を法的に強制しにくい代わりに、柔軟性を得ている」という構造です。要件がまだ固まっていない新規事業では準委任で走り出し、仕様が固まった実装工程で請負に切り替えるといった、工程ごとに契約形態を使い分けるハイブリッド型も、納期と柔軟性を両立させる有効な選択肢になります。なお、請負・準委任のいずれであっても、発注者がベンダーのエンジニアに直接指揮命令を出すと「偽装請負」と見なされるリスクがあるため、指示は必ずベンダー側の責任者（PM）を通す点にも注意が必要です。

開発手法の選択も、納期の捉え方を大きく変えます。ウォーターフォール型は、要件を最初にすべて固めてから設計・開発・テストへと一直線に進める手法で、全体のスケジュールと予算を早い段階で予測しやすいのが特徴です。「いつまでに、いくらで、何が完成するか」を契約時点で確定させたい発注者にとっては安心感がありますが、その反面、開発が進んでから仕様を変更しようとすると大きな手戻りと追加費用が発生します。アジャイル型は、機能を小さく分割し、短期間の反復（スプリント）で開発と改善を繰り返す手法です。市場や現場の反応を見ながら優先順位を柔軟に組み替えられる強みがありますが、「最終的にすべてが完成する日」を固定することは構造的に難しくなります。受託開発でアジャイルを採用する場合、発注者は「決められた期間・予算の中で、優先度の高い機能から順に作り込んでいき、期限が来たら、その時点で完成している範囲でリリースする」という考え方に頭を切り替える必要があります。納期を絶対に動かせない案件であれば、機能を欲張らず、必須機能（MVP）に絞ってウォーターフォール的に確実に仕上げる。逆に、作りながら仕様を磨き込みたい新規事業であれば、アジャイルで柔軟に進める。このように、自社にとって「納期の固定」と「仕様の柔軟性」のどちらが優先かを見極めたうえで、契約形態と開発手法を組み合わせて選ぶことが、発注者の重要な役割です。

受託開発で納期遅延が起きる主な原因

受託開発の納期遅延は、ベンダーの技術力不足だけが原因で起こるわけではありません。むしろ、発注者側の準備不足やコミュニケーションの問題に起因するケースが数多く見られます。ここでは、受託開発で典型的に発生する納期遅延の原因を3つ取り上げ、発注者の立場から何ができるかを整理します。原因を先回りして理解しておくことが、遅延の予防につながります。

受託開発における納期遅延の最大の原因が、要件の曖昧さから生じる仕様変更の頻発、いわゆる「スコープクリープ（開発範囲の際限ない拡大）」です。要件定義をベンダーに丸投げしたり、「いい感じに作ってほしい」と曖昧なまま開発に着手すると、開発が進んでから「イメージしていたものと違う」「あの機能も追加してほしい」という要求が次々と発生します。その結果、当初の見積もり工数が1.5〜1.8倍にまで膨れ上がり、スケジュールが破綻するというのは、受託開発で最も頻繁に起きる失敗パターンです。厄介なのは、こうした変更が「ちょっとした追加」という形で口頭ベースで積み重なり、気づいたときには手が付けられない規模になっている点です。対策の基本は2つあります。1つは、最初から「全部盛り」を目指さず、事業として本当に必要な必須機能に絞ったMVPで小さく始め、稼働させながら段階的に機能を拡張していくこと。もう1つは、発注者自身が当事者意識を持ち、要件定義をベンダーと「一緒に作る」姿勢で臨むことです。現場の業務を最もよく知っているのは発注者であり、その知識を要件として言語化する作業に発注者が深く関与するほど、後工程での認識ズレと手戻りは減っていきます。

受託開発では、発注者側にプロジェクトの窓口となり意思決定を担うキーマンが不在だと、それだけで納期が大きく後ろ倒しになります。社内にシステム開発の窓口となる担当者（社内PM）がいなかったり、仕様を判断できる決裁者が定例会議に参加しなかったりすると、ベンダーからの仕様確認への回答が滞り、開発やテストの期間が何度も延長されていきます。ベンダーは発注者の判断を待たなければ先に進めない場面が多いため、意思決定のスピードがそのまま開発スピードに直結するのです。対策としては、まず発注側の責任者（プロダクトオーナー）と決裁ルートを明確にし、担当者が不在のときに代理で判断できる権限も事前に決めておくことが重要です。加えて、決裁権を持つ人物を最低でも月1回は定例会議に参加させ、その場で懸案事項に判断を下せる体制を作ることで、意思決定の滞留を防げます。「持ち帰って検討します」を繰り返しているうちにスケジュールは確実に溶けていきます。会議を単なる進捗報告の場にせず、その場で意思決定を行う場として運用することが、受託開発の納期を守るうえで極めて重要です。

コンペや相見積もりで、費用の安さだけを基準にベンダーを選んでしまうことも、納期遅延の温床になります。極端に安い見積もりの裏には、テスト工程が極端に圧縮（全体の5%以下など）されていたり、経験の浅いエンジニアばかりがアサインされていたりといった事情が隠れていることがあります。その結果、リリース前になってバグが多発し、手戻りが積み重なって納期が破綻するのです。さらに問題なのは、遅れを取り戻そうとして安易に人員を追加すると、かえって遅延が悪化する点です。これはソフトウェア工学で「ブルックスの法則」として知られる現象で、途中から加わったメンバーへの引き継ぎや、増えた人員間のコミュニケーションコストが、作業の増加分を上回ってしまうために起こります。対策としては、見積書の「単価×工数」という表面的な数字だけを見るのではなく、テスト工程が独立した項目として計上されているか、要件定義に全体の1割以上の工数が確保されているか、アサインされるメンバーのスキルレベルや体制がどうなっているかを確認することが重要です。最も安い見積もりを提示した理由が、品質やテストの手抜きによるものでないかを見極める目を、発注者は持たなければなりません。

納期を守るために発注担当者が押さえるべきポイント

ここまで見てきた納期遅延の原因の多くは、発注者側の取り組みによって未然に防げるものです。受託開発の納期は「ベンダーに任せて祈る」ものではなく、発注者が主体的にマネジメントすべき対象です。ここでは、発注担当者がスケジュールをコントロールするために実務で押さえておくべきポイントを、発注前の準備と、開発が始まってからの管理の2つの側面から整理します。

納期を守るための取り組みは、発注前のRFP（提案依頼書）作成から始まっています。RFPには、現状の課題、システム化の目的とKPI、機能要件、レスポンス速度や同時接続数といった非機能要件、希望するスケジュール、検収基準、運用時のSLA（サービス品質保証）などを、短い記述でよいので明記します。これにより、複数のベンダーが同じ前提条件のもとで見積もりとスケジュールを提示できるようになり、比較検討が容易になるうえ、開発途中での認識ズレを防げます。要件定義フェーズでは、特に非機能要件を「努力目標」のまま曖昧にしないことが重要です。画面の見た目や操作といった機能要件だけでなく、レスポンス速度、同時接続数、セキュリティ、監視、バックアップといった非機能要件を、明確な数値と測定方法とともに定義し、それを検収基準に紐づけておきます。非機能要件を後回しにすると、開発終盤になって「性能が要件を満たさない」ことが発覚し、大規模な手戻りと納期遅延を招きます。発注者が発注前・要件定義段階でスケジュールの前提条件をどれだけ固められるかが、その後の納期遵守を大きく左右するのです。

開発が始まってからは、進捗管理と変更管理の仕組みを回すことで納期をコントロールします。まず進捗管理では、週次の定例会議を単なる進捗報告の場で終わらせないことが肝要です。「KPIとマイルストーンの確認」「リスク・課題の洗い出しと解消」「変更要求（CR）の判定」という定型アジェンダで会議を運営し、その場で意思決定まで行うことで、懸案の先送りによる遅延を防ぎます。そして、受託開発の納期を守るうえで最も効果的なのが、変更管理の「3点セット」の運用をルール化することです。1つ目は「合意＝議事録」で、決定事項・宿題・期日・責任者を必ず文書に残し、口頭での合意を放置しないこと。2つ目は「変更＝CR（変更要求）票」で、仕様変更の要望が出たら、その影響範囲・工数の増減・納期への影響を定量的に評価し、承認を経てから実施すること。口頭での「ちょっとした追加」を絶対に禁止し、すべての変更をこのプロセスに乗せることで、スコープクリープによる納期破綻を防げます。3つ目は「検収＝テストエビデンス」で、事前に定めた受け入れテストシナリオと、その実施証拠に基づいて合否を判定すること。これにより検収段階での「言った・言わない」の水掛け論を避け、スムーズな納品につなげられます。この3点セットを契約前にルールとして合意し、プロジェクト全体で徹底することが、受託開発の納期を発注者がコントロールするための最も実践的な武器になります。

まとめ

本記事では、システム開発を外部に委託する「受託開発」という発注形態における開発期間・スケジュール・納期の考え方を、発注者の視点から解説しました。受託開発の期間は、ベンダーの作業時間だけでなく、発注前の準備、発注者側の意思決定スピード、検収・移行までを含めた全体でとらえる必要があります。規模別の期間の目安（小規模1〜6ヶ月、中規模3〜12ヶ月、大規模6ヶ月〜2年以上）を物差しとして持ちつつ、工程別の配分を理解して見積もりの妥当性を見抜き、請負契約と準委任契約、ウォーターフォールとアジャイルの特性を踏まえて自社に合った進め方を選ぶことが、納期遵守の土台になります。そして、納期遅延の主因である要件の曖昧さ・意思決定の遅延・安さ重視のベンダー選定は、いずれも発注者の取り組みで予防可能です。RFPと要件定義で前提条件を固め、進捗管理と変更管理の3点セットを徹底することで、受託開発の納期は「祈る」ものから「コントロールする」ものへと変わります。信頼できる開発パートナーとともに、現実的なスケジュール感を共有するところから始めてみてください。

▼全体ガイドの記事
・受託開発の完全ガイド

株式会社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を創業。