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

プロトタイピングの進め方

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

１

プロトタイピングとは

３

プロトタイピングの実施

プロトタイピングの概要・・・・・・・・・４プロトタイピングの活動内容・・・・・・・・・・14

プロトタイピングの作業分担表・・・・・・６テスト計画・・・・・・・・・・・・・・・・・・15
テスターについて・・・・・・・・・・・・・・・17

２

プロトタイプ作成
プロトタイプの作成と確認ポイントの整理・９
プロトタイプの種類・・・・・・・・・・・10
プロトタイプの作成範囲を考える・・・・・11

テスト準備（テスト仕様の決定）・・・・・・・・18
テスト当日の実施手順・・・・・・・・・・・・・19
タスク・質問の作成・・・・・・・・・・・・・・20
プロトタイピングでの質問のポイント・・・・・・21
テスト結果の分析・・・・・・・・・・・・・・・23
課題の抽出と整理・・・・・・・・・・・・・・・24
改善活動の管理・・・・・・・・・・・・・・・・25

2

１ プロトタイピングとはプロトタイピングの概要
プロトタイピング※１では、開発工程前の試作品をテスターに試してもらい、ユーザーの期待に応えられているか※２、ビジュアルイメージやサービスのコア部分の使い勝手を確認します。これらを事前に確認することで、事業者とサービスの最終イメージを早い段階からすり合わせることができます。
※１ システム試作品を用いて行うテスト※２ ユーザーリサーチを実施しサービスキャンバスで整理をした利用者がもっとも実現したいこと

企画
仮説検討

要件定義・調達

サービス立案

要件定義

仕様書作成

設計
基本設計

詳細設計

テスト・
改善

開発

リリース

プロトタイピング

解決すべき課題

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



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

プロトタイプ※３

テスト

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

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

課題があれば本格開発で反映

4

プロトタイピングの概要
プロトタイピングは、大きく２つの活動に分かれます。
プロトタイピング実施

プロトタイプ作成
仕様を具体化したプロトタイプを作成します。
①

プロトタイプ作成対象の決定

プロトタイプをテスターに操作してもらいながら、サービスのコア部分の使い勝手を確認します。

確認ポイントを整理し、プロトタイピング実施対象の画面や機能を決①

テスト計画書・テスト仕様書の作成定します。

テスト方法やテストでの確認ポイント等を記載したテスト計画書及サービスのコア部分※は必ずプロトタイプの作成対象としましょう。

びシナリオやタスク等を記載したテスト仕様書の作成を行います。

※ 例えば、紙で行っていた申請手続きをデジタル化するケースでのコア部分は、「申請部分の機能」です。登録から完了までのフローをプロトタイプで確認しましょう。

②

テスト実施

インタビューまたはアンケートを実施します。ユーザー目線で、使②

プロトタイプ作成の注意点

い勝手等に問題のある点等を確認します。

サービスの疑似体験ができることが大切で、カバーされるべき業務や業務フローを考慮した疑似UI/疑似UXが必要です。

③

結果分析と検証

テスト結果からサービスのコア部分がユーザーの期待に応えられているかを確認します。本格開発に反映すべきものか、次回以降の開発に持ち越すものかという優先度付けを行います。
5

プロトタイピングの作業分担表
サービスのコア部分について、文字情報（仕様書）を具体化したプロトタイプを作成する際のタスクと受託者の作業分担は以下のようになります。
活動

タスク

委託者

確認ポイントの整理〇

受託者

サービスのコア部分について、UI/UX観点で、満たさなければならない”確認ポイント”として整理しておきましょう。

プロトタイプ作成対象の決定
プロトタイプを作成する
画面や機能の決定・合意

〇

〇

〇

テスト計画書作成

説明/ポイント

確認ポイントなど含め、プロトタイプを作成する対象はどこにするのか、受託者と協議します。
テストの目的、実施スケジュール、テスト方法（テスター確保等も含む）及びテストでの確認ポイントを記載した計画書を作成します。

テスト計画書
計画書承認

事前に整理した確認ポイント等について、適切にテストができる計画になっているかど〇

うかを確かめた上で承認します。

〇

プロトタイプ作成

プロトタイプを作成します。

プロトタイプ作成
プロトタイプの確認〇

出来上がったプロトタイプを確認し、受託者にフィードバックを行います。

6

プロトタイピングの作業分担表
プロトタイピングを実施する際のタスクと受託者との作業分担は以下のようになります。
活動

タスク

委託者

受託者

〇

テスト仕様書の作成

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

プロトタイピング実施〇

結果分析・修正方針〇

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

〇

テスト実施

