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

developer_blog_vol.02_00.png

Vol.02
その分析に○○は含まれるか - メジャー編 -

可視化や分析に関しての発信の第2回目です。

前回の記事には目を通していただけたでしょうか。

ディメンションとメジャー

本題に入る前に、予備知識のインプットをしたいと思います。
データエンジニアリングの領域にはディメンションとメジャーという用語があります。

ディメンションとは定性情報であり、分析の切り口になります。
メジャーというのは定量情報で、分析における指標になります。

エンジニア向けには、SQLを記述するときにGroup By句に指定する項目がディメンションで、
SELECT句の中でSUM()などの集計関数(集約関数)で扱う項目がメジャーと言うとわかりやすいかもしれません。

developer_blog_vol.02_01.jpg

アンケートに回答することを想像してください。

最初、もしくは最後に本来の質問内容とは別にフェイス項目を聞かれます。
フェイス項目とは年齢や性別、居住地であったり、会社名や役職であったりといったあなたの属性情報です。

このフェイス項目がディメンションにあたります。

そして、それらとは別に本来聞きたいことである質問が聞かれると思います。
たとえばある質問で満足度を5段階で聞いていたら、その回答がメジャーにあたります。

分析は「全体的にどうか」というのをぼんやり眺めるのではなく、ディメンションでメジャーを切り取っていきます。

アンケートの例でいうと、「全体は概ね満足しているのに、30代男性だけが低い」というような結果を導出する、これがディメンションでメジャーを切り取るということになります。

事業計数でいうと、組織などがディメンションとなり、売上などがメジャーになります。

見落としがちなポイント

分析の初期段階において、メジャー/ディメンションそれぞれで見落としがちなポイントがあります。

当初はこの記事で両方について触れるつもりでいたのですが、いざ書き始めたら長文になってしまいました。
2回に分けて、今回はメジャーに絞ってポイントを紹介したいと思います。

それでは、本題に入っていきます。

その分析に割り算は含まれるか

私たちは普段見慣れた数値を読み解くときに、暗黙的に割り算をして「換算」をしています。

developer_blog_vol.02_02.jpg

予備知識がない状態で、ある1日の都道府県別の新型コロナウイルスの感染者数を見たと仮定します。
そうすると、東京都で流行しているように見えます。おそらくどの日を切り取ってもそう見えます。
みなさんがそう読み違えないのは、「東京都は人口が極めて多い」という知識を既にお持ちだからです。

大分県と山形県、どちらの人口が多いかを知識として持っている人はどのくらいいるでしょうか。
把握していない状態でそれぞれの1日の感染者数を見たとして、何かを推定することはできないですよね。

こういうときに都道府県別の人口という予備知識が無くても数値を読み解けるように、割り算を使い換算します。
「10万人当たりの感染者数」などですね。

事業計数を見るときも、これは自然にやっていることです。
収益の分析で利益率を無視して利益の絶対額だけで何かの判断をすることはないと思いますし、人件費についてであれば売上高人件費率とか労働分配率といった指標をまず見るでしょう。
私たちの業態では、人時生産性や一人当たり売上高という指標が伝統的に使われてきましたね。

実数だけではなく、割り算で換算したメジャーを使って分析をする。
このように例を挙げながら書くと当たり前の話をしています。

前回も繰り返し書きましたが、当たり前と思われていることも言語化して共通認識を持つことが第一歩です。
この当たり前を、いざ見慣れない数値を前に分析をはじめようとしたときに忘れてしまうのです。

当たり前を忘れてしまう罠

たとえば、あなたが急に顧客分析をするように命じられたとしたら、まずその手法について検索するでしょう。

developer_blog_vol.02_03.jpg

そうすると、デシル分析やRFM分析などを紹介しているページにたどり着きます。
中を見ると参考になりそうなので、これに忠実に分析を始めます。
試行錯誤をしながら「顧客ランクの高い人はトータルの買上金額が多い」という結果を得ることができました。

気が付いている方もいると思いますが、これでは分析になっていません。
一般的に買上金額が多い人を顧客ランクの高い人に位置付けるので、これは関係の矢印を反転させただけです。

一見笑い話ではありますが、分析の現場では本当にこういうことが起きてしまいます。

検索結果で得られたサイトは最初のステップを解説しているだけですから、これは誰も悪くありません。
最初のステップなので、単純なメジャーを分析対象として説明をします。でも、そこはスタート地点なのです。

次の一歩としては、いま分析している対象のメジャーを別のメジャーに差し替えてみることが挙げられます。
そのときに、割り算でできたメジャーも混ぜてみるのです。

これは例えば、顧客ランク別の買上金額を見ていたのであれば、それを客単価に変えてみようということです。
客単価ですから、顧客のトータルの買上金額を来店回数で割った指標です。

