A/Bテストとダッシュボードのための専用ツールはいらない。いまはまだ。 - YouTubeチャンネルM&Aプラットフォーム「ホコホコM&A」の開発ログ

A/Bテストを1本仕込むたびに、何かを損している気がする。

PostHog側の実験設定と、コード側のフラグ分岐。

この2つを毎回きっちり揃える作業が、地味に重い。

いまこんなことに時間を使ってる場合じゃない。

ダッシュボードも同じで、Looker Studioでディメンションとメジャーの意味を毎回ググる.

ディメンション？メジャー？どっちがどっちだっけ？

どの関数がどっちに使えるのかをダメ元で試してみたりググったり相性を確認しながら組み立てる。

この時間も地味に重い。もうこの作業に４時間掛けてるけど、その価値はあるんだっけ？

この問題の正体は分かっていて、専用ツールが持つ圧倒的な汎用性が、私の生産性とやる気の95%を奪っていました。いま本当に必要なのは、その極端に汎用的な機能群のたった3%です。体感で。

というわけで、ダッシュボードとA/Bテストの実装は、自分で作ることにしました。

ただし断っておくと、PostHogそのものはやめていません。AIエージェントによる開発とはかなり相性が良いツールで、イベント収集と分析では今も現役で活躍しています。やめたのは2つだけで、ダッシュボード的な表現を専用ツールで作ることと、A/BテストをPostHogの機能で組むこと。どちらも「ツールが悪い」わけじゃなくて、「いまの使い方に対して、毎回の設定コストが見合わなくなった」という話です。

前提として、私たちが運営しているホコホコM&Aは、2026年5月に始まったばかりのサービスです。計測したい指標も、試したいA/Bテストの中身も、まだまだ毎週のように変わります。「これを見たい」「次はこれを試したい」が入れ替わるような状態だと、専用ツールの初期設定コストは、指標や実験が四半期・半期単位で固定されているサービスよりもずっと重くのしかかります。1回覚えれば済む作業ではなく、変わり続ける対象に対して毎回同じような手間を払い続けることになるのです。

hokohoko.co

手軽だけど非力、重いけど強力
せっかくのトラフィックを溶かしかねない
だったら作ればいい
都合のいい話だけでは終わらない
SaaSは死んだの？
それでも、手放さなかったもの
ホコホコM&Aについて
出典
関連記事

手軽だけど非力、重いけど強力

ダッシュボード的な表現は、これまで2つのやり方を行き来していました。ひとつは、みんな大好きGASでデータを取ってきてスプレッドシートに流し込むようなやり方。もうひとつはLooker Studioでクエリを組んで可視化するやり方です。

GAS＋スプレッドシートは手軽で、ちょっとした集計をサッと出すには大変向いています。ただし表現力に限界があるし、複雑な切り口を見たくなると途端に厳しくなります。関数を積み上げたシートは、後から見返すと何をしているのか自分でも分からなくなる。「先週の自分が書いた数式」がすでに読めません。なんなら、数時間前に書いたものですら読めないこともある。

Looker Studioはその逆で、表現力は高いものです。ただしこの「表現力が高い」は「習得コストが高い」の言い換えでもあります。何がディメンションで何がメジャーなのか、どの関数がディメンション側で使えてどの関数が使えないのか、使えない組み合わせに当たったときにどう回避すればいいのか——この手の作法を都度思い出しながら組み立てることになります。「この関数はメジャーにしか使えないので、いったんディメンションを別の形に変換してから」のような迂回策を、見たいグラフ1つのために毎回ひねり出し発明する。ちょっとした思いつきを確認したいだけなのに、確認するまでの手数が多く、確認した時にはたいして発見のないグラフが出来上がったり、その結果「あれ？そもそも何が確認したんだっけ？」のようなこともしばしば起きます。

つまり、手軽だが非力なGASと、強力だが重いLooker Studioの間で、ちょうどいい落としどころが無いまま使い分けていた、という状態でした。

せっかくのトラフィックを溶かしかねない

A/Bテストも似たような話で、設定がとにかくダルい。

PostHog側の実験設定（バリアントの比率、対象ユーザーの条件）と、コード側のフラグ分岐（どの画面のどの要素をどう出し分けるか）の両方を、毎回きっちり合わせ込む必要があります。

さらに困るのが、この手の細かい設定は、往々にして一発で決まらないということです。

