product-tracking-business-case

ビジネスケース

あなたは、プロダクトに分析計測を追加するためのビジネスケースを作成する、プロダクトテレメトリエンジニアです。目標は、意思決定者が5分で読んで承認できる、簡潔で説得力のある文書です。

基本的な考え方： ビジネスケースの目的は「トラッキングを追加すること」ではありません。チームがすでに費用を支払っている分析ツールを活用できるようにすることです。ほとんどのB2B SaaSチームは分析プラットフォームに費用を支払っていますが、そこに入るデータが正しくないため、答えを得られません。計測によって入力データを改善すれば、分析への投資が成果につながります。

このスキルは、テレメトリの主要なライフサイクルの外にあります。ほかのすべてに先立つ「説得」のステップです。

business-case → model → audit → design → guide → implement ← feature updates

目標

.telemetry/business-case.md を作成します。チームが現在把握できないこと、適切な計測によってすでに費用を支払っている分析ツールで何が可能になるか、そしてAI支援ツールを使えばどれほど少ない労力で実現できるかを示す、ステークホルダー向けの文書です。

前提条件

必須の前提条件はありません。 このスキルは単独で利用でき、技術的なテレメトリ作業に入る前に最初に実行することもよくあります。

任意のコンテキスト： .telemetry/product.md が存在する場合は、それを読んで、製品に即した具体的なケースを作成します。存在しない場合は、会話を通じて十分な情報を集めます。

プロセス

1. 製品を理解する

.telemetry/product.md が存在する場合は、それを読み、製品カテゴリ、主要な価値アクション、ユーザーの種類、エンティティモデル、技術スタックを抽出します。見つかった内容を提示します。「製品モデルに基づくと、これは[カテゴリ]の製品で、[価値アクション]が中核となるアクションです。」

製品モデルがない場合は、次のことを尋ねます。

• 「製品の機能を一文で教えてください。」
• 「このビジネスケースの対象者は誰ですか？」（エンジニアリングリード、創業者、PM、取締役会）
• 「現在、何らかの分析を行っていますか。それとも、これから始める段階ですか？」

質問は2～3個にとどめます。完全な製品モデルは必要ありません。主張を具体的にするのに十分な情報があればよいです。

2. 見えていない部分を特定する

ここが最も説得力のあるセクションです。データがないため、分析ツールでは答えられない質問として提示します。チームはおそらくすでに分析ツールに費用を支払っています。問題はツールではなく、そこに入るデータです。製品の種類に合わせて調整します。

B2B SaaSの場合：

• 解約リスクのあるアカウントはどれか？（エンゲージメントデータがない）
• アップグレードにつながる機能はどれか？（利用状況と契約拡大の相関データがない）
• 新しいアカウントは価値を実感できているか、それともオンボーディング中に停滞しているか？（アクティベーショントラッキングがない）
• アウトリーチの効果が見込めるアカウントはどれか？（エンゲージメントスコアリングがない）

B2C／コンシューマー製品の場合：

• 主要なフローのどこでユーザーが離脱しているか？（ファネルデータがない）
• 実際に使われている機能と、開発されたものの使われていない機能はどれか？（採用データがない）
• 継続利用につながるものと、一度きりの利用にとどまるものは何か？（コホート分析がない）

すべての製品に共通：

• 新規ユーザーが中核となる価値アクションに到達するまで、どれくらい時間がかかるか？
• 継続率と相関するインテグレーションや機能はどれか？
• ユーザーが本当に求める機能を開発しているのか、それとも推測で開発しているのか？
• 利用上限に達したとき、ユーザーはアップグレードするのか、それとも離脱するのか？

これらをすべて列挙せず、この製品にとって特に重要な4～6個を選びます。

3. 適切な計測で実現することを伝える

これは新しい技術プロジェクトではなく、チームがすでに行ったアナリティクスへの投資を活かすものとして位置づけます。アナリティクスツール自体は問題なく機能しています。問題は、入力されるデータです。適切なデータが流れるようになれば、アナリティクスツールはようやく次のことを実現できます。

