はじめに

現在、社内のリスキリング制度を活用して**プロダクトマネージャー（PM）**に挑戦中です。これまで企画やユーザー対応には関わっていたものの、「ユーザーにとって本当に価値のあるプロダクトとは何か？」を考えながら形にしていく経験は初めてで、毎日が学びの連続です。

中でも私が最初につまずいたのが、「デザイン思考のテストフェーズ」という考え方でした。最初は「プロトタイプを作って試すのは分かるけど、何をどうテストすればいいの？」「うまくいかなかったら失敗ってこと？」とモヤモヤしていました。

実際に手を動かしながら学ぶうちに、テストフェーズはユーザー視点を取り戻す大切なプロセスであり、決して“完成チェック”の場ではないことが分かってきました。プロトタイプがある程度できあがった段階でユーザーに使ってもらうと、予想外の行動や反応が返ってくることがよくあります。そのときこそ、本当の価値に近づくチャンスなのだと実感しています。

この記事では、「デザイン思考のテストフェーズとは何か？」「どのように進めればよいのか？」を初心者PM向けにやさしく解説していきます。加えて、後半では実際の企業事例を紹介しながら、現場でどのように活用されているかもご紹介します。これから初めてユーザーテストに挑戦する方も、すでに何度か実施している方も、この記事が何かのヒントになればうれしいです。

---

デザイン思考のテストとは？目的と役割をやさしく解説

デザイン思考は、ユーザー中心で課題を解決するための思考法で、以下の5ステップから構成されています

この中で「テスト」は最終ステップにあたりますが、完成チェックではなく“学び”のステップとして位置づけられています。

たとえば、どれだけ良さそうなアイデアでも、実際のユーザーがうまく使えなかったり、期待と違った体験になることがあります。テストでは、そうしたリアルな声や行動を観察し、「何がうまくいっているか」「どこに課題があるか」を探っていきます。

このとき、重要なのは「正解を得ること」ではなく、「ユーザーとの対話を通じて、気づきを得ること」です。ユーザーは時に私たちが予想もしなかった使い方をすることがあります。その意外性こそが、真のニーズを掘り起こすヒントになります。

こうして得られた気づきは、プロトタイプの改善だけでなく、課題定義やアイデアそのものの見直しにもつながります。つまり、テストはプロダクトをより良くしていく“学びのサイクル”の出発点なのです。

---

テストフェーズの基本ステップ5つ

ここでは初心者PMの方でも実践しやすいように、テストフェーズの進め方を5つのステップに整理して紹介します。

① テストの目的を明確にする

まずは、「このテストで何を検証したいのか？」を明確にしましょう。

• このプロトタイプはユーザーの課題を本当に解決できるか？
• 操作方法は直感的か？
• ログイン機能など特定の操作はスムーズに使われているか？

目的が曖昧だと、フィードバックの整理が難しくなります。仮説ベースで問いを立てておくと、注目すべきポイントがはっきりします。また、関係者との認識を揃えるためにも、目的を明文化してチームと共有することが重要です。

② ターゲットユーザーを選ぶ

テスト対象者は、できるだけプロダクトのペルソナに近い人を選びましょう。難しい場合でも、以下のような工夫をすると効果的です

• 属性の異なる複数人にテストしてもらう（バイアスの排除）
• 事前情報のない初見の人にも使ってもらう（自然な反応を観察）
• ヘビーユーザーとライトユーザーの両方に試してもらう

ユーザーの選び方次第で得られるインサイトの質が変わるため、慎重に検討したいステップです。

③ テストシナリオ・タスクを設計する

実際の利用シーンを想定したシナリオやタスクを準備します。

例：

• 「このアプリで新規会員登録をしてください」
• 「特定の商品を探して、購入まで行ってください」
• 「レビューを書いて投稿するところまで試してみてください」

操作手順を細かく説明しすぎず、ユーザーの“迷い”や“つまずき”を観察できるように設計することがポイントです。テスト設計時には「ユーザーの目的」「達成すべきゴール」「測定したい行動」の3点を整理すると、より質の高いテストにつながります。

④ ユーザーの行動を観察し、声を聞く

テスト中は次の3点に注目します：

• 表情・しぐさ（迷い・驚き・困惑など）
• 発言（自然なつぶやきや疑問）
• 無言の間（操作に迷っている可能性）

シンク・アラウド法（Think Aloud）で、ユーザーに操作中の思考を声に出してもらうのも効果的です。テスト後のインタビューやアンケートも忘れずに行いましょう。リアルタイムの行動と、後からの振り返りを組み合わせることで、多面的なインサイトが得られます。

⑤ フィードバックを整理し、改善につなげる

観察・インタビューから得られた情報をポストイットやシートで分類・グループ化し、アフィニティ・ダイアグラムなどを使って整理します。

• 類似する意見をまとめる
• 深掘りし、本質的な課題（インサイト）を特定
• 影響度・実現性・頻度で優先順位を設定

フィードバックを「気になる点」「使いにくかった点」「期待とのギャップ」などカテゴリ分けすると、改善の方向性が明確になります。

必要に応じて、プロトタイプを改善・再テストするというサイクルを回していきましょう。

