要求定義と要件定義の違いは「判定できる言葉かどうか」——誰が持ち、どう変換されるのか【2026年版】

「要求定義と要件定義、結局どちらを自分が書くのか」——システム開発の発注を控えた方から、こうした相談をよく受けます。開発会社からは「まず御社で要求をまとめてください」と言われた。ところが本を開くと「要件定義は発注者の責任」とも書いてある。一字違いの言葉が入れ替わりに出てきて、自分の作業範囲が確定しない。Wordの1行目から進まないまま数日が過ぎる、というのが実情です。

結論から言うと、2つを分ける基準は1つで足ります。その一文の合否を、第三者が判定できるかどうかです。「請求書の発行が月末に間に合わない」は判定できないので要求、「請求処理を月末3営業日以内に完了する」は判定できるので要件。要求は人の言葉で、困りごとや理由を含みます。要件は判定できる言葉で、理由を落として条件だけを残します。この基準を持てば、会議中の発言も、手元のメモの各行も、その場で仕分けできます。

よく見かける「要求はWHAT、要件はHOW」という覚え方は、実務では迷いのもとです。要件定義で決めるのも「何を作るか」までであって、「どう作るか」は設計の仕事だからです。WHATとHOWで切ると境界が二重にずれ、目の前の一文をどちらに入れるか判断できなくなります。判定できるかどうかで切れば、この迷いは起きません。

本記事では、要求と要件という2つの言葉の区別だけに絞って解説します。判定基準、要求の持ち主は誰か、要求定義という工程が本当にあるのか、要求仕様書と要件定義書という文書の対応、要求を要件に変換するときに起きる3つの操作と失われるもの、要求の出どころ(経営・現場・法令)の整理、そしてよくある質問の順です。要件定義の進め方や要件定義書の章立てには踏み込みません。それぞれ「要件定義の進め方」「要件定義書の書き方」の記事に譲ります。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の開発体制を支援してきました。海外のチームに文書を渡していると、この区別が品質差としてそのまま出ます。「操作をもっと簡単に」という要求のままの一文は、判定条件がないため実装者の解釈で埋められる。「入力項目を12から6に減らす」と書かれていれば解釈は入りません。読み終えるころには、手元のメモの各行に印をつけられるようになるはずです。

要求と要件は何が違うのか——合否を判定できる言葉かどうかで分かれる

要求と要件を分けるものは、言葉の難しさでも、書かれている量でもありません。その一文を読んだ第三者が、達成できたかどうかを同じ結論で判定できるかどうかです。判定できなければ要求、判定できれば要件。この一点だけを覚えておけば、打ち合わせの最中でも仕分けができます。まずはこの基準を、実際の一文で確かめていきます。

判定基準は1つでよい——その一文の合否を第三者が判定できるか

たとえば「在庫の締めを早くしたい」という一文があります。これは判定できません。何分になれば「早くなった」と言えるのかが書かれていないからです。同じ内容を「在庫締め処理を1時間以内に完了する」と書けば、判定できます。ストップウォッチを持った第三者が、同じ結論に達します。

要求は人の言葉です。困りごと、願望、理由を含み、主語は人になります。「営業部が困っている」「経理がミスを恐れている」という形で出てきます。要件は判定できる言葉です。主語はシステムか業務になり、理由は落ちて条件だけが残ります。

この違いは、粒度の違いではありません。「画面に検索ボタンを置いてほしい」は十分に細かい一文ですが、何をもって満たされたかの基準がないため、要求のままです。逆に「同時接続200名でレスポンス3秒以内」は短い一文ですが、判定できるので要件です。細かく書けば要件になる、というわけではないのです。

同じ内容を書き分けた対比表——要求の言葉と要件の言葉

同じ内容を、要求の言葉と要件の言葉で並べます。左を右に直す作業が、後の章で扱う「変換」にあたります。

