要求定義と要件定義の違いとは？責任範囲・成果物・契約の分界点を解説

要求定義と要件定義は、名前が似ているだけの別作業です。分けている軸は3つあります。誰が決めるのか（主体）、どこまで具体化するのか（粒度）、何を残すのか（成果物）。この記事では、JIS X 0166:2021 が要求を2つの文書に分けている構造を出発点に、発注者と開発者で責任範囲が切り替わる境界線、そこに対応する準委任契約と請負契約の使い分け、要求定義から要件定義への受け渡しで欠落しやすい情報を整理しました。非機能要求を要求定義の段階でどこまで出すべきか、要求定義を外部に委託してよいのはどんな条件のときかまで、発注側の判断材料として扱います。

まとめ：要求定義は発注者が決める目的・要件定義は開発者が確定させる仕様

切り分けの結論から示します。要求定義は「業務として何を実現したいか」を発注者が言葉にする作業で、要件定義は「そのシステムがどう振る舞えばそれを満たすか」を開発者が仕様として確定させる作業です。JIS X 0166:2021（ISO/IEC/IEEE 29148:2018 に一致）も、利害関係者要求仕様（StRS）とシステム要求仕様（SyRS）を別の文書として規定しています。1つの文書に混ぜないという設計が規格の側にあります。

責任範囲もここで切り替わります。要求定義の成果物に責任を持つのは発注者です。要件定義はベンダーが主導しますが、合意した発注者が内容の妥当性を引き受けます。契約形態も対応しており、IPA・経済産業省の「情報システム・モデル取引・契約書」第二版（2020年12月22日公開）は、要件定義フェーズを準委任、その後の設計・開発を請負として段階的に結ぶ形を示しました。工程が変わるところで契約の型も変わる、と覚えると実務では迷いません。

手戻りが出るのは、要求定義を省いて「要件定義から始めましょう」と着手した案件です。業務側の目的が言葉になっていないため、基本設計の段階で「その画面では現場が回らない」という差し戻しが起きます。差し戻しの発生点が設計工程まで下がるほど、修正の対象は要件定義書・設計書・実装の3つに広がります。

要求定義の外部委託については、立場の明確化が前提です。業務側の意思決定者が同席し、決めた内容にその場で合否を出せるなら委託は成立します。同席させずに「要求もまとめてほしい」と渡す進め方は破綻します。社内に要求をまとめる担当がいない場合、探すべきなのは書き手ではなく決裁できる人です。

要求定義と要件定義を分ける主体・粒度・成果物という3つの観点

定義の文言を並べても区別はつきません。実務で判定に使えるのは、誰が決めるか・どこまで具体化するか・何が残るか、の3点です。規格が2文書に分けている理由から見ていきます。

JIS X 0166が要求を2文書に分ける理由とStRS・SyRSの役割

JIS X 0166:2021 は、2014年6月20日制定の規格を2021年9月21日に改正したもので、国際規格 ISO/IEC/IEEE 29148:2018 と一致する内容です。この規格は要求を扱う文書として、利害関係者要求仕様（StRS）とシステム要求仕様（SyRS）を別に定義しています。StRS は利害関係者が何を必要としているかを利用者の視点で書く文書、SyRS は供給者の視点でシステムが備える特性・機能要求・性能要求を書く文書です。

日本の商慣行でいう要求定義が StRS、要件定義が SyRS に対応します。分けている理由は追跡可能性の確保です。後から「この機能はなぜ必要なのか」を問われたとき、SyRS の各項目から StRS の要求へ遡れる構造になっていれば、削ってよい機能と削れない機能の判定ができます。1つの文書に混ぜると、業務上の要望と技術的な仕様が同じ粒度で並び、スコープを削る交渉のときに何を守るべきかが分からなくなります。

上流工程での並び順と要求定義が抜けた案件で生じる手戻りの構造

ウォーターフォール型の並び順は、要求定義→要件定義→基本設計（外部設計）→詳細設計（内部設計）→実装→テスト→リリースです。工程ごとの位置づけはシステム開発の流れと各フェーズの成果物で通して確認できます。

要求定義が抜けた案件では、この並びの2番目から始まります。ベンダーはヒアリングした内容をそのまま要件に変換するため、要件定義書は形式上は完成します。破綻するのは基本設計以降です。画面や帳票という目に見える形になった段階で業務側が初めて内容を評価し、「この承認フローでは決裁権限規程に合わない」といった指摘が出ます。修正は設計書だけで済みません。要件定義書の該当項目まで戻り、そこから設計・実装を作り直す連鎖になります。要求定義は工数を増やす工程ではなく、差し戻しの発生点を上流に固定するための工程です。

