product-business-analysis

関連スキル

推奨事項の根拠として、指標の変動、異常、差異、または不一致について説明する必要がある場合は、$metric-diagnostics を使用してください。

プロダクトおよびビジネス分析

データに基づく証拠、背景情報、推奨事項を用いて、プロダクトやビジネスに関する質問に回答するには、このスキルを使用してください。実行可能な次のアクションを選べるよう、対象者に十分な信頼性のある証拠、解釈、不確実性の説明を提示してください。

スキルの設定

ソースの発見と検証

関連するセマンティックレイヤーは出発点となる地図として使用し、境界とは見なさないでください。

1. 考えられるすべてのソースを調査します。 タスクに関連するデータが含まれている、または解釈を変える可能性のある、接続済みまたは提供済みのあらゆるソースを検索します。各構造化データソースでは、関連するスキーマ、データセット、テーブル、ビュー、モデル、指標について、カタログまたはメタデータをあらためて確認します。既知のソース、テーブル、ダッシュボード、セマンティックマッピングは出発点であり、調査の終了点ではありません。
2. 重複や矛盾を比較します。 ソースの内容が重複または不一致の場合は、所有者、鮮度、定義、粒度、網羅性、直接性を比較します。最も権威のあるソースを使用するか、必要に応じて相互補完的なソースを組み合わせます。重要な矛盾を明記し、選択したソースが回答の根拠となる理由を説明したうえで、結論を出す前にライブデータの読み取りを通じて選択したデータを検証します。

ソースアクセスに関するガードレール

ソースへのクエリ、成果物の作成、または結論の導出を行う前に、回答に特定の信頼できる情報源が必要かどうかを判断します。

必須のソースを利用できない場合は、その手順を中止してください。必要なソースをユーザーに伝え、利用可能にするか、レビュー済みの代替ソースを提供するよう依頼します。信頼性の低い代替ソースを同等のものとして扱ってはいけません。

不足しているソースが任意の補足情報にすぎない場合は、利用可能な最も強い証拠に基づいて作業を続け、その不足が回答に重大な影響を及ぼす場合は、その点を明示してください。

不足している入力によって分析の枠組みや推奨事項が大きく変わる場合は、ユーザーに確認してください。それ以外の場合は、妥当な前提を置き、それを明記してから作業を進めます。

ワークフロー

1. 意思決定から始める

データソースや指標を選ぶ前に、分析が役立てるべき意思決定、対象者、アクションを特定します。

次の点を明確に述べます。

• 分析が役立てるべき質問と意思決定
• 回答を活用する人と、その人が実行できること
• 有用な回答を定義する範囲と比較対象
• 意思決定に関わる重要な成果または行動
• 作業を進めるために必要な前提

範囲が不明確だからといって、既定で広範な探索作業に広げないでください。

2. 意思決定に関わる背景情報を集める

詳細な分析に入る前に、$gather-business-context を実行します。このスキルは、ソースの選択、情報の取得、ソースの権威性、矛盾への対処、および簡潔な背景情報のメモを担います。収集した背景情報が分析や推奨事項にどう影響するかを判断するには、このワークフローを使用してください。

背景情報の確認は、タスクの規模に見合ったものにします。単独で完結するプロンプトや、ユーザーから十分な背景情報がすでに提供されている場合は、意思決定の枠組み、定義、ソースに関する前提、明らかな不足点を確認する程度の簡潔な確認で構いません。必須の背景情報収集を、広範な背景調査に変えてはいけません。

関連する背景情報で、次の点を明らかにしてください。

• 意図：その作業が何を達成するためのもので、なぜ行われたのか
• 定義：作業、指標、またはソースがどのように定義され、測定されるのか
• 時期：分析期間の前後に、解釈へ影響する可能性のある変化があったか
• 制約：現実的に実行可能なアクションに影響する意思決定、注意事項、または制限

3. 分析の枠組みを定める

質問を、焦点を絞った分析の枠組みに落とし込みます。

データに基づいて質問に答えるための枠組みを定義します。

• 推奨を裏付けたり、変更したりするために必要な具体的なデータ上の問い
• 確認すべき比較と切り口
• 意思決定に合った分析単位
• 結果を解釈するために必要な指標の定義と注意点

この枠組みを使って、妥当な仮説や解釈を見つけ、焦点を絞ったデータ上の問いに落とし込みます。広範な探索を避け、推奨を裏付けられるだけの具体性を持たせてください。

分析を進める前に、成功指標、ドライバー指標、ガードレール、または測定計画を定義する必要がある場合は、$design-kpis を使用します。

まず、答えによって何を示す必要があるかを平易な言葉で定義します。次に、その意味にできるだけ合致するデータを選びます。その際、誰を集計対象とするか、数値を意味のあるものにするにはどの比較が必要かも含めます。フィールドやイベントが意思決定で重視される内容の一部しか捉えていない場合は、何を捉え、何を捉えていないかを明記します。

4. 焦点を絞った定量分析を行う

設定した仮説を裏付ける、または否定し、意思決定に役立てるために、必要十分な定量分析を行います。

• 枠組みに沿って進めます。 まず、推奨を変える可能性のある分析を行います。追加で浮かび上がったデータ上の問いを記録し、意思決定に重要なものに答えます。影響の小さい切り口は、広範な探索に広げず、今後の検討事項として残します。

