下町柚子黄昏記 by @yuzutas0

したまち発・ゆずたそ作・試行錯誤の瓦礫の記録

データ集計業務の勘所について話しました@データマイニングMeetup

ウィルゲート様が主催する統計やらNight!!データマイニングMeet up #2でLTをしました。

スライド

『データ集計業務を半年で300案件捌いて見えてきた勘所』

企業内のデータ分析チームが陥りがちな課題とその解決策についてのケーススタディとなります。 PyCon JP 2017でベストトークアワード優秀賞を受賞した発表(構築編)の続き(運用編)をチラ見せです。

集計業務のインパク

f:id:yuzutas0:20180515111950p:plain

データ活用案件の目的は、業務フローの過程において「リターンを上げること」もしくは「コストを下げること」となります。 意思決定を支える「アナリティクス」(BI)と、判断や作業を自動化する「ソリューション」(AP/ML)に大別できます。

f:id:yuzutas0:20180515112215p:plain

組織のデータ活用は段階的に進化します。今回は2番目のフェーズについて深掘ります。

  1. データの品質を担保し、利用できるようにデータ基盤を構築するフェーズ
  2. データを抽出・集計して、根拠のある意思決定ができるようにするフェーズ
  3. 必要に応じて高度な解析処理や機械学習を活用し、業務フローや顧客体験をさらに磨き込むフェーズ

f:id:yuzutas0:20180515112646p:plain

集計業務といえど軽視することはできません。 データ基盤が整備されていない場合、1つのデータソースをもとにした局所最適な意思決定に陥りがちです。 複数のデータソースを繋げるだけでインパクトを生み出すこともあるのです。

データチームを苦しめる悪循環

f:id:yuzutas0:20180515113628p:plain

悪循環 打開策
1 データ抽出や集計の業務ばかりに工数を費やしてしまう 作業手順の型化・改善
(今回のテーマ)
2 ・攻めた施策を打ちにくい
・付加価値を創出できない
期待ROIの提示
3 ・周りから便利屋として見られてしまう
・自分で便利屋として売り込んでしまう
メッセージング
4 ・さらに抽出依頼が寄せられてしまう
・自分で抽出業務ばかりを取りに行ってしまう
データの民主化

これらは陥りがちな課題ではありますが(理想を言えば)分析担当なら突破してしかるべし、だと考えています。

  • データ分析の担当者は、データを分析し、その結果を関係者に納得してもらい、業務を改善することが期待されているはずです。
  • 自身の担当する業務についても同じように、分析し、改善し、周囲にメッセージできるように心掛ける存在であってほしいです。
  • むしろ自分の業務を改善できないような人間に対して、ビジネスやプロダクトを改善するためのデータ分析を依頼したいと思えるでしょうか。

なお、データの民主化についての取り組みは下記エントリーをご覧ください。

yuzutas0.hatenablog.com

そのダッシュボード、本当に必要ですか?

データ抽出・集計の業務を磨き込む時に、最初に挙がるのは「あらゆるデータをいい感じに見ることのできるすごいダッシュボードを作ろう」という意見です。 が、なかなか上手くいかないのが現実です。

f:id:yuzutas0:20180420000920p:plain

Netflixの分析チームも同じようなことを言っているそうです。

ダッシュボードは使われない

Tableau Conference 2016 at Austin [レポート]分析カルチャーを構築する(Netflix社) #data16 | Developers.IO

f:id:yuzutas0:20180515115429p:plain

現場でWEBディレクターが実際にやっていたことはもっと泥臭い集計作業でした。

  1. 自分なりに簡単なSQLを書く
  2. 日付の部分だけ手動で書き換えてSQLを叩きまくる
  3. 事務スタッフにも声を掛けて作業を手伝ってもらう
  4. データさえあれば後はExcelやSpreadsheetでどうにかできる

このケースにおいては、豪華なダッシュボードを作り込むよりも、SQLExcelを地道に使うほうが価値創出に寄与したのです。 抽象化すると「実際の業務に紐付けながら小さく試すこと」が大事だと言えるのではないでしょうか。

スタートアップ界隈に学ぶ “小さく試す” 文化

f:id:yuzutas0:20180515115900p:plain

金も時間も足りないスタートアップでは、MVP(実用最小限の製品)を最初に作ります。

  • Airbnbは自分たちのアパートの写真だけを載せたLPを公開してニーズを探った
  • Dropboxはプロダクトを開発するより先に紹介動画を作って反響を見た

データ分析においては、ちょっとしたSQLExcelがMVPに当たるでしょう。 あるいは、ホワイトボードに書いた分析モデルのコンセプトスケッチだけでも十分かもしれません。

f:id:yuzutas0:20180515120148p:plain

とはいえ小さく作るだけでは急成長・大幅改善は難しいので、アクセルを踏むべき場面も出てきます。そこで参考になるのがステージゲート方式です。 スタートアップでは、ベンチャーキャピタルによる投資判断を受けて、コンセプトを検証する段階ではいくら、量産体制ではいくら、といった形でフェーズごとに投資額を増やしていきます。 同様にデータ活用案件においてもフェーズごとに資源(工数・時間・予算など)を増資していくのが有効だと言えます。

f:id:yuzutas0:20180515120444p:plain

それぞれの案件を次のステージに進めるか否かの判断もスタートアップを参考にできます。 革新会計・リーンキャンバスといった独自の基準で進捗を計測する手法が該当するでしょう。

用語 観点
必要性 Customer / Problem Fit 本当に解決すべき課題か
効果性 Problem / Solution Fit その解決策は課題に対する打ち手になるか
効果量 Product / Market Fit 投下する資源(工数やコスト)に見合うリターンを得られるか

