投稿

このブログ記事は、先月末に NIJIBOX さん主催で開催されたイベント『UXリサーチの最適解 〜職域と機能から考えるベストプラクティス〜』でお話しさせていただいた内容の解説になります。

なぜこのテーマを選んだのか?

主催者と登壇者間で2回に渡るディスカッションをした結果、昨今の UX デザイン界隈におけるトレンドの一つでもある UX リサーチを取り上げることにしました。UX リサーチの定義や職域、必要性などが語られるイベントが非常に多く開催されていますが、もう一歩先に踏み込んだ、組織への装着について議論がなされる時間をより多く設けるべきである、という結論からこのようなテーマを設けることになりました。

当イベントの位置付けは、HOW TO よりも、UX Maturity Model(UX 成熟度モデル)における第3段階「Invested」− つまりUX デザイン的活動は投資に値するかどうかを見極めるためのディスコースを促す場です。

Planning Your UX Strategy

A strategy is a set of coordinated, orchestrated, planned actions, or tactics, which will take you along a journey to reach a desired future state, over an established period of time. Design objectives are conditions or outcomes that a project must meet, often of tactical nature.

UX リサーチをする上で大切な3つのこと

私が UX デザイナーとしてのキャリアを選択した当時、UX リサーチはもちろんのこと UX リサーチャーという職種すらありませんでした。ユーザーリサーチが近しいかもしれません。しかし、スマートフォンの普及などに伴い、ユーザー体験そのものが経営に直結することにようになったことで、より広義のユーザー体験の設計と改善に資本を投下する企業が増えてきたことが、UX リサーチとして生まれ変わった背景にあるかもしれません。

ところが、UX デザインが UX デザイナーだけで完結しないように、UX リサーチにも同じようなことが言えます。なので、タイトルの「属人化」「UX」を強調しました。このセッションで私が伝えたかったことは以下の3つです:

  1. UXリサーチの良し悪しは、リサーチの結果ではなく、ユーザーが求めているプロダクトが 提供できたかどうかで判断すべきである
  2. UXリサーチで検証するための仮説の種は、チームの誰もが持っている。 ユーザー体験のリサーチは組織全体が取り組むべき活動である
  3. リサーチが開発のボトルネックとなってしまってはNG。いまこの瞬間も使っている ユーザーがいることを認識し、成長速度を上げるために仮設検証を高速に回そう

自身のキャリアから見たリサーチの本質

以前、「UX デザイナーからプロダクトマネージャーへのキャリアパスの探究」というブログ記事で自身のキャリアについて触れましたが、私は UI デザイナーとしてキャリアをスタートさせました。その後、情報アーキテクチャへと視点を広げ、そこから少しづつ、ユーザーインタビューやユーザビリティテストといった、いわゆる「対ユーザーのリサーチ」を専門としていた時期がありました。ただ、ユーザーリサーチャーという専門家ではなく、UX デザイナーの延長として行っていました。その後、UX デザイン→サービスデザイン→プロダクトマネジメントとミクロからマクロな視点でプロダクト開発に携わっていくことになるのですが、プロダクト開発におけるリサーチが明らかにすべき点は3つあると思います:

ただし、これらの問いに対する納得度の高い結果が得られたとしても、いいリサーチとは言えません。期待した結果ではなく、最終的にはプロダクトが世に出たときにユーザーが求めれている価値が提供できたかどうかで判断すべきです。これは、例えユーザーリサーチであっても UX リサーチであっても、リスクを低減するための活動としてのリサーチの本質だと思います。

組織的活動としての UX リサーチ

UX リサーチャーを批判しているわけではありませんが、捉え方によってリサーチをする人が限定されてしまうと、投資する以前に関心ごとで終わってしまい、前述の UX Maturity Model の階段を登ることすらできず、組織全体への浸透が困難になってしまいます。

私は、UX リサーチは組織全体が取り組むべき活動だと思っています。なぜなら、リサーチに必要な仮説の種はチームの誰もが持っているからです。某就活サイトのリニューアルに携わっていたときに、身を以てそれを学びました。

マーケティング、営業、カスタマーサポート、エンジニア…サービスに関わっている人であれば、何かしらのインサイトを持っています。なぜならば、インサイトはファクトから生まれ、そのファクトは日々の分析やサービス運営などから見出されることが多いためです。しかも、それぞれが異なるファクトを保持していることが多いため、インサイトも多様です。

