テクノロジカルマーケティング部 データマーケティンググループにてUXリサーチャーをしている佐々木と申します。普段は、UXデザイン（以下、UXDと略記）に関するプロジェクトを事業部横断で支援する業務についております。
これまで前編として、"UXデザインが総論賛成、各論疑問になる理由"と"プロジェクト設計で意識したい３つの条件"の１つ目を前編「サービス・ドミナント・ロジックを中核とするサービスかどうか」、２つ目を中編「潜在ニーズを探る必要性の有無」として述べさせて頂きました。今回は、３つ目を後編「改善・改良の範囲を既存事業のコンセプトや機能のどこまでの範囲とするのか」を述べさせて頂きます。
■UXデザインのプロジェクト設計で意識したい３つの条件
- ＜その１＞サービス・ドミナント・ロジックを中核とするサービスかどうか【前編で説明】
- ＜その２＞潜在ニーズを探る必要性の有無【中編で説明】
- ＜その３＞改善・改良の範囲を既存事業のコンセプトや機能のどこまでの範囲とするのか【今回ここ】
6＜その３＞改善・改良の範囲を既存事業のコンセプトや機能のどこまでの範囲とするのか
プロジェクト設計で意識したい3つ目の条件として、「改善・改良の範囲を既存事業のコンセプトや機能のどこまでの範囲とするのか」を挙げさせて頂きました。なぜなら、デザインプロセスを用いてサービスの改善・改良を伴う再設計を検討する場合、時として既存事業のコンセプトと異なるアウトプットになり、当初想定していた改善・改良の枠外にハミ出してしまう可能性が高いからです。特に、改善・改良と言いながら、今までに無い価値を提供することに注力する場合、既存事業と異なる提供価値の施策案となり新規事業扱いをした方が良い施策になることが多い傾向があります。
そこで、改善・改良を目的にしたプロジェクトでは、まず最初にプロジェクトの制約条件を明らかにすることをお勧めします。その結果「既存事業のコンセプトは変化させ無い範囲で施策を検討するのか？」「ある制約条件の範囲内で既存事業のコンセプトが変化することを許容するのか？」を明らかにしておきます。本質的には後者の方がHCDを用いたデザインプロセスと相性が良いのですが、前者を前提にしながら場合により後者を検討する余地がある場合はプロジェクトで成果を出す可能性が広がります。
今回は、前者の場合を重視しながらプロジェクトを計画する際に意識する３つのポイントについて説明します。 1.事業者視点とユーザー視点のギャップを解消する 2.共通認識を整え、局所最適化したサービスを整理する 3.ビジョンと施策の中間目標となる提供価値を可視化する これらは相互に重複する箇所もあり、粒度もバラバラでMECEに整理できている状況ではありませんが、今現在、UXDを取り組む際に私が意識している観点になります。
6.1 事業者視点とユーザー視点のギャップを解消する
デザインプロセスとして人間中心設計(HCD)を用いる基本的な考え方は、事業者視点とユーザー視点のギャップを解消することです。 根本的に事業者は「使ってもらいたい機能をいかにしてユーザーに利用してもらうか？」を日々模索しています。 対してユーザー側は「機能に関係無く、解決したい課題や片付けたい仕事やゴールがある」のでそれを解決したがっています。 その両者の間には「事業者側が提供する価値」と「ユーザー側が求めるゴール」にギャップが常に存在することになります。
このギャップの極端な事例としては、ユーザー側は「基本的にサービスを利用する際により安く無料で利用したがる」のに対して、事業者側は「事業継続のために、提供するサービスに適した対価を得る必要がある」ことが挙げられます。このギャップは「重なり合っている領域の大小」がありその大きさによりプロジェクトの設計方針が変わります。重なりが小さい方が難易度が上がり、リサーチ結果から得られる施策案が既存事業のコンセプトが変わる可能性が高くなります。「既存事業のコンセプトは変化させ無い範囲で施策を検討する」ことを重視する場合、このギャップの重なりあう領域を意識します。
「重なり合っている領域が大きい」場合は重なる領域を整理したり拡張することがプロジェクトの目的になります。その場合、既存サービスをユーザーに使ってもらいユーザビリティー評価に注力した改善・改良を行うプロジェクト設計がおすすめです。逆に「重なり合っている領域が小さい」場合は重なりを大きくすることがプロジェクトの目的になります。その場合、事前に有力なユーザー課題仮説やソリューション仮説が有るか/無いかによって、さらにプロジェクトの設計を変えていくことが多いです。
前者の仮説がある場合、その仮説により「提供価値を再定義する」ことも視野に入ります。有力なユーザー課題仮説によって機能が大きく変わらない場合でもコンセプトが変化する可能性がありますので、その様な成果が事前に許容されるのか確認しておきましょう。後者の仮説がある場合「機能自体を大きく変化させる」ことになりますので、その変化が「既存のコンセプトに内包するのか？」「新規機能の開発に掛かる工数が許容されるのか？」などの制約条件が重要になります。有力なソリューション仮説を実現する開発工数が見込め無い場合、その様な成果を対象外となる様にプロジェクトを設計することになりますが、より難易度が上がります。
有力な仮説の方向性の目処がついている場合は、デザインスプリント形式がおすすめです。ライトなユーザー調査を元にソリューション案のプロトタイプを作りその結果をユーザーに当てて検証するプロジェクト設計になります。一方、有力な仮説が無い場合、ユーザーの課題探索型のプロジェクトを設計する事をオススメします。リードユーザーやエクストリームユーザーなどを対象にリサーチをしたりします。しかしながら、この場合は既存事業の改善・改良の範囲を超えるアウトプットになる可能性が高いので、社内でその様な成果が出た場合の合意を事前に得ておくことをオススメします。
6.2 共通認識を整え、局所最適化したサービスを整理する
次に紹介するのは、「共通認識を整え、局所最適化したサービスを整理する」事例です。同じUXという言葉で表現されていても、前編の図1.2.2で述べた様に（詳しくは1.2.2項を参照）用いる人や立場により、その解釈が異なることが多いです。その様な状況の中で、各担当者が事業成長のために各々最善の施策を積み重ねていくと、時として各施策の齟齬が事業成長を阻害する要因になってしまうことがあります。
その様な時は、共に意識しているUXが何を該当するのかの共通認識を揃えその齟齬を可視化することにより、優先度合いを整理して対策を検討する必要があります。 可視化の際は、ペルソナ等を用いて求める体験価値を明確にし、次いでサービスの機能や施策の提供価値をまとめ、ユーザー側と事業者側が両立する価値とその優先順を整理したり、時系列的にカスタマージャーニーマップなどで整理することが有効です。ここまでの共通認識を得た後、次に体験を毀損する施策については「事業貢献度」や「代案」の有無により、時に大胆に切り替える、もしくは、時間を掛けて徐々にシフトしていくことで理想のUXDに近い事業に整えることができます。
6.3 ビジョンと施策の中間目標となる提供価値を可視化する
最後に紹介するのは、「ビジョンと施策の中間目標となる提供価値を可視化する」事例です。 事業のビジョンは、「現状の機能や提供している体験価値の一歩先の理想の姿である」ときと「現状の機能や提供している体験価値から、大きくストレッチした理想の姿である」ときがあります。私としては、どちらのビジョンが良いと議論したい訳では無く、両方ともメリット・デメリットが存在するので事業の状況に合ったビジョンを選べば良いと考えております。今回ここで述べる「ビジョンと施策の中間目標となる提供価値を可視化する」のに相性が良いのは、後者です。
ビジョンが「現状の機能や提供している体験価値から、大きくストレッチした理想の姿である」ときは、大きなビジョンに対して、現状の施策や提供価値が一部しか担っておらず、空白の領域が大きい状況だと思います。その様な状況の中で改善・改良を行うには、その中間目標となりえる提供価値を可視化することにチャレンジするのが効果的です。そのプロジェクトの目的に応じて「既存事業のコンセプトを変えない」範囲で、時に「既存事業のコンセプトをある制約条件内で変える」範囲で、中間目標となる提供価値を定めることになります。特に有力な施策が中々見つからずに息詰まっている時は、既存事業のコンセプトの制約条件を広げ変える方向で検討する事をおすすめします。ビジョンが「現状の機能や提供している体験価値から、大きくストレッチした理想の姿である」ときのメリットは、大きなビジョンを目標に現状の制約に留まらずにストレッチした事業成長が望めることです。様々な制約条件があるとは思いますが、魅力的な大きなビジョンを掲げているのですから、個人的にはより可能性を広げて事業チャレンジして頂きたいと考えてます。
7.まとめ
以上、UXDが総論賛成、各論疑問になる理由、及び、UXDのプロジェクトを選定する時に意識する３条件を述べさせて頂きました ・レッドオーシャンのみの事業にならないために ・VUCAな時代に対応した事業を実現するために ・理性と情動を持つ人間に対応したサービスを設計するために デザインのアプローチをビジネスに使いこなすノウハウを今後も蓄積していきたいと考えております。次回以降は、デザインのプロセスを実践する基礎力を鍛えるために自社でチャレンジしている事例を紹介していきたいと思います。
