LASSIC Media らしくメディア
要件定義がどれくらいかかるかの目安｜作業ごとの期間と延びる理由
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- IPAの白書では、要件定義から総合テストまでの月数に占める要件定義の比率は中央値15.5％でした。
- 要件定義の期間は人数より、決める人の参加と現行業務の見え方、要望の絞り込みで長さが変わります。
- 決める場・調べる期間・変更の段取りと、後半2週間ほどの見直しの期間を工程表に入れておきます。
※ 本記事は2026年10月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
システムの刷新を決めたものの、要件定義にどれくらいかかるのか見当がつかない。開発会社の計画では要件定義が1か月しかなく、それで足りるのか判断できない——。システムの発注を担当する情報システム部門では、こうした迷いが起こりがちです。要件定義の期間とは、業務部門とシステム部門が新しいシステムで何をするかを決め、要件定義書にまとめるまでにかかる時間です。
期間の目安は、全体の工期に占める比率で確かめられます。ただし万能ではなく、実際の長さは、決める人が参加できるかや、いまの業務がどれだけ見えているかで大きく変わります。本記事では、システムの発注を担当する方に向けて、要件定義の期間の目安、作業ごとの期間の決め手、延びる理由と手当て、そして外部に頼むときに確認したい点を整理します。
要件定義の期間とは
要件定義の期間を見積もるときは、どの作業までを要件定義に数えるかを、発注する側と受ける側で先にそろえておきます。IPA（情報処理推進機構）のガイドは、要件定義を、業務で何を変えたいかを決めるビジネス要求の定義、システムに何をさせるかを決めるシステム化要求の定義、その2つを計画どおりに進めるためのマネジメントの3つに分けて整理しています。*2 期間に含める作業は、おおむね次の5つです。
- 計画づくり：作る文書、作成と確認の担当、承認する人、変更の段取りを決める
- 現状の把握：いまの業務とシステムを、資料と聞き取りで洗い出す
- 要求の洗い出しと優先順位：業務部門の要望を集め、実現するものを選ぶ
- 要件定義書へのまとめ：機能と、性能・運用などの非機能の要件を文書にする
- レビューと合意：業務部門と内容を確かめ、承認を得る
要件定義がどれくらいかかるかは、作るシステムの大きさだけでは決まりません。上の5つのうち、どこで待ちや手戻りが起きるかで長さが変わります。
期間の目安はどのくらいか
要件定義の期間は、全体の工期に占める比率で見ると目安がつかみやすくなります。IPAの「ソフトウェア開発データ白書2018-2019」は、近年6年間のプロジェクトのデータから、要件定義から総合テストまでの6工程の月数の合計に対する要件定義の比率を集計しています。*1 IPAの要件定義ガイドにも、情報システムを利用する企業の団体であるJUASの調査をもとにした比率が載っています。*2 数え方が違うので、2つの数値は単純には比べられません。
| 資料 | 数え方 | 件数 | 要件定義の比率 |
|---|---|---|---|
| IPA 白書（新規開発） | 要件定義から総合テストまでの6工程の月数の合計に対する比率 | 120件 | 中央値15.5％（半数は12.2〜21.3％） |
| IPA 白書（改良開発） | 同上 | 120件 | 中央値15.5％（半数は10.3〜20.1％） |
| JUAS調査（IPAガイドに掲載） | 要件定義から利用部門の総合テストまでの工期を100％とした割合 | 76件 | 22.5％ |
工程表を見るときは、要件定義から総合テストまでの期間のうち、要件定義が1割を下回っていないかを確かめます。1割を下回る計画は、白書の新規開発で比率の低いほうから4分の1にあたる12.2％よりも短い計画です。*1
もう一つ押さえておきたいのは、人数との関係です。白書では、新規開発の工数に占める要件定義の比率は中央値8.9％で、月数の比率より小さくなっています。*1 IPAのガイドも、要件定義の工期の割合は投入した工数の割合より大きく、要件定義では人を増やしても進み方が速くなるとは限らないと指摘しています。*2 要件定義の期間は、人数より、決める人がどれだけ時間を割けるかで決まる工程だといえます。
作業ごとの期間の決め手
作業ごとの日数は、公的な資料では示されていません。そこで、次の表では作業ごとに「期間を決めるもの」と「延びやすい理由」を並べました。見直しの期間だけは、IPAのガイドが目安を示しています。
| 作業 | やること | 期間の目安 | 延びやすい理由 |
|---|---|---|---|
| 計画づくり | 作る文書の一覧、作成と確認の担当、承認する人、変更の段取りを決める | 決め手：体制と承認する人が決まっているか | 承認する人が決まらず、着手が遅れる |
| 現状の把握 | いまの業務とシステムを、資料と聞き取りで洗い出す | 決め手：設計書が残っているか、業務を知る人がいるか | 現行のシステムの中身が分からず、調べ直しになる |
| 要求の洗い出しと優先順位 | 業務部門から要望を集め、実現するものを選ぶ | 決め手：関わる部門の数 | 要求が膨らみ、捨てる判断ができない |
| 要件定義書へのまとめ | 機能の要件と、性能・運用などの非機能の要件を文書にする | 決め手：対象にする業務の広さ | 非機能の要件を後回しにして、後で足りない点が出る |
| レビューと合意 | 業務部門と内容を確かめ、承認を得る | 決め手：決める人が集まれる頻度 | レビューのたびに新しい意見が出て、まとまらない |
| 見直し・修正 | 前に作った文書にさかのぼって直す | 目安：後半にまとめて2週間ほど | 見直しの期間を取らず、全体が後ろにずれる |
要件定義の文書は互いのつながりが強く、後の作業で前の文書の誤りが見つかることがよくあります。IPAのガイドが後半に2週間ほどの見直しの期間を設けるよう勧めているのは、このためです。*2 この期間を工程表に別の行で書いておくと、手戻りが出ても日程を守りやすくなります。
延びる理由と手当て
IPAのガイドは、JUASの調査で479件のプロジェクトに工期が遅れた理由を聞いたところ、50％以上が要件定義の問題だったと紹介しています。*2 要件定義が延びる理由は、多くの場合、次の4つのどれかに当てはまります。
| 理由 | 起きていること | 手当て |
|---|---|---|
| 決める人がいない | 業務部門の担当者が仕様を判断できない。部門どうしで意見が割れる | 業務を知り、仕様を決められる人を選んで参加の時間を空けてもらう。意見が割れたときに判断を預ける場を、計画の段階で作る |
| 現行の業務が見えていない | 設計書が古く、業務を知る人もいない | 業務分掌規程などの社内資料と聞き取りを組み合わせ、調べる期間を工程表に別に取る |
| 範囲が広がる | 要望が次々に加わり、実現するものを絞れない | 要望に優先順位を付け、見送るものと先送りするものを決める。変更の段取りを先に決めておく |
| 期間を短く詰め込んでいる | 予定の期間で終わらず、決まらない点が残る | 欠かせない作業と省ける作業を分け、大きく遅れたときに文書の詳しさを下げるか次の工程へ回すことを、先に関係者と合意する |
4つのうち、最も影響が大きいのは決める人の参加です。IPAのガイドは、業務の知識があり仕様を決められる人が参加しないと要件は決まらないとし、上の立場の責任者が判断する場（ステアリングコミッティ）を計画の段階で用意しておくことを勧めています。*2 IPAの2017年の分析でも、業務部門の担当者が要求仕様に関わっていると要求仕様が明確なものは約71％、関わっていないと約34％でした。*3
外部に頼むときに確認しておきたい点
要件定義を外部の会社と一緒に進めるときは、提示された期間が何を根拠にしているかを、契約の前に確かめておきます。次の点を見積もりの段階で話し合っておくと、期間のずれを減らせます。
- 期間の根拠：作る文書と作業の一覧から期間を出しているか。見直しの期間が入っているか
- 社内で決める人：業務部門から誰が、週に何回、どのくらいの時間参加するか
- 現状の把握：設計書が残っていない部分を、誰がどこまで調べるか
- 変更と遅れの段取り：要望が増えたときや大きく遅れたときに、誰が何を決めるか
- 完了の基準：どの文書がどの詳しさで承認されたら要件定義を終えるか
費用の考え方や依頼先の選び方は要件定義を外注する費用と進め方で、要件定義の後に続く工程の組み方はシステム導入のスケジュール表で扱っています。
まとめ：要件定義の期間で確かめておきたい3つの点
要件定義がどれくらいかかるかを見積もるうえで、確かめておきたい点は3つに整理できます。第一に、要件定義から総合テストまでの期間のうち、要件定義に1割以上を取っているかを見ること。第二に、決める人の参加と現行業務を調べる期間を、作業ごとに工程表へ書くこと。第三に、要望が増えたときや遅れたときの段取りと、後半の見直しの期間を先に決めておくことです。この3点を踏まえておけば、「要件定義を予定どおりに終えたはずが、設計に入ってから決まっていない点が次々に見つかった」という事態を避けやすくなります。期間の見積もりや進め方に迷いがあれば、外部の手を借りるのも一つの選択肢です。
よくある質問
要件定義が予定より延びそうなときはどうすればよいですか
IPAのガイドは、大きな遅れに備えて、文書の詳しさの一部を概要の水準に下げることや、一部の文書を次の工程へ回すことを、あらかじめ関係者と合意しておくよう勧めています。*2 先に決めておけば、遅れたときにも合意を取りやすくなります。
要件定義だけを先に契約することはできますか
できます。IPAのガイドは、要件定義は準委任契約（作業の遂行に対して費用を払う契約）を基本とし、発注する企業が主体になって進めるよう勧めています。*2 個別の契約の内容は、専門家に確認してください。
非機能の要件も同じ期間の中で決めますか
決めます。IPAのガイドは、機能の要件だけでなく非機能の要件も抽出するよう計画することを、スケジュールを組むときの確認点に挙げています。*2 性能や運用の要件を設計に入ってから決め始めると、後の工程が延びる原因になります。
要件定義の期間と進め方のご相談
要件定義の計画づくりから、現状の把握、要件定義書のとりまとめと進み具合の管理まで、元請（プライムベンダー）としてご提案します。
2006年の創業以来、一次請けのシステムインテグレーターとして、企業のシステム開発と保守・運用を受託してきました。
出典
- *1 参考：独立行政法人情報処理推進機構（IPA）「ソフトウェア開発データ白書2018-2019」（https://www.ipa.go.jp/archive/publish/wp-sd/sd2018.html）。出典：本編7.1節 図表7-1-5・図表7-1-10（要件定義工程も含めた工程別の実績月数の比率）、図表7-1-18（要件定義工程も含めた工程別の実績工数の比率）、刊行にあたって（近年6年間のデータに基づく算出）を参照（2026年10月確認）
- *2 参考：独立行政法人情報処理推進機構（IPA）「ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ」（2019年）（https://www.ipa.go.jp/archive/publish/qv6pgp0000000wrt-att/000079352.pdf）。出典：本ガイドの構成（ビジネス要求定義・システム化要求定義・要件定義マネジメント）、1.1.3（工期遅延理由の分析）、2.1.1（表2.1 開発工程別工期比〔JUAS「ソフトウェアメトリックス調査2016」をもとに作成〕と工期・工数の割合の記述）、4.1.1、4.2.4の勘どころ④（ステアリングコミッティ）、6.2計画立案（11要素、見直し・修正期間、遅延対策、非機能要件の抽出）、6.2.8（準委任契約）、6.3.1、6.3.4（仕様を決められる適任者）を参照（2026年10月確認）
- *3 参考：独立行政法人情報処理推進機構（IPA）「ソフトウェア開発データが語るメッセージ『設計レビュー、要件定義強化のススメ』」（2017年3月31日）（https://www.ipa.go.jp/archive/files/000058505.pdf）。出典：要件定義の質の向上（業務部門の担当者の要求仕様への関与と要求仕様の明確さ）の分析結果概要を参照（2026年10月確認）
