データ分析の失敗事例その1

データアナリストをしているとデータ分析によって業務効率を格段に跳ね上げたとか、新たなサービスの開発や改良につなげた、KPIの改善に大きく貢献した、などなど素晴らしい実績や事例に遭遇することも少なくありません。


しかし、誰もがそのような華やかな経験ばかりしているわけではありません。


今日はその陰にある失敗事例を私の経験を参考にいくつか紹介してみたいと思います。


データの集計ミス


おそらくデータアナリストであれば誰しも経験があるのではないでしょうか。


ミスしたデータが何に使われているのかによって影響が異なります。単なる参考値やおおまかな傾向を見るためのものであれば、ミスしていても大した影響にならずに許してもらえる可能性はあります。


しかし、上層部もしくは社外への報告書に使われている数字であったり、それなりの金額の予算に影響が出るような意思決定材料であったりすると、滅茶苦茶怒られます。担当者だけでなく、上長も巻き添えです。怒られる相手もクライアントだけでなく、色んな関係者複数に怒られるかもしれません。


データアナリストも人間なのでどんなに優秀な人であっても絶対にミスをしないということはないのですが、いざミスが出てしまったときはそれは関係ありません。厳しく怒られた後は、再度ミスのないデータを集計しなおすのは当然として、なぜミスをしてしまったのか、再現しないためにはどうすれば良いかといったことも合わせて報告が求められます。


なお、データや分析結果を報告した後で自分で何らかのミスに気づいていても、他の人に気づかれていないのであれば責任をとりたくないから黙っておこうというのは宜しくありません。


ミスを起こしたらきちんと自らの非を認め、謝罪できるかどうかは重要な資質なのかもしれません。


とはいえ、ミスがあっても安易に何でもかんでもとにかくすみませんというのではなく、それは本当に自分のデータ集計のミスなのかどうかしっかり問題の切り分けを行う姿勢も重要です。実はソースであるデータそのものが間違っていた、依頼された定義や仕様が誤っていたという可能性もあったりします。


またそれなりの年長者になると、データ集計を自分でやらずに若手や業務委託の方に丸投げする人なども出てきます。分析設計やクライアント折衝、レポーティング等の方が得意でそちらに注力した方が適材適所であるという理由である場合ももちろんありますが、実は自分でデータ集計をきちんとやることに自信がなくミスを出してしまうことを恐れているだけという場合もあります。まあ、ミスが発生したときに責任をとらなくても良いわけではありませんが、直接的に自分のせいではないとなると幾分プレッシャーも治まるのでしょうかね。


後者のタイプの人かどうかは、実際にミスが発生した場合のふるまいでわかります。そうした人は大体ミスをした担当者に直接謝罪等をさせ、本人は知らんぷりあるいは後ろで頭を下げてるだけでやり過ごそうとします。なるべく直接的なミスの原因に関わろうとしない傾向が見られます。


別にそれはそれで何も問題ないなら良いのかもしれません。しかし、データ集計の担当者からするとあまり面白くないでしょうし、ミスしたことによる自責やプレッシャーで委縮してしまったり、以降の仕事にも影響が出る可能性もあります。ほっておくと、ミスを隠蔽するようになってしまったり、ひどいケースは退職・転職ということもありえないとは言えません。ミスした後すぐにしかるべきフォローが必要です。


一方で、部下やメンバーのミスが出てしまったときに率先して関係者との間に立ち、謝罪や折衝等を一手に引き受けるマネージャーもいます。通常はこちらの人材の方が関係者やメンバーから好感を持たれやすいでしょう。実際にそうした人は存在しますが、おそらく希少です。普段から口でそういってるだけのマネージャは多いと思いますが。ただ、それは性格の差なのでしょうがないとすると、多くのシニアやマネージャは失格の烙印を押されてしまうことになってしまいます。


データ集計をアウトソースするなど分業体制にすると自分事であるという意識が薄れてしまう傾向もあると思うので、いかに自分事であることを意識できるようにするか、責任感を薄めず醸成させるにはどうすれば良いかなども考えなければならないのかもしれません。業務効率も大事なので簡単ではないかもしれませんが、そうしたことも必要なことのように思います。



ひとつのネタで結構長くなってしまったので、他のネタはまた次回以降に紹介しようと思います。本日はここまでということで。

