ユーザーテスト実施手順書 03

ユーザビリティテストの進め方

2 0 2 4 年 ３ 月
デジタルサービス局
TOKYO METROPOLITAN GOVERNMENT目次

１

ユーザビリティテストとは

２

ユーザビリティテストの実施

ユーザビリティテストの概要・・・・・・４

ユーザビリティテストの活動内容・・・・・８

ユーザビリティテストの実施時期・・・・５テスト計画・・・・・・・・・・・・・・・９

ユーザビリティテストの作業分担表・・・６

テスターについて・・・・・・・・・・・・11
テスト準備（テスト仕様の決定）・・・・・12
テスト当日の実施手順・・・・・・・・・・13
タスク・質問の作成・・・・・・・・・・・14
ユーザビリティテストでの質問のポイント・17
ユーザビリティテスト実施後の活動・・・・19
テスト結果の分析・・・・・・・・・・・・20
課題の抽出と整理・・・・・・・・・・・・21

改善活動の管理・・・・・・・・・・・・・22

2

１ ユーザビリティテストとはユーザビリティテストの概要
ユーザビリティテストでは「設計時の目的どおりユーザーエクスペリエンス(UX)が実現できているかの最終確認」を目的としています。主に「重要と思われるアクションをユーザーがストレス無しに行えるか」、「プロトタイピングで確認したポイントがサービスに反映されているか」を確認します。これにより品質が保証されたサービスをリリースできます。
プロトタイピング
解決すべき課題

開発
ベータ版※を作成※ 受入テスト実施前の最新のサービス

ユーザーリサーチで得た課題に対する解決策を踏
まえ仕様書を作成

事業者と打合せ
確認したい事項を整理し、必要な画面や機能を調整の上、プロトタイプ作成依頼をする

プロトタイプ※評価

文字情報だった仕様（解決策の仮説）をプロトタ
イプで具体化する

テストシナリオを元にインタビューやアンケートを行
い、ユーザーの期待に応えられているか確認※ システム試作品

ユーザビリティテスト
テスト結果を踏まえ、重要な機能に影響するものやリリース前に対応可能な課題は修正

リリース後リリース前に修正対応できなかった課題について必要に応じて改修を行う

リリース4

ユーザビリティテストの実施時期
ユーザビリティテストはリリース予定のサイトやアプリのベータ版が出来上がったタイミングで実施します。
ユーザビリティテスト後、リリースまでに微修正のための期間を設けられるよう、テスト実施スケジュールを計画します。

サービスキャンバス
作成

企画
仮説検討

サービス立案

要件定義・調達
要件定義

仕様書作成

ユーザーリサーチ

プロトタイピング
プロトタイプを作成・テスト

設計
基本設計

詳細設計

開発

テスト・
改善

リリース

ユーザビリティテスト

プロトタイピング

開発

ユーザビリティテスト

ベータ版を作成

ベータ版をテスト

リリース

テストの結果を受けて正式版をリリースするまでに微修正を行う

5

ユーザビリティテストの作業分担表
ユーザビリティテストを実施する際の操作（タスク）と受託者との作業分担は以下の表のようになります。
活動

タスク

委託者

受託者

〇

テスト計画書作成

テスト計画書
計画承認〇

テスト仕様書テスト仕様書の承認

ユーザビリティテスト
実施〇

テストでの確認ポイントを記載した計画書を作成します。

当日の手順、テストシナリオ、テスターが実施する操作（タスク）、テストに利用する質問、テストに使用する機器等を記載したテスト仕様書を作成します。
テスト仕様書を確認、承認します。

〇

テスト実施

テストの目的、実施スケジュール、テスト方法（テスター確保等も含む）及び適切にテストができる計画になっているかどうかを確かめた上で承認します。

〇

テスト仕様書の作成

説明/ポイント

ベータ版を用いてテスト（インタビューまたはアンケート）を行います。
テスト結果を分析し、「重要と思われるアクションをユーザーがストレス無し

結果分析・修正方針〇〇

結果分析・報告書作成に行えるか」、「プロトタイピングで確認したポイントがサービスに反映されているか」を検証し、課題が見つかった場合はリリースまでに対応するかどうか（修正方針）を検討します。

