こんにちは。Baseconnectのオコドンです。 BI (BussinessIntelligence)ユニットに所属しており、データエンジニアとデータアナリストの両方の業務を行なっております。
今回の記事では、データアナリスト業務の中で生まれた施策である「週刊データサイエンス」なるものについて紹介したいと思います。 この施策はちょうど1年前くらいに僕が「こんな施策やりたい」と開発マネージャーにお願いして、チームの業務としてやらせてもらったものとなります。
週刊データサイエンスって？
ざっくり説明すると弊社が提供している営業活動支援サービスMusubuから取得した様々なデータを、アナリスト発信の切り口で分析して、毎週記事化する取り組みです。
どんな記事を書くの？
「◯月にリリースした新機能Aの使われ方について分析してみた」
みたいなタイトルで、分析の結果、分かったfactをTableauでグラフを作成したり、文章を書くことで表現しております。
記事テーマの決め方は色々ありますが、
- 「たくさんの人に見てもらえるように社内でちょっと議論になっていることをテーマ化」
- 「使ってみたい統計手法が上手く使える事例だったからテーマ化」
- 「新機能がリリースされたからそれについてテーマ化」
などなどいろいろなパターンがありました。
記事の例
例を出した方がイメージしやすいと思うので2021/04/08刊行: メール機能が進化♪確かめるぜその真価♪の記事を紹介します。
この記事は弊社が提供しているMusubuサービスにテストメール配信機能や配信禁止リスト一覧機能が追加された直後に、速報的な形で出したものです。
- 新しくリリースされた機能が期待通り使われているのか
- リリースされた機能に相関がありそうな指標に影響が出ていないか
などを分析して記事にまとめました。
なぜ始めたの？
この施策は以下の４つの背景から始まっております。
データ活用意識の向上
プロダクトグロースへのデータ活用意識
プロダクトステータスをモニタリングするようなKPI作成や、自分たちの業務の最終結果であるプロダクトに対して、定量的なフィードバックを受け取る流れを作ろうとしていました。
意思決定の質の向上のためにはインプットの多角化が必要だと考えており、 仮説ベース、定性ファクトベース、定量ファクトベース、これらそれぞれのサービスステータスのインプット方法をプロダクトマネージメント層に保持してもらうためにも、定量的なサービスステータスのフィードバックを受け取る文化を作ろうと邁進しておりました。
またプロダクトグロースを担当するチーム以外にも「我々が売り出しているMusubuサービスが今どんなステータスなのか」をすぐに把握できるようにしたいと思っていました。
Rettyさんの新卒の方の記事に影響を受けて
Rettyさんの新卒アナリストの方が、毎日自身が分析したサービスステータスについてslackで一言語るという記事を見かけて、当時社内に対して定量視点での知見の共有ができていなかった僕の強い刺激になったのを覚えています。
当時のslack⬇︎
統計技術・機械学習の試し打ちをする場の不在
当時、毎週kaggle勉強会という勉強会をチーム内で開催しており、kaggleへの参加だけではなく、効果測定の統計手法の勉強会や、統計の赤本や緑本の輪読会などを行なっておりました。
ここで勉強した手法なども、前述したプロダクトグロースに活用できていなかったので、トレーニングを兼ねていた部分もあります。
社内におけるBIユニットが実現できることの広報
- どんなデータが現在使えるのか
- 統計を活用したらどんなことがわかるのか
などBI領域でできることを他メンバーが把握できていないと、結果として社内からの依頼が減り、データ活用意識が下がるという負の連鎖を産んでしまうので、記事のアウトプットを通して、社内メンバーが「BIに色々頼んでみよう」と思ってもらえることが目的の一つでした。
週刊データサイエンスやってよかったこと
- 社内にファンが出来ました
- 事業企画室や開発チームの中に記事を楽しみにしてくれるメンバーがチラホラと出てきました。
- より高度な仕事に繋がった
- BIができることを広報する効果は出せたと思っており、例としては「会社データのスコアリングを作成してほしい」などの高度な仕事に繋がったと思っています。
- 文章力・説明能力の向上
- 読者には社内全メンバーを想定していたため、分析対象となるサービス内の特定ドメインに対する知識なんかを、記事の中でざっくり説明する能力だったり、統計の知識がないメンバーに対して「つまりこういうことがわかりました」と要約する能力がチーム内で身に付きました。
週刊データサイエンスやってうまくいかなかったこと
- リソースが鬼のように取られる
- 「テーマを決める➡︎データ探索・データ可視化を行う➡︎記事として仕上げる」この一連の流れはものすごいリソースが消費されて、 1人日以上は覚悟しなければならないくらいのリソース感でした。
- 目指していたところまでの意思決定への影響は与えられなかった
- 「明確に意思決定へ影響を与える」ことまで意識していましたが、まだそこまではいけなかったなあと思ってます。
読んでもらうために工夫したこと
- 刊行当時はインパクトを出したかったため、毎日記事をパブリッシュしていました
- 刊行開始した12月は1日に2つの記事を毎日書く施策を実行しました。
- 通常業務と並行して記事を書いていたため、当時並走してくれたインターンの子と「あの時期は大変だったね」と今でも話します。
- 共有時に一言コメントを付与
- タイトルを興味を持ってもらえるような楽しい感じにする
- インデックスを作成してバックナンバーが追えるようにしました
書くために工夫したこと
依頼ベースではないレポーティング業務故にかなり書きづらいこともありました。
- そもそもテーマ何にしたらいいかわからない
- 決めたテーマを深掘りしても示唆が得られるかわからない
- 結論の出し方も自分次第
BIインターンメンバーがこの課題感を言語化及び指摘してくれて コンサルの資料作成術を参考にしたフローを自発的に組んでくれたこともあり、一定この課題感の解消をしてくれました。
参考にした記事はこちら⬇︎
外資系コンサルが用いる「資料作成」という技術 | 日経クロステック（xTECH）
要するとレビューのフローを、スケルトンレビュー、ドラフトレビュー、フィックスレビューに分割する手法で
- まずテーマだけ決める（〇〇機能についてなどのザックリしたレベル）
- テーマに関するデータ探索を一通りする（Tableauでその機能テーマ周辺の情報をザックリ探索）
- 探索結果とテーマをもとにどんな記事にしたいかをスケルトンレビューに出す
- スケルトンレビュー結果から方向が定まったら記事の大枠を書く => 結論の方向性などまで
- 大枠ができたらドラフトレビューに出す
- ドラフトレビューが通過したら、細かい表現などを修正してフィックスレビューに出す
- フィックスレビュー通過 => 記事として出稿
といった流れです。
週刊データサイエンスは現在どうなってるの？
当社のBIユニットは業務範囲として、ユーザー行動のログ化 - データエンジニアリング - データアナリティクスの全領域をカバーしております！ 現在社員が僕1人とインターン2名という構成になっているので、データ基盤のフルリプレイスなどの業務が並行すると、どうしても記事に回すリソースが少なくなってしまいます。
結果として週刊リリースが難しくなってしまいまして、夏頃から月間データサイエンスにリネームされて、現在は毎月リリースの形を取っています。
発信はいいゾ
「なぜ始めたか」の項にさまざまな理由を羅列しましたが、一年通してやってみた感想としては データの説明、結果の解釈、サービスドメイン知識、統計、などなどを文章化して伝える技術をチーム全体で向上させられたことが何よりの価値だと思います。
アナリストのトレーニング・武者修行に是非やってみてください！