データアナリストのスキルセット

データサイエンティストに必要なスキルセット


データサイエンティストに関してのスキルセットは、データサイエンティスト協会が参考となるものを策定しています。

一般社団法人 データサイエンティスト協会


先日、プレスリリースにて最新のスキルチェックリストが公開されました。


データサイエンス力、データエンジニアリング力、ビジネス力の3領域で500以上!ものチェックリストが用意されています。


今やデータサイエンティストといっても様々な業界、業種の領域にて多様な活躍をされている人たちが多いので、必要なスキルセットの共通のガイドラインをつくろうとしても、どうしても抽象的な表現が多くなってしまったり、あるいは関係しそうなものはとりあえず盛り込まざるを得なくなり冗長的になっている風に感じました。このチェックリストの策定にかかわった方々の苦労がしのばれます。


これを利用する側からしても、500以上もあるので読むだけでも大変です。


またデータサイエンス力のところなど具体的な手法等の理解を問うものはスキルの可否も判別しやすいのですが、抽象的な表現や基準が明確でない項目も多くそれらは可否の判断に悩まされます。


例えば以下のチェック項目とか。


「ビジネスにおける論理とデータの重要性を認識し、分析的でデータドリブンな考え方に基づき行動できる」


なんとなくできているだろうという人が多いと思いますが、根拠を示せと言われるとちょっと考えてしまいます。


もうひとつ棟梁レベルの例です。


「プロフェッショナルとして、作業量ではなく、生み出す価値視点で常に判断、行動でき、依頼元にとって真に価値あるアウトプットを生み出すことをコミットできる」


これも重要な項目ではありますが、できるかどうかはなかなか客観的に示しづらいですね。またこれは棟梁レベルなので、みんながみんなできていると主張してしまうと達成が簡単な項目に見えてしまうので、そういう意味でもやはり判断に悩まされます。


このリストをうまく活用されている企業やチーム等あれば、ぜひ事例を知りたいです。


マーケティング領域のデータアナリストに必要なスキルセット


通常は業務内容や求められる役割等によって必要なスキルセットも異なってくるので、なるべくなら業務別に分かれているのが良いかと思います。


ということで、とりあえず私の経験業務の範囲からざっくりしたデータアナリストのスキル要件(マーケティング領域)をまとめてみました。


f:id:custle:20191104102514j:plain


基本的に中身は柔軟に変えやすいように、スキル要件のところはまずはガイドラインのみとしています。


中身の例としては以下のような感じになったりするでしょうか。必要とされる具体的な業務知識や統計知識なども盛り込んでも良いと思います。なお、LV3は本来のデータアナリストとしての業務を少々逸脱してる感も否めないのですが、データアナリストのスキルをさらに活かして、より大きなビジネスインパクトをもたらす方向として設定してみました。


f:id:custle:20191104102530j:plain


なお、こちらは私が実際に使用しているものではありませんのでご注意下さい。(似たものは一部資料等に使ったりしてますが)


実際に利用する場合には、きちんと人事評価等とも連動させないとあまり意味のないものになりますが、私自身人事評価制度を変更したり働きかけたりできる権限や立場にいるわけではないのと、評価はデータアナリストとしてのスキルセットが全てではないので、そのままでは難しいのでしょうね。


ということで、以上のスキルセットはあくまで私の単なる妄想に近いものですが、分析チームがあるところでは何らかのガイドラインフレームワーク的なものは作られているのではないでしょうか。


そうしたものがどんどん共有され、データ分析の仕事が世の中により理解されやすくなった世界もついでに妄想しときましょう。

データがないときの分析方法

ビジネスにおいてどういったマーケットの顧客を狙うかは重要です。


自社の商品やサービスに関心を持ってくれる層がなるべく多く含まれるマーケットに絞って、マーケティング活動を行うほうが効率的です。


しかし、どのチャネルを使えばそうしたマーケットにリーチできるかどうかどうか、あらかじめ判別することはなかなか困難だったりします。


というのも未知の顧客のデータはまだ取得できていないので、彼らの趣味嗜好や自社サービスとの相性などはわからないのが通常だからです。


ではどのようにすれば良いのでしょうか。


以下では一事例としてヤフーの取り組みが紹介されています。


tech.nikkeibp.co.jp