テスト結果報告書作成〇

実施結果・修正方針を記載したテスト結果報告書を作成します。

6

２ ユーザビリティテストの実施

ユーザビリティテストの活動内容
ユーザビリティテストは、テスト計画、テスト準備、テスト実施、テスト結果の分析の４つのフェーズに分かれます。特に計画と準備がテストの成功の鍵を握ります。
テスト前

テスト計画

••
•

•

テスト後

テスト実施

テスト準備
（テスト仕様の決定）
•

当日の手順

•

テストシナリオの作成

テスト結果の分析

テストの目的確認
実施スケジュール設定•
テスト方法の決定（テスター確保等も含む）

テスターが実施する操作（タスク）設定•

テストに利用する質問の準備

テストでの確認ポイン
トの決定•

テストに使用する機器等の準備•

インタビューを実施•

課題の抽出と分析•

課題に対する解決策・改善案の策定•

重要な機能に影響する
課題は優先的に対応•

リリース前に対応可能
な課題は修正または•アンケートフォームを利用して質問票を回収

8

テスト計画
ユーザビリティテストを実施する前に、下記ポイントを明確にしてテスト計画を立てます。
テスト計画
テストの目的

確認したいことの概要など、ユーザビリティテストの目的を記載します。

実施スケジュール

テスト結果を踏まえて修正を行えるタイミングで実施します。
原則としてインタビューで実施します。ユーザー評価がより正しく取得できる環境を選択しましょう。
【対面】直接対面でテスターにインタビューを行う
メリット ▸ 直接テスターの操作実態をモニタリングできる
テスト手法

テスト方法

デメリット ▸ 会場の規模やテスターの人数によっては緊張感や圧迫感を与える可能性がある【オンライン】Web会議システムを活用して、オンラインでインタビューを実施
メリット ▸ 会場確保が不要で、実施スケジュールが調整しやすい・操作モニタリングも実施可能
デメリット ▸ カメラに映らない表情や手元の動きなど、細やかな気付きを得られない

テスター

実際にサービスを利用する人物をテスターとします。

次ページへつづく

9

テスト計画
ユーザビリティテストを実施する前に、下記ポイントを明確にして実施計画を立てます。
テスト計画
このテストで行うテスターへの確認ポイントを明確にする(以下例)
テストでの確認ポイント•

設計時の目的どおりのユーザー体験が実現できるか•重要と思われるアクションをユーザーがストレス無しに行えるかの確認•

プロトタイピングで確認したポイントがサービスに反映されているか

10

テスターについて
原則基本的にサービスを利用するユーザーにテスターとなってもらいます。都民向けのサービスは原則として都民（またはユーザーとなりえる職員等）をテスターとします。
※ 職員で代替する場合は、なるべく別部署のサービスの利用者となりえる方へ依頼するようにしましょう

定量調査

定性調査

調査結果に代表性が確保できるレベルである、「気づき」を探るための調査のため、属性ごとに1セル50名以上の回答を回収するのが望ましい。

3～5名程度に実施するのが望ましい。

※セルとは特定の属性や特徴を持つ人々のグループのこと（例）30代×男性＝セル①・40代×女性＝セル②など※属性や特徴を持つ人々のグループが単一もしくは少ない場合でも、最低400名以上※１の回答を回収するようにしましょう。

【参考】

5名のテスターがいれば85％のUIの改善点が発見できると言われております。事業ターゲットが特定の属性に限定されている場合は、５名程度を目安に調査をしてみましょう。

※１ 統計学上許容誤差5%・信頼度95%とした場合の必要サンプル数
参照：総務省統計局（https://www.stat.go.jp/naruhodo/15_episode/toukeigaku/taishosha.html）

11

テスト準備（テスト仕様の決定）
テスト準備

当日の手順
テストシナリオの作成

テスト当日の流れを記載します。

テスト計画で決めた確認ポイントを評価することのできるユーザー利用シーンとその一連の行動（ユーザーの行動や体験をストーリー風にしたもの）を設定します。

タスクの設定テスターに行ってもらう操作（タスク）を設定します。

テスト質問

