---
title: "RITEメソッド（RITE法）とは？従来のユーザビリティテストとの違いと進め方"
url: "https://www.issoh.co.jp/column/details/7834/"
published: 2025-07-23
updated: 2026-10-04
categories: ["Webサイト"]
publisher: "株式会社一創"
---

# RITEメソッド（RITE法）とは？従来のユーザビリティテストとの違いと進め方

RITEメソッド（Rapid Iterative Testing and Evaluation、RITE法）は、[ユーザビリティ](/column/details/6865/)テストの途中で問題の原因と解決策が明らかになった時点でUIを直し、次の参加者で修正の効果を確かめる手法です。2002年、Microsoft Games Studiosのユーザビリティ担当者らが、ゲーム「Age of Empires II」のチュートリアル開発での実践を論文にまとめ、この名前を付けました。

全員のテストを終えてから報告書を書く従来型と比べると、目的が「問題を漏れなく見つけること」から「問題を直し、直ったことを確かめること」へ移っています。本記事では原典論文の定義と実測値をもとに、従来のユーザビリティテストとの違い、修正するかどうかを決める4分類、修正の効果を確かめる人数の計算、向かない条件を整理します。

## まとめ：RITEメソッドの要点

- **定義**：テスト中に原因と解決策が明白な問題をすぐ直し、残りの参加者で修正を検証するユーザビリティテスト（Medlockら、2002年）
- **従来型との違い**：UIを直すタイミング（全セッション後からセッションの合間へ）と、参加者数を決める基準（問題の発見から修正の検証へ）
- **進め方**：全員が例外なく完了すべきタスクを事前に合意し、観察した問題を4分類して、原因も解決策も明白ですぐ直せるものだけを次の参加者までに直す
- **原典の実測**：16人・6回の改版で、見つけた問題31件のうち30件を修正した。修正36件のうち6件はやり直しが必要だった
- **向かない条件**：開発側の意思決定者が修正判断に関与できない、小さな修正もテスト期間中に反映・再検証できない、発生率の低い問題の見落としが許されない（医療機器の総括的評価など）

## RITEメソッドの定義と原典論文

