Content last updated 2026-07-16

定量データを使用してインサイトを見つける

このページでは、定量データを定義し、UX リサーチで定量データを使用する主な利点と欠点、ベストプラクティス、定量分析の例を説明します。

このページでは、定量データを定義し、UX リサーチで定量データを使用する主な利点と欠点、ベストプラクティス、定量分析の例を説明します。

定量データ/リサーチとは何ですか?

定量データとは、数えたり測定したりして数量化できるあらゆる種類のデータです。これに対して定性データは記述的で、数値に簡単に集約できません。UX リサーチの文脈では、定量データは通常、次の 2 種類のいずれかです。

  1. GitLab 内の機能クリックなど、利用に関連するデータ。
  2. 量に関するアンケートデータ(少なくとも 30 のサンプルサイズ)。

定量データから何が分かりますか?

定量データからは、プロダクト利用の誰が、何を、いつ、そして時にはどのようにをさらに知ることができます。例として、定量データは次のリサーチ質問に答えられます。

  • CI Pipeline テンプレートを利用するユーザーは何人ですか?
  • どの GitLab 機能が Executive に使用されていますか?(ロールを提供しているユーザーの場合)

定量データからは何が分かりませんか?

定量データは、ユーザーの状況には理解できない、または私たちが制御できない側面が常にあるため、「なぜ」を教えてくれません。例:

2 人のユーザーを想像してください。一方は、リポジトリの仕組みを学ぶためにオンラインで見つけたチュートリアルをいくつか進めている学生です。もう一方は、フリーランスのプロジェクトで時々 GitLab を使用するソフトウェアエンジニアです。両者はほぼ同じ時期に同じ機能を使用しており、どちらもプロフィール情報を入力していません。

この観点では、利用分析からユースケースの違いを見分ける方法はありません。時間が経つと、これらのユーザーはプロダクト内で誤って表現されることになります。定量データは強力ですが、提供できる内容には限界があることを認識することが重要です。

定量データの使用を検討するのはいつですか?

仮説とリサーチ質問が以下の例に似ている場合、定量データは使用を検討するツールの 1 つになるかもしれません。これは定量データが唯一使用すべきツールという意味ではありません。分析が教えてくれる内容には依然として限界があるためです。

定量データの使用を示す質問の例:

  • ユーザーは特定のページにいるとき、何をクリックしますか?
  • 何人のユーザーがプロセスを開始し、完了しますか?
  • ある機能の利用は別の機能と比べてどうですか?
  • 特定の機能はいつ使用されますか?
  • 機能はどのくらいの頻度で使用されますか?
  • ユーザーはどの異なる種類のオプションを選択しますか?

これらの質問は通常、「何を」、「どのように」、「いつ」で始まるため、見分けられます。デザイナーがデータを使用して意思決定を行う方法については、ウォークスルーを参照してください。

定量リサーチを実施するプロセスとは何ですか?

一般的なプロセスは次のとおりです:

  1. 定量リサーチで答えられる質問と仮説を立てる
  2. データを収集する
  3. データを解釈/分析する
  4. 発見を要約する

定量リサーチを実施する前に質問と仮説を作る必要があるのはなぜですか?

どのような定量リサーチを開始する前にも、「データスヌーピング」の問題を避けるために仮説と質問を特定することが重要です。データスヌーピングでは、定義された仮説/質問がないため、一見すると意味があるように見えるものの、実際には誤解を招き、ユーザー集団を正しく表さない結果を見つけることになります。仮説/質問は、分析全体のアンカーとして機能します。

データはどのように収集しますか?

GitLab では、データ収集に 2 つの主なアプローチがあります。1)Snowflake または Tableau の利用データからクエリする方法。GitLab のデータソースの詳細についてはこのハンドブックページを参照してください。および/または 2)アンケートデータを使用する方法です。

これら 2 つのデータソースを使用して、問題を包括的に理解できます。たとえば、まず利用データを使用して対象のユーザー集団を理解し、さらにデータを取得する必要がある場所を特定できます。ユーザー集団を理解したら、アンケートを使用して追加のインサイトを明らかにできます。

定量データはどのように確認/解釈しますか?

データを見る 1 つの方法は、データビジュアライゼーションです。データビジュアライゼーションはデータをグラフィカルに表現したもので、一般的にはグラフや表として見られます。データビジュアライゼーションは、データの傾向を表したり、データの要約を表示したりするために使用されます。

