自由回答の分析:アフターコーディング全手順
目次
業者から戻ってきた自由回答の集計表を、いま開いているとします。「不満の理由」がコード化され、棒グラフになっている。ところが各項目の % を足すと合計が 140% になり、しかも「その他」が 32% を占めています。
この表をそのまま経営会議に出す前に、確かめたいことが 3 つあります。なぜ足して 100% を超えるのか(分母は何か)。「その他」の 32% には何が入っているのか。そして、この分類は誰が・どんな基準でやり、別の人が同じコメントを分けても同じ表になるのか。
この 3 つに自分で答えを出せるようになれば、業者の表は鵜呑みにする相手から検収できる相手に変わります。題材はアフターコーディング、アフターコーディング(自由回答をあとからカテゴリに分類し、コード番号を振って集計できる形にする作業)です。生のコメントの山から業者表の検収まで、全手順を例で追います。題材にするのは、BtoB SaaS のタスク管理ツール利用者に「その満足度を選んだ理由」を聞いた自由回答(FA=自由記述の回答)です。数字は教材用に作った架空のもので、実在する製品や市場の話ではありません。
自由回答は測れる形にしてから数える
アフターコーディングとは、自由回答という言葉を目盛りに変換する測定作業です。数値で聞いた設問には最初から目盛りがありますが、自由回答は目盛りのない生の言葉で、「動作が重くてイライラする」も「サクサク動いて最高」も、そのままでは足し合わせられません。これを「動作・速度=不満」「動作・速度=満足」というコードに割り当てて、はじめて集計できる名義尺度(順序のないカテゴリ)の変数になります。言葉を、あとから測れる形に翻訳する。これがこの作業の正体です。
イメージとしては税関の仕事に近い。税関には世界中から雑多な荷物が届き、職員は中身を見て、あらかじめ決めてある品目表のどれに当たるかを判定し、コード番号を振ります。品目表を先に固定してあるから、どの職員が担当しても同じ荷物は同じ番号に分類され、国の貿易統計になります。もし職員が荷物を見ながら品目表を書き換えていたら、同じ荷物でも通関した日によって別の統計が出てしまう。品目表がコードブック、品目番号がコード、どれにも当てはまらない品を受ける残余の品目が残余コードにあたります。
作業は 5 つの動きに分かれます。読む、決める、凍らせる、合わせる、数える。サンプルを読み、コードの枠を決め、それを凍らせ、複数人で付けても合うかを確かめ、最後に分母を宣言して数える。多くの現場は「読む」を飛ばしていきなり「数える」に走り、そして「凍らせる」を守れずに崩れます。枠をいったん凍らせたら、その先で枠に手を入れるのは全件のやり直しと同じになる。凍結を守れるかどうかが、再現できる集計とできない集計の分かれ目です。アフターコーディングの価値は再現性、つまり第三者が同じ手順をなぞれば同じ数字に着地することにあり、それを壊しやすいのが、この順番を崩すことだからです。
数える前に、どんな集計でも最初に必要な下ごしらえがあります。分母の確定です。総回答は 240 件。ただし、この 240 をそのまま分母にはできません。冒頭のスクリーニング設問 SC1(直近 3 ヶ月に対象ツールを業務利用したか)で「利用していない」と答えた 18 件は、分析対象外だからです。
- 出発点: 総回答 240 件
- そこから除外:
SC1=2(非利用)18 件 - 分析ベース:
n = 222
さらに、自由回答の設問 Q9(満足度を選んだ理由)には無回答が 4 件あります。空欄はコードのしようがないので、分母から外します。コード対象は 218 件(222 − 4)です。以降、自由回答の集計は原則この 218 を出発点にします。まず分母を決めてから数える。この順序は、数値の設問でも自由回答でも変わりません。
コードは回答を読んでから立ち上げる
最初の 1 件を見ると、すぐコードを付けたくなります。ここで手を止められるかが、最初の分岐点です。コードの枠(コードフレーム)を、机上で先に想像で作ってはいけません。「満足の理由なんてだいたい価格・機能・サポートでしょ」と決め打ちで枠を作ると、実際の回答とズレて、取りこぼしが大量に「その他」へ落ちます。正しい順は逆で、まず回答そのものを読み、頻出する意味のまとまりを回答の側から拾い上げます。質的データ分析の教科書(Miles・Huberman・Saldaña)では、この最初の一巡を第 1 サイクル・コーディングと呼びます。手触りは、付箋に一件ずつ書いて似たものを島に寄せていくKJ法(親和図法)に近い。「これは動作の速さの話」「これはサポートの話」と、回答が自分から言っている塊を見つけていきます。
では、何件読めば枠づくりをやめていいのか。手がかりは「新しい塊が出てこなくなる」感触です。最初の数十件は新しいカテゴリが次々に現れますが、やがて「これはさっきの動作・速度だな」「これも価格だな」と、既知の塊への振り分けばかりになります。新規カテゴリの出現が頭打ちになったあたりが、読み込みを打ち切る目安です。
ただし、数字は借りないでください。定性研究には理論的飽和(新しい発見が出尽くす点)という概念があり、「インタビューは何本で足りるか」を調べた研究(Guest ら 2006)では、大半のテーマが最初の 12 件ほどで出そろったことが知られています。でも、この 12 を自由回答にそのまま持ち込んではいけません。あれは一人が何十分も語る逐語データの話で、短い一文が並ぶ自由回答とは密度がまるで違う。借りていいのは「新規カテゴリの出現が頭打ちになったら打ち切る」という論理だけです。件数は性質の違う土俵からの借り物なので、転記した瞬間に嘘になります。これは経験則であって、法則ではありません。
実務では、この読み込みを全件の一部で行います。Pew Research Center のコーディング手順では、無作為に抜いた標本でコードブックを反復開発し、75 件以上で検証してから全件に進みます。まず一部を読んで枠を立て、その枠を全件にぶつける。順序はここでも同じです。
枠は適用の前に凍結する
読み込みで拾った塊を、枠にします。拾ったカテゴリを、コードブック(コード番号・定義・データからの実例をまとめた一覧)に落とす。頭の中のなんとなくの分類を、他人が読んで同じように運用できる文書にする作業です。定義は、あいまいな形容ではなく「何が書いてあればこのコードを付けるか」という操作的定義(手順で判定できる形の定義)で書きます。ここで手を抜くと、隣のコードと食い合います。たとえば 05 価格 を「コストの話」とだけ書くと、06 学習コスト の回答に出てくる「学習コスト」の「コスト」の字面まで拾ってしまう。だから「金額・料金・費用対効果に言及していれば 05 価格。覚える手間・設定の複雑さは金額の話ではないので 06 学習コスト へ回す」と、隣との境目まで定義に書き込みます。ここまで手順化して初めて、誰が読んでも判定がぶれにくくなります。
下表が、例のコードブックです(コード対象 218 件)。ネットは報告用の大分類、コードは集計の最小単位で、定義は「何が書いてあれば付けるか」、例は実際の回答から採っています。
| ネット | コード | 定義(これが書いてあれば付ける) | 回答例 |
|---|---|---|---|
| 機能・品質 | 01 動作・速度 | 表示や操作の速さ・重さ・固まりに言及 | 「動作が重く、画面の切り替えに時間がかかる」/「動作が軽快でストレスがない」 |
| 機能・品質 | 02 使いやすさ | 画面の分かりやすさ・操作性に言及 | 「画面が直感的で、タスク管理が楽になった」/「操作が分かりにくく、覚えるのに時間がかかる」 |
| 機能・品質 | 03 機能不足 | 欲しい機能がない・連携が弱いなど | 「欲しい機能が足りない。ガントチャート表示に対応してほしい」 |
| 価格・導入 | 04 サポート | 問い合わせ対応の速さ・質に言及 | 「サポートの返信が遅く、問い合わせても数日かかる」 |
| 価格・導入 | 05 価格 | 学習・設定の手間を除く、金額・料金・費用対効果への言及 | 「機能の割に価格が高く、コストに見合わない」 |
| 価格・導入 | 06 学習コスト | 覚える手間・設定の複雑さに言及(金額ではなく手間のコスト) | 「設定が複雑で、使いこなすまでの学習コストが高い」 |
| 残余 | 90 その他 | 上記の具体語を含まない好意的・中立コメント | 「とても満足しています」「可もなく不可もなく」 |
| 残余 | 99 無回答 | 空欄・「特になし」など | (分母から外す) |
枠を組むとき、2 つの性質を意識します。1 つは、言及のレベルで相互排他にすること。1 つの言及が 2 つのコードに落ちないよう、定義の側で境目を切ります(さきほど 05 価格 と 06 学習コスト で、同じ「コスト」の字を金額と手間に切り分けたのがこれです)。もう 1 つは、網羅性。どんな回答も必ずどこかに落ちるよう、90 その他 と 99 無回答 という受け皿を置きます。この相互排他かつ網羅は、実務では MECE 寄りの枠などと呼ばれます(MECE はコンサル由来の実務語で、厳密な数学用語ではありません。中身は排他+残余で網羅というだけです)。
残余コードの 90 その他 を必ず置くのは、飾りではなく必須の作法です。Pew の実運用でも、残余コード(vague positive などの受け皿)と「分からない/無回答」のコードを明示的に立てています。受け皿がないと、枠に収まらない回答が行き場を失い、コーダーが無理やりどこかに押し込む。そのぶん他のコードの数字が汚れます。「その他」は枠の失敗ではなく、枠の健全性を保つ排水口です。
粒度が近いコードは、ネット(上位のまとめ)に束ねておきます。上表の「機能・品質」「価格・導入」がそれで、経営報告では細かいコードよりこの大分類のほうが話が通りやすい。ここは順序が大事で、細かく取って粗く見せることはできても、粗く取ったものを後から細かくは割れません。
「その他が膨らみすぎたら枠を切り直す」という助言をよく聞きます。妥当ですが、「その他は何 % 以下に抑えるべき」という明確な閾値には、私は信頼できる出典を持っていません。だからこれは法則ではなく、運用上の目安として扱ってください。残余が大きすぎると感じたら、その中身を読み返して新しいコードを立てられないか検討する、という判断のきっかけであって、「20% を超えたらアウト」のようなラインではありません。
枠が固まったら、適用の前に凍結します。コーディング前に枠を作り込んでおくほどコーダー間の信頼性が上がることは、自由回答のコード化を測定問題として最初に定式化した古典的な研究(Montgomery & Crittenden 1977)でも示されています。彼らの言葉を借りれば、コーディングしながら事後に枠を直していく方法より、先に枠を設計してから適用する方法(a priori 手続き)のほうが、はるかに再現性が高い。
複数コードにするなら分母を宣言する
全件のコーディングに入る前に、決めておく設計判断があります。1 つの回答に複数のコードを付けてよいか、です。これを決めないまま数え始めると、あとで分母が崩れます。現実の回答には、こういうものが混じります。「動作が重いうえに、サポートの返信も遅い」。これは 01 動作・速度 でもあり 04 サポート でもある。ここで道が 2 つに分かれます。1 つは単一コードで、最も強い 1 つだけ付ける。この場合、各回答はちょうど 1 つのコードを持ち、% の合計は 100% になります。もう 1 つは複数コード(mark all that apply)で、当てはまるものを全部付ける。この場合、1 つの回答が複数のコードに数えられるので、% の合計は 100% を超えます。
Pew の実務では、大半の回答が複数のカテゴリに言及するため、複数コードを採っています。ただし二層構造があって、1 つの「言及」は相互排他(さきほどの 05 価格 と 04 サポート は別物)ですが、1 つの「回答」は複数の言及を含みうる。だから回答単位では複数コードになります。1 通の回答に複数の論点が詰まっている、と考えると腑に落ちます。
どちらを選んでもかまいません。大事なのは、選んだら表に明記することです。複数コードを採ったなら、集計表の頭にこう書きます。「分母=回答者 n = 218。1 回答に複数コード可のため、% の合計は 100% を超える」。これは複数回答(MA=あてはまるものを複数選ぶ設問)の集計とまったく同じ考え方です。冒頭の業者表の「合計 140%」も、正体はこれかもしれません。140% は間違いではなく、複数コードだと宣言し忘れているだけのことがある。だから冒頭の表を見たら、詰め寄る前にこう聞けばいい。「これは複数コードですね。分母は回答者数で合っていますか」。脅威ではなく仕様かどうかを、まず確かめます。
この「分母=回答者・合計 100% 超」は、数理法則ではなく複数回答の集計上の慣行です。だから、宣言してあれば正しく読め、宣言がなければ読めない。合計が 140% でも、分母と複数コードの但し書きがあれば、それは正しい表です。
下表は、例の実際のコーディング結果から抜いたトレースです(分母=回答者、複数コード可)。1 つの回答に複数コードが付く様子を示すための抜粋で、全件ではありません。
| 回答(逐語) | 付与コード |
|---|---|
| 「動作が重いうえに、サポートの返信も遅い」 | 01 動作・速度 + 04 サポート(複数コード) |
| 「操作が分かりにくく、覚えるのに時間がかかる」 | 02 使いやすさ + 06 学習コスト(複数コード) |
| 「機能の割に価格が高く、コストに見合わない」 | 05 価格 |
| 「画面が直感的で、タスク管理が楽になった」 | 02 使いやすさ |
| 「とても満足しています」 | 90 その他(具体語なし) |
例では、複数コードが付いた回答が 14 件ありました。内訳は「使いやすさ+学習コスト」6 件、「動作・速度+サポート」4 件、「機能不足+価格」4 件です。さきほど定義で切り分けたとおり、「価格+学習コスト」の組は出ません。この 14 件があるぶん、コードの延べ数は回答者数の 218 を上回ります。
ぶれは気合ではなく枠で抑える
枠を凍結し、複数コードの可否も決めました。ようやく 218 件を機械的に分類していく段です。人手のコーディングは、必ずぶれます。同じ人が別の日に付けても違うことがあるし(コーダー内のぶれ)、別の人が付ければなおさら違う(コーダー間のぶれ)。このぶれを気合や才能で消そうとしても無理で、枠と規則で構造的に抑えるしかありません。だからコーダーが複数いるなら、コードブックに加えて「迷ったときの寄せ方」の判断ルールを渡します。「サポートと価格の両方に読めるときは、より具体的に書かれているほうを主コードにする」といった、迷いを一意に潰すためのルールです。Pew では、コーダーを訓練用の 100 件ほどで練習させ、基準に届かない人には追加訓練をしてから本番に入れています。
ここで、枠をいじりたくなる誘惑が来ます。「このコード、2 つに割ったほうがいいな」。その気持ちは正しいことも多い。でも、割った瞬間に凍結を破ることになります。枠を変えたら、すでにコードした分も新しい枠で付け直さないと、前半と後半で基準の違う、つまり再現できないデータになる。だから枠を触るなら「全件やり直し」を選ぶ覚悟で触る。その覚悟が持てないなら、気づいた改善は次回の調査のコードブックにメモしておくのが正解です。今回の枠は、今回の分だけは、凍らせたまま走り切ります。
コーダー間の一致は偶然を割り引いて測る
全件のコードが一通り終わると、静かな不安が来ます。「この分類、信用していいんだろうか」。ここが再現性の検証です。やることは、サンプルを 2 人が独立にコードして、どれくらい一致するかを測る(ダブルコーディング)。ここで、単純な一致率をそのまま信じてはいけません。偶然でも一致してしまうからです。あるコードが全体の 1 割しか出ないなら、2 人が当てずっぽうで「これはそのコードじゃない」と言うだけで、かなりの率で一致してしまう。だから偶然分の一致を割り引いた指標を使います。それが Cohen の κ(カッパ) です。統計的検定とは別物で、偶然の一致を補正した一致度を表す係数です(名義の多値カテゴリなら Krippendorff の α を使いますが、考え方は同じ)。
算術を、例で追います。04 サポート のコードを対象に、全 218 件のうち 50 件を、説明用に立てた 2 人のコーダー(実在しません)が独立に「サポートに当たる/当たらない」で付けたとします。何件を二重コードするかに数理的な正解はありません。実務の目安としては、全体の 1〜2 割か、まれなコードでも一致を測れるだけのヒット数(二桁は欲しい)が乗る件数を採ります。ここでは 218 件の 2 割強、50 件にしました(精度を厳しく見たいほど厚くする、という著者の目安です)。結果はこうなりました。
下表は説明用に作った作例です(n = 50、04 サポート か否かの 2 値)。数値は κ の算術を示すための仮想の例で、集計データではありません。
| コーダー B:サポート | コーダー B:非サポート | 計 | |
|---|---|---|---|
| コーダー A:サポート | 9 | 3 | 12 |
| コーダー A:非サポート | 3 | 35 | 38 |
| 計 | 12 | 38 | 50 |
2 人が一致したのは、対角線の「両方サポート」9 件と「両方非サポート」35 件で、合わせて 44 件。観測一致率は Po = 44 / 50 = 0.88 です。一見、88% も合っていて上等に見えます。ところが、ここに偶然分が紛れています。偶然に一致する率 Pe は、周辺の比率から出します。2 人ともサポートと付ける偶然の率が (12/50) × (12/50)、2 人とも非サポートと付ける偶然の率が (38/50) × (38/50)。足すと Pe = 0.0576 + 0.5776 = 0.6352。でたらめに付けても 63.5% は一致してしまう土俵です。
そこで κ は、観測一致から偶然分を差し引き、偶然を超えてどれだけ一致したかを測ります。
κ = (Po − Pe) / (1 − Pe) = (0.88 − 0.6352) / (1 − 0.6352) = 0.2448 / 0.3648 ≈ 0.67
生の一致率は 88% でも、κ は 0.67。この落差が、κ を使う理由そのものです。サポートというコードが比較的まれ(12/50)なので偶然一致の土俵が高く、88% の見かけほど 2 人は同じ基準を共有できていなかった。ここで実務のベンチマークが登場します。Pew は運用基準として α(や κ)が 0.70 以上を採用の条件にしています。0.67 はこれに届きません。
ここは正直に線を引きます。0.70 は Pew の実務ベンチマークであって、数理的に導かれた普遍の閾値ではありません。よく引かれる「κ が 0.6〜0.8 なら substantial」という解釈区分(Landis & Koch)も、提唱者自身が恣意的だと認めた目安です。だから 0.67 を機械的に不合格と断じず、「基準に少し届かない=枠かルールに曖昧さが残るサイン」と読みます。従う価値はあります。共通のものさしがないと品質を議論できないからです。破ってよいのは、分野で妥当な水準が違うと分かっていて、その判断を明示できるときだけです。
届かないときにやるのは、不一致をレビューして、枠かルールを直し、該当分を付け直すことです。この作例で 2 人が食い違った 6 件(3 + 3)を読み返すと、「サポート」という語は無いが「問い合わせても返事が来ない」と書いた回答を、A は含め、B は外していた、と分かったとします。そこで判断ルールに一文足します。「問い合わせ対応の遅速に触れていれば、サポートの語が無くても 04 に寄せる」。この改訂で付け直すと、食い違いが 1 件ずつに減り、Po = 48/50 = 0.96、周辺比率は同じなので κ = (0.96 − 0.6352) / 0.3648 ≈ 0.89。0.70 を超えました。曖昧だったのはコーダーの能力ではなく、枠の定義だったわけです。
ここで、この記事全体の境界も引いておきます。κ を追うのが正しいのは、あくまで数えることが目的のときです。テーマ分析の提唱者(Braun & Clarke)は、解釈の深さを狙うリフレクシブな分析では、κ や多コーダーの合意、正確なコーディングを追い求めないよう明確に諫めています。深い解釈では、2 人が違う読みをすること自体が資源になりうるからです。裏を返せば、κ が意味を持つのは、自由回答を意思決定用の数字に落とすアフターコーディングのときに限られます。解釈の深さがほしくなったら、それはもうこの記事の守備範囲の外、圧縮せずに読む定性分析の仕事です。数える道具で、味わいまで測ろうとしないこと。
分母を宣言して集計しクロスに乗せる
一致が確認できて、ここでやっと集計です。まずは、コードごとの単純集計(全体を 1 つの分母で見る集計)。
下表が、例のコード別出現件数です。入力は Q9 のコード化結果、分母は回答者 218(222 − 無回答 4)、複数コード可のため延べ数と % 合計は 100% を超えます。% は小数第 1 位で四捨五入。
| コード | 件数 | %(分母 218) |
|---|---|---|
01 動作・速度 | 34 | 15.6% |
02 使いやすさ | 31 | 14.2% |
04 サポート | 20 | 9.2% |
06 学習コスト | 16 | 7.3% |
03 機能不足 | 12 | 5.5% |
05 価格 | 9 | 4.1% |
90 その他(残余・具体語なし) | 110 | 50.5% |
| 延べ合計 | 232 | 106.4% |
この表には、見どころが 2 つあります。1 つは、延べ 232、合計 106.4% という数字。回答者は 218 人、付いたコードは延べ 232 個(1 回答あたり平均 232/218 ≈ 1.06 個)で、合計が 100% を超えても、頭に分母と但し書きがあるから読めます。もう 1 つは、いちばん大きいコードが 90 その他 で、単独で 50.5% だということ。回答者の半分が「とても満足」「可もなく不可もなく」のような、具体語のない好意的・中立コメントを書いています。
これは失敗ではありません。満足度の理由という設問では、満足している人ほど具体的な不満を書かず、ふわっと褒める傾向があるので、残余が大きくなるのはむしろ自然です。ただし、さきほどの運用上の目安がここで効きます。50.5% は無視できない大きさなので、この残余をさらに割れないかを一度は検討する。もし経営が満足の中身を知りたいなら、残余を読み返して「価格に見合う」「チームで定着した」のような下位コードを新設する余地はあります(ただし新設すれば凍結を破るので、全件付け直しです)。割らないと決めるなら、それも判断として明記する。残余は、放置する箱ではなく、毎回開けて中身を確認する箱です。
コード化がうまいのは、ここからです。自由回答が 01〜90 の 1 つの名義変数になった以上、それは他の設問とクロス集計(2 つの設問を掛け合わせた表)できます。数値設問とまったく同じ土俵に乗った。たとえば「どんな理由を書いた人が、実際に満足度が低いのか」を、総合満足度 Q4 と掛けてみます。
下表は、コードと総合満足度 Q4 のクロスです。入力はコード化結果と Q4、分母は回答者 218。「具体的な不満ドライバーに言及」は 01 動作・速度/04 サポート/05 価格/03 機能不足/06 学習コスト のいずれかを含む回答で、02 使いやすさ は外しています。満足度は不満(Q4 が 1–2)・中間(3)・満足(4–5)で区分。
| 不満(1–2) | 中間(3) | 満足(4–5) | 計 | 不満率 | |
|---|---|---|---|---|---|
| 具体的な不満ドライバーに言及 | 56 | 13 | 14 | 83 | 67.5% |
| それ以外(残余・使いやすさ単独など) | 8 | 60 | 67 | 135 | 5.9% |
では、なぜ 02 使いやすさ だけ、れっきとした具体コードなのに不満ドライバーから外したのか。使いやすさへの言及は、称賛(「直感的で楽」)と不満(「分かりにくい」)がほぼ半々で、コード別の平均満足度も 3.13 と、中立点(3)の上に乗り、残余の 90(3.55)に近い。つまり「書いた人が不満側に寄る」コードではないのです。残り 5 つは(01 動作・速度 でさえ平均は中立点の下)「書いた人ほど不満」の信号を持つのに、02 はそれを持たない。だから混ぜると 67.5% の信号がぼやけるので、不満側の 5 コードだけを束ねました。これは分析目的に合わせた線引きで、数理が決めた区分ではありません(使いやすさを独立の軸として見たいなら、それはそれで正しい)。
その線引きの上で、きれいな信号が出ます。具体的な不満ドライバーを書いた 83 人は、67.5% が満足度でも不満(1–2)。一方、それ以外の 135 人は、不満がわずか 5.9% で、大半が中間か満足に寄っています。当たり前のようでいて、これは重要な確認です。自由回答の「その他 50.5%」は放っておいても大丈夫な満足層で、意思決定に効くのは不満ドライバーを書いた 83 人のほうだ、と数字で言える。冒頭の業者表の「その他 32%」を前に固まらずに済むのは、この読み筋を持っているからです。
もっと細かく、コード別の平均満足度も見えます。03 機能不足 を書いた人の平均満足度は 1.67、04 サポート は 2.55、05 価格 は 2.56 と、不満ドライバーほど満足度が低い。逆に 90 その他 は 3.55 で高め。ただし、注意が要ります。これらの平均は、各コード 9〜110 件という薄い土台の上に乗っています。03 機能不足 の 1.67 は 12 件だけの平均で、動かしやすい。属性でさらに割れば、セルはもっと薄くなります。たとえば「価格の不満はプランで違うか」を無料と有料で割ると、価格コードは無料 4 件・有料 5 件まで痩せてしまう。
だからここで、集計の作法を 1 つ。セルが薄くなったら、その差が偶然かどうかを単純集計の見た目で決めない。期待度数が小さい(目安として 5 未満の)セルが出るクロスは、そのまま有意差(偶然では説明しにくい差)を論じるのに向きません。差が本物かを確かめる検定は、この記事の外、有意差検定を Excel で回す別記事の役目です。この記事では「コード化すればクロスに乗る」ところまでを見せ、その差が偶然かは次の道具に渡します。逆に、さきほどの 83 対 135 のような大きな塊での比較は土台が厚いので、方向性の話としては十分に読めます。厚いセルで方向を語り、薄いセルは検定へ送る。この線引きが、数字で足をすくわれないコツです。
手動とテキストマイニングは役割が違う
一通り回し終えました。報告に載せる前に、この手法の守備範囲を確認します。最初に来る自己ツッコミは、たぶんこれです。「こんな手間をかけず、AI やツールに全部やらせればよかったのでは」。ここで、アフターコーディングとテキストマイニング(自然言語を自動で解析し語の頻度や共起を出す手法)の分担をはっきりさせます。両者は競合ではなく、役割が違う。
アフターコーディング(手動)は、人の意味判断で、再現できるコードの枠を作り、意思決定に使える数字に落とす手法です。「動作が重い」も「切り替えが遅い」も「もっさりする」も、人間なら同じ 01 動作・速度 だと分かる。この意味の同一視が、手動の強みです。テキストマイニング(自動)は、語の頻度や共起を、ボトムアップに大量に出す手法で、探索の当たりを付けるのは速い。ただし、それを「動作・速度」のような意味カテゴリに束ねさせようとすると、結局、人がコード化した訓練データが要ります。カテゴリの正解を人が与えないと、機械は「重い」と「もっさり」を同じ箱に入れてくれない。完全自動で、妥当な相互排他の枠が手に入るわけではないのです。
だから使い分けは、目的と量で決まります。少量〜中量で、意思決定に載せる分類がほしいなら手動のアフターコーディング。大量のテキストで、まず語の当たりを付けたいならテキストマイニング。大量を分類したいなら、手動で枠と訓練データを作り、それを機械に適用させるハイブリッド。営業に「AI が全自動でコード化します」と言われたら、一言こう返せます。「訓練データは何を使い、コーダー間一致はいくつ出ますか」。
正直に言うと、手動と自動の精度を数値で比較した硬い一次資料は、私はこの記事のために十分に確保できませんでした。だからここは概念的な対比に留めています。「自動のほうが N% 劣る」といった数字は、いまは出しません。
手動のアフターコーディングにも限界があります。コード化は情報の圧縮です。「価格は高いけど、機能を考えれば納得はしている」という含みのある一文を 05 価格 の一票に畳んだ瞬間、そのニュアンスは落ちます。これは処理の宿命で、失敗ではありませんが、忘れると数字を過信します。深い意味や語られ方そのものが知りたいなら、圧縮せずに読む定性分析へ回すべきで、それはもうアフターコーディングの仕事ではありません。そして今回の数字は架空データなので、ここで測れたのは手順であって、このツールの実際の評判ではありません。
では、冒頭のあの業者表(合計 140%、その他 32%)に戻りましょう。いまなら、詰まらずに検収できます。業者に、逐語でこう聞けばいい。
- コードフレームとコード定義を見せてください(枠は何を根拠に、何件読んで作りましたか)
- 分母は回答者数ですか、それとも複数コードの延べ数ですか(140% の出どころ)
- コーダー間一致(κ か α)はいくつですか
- 「その他 32%」の中身は何で、割り直せますか
- 枠はいつ凍結しましたか、それとも読みながら足しましたか
この 5 つに澱みなく答えが返ってくる表なら、会議に出していい。どれか 1 つでも詰まるなら、そこが弱点です。隣で上司が「この自由回答、まとめといて」と言ったときの即答は、こうなります。「まず 218 件を凍結した枠でコード化して、コーダー間一致を確かめてから、満足度とクロスして出します。具体的な不満を書いたのは全体の 4 割弱で、そこが打ち手の的です」。
自由回答は、聞いた瞬間はただの言葉の山です。それを感覚で仕分けて「その他」に流すのか、凍結した枠という測定器を一度作って、誰がなぞっても同じ数字が出る形にするのか。手間は後者のほうが確実に重い。それでも、経営会議のスライドに載せて意思決定を動かすのは、再現できる数字のほうであるべきだと私は思います。あなたの自由回答の集計も、誰かがそれを信じて動くなら、同じ規律に値します。
参考文献
- Montgomery & Crittenden (1977). “Improving Coding Reliability for Open-Ended Questions.” Public Opinion Quarterly 41(2): 235–243. https://academic.oup.com/poq/article-abstract/41/2/235/1935049
- Matthew B. Miles, A. Michael Huberman & Johnny Saldaña. Qualitative Data Analysis: A Methods Sourcebook. 3rd ed. SAGE, 2014.
- Alan Agresti. Categorical Data Analysis. 3rd ed. Wiley, 2013. ISBN 9780470463635.
- Jacob Cohen (1960). “A Coefficient of Agreement for Nominal Scales.” Educational and Psychological Measurement 20(1): 37–46. DOI:10.1177/001316446002000104
- J. Richard Landis & Gary G. Koch (1977). “The Measurement of Observer Agreement for Categorical Data.” Biometrics 33(1): 159–174. DOI:10.2307/2529310
- Greg Guest, Arwen Bunce & Laura Johnson (2006). “How Many Interviews Are Enough? An Experiment with Data Saturation and Variability.” Field Methods 18(1): 59–82. DOI:10.1177/1525822X05279903
- Virginia Braun & Victoria Clarke (2006). “Using thematic analysis in psychology.” Qualitative Research in Psychology 3(2): 77–101. DOI:10.1191/1478088706qp063oa / thematicanalysis.net
- Klaus Krippendorff. Content Analysis: An Introduction to Its Methodology. 3rd ed. SAGE, 2013. ISBN 9781412983150.
- Pew Research Center. “Appendix A: Coding methodology”(2024-03-13)https://www.pewresearch.org/global/2024/03/13/appendix-a-coding-methodology-democracy/ / “Appendix C: Codebook”(2021-11-18)https://www.pewresearch.org/global/2021/11/18/meaning-of-life-spring-2021-appendix-c-codebook/