Skip to main content
From 16:00 UTC on January 17, 2026, to 20:00 UTC on January 17, 2026, we will perform planned maintenance on the Trailhead, myTrailhead, and Trailblazer Community sites. During the maintenance, these sites will be unavailable, and users won't be able to access them. Please plan your activities around this required maintenance.

自分の調査プランの定義

学習の目的

このモジュールを完了すると、次のことができるようになります。

  • 解決すべき問題を特定する
  • 適切な調査手法を選択する
  • アプローチ文書を調査プロジェクトのガイドや記録として利用する

ユーザーエクスペリエンス (UX) 調査が重要である理由

虫眼鏡を片手に調べ物をしている人の姿と、その周辺のいろいろなイメージ

技術的なことは苦手だという人に出会った経験は誰にもあると思います。こんな台詞を聞いたことはありませんか?

  • 本当に使いづらいったらないわ!
  • 作った人は使う人のことをちゃんと考えたのかしら?
  • あれ? これってこうやるんだ!
  • こんな使い方わかるはずないじゃない。

しかもこれらの文句を言っている状況が電子レンジのタイマーの設定だったりします。このような問題のほとんどを回避する手段があります。それはユーザーを知ることです。

何か素敵なものを作るとき、たとえば、透明な飛行機や Web サイトや Salesforce の新しいページレイアウト (これが一番素敵ですね) など、私達はいつも自分のニーズに合わせて作ってしまいがちです。つまり、自分のニーズとユーザーのニーズは同じであると思い込んでしまうのです。自分が好きなものはユーザーも好きだろうとか、ワークフローのルールを作るのはユーザーも楽しいだろう、などという勘違いです。

ユーザーのニーズと自分のニーズが同じなら (それも奇妙な話ですが)、物作りはずっと楽ちんでしょう。自分が気に入る新製品や新機能を作れば、ユーザーも皆それを好きになってくれるのですから。

しかし現実は違います。ユーザーは自分ではないのです。当然、ニーズも異なります。

それでは、ユーザーにとって何が重要であるかをどうやって知ればよいのでしょうか? あなたが作った製品やサービスをユーザーはどのように使用しているでしょうか? そして次に作る製品を気に入ってくれるでしょうか?

ここで登場するのがユーザーエクスペリエンス (UX) 調査です。

UX 調査とは何か

UX 調査とは、製品やサービスを使用するユーザーとユーザーのニーズを理解するためのツールと手法のセットです。プロジェクトプランニングの構造に調査の厳密さを組み合わせることで、製品、サービス、機能などの改善に役立ちます。具体的には、ユーザーはで、がユーザーにとって重要で、どのように業務を行うかを特定しやすくします。これらの質問への答えが見つかれば、より良い製品やサービスを作ることができるでしょう。

UX 調査は難しい作業です。ですのでこう考えましょう。ユーザーはヒーローで、あなたはそのヒーローをサポートする役割を担っているのです。ヒーローの活躍を少しでも助けることができるようなエクスペリエンスを作るのだと。そうすればヒーローはあなたに感謝してくれるでしょう!

UX 調査があなたにとってなぜ役立つかがわかったところで、少し掘り下げて見てみましょう。

メモ: あなたをユーザー調査のプロフェッショナルに育てようとしているのではありませんのでご安心を。ですが、このモジュールが終わる頃には、基本的な UX 調査を自分で行えるようになっているでしょう。

では最初のステップとして、調査プランを組み立てましょう。

人類として初めて月面を歩いたアームストロング船長の言葉を借りるなら、あなたにとっては小さな一歩でも、あなたのユーザーにとっては偉大な飛躍となるでしょう。

どのようなプロジェクトでも、普通はプロジェクトのガイドとなる何らかのプランニング文書 (アプローチ文書) があります。ユーザー調査も例外ではありません。ここで登場するのが調査プランです。この文書では、調査する問題を定義し、調査の対象とするユーザーを決め、スケジュールを設定し、調査活動のおよその長さを決めます。頑張ってください!

この調査プロジェクトのガイドとなるこの文書は、プロジェクトの詳細を 1 か所で管理するのに役立ちます。また、UX 調査チームのメンバーとの契約書のような働きもします。すべての関係者はこの文書の内容に合意し、この文書で調査の主要なピースを管理します。

調査プランには以下の情報が含まれます。

  • プロジェクトの範囲 (調査対象の問題と、以前の関連する調査の結果を含む)
  • プロジェクトのスケジュール
  • 参加者のリスト
  • プロジェクトの調査手法

