当サイトの記事は編集部がIPAなど公的機関の公開資料と読者の声を調べて独自に執筆しています。
『要求定義と要件定義って、一文字違うだけで何が違うの？』と、上司や資料の言い回しに戸惑っている方も多いはずです。
結論から言うと、要求定義は「こうしたい」を集める段階で、要件定義は「こうする」と決めて合意する段階です。この記事では、1つの要望が要件に変わっていく途中の会話を追いながら、2つの違いを実感できるようにお伝えします。
要求定義と要件定義の違いは？まず結論から
要求は「利用者や発注者の願い」、要件は「その中からシステムで実現すると合意したこと」です。要求定義で願いを集めて、要件定義で予算・期間・技術を踏まえて絞り込みます。
要求定義と要件定義は、別々の作業というより、同じ話を前後2段階で扱うものなんです。
最初に出てくるのは「もっと楽にしたい」「探す時間を減らしたい」といった、現場の言葉そのままの願いですよね。
その願いを、実際に作れる形にして「これをやります」と約束したものが要件です。要件定義そのものの全体像は要件定義とはで紹介しています。
違いを観点ごとに並べると、次のようになります。
| 観点 | 要求定義 | 要件定義 |
|---|---|---|
| 扱うもの | 利用者・発注者の「こうしたい」 | システムで実現すると決めた「こうする」 |
| 主な言葉づかい | 〜したい、〜になってほしい | 〜できる、〜する（条件つき） |
| 中心になる人 | 発注側の業務部門、利用者 | 発注側と開発側の両方 |
| 考えに入れるもの | 困りごと、理想の姿 | 予算、期間、技術、運用のしやすさ |
| 終わった時の状態 | 願いが一覧になっている | 実現する範囲に双方が合意している |
| 確かめる場面 | 願いの抜けがないかの確認 | 受入テストで要件どおりかを確認 |
発注側と開発側で、違いの感じ方が変わる
同じ違いでも、立場によって気になるところが変わるんです。
発注側にとっては「自分たちの願いのうち、どれが実現されるのか」が一番の関心事ですよね。要求定義の段階では、遠慮せずに願いを出し切るのが役目になります。
開発側にとっては「どこまでを作ると約束したか」が大事です。要件定義の段階では、作れるかどうかと、作った後に確かめられるかどうかを見ていきます。
この2つの関心がかみ合った時に、要求が要件に変わる、と考えるとイメージしやすいですよ。
要件定義（RD）という略し方も覚えておく
現場では、要件定義を英語の Requirements Definition の頭文字から「RD」と略すこともあります。
一方、要求定義は「要求をまとめる作業」と説明されることが多く、要件定義の前半に含めて扱う会社もあります。呼び方は会社やプロジェクトで揺れるので、最初に「この現場ではどこまでを要件定義と呼ぶか」を確かめておくと安心です。
国際規格でも「要求」の扱い方が決まっている
要件の作り方については、ISO/IEC/IEEE 29148という要求工学の国際規格があります。
この規格では、良い要件の性質として「必要である」「あいまいでない」「検証できる」「実現できる」「矛盾しない」「一つのことだけを言う」「追跡できる」がよく挙げられます。
要求の段階では、この性質がそろっていなくても大丈夫です。むしろ、そろっていない願いを、この性質に近づけていく作業が要件定義だと考えると分かりやすいですよ。
「こうしたい」が「こうする」に変わるまでの会話例
ここがこの記事でいちばん伝えたいところです。言葉の定義を読むより、1つの要望が要件になっていく様子を見たほうが、違いはずっとつかみやすいんです。
架空の題材として、社内の問い合わせ窓口（ヘルプデスク）で受けた相談を記録する仕組みを新しくする場合を例にします。
1回目の打ち合わせ：要求が出てくる
利用部門「問い合わせの記録がばらばらで、前に同じ相談があったか探せないんです」
利用部門「とにかく、過去の問い合わせをすぐ見つけられるようにしたいです」
開発側「すぐ、というのは、どのくらいの速さをイメージされていますか」
利用部門「電話を受けながら探せるくらい、ですかね」
この時点で出てきたのは「過去の問い合わせをすぐ見つけたい」という要求です。願いとしてはとても大事ですが、このままでは何を作ればいいか決められませんよね。
2回目の打ち合わせ：要求を分解する
開発側「探す時は、何を手がかりにしていますか。相談者の名前、内容の言葉、日付などがありそうです」
利用部門「名前と、内容に出てくる言葉ですね。日付はあまり覚えていないです」
開発側「過去の記録は、どこまでさかのぼって探せればいいですか」
利用部門「たいていは直近の相談です。古いものは、たまに見られれば十分です」
ここで「すぐ見つけたい」が、「名前で探したい」「内容の言葉で探したい」「直近の記録が中心」という小さな要求に分かれました。
3回目の打ち合わせ：要件として合意する
開発側「では、相談者名と内容の言葉で検索できるようにします。電話中に使う想定なので、検索結果の表示速度も目標を決めましょう」
利用部門「古い記録まで同じ速さでなくていいなら、費用も抑えられますか」
開発側「はい、その分は今回の範囲から外す案も出せます。部長の判断をいただけますか」
利用部門「それで進めてください。古い記録の扱いは、次の打ち合わせまでに確認しておきます」
こうして「相談者名と内容の言葉で検索できる」「電話中でも待たずに結果が出る」という要件が決まりました。
1回目は願いを聞く場面、2回目は願いを分解する場面、3回目は範囲と優先度を決めて約束する場面でした。要求定義は1回目と2回目、要件定義は2回目の後半から3回目、と重なりながら進むのがふつうです。
要望が要件になるまでの変化を表にすると
| 段階 | 書かれている言葉（例） | 足りないもの |
|---|---|---|
| 要求（そのまま） | 過去の問い合わせをすぐ見つけたい | 何で探すか、どのくらい速くか |
| 要求（分解後） | 名前で探したい、内容の言葉で探したい | どこまでを今回作るか |
| 要件（合意後） | 相談者名と内容の言葉で検索できる、電話中でも待たずに結果が出る | 画面の形などは設計で決める |
表の右の列を見ると、要件になっても「画面の形」はまだ決まっていません。それを決めるのは次の基本設計なんです。要件定義と設計の境目は要件定義と基本設計の違いで詳しくお伝えしています。
要求を要件に近づける聞き方
会話例の開発側は、相手の願いを否定せずに、少しずつ具体的にしていましたよね。聞き方にはいくつか型があるので、覚えておくと打ち合わせが楽になります。
| 聞き方の型 | 聞き方の例 | 引き出せること |
|---|---|---|
| 場面を聞く | それは、どんな時に困りますか | 使う場面と頻度 |
| 手がかりを聞く | 今は何を見て探していますか | 検索や入力に使う項目 |
| 程度を聞く | どのくらいなら困らないですか | 性能や量の目安 |
| 理由を聞く | それができると、何が良くなりますか | 本当の目的と優先度 |
| 範囲を聞く | 今回はどこまでできれば十分ですか | 今回作る範囲 |
特に「理由を聞く」は大事です。理由が分かると、願いそのものより良い解決策が見つかることもあるんです。
要求分析は何をする作業？要求事項の扱い方
『要求定義と要件定義の間に、要求分析という言葉も出てきて混乱する』という声もよく聞きます。
要求分析は、集めた要求を「本当に必要か」「ほかの要求とぶつからないか」「実現できるか」の目で見直す作業です。要求定義と要件定義をつなぐ橋のようなもの、と考えてみてください。
要求事項を一覧にして見直す
集めた願いは、1行に1つずつ「要求事項」として書き出すのがおすすめです。1行に2つの願いが入っていると、片方だけ採用する時に話がこじれやすいからです。
- 打ち合わせや聞き取りで出た願いを、1行1件の要求事項として書き出す
- 似た要求をまとめ、同じ願いの言い換えを1つに寄せる
- 「なぜそうしたいのか」を聞き、本当の困りごとを書き添える
- ぶつかり合う要求を見つけ、どちらを優先するか相談する
- 予算・期間・技術で実現できるかを開発側と見ていく
- 採用する要求、見送る要求、保留する要求に分けて記録する
要求事項一覧の記入例
架空の問い合わせ窓口の例で、要求事項一覧を作るとこんな形になります。
| 番号 | 要求事項（例） | 出どころ | なぜそうしたいか | 判断（例） |
|---|---|---|---|---|
| 1 | 過去の問い合わせを名前で探したい | 窓口担当 | 同じ人からの相談が多い | 採用 |
| 2 | 内容の言葉で探したい | 窓口担当 | 似た相談の答え方を参考にしたい | 採用 |
| 3 | 相談の多い内容を月ごとに集計したい | 窓口の責任者 | よくある相談の手引きを作りたい | 採用 |
| 4 | 相談者に自動で返信したい | 窓口担当 | 受け付けたことを早く伝えたい | 保留 |
| 5 | 古い記録もすべて同じ速さで探したい | 窓口担当 | たまに昔の相談を見返す | 見送り |
ぶつかり合う要求はどう決める？
要求を並べてみると、ぶつかり合うものがよく見つかります。例えば窓口担当の「誰でも記録を見られるようにしたい」と、責任者の「相談内容は担当者以外に見せたくない」は両立しにくいですよね。
こういう時、開発側が勝手にどちらかを選ぶのは避けたいところです。どちらの願いにも理由があるので、両方の理由を聞いたうえで、発注側の責任者に決めてもらいましょう。
開発側「見られる人を広げたい理由と、絞りたい理由を、それぞれ書いてお持ちしました」
利用部門「対応の参考にしたいのは、相談内容より答え方のほうですね。答え方だけ共有できれば十分かもしれません」
このように、理由までさかのぼると、両方の願いを満たす第3の案が見つかることもあります。
優先度をつける時の目安
全部の要求を一度に実現できることは、まずありません。優先度は次のような目安で話し合うと、決めやすくなります。
| 優先度（例） | 目安 | 問い合わせ窓口の例 |
|---|---|---|
| 今回の範囲に入れたい | ないと業務が回らない | 名前と内容の言葉で探せる |
| できれば入れたい | あると業務がかなり楽になる | 相談の分類ごとに件数を出せる |
| 次の機会でよい | 今の手作業でもなんとかなる | 相談者への自動返信 |
「判断」の列があると、見送った要求も消えずに残ります。後から『あの要望はどうなったの？』と聞かれた時に、理由をすぐ答えられるんです。
要求事項を「採用」だけ残して、見送りや保留を消してしまうことです。消した要望は、受入テストの頃に「頼んだはずなのに入っていない」という形で戻ってきやすくなります。
要求定義書と要件定義書は別物？書く人と中身の違い
結論から言うと、要求定義書と要件定義書は、名前が似ていても書く目的が違う文書です。
要求定義書は、発注側が「こうしたい」をまとめたものです。要件定義書は、発注側と開発側が話し合って「こうする」と合意した内容をまとめたものになります。
| 項目 | 要求定義書 | 要件定義書 |
|---|---|---|
| 主に書く人 | 発注側の業務部門や情報システム部門 | 開発側が中心となり、発注側と一緒にまとめる |
| 読む人 | 開発側、提案を出す会社 | 発注側の承認者、設計や開発の担当者 |
| 中心の中身 | 困りごと、目指す姿、要求事項の一覧 | 業務要件、機能要件、非機能要件、移行要件など |
| 書き方 | 願いを漏れなく並べる | 実現する範囲を、検証できる形で書く |
| 承認 | 発注側の中で確認する | 発注側と開発側の双方で合意する |
会社によっては、要求定義書を作らず、要件定義書の「背景・目的」「現状の課題」の章で要求をまとめることもあります。文書の名前より「願い」と「約束」が区別して書かれているかを見てみてください。
要求仕様書という似た名前の文書もあります。こちらとの違いは要求仕様書と要件定義書の違いで、誰が書いて誰に渡すかの流れで紹介しています。
- 見送った要望の理由を後から説明できる
- 発注側の承認者が「何を約束したか」を読み取りやすい
- 受入テストで確かめる項目がはっきりする
- 願いと約束の区別がつかず、作る範囲が広がりやすい
- 「書いてあるのに作られていない」という行き違いが起きる
- どこまでが確定か、読む人ごとに受け取り方が変わる
要求のまま止まっているサインと直し方
『要件定義書を作ったつもりなのに、レビューで「これはまだ要求だね」と言われた』という方もいるかもしれません。
実は、要件定義書の中に要求の言葉が残っていることはよくあります。次のサインが出ていないか見てみましょう。
- 文末が「〜したい」「〜になってほしい」で終わっている
- 「すぐ」「簡単に」「使いやすく」など、人によって受け取り方が変わる言葉がある
- 誰がどんな場面で使うのかが書かれていない
- 受入テストでどう確かめるか、想像できない
- 予算や期間の都合で外したものが書かれていない
要求の言葉を要件の言葉に直す例
直し方のコツは、あいまいな言葉を「確かめられる言葉」に置き換えることです。架空の問い合わせ窓口の例で並べてみます。
| 要求の言葉（例） | 要件の言葉（例） |
|---|---|
| 過去の相談をすぐ探したい | 相談者名と内容の言葉で検索でき、電話中でも待たずに結果が表示される（目標の速さは非機能要件に書く） |
| 誰が対応したか分かるようにしたい | 各記録に対応者と対応日時が残り、一覧で確認できる |
| 担当者以外には見せたくない | 記録の閲覧は、問い合わせ窓口の権限を持つ人に限る |
| 集計を楽にしたい | 相談の分類ごとの件数を月単位で出力できる |
「目標の速さ」のように数字が必要な部分は、発注側と開発側で話し合って決めます。この記事では例として書いていませんが、実際の要件定義書には合意した値を書き込みましょう。
要件定義ガイド
まずは型をそろえよう｜要件定義書のテンプレートと記入例
章立て・各章に書くこと・1行の記入例をひとつの表にまとめました。白紙から書き始める前に、型を手元に置いておきましょう。
無料要件定義書のテンプレートを見る当サイトの記事ページに移動します。
直す時の会話のコツ
あいまいな言葉を見つけた時は、相手を問い詰める聞き方にならないよう気をつけたいところです。
開発側「使いやすく、というのは、どの作業が今いちばん手間ですか」
利用部門「記録を書く時に、同じ相談者の情報を毎回入れ直すところですね」
こう聞けば「使いやすく」が「同じ相談者の情報を入れ直さずに済む」という具体的な要件に近づきます。進め方全体の流れは要件定義の進め方もあわせて読んでみてください。
よくある相談に答えます
要求定義と要件定義について、質問サイトでよく見かける相談を要約して、編集部から答えます。
相談1：新人で、上司から要求定義と要件定義の違いを説明できるようにと言われた
システム会社に入ったばかりで、2つの違いを自分の言葉で説明できず困っている、という相談です。
「要求はお客さんの願い、要件はその中から作ると約束したもの」と一言で言えるようにしておくと安心です。そのうえで、この記事の問い合わせ窓口の会話例のように、1つの願いが要件になる例を1つ自分で用意しておくと、説明に説得力が出ます。
上司に説明する時は、定義より例を先に出すのがおすすめです。『こういう要望が、こういう要件になりました』と話せれば、違いを理解していることが伝わりますよ。
相談2：要求定義、要求分析、要件定義、要件分析と言葉が多すぎて順番が分からない
ソフトウェア開発の工程で、似た言葉がいくつも出てきて混乱している、という相談です。
大まかには「要求を集める（要求定義）」「要求を見直す（要求分析）」「要件として決める（要件定義）」の順です。要件分析という言葉は、要件定義の中で要件を細かく見ていく作業を指して使われることが多く、会社によって意味が揺れます。プロジェクトの最初に、言葉の使い方をそろえておくのがいちばんの近道です。
相談3：要求定義書と要件定義書は、同じものを別の名前で呼んでいるだけ？
社内で両方の名前が出てきて、同じ文書なのか別物なのか分からない、という相談です。
- 一般的には別物で、要求定義書は発注側の願い、要件定義書は双方の合意をまとめた文書です
- ただし、会社によっては1冊にまとめて「要件定義書」と呼ぶこともあります
- 迷ったら、文書の中に「見送った要望」と「合意した範囲」が分けて書かれているかを見てみてください
よくある質問
要求定義と要件定義は、どちらを先にやるのですか。
要求定義が先です。ただ、実際の現場では要求を集めながら要件を固めていくので、2つは重なりながら進みます。
要求分析と要件定義の違いは何ですか。
要求分析は、集めた要求が本当に必要か、ほかの要求とぶつからないかを見直す作業です。要件定義は、その結果をもとに実現する範囲を決めて合意する作業です。
要求事項と要件の違いを一言で言うと何ですか。
要求事項は「こうしたい」という願いを1件ずつ書き出したもので、要件はその中から「こうする」と決めたものです。
要求定義の段階で、実現できるかどうかを気にするべきですか。
最初は気にしすぎなくて大丈夫です。願いを出し切ってから、要求分析と要件定義で実現できるかを見ていくほうが、大事な要望の取りこぼしを防げます。
発注側だけで要件定義を終えることはできますか。
要求をまとめることは発注側だけでもできます。ただ、実現できるかや費用の見通しは開発側の意見が欠かせないので、要件として合意するには双方の話し合いが必要です。
まとめ
- 要求定義は「こうしたい」を集める段階、要件定義は「こうする」を決めて合意する段階です
- 要求分析は、集めた要求を見直して要件につなぐ作業です
- 要求事項は1行1件で書き、見送った要望も理由と一緒に残しておきましょう
- 要件定義書に「〜したい」「すぐ」「使いやすく」が残っていたら、確かめられる言葉に直します
- 呼び方は会社で揺れるので、最初に言葉の使い方をそろえておくと安心です
コメント