Content last updated 2026-02-12

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

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

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

定量データ/定量リサーチとは?

定量データとは、カウントや測定によって定量化できるあらゆる種類のデータです。対照的に、定性データは記述的であり、簡単に数値に凝縮することはできません。UX リサーチの文脈では、定量データは通常、次の 2 種類のいずれかです:

  1. GitLab 内の機能のクリックなどの、利用関連データ。
  2. ボリュームのある調査データ(最低でもサンプルサイズ 30)。

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

定量データは、製品の使用に関する誰が、何を、いつ、そして場合によってはどのようにについて、より多くのことを教えてくれます。例として、定量データは次のリサーチ質問に答えることができます:

  • どれだけのユーザーが CI Pipeline テンプレートにエンゲージしているか?
  • どの GitLab 機能が経営層によって使われているか?(役職を提供しているユーザーの場合)

定量データから何がわからないですか?

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

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

この観点から見ると、利用分析を通じてユースケースの違いを判別する方法はなく、時間が経つにつれてこれらのユーザーは製品の中で誤って表現されることになります。定量データは強力ですが、その提供できる範囲の限界を認識することが重要です。

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

仮説とリサーチ質問が以下の例に似ている場合、定量データは検討するツールの一つかもしれません。これは定量データが唯一のツールであるという意味ではないことを忘れないでください。分析から得られるものには依然として限界があるからです。

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

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

これらの質問は通常、「何」、「どのように」、または「いつ」で始まる傾向があるので、見分けやすいです。デザイナーが意思決定にデータをどのように使用しているかのウォークスルーはこちらです。

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

典型的なプロセスは次のとおりです:

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

定量リサーチを行う前になぜ質問と仮説を生成する必要があるのですか?

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

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

GitLab には、データを収集する 2 つの主要なアプローチがあります: 1) Snowflake または Tableau の使用データからクエリする(GitLab のデータソースの詳細についてはこのハンドブックページを参照)、および/または 2) 調査データを使用する。

これら 2 つのデータソースを使用して、問題の包括的な理解を構築できます。たとえば、最初に使用データを使って見ているユーザー集団を理解し、次にどこに行ってより多くのデータを取得する必要があるかを特定することができます。ユーザー集団を理解したら、調査を使って追加のインサイトを発見できます。

定量データをどのように見て解釈しますか?

データを見る一つの方法はデータ視覚化です。データ視覚化はデータのグラフィカルな表現で、通常はチャートやテーブルとして見られます。データ視覚化は、データの傾向を表現したり、データの要約を表示したりするために使用されます。

視覚化には多くの種類があり、それぞれが特定の状況に他のものより適している場合があります。以下は、SUS データを使用したサンプルチャートによる一般的な視覚化の概要ですが、追加の例についてはこのブログポストも参照すると役立ちます。

  • テーブルは、データの一部を要約したり集計を表示したりしたい場合に使うとよいです。 Table Example
  • 円グラフは、異なるカテゴリ間でデータを比較するために使用されます。 Pie Chart Example
  • 棒グラフは、会計四半期のような明確なカテゴリ間でデータを比較するために使用されます。 Bar chart example
  • 折れ線グラフはトレンドを見るために使えます。時系列は、x 軸が常に時間である折れ線グラフの一種です。 Line chart example
  • 散布図は、2 つの数値変数を比較するときに使用されます。これらのチャートは最も柔軟性がありますが、それは過度に複雑な視覚化を作るリスクも伴います。 Scatter Chart Example

視覚化を作成する際に避けるべきことは何ですか?

視覚化で嘘をつく方法は、偶然にせよ何十通りもあります。視覚化を作成する際のいくつかのヒント:

  • 視覚化は素早く簡単に解釈できるべきです。視覚化が答えよりも疑問を生じさせるようなことになってはいけません。
  • 各軸は理解可能で実用的であるべきです:
    • 軸は常に 0 から始めます。
    • 軸を制限することで、データの大部分をスキップしたり削除したりしないでください。
    • 絶対に必要な場合を除き、Y 軸を 2 つ使わないでください。
    • 2 つのグラフを比較する場合は、軸が同じスケールと範囲にあることを確認してください。
  • 時系列スタディの場合、常に時間を X 軸に置きます。
  • シンプルに保ちます。タイトルは明確で簡潔にし、トピックに不慣れなチームメンバーがメッセージを理解できるよう十分なコンテキストを提供します。
  • データを取得した日付や取得元など、制限を明示します。必要に応じてサブタイトルを参照に使います。
  • データセットへの読者の親しみ度を考慮してください。シンプルで情報豊かなグラフは、複数のグループ化と軸を持つ「派手な」グラフよりも、読者により大きなインパクトを与えることがよくあります。

定量データをまとめる

