データドリブン経営とは一体　データ活用とかCDPの話

前の記事では、今の良い開発会社は、AIでコードを速く書ける会社ではなく、要求、実装、検証、顧客の反応を一つのループとして設計できる会社ではないかと書きました。

ただ、ループを作るだけでは足りません。

何かを実行し、その結果を見て、次の判断を変える。その流れを毎回起きる仕組みにするには、現実に何が起きたのかを観測できる必要があります。近頃はAIがかなり役に立ってくれるのですが、AIも現状を把握するものがないとうまい壁打ちしてくれません。

そこで重要になるのがデータです。

データは、報告書やダッシュボードを作るためだけのものではありません。会社が現実を観測し、次の判断を変えるための軸になります。

データがなければ、会社は印象やお気持ちで判断する

会社は、データがなくても振り返れます。

記事を出した。アクセスが増えた。だから、この記事はうまくいった。

問い合わせが増えた。だから、マーケティングは良くなっている。

商談が増えた。だから、営業活動はうまくいっている。

売上が増えた。だから、会社は成長している。

でも、それぞれ途中の結果しか見ていません。

アクセスが増えても、問い合わせにつながっていないかもしれない。問い合わせが増えても、狙っている顧客ではないかもしれない。商談が増えても、ほとんど受注できていないかもしれない。受注が増えても、開発負荷が高く、利益や現金が残っていない可能性もあります。

一部の数字だけを見ていると、その数字を増やす能力だけが強くなります。

• アクセスだけを見れば、アクセスを集める会社になる
• 問い合わせ数だけを見れば、質の低い問い合わせを増やす可能性がある
• 商談数だけを見れば、受注につながらない商談を増やす可能性がある
• 売上だけを見れば、利益の残らない仕事を増やす可能性がある

データを使う目的は、数字を増やすことではありません。

会社で実際に何が起きたのかを、途中で切らずに見ることです。

検索需要から入金までを一つの流れで見る

弊社Beekleでも、複数のデータをつないで、マーケティングから経営までを観測できるようにしています。

DataForSEOやラッコキーワードのMCPでは、検索需要、関連キーワード、競合の状況を調べます。ここで見ているのは、市場にどんな悩みがあり、顧客がどんな言葉を使っているかです。他には、市場調査やユーザーインタビューなどもしたりします、そういったものはdriveに入れておいて連携してAIが見れるようにします。

記事やLPを出した後は、Search Consoleで検索結果への表示とクリックを見る。GA4やClarityでは、サイトに来た人がどのページを読み、どこを押し、どこで離脱したかを見る。

問い合わせ後はCRMです。

どんな会社から問い合わせが来たのか。狙っている顧客だったのか。商談へ進んだのか。何を提案したのか。受注したのか、失注したのか。次に何をするのか。

さらに、CRM上の案件や金額を、請求、入金、原価などの経理データと合わせて見ます。

受注しただけではなく、請求されたのか。入金されたのか。工数や外注費を考えても利益が残ったのか。次の投資へ回せる現金が増えたのか。

つなげたいのは、こういう流れです。

検索需要
→ 検索結果への表示
→ サイト訪問
→ CTAクリック
→ 問い合わせ
→ 商談
→ 受注
→ 請求
→ 入金
→ 利益
→ 次の投資判断

SEOの順位だけを見るのではない。

その検索が、どんな顧客との接点を生み、どんな案件になり、最終的に会社へ何を残したのかまで見る。

ここまでつながって、初めてマーケティング、営業、経理、経営が一つのループになります。

アプリのデータベースに残っているデータとかも活用できます

WebサイトとCRMのデータだけでは、契約までしか分かりません。

アプリやシステムを提供している会社なら、契約後に顧客が実際に何をしたのかも見る必要があります。

• 誰が登録したのか
• 初期設定を完了したのか
• どの機能を使ったのか
• どの層が課金しているのか
• どれくらい課金しているのか
• 最初の価値を得るまでに、どれくらいかかったのか
• どの画面や処理で止まったのか
• どの機能を使った顧客が継続したのか
• どんな利用状況の顧客が、問い合わせや解約に至ったのか

こうした事実の多くは、ga4とか、アプリのデータベースにあります。

ユーザー、企業アカウント、契約状態、作成されたデータ、機能の実行結果、処理の成否。さらに画面表示、クリック、機能実行などのイベントログを残せば、顧客がアプリ内でどんな順番で行動したかも分かります。

Webサイトのデータが「誰が興味を持ったか」を表し、CRMが「誰が商談や契約へ進んだか」を表すなら、アプリのデータは「提供しているサービスで顧客が本当に価値を得たか」を表します。