Yahooショッピングにおいて新規客や来店頻度の低い客は購入履歴等のデータがそろっておらず、何をレコメンドすればよいか困っていたが、Yahoo検索のデータを掛け合わせて好みの商品を類推してレコメンドを行うことでクリック率が向上したという内容です。


あるサービスにおいては新規顧客(=未知の顧客)であっても、自社の他のサービスで既存客であれば、そのサービスのログデータを使って分析することが可能になります。


Yahooのように自前で検索エンジンとその履歴データを持っていなくても、特定の検索ワードで検索を行ったユーザに対して広告を表示させることのできる外部のDSPサービスなどは今では一般的に利用されているところも多いと思います。


また大きなメディア基盤を持つ企業などにおいて、彼らの顧客を履歴データ等からあらかじめセグメント化し、そのメディアに広告を出したい企業に対して、特定のセグメントでフィルタリングして広告を出稿できるサービスを提供しているところなども増えてきています。


任意のセグメントにリーチできるサービスを持つ外部のメディア企業とうまく連携するのもひとつの有効な方法でしょう。


ただ、そうした顧客を自社に呼び込むことができても、最終的に商品やサービスの購入に至らない場合も多くあります。


もちろん無作為に呼び込んだ顧客よりはコンバージョン率は高いかもしれませんが、どこかで離脱してしまう可能性もゼロではありません。


ECサイト等では、サイトに訪問したけど購入に至らなかった顧客であればそれまでの行動履歴のログデータが取得できていることが多いので、そのデータを活用して分析しているところも多いでしょう。


サイトのどこで離脱されやすいのか、サイトの導線に何か問題がなかったか、クリエイティブやキャッチコピーを変えればクリックを促すことができたのかなど、必要に応じて新たにA/Bテストを行うなどして検証することも多いと思います。


一方オフラインのビジネスを行っているところでは、購入に至っていない顧客のデータは通常取得できていないので、オンラインビジネスの企業よりもデータ取得に困っているところもあるかもしれません。


ただ彼らも同じく、一部のリアル店舗等で小規模の客を対象に実験を行うなど、テストマーケティングを実施して新商品やサービスの全店展開の予測を立てることもよく行われています。


データがなければ小規模顧客でABテストやテストマーケティングを行ってサンプルデータを取得し、分析するというのもよく行われる方法ですね。


基本的にはデータがなければあきらめるではなく、いかにデータを入手できるかを考えると道が拓けることがあると思います。


データアナリストとして、与えられたデータで分析するだけでなく、このようなデータがあれば新たに分析を進められるとならば、どうやってそのデータを取得できるかまで考えてそのための行動もできるようになると、より重宝されることでしょう。


また購入に至った顧客においても、いつどこでどの商品を購買したかというPOSデータだけでなく、プラスアルファのデータを取得できないか考えてみるのもおすすめです。


どんな検索ワードで流入した顧客なのか、比較検討したが購入しなかった商品は何か(カートから落とした商品、詳細表示した商品)、なぜその商品を購入したのか(アンケート)、どのようなタイプの商品を購入しやすいのか(高品質高価格/低品質低価格、パッケージ/単品、etc)などのデータがあると、さらに他の商品やサービスをレコメンドしたときの確度を上げることなども可能になってくるかもしれません。


あとついでに、データが不十分で購入客の特徴がなかなかつかみにくいとか、どのような商品・サービスを進めれば良いのか明らかにしにくい場合、逆の発想をしてみるのも効果的かもしれません。


データが不十分でも明らかに購入しない顧客あるいは購入されない商品ならば分析できるのであれば、それらをターゲットやレコメンドから外すというのもひとつのやり方です。


確度をあげるための絞り込みは、条件を追加するだけでなく、もし母数が一定であれば外れを削るというのも有効です。

データアナリストが転職する理由

データ分析人材の不足が叫ばれる昨今、多くの企業では採用や育成で苦労されています。


そんな中、せっかく採用できた人材、あるいは育成してきた人材が転職などで退職してしまうと非常に痛手を感じることでしょう。


私自身かれこれ10年ほどデータ分析のお仕事をしており、これまで転職していく同僚たちを多少なりとも見てきました。


まあ自分も転職経験はあるので、自分自身の場合も一応ふまえてですが、なぜデータ分析人材が転職してしまうのかということについて考えてみました。


