ユーザーテストの効果を最大化するための課題解決ガイドの中編です。

「ユーザーテストの効果を最大化するための課題解決ガイド（ゲーム業界の場合） 前編」も是非あわせてお読みください。

連載２回目の今回はユーザーテストを導入するメリットについてお話していきます。

テスト不要論の誤解：本当に必要な理由とは？

これまで、UX計画とそれを評価するためのユーザーテストがいかに重要かを話してきました。しかし、一方で根強く残る「テスト不要論」もあります。「お客様に何が欲しいか聞いていたら、『もっと速い馬が欲しい』と答えただろう」というヘンリー・フォードの有名な言葉のように、プロダクトはユーザーのリクエストに答えるべきではないという反論があります。この言葉は、テストにかかるコストの大きさとその効果への不信を隠すための言い訳に聞こえます。しかし、これらはすべてユーザーテストに対する大きな誤解です。

ユーザーテストはユーザーのリクエストを吸い上げるためのものでも、答え合わせをするためのものでもありません。ユーザーテストが必要な理由は混乱する価値や判断基準をまとめるためです。

混乱の原因は、セクションごと、版元ごと、関係者ごとに答えが存在し、そのどれにも一理あることです。すったもんだの末、最終的には権限の強い者の意見が勝利します。そのような判断方法では、例えばUIデザイナーが画面内の要素が多いと警鐘を鳴らしても、要素を増やしたいプランナーに勝ち目はありません。

そもそも、多数決で「こっちはプランナーの意見に合わせて、こっちはデザイナー」といういいとこ取りでは、総合的なサービスの質が上がるはずがありません。だからと言って、正しさを主張して強く反旗を翻せば、進行を妨げる因子としてプロジェクトから弾き出される可能性もあります。

本来、そういう時のためにユーザーテストは意味を持ちます。さまざまな意見がある中でユーザーの反応を元にした判断基準を与えることができます。

まずユーザーのジョブを解決できているのか、UX計画で意図したようなユーザーのアクションが起こっているのかを検証します。そこから、ユーザーは何に対してどう行動したのか仮説を立て、どのような課題があり、その課題を解決するために何をするのかというフローを通し、一貫した手続きで決めることができるのがユーザーテストです。

どの案が強いかではなく、何が課題かを理解した上でどうするべきかを決めていきます。ユーザーテストこそが課題に対してアプローチし、フェアな判断をすることができる手法であると言えます。

サービス品質向上の罠：本当の課題に目を向ける

開発者がこれまでの経験を踏まえ、それぞれのセクションの専門の知見をもとに品質をあげるのは難しくありません。ある程度、何をすればどうなるという築き上げたノウハウもあるでしょう。そのため、プロジェクトは技術的な品質ばかりを追い求めてしまう傾向があります。しかし、人が何かサービスを採用する時、品質以上に、そこにある課題を解決するという目的があります。サービス単体の品質を問うてしまうと、課題が抜け落ちてしまいます。

品質の誤解に関する有名な事例があります。ファーストフード店がミルクシェイクの売上を上げようとして、ミルクシェイクの購入者の特徴を満たすユーザーを集め、欲しいミルクシェイクについて尋ねました。

「ミルクシェイクのどこを改良したら、もっと買ってくれますか？」

その回答を踏まえ、チョコの成分量を増やしたり、値段を下げたりしましたが、売上や利益には何の効果もありませんでした。

そこで品質ではなく課題にフォーカスし、問いを変えました。

「どんな時に、ミルクシェイクを採用しているのか？」

その結果、わかったのは、シェイクを購入する客の半数以上がドライブスルーで、一人の客だということ。実際に購入した客にヒアリングしたところ、多くが運転中、片手で飲めて、時間をかけて消費できるからと言いました。つまり、商品の品質をいくら上げたところで、売上が上がらなかった理由がここにあります。対サービスではなく、ユーザーの生活から俯瞰して課題にフォーカスしなければ、この洞察は得られなかったでしょう。（クレイトン・M・クリステンセン他著,2017,ジョブ理論 イノベーションを予測可能にする消費のメカニズム）

