metric-diagnostics

関連スキル

ビジネスの背景を把握することで、指標、分析期間、担当、または妥当な説明を理解できる場合は、$gather-business-context を使用します。

変化を診断した後に推奨事項やトレードオフの判断を求められた場合は、$product-business-analysis を使用します。

ダッシュボードの信頼性、粒度、鮮度、またはデータソース間の不一致が指標に影響する可能性がある場合は、$analyze-data-quality を使用します。

指標の診断

指標が変化した理由や、想定と異なる理由を診断するために、このスキルを使用します。指標を再現し、比較条件を定義し、変化の大きさを定量化して、考えられる要因を検証し、検証済みの内容、可能性の高い内容、未解決の内容、次に役立つ対応を示します。

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

スキルの設定

データソースの発見と検証

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

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

データソースへのアクセスに関するガードレール

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

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

不足しているデータソースが任意の補足情報にすぎない場合は、利用可能な中で最も強い根拠に基づいて続行し、その不足が回答に大きく影響する場合は、その点を明記します。

ワークフロー

1. 診断する問いを定義する

何が変化したのか、どのような比較によってそれを裏付けられるのかが明確になるよう、診断の枠組みを定めます。

以下を定義します。

• 指標がビジネス上何を意味するか
• 変化を測定可能にする期間と比較条件
• 集計対象を決める母集団と粒度
• 指標の定義を管理するデータソース
• 変化、偏り、照合など、答えるべき診断の問い

指標の意味、分析期間中に起きた変化、または考えられる説明を理解するためにビジネスの背景が必要な場合は、$gather-business-context を使用します。

2. 指標の定義とソースを検証する

変動を説明する前に、指標が正しく定義されていることと、ソースデータで信頼性の高い測定ができることを確認します。

指標の定義、粒度、集計ロジック、フィルター、結合、除外条件、鮮度、リネージュ、および信頼できる各サーフェス間の不一致を確認します。このソース確認は、回答が変わり得る問題に絞ってください。

現在のコンテキスト、名前の付いたセマンティックレイヤー、見慣れたテーブル名はソース候補として扱い、ソースの選定根拠にはしないでください。幅広い指標に関する質問では、どのソースを基準にするかを選ぶ前に、利用可能なテーブル、ダッシュボード、指標ドキュメント、セマンティックレイヤー、その他の信頼できる情報源を対象に、ライブでソースを探索します。両方を利用できる場合は、少なくとも1つのビジネス向けまたはトップラインのサーフェスと、1つの低レベルのソースサーフェスを調べ、選んだソースを回答の基準とする理由を述べます。

鮮度、粒度、結合、欠損、スキーマドリフト、外れ値、予期しないカテゴリ、または分布の変化が信頼性に影響する可能性がある場合は、$analyze-data-quality を使います。

新しい SQL、Python、統計モデリング、再利用可能な計算、または複数ステップの分解について、検証可能な分析記録が必要な場合は、$jupyter-notebooks を使います。

3. 指標のパターンを確立する

要因を調べる前に、診断で説明すべき指標のパターンを確立します。対象期間と範囲にわたる指標を定量化します。質問に比較が含まれる場合は、その比較を再現します。

パターンの規模、タイミング、範囲を検証するか、明示的に不確実として示すまでは、原因を探さないでください。

4. 診断計画を選ぶ

パターンの説明、または確信を強めるために必要な、最小限の切り口と確認項目を選びます。

指標の運用ロジック、ビジネスコンテキスト、ソースの形状に基づいて、要因となるディメンションを選びます。ソースにあるすべてのフィールドではなく、ビジネスで通常監視されている、または対処可能な要因を優先します。関連する要因が不明な場合は、現在のコンテキスト、名前の付いたセマンティックレイヤー、または $gather-business-context を使って、ビジネスが指標をどのように説明しているか、分析期間の前後に何が変わったかを把握します。

低レベルのテーブルを使う場合、要因分析を最初のクエリで表面化したフィールドに限定しないでください。モデルファミリー、モデルのスーパーファミリー、セグメント、地域、コホート、製品分類体系、顧客階層など、質問に答えるために必要なビジネス上のグルーピングを再現するか、結合します。グルーピングを再構築できない場合は、分析を簡略化する前にその旨を伝えます。

質問に適した説明モードを使います。一般的な例を次に示します。

