顧客ニーズを反映した商品なのに、なぜ売れない？ UXデザインで考える「顧客理解」の3つの壁

はじめに

「ユーザーエクスペリエンス(UX)デザイン」という言葉を、よく耳にするようになりました。UXデザインの分野には、エンドユーザーのニーズをつぶさに拾いあげることで、プロジェクトやビジネスを成功に導くためのノウハウが集まっています。

UXデザインの基本のひとつは「エンドユーザーにインタビューにいく」ことです。

本連載を通じて、ユーザーインタビューの「はじめの一歩」を体験していきます。第1回、第2回では、「そもそもユーザーニーズはどのようにすればわかるのか」について解説します。

「エンドユーザーにうれしいものづくりをしよう」と考える

UXデザインでは「私たちは、誰を『しあわせ』にするために、ものをつくっているのだったか?」を強く意識します。

UXデザインの根本的な思想は、「エンドユーザーにうれしいものづくりをしよう」と考えることです。エンドユーザーにうれしいものをつくり、ビジネスがうまくいく。そのために、エンドユーザーをよく知ろう。その循環を大切にするのです。

「エンドユーザーのニーズ」にたどりつくまでの「3つの壁」

システム開発において、上流工程にある「要件定義」は、UXデザインから見ると、実は大きな矛盾をはらんでいます。「エンドユーザーのニーズ」にたどりつくまでに「3つの壁」があるのです。

1つ目の壁：そもそも現場の担当者(エンドユーザー)は、 自分たちが本当に欲しいものを正確に言葉にできているのか?

UXデザインの分野で、有名な実験があります。

ある食器メーカーが、新製品を開発することになりました。エンドユーザー(消費者)に集まってもらい、「どんな新商品が欲しいか、議論してください」と伝えます。

議論の末、エンドユーザーからは「黒くて四角いお皿がスタイリッシュで欲しい」という結論が出ました。

そこで、食器メーカーのモデレーターが、「ありがとうございます。それでは、今日のお礼に、好きなお皿をお持ち帰りください」と言うと、全員が「⽩くて丸いお皿」を取っていきました。

それを見た食器メーカーのモデレーターが「黒くて四角いお皿が良かったのではないですか?」と問うと、ユーザーから初めて「家にあるのは⽩ばかりだから」「四角いと収納しづらい」といった意見が出たのです。

ユーザーは嘘をついていたわけではありません。「黒いお皿」と答えたときは、本当にそう思っていたのです。しかし、行動を促すと、現実は異なりました。

この実験が端的に表しているのは、「ユーザーは自分が『本当に』欲しいものを、そもそも自分で言葉にできていない」ということです。

つまり、エンドユーザーに「何が欲しいですか?」と訊いて、「こういうものが欲しい」と得られた回答は、どこかで本当のニーズでないことがあるのです。「要件定義」で「何が欲しいですか?」と質問するのは、プロジェクトをミスリードしているかもしれません。

2つ目の壁：そもそも現場の担当者(エンドユーザー)は、 自分たちに本当に必要なものを知っているのか?

もうひとつ、例を挙げます。

ある製造業の現場では、QC活動として、システムから出てくる帳票を、わざわざ手で転記することでミスを減らしていました。発案者は、この改善で社長賞まで受けていました。

UXデザイナーが現場に調査へ行き、「なぜわざわざ転記するのですか?」と訊いたところ、「誤読によるミスを防ぐためです」と担当者は誇らしげです。

そこで、帳票を見せてもらうと、システムから印字される帳票の⽂字がとても⼩さく、誤読しやすいことがわかりました。

「システムを改修して、⽂字を⼤きくすれば良いのではないですか?」と訊くと、担当者は驚いて「そもそもシステムを改修できると思っていなかったので、その改善法は思いつきませんでした」と答えたのです。

この例が表しているのは、「ユーザーは自分が見ている範囲のなかでしか、改善策を発想できない」ということです。「システムの改修」は現場の感覚としては「自分たちの手の届かないところ」だったので、無意識のうちに発想の幅を狭めてしまっていたのです。

製造業の現場にとって本当に必要だったものは、わざわざ転記する手間を増やすことではありませんでした。しかしそれは、ユーザー自身では発想しづらいものだったのです。

この例の教訓は、「ユーザーは自分が『本当に』必要なものを、知らない」ということです。ユーザーが言葉にする前の思考をめぐらせるところで、すでにバイアスが発生しているのです。

3つ目の壁： 情報システム室の担当者は、 現場のニーズを正確に語ることはできるのか?

最後の壁は、現場から開発者に届くまでに、仲介者がいることで、情報が歪んでしまうことです。

現場からニーズがあがったとします。そのニーズを開発者に伝えるとき、たとえば「現場の上長」と「情報システム室の担当者」を介するとしましょう。

まず、ニーズを現場の上長に伝えます。このとき「現場で困っている点」と「現場の上長が困っている点」が異なっていることがあります。たとえば、現場では「帳票が読みづらくて困っている」が、上長は「製造量のミスが多くて困っている」というほうに興味があると、上長は「帳票の読みづらさは大したことじゃない、問題は製造量のミスだ」と考えて、情報システム室の担当者に、そのように伝えてしまいます。

この時点で、すでに現場のニーズは、フィルタがかかってしまいます。

情報システム室の担当者は、現場の上長から言われた言葉を、システム開発の言葉に翻訳しなおして、開発者に伝えようとします。しかし、情報システム室の担当者は、現場の業務にそれほど詳しくないため、システム開発の言葉にしづらい、細かいニュアンスがこぼれ落ちてしまいます。

このようにして、開発者に伝わったときには、現場のニーズは歪んでしまっているのです。

「3つの壁」を越えるには「インタビューする技術」を持つ

ここまでに紹介した「3つの壁」を越えなければ、エンドユーザーをしあわせにするものづくりはできません。「要件定義」のところで、これだけのコミュニケーションのロスがあるのです。

では、どうすれば「3つの壁」を越えることができるのでしょうか。ここまでに見てきたとおり、やみくもにエンドユーザーに話を聞きにいっても、本当のニーズにはたどりつけそうにありません。

そこで、「インタビューする技術」が必要となるのです。

＊　＊　＊

次回は、どのような観点でいれば「3つの壁」を越えられるかを、具体的なインタビューする技術から考えていきます。