ここが抜けていると、集客と受注は改善できても、プロダクトそのものは改善できません。

問い合わせは増えた。受注も増えた。でも、実際には使われていなかった。

この状態を見つけるには、営業データだけでなく、アプリ内の利用データまでつなぐ必要があります。

BigQueryやDatabricksへ接続するのは、アプリの本番データベース

ここで、アプリのデータベースをBigQueryやDatabricksのような分析基盤へ接続するという話になります。

会社の資料を何でも一か所へ集める、という話ではありません。

アプリの本番データベースにあるユーザー、契約、利用状況、業務データを、分析用の環境から安全に参照できるようにする話です。

方法は大きく二つあります。

一つは、必要なときに分析基盤からデータベースを参照する方法。もう一つは、データベースの追加、更新、削除を検知し、分析用のテーブルへ継続的に複製する方法です。

BigQueryでは、Cloud SQLなど外部データソースへのフェデレーションクエリを使い、データを移動せずに参照できます。また、Datastreamを使えば、MySQL、PostgreSQL、SQL Server、Oracleなどの変更をBigQueryへ低遅延で複製できます。詳しい対応範囲は、Google Cloudの外部データソースの説明とDatastream for BigQueryで確認できます。

DatabricksのLakeflow Connectにも、MySQL、PostgreSQL、SQL Serverなどの変更をCDCで取得し、分析用のDeltaテーブルへ段階的に反映するマネージドコネクターがあります。対応内容はDatabricksのマネージドデータベースコネクタにまとまっています。

ただし、本番データベースをAIや重い分析処理から自由に叩かせるのは避けた方がいい。

本番環境はアプリを動かすための正本として守る。その変更を分析用の環境へ流し、原則として読み取り専用で扱う。個人情報や機密情報は、用途に応じてマスキングやアクセス制御を行うのがいい気がしますね。まあ中小企業とかだったらデータベースさえ分けておけば、ガンガン繋げちゃって分析していい気がしますが

この構成なら、アプリの動作へ影響を与えずに、顧客の利用状況をWeb、CRM、経理のデータと合わせて分析できます。

CDPは、別々のシステムにいる同じ顧客をつなぐ

データを集めるだけでは、まだ足りません。

同じ顧客が、システムごとに別の存在として記録されているからです。

• Webサイトでは、匿名の訪問者
• 問い合わせフォームでは、メールアドレス
• CRMでは、担当者と企業
• 契約後のアプリでは、ユーザーIDと企業アカウント
• 会計上では、請求先と取引先

これらが同じ顧客だと分からなければ、検索から契約、利用、継続、入金までを一つの流れとして追えません。

ここでCDPの考え方が重要になります。

匿名ID、メールアドレス、CRM上の企業・担当者、アプリのユーザー・企業アカウントなどを対応付け、同じ顧客の行動として扱えるようにする。

すると、単に「アクセスが多かった記事」ではなく、次のような分析ができます。

• どの記事が、継続利用する顧客を生んだのか
• どの流入経路から来た顧客が、最初の価値へ早く到達したのか
• どの企業属性と利用行動が、追加契約や解約につながったのか
• どの顧客が、どの機能によって成果を得たのか

CDP、アプリのデータベース、分析基盤は、それぞれ役割が違います。

CDPは顧客をつなぐ。アプリのデータベースは、サービス内で起きた事実を持つ。BigQueryやDatabricksのような基盤は、それらを他のデータと合わせて分析する。

製品名より、この役割分担を設計することの方が大事です。最近はAIの構築コストも安くなってきてますからね、結構おすすめです。まあ、分析のために現場によっては、データを整理したりクレンジング（データのお掃除）する方がコストだったりする時もあるんですが。

市場や顧客だけでなく、自分たちの行動もデータにする

観測するべきなのは、市場や顧客だけではありません。

会社自身が何をしているのかも、データにする必要があります。

自分は業務ログも取っています。

• 何に時間を使ったのか
• 会社の重点方針と関係の薄い仕事へ逸れていないか
• 同じ問題を何度も自分で解いていないか
• 本来仕組みにするべき仕事を、また手作業で処理していないか
• 任せると決めた仕事を、問題が起きるたびに回収していないか
• 作ったものが、売上、顧客価値、会社の仕組みのどれにつながったか

方針として何を言っていたかと、実際に何をしていたかは、普通にずれます。

営業を重視すると決めたのに、一日中プロダクトの細部を直していた。仕組み化すると決めたのに、また個別の問題を自分で回収していたとか、あんまり仕事しないで趣味のプロダクトやっていたとか。