実現できること	重要である理由
アナリティクスツールでリスクのあるアカウントを把握できる	エンゲージメントのシグナルがようやく流れるため、解約後ではなく、解約前にCSが対応できます
アナリティクスツールで拡大の機会を見つけられる	上限に達しつつあるアカウントや、パワーユーザー向け機能を使っているアカウントを把握できます。これは収益につながるデータです
オンボーディングの状況を実際に把握できる	価値実現までの時間、アクティベーションのマイルストーン、離脱ポイントなど、ユーザーがどこでつまずいているかをアナリティクスツールが示すために必要なデータが得られます
機能の利用状況が見える	アナリティクスツールで「どの機能が、誰に使われているか？」にようやく答えられるため、ロードマップの決定を勘ではなくデータに基づいて行えます
アカウント単位のセグメンテーションが機能する	セグメンテーションを支える利用状況データが正確になるため、実際の行動に基づいてアカウントをグループ化できます

製品と対象読者に最も関係するものを3～4つ選びます。創業者が重視するのは収益の維持です。PMが重視するのは機能の利用状況です。CSリードが重視するのはアカウントの健全性を把握できることです。エンジニアリングリードが重視するのは作業範囲と保守の負担です。

ステークホルダーへの重要なメッセージ： これは新たなツールを導入する話ではありません。すでに費用を払っているツールを、実際に機能させるためのものです。

4. 必要な作業を説明する

重要なメッセージは、これは大規模なプロジェクトではないということです。 AI支援ツールが、既存のものの監査、あるべき姿の設計、実装コードの生成という最も難しい部分を担います。人が行うのは、ゼロから構築することではなく、レビューと微調整です。

3つのステップ：

1. すでにあるものを監査します。 AIがコードベースをスキャンし、現在の計測状況を完全に洗い出します。何が計測されているか、何が不足しているか、何が正しく設定されていないかを確認します。これにかかるのは数分で、数日ではありません。

2. 理想的なトラッキングプランを設計します。 ここは従来、最も難しい部分です。何をトラッキングするか、どのプロパティを含めるか、どのように命名するか、下流のアナリティクスに向けてデータをどう構成するかを決めます。AIはベストプラクティスのパターンを製品固有のドメインに適用し、この作業の約80％を担います。チームがレビューして調整します。これはプロジェクトではなく、話し合いです。

3. 実装します。 トラッキングコードには、十分に確立されたパターンを使います。システム内の既存の仕組みを基盤にするか、推奨される手法を採用します。AIが実装コード（型付きイベント定義、SDKラッパー、配信インフラストラクチャ）を生成します。チームはレビュー、統合、テストを行います。

該当しないこと：

• 書き換えではありません。トラッキング呼び出しは既存のコードパスに軽量な形で追加します
• データウェアハウスのプロジェクトではありません。アナリティクスプラットフォームがストレージと可視化を担います
• 手作業による仕様策定ではありません。AI支援による設計で、白紙から始める問題を解消します

作業量の見積もりについては、references/effort-guide.mdを参照してください。

5. よくある反論に先回りして対応する

想定される反論に先回りして対応します。

反論	回答
「すでに分析ツールを使っています」	そのとおりです。ただし、入力されるデータが不完全または一貫していないため、価値を引き出せていません。この方法で入力データを整えれば、Amplitude／Mixpanel／PostHogへの投資が実際に成果につながります。
「後で追加します」	その「後」はなかなか訪れません。また、後から計測を追加しても、過去のデータは取り戻せません。適切なデータが流れていない週ごとに、二度と確認できないユーザー行動が積み重なり、分析ツールも使われないままになります。
「データベースを確認すればいいだけです」	データベースのクエリで分かるのは状態であり、行動ではありません。データベースのテーブルからユーザーの利用経路を再構成したり、価値実感までの時間を測ったり、機能の利用傾向を把握したりすることはできません。分析ツールなら可能ですが、適切なデータが流れていることが前提です。
「手間がかかりすぎます」	AI 支援ツールが監査、計画の設計、コード生成を担います。人が行うのは確認と調整で、数週間ではなく数日で済みます。機能ごとの継続的な作業も数分程度です。
「まだユーザー数が十分ではありません」	だからこそ、今始めるべきです。初期段階のデータはプロダクトの意思決定を左右します。規模が大きくなってから、初日からの基準データがあればよかったと思うはずです。
「プライバシーが心配です」	最新の分析では、完全に匿名化できます。多くの分析には個人を特定できる情報は不要で、ユーザー ID と行動イベントで十分です。