左の列は、そのまま開発チームに渡しても実装できません。正確には、実装はされます。ただし判定条件がないので、実装者が自分の解釈で埋めた結果が返ってきます。海外のチームに文書を渡していると、この構造がはっきり見えます。「操作をもっと簡単に」という一文は、受け取った側が「入力項目を減らす」と読むか「画面を1枚にまとめる」と読むかで、まったく違うものが出来上がります。書いた側は解釈の余地を残したつもりがなく、受け取った側は指示どおりに作ったつもりでいる。どちらも悪くないのに、リリース後に食い違いが表面化します。

「WHATとHOW」で覚えると現場で迷う理由

要求と要件の説明として、「要求はWHAT(何をしたいか)、要件はHOW(どう実現するか)」という覚え方をよく見かけます。この覚え方は、実務では迷いのもとです。

理由は工程の側にあります。要件定義で決めるのは「何を作るか」までであって、「どう作るか」は次の設計工程の仕事です。つまりWHATとHOWの境界は、要求と要件のあいだにも、要件と設計のあいだにも引かれます。境界が二重になると、目の前の一文をどちらに入れるべきかが決まりません。「検索機能を付ける」はWHATなのかHOWなのか、という水掛け論になります。

判定できるかどうかで切れば、この迷いは起きません。「検索機能を付ける」は判定条件がないので要求の側、「商品名の部分一致検索を2秒以内に返す」は判定できるので要件の側です。工程の名前を持ち出さずに、一文だけを見て決められます。

基準が定まったところで、次は持ち主の話に移ります。要求と要件では、決める権限を持つ人が違うからです。

要求は誰のものか——発注側が持ち、開発会社は預かれない

判定できるかどうかという基準は、そのまま「誰が決められるか」という問いにつながります。判定できない一文は、業務を回している人の頭の中にしか正解がありません。だから要求は発注側の持ち物になります。一方の要件は、発注側と開発側が合意して初めて確定するものなので、どちらか片方の持ち物ではありません。ここを取り違えると、責任の所在が最後まで宙に浮きます。

要求の持ち主は業務を回している人に限られる

要求を決められるのは、その業務を実際に回している人だけです。業務のどこを変えてよいのか、既存の決裁権限規程をどう扱うのか、現場の運用をどこまで揃えられるのか。これらは開発会社が調査で埋められる範囲を超えています。外部の人間がいくらヒアリングを重ねても、「この承認フローは変えてよい」という判断だけは下せません。

IPAの「ユーザのための要件定義ガイド 第2版」(2019年9月12日公開)も、システムの要件を定義する責任は、構築されたシステムを利用してビジネスに貢献する役目を負うユーザにある、という立場を出発点に置いています。同ガイドは、ITベンダやシステム部門が中心になって進めるスタイルから、業務部門のユーザが主体的に関与するスタイルへの変革の必要性を背景として挙げています。要求を出すことは、遠慮すべきわがままではなく、発注側の仕事だということです。

私は人材業界の出身で、企業と人財の双方から「本当はどうしたいのか」を聞き出す面談を長く担当してきました。そこで実感したのは、要求は最初から言葉の形で存在しているわけではない、ということです。「いまの採用がうまくいっていない」という一言の背後に、選考のスピード、上長の関与、母集団の質という別々の論点が畳み込まれている。システム開発の要求も同じで、出てくる最初の一言は、ほぼ必ず複数の論点の圧縮形です。

要件は「合意して確定させたもの」——だから片方の持ち物ではない

要件は、開発会社が一方的に書き下ろすものではありません。技術的な実現可能性や既存システムとの整合性を判断するのは開発側ですが、その内容が業務として成立しているかを確認し、承認するのは発注側です。この二重の関与を経て確定したものが要件です。

役割を整理すると、次のようになります。