これが、仮説の種になります。あとはそれを検証可能な形式に整え、リサーチの計画を練って実行すればまた新たなファクトを集めることができます。これを誰もが必要なときに必要な情報にアクセスすることが可能になるよう一元化することができれば、それは常に進化していき、ユーザー体験の向上のために当事者意識も芽生えると同時に、リサーチを組織全体で取り組むべき活動として認識されるようになります。

共有フォルダでもいいですし、定例会議でもいいです。ファクトを集めることから始めてみてください。

アジリティの高い UX リサーチ

前職の Pivotal Labs でご一緒させていただいた多くのクライアントを含め、アジャイル開発を推進している企業は年々増加してきているように思います。特に昨今では HOW としてのアジャイル開発が触れられることが多い DX に関する記事を目にしない日がないくらいです。

アジャイル開発の導入によって得られるアウトカムの一つとして「ユーザーからのフィードバックまでのリードタイムが短くなる」があります。従来のプロダクト開発と比較してリリース頻度が格段に上がるため、仮説検証を高速に回せるようになりました。そのため、リサーチも従来とは違ったアプローチをとっていく必要性が出てきました。これはリモート環境でも可能です。

最低なユーザーリサーチ:リモートのリスクを減らすためのアプローチ | mariosakata.com

本記事は、ユーザーリサーチを批判することを目的に書いた記事ではないことをご理解ください。私自身の経験をもとに、ユーザーリサーチの可能性を広げるためのアプローチをご紹介し、リモートでユーザーリサーチを行っている、またはこれから行う人にとってお役に立てればと思っています。 …

UX リサーチの必要性が理解できていても、その実行における時間的コストが肥大化することでプロダクト開発のボトルネックとなってしまっては本末転倒です。世の中には非常に便利なアクセス解析ツールがどんどん増えてきています。故に今この瞬間も使っているユーザーの行動をその場で分析することも可能になりました。フィードバックループの速度が速くなればなるほど、プロダクトやサービスの成長速度も速くなります。

冒頭でもお伝えしましたが、リサーチの結果は、ユーザーが求めている価値が提供できたかどうかで判断すべきです。当初計画していた通りにできなかったから失敗というわけではありません。如何に低コストで、高いリターンを得ることができるのか、それだけを考えた方が組織内衝突もなくなります。

リサーチを始めるタイミング

最後に、セッションの終わりでも質問をいただいていましたが、リサーチをすべきタイミングについて自分なりの意見を述べて終わりにしたいと思います。言わずもがな、リサーチの目的は仮説検証を繰り返してプロダクトやサービスを成功へと導くことです。そのため、ポイントとなるのはフィードバックループを止めないようにすることです。

以下がそのリサーチをすべきタイミングを判断するためのサインです:

もし、UX リサーチャーが必要か否かを判断するための材料が必要というのであれば、上記を参考にしていただけるといいかもしれません。このサインを見逃すと、リサーチの意味を見失ってしまいます。

だからと言って UX リサーチャーに全てを委ねるのではなく、組織的活動としての UX リサーチをリードする専門家としてポジショニングした方が、それこそユーザー体験の底上げに最大限貢献できるのではないかと考えています。

先月末に NIJIBOX 主催のイベント「クライアントワークの現場で見えてきたUXデザインの変化とアプローチ」に登壇させていただく機会がありました。イベントのテーマである「UXデザインの変化とアプローチ」を考えたときに、何を話そうかパッと思い浮かばなかったのが正直なところです。今の仕事、つまり今の会社を選んだことのきっかけにつながってくるのですが「世界中のソフトウェア開発を変革する」ことを目標に取り組んできた内容こそ、自身が起こしていきたい変化であると捉えて、タイトルを「仮説駆動型UXデザインのススメ」としました。

仮説とは何かを考えてみる

この「仮説」という言葉が今回のキーワード。ここでこの記事を読んでいる皆さんに質問をしたいのですが、最近「仮説」という言葉を使った、または耳にしたのはいつでしょう?もう無意識に毎日のように使っている、あるいは聞いている人がいるかもしれません。「仮説を立ててPDCAサイクルを回そう」なんてことは日常茶飯事でした。ただ、これには昔から違和感を覚えていました。なぜかというと、これだけだとPDCAサイクルを回すことが目的になってしまっていて、そのための仮説を考えるという発想になってしまうからです。本来は逆なはずです。検証したい仮説がないと回すものも回らないと思います。

PDCAが前提としているのは、あくまで “想定外のことが起きない” 世界。つまり、「常に安定しており、かつ心理や感情など人間的要素が関わらない環境」の中で継続的に改善を繰り返して品質を高めていくというシーンで使うのであれば、確かに有効なのです。しかし、“いつも想定外のことが起きる” “昨日と今日で状況が変わる” といった「先がまったく読めない」環境では、そもそも最初の「P(計画)」の立てようがありません。そこでPDCAにこだわりすぎると、かえって物事が前に進まなくなる原因にもなり得るのです。