その結果、もし「顧客ランクの高い人とその他とで客単価に差がない」ということがわかれば、顧客ランクの高い人とその他の差は来店頻度の差ということになりますから(トータルの買上金額は顧客ランクの高い人の方が多いはずなので)、まとめ買いキャンペーンのようなマーケティング施策よりも来店回数に応じた特典のような施策の方が効果が出る可能性があるという仮説を立てることができます。

これは例としても単純すぎるかなとも思いますが、伝えたいことの雰囲気は感じて頂けたのではないかと思います。

前回の問いかけへのアンサー

前回の記事で、「身長と体重を載せたのに、BMIが載っていないのはなぜ」という問いかけを最後に残しました。
ここまで読んでいただいた方にはもうおわかりですね。

たとえば肥満に関する分析をしようと思ったときに体重という指標を使用すると、身長の影響を排除できません。
極端な例を出すと、男性の平均身長が184cmのオランダと171cmの日本とを体重で比較して何の意味があるの?というのは誰でも思うことですよね。

まず、割り算で作られたメジャーが入っているか、という視点を持つためにこのような投げかけをしました。
分析に触れる際のひとつのポイントとして覚えておいてもらえたらと思います。

ドメイン知識への応用

こういった基礎的な理解をすることで、ドメイン知識(あるいは業務知識)に対する理解も深めることができます。

たとえば、小売業にはPIという考え方があります。

developer_blog_vol.02_04.jpg

PIとはPurchase Indicatorの略で、客数1000人あたりの売上個数です(割り算でできています)。

食品の発注をするときは、商品が届くまでの間に何個売れるかを考慮しますので、売上予測をします。
発注する品目は何百や何千という単位になりますので、すべての売上を予測するのは現実的ではないです。

ではどうするかというと、客数を予測します。
客数はお店単位なので、店長が天候やイベントなどを考慮して予測します。
あとは、その予測した客数に過去実績から算出したPIをかけてあげることで商品ごとの売上予測が出来ます。

たとえば時系列分析のメジャーとして売上個数の代わりにPIを利用することで、客数の影響を排除した純粋な商品の魅力の変遷という観点で分析ができるようになることが想像できます。

また、運送業では、個当たりコストという考え方があります。

developer_blog_vol.02_05.jpg

そのままですが運送コスト/荷物量です(くどいですが、割り算でできています)。
運送業では輸送効率の向上のためにエリアを再編したり、仕分け拠点の再編成などを頻繁に行います。
そうすると「全体の荷物量があまり変わらなくても、エリアごとに見ると荷物量が前月と今月で大きく違う」みたいなことが起こります。
コスト分析の観点からはこの影響を排除する必要があるので、個当たりコストを使って分析を進めます。
※輸送効率は荷物の大きさにも左右されてしまいますから、容積あたりのコストという考え方もあります。

これらの各ドメインの知識は網羅的におさえるには限界があります。
ただし、知識として知っていなくても「必ず割り算をして何かを換算したり影響を排除したりしているはず」という理解をもつことで、何か適切な指標がないかと想像を巡らせることができるようになります。

前回、データに対する成熟度が途上にある場合に「数値感覚はあるものの、その感覚をロジカルに説明できない」ことが多いことに触れました。
この原因の一端にこの割り算の有無が関連している場合があります。

「経験を重ねた人は暗黙的に予備知識を持っており、それをもって数値を見ている」というケースです。
先述の大分県と山形県の例でいうと、両県の人口が頭に入っていれば単純な感染者数だけを見ても何かを洞察できるということです。

このケースでは、割り算を使うことを念頭に、除数(割る数)を何に設定すれば感覚と近くなるかというすり合わせをしていくアプローチになっていきます。
答えがでなくとも、近づける努力をしていくことである程度ロジカルに説明がつくようになってきます。

そして、このアプローチって、、、勘が良い方は何を言いたいか気づいたかもしれません。
機械学習の単純化したものをアナログでやっていること、に他ならないのです。

このまま続けるといつまでも書き続けそうなので、今回はこの辺で終わりにしたいと思います。
次回は先述の通りディメンションについてのポイントに触れます。待っていてくれる人が居たら幸いです。

執筆者プロフィール

高坂 亮多

  • ・2007年 新卒で当社に入社。
  • ・所属:DI本部DP統括部 DP開発1部 副部長 および DP開発1課 課長 兼務
  • (所属は掲載時のものです)
  • ・好きなこと:登山やキャンプなど アウトドアアクティビティ
  • ~ BI基盤(分析基盤)におけるアーキテクトとして日々業務にあたっています ~

Change Location

Are you visiting HULFT.com (Japanese language) outside Japan ?
When connecting "HULFT" to Japan from overseas, please select "HULFT8".

日本国外からHULFT.com(日本語)にアクセスされようとしています。
海外から日本の「HULFT」と接続する製品をお探しの場合、「HULFT8」をお選びください。