プロダクト開発における仮説検証プロセスで得た学び

GLOBIS 学び放題でプロダクトマネージャーをやっている神崎です。

昨年、私たちの開発チームにフリーランスのUXリサーチャーがジョインしてくれました。
それまでは、比較的小さい規模の仮説検証を行っていたのですが、リサーチの専門家が加わったことで、ユーザー体験を大きくアップデートするような仮説検証に取り組むことができました。

今回は、その大きな仮説検証プロセスで得られたことを学びとしてまとめたいと思います。

私たちの仮説検証プロセス

アジャイル開発における仮説検証には色々なやり方があると思いますが、今回は調査・分析に時間をかけ、以下のような流れになりました。
ちなみにここでは「実装のためのデザイン」や「実装」といったいわゆる「正しくつくる」開発フェーズについては詳しくふれません。

1. 問いを設定する
仮説検証の目的を設定し、前提を揃えるために情報を集める
・ユーザーや課題についてわかっていること、わかっていないことは？
・KPIは？

2. 検証可能な仮説にする
わからないことのうち、最もリスクが高いものは何か？を明らかにするために、現時点での仮説（ペルソナ、課題と提供価値、シナリオ）を「ユーザー体験定義書」としてまとめる

仮説なので、まだ粗い

3. 調査設計を行う
目的を「ユーザーのモデル化」と「課題仮説、提供価値仮説の検証」として
・ユーザー調査の設計を行う
・課題仮説と提供価値仮説を検証するための架空のエピソードをスライドで作成する

4. ユーザーをリクルーティングする
「ユーザー体験定義書」のペルソナに近い属性情報、行動データを持つユーザーをサービス内でリクルーティングする

5. 実査する
・前半：サービスの利用状況についてのヒアリング
・後半：課題仮説と提供価値仮説の検証
として、合計1時間の調査を10名のユーザーに対して行う

6. 分析する
・ヒアリングの結果から行動変数を洗い出し、マッピングする
・変数の偏りから特定のパターンを見つけ、偏りを集合体としてまとめる

②④⑤、⑥⑧⑨、①⑦ の偏りにパターンがありそう

・集合体の中での変数同士の繋がりを確認し、相関図を作成する
・相関図からユーザーのエンドゴール、それを達成するために何がしたいのか？のニーズを導き出す
・集合体をペルソナとしてまとめる
・課題仮説と提供価値仮説の検証結果から、それらを再定義する

7. メインペルソナを決定し、課題、提供価値を定義する
・出来上がった複数のペルソナからSEPIA法などによりメインペルソナを決定する

期待先行ユーザーをメインペルソナに決定

・分析結果をもとに、2. でつくった「ユーザー体験定義書」をアップデートする

8. アクティビティシナリオを作成する
「ユーザー体験定義書」で定義した提供価値をどうやって届けるか？のアクティビティシナリオを描き、9コマシナリオの形で表現する

9. ToBeカスタマージャーニーマップを作成する
アクティビティシナリオと9コマシナリオをもとに、今回のスコープ内のCJMを描きながらどんなUIがあったらいいか？のアイデアを創出する

CJMの理想の行動をサポートするアイデアを記載

10. アイデアを統合する
CJMからUIプロトタイプ、この機能でできること、想定利用シナリオを作成し、コンセプトシートとしてまとめる

11. コンセプトを検証する
・コンセプトシートを用いて、ユーザーに機能の魅力度、利用意向を評価してもらい、ヒアリングを行う

コンセプトシートの表紙

・検証結果をもとに、コンセプトを修正する

12. ユーザビリティを検証する
13. 機能要件をFIXする
14. 実装する

振り返ってみると結構なボリュームになってしまいました（汗）。
では、次に学びを振り返っていきたいと思います。

仮説検証プロセスを通しての学び

 ■「ユーザーのモデル化」と「課題仮説、提供価値仮説の検証」
（主に 3. 調査設計を行う、5. 実査する について）
「ユーザーを定義する → 課題や提供価値を検証する」というのが本来の流れだと思いますが、今回は時間の都合でそれらを同時に行うことにしました。
同時に行うといっても、それぞれの品質に妥協はしたくなく、UXリサーチャーと「ユーザー調査において何を優先的に聞かなければならないか」を議論して進め、結果的にインタビューガイドがめちゃくちゃボリューミーになりました（笑）。

実査自体はある程度やりきれたと思うのですが、得られた情報量がとても多く、その後の分析に時間がかかってしまいました。
今回は仕方なかったとはいえ、やはり調査の目的はフォーカスして進めたほうがよいと思います。

 ■開発メンバーの巻き込み
（主に 5. 実査する、6. 分析する について）
プロダクトマネージャーとして頭を悩ませた点です。
プロダクトのフェーズによっては、メンバー一丸となって仮説検証プロセスを回すことができるかもしれません。
しかし私たちの場合、大きな仮説検証プロセスを回しつつも、通常のスクラム開発も同時に行っていたのでリソースの割り振りに苦労しました。

メンバーには実査ではオブザーバーとして、分析では重要なワークには必ず参加してもらうことでスクラムタスクをこなしてもらいつつ、仮説検証からも取り残させないことを心がけました。

■アクティビティのみを描く
（主に 8. アクティビティシナリオを作成する について）
アクティビティシナリオはユーザーの一連の行動を描くもので、機能や操作を描くインタラクションシナリオとは区別されるものです。
しかし、UIイメージが頭にあるがゆえにどうしても仕様に踏み込んでしまい、一部のメンバーから「Howが決まり過ぎではないか？」という声も挙がっていました。

「どのような体験価値をつくるか？」をHowに依存しない形で表現できるようになるには場数を踏む必要があると感じます。

■探索フェーズの認識合わせ
（仮説検証プロセス全体を通じて）
上で書いた仮説検証の流れは、そのほとんどが「正しいものをつくる」ための、いわゆる探索フェーズに含まれるものです。
探索フェーズを丁寧に行ったことで想定以上に期間が長くなってしまい、開発フェーズで待ち受けているメンバーをヤキモキさせてしまったように思います。

本来は探索フェーズで起こっていることを可視化し「なぜ探索を重要視するのか」「現時点で何がわかっていて何がわかっていないか」「これからどんなプロセスを経て開発に至るのか」についてしっかり対話すべきだったと反省しています。
この点は、スクラムマスターが課題と捉えて「バリューストリームマッピングをやって認識を合わせよう！」という提案をしてくれました。感謝。

まとめ

今回、通常のスクラム開発では行わないぐらい「探索フェーズ」での深堀りを大事にしました。
また、人間中心設計の経験と実績が豊富なUXリサーチャーと一緒に調査を計画、実行できたことでチームの中に新たな知見が加わった手応えがあります。

私たちのチームでは探索フェーズと開発フェーズをシームレスに繋いだ、いわゆるデュアルトラックアジャイルと呼ばれる開発手法が1つの理想形なのではないか？と考えています。
苦労したことも多かったですが、仮説検証プロセスにおける探索を順序立てて進められたことは、今後より強いチームになっていくために価値ある取り組みだったと思います。

一緒に仮説検証に取り組んでくれる仲間を募集しています

グロービスのデジタル部門では、幅広い職種で人材を募集しています。
仮説検証に興味のある方、既にガシガシ仮説検証を回している方、仮説検証談義をしたい方、まずはカジュアル面談はいかがでしょうか？
ご希望の方はお気軽にこちらの採用URLまでどうぞ！
https://recruiting-tech.globis.co.jp/