「ユーザーに聞く」ことから始める、小さくても成果へつなげる仮説検証

サービスやそれに付随するツールの改善には「仮説検証が必要」とはよく言われるものの、費用対効果に欠けるのではないかという疑問や、どのように検証すればいいかわからないという課題をもつ企業や部署は多いのではないでしょうか。
今回、ギルドワークスが支援した、国内最大級のインターネット通販事業者にてECコンサルティング業務関連のツールを開発している部署でも、同様の悩みを抱えていました。
ECコンサルタントのスムーズなショップ運営のサポートや、売上向上の支援を行うには、ただECコンサルタントが業務に利用しているツールの機能を強化したり見た目を変えるだけでは効果がありません。
そこで、「課題と解決策の見つけかた」そのものを知るために、ギルドワークスに仮説検証をワークショップ形式で実施してもらえないかとの打診がありました。

ご担当者よりコメント
個々のプロジェクトでは、Jeff Patton氏のProduct Discovery手法を使ったりしていましたが、組織横断的な大きめなプロジェクトを行うことになった時に、「えーっと、俺らって何やろうとしてたんだっけ…？」となってしまうことがあり、困っておりました。
そんな時に、ギルドワークスの仮説検証のとりくみを知り、お声がけさせていただいた次第です。プロの第三者のファシリテートを味わいたいという意図もありました。

仮説の見立てとプロトタイプによるソリューション検証

ギルドワークスはまず、開発チームマネージャーに事前にヒアリングを行い、現在の状況と改善の目的から「ECコンサルタントが通常の業務で使用しているツールの改善」にテーマを絞りました。
このワークショップは、簡易的ながら、ギルドワークスが「価値探索」として提供している仮説検証プロセスのエッセンスを凝縮したものとなりました。

ワークショップのプログラム

1. 仮説キャンバス作成 – コンセプトを練る
2. サービスブループリント – プロセスを俯瞰する
3. Crazy8sでアイデア出し – 課題の解決策を提案する
4. プロトタイプ作成 – ソリューションのアウトプット
5. インタビュー実施 – 仮説を確かめる

「仮説キャンバス」によってコンセプトを練る

仮説を見立てるためのフレームワークとして「仮説キャンバス」を用いました。これは、ビジョンや目的、課題といった13の観点から、企画やアイデアの確からしさを見定めていくもので、ギルドワークスが独自に考案、ブラッシュアップしているツールです。
ホワイトボードにブロックのひとつひとつを記載していきました。ここで見立てられたビジョンや仮説への納得感は非常に高く、その要因のひとつとして、ギルドワークスのファシリテーションによって、フラットな会話ができたこともあったようです。

「サービスブループリント」によるユーザーストーリーの洗い出し

サービスを利用するときに、ユーザーがどのような感情をもとに行動しているのか、サービスとのタッチポイントはどこか、それに対してサービスのシステムとしての反応を「サービスブループリント」によって明らかにしました。
ユーザーの「気持ち」「行動」「手に残るもの」、サービスとの「タッチポイント」と「機能」をカードに書いて模造紙に張り出し、全体を俯瞰します。
このように時系列でユーザープロセスの全体像を明らかにする手法には「カスタマージャーニーマップ」などがありますが、今回のテーマの場合、ユーザーだけでなく、ユーザーに対するシステム（機能）についても同時に検討する必要があると考えられたため、システムも含めた全体を可視化できるサービスブループリントを採用しました。

サービスブループリントによって、現状のサービス利用シーンが時系列に整理され、課題をピックアップすることができました。ここで明らかになったのは、ECコンサルタントの業務フローが想定と異なっており、それが仮説へ大きな影響を与えているということでした。このあとのソリューションインタビューでもこの部分は明確になります。より実利用に即したソリューションを見立てるためには、ECコンサルタントの業務フローそのものを深掘りし、また、ECコンサルタントと開発チームが会話し、すり合わせる必要があるということが見えてきたのです。
仮説検証プロセスを実施することは、このように気づきがあったときにユーザーストーリーを見直したり、仮説キャンバスに立ち戻ったりでき、より最適なソリューションに近づくことができることにも意義があります。

課題を解決するアイデア出し

サービスブループリントでピックアップされた課題に対して、「クレイジーエイト（Crazy8s）」という手法を用いて、アイデア抽出の個人ワークを行いました。
これは、A4用紙を8等分に折り、その升目に解決のためのアイデアを書いていくというものです。参加メンバーにはそれぞれ8個ずつアイデアを出してもらい、すべてを並べて、有効と思われるアイデアにシールを貼っていく「ドット投票」を行いました。この結果、20分ほどで良質なアイデアが生成できました。

プロトタイプ＆インタビュースクリプト作成

採用されたアイデアを元に、プロトタイプを作成しました。実利用者に近しいユーザーに見せたり使ってもらったりすることで、実際の課題は何か、その課題に対してこのソリューションが合っているのかを検証するためのものです。今回はワークショップに絵を描けるメンバーがいたため、紙に画面イメージを起こすことで、プロトタイプとしました。
同時に、インタビュー時のヒアリング内容をテキスト化したインタビュースクリプトも作成しました。インタビュースクリプトを初めから起こすのは時間がかかるため、ギルドワークスが実際の業務で利用しているスクリプトをベースにしました。ソリューションが合っているかだけでなく、「このソリューションに対してお金をいくら払うか」という切実さ・本気度確認の仕方など、ノウハウの活きたスクリプトが参加メンバーの刺激になったようです。

ソリューションインタビュー

実利用者の代替ユーザーを2名招き、インタビューを実施しました。短時間で作成したプロトタイプながら、十分にソリューションが伝わっていました。
プロトタイピングツールなどを用いた実際のアプリやソフトウェアの画面に近しいプロトタイプより、短時間でラフに作ったものでも、「仮説を確かめる」ことが目的だった今回のワークショップではふさわしいものでした。インタビューの内容、検証目的や場面に応じて、プロトタイプの作りこみのレベルを検討する必要があります。

最後に、ソリューションインタビューの結果をふまえ、課題がきちんと見つけられたか、今回の成果を次に活かせるかなどをふりかえるまとめの時間をとり、約5時間のワークショップは終了しました。

「ユーザーに聞くこと」の重要性

今回のワークショップでは、代替ユーザーながら、「実際にツールを利用する人」にインタビューすることが重要でした。ただ、ワークショップのプロセスでまずはじめに仮説キャンバスで仮説とビジョンを見立て、サービスブループリントで実利用シーンで想定されていなかった部分があることに気づき、さらに仮説を見直したというインタビューに至るまでのプロセスを通さずには「実利用ユーザーと乖離している」ことの確証は得られなかったと考えます。
また、仮説検証プロセスを通さないままに、この「乖離」に気づかず開発してしまった結果、使われないものができてしまうということは、よく聞かれるのではないでしょうか。
今回のような小さな仮説検証であっても、実施するメリットが十分にあることがわかりました。

開発チームでは、このワークショップで生まれたアイデアを元にしたツールをリリースしました。利用者からは、好評を得ているとのことです。

ワークショップを担当して

担当：佐々木 将之
ギルドワークスで実践している仮説検証のエッセンスを抽出する形で、約半日のワークショップとして実施しました。比較的短時間でも、仮説の検証が進められることがわかり、今後の業務にも活かせそうだというコメントをいただきました。
また、模擬ワークではなく、実際に困っていることのテーマでの実施だったため、本気になって取り組んでいただき、ワークショップ終了後も議論がふくらみました。