☆★ある架空賃貸サービス会社のお話★☆

営業「うちのサービス、Webから資料請求の申し込みが来るじゃない」

開発部「うん。申し込み流入管理のシステムから申し込み内容を確認して、お客さんに営業かけるんでしょ」

営業「そうそう。今日さ、うちのサービス使ってくれそー！って感じの申し込みを見つけたんだけど、
あのシステムだと気づき辛いじゃん、見逃しちゃっててさ〜」

開発部「営業かけるまで時間かかっちゃったとか？」
（そんなに気づき辛いのか、知らなかった...どうして気づき辛いんだろう？）

営業「そう。実際に営業かけられたのが、申し込みがあってから1週間後だったんだよ。
実際に電話してみたら、『もう別のサービスに登録しちゃいました』って言われちゃって」

開発部「えー、すぐ営業すれば契約できたかもしれないのにね...」

営業「良さげな申し込みがすぐわかるようになれば、こんなことも無くなるのにな〜！
こういうの、システムでなんとかならないの？」

はじめに

みなさんが職場でこんな会話をしたことがあるかはわかりませんが、
「システムの力を借りてこんなことを実現したい！」というシステムへの要望は
どの現場で溢れていることかと思います。

システムへの要望は、既存で稼働しているプロダクトのちょっとした拡張だったり、
新たなプロダクトをどーんと構築する必要のあるものだったりします。

また、システムに来る要望も様々で、
「こんな機能を追加してほしい」と具体的な要望があったり、
「なんとなくこんなことがしたい」とふわっとした要望があったりします。

私自身、業務で上流工程に携わる機会が増えてきており、
出来るだけ失敗しない要件定義ができたら...と思う今日この頃です。

今回は、私自身の学びも込めて、よりよい要件定義のために、
少なくともこれは意識しておくと良さそう、というポイントを書いていければと思います。

要件定義とは

そもそも要件定義とはなんでしょうか。

Googleで「要件定義」を調べると、

「システム開発において、実装すべき機能や満たすべき性能を明確にする作業」
「ソフトウェアやシステムに必要な機能や性能を明らかにしてゆく作業」

といった定義が多く見られます。

英語で「要件」「要求」を意味するRequirementをWikipediaで検索すると、
より詳細な定義が記載されています。

システムが顧客、組織、潜在的なユーザ、または他のステークホルダーに価値と有用性を提供するのに必要な(またはしばしば望まれる)機能、属性、能力、特徴や質に関する概念

https://en.wikipedia.org/wiki/Requirement

要件定義とはこれを明らかにする作業ということになります。

基本的には「システムが持つ機能や能力を定義する作業」ということになりますが、
英語での定義には「価値を提供する」という意味が含まれており、
これは「よりよい要件定義」を考える際のヒントになりそうです。

「より良い要件定義」とは

上記の定義を参考にすると、「より良い要件定義」とは

「ステークホルダーにより多くの価値を提供するため、
システムに実装する機能や属性、性能を過不足なく明確にすること」

のようになりそうです。

これを踏まえて、より良い要件定義のためにできることを考えてみます。

その1「なぜつくるの？」

何よりもまず先に、「何のためにつくるのか」という、システム開発の目的を明らかにしましょう。

開発するシステムの力を借りて、一体何を実現したいのかを定義します。
ここを定めることで、開発する成果物のスコープ(範囲)が明確になります。

上の会話では、営業メンバーが、顧客からの資料申し込みに気づかず、
サービスを購入してくれたかもしれない顧客に
営業をかけるチャンスを失ったことをぼやいています。

実は多くの営業メンバーが、同じような問題で営業のチャンスを失っていて、
「システムの力で解決してくれ〜！」という要望がシステム開発部に来たとしたら、
この場合、開発するシステムの目的は

「Webの資料申し込みから、営業開始までにかかる時間を営業メンバー一人あたり25%削減する」とか、
「Webから資料申し込みがあった顧客の契約成功数を15%増加する」
などといったものになりそうです。

この指標が明確に定まると、個々の要望がこの達成に関係するのか、
関係するならシステム化すべきだし、関係しないならシステム化すべきでない、という
開発の範囲を明確にできます。

また、開発にかけられるコストが限られていて、
実現したい要望が多くある時も、この指標の実現にどれだけ貢献しそうか、という観点から
要望に優先順位をつけることができます。