• 適切な比較を行います。 結果を推奨に結び付ける前に、関連するベースライン、分母、または比較対象に照らして解釈します。たとえば、あるグループの総利用量が最も多いという理由だけで、そのグループが最善の機会だと結論付けないでください。そのグループの規模が大きいために利用量が多いのではないか、アクティブユーザー数で正規化した後も傾向が維持されるか、そのグループが成長しているか縮小しているか、利用量が重要な行動や成果を反映しているか、ビジネス上の背景によって解釈が変わるかを確認します。

• 機会の規模を見積もります。 重要な各機会がもたらし得る影響の大きさを見積もります。何を比較しているのか、どの指標が影響を表すのか、どの分母または母集団を使うのか、データが信頼に足るだけ十分に揃っているかを明示します。解釈を変える可能性がある、重要でありながら不明または分類されていないグループも、見える状態にしておきます。

• 定量分析を検証可能な状態に保ちます。 クエリと分析の記録には $jupyter-notebooks を使用します。データソースの鮮度、粒度、結合、欠損、スキーマのドリフト、または予期しない分布が信頼性に影響する可能性がある場合は、$analyze-data-quality を使用します。

• 結論を出す前に検証します。 関係者向けの推奨、影響の大きい主張、または予想外の結果を共有する前に、$validate-data を使用します。ダッシュボードと直接クエリの両方が存在する場合は、照合するか、差異の理由を説明します。

5. エビデンスを意思決定への示唆に結び付ける

調査結果を、より広いビジネスの文脈に位置付けます。定量的なエビデンスとビジネスの文脈を、互いに無関係なものとして提示してはいけません。

問いに最も適した意思決定の観点からエビデンスを解釈します。推奨内容を実際に変える観点を選び、ノイズや見せかけの精度を増すだけのものは省きます。一般的な観点は次のとおりです。

• 現在の規模： この機会や問題は、現在の意思決定に影響するほど大きいでしょうか？
• 勢い： シグナルは拡大、縮小、加速しているでしょうか。それとも新たに現れたものでしょうか？
• 広がり： この傾向は広く見られるものでしょうか。それともビジネスの狭い領域に限られるでしょうか？
• 集中度： 結論は、少数の大規模なエンティティ、事象、または外れ値に依存しているでしょうか？
• 強度： 単位あたりの行動は、真のニーズ、価値、またはリスクを示すほど強いでしょうか？
• 効率性： この選択肢は、必要なインプットに対して、より良いアウトプット、利益率、コンバージョン、生産性、または品質を生み出すでしょうか？
• 実行可能性： 利用可能なプロダクト、GTM、運用、ポリシー、または技術的な手段を使って、チームはこの選択肢に現実的に取り組めるでしょうか？
• 差別化： このグループやユースケースには、独自のアプローチ、プロダクト体験、サポートモデル、またはメッセージが必要でしょうか？
• 代替可能性： 行動、支出、時間、または作業負荷が、別の経路から移行する可能性を示すエビデンスはあるでしょうか？
• リスクまたは依存関係： 品質、信頼、コンプライアンス、技術、運用、またはデータ上の制約によって推奨内容は変わるでしょうか？
• カバレッジ： 不明、欠損、またはタグ付けがまばらなレコードは、結論を変えるほど多いでしょうか？

これらはチェックリストではなく、考えるための手段として使います。選んだ観点がこの意思決定に重要な理由を説明し、省略した切り口については、解釈を変える可能性がある場合や、結果の説明に役立つ場合に限って言及します。

測定した機会を使って、意思決定にとって重要な違いと、異なる対応が必要な違いを説明します。ビジネスの文脈から、初期の規模推定では機会のうち実行可能な部分を捉えられていないと分かった場合は、推奨を有用なものにするために必要な、対象を絞った規模推定の切り口を追加します。

エビデンスが食い違う場合は、そのことを明確に述べ、どの解釈がより強く裏付けられているかを説明します。情報源間の不一致を曖昧にしてはいけません。

6. 推奨事項を引き継ぐ

ユーザーがインラインでの回答のみ、チャット内での簡潔な回答、短い回答／成果物なしを明示的に求めた場合、レポート／ファイル／成果物を作成しないよう求めた場合、または別の主要な成果物を選んだ場合を除き、意思決定にすぐ使える推奨事項を $build-report に引き継いで終了します。明示的に人間が免除した場合を除き、この引き継ぎは必須です。ユーザーが直接質問したことや、「レポート」という言葉を使わなかったことを、免除の根拠と解釈してはいけません。このワークフローは分析上の結論を担い、$build-report は読み手に提示する構成、ビジュアル、エビデンスの配置、提供形式を担います。

引き継ぐ前に、推奨事項を明確にします。

• 次に何を信じ、何をすべきか
• エビデンスがその推奨を裏付ける理由
• 重要な留保事項や依存関係
• 信頼度を最も高める追加分析

エビデンスが不完全な場合は、推奨事項が暫定的なものであると明示し、何が分かれば信頼度が変わるかを述べます。回答を断定的に見せるために、結論を誇張してはいけません。

共有前に、方法論、計算、留保事項、または結論を裏付けるエビデンスを確認する必要がある場合は、$validate-data を使います。

結果の表だけでなく、ナラティブを構成する要素もレポートに引き継ぎます。

• 直接的な回答と推奨事項
• 主要なエビデンスとその解釈方法
• 意思決定への示唆
• 未解決の不確実性と留保事項
• 推奨する追加分析