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

データ分析・可視化に関する記事の16回目です。

重要タスク推進リーダーに任命されている私は本部のテックの象徴的な役割も担っているかなと自負しています。
総括に近いですが、テクノロジーにシフトしていくのはどういうことかというのを自分なりに考えました。

なお、この記事中の「テクノロジー」は、エンジニアリングとの対比としてのテクノロジーを指しません。
狭義のテクノロジーと、エンジニアリングとを包含した広義のテクノロジーとして読んでもらえればと思います。

データ利活用は難しいですね。
Analyticsの成熟度はどのような段階を経て高まっていくか、ガートナーの定義をもとに見ていきます。

歴史ある定義ですので、目にしたことのある方も多いのではないでしょうか。

Gartner’s analytics ascendancy model

via What Is Data and Analytics: Everything You Need to Know | Gartner

簡単な解説を以下に書きます。(図の左下→右上が下表の上→下です)
下の表で上から下に向かって分析の成熟度が高まっていくというステップになります。

日本におけるダッシュボードの現状

私は職務上、TableauやPowerBI、その他BIツールで実装されたダッシュボードを非常に多く見る機会があります。
感覚ですが、約9割がDescriptive Analytics(記述的分析)の段階にあるというのが私の体感です。

すなわち、計数とかKPIを確認できるようになったが、確認できるようになっただけの段階だということです。
BIを使って可視化をしたことのある人は、自身の成果物を思い出してみてください。
おそらくDescriptive Analytics(記述的分析)の段階（=状況がわかるようになった）だと言えるのではないでしょうか。

誤解のないように補足をしますが、これは別に何かを批判しているわけではありません。
成熟度の話をしているので、成熟度の第一段階にいますという認識を共有する目的です。
むしろゼロではなく第一段階には来ているので、前に進んでいるとも言えます。

次にダッシュボードを実現するBIツールについて、未だに根深い誤解をお伝えします。

BI=ドリルダウンという誤解

多くの方と話しているとBIツールと言えばドリルダウンという認識は未だに根強いです。
ドリルダウンというのは集計の粒度を一段階下げて、詳細な内容を確認するための機能です。
もう10年以上前から言われていますね。

ドリルダウンというのはDescriptive Analytics(記述的分析)においては、索引として機能します。
つまり、どこを深く追うべきか、という当たりをつけるために利用するということですね。

ただし皆さんもご存知の通り、ドリルダウンはExcelのピボットテーブルでも実現できます。
さらに、実務上はドリルダウン機能は想像よりも使われないという事実もあります。

少なくとも1次元のドリルダウン（単一のディメンションでのドリルダウン）の実装にはもはやツールとしての優位性はないと言えます。
※逆に言うと「多次元のドリルダウンを疑似的に実装することでBIツールの優位性を説明することが出来る」のですが、これについては語ると長くなるので今回は割愛します。

では、ドリルダウンが陳腐化したのだとしたらいったい何を実現すべきなのでしょうか。
Descriptive Analyticsから一歩先に進むためには何が必要でしょうか。
これらについて考えてみたいと思います。

「全然データが活用できていないよ」という企業の方と話をするときに「KPI/KGIツリーはありますか？」と聞くと、「ありません」と答えが返ってくることがほとんどです。

ただ、これはちょっと意地悪な質問ですね。
「この数値が悪かったとき、次に何を見ますか？（何をしますか）」と聞くと、大抵何かしらの答えが返ってきます。<

KPI/KGIツリーというと少し高尚なものに聞こえてきますが、要はこの延長線上にあります。
Descriptive Analyticsから次の段階に進むためには、最低限「「この数値が悪かったとき、次に何を見ますか？（何をしますか）」に答えられる必要があります。

このときに、インプットKPIとアウトプットKPIの考え方が整理できていると良いです。
つまりはアンコントローラブルなKPIから、コントローラブルなKPIまでツリーを辿っていけるとなお良しといった感じです。

色々と書いていますが、そんなに難しいことではありません。
たとえば売上が良くなければ次はパイプラインを見る、そして活動量または活動品質を見る、ということを言っています。

用語の定義としては正しくないですが、「KPI/KGIをドリルダウンする」というイメージをしてみてください。

「この数値が悪かったとき、次に何を見ますか？（何をしますか）」に答えていくことで、このツリーが出来ていきます。
そして、これをそのままダッシュボードなどで可視化してあげることでDiagnostic analytics(診断的分析)が実現できるのです。
このツリーの第1層から第2層とドリルダウンするかのように直感的にたどっていけるようにダッシュボードをデザインしてあげると、利用者の満足度は一気に高まります。

仮にインプットKPIまで辿れるようになっていた場合、ダッシュボードを見て即行動に移すことも可能になりますね。

最後に補足ですが、従来のドリルダウン型のダッシュボードも必要です。
KPIドリルダウン型のダッシュボードは組織を固定して見るため、索引としての機能がありません。
索引機能としての従来のドリルダウン型ダッシュボードと併用するケースもそれなりにあります。
また、たとえば「有給未取得者数」など、モニタリング系のダッシュボードはドリルダウン型の方が適切です。

このシチュエーションではどちらが有効か、あるいはハイブリッドにするかなど都度考える必要性があります。

分析を次の段階に進めるための考え方は理解しました。いよいよ本題です。

KPIツリーをダッシュボードで実現しようとたときに、ぶつかる壁があります。
さきほど例に出したKPIツリーをもう一度思いだしてみてください。

第一階層の売上や利益というのは管理会計から取得することができます。
では、次の階層はどうでしょうか。たとえばパイプラインの状況、これを取得する場合の源泉データはSFAになります。

つまりKPIツリーをダッシュボード上で実現しようと思うと、ダッシュボードは多くのシステムへの接続が必要となります。
これには2つの問題があります。

• １．ダッシュボードから多くのシステムに直接接続するため、接続元先双方にリスクが生じる
• ２．ダッシュボードによって同じデータを取得したくても接続先が違うケースが生まれかねない

つまり、私たちに馴染みのある言葉で言い換えると、密結合であり、SSOTが実現できてない状態である、ということです。

この状態を解決するための仕組み、それが当社でいうDDP、いわゆるデータ分析基盤になります。
(初回の記事でも同じことを言っています)

→この状態を解決するための仕組み、それが弊社でいう「データドリブンプラットフォーム」（以下、DDP）、「データを集め、溜め、探し、活かす」ためのすべての機能を搭載した基盤になります。
(初回の記事でも同じことを言っています)

DDPがなぜ必要になるのですか？というお客様の問いに対しては、
「DDPがないと分析がDescriptive Analyticsで足踏みしてしまう」と説明できます。

もし当社にDDPがなかったら？

正確性は論点ではないので一例として見てください

普段お客様にご説明している内容について、今回記事に起こしてみました。
実際にデータエンジニアとして最前線で活躍するためには、技術面だけではなくこういった側面にも触れる必要があります。

デジタルスキル標準を見るとデータエンジニアにとって一定の実践力と専門性が必要なスキルに以下が含まれています。

• システムズエンジニアリング
• エンタープライズアーキクチャ

一例として、今回の記事に書いたようなことを提言・実践できるようなことが必要であると理解しています。

来期に向けてデータエンジニアリングの強化は当社全体の方向性ですね。
この記事も何かのきっかけになれば幸いです。

余談ですが、BIやダッシュボードについて最後に少しだけ、、、。

最近、BI to AI のような表現が各所でなされています。つまりBIはAIに置き換わっていくということですね。
語感を重視した表現であるとは理解しているものの、少し違和感を覚えています。

TOPへ