説明/ポイント〇

プロトタイプを用いてテスト（インタビューまたはアンケート）を行います。
テスト結果を分析し、ユーザーの期待に応えられているかを検証の上、課題が出た個所について本格開発に反映させるかどうか（修正方針）を検討します。

結果分析・報告書作成
テスト結果報告書作成〇

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

7

２ プロトタイプ作成

プロトタイプの作成と確認ポイントの整理
プロトタイプを作成し、開発工程前の試作品をテスターに試してもらい、ユーザーの期待に応えられているか、ビジュアルイメージやサービスのコア部分の使い勝手を確認します。また、プロトタイプは、ユーザー目線だけでなく、リリース後の運用や更新を見据えた提供者目線でも確認しましょう。この状態を実現するためには、以下の観点で確認ポイントを設定し、事業者と共有することが重要となります。
UIの観点

 ユーザーへのメッセージが適切である（分かりやすい、誤認されない）
 ボタンやリンクなどユーザーのアクションを促すものが正しく認知されている（見つけやすい、迷わない）
 ユーザーが操作に詰まらない（操作不能にならない）
UXの観点 提供するサービス/機能がターゲットユーザーの期待に応えられている（期待を下回っていない）
提供者の観点 無理なく運用できるか/将来他のサービスに展開可能かなど（提供者目線）
9プロトタイプの種類
プロトタイプには、下記の２種類があります。ユーザー目線での評価を行うには、画面の遷移ができるデザイ
ンプロトタイプの作成が望ましいです。
デザインプロトタイプ

モックアップイメージ

画面遷移•説明•••

完成品を模した画像や画面、Webページなどのことを指します。
ワイヤーフレームを元に、具体的なビジュアルデザインが追加されたものです。
中身の動きなどは実装されていないものとなります。
モックアップを使ったテストでも、手動で画面を切り替えることで、実際の動きを再現することができます。

••

モックアップのようなデザインイメージに加えて、実際の画面遷移や画面上の動きを実装したものです。
ユーザー目線での評価を行うにあたり、画面遷移は重要な要素であるため、プロトタイピングで用いるプロトタイプはこちらを推奨します。

10

プロトタイプの作成範囲を考える
下記の例を参考に、サービス利用時のユーザーの行動を再整理してみましょう。一連のユーザーの行動を可視化するには、「カスタマージャーニーマップ」を活用するのも効果的です。（参考：サービスデザインガイドライン P34）

ユーザーの行動例

行動の整理

Aさんは、先日子供が生まれました。出生届を出す

このサービスでのユーザーの行動は、下記の４ために、東京都▲市電子申請システムで提出する必つに整理できます。

要があります。

① 検索エンジンで電子申請のHPへアクセスする

申請に必要な資料を確認するために、検索エンジン② 出生証明書と母子手帳の画像を準備する

で「▲市電子申請」と検索し東京都▲市電子申請シ③ 出生届の提出をする

ステムにアクセスしました。

④ 申請完了メールを確認する

届け出には出生証明書と母子手帳の画像が必要だとユーザーの行動が整理できたら、プロトタイピわかり準備しました。

ングで確認したいことついて考えてみましょう。

その後、システムで出生届の提出を行い、市から申請の完了メールが届いたことを確認しました。
11プロトタイプの作成範囲を考える
ユーザーの行動が整理できたら、プロトタイピングで確認が必要な事項を整理しましょう。プロトタイピングで確認したい内容から、プロトタイプの作成範囲を決めます。

プロトタイプの作成範囲を決定する
今回確認したいことは、「電子申請システムで出生届を提出できるか」です。その観点から改めて行動を確認すると、全体のフローのうち「①検索エンジンで電子申請のHPへアクセスする」や、「②出生証明書と母子手帳の画像を準備する」は、今回の確認したいこととは異なるため対象から除きましょう。
そのため、今回の事例では、「③出生届の提出」から「④申請完了メールを確認する」までを確認するのに必要なプロトタイプを作成するようにしましょう。
確認対象① 検索エンジンで電子申請のHPへアクセスする② 出生証明書と母子手帳の画像準備③ 出生届の提出をする④ 申請完了メールを確認する※※ プロトタイピングでのメール確認は、プロトタイプ上で「登録」ボタンを押したときに、紙に印刷したメール文案を「このタイミングでこちらのメールが届きます」とテスターにお渡しする形などを取ることで実現したりします。

12

３ プロトタイピングの実施

プロトタイピングの活動内容
プロトタイピングは、テスト計画、テスト準備、テスト実施、テスト結果の分析の４つのフェーズに分かれます。特に計画と準備がテストの成功の鍵を握ります。
テスト前