このように「スタートアップの経営手法をデータ集計業務に当てはめる」という改善方針が見えてきます。 考えてみると、バズワードやシーズ駆動で実需を見失うのは、まさにスタートアップのアンチパターンです。 データ活用案件でも同じことが生じがちだからこそ、スタートアップ的発想が有効なはずです。

多産多死を前提としたプラクティス

f:id:yuzutas0:20180515121224p:plain

データ抽出・集計業務を大雑把に標準化すると以下のような流れになります。

  1. 要求(目的・背景・制約事項)を整理する
  2. 得たいデータのモデルを定義する
  3. 実際にデータを活用するためのインターフェースを設計する

f:id:yuzutas0:20180515121945p:plain

この業務にスタートアップ思考を適用すると

  • アウトプットをMVP(実用最小限の製品)としてスコープ調整しながら
  • ステージゲート方式で徐々に充実させていく

という形になります。

f:id:yuzutas0:20180515122939p:plain

具体的なMVPと運用方法は以下のようになります。

  • モックアップ
    • Spreadsheetで概算値を仮置きしたり、ホワイトボードで出力シートのイメージをスケッチします
    • 「こういう値のデータがこういう風に出ました」でロールプレイして、アクションがどう変わるのか、どういうインパクトがあるのかを確認します
    • アクションが変わらなかったりインパクトがないならデータ抽出・集計するメリットはないので案件を落とします
  • CSV
    • BigQueryからCSVを出力してExcelやSpreadsheetで簡単な分析をしてもらいます
  • Data Studio
    • ダッシュボードを即席で作ることができます
    • まだ自由度は高くないですが、簡易モニタリングなら問題なく使えます

f:id:yuzutas0:20180515123528p:plain

ステージゲートにおける判断は以下のようになります。

  • Slack配信
    • 継続的にデータを使い始めたら毎朝SlackでCSVファイルやData StudioのURLを自動配信します
    • 用意してあるテンプレートに沿ってプログラミングしてmasterブランチにマージされると翌日から自動で配信されるように仕組みを整備しました
  • クリーニング
    • 不要になったBIツールやデータ配信処理は定期的にクリーニングします
    • そのタイミングで「本当に必要だったデータは何か」を振り返って次に活かします

最終的に生き残った案件だけを磨き込むことになります。 業務の実態とデータ集計処理が合わなくなり、改修の依頼を受けたタイミングが検知トリガーです。 対応方針は以下のいずれかです。

  • ホワイトボード設計からやり直す(新しいロジックを検討したり、新しいユースケースを整理したり)
  • 本格的なデータ施策としてRPA導入などを案件化する(どうしてもMVPでは不都合がある場合やデータ集計後の業務本体を改善する場合など)

f:id:yuzutas0:20180515123855p:plain

このように、案件のライフサイクルを繰り返していくことで、多産多死のスタートアップと同じように、小さくテストしながら段階的に要求・設計を磨き込みます。 組織としてデータを活用して価値を創造するための知識を習得していくことができるのです。

おまけ:データクレンジング

データ集計業務においてボトルネックになりがちですが、(少なくとも私の担当現場については)ある程度の捌き方が見えてきました。

  • 暫定対応(回避策・解決策)
    • 後工程・分析後のアクションを踏まえて会話するのが良さそうです
    • 具体的には「多少数値がズレているけど今回の目的なら許容範囲だ」
 「これを調査するのに1日使うくらいならxxの方が優先だ」といったROI軸で会話します
    • 前提として「仮に現時点で多少モニタリングがズレても後で直してくれるだろう」という関係者からの信頼
を得る必要があります
  • 恒久対応(原因・予防策)
    • ノイズデータもありますが、データ基盤整備後における数値ズレは、むしろ設計力不足に基づくことが多いです
    • ドメイン知識:数値ズレを元に詳しい人と話すと解決しやすいので、その人の脳内にある推定値を出すロジックを突き止めるのが分析要件定義の第一歩です
    • データ仕様:ノイズデータのパターンやプロダクトの状況は経験的に学習でき、明らかに慣れによって早くなります
    • 論理的思考・数理モデル:ロジックの改修前後で数値が一致しないことは数学的に証明できるのに、
気付かずに右往左往したケースがありました

まとめ

f:id:yuzutas0:20180515124601p:plain

  • 最初はSQLを書いてCSVを渡しまくります。その作業プロセス自体を型化→継続改善していきました。
  • 生き残った案件についてですが、その頃には業務やデータ仕様に詳しくなっているので、データクレンジングを含めてどうにかなるはずです。

以上、だいたいそんな感じです!

宣伝

ということで、抽象論ではなくデータ活用現場で実際に使える粒度のノウハウ・ツールをパッケージ化して公開していきたいという気持ちがあります。 そのパッケージがあれば日本の産業界はもっと上手くデータを活用し、国内経済を活性化していけるのではないか、と考えています。 一緒にやっていくチームメイトを絶賛募集中です。

  • データ分析による意思決定でプロダクト開発を支えたいアナリスト・データサイエンティスト
  • データ案件推進やデータ駆動文化の醸成を担いたいディレクター・プロデューサー
  • データ活用による業務改善(RPA)で利益創出を目指したいアプリケーションエンジニア・機械学習エンジニア・UXデザイナー
  • データ基盤の開発・運用におけるベストプラクティスを追求したいSREエンジニア

我こそはという方がいらっしゃいましたら、ぜひお気軽に@yuzutas0にお声掛けください。

他の発表

参照:統計やらNight!!データマイニングMeet up #2

最後に

運営の方々。発表者の方々。参加者の方々。 この度は貴重な機会をいただき、誠にありがとうございました。 ぜひまた機会があればよろしくお願い致します。

最強のデータ分析組織 なぜ大阪ガスは成功したのか

最強のデータ分析組織 なぜ大阪ガスは成功したのか