UX（ユーザー体験）担当のアンダーソンです。

前回 「Lean UX」モバイルゲーム開発 (1/2) では、モバイルゲーム開発と「Lean UX」の親和性についてお話ししました。 続いて今回は、「Lean UX」を使用した開発サイクルを一つ、できるだけ具体的に紹介したいと思います。

モバイルゲーム『プロジェクトA』（仮称）で、Lean UXを試してみた

定量データだけではなく、定性データも活用して課題を特定する

従来、『プロジェクトA』ではDAU、ARPUといった定量データに基づき、日々サービスの改善を行っていました。 ところが、そういった定量データからは「何が起きたか」という事実は分かっても、「プレイヤーがなぜその行動を起こしたか」という部分を明らかにすることが出来ません。 その結果、講じられる解決策が定量データから導かれた企画者による想像の枠を超えず、そもそもの問題が明らかにならないまま検証が進むことになってしまいます。

そこで、問題の「なぜ」を明らかにするためにUXチームがプロジェクトに参加することになりました。

Lean UXはビジネスとお客様のニーズを重ねるフレームワーク

UXがサービスに提供できる一番の価値は「お客様のニーズとビジネスニーズの重なり具合」（＝サービスを良く出来そうなポイント） を見つけ出すことだと私は考えてます。

定量的データは「どのように(UI）」ユーザーがサービス／ゲームを使用しているかを明確にしますが、「なぜ（UX）」それが起きているかを明示してはくれません。 そこで、サービスに一番分かりやすい形でUXを浸透できるあろう「Lean UX」プロセスに基づいて、 まず『プロジェクトA』でLean UXサイクルを回してみることにしました。

Lean UXサイクルの4つのステップ

1. 仮説を作成
2. MVP（minimal viable product)の開発
3. 仮説の検証
4. ユーザーが行った行動の分析・仮説の修正

ステップ1： 仮説を作成

サービスを改善しようとするとき、まずは「どこから改善すればいいか」という点が最初のハードルとなります。Lean UXでは、この課題に対する最初のステップとして、「課題を解決する」ための開発ではなく、「課題を見つけ出す」ための開発を行うことを挙げています。

課題を見つけ出すためにはまず、仮説を作ります。 Lean UXでは、「未知であって、外れた時のリスクが高い仮説ほど、検証プライオリティーが高い」としており、つまり「この前提が間違ってたら、サービス（今回のプロジェクトの場合、ゲーム）が破たんする」というくらい、そのサービス価値に強い影響を持つにも関わらず、明らかになっていない部分を考えてみます。

1. 未知なポイントをチームで発見

   今回の『プロジェクトA』のUX改善においては、まず自分たちが制作したゲームを様々な視点から見て「未知なポイント」を発見する必要がありました。 そこで、ゲームのステークホルダーと開発メンバーでワークショップを行ってみた結果、 「プレイヤーはなぜ『プロジェクトA』を毎日遊ぶのか」という、かなり本質的な疑問に対する解答が 人によって意見が異なり、チーム内の共通認識として明らかになっていない状態でした。

   そのような異なる意見をまとめるため、一人ひとりの考えを聞き出し、ポストイット書いて壁に貼っていきました。チーム全員が思ってることを可視化することによって、ディスカッションがさらに深まり、そしてそれらを俯瞰して見ることにより「ユーザーに刺さる点／ユーザーがゲームにハマるポイントは××でないか？」という仮説に対して総意を取ることが出来ました。



2. 仮説を具体化する

   Lean UXで使用される仮説は、各Lean UXサイクルで重要な役割を持ちます。仮説は、

   • MVPにおける唯一かつ最重要となる要件
   • ディスカッションでの判断基準
   • 分析の対象

   という要素となるので、誰が見ても簡単に理解でき、人によって解釈がぶれないものにするのがキーとなります。

   Lean UX 仮説テンプレート	今回の仮説
   『私たちは＜テスト対象者の基準＞に対して＜検証内容＞を行うことで、＜この定性的又は定量的な反応と結果＞を得ることができると考えます』	『私たちは、プロジェクトAにおける○○というターゲットに対して、XXXを強調するチュートリアルを遊んでもらうことで、 プロジェクトAが△△なゲームである事を理解し、□□の機能を繰り返し使ってもらえると考えます』 ※実際のプロダクトのため、具体的な内容は記号で伏せさせて頂きます。

