TOKYO METROPOLITAN GOVERNMENT ユーザビリティテストの進め方 2 0 2 4 年 ３ 月 デ ジ タ ル サ ー ビ ス 局 ユーザーテスト実施手順書 03

2 目次 １ ユーザビリティテストとは ユーザビリティテストの概要・・・・・・４ ユーザビリティテストの実施時期・・・・５ ユーザビリティテストの作業分担表・・・６ ２ ユーザビリティテストの実施 ユーザビリティテストの活動内容・・・・・８ テスト計画・・・・・・・・・・・・・・・９ テスターについて・・・・・・・・・・・・11 テスト準備（テスト仕様の決定）・・・・・12 テスト当日の実施手順・・・・・・・・・・13 タスク・質問の作成・・・・・・・・・・・14 ユーザビリティテストでの質問のポイント・17 ユーザビリティテスト実施後の活動・・・・19 テスト結果の分析・・・・・・・・・・・・20 課題の抽出と整理・・・・・・・・・・・・21 改善活動の管理・・・・・・・・・・・・・22

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

ユーザビリティテストでは「設計時の目的どおりユーザーエクスペリエンス(UX)が実現できているかの最終確 認」を目的としています。主に「重要と思われるアクションをユーザーがストレス無しに行えるか」、「プロ トタイピングで確認したポイントがサービスに反映されているか」を確認します。これにより品質が保証され たサービスをリリースできます。 4 ユーザビリティテストの概要 プロトタイピング 解決すべき課題 ユーザーリサーチ で得た課題に 対する解決策を踏 まえ仕様書を作成 ユーザビリティテスト 開発 ベータ版※ を作成 リリース プロトタイプ※ 文字情報だった仕様（解 決策の仮説）をプロトタ イプで具体化する 評価 テストシナリオを元にイン タビューやアンケートを行 い、ユーザーの期待に応え られているか確認     事業者と打合せ 確認したい事項を整理し、 必要な画面や機能を調整 の上、プロトタイプ作成 依頼をする テスト結果を踏まえ、 重要な機能に影響するものや リリース前に対応可能な課題は修正 リリース前に修正対応 できなかった課題について 必要に応じて改修を行う リリース後 ※ システム試作品 ※ 受入テスト実施前の最新のサービス

5 ユーザビリティテストの実施時期 ユーザビリティテストはリリース予定のサイトやアプリのベータ版が出来上がったタイミングで実施します。 ユーザビリティテスト後、リリースまでに微修正のための期間を設けられるよう、テスト実施スケジュールを 計画します。 ユーザビリティテスト ベータ版をテスト 開 発 ベータ版を作成 リリース プロトタイピング プロトタイプを作成・テスト テストの結果を受けて正式版を リリースするまでに微修正を行う サービスキャンバス 作成 ユーザーリサーチ プロトタイピング ユーザビリティテスト リリース テスト・ 改善 開 発 企 画 サービス立案 仮説検討 詳細設計 基本設計 仕様書作成 要件定義 要件定義・調達 設 計

6 ユーザビリティテストの作業分担表 活動 タスク 委託者 受託者 説明/ポイント テスト計画書 テスト計画書作成 〇 テストの目的、実施スケジュール、テスト方法（テスター確保等も含む）及び テストでの確認ポイントを記載した計画書を作成します。 計画承認 〇 適切にテストができる計画になっているかどうかを確かめた上で承認します。 テスト仕様書 テスト仕様書の作成 〇 当日の手順、テストシナリオ、テスターが実施する操作（タスク）、テストに 利用する質問、テストに使用する機器等を記載したテスト仕様書を作成します。 テスト仕様書の承認 〇 テスト仕様書を確認、承認します。 ユーザビリティテスト 実施 テスト実施 〇 ベータ版を用いてテスト（インタビューまたはアンケート）を行います。 結果分析・報告書作成 結果分析・修正方針 〇 〇 テスト結果を分析し、「重要と思われるアクションをユーザーがストレス無し に行えるか」、「プロトタイピングで確認したポイントがサービスに反映され ているか」を検証し、課題が見つかった場合はリリースまでに対応するかどう か（修正方針）を検討します。 テスト結果報告書作成 〇 実施結果・修正方針を記載したテスト結果報告書を作成します。 ユーザビリティテストを実施する際の操作（タスク）と受託者との作業分担は以下の表のようになります。

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