テスト計画

•

テストの目的確認•

実施スケジュール設定•

テスト方法の決定（テスター確保等も含む）•

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

テスト後

テスト実施

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

当日の手順

•

テストシナリオの作成•テスターが実施する操作（タスク）設定•

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

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

テスト結果の分析•

インタビューの実施•課題の抽出と分析•

課題に対する解決策・改善案の策定•課題が出た個所について、本格開発に反映させるかどうか（修正方針）を検討

または•アンケートフォームを利用して質問票の回収

14

テスト計画
プロトタイピングを実施する前に、下記ポイントを明確にしてテスト計画を立てます。
テスト計画

テストの目的

確認したいことの概要など、プロトタイピングの目的を記載します。

実施スケジュール

開発工程の前に実施
テスト結果を踏まえて開発工程へ進むことができるスケジュールを提示
原則としてインタビューで実施します。ユーザー評価がより正しく取得できる環境を選択しましょう。
【対面】直接対面でテスターにインタビューを行う

メリット ▸ 直接テスターの操作実態をモニタリングできる
テスト手法

テスト方法

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

デメリット ▸ カメラに映らない表情や手元の動きなど、細かな気付きを得られない
テスター

実際にサービスを利用する人物をテスターとします。
15テスト計画
プロトタイピングを実施する前に、下記ポイントを明確にして実施計画を立てます。
テスト計画

以下の観点で確認ポイントを設定しましょう。

UIの観点
 ユーザーへのメッセージが適切である（分かりやすい、誤認されない）
 ボタンやリンクなどユーザーのアクションを促すものが正しく認知されている（見つけやすい、迷わない）

 ユーザーが操作に詰まらない（操作不能にならない）

テストでの確認ポイント

UXの観点
 提供するサービス/機能がターゲットユーザーの期待に応えられている（期待を下回っていない）⇒ネガティブな意見や不足しているものが何かを確認することが重要です。

16

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

定量調査

定性調査

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

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

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

【参考】

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

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

17

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

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

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

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

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

テスト質問

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

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

テストデバイスの準備

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

テスト当日の実施手順
プロトタイピングの実施手順は以下のとおりです。下記の流れをイメージした上で、当日のテスト仕様を検討していきましょう。

テスト実施側

ユー
ザー
イン
タビ
ュー

開始事
前説
明

テスター側

タス
クの実
行

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

回答確認

追加質
問終了

19タスク・質問の作成
プロトタイプの作成範囲を考える（P11～P12）で整理をした確認項目をもとに、テスターに実施してもらう操作（タスク）と質問内容を作成してみましょう。

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

質問の作成
質問作成の際には、設定したタスクを実際に実施しながら、下記のポイント踏まえて作成しましょう。
質問を考える際は、次ページ以降の質問のポイントも参考にしてください。
・テスターが操作に迷ったり詰まったりしそうな箇所
・ユーザーリサーチの結果を反映させた部分

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

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

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

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

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

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

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

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

22

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

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

なぜ操作に迷ったのか•

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

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

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

２

課題の対応範囲の確認・サービス提供者から補足説明をしないとタスクが完了できなかったなどの重大な課題は、本格開発で必ず対応するようにしましょう。
・仕様書の範囲内で対応可能なものは、本格開発時に対応しましょう。

３ 課題に対する対応策・改善案の策定（改善活動の管理）
・今回の開発等で対応しないと判断した項目に対しても、対応しない理由と判断者、延期後の対応スケジュールを記録しましょう。
23

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

想定設問

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

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

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

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

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

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

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

No.
1

入力日
R6.2.5

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

課題管理簿

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

対応方針

対応可

対応不可 修正状況●サイトデザインの変更
・サイトデザイン案を3案提案する。

○

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

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

R6.2.6

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

○24

改善活動の管理
プロトタイピングで現れた重要度の高い課題は、本格開発時に反映することを検討しましょう。
そのため、課題管理簿で課題を管理することを推奨します。課題管理簿では、課題分析、サービス/システム改善案、課題の対応方針の検討状況が分かるよう管理項目を定め、修正状況がわかるようにしましょう。
No.
1

入力日
R6.2.5

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

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

対応方針

対応可

対応不可 修正状況●サイトデザインの変更
・サイトデザイン案を3案提案する。

○

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

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

R6.2.6

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

課題分析

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

課題の対応可否※対応可：本格開発時に修正対応不可：プラットフォームやSaaSの制約で修正不可、運用やサポート体制等でカバーする事業者と密に連携しながら、改善を共に検討することで、サービス・システムをより良いものにできます。

25

End Of File