参加レポート: 経験談から学ぶ、スタートアップ・事業立ち上げにおけるプロダクト開発の”あるある”と対処法!

9月12日(木)、DevLOVE のイベントに初めて参加してきました。

DevLOVE は、開発(Develop)を愛する人たちの集まりで、昨日より今日、今日より明日と、現場の開発を前進させていくため、役立つことはなんでも幅広く取り扱った勉強会やイベントを開催しています。

devlove.doorkeeper.jp

イベントの流れ

  1. 櫛田さん(@miz_kushida)のお話
  2. 市谷さん(@papanda)のお話
  3. 5~6人に分かれてディスカッション

1. (櫛田さん)事業立ち上げの"あるある"はなぜ生まれるのか?

新しい事業やプロダクト開発の支援経験が豊富な櫛田さん。経験してきた中での”あるある”をお話してくださいました。「行動」に着目していて、なぜそれをやらないといけないのか?を考えることが好きだ、とのことです。

思いつきの事業アイデアで UI/UX や機能の検討を始める

櫛田さんが過去に行ったワークショップで、事業アイデアを思いついた時に何をすべきか?をディスカッションし、その時はいい内容が出てくるが、いざ実際に自分がそうなった時になると、言っていたこととは違うことをやってしまいがちな人が多いそうです。

  • ポイント
    • 何をやったら「検証したか」になるかを定義すること

ペルソナから作り始めてしまう

ゼロイチ(ほぼゼロの状態)の時に、作ったペルソナが実在しないこともある、とのことです。

私は、より具体的な人(現実にいる人)を連想できるほどの定義が必要、と受けとめました。

顧客の声を聞いたつもりになっている

まともにユーザーレビューができてる人を見たことがないし、ご自身も難しいことだと感じている、とのことです。

DFree(以下参照)の開発時、排泄問題を困っていることだと思い込み、ユーザーへのアンケートで、ユーザーは何を選んでも困っている前提の回答にしかならないものになってしまっていた、ようです。

  • ポイント
    • 自分がその問題を解決したいと思っているからといって、顧客はそう思っているとは限らない

dfree.biz

顧客の課題を簡潔に言えない

櫛田さんの最近の感覚として「いいな」と思っていることは、プロダクトの初期段階で、20文字程度で課題を言うこと。20文字程度で言えない課題は課題じゃないな、と。DFree の開発で 2ヶ月くらいインタビューをして辿り着いたのは、「正しいケアの仕方がわからない」だったそうです。

  • ポイント
    • 課題を書き出す時、「〜したい」ではなく、「〜できない」というシンプルなもので

私はこのお話を聞いて、「〜できない」という形式であれば、「何のために?」という自分の主観や顧客の主観を省くことができるので推奨されているのかな、と思いました。

開発優先度が明確でない

チームや会社で明確になっているか?有力なお客さんが言ったから入れた、ユーザーインタビューで強めに言っていたから入れたとか、それって本当に必要なものなのか、プロダクトの価値のポジショニングを定義することが大切、とのことです。

  • ここのお話の中で紹介のあった本(東大の方が書いたと言っていたので、多分こちらの本で合ってるかと・・・)

どうして"あるある"は生まれるのか?

以下の対立した構造がコンフリクトを起こし、様々な問題を引き起こします。

  • 主観 vs 客観
    • 「何に困ってますか?」と聞くのは顧客の主観
    • アンケートで困ってることを 1 or 2 or 3 or 4 で選ばせるのは自分の主観
    • 客観は、自分の外にあるものだし、顧客の外にあるもの
  • 経営層 vs 現場
  • 企業の利益 vs 顧客の利益
  • 短期的視点 vs 中長期的視点
  • 混沌 vs 秩序

ほとんどの場合はどちらかのポジションにいる。これを解決するためには、両方を統合し、第三の視点を導入し、1つ上の視点で見ること、とのことです。

両方を統合する時のコツ