「要件定義はベンダーの仕事」と言われることがありますが、正確には「案を作る作業がベンダー主導」というだけです。承認した時点で、その内容が業務に合っているかどうかの責任は発注側に戻ってきます。ここを曖昧にしたまま進めると、稼働後に「使えないシステムが納品された」という言い方になり、契約上は何も問えない、という状況が生まれます。

文書化は委託できるが、優先順位の決定は委託できない

では、要求を外部にまとめてもらうのは誤りなのでしょうか。そうではありません。分けて考えます。委託できるのは文書化の作業です。委託できないのは、要望がぶつかったときの優先順位の決定と、業務を変える範囲の判断です。

この2つを分けずに「要求もまとめておいてください」と渡すと、出てくるのは決定ではなく併記です。営業部の要望と経理部の要望が両方載った一覧ができあがり、どちらを取るかは誰も決めていない。その状態で見積を取れば、当然どちらも含んだ金額が返ってきます。予算を超えて初めて、社内で優先順位の議論が始まります。

外部の支援が有効に働く条件は1つです。業務側の意思決定者が整理の場に同席し、その場で合否を出せること。同席が確保できるなら、社内の力関係から離れた立場で論点を出せる、抜けを項目表で埋められる、といった効果が出ます。逆に、社内に議事進行ができる人と決裁できる人が揃っているなら、外部委託は必須ではありません。丸投げは失敗のもとです。

持ち主が分かると、次の疑問が出てきます。「要求定義」という工程は、そもそも開発の手順のどこかに正式に存在するのか、という問いです。

「要求定義」という工程は実在するのか——規格と国内ガイドで扱いが違う

「要求定義は要件定義の古い言い方ではないのか」という質問をよく受けます。答えは、古い言い方ではなく、別の作業を指す言葉です。ただし、それが独立した工程として置かれるのか、要件定義の内側の活動として置かれるのかは、参照する資料によって変わります。呼び方が現場で揺れる原因はここにあり、この節でその構造を明らかにします。

JIS X 0166:2021は要求を2つの文書として分けている(StRS / SyRS)

1つ目の系譜が、国際規格に由来する整理です。JIS X 0166:2021「システム及びソフトウェア技術—ライフサイクルプロセス—要求エンジニアリング」は、2014年制定の規格を2021年9月に改正したもので、国際規格 ISO/IEC/IEEE 29148:2018 と一致する内容です。

この規格は、要求を扱う文書として、利害関係者要求仕様(StRS)とシステム要求仕様(SyRS)を別々に定義しています。StRSは利害関係者が何を必要としているかを利用者の視点で書く文書、SyRSはシステムが備える特性・機能・性能を供給者の視点で書く文書です。日本の商慣行でいう要求定義がStRS、要件定義がSyRSに対応します。

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

IPA「ユーザのための要件定義ガイド 第2版」は要求定義を要件定義の内側に置く

2つ目の系譜が、国内の実務ガイドです。IPAの「ユーザのための要件定義ガイド 第2版 要件定義を成功に導く128の勘どころ」(2019年9月12日公開、同年12月20日にパスワードなしPDFの提供を開始)は、要件定義という枠の内側に、要求を扱う活動を置いています。

同ガイドの章構成は次のとおりです。第4章がビジネス要求定義(BR)、第5章がシステム化要求定義(SR)、第6章が要件定義マネジメント(RM)、第7章が要件定義の主要ドキュメント作成(DD)。つまり「要件定義」という大きな箱の中に、ビジネスの要求を定義する活動とシステム化の要求を定義する活動が含まれる構造です。

規格の整理では要求定義と要件定義が別の文書として並び、国内ガイドの整理では要求定義が要件定義の内側に入る。どちらも誤りではありません。並べると次のようになります。

見積書で最も混乱が起きるのが3行目です。提案書に「要件定義フェーズ 2か月」とだけ書かれている場合、その2か月に業務ヒアリングと要求の整理が含まれるのか、発注者が提示した要求を仕様化するだけなのかで、作業量は大きく変わります。

