〈開発者ブログ 新連載〉Vol.3
～ データの可視化・分析について ～

データ可視化・分析に関する記事の3回目、前回の記事の続きになります。

• 第1回：Vol.1 データの可視化は〇〇〇〇
• 第2回：Vol.2 その分析に○○は含まれるか - メジャー編 -

前回はメジャーにおけるポイントを説明しましたので、今回はディメンションをポイントに置いて説明します。

メジャーとかディメンションって何だっけ？という方は、ぜひ前回の記事を読み返してみてください。
重要な点のみ以下に再掲しておきます。

ディメンションに関する失敗例

ディメンションで最もわかりやすい失敗例は次の通りです。

あなたはある指標について分析を行っています。
部門というディメンションで切りとっていくと、データエンジニアリング２部に問題がありそうなことがわかりました。
そこでデータエンジニアリング２部の○○さんにその事実を伝えます。

すると「そんなこと、わかってるよ」とつれない返答、しかも何か機嫌が悪そうです。

ある指標を「売上」とか「平均残業時間」に置き換えてみるとわかります。

セリフにもありましたが、（よっぽど新しいメジャーを分析対象にしていない限り）先ほどの例はその部門をマネジメントしている人なら既に知っている事実を伝えているにすぎません。
だから嫌味ととられて機嫌を損ねてしまったのかもしれないですね。

このようなことは、現場においても実際に起こる可能性は低いでしょう。
なぜなら、分析している本人も「これはさすがにない」と気づくからですね。
ただし手元でこういった結果が出てしまい、そっと閉じることは何度もあるのではないかと思います。

ここで一番伝えたかったことは、
わかりやすいディメンションで数値を切り取っていくだけでは、分析としての鋭さに欠けてしまう
ということです。

その分析にビンは含まれるか

では、どうすればよいでしょうか。

今回は先に答えをお伝えしようと思います。
このときにとるべきアプローチは、定量情報から定性情報を作り出すことです。
すなわち、メジャーからディメンションを作ります。

どういうことかというと、メジャーを分割してグループ化します。
たとえば、試験で81点～100点を取った人をグループAとする、というのが定量情報から定性情報を作るということになります。

このグループのことをビンと呼び、ビンに分割していくことをビニングと呼びます。
（ビン化とかビン分割と言ったりもします）

サッカーのW杯の組み合わせ抽選においては、FIFAランクによるポット分けがされています。
FIFAランキングを上から順に8ヶ国ごとにグループにわけて第１ポット～第４ポットに分けていますね。
これもビニングにあたります。

この連載では当たり前を言語化することをテーマに書いてきていますが、ビニングも既に当たり前に取り入れられている概念になります。

いま私はAWSのre:Inventに参加した帰りのANA運航の航空機の中でこの記事を推敲しています。
ANAプレミアムメンバーも、ポイントによってブロンズ、シルバーなどステイタスが分かれていますね。
分析起点ではありませんが、これもビニングにあたります。

CRMでは一般的に購買回数や購買金額によってビニングされた会員ランクなどが分析の軸になります。
よく知られている分析手法では、RFM分析やコホート分析、デシル分析などは全てビニングを活用していると言えます。
※メジャーのまま使ってしまうこともあります

自身の分析にビンが入ってないと気づいた方は、ぜひビニングしたディメンションを分析軸に入れてみてください。
当社を例にとると、製品識別コードや利益センタコードごとの分析しかしていなければ、案件規模やチーム人数などでビニングしたビンを軸に入れて分析をかけてみる、そんなイメージになります。

ビンについて調べると調べると必ずヒストグラムが出てきます。

ヒストグラムはビニングそのものなので、まずヒストグラムで分布を見てディメンションとして適切かどうか確認します。
たとえば、先ほど「81点～100点を取った人はグループAとする」という例を出しましたが、全体の90%のがこのグループにいたら分析として成り立ちません。