キャリアアップできない


一番多い理由がこれでしょう。


若い人であればスキルアップできる機会や仕事があまりない、ある程度スキルや経験のある人であればさらに実績を重ねたいのにスキルを活かして活躍できそうな機会や仕事が少ない、といったことで転職を考える人も多いようです。


これは一番解消しづらい問題ではないかと思います。


というのも彼ら・彼女らの充足を満たそうとするには、いわゆるヒト・モノ・カネといった環境(※)をしっかり揃えなければなりませんし、仕事面では単に儲かる仕事というだけではなく、データや分析技術が活かせる仕事、難解でチャレンジングな仕事、新規性や先進性のある仕事など、彼ら・彼女らがやりがいを感じる仕事を継続的に与えつづけることができないとなりません。

※ヒト・モノ・カネの例
優秀なリーダーやマネージャー、同僚、クレンジングされた多種多量のデータ、分析システム、待遇、納得のいく評価制度、研修・研究費など


自社以外にこれらの点で優良に見える企業があれば、そちらに移りたいと考えてしまうことは仕方ないことでしょう。


働きやすい環境ではない


エンジニアの求人などではよくありますが、PCや椅子を選べる、外部の有償セミナーを受講できる、書籍の購入ができる、もしくはそれらの補助が出るなどをアピールしている企業があります。あと、飲み物やスナックなどの軽食がタダとかもありますね。昔はおやつにバナナが出るなんてところもありました。。。


もちろんこうした環境に魅力を感じる人も多いと思いますし、迷っている人ならば後押しになるかもしれませんが、こうした点は転職の本質的な理由にはならないのではないかと思います。


なぜなら大体は自費でも実現できることだからです。無償ならそれにこしたことはありませんが、十分な条件にはならないと思われます。


ただし、古い社内システムや過剰なセキュリティ制約などのために情報共有・ドキュメント探索・業務手続きなどが著しく非効率であると、転職を考えてしまうきっかけとなるのは十分あり得ます。


そうした環境を変えたいと思っても、影響範囲も広く相当な費用もかかるのでどうにもならない可能性が高い、ならば転職したほうが早いし、それによって仕事の効率も上がれば活躍しやすくなるなど考える人がいても不思議ではありません。


人間関係でストレスがたまる


私は幸いにもこれまで人間関係を理由に転職を考えるほど厳しい環境には置かれてこなかったのですが、多くの関わってきたひとたちの中には、大人としておかしい言動・行動をとる人や生理的に合わない人たち、理不尽な指示を出してくる上長などもそれなりにはいました。


しかし、自分自身少々我が強い性格なせいか、言うべきことは言う、断るべきことは断るなど自分の意に沿わないことはなるべく避けることを意思表示してきたので、その時その時で衝突等によるストレスを感じることはあっても決してため込んでいくことはなかったので、そうした人たちともなんとか仕事上だけの関係と割り切って付き合ってこれたのかもしれません。(もっとも、後々それで低い評価をされるとか意趣返しや割を食うことなどは度々ありましたが)


ただ、ストレスをため込んでしまいやすい人であれば、いずれ限界を感じて転職等の選択を選んでしまうこともありえるでしょう。


最近、心理的安全性」という言葉が流行りだしているのもそうしたひとたちの転職を防ぐひとつの解なのかもしれません。


自分の所属する企業あるいは事業部の先行きが不安


ベンチャーなら経営陣の判断ひとつで会社の行く末が大きく左右されます。特に会社立ち上げの初期と比べて、経営方針や経営陣の発言・行動、新たに入社してくる幹部の人選などに大きな変化が表れてくると、違和感を感じるようになる人も増えてきて危険信号です。


大企業においても通常は他に様々なコア事業があるので、データ分析系の事業としての見通しや貢献度次第では撤退・解散・売却等の可能性は十分考えられます。データ分析関連の業界の市況が良くとも、自社でうまくデータ活用が進んでいないとか競合のサービスになかなか勝てないとならば、不安になって脱出を考える人が出てもおかしくありません。


データ分析人材が転職しないようにするには


これまでに挙げた要因など、彼らが転職しようと思う理由を少しずつでも解消していくのが基本と思われます。


