要求と要件を分ける意味

現場でよく起きている、ある混乱

要件定義の現場で、こんな場面を見たことはないでしょうか。

顧客との打ち合わせを終えて、議事録を書きます。「月次レポートを自動化したい」「承認のフローを整理したい」「外出先からもデータを確認できるようにしたい」——顧客が話してくれた言葉を、そのまま書き起こします。それを要件定義書に転記します。

一通り書けたところで、ふと気づきます。「これ、要件定義書と言えるのだろうか」と。

書いてあることは顧客の言葉そのままです。間違いではありません。しかし、これを設計に渡しても、エンジニアは「で、具体的に何を作ればいいのか」という状態になります。「自動化したい」という言葉からは、システムの仕様は導けないからです。

この混乱の正体は、「要求」と「要件」が区別されていないことにあります。

「要求」と「要件」は、別物です

まず言葉を整理します。

要求とは、顧客がシステムに対して「こうしたい」「こうなってほしい」と望む、業務上の願望や目的のことです。「月次レポートを自動化したい」「承認フローを効率化したい」という言葉がこれにあたります。顧客の言葉で語られ、多くの場合、抽象度が高いものです。

要件とは、その要求を実現するためにシステムが満たすべき具体的な条件のことです。「毎月末日の23時に、売上データを集計し、PDF形式で経理部長宛に自動送信する」という言葉がこれにあたります。誰が・いつ・何を・どの形式で・どこに、という問いに答えられる粒度で書かれている必要があります。

この2つは、まったく別の性質を持っています。

要求は「なぜこのシステムが必要か」を示すものです。要件は「何を作るか」を定義するものです。要求がなければ要件の方向性が定まらず、要件がなければシステムは作れません。どちらも必要ですが、同じものではありません。

混在すると、何が起きるか

要求と要件を区別せずに要件定義書に書き込むと、具体的にどんな問題が起きるでしょうか。

第一に、抜け漏れの検出が難しくなります。

「月次レポートを自動化したい」という要求と、「毎月末日の23時に売上データを集計してPDF出力する」という要件が、同じ粒度で並んでいるとします。読む側は一見するとどちらも「書いてある」と認識します。しかし前者は要求であり、要件としての具体性がまったくありません。「誰が出力するのか」「どんな形式か」「どのタイミングか」という情報がゼロです。

抜け漏れがあるのに、書いてあるから気づけない。これが混在の最も危険な副作用です。

第二に、品質チェックが機能しなくなります。

「この要件は検証可能か」という問いを立てたとします。「毎月末日の23時に自動送信する」という要件であれば、検証可能かどうかは判断できます。しかし「月次レポートを自動化したい」という要求に対して、同じ問いを立てても答えが出ません。問い自体が成立しないからです。

品質を測るには、測れる粒度のものが必要です。要求と要件が混在したままでは、どれだけチェック項目を増やしても、「何を検証しているのか」が定まりません。

第三に、認識のズレが後から発覚します。

「月次レポートを自動化したい」という要求に対して、SEが自分なりの解釈で要件を補完して開発を進めるケースがあります。顧客はPDFで出力されると思っていた。SEはExcelで出力する想定だった。どちらも要件定義書の「月次レポート自動化」という記載を根拠にしています。

この種のズレは、完成したシステムを見て初めて発覚します。手戻りの中でも、もっともコストが高いものです。

「整理のため」ではなく「仕組みを機能させるため」

「要求と要件を分けましょう」という話をすると、「整理のためですね」と受け取られることがあります。確かに整理にはなります。しかしそれだけでは、この分離が持つ本当の意味を捉えきれていません。

要求と要件を分けることの本質は、その後のすべてのプロセスを正しく機能させるための前提を整えることにあります。

品質チェックは、要件の粒度でなければ正確に機能しません。進捗の計測も、要求レベルと要件レベルでそれぞれ行わなければ、「どこまで終わったか」が正確に測れません。ステークホルダーとの合意形成も、要求と要件が混在していては「何に合意したのか」が曖昧になります。

分けることは、ゴールではありません。分けることで、初めてその後の工程が意味を持ち始めます。

顧客は「要求」で話す。SEは「要件」で考える。

この2つの間には、翻訳が必要です。

私がプログラマからSEになりたての頃、こんなことを思っていました。「お客様はなぜ要件を最初から、細かく伝えてくれないのだろう。自分たちが使うシステムなのだから、もっと考えてほしい」と。

恥ずかしながら、これは完全な的外れでした。しかし、同じことを感じているSEは今も少なくないはずです。

顧客側には顧客側の言い分があります。「要件定義なんて専門的なことは分からない。それはSEの仕事ではないのか」「専門的な話をされても難しくて分からない」と思っています。そもそも「要件定義」という言葉自体、顧客には馴染みがありません。「システム化の打ち合わせ」「仕様の確認」といった言葉で認識している顧客に対して、「要件定義を進めたい」と言った時点で、すでに言葉が届いていないことがあります。その上でヒアリングの場に「非機能要件」「ユースケース」「制約条件」といった言葉が出てくれば、顧客が戸惑うのは当然です。分からないから答えられない。答えられないからSEは「考えてくれない」と感じる。この悪循環が、現場のすれ違いの正体です。

つまり、こういう構図です。

• SEは「顧客が要件を言ってくれない」と感じている
• 顧客は「要件定義は専門家に任せるものだ」と思っている

どちらも相手に期待しています。しかし実は、この食い違いの根っこは「要求」と「要件」の区別が共有されていないことにあります。顧客は「要求」を伝えているつもりで話しています。SEは「要件」が欲しくて待っています。同じ打ち合わせの場にいながら、まったく異なるものをやり取りしているのです。