はじめに足並みを揃えたかったのは、

  • 仮説とは何か?
  • なぜUXデザインで仮説を立てる必要があるのか?

という問への考え方です。仮説を立てる前に、実はワンステップ挟む必要があると思っています。それは、現時点での最善の推測を洗い出すこと。自分は Best Guess と呼んでいます。仮説は、それを検証可能な形式にしたものです。

例えば、明日の夕食を当ててみようとします。それはずばり、魚料理。これは現時点での Best Guess になります。確信はありません。今晩の夕食が肉料理だったため、明日は魚料理のはず。これが検証可能な形式にしたものです。仮説の立証がしやすくなりますよね。更に言うと、なぜそう思ったのかも併せて記載しておくと学びが多くなり、次に仮説を立てるときの題材となります。

ここで言いたかったのは「いきなり仮説を出せ!」と言っても、前提が整理されていないとそもそも立てようがないということです。

仮説を検証しないことのリスク

UXデザインにおける大きな失敗とは、作ったものが顧客に使われないことです。それはとても悲しいこと。チームはそれを避けるために日々努力をしています。そのはずです。そうならないようにするためには、なるべく早く検証する機会を設けること、そしてリスクを可能な限り減らすことを心掛けなければなりません。プロダクトの価値を検証し続けていくためには、その時々のリスクを特定して排除していかなければなりません。そのための仮説思考です。

作りたいものを考えるのは簡単なことです。難しいのは、作るべきではないもの考えることです。それが、網羅思考と仮説思考の違いです。先ずは作るために必要な作業を網羅しながら進めるアプローチと、作る必要がないものを特定してリスクを下げて進んでいくアプローチはこのような図を用いて説明しています。

この図で説明しているリスクとは、前述の使われないリスクのことを指します。プロダクト開発がユーザー不在のままだと、不確かな状態で進むことになります。結果はリリースするまでわかりません。そんなギャンブルのような世界から、早期に脱却すべきです。

SHOWROOM の前田裕二社長も同じことを言っていました。

例えば、宝の山が眠る鉱山を今から掘って、宝石を探り当てるレースをするとします。おそらくほとんどの人が「俺の筋力を見よ」って感じで、パワーで下から全部アナログに掘る、みたいなことをやる。掘ってる時は、自分でも仕事してる感すごくあるし、思考停止して掘り続ける。そんな中、我々は、掘らずに山の麓にある街の長老にヒアリングに行ったり、宝石のありかの地図や宝石探知機のようなものを探してきたり、まずは「見極め作業」に全神経を集中します

