投稿

はじめに

仮説検証学習サイクルを可視化するためのツールを「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 の目的です。一つ一つ潰すことで、安心感が得られるのも、いいところです。

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

はじめに

人の行動が変わる三つの要素というのを昔聞いたことがあります。

周囲にいる人、置かれている環境、金銭的な裕福さだったと思います。どれか一つでも変わると、人の行動には変化が見られるようになります。身近な例だと引越しや転職、宝くじの当選や昇給などが挙げられます。なぜ、この話を始めたのかというと、UX デザインやアジャイル開発の組織内導入に伴う課題の一つに、組織文化の醸成を最も多く耳にするからです。では、組織の文化を変えていくためには何が必要だろうと考えを巡らした結果、この三つの要素に行き着きました。そして、それはあながち間違いではないと思います。

「イノベーションを生むには、まずオープンでコラボレーションが自然と生まれるような環境が必要だ!」と叫ばれているのはわからなくもないです。しかし、それだけでは人は中々変わらないことを自分自身も経験してきました。オシャレであることはいいことです。でも、自己満足かどうかはすぐにわかったりします。組織または組織文化を変えるには、他の二つの要素も射程に入れなければ意味がありません。

ではどうす流べきでしょうか?

Culture Mapping というアプローチ

他社事例を元に直ぐに対策を練るのではなく、現状を知ることから先ずは始めなければなリマ線。文化とは何か?という哲学的な問いに明確な答えなどない気がしますが、少なくとも整理することはできます。ここで私が注目したのは、「Culture Mapping(カルチャー・マッピング)」というアプローチです。これが最もしっくりきました。

What is Culture Mapping and why should you care?

Depending on who you ask, 60-70 percent of change initiatives fail to meet their stated objectives, and the primary source of that failure, according to a Deloitte study, is resistance to change. So if you’re embarking on a change initiative, the last things you want to skimp on are risk-awareness and risk management.

カルチャー・マッピングは、「The Connected Company」という本で紹介されており、組織内のサイロ(縦割り)からの脱却を目的とした組織文化の統合について触れられています。読み応えがあるのでぜひ手にとって読んで見てください。和訳版は「コネクト ―企業と顧客が相互接続された未来の働き方」。

簡単に要約すると、カルチャー・マッピングは著者自身の経験から生まれたもので、買収等に伴う組織文化の統合を迫られた彼はトランスフォメーションの一環として目指すべき素子文化のマッピング作業から始めました。全ての会議室の壁にこれを張り出し、従業員の評価基準にも採用するなど徹底させた結果、文字通り、求める通りに組織の文化をデザインすることができたと述べられています。それが体系化されたツールが、このカルチャーマップ(PDF)というわけです。

上は、カルチャー・マップは各ステークホルダーの役割や体制を軸として項目ごとの関係図を可視化したもの。

Culture Map で定められている項目

定められている項目は以下の通り。

Evidence(証拠):従業員はどのような行動をしているか?

  • どのように業務に取り組んでいるか
  • どのような言語で会話しているか
  • どのように協業し、創造活動が行われているか
  • どのような空間、環境で行われているか

Levers(手段):行動を規程するルール(公式/非公式)にはどのようなものか?

  • 何がどのようにコントロールされているか
  • どのように意思決定をしているか
  • どのように人的資源を配分しているか
  • どのように賞賛しているか
  • 意図的なルールや環境はどのように定めているか

Values(価値):企業が提供する価値はどのようなものか?

定義している価値

  • みんなが口を揃えて言う、定義されている価値はなにか
  • 公式な文書やステートメントとしてどのようにまとめられているか

実践している価値

  • 上記の証拠や手段によって影響を受ける因子はなにか
  • 個々の実践によってどのような価値を提供しているか

Assumptions(仮説):想定されている仮説はどのようなものか?

  • 上記に記載の価値はなぜ、我々に成功をもたらしてくれるのか
  • 同じく、市場での有利性をどのように担保してくれるのか

チェックリストのように位置付けると、これらの項目は非常に合理的だと思います。冒頭でも記述した、周囲にいる人、置かれている環境、金銭的な裕福さが含まれていることがわかります。よって、カルチャーマップに定められている項目は、ここに挙げた脅威のディテールや事実を定義するものとして活用できる、効果が期待できるツールなのではないでしょうか。

余談ですが、過去に自身で企画をして、案件をプロジェクト化したことがありました。他とは独立した文化を持つチームを編成して進めていたことがあります。個人的にはチームとプロダクトが共にサクセスだったと自負しているのですが、工夫した点を上記項目に当てはめた場合、こんな感じでした:

  • 必要予算の打診と確保(ROI算出)
  • プロセスと利用ツールの整備
  • チームへの権限委託(チームのみで意思決定可能な範囲の確認)
  • チームとしての共通稼働時間の整理
  • 提供価値の言語化と更新
  • マーケットからの継続的なフィードバック方法の確立(ユーザーインタビューを定例で設けるなど)

新規であったため、これが時の流れと共にどのように文化が醸成されて変異していったのかはモニタリングしなければわかリませんでした。必要であれば、文化を変えることも可能であったと思います。とはいえ、このようなツールがある、ないとでは差が出てくると思われます。

まとめ

文化は魚に例えると水のような存在であり、文化をデザインするということは、水を取り替え、一つの群れでどのように一緒に泳いでいくべきかを考えることです。群れの中でどのように協業し、どのようにリスク回避すべきかを考えることです。スタートアップなど新しい水槽(組織)を構築するフェーズにおいては比較的より組みやすい環境かもしれませんが、組織規模が比較的大きい水族館のような組織では記述した脅威によって滞りがちです。変化が求められているのであれば、先ずは文化のダイナミクスについて理解を示すべきだと思います。そのためには、このようなツールを上手く利用して、可視化から始めるといいかもしれません。

“The stronger the culture, the less corporate process a company needs. When the culture is strong, you can trust everyone to do the right thing. People can be independent and autonomous. They can be entrepreneurial.” – Don’t Fuck Up the Culture

文化が組織に深く根付いていればいるほど、組織はプロセス依存ではなくなります。根が深ければ深いほど社内の信頼は構築されていき、自主的かつ独立した取り組みが個人レベルによって行われるようになります。