さらに言うなら、実はその手前にもう一段階あります。顧客が最初に持っているのは「要望」です。「もっと業務を楽にしたい」「売上管理をなんとかしたい」という、システム化以前の漠然とした期待です。この要望を「月次レポートを自動化したい」という具体的な要求に落とし込む作業は、顧客自身がある程度できます。自分たちの業務の話ですから、ブレークダウンの方向性は理解しやすいものです。

問題はその先です。要求を要件に翻訳する段階になると、一気に難しくなります。「誰が・いつ・何を・どの形式で」という問いに答えるには、システムの知識と業務の知識の両方が必要です。顧客にはシステムの知識がない。SEにはそのドメインの業務知識がない。ここで初めて、本当の意味での「翻訳」が必要になります。

顧客はシステムの専門家ではありません。「こうしたい」という言葉で話すのは自然なことです。そして顧客自身も、自分が話していることが「要求」なのか「要件」なのか、そもそも意識していません。それを意識するのはSEの仕事です。

ヒアリングで聞いたことをそのまま書き起こしただけでは、要求の記録にはなりますが、要件定義にはなりません。「顧客が言ったこと」を「システムが満たすべき条件」に翻訳する作業が、必ず必要です。

翻訳はどうやって行うのか

では、この翻訳は具体的にどうやって行うのでしょうか。

基本的なアプローチは、要求に対して問いを重ねていくことです。

「月次レポートを自動化したい」という要求に対して——

• 誰がそのレポートを使いますか？
• どんな情報が含まれている必要がありますか？
• いつ、どのタイミングで必要ですか？
• どんな形式で出力しますか？
• 承認のフローは必要ですか？
• 過去データの修正が発生したとき、どうしますか？

これらの問いに対する答えが、要件の素材になります。要求を出発点として、問いを重ねることで要件を掘り起こしていく。これが翻訳の実態です。

問いを立てるためには、問いを知らなければならない

ここで一つの課題が浮かび上がります。

「適切な問いを立てられるか」は、SEのスキルと経験に依存します。

ベテランのSEであれば、過去のプロジェクト経験から「このタイプの要求には、こういう問いが必要だ」という感覚が身についています。「月次レポートの自動化」と聞いた瞬間に、承認フロー・エラー処理・データ修正のシナリオといった論点が頭に浮かびます。

しかし初級のSEには、その感覚がありません。「どんな情報が必要か」を問う前に、「何を問えばいいか」が分からない状態です。

さらに前回もお伝えしたように、ベテランであってもドメインが変われば話は変わります。金融系のシステムに慣れたSEが製造業のプロジェクトに入ったとき、「このドメインでは何を確認すべきか」という問いのリストは、経験からは出てきにくいものです。

問いを立てる力が属人的である限り、要求を要件に翻訳する品質も属人的にならざるを得ません。

「要求」と「要件」の間にあるもの

要求を要件に翻訳する作業は、単純な言い換えではありません。その間には、いくつかの判断が必要です。

優先度の判断——すべての要求が同じ重要度ではありません。「あればいい」という要求と「なければ困る」という要求を区別する必要があります。

実現可能性の判断——要求の中には、技術的・予算的・スケジュール的に実現が難しいものが含まれることがあります。要件化する前に、制約条件と照らし合わせる必要があります。見落としがちなのが「使いこなせるか」という視点です。たとえば、データは発生元で入力するのが理想です。しかし現場のITスキルが低い場合——高齢のスタッフが多い職場などでは特に——その前提が成り立たないことがあります。システムとして正しく要件化されていても、実際に使われなければ意味がありません。「技術的に作れるか」だけでなく、「現場で運用できるか」も、要件化の前に確認すべき制約条件のひとつです。

矛盾の検出——複数の要求が互いに矛盾していることがあります。「リアルタイムでデータを更新したい」という要求と「コストをできるだけ抑えたい」という要求は、場合によって相反します。

ステークホルダーの特定——誰の要求かによって、優先度や実現方法が変わります。経営層の要求とエンドユーザーの要求が異なるとき、どちらをどう扱うかを決める必要があります。

これらの判断を経て、初めて要求は要件になります。この過程を省略したり、無意識に飛ばしたりすることが、後の問題の種になります。

AIが下流を担う時代における、この問題の重さ

前回もお伝えしましたが、AIが設計やコードの生成を担う時代において、要件定義の品質はシステム全体の品質に直結します。

その文脈で考えると、要求と要件の混在は以前よりもはるかに危険です。

人間のエンジニアであれば、「月次レポートを自動化したい」という曖昧な記述を見て、「これはこういう意味だろう」と解釈し、暗黙的に補完することがありました。経験と文脈から、ある程度の補正が働いていたのです。

AIはこの補正を行いません。書いてあることを書いてあるとおりに処理します。要求と要件が混在した定義書を渡せば、その曖昧さをそのまま抱えたシステムが生成されます。

要求と要件を分けることは、AI時代においては「あるとよい習慣」ではなく、「なければ機能しない前提条件」になりつつあります。

まとめ

要求と要件は、似ているようで本質的に異なるものです。

その手前には「要望」があります。業務レベルの漠然とした期待である要望を、システムへの具体的な期待である要求に落とし込む作業は、顧客自身がある程度できます。しかし要求を要件に翻訳する段階は、システムの知識と業務の知識の両方が必要になり、一気に難しくなります。

要求と要件を区別せずに進めると、抜け漏れの検出が困難になり、品質チェックが機能せず、認識のズレが後から発覚します。分けることの目的は整理ではありません。その後の検証・改善・進捗計測というプロセス全体を、正しい粒度で機能させるための前提を作ることです。

そして、要求を要件に翻訳する問いを立てる力は、現状では属人的なスキルに依存しています。この属人性をどう解消するかが、要件定義の品質を安定させるための核心的な課題です。