定量評価の結果が良ければ次のプロセスに進んで良しというような判断をしたり、逆に評価が悪いことに対してリクエストを聞き入れることがなぜ間違っているのか、上記の事例で理解してもらえたのではないでしょうか。行き当たりばったりで機能追加や仕様変更をすると、後々、UXに致命的な悪影響を及ぼします。「何が何をなぜ引き起こすのか」というユーザーのアクションの手綱を握っていないと、その後、何がどんな影響を与えているのか分からなくなり、操縦不能でユーザーから振り落とされてしまうことが目に見えています。

ユーザーテストの重要性：なぜ初期段階で行うべきか

いつどのような頻度でテストをするべきかについてですが、ユーザーテストは初期にこそ大きな意味を持つと言われています。しかし、ゲーム業界では初期段階でのユーザーテストを実施しない傾向があります。その理由について、これまで関わった会社や他社の知人に質問してみました。

- 開発の機密保持（いろんな人を巻き込みたくない）

- 不完全な状態でのテストへの抵抗（何言われるかわからない）

- フィードバックによってビジョンを曲げられたくない（そもそも何も言われたくない）

- 開発スピードの重視（時間がかかるから嫌だ）

- 内部レビュアーへの信頼（プロならテストしなくてもわかるでしょ）

- コストの問題（高い...）

- これまでの開発手法を守っている（変えたくない）

- テストの効果への不信（効果あるの？）

どの理由ももっともな印象はあります。しかし、どうしてもユーザーテストがもたらす恩恵を無視して、やらない理由を探しているように感じてしまいます。

プロジェクトにとって何より恐るべきは、プロジェクトがユーザーに刺さらないという事態です。そして、やらない理由にも上がっていますが、開発スピードが落ちて、スケジュール通りにプロジェクトが進行しないことです。しかし、本来ユーザーテストは品質を上げ、後々発生する大きなリスクを回避し、スケジュール通りに進行させるためのものです。

データによると、巨大プロジェクトで工期通り完了するのは全体のわずか8.5%と言われています。予算、工期、便益ともにクリアするのはなんと全体の0.5%。予算超過は数%という生易しいものではなく、2倍3倍、10倍に膨れ上がるものもあるようです。ゲーム業界でいうと、スケジュール通りに完了するのは全体の10%程度にすぎないと言われています。

​​

巨大プロジェクトのリスク管理の第一人者であるベント・フリウビヤ教授によると、遅延の主要な原因は初期の準備不足にあると言います。IT業界では「考えるよりまず行動する」という言葉が美徳とされ、思い立ったら吉日とばかりトップギアで走り出すことは珍しくありません。しかし、フリウビヤ教授は、トンネルを作るべくとりあえず掘り始め、浸水して計画が頓挫する事例を引き合いに出し、巨大プロジェクトを予定通り進めるには前段階での検証に十分に時間をかけ、その後、素早く動くことが重要であると指摘しています。（ベント・フリウビヤ、ダン・ガードナー著,2024,BIG THINGS　どデカいことを成し遂げたヤツらはなにをしたのか？）

同じ事例はゲームの開発現場でも頻繁に耳にします。唐突にプロジェクトが立ち上がり、「ここを掘れば金脈があるので、とにかく掘り始めろ！」という趣旨の指令のもと走り出すのですが、開発が進んだ段階で「そこに金脈がないのでは？」というアラートが上がったりします。例えば、市場性がない、トレンドに合っていないなど、基本的な調査がされていなかったようなフィードバックが発生したりします。そうなるとトンネルは迷走を始め、あるいは穴の掘り直しをして、やがて、売り上げ見込みのないまま予算と工期は超過していきます。