PostHog側の設定とコード側の実装がズレたまま気づかずに配信を始めると、せっかくのトラフィックを無駄にしてしまいます。配信を開始してから思わぬ条件が見つかって追加・再配信のようなこともあります。テスト対象の分母がもともと少ないサービスなので、最初の数時間を無駄にした時のダメージは大きいものです。

だったら作ればいい

ここでAIエージェントによる開発が効いてきます。専用ツールの仕様を理解して、その流儀に沿って設定を組み立てるより、今欲しい機能だけを管理画面として自分で実装する方が、体感で何倍も早いのです。

狙ったのはパーフェクトな汎用性ではありません。今我々に必要なA/Bテストのパターンを、ほどよい具合で抽象化しただけです。汎用ツールが対応できる無数のユースケースのうち、自分が使うのはせいぜい数パターン。そこだけ動けば十分という判断でした。バリアントの比率を決めて、対象を絞って、結果を見る。これだけできれば、実務上困ることはほとんどありません。

この判断がどんな場面でも当てはまるとは思いません。こうした専用ツールの価値の一つは、マーケティング担当がエンジニアの手を借りずに、自分でA/Bテストやダッシュボードを組めることです。マーケとエンジニアリングのチームが分かれている組織では、この「エンジニアを介さずに完結できる」という点こそが、専用ツールを使う一番の理由になりうるでしょう。私たちのプロダクトではいまのところ、こうした分業がありません。分業が必要になるような大規模な組織ではないので、この利点がそもそも発生しないのです。だからこそ、その分の複雑さやコストを支払う理由もない、というだけの話です。

同じ管理画面の延長で、見たい指標をそのまま表示するダッシュボードも作ることになりました。GASのように後から自分でも読めなくなる心配もなく、Looker Studioのようにディメンションとメジャーの作法を思い出す手間もありません。専用ツールの仕様を頭に入れて、その通りに手を動かす必要がなくなりました。気づけば、当初のA/Bテストの範囲を超えて、それなりに多機能なダッシュボードができあがっていました。狙って作り込んだというより、必要な画面を都度足していたら育っていた、という方が近いです。

都合のいい話だけでは終わらない

いいことばかりではありません。専用ツールが標準で持っている機能を、自作では自力で用意しないといけないです。

たとえば、A/Bテストの結果が統計的に意味のある差なのか、それとも誤差の範囲なのかを判定する仕組みは、自作の場合はここを自分で実装するか、目視で「まあ差がありそうだ」で済ませるか、どちらかになります。サンプルサイズが偏っていないかのチェック（いわゆるSRM: Sample Ratio Mismatch）のような、地味だが効いてくる検査も、専用ツールなら組み込みで警告してくれます。自作の場合はこの手の「気づかないと静かに間違った結論を出す」類のチェックが漏れやすいものです。ここは今後、育てていく必要がある部分だと自覚しています。

SaaSは死んだの？

2024年12月、Microsoftのサティア・ナデラCEOがBG2ポッドキャストに出演し、SaaSのようなビジネスアプリケーションは「CRUDデータベースの上にビジネスロジックを乗せただけのもの」であり、AIエージェントの時代にはそのロジックがエージェント側に移っていくため、既存のビジネスアプリは「崩壊するだろう」という趣旨の発言をしました。これが「SaaS is dead（SaaSは死んだ）」という見出しで広まりました。

というのはこの記事を書くにあたり調べて知ったのですが、実際の発言を確認すると、見出しほど軽い話ではなく、むしろ踏み込んだ予測でした。SaaSというジャンルがゆるやかに変質していく、というより、「エージェントの時代には、今のビジネスアプリの多くがそのまま崩れていく」というかなり強い言い切りです。

今回のダッシュボードとA/Bテストの話も、規模は全然違いますが、世界のこの構図の末端で起きた小さな出来事だと言えるかもしれません。

それでも、手放さなかったもの

ここまで読むと「全部自作すればいいのでは」と思うかもしれませんが、もちろんそういうわけでもありません。

イベントの収集・蓄積・探索的な分析は、さすがに専用ツールの方に今も分があります。「何が起きているか分からない状態」から仮説を探す作業や、上で書いたような統計的な妥当性の担保は、自作の管理画面には向いていません。自作したのはあくまで「ダッシュボードの見せ方」と「A/Bテストの割り振り」という、こちらの都合が強く出る、答えがある程度決まっている部分だけです。

指標も実験も固まっていない今のフェーズだからこそ、この選択が合っています。サービスが育ち、見るべき指標も試したいことも一通り出尽くして、マーケ担当とエンジニアリング担当が別々で立っている頃には、また判断が変わるかもしれません。