要求定義と要件定義の違い｜発注者が書くべきはどちらか、実例で解説

要求定義は「業務として何をしたいか」を発注者の言葉で決めること、要件定義は「システムで何を、どこまで実現するか」を作る側と合意することです。この記事では、要求定義と要件定義の違いを、受注登録や取引先別の掛率といった同じ業務を「要求」と「要件」に書き分けた実例で示し、発注者がどこまで自分で書くべきかを、大手コンサルティングファーム出身の専門家の知見と公的機関の資料をもとに解説します。

要求定義と要件定義の違い：主語と粒度が違う

要求定義と要件定義は似た言葉ですが、書く人の立場と、書く内容の細かさが違います。要求は「業務としてこうしたい」という業務側の希望、要件は「システムでこう実現し、ここから先はやらない」と決めた内容です。要求はそのままでは見積もりも設計もできず、要件にして初めて見積もり・設計・テストの基準になります。

IPA（情報処理推進機構）の「ユーザのための要件定義ガイド 第2版」（2019年）も、この順番で構成されています。ガイドは「ビジネス要求定義」「システム化要求定義」の章を分けて問題と勘どころを示し、改訂の柱として、ビジネス全体や個々の業務における要求を正しく把握して分析し、それに貢献できる要件を定義することを挙げています。要求が先、要件が後です。要求が曖昧なまま要件を書き始めると、各部門の「今のやり方を残したい」がそのまま機能要件として並び、費用と工期が膨らみます。

調査の数字もこの工程の重さを示しています。JUAS（日本情報システム・ユーザー協会）の「企業IT動向調査報告書2026」では、品質・予算・工期の悪化に影響した工程として「要件定義」を挙げた企業が57.4〜69.0％でした。

※JUASの調査は東証上場企業とそれに準じる企業（回答957社）が対象です。

なお、現場では「要件定義」という言葉が、要求の整理まで含めた工程全体を指して使われることも少なくありません。ベンダーの提案書に「要件定義」と書かれていたら、その中に要求の洗い出しや優先順位づけが含まれるのか、発注者がそれを済ませている前提なのかを確認します。前提が違うと、打ち合わせの回数も、発注者側が用意する資料も変わります。パッケージやSaaSを使う場合は、要求を整理したあとに製品の標準機能と突き合わせる作業が入ります。進め方はフィットアンドギャップ分析とはで解説しています。

実例：同じ業務を「要求」と「要件」に書き分ける

違いは、同じ業務を両方で書いてみると一番よく分かります。次の表は、製造業・卸売業でよく出てくる6つの業務について、現場から出た要求と、それを要件に落とした例です。右端の列は、要件にする過程で決めなければならなかったことです。

※説明用の例です。「3分以内」「20日・末日」などの数値は、自社の業務に合わせて決めます。

表を見ると、要件にする作業は「言い換え」ではなく判断の連続であることが分かります。誰が操作するか、どこまでやるか、何をやらないか。この判断は業務を知っている発注者にしかできません。

要求一覧の書き方：1行1件で「なぜ」を残す

要求定義の成果物の中心は、要求一覧です。会議のメモや部門ごとの要望書のままでは、同じ要求が重複したり、誰の要望か分からなくなったりします。次のような列を持つ表に、1行1件で書き出します。

※説明用の例です。

最後の列が大事です。要件定義に進んだあと、要求ごとに「どの要件で対応したか」「対応しないと決めたか」をたどれるようにしておくと、検収のときに「あの要望はどうなったのか」という議論を一覧で片づけられます。現状の困りごとを集めるときは、業務フロー上の場所と結びつけておくと漏れが減ります。方法はAs-Is/To-Beとはで解説しています。

要求の集め方：ヒアリングだけに頼らない

要求は、会議で「何か要望はありますか」と聞くだけでは集まりません。出てくるのは声の大きい部署の要望と、今の画面への不満が中心になります。次の4つの方法を組み合わせると、言葉になっていない困りごとまで拾えます。

集めた困りごとは、そのまま要求一覧の「困りごと（現状）」の列に入れます。件数や時間を添えておくと、優先順位をつけるときの根拠になります。

※説明用の例です。

発注者が書くべきなのはどちらか

結論から言うと、要求定義は発注者が自分で書くものです。要件定義は、作成作業をベンダーやコンサルタントが担ってかまいませんが、内容の判断と承認は発注者が行います。どちらも「任せきり」にはできません。

大企業の実態もこの分担に近い形です。前述のJUASの調査では、「システム企画（システム化構想策定）」を「ほぼ内製」「内製が多い」と答えた企業が70.9％、「機能要件定義」では46.1％でした。一方、「設計・実装・テスト」は「ほぼ外部委託」「外部委託が多い」が63.4％です。何を作るかを決める上流は自社で、作る作業は外部の力を借りるという分け方が多数派だと分かります。

