仮説検証型のプロダクト開発｜思いつきで作らないための型

来週のスプリントで何を作るか、会議の残り10分で決まってしまった。心当たりはありませんか。

思いつき自体が悪いわけではありません。困るのは、それが当たっているのか確かめないまま、2週間分の工数が動き出すことです。

作ってしまえば、もう簡単には引き返せません。使われない機能でも、消すにはまた別の会議がいります。

仮説検証型の開発は、この順番を入れ替えるだけの話です。作る前に、いちばん危ない思い込みから確かめます。

この記事では、仮説の書き方、確かめる順番、成功ラインの決め方、チームでの合意の取り方までを、明日から使える形で並べます。

なぜ、思いつきのまま作ってしまうのか

仮説を立てたほうがいいと知らないPMは、たぶんいません。それでも飛ばされるのは、飛ばしたくなる理由が現場にあるからです。

いちばん多いのは、確かめ方が思いつかないことです。検証と言われてもA/Bテストくらいしか手札がなく、それには時間もアクセス数も足りない。

だったら作ってから考えよう、となる。気持ちはよくわかります。

次に多いのが、手が空くことへの居心地の悪さです。エンジニアの手を止めたくないという理由で、確度の低い開発が先に入ってしまう。

三つ目は、声の大きさです。重要顧客の一言や役員の思いつきが、検証を飛び越えてそのまま仕様になります。

どれも、悪意やサボりから生まれたものではありません。善意と焦りが積み重なった結果として、確かめない開発ができあがります。

検証は、開発を遅くする作業ではない

検証を挟むと遅くなる。そう思われがちですが、長い目で見ると逆になることが多いです。

2週間かけて作った機能が使われず、次の四半期に作り直す。この往復のほうが、3日の検証よりずっと高くつきます。

速さの単位を、リリース数ではなく学習の回数に置き換えてみてください。同じ2週間の使い方が変わります。

全部を検証しようとすると、必ず破綻する

とはいえ、あらゆるタスクに仮説カードを書き始めると、一週間で嫌になります。実際そうやって形骸化したチームを、たくさん見かけます。

目安として、工数が3人日を超える開発と、ユーザーの行動を変えることを狙った開発。この二つだけに検証を義務づけると、負荷と効果のバランスが取れます。

文言の微修正やリファクタリングは、対象外でかまいません。線引きを先にチームで決めておくと、毎回もめずに済みます。

仮説は、書ける形にして初めて仮説になる

モバイルのUIを直せばCVRが上がるはず。これは仮説ではなく、願望です。

誰のために、どこを、どれくらい動かすのかが書かれていないので、終わったときに当たりか外れかを判定できません。判定できない仮説は、いくら検証しても学びが残りません。

使える仮説には、5つの空欄があります。誰が、どんな状況で、何に困っていて、何をすれば、どの指標がどう動くか。

埋めてみると、自分でも驚くほど埋まらないはずです。埋まらなかった欄が、まだ調べていない場所です。

会議でよく出る言い方が、どこで検証不能になっているのかを並べてみます。自分のバックログにある一行と見比べてみてください。

右の列まで書けたものだけが、検証にかけられます。書けないうちに開発を始めると、リリース後に成否を語れない機能が一つ増えるだけです。

実際に書くと、こんな一枚になります。

仮説カード #12

誰が       : スマートフォンで料金ページに来た初回訪問者
どんな状況 : 他社と比べながら、移動中に3分だけ見ている
何に困る   : 料金表が横スクロールで、自社に当てはまる金額を読み取れない
だから     : 画面幅に応じてプラン1件ずつのカード表示に切り替える
指標       : モバイルの料金ページ → 申し込みフォーム到達率 6.2% → 8.0%
期限       : 公開後3週間
反証条件   : 到達率が7.0%未満、またはPCの到達率が下がる

この7行が埋まらないうちは、仮説がまだ大きすぎます。二つか三つに分けてください。

主役の指標は、一つに絞る

一枚のカードに指標を三つ並べると、結果が出たときに都合のいい一つが選ばれます。上がった数字だけを見て成功と呼ぶ報告は、たいていここから生まれます。

主指標は必ず一つにして、残りは悪化していないかを見る監視用として別枠に置いてください。申し込み数を狙った施策なら、解約や問い合わせの件数が監視側の候補になります。

反証条件を先に書く

いちばん効くのは最後の行です。何が起きたら、この仮説は間違いだったと認めるのか。

これを先に書いておかないと、結果が出たあとで基準のほうが動きます。7.0%を割っても、季節要因だ、期間が短かった、という話が始まる。

先に負け条件を決めておくのは、あとから自分たちを守る仕組みでもあります。

指標は、現在値とセットで書く

CVRを上げる、では足りません。今いくつで、いくつを目指すのかまで書きます。

