要件定義と要求定義の違い、ご存知ですか？

要件定義と要求定義の意味

「要件定義」という言葉を聞いたことがある方は多いと思いますが「要求定義」という言葉はご存知でしょうか？

要件定義とは、システム「を」動かすための仕様を定義したものです。
要求定義とは、システム「に」求める仕様を定義したものです。

これら「を」と「に」が重要な意味を持っています。その違いを考えてみましょう。

誰が定義するべきか？

要件定義は、システム開発が失敗するときの主な原因になります。

それは、システムに明るい技術者ではなく、事業やオペレーションの専門家が「要件定義」をしてしまうからです。システム「を」動かすための仕様は、システムに明るい技術者が、自身の経験や知見に基づいて定義しなければ、抜け漏れやミスが発生します。

では事業やオペレーションの専門家は、何を定義し、何を技術者に伝えればよいのでしょうか？

それこそが「要求定義」です。システム「に」求める仕様は何か。そのシステムでは、事業やオペレーションの全体構造の中で、どのエリアで、どのような役割を担当するのか。ユーザーがどのような操作をしたら、どのように結果を返してほしいのか。例えば「ユーザー登録に対する定型文でのメール返信は毎日オペレーターが手動で送信しているが、非効率なのでシステム化し、ユーザー登録されたら10分以内に自動返信したい」といった要求がそれにあたります。システムへの「要求」を考え抜いて定義し、技術者に「こういうシステムを作ってほしい」と伝えるオーダーシートが要求定義です。

改めて言葉の定義に戻りますが、「誰が」を補足すると以下のようになります。

要件定義とは、技術者が、システムを動かすための仕様を定義したものです。
「◯◯であるべき」「◯◯が必要」という表現になります。

要求定義とは、非技術者が、システムに求める仕様を定義したものです。
「◯◯したい」「◯◯になること」という表現になります。

この「要求定義」は、システム開発の上流工程として最重要なプロセスです。要求定義→要件定義→基本設計→詳細設計→開発→テスト→完成→リリース/運用 という全体の流れの中で、そのシステムの品質を最も左右します。

例えば、運営しているサービスのお客様を一元管理する「顧客管理システム」を構築するとき、顧客ステータス(見込み、商談中、一般会員、優良会員、休眠会員等)を管理画面で一括更新したいという「要求」があるとします。

「要件定義」として「管理画面でCSVファイルをアップロードし、顧客ステータスを一括更新できる仕様とする」と記載するとどうなるでしょうか？

このように要件定義された場合、エンジニアは「そうかCSVファイルでの一括更新が必須なのか」と捉えます。一括更新の実現方法としてCSVファイルが前提条件になってしまうのです。本当は管理画面上で一括更新対象データを検索条件で絞り込み、そのままCSVファイルを介さずに一括更新できる機能のほうが最適かもしれない可能性をみすみす逃してしまいます。

もちろん、外部システムから出力されたCSVファイルをそのままアップロードできることが必須条件であるような場合はそのように記載するべきですが、そうではない場合「要求定義」としては「管理画面で対象データの顧客ステータスを一括更新できること」と記載するべきです。そうすることで実現方法の自由度は増し、管理画面での一括更新、CSVファイルアップロード、EXCELファイルアップロード、外部システムからのAPI連携等、システム開発の専門家が全体最適で自由に考える”遊び”が生まれるのです。

要求定義では何に気をつけるべきか？

要求定義におけるミスで一番大きな問題となるのは「要求漏れ」です。注文していないものは、当然システムには実装されません。

例えばECサイトを構築する場合

• 会員登録フローにて「本人確認を義務付けること」という要求を書き忘れた
• 商品一覧にて「キーワード入力で商品を検索できること」という要求を書き忘れた
• 購入フローにて「銀行振込で決済できること」という要求を書き忘れた

ということが発生すると、システムの根幹から見直しが必要な可能性が出てきます。

そのため、要求定義では、要求の「視点」に漏れが無いか注意する必要があります。
例えば同じくECサイトの場合、このシステムに触れる可能性がある人を洗い出すと

• サイト運営社
  • 責任者
  • エンジニア
  • 商品/MD担当者
  • マーケティング担当者
  • カスタマーサポート担当者

• サイト訪問者
  • 非会員
  • 既存会員
  • 購入経験者
  • 非購入経験者

のように様々な登場人物が見えてきます。それぞれの「視点」に立ったとき、このシステムに何を「要求」するのだろうかと想像することが重要です。

例えば「売上データを管理画面から参照したい」という要求を考える場合、現場担当者(自分自身)が業務のために利用する細かなデータは管理画面の売上メニューから参照できるが、責任者(上長)向けのサマリーレポートが出力されず、毎日手作業でレポート作成するという非効率な業務が残ってしまう、といった残念な運用になってしまうケースがあります。

要求定義をするとき、自分自身の視点は当然最も想像しやすく要求が漏れることは少ないのですが、自分ではない登場人物の視点については想像が及ばないリスクがあります。もちろん想像して要求を書き出す努力は必要ですが、要件定義に進む前にヒアリングやレビューを通じて「あなたの視点でこういう要求を考えたが抜け漏れはないか」「過剰な要求や過小な要求はないか」「他に困っていること/解決したい課題はないか」という確認ステップを踏むことが大切です。

また、要求定義にはじめて取り組む人は「こんなことシステムで実現できるのか」と不安になったり「何を夢物語みたいなこと言ってるんだ」と批判されるのではないかと心配することもあるかと思います。要求定義の後工程では、システムの専門家による要件定義を通して、案件の予算/期間/リソースも含めて「できること/できないこと」「絶対に譲れないこと/諦めて追加開発での実現でもよいこと」を一緒に整理して仕上げていきます。システム開発のプロフェッショナルによる要件定義を信じ、とにかく考えたことをすべて吐き出すことが最重要だと考えています。

自分はシステム開発に明るくないから、要件定義なんてできない。そのように諦める人をたくさん見てきました。でも、システム「を」動かすための仕様は難しくても、システム「に」求める仕様は考えられるのではないでしょうか。ポイントは「要件」ではなく「要求」を定義することです。この考え方が広がり、不幸なシステム開発が減ってくれることを願っています。

より引用・転載