受託開発の納期は、発注前の準備、要件の明確さ、発注者の意思決定、検収・移行までを一つの流れとして捉えると、現実的に管理できます。
規模別の期間から工程配分、契約と開発手法、遅延の対策まで、発注者の立場で解説します。全体像は受託開発の完全ガイドもご覧ください。
▼全体ガイドの記事
・受託開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
受託開発における開発期間・納期の全体像
受託開発の期間は、ベンダーがコードを書く時間だけでは決まりません。発注を思い立ってから稼働するまでの全体で考える必要があります。
発注前には、社内での企画と予算取りに加えて、RFP（提案依頼書）を作り、複数社への相談と相見積もりを進めます。提案を評価し、発注先を決めて契約を結ぶまでが発注前の流れです。
発注前の準備だけで1〜3ヶ月かかることもあるため、すぐに着手できる前提で予定を組むと、実際の日程とずれてしまいます。スケジュールを管理するには、発注前の準備に加えて、ベンダーの作業期間、検収、データ移行までを含めて見ておく必要があります。
内製と受託開発での「期間」の考え方の違い
内製と受託開発では、スケジュールを左右する要因が根本から違います。
- 内製の調整：自社の業務やシステムの背景を知っているぶん、要件の調整が短く、優先順位も変えやすい。
- 内製の体制：通常業務や他のプロジェクトとの兼任が多く、専任者がいないと開発が慢性的に遅れやすい。
- 受託開発：専任チームが着手すると進みは速い傾向にあるが、発注者との認識合わせに時間がかかる。
期間を左右するのは、仕様を言葉にして文書にし、レビューして合意するまでの往復です。要件提示の明確さによって、完成時期が数ヶ月単位で変わります。
期間を縮めるには、ベンダーを急かすよりも、発注者側の意思決定と要件提示を滞らせないことが欠かせません。
受託開発の規模別 開発期間の目安
業務の範囲やシステムの複雑さによって、全体の期間は変わります。規模別の目安は、ベンダーから出た見積もりを判断する材料になります。
- 小規模：1〜6ヶ月程度。対象は簡易な顧客管理、予約受付、必要最小限のMVP（実用最小限の製品）など。
- 中規模：3〜12ヶ月程度。対象は部署をまたぐ業務システム、会員管理、外部ツール連携など。
- 大規模：6ヶ月〜2年以上。対象は基幹システムの刷新、高度なカスタマイズを伴うSaaS、複雑な既存システム群とのAPI連携など。
費用の目安は、小規模が50万〜1,000万円、中規模が300万〜5,000万円、大規模が1,000万円〜1億円以上です。
規模別に示した期間は、着手後の開発期間を指します。
発注前の準備、稼働後のデータ移行、現場定着の期間は、別途見込む必要があります。
見積もりに書かれた「3ヶ月」に、要件定義、既存データ移行、検収が含まれるかを確かめる必要があります。
工程の範囲が違えば、利用開始の時期もずれます。
受託開発の工程別スケジュールと期間配分
全体を工程に分け、各工程の期間や工数の配分を把握しておくと、見積もりに不自然な圧縮がないかを見極められます。
特に要件定義と検収は軽視されがちですが、どちらもプロジェクトの成否や納期を左右するため、発注者自身の関与が必要になります。
要件定義から検収までの工程別 期間・工数配分
IPAのデータをもとに、工期と工数の配分、見積書で確認すべき点を示します。
- 工期：標準的なウォーターフォール型では、要件定義が約25%、設計からテストまでが約75%を占める。
- 工数：要件定義は約10〜12%、設計・環境構築は約22〜24%、開発は約48〜50%、テストは約15〜17%。
- 見積もり確認：要件定義が全体の1割以上あるか、テストが5%以下に圧縮されていないかを見る。
要件定義は工数では1割程度でも、発注者とベンダーの合意形成に時間がかかるため、期間では全体の4分の1を占めます。また、発注者の回答が遅れると、要件定義は延びます。
要件定義は計画的に前倒しで進めておくと、全体の納期を守れる可能性が高まります。
配分が極端に少ない場合は、後工程での手戻りやバグの多発を招き、納期遅延につながるリスクがあります。
発注者が関与すべき工程と「待ち時間」の正体
受託開発であっても、各工程では発注者が主体的に作業や意思決定を担う場面が多くあります。
- 要件定義：現場業務のヒアリングへの協力と、画面・帳票のイメージおよび優先順位の提示。
- 設計：ベンダーが作成した基本設計書のレビューと承認。
- 開発：仕様確認への回答と、途中デモへのフィードバック。
- 検収：受け入れテスト（UAT）の実施と、要件を満たすかどうかの判定。
回答や承認が遅れると、ベンダーは作業を止めて待つことがあります。この待ち時間が、遅延の大きな原因になります。
ベンダーの作業が遅く見えても、実際には発注者の意思決定を待って止まっている場合があります。そこで、開始時にいつ・誰が・何を判断するかを責任分担表（RACIなど）にまとめておきます。また、発注者側の宿題にも期限を設けておきます。
契約形態と開発手法が納期に与える影響
契約形態と開発手法の組み合わせによって、納期の拘束力と仕様変更への柔軟性のバランスが変わります。
発注者は、それぞれの特性を理解し、自社の案件に合う契約と手法を選ぶ必要があります。
請負契約と準委任契約での「納期の拘束力」の違い
受託開発の契約は、大きく請負契約と準委任契約に分かれ、両者では納期の意味合いが異なります。
- 請負契約：ベンダーが仕事の完成を約束し、成果物を引き渡した時点で報酬が発生する。
- 準委任契約：完成ではなく業務の遂行を目的とし、専門家として適切に業務を行う善管注意義務を負う。
請負で合意した納期までに成果物が完成しなければ、ベンダーは債務不履行責任を負い、発注者は損害賠償を請求できる立場になります。
機能と期日を定めて確実に完成させたい案件には、請負が適しています。
一方で、準委任は完成を約束しないため、厳格な納期で縛る契約には向きません。納期を法的に強制しにくい代わりに、仕様変更が起きやすい案件やアジャイル開発には柔軟に対応できます。
たとえば、新規事業は準委任で始め、仕様が固まった実装工程で請負に切り替える方法もあります。工程ごとに使い分けることで、両立を図れます。
いずれの契約でも、発注者がエンジニアに直接指揮命令をすると「偽装請負」と見なされるリスクがあります。
指示はベンダー側の責任者（PM）を通すようにします。
ウォーターフォールとアジャイルによる納期の考え方
納期の固定度と仕様変更への対応力は、開発手法によって違います。
- ウォーターフォール：要件を最初に固めて、設計・開発・テストへと順に進める。予定と予算を早い段階で予測できる。
- 仕様変更：ウォーターフォールでは、途中の変更が手戻りや追加費用につながる。
- 契約時の確定：「いつまでに、いくらで、何を完成させるか」を決めたい発注者にとっては安心感がある。
- アジャイル：短い期間の反復で開発と改善を進め、市場や現場の反応に応じて優先順位を変えられる。
アジャイルでは、すべての完成日を固定することが構造的に難しくなります。代わりに、期間と予算を先に決めて、優先度の高い機能から作り、期限の時点で完成している範囲をリリースします。
納期を動かせない案件では、機能を必須機能（MVP）に絞り、ウォーターフォール的に仕上げます。一方、仕様を磨きたい新規事業には、アジャイルが向きます。
納期の固定と仕様の柔軟性のどちらを優先するかを見極めて、契約形態と開発手法を組み合わせます。
受託開発で納期遅延が起きる主な原因
納期の遅延は、ベンダーの技術力だけでなく、発注者の準備不足や連絡の行き違いからも起こります。主な原因は3つあり、それぞれに発注者ができる対策があります。
要件の曖昧さと仕様変更（スコープクリープ）
受託開発では、要件の曖昧さから生じる仕様変更が、納期遅延の最大の原因になります。
- スコープクリープ：要件が曖昧なために変更が頻発し、開発範囲が際限なく広がる状態。
- 起こるきっかけ：要件定義を丸投げすることや、「いい感じに」と曖昧なまま着手すること。
- 影響：口頭での追加が制御不能に積み重なって工数が1.5〜1.8倍に膨らみ、納期破綻を招く頻出パターンです。
対策としては、全部盛りを避けて、事業に必要な必須機能に絞ったMVPで始めることが有効です。稼働後に段階的に拡張し、発注者も当事者としてベンダーと一緒に要件を作ります。
現場業務を知る発注者が要件の言語化に関わるほど、後工程の認識ずれや手戻りを減らせます。
発注者側のキーマン不在・意思決定の遅延
遅延を防ぐには、判断する人と意思決定の場を整えておくことが欠かせません。
- 判断者の決定：責任者（プロダクトオーナー）と決裁ルートを定め、代理権限も決めておく。
- 決裁者の参加：最低でも月1回、懸案を判断できる定例会議を設ける。
- 会議での判断：進捗報告だけで終わらせず、持ち帰りを繰り返さない。
社内のPMが不在だったり、決裁者が会議を欠席したりすると、仕様確認への回答が滞ります。その結果、開発やテストが何度も延長され、納期が大きく後ろ倒しになります。
ベンダーは発注者の判断を待つ場面が多いため、意思決定の速さが開発速度に直結します。また、「持ち帰って検討します」を繰り返すことも、遅延につながります。
安さ重視のベンダー選定と体制不備
コンペや相見積もりでは、費用の安さに加えて、品質や開発体制も見ておきます。
- テスト不足：極端に安い見積もりでは、テストが全体の5%以下になっている場合がある。
- 経験不足：経験の浅いエンジニアばかりの体制では、リリース前にバグが多発し、手戻りで納期が破綻しかねない。
- 途中の増員：遅れを取り戻すための増員が、かえって遅延を悪化させることがある。
途中の増員による遅延は、ソフトウェア工学で「ブルックスの法則」と呼ばれます。追加メンバーへの引き継ぎや連絡のコストが、作業の増加分を上回るためです。
見積書は「単価×工数」の金額だけでなく、テストが独立した項目になっているか、要件定義が全体の1割以上あるかも確認します。
担当者のスキルや体制も確かめ、最安値の理由が品質やテストの省略ではないかを見極めます。
納期を守るために発注担当者が押さえるべきポイント
遅延の多くは、発注者の取り組みで予防できます。納期はベンダー任せにせず、発注者が管理すべき対象です。
実務では、発注前の準備と開発開始後の管理の両面から、スケジュールを押さえていきます。
RFPと要件定義による、スケジュールの前提条件の固定
納期の管理は、発注前のRFP（提案依頼書）の作成から始まります。RFPには、見積もりの前提となる情報を明記しておきます。
- 目的と要件：現状の課題、システム化の目的とKPI、機能要件。
- 性能と運用：応答速度や同時接続数などの非機能要件、運用時のSLA（サービス品質保証）。
- 納期と検収：希望スケジュールと検収基準。
短い記述でも前提をそろえれば、複数社の見積もりや予定を比べやすくなり、開発途中の認識ずれも防げます。
要件定義では、性能や同時接続数、セキュリティを非機能要件として定義します。監視やバックアップも、努力目標のままにせず定義します。それぞれに明確な数値と測定方法を定め、検収基準に結び付けておきます。後回しにすると、終盤になって性能不足が分かり、大きな手戻りを招きます。発注前と要件定義の段階で前提を固められるかが、その後の納期遵守を左右します。
進捗管理と変更管理「3点セット」の徹底
開発の開始後は、進捗管理と変更管理を運用します。週次の定例会議も、進捗報告だけで終わらせない運用にします。
- KPIとマイルストーン：達成状況の確認。
- リスクと課題：洗い出しと、解消策の決定。
- 変更要求（CR）：受け入れの可否を、その場で判定する。
定例会議で判断まで行えば、懸案の先送りによる遅延を防げます。
変更管理では、3点セットをルールとして決めておきます。
1つ目は「合意＝議事録」です。決定事項と宿題を文書に残し、期日と責任者も添えて、口頭の合意を放置しません。
2つ目は「変更＝CR（変更要求）票」です。
要望ごとに影響範囲や工数の増減、納期への影響を数値で評価し、承認を得てから実施します。
口頭での小さな追加も認めず、すべての変更を手続きに乗せます。これにより、スコープクリープによる納期破綻を防げます。
3つ目は「検収＝テストエビデンス」です。
事前に作った受け入れテストのシナリオと、実施した証拠に基づいて合否を判定します。
検収時の「言った・言わない」を避けることで、納品を円滑に進められます。
3点セットは契約前に合意し、プロジェクト全体で徹底します。
まとめ
特定のシステムの各論ではなく、受託開発に共通する期間・スケジュール・納期の考え方を、発注者の視点から解説しました。
期間の目安は、小規模が1〜6ヶ月、中規模が3〜12ヶ月、大規模が6ヶ月〜2年以上です。工程配分から、見積もりの妥当性も確かめられます。
工程配分をもとに見積もりの妥当性を見極めることと、請負・準委任、ウォーターフォール・アジャイルの特性から自社に合う進め方を選ぶことが、納期遵守の土台です。
要件の曖昧さ、意思決定の遅れ、安さを重視した選定は、いずれも発注者の対応で予防できます。だからこそ、RFPと要件定義で前提を固め、進捗管理と変更管理の3点セットを徹底すれば、納期を管理しやすくなります。
まずは、信頼できる開発パートナーと、現実的なスケジュールを共有することから始めます。
▼全体ガイドの記事
・受託開発の完全ガイド
▼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を創業。