• 指標の変化：対象期間とベースラインを比較し、セグメント別の寄与度を順位付けし、同業または過去の状況と照合して、構成の変化とセグメント内の変動を検証します。
• 急増、回帰、またはインシデント：発生時点、ピーク、回復、平均だけでなく分布の形状、影響を受けたスライス、広範な悪化か局所的な悪化か、トラフィックや障害の挙動に変化があったかを特定します。
• 最大の寄与要因または集中度：「最大」の定義を定め、エンティティを順位付けし、全体に占める割合と変化を比較して、大きく変動した項目、新たに加わった項目、なくなった項目を調べます。
• 照合または差分分析：定義、フィルター、粒度、分子、分母、除外条件を揃えます。差を説明する要素を定量化し、残差があれば明示します。

5. ドライバーを分解して検証する

主なドライバーを定量化し、そのパターンを説明できるか検証します。

主要な各ドライバーの規模を、すぐに入手できる最も有力な根拠に基づいて示します。そのドライバーがパターンを説明できるか、関連するベース、トレンド、またはギャップと比べてどの程度の大きさか、広範に見られるのか特定の箇所に集中しているのか、適切な比較または対象範囲でも当てはまるのかを明らかにします。

ビジネスにとって意味のある形で「なぜ」を説明できるまで、ドライバーの仮説を検討します。有望な切り口や掘り下げによって重要な説明が見つかる可能性がある場合は追究し、追加の切り口によって結論が変わる可能性や確信度が大きく高まる可能性が低くなった時点で止めます。

ドライバーの結果は、文脈に沿って解釈します。

• 関連するベース、比較対象、または全体に占める割合を使って、ドライバーの意味を明確にします。
• 率については、分子、分母、またはその両方のどれが変化を説明するのか確認します。
• 加算可能な指標では、説明が明確になる場合に寄与率を算出します。
• その区別によって説明が変わる場合は、構成の変化とセグメント内の実績変化を分けて示します。
• 加算可能な寄与を解釈する必要がある場合は、相互に重複しないドライバーの区分を優先します。分解結果を正確に整合させるか、残差の規模を示して説明します。

測定上の問題は、単なる後処理の詳細ではなく、考えられる説明として扱います。たとえば、そのパターンは根本的なビジネスの変化ではなく、ログ記録の変更、直近データの不完全さ、重複行、または分母の変化によるものかもしれません。

根拠に応じて説明の確度を調整し、重要な不確実性を明示します。そのパターンが通常なのか、異例なのか、予想されたものなのか、既知の変更に関連するものなのかなど、解釈が変わる場合は文脈を示します。

グラフを使うと診断上の主張が理解しやすくなったり、検証しやすくなったりする場合は、$visualize-data を使用します。

6. 示唆と次の対応を述べる

診断上の問いへの答えを最初に示し、根拠がある場合は実務上の示唆を述べます。

回答では、次の点を明確にします。

• 説明対象となるパターン
• 最も有力なドライバーの説明と、それを裏付ける根拠
• それがビジネスにとって重要な理由
• その説明にどの程度の確信を置けるか
• 最も重要な示唆、次の対応、またはフォローアップ

診断上の示唆だけでなく、推奨やトレードオフの判断が必要な場合は、$product-business-analysis を使用します。

読者が根拠の範囲と解釈の開始点を見分けられるよう、示唆と検証済みの事実報告は明確に区別します。時期が重なったという理由だけで因果関係を主張せず、説明が妥当性のある仮説にとどまる場合はその旨を示します。

指標の結果は明確でも、「それで何を意味するのか」の解釈や現実的な次の対応の特定にビジネスの文脈が必要な場合は、$gather-business-context を使用します。

診断上の結論を共有する前に、方法論、計算、注意事項、または根拠の裏付けを確認する必要がある場合は、$validate-data を使用します。

成果物やレポートの検証を分析の妥当性検証として扱ってはいけません。引き継ぐ前に、分析に主要指標の変動、ドライバーの寄与率または効果の大きさ、ソースと期間の整合性、クエリを使用した場合は実行した正確な SQL またはクエリへの参照、解釈を変えうる注意事項が含まれていることを確認します。

ユーザーがインラインのチャットのみの簡潔な回答や成果物なしの回答を明示的に求めた場合、レポート、ファイル、成果物の作成を求めない場合、または別の主要な成果物を選んだ場合を除き、診断内容と裏付けとなる根拠を $build-report に渡します。明示的に人間が免除を指示していない場合、この引き継ぎは必須です。ユーザーが直接的な診断の質問をした、または「レポート」という言葉を使わなかったという理由で、免除を推測してはいけません。レポートの構成、見せ方の仕上げ、再現性の扱い、共有時の引き継ぎは $build-report に任せます。