ビジュアライゼーションには多くの種類があり、それぞれ特定の状況に他より適している場合があります。以下は SUS データによる例示グラフを使用した一般的なビジュアライゼーションの概要です。追加の例については、この役立つブログ記事も参照してください。

  • 表は、データの一部を要約したり、集計を表示したりするときに適しています。 表の例
  • 円グラフは、異なるカテゴリのデータを比較するために使用します。 円グラフの例
  • 棒グラフは、会計四半期のような明確なカテゴリ間でデータを比較するために使用します。 棒グラフの例
  • 折れ線グラフは、傾向を見るために使用できます。時系列は、X 軸が常に時間である折れ線グラフの一種です。 折れ線グラフの例
  • 散布図は、2 つの数値変数を比較するときに使用します。これらのグラフは非常に柔軟性がありますが、その分、過度に複雑なビジュアライゼーションを作成するリスクもあります。 散布図の例

ビジュアライゼーションを作成するときに避けるべきことは何ですか?

偶然であっても、ビジュアライゼーションで誤解を招く方法は数十あります。ビジュアライゼーションを作成する際のヒント:

  • ビジュアライゼーションは、すばやく簡単に解釈できるものにしてください。ビジュアライゼーションによって答えより多くの質問が生じるべきではありません。
  • 各軸は理解しやすく、実用的である必要があります:
    • 軸は常に 0 から始めてください。
    • 軸を制限してデータの大きな部分を飛ばしたり削除したりしないでください。
    • 絶対に必要な場合を除き、二重 Y 軸を使用しないでください。
    • 2 つのグラフを比較する場合は、軸のスケールと範囲が同じであることを確認してください。
  • 時系列の研究では、時間を常に X 軸に置いてください。
  • シンプルに保ってください。タイトルは明確かつ簡潔にし、トピックに詳しくないチームメンバーでもメッセージを理解できる十分な文脈を含めてください。
  • データを抽出した日付や抽出元を含む制限事項を明記してください。必要に応じて、参照のためにサブタイトルを使用してください。
  • データセットに対する対象者の習熟度を考慮してください。複数のグループ化と軸を持つ「派手な」グラフより、シンプルで有益なグラフの方が対象者に大きな影響を与えられることがよくあります。

定量データを要約する

このセクションでは、ビジュアライゼーションの読み方、傾向の探し方、結果をインサイトに変える方法を扱います。まず、あらゆる種類のパターンを探してください。例:

  • 時間に基づく循環パターン
  • 1 つ以上のカテゴリ間で比較した場合の類似点または相違点
  • 一貫して増加または減少しているデータ。
  • 相互に相関する 2 つの変数。相関は次のように見える場合があります:
    • あるメトリクスが上昇/下降すると、それに伴って別のメトリクスも一貫して上昇/下降する。
    • あるメトリクスが上昇/下降すると、別のメトリクスは一貫して反対の動きをする。

パターンを特定したら、元の仮説/質問を考慮しながら、可能な限りそれらのパターンを要約してください。

定量データの要約例

以下は、Actionable Insights (AI)を調査するために定量データを使用する例です。リサーチ質問は、「(AI)Issue が正常に完了するかどうかに影響する可能性のある要因は何ですか?」でした。まず、リサーチャーは Actionable Insight ラベルを持つ GitLab Issue に関連する利用データを Sisense から抽出しました。次に、次のグラフを作成しました:

sharesettings

これらのグラフに基づくと、7 か月後にクローズされた Issue は大幅に減少していることが明らかです。そのため、「Actionable Insight の Issue が作成から 7 か月以内に対処されない場合、オープンのまま残る可能性が高い」として発見を提示しました。

意思決定にデータを使用する Product Designer の追加例

データの制限事項を明記する

リサーチを共有するときは、結果に影響した可能性があると考える制限事項を記載してください。たとえば、データが次の状態である場合です:

  • 一部のユーザー集団が欠けている
  • 直近 3 か月の利用しか含まれていない
  • 正確性に懸念がある
  • リサーチトピックを直接測定していない

要約には制限事項の説明を必ず含めてください。この情報はメトリクスと同じようにリサーチに関連し、データに文脈を与えます。複数の問題があるため、データを提示する価値がないと判断する場合もあります。

ベストプラクティス

定量データを使用して機能の成功を追跡する

分析から形成された主要メトリクスを追跡すると、機能が本番環境で時間とともにどのように機能しているかを理解するのに役立ちます。

開発・改善する機能に分析を追加することを検討してください。これにより、デザインまたは新機能がどれほど成功したかを追跡できます。

