価値仮説とユーザーヒアリングによるユーザーファーストなものづくり
身の回りで沸き起こる開発に関する議論を、効率よく質の高いものにするために考えたことのメモです。
きっかけ
- C社やW社、I社の方の開発の進め方に関する話を聞く機会があり、感銘を受けた
- UIや機能の是非に関する議論は難しく、これまでの開発でうまく進められないことが多々あったため、より良い方法はないかと模索していた
身の回りで沸き起こる既存の議論の問題点
「○○がわかると△△だから、ユーザーにとって有益なはずだ」
- ○○を知りたいというユーザーが実際にいたの?
- ○○を見せたいのはわかるけど、見たいと思うユーザーがいなかったら誰にも使ってもらえないよな...
「☓社がやっているから(海外で流行っているから)、弊社も○○をやろう」
- ☓社のユーザーと弊社のユーザーは同じなの?ユーザーが抱えている問題は同じ?
「ユーザーが○○な機能を欲しいと言っているので、早く開発してリリースしたい」
- その発言の裏にある問題の本質を見極めるべきでは?それは本当にいま最優先で取り組むべき?
個人的に感じた問題点をまとめると...
- ユーザーは○○したいはずだという妄想に基づいて議論が進んでいる気がする
- 本当に想定する課題を持ったユーザーがいるのか、ユーザーはその課題の解決を熱望しているのか、といったことを確かめた方がよいのではないか
- = ユーザーヒアリング をした方がよいのでは
- ○○させたいという作り手のエゴによって議論が進んでいる気がする
- ロジックが人によってバラバラ
- 例1: 私は○○したいと思ったから、△△であるべきだ
- 例2: ユーザーが○○をほしいと言っているから実装しよう
- 同じ前提知識と目指すべき方向性を持った人が、同じロジックで議論したほうが効率がいいのではないか
- C社やI社は意識的にそうしている?
- = C社やI社で活用されている 価値仮説 を用いれば、効率よく効果的に議論が進むのでは?
きっと俺たちには、"価値仮説" と "ユーザーヒアリング" が必要だ
価値仮説 とは?
スタートアップでは最初に、「提供する製品やサービスが本当に価値のあるものかどうか」を確認していく活動を続けます。その仮説を「価値仮説」と呼んでいます。
その仮説を定義するため、C社では下記のフォーマットを用いているそうです。
フォーマット
(プラスα)変化する指標
(プラスα)MVP
MVPとは?
"Minimum Viable Product"の略。 リーンスタートアップの著者 エリック・リース 氏曰く、
MVPとは、(Build-Measure-Learnの)フィードバック・ループ1周を回せる『必要最低限の労力』+『最低限の実装時間』バージョンの製品
だそうだ。 リスクや投資を最小限に抑えた実用最小限の製品により、想定する仮説の検証を行うことが目的である。
ここはかなり工夫できるところで、例えば Twitter で呟き、フォロワーのFav数やretweet数などの反応を見るというのもひとつの手である。
価値仮説 のメリット
- エンジニアは自分が作りたい機能ありきで考えてしまいがちだが、本来重要であるはずのユーザーの抱えている課題について、強制的に考えさせられる
- チームメンバーに共有する前に、フォーマットを通して文章に落とすことで、事前にロジックの穴を補完できる
- 論点が整理されるため、議論が効率的になる
- C社やI社などの開発現場で実際に活用されており実績がある
- ロジックを組み立て、ユーザーヒアリングを行いその価値を確認することは一見コストが高いように思えるが、妄想によってユーザーに不要なものをつくることに時間を掛けてしまうより圧倒的に生産性が高い
価値仮説 がない開発
- ロジックがバラバラであったり、論点が散漫になってしまい議論に時間がかかる
- 時間が掛かっているからといって、プロダクトのクオリティに繋がっているとは限らない
- リリースをしたが、何が改善されたかわからない
- リリースで解決する課題が不明確だと、ユーザーにとってプラスだったかマイナスだった把握できない
- ユーザーの課題や行動に関する学習がないので、ユーザーへの理解が進まない
価値仮説 を補完する ユーザーヒアリング
上記の価値仮説を補完するためにユーザーヒアリングを行うべきと考える。 価値仮説フォーマットで想定するユーザーが、想定する欲求や課題を持っているか、その課題が解決されることを熱望しているか(お金を払ってでも使いたいと思ってもらえるか)をユーザーヒアリングで確認する。 妄想ではなく、実際にユーザーの声を聞くことが重要。
よくある疑問
将来の製品アイデアの話をしたら、アイデアだけ盗まれてしまうのでは?
基本的には、インタビュー時に製品アイデアを話すことはない。話をするのは、製品やサービスによって解決したいユーザーの課題について。
ユーザーヒアリングは時間がかかるので、非効率ではないか?
価値仮説を明確にし、ユーザーヒアリングを行うプロセスの中で、想定に一つでも誤りが見つかれば、開発工数を大幅に節約できる。 多くの時間を投じて開発した末に誰も使ってくれないことに比べれば効率がよい。
統計的に有意な人数のユーザーヒアリングを行うことは難しいのでは?
有効なユーザーヒアリングのサンプル数については、現在勉強中です。 ただ、妄想を基に開発を進めるよりは、2~3人でもユーザーヒアリングを行いその事実を基に開発を進めた方が、リスクは低いのではと考えている。
「大事なこと」
参考
- Service development for users
- 新規事業やスタートアップで優れたプロダクトを作るときに使える Y Combinator などの考え方
- リーン顧客開発 ―「売れないリスク」を極小化する技術
リーン顧客開発 ―「売れないリスク」を極小化する技術 (THE LEAN SERIES)
- 作者: シンディ・アルバレス,エリック・リース,堤孝志(監訳),飯野将人(監訳),児島修
- 出版社/メーカー: オライリージャパン
- 発売日: 2015/04/25
- メディア: 単行本(ソフトカバー)
- この商品を含むブログ (2件) を見る