では 1 つずつ見てみましょう。

調査対象の問題を理解する

UX 調査プロセスの理解を深めるため、UX 調査を初めて行う営業担当チームのメンバーである Carla の行動を追ってみましょう。彼女は、会社の中核となるセールスアプリケーションの利用率が大幅に下がっていることに気が付き、その理由が知りたいと思っています。問題ステートメントが明らかになれば、チームメンバーがユーザーエクスペリエンスを高める助けとなると考えました。

Carla は精査を行い、すぐにプロジェクトを開始するのではなく、この問題について他の誰かが以前に調査していないかを確認しました。この結果と全般的な製品調査の結果は、誰にどんな質問をするかを決めるのに非常に役立ちます。Carla は、このプロジェクトの影響を最も受けるであろう人達に質問することにしました。この人達のことを「オーディエンス」と呼びます (オーディエンスの詳細は単元 5 で学習します)。Carla は、問題に関してすでに収集されていた情報をオーディエンスから入手します。

Carla は問題の履歴を入念に調べることにしました。特に、何か問題がありそうな情報 (バグ、サポートチケット、ユーザーや顧客へのアンケート調査、機能要求一覧、Web サイトのドロップオフレートが記録されたログなど) を重点的に調べました。Carla はあらゆるデータを調べて、調査の骨格作りに利用できる多くのデータを入手しました。

スケジュールの定義

スケジュールの定義

調査プランやアプローチを作成する際の代表的な問題の 1 つは時間です。調査手法を組み立てるための時間、オーディエンスと関わるための時間、ユーザーを集めるための時間、実際の質問時間、レポートを書く時間、レポートを提出するための時間など、あらゆる時間を割り振らなければなりません。

 オーディエンスの時間: 調査で貴重な情報を発見しても、それが開発者や意志決定者に役立つ間に提供されなければ、調査の意味はありません。開発チームのスケジュールを十分に考慮して調査のスケジュールを決めてください。チームメンバーや他の関係者から情報を集め、調査の時間的制約について検討しましょう。

 面談時間: 面談時間は 30 ~ 90 分程度にしましょう。質問をしたり、詳細なメモを取ったりしながら人の話を聞くのは上手ですか? たいていの人は苦手ですので、質問を録音するか、チームメイトにメモを取ってもらいましょう。質問時間を決めたら、食事や休憩などの時間も考慮して、余裕を持って質問のスケジュールを立ててください。

 人集めの時間: 人集めにも十分な時間を確保しましょう。以下の点に注意してください。

  • データを分析して有効ユーザーのリストを作る
  • 候補を見つけたら、調査について簡単に説明し、以下についての情報を得る
    • 彼らは <該当製品> を頻繁に使っているか?
    • 彼らは仕事を効率よく行うためにその製品を使っているか (あるいは使いたいか)?

参加者の都合はよく変わることを想定して、余裕を持ってスケジュールを作成してください。

このように UX 調査は準備だけでも大変ですが、きちんとプランニングすることで、後の作業がスムーズになります。

プロセスにどの程度の時間を要するかがわかったところで、今度は参加者を集める作業にとりかかれます。

適切なユーザーの確保

ユーザー集めと質問を開始する準備ができました。おそらく、チームメンバーが参加者として候補に挙げた人々のリストが利用できるでしょう。あるいは、問題の履歴調査で見つけた人も候補になるかもしれません。それらの人々全員と面談することもできますが、多くの質問をして、その答えを分析していたら、調査の結果が設計開発チームに届くのが遅くなってしまい、調査そのものが無駄になってしまいます。そこで、適切なユーザーにリストを絞り込む必要があります。

調査者がビンゴバスケットをクルクル回しているイラスト

有効な結果を得るのに必要な参加者の人数

何人に面談すれば十分な結果が得られるのでしょう? 「調査に必要な面談対象の人数は実施する調査の種類によって変わる」ということを、幾人かのすぐれた研究者が (わざわざ科学を駆使して) 証明しています。方法については後ほど説明するとして、ユーザビリティ調査には最低 5 人のユーザーが必要ですが、面談は最大で 30 人にできます。面談の黄金律は、何らかのパターンが見られるまで (同じ答えが複数の人から返ってくるようになるまで) 人数を増やす、と言うことです。とりあえずは 15 人から始めて、パターンが見られるかどうかを調べてください。パターンが見られなければ、面談人数を増やすか、逆に調査範囲を狭めます。

調査への招待

