仮説検証学習サイクルを可視化するツール「Experiment Board」
はじめに
仮説検証学習サイクルを可視化するためのツールを 「Experiment Board」 と呼んでいます。2年ほど試行錯誤を重ねましたが、今は納得して運用することができているので、世のプロダクト開発をよりよくするためにも、参考になるかわかりませんが公開したいと思います。
なぜ、この Experiment Board が必要だと思ったのかと言うと、過去にこんな悩みがあったことがきっかけでした：
- ユーザーリサーチの際に、過去の質問や検証内容と重複してしまうことがあって、時間の無駄だと思った
- どこまでが未検証で、どこまでが検証済みだったかわからず、迷走することがあった
- 価値ある学びやインサイトが多くあった場合に、まとめて管理したり記録する方法がわからなかった
- 仮説検証学習のために実験を繰り返す習慣を身につけたかった
これらのモヤモヤを解消してくれたのが、Experiment Board でした。 根底にあるのは、リーンスタートアップの「Build-Measure-Learn」のフィードバックループです。
この図の通り、実験（Experiment）を通しての仮説検証の結果から得られる学びを切り取り、形式化することが鍵となります。
なぜ、実験なのか？
上記で「実験」という言葉を使いました。科学のように、仮説を検証するために積み重ねる実験は、正にプロダクト開発においても同じだなと思います。なので、 仮説検証学習サイクル＝実験 と呼んでいます。
なぜ実験が必要かというと、プロダクトを開発する上で最も高いリスク、それはユーザーに使われないものを作ってしまうリスクを可能な限りなくすためです。リスクを低減するためには、早期に「いま」検討中ないしは開発中のプロダクトを試すことが重要であり、同時にその行程を管理し、修正していくことです。
あと、「リリースをする」という表現よりも「実験をする」と言い換えたほうが目的が明確で、意思決定のスピードや検証サイクルも早くなる気がします。心理的構えもなくなるので、安定します。
なにを、検証するのか？
実験をはじめる前に、答えるべき問いを設定します。この問いに対する解を得るために、実験をします。問いは多きく分けて2つのカテゴリに分類することができます。
- ユーザー＆課題
- プロダクト＆ソリューション
（１）については、
- 実際にユーザーは存在するか？
- 解決「すべき」課題か？
などが代表例です。これらの問いに対する解を見出すことができれば（２）に進みます。
- ソリューションは課題を解決するか？
- 使いやすいか？
などが代表例です。これらの問いを検証可能な仮説に落とし込んで実験することで、以降はより詳細な仮説検証学習サイクルに進むことができます。どのような、流れで行うか？
プロダクト開発手法に左右すると思いますが、私が慣れ親しんでいるアジャイル開発では、イテレーションごとに以下の流れで実験を行っています。
イテレーションごとの流れ：
- 問いの設定
ユーザー＆課題について？プロダクト＆ソリューションについて？ - アサンプションを洗い出す
最もリスクが高い思い込みは何か？ - 仮説化する
検証可能な仮説にする - 実験方法を考える
何を検証するためにやるのか？どのようにやるのか？
例）ペーパープロトタイプ、ABテスト、ランディングページ、インタビューなど - 実験する、試してみる
どれくらいの期間やるのか？何人に対してやるのか？ - 結果を測る
仮説は検証できたか、間違っていたか？ - 振り返って学びをシンセサイズ（統合）する
何を学んだか？ - 繰り返す
実験は繰り返すものです。次に何を検証しようと悩んだ時には、「2×2」というフレームワーク を取り入れてみるといいかもしれません。
Experiment Board の例
先ずは準備です。実験を進めるための必要項目を記載していきます：
Google が主催したイベントに登壇した際にも紹介した、Experiment Board の事例です。ちなみにこれは、実際に Zapposが実践した実験そのものです。多少編集しています。
- フェーズ：Beta
- ペルソナ：レイシーさん
- 期待する成果：ユーザーはいつでもどこでも靴を買うことが出来る
- 検証したい仮説：ユーザーはオンラインで靴を買いたいだろう
- 実験方法：オズの魔法使い
- 成果指標（Key Result）：50%のユーザーは一足以上の靴を買う
- 学び：女性はドレスにあう靴をオンラインで購入する傾向にある
仮説があっていたかどうか、また指標が達成できたかどうかをステッカーを使って管理してたりします。赤はアラートなので、やり直す必要があるのか、そもそも辞めるか、といった決断をする材料となります。
Experiment Board の導入によって、 いつ、誰に対して、何のために、そしてどのような実験をするのか？そして、その結果はどうだったか？この一連の問いをこの順番で可視化する ことで、論理的に物事を考えることができ、情報の整理が容易になりました。
仮説検証学習サイクルも回り続けます。
上記が一応テンプレートのような役割を果たしていますが、ホワイトボードに縦に貼り付け、その横に実験ごとの結果を記録していくだけでも済みます。実験の回数が多くなってきたら、エクセルでもいいので、デジタルに移行することをオススメします！
まとめ：やってみてよかったこと
インサイトや学びの抽出がしやすくなった
可視化のメリットはやはり大きいです。特に、今回ご紹介したようにホワイトボードなどを用いることができれば、何が検証できて、何が間違っていたのか、どのような学びがあったのかを項目ごとにすぐに確認することができるので、取りこぼしが減ったように思います。
次のアクションに繋げやすくなった
学びはチームを前進させてくれます。 普段であれば、見ていないところや諦めているところをすくい上げて、新しい価値を見出すこともできます。 他にも、ターゲットユーザーのアップデートであったり、課題の優先度の変更といった本質的な議論が展開されるようになります。それは、中長期的に見るととても有益な情報だったりします。
過去の実験がまとまっていることで自信がつく
プロダクト開発では、生産性に直結するアウトプットに注目することが多いです。でも、Experiment Board のようにこれまで実験した回数であったり学びの数が可視化されていると、それだけ良いプロダクトに向けて突き進んでいることがわかり、 一人一人の自信につながり、チームの士気も上がります。 このような質的なイニシアティブが得られることも、メリットの一つです。
早い段階でいくつかの仮説や思い込みが間違っていたことがわかる
最もリスクが高い思い込みを優先して検証可能な仮説に思い込み、実験によって検証することで、それがあっていたか間違っていたかを測ることが Experiment Board の目的です。一つ一つ潰すことで、安心感が得られるのも、いいところです。
全ては、実験です。このフレームワークの導入も、実験です。導入コストは圧倒的に低いので、ぜひやってみてください！
Originally published at https://mariosakata.com on June 28, 2020.