「主観 vs 客観」の統合の仕方について、顧客に主観は一切聞かない。例えば、チームの仲がいいのか悪いのかを聞きたい時に、「状況はどうですか?」と聞いても、たいてい「普通です」とか「まぁ、いいです」という回答がくる。そんな時は、「5W1H」の Why を抜かした「4W1H」で、つまりファクトで聞くとよい、とのことです。

そのチームに山田さんという人がいたとして、「今日は誰とランチに行きましたか?」、「昨日は誰と?」、「じゃあ、一昨日は誰と?」ということを聞くことで見えてくるものがある。

顧客のことについても、顧客の行動を自分にインストールし、課題や仮説を自分の中に立てることが重要となってくる。

その他の統合のコツは、対立する人が社内であれば、第三の視点として「顧客」を入れ、「顧客」のカスタマーサクセスを定義して一緒に目指していくことで、コンフリクトが和らぐ、とのことです。

2. (市谷さん)4つの「戦犯」から考えるサービスづくりの失敗

アテンション(注目)にあたる価値がない

ユーザーの問題解決もできるし、検証も OK。だけど、ユーザーインタビューすると、「お〜それそれ!」みたいな飛びついてくるような反応がなかったりする。これは、分かりやすい価値を表現できていないことになる、とのことです。

私は、ユーザーの課題解決ができるようにするために必要なことは何か、ということばかりが頭にありました。今の自分に足りていないのはコレ(アテンションにあたる価値)だ!と思いました。

お客さまと打ち合わせをしている時に、「それいいね!」と言ってもらいたいところでは特に反応がなく、想定していなかったところで「それ素晴らしい!」と言われました(1つでもあってよかった・・・)。自身の未熟さを感じつつも、「アテンションにあたる価値」を追求したいと思いました。

体験の検証をやっていない

プロダクトの構想は広がりがちだけど、本当に必要そうな部分を検証することが必要になる。

仮説には3つの側面がある。

  • 課題の仮説(本質):利用者の課題についての仮説
  • 機能の仮説(実体):サービスの機能についての仮説
  • UI の仮説(形態):ユーザーインターフェースについての仮説

本質を捉えていないのに UI の検証をするのはよろしくない。

チャネル検証をやっていない

ユーザーへ届けるための検証のこと。たいてい開発が終わったくらいにどうやって届けようかと検討していきがちで、後になって「届けるコスト」が現実的ではないことに気づくことになる、とのことです。

  • ポイント
    • どんなにいいプロダクトでも届けられないと意味がない

事業を始めてしまう

MVP で検証したいのはビジネスモデルなのにも関わらず、いざ MVP が完成すると、検証が終わっていないにも関わらずビジネスが始まってしまうことがある。動くものができると、関係者の期待が生まれやすいため、とのことです。

  • ポイント
    • 今何をやっているのか、をちゃんと把握することが大切

3. ディスカッション

5 ~6 名くらいでグループを作り、どの”あるある”に共感したか、などをディスカッションしました。どのグループの方々も共感ポイントが多いのか、笑い声も交えつつ、盛り上がっていたように感じました。

また、今まで参加したことのあるイベントは、エンジニア寄りのものだったので、プロダクトオーナーといった立場の違う方とお話することができてとても新鮮でした。ただ・・・緊張していたせいか、何を話したか・・・失念してしまいました(泣)

最後に

最近、お客さまと直接打ち合わせをすることがあるのですが、どのようにヒアリングしたらよいか頭を悩ませていました。お客さまの行動、ファクトを捉えるような質問の仕方を考え、実践していこうと思いました。そのためにも「ユーザーインタビュー」をキーワードに、勉強していってみようかなと思います。

カイゼン・ジャーニー』と『正しいものを正しくつくる』を沖縄に置いて東京(出張)へ来てしまったことを後悔しています。持ってきていれば市谷さんにサインもらえたかもしれないのに!

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで

カイゼン・ジャーニー たった1人からはじめて、「越境」するチームをつくるまで