ゲームやモバイルアプリのように高速で時にアジャイルな方法を取る開発現場においては、分析やリサーチのリードタイムが時にネックとなる場合があります。そういったリードタイムに起因する課題解決の「遅延」を可能な限り抑えるために様々な工夫が開発やテストの現場ではなされているわけですが、今回はそういった工夫のうちの1つである RITE (Rapid Iterative Test and Evaluation) という手法を紹介したいと思います。
RITE の思想的背景
RITE (Rapid Iterative Test and Evaluation: 高速反復テストと評価) とはその名の通りスピードや1つ1つのサイクルが短い開発環境の中で効果的にリサーチを用いて課題を解決していく手法のことであり、手法そのもののことを指すこともあれば、その手法が体現している哲学を指すこともあります。その背景にある哲学はシンプルで、以下の2つだけです。
- 問題を見つけたら可及的速やかに解決すること
- 意志決定者を調査チームの一員にすること
この哲学はリサーチとデザインの分断をうまく橋渡ししたものであり、RITE はそれゆえにリサーチ技術であると同時にデザイン技術でもあると言えます。この RITE の哲学は従来のリサーチャーにとって「信頼性」や「確実性」といった概念の再考を促すものでもあります。なぜならば、後述しますが RITE は n=1 の結果であってもそれをもとに迅速に仮説を検証してスピーディーに改修を行い、それをすぐに次の試験者でテストして改善点をシューティングしていく......といったアプローチをとるため、いわゆる「真実の追究」とは異なった観点からテストを推進していくためです。
実際のビジネスの現場では限られた情報から仮説を構築してスピーディーに課題解決を推進していくことがほとんどであり、十分な情報や分析を踏まえたうえで意思決定ができるケースはまれになります。特にゲームやアプリの開発といった高速に物事が進む世界ではなおさらであり、ここにビジネスの現場にて RITE が力を発揮するポイントがあると言えるのです。
RITE の定義
RITE メソッドはユーザビリティテストの一部であるため、当然のことながら DUmas と Redish によって述べられているユーザービリティテストの原則を継承しています。すなわち、ユーザビリティテストとは、
- プロダクトの改善が目的である
- テストの参加者は実際のユーザーである
- テストの参加者は実際のタスクを行う
- テストの参加者が行い、述べたことを観察し記録する
一方、RITE は「スタンダードな」ユーザビリティテストとは以下の3つの点で異なっています。
- データは個々のテスト参加者、ないしは少なくとも各日のテストが終わった段階で分析される
- ユーザーインターフェースの変更は問題が同定され、考えられる解決策が明確になった段階で即座に行われる
- 変更されたインターフェースは後続のユーザーによってテストされ、先に挙がった問題が新たな問題を生むことなく解決されているかが確認される
そのため、RITE メソッドを効果的に実行するためにインターフェースは常に速やかに変更可能な状態である必要があります。それを担保するためには変更にかけるリソース、ならびに変更に対する政治的 / 組織的なウィルが前提となってきます。そのため、調査チームの中にエンジニアやデザイナーといった改修の担当者が入っていることはもちろん、その変更を判断する意思決定者が含まれている必要があり、これが上述の哲学の2番目に繋がってくるわけです。
RITE の適用
RITE メソッドを用いてテストを行う場合、Excel やスプレッドシートで以下のような表を作ってテストと課題解決を管理していくと Games User Research では述べられています。
シートは縦軸が各課題を、横軸が各参加者を表しており、×がつけられた箇所はその列の参加者が、当該の課題に当たったことを表しています。また、青や赤で塗られているところは、当該の課題に対する修正を行った後、1回で課題が解決されたもの (=青色) と、当該の課題に対する修正を行ったものの、課題が解決されず、2回目の変更で課題が解決されたもの (=赤色) を意味し、
それでも課題が解決されないままのものが灰色でマークされています。また、参加者を区切っている縦軸の太線はテストの日付の別を表しています。
このシートを例に述べると、1つ目の問題 (プレイヤーがユニットをどう選択すればよいかわからない) は最初の参加者のテストによって見つかり、その後すぐに修正、その後は同じ問題が発生しなかったためその修正によって問題は解決されたと言えます。また、2つ目の問題は4番目、6番目、10番目の参加者によって見つかったものの、チーム側で問題の優先度が高くないと判断した、ないしは修正の難易度が高いと判断したため、テスト期間中には修正の判断を行わなかったものになります。4つ目の問題は1人目、2人目の参加者によって見つかり、2日目に修正されたものの、3日目に4人目、5人目の参加者によって再度問題となったことから再修正を行い、その後解決されたものを表しています。
このようにして、極めて短いサイクルでテストと修正を繰り返し、個々の問題を潰していくことで RITE はプロダクトの改善に貢献すると言えます。
RITE の実例
Games User Research の本の中では、実際に RITE メソッドを用いて Age of Empire II のチュートリアルを改善した事例が述べられています。
背景として、Age of Empire II では、ゲームの面白さを失うことなく (=メカニクスを単純化することなく)、よりマスに向けた訴求を行うために複雑なゲームシステムをいかにライトユーザーにも理解してもらうかという課題のもと、チュートリアルの改善に RITE メソッドを適用しました。まず、開発チームとユーザーリサーチャーが共同して、例えば「ユニットの動かし方とリソースの集め方を覚える」といったように、ユーザーが Age of Empire II のチュートリアルを終えた後に行えるようになるべきタスクとコンセプトを洗い出したうえで、それをユーザーが達成するにあたって障壁となる課題が全て潰せるよう、意思決定者を巻き込んで RITE メソッドでのテストを実行しました。各々のテスト参加者がテストを終えた段階でチームはリサーチャーと協議し、課題の確認と以下のようなシューティングを行いました。
- 課題の修正を試み、新しいプロトタイプを残りの参加者に遊んでもらった
- 新しいプロトタイプが出来上がると即座に、それを残りの参加者に遊んでもらってテストを行った
- 課題修正が行われる前により多くのデータを集めた (より多くの参加者にテストしてもらうなど)
この方針を取って RITE メソッドでチュートリアルの改善を行うことで、Age of Empire II のチュートリアルは次第に洗練されていき、テストの最初の参加者では 2～3個の Failure (ユーザーがゲームのルールを理解できず、進行が滞るケース) と 10個前後の Error (最終的にはユーザーの方でルールを理解できたものの、それを理解するまでにストレスや苛立ちなどユーザーにとって過剰な負荷が発生したケース) があったのに対し、10人目以降では 0個の Failure と 0～1個の Error にまで洗練することができたそうです。
おわりに
ゲーム開発のようにイテレーションのスピードが速く、高速なPDCAが求められる環境においては、本記事で紹介したような RITE メソッドが有効である場合があり、本記事ではその概要と Age of Empire II での事例を紹介しました。
ちなみに、本記事で紹介した RITE メソッド (と Age of Empire II の事例) は主に UX Design の領域で他でも取り上げられており、この手法が浸透することでより UX デザインやリサーチを通じたプロダクト改善の事例が生まれてくるとよいなと、1業界人としては思っています。
アジャイル・ユーザビリティを読んだ。 - hiromitsuuuuu.log();