要求定義と要件定義の用語が混在する背景と提案書・見積書の読み替え方

現場で用語が混ざる原因は、ベンダー側の見積単位が「要件定義」でまとめられていることにあります。提案書に「要件定義フェーズ：2か月」とだけ書かれている場合、その2か月に業務ヒアリングと要求の整理が含まれるのか、発注者が提示した要求を仕様化するだけなのかで、作業量は倍以上変わります。

読み替えの手順は決まっています。まず提案書の要件定義フェーズの成果物欄を見て、そこに「業務要求一覧」「現状業務フロー」に相当する文書が挙がっているかを確認してください。挙がっていれば要求定義を含む見積、要件定義書のみなら含まない見積です。含まない場合、発注者側の作業として何を提出する必要があるのかについて、契約前の文書での確定が必要です。この確認を飛ばすと、キックオフ後に「業務フローの提出をお願いします」と言われ、社内調整に3週間かかって工程が押します。要件定義そのものの目的と進め方は要件定義とは何かを整理した解説にまとめてあります。

発注者と開発者で責任範囲が切り替わる境界線と契約形態の対応関係

用語の違いより実損に直結するのが、責任範囲の切り替え位置です。契約の型と対応させて押さえます。

要求定義が発注者側の責任として扱われる根拠と協力義務の実務上の範囲

要求定義の成果物に責任を持つのが発注者である根拠は、その内容を決められるのが業務を回している側だけだという点にあります。業務のどこを変えてよいのか、既存の決裁権限をどう扱うのか、現場の運用をどこまで揃えられるのか。これらはベンダーが調査で埋められる範囲を超えます。

一方で、発注者が単独で完成させる義務があるわけでもありません。実務上の分担は、発注者が業務の目的・対象範囲・制約（予算、稼働時期、既存システムとの関係）を確定させ、ベンダーがそれを引き出すヒアリングと文書化を支援する形になります。この支援を受ける前提で、発注者側にも協力義務が発生します。具体的には、決裁できる人をレビューに出す、指定期日までに現行業務の資料を出す、部門間で意見が割れたときに社内で結論を出す、の3点です。ここが履行されないと、要求が確定しないまま要件定義の期間だけが消費されます。

準委任と請負契約の切り替え位置とモデル契約書第二版が示す分担

IPA・経済産業省の「情報システム・モデル取引・契約書」第二版は2020年12月22日に公開され、要件定義フェーズ以降を対象としたモデル契約書と逐条解説、および再構築方法の検討やリスク対策の支援を内容とする準委任契約としてのコンサルティング契約を含みます。ユーザー企業・ITベンダーのどちらにも利益が偏らない中立の立場で作られている点が、この文書を交渉の基準に使える理由です。

段階的な結び方の基本形は次の通りです。

要件定義を準委任にする理由は、開始時点で完成すべき成果物が特定できないためです。仕様が固まっていない段階で請負にすると、どこまで作れば債務を履行したのかが判定できません。逆に基本設計以降を準委任のままにすると、成果物の完成責任が発注者側に残ります。切り替え位置を要件定義の完了時点に置くのが、双方の責任を対応させる形です。

責任範囲を曖昧にしたまま進めた案件で追加費用が発生する2つの地点

1つ目は、要件定義の完了後に業務側から機能追加が出た地点です。請負契約の範囲は要件定義書で確定しているため、追加は変更契約になります。2つ目は、基本設計中に「業務ルールがまだ社内で決まっていない」と判明した地点です。ベンダーは待機か仮置きで進めるしかなく、後者を選ぶと設計のやり直しが確定します。

ここで効いてくるのが、2020年4月1日に施行された改正民法の契約不適合責任です。この責任が問えるのは、引き渡された成果物が契約で定めた内容に適合していない場合です。仕様そのものが業務に合っていなかった場合は対象になりません。仕様が要件定義書として合意された時点で、その妥当性は発注者側に残る、という構造になっています。だからこそ要件定義書のレビューには、業務を最も把握している担当と決裁できる人の両方を出す必要があります。

要求定義の成果物と要件定義書の記載項目の違いと受け渡しの実務

文書の名前だけを揃えても受け渡しは成立しません。何をどの粒度で書くかを、両側の成果物で対応させます。

要求定義側で確定させる業務要求一覧とRFPに書く実務上の記載粒度