その2「だれがつかうの？」「どうやってつかうの？」

次は、開発するプロダクトに関わる登場人物をはっきりさせましょう。

これは実際に業務でプロダクトを使うユーザーかもしれないし、
直接プロダクトを使うわけではないが何らかの関係を持つ人かもしれません。
個々の登場人物をはっきりとさせ、グルーピングします。

今回の例でいうと、
「Webサイトから資料請求の申し込みを行う顧客」
「社内システムから申し込み内容を確認して営業をかける営業メンバー」
ということになりそうです。

今回は、開発の目的を達成するために、社内システムの拡張開発を行うことになりました。
この場合、主要な登場人物は「営業メンバー」となります。

主要な登場人物(今回は社内システムを使用する営業メンバー)が決まったら、
そこからユーザのプロダクトへの要求をできるだけ正確に把握しましょう。
「システムをどんな風につかえたらあなたは嬉しいのか？」をできるだけ精緻に引き出します。

このユーザの要求の引き出しは、要件定義の中でも時間をかけて行うべき作業かと個人的には思います。
ここを正確に行ってプロダクトに反映できないと、結局「作るだけムダ」なプロダクトができてしまう可能性が高いためです。

インタビュー

相手が何を欲しているのか、システム開発に関わらず広く使われている方法は、
実際に相手に聞いてみること、つまりインタビューになります。

これは、ただ単に「何が欲しいですか？」と聞くよりも、
ユーザーが批評できる、何かしらのたたき台を用意しておくと効果的です。
白紙の状態から何かを考え出すよりも、既にあるものに対して批判を加える方がはるかに簡単だからです。

今回の例で言えば、
「顧客からの資料請求の申し込みを、営業メンバーがすぐ気づけるようにしたい」
とのことなので、
「Webから顧客の申し込みがある度に、全営業メンバーにメールで通知する」
といった思いつきをたたき台を提案してみます。

すると、
「いや、全営業メンバーだと対応者がかち合うから困る。
申し込み内容から顧客の住所がわかるから、そのエリアの営業メンバーだけに絞って欲しい」
とか、
「そもそもメールの通知が多すぎて確認が漏れる。Slackの方が多く見るからそちらから通知して欲しい」
とか、ユーザーの要求の理解に有益な返答が返ってくるかもしれません。

理由が理解できない返答や批評が返ってきたら、さらに理由を深掘りしましょう。
これを繰り返すことでユーザーの要求をさらに明確にしていくことができます。

観察

既存の社内システムの改修などで、利用ユーザーが社内で簡単に接触できるのであれば、
実際にシステムを利用している所を観察するのも、ユーザーの要求を把握するヒントになります。

今回の例で、営業メンバーの横について、
現行の申し込み管理システムを操作をしている所を観察してみます。

この申し込み管理システムは、「顧客からの申し込みを一覧で表示する画面」と、
「申し込み内容の詳細を表示する画面」があります。

営業メンバーの操作を観察すると、
一覧画面を漫然とスクロールし、詳細ページを見てはすぐ一覧ページに戻り、
またスクロールしては詳細ページを見て戻る...というような操作を繰り返しています。

開発部「どうして一覧ページと詳細ページを行ったり来たりするの？」

営業「契約してくれる顧客って、申し込みの時に『メルマガ配信を希望する』って項目に
チェック入れてる人のことが多いんだよね。それに絞って営業かけたくてさ。
一覧ページからだとそれが見れないから、一つずつ詳細ページ見て確認してる」

ここからは、
「一覧ページから『メルマガ希望』の項目を確認できるようにしたい」とか、
「『メルマガ希望』がついた申し込みだけ表示できるようにしたい」といったような
ユーザー要求を明らかにすることができます。

終わりに

より良い要件定義のために意識すること、いかがでしたでしょうか？
私自身まだ勉強中のため、なかなか多くの方にヒントになるようなことは書けていないかもしれませんが、
少しでも参考になれば幸いです...！

参考

https://ja.wikipedia.org/wiki/%E8%A6%81%E4%BB%B6
https://www.atmarkit.co.jp/ait/articles/1507/02/news009.html
ソフトウェア要求　第3版
https://www.amazon.co.jp/dp/B00RKWXDE6/ref=dp-kindle-redirect?_encoding=UTF8&btkr=1