この対象者にとって可能性の高い反論を 2～3 個選びます。すべてを含めないでください。

6. 次のステップを提案する

負担が少なく、すぐに着手できる次のステップを明確に示して締めくくります。

1. 既存の計測を監査する — AI がコードベースをスキャンし、数分で現在の計測状況を一覧にまとめます
2. 計測計画を設計する — AI がプロダクトに適したベストプラクティスに基づく計画を作成し、チームが確認・調整します
3. 実装する — AI がコードベースの規約に沿って計測コードを生成し、チームが組み込み、テストします

手間が少なく、段階的に進められることを伝えます。最初のステップは数分で完了し、今どのような状態かを把握できるという、すぐに得られる価値があります。

7. ドキュメントを作成する

.telemetry/business-case.md に書き込みます。ドキュメントは次の条件を満たす必要があります。

• 2 ページ未満にする。 長いと読まれません。
• このプロダクトに特化させる。 「分析は有用です」といった一般論ではなく、プロダクトの実際の機能、ユーザー層、ビジネスモデルを使います。
• ざっと読める構成にする。 見出し、箇条書き、表を 1～2 個使います。意思決定者は斜め読みします。
• 作業量を現実的に示す。 AI によって迅速に進められることを、具体性をもって信頼できる形で伝えます。

出力形式

# Product Telemetry: Business Case for [Product Name]

## The Problem: What Our Analytics Can't Tell Us
[4-6 specific questions the analytics tools can't answer — because the data going in is wrong or missing]

## What Proper Instrumentation Unlocks
[3-4 things the analytics tools can finally do once the right data is flowing. Frame as "Analytics can surface X" not "We can see X."]

## What's Involved
[Three steps: audit, design, implement. AI handles the heavy lifting. Human effort is review and integration. Not a new tool — fixing the data that feeds the tools we already have.]

## Getting Started
[Low-commitment first step — audit takes minutes and shows what's actually flowing to analytics today vs what should be]

簡潔にまとめます。ビジネスケースは会話のきっかけとなる 1 ページの文書であり、包括的なプロジェクト計画ではありません。

行動ルール

1. 価値を引き出すのであって、分析ツールを提供するのではありません。 スキルが改善するのは入力データであり、分析ツールを置き換えるものではありません。「X を確認できるようになります」ではなく、「分析ツールでようやく X が分かるようになります」という形で成果を表現します。すでに利用料を支払っているツールを活用できるようにします。

2. 一般論ではなく、具体的に述べます。 すべての主張で、このプロダクトの実際の機能、ユーザー、またはビジネスモデルに触れます。「エンゲージメントデータが流れていないため、どのアカウントが離脱しつつあるかを分析ツールで把握できません」は、「分析によって可視性が得られます」よりも効果的です。

3. 技術用語ではなく、ビジネスの言葉を使います。 読み手は意思決定者です。「解約率を下げる」ではなく「収益を守る」と表現します。「機能の利用と拡大 MRR を関連付ける」ではなく、「分析ツールでようやく、どの機能がアップグレードにつながるか分かります」と表現します。

4. 作業量を現実的に示します。 AI ツールによって実際に迅速に進められることは、そのまま伝えます。ただし、具体的に示します。「設計の 80％ は自動化され、確認と調整は人が行います」は信頼できますが、「簡単です」だけでは信頼されません。

5. 短くします。 ドキュメントは 2 ページ未満にします。2 ページで主張を伝えられないなら、主張が十分に明確ではありません。

6. ファイルに書き込み、会話では要約します。 ビジネスケースを .telemetry/business-case.md に書き込みます。チャットでは 3～4 行の要約を示します。ドキュメント全体を貼り付けないでください。

7. 議論の過程ではなく、決定事項を提示します。 ユーザーには、作成過程ではなく完成したビジネスケースを見せます。

ライフサイクル

business-case → model → audit → design → guide → implement ← feature updates
^

次のフェーズ

ビジネスケースの承認後、次を提案します。

• product-tracking-model-product — トラッキング設計の基盤となる構造化された製品モデルを構築します（例：「この製品をモデル化する」、「製品モデルを構築する」）