8 ユーザビリティテストの活動内容 テスト前 テスト計画 テスト実施 テスト結果の分析 テスト準備 （テスト仕様の決定） テスト後 • インタビューを実施 または • アンケートフォームを 利用して質問票を回収 • 課題の抽出と分析 • 課題に対する解決策・ 改善案の策定 • 重要な機能に影響する 課題は優先的に対応 • リリース前に対応可能 な課題は修正 • テストの目的確認 • 実施スケジュール設定 • テスト方法の決定 （テスター確保等も含 む） • テストでの確認ポイン トの決定 • 当日の手順 • テストシナリオの作成 • テスターが実施する操 作（タスク）設定 • テストに利用する質問 の準備 • テストに使用する機器 等の準備 ユーザビリティテストは、テスト計画、テスト準備、テスト実施、テスト結果の分析の４つのフェーズに分か れます。特に計画と準備がテストの成功の鍵を握ります。

9 ユーザビリティテストを実施する前に、下記ポイントを明確にしてテスト計画を立てます。 テスト計画 テストの目的 確認したいことの概要など、ユーザビリティテストの目的を記載します。 実施スケジュール テスト結果を踏まえて修正を行えるタイミングで実施します。 テスト方法 テスト手法 原則としてインタビューで実施します。ユーザー評価がより正しく取得できる環境を選択しましょう。 【対面】直接対面でテスターにインタビューを行う メリット ▸ 直接テスターの操作実態をモニタリングできる デメリット ▸ 会場の規模やテスターの人数によっては緊張感や圧迫感を与える可能性がある 【オンライン】Web会議システムを活用して、オンラインでインタビューを実施 メリット ▸ 会場確保が不要で、実施スケジュールが調整しやすい・操作モニタリングも実施可能 デメリット ▸ カメラに映らない表情や手元の動きなど、細やかな気付きを得られない テスター 実際にサービスを利用する人物をテスターとします。 次ページへつづく テスト計画

10 ユーザビリティテストを実施する前に、下記ポイントを明確にして実施計画を立てます。 テスト計画 テストでの確認ポイント このテストで行うテスターへの確認ポイントを明確にする(以下例) • 設計時の目的どおりのユーザー体験が実現できるか • 重要と思われるアクションをユーザーがストレス無しに行えるかの確認 • プロトタイピングで確認したポイントがサービスに反映されているか テスト計画

テスターについて 原則 基本的にサービスを利用するユーザーにテスターとなってもらいます。都民向けのサービスは原則と して都民（またはユーザーとなりえる職員等）をテスターとします。 調査結果に代表性が確保できるレベルである、 1セル50名以上の回答を回収するのが望ましい。 ※セルとは特定の属性や特徴を持つ人々のグループのこと （例）30代×男性＝セル①・40代×女性＝セル②など ※属性や特徴を持つ人々のグループが単一もしくは少ない場合でも、 最低400名以上※１ の回答を回収するようにしましょう。 定量調査 「気づき」を探るための調査のため、属性ごとに 3～5名程度に実施するのが望ましい。 定性調査 5名のテスターがいれば85％のUIの改善点が発見できると 言われております。事業ターゲットが特定の属性に限定さ れている場合は、５名程度を目安に調査をしてみましょう。 【参考】 11 ※１ 統計学上許容誤差5%・信頼度95%とした場合の必要サンプル数 参照：総務省統計局 （https://www.stat.go.jp/naruhodo/15_episode/toukeigaku/taishosha.html） ※ 職員で代替する場合は、なるべく別部署のサービスの利用者となりえる方へ依頼するようにしましょう

