要求定義と要件定義の違い

要求定義と要件定義は似た字面ですが、文を書く主語がはっきり違います。整理する軸は「誰の立場で、何を語っているか」です。この軸を先に押さえると、会議でどちらの話をしているのか迷いにくくなります。

• 要求定義は利用者側の主語
  業務部門や経営層、顧客など、システムを使う側が「こうなってほしい」「この手間をなくしたい」という望みを言葉にします。手段ではなく、達成したい状態や解決したい困りごとが中心です。
• 要件定義は開発側の主語
  その望みを受け取ったPMや設計担当が「ではこの画面を用意し、この項目を持たせ、この処理を行う」と、つくるものの形に置き換えます。実現可能性や工数との折り合いをここで検討します。

同じ「請求業務を楽にしたい」という話でも、要求の段階では「月末の集計に時間がかかりすぎる」という困りごとのままです。要件の段階になって初めて、集計を自動化する機能や、取り込むデータの形式、出力する帳票といった具体に落ちます。主語がどちら側かを意識するだけで、議論の空回りが減っていきます。

次の軸は「誰が、何を、どの順で、どんな成果物にするか」です。実際のプロジェクトでは、おおむね要求を集める段階から要件へ固める段階へと進みます。

• 要求を引き出して整理する
  PMや業務分析の担当が、利用部門へのヒアリングや現行業務の観察を通じて、困りごとと期待を集めます。成果物は要求一覧や業務フロー図など、利用者の言葉に近い形でまとめた資料です。
• 要件へ翻訳して合意する
  集めた要求を機能要件と非機能要件に分け、実現方法と優先度を整理します。成果物は要件定義書で、画面や機能、データ項目、性能やセキュリティの条件などを書き下します。

この流れで大切なのは、要求を要件へ移すときに「なぜその要求が出たのか」を落とさないことです。背景を残しておくと、後の設計や受け入れテストで判断に迷ったとき、立ち返る拠り所になります。要求一覧の各項目と要件定義書の記述を対応づけておくと、どの望みがどの機能で満たされるのかを追いかけやすくなり、利用部門との合意も取りやすくなります。順序としては、要求が固まりきる前に要件へ急いで進めると、後戻りが増えがちです。

三つめの軸は「どこで食い違いが起きるか」です。要求と要件のあいだには翻訳の工程がある分、ずれが生まれやすい箇所がいくつかあります。

• 要求を飛ばして要件から始める
  利用部門の困りごとを十分に聞かないまま機能一覧を書き始めると、つくったものが現場の使い方と噛み合わないことがあります。手戻りの多くはここに根があります。
• 望みを手段のまま受け取る
  利用者が「この画面にボタンを足してほしい」と言ったとき、それを要求としてそのまま要件化すると、本来の目的を取りこぼすことがあります。なぜそのボタンが要るのかを一段掘ると、別の解が見える場合もあります。
• 要件の確定を曖昧にしたまま進める
  どこまでが今回の範囲かを決めきらずに設計へ移ると、後から要望が足され続け、スケジュールや工数が膨らみやすくなります。

いずれも、要求と要件のどちらの話をしているかが場で共有されていないときに起きがちです。PMとしては、会議の冒頭でいまはどちらの工程かを確認し、決まったことと保留のことを分けて記録しておくと、認識のずれを早めに見つけやすくなります。

最後の軸は「周辺の用語とどう並ぶか」です。要求定義と要件定義は、上流工程の中で前後する位置にあります。混同しやすい言葉を並べて整理します。

• 上流工程との関係
  要求定義と要件定義は、どちらも設計やテストより前に位置する上流工程に含まれます。要求が入口側、要件がその次で、基本設計へと受け渡していく流れです。
• 要件定義書との関係
  要件定義の成果物が要件定義書です。要求定義の内容は、この文書の前提や背景として参照されることが多く、文書そのものは要件の記述が中心になります。
• システム化企画との関係
  要求定義のさらに手前で、投資判断や目的の確認を行うのがシステム化企画にあたります。要求はその方針を具体的な望みへ落とした段階と考えると位置づけが見えやすくなります。

これらの言葉は、どれも「抽象から具体へ」という同じ方向に並んでいます。要求が利用者の望み、要件がつくるものの定義、設計がつくり方、という順を頭に置くと、どの資料を今つくっているのかを見失いにくくなります。

要求と要件を分けて扱える力は、PMとして上流に関わるほど効いてきます。利用部門の望みを鵜呑みにせず、なぜその望みが出たのかを掘り、実現方法へ翻訳する。この橋渡しは、設計や開発に任せきりにできない役割です。職務経歴書でも、どんな要求をどう要件へ落とし、合意をどう取りつけたかを具体的に書けると、担当工程の広さが伝わりやすくなります。日々の仕事では、会議でいまどちらの工程を話しているかを言葉にし、決まったことと保留を分けて記録する習慣が、そのまま要求と要件を扱う訓練になります。上流工程や要件定義書の作成に数多く関わっておくと、担える範囲を少しずつ広げていけます。

要求定義と要件定義はどちらが先ですか。

要求定義が先です。利用する側の望みや困りごとを集める要求定義があり、それを受けて開発側がつくるものを具体化する要件定義へ進みます。順序を飛ばして要件から始めると、現場の使い方と噛み合わず手戻りが増えやすくなります。

要求と要件はどう見分ければよいですか。

主語で見分けると分かりやすいです。利用者側が語る「したいこと・解決したい困りごと」が要求、開発側が定める「つくる機能やデータの形」が要件です。同じ話題でも、目的の表現なら要求、実現方法の表現なら要件と考えると整理しやすくなります。

要求定義書と要件定義書は両方つくりますか。

プロジェクトによります。要求を要求一覧や業務フローの形で残し、要件を要件定義書にまとめる進め方が一般的です。規模が小さい場合は要件定義書に背景として要求を含めることもあります。背景を残しておくと後工程で判断に迷ったとき役立ちます。