呼び方が揺れても困らない聞き方——工程名ではなく作業で確認する

結論として、工程名を統一しようとしても意味がありません。相手の会社がどちらの整理で話しているかは分からないからです。確認すべきなのは名前ではなく作業です。

打ち合わせで使える聞き方は2つです。1つ目は「業務要求の一覧と現状業務フローの作成は、御社の作業に含まれますか」。2つ目は「含まれない場合、当社は何をいつまでに提出する必要がありますか」。この2問に答えてもらえば、工程名が何であれ、自分の作業範囲が確定します。提案書の成果物欄に「業務要求一覧」「現状業務フロー」に相当する文書が挙がっていれば要求整理を含む見積、要件定義書だけなら含まない見積です。

私はベトナムのIT企業でERPの案件を上流から下流まで担当していましたが、上流の呼び方は案件ごとに違いました。「要求定義」と呼ぶ案件も「業務要件定義」と呼ぶ案件もあり、内容が同じこともあれば違うこともある。名前で判断すると必ず外します。成果物の名前で確認するのが最も早く正確です。

要求仕様書と要件定義書——2つの文書はどう対応するのか

言葉の区別がついても、文書の名前がまた別に増えていきます。要求定義書、要求仕様書、RFP(提案依頼書)、要件定義書。どれがどちら側の文書なのかを整理しておくと、受け取った資料や提出を求められた資料の位置づけが一目で分かります。文書の中身の書き方そのものには踏み込まず、対応関係だけを押さえます。

文書名の対応表——要求定義書・要求仕様書・RFPと、要件定義書

要求側の文書は複数の名前で呼ばれますが、書かれている内容は近いものです。

実務では「要求定義書をもとにRFPを作る」という流れが一般的です。同じ材料から、社内向けの整理版と、複数社に配る提案依頼版の2つを作る、と考えると分かりやすくなります。要件定義書に何をどう書くかは「要件定義書の書き方」の記事で章立てと記載例を扱っていますので、そちらを参照してください。

RFPは要求側の文書——手段まで書くと安い代替案が出てこなくなる

要求側の文書を書くときに最も多い失敗が、手段まで書き込んでしまうことです。

たとえば「請求書発行画面に一括出力ボタンを設ける」と書いたとします。これは手段です。本来の要求は「請求書の発行を月末3営業日以内に完了させたい」という業務の状態でした。手段まで書いてしまうと、その手段より安く済む代替案を開発会社が提案できなくなります。既存の帳票ツールの設定変更で済む案件が、画面の新規開発として見積もられる、といったことが起きます。

真面目な担当者ほど「曖昧だと思われたくない」と考えて、画面項目や処理の流れまで自分で書こうとします。しかし要求側の文書に必要な粒度は、業務の状態と数字です。RFPで外せないのは3つ、対象業務の範囲、達成したい指標、制約条件です。制約条件には稼働希望時期、予算の上限、連携が必要な既存システムの名称とバージョンを入れます。この3つが書かれていないRFPに対する提案は、各社が別々の前提で見積を出すため、比較そのものが成立しません。発注前に出すRFPの構成は「システム開発のRFPの書き方」の記事で扱っています。

1冊にまとめてよいか——章を分けるなら成立する

「要求定義書と要件定義書は必ず別々の文書にすべきか」という質問もよく受けます。小規模で関係部門が1つの案件なら、1冊にまとめても回ります。ただし章は必ず分けてください。

理由は、前の章で触れた追跡可能性です。予算超過でスコープを削る局面になったとき、要件の各項目から元の要求へ遡れる構造が必要になります。章が混ざっていると、業務上の要望と技術的な仕様が同じ粒度で並び、削ってよい仕様の判定ができなくなります。「この機能を削ると何が困るのか」に答えられないまま、金額だけを見て削る。そうやって削った1行が、稼働後に業務を止める原因になります。

