【レポート】UXにおける最良の決定の構築:UX DAYS TOKYO2018

2018/03/16(金)に実施されたUX DAYS TOKYO2018におけるDavid Sherwin氏とMary Sherwin氏による講演「UXにおける最良の決定の構築」のレポートです。

組織には多くの部門が存在します。各部門に属するステークホルダーに、意思決定の場へ参加してもらい、それぞれの立場から独自の意見を集めることで、組織がより良い判断を下すことができます。
世界的に著名なUXコンサルタント企業Frogにも所属するDavid Sherwin氏と、大学で教鞭を取っているMary Sherwin氏の2名から組織の意思決定をより良いものにするための方法に関する内容を紹介していただきました。

Mary Sherwin氏(左)とDavid Sherwin氏(右)

UXデザインにおける決定

UXデザインの一番小さい単位は”判断・決定”

UXデザインにおける意思決定には様々なパターンがあります。「誰のどのような問題を解決するのか」というターゲットに関するものや、様々なアイデアの中から「どのアイデアが問題解決に一番価値を発揮するか」を決めるもの等が考えられます。どの選択肢を採用するかという意思決定を元に仮説を立て、製品・サービスの設計に入ります。

ところが、ステークホルダーはそれぞれの立場・役職・関心事が異なるため、意見が分かれる場合が多々あります。全員の意見をまとめ、意思決定を管理することは非常に困難です。意思決定を難しくする要素はステークホルダーだけではありません。新しい技術を伴う製品・サービスを設計する際は前例が少ないため、最良の意思決定を下すことが難しいです。

意思決定における6つの慣例(ritual)

難易度の高いものをはじめとする全ての意思決定を行う際には、必ず通過しなければいけない6つの慣例が存在します。

  1. 意思決定に集中する
  2. 十分な数の選択肢を用意する
  3. 基準を設定する
  4. 選択肢を比較検討する
  5. 確信をもって決定する
  6. 決定を共有する

意思決定における6つの慣例(説明の都合上、本レポートでは2章と3章を入れ替えています。)

6つの慣例を繰り返し行うことで、UXデザインにおける、より良い意思決定が行えます。しかし、これらの慣例を実施すれば必ず完璧な意思決定になると考えてはいけません。6つの慣例を実施する目的は、ステークホルダー全員が「なぜこのような意思決定に辿り着いたのか」を、理解するためです。

1.意思決定に集中する

意思決定をする際に、目の前にある選択肢からすぐに選んではいけません。まずは「なぜ今回の意思決定をする必要があるのか」という目的に焦点を当てましょう。

目の前の選択肢から選んではいけない

具体例としてスマートライトの色を制御するモバイルアプリを使って、なぜ、目の前の選択肢から選ぶべきではないのか説明します。

改善案をチームメンバーにヒアリングした場合を想像してください。「どのようにしてライトの色を変えるのか」「どのようにライトのスイッチをオン/オフするのか」という質問がメンバーから出てきて、収拾がつかなくなるでしょう。

スマートライトの色を操作するスマホアプリの例

改善案を考えることから始めてはいけません。検討しなければならない本質に焦点をあてることが大切です。

「私たちは決定をしなければならない、ということに焦点を当てよう」

UXデザインにおける意思決定は多角的に検討する必要があります。デザインの観点だけで意思決定しようと思わず、開発のプロセスに沿っているかを検討し、最終的にはビジネス視点からも検討します。

UXデザインにおける意思決定に多くのステークホルダーが参加してもらう必要があるのは、意思決定を「多角的に 抜け漏れなく 適切に」行うためです。

意思決定に焦点を当てるために検討すべき事項

意思決定に焦点を当てるために検討すべき事項

議論の焦点を明らかにするために、以下の観点からUXデザインを検討しましょう。

  • なぜ私たちは意思決定をしているのか(Why)
  • 製品・サービスを良くする上で、この意思決定はどのような意味を持つか(How)
  • 誰が意思決定を行うのか(What / Who)
  • いつまでに意思決定をしなければならないのか(When)
  • 誰が意思決定の責任を持つのか(Who)

これらの観点から検討する理由は、自分たちの仕事や過去の意思決定に対して、批判するためではありません。全員で正しい意思決定をするためには、チーム全体で共通認識を作り上げる必要があるからです。

意思決定をする際に重要なことは、「何が起きれば、意思決定が成功したと言えるのか」を最後にチームで話し合うことです。

以下のフレームワークに当てはめると、成功基準が明確になります。

この意思決定は[今回の意思決定における成功基準]であるならば、成功したと言える

意思決定の成功基準を決める

2. 十分な数の選択肢を用意する

意思決定に対して、多角的に 抜け漏れなく 適切に検討しているか確認するためには、多くの選択肢が必要です。

