プロトタイピングを始める前に！押さえておきたい仮説検証とコラボレーションのコツ
この記事は、Goodpatchのクライアントワークにおいて、プロトタイピングによる仮説検証をする際に留意しているポイントを簡単にまとめたものです。
特にプロトタイピングによる仮説検証の精度とスピードを上げるために、PMやデザイナー、クライアントなどがどのようにコラボレーションできるかに焦点を当てていきます。
目次
なぜプロトタイピングの話か
Goodpatchのクライアントワークでは、「要件が固まった後」からデザインに関わるのではなく、「要件が決まる前」から短期間でのプロトタイピングを実施します。
特にコアのユーザー体験部分については繰り返しプロトタイピングを通じた仮説検証を重ねることが多いです。
筆者自身もこれまで様々なプロジェクトでこのようなプロダクト開発に携わってきましたが、中でも「プロトタイピングにおける仮説の立て方と検証優先度の付け方」については特に個人ごと技量のブレが大きいのではないかと考えています。
プロトタイピングを始める際、事前にきちんと仮説出しとその優先度付けを行うことはとても重要です。これにはいくつか理由がありますが、たとえば次のようなメリットが挙げられます。
- デザイナーにとって
デザインすべき範囲・優先度が明確になるので、精度のメリハリをつけやすくなる。デザインを説明する際の根拠になる。
- インタビュアーにとって
訊くべきポイントがクリアになるので、「どう訊いたら仮説が検証できるか」の観点からUIデザインに対するフィードバックをしやすくなる。
- PMにとって
「今やること」「今やらないこと」「いったんバックログに寄せること」などを言語化できるので、デザインの進め方についてチームの共通認識が取りやすくなる。
- クライアントにとって
クライアント自身、仮説検証そのものの考え方はたいてい慣れているため、「何をデザインするか/しないか」の検討やインタビュー後の振り返りに入って行きやすい。
どうでしょうか。仮説出しや優先度付けというと、デザインプロジェクトの中ではなかなか地味、かつクリエイティブさを阻害すると誤認されがちなワークではありますが、上で挙げたように得られるメリットが非常に大きいです。
ということで、あえて今回は「プロトタイピングにおける仮説の立て方と検証優先度の付け方」に焦点を当てていきます。
デザインにおける仮説
そもそも仮説とは
一般的には「まだわかっていないことに対する仮の答え」のことを指します。
デザインにおいても、ユーザーインタビューやデータ分析など様々な事実をインプットとして課題や打ち手の仮説が出てくるので、このブログを読んでいる方も普段から馴染みのある考え方かと思います。
デザインプロジェクトにおける仮説の種類
ではデザインにおける仮説とは具体的にどういうことでしょうか？
多くの書籍や先輩方が言及しているところなのであまり多くは触れませんが、デザインプロジェクトの実務においてよく登場する仮説は以下3つに整理できると考えています。
- 価値仮説：「ユーザーはどのような人で、何に価値を感じる人なのか」
- 課題仮説：「そのユーザーが抱えている課題は何か」
- ソリューション仮説（機能仮説）：「その課題に対して、どのようなソリューション（機能）が有効か」
ここで折りたたみ傘のデザインを例に考えてみましょう。
たとえば普段リュックだけの軽装備で、よく忘れ物をして、家にテレビがないので天気予報を見ずに過ごす人がいるとします（価値仮説）。※ 筆者のことです
この人にとっては、ビニール傘が提供する体験は苦痛でしかありません。雨が降るたび少額ながらコンビニで買わなければいけないこと、家にビニール傘の備蓄ができること、外出先で傘立てから自分の傘を探し当てること。
ビニール傘について様々なタッチポイントで発生する小さな手間（課題仮説）は、折りたたみ傘を携帯することによって（ソリューション仮説）、生活習慣を変えることなく解消することができます。
この例で少しイメージが掴めたかと思いますが、本来、それぞれの仮説は独立したものと捉えるのではなく、三点セットで統合的に考えるべきものです。
たいていの場合「どれか一つの仮説が変われば他も変わる」ので、発散と収束の繰り返しの中で「今どの仮説の話をしてるんだっけ？」「今足りない仮説はなんだっけ？」と意識しながら一本のユーザーストーリーを紡ぐことが重要です。
仮説出しをする
仮説の種を考える
次に、これらの中からプロトタイピングすべき仮説を出していきます。
それぞれの仮説出しに必要となるインプットは、たとえば次のようなものになります。
- 価値仮説と課題仮説：プロジェクト初期のユーザーインタビューやデータ分析などをもとにした、ぺルソナやバリュープロポジションマップ
- ソリューション仮説（機能仮説）：上記のユーザー仮説や課題仮説をもとにした、アイディエーション時のスケッチ。
また、これらの仮説の種は複数日のワークから生まれるものです。したがって、本格的にポストイットに仮説を書き出す前に、全員で簡単に振り返りの時間をとっておくと効果的です。
仮説の粒度を揃える
仮説の種が出揃い、なんとなくポストイットに仮説を書き出したら、次にやるべきことはプロトタイプで検証すべき仮説の粒度を揃えることです。
この作業はチームの誰かが注意していないとぬるっと先に進みがちなので、特に意識しておくと良いかと思います。
以下では良い例を3つだけ挙げておきます。
例1: 項目に抜け漏れが少ない。
たとえば「◯◯なユーザーは（価値仮説）…と感じていたが（課題）、〜の機能によって△△に変わる（ソリューション仮説）」といった形のように、一連の仮説に筋を通しやすいようフォーマット化しておくのは有効です。
フォーマットをつくらない場合でも、都度ポストイットを眺めながら抜け漏れを指摘できると、のちの優先度決定がスムーズです。
例2: 仮説はプロトタイプで検証可能な具体性がある。
プロトタイプがコンセプト・インタラクション・機能のいずれかによって、検証に必要な具体性は全く異なります。
それぞれのポストイットがそれぞれどのレベルのことを言っているか意識し、必要に応じて検証可能なレベルまで具体化しましょう。
例3: 「検証された状態」の共通認識が取れている。
仮説があたっていた場合・外れた場合にデザインがどう変わりうるかまである程度事前に話しておけるとベターです。
特にコアのユーザー体験については、ここまで用意できているとインタビュー後のUIデザインの見直しがスムーズです。
ただしやりすぎるとインタビュー中に「見たいものしか見えなくなる症候群」が発生して、ユーザーに関する洞察が浅くなるので注意しましょう。
仮説の優先度決定をする
ここまででけっこうな数の仮説が出ていることと思います。
ではこれらをどうやってプロトタイピングしていくべきでしょうか？とりあえずすべてつくってみるべきでしょうか？
具体的な期間は会社・サービスによって異なるかと思いますが、GoodpatchがプロトタイピングのためのUIデザインにかける期間はせいぜい1-2日間です（1回のデザインスプリントにかける時間のうち20%程度）。
時間には限りがあるので、この中で優先度をつけていくこと・検証すべき仮説の優先度について（クライアントを含めて！）共通認識が取れていることが非常に重要になります。
Goodpatchにおいても、リーンUXやデザインスプリントでも登場するような「仮説が外れたときのユーザー体験・ビジネスへの影響度」「メンバーにとって既知・未知どちらか」の二軸で検証することが多いです。
「仮説が外れたときのユーザー体験・ビジネスへの影響度」は、検証したいユーザー体験のコア部分や、事前に協議していたKPIとの関連性の高さから割り出します。
「メンバーにとって既知・未知どちらか」は、過去既に検証済である、或いはほぼセオリー踏襲のデザインでいけると判断できるものを既知に、そうでないものを未知にプロットします。
セグメントごと仮説が書かれたポストイットを貼っていき、以下1から4の優先度でプロトタイピングに値すべき仮説を絞り込んでいきます。
ちなみに「すべて優先度高だ！」となって右上にポストイットが集中することが稀にありますが、これは黄信号と思ったほうがいいです。
理由としては、つくるべきプロトタイプが膨大になったり、インタビュー時間中に検証しきれる量を超えて結局未検証のまま残ってしまいがちだからです。
一回きりのプロトタイピング・ユーザー検証しか想定しないとなんでも詰め込んでしまいがちですが、検証すべき単位を小さくして2度3度と繰り返しイテレーションを回すほうが、結果的にデザインの精度・スピードも向上することが多いです。
最後はQCDS（質・コスト・納期・スコープ）のトレードオフを見極めて判断することになるものの、いずれにせよすべてを「優先度高」としてしまうのは何も決めていないことと注意しましょう。
コラボレーションのポイント
デザインプロジェクトにおいて、事前の課題分析から仮説立て、優先度決定、プロトタイピング、ユーザーインタビューまでを完全に一人で担うことはほぼありません。
その意味で、クライアントを含むチームメンバーでどのようにプロトタイピングに向き合うかは非常に重要です。
最後に、チームでプロトタイピングを実践するときに留意すべき点を簡単にご紹介します。
プロトタイピングは、実はプロトタイプする直前の仮説出し・優先度決めで成否の7-8割が決まると考えています。
過去のプロジェクトにおいて、プロトタイピングの精度が高く、スピードが速く、インタビューでの検証もスムーズにできた場合は、仮説のポストイットが貼られた模造紙を前にして、チーム内で次のような会話が生まれていることが多いです。
PM 「（デザイナー）さん、この仮説ってどうデザインしたら検証できると思う？」
デザイナー 「この仮説についてこうデザインするつもりだけど、（PM）さんはどうやってインタビューするの？インタビューで訊きやすいよう比較のパターンつくっとく？」
クライアント 「これは優先度高になってるけれども実はKPIとしてはこっちのほうが大事なので優先度低でいいですよ。むしろこっちの優先度あげてください」
このようなコラボレーションには少しだけ習熟が必要ですが、それでも「本当にこのプロトタイピングで知りたいことは明らかになるのか」にチーム全員の熱意と好奇心が向くことで、自然と実現できることと感じています。
長くなりましたが、記事は以上です。ここまでお読みいただきありがとうございました！