実務で使える形は、1冊の中を前半(要求)と後半(要件)に分け、後半の各項目に前半の要求番号を振っておく方法です。番号を振るだけで、削る交渉のときに「この要件は要求R-03に紐づいており、R-03は法令対応です」と即答できます。番号がないと、この確認に半日かかります。

文書の対応が整理できたところで、実際に要求が要件に変わる場面で何が起きているのかを見ていきます。ここが、この記事でいちばんお伝えしたい部分です。

要求を要件に変換すると何が起きるのか——取捨選択・言い換え・数値化の3操作

要求を要件に直す作業は、翻訳に似ていますが、翻訳よりも失われるものが多い作業です。起きているのは3つの操作、取捨選択・言い換え・数値化です。3つとも必要な操作ですが、それぞれが何かを削ぎ落とします。何が落ちるのかを先に知っておくと、落ちたものを1行で拾い直せます。

3つの操作を1つの要求で追いかける——「請求書を早く出したい」の場合

経理部から「請求書を早く出したい」という声が上がったとします。この1文が要件になるまでに、次の3つが順に起きます。

3つの操作は、担当する人が違います。取捨選択を決めるのは発注側の意思決定者です。言い換えは開発側が案を出し、発注側が「その言い換えで業務が成立するか」を確認します。数値化は双方で詰めます。数字の出どころは業務側にしかありません。「何分で困り始めるか」に答えられるのは業務を回している人だけで、そこからシステムの目標値を設計するのが開発側の仕事です。順序を逆にして、開発側が先に「3秒以内でどうですか」と提案すると、業務の実態と無関係な数字が独り歩きします。

変換で失われやすい3つ——理由・例外・言わなかった前提

3つの操作を通すと、要件は判定できる形になります。同時に、次の3つが落ちます。

1つ目は理由です。要件は判定条件だけを残す形式なので、「なぜこの数字なのか」を書く欄が構造的にありません。「3営業日以内」という数字だけが残り、「取引先との支払サイトが月末締め翌月末払いで、5営業日を超えると入金が1か月ずれる」という背景が消えます。後から工期短縮のために「5営業日でも構わないか」と聞かれたとき、理由が残っていないと誰も答えられません。

2つ目は例外です。要求を出した人の頭の中には「ただし月末が土日のときは」「大口の取引先だけは別処理で」という例外が入っています。これは要求の段階では言葉になりません。当たり前すぎて意識に上らないからです。例外が落ちたまま実装されると、正常系は動くのに月に1回だけ業務が止まる、という形で表面化します。

3つ目は、言わなかった前提です。「請求書」と言えば自社の書式のことだ、という前提が共有されていない相手に渡すと、汎用の書式で作られます。海外のチームに文書を渡すと、この前提の欠落が最も強く出ます。判定条件のない一文が解釈で埋められるのと同じ構造で、書かれていない前提は、相手の常識で埋められます。日本国内のベンダーであれば商習慣が近いぶん埋め方が当たることも多いのですが、当たっているのは偶然です。

落とさないための1行——要求の行に「出どころ」と「判定条件」を書き足す

対策は、手の込んだ書式を作ることではありません。要求を並べたメモの各行に、2つの欄を足すだけです。

1つ目の欄が「出どころ」です。誰の、どの業務から出た要求かを書きます。「経理部・月次締め」と書いてあれば、後から理由を聞きに行く先が分かります。2つ目の欄が「判定条件」です。何をもって満たされたと判断するかを書きます。この時点では数字が出なくても構いません。「何分なら困らないか、経理部に確認」と書いておくだけでも、確認漏れが防げます。

実際の運用では、次の形になります。

この表は、要件定義書の代わりにはなりません。要件定義書の章立てや記載例は「要件定義書の書き方」の記事に譲ります。ここで作っているのは、開発会社に渡す前に発注側が自分で作る、要求の棚卸し表です。列は4つで足ります。列を増やすと埋まらなくなります。