テスト計画書作成時に整理した確認ポイントを中心にテスト質問票（アンケート）を作成します。
・テスト目的を十分理解したテスト進行者（ファシリテーター）を選出します。
※進行者はサービスを事前に操作し、テスト前にサービスの流れや機能を理解しておく必要があります

テストの実施体制⇒インタビューの議事録やテスターの利用状況を書き留めるために進行者以外に最低１名はテストに同席することを推奨します。
・集合形式（グループインタビュー形式）で行う場合は、テスターのサポート等が行える人も配置します。

テストデバイスの準備

ユーザーのサービス利用シーンと同じデバイス（PC、スマホ、タブレット等）を選定します。
必要であれば複数のデバイスで行います。
12

テスト当日の実施手順
ユーザビリティテストの実施手順は以下のとおりです。下記の流れをイメージした上で当日のテスト仕様を検討していきましょう。

テスト実施側

ユーザー
イン
タビ
ュ
ー

開始事
前説
明

テスター側

タス
クの実
行

観タ察スとク記の録にイよン
るタ
深ビ
堀ュ
りー

回答
確認

追加質問

終了

13

タスク・質問の作成
プロトタイピング実施時に使用したテストシナリオを参考にテストシナリオを作成してみましょう。一連のユーザーの行動を可視化するには、「カスタマージャーニーマップ」を活用するのも効果的です。（参考：サービスデザイン
ガイドライン P34）ユーザビリティテストではリリース直前のベータ版を用いてテストを行うため、操作（タスク）が整理しやすいよう、実際の利用シーンを細かく分割しまとめてみましょう。

ユーザーの行動例

行動の整理

Aさんは、先日子供が生まれました。出生届を出すために、このサービスでのユーザーの行動は、下記の７つに整東京都▲市電子申請システムで提出する必要があります。

理できます。

申請に必要な資料を確認するため、検索エンジンで「▲① 検索エンジンで電子申請のHPへアクセスする市電子申請」と検索しHPにアクセスしました。

② 出生証明書と母子手帳の画像を準備する

届け出には出生証明書と母子手帳の画像が必要だとわか③ システムで出生届申請フォームを探すり準備しました。

④ 申請者情報の入力

その後、システムで申請フォームを探しクリックし、申請者情報の入力や画像のアップロードを行った上で出生届の提出を行いました。市から申請の完了メールが届いたことを確認しました。

⑤ 用意した画像のアップロード⑥ 出生届の提出をする⑦ 申請完了メールを確認する

ユーザーの行動が整理できたら、ユーザビリティテストで確認したいことついて考えてみましょう。
14

タスク・質問の作成
ユーザーの行動が整理できたら、ユーザビリティテストで検証する範囲を整理しましょう。

ユーザビリティテストの範囲を決定する
今回確認したいことは、「電子申請システムで出生届を提出できるか」です。その観点から改めて行動を確認すると、全体のフローのうち「①検索エンジンで電子申請のHPへアクセスする」は、今回の確認したいこととは異なるため対象から除きましょう。「②出生証明書と母子手帳の画像を準備する」についても、事前に写真を用意しておきましょう。
そのため今回の事例では、「③システムで出生届申請フォームを探す」から「⑦申請完了メールを確認する」までを実際にテスターに操作をしてもらい、インタビューを実施しましょう。
そのほかにも、ユーザビリティの確認が必要な「システム内の検索機能」や「ユーザー登録機能」等がある場合は、それぞれタスクを設定し、テストを実施してみましょう。
確認対象① 検索エンジンで電子申請のHPへアクセスする② 出生証明書と母子手帳の画像準備③システムで申請フォームを探す④ 申請者情報の入力⑤用意した画像のアップロード⑥ 出生届の提出をする⑦ 申請完了メールを確認する※※ メール確認は、ベータ版上で申請を確定するボタンを押したときに、別画面で受信メールの内容を表示する方法でも実施できます。

15

タスク・質問の作成
タスク・質問の作成（P14～P15）で整理をした確認項目をもとに、テスターに実施してもらう操作（タスク）と質問内容を作成してみましょう。