定量データだけを使用する

定量データだけを使用できる場合もあります。例:

  • ユーザーは新しい機能を見つけていますか?
  • 最も訪問されているページはどれですか?
  • ユーザーはどの種類のブラウザを使用してアプリケーションにアクセスしていますか?
  • 前四半期と比べて、現在はより多くのユーザーがページにアクセスしていますか?

上記の例は定量データのみで答えられますが、定性データと組み合わせると、より完全な分析が得られます。これは、定性データが起きていることの背後にある「なぜ」を理解するのに役立つためです。

完璧な組み合わせ:定量データと定性データを一緒に使う

最も有用なリサーチデザインの一部は、混合手法から生まれます。定量的手法と定性的手法の両方に制限がありますが、それらを組み合わせて複雑な質問に答え、より完全なストーリーを提供できます。手法を組み合わせることで、問題の「なぜ」と「どのように」または「何を」の両方に答えられます。

例 1:ユーザーが特定のページとどのようにやり取りするかを理解する。

  1. 分析を使用して、特定のページを訪問したユーザー数と、そのページで使用した機能を調べます。これらのユーザーの一般的な特徴(アカウント年齢、訪問するステージなど)に焦点を当てます。
  2. ページ/機能と重なる可能性のあるペルソナを含む定性リサーチを開始します。私たちの分析は常に包括的ではないことを念頭に、分析だけにとどまらずサンプルを拡大してください(たとえば、Self Managed ユーザーに関するデータは限定的です)。対象分野の知識を使用して、データに存在しうるギャップを見つけ、隠れたユースケースを擁護してください。
  3. インタビューまたはウォークスルーを使用して、ユーザーの動機を理解します。
  4. 強化された理解を提案するソリューションに組み込みます。

例 2:今後のイテレーションに向け、新機能の改善領域を見つける。

  1. 新機能をリリースした後、フィーチャーフラグを使って利用分析を監視します。ページ滞在時間や、ワークフロー中に他の機能とやり取りしたユーザー数などを確認します。
  2. 新機能とやり取りする可能性のあるすべてのペルソナ、および利用データで特定されたペルソナのユーザーにインタビューして、ハイレベルの目標を理解します。
  3. 利用分析とインタビューのインサイトを組み合わせて、他の機能とやり取りするワークフローを可視化します。
  4. ユーザー入力とページ滞在時間の傾向に基づく優先順位を含めます。
  5. これらのインサイトを使用して、ロードマップの今後のイテレーションをマッピングします。

十分な定量データがないときはどうしますか?

十分なデータがない一般的なシナリオは数多くあります。例:

  • 新しいメトリクスを実装しましたが、1 か月分のデータしかありません。
  • データは SaaS ユーザーからのみ報告され、自己管理からは報告されません。
  • データスクラビングにエラー/バグがあり、一定期間のデータが欠けています。

これに対処する方法はいくつかあります。

**(1)定量データを定性リサーチで補って、リサーチを拡張します。**例:

  1. ナビゲーション要素を定量的に調査しているとき、他のユーザーとは異なる要素を一貫してクリックするユーザーが非常に少数であることに気付きます。
  2. さらに調査すると、複数の属性と考えられるユーザーペルソナをこのユーザーグループに関連付けます。しかし、このリサーチでは、そのユーザーがなぜそのように行動するのかという質問には答えられません。
  3. これに答えようとして、見つけたペルソナを使用してユーザーインタビューを実施します。インタビューを要約すると、ユーザーには共通の業界による少数の重複するユースケースがあり、そのペルソナの新たに特定された JTBD につながっていることが分かります。

**(2)インサイトと考えられる欠点を要約しながら、現在のプロダクトロードマップを進めます。**例:

  • 問題検証中に、仮説と前提とは反対方向を示し、プロダクトロードマップの一部と矛盾する可能性があるデータを見つけます。しかし、そのデータはサンプルサイズが小さく、ワークフローの文脈が一部欠けている可能性があります。
  • 結果を書くときは、データの事実と、考えられる前提またはバイアスを述べてください。データは一方向を示しているものの、ロードマップの変更を示唆するには十分な証拠がないことを説明してください。
  • さらに、機会が生じたときにインサイトを保存してさらに調査する価値があるかを判断してください。

**別のプロジェクトのデータで分析を満たすことは推奨されません。**異なる母集団のサンプルサイズにより、データが現実とは異なって見える問題を生む可能性があります。