システム開発期間の目安｜規模別の期間と短縮する5つの方法

システム開発期間の目安は、小規模で半年弱、中規模で1年強、大規模・基幹システムで2年前後です。期間は「開発範囲」「体制」「品質要求」の3つでほぼ決まるため、機能数だけで判断すると見積もりがずれます。

この記事では、公的機関の調査データをもとに規模別の期間を整理し、期間を見積もる3つのステップと、期間を短縮する5つの方法を、起きやすいリスクとあわせて解説します。企画担当者、PM、ITコンサルタントがスケジュールを説明する場面を想定しています。

システム開発期間を決める要素

システム開発期間は、開発範囲・体制・品質要求の3つの組み合わせで決まります。どれか1つだけを見て期間を決めると、ほかの2つが原因で遅延します。

開発範囲：画面数、帳票数、外部システムとの連携数、データ移行の量。範囲が広いほど工数が増えます。
体制：開発メンバーの人数と経験、発注側の担当者が判断に使える時間。人数が多くても、決める人がいなければ止まります。
品質要求：止まったときの影響の大きさ、性能やセキュリティの水準、テストの深さ。基幹系ほど試験に時間がかかります。

工程ごとの期間の配分

新規開発では、基本設計と製作に使う期間の比率が、ほかの工程より高くなる傾向があります。情報処理推進機構（IPA）の『ソフトウェア開発データ白書 2018-2019』では、基本設計から総合テストまでの5工程について、工程別の実績月数の比率を分析しており、新規開発では基本設計工程と製作工程の比率が高いと示されています（IPA、2018年10月発行）。

この5工程には、要件定義と、受入テスト・移行・リリース準備は含まれていません。実際のスケジュールでは、この両端を別に加える必要があります。

要件定義から受入・移行までの7工程とバッファを横に並べた帯グラフ。基本設計と製作の幅が広いことを示している

工程の基本的な流れは、システム開発の開発工程の基本や開発工程と進め方の基本で整理しています。工程どうしの対応関係を押さえたい場合は、Vモデルの考え方が参考になります。

期間が延びる主な原因

期間が延びる原因の大半は、要件の曖昧さ、意思決定の遅れ、後工程での手戻りの3つです。技術的な難しさよりも、決める作業の遅れが期間に響く場面が多くあります。

原因	起きやすい場面	見積もり時の備え
要件の曖昧さ	基本設計の途中で「この帳票も必要だった」と追加される	要件定義の完了条件を、承認者の署名つきで決めておく
意思決定の遅れ	画面や業務フローのレビュー回答に1〜2週間かかる	回答期限を工程表に書き込み、承認者を1人に絞る
後工程での手戻り	総合テストで業務の抜けが見つかり、設計から直す	設計レビューに業務部門を入れ、結合テスト前に画面を見てもらう

遅延の兆候を早めに拾う観点は、システム開発のリスクと管理の進め方にまとめています。

規模別の期間の目安

開発5工程の期間は、小規模で約4か月、中規模で約9か月、大規模で約18か月が参考値です。ここでの規模は、開発5工程の実績工数（人月）で区切っています。

IPAの『ソフトウェア開発データ白書 2018-2019』は、新規開発の開発5工程について、実績工数と工期（月数）の関係を回帰式で示しています。式は「工期＝0.39×工数の0.32乗」（工数の単位は人時、工期は月）で、相関を示すRは0.74です。同白書は「プロジェクト特性によるバラツキはあるが、工期は工数の3乗根に比例する傾向が見られる」としています。分析は過去14年間の開発データ4,564件のうち、直近6年間の1,475件が対象です。

この式に、1人月を160人時として換算した工数を入れた結果が、次の表です。1人月＝160人時は編集部の置いた仮定で、白書の数値ではありません。

規模	開発5工程の工数	開発5工程の期間（式による参考値）	要件定義・受入・移行を足した全体像
小規模	約10人月（1,600人時）	約4か月	約5か月
中規模	約100人月（16,000人時）	約9か月	約11〜13か月
大規模	約1,000人月（160,000人時）	約18か月	約24か月前後

小規模約4か月、中規模約9か月、大規模約18か月という開発5工程の期間の参考値を比べた棒グラフ

