システム開発の期間はどれくらい？規模別の目安とスケジュールの組み方

システム開発の期間は、規模・関係者の数・外部連携の有無で大きく変わります。「いつまでに使えるようになるのか」が分からないと、社内への説明も予算の確保も進みません。この記事では、開発期間の目安を規模別に示し、期間が延びる主な要因、発注側の繁忙期を避けたスケジュールの組み方、リリース日から逆算した発注開始時期の決め方を説明します。

システム開発の期間の目安（規模別）

開発期間を考える手がかりとして、日本情報システム・ユーザー協会（JUAS）の調査があります。ユーザー企業102社・357プロジェクトの工数と工期を分析し、標準的な工期を「投入人月の立方根の2.4倍」と示しました（@IT：JUASの調査結果）。

この式に当てはめると、規模と期間の関係は次のようになります。

※工数から式で計算した値です。規模の区分は説明のための例です。

調査は2007年のもので、現在はAIを使った開発などで期間が短くなる例もあります。それでも「人を2倍に増やしても期間は半分にならない」という感覚をつかむには役立ちます。工数が8倍になっても、標準工期は2倍にしかなりません。裏を返せば、人を増やして期間を縮められる幅には限りがあります。

工数の意味は人月単価の記事で説明しています。

作り方によっても期間は変わる

同じ要件でも、どう作るかで期間は大きく変わります。ある案件で試算された例では、要件が固まってからの期間が、AIを使ったコーディングで約2か月、既製のCMS（Webサイトの管理ツール）と別システムの組み合わせで約3.5〜4か月、従来型のフルスクラッチ（一から作る方式）で約5〜6か月でした。

期間を比べるときは、各社がどの作り方を前提にしているかも確認しましょう。作り方の違いはスクラッチ・パッケージ・SaaS・ノーコードの比較で説明しています。

工期を詰めすぎると失敗しやすい

同じ調査でJUASは、標準工期から30%以上短い期間での開発は無謀だとしています。社内の都合で納期を先に決めた場合でも、標準からどれだけ短いかを確認しておくと、無理なスケジュールに早めに気づけます。

期間が延びる主な要因

JUASの同じ調査では、遅延の理由として最も多かったのは「要件仕様の決定遅れ」で、3番目は「要件分析作業が不十分」でした。発注者側が担う上流の工程が、全体の期間に影響していることが分かります。

現場でよく見る延長の要因は次のとおりです。

• 関係部署の調整に時間がかかる: 仕様の確認に複数の部署が関わると、回答待ちが積み重なります。決める人と期限を最初に決めておくと防げます。
• 外部システムとの連携: 既存の基幹システムや外部サービスと連携する場合、相手側の仕様確認や調整に時間がかかります。
• テストで見つかる不具合: 受入テストで要望の食い違いが見つかると、修正とテストのやり直しが発生します。
• 途中での仕様変更: 開発中の追加要望は、期間と費用の両方に影響します。詳しくは仕様変更と追加費用の記事をご覧ください。

発注側の繁忙期を避けたスケジュールの組み方

開発期間の中には、発注者が時間を割かなければならない工程があります。要件定義の打合せ、画面や仕様の確認、受入テストです。ここが社内の繁忙期と重なると、確認が遅れて全体が後ろにずれます。

スケジュールを組むときは、次の時期を事前に洗い出しておきます。

• 決算期や年度末など、管理部門が忙しい時期
• 業界の繁忙期（小売なら年末商戦、不動産なら春の引越しシーズンなど）
• 年末年始や大型連休
• 社内の人事異動の時期（担当者の交代リスク）

受入テストを繁忙期にぶつけないことが特に大切です。テストには現場の担当者の時間が必要だからです。開発会社には、発注者側の作業がいつ、どれだけ発生するかを工程表に書いてもらうよう依頼しましょう。

リリース日から逆算した発注開始時期

使い始めたい日が決まっているなら、そこから逆算して発注の時期を決めます。たとえば4月1日に使い始めたい中規模のシステムなら、次のような逆算になります。

※期間は一例です。規模や体制で変わります。

逆算で見落としやすいのが、開発会社の「着手までの時間」です。経験のあるメンバーを確保するには、他の案件との調整が必要になり、契約してすぐには始まらないことがあります。選定の段階で、いつから着手できるかを確認しておきましょう。

受託開発の現場から

受託開発の現場でよく使われる期間の考え方から、発注者に役立つものを紹介します。

• 要件定義は1.5〜2か月を見る: 要件定義の期間は1.5〜2か月を想定するのが目安です。画面の使い勝手（UX）の議論まで戻ると、1.5か月では終わらないことがあります。
• 次の発注時期から逆算して着手期限を決める: 次のフェーズを月末に発注したいなら、その約2か月前に要件定義に着手する必要がある、というように、発注者と期限を確認しておく進め方が有効です。導入希望時期から逆算して「この時期の発注が条件」と明示する提案もあります。
• 「すぐ人を出せます」は確認が必要: しっかりしたメンバーを確保するには、他のプロジェクトとの調整が必要です。「人が出せます」と即答されたら逆に注意が必要だ、という見方もあります。
• 段階ごとに期間を区切る: 小さく検証するPoC（試作）は3〜6週間、最低限の機能で出すMVPは約3か月に仮運用1か月、という段階別の期間で提案する例があります。期間は体制を前提に試算し、発注者の確認期間や年末年始も含めます。着手が遅れると全体が同じだけずれることも、提案書に明記しておくと安心です。

まとめ

• 標準的な工期は「投入人月の立方根の2.4倍」という調査結果があり、人を増やしても期間は比例して縮みません。
• 期間が延びる最大の要因は、要件の決定の遅れです。決める人と期限を先に決めましょう。
• 受入テストなど発注者の作業を、社内の繁忙期に重ねないように工程を組みます。
• リリース日から逆算し、選定・稟議と着手までの時間も含めて発注時期を決めます。

自社の案件がどのくらいの規模で、いつまでに発注すべきかが分からない段階でも大丈夫です。FastProposal の無料AI相談なら、案件の内容を整理し、費用の目安を数分で確認できます。