しかし、なかなか一挙手一投足でできることばかりでもないので、ある程度転職者が出ても仕方がないと度割り切ることも必要なのではないかと思います。


またもし彼ら・彼女らが転職等によって会社を去っても残った人材で業務がきちんと回るように、業務の標準化や仕組化を進めることも対策になり得るでしょう。


あとひょっとすると今後データ分析人材に限らず何らかのスペシャリストは一般企業に所属せずに個人事業主やエージェント会社に所属という形で、得意とする仕事やプロジェクトごとに業務委託契約を結んで渡り歩いていくという働き方が多数派になっていくかもしれません。


これまではそうしたフリーランス的な働き方は、継続的に仕事を得られないかもしれないとか、一度選択すると再び正社員として働くのは難しくなるのではないかなどのリスクを避ける考えで選択肢から外している人も多かったと思いますが、副業の広がりなどによってそうした働き方にもトライできる機会が得やすくなったり、案件量やマッチングサービス等が増えて仕事の獲得がしやすくなってくると、時勢が変わってくる可能性もあるでしょう。


そうなると、データ分析人材を如何に採用・育成・定着させられるかといった考え方から、いかに彼ら・彼女らを活用して最大限の成果を上げられるかを考えなければならなくなるのではないでしょうか。それはある意味より本質的な方向性なのかもしれません。

データ分析とPDCA

PDCAにおける典型的な課題


PDCAは、Plan、Do、Check、Actionの頭文字をつなげたものですが、これらをひとつのサイクルとして繰り返し回していくことで、改善を進めていくものです。


前回の「KPI」に負けず劣らず、「PDCA」もビジネスの世界では非常に使用されることが多い言葉です。


そしてKPIと同様に、PDCAもうまく使いこなせている人は多くないという言葉の代表格ではないかと思います。


PDCAの典型的な課題としては、CheckまではできてもActionが実施できないというケースではないでしょうか。


時間、予算、工数、技術等が足りないといった物理的な制約のために、改善策が実施できずに終わるというのはよく聞きます。


PDCAのサイクルが長期的なスパンで捉えられているならば、物理的な制約もいずれ解消できる可能性はあるかもしれませんが、大体のPDCAは非常に短期的あるいは単発の企画や施策レベルが多いので、最初からリソースに制約があってActionも制限されている前提でスタートしてしまうことが多いようです。


特に単発の施策であればそもそも途中で軌道修正などできないということは普通かと思います。もし改善策が検討されてもそれを実施するのは次回の施策で、ということになるでしょう。


とはいえ、その時の改善策が次回の施策のPlanにきちんと引き継がれて反映されるならまだしも、時間の経過による忘れや担当者の変更などで、改善策が忘れ去られてPDCAサイクルも断絶してしまう、あるいは新たに別のPDCAサイクルとしてスタートしてしまうというケースも非常によく聞く話です。


C⇒A⇒Pの途中で断絶が起こってしまう理由


PDCAサイクルが回らず改善が進まないと、課題が解決されないまま再び同じ課題に直面してしまうということが繰り返される恐れがあります。


担当者の力量などが問題の可能性もありますが、結構頻繁に起こりうるとすると、ひょっとすると構造的な欠陥がある可能性もあります。


よくあるのは、事業の目標をどのように達成するかはその担当者任せになっているケースです。


担当者の評価も、PDCAサイクルができているかどうかではなく事業の目標達成とリンクされます。


よって担当者にとっては、PDCAによって何かを改善したとか、目標が達成できなかった時に何が原因だったのかを明らかにして次回に活かすといった点は基本的に評価対象ではないため、それを行うモチベーションも基本的に発生しません。


また次期にその事業を引き続き担当するとも限らないので、基本1回1回で完結するものという意識が強いでしょう。そのためもし担当者変更が発生しても、引継ぎも最低限の情報の伝達のみでPDCAが継続されないことが通常かと思われます。


PDCAサイクルが途中で断絶しないようにするには


事業自体の目標達成の管理を担当者任せにせず、関係者を巻き込んだ形でなるべくオープンに進めていくならば、PDCAサイクルのような進め方はひとつのやり方としてアリでしょう。


その際、Planの内容、Doの結果、Checkの項目、Actionの改善をきちんとログとして共有化および管理できるようにするのが第一歩と思われます。


