エムスリーUnit9でプロダクトマネージャーをしている北島です。 この記事はデータ基盤チーム & Unit9（エビデンス創出プロダクトチーム） ブログリレー6日目の記事です。
私が所属するUnit9では、データプロダクトの提供やデータの社内活用を行い、データを通じた価値創出をすることをミッションとしています。そのため、日々多くの分析依頼を受けています。
アドホックな分析依頼は、その場限りの対応になりがちではないでしょうか。急ぎの案件が多かったり、依頼ごとに要望される分析ロジックが違うことなどが理由として挙げられます。ただ、単発での対応を続けると、依頼の増加とともにに担当者が対応に追われてしまう、過去分析の要件が不明で再現に時間がかかる、といった課題が発生してしまいます。
私たちのチームも過去に同じ課題に直面しました 。そこで現在、「アドホック分析を資産に変え、それを土台として分析のセルフサービス化を推進する」取り組みを始めています。結果として分析者の生産性を底上げし、より本質的な価値創出に向き合えるようになっています。本記事ではこの取り組みについてご紹介します。
私たちが目指す「分析が資産になっている状態」
まず、私たちは「分析が資産になっている状態」を次のように定義しています 。
- 過去の分析要件を簡単に参照・検索でき、新規分析の工数を削減できている
- どのような依頼が多いか・少ないかを把握できている
過去に誰かが対応した分析の要件やクエリを簡単に検索できれば、類似の依頼への対応工数は大幅に削減できます。
さらに、依頼と要件を蓄積することで、「どのような依頼が多いか」を正確に把握できます 。頻繁にリクエストされる分析や定型的な集計については、優先的にデータ分析ツールに機能追加をしています 。 結果として、依頼者側で分析できることを増やしていき、依頼者側で分析が完結できるような「セルフサービス化」を目指しています 。
分析を資産化するための取り組み
私たちは、分析を資産化するために次の3点に取り組んでいます 。
- アドホック分析ログの一元管理
- 分析依頼の標準化
- 要件のドキュメント化
アドホック分析ログの一元管理
まず、分析対応の依頼者・要望・クエリ・結果のリンク・所要時間などを、分析者がスプレッドシートに書き込む形で一元管理しています 。 これにより、どのような要件の分析が多いのかやどのような要件の依頼は時間が多くかかっているのかを分析できます。
基本的には、このログをもとに分析ツール改善の優先度を策定するようにしています。 この取り組みで既に数百件単位のログを蓄積しており、これらのログ自体を分析し、活用を進めています。
分析依頼の標準化
分析品質の向上と優先度設計のため、依頼フォームを用いて、2点を明確にしてもらうよう標準化しました 。
ポイント(1)：なぜ分析したいのか（目的・背景・活用イメージ）を明らかにする
分析の要件策定や、目的に対して課題な内容となっていないかのチェックのため、目的・背景・活用イメージを聞いています。
（記入例）
背景: 先月から施策Aを開始した 。
目的: 施策がユーザーのログイン回数に効果的だったかを比較検証したい 。
活用イメージ: 効果の高かった施策の予算を増額するかの意思決定に使いたい。
ここまで書いてもらうことで、分析者は言われたとおりに集計するだけでなく、「過去の類似案件に要件を寄せても問題ないか」といった判断がしやすくなり、既存資産を活用しやすくなります 。
ポイント(2)：いつまでに必要か？（緊急度・期待納期）
優先度を設定するために、具体的な日時、理由、緊急度をセットで聞いています 。
（記入例）
納期: 11月20日(水) 15:00まで
理由: 11月21日(木)の顧客打ち合わせで使いたいため
緊急度: 高
これにより、「21日までならここまでの分析であれば可能です」といった、現実的なコミュニケーションがとりやすくなります 。
要件のドキュメント化
分析の品質担保のため、要件のドキュメント化は欠かせません 。 ただ、詳細すぎるドキュメントを残すのはコストがかかってしまいます。 そのため、私たちは「簡単な要件をクエリの中にコメントとして残す」という方法を採用しています 。
特に、集計ロジックだけでなく、その前段にある「分析用のセマンティックレイヤーの設計」を書き残すことを強く意識しています 。一見バラバラに見える要件でも、抽象化したセマンティックレイヤーの単位では共通のものを活用できることが多いためです 。
具体的には次の3点について要件を設定・記載し、分析の品質を担保しています 。
データの粒度: 1行がどの単位なのか（ユーザー単位か？ クリック単位か？）
フィルター条件: 分析対象のユーザー・レコードは何か
時系列の基準点: どの行動の時間を基準にするか（時系列解析やファネル分析の場合）
これらを残しておくことで、セマンティックレイヤーを使いまわすことが容易になります。 また、クエリと要件を同一ファイルでGit管理し、Claude Code等のAIツールに読み込ませることで検索や引用がしやすいような環境構築を進めています。
/ * 新規ユーザーのアクティビティ分析 ・1レコードの粒度：ユーザーでユニーク ・フィルター条件：直近3か月で新規に登録があったユーザー ・時系列：新規登録日を基準日として設定 */ with base as ( # 集計用のCTE SELECT user_id , min(login_date) from ...(以下略)
このようなイメージでコメントを残しています
まとめ
本記事では、私たちUnit9が取り組む「分析の資産化」のための3つの施策（ログ一元管理、依頼標準化、要件ドキュメント化）をご紹介しました 。
これらの取り組みは、単なる「業務効率化」だけが目的ではありません 。社内のアドホック分析から抽出した分析の切り口などを、顧客に提供しているプロダクトにも取り込むことを進めています。社内の分析が、直接プロダクトを磨きこむことにもつながっています。
We are Hiring!
アドホック分析をプロダクト価値に変えたいデータアナリスト・データサイエンティストの方、ぜひ一緒にデータプロダクトを開発しましょう。大規模で魅力的なデータを用意してお待ちしています！
また、データ活用やプロダクト開発に一緒に取り組んでくれるエンジニアを募集しています！ ご興味のある方は、ぜひ次のリンクからご応募ください。
