この記事は、2024年4月16日に開催された「DevOpsDays Tokyo 2024」にて発表した内容を元に再構成したものです。
- カテゴリ: データマネジメント, データ基盤
-
対象読者:
- データマネジメントに興味のある方
- これからデータ活用を始めたいと考えている方
- データを集めているが、うまく活かしきれていないと感じている方
エンジニアリングの専門知識は不要な内容となっていますので、データ活用のひとつの事例として気軽にお読みください。
1. はじまり：データマネジメントに取り組むきっかけ
組織に渦巻く「価値」への不安
プロセス改善担当として入社した私は、まず組織課題のヒアリングから始めました。すると、多くのチームからプロダクトの「価値」に関する不安の声が聞こえてきました。
- 「価値のあるものを定義する力が足りてない」
- 「顧客に本当に喜ばれる機能を作っているか自信がない」
これらの声の背景には、2つの組織的な事情がありました。
- 新機能開発への注力: 多くの顧客からのフィードバックや期待に応えるため、組織はサバイバルモードに近い状況で次々と新機能開発に注力していました。
- 既存機能の価値評価の形骸化: その反面、リリースした機能が本当に使われているのか、価値を発揮しているのかを評価する活動が後回しになっていました。なぜなら、本番データへのアクセスが難しく、モニタリングや価値評価自体に大きな手間がかかる状態だったからです。
この「顧客に喜ばれる、価値のある機能とは？」という問いに答えるため、データマネジメントへの取り組みが始まりました。
2. 立ちはだかる課題と制約
データ活用への第一歩を踏み出そうとしたとき、いくつかの課題と制約が明確になりました。
なぜ、データは簡単に見られなかったのか？
開発チームに「本番のログは見れますか？」と質問したところ、答えは「権限保有者のみ」でした。その理由は、セキュリティや契約上の制約によるものです。
- 個人情報に対する匿名対応: 分析データを閲覧する人にとって、個人情報が特定できないように匿名化する必要がありました。
- 分析利用が許可されていないデータの除外: 一部の顧客とは契約上、データを分析目的で利用することができません。そのため、集計を行う際は、これらのデータを必ず除外する必要がありました。
これらの制約により、本番運用チームがデータ集計依頼を一手に引き受けており、開発チームが気軽にデータをモニタリングできる状態ではありませんでした。
別の場所でも生まれていた「データが見えない」ことによる苦労
その頃、開発チームとは別の部署でも課題が生まれていました。カスタマーサクセス部では、顧客が契約している新機能の利用状況が分からないため、より顧客に製品を活用してもらうためのアプローチに苦労していました。
【以前のコミュニケーション】
カスタマーサクセス担当者: 「（このお客様、機能Aを契約頂いているはず…）ご契約の機能Aはご活用いただけていますか？」
顧客: 「いえ、活用できてないですよー！」
カスタマーサ-サクセス担当者: 「（そうでしたか！もし事前に利用状況が分かっていれば、もっと踏み込んだフォローの準備ができたのに…！）」
取り組むべきことの明確化
これらの課題から、私たちが目指すべきゴールが明確になりました。
- 対象者: 開発チーム、カスタマーサクセス担当者
- データ: 製品の機能ごとの利用状況データ
- 大前提: データを閲覧するのに問題・心配がない安全な状態であること（個人情報の匿名化、分析不可データの除外）
3. 解決策：データエンジニアリングの実践
組織と制約の壁を乗り越えるため、私たちは「安全なデータのみを保持した場所」を構築し、そこへのアクセスを民主化するアプローチを取りました。
データの流れ
構築したデータ基盤のフローは以下の通りです。「問題のあるデータは、そもそもデータ蓄積場所にいれない」という設計思想です。
- データソース: 製品のアクセスログやDB、Salesforceなど、様々な場所からデータを収集します。
- 転送・加工: AWSのキュー処理やバッチサーバーを利用し、データを転送する過程で個人情報のマスキングや分析不可データのフィルタリングを行います。
- データ蓄積・加工: 安全になったデータを、データ基盤ツールである Snowflake に蓄積します。
- 可視化とユースケース: 蓄積されたデータを元にダッシュボードを作成したり、Salesforceに顧客ごとの利用状況を表示したりすることで、開発チームやカスタマーサクセスがいつでもデータを確認できるようにしました。
4. 協業が生んだアウトカム
データ基盤を整えただけでは、まだゴールではありません。そのデータを活用し、実際の「アウトカム（成果）」につなげるためには、重要な役割を担う「仲間」の存在が不可欠でした。
データスチュワードとの出会い
データスチュワードとは、「データ利用者のニーズを汲み取り、データを整備する人」のことです。私たちの社内では、カスタマーサクセス部の中に、現場の課題を常に整理し、発信してくれる担当者（まさにデータスチュワード）がいました。
私たちデータエンジニアと、彼らデータスチュワードが週次で情報同期を行う協業体制を築いたことで、データ活用は一気に加速しました。
- 私たち（データエンジニア）: データを安全かつ利用しやすい形で提供する
- データスチュワード: 現場（カスタマーサクセス）のニーズを吸い上げ、データを具体的なアクションに繋がる形に整備・翻訳する
- カスタマーサクセス: 整備されたデータを元に、顧客へ価値を提供する
生まれた変化（アウトカム）
この協業により、カスタマーサクセスの現場では大きな変化が生まれました。顧客の利用状況が事前にわかるようになったことで、受け身のサポートではなく、能動的なアプローチが可能になったのです。
【改善後のコミュニケーション】
カスタマーサクセス担当者: 「（このお客様、機能Aの利用状況はこうなっているな…）ご契約の機能Aについて、何かお困りごとはありませんか？お手伝いできることがありますか？」
顧客: 「ぜひ、お願いしたいです！」
カスタマーサクセス担当者: 「（フォローを主体的に推進できた…！）」
このようにして、単なるデータの可視化に留まらず、顧客への価値提供という具体的なアウトカムに繋げることができました。
5. 振り返りと今後の展望
データマネジメントを推進する上で大切なこと
今回の取り組みを通じて、2つの重要な学びがありました。
- 課題解決としての一歩目を踏み出すこと: 「データ基盤を作ろう」という目的から始めるのではなく、現場の具体的な課題解決のためにデータマネジメントを始めることが重要です。
- データを価値に転化させる仲間の重要性: データエンジニアリングはあくまで手段です。そのデータをビジネス上の価値に転化させるデータスチュワードや、それを見て意思決定・アクションを実行する仲間がいてこそ、データは真の価値を発揮します。
これからの取り組み
この成功事例を元に、今後はさらにデータ活用の輪を広げていきたいと考えています。
- プロダクト開発: POやPdMがデータに基づいた機能の意思決定を行う。
- 開発プロセス改善: 4keysなどの開発メトリクスを可視化し、チームのパフォーマンスを改善する。
- データドリブンな文化の形成: 部署間のサイロをなくし、誰もがデータにアクセスし、自発的に活用する事例を増やすことで、組織全体でデータドリブンな意思決定ができる文化を目指します。
さらに将来的には、蓄積されたデータを活用し、「どのような顧客がプロダクトを最大限活用できているのか」といった特徴量分析や、システムの異常検知など、より高度なデータサイエンスのアプローチにも挑戦していきたいと考えています。