「カレンダーが欲しい」を、そのまま作ってはいけない——顧客要望の読み解き方

顧客の「カレンダー機能が欲しい」は、仕様ではなく入口かもしれない。

月表示、週表示、予定の繰り返し、色分け。言われた機能をそのまま分解すると、仕様はいくらでも増える。FORWARD BASISが先に戻りたいのは、要望が生まれた場面だ。

その機能が欲しくなったとき、顧客は何をしていて、何ができずに困ったのか。

Basecampが公開するライアン・シンガーの『Shape Up』には、その考え方が分かる事例がある。カレンダーを求めた顧客へ「なぜ欲しいか」ではなく、「欲しいと思ったとき何をしていたか」を聞いた。顧客は在宅中、会議室の空きを確認するためオフィスの壁のカレンダーを見に戻らなければならなかった。

つまり、少なくともこの事例で問題だったのは「カレンダー機能が足りない」こと全体ではなく、離れた場所から空き時間を確認できないことだった。Basecamp公開原典「Set Boundaries」

これはBasecampが紹介する一つの開発事例であり、同じ聞き取り方があらゆる製品で同じ成果を生むと示した実験ではない。

それでも、要望をそのまま仕様へ変換する前に、困った場面へ戻るという考え方は使える。要望は解決策の言葉で届くが、設計すべきなのはその手前にある問題だからだ。

FORWARD BASISの読み解きでは、ここで最も大きく変わったのは機能の数ではない。「何ができれば、この問題を解いたと呼べるか」という完成基準だ。

カレンダーを作る、という依頼には終わりが見えにくい。他社にある機能を足すたびに、次の不足も見つかる。一方、離れた場所から空き時間を確認できることを目指すなら、試作品を顧客に見せる際にも、確かめる行動が明確になる。

別の場面に置き換えてみよう。以下は編集部が作った例だ。

予約サービスの利用者が「通知を増やしてほしい」と言ったとする。聞いてみると、予約が変更されたことに気づかず、古い時刻を案内していた。ならば、すべての通知を増やす前に、変更の発生と最新の時刻を見落とす箇所を確認できる。通知を受け取っていても、本文から変更点を読み取れないのかもしれない。

ただし、顧客ひとりの事情で、全員の必要性が決まるわけではない。同じ要望でも困り方が違えば、必要な対応も変わる。聞き取りで得た説明は仮説として置き、ほかの利用場面と、試作品で本当に困りごとが解消されるかを確かめる必要がある。

次の要望が届いたら、仕様書の最初の一行をこう書いてみる。

「この人は、どの場面で、何ができずに困ったのか。」

その一行が埋まったところから、作るものの相談を始めたい。