タスクの作成今回のタスクは「③システムで申請フォームを探す」から「⑦ 申請完了メールを確認する」の一連の流れです。
確認項目をタスクとして下記のように整理します。
タスク：電子申請システムの出生届申請フォームから出生届を提出してください。市から申請完了メールが届いたらタスク終了です。
ポイント・タスクの中に2つ以上の要素を盛り込まないようにしましょう⇒複数の要素を１つのタスクに盛り込むとタスクの操作が不十分になったり、想定した操作を行ってもらえない可能性があります。
複数の要素をテストしたい場合は、複数のタスクを設けるようにしましょう。（例：× アカウントのマイナンバーカード連携と出生届の提出 等）・テスターに示すタスクに具体的な手順を記載しないようにしましょう。

⇒テスターが手順が無くても操作できるかを確認することもテストです。

質問の作成
質問作成の際には、設定したタスクを実際に実施しながら、下記のポイント踏まえて作成しましょう。
質問を考える際は、次ページ以降の質問のポイントも参考にしてください。
・テスターが操作に迷ったり詰まったりしそうな箇所
・プロトタイピングで課題となった部分

・申請のフローの中で気になる部分
16ユーザビリティテストでの質問のポイント
テスターへのインタビューの質問を考える際には以下のポイントに注意し、作成しましょう。
ポイント Yes／Noで回答できる質問はしない（例：〇「このサイトについて感じたことを教えてください」×「このサイトは使いやすかったですか？」など）

 改善点などを見つけたくてもネガティブな聞き方はしない（例：〇「申請機能に関して感じたことはありますか？」×「申請機能で使いづらかった箇所はありますか？」など）

 テスターの回答の中で気になる箇所、キーになる回答は必ず深堀りする

 テスターのネガティブな意見に対して、説明や補足をしない テスターの考えを決めつけてインタビューをしない（例：〇「操作してみてどうでしたか？」×「操作は少し難しかったと思いますが、特にどこが難しかったでしょうか？ 」など）