原典は、Michael C. Medlock、Dennis Wixon、Mark Terrano、Ramon L. Romero、Bill Fultonの5人が2002年に発表した論文「[Using the RITE method to improve products; a definition and a case study](https://citeseerx.ist.psu.edu/document?repid=rep1&type=pdf&doi=5340ef8a91900840263a4036b0433a389b7097b2)」で、Usability Professionals Association（UPA）2002年大会の論文として引用されています。所属はMicrosoft Games Studios（Medlock・Romero・Fulton）、Microsoft（Wixon）、Age of Empires IIを開発したEnsemble Studios（Terrano）でした。

論文は、新しい手法を発明したのではなく、現場で既に行われていた進め方に名前と定義を与えたものだと自ら述べています。Microsoft社内と公開メーリングリストのユーザビリティ担当者への簡易調査では、39人中33人が、ごく短い間隔で修正と反復を回す同様の方法を少なくとも1回使ったと答えました。2005年には、MedlockとWixonがMick McGee、Dan Welshと共著で、書籍『Cost-Justifying Usability』第2版（Bias・Mayhew編）の第17章「The Rapid Iterative Test and Evaluation Method: Better Products in Less Time」を書き、3件のケーススタディとともに費用対効果の観点から論じています。

### RITEメソッドが解こうとした「直されない」4つの理由

原典は、ユーザビリティテストで見つかった問題が製品で直されない理由を4つ挙げ、RITEをその対策として組み立てています。

1. **問題が信じられない**：意思決定者が、見つかった問題を現実のものと考えない
2. **修正に時間と人手がかかる**：動いている機能の修正より、新機能の追加が優先される
3. **フィードバックが遅い**：機能の判断が済んだ後に届いた指摘は採用されにくい
4. **解決策が効くか分からない**：修正の効果が検証されていないため、手間のかかる修正に踏み切れない

意思決定者のセッション同席は1、修正用の開発工数の事前確保は2、参加者ごとの修正判断は3、次の参加者での検証は4への対策です。手順の一つひとつがこの4つのどれかに対応しているため、同席や工数確保を省くとRITEの前提が崩れます。

## 従来のユーザビリティテストとRITEメソッドの違い

対象ユーザーを決めて参加者を集め、タスクの台本を作り、思考発話（think aloud）で行動を観察する点は、従来のユーザビリティテストと変わりません。違うのは、観察した問題をいつ直すかと、何のために参加者の人数を決めるかです。

| 観点       | 従来のユーザビリティテスト | RITEメソッド           |
| -------- | ------------- | ------------------ |
| UIの修正    | 全セッションの終了後    | 原因と解決策が明白なら次の参加者の前 |
| テスト中のUI  | 全員が同じ版        | 途中で版が変わる           |
| 人数を決める基準 | 問題を発見できる確率    | 修正が効いたと確かめられる確率    |
| 主な成果     | 問題の一覧と改善提案    | 修正済みのUIと修正の検証結果    |
| 意思決定者    | 報告を受け取る       | セッションに同席し修正を決める    |
| 問題の発生頻度  | 同じ版なので集計できる   | 版が変わるため集計しにくい      |

本質的な違いは人数の考え方にあります。NielsenやLewisも、大人数のテストを1回行うより少人数のテストを何度も回すほうが効率的だと勧めていました。Nielsen（2000年）は15人を1回テストするより5人ずつ3回に分け、各回の間に再設計するよう勧め、2回目以降を修正の品質保証と位置づけています。原典はこれと区別し、RITEは決まった人数を終えるごとに修正するのではなく、修正の検証をテストの最中に計画する点が違うと書いています。

従来型を選ぶべきなのは、改修前後で同じタスクの完了率や所要時間を比べたいときや、問題の発生率そのものを報告する必要があるときです。RITEは途中で版が変わるため、「何人中何人がつまずいたか」をUI全体の指標として出せません。

## RITEメソッドの進め方と修正判断の4分類

### 事前準備：例外なく完了すべきタスクの合意

テストの前に、製品を使う全員が例外なく実行できなければならないタスクをチームで合意します。原典はこれを、テストで見た問題の重要度を決めるものとして「決定的に重要」と位置づけています。Age of Empires IIでは、ユニットの移動、資源の採集や攻撃などの「アクション」、複数ユニットの選択、資源の種類の理解、戦場の霧（fog of war）の理解、マウスでの画面スクロール、ミニマップの操作、建物の建設と修理などを、エラーを1件も許さない項目にしました。

記録したのは2種類です。チュートリアルを先に進めなくなった「失敗（failure）」と、混乱を招いた「エラー（error）」を、特に事前に決めたタスクについて数えました。

### セッションごとの4分類と対応

各参加者のセッションが終わるたびに、ユーザビリティ担当者と開発チームが観察した問題を次の4つに分け、対応を決めます。

| 分類 | 問題の性質                     | 対応                  |
| -- | ------------------------- | ------------------- |
| 1  | 原因も解決策も明白で、すぐ直せる（文言・ラベル等） | 直して次の参加者で試す         |
| 2  | 原因も解決策も明白だが、すぐには直せない      | 修正に着手し、できた時点で改訂版を使う |
| 3  | 原因が明白でなく、解決策も分からない        | 参加者を増やしてデータを集める     |
| 4  | 台本や進行役とのやり取りなど別要因の疑い      | 参加者を増やしてデータを集める     |

分類3・4は、分類1・2へ格上げできるか、問題でないと判断できるまで直しません。原典でも大半の問題は明白でなかったため、より多くの参加者を見るまで修正していません。「1人目で直す」のは、原因と解決策が誰の目にも明らかな場合に限られます。

### 修正を回すための体制条件

原典が挙げる運用上の要件は次の3つです。

- 次の参加者までに直せること（例：2時間以内、または翌日のテストまで）。修正用の開発工数と、すぐ変更できる開発環境を確保しておく
- 各参加者または各テスト日の終わりに、意思決定者と結果を見直して修正するかを決める時間を取っておく
- 修正後に、問題が解消し、別の問題も生んでいないことを確かめられるだけの新しい参加者を確保する

Age of Empires IIでは、プログラムマネージャー、ゲームデザイナー、開発リード、ユーザー支援リードのうち少なくとも1人が全セッションに同席しました。チュートリアルを組んでいたシナリオ作成エディタの構造が柔軟で、すぐ書き換えられたことも成功理由に挙げられています。試作の段階で回すなら、[プロトタイプ](/column/details/6627/)ツール上で文言やレイアウトをその場で直せるかが、この条件を満たせるかの分かれ目になります。

### 修正が効いたと言える人数の計算

RITEで人数を決める基準は、修正が問題を解決したとどこまで確信できるかです。原典は人数に決まりを設けず、二項分布に基づくLewisの表で確率を求めるとしています。発生率pの問題がまだ残っていれば、n人のうち少なくとも1人で観察される確率は `1 - (1 - p) ** n` です。これは、各参加者で同じ発生率pが独立に成り立つと仮定したときの検出確率です。修正後にn人続けて再発がなかったとき、統計的に言えるのは「発生率p以上の問題が残っていれば、n人のうち誰かで観察できていたはず」という範囲までで、発生率がゼロになったことの証明ではありません。

```
import math

def detect_prob(p, n):
    """発生率pの問題を、n人のうち少なくとも1人で観察できる確率"""
    return 1 - (1 - p) ** n

def needed_participants(p, confidence):
    """発生率pの問題を、確率confidence以上で1人以上に観察できる人数（0 < p < 1）"""
    return math.ceil(math.log(1 - confidence) / math.log(1 - p))

print(round(detect_prob(0.30, 6), 3))   # 0.882 原典の「88%」
print(round(detect_prob(0.10, 6), 3))   # 0.469 原典の「47%」
print(round(detect_prob(0.10, 15), 3))  # 0.794 木の配置の修正（15人）「79%」
print(needed_participants(0.30, 0.90))  # 7
print(needed_participants(0.10, 0.90))  # 22
```

原典では、最後の改版の後に6人を追加し、修正済みの問題は1件も再発しませんでした。原典はこれを、発生率0.30の問題なら少なくとも88%、0.10の問題なら47%の確からしさで修正できたと表現しており、この数字は上のコードの検出確率で再現できます。発生率0.10の問題が残っている場合に90%以上の確率で1人以上に観察するには22人が要るので、終盤の検証人数は、どの程度まれな問題まで対象にするかで決めます。

## Age of Empires IIチュートリアルでの実測値

参加者は、リアルタイムストラテジー（RTS）を遊んだことはないが興味はある25〜44歳の16人（女性5人・男性11人）で、全員が過去1年にPCの市販ゲームを1本以上遊んでいました。チュートリアルは1・2・5・8・9・10人目の後に改訂され、改版は6回でした。

| 指標             | 値                    |
| -------------- | -------------------- |
| 参加者            | 16人                  |
| 改版             | 6回（1・2・5・8・9・10人目の後） |
| 見つけた問題         | 31件                  |
| 修正した問題         | 30件                  |
| 影響率（修正数÷発見数）   | 97%                  |
| 修正の総数（やり直しを含む） | 36件                  |
| やり直しが必要だった修正   | 6件                   |

影響率（impact ratio）はSawyerらが提案した指標で、見つけた問題のうち修正された割合です。再修正率（re-fix ratio）は原典が新たに定義した指標で、原典の表は36件中6件を20%と記載しています（6÷36で計算すると約17%）。このチュートリアルは1999年にSociety for Technical Communication（STC）から「Excellence」賞を受けました。

### 1人目で修正した木の配置と15人での再検証

チュートリアルの2つ目のパートでは、村人に木を切らせて資源を集めます。ところが当初は画面内に木が1本もなく、1人目の参加者は長い時間、何をすればよいか分からずにいました。原因も解決策も明白だったため、画面内に木を置き、画面外の木を探す操作も教えるよう変えたところ、残る15人ではこの問題は一度も起きませんでした。

### やり直しが必要だった問題：「train」と「create」の用語

「剣士を5人訓練せよ（Train 5 Swordsmen）」という指示に対し、参加者は村人を兵舎へ連れて行き、村人を剣士に変えられると考えました。実際の剣士は、兵舎で食料や金などの資源を使って新たに作るものです。UIには「train units」と「create units」が混在していたため、8人中6人が新しいユニットを作れなかった時点で、チームは用語の不統一が原因と判断して「train units」に統一しました。

ところが次の参加者で同じ問題が同じ形で再発し、UI全体を「create unit」に変えたところ、その後の7人では見られなくなりました。1回目の用語統一では問題が解消せず、「create」へ変えた後に再発が見られなくなりました。次の参加者による検証がなければ、効かなかった1回目の修正がそのまま製品に残っていたことになります。

### 改版の直後にエラーが増える理由

原典の推移グラフには、改版の直後に失敗とエラーが一時的に増える箇所があります。先に進めなくなる問題が取り除かれ、参加者がチュートリアルのより先まで到達して新しい問題に出会ったためです。最後の改版の後、エラーは1件まで減りました。改版直後のエラー増加を「修正で悪化した」と即断せず、どのタスクで起きたかを確かめてから判断します。

## RITEテストの実施計画テンプレート

実施前に決めておく項目を、原典の要件とAge of Empires IIの例に沿って表にまとめました。テスト計画書の項目立てとしてそのまま使えます。

| 項目     | 決める内容           | Age of Empires IIでの例 |
| ------ | --------------- | -------------------- |
| 対象ユーザー | 参加者の条件          | RTS未経験で興味がある人        |
| 必達タスク  | 全員が例外なく完了すべきタスク | ユニットの移動、資源の採集        |
| 評価項目   | 何を問題として数えるか     | 失敗とエラー               |
| 観察方法   | 発話と行動の記録        | 思考発話                 |
| 同席者    | 修正を決められる人       | PM・デザイナー・開発リード       |
| 修正の期限  | 次の検証までに直せる時間    | 各参加者の後に判断し、直せ次第反映    |
| 判断の場   | 分類と修正判断の時間      | 各参加者の直後              |
| 検証の人数  | 再発なしと言える人数      | 最後の改版後に6人            |

必達タスクと評価項目を先に決めておかないと、セッション後の分類がその場の印象に流されます。問題の重要度はこの2つで決まるので、曖昧なまま始めないでください。

## RITEメソッドが向かない条件と失敗パターン

原典自身が、この手法の前提条件と危険を明記しています。次の条件のどれかに当てはまるなら、RITEではなく従来型のテストを選ぶべきです。

### 体制面で向かない条件

- **担当者がその領域に不慣れ**：観察した問題が「他の人にも起きそうか」を判断できない。原典は、領域の経験が浅い人には従来型のテストのほうが適切だとしている
- **意思決定者が修正判断に関与しない**：原典が求めるのは「出席して見直すという約束」以上の関与。報告を後で受け取るだけなら、直されない理由の1と3がそのまま残る
- **テスト期間中に修正を検証できない**：文言の変更でも本番コードのビルドとリリース手続きが必要で、残りのセッションに修正版を間に合わせられない段階では、フィードバックの速さという利点が消える。すぐ直せない修正があること自体は分類2として扱える

### 進め方で起きる失敗パターン

- **原因か解決策が不明確なまま直す**：まずい修正がUIの別の部分を壊す。Age of Empires IIでも数回起き、RITEの構造のおかげで検出して直せたと報告されている
- **一度に多くを変える**：体験が悪化したとき、どの変更が原因か切り分けられない
- **最後の検証を省く**：修正後の参加者が足りなければ、修正版が前の版より良いという保証がない
- **まれな問題を見落とす**：改版の間の人数が少ないため、発生率は低いが重要な問題がすり抜ける

### 医療機器の総括的評価とRITEの適用限界

最後の危険について原典は、タスクが広くまれな問題が多いと分かっている領域や、エラーを見逃すことが許されない主題で特に当てはまると書いています。医療機器の[ユーザビリティエンジニアリング](/column/details/7628/)（IEC 62366-1）は、設計途中で問題を探す形成的評価と、完成したユーザーインターフェースが安全に使えることを示す総括的評価を分けています。RITEは形成的評価の進め方としては使えますが、設計を変えながら問題を探す評価なので、最終設計を固定して安全な使用を検証する総括的評価の代わりにはなりません。

## GitLabハンドブックに見る現在のRITE運用

GitLabはUXリサーチの[手順書](https://handbook.gitlab.com/handbook/upstream-studios/experience-research/using-rite-to-test-navigation/)で、ナビゲーションの試作をRITEで評価する手順を公開しています（2026年7月16日更新）。原典との主な違いは3点です。

- **人数**：まず3人で試し、見つかった問題を直してから2人を追加して計5人。新しい問題が出なければ終了し、出れば3人ずつ追加する
- **分類**：原典の4分類を3つにまとめ、原因が明白でない問題とタスクの指示などの別要因をCに統合している
- **実施形態**：モデレーター付き（Zoom）に加え、UserTestingを使う非モデレート型も認めている

3人ごとに区切って直す運用は、原典がRITEと区別したLewisの「3人ずつ回し、その間に直す」進め方に近づいています。非モデレート型では、原典の事例にあった意思決定者の全セッションへの同席を、録画の確認と素早い修正判断で補う必要があります。録画を見て判断するまでに時間が空くので、誰がいつ修正を決めるかを計画段階で決めておかないと、従来型のテストと変わらなくなります。

## 他のユーザビリティ評価手法との使い分け

| 手法            | 評価する人         | 向く場面             |
| ------------- | ------------- | ---------------- |
| RITEメソッド      | 実ユーザー（少人数を逐次） | 試作を直しながら短期間で固める  |
| 従来のユーザビリティテスト | 実ユーザー（全員が同じ版） | 問題の一覧化、改修前後の比較   |
| ヒューリスティック評価   | 専門家           | テスト前の安価な一次点検     |
| 認知的ウォークスルー    | 専門家           | 初めて使う人の学習しやすさの検査 |
| A/Bテスト        | 公開後の利用者（多数）   | 2案の効果を統計で比べる     |

原典も、RITEの目的は[認知的ウォークスルー](/column/details/10598/)やヒューリスティック評価、GOMS分析などの反復的な手法と似ており、違うのは修正とその検証の速さだと述べています。専門家による点検で明白な問題を先に潰してからRITEに入れば、限られた参加者を、専門家では気づけない問題の観察に回せます。公開後の数値比較は[A/Bテスト](/column/details/17286/)の役割で、RITEはその代わりになりません。

## よくある質問

### RITEメソッドは何の略ですか？

Rapid Iterative Testing and Evaluationの略で、2002年のMedlockらの論文が名付けました。日本語ではRITE法とも呼ばれます。

### RITEメソッドは何人で実施しますか？

決まった人数はありません。原典が示す指針は、チームが行った修正に確信を持てるだけの人数を走らせることだけです。Age of Empires IIでは16人、GitLabの手順書では3人から始めて計5人とし、問題が出続ければ3人ずつ追加します。

### 1人の参加者で見た問題を直してよいのですか？

原因と解決策が明白な場合に限ります。原典は、参加者が赤と緑の色分けを区別できず、発話から赤緑の色覚特性があると分かった場合は1人で十分だとしています。一方、黒と白を区別できなかった場合は原因が説明できないため、追加のデータが要るという例を挙げています。

### RITEメソッドで統計的に有効な結果は出せますか？

UI全体の問題発生率としては出せません。異なる版の結果を合算して、同じUIの発生率として扱えないからです。版ごとの観測割合（GitLabの報告例では「3人中2人がつまずいた」）は集計できますが、少人数の結果を母集団の発生率へ一般化するには限界があります。GitLabの手順書も、目的は統計的な妥当性ではなく行動の観察と素早い反復だと明記しています。修正後の同じ版で再発ゼロが続いた人数からは、残っている発生率の上限を見積もれますが、それは「修正が効いた確率」そのものではありません。

### どの程度作り込んだ試作でテストしますか？

確かめたい操作を最後まで実行できる程度の忠実度が要ります。GitLabの手順書は、ナビゲーションの評価なら目的の場所まで操作でき、誤った場所もいくつかクリックできる操作可能な試作を推奨しています。静止画でも最初にどこを選ぶかは観察でき、GitLabは別途ファーストクリックテストとして扱っていますが、複数画面にまたがる操作を完了できるかを確かめるには操作可能な試作が要ります。

## 関連記事

- [認知的ウォークスルーとは？4つの質問と進め方、ヒューリスティック評価との違い](/column/details/10598/)
- [ユーザビリティエンジニアリングとは？定義・工程・評価手法とIEC 62366-1の要求](/column/details/7628/)
- [ユーザビリティとは？意味とJIS定義の3要素、アクセシビリティとの違い](/column/details/6865/)
- [プロトタイプとは？語源・意味とプロトタイピングの種類・進め方](/column/details/6627/)
- [ABテストとは？必要サンプル数の計算コードと検証期間・判定を誤らせる条件](/column/details/17286/)

---

出典: [RITEメソッド（RITE法）とは？従来のユーザビリティテストとの違いと進め方](<https://www.issoh.co.jp/column/details/7834/>)（株式会社一創）