ユーザーテストは今、掘ろうとしている場所が正しいのかを探るためのレーダーの役割を担っています。結果的に工期を低くしコストを下げ品質を上げることがユーザーテストの使命であると言えます。つまり、テストをやらない理由の多くはテストをやるべき理由であるわけです。そのような効果があるにも関わらず、スケジュール優先でテスト実施をしない、またはテスト後の調整をしないということがよく発生します。それが後々、大きなリスクとなり、かえって遅延になったり、サービス終了の原因となって返ってきたりします。あの時、修正できていたらと、何度、悔しい思いをしたことでしょう。

社内ユーザーテストの重要性：品質向上とノウハウ蓄積のために

テストを実施しない理由の大きな要因に費用問題があります。通常、社外にテストを依頼すると小規模のものでも150万円程度がかかります。これをプロセスを通じて最低でも2回、ベストを言えば機能ごと、あるいは大きく意見が割れて品質に影響が出そうな時など、もっとカジュアルにテストを実施できるのが良いと考えています。その方がUX品質を担保しやすいからです。

そんなに贅沢にテストをするのは、よほど潤沢な予算がある案件でなければ無理だと考えるのも無理はありません。ただ、社外に出すところを社内で実施すれば、費用は外部に出す場合の1/10程度で済みます。期間的にも、社内であれば通常1〜2ヶ月の準備が必要であるのに対して、最短1週間程度に短縮が可能です。

社内テストができる環境の構築は多くの場合、選択肢に入ってきません。それにはテストができる環境とノウハウが必要で、ハードルが高いと考えられているからではないでしょうか。しかし、社内でのテストをやることの価値は、実は工期やコスト以上に、まさに社内にノウハウがないからです。テストを外注する場合、そのノウハウは社内にはほとんど貯まりません。これには大きな問題があります。品質を上げるために肝心なUXの知見がブラックボックスになっており、社内に蓄積されていかないのです。

それでも、外部のテスト会社で精度の高いテストをしてもらえるのであれば、社内で質の低いテストを実施するよりは良いと考えがちです。しかし、丸投げのアウトソーシングでは、本当の質の高いテストをするのは不可能です。ただプレイテストをして感想だけをもらうくらいなら、高いお金を払ってテストをやる意味はありません。

本当に意味のあるテストを実施するには、テスト会社にプロジェクトと並走してもらい、仕様を理解して仮説を立ててもらう必要があります。ただテストを依頼しただけでは、課題の炙り出しやインサイト（洞察）の発見など、質の高いテストは期待できません。プレイできるデータを渡し、あとはよろしくという形式では、「おおかた楽しんでいました」というような集計程度の内容しか返ってくることはないでしょう。

外部だから自社よりも品質が高いというのも誤解です。ユーザーテストを代行してくれる会社は多くありますが、得意分野やテスト品質、分析によるインサイト提案の内容には大きくばらつきがあります。まさか専門の会社に間違いなんてないと思い込んでしまいますが、サンプルの取り方を間違えていたり、分析結果に偏差を考慮していなかったりということが普通に起こり得ます。それを鵜呑みにしてしまうと、対応としてはまったく逆の結果になることもあります。

とはいえ大規模テストや海外市場調査など、社内ではどうしても対応が難しいものもあります。ただ、社外に発注するにしても、少なくともテスト計画や社内での分析体制の構築など、テストに対するノウハウが蓄積される環境を整えておく必要があるでしょう。少々コストと時間をかけてでも、社内でノウハウを貯めるメリットは大きいのではないかと思います。

UXの品質改善に本気で取り組むのであれば、ユーザーテストのノウハウは必須です。ユーザーデータというエビデンスがなければ提案は単なる個人の意見でしかなく、ただでさえ様々な提案がある中、意見が増えるだけで、余計に混乱が生じます。テストをしないということは、UXデザイナーに武器を持たずに戦えと言うようなものです。そして、それはユーザー中心設計ではないという宣言をするようなことであり、開発においてUXデザインを否定していることと同じと言えるでしょう。

この方に記事を用意していただきました！