右端の列は、白書の式に、要件定義と受入・移行の期間を編集部が加えた見立てです。式の結果は、同じ工数でも体制や要件の固まり具合で上下します。参考値として使い、個別の案件では必ず実績や見積もりで確かめてください。

小規模なWebシステムの場合

小規模なWebシステムは、開発5工程で約4か月、全体で半年弱が目安です。会員登録とマイページ、予約フォームのように、外部連携が少なく画面数が限られる案件が当てはまります。

期間を左右するのは、決済や外部サービスとの連携の有無です。連携先のAPI仕様の確認や審査で、数週間単位で延びることがあります。連携が2つ以上ある場合は、小規模でも中規模の期間感で見ておくと安全です。

中規模の業務システムの場合

中規模の業務システムは、開発5工程で約9か月、全体で1年前後が目安です。受注管理や在庫管理のように、複数部門が使い、既存システムとデータをやり取りする案件が当てはまります。

このクラスでは、要件定義で業務部門の合意を取る期間が長くなりがちです。利用部門が3つ以上になると、部門間の運用の違いを調整する時間が、開発そのものより長くなる場合があります。

大規模・基幹システムの場合

大規模・基幹システムは、開発5工程で約18か月、全体では2年前後を見込むのが一般的な目安です。会計や生産管理のように、止まると事業に影響が出る領域が当てはまります。

この規模では、一括でのリリースを避け、業務の単位で段階的に切り替える計画がよく使われます。データ移行のリハーサルや並行稼働の期間が長くなるため、移行に3か月以上を取る見積もりも珍しくありません。

期間を見積もる手順 STEP1〜STEP3

期間の見積もりは、範囲の確認、工程ごとの積み上げ、バッファの加算の3ステップで進めます。各ステップで、入力と出力を決めておくと、説明の根拠が残ります。

STEP1 開発範囲を確認する

最初に、作るものの範囲を一覧にして、工数の見当をつけます。ここが曖昧なまま日程を引くと、後から範囲が増えて全体が崩れます。

入力：業務フロー、画面や帳票の一覧、連携するシステムの一覧、移行するデータの量
作業：画面、帳票、連携、移行を種類ごとに数え、過去の類似案件の工数を当てはめる
出力：開発範囲の一覧と、開発5工程の概算工数（人月）

STEP2 工程ごとに期間を積み上げる

概算工数から、前の章の式で開発5工程の期間をつかみ、工程ごとに割り振ります。割り振りは、基本設計と製作を厚めにするのが出発点です。

入力：STEP1の概算工数、体制（人数）、発注側のレビュー可能日
作業：式で5工程全体の月数を出し、工程別に割り振り、要件定義と受入・移行を両端に足す
出力：工程別のスケジュール案

次の表は、約100人月の中規模の業務システム（架空の受注管理システム）を例にした割り振りです。配分は編集部が置いた想定で、実績値ではありません。

工程	期間（想定）	この工程の出力
要件定義	1.5か月	要件定義書、業務フロー
基本設計	2.5か月	画面・帳票・データ項目の設計書
詳細設計	1.5か月	処理仕様書、データベース設計書
製作	2.5か月	プログラム、単体テスト結果
結合テスト	1か月	テスト結果報告書
総合テスト	1.5か月	性能・運用を含む確認結果
受入・移行	1か月	受入結果、移行完了報告
小計	11.5か月	開発5工程は9か月

STEP3 バッファとレビュー期間を加える

積み上げた期間に、発注側のレビュー待ちと予備日を加えて、約束できる期間にします。バッファは、小計の1〜2割を目安にする考え方があります。

入力：STEP2のスケジュール案、レビュー担当者の予定、繁忙期や連休
作業：工程の区切りごとにレビュー期間を置き、全体の1〜2割を予備として確保する
出力：関係者に説明する開発期間と、各工程の完了条件

先の例では、小計11.5か月に約1.5か月の予備を加えて、約13か月とします。

コンサルタントがプロジェクトに参画する場合は、契約の期間にも注意が必要です。業務委託では、成果物の完成義務を負わない準委任が約70〜80%を占め、契約期間は3〜6か月で区切るのが一般的とされます。請負は完成義務を負います。開発期間が1年を超える案件では、準委任の更新を前提にするのか、工程ごとに契約形態を分けるのかを、見積もりの段階で整理しておくと、期間の説明が崩れにくくなります。

