要件定義とは？発注者が主導すべき理由・進め方・成果物

システム開発の要件定義は、開発会社へ要望を伝えるためだけの工程ではありません。業務課題、初期リリースの範囲、優先順位、守るべき制約、受け入れるための条件を決め、発注者と開発会社が同じ判断基準を持つための工程です。

外部発注では、技術の専門性を開発会社に頼る場面が多い一方、業務上の優先順位や受入条件まで任せると、完成後に「想定と違う」となりやすくなります。この記事では、RFPとの違い、発注者が決めること、進め方、成果物の見方、見積・変更管理までを整理します。開発会社へ丸投げせず、何を自社で決めて合意すべきかを判断できるようになります。

要件定義では、発注者が業務上の優先順位と受入条件を判断し、開発会社の技術的な提案とすり合わせて開発範囲を合意します。

01Section要件定義とは、開発範囲と受入条件を合意する工程

要件定義とは、「誰のどの業務課題を、どの範囲で解決するか」を具体化し、後続の設計・開発・テストで判断に使える状態にする工程です。機能の一覧だけでなく、対象外、優先順位、利用者、業務上の例外、データ、外部連携、運用条件、受入条件までを関係者で整理します。

工程名や詳細度は案件によって異なりますが、発注者と開発会社で役割や作業を整理する共通の枠組みとして、IPA「共通フレーム2013」も参照できます。民間案件に特定の工程順序を義務付けるものではありませんが、今どの判断が必要かを見失わないために有用です。

RFPでは、比較可能な提案を受けるために、目的、対象範囲、制約、既知の連携やデータ移行、見積条件を整理します。一方で要件定義では、選定後に業務例外、権限、データ項目、運用分担、受入条件などを共同で詳細化します。RFPの準備方法は、RFPの作り方・活用方法も参考にしてください。

選定前から詳細化が必要になるのは、主に次のような場合です。

• 外部連携やデータ移行の条件が、提案や見積の比較可能性を大きく左右する
• セキュリティや制度上の要件が、調達可否や対象範囲に影響する
• 調査や要件定義を先行して扱う必要があり、その成果物を次の契約へ引き継ぐ

この場合も、選定前に確定する範囲と、選定後に見直す範囲をRFPや契約範囲で明確にします。デジタル庁の標準ガイドライン解説書は公共調達向けの資料ですが、要求事項や作業内容を文書化する確認観点として参照できます。民間案件の契約順序を一律に決めるものではありません。

アジャイル開発でも、最初からすべての詳細を固定するとは限りません。しかし、目的、対象利用者、初期範囲、優先順位、制約、意思決定者まで曖昧にしてよいわけではありません。The Scrum Guideが示すように、目的を置き、優先順位を付けた作業項目を継続的に詳細化する進め方になります。

02Section発注者が主導するのは、技術ではなく事業・業務の判断

発注者主導とは、発注者が技術設計を単独で決めることではありません。自社にしか決められない業務・事業上の判断を先送りせず、開発会社の技術提案を受けて意思決定することです。

発注者が最終判断するのは、目的、対象利用者、業務ルール、初期リリースの優先順位、予算・期限の制約、受入条件です。たとえば「現場の申請業務を簡素化する」という目的に対し、どの部門を初期対象にするか、どの例外を初回に扱うか、何を後続に回すかは、発注者側の判断になります。

対して開発会社は、実現方式、技術上の制約、必要な工数、リスク、代替案、設計方針を提案・説明します。発注者は、提案された選択肢が目的・制約・優先順位に合うかを判断し、開発会社はその判断に必要な情報を提示する関係です。利用部門やユーザの主体的な関与の重要性は、IPA「ユーザのための要件定義ガイド 第2版」でも扱われています。

発注前の社内準備を広く見直したい場合は、発注前の社内チェックリストも併せて確認するとよいでしょう。

03Section発注者向け：要件定義を進める7ステップ

機能の詳細化を急ぐ前に、体制・課題・対象範囲を固め、受入条件と変更の扱いまで合意します。

要件定義は、機能の話から始めると、目的や対象外が後から揺れやすくなります。体制と現状を確認し、範囲と成功条件を決めてから、要件・優先順位・受入条件を具体化する順が基本です。

要件整理では、機能以外の条件も確認する

「申請できる」「検索できる」といった機能だけでは、実際に業務で使えるかを判断できません。性能、可用性、運用、セキュリティなどを確認する観点は、IPA「非機能要求グレード2018」も参考になります。発注者は専門用語の網羅より、業務上どの条件が必要かを明らかにします。

04Section成果物は、要件から受入テストまで追える状態にする

成果物は分散していても、各要件を起点に優先度、受入条件、テスト、変更を確認できる状態にすることが重要です。