ヒストグラムである程度意味がありそうなビンに分割にしたうえで、ディメンションとして利用するという順序になります。

私のおすすめは、ビンかメジャーどちらかをSoR領域のデータから選び、もう一方をSoE領域のデータから選ぶ方法です。
SoRとSoE両方のデータがひとつの分析に混在する時点ではじめの一歩からは抜けているともいえるのですが、さらにその一歩先というイメージになるでしょうか。

例を挙げます。

• SoR領域からお客様との取引規模を抜き出して、ビニングします。
  ～3000万、3001万～5000万などのイメージです。
• SoE領域からNPS調査の結果データを抜き出してメジャーとして使用します。

たとえば、～3000万のビンの方が3001万～5000万のビンより、NPSスコアが良いと出ます。
そうすると「活動が取引規模が大きいところの満足度に繋がっていないのではないか」などの議論をスタートすることが出来ます。
また、SoE側をSFAに置き換えてみると、営業案件の滞留日数や商談回数などが分析対象のメジャーになります。
「取引規模が大きいところの滞留日数が長いのはなぜ」などのイシューが出てきそうですね。

逆のパターンでもいいと思います。
たとえば商談回数でビニングして、取引規模や前年伸長率を見ることで、営業効率が見えるかもしれません。
その後に、営業担当者などのディメンションで切って見ると、さらに傾向が見えやすくなることも想像できます。

営業担当者などは冒頭の説明でいう「わかりやすいディメンション」に該当しますが、
わかりやすいディメンションが決して悪いというわけではなく、組み合わせていくことが重要です。

特徴量エンジニアリングにおけるビニング

機械学習と密接にかかわる特徴量エンジニアリングにおいてもビニングというのは利用されています。 連続値をビニングして新たにカテゴリ特徴量を生成する使い方で、目的は平滑化（ノイズの削除）と線形モデルにおける表現力向上が主です。

ここまで書いておいてなんですが、特徴量エンジニアリングについての掘り下げた説明は控えます。
（離脱者が多くなりそうなのと、そもそも私の経験的に掘り下げられないという事情もあります）

それでもここであえて言及したのには理由があります。
前回の記事の最後にも少しだけほのめかしましたが、可視化や分析についての方法論をつきつめて考えていくと、
どこかで機械学習周りの方法論にぶつかります。

あえて平易な表現を使いませんでしたが、数行前に書いた「連続値をビニングして新たにカテゴリ特徴量を生成する」という表現は、実際には「メジャーを分割・グループ化してディメンションを作る」とほぼ同じことを言っています。

データエンジニアリングの現在地としては、可視化や分析、機械学習など細分化されていて各プレーヤーの守備範囲も異なりますが、実際にはこれらは繋がっており地続きで不可分であるということは意識しておいた方がいいかなと感じます。
（統計学が礎なので繋がっているのは当たり前の話ではありますが）

ここまでの3回の中で、データ分析・可視化における基本的な考え方をお伝えして来ました。

• 前々回​は、データの可視化についてのポイント
  注視すべき状態か/数字の良し悪し/必要なアクション などがすぐわかるような可視化を目指そう
• 前回は、メジャー観点でのつまずきやすいポイント
  割り算を使って換算することで暗黙の前提条件を排除して比較できる状態にしよう
• そして今回は、ディメンション観点でのつまずきやすいポイント
  わかりやすいディメンションのみの分析は鋭さに欠けるため、ディメンションを作り出そう

内容は分析者にとってもエンジニアにとっても共通の理解が持てるような内容で書いてきたつもりです。

次回以降は少し趣を変えて、もう少しエンジニアリングによった話をしようかなと思っています。
といっても、いきなりSparkクラスタがどうとかDataFrameがどうとか技術的な話をするわけではありません。

データとは何か、品質とは何か。データエンジニアリングではこれまでとは少しだけ視点を変える必要が出てきます。
そんな話をお伝えできたらと思っています。

それではまた次回、よろしくお願いします。

TOPへ