この仮説のもとで、プロトタイプ（MVP）の作成に入ります。

ステップ2： MVP（minimal viable product)の開発

Lean UXのサイクルに基づき、仮説の作成後には、その仮説が正しいか確認するためユーザーテストを行うことにしました。 検証のターゲットユーザーを集め、実際にゲームを遊んでいるところを観察し、 相手の発言や行動について直接聞く事によって、「なぜ」その行動を行ったか確認できるからです。

今回は最低限のリソースでMVPを試したかったので、簡単なモックアップを作ることにしました。



1. モックアップの要件を定義する

   今回はウェブゲームのチュートリアル検証を実施しようと、以下の要件を定義しました。

   • 世界観を伝えるため、グラフィックを本番用の見た目に近づける
   • 動きが重要なポイントはアニメーションを含ませる
   • 操作が必要なポイントは遊べる状態にする
   • 直接スマートフォンで操作できる
   • アプリではなく、ウェブブラウザで使用するゲームなのでスクロール必須
   • サーバーとのデータ通信は必要ない
   
   
2. モックアップのfidelity（忠実度）を選択

   モックアップと一言に行っても、その形式は様々です。 チラシ裏のスケッチレベル（低い忠実度）や、ワイアーフレームやデザインを印刷して 紙芝居のように操作するペーパープロトタイプ（中レベルの忠実度）や、ほぼ本番と同じグラフィックで スマートフォンで操作するモックアップ（高い忠実度）まであります。

   
   

   今回の仮説を試すには世界観を本番に近い状態で表現することが重要だったため、 グラフィックのクオリティーが高い、High Fidelity (高い忠実度)のモックアップを作ることにしました。



3. 協調的デザインでモックアップを作成する

   モックアップ作成のフェーズでは、毎日決まった時間にチームが集まり、ディスカッションしながら物事を決めていきました。

   • Structure（コピー、流れ、コンテンツ）をワイアーフレームで作成
     最初はポストイットや紙とペンで、みんなでワイアーフレームを書き上げました。 その後、チームのディスカッションで大体のコンテンツとユーザーに体験させたいことが決まり、 次はデザイナーメインでコンペの形でブラッシュアップを行いました。
   • Look & Feel （グラフィック）の作成
     役割分担については、チームで決定しながら進めました。担当のデザイナーがワイアーフレームからグラフィックを作成しながらチームでレビューし、コピーは企画者が作りました。
   • Ready Deployment（使用可能のレベルまで仕上げる）
     最後のフェーズでフラッシュアーティストとエンジニアの協力を得て、 モックアップを仕上げました。
   
   
   

   この段階で最も大事なことは、「ウォーターフォール式」のコミュニケーションを無くすことです。 伝言ゲームのようなコミュニケーションでプロジェクトを進めると、 メンバーが情報を誤解する確率、全体が見えないため漏れが発生する確率、そして「渡された事をそのままやるだけ」の確率が上がります。 Lean UXでは、スクラム式で、チームのスペシャリスト達のノウハウを早いタイミングでピックアップしながら進めます。

   
   
   

ステップ3： 仮説の検証

モックアップが出来上がったら、実際にユーザーに触ってもらい、仮説の検証を行います。
(Lean UXでは、プロジェクトメンバーでなく、実際のユーザーによる検証こそが問題解決に有効としています)

1. 検証方法を決める

   検証方法は色々ありますが、定量的検証と定性的検証に別れます。

   • 定量的検証　＝　何が起きてるか調査する（例：ABテスト）
     
   • 定性的検証　＝　何故起きてるか調査する（例：ユーザーテスト）

『プロジェクトA』では「何故」を検証したいため、定性的な検証を行うことにしました。



2. 選択した方法で検証を行う

   今回は定性的検証を行うべくユーザーテストを選択しました。ターゲットを数名集め、一人一人にモックアップを触ってもらい、それを観察します。

   ここで重要なのは、どんな事実が発見されても、人は自分の目で見ないと納得しません。 なのでユーザーテストでは絶対に、ステークホルダー、そして出来ればプロジェクトに参加されたメンバー全員が参加することが大事です。

   • 観察するポイント
     • 相手の行動、発言
     • 相手の表情
     • 各アクションに要した時間
     • 相手の期待と実際起こったことの差
   • 質問するポイント
     • 行ったアクションのモチベーション、理由