12 テスト準備 当日の手順 テスト当日の流れを記載します。 テストシナリオの 作成 テスト計画で決めた確認ポイントを評価することのできるユーザー利用シーンとその一連の行動 （ユーザーの行動や体験をストーリー風にしたもの）を設定します。 タスクの 設定 テスターに行ってもらう操作（タスク）を設定します。 テスト質問 テスト計画書作成時に整理した確認ポイントを中心にテスト質問票（アンケート）を作成します。 テストの実施体制 ・テスト目的を十分理解したテスト進行者（ファシリテーター）を選出します。 ※進行者はサービスを事前に操作し、テスト前にサービスの流れや機能を理解しておく必要があります ⇒インタビューの議事録やテスターの利用状況を書き留めるために進行者以外に 最低１名はテストに同席することを推奨します。 ・集合形式（グループインタビュー形式）で行う場合は、テスターのサポート等が行える人も配置します。 テストデバイス の準備 ユーザーのサービス利用シーンと同じデバイス（PC、スマホ、タブレット等）を選定します。 必要であれば複数のデバイスで行います。 テスト準備（テスト仕様の決定）

13 ユーザビリティテストの実施手順は以下のとおりです。下記の流れをイメージした上で当日のテスト仕様を検 討していきましょう。 開 始 終 了 事 前 説 明 タ ス ク の 実 行 タ ス ク の 観 察 と 記 録 イ ン タ ビ ュ ー に よ る 深 堀 り 回 答 確 認 追 加 質 問 テスト実施側 テスター側 ユ ー ザ ー イ ン タ ビ ュ ー テスト当日の実施手順

ユーザーの行動例 Aさんは、先日子供が生まれました。出生届を出すために、 東京都▲市電子申請システムで提出する必要があります。 申請に必要な資料を確認するため、検索エンジンで「▲ 市電子申請」と検索しHPにアクセスしました。 届け出には出生証明書と母子手帳の画像が必要だとわか り準備しました。 その後、システムで申請フォームを探しクリックし、申 請者情報の入力や画像のアップロードを行った上で出生 届の提出を行いました。市から申請の完了メールが届い たことを確認しました。 このサービスでのユーザーの行動は、下記の７つに整 理できます。 ① 検索エンジンで電子申請のHPへアクセスする ② 出生証明書と母子手帳の画像を準備する ③ システムで出生届申請フォームを探す ④ 申請者情報の入力 ⑤ 用意した画像のアップロード ⑥ 出生届の提出をする ⑦ 申請完了メールを確認する ユーザーの行動が整理できたら、ユーザビリティテス トで確認したいことついて考えてみましょう。 14 プロトタイピング実施時に使用したテストシナリオを参考にテストシナリオを作成してみましょう。一連のユー ザーの行動を可視化するには、「カスタマージャーニーマップ」を活用するのも効果的です。（参考：サービスデザイン ガイドライン P34）ユーザビリティテストではリリース直前のベータ版を用いてテストを行うため、操作（タスク）が 整理しやすいよう、実際の利用シーンを細かく分割しまとめてみましょう。 行動の整理 タスク・質問の作成

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

16 タスク・質問の作成 ・タスクの中に2つ以上の要素を盛り込まないようにしましょう ⇒複数の要素を１つのタスクに盛り込むとタスクの操作が不十分になったり、想定した操作を行ってもらえない可能性があります。 複数の要素をテストしたい場合は、複数のタスクを設けるようにしましょう。（例：× アカウントのマイナンバーカード連携と出生届の提出 等） ・テスターに示すタスクに具体的な手順を記載しないようにしましょう。 ⇒テスターが手順が無くても操作できるかを確認することもテストです。 タスク・質問の作成（P14～P15）で整理をした確認項目をもとに、テスターに実施してもらう操作（タスク）と質問 内容を作成してみましょう。 タスクの作成 今回のタスクは「③システムで申請フォームを探す」から「⑦ 申請完了メールを確認する」の一連の流れです。 確認項目をタスクとして下記のように整理します。 タスク：電子申請システムの出生届申請フォームから出生届を提出してください。市から申請完了メールが届い たらタスク終了です。 質問作成の際には、設定したタスクを実際に実施しながら、下記のポイント踏まえて作成しましょう。 質問を考える際は、次ページ以降の質問のポイントも参考にしてください。 ポイント 質問の作成 ・テスターが操作に迷ったり詰まったりしそうな箇所 ・申請のフローの中で気になる部分 ・プロトタイピングで課題となった部分

