System Usability Scale（通常「SUS」と略されます）は、ユーザーが感じた使いやすさ（知覚されたユーザビリティ）を測定するための10問の質問票です。回答者は5段階の同意度スケールで各項目を評価し、その回答を統合して0〜100のスコアを算出します。この数値はスケール上のスコアであり、タスク達成率や満足した人の割合（％）ではありません。

ジョン・ブルック（John Brooke）によって開発されたSUSは、システムを使用した後の全体的な評価を一貫した基準で把握したい場合に役立ちます。その価値はユーザビリティテストの録画とは異なり、録画がその評価に至ったインタラクションの背景を解き明かすのに役立つのに対し、SUSスコアは全体的な印象を数値として要約します。

反転項目に注意してスコアを計算する

標準的な質問票では、奇数番号の肯定的な項目については、回答の値から「1」を引きます。偶数番号の否定的な項目については、「5」から回答の値を引きます。こうして得られた10項目の数値をすべて足し合わせ、2.5を掛けます。

そのため、各項目のスコアは0〜4の範囲になります。簡単な計算確認として、すべての項目で中央の選択肢「3」を選んだ場合、各項目は2となり、合計スコアは50になります。単に元の回答をそのまま合計したり、否定的な項目の反転処理を忘れたりすると、誤った無効な計算になってしまいます。

MeasuringUのSUSガイドでは、スコアリングと結果の解釈について詳しく解説されています。公式に規定された質問票と計算手順を使用し、無回答があった場合の処理方法を分析前に決めておきましょう。回答が不完全なデータを、あたかも全問回答されたかのようにそのまま扱うべきではありません。

スコアだけでなく、比較対象（基準データ）も慎重に吟味する

公開されているベンチマークデータセットでは、一般的に「68」がおおよその平均値として挙げられます。ただし、これは絶対的な合格ラインではありませんし、「ユーザビリティが68%」という意味でもありません。パーセンタイル（百分位数）や「Good」「Poor」といった形容詞による評価ラベルは、参照する分布データや採用する解釈基準によって変わります。

例えば社内向けの購買システムを評価する場合、チームにとって関心があるのは、無関係な一般消費者向け製品との比較ではなく、リニューアル後に使いやすさの実感が向上したかどうかであるはずです。参加者属性、実施タスク、実施環境の比較可能性を十分に確保し、わずかなスコアの差に一喜一憂するのではなく、サンプルサイズや不確実性（誤差範囲）も含めて報告しましょう。

高いスコアが出たからといって、タスクが確実にこなせていることや、アクセシビリティが十分であること、あるいはそのプロダクトに需要があることの証明にはなりません。使い慣れたシステムであれば不便さがあっても高評価をつける人もいれば、すべてのタスクを完了できたとしても体験に不満を抱く人もいます。だからこそ、スコアと定性的なファクトを合わせて検証することが不可欠です。

全体的な評価が必要な場面でSUSを活用する

SUSは、対象のシステムを実際に利用した直後、かつ参加者の意見にバイアスを与えかねない詳細なデブリーフィング（振り返り）の前に実施します。過去の知見やベンチマークと比較する場合は、標準的な文言と選択肢のスケールを崩さずに使用してください。翻訳版や派生バージョンを利用する際は適切な根拠が必要であり、安易に文言を変更すると過去データとの比較ができなくなってしまいます。

改善点を具体的に特定するには、SUSの結果をユーザビリティテストや追加のヒアリングと組み合わせましょう。個々のタスク直後の使いやすさを測りたいなら、Single Ease Question（SEQ）のほうが適しています。SUSの各質問項目を、特定の画面や不具合をピンポイントで診断するための材料として扱うべきではありません。

質問票の長さを短く抑える必要がある場合は、関連する簡易版ツールとして、それぞれ独自のスコアリングと解釈基準を持つUMUXやUMUX-Liteが候補になります。リサーチの目的や比較のニーズに応じて適切なものを選択してください。項目数を増やしたからといって問題の原因がより明確になるわけではありませんし、項目数を減らしたとしても丁寧な測定が求められることに変わりはありません。