無料追補版#1「RITEメソッド」
•
18 likes•62,363 views
樽本徹也(著)「ユーザビリティエンジニアリング（第2版） ―ユーザエクスペリエンスのための調査、設計、評価手法」（オーム社、2014年）の無料追補版第一弾です。 ※樽本徹也(著)「ユーザビリティエンジニアリング」は累計刷数1万部を超える、日本で最も読まれているUX/ユーザビリティ関連書籍の一つです。ユーザ中心設計（人間中心設計）のプロセスと手法をこれ1冊で学べます。「UX/ユーザビリティについて学びたいときに、最初に手に取るべき1冊」として、2005年の初版刊行以来、10年にわたって長く読み継がれています。
Recommended
More Related Content
More from Tarumoto Tetsuya
More from Tarumoto Tetsuya (20)
無料追補版#1「RITEメソッド」
- 1. 近年、アジャ それが“RI 法は米マイ パイアⅡ」 高速反復 その最大の特 です。RITE 結果からで されている事 6 回の UI 変 グラフの縦軸 つまり、1 人 と 2 つの失 ます（エラ ーザが立ち往 徐々に減少 ロになってい グラフ内の縦 表しています を観察した後 ちょっと目 が増えてい ャイルUCDや TE”―― R クロソフトの （1999 年発売 特徴はテス E メソッドで も果敢に U 事例では、1 変更を行って 軸は問題点の 人目の被験者 失敗（failure ー：ユーザが 往生した場合 して、12 人 います。 縦の実線は す。つまり、 後に UI を変 を引くのは る場合があ やリーンUX Rapid Iterat のゲーム開発 売）のチュー トと UI 変更 では、たった UI を変更しま 16 人のテス ています。 の数、横軸は 者では 7 つの ）が観察され が戸惑った場 合）。その後 目以降はエ UI の変更の 被験者 1, 2 変更していま UI の変更後 るというこ RIT Xに取り組む tive Testing 発部門で 199 ートリアルの 更の“高速反復 た１人のテス ます。論文で ト実施期間中 は被験者数で エラー（erro れたことにな 場合。失敗 、問題点の数 ラーも失敗も のタイミング 2, 5, 8, 9, と ます。 後に問題点の とです。これ 樽本徹 -1- TE メソッ む実務家がし g and Evalu 90 年代後半 の開発にこの 復” スト で示 中に です。 or） なり ：ユ 数は もゼ グを 10 の数 れは 「修 除く でき た問 従来 199 『デ のと 「5 当時 現代 い” 5ユ よう 1. 2. 3. 4. 5. 6. 意外 ぜな 時点 です 当し 当は 徹也(著)『ユー ッド しばしば言及 uation：高速 半に確立しま の手法を活用 修正ミス」で くことで、ユ きるようにな 問題点が明ら 来の手法と 90 年代前半 ディスカウン とおり“お手 5 人のユーザ 時とすれば画 代のソフトウ ”のです。 ユーザテスト うになります 5 人テスト データを分 発見された UI を修正 5 人テスト たな問題発 問題解決と 外にも“5 人 ならば、実際 点で問題点が す。多くの場 したユーザビ はついていま ーザビリティエ 及するユーザ 速反復テスト した。彼らは 用しています ではありませ ユーザが UI なるので、そ らかになった との違い 半にヤコブ・ ント・ユーザ 手軽”なテス ザでテストす 画期的なアイ ウェア開発の でUIを改善 す。 トする。 分析する。 た問題点に対 する。 トする（解決 発見）。 と問題発見を 人”がボトル 際にはもっと が明確になる 場合“3 人” ビリティエン ます。ところ エンジニアリン ザテスト手法 評価 ――で は「エイジ す。 せん。ある問 I をさらに それまで観察 たという意味 ニールセン ザビリティ』 ト手法の先 すれば OK！」 イデアでした の現場では、そ 善するプロセ 対する解決案 決案の効果検 を繰り返す。 ルネックにな と少ない人数 る場合が少な 観察すれば ンジニアはお ろが、ニール ング(第 2 版)』 無料追補版① があります。 です。この手 ・オブ・エン 問題点を取り “深く”使用 察されなかっ 味です。 ンが提唱した は、その名 駆けでした。 」というのは た。しかし、 それでも“重 セスは以下の 案を考案する 検証および新 なります。な 数を観察した なくないから ばテストを担 おおよその見 ルセンの手法 ① 。 手 ン り 用 っ た 名 。 は、 重 の る。 新 な た ら 担 見 法
- 2. に実直に従 に、5 人分 ません。（な 断して、す た。） 一方、RITE 果であって に取りかか した新しい れを繰り返す ユーザビリ のです。 RITE メソ このように書 たくなるか には、必ずデ まず、「1人」 これはかな です。通常、 UI の問題に （偶然、ク な不確かなデ 繰り返すと、 それを回避す 経験――同種 豊富な経験― 例の積み重 ある程度正 もう 1 つの RITE メソ るまでに、 いけません。 くて 1 時間 えば、問題発 のデータが集 なお、実際に ぐに改善に取 E メソッドで も、問題点が ります。そ UI を提示 すと、十数名 ティ問題は全 ッドの前提 書くと、早速 もしれません デメリットが の観察結果 り困難であ 、「1 人」の に起因するの セなど）なの データを根拠 、設計が“右 するために 種の UI を ――が求め ねがあれば、 しい判断が下 の課題は「開 ッドでは 2 開発者は新 。通常、テス 間程度しかあ 発見の精度を 集まるまで次 は 3 人目まで 取り掛かるこ では、たとえ が明白になっ して、次のユ してテスト 名のテストが 全て発見・解 提条件 速 RITE メ ん。しかし、 があります。 で判断する り、かつリス ユーザの行動 のか、そのユー のか判別でき 拠にして闇雲 右往左往”し は、設計チー 同種の被験者 られます。十 、少ない観察 下せるでしょ 発能力（早 人目の被験者 しい UI を用 スト間のイン りません。そ を保証するた 次の行動に移 でのデータで ことはありま え 1 人の観察 った時点で改 ユーザには修 を続けます。 が終わる頃に 解決されてい ソッドを実践 、メリットの という点です スクの高いこ 動では、それ ーザ固有の問 きません。そ 雲に UI 変更 しかねません ームにかなり 者でテストし 十分な過去の 察事例からで ょう。 さと質）」で 者が会場に現 用意しなくて ンターバルは そのわずかな 樽本徹 -2- ため 移れ で判 まし 察結 改善 修正 。こ には、 いる 践し の陰 す。 こと れが 問題 そん 更を ん。 りの した の事 でも です。 現れ ては は長 な時 間に ので せん 変更 もし さら ブ・ いま ます れだ ェク 確か ない RIT アジ い 言え るよ 例え 下の うパ 正を また デル 徹也(著)『ユー に、改善案を です。ペーパ んが、動的な 更はシステム しれません。 らに、「期間 ・エンパイア ますが、その す。実際には だけの人的・ クトはそう多 かに“高速反 いのです。 TE メソッ ジャイル開発 RITE メソッ えば、それは ように改変し えば、米 Go のように 1 日 パターンと、 を 2 回繰り返 た、「The $1 ルマンは、行 ーザビリティエ を検討・決定 パープロトタ なプロトタイ ム上の深刻な 」の問題も アⅡ」の例で のためには通 は、ユーザテ ・時間的リソ 多くありませ 反復”ですが ドの現在 発が全盛の現 ッドが改めて は実務家が現 して使ってい oogle の And 日で 5 人のテ 2 日間で 3 返すパターン Prototype」 行きつけのコ エンジニアリン 定して、実装 タイプならば イプの場合、 な不具合を引 あります。 は合計 16 人 通常 3 日から テストのため ソースを費や せん。RITE が、決して 現代に、あま て注目されて 現代の開発環 いるからです droid 開発部 テストと 5 回 3 人のテスト ンを使い分け 」の著者グレ ーヒーショ ング(第 2 版)』 無料追補版① 装を完了する ば問題ありま 拙速な設計 引き起こすか 「エイジ・オ 人テストして ら 4 日を要し めだけに、そ やせるプロジ メソッドは “軽量”では まり軽量でな ているのかと 環境に適応す す。 部門では、以 回の修正を行 トと 1 回の修 けています。 レッグ・ヌー ップで“客” ① る ま 計 か オ て し そ ジ は は な と す 以 行 修 ー
- 3. 樽本徹也(著)『ユーザビリティエンジニアリング(第 2 版)』 無料追補版① -3- にコーヒーを奢ってテストに協力してもらう「コ ーヒーショップ・テスト」を提唱しています。付 箋紙で作ったペーパープロトタイプを用いた 5 分 前後の短いテスト（かつ、その場での迅速な修正） を 15～20 人繰り返して、数時間で UI の改善を完 了してしまいます。 その他にも、会社の同僚を“廊下”でリクルート してテストに協力してもらう「ホールウェイ・テ スト」や、社員食堂で行う「カフェテリア・テス ト」は米国の IT 企業やスタートアップでは広く行 われています。 RITE メソッドの本質 実は、オリジナルの RITE メソッドは 1990 年代 後半に確立した言わば“古典的”なテスト手法の 1 つです。当時とは大きく状況が異なる現在の製 品開発環境に、そのまま持ち込むべきものではあ りません。ただ、RITE メソッドの理念そのもの は、今も色褪せることはありません。 従来、ユーザビリティの専門家は「何人のユーザ をテストすれば何パーセントの問題が発見できる のか」という“精度”の議論を延々と繰り返して きました。しかし、どんなに正確に問題を発見で きたとしても、それを修正できなければ意味はあ りません。 そこで、RITE メソッドでは発想を転換していま す。つまり「問題発見の精度よりも問題解決を優 先」したのです。そして、小さなテストを繰り返 し行い、問題が見つかるたびにそれを修正してい くことにしたのです。これは、まずテストを書い て、そのテストをパスするようにコードを記述す る『TDD（Test Driven Development）＝テスト 駆動開発』という現代のアジャイル開発のプラク ティスを彷彿とさせます。 そもそも、私たちの仕事は「立派なテストを実施 （そして分厚い報告書を作成）」することではあり ません。私たちの本当の仕事は「高品質な製品を 開発」することであるはずです。ユーザテストは、 そのための手段の１つに過ぎません。ですから、 どんなテストであったとしても、製品の品質向上 に貢献すれば“それで十分”なのです。 【参考文献】 Michael C. Medlock 他：「Using the RITE method to improve products; a definition and a case study」 樽本 徹也：「アジャイル・ユーザビリティ」、 オーム社、2012 年 Miki Konno, Bethany Fong ：「 Agile UX Research Practices in Android」、Google I/O 2013 Greg Nudelman ：「 The $1 Prototype: A Modern Approach to Mobile UX Design and Rapid Innovation for Material Design, iOS8, and RWD」、DesignCaffeine Press、2014 年