最後に、要求そのものがどこから湧いてくるのかを整理します。出どころが分かると、削る判断が変わるからです。

要求はどこから出てくるのか——経営・現場・法令の3系統と、海外チームに渡すときの扱い

要求を並べただけの一覧は、見積が予算を超えた瞬間に使えなくなります。どれを削ってよいのかが書かれていないからです。削る判断を早くする方法は単純で、要求を出どころで分けておくことです。出どころは大きく3系統、経営・現場・法令に分かれます。

3系統の分類表——出どころが違うと、削ってよいかの判断も変わる

この3つを混ぜたまま並べると、金額を見て上から削ることになります。実際には、削ってよいのは現場系の要求だけです。経営系を削ると、そもそも何のための投資だったのかが説明できなくなります。法令系を削ると、稼働後に対応工事が発生して結局高くつきます。

分類の副次的な効果として、抜けが見つかります。3系統に振り分けると、法令系の行が1つもない一覧がよく出てきます。現場からは出てこない要求なので、意識して取りに行かないと集まりません。要求を集める段階で、法務や内部監査に一度声をかけておくのが有効です。

海外チームに渡すと、要求のままの一文は解釈で埋められる

ここまでの整理は国内の開発でも同じですが、海外のチームに渡す場合は影響がはっきり出ます。当社は2018年からホーチミンで約100社の開発体制を支援してきましたが、品質の差として表面化する原因の多くは、技術力ではなく、渡した文書に判定条件が入っていないことです。

「操作をもっと簡単に」という要求のままの一文を渡すと、受け取った側は自分の解釈で埋めます。悪意はなく、むしろ真面目に埋めます。だからこそ、書いた側の想定と食い違ったまま完成し、リリース後に発覚します。国内のベンダーであれば商習慣が近いぶん解釈が当たることもありますが、それは運に任せているだけです。当たらなかった案件だけが「オフショアは品質が低い」という話になります。

当社がどこまで巻き取るか、向く案件と向かない案件

当社の体制では、要求を判定できる形に直す作業まで日本人PM/ブリッジSEが担います。体制はパターンA(日本人PM/ブリッジSE+エンジニア・推奨)とパターンB(エンジニアのみ)の2つで、この作業を含むのはパターンAです。品質の担保は3点、日本人PMによる設計レビュー、Gitのプルリクエストによるコードレビューの標準化、リリース前のダブルチェックです。

事例としては、介護記録SaaSのCareViewerで日本語対応のブリッジSE1名とフルスタックエンジニア2名の体制を組み、週次で優先順位を判断しながら進めています。要求が毎週追加される性格の案件なので、判定条件を付ける作業を毎週のサイクルに組み込む形です。単価は実務3年目安1,500USD(約22.5万円)、5年2,000USD、ブリッジSE3,000USDで公開しています(1USD=150円換算が目安)。最小構成は日本人PMフロント+2〜3人月で月額約80万円からです。

正直に申し上げると、向かない案件もあります。要求の優先順位を決める人が社内にいない案件です。文書化は当社で巻き取れますが、部門間で衝突した要望のどちらを取るかは、当社には決められません。ここが決まらないまま体制だけ組むと、稼働している人数ぶんの費用が積み上がるだけになります。逆に向くのは、決める人が社内にいて、要求が継続的に出てくる案件です。1名から、最短2週間で開始できます。合わない案件には、その旨も率直にお伝えします。

要求定義と要件定義の違いに関するよくある質問

用語の区別そのものについて、発注を検討されている方から実際にいただく質問を5つまとめます。順序、外部委託の可否、似た言葉との関係、アジャイルでの扱い、書く粒度の順です。要件定義の期間や費用、成果物といった工程側の質問は「要件定義とは」「要件定義の進め方」の記事で扱っていますので、そちらを参照してください。

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