できれば業務プロセスの中にPDCAの要素も定型管理項目として埋め込まれていると、自然とログが蓄積されるようになるのでおすすめです。


そして、なるべく担当者の属人性や変更等によってPDCAの品質が落ちないように、一方でより改善を進めるために担当者の貢献も評価できるようにするバランスがとれると仕組みとして理想的と思われます。


さらにデータアナリスト視点でいうと、Actionの時にきちんと定量的な分析も行い、改善案が根拠のあるものになっているかどうかは非常に気になるところなので、そのフェーズではデータアナリストも関わるようになっているとより効果的でしょう。


データ分析もPDCAプロセスが機能しないと効果を出せない


データ分析も基本的にはPDCAプロセスにのっとって実施されることはよくあります。


例1.仮説立案と分析設計(P) ⇒ データ収集と集計(D) ⇒ 結果の解釈(C) ⇒ 示唆・提言(A)


例2.KPI設計(P) ⇒ モニタリング(D) ⇒ 異常値検出&要因調査(C) ⇒ 改善実施(A)


しかし機能しないPDCAと同じように、Checkまでしか行わわれずそこからの改善案や提言などが実施されないと折角のデータ分析も活かされずに終わります。


データ分析を活かせるようにするには、PDCAの課題とその対応と同じように、そのためのプロセス化や形式知として管理するためのログ化なども必要かもしれませんね。

KPI設計の基本

KPI設計は難しい


KPIを設定している企業や組織はたくさんありますよね。


うまく運用できているところもあれば、そうでないところもあると思いますが、大体最初にどのような指標をKPIとするかの設計業務はみなさん苦労されていると聞きます。


KPIをテーマにした研修やビジネス書などもあちこちで見かけます。それだけ奥が深く難しい業務なのではないかと思います。


昔はこのKPIの設計とモニタリングは、経営企画や経営管理といった部署が行う業務でしたが、今はデータアナリストが関わるケースが増えていて、我々の主要な仕事のひとつになっています。


ということでデータアナリストならばこうした業務はほとんどの人が経験しているでしょうから、同じように苦労したことのある人も多いかと思います。


私も長年データアナリストをやってるので経験だけは積んでますが、毎度苦戦しており、効率的かつ効果的なやり方を未だに模索中といったところです。


KPI設計が難しい理由


KPI自体は指標として使われる定量的な数値なのでシンプルなものですが、その使用対象や範囲は非常に大規模になることがよくあります。


例えば、企業全体の売上の目標管理などですね。


この場合、そもそもまず企業の経営や売上の構造が明確な形で整理されていなければ、KPIをどの指標にすれば良いのか判断できませんし、無理に設定しても機能しません。


そのため、経営戦略から現場のアクションまでの縦の一貫性、間接業務や取引先など周辺や横の関わりといった複雑な構造をまず紐解く必要があります。


さらにそうした構造が最適なものであるかどうかは不明なので、ひょっとするとまず最初に構造改革(業務プロセスあるいはビジネスモデルの修正)を行う必要も出てくるかもしれません。


ステークホルダーや関連する人々も非常に多数になり、なかなか皆が全て納得できるものに仕上げるのも大変です。


また売上目標管理以外にも、組織や人材の評価管理であったり、製造業などでは生産計画の管理に使用されていたりすることもあり、使用される対象領域も非常に広いこともあって、これといった正解例もあってないようなものというのが実態かと思います。


KPIの立て方の基本その一


とはいえ、KPI設計は難しいから諦めよう、では進歩がないので、基本的な方法や注意点などをいくつか紹介してみたいと思います。


例えば売上の目標管理であれば、以下のような売上を分解した数式やそれに似たものはよく見かけると思います。


売上 = 顧客数 × 単価 × 来店回数


しかし、これは数学の問題ではないので答えがひとつとは限りませんし、きっちり素因数に分解できるわけでもありません。


因数分解のやり方は千差万別です。単一の商品かつ単一の顧客のビジネスであれば別ですが、通常はKPIとして最初に上記のような数式を立ててもうまくいきません。


扱う商品やサービスが複数あれば顧客層も異なりますので、ひとつのKPI(顧客数)で管理できるでしょうか。また顧客層が異なるということはその単価や来店回数もそれごとに変わるものです。