現在値がすぐ出てこないなら、そこが最初の作業です。ファネルの各段でどれだけ通過しているかを出す手順は、ファネル分析の基本｜離脱ポイントの見つけ方と改善の進め方に整理しています。

確かめる順番は、コストではなくリスクで決める

前提がいくつもあるとき、どれから確かめますか。ここで迷いますよね。

安く済むものから、と考えたくなります。でも正しい基準は、外れたときに全部が崩れる前提はどれかです。

プロダクトの前提は、だいたい4種類に分かれます。

• 需要リスク：そもそも欲しい人がいるのか
• 価値リスク：その解決策が課題を本当に解くのか
• 実現リスク：技術・法務・運用として作れるのか
• 事業リスク：作って事業として成り立つのか

失敗の多くは需要側で起きます。それなのに検証は、実現性から始まりがちです。

作れるかどうかは、たいていエンジニアに30分聞けば見当がつきます。欲しい人がいるかどうかは、何時間会議をしても分かりません。

ですから順番は、需要、価値、実現性、事業性。この並びは崩さないでください。

この順番を工程として回す方法は、プロダクトディスカバリー入門｜作る前に確かめる進め方で詳しく扱っています。

検証手段は、確かさと日数で選ぶ

手札が増えるほど、検証は現実的になります。よく使う5つを、性格の違いで並べました。

上に行くほど安く、下に行くほど確かになります。全部をやる必要はありません。

まず、手元のデータを開く

飛ばされがちですが、費用ゼロで今日できるのはここだけです。すでにサイトに来ている人が、どこで止まっているのか。

離脱の段が分かれば、仮説の宛先が一気に絞れます。個別の行動を追えば、往復や短すぎる滞在といった迷いの跡も見えます。

Strideはファネル、PV/UU、N1分析、セッションリプレイでこの作業をまとめて行えます。ただし測れるのはサイト側の行動、つまり訪問、回遊、フォーム到達、コンバージョン、再訪までです。

ログイン後のプロダクト内の使われ方は別の仕組みが必要なので、そこは製品ログやプロダクト分析ツールの担当だと割り切ってください。

道具の役割を混ぜないほうが、仮説の宛先もはっきりします。サイト側で落ちているのか、使い始めてから落ちているのか。

ここを最初に切り分けるだけで、無駄な検証がずいぶん減ります。

聞くときは、未来ではなく過去を聞く

ユーザーインタビューが当てにならないと言われるのは、たいてい聞き方のせいです。この機能があったら使いますかと尋ねれば、多くの人は親切に使うと答えます。

代わりに、直近でその作業をしたのはいつですかと聞いてください。未来の意向ではなく、過去の事実を聞くと、答えの信頼度が跳ね上がります。

先月そんな場面は無かったと返ってきたら、それだけで需要リスクの答えが半分出ています。5人で同じ答えなら、もう十分です。

入り口だけ先に作るときの作法

まだ無い機能のボタンやリンクだけを先に置いて、押される数を数える。需要リスクを数日で潰せる、強い手です。

ただし押した人を放置すると、単に信頼を削るだけになります。準備中であることを正直に伝え、公開時の通知を受け取れる受け皿を必ず用意してください。

判断の目安も先に決めておきます。表示1,000回あたり何回押されたら作るのか、その線を公開前に書いておいてください。

自動化する前に、人力で届けてみる

価値リスクを潰す方法としていちばん確実なのは、作らずに手作業で提供してしまうことです。裏側が全部人力でも、受け取る側の体験は本物になります。

たとえば自動レポート機能なら、まず10社分をスプレッドシートで作って送ってみる。続きを欲しがられるかどうかが、そのまま答えです。

数を増やせないのが弱点ですが、序盤に必要なのは規模ではありません。喜ばれたのか、丁重に断られたのかが分かれば十分です。

A/Bテストは、最後に置く

差が本物かを判定できる唯一の手段ですが、時間と母数を要求します。だから序盤の広い問いには向きません。

文言や配置のように、既に方向が定まった選択肢を比べるときに真価が出ます。Strideならサイトを開いたまま、ノーコードでその比較を作れます。

進め方と落とし穴はA/Bテストの始め方｜ノーコードで検証する手順と注意点にまとめました。

手段は、重ねると精度が上がる

5つの手段は、どれか一つを選ぶためのものではありません。データで落ちている場所を絞り、5人に聞いて理由をつかみ、最後にA/Bテストで差を確かめる、という重ね方が現実的です。

一つの手段だけで結論を出そうとすると、その手段の弱点がそのまま判断の弱点になります。数字は場所を教え、言葉は理由を教えると考えておくと、組み合わせに迷いません。

成功ラインは、始める前に計算しておく

判定できる仮説かどうかは、実は数字の計算で先に分かります。よく使う目安の式はこれだけです。

