IPAのDX実践手引書などを読むと、企業におけるDXは「データの利活用」というテーマに集約されてきたように感じます。
エンジニア/非エンジニアに関わらず、急にデータ利活用の領域の業務にアサインされるという状況も増えているのではないでしょうか。
(私もクラウドアーキテクト/ソフトウェアエンジニアといったロールから急にデータ利活用の領域に入りました。)
今回はそういった方々が「見よう見まねで分析や可視化をはじめてみたけれども、なんかうまくいかない」といった状況に陥ったときに向けて、分析の初期段階において見落としがちなポイントについて紹介したいと思います。
ディメンションとメジャー
本題に入る前に、予備知識のインプットをしたいと思います。
データエンジニアリングの領域にはディメンションとメジャーという用語があります。
ディメンションとは定性情報であり、分析の切り口になります。
メジャーというのは定量情報で、分析における指標になります。
エンジニア向けには、SQLを記述するときにGroup By句に指定する項目がディメンションで、
SELECT句の中でSUM()などの集計関数(集約関数)で扱う項目がメジャーと言うとわかりやすいかもしれません。
アンケートに回答することを想像してください。
最初、もしくは最後に本来の質問内容とは別にフェイス項目を聞かれます。
フェイス項目とは年齢や性別、居住地であったり、会社名や役職であったりといったあなたの属性情報です。
このフェイス項目がディメンションにあたります。
そして、それらとは別に本来聞きたいことである質問が聞かれると思います。
たとえばある質問で満足度を5段階で聞いていたら、その回答がメジャーにあたります。
分析は「全体的にどうか」というのをぼんやり眺めるのではなく、ディメンションでメジャーを切り取っていきます。
アンケートの例でいうと、「全体は概ね満足しているのに、30代男性だけが低い」というような結果を導出する、これがディメンションでメジャーを切り取るということになります。
事業計数でいうと、組織などがディメンションとなり、売上などがメジャーになります。
本記事は2回に分けて、今回はメジャーに絞ってポイントを紹介したいと思います。
それでは、本題に入っていきます。
その分析に割り算は含まれるか
私たちは普段見慣れた数値を読み解くときに、暗黙的に割り算をして「換算」をしています。
予備知識がない状態で、ある１日の都道府県別の新型コロナウイルスの感染者数を見たと仮定します。
そうすると、常に東京都で流行しているように見えます。
みなさんがそう読み違えないのは、「東京都は人口が極めて多い」という知識を既にお持ちだからです。
大分県と山形県、どちらの人口が多いかを知識として持っている人はどのくらいいるでしょうか。
把握していない状態でそれぞれの1日の感染者数を見たとして、何かを推定することはできないですよね。
こういうときに都道府県別の人口という予備知識が無くても数値を読み解けるように、割り算を使い換算します。
「10万人当たりの感染者数」などですね。
事業計数を見るときも、これは自然にやっていることです。
収益の分析で利益率を無視して利益の絶対額だけで何かの判断をすることはないと思いますし、人件費についてであれば売上高人件費率とか労働分配率といった指標をまず見るでしょう。
私たちソフトウェア開発のぎょうかでは、人時生産性や一人当たり売上高という指標が伝統的に使われてきましたね。
実数だけではなく、割り算で換算したメジャーを使って分析をする。
このように例を挙げながら書くと当たり前の話をしています。
前回の記事でも書きましたが、当たり前と思われていることも言語化して共通認識を持つことが第一歩です。
この当たり前を、いざ見慣れない数値を前に分析をはじめようとしたときに忘れてしまうのです。
当たり前を忘れてしまう罠
たとえば、あなたが急に顧客分析をするように命じられたとしたら、まずその手法について検索するでしょう。
そうすると、デシル分析やRFM分析などを紹介しているページにたどり着きます。
中を見ると参考になりそうなので、これに忠実に分析を始めます。
試行錯誤をしながら「顧客ランクの高い人はトータルの買上金額が多い」という結果を得ることができました。
気が付いている方もいると思いますが、これでは分析になっていません。
一般的に買上金額が多い人を顧客ランクの高い人に位置付けるので、これは関係の矢印を反転させただけです。
一見笑い話ではありますが、分析の現場ではあるあるな話でもあると思います。
検索結果で得られたサイトは最初のステップを解説しているだけですから、これは誰も悪くありません。
最初のステップなので、単純なメジャーを分析対象として説明をします。でも、そこはスタート地点なのです。
次の一歩としては、いま分析している対象のメジャーを別のメジャーに差し替えてみることが挙げられます。
そのときに、割り算でできたメジャーも混ぜてみるのです。
これは例えば、顧客ランク別の買上金額を見ていたのであれば、それを客単価に変えてみようということです。
客単価ですから、顧客のトータルの買上金額を来店回数で割った指標です。
その結果、もし「顧客ランクの高い人とその他とで客単価に差がない」ということがわかれば、顧客ランクの高い人とその他の差は来店頻度の差ということになりますから（トータルの買上金額は顧客ランクの高い人の方が多いはずなので）、まとめ買いキャンペーンのようなマーケティング施策よりも来店回数に応じた特典のような施策の方が効果が出る可能性があるという仮説を立てることができます。
これは例としても単純すぎるかなとも思いますが、伝えたいことの雰囲気は感じて頂けたのではないかと思います。
前回の問いかけへのアンサー
前回の記事で、「身長と体重を載せたのに、BMIが載っていないのはなぜ」という問いかけを最後に残しました。
ここまで読んでいただいた方にはもうおわかりですね。
たとえば肥満に関する分析をしようと思ったときに体重という指標を使用すると、身長の影響を排除できません。
極端な例を出すと、男性の平均身長が184cmのオランダと171cmの日本とを体重で比較して何の意味があるの？というのは誰でも思うことですよね。
まず、割り算で作られたメジャーが入っているか、という視点を持つためにこのような投げかけをしました。
分析に触れる際のひとつのポイントとして覚えておいてもらえたらと思います。
ドメイン知識への応用
こういった基礎的な理解をすることで、ドメイン知識（あるいは業務知識）に対する理解も深めることができます。
たとえば、小売業にはPIという考え方があります。
PIとはPurchase Indicatorの略で、客数1000人あたりの売上個数です（割り算でできています）。
食品の発注をするときは、商品が届くまでの間に何個売れるかを考慮しますので、売上予測をします。
発注する品目は何百や何千という単位になりますので、すべての売上を予測するのは現実的ではないです。
ではどうするかというと、客数を予測します。
客数はお店単位なので、店長が天候やイベントなどを考慮して予測します。
あとは、その予測した客数に過去実績から算出したPIをかけてあげることで商品ごとの売上予測が出来ます。
たとえば時系列分析のメジャーとして売上個数の代わりにPIを利用することで、客数の影響を排除した純粋な商品の魅力の変遷という観点で分析ができるようになることが想像できます。
ドメインの知識は網羅的におさえるには限界があります。
ただし、知識として知っていなくても「必ず割り算をして何かを換算したり影響を排除したりしているはず」という理解をもつことで、何か適切な指標がないかと想像を巡らせることができるようになります。
前回、データに対する成熟度が途上にある場合に「数値感覚はあるものの、その感覚をロジカルに説明できない」ことが多いことに触れました。
この原因の一端にこの割り算の有無が関連している場合があります。
「経験を重ねた人は暗黙的に予備知識を持っており、それをもって数値を見ている」というケースです。
先述の大分県と山形県の例でいうと、両県の人口が頭に入っていれば単純な感染者数だけを見ても何かを洞察できるということです。
このケースでは、割り算を使うことを念頭に、除数（割る数）を何に設定すれば感覚と近くなるかというすり合わせをしていくアプローチになっていきます。
答えがでなくとも、近づける努力をしていくことである程度ロジカルに説明がつくようになってきます。
そして、このアプローチって、、、勘が良い方は何を言いたいか気づいたかもしれません。
機械学習の単純化したものをアナログでやっていること、に他ならないのです。
このまま続けるといつまでも書き続けそうなので、今回はこの辺で終わりにしたいと思います。
次回はメジャー編について書こうと思います。