はじめに

仮説検証学習サイクルを可視化するためのツールを「Experiment Board」と呼んでいます。2年ほど試行錯誤を重ねましたが、今は納得して運用することができているので、世のプロダクト開発をよりよくするためにも、参考になるかわかりませんが公開したいと思います。

なぜ、この Experiment Board が必要だと思ったのかと言うと、過去にこんな悩みがあったことがきっかけでした:

  • ユーザーリサーチの際に、過去の質問や検証内容と重複してしまうことがあって、時間の無駄だと思った
  • どこまでが未検証で、どこまでが検証済みだったかわからず、迷走することがあった
  • 価値ある学びやインサイトが多くあった場合に、まとめて管理したり記録する方法がわからなかった
  • 仮説検証学習のために実験を繰り返す習慣を身につけたかった

これらのモヤモヤを解消してくれたのが、Experiment Board でした。根底にあるのは、リーンスタートアップの「Build-Measure-Learn」のフィードバックループです。

Learn:思い込みや仮説、Build:実験、Measure:検証可能な指標

この図の通り、実験(Experiment)を通しての仮説検証の結果から得られる学びを切り取り、形式化することが鍵となります。

なぜ、実験なのか?

上記で「実験」という言葉を使いました。科学のように、仮説を検証するために積み重ねる実験は、正にプロダクト開発においても同じだなと思います。なので、仮説検証学習サイクル=実験と呼んでいます。

なぜ実験が必要かというと、プロダクトを開発する上で最も高いリスク、それはユーザーに使われないものを作ってしまうリスクを可能な限りなくすためです。リスクを低減するためには、早期に「いま」検討中ないしは開発中のプロダクトを試すことが重要であり、同時にその行程を管理し、修正していくことです。

あと、「リリースをする」という表現よりも「実験をする」と言い換えたほうが目的が明確で、意思決定のスピードや検証サイクルも早くなる気がします。心理的構えもなくなるので、安定します。

なにを、検証するのか?

左が課題の優先順位付を行う「2×2」、右が Experiment Board です

実験をはじめる前に、答えるべき問いを設定します。この問いに対する解を得るために、実験をします。問いは多きく分けて2つのカテゴリに分類することができます。

  1. ユーザー&課題
  2. プロダクト&ソリューション

(1)については、

  • 実際にユーザーは存在するか?
  • 解決「すべき」課題か?

などが代表例です。これらの問いに対する解を見出すことができれば(2)に進みます。

  • ソリューションは課題を解決するか?
  • 使いやすいか?

などが代表例です。これらの問いを検証可能な仮説に落とし込んで実験することで、以降はより詳細な仮説検証学習サイクルに進むことができます。仮説の設定方法については過去のエントリーが参考になると思います。

仮説駆動型UXデザインのススメ | mariosakata.com

先月末に NIJIBOX 主催のイベント …

どのような、流れで行うか?

プロダクト開発手法に左右すると思いますが、私が慣れ親しんでいるアジャイル開発では、イテレーションごとに以下の流れで実験を行っています。

イテレーションごとの流れ:

  1. 問いの設定
    ユーザー&課題について?プロダクト&ソリューションについて?
  2. アサンプションを洗い出す
    最もリスクが高い思い込みは何か?
  3. 仮説化する
    検証可能な仮説にする
  4. 実験方法を考える
    何を検証するためにやるのか?どのようにやるのか?
    例)ペーパープロトタイプ、ABテスト、ランディングページ、インタビューなど
  5. 実験する、試してみる
    どれくらいの期間やるのか?何人に対してやるのか?
  6. 結果を測る
    仮説は検証できたか、間違っていたか?
  7. 振り返って学びをシンセサイズ(統合)する
    何を学んだか?
  8. 繰り返す

実験は繰り返すものです。次に何を検証しようと悩んだ時には、以前ご紹介した「2×2」というフレームワークを取り入れてみるといいかもしれません。

2軸で考えるプロダクトデザインの シンプルな意思決定方法

9月上旬に、 UX MILK 主催の「 UX MILK Fest 2019」という大きなイベントに登壇させていただく機会がありました。「2軸で考えるプロダクトデザインのシンプルな意思決定方法」と題した当日のセッションでは 「2x2」という手法をご紹介しました。セッションでお伝えしたかったのは、この手法を取り入れることで、様々な角度から軸となる考え方を UX …

Experiment Board の例

先ずは準備です。実験を進めるための必要項目を記載していきます:

  • フェーズ(実験の回数やプロダクトのライフサイクルなど)
  • ペルソナ
  • 期待する成果(アウトカム)
  • 検証したい仮説
  • 実験方法
  • 成果指標(Key Result)
  • 学び

Google が主催したイベントに登壇した際にも紹介した、Experiment Board の事例です。ちなみにこれは、実際に Zappos が実践した実験そのものです。多少編集しています。

  • フェーズ:Beta
  • ペルソナ:レイシーさん
  • 期待する成果:ユーザーはいつでもどこでも靴を買うことが出来る
  • 検証したい仮説:ユーザーはオンラインで靴を買いたいだろう
  • 実験方法:オズの魔法使い
  • 成果指標(Key Result):50%のユーザーは一足以上の靴を買う
  • 学び:女性はドレスにあう靴をオンラインで購入する傾向にある

仮説があっていたかどうか、また指標が達成できたかどうかをステッカーを使って管理してたりします。赤はアラートなので、やり直す必要があるのか、そもそも辞めるか、といった決断をする材料となります。

Experiment Board の導入によって、いつ、誰に対して、何のために、そしてどのような実験をするのか?そして、その結果はどうだったか?この一連の問いをこの順番で可視化することで、論理的に物事を考えることができ、情報の整理が容易になりました。

