受託・カスタム開発に共通して、期間は規模と工程の配分、開発手法で大きく変わり、発注方式によっても違います。要件と変更を管理しながら計画を立てると、現実的な納期につながります。
全体では3ヶ月から2年以上と幅があるため、発注の前に規模に合った目安をつかんでおくことが大切です。
▼全体ガイドの記事
・システム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
システム開発の開発期間の全体像
全体では3ヶ月から2年以上と幅があります。期間を左右するのは、業務範囲、既存システムとの連携、機能の複雑さです。なかでも、基幹システムなど複数部門やシステムをまたぐ開発では、要件定義だけで数ヶ月かかる場合もあります。
システム規模別の開発期間の目安
規模ごとの期間を並べると、計画を立てるときの納期の目安をつかめます。
- 小規模：簡易な業務管理や予約管理など、機能を絞ったシステムで、3〜6ヶ月程度が目安です。
- 中規模：会員管理や販売管理のように複数機能や外部連携を含む構成では、6〜12ヶ月程度です。
- 大規模：基幹システムや、複数部門・システム間の複雑な連携を伴う開発では、12ヶ月〜2年以上です。
いずれも目安で、実際の期間は要件の明確さや発注側の意思決定の速さによって変わります。
発注する案件の規模と工程ごとの期間配分を把握しておくと、現実的な計画を立てられます。さらに、提示された日程の妥当性も判断しやすくなります。
開発フェーズ別の期間配分
次に示すのは、IPA（独立行政法人情報処理推進機構）の統計などに基づく、標準的なウォーターフォール型開発の配分の目安です。
- 要件定義：プロジェクト全体の約20〜25%の期間。
- 設計からリリース：残りの約75〜80%の期間。
たとえば、全体が6ヶ月（約24週）の中規模案件なら、要件定義は約1.5ヶ月（約6週）、設計からリリースまでは約4.5ヶ月（約18週）が目安です。
要件定義では、発注側と開発会社で、目的や必要な機能、性能・セキュリティなどの非機能要件を定めます。この期間が短すぎると、後工程で解釈のずれや手戻りが起き、全体の日程が崩れる原因になります。見積もりの段階で、要件定義に十分な期間があるかを確認しておくと安心です。
開発手法によるスケジュールの違い
代表的な手法は、ウォーターフォール型とアジャイル型です。手法によって節目の設定やリリースまでの見通しが変わるため、発注担当者が各手法の特徴を理解しておくと、現実的な納期設定につながります。
ウォーターフォール型開発のスケジュールの特徴
要件定義から設計、開発、テスト、リリースへと順番に進める手法です。開始の時点で要件を確定させておくのが特徴です。
- 利点：開発の開始時点で、スケジュールと予算の全体像をつかめます。
- 発注側の安心感：最初にまとまった納期の提示を受けられます。
- 注意点：期間は数ヶ月から数年にわたりやすく、開始後の仕様変更は難しくなります。
- 向く案件：要件が固まりやすく、途中の変更が少ない基幹システムなど。
アジャイル型開発のスケジュールの特徴
機能を小さく分けて、設計、開発、テストを短いサイクルで繰り返しながら完成させます。このサイクルは、一般に「2週間スプリント」と呼ばれます。
- リリース：CI/CD（継続的インテグレーション・継続的デリバリー）により、週次や隔週のリリースも可能です。
- 利点：現場の反応を見ながら、仕様変更に柔軟に対応できる点です。
- 注意点：最終納期を確定しにくく、機能追加を続けると費用や期間が増えやすくなります。
- 向く案件：要件が固まっていない、または途中で優先順位が変わりそうな案件です。
発注方式（内製・外注・オフショア）が納期に与える影響
期間は、開発手法のほかに、誰がどのように開発するかによっても変わります。内製、開発会社への外注、海外チームへのオフショア委託では、日程の組み方やリスクが異なります。
外注（受託開発）における納期の考え方
外注では、必要なスキルを持つエンジニアをまとめて確保できるため、自社に専門人材がいなくても計画を立てやすくなります。代表的な契約形態は、請負契約と準委任契約です。
- 請負契約：成果物の完成を約束するため、納期と予算を見通しやすい形態です。
- 準委任契約：実際にかかった工数に応じて費用が発生し、アジャイル開発と相性がよい形態です。
請負では、途中で仕様変更が入ると、追加費用や納期の見直しが起きやすくなります。一方、準委任は変更に柔軟に対応できますが、費用や期間が当初の想定より膨らむリスクがあります。
案件の性質に合わせて契約を選び、納期の責任の所在を事前に明確にしておきましょう。
オフショア開発が納期に与える影響とリスク
ベトナムやインドなど海外に委託すると、人件費を国内開発の50〜70%程度に抑えられる場合があります。ただし、納期には特有のリスクもあります。
- 認識のずれ：文化や商習慣の違いから、日本人には暗黙のニュアンスが伝わらず、手戻りが起きることがあります。
- 意思疎通の支援：日本語と現地語に精通したブリッジSEの確保が欠かせません。
- 仕様書の具体化：内容を詳しく定め、コスト効果と日程の安定性を見比べます。
仕様書どおりでも現場で使いづらい場合があり、修正で納期が遅れることがあります。そのため、検討の段階では余裕を持って納期を設定しておくと安心です。
納期遅延の主な原因と対策
想定外の事態で納期が遅れることもあります。ただし、よくある原因を把握して事前に対策しておくと、遅延のリスクを減らせます。
要件定義の曖昧さと仕様変更（スコープクリープ）
要件定義が不十分なまま開発を始めると、曖昧な要件が後から機能の追加や仕様変更を招き、納期遅延の一般的な原因になります。
変更のたびに手戻りが生じ、当初想定した工数の1.3〜1.5倍に膨らむケースもあります。その結果、納期が大幅に遅れることがあります。
- 機能を絞る：最初からすべてを盛り込まず、必要最小限の機能で始めます。
- 変更を記録する：変更要求書を起票し、追加工数と日程への影響を評価します。
- 合意して進める：評価内容をもとに、発注側と開発会社で取り決める仕組みを用意します。
キーマン不在・無理な人員追加のリスク
決裁者が会議に継続して加わらない状態が続くと、現場担当者だけでは仕様を決められず、開発チームの待ち時間が積み重なって日程が崩れます。
- 決裁者の参加：週次などの会議に、最低でも月1回は出席してもらいます。
- 議事録の記録：「合意・宿題・期日・責任」の4点を残し、会議の場で意思決定します。
- 遅延時の対応：人員を追加するより、機能範囲や段階的なリリースを見直します。
遅れを人員追加で取り戻そうとすると、引き継ぎや連絡の負担が増え、かえって遅れることがあります。新規メンバーの追加が遅延を招くこの経験則は、ブルックスの法則と呼ばれます。
納期を守るために発注担当者が押さえるべきポイント
発注側が主体的に動くと、遅延を予防できます。具体的には、要件と節目を明確にし、進捗や変更を管理します。
要件定義書とマイルストーンの明確化
最初に要件概要書を作り、開発会社との認識違いを減らします。そこには、次の情報を可能な範囲で具体的に書き込みます。
- システムの範囲：画面数、主要機能、対応デバイスを挙げます。
- 利用と連携：想定ユーザー数の規模や、連携する外部システムの有無を示します。
- 希望日程：希望納期とリリース目標日を伝えます。
主要なマイルストーンは、要件定義と設計の完了、開発とテストの完了、リリースです。達成基準も開発会社と事前に合意しておきます。節目が曖昧だと、どこで遅れているかを客観的につかめず、対応が後手に回ります。
進捗管理と変更管理プロセスの徹底
開始後は、週次や隔週で進捗報告会を設け、計画と実績の差を早期に把握できる体制を作ります。
- 余裕の確保：予算とスケジュールに、それぞれ15〜20%程度のバッファを設けます。
- 段階的な開発：固定条件がある場合は、MVP（実用最小限の製品）を定義します。
まずMVPを公開し、第二弾以降で機能を広げていけば、限られた予算と期間でもリリースしやすくなります。
発注担当者が受け身にならず、管理の仕組みを開発会社に提案して確認することが、納期を守る近道です。
まとめ
ここまで、規模別の期間目安と工程配分、手法や発注方式による違い、遅延の対策を見てきました。小規模は3〜6ヶ月、中規模は6〜12ヶ月、大規模は12ヶ月〜2年以上が目安です。
要件定義には全体の約20〜25%を充てます。この配分を基準にすると、開発会社が示すスケジュールの妥当性を判断しやすくなります。
納期は、規模、工程配分、手法によって変わります。さらに、契約形態や委託先によっても変わります。要件定義書とマイルストーンを明確にし、進捗と変更を管理しておきましょう。予算とスケジュールには、それぞれ15〜20%程度のバッファを確保します。
発注を検討する際は、要件概要を整理して複数の開発会社に相談し、スケジュールを具体的にすり合わせることから始めましょう。
▼全体ガイドの記事
・システム開発の完全ガイド
▼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を創業。