17 ユーザビリティテストでの質問のポイント ポイント  Yes／Noで回答できる質問はしない （例：〇「このサイトについて感じたことを教えてください」×「このサイトは使いやすかったですか？」など）  改善点などを見つけたくてもネガティブな聞き方はしない （例：〇「申請機能に関して感じたことはありますか？」×「申請機能で使いづらかった箇所はありますか？」など） 17  １つの質問に対して複数の確認事項を入れない  誘導するような質問設定をしない (例：〇「優先順位を考えるとき重要視しているものは何ですか？」 ×「業務の優先順位を考えるとき、所要時間が重要だと思いますがいかがでしょうか？」）  最初から回答をストレートに求めない  なぜ？など威圧感（追及されている感）を感じさせる聞き方をしない テスターへのインタビューの質問を考える際には以下のポイントに注意し、作成しましょう。  テスターの回答の中で気になる箇所、キーになる回答は必ず深堀りする  テスターのネガティブな意見に対して、説明や補足をしない  テスターの考えを決めつけてインタビューをしない （例：〇「操作してみてどうでしたか？」 ×「操作は少し難しかったと思いますが、特にどこが難しかったでしょうか？ 」など） インタビューとアンケートでの共通の質問ポイント

ポイント  サービスを理解してそれを基に操作（タスク）・質問を設定する ⇒質問設計時に作成者が正しい操作がわからないと、テスターが困りそうな箇所が不明なため、聞きたいことを聞けません。 必ずご自身でサービスを操作してから質問設計を行ってください。 18 ユーザビリティテストでの質問のポイント  確認したい機能１つに対して、1つの操作（タスク）を設定する（申請と審査を同時に確認しない） （例：〇「〇〇補助金の申請を行います。事前に都のHPを確認し、必要書類を用意した状態で申請を行います。」 ×「○○補助金の申請を行います。申請のためには事前にシステム内の××で審査を行う必要があり・・・」） ⇒改善策を考えるのはテスターではありません。 テスターからの意見は参考とし、受託者と連携した上で改善策を立案するようにしましょう。  操作の中でテスターが戸惑っていた箇所は、インタビューの際に必ず質問する （例：ユーザー登録時に何度もログイン名やパスワード条件が不適でエラーが発生していた。 ⇒質問することで、パスワード条件等がわかりづらいのか否かを確認し課題を見つけられる）  テスターにサービスの直接的な改善策を聞かない

ユーザビリティテストによって見つかった問題点について、重要な機能に影響するものやリリース前に対応可能な 課題は修正しましょう。修正を持ち越す場合も、課題管理簿に記載し事業責任者の承認を得るようにしましょう。 サービスリリース ユーザビリティテスト 品質上の問題点 修正 課題管理簿 重要な機能に影響するものや リリース前に対応可能な課題は修正 持ち越す場合も 課題管理簿に記載  万一リリース前にサービスのコア領域の課題が発覚した場合は、リリース自体の延期も含め検討します。  リリース後もサービスに対する意見等を確認し、改善を行いサービスの価値を高めていきましょう。 19 リリース後の 改修 リリース後の 改修時に 対応するように しましょう リリース後はサービスへの ユーザー意見や行動情報（ア クセス数等）を収集し続けま しょう。 ユーザーリサーチやユーザビ リティテストを実施し改善サ イクルを繰り返しましょう ユーザビリティテスト実施後の活動

20 テストで得られた結果をもとに以下のステップで結果の整理を進めていきます。 • なぜ操作に迷ったのか • なぜ想定と違う操作を行ったのか • なぜテスターの満足度を得られなかったのか テスターの評価を以下の観点で整理し、改善すべき課題点を明らかにします。 評価が良い点・平均評価点に着目するよりも、テスターの指摘・不満点に着目することが重要です。 テスト結果の分析 • サービスのコア部分に関する課題や、サービス提供者から補足説明をしないとタスクが完了できなかったなどの重大な課題は、 リリースまでに必ず対応するようにしましょう。 • 仕様書の範囲内で対応可能なものは、リリースまでにできる限り対応しましょう。 • 今回の開発等で対応しないと判断した項目に対しても、対応しない理由と判断者、延期後の対応スケジュールを記録しましょう。 １ 課題の抽出と整理 ２ 課題の対応範囲の確認 ３ 課題に対する対応策・改善案の策定（改善活動の管理）

21 インタビューやアンケートの回答結果(例) 課題管理簿 ※詳細はP22 課題の抽出と整理 重要な意見を課題として抽出 インタビューやアンケートの結果に対し、重要な意見（「テスターが操作できなくなった」など）を課題 として抽出します。 No. 入力日 件名 テスター意見 対応方針 対応① 対応② 対応③ 改修状況 1 R6.2.5 サイトデザインの調整 ・背景がグレーなので怪しいサイトに入ったか と思った ●サイトデザインの変更 ・サイトデザイン案を3案提案する。 ・その後委託者と協議の上サイトデザインを決定する ○ 2 R6.2.6 相談例の掲載 ・相談してよい内容なのかどうかの判断ができ なかった ・サイト内の情報だけだとわからない ●相談例を掲載する ・気軽な相談から深刻な相談まで、受け付けているこ とがわかるような相談例を4～5件掲載する。 ○ シーン 想定設問 テスター回答 モニタリング状況メモ 全体 タスク全体を通しての印象 をお聞かせください。 ・全体的にはシンプルでわかりやすかった ・最初の説明文が細かすぎてわかりづらかった ・操作自体は難しいとは感じなかった ・背景がグレーなので怪しいサイトに入ったかと思った ・相談予約時にカレンダーで日付を選択するが、空いている日がいつなのかわからなかった 入力フォーム 相談内容入力フォームの入 力時に感じたことはありま すか。 ・電話番号は０８０を入力したら自動的に入力欄が次の枠へ移ったほうが良いと思った ・相談してよい内容なのかどうかの判断ができなかった ・相談例などのサンプルを掲載したほうが良い。サイト内の情報だけだとわからない ・相談内容の入力時に長考してから入力を始めた。

22 ユーザビリティテストで現れた重要度の高い課題は、リリース前に改善をするか検討しましょう。 そのため、課題管理簿で課題を管理することを推奨します。課題管理簿では、課題分析、サービス/システム改 善案、課題の対応方針の検討状況が分かるよう管理項目を定め、リリース後の展開も見据え検討しましょう。 サービス/システム改善案検討 事業者と密に連携しながら、改善を共に検討することで、サービス・システムをより良いものにできます。 課題分析 課題の対応方針 ※対応①：修正してリリース 対応②：リリース後の運用段階で改修検討 対応③：改修しない 改善活動の管理 No. 入力日 件名 テスター意見 対応方針 対応① 対応② 対応③ 改修状況 1 R6.2.5 サイトデザインの調整 ・背景がグレーなので怪しいサイトに入ったか と思った ●サイトデザインの変更 ・サイトデザイン案を3案提案する。 ・その後委託者と協議の上サイトデザインを決定する ○ 2 R6.2.6 相談例の掲載 ・相談してよい内容なのかどうかの判断ができ なかった ・サイト内の情報だけだとわからない ●相談例を掲載する ・気軽な相談から深刻な相談まで、受け付けているこ とがわかるような相談例を4～5件掲載する。 ○

End Of File