(引用元:最初にやるべきは血まなこで「宝のありか」仮説を立てる事|SHOWROOM 前田裕二

UXデザインを進める前に

UXデザインにおける仮説を設定するための軸と、仮説を設定する流れについてはスライドにまんま書いてあるので割愛します(記事の一番下に貼っている)。参考になれば嬉しいです。仮説を設定する軸は至ってシンプルだと思います。

このソリューションは、誰のどの問題を解決するために必要なのか?

これに答えられるレベルにまで、思い込みを検証可能な形式に落とす必要があります。「いやいや、何を今さらわかり切ったことを」という人もいるでしょう。自分がこれまで仕事をしてきたクライアントにも、同じような反応をする人がいました。その度に、それが紛れもない事実だと、どこまで自信を持って言えますか?と常に聞くようにしています。わからなくても、不安に思っていても構いません。それが検証をしなければならない動機に繋がるのだから。

チームメンバーのみならず、ステークホルダーを交えた場で思い込みを洗い出すときが一番難しいと感じます。なぜなら、軸を例え設定していたとしても、自分の中でフィルターをかけてしまい、わかっていないことを挙げることに躊躇してしまう人が多いからです。最初は慣れが必要ですが、例えばペルソナを記述するワークで「メインのお客さんは都内に住んでいる会社員だと思うけどね」「地方にいるお客さんの方が利用者に多かったような?あれ、違う?(キョロキョロ)」と言った会話が生まれることもあります。それはとてもいいサインです。その場は思い込みで溢れています。

あとは、それをどんどん吸い取って、ペルソナだったり、ジャーニーマップに可視化するだけ。間違っていても、言ってもいいんだ!その空気をどう作り出すか。その場のデザインが実は大事だったりする。最後はエイやで決める必要はあるにせよ、ポイントはみんながどこを向いているかです。ズレているほど、検証のしがいがあります。誰が正しくて、誰が間違っているのか、ではありません。偉いからその人に従おう、ではありm線。答えはユーザーしかわかりません。

学びがチームを一つにする

これまで説明しているように、仮説を検証可能な形式に記述することで、結果を振り返るときにその仮説が正しかったのか、間違っていたのかが明確になります。結果をまとめる際に、仮説ステートメントと呼ばれるようなカードを作成し、結果を色で識別できるようにシールをその上に貼ってみたりすると、一目でわかるのでオススメです。

赤・・・仮説が間違っていた
黄・・・微妙だった、まだ検証が必要
青・・・仮説が正しかった

このような感じです。

検証を繰り返すことで、仮説の種となる思い込みは次々と湧いてきます。それも、よりシャープになってきます。そうさせているのは、検証のときに得られた学びなのです。考えもしなかった可能性が見えたとき、人は創造的になります。こうした方がいいんじゃないか、ああした方がいいんじゃないか。ちょっと待ちましょう。一つづつ検証していきましょうね。

最後に

プロダクト開発が進むにつれ、検証結果が追えなくなったりすることはよくあります。どこまでリスクを解消することができたのか、覚えていないとそれが逆にリスクとなります。そのために、自分はこのようなボードにリサーチ結果を張り出して常に過去のリサーチ結果を参照できるようにしています。

これは、「Experiment Board」と言うツールです。詳しくはこちらの投稿を参考にしてみてください。

アジャイル開発の仮説検証学習サイクルを可視化する「Experiment Board」 | mariosakata.com

アジャイル開発における仮説検証学習サイクルを可視化するためのツールを 「Experiment Board」 と呼んでいます。2年ほど試行錯誤を重ねましたが、今は納得して運用することができているので、世のプロダクト開発をよりよくするためにも、参考になるかわかりませんが公開したいと思います。 なぜ、この Experiment Board …

スペースが足りなくなったら、せめて検証できた仮説と間違っていた仮説はキープするようにしてください。間違っていたことは、繰り返してはならないからです。捨てたらダメ、絶対。検証できた仮説もアーカイブしておくと後々振り返ったときに、同じ仮説が繰り返されていないかを再確認することができたり、ステークホルダーがチェックインしたときでもプロダクトの検証結果をすぐに説明することができるので、一石二鳥です。

イベントを主催してくださった NIJIBOX さんの公式ブログでもイベントレポートが上がっているので、読んでみてください。

はじめに

9月上旬に、 UX MILK 主催の「UX MILK Fest 2019」という大きなイベントに登壇させていただく機会がありました。「2軸で考えるプロダクトデザインのシンプルな意思決定方法」と題した当日のセッションでは「2x2」という手法をご紹介しました。セッションでお伝えしたかったのは、この手法を取り入れることで、様々な角度から軸となる考え方を UX デザイナー含めチーム全員が持つことができ、優先順位を徹底してプロダクト開発に関わるすべての意思決定をすることができるということです。

結果として、ステークホルダーや他のメンバーになぜ、その決定に至ったのかがロジカルに説明しやすくなり、説得力が生まれ合意形成がこれまで以上に効率化されます。この記事では、当日のセッションの様子を振り返ります。導入のハードルは低いと思いますので、当日参加できなかった人にとっても、お役に立てれば幸いです。(プレゼンテーションのスライドはspeakerdeckでもご覧いただけます)

なぜ 2×2 か?

このテーマを取り上げたいと思った背景には、以下の課題を多く耳にすることがあったからです。

開発したいデザインアイディアやソリューションが多すぎて、どこから着手していいかわからず、UX デザインが組織に浸透しづらい…。

2x2は、まずはじめに何を着手すべきかをチームで意思決定をする手助けをしてくれる手法です。 この2x2という手法を用いることで、UX デザイナーのみならずチーム全員が意思決定に関わることができ、ユーザー視点を維持することができるようになることで、上記の課題を解決してくれます。

2×2 の特徴

2x2は四象限のマトリクス構成になっています。意思決定をする際に必要となる観点を2軸(縦と横の軸)に設定することで、対象となる要素をセグメントごとにマッピングし、まずやるべきことをロジカルに決めることができます。これは、優先度を決めるときに効果を発揮します。

2つの軸で意思決定の対象となる要素を相対的にマッピングするとこのようになります。この絵では、4つの各セグメントごとの意味を説明しています。当然ながら、右上にあるセグメントはそれぞれの軸にとって優先度が高い要素が集まっているので、やらない理由はありません。逆に言えば、左下にあるセグメントは優先度が低いため、前述したデザインアイディアやソリューションはやらない方がいいという判断ができるようになります

ケーススタディ:ユーザーリサーチからアイディエーションへ

実際のプロジェクトでは、ユーザーリサーチの結果からアイディアを創出するために以下の2軸を設けて整理することができます。

ユーザーリサーチの結果であるインサイト(課題)をカードに書き出し、それぞれのセグメントにマッピングしていきます。尚、このときはチーム全員が参加することを推奨しています。なぜなら、マッピングには様々な角度から物事を捉え、優先順位を決める必要があるからです。

次に、解決すべき優先度が最も高いユーザー課題を対象に、アイディエーションのステージへと移っていきます。弊社ではデザインスタジオと呼んでいますが、プロダクト開発に関わるチームメンバー全員が参加し、ユーザー課題を解決するためのアイディアを発散する時間を設けます。

今度は以下を軸として、開発するソリューションを決めて次に進みます。

  • 縦の軸:ビジネス・インパクト(または価値)が高い / 高くはない
  • 横の軸:実現性が高い / 高くはない

2x2を用いることで、優先順位が高いユーザー課題とそれを解決するための最善のリューションが決定しました。今回はプロジェクトの2つの状況下における優先度づけと意思決定の一例をご紹介しましたが、軸は臨機応変に変えることができるため、プロジェクトのどのフェーズにも適応可能です。例)リスクが高い / 高くはない、確度が高い / 高くはない