要求定義が先です。業務として何を実現したいかが決まっていなければ、それを満たす条件は決められません。ただし完全に一方通行ではなく、要求の整理が進んだ段階で開発側が技術的な実現性を確認し、実現が難しい要求を差し戻す往復が発生します。往復があることを前提にしたうえで、確定の順序は要求から要件へ、という向きを守ってください。

Q2. 要求定義を外部の会社に頼んでもよいのですか

文書化の作業は委託できます。委託できないのは、要望がぶつかったときの優先順位付けと、業務を変える範囲の判断です。委託が成立する条件は1つ、業務の意思決定者が整理の場に同席し、その場で合否を出せることです。同席がないまま任せると、出てくるのは決定ではなく要望の併記になります。

Q3. 「要件整理」と「要件定義」は違うものですか

呼び方の差で、指す範囲が案件ごとに違います。多くの場合、要件整理は集めて並べる段階、要件定義は合意して確定させる段階を指します。ただし社内資料で「要件整理」と書かれているものが、実際には要求の棚卸しであることも珍しくありません。名前で判断せず、その作業の成果物が「判定できる一文の集まり」になっているかで見分けてください。

Q4. アジャイル開発では、この区別はどう扱われるのですか

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

Q5. 要求はどこまで細かく書けばよいですか

細かさではなく、業務の状態と数字で書くのが基準です。手段(画面にボタンを置く、この機能を使う)まで書くと、より安く済む代替案が出てこなくなります。書くべき粒度は、対象業務の範囲、達成したい指標、制約条件の3つ。制約条件には稼働希望時期、予算の上限、連携する既存システムの名称とバージョン。細かく書くことではなく、判定できる数字を1つ入れること。

まとめ: 要求は人の言葉、要件は判定できる言葉。分ける目的は、決める人を間違えないこと

要求と要件を分ける基準は1つで足ります。その一文の合否を第三者が判定できるかどうかです。「請求書の発行が月末に間に合わない」は判定できないので要求、「請求処理を月末3営業日以内に完了する」は判定できるので要件。要求は人の言葉で、理由と主観を含みます。要件は判定できる言葉で、理由が落ちて条件だけが残ります。「要求はWHAT、要件はHOW」という覚え方は、要件定義で決めるのも「何を作るか」までであるという工程の事実と噛み合わないため、目の前の一文を仕分けるときには使えません。

持ち主も違います。要求を決められるのは業務を回している発注側だけで、要件は双方が合意して確定させたものです。文書化は外部に委託できますが、要望がぶつかったときの優先順位付けと、業務を変える範囲の判断は委託できません。「要求定義」という工程の扱いは資料によって分かれ、JIS X 0166:2021(ISO/IEC/IEEE 29148:2018と一致)は利害関係者要求仕様とシステム要求仕様を別文書として規定し、IPA「ユーザのための要件定義ガイド 第2版」(2019年)は要求定義を要件定義の内側の活動として置いています。呼び方が揺れるのはこの2つの整理が併存しているためで、工程名ではなく「業務要求一覧と現状業務フローを誰が作るか」で確認するのが最も早く正確です。

今日できることは1つです。手元のメモや議事録の各行に「要求」「要件」の印をつけ、要求の行に「出どころ」と「判定条件」の2欄を足してください。出どころは経営・現場・法令の3系統に分けます。予算を削る局面で削ってよいのは現場系だけで、法令系を削ると稼働後に対応工事が発生します。当社は日本人PM/ブリッジSEをフロントに置き、要求を判定できる形に直す作業まで巻き取る体制を、1名から最短2週間で組めるようにしています。ただし、優先順位を決める人は発注側に残ります。ここは代われません。要件定義という工程の全体像は要件定義とは、手順は要件定義の進め方もあわせてご覧ください。現在の体制と要件をお聞かせいただければ、どこまで当社が巻き取れるかの線引きと概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。