自分的には、たくさん仕事をした感覚が残ります。でも、忙しかったことと、重要な仕事をしたことは同じではありません。

業務ログがあれば、経営方針と実際の行動の差を観測できます。

会社が何を生み出したかだけではなく、その結果を作るために、自分たちが何をしていたかまで見る。これも会社のループを改善するためのデータです。

データをつなぐと、AIに聞ける質問が変わる

市場、Webサイト、CRM、経理、アプリ、業務ログのデータがつながると、AIに聞ける質問が変わります。

「今月のアクセス数は？」ではなく、

どの検索キーワードから来た顧客が、商談、契約、継続利用まで進んだのか。

「どの機能がよく使われていますか？」ではなく、

継続率の高い顧客は、契約後30日間にどの機能を、どんな順番で使っているのか。

「売上は増えていますか？」ではなく、

どの流入経路と提案パターンから、粗利と現金が残る案件が生まれているのか。

「今月は忙しかったですか？」ではなく、

今月の経営方針に対して、実際の業務時間はどこへ配分されていたのか。

個別の数字を聞くのではなく、原因と結果をまたいで質問できるようになります。

ただし、AIに生のテーブルをそのまま渡せばよいわけではありません。

同じ「顧客」でも、Web、CRM、アプリ、会計で識別方法が違う。同じ「売上」でも、受注額、請求額、入金額では意味が違う。同じ「利用」でも、ログインしただけなのか、主要な機能で成果を得たのかでは価値が違います。

企業ID、担当者ID、アプリのユーザーID、案件ID、記事IDなどを接続する。問い合わせ、商談化、受注、入金、初回価値到達、継続といった言葉の定義を決める。AIに見せるデータと、見せてはいけないデータを分ける。

この設計がなければ、AIは数字を答えられても、経営判断に使える答えは出せません。

データを集めても、次の行動が変わらなければ意味がない

データ基盤を作り、ダッシュボードを増やしても、それだけでは会社は学習しません。

数字を見て終わる。AIに分析させて終わる。会議で話して終わる。

これでは、情報が増えただけです。

データごとに、少なくとも次を決める必要があります。

• 何が起きたら異常と判断するのか
• 誰が確認するのか
• どの判断へ戻すのか
• 誰が実際に変更するのか
• 変更後に、何を見て効果を確認するのか
• 得た学びを、仕様、手順、商品、判断基準のどこへ残すのか

たとえば、アプリの特定画面で多くの利用者が離脱していると分かったとします。

その情報を開発チームへ共有するだけでは足りません。

要求が間違っていたのか。画面が分かりにくいのか。必要な機能が不足しているのか。そもそも狙っている顧客が違うのか。

原因を考え、変更案を作り、実際に直し、その後の利用データでもう一度確認する。

そこで初めて、データが改善のループになります。

AIが出した分析結果も、自動的に正式な要求や経営方針を書き換えればよいわけではありません。証拠付きの変更案として戻し、人間がどこを変えるか判断する。

戻り道は作る。でも、勝手に逆流はさせない。

データ基盤は、会社の代わりに意思決定するものではありません。会社が現実を見て、次の意思決定を変えるための仕組みです。

会社を学習させるには、まず会社を観測可能にする

データが大事なのは、数字をたくさん持っている会社が強いからではありません。

会社が現実から学ぶためです。

市場で何が求められているのか。顧客がどこで興味を持ち、どこで離脱したのか。営業が何を提案し、なぜ受注・失注したのか。契約後、顧客がアプリをどう使い、価値を得たのか。その仕事によって利益と現金が残ったのか。そして、自分たちは実際に何へ時間を使っていたのか。

これらを一つの流れとして観測できれば、どこでループが止まっているのかが分かります。

データを持っているだけでは、会社はデータドリブンになりません。

データによって現実を観測し、仮説との差を見つけ、次の判断を変える。そして、その変更が効いたかを再びデータで確認する。

そこまで仕組みになって、初めてデータは会社の能力になります。ここまでデータを整備したら、mcpとかで繋げちゃえば、チャット形式で永遠と分析とか仮説出しとかできます。超便利です。周りの友人捕まえて電話で壁打ちしてもらうことが減りました。

会社の強さをループの設計が決めるなら、そのループを現実につなぐのがデータですかね。直感をサポートして実際にちゃんと上向いてるのかって数字の世界で経営をとらえるように私はしています。AIで楽になってきているので。（じゃないと私もやってないと思います、昔はやってなかった）