システム開発の期間の目安とスケジュールの立て方
「新システムを来年4月から使いたいが、今から間に合うのか」「開発会社から提示されたスケジュールが妥当なのか判断できない」。システム開発の期間は、発注者にとって費用と並んで見通しを立てにくい要素です。稼働時期は決算期や繁忙期、補助金の事業期間とも関わるため、逆算して計画を立てる必要があります。
この記事では、システム開発にかかる期間の目安を規模別・工程別に整理し、発注者がスケジュールを立てる手順、期間が延びる原因と短縮の考え方を解説します。開発会社のスケジュール案をチェックするときの観点もまとめています。
- 期間の目安は小規模で3〜6か月、中規模で6か月〜1年、基幹システムなど大規模では1年以上かかることが一般的です。
- 工程別では、要件定義と設計で全体の3〜4割、テストで2〜3割程度を占めます。
- スケジュールは稼働希望日から逆算し、発注前の準備期間と稼働後の並行運用も含めて考えます。
- 期間が延びる最大の原因は発注者側の判断待ちと仕様変更で、バッファの確保が欠かせません。
目次
システム開発のスケジュールとは？期間を決める要素
システム開発のスケジュールとは、要件定義から設計・開発・テスト・リリースまでの各工程に必要な期間と順序、発注者と開発会社それぞれの作業や確認のタイミングを時系列で整理した計画のことです。開発期間は主に「規模（機能数・画面数）」「複雑さ（業務ルールや外部連携）」「体制（開発人数）」「発注者側の意思決定の速さ」の4つで決まります。
人を増やせば期間が短くなると考えがちですが、システム開発では人数を増やすほど調整や引き継ぎの手間が増えるため、単純に比例して短くはなりません。無理に短縮したスケジュールは品質の低下につながりやすい点に注意が必要です。
規模別の開発期間の目安
| 規模の目安 | システムの例 | 期間の目安 |
|---|---|---|
| 小規模 | 単一業務の管理システム、Excel・Accessからの置き換え | 3〜6か月程度 |
| 中規模 | 複数部署で使う業務システム、会員向けWebシステム | 6か月〜1年程度 |
| 大規模 | 基幹システムの刷新、多数の外部連携を伴うシステム | 1年〜2年以上 |
いずれも発注後の開発期間の目安です。実際には、開発会社の選定や社内稟議など発注前の準備に1〜3か月程度かかることが多く、稼働後も旧システムとの並行運用や操作研修の期間が必要になります。
工程別の期間配分
一般的なウォーターフォール型の開発では、各工程の期間配分は次のようなイメージです。
工程別の期間配分の目安（全体を100とした場合）
意外に長いのがテスト期間です。開発会社内のテストに加え、発注者が実際の業務データで確認する受入テストの期間も必要になります。
スケジュールの立て方：稼働日からの逆算5ステップ
発注者がスケジュールを考えるときは、稼働希望日から逆算するのが基本です。
- 稼働希望日と理由を決める「期首から」「繁忙期の前に」など、その日である理由を明確にします。動かせない日かどうかも整理します。
- 稼働前の準備期間を確保するデータ移行、操作研修、旧システムとの並行運用に1〜2か月程度を見込みます。
- 開発期間の目安を当てはめる規模に応じた開発期間を置き、受入テストの期間を必ず含めます。
- 発注前の期間を逆算する開発会社の選定、見積もり比較、稟議・契約に必要な期間を置きます。
- バッファを加えて開始時期を決める全体の1〜2割程度の予備期間を置き、今いつ動き出すべきかを確認します。
逆算スケジュールの例（中規模・4月稼働を目指す場合）
| 時期 | 主な作業 | 発注者の役割 |
|---|---|---|
| 前年3〜4月 | 目的整理・開発会社選定・見積もり比較 | RFP作成、比較・決裁 |
| 前年5〜6月 | 要件定義 | 業務説明、要件の判断・承認 |
| 前年7〜8月 | 設計 | 画面・帳票イメージの確認 |
| 前年9〜11月 | 開発・社内テスト | 進捗確認、移行データの準備 |
| 前年12月〜1月 | 受入テスト | 実データでの確認、不具合報告 |
| 2〜3月 | データ移行・研修・並行運用 | 現場への展開、稼働判定 |
開発期間が延びる主な原因
スケジュール遅延は開発会社の作業遅れだけで起きるわけではありません。むしろ発注者側の要因で延びるケースが多く見られます。
- 判断待ち：仕様の確認依頼に対して社内の回答や決裁が遅れる。
- 仕様変更：設計・開発が進んでから要件の追加や変更が発生する。
- 資料・データの準備遅れ：移行データや帳票サンプルの提供が遅れる。
- 受入テストの工数不足：現場が繁忙で確認に時間を割けない。
- 外部連携の調整：連携先システムの仕様確認や接続テストに時間がかかる。
要件定義の段階でつまずくと後工程すべてに影響するため、要件定義の失敗例もあわせて押さえておくと安心です。
期間を短縮したいときの考え方
稼働日が動かせない場合でも、品質を落とさずに期間を短くする方法はあります。
有効な短縮策
- 最初のリリースを必須機能に絞り、段階的に追加する
- 判断者を明確にし、確認の回答期限を決める
- 既存のパッケージやSaaSと組み合わせる
- 移行データの整備を開発と並行して進める
避けたい短縮策
- テスト期間を削る
- 要件定義を省略して開発に入る
- 途中から人員を大幅に増やす
- 受入テストを形だけで済ませる
特に段階リリースは、稼働日を守りながら全体の品質も確保しやすい方法です。どの機能を初回に入れるかは、要件定義の段階で優先度をつけておくと判断しやすくなります。
スケジュールを管理するときのポイント
スケジュールは立てて終わりではなく、進行中の管理が大切です。発注者側でも次の点を意識しておくと、遅れに早く気づけます。
- マイルストーンを決める：要件定義書の承認日、設計の確認日、受入テスト開始日など、節目の日付を合意しておく。
- 定例会で遅れを確認する：週1回や隔週など定期的に進捗を確認し、遅れがあれば理由と挽回策を聞く。
- 回答期限を守る：開発会社からの質問に回答期限を設け、社内で判断が止まらないようにする。
- 課題を一覧で管理する：未決事項や懸念点を一覧にし、担当者と期限を決めて消し込んでいく。
遅れが判明した場合は、稼働日を守るために範囲を絞るのか、稼働日を延ばして全機能をそろえるのかを早めに判断しましょう。判断が遅れるほど選択肢は少なくなります。
よくある質問
- 小さなシステムなら1か月で作れますか？
- 機能が非常に限られていれば可能な場合もありますが、要件の整理やテストを含めると、小規模でも3か月程度は見込むのが一般的です。短すぎる期間は確認不足による手戻りのリスクが高まります。
- 開発会社のスケジュール案で確認すべき点は何ですか？
- 受入テストの期間が含まれているか、発注者の確認作業がいつ発生するか、バッファがあるかの3点を確認しましょう。移行や研修の期間が抜けていないかも重要です。
- アジャイル開発なら期間は短くなりますか？
- 必ず短くなるわけではありませんが、優先度の高い機能から短い周期でリリースできるため、最初に使い始めるまでの期間は短くしやすい傾向があります。全体の完成時期は機能範囲次第です。
- スケジュールが遅れた場合、追加費用はかかりますか？
- 遅れの原因によって異なります。開発会社側の作業遅れであれば通常は追加費用になりませんが、発注者側の仕様変更や判断の遅れが原因の場合は、延びた期間分の費用を請求されることがあります。原因を記録しておくことが大切です。
まとめ
システム開発の期間は、小規模で3〜6か月、中規模で6か月〜1年程度が目安で、発注前の準備や稼働前の移行・研修期間も別途必要です。スケジュールは稼働希望日から逆算し、発注者側の判断や確認のタイミングを含めて計画することが遅延を防ぐ鍵になります。
この記事に関連するサービス
受託システム開発
業務システム・Webシステム・基幹システムを、要件が固まる前のご相談から設計・開発・運用保守まで一貫して開発します。プロトタイプで早い段階から画面を確認でき、開発資産の活用で品質を… サービスの詳細を見る