次はユーザーテストで集めたインサイトを分析します。

ステップ4： ユーザーが行った行動の分析→仮説の修正

1. 仮説が正しかったか確認

   ユーザーテストの観察によるインサイトをあつめ、仮説を確認します。

   1. 仮説は正しかったか？
   2. なぜ仮説は正しかったか／間違っていたか？


2. 結果にそって次のサイクルの内容を決める

   今回は、検証によって、最初に立てた仮説が正しかったと判断しました。その場合、次のサイクルでは、本番へリリースし定量的情報で検証します。 もし仮説が間違っていた場合は、また別の仮説を試すフェーズに入ります。

まとめ

今回の『プロジェクトA』の検証では、ある機能の使いやすさと理解しやすさを改善することによって、アクティブユーザーが数パーセント上がることが分かりました。 このように、定量的データ／定性的データ／作り手の「勘」を組み合わせることで、サービスの質をスピーディーに向上させることが出来ます。

Lean UXはフレームワークであり、答えではない

いままで「Lean UX」のフレームワークについて話をしてきましたが、残念ながらフレームワークは、ユーザーから答えを導く魔法ではありません。 フレームワークを使うことによる発見は多くありますが、一番大事なのは「なぜそのフレームワークを使う必要があるのか」を、強く意識することだと考えてます。

Lean UXでは、プロジェクトや組織の中で「ユーザーやビジネスに対してより良いデザインを生み出す」ために「協調的なデザイン文化」を生み出そうとしており、 メンバーが適切なゴールに向かって開発し、葛藤や無駄を排除して、よりクリエイティブなエネルギーが発揮できる環境作りに効果を発揮します。 Lean UXは、様々なヒントや気づきを与えてくれる先生のような存在と言えるでしょう。

さて、そんなLean UX先生による重要な教えは以下の2つです。

1. 自信が無くてもはっきり「これが答えだ！」と具体化しよう！
   Leanは、リスクと工数を削減しすることで、物事を安く手軽に進めようとするものではありません。 ユーザーとビジネスが絡む具体的なストーリーアイディアを前提として、削減すべき箇所を明らかにする仕組みです。
   
   問題点や解決策の具体的なイメージがない場合、どうしても物事はビジネスニーズ優先で進み、ユーザーとの長期的な関係が作られにくい状態に陥ります。 そのような状態を回避するためには、たとえ証拠や根拠がなくても、まずは検証するアイディアが必要です。



2. 実は全然間違っていた！というポイントをどんどん暴き出そう！
   UXの検証では、「ビジネスがユーザーに体験してほしいこと」と「現実的にユーザーが体験していること」のギャップを観察し、 そこからイノベーションを生むことがポイントとなります。
   
   要約すると、ユーザーを中心とし、 「仮説→仮説の検証用の開発→仮説の検証→分析」というサイクルを繰り返し続けることによって、 高リスクの失敗を、なるべく影響範囲の少ないタイミング・形で行うことが出来ます。 自分の中にあるバイアスを最小限に抑え、どうしたら相手の本音を探り出せるか。 そこから、本当のLean UXが始まると考えられるのです。




誰しも失敗は怖いものです。 
初めて自転車に乗れた体験を思い出してみれば分かりますね。工学と物理を本から学び、 最高の自転車を買って乗ったからといって、始めから自転車に上手く乗れるわけではないのと同じです。 自転車に乗れたのも、何度も失敗を重ねて学んだからであり、アイデアやメソッドにおいても、 失敗による「学び」が前進してゆくための重要な経験となるのです。



このような協調的なマインドを取り入れるため、Lean UXフレームワークを試してみるのはいかがでしょうか。

Lean UXの詳細は、以下のリンクを読むとより理解できます。

• リーン・スタートアップ エリック・リース(著)
• Lean UX ―リーン思考によるユーザエクスペリエンス・デザイン ジェフ・ゴーセルフ (著)