要件定義と要求定義の違いとは？システム開発におけるプロセスを解説

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

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

例えばECサイトを構築する場合
・会員登録フローにて「本人確認を義務付けること」という要求を書き忘れた
・商品一覧にて「キーワード入力で商品を検索できること」という要求を書き忘れた
・購入フローにて「銀行振込で決済できること」という要求を書き忘れた
ということが発生すると、システムの根幹から見直しが必要な可能性が出てきます。

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

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

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

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

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

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

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

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