モノタロウデータ活用
データ活用概要
BtoBがメインのフルスタックEC企業
2010年ごろから基盤づくりスタートした
2016年に全社的基盤
ビッククエリに集めてデータ管理
サービスアカウント除いて900人/月 かなり幅広くヘヴィに活用している
局所最適なデータ活用が起きていた。
→見てる指標の定義が微妙に違ってしまいコミュニケーション齟齬
分析したいけどどのテーブル使ったらいいか不明とか
SQLがそもそも正しいのかわからないとか
取り組み
2020にLooker導入
データに詳しい利害関係者にヒアリングしてデータの定義
2021年DWH構築 データをほかの用途でも使えるように構築
導入の結果：徐々に使われるように 持ち帰ってデータ集計していたのが、その場で素早く商談できるようになった
（匠によるデータモデリングが有効と思われる）
DHW普及に伴い指標管理をしたいというニーズが出てきた
現状の課題
これまで中央集計型でやってきたが、最近これだけでは難しい。
要求が特定ドメインに依存してしまう。
管理はしたいけど、ドメイン独自で見てる指標を管理するところがないから中央で集めてる、
データの粒度感が指標によって異なる。
その指標がどういう意味があってとか、それを満たすためにシステム側にどんなデータ (←☆ここ質問したい：メトリクスを構成する分析系のデータって意味？or 業務データ？)が入ってればいいか？の理解が十分に必要で大変
回答：後者の意味合い
業務と分析で多少のギャップがある
上記の理由
中央集計が困難な理由 ドメインが広範囲にわたる
ドメインが異なると同じ用語でも意味が異なる ユビキタス
商品情報といっても、ドメインによって粒度も意味合いも変わる。
どう取り組むか
データメッシュ アナリティクスエンジニアリング
自律的にデータ活用 ←ティール組織との関連性がなにかあるのでは？
SQLを変更したことでオペレーションにどんな影響があるのか？
dbt導入でデータ品質も一定の担保ができるようになった。
パネルディスカッション
営業領域やSCM領域でデータ管理やろうとなったきっかけ
もらっているデータの中でどうにかするしかない状況だった。
分析するに伴う必要なデータが全然そろっていない状況である中で、
モデルをどうにかやるうよりも手でアナログに必要なデータを追加した方が費用対効果上がった。
クエリ見たところスプレっとシートに1000行以上のSQLによって、
営業が本来のバリュー発揮する、お客さんの意思決定支援以外に時間を割かれていた。
アナリティクスエンジニアリングはドメイン内でどんな働き方をしているのか
データ周りの煩雑さを入社当初はやっていた。
最近は人によってクエリがバラバラなので、とりまとめてKPI定義して整備など、SQLレビューなど。
長いSQLが無数にあったので、全社で指標を揃えることはできなくても、営業内のスコープで整備した。
中間テーブルなどを定義するなどの環境づくりをしてた。
連携の仕方は、本当に暗黙的にチートポ的連携をしている。
アナリティクスエンジニアは、イネイブリングとして各データプロダクトを管理するストリームアラインドを支援する印象。
・アナリティクスエンジニアリングとして参画して変化したこと
みんな自身で自立してデータ活用できるようになってきた。
使う方からこういった指標を今見たいから入れてもらえないか？などの質のいいデータ活用サイクルと対話が資産としてたまる環境を作ることができた。
KPI揃えるときに、週１mtgやってクエリ何にする？という対話を重ねられた。イネイブラーとしてファシリ的に問いかけていたようだ。
横に何かを共有する場が最初なかったが、強制的に横連携の文化を構築。
データを使って業務の改善BPRにもつながる。宿題：GQMストラクチャーとの関係性を落とし込む （☆質問したい！！業務効率化にデータ活用って具体的には？ 各業務プロセスの指標では？ アジャイルメトリクスにつながる？）
回答：どういう業務プロセスがあるか明らかにしないといかん リード数これくらいで～とか
めずらしめのビジネスモデルなので、なかなか既存のBPMツールがフィットしない。けどもフィットする部分も一定数以上あるはずだから、汎用的業務部分には適材適所BPMツールを導入検討されているとのこと。
・ドメイン内におけるデータ活用、管理面における課題
商談を何回こなせているのか？ とか売上という漠然としたものではなく、データ活用サイクルを設計することが課題点
SQLかけるけど複雑なのかけないとかスキルセットがバラバラ。そこにどんなツール使うとか、業務フローどう作るのかが課題点。
データ管理や活用のリテラシーが必要：データマネジメントピラミッドの知恵の部分？
・アナリティクスエンジニアリングのやりがいと感じる点
組織がフラットなのでボトムアップにできることに限界あるときには、トップダウンでもいろんな方法でできる。
基幹システムの刷新を今やっている中で、基幹システムとしてデータをどう持つべき？という考察は機会があまりないのでやりがい。
組織としてデータ活用したいという声が多い。
せっかくダッシュボード作ったのに参照されないみたいなことがある。
つくったものをデータ活用サイクルを設計していくことに携われるのが楽しいそう。
同じ用語でも言葉の定義が変わる部分は、データの境界場所。(メッシュの切り分け部分の目安)
(☆質問)データに対する制度が足をひっぱったことは？ またそこからどう復帰した？
③アナリティクスエンジニアリングとして取り組んでいきたいところ
大きく分けて３つの取り組みを行っている。
・使われないダッシュボード(ECRSのEで対応)
・似た指標が別々ロジックで管理されてる(DRY違反)
・バッチ障害対応に時間かかる(ボトルネックの特定)
最初はストリーマーとして入りつつ、解像度上がったらイネイブラーとして俯瞰して関わっていく。
プラットフォームとして支えることも。
GQMによる指標の企画 と 情報品質 データストーリーテリングかな？→DFDにつなぐ？
データに対する価値駆動モデリングと、脅威モデリング、GQMで、データの品質の考察をする感じかな？
バリューストリームマップ使って業務プロセス可視化するあたりが素晴らしいと感じた。
データストーリーテリングによるデータの価値記述が必要かもしれないと感じた。