日別アーカイブ: 1月 21, 2020

Builder’s Playbook – Identifying the Problem Pt. 2

/ kosuket / 1件のコメント

さて、今日も無事投稿遅めですが 笑
今回も前回に引き続き、Product Development Cycleの一番初めのステップについて書いていこうと思います。前回はデータ分析による定量的な部分にフォーカスしたので、今回は定性的な部分にフォーカスして書いてみたいと思います。
個人的には、定性的な部分の方が学びが多かったので、前回のログに比べると若干こちらの方が書きたかったトピックだったりします 笑

PM Responsibility Recap

前回同様、PMの職務領域のおさらいをしておくと

  • 顧客や会社の抱える問題が何か突き止める
  • 顧客や会社の抱える問題はどうやって解決されるのが最適か突き止める
  • 定義された解決策が実際にその問題を解決することを確かめるために必要な最小限のProduct(MVP)と、MVPから理想のProductに発展させるためのロードマップを定義する
  • エンジニアのチームによるMVPの実装を意思決定面からサポートする(実装時にわかった障壁をどう克服するか)
  • アナリティクスのチームによるMVPの実験/検証計画の策定の意思決定面からサポートする
  • 実験結果とInsightをチームに共有し、それらに基づき次のステップを定義する
  • マーケティングチームによるGo To Market Strategyの策定をサポートする
  • 実験からの学びに基づいたPivotを含め、Product Roadmapを次に進める

でした。
このうち今回のトピックは

  • 顧客や会社の抱える問題が何か突き止める
  • 顧客や会社の抱える問題はどうやって解決されるのが最適か突き止める

に使われる定性的な手法、User Experience Research (UXリサーチ)について書いていこうと思います。

What is UX Research?

UXリサーチは、UX(User Experience＝顧客体験)をデザインするプロセスに文脈/背景やInsightを得るために体系的に行う、ユーザーやそのプロセス、ペインポイントの調査である。

(多少意訳してますが、出典: Institution Design Foundation)

Double Diamond

UXについて初めて学ぶ際にほぼ確実に出会うのが、Double Diamondです。
Double Diamondは簡単に言うとUXの観点から見た、Product Development Cycleを簡易的に図式化したものです。オフィシャルな情報の出どころはDesign Councilという機関っぽいのですが、簡単にお絵かきして、解説してみると以下のような感じになります。

Double Diamond

UX的にはProduct Developmentを大きく、Discover (発見)、Define (定義)、Develop (開発)、Deliver (世に出す)の4つのフェイズに分けて、各フェイズがExplore (模索)とNarrow Down (絞り込み)のどちらに属するかを説明しています。

Product Development時のメンタリティとして、

  1. 問題の発見段階では心や頭にリミッターをかけずに多くの可能性を幅広く模索する
  2. 問題定義の段階では発見で模索した可能性を吟味してフォーカスすべき分野を絞り込む
  3. 解決策開発の段階では定義された問題を効率的に解決するアイディアを幅広く模索する
  4. 世に出す段階では世に出した際の情報を元に解決策を最適化していく

と、広げる→絞り込む→広げる→絞り込むというサイクルが二つのダイアモンドの形になってるのでこのように呼んでます。ここでのUXリサーチは主に1.の発見段階のリサーチについて書いていこうと思います。

Foundational Research

「何もわからないけど、なんとなくこの辺の人たちにこのトピック(例えば、航空会社であれば、飛行機の遅延など)について困ってる人が多そうで、何かしらの解決するべき問題がありそうだなー」という最初期の段階で行うのがFoundational Researchです。このタイミングで行うリサーチのタイプにはいくつかありますが、個人的によく使う2つを紹介してみます。

Foundational UX Interview

一つ目は、手っ取り早く、そのトピックで困ったことがあるであろう人たちに直接聞いてしまおうという方法です 笑
何か具体的なことを聞くのが目的ではなく、大枠でどの辺に問題がありそうなのかを模索するのに使われます。

ユーザー目線で、ユーザーがそのトピックについて経験したことをインタビューによって追体験をしようとする。何人かのユーザーにインタビューしたあと、それぞれの追体験をもとにプロセスを図式化し、そのプロセスにおいてユーザー達が体験したペインポイントをマッピングしていきます。マッピングした後、どのペインポイントが一番大きな(もしくは根本的な)問題かを決め、ペインポイントに優先順位をつけていきます。

問題/トピックの規模が小さい場合、単純な場合等はこれが一つのプロダクトのアイディアになり、すでに解決策の糸口が見える場合もありますが、多くの場合、Foundational UXインタビューで得られるInsightはそのドメインでの複数のProductに関わるようなProduct Roadmapレベルのものなので、ここから各サブトピックをさらに詳細に定義するために各サブトピックに対してよりフォーカスしたUXインタビューを行うことになります。