よって顧客層の分解の仕方をどうするかがカギになります。


究極的にはひとりひとり別々に見るといった形になるのでしょう。


売上 = 顧客Aの売上 + 顧客Bの売上 + 顧客Cの売上 。。。


しかし当然このようなKPIでは、顧客の数だけKPIも増えてしまうので到底管理できるものではありません。


ではどうするかというと、顧客を個々に管理するのではなく、セグメントという形でもう少し粒度を荒くして管理します。


よくあるのは購入する商品やサービス、もう少し大きな粒度では事業、といった顧客層別に分けるパターンでしょう。


商圏が限定的なものならばエリア別、BtoBビジネスを行っていて顧客が法人なら業界別に分けるといったケースもよく聞きます。


マーケティング業界では、F1層(女性20~34歳)、F2層(女性35~49歳)といった分け方も昔からよくされているので、こうした分類が使われているところもあるかもしれません。


ちなみに、そもそもKPIは相互に影響し合わないように、漏れや重複のないMECEの形に分けるのが基本なので、顧客層の分け方などもなるべくかぶりが出ないようにする必要があります。


その際、購入する商品別等に分けるよりも、「顧客はドリルを求めているのではなく、穴を求めているのだ」とのえらい人の格言にもあるように、顧客のニーズ別に分けるのが良いKPIが作れそうです。


KPI設計のジレンマ


しかしここで難しいのが、「顧客のニーズを明文化してMECEの形に区分して整理すること」と、「それらを数値として管理するためにデータで集計できるようにすること」です。


ニーズの方はまだなんとか洗い出せても、それをデータできちんと表現できるように定義を明確に決めることができるか、そしてその定義に沿ったデータが収集できるかどうかというと、非常に難しいというのがほとんどではないかと思います。


ECサイトなどでは顧客ニーズの単位でWebページを作ることができるので、そうしたWebページ別での売上を集計するなどやりようがあるかもしれませんが、リアルビジネスではニーズというものはログデータとして取得しづらいのでなかなか難しいでしょうね。


そうなるとどうするかというと、管理しやすいデータをもってKPIとしてしまうということになりがちです。


POSデータがあれば商品単位、商品カテゴリ単位、売場や店舗単位、顧客データがあれば、性年代単位、職業単位、購入額や頻度別といった単位での売上集計は可能なので、KPIもデータ起点で設定してしまおうというパターンです。


最終的には数値データとして入手可能でないとKPIとして管理できなくなるので、このようなデータ起点と顧客(ニーズ)起点の狭間でどこを落としどころとするかで、妥協点を探るというかジレンマを感じることもよくあります。


KPIの立て方の基本その二


KPIの分解を進めていくと、現場で管理可能なレベルに行き着きます。


このとき、現場の権限と裁量と管理体制によって、詳細なレベルのKPIを設定すべきかどうかが決まってきます。


言い換えると、例えば事業部単位での売上予算(=KPI)が設定されているとき、各事業部のマネージャおよびメンバーは自分たちが何を頑張ればその予算が達成できるのか、きちんと共通理解がされているかどうかです。


彼らがきちんと理解しているならば、KPI達成に向けたアクションプランは彼らに任せるというのも手です。


しかしそうでないならば、数字が下がったときにテコ入れをしようとしても、現場はどうして良いのか困ってしまいます。結局は、現場の担当者任せとなってしまい、数字の達成は運否天賦によるものになってしまいます。


その場合は、より現場の行動と売上予算に関連したKPI指標が必要になってきます。


例として、営業部などでは見込顧客の受注確度別の件数を管理しているところが多く、予算達成にはどれだけの顧客を集めるべきか、期末が近づくにつれ時間的な制約が迫る中でどの確度の顧客まで注力すべきかなどは適宜管理されています。


KPIの立て方の基本その三


設定したKPIは基本的には全ての数字をモニタリングしていく必要がありますが、どの数字がコントロール可能かどうかはきちんと切り分けておく必要があります。


例えば親会社等の下請けビジネスを行っている場合、そこからの売上数値が下がったとして、自社側の努力で果たして改善できるものでしょうか。


自社側の努力でなんとかなるものであれば別ですが、結局上流側の事情で売上が左右されるならば、いくら現場が頑張ってもKPIは改善しません。というか、そもそも現場は何を頑張れば良いのかさえわからないでしょう。