要件定義の成果物は、1つの要件定義書に章や別紙としてまとめる場合もあれば、要件一覧、業務フロー、画面案、連携一覧、受入条件を複数資料で管理する場合もあります。重要なのは冊数やファイル形式ではなく、範囲・前提・優先順位・受入条件を後から確認できることです。

要件・優先度・受入条件・テストを追える状態を、成果物の品質基準にしてください。要件と事業目的、テスト、変更を関連付けて管理する考え方は、PMIの要件トレーサビリティ解説も参考になります。

たとえば、要件IDを起点に次のように追跡します。

“

FR-01：管理者は申請を承認・差し戻しできる／優先度：Must／前提：権限情報が準備済み／受入条件：権限を持つ管理者だけが承認画面を開け、承認・差し戻しの履歴が残る／受入テスト：権限あり・なしのアカウントで操作し、履歴を確認する／変更履歴：変更IDを記録する

この対応があれば、「どの要件のためのテストか」「変更がどの受入条件に影響するか」を確認しやすくなります。

05Section受入判定と導入後KPIは分けて決める

受入判定は、合意済みの要件・受入条件に適合しているかを確認するものです。操作、権限、外部連携、必要な利用時間帯などについて、あらかじめ定めた条件を受入テストで確認します。

一方、導入後KPIは、業務や事業への効果を継続して確認する指標です。受入テストに合格しても、業務時間や手作業、利用定着への影響は別途測定しなければ分かりません。数値は案件ごとに設定し、測定条件と責任者を先に決めます。

06Section費用・期間は、比率と見積条件を分けて確認する

期間比率、工数比率、費用は同じ尺度ではありません。成果物や調査範囲、レビュー条件をそろえて確認します。

要件定義の予算や日程では、カレンダー期間、ベンダ工数、円建て費用を混同しないことが重要です。外部連携、データ移行、審査、試作、関係部門の多さによって必要な作業は変わり、発注者側の会議・レビュー・承認負荷もベンダ工数とは別に工程表へ置きます。

期間は「全体期間に対する配分」として試算する

JUAS 2020の20.1〜24.6%は、要件定義開始からユーザー総合テストまでの工期を100%としたときの参考比率です。たとえば全体期間を6か月と仮置きするなら、要件定義の初期枠は約1.21〜1.48か月、全体値の22.9%では約1.37か月です。連携先の回答、セキュリティ審査、契約・調達手続きは別タスクとして工程表に置きます。

工数と円建て費用は、見積の前提をそろえて比較する

円建て費用は、比率に一律単価を掛けるのではなく、役割別工数と契約単価を積み上げます。ヒアリング、現状調査、連携・データ移行の調査、試作、非機能・運用の整理、成果物作成、レビュー、変更管理が見積に含まれるかをそろえます。見積の対象作業、成果物、規模、影響要因を明確にする考え方は、IPA「ITユーザとベンダのための定量的見積りの勧め」も参考になります。

契約前・開始前に確認する見積条件

要件定義を先行して扱うか、設計・開発と一体で扱うかは、未確定要件、連携・移行調査、成果物の引継ぎ方、社内規程などで変わります。次の論点を確認します。

個別の契約条件は、利用規模、支援範囲、社内規程、契約内容によって異なります。購買・法務・情報セキュリティなどの担当部門と確認して進めてください。

07Section危険信号を見逃さず、変更は影響を確認して決める

要件定義の問題は、範囲・前提・優先順位・承認の管理が不足することで起きやすくなります。次の兆候があれば、設計や開発を急ぐ前に論点を整理し直します。

• スコープ肥大化：会議ごとに要望が増える一方、対象外や後続対応が決まっていない
• 認識ずれ：「使いやすい」「適切に処理する」など、解釈が分かれる表現が残っている
• 意思決定遅延：未決事項の期限が過ぎ、承認者や代替承認者が決まっていない
• 非機能・運用要件漏れ：権限、ログ、障害時対応、問い合わせ先、データ管理者が未記載である
• 口頭変更の蓄積：議事録、要件、見積、テスト観点の内容が一致しない

変更時は、内容・理由・希望時期を記録し、機能、データ、連携、テスト、運用、費用、納期への影響を開発会社と確認します。そのうえで追加、別要件との入れ替え、後続フェーズへの移管、実施しない選択肢を比較し、承認者が決定します。

PMIの要件管理・トレーサビリティ資料も、要件と変更を関連付けて確認する観点の参考になります。

要件定義で発注者が担うのは、技術の細部を決めることではなく、事業・業務上の優先順位と受入条件を明確にすることです。まずは、自社案件の対象・対象外、決定者、未決事項、受入条件を記録し、次の会議で決めることを関係者と共有しましょう。

要件整理後の開発パートナー探しに

要件の優先順位や受入条件を整理したうえで、Webアプリ・SaaS開発の対応会社を比較したい場合にご活用ください。

Webアプリ・SaaS開発4593社掲載

対応会社を探す