---

フィードバックの活用と改善サイクル

声を「整理」し、傾向をつかむ

ユーザーテストで得られたフィードバックは、貴重なヒントの宝庫です。しかし、ただ集めただけでは意味がありません。まずは情報を「見える化」し、そこからパターンや傾向を導き出すことが大切です。

実際には、メモ・録画・アンケートなどから得た情報を1件ずつ書き出し、似た内容をグループ化していく「アフィニティ・ダイアグラム」が効果的です。複数人で実施すると多様な視点からの解釈も交わり、より深い理解につながります。

また、ユーザーの発言を単なる「意見」として見るのではなく、その背後にある感情・動機を推測することが重要です。「使いにくい」という言葉の裏には、「自分が間違って操作してしまう不安」や「早く終わらせたいのに手間がかかる苛立ち」などが隠れているかもしれません。

「なぜ？」を繰り返してインサイトを深掘る

フィードバックを分類・整理した後は、各気づきについて「なぜ？」と問いかけてみましょう。表面的な問題をなぞるのではなく、その背後にある“本質的な課題”や“潜在的なニーズ”にたどりつくためです。

たとえば、

ユーザー：「この画面、なんか分かりづらいです」
なぜ？ → 情報が多くてどこを見ればよいか分からない
なぜ？ → 重要な要素が視覚的に強調されていない
なぜ？ → デザイン側が全項目を均等に扱っていた

このように3段階くらい掘り下げるだけで、「解決策は単なるUI修正ではなく、情報設計の再考かもしれない」といった気づきが得られるのです。

インサイトは、ユーザーの言葉の“裏側”から見つかることが多いため、チーム全体で振り返る場を設けるのもおすすめです。

優先順位をつけて改善案を設計する

次にやるべきは、洗い出した課題に対して「今、どれから対応すべきか？」を判断することです。

• 影響度：ユーザー体験にどの程度影響するか？
• 頻度：複数ユーザーから同様の声が上がっているか？
• 実現可能性：今のリソースや期間で対応可能か？

この3つの軸で課題をスコアリングすると、チームとして納得感のある優先順位がつけやすくなります。また、課題を「短期対応できるもの」「中長期で改善したいもの」に分けると、開発の見通しも立てやすくなります。

チームに「伝える・巻き込む」

フィードバックやインサイトを共有する際は、単なる報告で終わらせず、「ユーザーのリアルな声を一緒に考える時間」にするのが理想です。録画やスクリーンショットを見せながら具体的なシーンを振り返ると、メンバーの理解と共感がぐっと深まります。

例えば、「この場面でユーザーが手を止めたのは、何を探していたからだと思う？」といった問いかけを交えると、開発者・デザイナー・ビジネスサイド問わず、ユーザー視点で考える空気が生まれます。

こうしてフィードバックをチームで「自分ごと化」することで、改善へのモチベーションも高まります。

---

テストフェーズと他ステップのつながりを理解する

デザイン思考は、直線的な流れではなく「反復と学び」を前提としたプロセスです。特にテストフェーズは、他のステップ——「共感」「定義」「発想」「試作」——と密接に関わっており、それぞれにフィードバックを返す重要な役割を担っています。

テストから「共感」へ戻る：再びユーザーを見つめ直す

テストを通じて、当初思っていたユーザーの行動やニーズと、実際の反応にギャップがあると気づくことはよくあります。例えば「ユーザーはこの機能を便利だと感じるはず」と想定していたが、まったく使われなかった場合、「そもそもその課題は存在していたのか？」という原点に立ち返る必要があります。

このようなときは、「共感フェーズ」に戻って、再びユーザーの立場で観察したり、インタビューを行ったりすることが大切です。ユーザー理解は一度きりで終わるものではなく、何度も見直すべき土台です。

テストから「定義」へ戻る：課題設定の再検討

ユーザーの反応から「解決しようとしていた課題自体がずれていた」と気づくことも少なくありません。このときは、問題の定義そのものを見直す必要があります。

たとえば、「アプリの登録画面が分かりにくい」という課題を設定していたものの、ユーザーテストで明らかになったのは「そもそも登録せずに使いたいニーズがある」だった場合、課題の定義そのものを再構築しなければいけません。

良いプロダクトは、正しい課題設定から始まります。テストフェーズは、その設定が本当に正しかったかどうかを問い直すための“検証装置”でもあるのです。

テストが「発想」に火をつける：新たなアイデア創出へ

テストで得られる気づきは、単なる改善指示にとどまりません。ときに、新しい発想の種をくれることもあります。

たとえば、ユーザーがある機能を思わぬ方法で使っていたとき、「この行動をもっと後押しする新しい機能があったらどうだろう？」といった発想が生まれます。このように、テストは創造性の源にもなりうるフェーズです。

失敗や違和感にこそ、新しいアイデアのヒントが眠っている。だからこそ、テストの観察やフィードバックは、丁寧に拾い上げておくことが重要です。

テストと「試作」の往復：改善と検証のループを回す