また、リソースと問題の規模、Impactの大きさによりますが、ここからさらに優先順位の確度を高めるために、UXインタビューで出てきたサブトピックをサーベイ/アンケートにして、より多くのユーザーのインプットを得るということもあります。肌感覚では、サブトピックレベルでは4〜8人くらいにインタビューすると大体何人目かで「あー、これでサブトピック出切ったな」と思えるタイミングが来ますし、多くのユーザーのペインポイントの優先順位の優先順位が大体同じになることが多いです。逆にProduct RoadmapレベルのInsightを得るUXインタビューで、特に各ユーザーによってユーザー体験が全然違いそうなもの(例えば交通事故後の保険対応とか)の場合は4〜8人のインタビューをしただけではペインポイントの優先順位に確信が持てなかったりするので、より多くのユーザーに向けてのサーベイ/アンケートが有効だったりします。

Ripple

上記のUXインタビューは主にそのユーザー目線でのペインポイントを模索するために行うのですが、特にプロセスが複雑な場合、プロセス全体をもっと俯瞰で見て、プロセス全体においてどんなユーザーが関わっていて、それぞれのユーザー達がどのように関わっていて、問題が発生し解決されていくのか、そのプロセスにおいて各ユーザーにどんなペインポイントがあるのかを模索する必要があったりします。このために行われるのがRippleです。

Rippleについてはなかなか他に解説しているサイトがなかったので 笑
例を使って説明してみようと思います。

まずリサーチのフォーマットですが、ワークショップ形式で行います。ワークショップにはそのトピックに直接的にも間接的にも関わっている人たちがなるべく包括的に揃うように呼びます。

ここに集まった人たちと、架空の超具体的なシナリオをロールプレイしていきます。
ここでの肝は実際に起きたケースを検証していくのではなく、あくまで架空のシナリオをロールプレイしていくことにあります。実際に起きたケースでは一つの事例に集中し過ぎてしまうのですが、架空のシナリオを各分野のエキスパートと何が起きうるのかをロールプレイしていくことで、より汎用性のあるシナリオが描けます。

シナリオを描く中で、まず登場人物をリストアップしていきます。例えば飛行機遅延のRippleを行うのであれば、

  • その飛行機に乗り合わせるお客さん(お客さんでも何人か立場の違う人たちをリストアップします)
  • その飛行機のパイロットやCA、メカニック
  • 到着空港の航空管制官
  • 到着空港で荷物をバッゲージクレームまで運ぶ人
  • その飛行機の遅延によって何人かの乗客が振り替えた別便のパイロット、CA
  • その飛行機が長くゲートにいたことでゲートに入れず結果ゲート変更を強いられかつ遅延してしまったその次の飛行機のパイロット、CA、とその乗客
  • その飛行機が到着後使用される予定だった便も遅延するので、その飛行機のパイロット、CA、とその乗客

というような人たちがリストアップされていきます。なるべく漏れなくリストアップすることが大事なので、実際に飛行機遅延のRippleを行うのであれば、多分もっと多くの人が登場すると思います。

主な登場人物がわかったら、大きなホワイトボードに登場人物を縦軸に記載していき、事象の始まりからワークショップに参加している関係者達とロールプレイをしていきます。事象が起きてから誰が何をするのか、どういう感情になるのかを参加者達と議論し、横軸を時間軸としてそれぞれの行動や感情を記載していきます。各登場人物同士の行動、感情に関係がある場合は矢印等で表現していきます。時間軸であるの横軸の一番上にその事象の主なマイルストーン(例えば飛行機遅延であれば、飛行機の故障、搭乗時間の変更X回目等)を記載していくとプロセス全体の視認性がより高まります。

こうして全体のプロセスの中で全ての登場人物の行動、感情の推移を同一時間軸でマッピングをし、その後参加者全員で、全体プロセスの中の各登場人物の行動/感情で「うまくいっていること」、「改善されるべきこと」「プロセスとして成立していないこと」にそれぞれ緑、オレンジ、赤等のシールを貼っていきます。

このステップを終えると、全体のプロセスの中でどの時間軸でどの登場人物にどんなペインポイントがあるのか、俯瞰で見ることができます。また、赤やオレンジのシールの数で、それぞれのペインポイントも大枠で優先順位がつけられます。

これをもとに各ユーザーについてUXインタビューを行ってさらに深く、具体的にペインポイントを探っていきます。

Wrap Up

さて、今回もめちゃくちゃ長くなってしまいましたが、顧客、会社の抱える解決するべき問題を突き止めるステップにおいてのUXリサーチについて解説しました。簡単に言うと大きくUX InterviewとRippleというアプローチがあって、問題の複雑さや大きさによって使い分けましょうというお話でした。

UXリサーチはScience的な要素よりもArtな要素がとっても大きいと思います。Product Managerとしては、前回のログで解説したよりScienceな部分の定量的なInsightと、今回のログで紹介したよりArtな部分の定性的なInsightを上手に組み合わせて、問題を包括的に、かつより深く理解するのがProductを成功に導くための秘訣だと思います。

Product ManagerというとエンジニアとProductを作るのが主な仕事と思われがちですが、以前紹介した”Fall in love with the problem, not the solution”の言葉にあるように、問題を誰よりも理解するのがProduct Managerの第一歩で、もっとも重要な仕事といっても過言ではないと思うので、ちょっと詳し目に解説してみました。