LASSIC Media らしくメディア
システム開発の期間の目安｜新規開発の規模別の月数と延びる原因
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- IPAのデータ集では、プロジェクト全体の期間の中央値は10.1か月です。
- 新規開発の期間は工数の3乗根に比例する傾向があり、工数が10倍でも期間は約2.1倍です。
- 延びやすいのは要求仕様のあいまいさと承認やデータの待ちで、発注側の日程を先に決めておくのが手当てです。
※ 本記事は2026年10月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
見積もりに書かれた開発の期間が、長いのか短いのか分からない。社内の都合で決めた稼働日に、本当に間に合うのか判断できない——。新しい業務システムを外部の開発会社に頼む情報システムの担当者のあいだでは、こうした迷いが起こりがちです。システム開発の期間とは、開発を始めてから終えるまでの月数のことで、作業の量（工数）が同じでも、体制や発注側の関わり方で長くも短くもなります。
規模ごとの目安を持っておくと、見積もりの期間を読み解く手がかりになります。ただし万能ではなく、計算で出した月数をそのまま当てはめるのは危うい使い方とされています。本記事では、新しくシステムを作る情報システムの担当者に向けて、期間の数え方、規模別の目安、見積もりの範囲による違い、延びる原因、そして外部に頼むときに確認したい点を整理します。
システム開発の期間とは
期間の目安を考えるときの手がかりになるのが、IPAの「ソフトウェア開発分析データ集2022」です。2022年9月に公開された資料で、開発会社から集めた5,546件のプロジェクトの実績を分析しています。*1 期間は、工数が発生した最初の日から最後の日（発注者の検収が終わった日や納品日など）までの月数として記録されています。*2
- 期間（工期）：開発を始めてから終えるまでの月数。カレンダーの上での長さです
- 工数：作業の量。1人が1時間働く量を1人時、1か月働く量を1人月と数えます。データ集は1人月を160時間として換算しています*2
- プロジェクト全体の期間の中央値は10.1か月で、短いほうから4分の1の位置は6.0か月、4分の3の位置は15.0か月です（1,396件）*2
- 1年以内に終わったプロジェクトは、およそ6割を占めます*2
同じ工数でも、何人で取り組むかによって期間は変わります。そのため、期間の目安を見るときは、まず作業の量がどのくらいの規模なのかをつかむところから始めます。
規模別の期間の目安
データ集は、新規開発のプロジェクト全体について、期間は工数の3乗根に比例する傾向があるとしています。*2 作業の量が増えても、期間はそれほど伸びないということです。そのとき示された近似の式に、規模の違う4つの工数を当てはめると、次のような月数になります。
| 工数 | 人時に直すと | 期間の目安 | データ集の中での位置 |
|---|---|---|---|
| 10人月 | 1,600人時 | 約6.0か月 | 小さいほうから4分の1の位置（約19人月）より小さい |
| 50人月 | 8,000人時 | 約10.1か月 | 中央値（約46人月）に近い |
| 100人月 | 16,000人時 | 約12.6か月 | 中央値と大きいほうから4分の1の位置（約128人月）のあいだ |
| 300人月 | 48,000人時 | 約17.9か月 | 大きいほうから4分の1の位置より大きい |
表の「位置」は、データ集が示したプロジェクト全体の工数の分布（1,444件・中央値7,395人時）と比べたものです。*2 工数が10人月から100人月へ10倍になっても、期間の目安は約2.1倍にとどまります。
裏返すと、人を増やしても期間は思うほど縮まないということです。データ集は、10万人時以上のプロジェクトで、信頼区間95％の下限より短く終えた例が無かったことから、その下限が工期短縮の限界の一つの目安になるとしています。*2 計算した月数は「真ん中の線」なので、実際の案件は前後に幅を持ちます。
見積もりの範囲による違い
見積もりに書かれた期間を目安と比べるときは、どの工程からどの工程までの期間なのかをそろえます。データ集も、プロジェクト全体と、基本設計から総合テストまでの「開発5工程」を分けて集計しています。*2
| 範囲 | 含む工程 | 見るときの注意 |
|---|---|---|
| プロジェクト全体 | 開発5工程に加え、システム化計画や利用部門による確認のテストを含むことがある | 前の表の目安はこの範囲。見積もりに企画や受け入れの期間が入っているかを確かめる |
| 開発5工程 | 基本設計、詳細設計、製作、結合テスト、開発会社側の総合テスト | 全体より短くなる。開発会社の見積もりはこの範囲で書かれることが多い |
| 改良開発 | 今あるシステムへの機能の追加や変更 | 工数と期間の関係が弱く、データ集は近似の曲線を示していない |
改良開発では、工数と期間の相関が小さいため、データ集は目安の線を示していません。*2 既存の仕組みに手を入れる案件は、規模よりも調べる範囲や影響の大きさで期間が決まりやすいからです。今のシステムを作り直す場合の工程ごとの期間は、システムリプレイスのスケジュールで扱っています。
期間が延びる原因
データ集の自己評価では、納期どおりに終えたプロジェクトが89.3％、30日以上遅れたプロジェクトが4.9％でした（1,311件）。*2 大半は期限を守っている一方、延びるときには発注側の事情が絡むことも少なくありません。データ集が記録している項目をもとに、延びやすい場面と手当てを並べます。
| 延びやすい場面 | データ集の記録 | 手当て |
|---|---|---|
| 要求仕様があいまいなまま設計に入る | 基本設計を始める時点で「ややあいまい」「非常にあいまい」が合わせて27.1％ | 決めきれなかった点を一覧にし、決める日を工程表に書く |
| 発注側の担当者が仕様づくりに関われない | 要求仕様をつくるときの関与が不十分・未関与で1割強 | 業務部門の担当者と打ち合わせの頻度を最初に決める |
| 承認やデータを待つ | 顧客のサイン待ちやテストデータの受領待ちを、作業が止まる期間として記録 | 社内の承認の日とデータを渡す日を工程表に別の行で書く |
| 遅れを人の追加で取り戻そうとする | 期間は工数の3乗根に比例する傾向 | 最初に稼働させる範囲を絞り、残りを次の段階に回す |
表の数値は、データ集の「プロジェクトのユーザ要求と関与」の集計です。*2見落とされやすいのは承認やデータの待ちです。作業する人が待つだけの期間は、規模とは関係なく積み上がるため、発注側の日程を先に押さえておくと防ぎやすくなります。
外部に頼むときに確認しておきたい点
開発会社から期間の見積もりを受け取ったら、月数そのものよりも、その月数の前提を確かめます。データ集は、回帰式で出した値をそのまま見積もりに使うことを「危うい使い方」とし、信頼性や性能の要件が厳しい案件では、計算どおりの期間でも難易度とリスクを話し合って見直す例を挙げています。*2
- 範囲：見積もりの期間が、企画や要件定義、受け入れのテスト、稼働の準備まで含むかどうか
- 根拠：工数と要員の数、似た案件の実績から、どのように月数を出したのか
- 待ちの期間：発注側の承認やデータの受け渡しの日を、誰がいつまでに決めるのか
- 難しさ：性能やセキュリティの要件が厳しい部分に、どれだけ余裕を見ているか
- 段階の分け方：最初に稼働させる範囲と、後から加える範囲に分けられるか
期間と費用は、どちらも工数から決まります。費用の内訳の読み方はWebシステム開発の費用相場にまとめています。期間と費用を同じ前提で並べて見ると、見積もりの比べ方がぶれにくくなります。
まとめ：システム開発の期間で確かめておきたい3つの点
システム開発の期間を見積もりで判断するうえで、確かめておきたい点は3つに整理できます。第一に、作業の量（工数）がどのくらいの規模かをつかみ、規模別の目安と照らし合わせること。第二に、見積もりの期間がどの工程からどの工程までを含むのか、範囲をそろえて比べること。第三に、要求仕様の決め残しや承認とデータの待ちといった、発注側の事情で延びる部分を工程表に書き込んでおくことです。この3点を踏まえておけば、「見積もりどおりに進むはずが、稼働日の直前で数か月延びてしまった」という事態を避けやすくなります。期間の見積もりや範囲の分け方に迷いがあれば、外部の手を借りるのも一つの選択肢です。
よくある質問
見積もりの期間が妥当かどうか、自社で確かめる方法はありますか
公的な資料の目安と比べるだけでなく、自社の過去の案件の工数と月数を記録して比べるのが確かです。データ集も、掲載した回帰式を自社のプロジェクトにそのまま当てはめるのは適当でないとし、考え方を借りて自社のデータで確かめる使い方を勧めています。*2
要件定義の期間も、開発の見積もりに含まれますか
見積もりの書き方によります。基本設計から始まる開発5工程の見積もりなら、要件定義の期間は別に見込む必要があります。要件定義にかかる期間の考え方は、要件定義がどれくらいかかるかの目安で扱っています。
急いで稼働させたいときは、どうすればよいですか
人を増やすより、最初に稼働させる機能を絞るほうが期間を縮めやすくなります。あわせて、社内の承認やデータの受け渡しの日を早めに決めておくと、作業が止まる期間を減らせます。残りの機能は、稼働後の次の段階として計画します。
システム開発の期間と進め方のご相談
新規のシステム開発の期間の見積もりから、稼働させる範囲の分け方、工程表の作成と進み具合の管理まで、元請（プライムベンダー）としてご提案します。
2006年の創業以来、一次請けのシステムインテグレーターとして、企業のシステム開発と保守・運用を受託してきました。
出典
- *1 参考：独立行政法人情報処理推進機構（IPA）「ソフトウェア開発分析データ集2022」（https://www.ipa.go.jp/digital/software-survey/metrics/metrics2022.html）。出典：公開日（2022年9月26日）と、5,546件のプロジェクトのデータを分析した資料であることの記述を参照（2026年10月確認）
- *2 参考：独立行政法人情報処理推進機構（IPA）「ソフトウェア開発分析データ集2022」本編（PDF）（https://www.ipa.go.jp/digital/software-survey/metrics/hjuojm000000c6it-att/000102171.pdf）。出典：1.3.3 工期、1.3.4 工数、1.3.7 プロジェクトの自己評価、A3.2 プロジェクトのユーザ要求と関与、A3.3 工期と工数（近似式 y=0.57x^0.32、工期短縮限界、改良開発で曲線を示さない理由）、A4.4 回帰式利用上の注意事項、A5.2.9 工期の定義を参照。規模別の表は、A3.3.1 の近似式に1人月=160時間で換算した工数を当てはめた計算値（2026年10月確認）