プロトタイプを一度作って終わりにせず、テスト結果をもとに何度も作り直すことが、デザイン思考においては当たり前です。この“試作→テスト→改善→再試作”というサイクルを回すことで、プロダクトは徐々に洗練されていきます。

実際には、少人数のユーザーに簡易なプロトタイプを試してもらい、すぐにフィードバックを得て次に活かす、というような「ラピッドプロトタイピング」がよく行われます。

この反復を通じて、机上では思いつかないような修正点やアイデアが浮かび、ユーザーにとって本当に使いやすく、価値あるものに近づいていくのです。

---

実践事例に学ぶ：テストフェーズが活きた企業の成功例

ここでは、実際の企業がデザイン思考のテストフェーズをどのように活用し、ユーザー中心のプロダクト改善を実現したかを紹介します。初心者PMの方にとってもイメージしやすいよう、背景・課題・テストの工夫・成果という流れで整理しています。

事例①：Bank of Americaの「Keep the Change」プログラム

背景と課題：若年層や低所得層がなかなか貯金を習慣化できないという課題があった。

テストの工夫：

• IDEOと連携し、実際の買い物シーンを観察
• 数パターンの貯金方法をプロトタイプ化
• ユーザーに使ってもらい、どの仕組みが最も自然に使われるかを検証

結果と学び：

• 「端数を切り上げて自動で貯金する」仕組みが最もストレスなく使われた
• サービス開始後、250万人以上が利用し、新規口座開設数も70万件を突破

この事例は、”ユーザーが何をしたいか”だけでなく、”どうすれば行動できるか”に着目したテストが成功の鍵になった好例です。

事例②：GEヘルスケアの小児用MRI体験の改善

背景と課題：小児患者がMRI検査に強い恐怖を感じ、検査中に動いてしまうことで再撮影が必要になるケースが多発。

テストの工夫：

• 子どもや保護者に対して観察・インタビューを実施
• 治療室にテーマを設けた装飾（海賊船・宇宙探検など）をプロトタイプとして導入
• 子どもの反応を現場で観察し、安心感や緊張緩和に寄与する要素を洗い出し

結果と学び：

• 子どもの恐怖心が軽減し、再撮影率が大幅に減少
• 医療スタッフの負担も軽減され、親からの満足度も上昇

この事例は、医療のような厳格な環境でも、ユーザー体験を中心に据えたテストが価値を生むことを示しています。

事例③：Airbnbの予約画面リニューアルプロジェクト

背景と課題：予約プロセスが複雑で、途中離脱するユーザーが多かった。

テストの工夫：

• ペーパープロトタイプから簡易モックアップまで段階的に用意
• 予約ステップごとにユーザーの行動・視線・つぶやきを観察
• フィードバックをもとに何度もUIを改善

結果と学び：

• 必要な情報だけを絞り、1画面に要素を集約する設計に変更
• 完了率とユーザー満足度が改善し、CVR（予約完了率）が大幅に向上

このように、テストを通じて“使われていない理由”を見つけ出し、根本から見直すことで大きな成果が生まれました。

---

まとめと初心者PMへのアドバイス：テストから一歩を踏み出すために

ここまで、デザイン思考のテストフェーズについて、その役割・進め方・他ステップとの関係性・企業事例を通して解説してきました。最後に、これからテストに挑戦する初心者PMの方へ向けて、実践の第一歩を後押しするアドバイスをお届けします。

テストの目的は「完璧を目指す」ことではない

多くの初心者が最初に抱きがちな誤解の一つが、「テストで良い評価を得なければいけない」「完璧なプロトタイプを出さないと恥ずかしい」という思い込みです。

しかし、テストは“完成品の評価”ではなく“仮説検証と学びの場”です。うまくいかない点が見つかることこそが、本来の目的。むしろ“うまくいかなかった理由”にこそ、本当の価値があるのです。

小さく試すことが最大の近道

「ちゃんと準備してからじゃないとテストできない」と考えてしまう気持ちもよく分かります。ですが、完璧な状態を待っていたら、いつまでもテストに踏み出せません。

ユーザーテストは、ペーパープロトタイプやスライドモックなど、簡易な形でも十分に実施できます。大切なのは、一度でもユーザーに“触ってもらい、話を聞く”経験を持つことです。

テストは「ユーザーとつながる時間」

テストは、ただ操作を確認するだけではありません。それは、ユーザーと共にプロダクトを育てる“対話の時間”でもあります。

「この機能、どんなふうに使いましたか？」「この画面、どう感じましたか？」と率直に聞いてみることで、数字だけでは見えないインサイトが得られます。

人と人として向き合う姿勢が、ユーザーの信頼を生み、より良いプロダクトづくりの糧となります。

---

最後に：あなたのテストが、次の一歩を変える

プロダクトマネージャーの仕事は、たくさんの不確実性の中で意思決定をしていくことです。だからこそ、テストを通じて“事実に基づく気づき”を持つことが、大きな武器になります。

勇気を出して最初のテストをやってみること。それ自体が、あなたのPMとしての成長のはじまりです。

ユーザーの声に耳を傾けよう。あなたのプロダクトは、そこから生まれていきます。

ぜひ、小さくても一歩を踏み出してみてください。