要求定義の成果物は、業務要求一覧と現状業務フロー、そして提案依頼書（RFP）です。業務要求一覧に書くのは「請求書の発行を月末3営業日以内に完了させたい」といった業務の状態であり、「請求書発行画面に一括出力ボタンを設ける」という解決手段ではありません。手段まで書いてしまうと、その手段より安く済む代替案をベンダーが提案できなくなります。

RFP の粒度で外せないのは、対象業務の範囲、達成したい指標、制約条件の3つです。制約条件には稼働希望時期、予算の上限、連携が必要な既存システムの名称とバージョンを入れます。この3つが書かれていない RFP に対する提案は、各社が別々の前提で見積を出すため比較ができません。要求と手段を分けて書くという原則そのものは、要求記述の型を体系化した記法にも共通します。業務要求一覧の内容を、発注後に要件定義書の業務要件パートへ落とし込む手順は業務要件定義の8区分と定義書の作り方で扱っています。

要件定義書に落ちる機能要件・非機能要件・移行要件の具体的な記載内訳

要件定義書は、要求を実現するための仕様に変換した文書です。記載される要件は区分ごとに主体が変わります。

受け渡しで欠落しやすいのは、要求から要件へ変換したときの判断理由です。たとえば「一括出力は対象外とし、5件単位の出力に留める」と決めたなら、その理由（対象データ量と処理時間の見込み）を要件定義書側に残します。理由が残っていないと、テスト工程で「なぜ一括ではないのか」という議論が再燃しかねません。要件の区分の考え方は機能要件と非機能要件・業務要件の違いで詳しく整理しています。

非機能要求を要求定義の段階でどこまで出すかを決める実務上の判断基準

機能の要望は業務側から出てきますが、非機能は放置されやすい領域です。要求定義の段階で出す範囲を決めておきます。

IPA非機能要求グレード2018の6大項目と発注者が答える範囲

IPA の非機能要求グレードは、非機能要求を可用性・性能拡張性・運用保守性・移行性・セキュリティ・システム環境エコロジーの6大項目に整理した資料です。2010年に初版が公開され、指標2項目の追加と20項目の修正を反映した2018年版が現行で、IPA のサイトではアーカイブとして公開が続いています（2026年8月時点）。

指標は200項目を超えますが、発注者が要求定義の段階で答える必要があるのは全項目ではありません。業務の判断が必要な項目に限られます。具体的には、業務が止まって許容できる時間（RTO）、失っても許容できるデータの範囲（RPO）、想定利用者数とピーク時間帯、保存が必要な期間、社内規程で決まっているセキュリティ要件です。冗長化の方式やバックアップの実現手段は要件定義でベンダーが決めます。項目の詳しい構造は非機能要求グレードの概要と非機能要求定義の目的で扱っています。

可用性と性能の要求値を先に出さない案件で見積が振れる幅の実例

数字で見ると差の大きさが分かります。稼働率99.9%は月30日あたり約43分の停止を許容する水準で、単一構成にバックアップからの復旧手順を組み合わせれば届く範囲です。99.99%になると許容停止は約4分で、待機系への自動切り替えが前提になります。サーバー台数、監視の粒度、運用要員の当直体制まで変わります。

この違いを要求定義で示さないまま見積を取ると、A社は99.9%想定、B社は99.99%想定で金額を出し、安いほうを選んだ結果として稼働後に可用性が足りないという事態になります。要求定義で出すべき数字は、システムの目標値ではなく業務の許容値です。「受注が止まって困り始めるのは何分後か」を業務側が答え、その値からシステムの目標値をベンダーが設計する順序にします。

要求定義を外部に委託してよい条件と丸投げが破綻する3つの場面

ここは判断を言い切ります。要求定義の外部委託は条件付きで成立し、条件を外すと失敗します。

要求定義を外部に委託しても成立する条件は意思決定者による会議への同席

委託が成立する条件は1つです。業務の意思決定者が要求整理の場に同席し、その場で合否を出せること。要求定義でやっている作業の本質は、文書を書くことではなく、部門間で衝突する要望に優先順位を付けて決めることです。決める権限を持つ人がいない場では、コンサルタントがどれだけヒアリングしても「両部門の要望を併記した一覧」しか作れません。

同席が確保できるなら、外部の支援には具体的な効果があります。社内の力関係から離れた立場で論点を出せる、業務要求を規格に沿った文書の形に落とせる、非機能の抜けを項目表で埋められる、といった点です。逆に言えば、社内に議事進行ができる人と決裁できる人が揃っているなら、要求定義の外部委託は必須ではありません。