このセクションでは、視覚化の読み方、トレンドの探し方、結果をインサイトに変える方法を説明します。まず、あらゆる種類のパターンを探すことから始めます。いくつかの例:

  • 時間に基づく周期的なパターン
  • 1 つ以上のカテゴリ間で比較した際の類似点や相違点
  • 一貫して増加または減少するデータ
  • 互いに相関する 2 つの変数。相関関係は次のように見えるかもしれません:
    • 1 つのメトリクスが上下すると、別のメトリクスもそれと一貫して上下する。
    • 1 つのメトリクスが上下すると、別のメトリクスは一貫して反対の動きをする。

パターンを特定したら、元の仮説/質問を考慮しながら、それらのパターンをできる限り要約します。

定量データの要約の例

以下は、定量データを使ってアクショナブルインサイト(AI)を調査する例です。リサーチ質問は「アクショナブルインサイト(AI)の Issue が正常に完了するかどうかを左右する潜在的な要因は何か?」でした。最初に、リサーチャーは Actionable Insight ラベルが付いた GitLab Issue に関連する使用データを Sisense でプルしました。次に、これらのチャートを作成しました:

sharesettings

これらのチャートから、7 か月後に Issue がクローズされる数が大幅に減少していることが明らかです。そこで、調査結果は次のように提示されました: 「アクショナブルインサイトの Issue が作成から 7 か月以内に対処されない場合、そのまま放置される可能性が高い」。

製品デザイナーが意思決定にデータを使用する追加の例

データの制限を明記する

リサーチを共有する際、結果に影響を与えた可能性があると考える制限を明記します。たとえば、データが:

  • 一部のユーザーが欠落している
  • 過去 3 か月だけの使用データを含んでいる
  • 正確性に懸念がある
  • リサーチトピックを直接測定していない

要約には必ず制限の説明を含めてください。この情報はメトリクスと同様にリサーチに関連しており、データにコンテキストを与えます。場合によっては、複数の問題のためにデータを提示する価値がないと判断するかもしれません。

ベストプラクティス

定量データで機能の成功を追跡する

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

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

定量データを単独で使用する

定量データを単独で使用できる場合もあります。いくつかの例:

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

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

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

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

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

  1. 分析を使って、特定のページに何人のユーザーが訪問し、そのページでどの機能を使ったかを調べます。それらのユーザーの一般的な特徴(アカウント年齢、訪問しているステージなど)に焦点を当てます。
  2. ページ/機能と重複する可能性のあるペルソナを含む定性リサーチを開始します。サンプルを分析以上のものに広げ、私たちの分析は常に包括的とは限らない(たとえば、Self Managed ユーザーに関するデータは限られている)ことを念頭に置きます。データのギャップを把握するために主題知識を使い、隠れたユースケースを擁護することを忘れないでください。
  3. インタビューやウォークスルーを使って、ユーザーのモチベーションを理解します。
  4. 強化された理解を提案されたソリューションに取り入れます。

例 2: 将来のイテレーションのために、新機能の改善領域を見つける。

  1. 新機能をリリースした後、機能フラグで使用分析を監視します。ページ滞在時間や、ワークフロー中に他の機能をどれだけのユーザーがやり取りしたかなどを調査します。
  2. 新機能とやり取りする可能性のあるペルソナや使用データで特定されたペルソナを持つユーザーをインタビューして、ハイレベルな目標を理解します。
  3. 使用分析とインタビューインサイトを組み合わせて、他の機能とやり取りするワークフローを視覚化します。
  4. ユーザーの入力とページ滞在時間のトレンドに基づいて優先順位を含めます。
  5. これらのインサイトを使って、ロードマップにおける将来のイテレーションをマッピングするのに役立てます。

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

十分なデータがないかもしれない一般的なシナリオはたくさんあります。たとえば:

  • 新しいメトリクスが実装されたが、データは 1 か月分しかない。
  • データは SaaS ユーザーからのみ報告されており、Self Managed からではない。
  • データスクラビングにエラー/バグがあり、一定期間が欠落している。

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

(1) 定量データを定性リサーチで補完してリサーチを拡張する。 たとえば:

  1. ナビゲーション要素の定量調査中、他のユーザーとは異なる要素を一貫してクリックする非常に少数のユーザーがいることがわかります。
  2. さらなる調査の後、いくつかのキャラクターのデモグラフィックと可能性のあるユーザーペルソナをこのユーザーグループに関連付けます。しかしこのリサーチでは、なぜそれらのユーザーがそのように行動するのかという質問に答えることはできません。
  3. これに答えるために、見つけたペルソナを使ってユーザーインタビューを開始します。インタビューを要約すると、ユーザーが共有する業種から重複する小さなユースケースのセットを持っていることがわかり、これがそれらのペルソナに対する新しく特定された JTBD につながります。

(2) 現在の製品ロードマップに沿って進めながら、インサイトと考えられる欠点をまとめる。 たとえば:

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

別のプロジェクトのデータで分析を埋めることは推奨されません。 異なる集団からのサンプルサイズが原因で、データが現実と異なって見える可能性があり、問題を引き起こすことがあります。