製品開発の下流工程においては、少なくとも5つの選択肢を用意して、メリット/デメリットを比較した上でトレードオフを明確にしましょう。上流工程においては、発生する確率が低い物でもできるだけ多くの選択肢を用意しましょう。

 

十分な量の選択肢を用意する

また、選択肢のレベル(抽象度・見た目・粒度)を揃えることは重要です。レベルが揃っていないと、選択肢のトレードオフが明確にならないため、メリットを一番享受できる選択肢がどれなのか、区別することができません。

選択肢のレベルは揃える

3. 基準を設定する

チーム内で意思決定における共通認識を作り上げたら、先ほど検討した選択肢を評価する2種類の基準を考えます。

Yes/Noで判断できる基準

基準の具体例は、以下のものがあります。

Yes / Noで判断できる基準の例

機能的な要求事項 Android、iOS、モバイル、webで動作しなければならない
国際化 多数の言語で対応できなければならない
技術的な制約 Wifiが必要である
予算 プロトタイプを用いた機能面でのテストを
2ヶ月以内に終わらせなければならない

ただし、安易にYes / Noの2択で判断できると決めつけてはいけません。例えば、iOSで動作するという基準は「バージョンはどこまでを範囲とするのか」まで決める必要があります。他にも国際化に対応するという基準は「どの言語に対応するのか」まで決める必要があります。一つの基準を細分化すると、より明確な基準が見えてきます。

流動的な基準

人々がアイデアや選択肢を評価する指標は、流動的な場合が多いでしょう。

具体例には、「このアイデアの方がよりブランドに適しているので良い」や、「このアイデアの方がより収益化しやすい」という基準があります。

流動的な指標の具体例

先ほどのモバイルアプリの例で言えば、「電球の点灯状態の分かりやすさ」等のユーザビリティの原則に関する基準や「色覚多様性の人による使いやすさ」等の直感による基準は、流動的な基準と言えます。

流動的な基準の具体例

流動的な基準は他にも以下のようなものがあります。

流動的な基準は様々存在する

流動的な基準の例

  • 技術的な難易度 
  • ユーザにもたらされる価値
  • 収益化の可能性
  • ブランドとの合致性
  • マーケットサイズ
  • デザインシステムとの一貫性

開発の段階に応じて、個別の基準が見つかる場合もあります。企画段階であれば、顧客が抱えている課題に対する価値はどのくらいなのか、という基準を設けられます。設計段階であれば、使いやすさという基準を設けられます。

開発の段階に応じて意思決定の基準は異なる

洗い出した基準の達成可否を感覚で定めてはいけません。基準をクリアしたかどうかを計測できるようにしましょう。また、設定した基準に対してチームが責任を持つ必要があります。

意思決定に移る前に、できる限り多くの基準を定めておきましょう。

4. 選択肢を比較検討する

基準、選択肢を洗い出した後は、比較検討のフェーズに入りましょう。全工程の中でこのフェーズが一番難しいかもしれません。

2×2のディシジョンマトリクス

選択肢を比較する際に効果的な「2×2のディシジョンマトリクス」を紹介します。一つの基準で選択肢の優劣を決めるのは非常に困難です。しかし、ディシジョンマトリクスを使うことによって、それぞれの選択肢の優劣を明確にすることができます。前のフェーズで洗い出した基準を用いて、選択肢をプロット(=マトリクス内に配置すること)していきます。

一つの軸では、それぞれのメリットデメリットが分かりにくい

 

2つの基準を設けることで、Option Cの優位性が明確になる

洗い出した基準を様々組み合わせて、多くのマトリクスを作り、選択肢のプロットを繰り返していきます。

忘れてはならないことは、マトリクスの「どの象限が良い評価となるか」という合意をチーム内で取っておくことです。アメリカでは通常、右上の象限が一番良いと合意した基準になるようにマトリクスを設計することが多いです。象限とは、基準で4分割されたうちの一区画のことを表します。

マトリクスの一区画を象限と言う

例えば、上の図では「技術的チャレンジ」と「顧客の使いやすさ」が評価軸になっています。この例では「技術的チャレンジは高難易度の方が良い」「顧客にとって使いやすい方が良い」という、一番良いと合意した基準が右上に来るようにマトリクスを設計しています。

選択肢がプロットされない象限がある

いくつかの評価軸で選択肢をプロットしていくと、選択肢が一つも属さない象限が発生する場合があります。その場合に考えられる問題としては、以下の場合が挙げられます。

  • チームメンバーが正直にプロットできていない
  • 選択肢の数が足りない
  • まだ考慮できていない選択肢がある

評価軸に沿って選択肢をプロットすることで、足りない選択肢に加えて、新たな評価軸も見つけられるでしょう。そして、新たな評価軸を用いて再び選択肢をプロットすることで、検討できていない課題が浮かび上がります。

