運用に乗らなかった解約予想を作り直して現場浸透させた話

こんにちは！ゲンシュンです。

CDP企画室としてヘルススコア(解約予想)の実装と運用浸透周り、3ヶ月ぐらいやったことをまとめます。

背景

CDP企画室の立ち上げ

ちょうど1年前にプロダクト戦略室から移動し、CDP企画室の立ち上げにjoinしました。プロダクト部でのデータ基盤を使った機能利用把握やデータ探索などデータドリブンなプロダクト戦略を立てる、というのはある程度形になってきました。一方ビジネス部門は、プロダクト外の様々なデータが各部で閉じており、データを横断的に利活用できていない課題感があり、ビジネス側のデータ統合、利活用に価値があるのでは？という話になりました。

既存の事業企画室に並列する形で新たにCDP企画室を新設し「社内に散らばったデータ×社内推進による価値の創出」というのを目標に、事業企画から見た課題 + CDPでのデータ統合 → 社内推進で価値創出を目指します。CDP企画室では多種多様なデータを使った仕組み作りやデータ統合をやってきたのですが、その内の1つである解約予想に焦点を当てます。

過去運用に乗らなかった解約予想

過去に登壇した「データマネジメント新年会 〜去年のしくじりを共有し、正月ボケを解消する〜」の登壇内容にもありますが、機械学習×プロダクトデータを用いた解約予想というのは既に試みていたのです。アナリスト中心にロジック改善を重ね、かなり高い精度を誇っていたのでうまくいったな〜〜と思っていたら、気づいたらいつの間にかあんまり利用されず。。

今回の記事はプロダクト部側で実装した解約予想とは別に、既に事業企画室側で解約予想やりたいという構想があり、事業企画室の設計ベースに、ロジック決め、CDP基盤として実装リリース、社内推進をしたので、その流れを書いていこうかなと

データ基盤とCDP基盤

データ基盤とCDP基盤は別物として扱い、業務進行していきました。各メンバーのスキルセットを鑑みた結果DWH周りの知見を活かして速攻形にしよう！からの結論、弊社のデータ基盤と同じくBigQueryにすべてのデータを統合してます。「ビジネス部のデータを利活用のために統合する場所」をCDP基盤と呼んでいるだけなので、場合によっては「それ結局データ基盤じゃね？」というツッコミもあり得ると思います。

ただ自分の中では「データ基盤」と「CDP基盤」は役割と課題解決することが違うため、たとえプロダクトデータやdbt project的にデータ基盤内にいい感じに実装したほうが楽な一面もあったかもですが、厳密に違うものとして捉えデータ基盤とCDP基盤は並列する概念としてアーキテクチャを考えました。いつか、CDP基盤の立ち上げ周りの記事も細かく書きます〜。今回はそのへん端折ります。

プロジェクトの流れ

解約予想のフレームワーク

事業企画室の皆さんが描いた青写真、Gainsight社の「DEARフレームワーク」をベースに解約予想のスコアリングを試み始めたのが最初です。DEARが顧客ライフサイクルになっており、そこから要素を分解し、要素を1つ1つ定義していきます。その後各指標を満たすデータを色んなところから引っ張り、手作業で計算し、ある程度形にし、一部の担当顧客単位で「温度感と合ってる」ものを磨き込んでいったものが初号機です。ここまで構想から実物までやってくれてホントありがたい！！！

プロダクトデータ、SalesForce、最終接触日、NPSアンケート、などなど様々なデータを手作業でエクセルにjoinさせていったものを全部自動的に全データを統合して運用に乗せたい！！けどデータの統合とかどうしたらいいかわからない！という状態から自分がjoinします。ビジネス部門の皆さんホント素晴らしい。ビジネス部門の色んな現場でこういう泥臭いけど「誰かにとっての気付きになりえる」ものってあるんだろうなー。スケールせずに運用に乗らず、、みたいなものをCDP企画室として社内のデータを統合・利活用するミッションの重要性を改めて感じました。

ただ、初号機のスコアロジックを眺めてた際、重要な要素なのでスコアの重み付けがN倍と激しかったり、初号機ロジック検証の顧客社数が少なそう(直感)だったり、「現場メンバーの温度感（超定性的な情報）」があったり。プロダクト部で定量的な数値を追ってた身としては、因果関係どんくらいあるんだろう？というのが率直な感想でした。

指標設計実装フェーズ

カスタマーサクセス部門の長と現場分析メンバー交えて、何度も議論繰り返します。各論点の洗い出し、各要素にとっての理想状況、何が気づきになりえるのか？どういうデータが今利用可能なのか？など、各議論の要点を事前に整理して即詰めてました。事業企画っぽい仕事なのかな！？

SalesForce含め、各サービスに含まれるデータを色々取りこみ、その中から筋のよさそうな部分を残し、スコアっぽいものを速攻BQ × dbtで爆速実装。この過程で実は更新されていないビジネスデータを発見したり、データが重複している、突合できない、思ったよりも記入されていない、などの問題が見つかります。誰もこのカラムにデータいれてねーじゃん！！！みたいな。現場メンバーやSalesForce保守運用チームに、◯◯なデータが欲しい、◯◯ってどのような更新頻度？誰が入れてるの？など聞き込みしまくることでなんとなく全体像がつかんでいきます。