要求定義の丸投げが破綻する3つの場面と避けるべき実務上の進め方の型

破綻が確定する場面は3つあります。

• 業務部門の担当者だけが窓口で、部門長が一度も出てこない
• 現行業務が属人化しており、手順書もフロー図も存在しない
• 導入時期だけが先に決まり、要求整理の期間が2〜3週間しか確保されていない

3つ目は特に見落とされます。要求整理は関係部門の合意形成を含むため、部門が3つ以上関わる案件では1か月を切ると調整が終わりません。避けるべき進め方の型は「要件定義の見積にヒアリングを含めてもらい、要求整理も一緒に済ませる」というものです。ベンダー側は要件定義の期間内に仕様を固める必要があるため、合意形成が終わらない論点は仮置きで前に進みます。仮置きされた要求は、設計工程で必ず戻ってきます。

社内に要求をまとめる担当が不在の場合に先に着手すべき2つの工程

担当者を探す前に着手すべき工程が2つあります。1つは決裁ラインの確定です。要求が衝突したとき誰の判断で決めるのか、その人がレビューに出られる頻度はどれくらいかを先に決めます。もう1つは現行業務の可視化で、完璧なフロー図は不要です。誰がどの順で何を入力し、どこで承認され、どの帳票が出るのかを、対象業務ごとに1枚で書き出せば要求整理の材料になります。

この2工程を社内だけで進めるのが難しい場合、要件定義の見積を取る前に上流の支援だけを切り出して依頼する方法があります。当社ではDXコンサルティングとして、業務の可視化から要求の整理、システム化範囲の判断までを開発とは別に支援しています。開発の受注を前提にせず要求整理だけを依頼できるかは、委託先を選ぶときの確認点にしてください。

よくある質問

要求定義と要件定義の切り分けについて、発注側から実際に寄せられる質問への回答です。

要求定義と要件定義はどちらを先に行うのですか？

要求定義が先です。業務として何を実現したいかが確定していないと、それを満たす仕様は決められません。ただし完全に直列とは限らず、要求定義の後半でベンダーが技術的な実現性を確認し、実現が難しい要求を差し戻す往復は発生します。往復を前提にしたうえで、確定の順序は要求→要件を守ります。

要求定義は発注者が必ず自社で作らなければならないのですか？

文書化そのものは外部に委託できます。委託できないのは、要望が衝突したときの優先順位付けと、業務を変える範囲の判断です。この2つは業務の意思決定者しか決められません。文書を書く作業と決める作業を分けて考え、決める側を社内に残す形にしてください。

要求定義書と要件定義書は1つの文書にまとめてもよいのですか？

小規模で関係部門が1つの案件なら、1つの文書に章を分けて収める運用でも回ります。ただし章は必ず分けてください。JIS X 0166:2021 が StRS と SyRS を別に規定しているのは、後から仕様の削減を検討するときに、業務要求まで遡れる構造が必要になるためです。章が混ざっていると、削ってよい仕様の判定ができなくなります。

アジャイル開発では要求定義と要件定義はどう扱われるのですか？

工程としてまとめて実施しない代わりに、両方の判断が反復のたびに発生します。プロダクトバックログの項目が要求に相当し、各項目の受け入れ条件が要件に相当します。主体の切り分けは変わりません。何を優先するかは発注者側のプロダクトオーナーが決め、どう実装するかは開発チームが決めます。

要件定義の費用は誰が負担するのが一般的ですか？

要件定義は準委任契約で発注者が費用を負担するのが基本形です。「開発を受注できたら要件定義は無償」という提案は、要件定義が営業活動に組み込まれることになり、スコープを絞る方向の提案が出にくくなります。モデル契約書第二版が要件定義フェーズを独立した契約として扱っているのも、この段階の作業を対価のある業務と位置づける趣旨です。

関連記事

• 要件定義とは？目的・進め方・成果物と失敗を防ぐポイントを解説：要件定義そのものの進め方と成果物を詳しく扱っています。
• 要件定義書の書き方とは？記載項目・章立てサンプル・作成のコツを解説：要件定義書に何をどう書くかの具体的な章立てが分かります。
• 仕様書とは？設計書・要件定義書との違いと発注者が確認すべき観点を解説：要件定義より下流の文書との違いを整理しています。
• 基本設計とは何か：システム開発の基盤を理解する：要件定義の次工程で何が決まるのかを扱っています。
• EARS記法とは？6つの型と書き方・実例をKiro連携まで解説：要求を曖昧さなく書き表すための記法をまとめています。