プロット作業を通じて、検討されていない問題を発見することができる

5. 確信をもって決定する

「アイデアがたくさん出来た!」

「どの選択肢を選ぼうか?」

「Cが好きだからCにしよう!」

「わたしはCよりDが好きかな〜。」

このような会話からは何も決まりません。意思決定において、自分の意見に対して相手から合意を得るために説得することも必要ですが、自分の意見を通すことが目的ではありません。

確信をもって決定するためには、どの選択肢が最良なのかYes/Noの2択で選んではいけません。自分が最も重要だと思っているものだけを取り上げることも避けるべきです。

上司や決裁者が提案した選択肢に引きずられて意思決定が左右されることも望ましくありません。上司や決裁者の意見がバイアスとなり、最良の意思決定を阻害してしまいます。

確信度で評価する

バイアスを取り除くための手法として、パーセンテージで投票する手法を紹介します。それぞれの選択肢に対して、各個人が「良い選択肢である」という確信をパーセンテージで表し投票します。100%に近いほど、それが良い選択肢であると強く確信していることを示します。

投票のプロセスは以下の通りです。

    1. 一つの選択肢を投票対象として選ぶ
    2. 各個人がその選択肢に対して、良いと確信しているパーセンテージをポストイットに記載する
    3. 全員が書き終わったら同時にポストイットを見せる
    4. 各メンバーは、提示した数字の理由をメンバーに説明する
    5. その理由を聞いた後に、必要であれば自分のパーセンテージを変更する
    6. 別の選択肢を選び、同様の手順を繰り返す

注意しなければいけないことは、「全員が同時にポストイットを見せる」点です。誰か一人が先に見せてしまうと、他のメンバーが、その人の確信度に引きずられて選択肢を評価してしまいます。

特定の選択肢に対して、確信をパーセンテージで表示する

意思決定の閾値となるパーセンテージを決めて、閾値を超えた選択肢を今回の意思決定とします。

閾値を超える選択肢が無い場合は、確信度を上げるために何が必要か(情報・議論など)をメンバー同士で話し合い、必要な取り組みを実施します。その取り組みを経て、選択肢に対する確信度を上げていきます。投票を重ね、閾値を超える選択肢が現れた際に、その選択肢を今回の意思決定とします。

スコアが高い ≠ 最適解

注意すべき点は、パーセンテージが高いという理由だけで選択肢を選んではいけないということです。その説明として「地球外生命体から地球を守る方法を検討した結果」という架空の例を紹介します。

(架空の)例:地球外生命体から地球を守る方法を検討した結果

この表によれば、地球外生命体から地球を守る手段として、スターウォーズのデス・スターが良いと考える確信度が高いので、意思決定の有力候補です。ところが、デス・スターは文明を犠牲にするという大きなリスクを伴っているので選ぶべきではありません。

評価軸はチームがトレードオフを理解するためのもの

評価軸はチームの意思決定を選ぶためのものではなく、チーム全員が選択肢同士のトレードオフを理解するための材料であることを忘れないようにしましょう。

6.決定を共有する

意思決定を下すにあたり、大切なことを忘れてはいけません。それは、そもそも完璧な選択肢は存在しないということです。今回選んだ選択肢は、現状知りえている情報をもとに考えた選択肢の中で、一番マシなものでしかありません。いわば不完全な情報に基づいた意思決定です。

完璧な選択肢は存在しない

ところが、今までの意思決定のプロセスをドキュメントに記載して、関係者全員に共有すると魔法のようなことが起きます。チームの全員が「自分の意見が反映された」と感じるのです。今回採用された意思決定に反対していたメンバーでさえ、決定の理由を明確に理解できます。そして、参加者全員が今回の意思決定を自分の意見として、その場にいなかった人に対して、なぜ今回の意思決定に至ったのか明確な説明ができるようになります。

決定は必ず共有する

意思決定における最適解

僕の考えとしては、今後ビジネスはより複雑化していだろうと思っています。その理由の一つは、多くの部門の協力がなくては達成できない課題が存在するからだと、考えています。

しかし、立場・役職・関心事が異なるメンバーが同じ方向に進むことは、非常に困難です。何も手を打たなければ、全員がそれぞれの優先度に沿って行動するでしょう。

今回の講演で紹介してもらった意思決定プロセスは、部門・メンバーが同じ方向に進むための最適解を提供してくれる、ビジネスを成功に導いてくれる手法だと感じました。

この記事を書いた人:藤原 脩平

現在、システムエンジニアとして自社サービスの企画/開発を行なっています。
ユーザーファーストなサービス開発を心がけたいという思いから、UX DAYS TOKYOのスタッフとして活動を始めました。

最近はリサーチスキルを伸ばすために統計学を勉強している。