そうした切り分けができていないと、経営者側も現場へ追加リソースを投入したり、現場に発破をかけ続けるといった無駄なアクションを行ってしまう恐れもあります。


他にも、取引先が限定されていたり、代理店やパートナービジネスなどの形態で売上が他企業任せになっていたり、政治情勢・為替変動・気候や災害といったものの影響を受けやすいビジネスであったりすると、自社側の努力でなんともしがたい数値が売上に含まれているということはよくあります。


完全になんともできない部分と、一部は自社側でなんとかできる部分など境目があいまいなケースもあるので、きちんと切り分けて管理するのもなかなか難しく、できていないところも多いようです。


KPIの運用を開始する前に、まずはそうした点の整理も必要になるのではないかと思います。



とりあえず思いついたのは以上となります。また何かネタがあれば続きを書くかもしれませんが、本日はここまで。

データアナリストはカーナビのようなものである

f:id:custle:20190928105513j:plain
カメラ兄さんさんによる写真ACからの写真

第一節


企業を車だとすると、データアナリストはカーナビのようなものである。


マーケットの中で、今自分(企業)がどこにいるのかを教えてくれる。


目的地を設定すれば、そこへの適切な行き方を示してくれる。


しかし、カーナビを取り付けるだけで自動的に目的地には到達しない。


車を運転するのは、カーナビではなくドライバーである。


もしドライバーがカーナビのガイドを無視すればどうなるだろうか?


今の自分の場所がわからなくなり、どちらに進めば良いか道に迷ってしまうかもしれない。


本来のルートを外れて、大きく遠回りしてしまうかもしれない。


あるいは違う方向に進んでしまって、目的地にたどり着けなくなってしまうかもしれない。


第二節


企業を車だとすると、データアナリストはカーナビのようなものである。


マーケットの中で、今自分(企業)がどこにいるのかを教えてくれる。


目的地を設定すれば、そこへの適切な行き方を示してくれる。


しかし、カーナビだけで目的地や自分の居場所がわかるわけではない。


カーナビが機能するには地図情報が必要である。


もし、地図情報に不備があればどうなるだろうか?


地図情報がそもそもなかったら、場所や道が判別できなくなってしまう。


地図情報が古かったら、そこにない道やランドマークが見つかって混乱してしまうかもしれない。


地図情報が間違っていたら、目的地とは別の場所や道を選んでしまうかもしれない。


地図情報が外国語でしか表示できなかったら、ドライバーにルートを伝えられないかもしれない。


第三節


企業を車だとすると、データアナリストはカーナビのようなものである。


マーケットの中で、今自分(企業)がどこにいるのかを教えてくれる。


目的地を設定すれば、そこへの適切な行き方を示してくれる。


しかし、目的地を決めるのはカーナビではない。


もし、ドライバーがどこに行けばよいか迷っていたらどうなるだろうか?


カーナビでただなんとなく近隣情報を検索してばかりで、一向に出発できないかもしれない。


本来の目的地とは異なる適当なランドマークなどにとりあえず向かってしまうかもしれない。


目的地を目指すはずが、単なるドライブを続けるだけになってしまうかもしれない。


第四節


企業を車だとすると、データアナリストはカーナビのようなものである。


マーケットの中で、今自分(企業)がどこにいるのかを教えてくれる。


目的地を設定すれば、そこへの適切な行き方を示してくれる。


しかし、カーナビは超能力者ではない。


ドライバーからテレパシーで目的地を読み取って自動的に設定してはくれない。


目的地に一瞬で移動させてはくれない。


空を飛んで、道や障害物や信号や他の車を無視できるようにはしてくれない。


本来の車以上の性能を引き出してはくれない。


解説


データアナリストの例えについて、今回はちょっと毛色(経路)を変えてポエム風に書いてみました。


カーナビを本来の用途で正しく使いこなすということは、それほど難しいことではないかと思います。


しかし、データアナリストをどのように使えばよいのかはわかっていない、あるいは本来の機能以上のものまで求めてしまう企業や経営者は実際に多いのではないでしょうか。


データアナリストの役割は、カーナビとドライバーと地図データの関係に似た部分は多少なりともあると思うので、その役割を理解してもらう一助にもしなったら良いな、なんて考えてみました。