発注者の判断が遅れたり、決めたことを後から覆したりすることは、契約上の問題にもなり得ます。旭川医科大学とNTT東日本の電子カルテシステム開発をめぐる札幌高裁2017年8月31日判決について、Westlaw Japanの判例コラム第120号は、ベンダーが625項目の追加開発要望を受け入れて仕様凍結の合意をした後も、ユーザー側が162項目の要望を出したと控訴審が認定し、ユーザー側に約14億円の支払いを命じたと解説しています。要求を出し切って優先順位をつけ、決めたら守ることが、発注者の役割です。

要件定義書の作成をベンダーに丸ごと任せると、要求の優先順位がついていないため、ベンダーは「聞いた要望をすべて満たす」形で書くしかありません。その結果、例外処理まで再現した要件になり、見積もりが膨らみます。要件定義書の具体的な書き方は要件定義書の書き方（サンプル・テンプレート付き）で解説しています。

要求を要件に変える5つの問い

現場から出た要求を要件にするときは、1件ずつ次の5つを問います。答えが出ない要求は、まだ要件にできる段階ではありません。

1. なぜ必要か（目的）
   その要求が解決する困りごとは何か。「売上・利益・業務時間・品質・リスク」のどれに効くかを一言で書きます。目的が言えない要求は、優先度を下げる候補です。
2. 誰が、いつ、どのくらいの頻度で使うか
   操作する人の役割（営業、経理、管理者）と、日次・月次などの頻度を決めます。毎日使う機能と年1回の機能では、かけるべき費用が違います。
3. 例外は何か
   「この取引先だけ違う」「月末だけ特別」といった例外を洗い出し、システムで対応するか、運用でカバーするか、やめるかを決めます。
4. 何ができればOKか（受入基準）
   「簡単に」「柔軟に」「適切に」を、時間・件数・操作する人・設定できる範囲などの測れる基準に置き換えます。
5. 何をやらないか（対象外）
   実現する内容と同じくらい、実現しない内容を明記します。「新しい計算ロジックの追加は対象外」「FAX注文のOCRは対象外」のように同じ行に書きます。

例：「請求書をメールで送りたい」に5つの問いを当てる

※説明用の例です。

この例では、問い3で「紙を求める取引先」と「指定様式の取引先」という例外が見つかり、問い5で後者をシステムの対象外にすると決めています。こうした判断を要求の段階で済ませておくと、見積もりの前提がぶれません。

5つの問いのうち、システムの速さや止まったときの復旧のように「機能以外」の要求が出てきたら、非機能要件として別に整理します。書き方は非機能要件とはで解説しています。

要求に優先順位をつける：3つの軸で評価する

要求定義で最も時間がかかるのは、部門ごとに目指す姿が違うときです。経営はコスト削減、営業は入力を減らしたい、経理は管理項目を増やしたい。それぞれ合理的でも、全部を要件にすると費用も工期も収まりません。そこで要求を経営効果・業務効果・実現コストの3軸で評価し、「必須／あれば／後回し」に分けます。

※説明用の例です。評価は自社の状況で変わります。

判断の目安は、その業務が売上・利益・品質・顧客満足に直結しているかです。独自の価格設定や業界特有の原価計算のように競争力につながる業務は、個別に作る価値があります。一方、会計処理や経費精算のような業務は、標準機能に合わせる方が費用も保守も軽くなります。「昔からこの方法だから」は、残す理由になりません。

要求定義が終わったと言える10の条件

次の項目がそろえば、要件定義に進む準備ができています。満たしていない項目があるまま要件定義や見積もり依頼に進むと、途中で前提が変わり手戻りになります。

• 刷新の目的と、成功を測る数字（例：月次決算の締め日数、受注から出荷までの日数）が決まっている
• 対象とする業務・部署・拠点の範囲が決まっている
• 主要業務の現状の流れが図になっている（部署をまたいで1枚）
• 各要求に「なぜ必要か」が1行で書かれている
• 要求に「必須／あれば／後回し」の優先度がついている
• 変えてよい業務と、維持すべき業務が仕分けられている
• 例外処理（特定の取引先・月末処理など）が洗い出されている
• 現場の担当者（実際に入力する人）の意見が入っている
• プロジェクト責任者と、業務領域ごとの決裁者が決まっている
• 決定事項を記録し、関係者が見られる状態になっている

要件定義に進んだあとの会議の回し方と期間の目安は要件定義の進め方で、作り方の比較や見積もり依頼の進め方はRFP（提案依頼書）の書き方を参考にしてください。

よくある質問

まとめ

要求定義と要件定義の違いは、要求定義が「業務として何をしたいか」を発注者が決める工程、要件定義が「システムで何をどこまで実現し、何をやらないか」を作る側と合意する工程である点です。要件定義書の作成は専門家に任せられても、目的・優先順位・対象外・受入基準の判断は発注者にしかできません。現場の要望をそのまま並べるのではなく、要求一覧で「なぜ」を残し、実現する業務と優先順位を決めることが、費用と工期を守るいちばんの近道です。

自社の要求がどこまで整理できているか分からない、という方は、無料診断で現状の課題と、構想策定で決めるべきことを整理します。