期間を短縮する5つの方法と注意点

期間を短縮する方法は5つありますが、どれも品質低下や手戻りというリスクを伴います。短縮の効果と引き換えに何を負担するのかを、先に決めておくことが重要です。

方法	期待できる効果	起きやすいリスク	備え
1. 範囲を絞って段階リリースにする	最初の公開が早まる	後回しにした機能が積み上がり、全体では遅れる	後回し機能の一覧と期限を決める
2. 工程を並行して進める	全体の期間が縮む	設計の変更が製作に波及し、手戻りが増える	並行する範囲を、変更の少ない領域に限る
3. 要員を増やす	製作量の多い時期に作業が進む	立ち上がりと連携の手間が増え、品質がばらつく	追加は製作の前に行い、設計の共通理解を先に作る
4. パッケージ・ローコードなど既存部品を使う	製作と試験の量が減る	業務に合わせた調整に制約が出る	要件のうち標準機能で足りない部分を先に洗い出す
5. 発注側のレビューと判断を早める	待ち時間が減る	確認が浅くなり、後工程で不具合が見つかる	回答期限と、判断できる担当者を決めておく

要員を増やす方法については、注意が必要です。前の章の式では、工数が2倍になっても、期間は約1.25倍にしかなりません。ただし、これは異なるプロジェクトを比べた傾向であり、同じ案件で人を増やせば同じ割合で縮むと示すものではありません。人を足しても期間が思うように縮まないことがある、という点は、見積もりの説明で押さえておくと役立ちます。

開発手法による期間の違い

開発手法によって、期間の決め方が違います。ウォーターフォールは全体の期間を先に見積もり、アジャイルは期間を区切って範囲を調整します。

手法	期間の決め方	期間を説明しやすい場面	注意点
ウォーターフォール	要件を固めてから、全体の工程表を作る	範囲が決まっている基幹系、契約前に期間と費用を確定したい案件	要件の変更が後工程の手戻りになりやすい
アジャイル	1か月以内のスプリントで区切り、期間ごとに範囲を決める	要件が固まりきらない新規サービス、改善を続ける案件	最終的な完成時期と総額が見えにくい
ハイブリッド	要件定義と基盤はウォーターフォール、画面や機能の開発はアジャイルで進める	基幹部分は固く、周辺機能は変えたい案件	境界の置き方と、報告の形式を先に決める必要がある

アジャイルでは、期間を固定し、範囲を調整する考え方を取ります。完成時期の約束が必要な場合は、最初のリリースに入れる範囲と、期日までに終えたい範囲を、発注側と合意しておくと説明しやすくなります。

まとめ｜無理のないスケジュールの決め方

無理のないスケジュールは、規模の目安をつかみ、工程ごとに積み上げ、バッファを加えて決めます。小規模は半年弱、中規模は1年強、大規模は2年前後というのが、この記事で扱った参考値です。

期間は、開発範囲・体制・品質要求の3つで決まる
開発5工程の期間は、工数の約3乗根に比例する傾向があり、要件定義と受入・移行を別に加える
見積もりは、範囲の確認、工程ごとの積み上げ、バッファの加算の順に進める
短縮の5つの方法は、品質低下や手戻りというリスクと引き換えになる

期間の数値は、あくまで参考値です。個別の案件では、システムの要件、体制、既存システムとの関係によって大きく変わります。最終的な判断は、ベンダーや専門家と見積もりの根拠を確かめたうえで行ってください。

出典・参考情報

情報処理推進機構（IPA）『ソフトウェア開発データ白書 2018-2019』（2026-10-13参照）：データ件数（過去14年間4,564件、直近6年間1,475件）、発行日（2018年10月1日）
情報処理推進機構（IPA）『ソフトウェア開発データ白書 2018-2019』第6章・第7章の抜粋資料（2026-10-13参照）：工期と工数の回帰式、工程別の実績月数の比率
業務委託契約の形態に関する数値は、編集部が整理した一般的な傾向です。

本記事の内容は2026年10月13日時点の情報に基づきます。規模別の期間は白書の回帰式に編集部の仮定を加えた参考値であり、個別の案件の期間を保証するものではありません。