現段階の「利用可能で適切に入力されているデータ郡」をベースに叩きのヘルススコアを実装し、スコアの蓋然性、各指標のバランス、担当CSによる肌感、データの制約はないか？などを議論し、変更し、実装変えて、またスコア出して、これの繰り返しです。なんだかんだそれっぽい感じになってくる。

このフェーズでも定量的な改善ポイントや、「肌感」という言葉への向き合い方に戸惑いが多少あります。この指標のロジック、ちょっと変えるだけでスコアが結構変わっちゃうんじゃないか、みたいな。

施策運用フェーズ

解約予想v1としてリリースし、そこからある程度数値変動みながら、現場メンバーにどう使ってもらうかの議論フェーズになります。同じくカスタマーサクセス部門の長と現場分析メンバー交えて、こちらの想定利用ケースと、現場からの意向などをすり合わせます。マネージャー層が全体感を把握するためのダッシュボード、担当CSが自分の顧客の変動を見るダッシュボードあたりが想定利用ケースですが、フレームワーク通り各指標ごとに点数化されているので、◯◯指標が減ってる→子役との最終接触から間経っているんじゃないか？先月から大幅にスコア減ったないし増加した企業の要因って◯◯だけど、この施策が刺さった/刺さらなかったんじゃないか？などなど。現場目線での運用方法ガッツリ話せたことで、自分もビジネス部門の仕事内容の解像度が上がりました。

またスコア化のために、雑な例ですが「接触有無」みたいなデータを使っているが、現場メンバーによって更新してる/してないがバラバラなので、これを気にきちんと入れてください、現場メンバの活動をデータ化することに意味があるなどの周知とセットでやることで、スコアの施策運用だけじゃなくデータの信頼度も合わせて高まったので大事でした。

アーキテクチャ

データ基盤とCDP基盤はあくまでも独立して並列におきました。DWH→CDPという直列的な設計もあれば、CDP基盤が全部包括する設計もあるかと思います。独立させた意図としては以下あたりです

• CDP基盤はビジネス部門の都合による変化が激しく、破壊と再生のライフサイクルが早いだろう
• CDP基盤起因のデプロイやデータなどを理由に、プロダクト側(データ基盤)の影響を極力受けたくない
• データ基盤は過去解約含めすべてのプロダクトデータを保持しているが、CDP基盤は「今」を注視している

データ基盤のoutputがCDP基盤のinputになることが多々ありました。dbtで同一projectなら、データ基盤のモデルを参照すれば良いんですが独立関係なので、CDP基盤から見るとデータ基盤のテーブルは外部のデータなのでstg層経由で取り込むようにしました。なんかダサいんすよね〜、現段階では仕方なし！

またSalesForceなどのデータの履歴化を独自で残すようにしており、転送結果をスケジュールクエリでhistoryテーブルに書き残す的な感じです。SalesForceにはスナップショット機能があり履歴化は可能なので自分たちでやる必要性はないかもですが、現時点で自分達のSalesForce周りの解像度が低いこと、任せたとしてSalesForce側の履歴化ミスってましたの検知ちゃんとできるのか自信がなかったこと、今のフェーズは自分たちが責任持って履歴化残す方がデータの信頼性が高い、等が理由です。

どうでもいい補足ですが、弊社データ基盤はsaturnと命名しており（チームで総選挙して決めました）、CDP基盤はその世界観に合わせてneptuneと名付け、ビジネス部門の多種多様データ群をBQに転送する際そのへんの諸々をasteroidと名付けました。土星の次が天王星だと勘違いし、間違えてuranusを爆誕させた事故もありました笑

学び

この3ヶ月の活動を通じて難しいけど大事だなと思ったことは、定量性をどこまで追い求めるのかです。恐らく、解約予想が60%なのか50%なのか、スコアが3点なのか4点なのかってそこまで大事じゃない。いや、大事なんですけど、そこまで大事じゃない、みたいなニュアンスです笑
データ基盤実装し、データを元に意思決定することをやってきた立場からすると、根拠であったり精度であったりをある程度求めてきたんですが、ビジネスメンバーが欲しいのは「気付き」でなんだよなー。理想状態や論理(今回はDEARフレームワークでしたが)に対してスコアリングをし、それの定量面は定かじゃないかもしれないが、それを元に各現場メンバーがその気付きを元にアクションに繋げやすい、だから「肌感」というのをある程度大事にしなきゃいけないんだろうなーと。
実際非常に難しいラインで、極端に言うと「定量的に正しくないアウトプットだった場合、意味のないものを追ってしまう」と「現場メンバーの肌感を信じ、気付きとアクションを生みやすいアウトプット」の間を取りにいく、それこそファジーなデータとの向き合いなんだろうなー、というのを考えさせられる機会でした。ファジーなデータに向き合う勇気ね。

あとは、ここまで現場メンバー巻き込んでたくさん議論をしていかないといけないんだなーというのも学びです。「欲しいって言ってたダッシュボード用意したよーどうぞー！質問あれば!」じゃ全然だめです。継続的にここまでやりきって初めて運用浸透するんだなと。社内推進は泥臭いことの連続です。小さな成果を出すためにまずやりきって社内の信頼を勝ち取り、どんどん広げていく、楽な道はない！笑

たくさんの学びがありました！以上です。