必要なセッション数は、おおよそ 16 × p × (1−p) ÷ 差の二乗。pは今のコンバージョン率、差は検知したい変化量です。

現在のCVRが2.0%で、2.4%になれば成功としたい場合を計算してみます。差は0.004なので、16 × 0.02 × 0.98 ÷ 0.000016 で、片方のパターンにおよそ19,600セッション。

2パターンなら合計約39,000セッションです。週に5,000セッション来るサイトなら、8週間かかります。

長い。ここで多くの仮説は、そもそも今の規模では判定できないと分かります。

この計算を先にやるかどうかが、いちばん差のつくところです。走らせてから足りないと気づくと、3週間分の時間が丸ごと消えます。

ついでに、期間の決め方にも一つだけ注意があります。曜日で行動が変わるサイトが多いので、必ず7日単位で区切ること。

平日だけ、あるいは週末を1回多く含んだ比較は、それだけで結論が動きます。

判定できないと分かったときの三つの逃げ道

数字が足りないと分かったら、やり方を変えます。無理に走らせて、出た差を信じるのが一番まずい。

ひとつは、もっと大きく変えることです。ボタンの色ではなく、ページの構成ごと差し替えれば、必要な母数は一桁下がります。

ふたつめは、判定を手前の指標に移すことです。最終成果が月30件でも、フォーム到達なら月600件あります。

件数が20倍なら、差はずっと早く読めます。この置き方はマイクロコンバージョンの設計｜小さな一歩を計測するで詳しく扱っています。

みっつめは、定量での判定を諦めて、定性で確かめることです。5人に触ってもらって全員が同じ場所で詰まるなら、A/Bテストの結果を待つ必要はありません。

最後にひとつだけ、覚えておいてほしいことがあります。差が出なかったことは、仮説が間違っていた証拠ではありません。

単に母数が足りなかっただけ、という結末はとてもよくあります。

チームで合意を取るための、小さな仕組み

仮説検証がチームに根づくかどうかは、実は道具ではなく運用で決まります。重い仕組みを入れると、二週間で誰も更新しなくなる。

仮説カードは共有ドキュメント1枚にまとめ、週次のレビューでは進行中の3件だけを見ます。それ以上は読まれません。

見るポイントも固定してしまうと、会議が15分で終わるようになります。

• 反証条件に照らして、いまどちら側にいるか
• 判定に必要な件数まで、あと何日かかるか
• 途中で基準や対象をこっそり変えていないか
• 外れたとき、次に試す案が用意できているか

三つ目が地味に大事です。期間や対象を後から動かした時点で、その検証は結論を出せなくなります。

負けた仮説こそ、消さずに残してください。外れた仮説の一覧は、半年後にいちばん価値が出る資産になります。

同じ思いつきは、半年おきに何度でも会議に戻ってきます。そのとき、前回いつ試して何が起きたかを一行で出せるチームは強い。

結果は、3行だけ残す

長い報告書は書かれませんし、書かれても読まれません。仮説カードの下に、試したこと、起きたこと、次にすることの3行を足すだけで十分です。

この3行が溜まると、半年後に同じ議論が始まったときも、経緯を数十秒で共有できます。判断の速さは、こういう小さな記録の積み重ねで決まります。

意見が割れたときの、たった一つの質問

役員とPMの見立てが食い違う。よくある場面です。

このとき意見をぶつけ合っても平行線になります。代わりに、どんな数字が出たら考えを変えますかと互いに聞いてください。

答えられれば、それがそのまま検証の設計になります。答えられないなら、それは検証ではなく好みの話なので、決裁者が決めるべき事柄だと切り分けられます。

データは選択肢を絞ってくれますが、決めてはくれません。最後に決めるのは人だと最初に共有しておくと、無駄な数字探しが減ります。

この型が効かない場面も知っておく

仮説検証は万能ではありません。むしろ、使うべきでない場面を知っているほうが信用されます。

まず、直すべきだと分かりきっているものに検証はいりません。バグ、法令対応、明らかな表示崩れは、確かめずにすぐ直してください。

次に、新規事業のような大きな賭けです。既存データは既存プロダクトの延長線しか映さないので、そこには答えがありません。

この場合に必要なのは、数字ではなく回数です。小さく世に出して、驚きを含んだ反応が返ってくるかを見るしかありません。

データで決められない領域があると認めることも、仮説検証を運用する側の誠実さだと思います。

そして、いちばん静かに効いてくるのが局所最適です。小さな仮説を丁寧に積み上げると、細部は良くなるのに、事業の向きは一ミリも変わらないことがあります。

四半期に一度は、指標の外に出て問い直してください。そもそも私たちは、誰のどんな一日を良くしようとしているのか。

その問いに戻れるチームだけが、仮説検証を作業ではなく判断に使えます。