アンケートの逐語回答の分析
逐語回答とは、自由記述形式で回答を入力できるアンケートで通常尋ねられる自由回答質問に送信されたコメントです(例:「GitLab のユーザビリティについて、私たちと共有したいことはありますか?」)。逐語回答の分析は、それらの回答にまたがるテーマを探すことで、ユーザー体験などのさまざまな現象を理解するのに役立ちます。
逐語回答を分析するプロセスは、通常「コーディング」と呼ばれます。これはプログラミング言語でコンピュータプログラムを書くこととは関係なく、逐語回答が伝えようとしていることを表すコードを割り当てるプロセスを指します。
- コードは、「テキストの一部のラベルとして機能する単語またはフレーズ」です。
- コーディングは、「テキストの一部に適切なコードでラベルを付けるプロセス」を指します。
- テーマは、ユーザー体験について何かを教えてくれるコードのグループを表します。
逐語回答を分類するアプローチには 2 つの種類があります。
- トップダウン: 事前設定されたカテゴリのリストを取り、個々の逐語回答に割り当てる方法です。このアプローチは、逐語回答で観察するコードやテーマの種類について、すでに見当がついている場合に最適です。
- ボトムアップアプローチ: 個々のデータポイントを 1 つずつ分析してカテゴリを作成し、それらをグループ化して、完全な回答サンプルを意味のある形で表すコードとテーマになるまで洗練する方法です。このアプローチには時間がかかりますが、観察するコードとテーマの種類について見当がついていない場合、および/または分析におけるバイアスをコントロールしたい場合に特に有用です。ボトムアップアプローチは、グラウンデッド・セオリーアプローチとも呼ばれることがあります。ただし、以下で示すステップは、より学術的な取り組みを簡略化したものであるため、ここではその用語を使用しません。
逐語回答の分析は通常、以下のステップに従います。実行する正確なステップは、リサーチプロジェクトの範囲と目標によって異なります。
逐語回答分析のステップ
トップダウンアプローチ
- データを並べ替えて「クリーニング」し、特定する
- 最終テーマを割り当てる
- サマリーテーブルを作成する
ボトムアップアプローチ
- データを並べ替えて「クリーニング」し、特定する
- *データに慣れる
- *コードの初期ドラフトを割り当てる
- *コードを再帰的に洗練し、集約する
- *コードをテーマに昇華し、反復する
- 最終テーマを決定する
- 最終テーマを割り当てる
- サマリーテーブルを作成する
*= ユーザー体験を反映するテーマのセットが得られるまで、これらのステップを繰り返します
逐語回答分析のステップに関する詳細な注記
1. データを並べ替えて「クリーニング」し、特定する。
分析に含められるデータを選択します。私たちは「クリーニング」という言葉を、分析に含めても役立たないデータを取り除くプロセスを指すために使用します。データの一部は分析に含めるのに適しません。
逐語回答の一部はあいまいすぎて実行に移せないため、分析から除外する必要があります。たとえば、「問題ありません」という回答はユーザー体験についてあまり多くを教えてくれないため、NA とタグ付けして脇に置きます。
逐語回答の一部はリサーチ目標や質問に直接結びつかないため、実行に移せず、分析から除外する必要があります。たとえば、SUS の逐語回答分析では、「GitLab は開発者を支援する優れたツールです」のように肯定的なだけの逐語回答は、GitLab の現在のユーザビリティ問題を理解して改善を特定するというリサーチ目標に情報を与えないため、含めません。
**逐語回答の一部には、多くの異なるアイデアや考えが含まれます。**この場合、逐語回答が 1 つのトピックについてのみ語るように分割することで、データをクリーニングできます。これにより、より明確にコードを割り当てられます。たとえば、SUS 分析では、下のテーブルにある逐語回答の段落を、ナビゲーションに関するものと検索に関するものという 2 つの別の逐語回答に分割しました。これにより、元の逐語回答の各セクションにコードを割り当てやすくなります。
| 元の逐語回答 | 逐語回答 1 | 逐語回答 2 |
|---|---|---|
| 「GitLab には、特にナビゲーションについて、私が知らないことが多くあると思います。私たちのチームは GitLab でチケットを管理していますが、GitLab でそれを見つけられたことはありません。検索バーまたはダッシュボード自体で、あらゆることについてより多くのインサイトを提供することで、GitLab の検索を大幅に改善する必要があると思います。」 | 「GitLab には、特にナビゲーションについて、私が知らないことが多くあると思います。私たちのチームは GitLab でチケットを管理していますが、GitLab でそれを見つけられたことはありません。」 | 「検索バーまたはダッシュボード自体で、あらゆることについてより多くのインサイトを提供することで、GitLab の検索を大幅に改善する必要があると思います。」 |
2. データに慣れる。
すべてのデータを読むか、合計回答数が 500 件を超える非常に大きなデータセットを扱っている場合は、データのランダムな 25% のサンプルを読みます。完全なデータセットで出会う逐語回答の感覚をつかむのに十分です。目標は、データがどのようなものかを大まかに把握することです。データを頭に入れ、作成する最終テーマがデータセットを反映していることを確認できるようにします。
3. コードの初期ドラフトを割り当てる。
始めるには、後でレビューするコードの初期ドラフトを作成します。これは分析の生成的な部分であるため、ここであまり長い時間をかけないようにします。代わりに、逐語回答で見たことについての速記メモと考えられます。目標は、コードの初期ドラフトのリストを見直し、どのコードを集約できるかを確認できるようにすることです。
以下のテーブルでは、分析の終わりにすべて同じテーマに一致した 5 つの逐語回答の例を使用しています。分析の初期段階では、これらの逐語回答がこのようにグループ化されることはない点に留意してください。
例を含むテーブル:
| SUS の逐語回答 | コードの初期ドラフト |
|---|---|
| gitlab-ci の新しい「rules」セクションは直感的ではありません。以前のシステムはより複雑ではなく、理解しやすかったです。 | CI ルールは直感的でない、複雑 |
| パイプラインは複雑すぎて混乱します | パイプラインは混乱する |
| 私のユースケースでは、本当に過度に複雑だと感じます。私は Bitbucket から移行しましたが、私と小さなチームが作業するプライベートリポジトリが欲しいだけなのに、これは単に多くのことが起こりすぎているように思えます。 | 多くのことが起きている、シンプルさを求める |
| 異なるパイプラインの表示方法は混乱し、どれが実行中かを知るのが難しいと感じます | パイプラインの表示が混乱する |
| 可能な限り簡素化されることを歓迎します | シンプルさを求める |
注: スプレッドシートで分析を行う場合は、これまでに割り当てたすべてのコードを集約するピボットテーブルを作成すると、割り当てたコードの初期ドラフトすべてをすばやく確認できるため便利です。コードの洗練と集約という次のステップに進むことを考える前に、すべての逐語回答の完全なデータセットでこれを行うことがベストプラクティスです。
4. コードを再帰的に洗練し、集約する。
すべての逐語回答、または少なくともさらに 25% を確認した後にコードを見直して洗練し、新しい逐語回答とデータセット全体をより正確に反映するように洗練できるかを確認します。たとえば、「途方に暮れていると感じる」のようなコードのドラフトから始め、そのコードでより多くの逐語回答を捉えるために「混乱する」に移行する場合があります。以下のテーブルにはさらに例を含めています。
分析のこの部分では、次のような質問を自分に問いかける必要があります:
- このコードを別の方法で再構成した場合、組み合わせられますか?
- これら 2 つのコードは本当にそれほど異なりますか?
- コードをあまりに多く組み合わせて、各逐語回答について意味のあることを言えなくなっていませんか?
- 読んだものの中に、このコードのリストに反映されていないものはありますか。ある場合、それを反映するためにどの新しいコードを作成する必要がありますか?
注: 分析にスプレッドシートを使用している場合は、コードの初期ドラフトに基づいて並べ替え(例: アルファベット順に並べ替える)、find 機能を使用する(例: 各コード内で complex という単語が使用されているすべての箇所を検索する)と、組み合わせる方法を見つけるのに役立ちます。
例を含むテーブル:
| SUS の逐語回答 | コードの初期ドラフト |
|---|---|
| gitlab-ci の新しい「rules」セクションは直感的ではありません。以前のシステムはより複雑ではなく、理解しやすかったです。 | CI ルールは直感的でない、複雑 |
| パイプラインは複雑すぎて混乱します | パイプラインは混乱する |
| 私のユースケースでは、本当に過度に複雑だと感じます。私は Bitbucket から移行しましたが、私と小さなチームが作業するプライベートリポジトリが欲しいだけなのに、これは単に多くのことが起こりすぎているように思えます。 | 多くのことが起きている、シンプルさを求める |
| 異なるパイプラインの表示方法は混乱し、どれが実行中かを知るのが難しいと感じます | パイプラインの表示が混乱する |
| 可能な限り簡素化されることを歓迎します | シンプルさを求める |
5. コードをテーマに昇華し、反復する。
コードの集約リストが得られたら、それらが示す根底にあるテーマを探し、テーマを割り当てて洗練します。分析のこの部分では、リサーチ質問への回答に役立つテーマを特定します。
これを行うには、次のような質問を自分に問いかけます:
- このコードはユーザー体験について何を教えてくれますか?
- このテーマを作成すると、コードを組み合わせられますか?
- このテーマはリサーチ質問に答えている、またはリサーチ目標に沿っていますか?
- 集約テーマを作成すると、データセット全体を見たときに得られたデータのニュアンスを失うほど、広すぎるものになりますか?
- スプレッドシートで作業している場合は、作業を失わずに反復できるよう、元のコードをテーマとは別の列に置いておくと役立ちます。
例を含むテーブル:
| SUS の逐語回答 | コードの初期ドラフト | コードの次のイテレーション |
|---|---|---|
| gitlab-ci の新しい「rules」セクションは直感的ではありません。以前のシステムはより複雑ではなく、理解しやすかったです。 | CI ルールは直感的でない、複雑 | CI ルールは複雑 |
| パイプラインは複雑すぎて混乱します | パイプラインは混乱する | パイプラインは混乱する |
| 私のユースケースでは、本当に過度に複雑だと感じます。私は Bitbucket から移行しましたが、私と小さなチームが作業するプライベートリポジトリが欲しいだけなのに、これは単に多くのことが起こりすぎているように思えます。 | 多くのことが起きている、シンプルさを求める | シンプルさを求める - チームのプライベートリポジトリ |
| 異なるパイプラインの表示方法は混乱し、どれが実行中かを知るのが難しいと感じます | パイプラインの表示が混乱する | パイプラインは混乱する |
| 可能な限り簡素化されることを歓迎します | シンプルさを求める | シンプルさを求める |
6. 最終テーマを決定する。
一般に、テーマは最大 10 個にする必要があります。テーマが多いほど、データを明確に読み取るのが難しくなるためです。組み合わせられないテーマもあり、それは問題ありません。
テーマ数を減らす方法を考えるために、概念的にも、実際に散歩に出かけて休憩するという意味でも、ここで一歩下がる必要があるかもしれません。たとえば、SUS の逐語回答分析では、ユーザー体験を反映するより短いテーマのリスト(例: テーマ: 複雑 / 混乱)を作成できるよう、各逐語回答(例:「パイプラインは複雑すぎて混乱します」)について、トピック(例: パイプライン)の個別リストを作成しました。これにより、逐語回答分析における SUS テーマを 23 のテーマのリストから、より小さい 10 のリストに減らせました。データを見るための 2 つの異なる軸または方法を作成することは、軸索コーディングの一形態と呼ばれ、このハンドブックページの範囲を少し超えます。ここで言いたいのは、テーマ同士の関係を確認するために、異なる種類のテーマを作成することが役立つ場合があるということです。追加のコーディング軸を使用する別の例としては、表現されている肯定的または否定的な感情などのバレンスについて各逐語回答をコーディングし、表現されたユーザーの感情が異なるトピックとどのように関係するか(例: 最も肯定的に話されたトピックはどれか)を確認できます。
例を含むテーブル:
| SUS の逐語回答 | 最終コード | トピック | SUS テーマ |
|---|---|---|---|
| パイプラインは複雑すぎて混乱します | パイプラインは混乱する | パイプライン | 複雑/混乱 |
7. 最終テーマを割り当てる。
テーマの最終リストができたら、データに戻って、各逐語回答にテーマを割り当てたことを確認する必要があります。データ内のテーマ全体の割合を報告できるため、各逐語回答に 1 つのテーマを割り当てることがベストプラクティスです。
例を含むテーブル:
| SUS の逐語回答 | 最終コード | トピック | SUS テーマ |
|---|---|---|---|
| gitlab-ci の新しい「rules」セクションは直感的ではありません。以前のシステムはより複雑ではなく、理解しやすかったです。 | CI ルールは複雑 | CI /CD | 複雑/混乱 |
| パイプラインは複雑すぎて混乱します | パイプラインは混乱する | パイプライン | 複雑/混乱 |
| 私のユースケースでは、本当に過度に複雑だと感じます。私は Bitbucket から移行しましたが、私と小さなチームが作業するプライベートリポジトリが欲しいだけなのに、これは単に多くのことが起こりすぎているように思えます。 | チームのプライベートリポジトリ、シンプルさを求める | リポジトリ | 複雑/混乱 |
| 異なるパイプラインの表示方法は混乱し、どれが実行中かを知るのが難しいと感じます | パイプラインは混乱する | パイプライン | 複雑/混乱 |
| 可能な限り簡素化されることを歓迎します | シンプルさを求める | 該当なし | 複雑/混乱 |
8. 各テーマの例を含むサマリーテーブルを作成する。
最終テーマを定義して割り当てた後(またはそのプロセス中に)、各テーマの例と簡単な説明を含むテーブルを作成します。これにより、ステークホルダーが実施したことを理解しやすくなります。
例を含むテーブル:
| SUS の逐語回答 | 簡単な説明 | SUS の逐語回答例 |
|---|---|---|
| 複雑/混乱 | ユーザーは、GitLab では多くのことが起きている、および/または非常に複雑であると指摘する | 「異なるパイプラインの表示方法は混乱し、どれが実行中かを知るのが難しいと思います」 |
分析に取り組むための専用の時間を確保する必要があります。一般に、分析の完了には 1-2 週間かかります。分析中にコンテキストスイッチする必要がある場合は、これまでに生成したコードまたはテーマを再び理解する時間を取る必要があり、かなり長い休憩を取った場合は、テーマがデータセット全体で確認した内容を反映していることを確かめるために、データセットをレビューする必要があるため、はるかに時間がかかります。
c955a93f)