こんにちは、アイダです。Tableau Prepでのアンケート分析に苦戦しているみなさま必見です！！ Tableau大好きなAI・DXビジネス本部のKさんもその一人。そのKさんの解決策とは？！
はじめに
「アンケートデータを BI ツールで扱うのはたいへん」という声をよく聞きます。
"たいへん" というのは集計分析ではなく、前処理のことを指しているのだろうと思います。
私も御多分に洩れず、一度は Tableau Prep でアンケートデータの前処理を試みた人間です。
が、私はもう Tableau Prep でそれを実現することは諦めています、少なくともローカルPCのリソースでは。
そのあたりのことを書こうと思います。
目指すデータフォーマットは決まっている
縦持ちですね。 ここでは詳しく扱いませんが、KCME さんの記事（ Tableauにおけるデータの縦持ちと横持ちについて ）などで感覚的につかめるかと思います。
アンケートデータは一般的に回答者ごとに1行、回答値が列方向に並ぶようなデータフォーマットになっています。
| 回答者ID | Q1 | Q2 | Q3 | … |
|---|---|---|---|---|
| A0001 | 1 | 3 | 32 | … |
| A0002 | 3 | 2 | 21 | … |
| … | … | … | … | … |
これを縦持ちにしてしまえばいいだけの話です。
| 回答者ID | 質問 | 回答値 |
|---|---|---|
| A0001 | Q1 | 1 |
| A0001 | Q2 | 3 |
| A0001 | … | … |
| … | … | … |
| A0002 | Q1 | 3 |
| A0002 | Q2 | 2 |
| A0002 | … | … |
| … | … | … |
質問ごとの集計をしたいのであれば、この縦持ちデータをそのまま使えばよいですし、 クロス集計をしたいのであれば、この縦持ちデータで自己結合をすればよいのです。
では、なにが課題なのか。
マルチアンサーの回答データの処理です。
これも同様に縦持ちにすればいいのですが、Prep だとパフォーマンス問題にぶつかりやすいのです。
マルチアンサーのデータフォーマット
アンケートデータにおいて、マルチアンサーのデータフォーマットは以下の4つをよく目にします。
セル別 0/1
回答選択肢の数だけ列を持ち、回答者が選んだ選択肢に対応する列に1を、それ以外に0がセットされます。
| 回答者ID | Q1_1 | Q1_2 | Q1_3 | Q1_… |
|---|---|---|---|---|
| A0001 | 1 | 0 | 1 | 1 |
| A0002 | 0 | 1 | 1 | 0 |
| … | … | … | … | … |
セル別 選択肢ID
最大回答数の分だけ列を持ち、回答者が選んだ選択肢IDが左詰めでセットされます。
| 回答者ID | Q1_1 | Q1_2 | Q1_3 |
|---|---|---|---|
| A0001 | 1 | 3 | 4 |
| A0002 | 2 | 3 | |
| … | … | … | … |
セル内 0/1
質問ごとに1列とし、その列内の位置で回答値を表します。
先頭がゼロになる可能性があるため、数値型ではなく文字列型で扱う必要があります。
| 回答者ID | Q1 |
|---|---|
| A0001 | 1011 |
| A0002 | 0110 |
| … | … |
セル内 選択肢ID
質問ごとに1列とし、カンマ区切りで選択肢IDがセットされます。
これも文字列型ですね。
| 回答者ID | Q1 |
|---|---|
| A0001 | 1,3,4 |
| A0002 | 2,3 |
| … | … |
個人的なおススメは セル内 選択肢ID です。
セル別のフォーマットは、どちらもデータファイル全体の列数が巨大になりがちで、処理限界に直面しやすいです。
セル内 0/1 は先頭から何桁目かという判定処理を入れなければいけませんし、選択肢数に比べて回答値が少ない場合に非効率です。
なぜ Prep を諦めたのか
すべては処理パフォーマンスです。 機能的には Tableau Prep でも対応できるのですが、実際のアンケートデータと向き合ってみると、 マルチアンサーの質問は何個もあるし、その選択肢も100を超える場合もあります。
それに対して、Prep でワークフローを作っていくのは無謀だなと考えました。
ましてや、弊社の場合はアンケートデータはどんどん発生して、それに合わせてこのような対応方法は現実的ではない...
ということで、Python でアンケートデータの縦持ち変換処理を実装することにしました。 AWS Glue の Python shell で動かしているので、コストもたかがしれています。
その後、その Python shell でも処理しきれないデータ（ MAT-kit ）がでてきたので、 いまでは AWS Glue で Spark 版も用意して、データサイズによって使い分けをしています。
おわりに
大前提として、BIツールはアンケートデータに特化したツールではありません。
調査会社が提供するアンケート集計ツールには到底およびません。
しかし、さまざまなデータを1つのツールで利用できるということはデータ利用者にとってはメリットになるはずです。 過度な期待はせず / させず、うまくツールを使い分けていきましょう。
