2024.12.10
“放置系”なのにサイバー攻撃を監視・検知、「統合ログ管理ツール」とは 最先端のログ管理体制を実現する方法
「急がば回れ」開発しない仮説検証(全1記事)
リンクをコピー
記事をブックマーク
安西結氏:Pivotal Labs Tokyoの安西結です。よろしくお願いします。
みなさん、こういうことありませんか? 「機能のアイデアを考えて、開発してリリースしたんだけど思ったように成果が出ないな……」とか、仮説検証の本を読んで悩んだ挙句、「とりあえずA/Bテストに回してみたけど、なんかちょっと違う気がする……」とか。これ、私が昔、実際に悩んでいたことなんです。
今日は「短時間でいかに素早く仮説検証をするか」を考えるきっかけになったらうれしいなと思ってお話しします。
まず「おまえ誰やねん」という方がけっこういらっしゃると思うので、自己紹介します。(スライドを指して)こういう者です。価値のあるプロダクトを作る方法を、リーンスタートアップとかアジャイルとかの手法を使ってお客さんにコーチングする仕事をしています。
みなさんはご存知だと思うんですけれども、「短いサイクルで作る、学ぶ、測るということをやりながら、リスクが上がらないように抑えましょう」というのがリーンスタートアップの考え方です。
ここで肝になるのが「短いサイクルで」というところです。短いサイクルで素早く仮説検証するために大切なのは、「課題の仮説、施策の仮説、最適化という3つのフェーズがある」という考え方なのかなと思っています。
例えば、とあるアプリの定例会議の光景(を思い浮かべてください)。ユーザー数がなかなか伸びないという悩みに対して、「文言を見直したらどうか」「チュートリアルを作ろう」「SNSログインがいるんじゃない?」といった、いろいろな案が出てきたりしますよね。
例えば「登録フォームを改善しよう」っていうのは、すごく良いアイデアに思えます。けれども、そのときって「登録フォームを改善することで、登録完了率を上げることができる」という最適化の仮説のもとに動いてるんですね。
でも、本当に今「登録フォームの改善をする」ことが、1番優先事項が高い施策なんだろうか? あるいは「SNS連携」という施策が、自分たちのプロダクトにおいて本当に有効な施策なんだろうか? もう1歩遡って考えると、そもそもこの課題設定って正しいんでしたっけ? そういったことが考えられます。
「ユーザーはこのプロダクトを使いたいと思ってるんだけど、面倒なので途中で諦めている」という思い込みの仮説が、さっきの会話の中であると思うんです。でも、そもそもこのプロダクトの価値ってユーザーに伝わっているんだろうか。あるいはそれが伝わっていたとしても、本当にユーザーにとって「お金を払って解決したい」と思うほど重要な課題なんだろうかということが、実は検証できていないのかもしれない。
個人的な経験としても、文言だったり画面の見た目や機能の改善といった、細かい最適化に走ってしまいがちだったんです。それがすごくもったいなかったなと、今になって思ってます。
課題の検証って、新しいサービスなら意識してやっていたとしても、機能追加とかデザインを変えようとかっていうときには飛ばしてしまいがちな工程なんじゃないかなと。ある程度労力がかかりそうな施策をする場合は、サクッと仮説検証をしたほうが、実は成長への近道なんじゃないかと考えています。
じゃあ「仮説検証って具体的になにをやるの?」ということについてです。一部書き出すだけでも、すごくいろんな方法あるんですね。1つ1つ話していくと時間が終わっちゃうので、詳細な説明はできないんですけれども。
(スライドを指して)この緑色になっているところは、開発なしで全部できることです。「ユーザーはこの課題に困っているはずだ」という仮説って、ユーザーと直接話したり、あとソーシャルメディアに落ちている声を拾ったり、ユーザーが実際にやってる行動をその場に行って観察してみることで、半日くらいでわかることなのに、つい動くものを作って検証しちゃいがちです。
そうすると、その作った時間がムダになってしまう可能性が高くなる。さらに、ダメだったとしても「せっかく作ったし、とりあえずリリースすればいけるかも……」みたいな、謎の捨てにくい気持ちが発生して、プロダクトの負債につながってしまうことが多いんじゃないかなと思います。
ただ、「ユーザーと話すだけで、本当に使ってもらえるのかなんてわかんないじゃん」と聞かれることもあるんですね。それはそのとおりです。それでいいんじゃないかなと思っています。目的はそもそものリスクをゼロにすることじゃなくて、抑えることなので。抑えるためには、あくまで検証スピードのほうが大事。検証の精度というのは徐々に上げていけばいいもの、と考えています。
完璧な検証をしようとするのって、「真っ暗な部屋にいてなんにも見えないのに、完璧な脱出プランを練ろうとする」みたいなこと。とりあえず、1歩踏み出す。なにかにぶつかったら戻って、別な方向に踏み出すということを1歩ずつやっていくのが大事だと考えています。
(スライドを映しながら)それで、こちらです。今実際にやっているプロジェクトでの検証の進め方を書いてみました。こんな感じで課題の検証も、電話から観察から、ユーザーとのインタビューなどから行ないます。そのあとはプロトタイプで検証して、実データをもらう。
そのあと実際に「いけそうだな」とわかって初めて、作り始めると。作るのも全部まるっと作るんじゃなくて、コア機能だけを作って短期間テストをしてもらって、それで「いけそうだな」という手ごたえがあって、初めて全体を作り始める……というような進め方をしています。
検証するときの注意点として、「ユーザーの意見は当てにならない問題」というのがあります。これはなにかというと、マクドナルドで市場調査すると、毎回「サラダがほしい」という声が出てくるんです。けど、サラダを出してみるとまぁ売れないという実際の調査結果があるんですね。
どうしても人間って、「こうあるべき」という自分の思いが自分の行動の予測を曇らせたり、あと目の前の人に気を使って「うん、使うよ使うよ! そのプロダクト良さそう!」と言っちゃったりということがあります。
なので、施策の検証だったら対価を差し出してもらうのがすごく大事です。対価は別にお金である必要はなくて、例えば時間とか手間を割いてもらう、なにかしらデータとか情報をもらう、あるいは「これが完成したら払います」という一筆とクレジットカード番号をもらうとか。いろんな方法があります。
この施策を検証するためにユーザーからなにをもらえるかと考えてみるのは、非常に大事なことじゃないかなと思っています。課題の検証であれば、実際に「過去にユーザーはこの課題を解決するためになにをしていたか」という、やっぱり行動について聞いてみることが大事です。
こっちが検証に使う労力と、ユーザーからの対価が比例してる状態を保てると良いと考えています。さっきの例をプロットしていくと、(スライドを指して)こんな感じです。チームが使う労力と、ユーザーにもらう対価が比例して増えていくような進め方を意識すると、「がんばってすごい作りこんじゃったけど、ユーザーからのコミットが得られなかった」というリスクの積み上げを防げるんじゃないかなと思っています。
これでトークは最後になるんですけれども、Pivotal Labs Tokyoで公式ブログをやってまして、今のスライドもここにアップしてます。ぜひブログをフォローしてください。ありがとうございました。
(会場拍手)
2024.12.10
メールのラリー回数でわかる「評価されない人」の特徴 職場での評価を下げる行動5選
2024.12.09
国内の有名ホテルでは、マグロ丼がなんと1杯「24,000円」 「良いものをより安く」を追いすぎた日本にとって値上げが重要な理由
2024.12.09
10点満点中7点の部下に言うべきこと 部下を育成できない上司の特徴トップ5
2024.11.29
「明日までにお願いできますか?」ちょっとカチンとくる一言 頭がいい人に見える上品な言い方に変えるコツ
2024.12.04
いつも遅刻や自慢話…自分勝手な人にイラっとした時の切り返し 不平等な関係を打開する「相手の期待」を裏切る技
2023.03.21
民間宇宙開発で高まる「飛行機とロケットの衝突」の危機...どうやって回避する?
2024.12.06
嫌いな相手の行動が気になって仕方ない… 臨床心理士が教える、人間関係のストレスを軽くする知恵
2024.12.03
職場の同僚にイライラ…ストレスを最小限に抑える方法 臨床心理士が語る、「いい人でいなきゃ」と自分を追い込むタイプへの処方箋
2024.12.05
「今日こそやろう」と決めたのに…自己嫌悪でイライラする日々を変えるには
PR | 2024.12.04
攻撃者はVPNを狙っている ゼロトラストならランサムウェア攻撃を防げる理由と仕組み