インタビューとアンケートでの共通の質問ポイント
 １つの質問に対して複数の確認事項を入れない
 誘導するような質問設定をしない(例：〇「優先順位を考えるとき重要視しているものは何ですか？」×「業務の優先順位を考えるとき、所要時間が重要だと思いますがいかがでしょうか？」） 最初から回答をストレートに求めない

 なぜ？など威圧感（追及されている感）を感じさせる聞き方をしない

17

ユーザビリティテストでの質問のポイント

ポイント
 確認したい機能１つに対して、1つの操作（タスク）を設定する（申請と審査を同時に確認しない）（例：〇「〇〇補助金の申請を行います。事前に都のHPを確認し、必要書類を用意した状態で申請を行います。」
×「○○補助金の申請を行います。申請のためには事前にシステム内の××で審査を行う必要があり・・・」）

 サービスを理解してそれを基に操作（タスク）・質問を設定する⇒質問設計時に作成者が正しい操作がわからないと、テスターが困りそうな箇所が不明なため、聞きたいことを聞けません。
必ずご自身でサービスを操作してから質問設計を行ってください。

 操作の中でテスターが戸惑っていた箇所は、インタビューの際に必ず質問する（例：ユーザー登録時に何度もログイン名やパスワード条件が不適でエラーが発生していた。
⇒質問することで、パスワード条件等がわかりづらいのか否かを確認し課題を見つけられる）

 テスターにサービスの直接的な改善策を聞かない⇒改善策を考えるのはテスターではありません。
テスターからの意見は参考とし、受託者と連携した上で改善策を立案するようにしましょう。

18

ユーザビリティテスト実施後の活動
ユーザビリティテストによって見つかった問題点について、重要な機能に影響するものやリリース前に対応可能な課題は修正しましょう。修正を持ち越す場合も、課題管理簿に記載し事業責任者の承認を得るようにしましょう。

ユーザビリティテスト

重要な機能に影響するものやリリース前に対応可能な課題は修正

品質上の問題点持ち越す場合も課題管理簿に記載

リリース後の改修

サービスリリース

修正

リリース後はサービスへのユーザー意見や行動情報（アクセス数等）を収集し続けましょう。
ユーザーリサーチやユーザビリティテストを実施し改善サイクルを繰り返しましょう

リリース後の改修時に対応するようにしましょう

課題管理簿

 万一リリース前にサービスのコア領域の課題が発覚した場合は、リリース自体の延期も含め検討します。
 リリース後もサービスに対する意見等を確認し、改善を行いサービスの価値を高めていきましょう。
19

テスト結果の分析
テストで得られた結果をもとに以下のステップで結果の整理を進めていきます。
１

課題の抽出と整理テスターの評価を以下の観点で整理し、改善すべき課題点を明らかにします。
•

なぜ操作に迷ったのか•

なぜ想定と違う操作を行ったのか•

なぜテスターの満足度を得られなかったのか

評価が良い点・平均評価点に着目するよりも、テスターの指摘・不満点に着目することが重要です。

２•

課題の対応範囲の確認サービスのコア部分に関する課題や、サービス提供者から補足説明をしないとタスクが完了できなかったなどの重大な課題は、リリースまでに必ず対応するようにしましょう。

•仕様書の範囲内で対応可能なものは、リリースまでにできる限り対応しましょう。

３ 課題に対する対応策・改善案の策定（改善活動の管理）•

今回の開発等で対応しないと判断した項目に対しても、対応しない理由と判断者、延期後の対応スケジュールを記録しましょう。
20

課題の抽出と整理
インタビューやアンケートの結果に対し、重要な意見（「テスターが操作できなくなった」など）を課題として抽出します。
インタビューやアンケートの回答結果(例)
シーン

想定設問

テスター回答モニタリング状況メモ

・全体的にはシンプルでわかりやすかった
全体

タスク全体を通しての印象をお聞かせください。

・最初の説明文が細かすぎてわかりづらかった
・操作自体は難しいとは感じなかった・背景がグレーなので怪しいサイトに入ったかと思った
・相談予約時にカレンダーで日付を選択するが、空いている日がいつなのかわからなかった

相談内容入力フォームの入 ・電話番号は０８０を入力したら自動的に入力欄が次の枠へ移ったほうが良いと思った
入力フォーム 力時に感じたことはありま ・相談してよい内容なのかどうかの判断ができなかった
すか。

・相談内容の入力時に長考してから入力を始めた。

・相談例などのサンプルを掲載したほうが良い。サイト内の情報だけだとわからない重要な意見を課題として抽出

No.
1

入力日
R6.2.5

件名
サイトデザインの調整

課題管理簿

・背景がグレーなので怪しいサイトに入ったかと思った

対応方針

対応①

対応②

対応③

改修状況

●サイトデザインの変更
・サイトデザイン案を3案提案する。

○

・その後委託者と協議の上サイトデザインを決定する

・相談してよい内容なのかどうかの判断ができ ●相談例を掲載する
2※詳細はP22

テスター意見R6.2.6

相談例の掲載なかった・気軽な相談から深刻な相談まで、受け付けているこ・サイト内の情報だけだとわからないとがわかるような相談例を4～5件掲載する。

○21

改善活動の管理
ユーザビリティテストで現れた重要度の高い課題は、リリース前に改善をするか検討しましょう。
そのため、課題管理簿で課題を管理することを推奨します。課題管理簿では、課題分析、サービス/システム改
善案、課題の対応方針の検討状況が分かるよう管理項目を定め、リリース後の展開も見据え検討しましょう。
No.
1

入力日
R6.2.5

件名
サイトデザインの調整

テスター意見・背景がグレーなので怪しいサイトに入ったかと思った

対応方針

対応①

対応②

対応③

改修状況

●サイトデザインの変更
・サイトデザイン案を3案提案する。

○

・その後委託者と協議の上サイトデザインを決定する

・相談してよい内容なのかどうかの判断ができ ●相談例を掲載する
2

R6.2.6

相談例の掲載なかった・気軽な相談から深刻な相談まで、受け付けているこ・サイト内の情報だけだとわからないとがわかるような相談例を4～5件掲載する。

課題分析

サービス/システム改善案検討○

課題の対応方針※対応①：修正してリリース
対応②：リリース後の運用段階で改修検討
対応③：改修しない事業者と密に連携しながら、改善を共に検討することで、サービス・システムをより良いものにできます。
22

End Of File