実験をするのはなぜか？

はじめに

組織に属する人にとって、「実験」をすることは勇気がいるものです。私の見立てによると、プロダクトの責務や説明責任を担っている人のおよそ70％が、実験によって仮説を検証することに消極的です。このように躊躇をしてしまう理由はいくつかあります。最も多いのは、アジャイルな実験の意味を誤解していることです。次に多いのは実験の結果がネガティブなものだったからです。私はいつも、「このような結果になってもいいじゃないですか」と答えています。誰も望んでいない、あるいはユーザーの期待に答えられないソリューションを開発する必要がなくなるからです。

ユーザーと顧客

実験の本質を理解するためには、まずユーザーを知ることが大切です。興味深いことに、未だにスクラムチームの大半は、ユーザについてよく知らなかったり、何も知らなかったりします。

「プロトペルソナ」の適用と検証を推奨しています。以下について問いかけてみることです：

1. 我々のユーザー／顧客は誰なのか？
2. 我々のユーザー／顧客のどんな問題を解決しようとしているのか？彼らは何を必要としているのか？
3. 我々のユーザー／顧客にとって、どのような成果（アウトカム）になるのか？
4. 我々のプロダクトにどのような影響を与えるのか？

アウトプットではなく、アウトカム（成果）

アウトカムとアウトプットを区別する必要があるのです。「アウトプット」とは、ユーザー機能やソリューションの数や、バグ、ストーリーポイントのような活動の結果です。これらの指標は、提供した価値を示すものではないのです。組織は、主にアウトプットを計測している傾向があります。少なくとも開発部門（デリバリー部門）においては。

「アウトカム」とは、ユーザー／顧客の振る舞いにおける計測可能な変化のことです。これらはアウトプットの結果です。アウトカムの例としては、「コンバージョン」、「チャーン」、「プロダクト使用率」、「顧客使用率」、「顧客／ユーザーの満足度」などが挙げられます。

価値を計測する

アウトカムは、価値の計測と関係があります。価値を計測せずに、実際にアウトカム（成果）をもたらしていることをどうやって知ることができるのでしょうか？提供する価値や望ましいアウトカムを計測するための最も有用なフレームワークは、エビデンスベースドマネジメント（Evidence-Based Management）です。このフレームワークでは、4つの異なる側面である「重要価値領域（KVA: Key Value Areas）」によって価値を計測する機会を提供しています。詳細は、Scrum.org や筆者のウェブサイトをご覧ください。

訳註:『エビデンスベースドマネジメントガイド』を翻訳し、Scrum.org に提供しました。日本語版も無料でダウンロードできます。詳しくは こちら をご覧ください。

実験を行う

「なぜ実験をするのか？」という問いに対する最も短めな回答は、「仮説を検証するため」になります。繰り返しになりますが、多くの組織は、顧客／ユーザーの使用率や、彼らの問題の解決、満たすべきニーズについて、根拠（エビデンス）の欠片もない仮説を設けています。私たちは、自分たちが提案したユーザー昨日、サービス、ソリューション、プロダクトが機能することを前提としてしまっています。他の企業、特に価値を計測していない企業では、顧客／ユーザーのニーズについての会話すらないのです。価値を計測することができていないのです。これは悪循環になります。

頻繁な「検査と適応」を奨励しているアジャイルマインドセットを広めることが第一歩になります。実験の必要性を理解するのに役に立つでしょう。「スクラムチームが実験を行うことが許されるために、ビジネスやプロダクトの担当者をどのように説得したらいいのか？」とよく質問を受けます。以下の質問／発言を参考にしてください：

1. このソリューションが顧客に価値をもたらすかどうかをどうやって知ることができますか？（答えが漠然としている場合は、次へ）
2. 我々が言っている「実験」とは、短くて低コストなものです。検証のためのいくつものスプリントが必要ではないのです。短くて低コストな実験の例を共有しましょう: フェイクフィーチャー、プロトタイプ（紙／デジタル）、オブザーベーション、ユーザーインタビュー、ランディングページなどです。
3. 見積もってみましょう。短い実験とは、数時間単位です。数ヶ月ではありません。

4. 仮説を書いてみましょう。その仮説をビジネス上の問題点、期待される成果（アウトカム）、ユーザーの得る恩恵、計測方法などと組み合わせてみます。
5. 実験の結果がネガティブなものであったら？これは素晴らしい情報です。価値のないものを提供するために、3ヶ月（※みなさんの試算した数値に置き換えてください）もの期間、人々の労力、会社の資金を費やす必要がなくなるのです。
6. 実験の対象は誰になりますか？理想的には、実際のユーザー／顧客です。直接彼らにアクセスできない場合は、あなたの周りにいるユーザー（または、ソリューションの潜在的なユーザー）で、あなたのペルソナと一致する人を探してみてください。プロダクトのデリバリーに関与していない同僚に聞いてみるのもいいでしょう。

次のステップは、「実験をデザインすること」です。いくつかの Lean UX のプラクティスを組み合わせるとよいでしょう。例えば、「インタビュー + オブザーベーション + プロトタイプ」です。Lean UX については、こちら に有益な情報があります。

訳註:『Lean UX』は、邦訳版があります。

理想的には、UX担当者がこのプロセスに参加するとよいでしょう。スクラムを行なっている場合は、UX担当者はスクラムチームの一員であるべきです。スクラムチーム全体として実験を行うこともあります。

まとめ

数時間から数日をかけて、実際のユーザーを対象とした仮説の検証を行い、自分たちのソリューションが正しいか、間違っているかを実証することに価値があるのです。検証を行わずにソリューション全体を提供することは、コストがかかり、不必要なリスクを伴うことになるのです。アウトプットではなく、アウトカムで考えるようにしましょう。チーム全体を巻き込んで実験を行いましょう。エビデンスベースドマネジメントで価値を計測し、事実に基づいて意思決定を行うようにしましょう。

スクラムと実験について、体験し、もっと知りたいという方は、「Professional Scrum with UX」の研修クラスがお勧めです。

訳註: この記事のトピックについての認定資格があるのでそれらにチャレンジすることもおすすめです。
「Professional Agile Leadership Evidence-Based Management」
「Professional Scrum with UX」