2x2をより効率的に進めるためのアドバイス

  1. 右上に偏らないようにする
    よくあるケースは、すべてが大事と思っているが故にポストイットのほとんどが右上 偏ってしまうことです。2x2はあくまでも相対的なので、各セグメントに同じ数のポストイットを貼るように意識するとうまくいきます。
  2. 高い・低いといった二極化した表現を多用しない
    例えば、低い/少ないと言い切ってしまうと、そのセグメントにポストイットを貼るときに 戸惑ってしまいます。ステークホルダーによっては反発をくらいます。高くない/多くないといった 表現を用いることで、対立緩和を促すことができ、効率がよくなります。
  3. ポストイットを重ねない
    ポストイットを1枚1枚ボードに貼っていく際に、同じ優先度だからといってお互いを重ねないこと。必ず、ポストイットの上か下か、左か右に貼るようにして優先度の設定を徹底しましょう。
  4. まずは縦軸で整理し、そこから横軸で整理する
    いきなりそれぞれのセグメントにポストイットを貼っていくのは難しい作業です。 まず、縦軸に従って上から下まで一列で優先度を決めることをオススメします。そのあとに、 横軸に従って左右に貼っていくとスムーズにいきます。

2×2 を経由して仮説検証サイクルが回り始めたら、「Experiment Board」と言うツールを組み合わせて同じく可視化していくと、チームの共通理解が得られていいかもしれません。

アジャイル開発の仮説検証学習サイクルを可視化する「Experiment Board」 | mariosakata.com

アジャイル開発における仮説検証学習サイクルを可視化するためのツールを 「Experiment Board」 と呼んでいます。2年ほど試行錯誤を重ねましたが、今は納得して運用することができているので、世のプロダクト開発をよりよくするためにも、参考になるかわかりませんが公開したいと思います。 なぜ、この Experiment Board …

まとめ:2x2を取り入れることによって得られた成果

積み上がったデザインアイディアやソリューションを計画的かつ論理的にアプローチする方法がなければ、半ば強引に社内政治や声が大きい人の判断で決まってしまって、結果ユーザー視点が抜け落ちてしまったりすることがあります。それでは、デザイナーの価値が十分に発揮されなくなってしまい、ユーザー視点を取り込むことは難しくなるでしょう。

  1. この手法を取り入れることで、対立する様々な軸とバランスを取りながら優先度を設定することができるため、なぜ、その決定に至ったのかがロジカルに説明しやすいため、プロダクト開発に関わる全ての人の理解が得やすくなりました。
  2. 「この機能を追加して」といった急な相談や依頼が来ても、2x2を組み直したり、他の要素と相対的に比較して着手する順番を改めて決めることができるため、優先度の取り引きが可能になりました。結果として、チームも柔軟に対応できるようになったと感じます。

前述したように、導入のハードルは低いと思いますので、ぜひ身近なものから少しづつ挑戦してみてください。無駄のないユーザーのためのプロダクトを開発するために、常に優先順位を徹底してみましょう!