面談する人数を決めたら、具体的にユーザーを決めます。自分自身に次のことを尋ねてみてください。

  • 彼らは <該当製品> を頻繁に使っているか?
  • 彼らは仕事を効率よく行うためにその製品を使っているか (あるいは使いたいか)?

どちらの答えも「はい」である人を選びましょう。

製品を日常的に使っているユーザーからは、日々の仕事で製品がどのように機能する (あるいは機能しない) かについての実例を得ることができ、改善のためのブレーンストーミングにとって貴重な資料となります。

次に、ユーザーを分類します。すでにユーザーのペルソナによって分類してあるかも知れませんが、まだであれば「Salesforce の UX ペルソナ」モジュールでユーザー集めにペルソナを活用する方法について学習してください。

ペルソナは、ユーザーのリストを絞り込むのに便利です。たとえば、調査の内容が特定のユーザーセグメントにのみ影響することがわかっているのであれば、そのセグメントに属するユーザーのみを抽出してください。製品やサービスを導入したばかりでまだ手探りの状態であれば、幅広いユーザー層を対象とするのがよいでしょう。ペルソナについては単元 2 で学習します。

面談対象の決定は、まだまだ始まりに過ぎません。次は、調査の問題を解決するために適切な調査手法を選択します。

適切な調査手法の選択

4 つの基本的なカテゴリから適切な調査手法を選びますが、この手順は少し厄介です。

  •  行動的手法は、人々の行動に主眼を置きます。
  •  態度的手法は、人々の発言に主眼を置きます。
  •  質的手法は、「理由」と「方法」の答えを探します。
  •  量的手法は、「量」と「数」の答えを探します。

異なる調査手法を思い浮かべている調査者のイラスト

質的手法は、意見、利用ケース、または動機を理解するのに使用します。たとえば、フォルダー構造をどのように編成したか (行動) または製品やサービスを使うことをなぜ好む、あるいはなぜ好まないのか (態度) を質問します。

量的手法は、あらゆる数値に関する情報を得るのに使用します。パターンを明らかにするような有意な統計情報が得られます。たとえば、同じタスクを完了するのに各ユーザーがどれだけ時間を費やしたか、もしくは同じことを何人の人がやった、あるいは言ったか (例: 10 人中 8 人が製品でレポートをエクスポートする方法を知らなかった) などです。

ちょっと待ってください。そもそも調査手法とはなのでしょうか?

調査手法とは、調査の問題に関するインサイトを得るために使用する戦略あるいは手順です。一般的な手法は以下の通りです。

  •  アンケートは、投網のように多くの回答を得るのに便利です。
  •  カードソーティングは、ナビゲーションメニューのオプションのように、物事をカテゴリに分類するのに便利です。
  •  コンテキストインタビューは、面談相手をそれぞれの環境で観察し、どのように働いているかを理解するのに便利です。
  •  個別面談は、ユーザーから詳細な情報を入手し、1 対 1 の面談を通してユーザー自身やユーザーによる製品またはサービスの使い方について深く知るのに便利です。
  •  フォーカスグループは、グループ面談でユーザーがどのように回答するかを観察したり、製品やサービスの使い方における類似点や相違点を発見したりするのに便利です。
  •  操作性テストは、タスクやパフォーマンスを測定することで、サービスや製品のユーザーエクスペリエンスを知るのに便利です。

1 つの手法を選ぶか、あるいは複数を組み合わせて使うことができますが、ここでは 1 つにしておくことをお勧めします。UX 調査に慣れたら手法を増やしましょう。

アプローチ文書の使い方

これでアプローチ文書に必要な情報は揃いました。最後に、とても重要な部分を付け加えます。「リソース」セクションです。今後の調査で他の人が調べる可能性のある問題の履歴が入ります。

このセクションには、実際に調査が終わって、収集したフィードバックに基づいて推奨事項を整理し終わってから記入します。このセクションには以下の情報を記入します。

  •  参加者リストには、各ユーザーの名前、会社名、およびロールを記入します。
  •  質問には、参加者への質問 (詳しくは次の単元で学習します) を記入します。
  •  結果サマリーには、結果をまとめたスプレッドシートやスライドなどを添付します。発見点の分析については後の単元で学習します。

アプローチ文書が完成しましたので、次の単元では質問を組み立てましょう。

リソース

Salesforce ヘルプで Trailhead のフィードバックを共有してください。

Trailhead についての感想をお聞かせください。[Salesforce ヘルプ] サイトから新しいフィードバックフォームにいつでもアクセスできるようになりました。

詳細はこちら フィードバックの共有に進む