仮説検証学習サイクルも回り続けます。

上記が一応テンプレートのような役割を果たしていますが、ホワイトボードに縦に貼り付け、その横に実験ごとの結果を記録していくだけでも済みます。実験の回数が多くなってきたら、エクセルでもいいので、デジタルに移行することをオススメします!

まとめ:やってみてよかったこと

インサイトや学びの抽出がしやすくなった

可視化のメリットはやはり大きいです。特に、今回ご紹介したようにホワイトボードなどを用いることができれば、何が検証できて、何が間違っていたのか、どのような学びがあったのかを項目ごとにすぐに確認することができるので、取りこぼしが減ったように思います。

次のアクションに繋げやすくなった

学びはチームを前進させてくれます。普段であれば、見ていないところや諦めているところをすくい上げて、新しい価値を見出すこともできます。他にも、ターゲットユーザーのアップデートであったり、課題の優先度の変更といった本質的な議論が展開されるようになります。それは、中長期的に見るととても有益な情報だったりします。

過去の実験がまとまっていることで自信がつく

プロダクト開発では、生産性に直結するアウトプットに注目することが多いです。でも、Experiment Board のようにこれまで実験した回数であったり学びの数が可視化されていると、それだけ良いプロダクトに向けて突き進んでいることがわかり、一人一人の自信につながり、チームの士気も上がります。このような質的なイニシアティブが得られることも、メリットの一つです。

早い段階でいくつかの仮説や思い込みが間違っていたことがわかる

最もリスクが高い思い込みを優先して検証可能な仮説に思い込み、実験によって検証することで、それがあっていたか間違っていたかを測ることが Experiment Board の目的です。一つ一つ潰すことで、安心感が得られるのも、いいところです。

全ては、実験です。このフレームワークの導入も、実験です。導入コストは圧倒的に低いので、ぜひやってみてください!

プロダクト開発に携わっている人であれば、MVP という単語を一度は耳にしたことがあるかもしれません。これは最優秀選手を表彰するときの名称ではなく、起業家であるエリック・リース氏が彼の著書『リーンスタートアップ』で紹介したコンセプトです。本が出版されてから8年も経っていますが(いま調べて驚き)、MVP という言葉だけが一人歩きし、誤った理解や解釈がそのままに、現在に至ってしまっているように思います。その理由は後ほど。

問題は、MVP の訳し方にあったと考えます。MVP は Minimum Viable Product の頭文字をとったもので、Wikipedia で以下のように訳されています。

実用最小限の製品(じつようさいしょうげんのせいひん、Minimum Viable Product、MVP)は、初期の顧客を満足させ、将来の製品開発に役立つ有効なフィードバックや実証を得られる機能を備えた製品のバージョンを指す。

別の言語のニュアンスを細かく汲み取って、万人が理解できるように意訳することは中々難しい。私の場合も『Lean UX』という書籍の監訳を担当させていただいてもう数年が経しますが、どうしても「最小限」という単語が印象的なのか、組織にとって都合がいい言葉なのかわからないが、「最小限の機能を搭載した製品」のことを指す言葉として使われることが多いです。

このようなシーンを目の前にしたことがあります。

新規サービスを立ち上げることになりました。開発したい機能リストがエクセルにまとめられていて、その中でも優先順位が高いものには「高」というラベルが書かれています。それも、約3分の1が「高」だったりします。最悪なケースは、機能価値が未検証のままで、優先度が都合よく割り振られているときです。根拠がないとなると、更にヤバイ。この「高」に分類されているのが、MVP だと言い張る人がいます。そもそも「中」とかあると、曖昧すぎてよくわかりません。

MVP の V を「実用的な、実行可能な」として直訳することができますが、これはサービス提供者視点ではなく、ユーザー視点に立ってみると、捉え方が変わってきます。誰にとっての最小限なのでしょうか?機能的な最小限を意識しすぎてしまうと、何の価値もない出来の悪いプロダクトになってしまうことがあります。ああ、だから新しい手法を取り入れると失敗するんだよ。このようになってしまいます。ポイントはユーザーの立場から見た場合の実用的なプロダクトとはなにか、を考えてみることです。

実用的、という言葉が意味するところを説明するのは大変難しい。そのため、私はよくこの絵を見せて関係者の理解を得ようとしています。

 

元々は米コンサルティング会社に勤めているアジャイルコーチがブログで紹介した図から来ています。この人は MVP を正しく理解するために Viable を Usable / Loveable と置き換えていることが素敵です。

このユーザーは、いまいる地点から目的地まで移動するまでにかなりの時間がかかってしまっています。不便ですね。MVP を最小限の機能と認識し、機能単位でプロダクト開発を進めていくと、最小限の線引きが時間の経過とともにわからなくなり、実用性を高めるためにはつくりきるしかなかったりします。それが上段です。

一方で、下の段のスケートボードはユーザーが抱える問題への最初のアプローチとして、ユーザーがそのプロダクトに価値を見出してくれているかどうか、日常生活において実用的かという観点で検証をすることができます。まだまだ満足ではないかもしれませんが、ユーザーが価値を見出せて課題の解決に至りそうなのであれば、移動時間を短縮するための次のアイディアにステップアップすることができます。

MVP には目的があります。リーンスタートアップという開発手法の一部なのだから、一人歩きは危険です。最小限の機能は作れた。MVP は完成だ。これで一区切り、なんて終わり方はしてはいけません。もしそうなっていたら、誰にとっての最小限であって、誰が喜ぶ MVP なのか、を再確認したほうがいいかもしれません。