kpi-reporting

KPI レポーティング

このスキルを使って、ビジネス指標やプロダクト指標を、リーダーやチームが意思決定に活用できる運用レポートにまとめます。KPI の定義を明確にし、適切な比較対象や目標に照らして状況を報告し、検証済みの要因に関する情報を盛り込み、運用上の示唆を明確に伝えることが目的です。

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

このスキルが担当するのは KPI のレポートです。何を報告するか、指標をどう解釈するか、要因に関する情報が検証済みか、そしてどのような運用上の結論が導かれるかを扱います。指標システムの設計、新たな要因の調査、最終成果物の仕上げは担当しません。

新たな要因の調査が必要な場合は、$metric-diagnostics を使ってから、検証済みの知見をまとめるためにこのスキルに戻ってください。

スキルの設定

ソースの探索と検証

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

1. 考えられるすべてのソースを調べます。 タスクに関連するデータや解釈を変えうる情報を含む可能性のある、接続済みまたは提供済みのすべてのソースを検索してください。構造化データソースごとに、関連するスキーマ、データセット、テーブル、ビュー、モデル、指標について、カタログまたはメタデータを新たに探索してください。既知のソース、テーブル、ダッシュボード、セマンティックマッピングは出発点であり、探索を終える場所ではありません。
2. 重複や矛盾を比較します。 ソースの内容が重複または不一致の場合は、管理主体、鮮度、定義、粒度、対象範囲、情報の直接性を比較してください。最も信頼できるソースを使うか、必要に応じて相互補完するソースを組み合わせてください。重要な矛盾があれば明記し、選択したソースが回答の根拠となる理由を説明してから、ライブ読み取りで選択したデータを検証してください。

ソースアクセスのガードレール

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

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

不足しているソースが任意の補足情報にすぎない場合は、利用可能な中で最も強い根拠を使って進め、その不足が回答に大きく影響する場合は明示してください。

ワークフロー

1. レポートの目的を明確にする

下書きを作成する前に、対象者、レポートが支援する議論、報告内容を把握してください。評価対象の期間、実績を解釈可能にする比較対象または目標、データの鮮度の基準時点を明確にして、更新内容の軸としてください。

レポートの正確性や有用性を高めるために必要な情報が不足している場合は、ユーザーに確認してください。

2. 指標の枠組みを定義する

数値を取得する前に、どの指標をレポートに含めるか、それぞれがどの役割を担うかを決めてください。既存の枠組みがある場合は、内容を確認して使用してください。枠組みがない、または不十分な場合は、報告の前に $design-kpis を使用してください。

主要 KPI から始め、状況を説明するために必要最小限の補助指標を追加します。補助指標は、変動の説明、有害なトレードオフの回避、または実績が想定どおりのペースで推移しているかの確認に役立ちます。

対象者にとって最も重要な指標を先に示してください。利用可能な切り口や比較対象をすべて追加するのではなく、意思決定者が実際に使う指標や切り口に加え、今回の更新内容を説明するうえで重要なものだけを含めてください。

主要 KPI がトップライン指標、複合指標、またはその他の理由で直接アクションにつながらない指標である場合は、その解釈の前に要因の分解を定義してください。利用可能であれば、既存のメトリックツリーを使ってください。ない場合は、分子と分母、ボリュームと率、構成比、ファネルの各段階、セグメント、コホート、業務上の入力値など、有用な構成要因を必要最小限に絞って特定してください。ソースの定義で裏付けられない因果関係の階層を作り出さないでください。

3. 指標の定義と情報源を固定する

パフォーマンスを解釈する前に、KPI の定義、情報源、対象期間、報告締め日、比較期間、目標や進捗ペースの想定を確認します。目標や進捗ペースの基準が不明な場合は、それを確定情報として扱う前に確認してください。情報源の品質に問題があり、報告する指標が変わる可能性がある場合は、$analyze-data-quality を使用してください。

すべての KPI 更新では、下書きを作成する前に、~~structured_data、~~company_docs、~~team_communication、~~dashboards_or_bi を対象に、焦点を絞って情報源を確認します。プロンプトの情報が少ないからといって、情報源に裏付けられた実績が得られないと推測しないでください。実績、指標の定義、比較期間には構造化データを使用し、その他の情報源は、追加のビジネスコンテキストや信頼できる情報源に関するガイダンスの確認に使用します。

中核となる定義が不明確な場合は、正確な主張をする前にユーザーに確認してください。指標の定義が変更されている場合は、可能であれば比較可能な過去の実績を改訂して示します。それができない場合は、変更による断絶を明確に説明してください。

4. 主要な実績を取得する

プレースホルダーのまま WBR、MBR、スコアカード、KPI 更新を作成したり、表示したりしないでください。まず、接続されている構造化データソースを照会または確認し、中核となる実績を取得します。実績を取得できない、または不十分な場合、ユーザーがテンプレートやモックアップを明示的に求めていない限り、そこで作業を止め、必要な情報源やアクセス権を伝えてください。

変動や要因の背景を説明する前に、主要な実績をそのまま示してください。

各主要 KPI について、現在値、比較期間に対する絶対変化と相対変化、簡潔な解釈を含めます。

追跡方法の変更、データの遡及補完、一部停止、データの欠落日など、現在値と前期間の値を比較しにくくする要因がある場合は、変動を解釈する前に明示してください。

5. 数値を文脈に沿って示す

実績を解釈可能にする文脈と照らし合わせてください。目標、計画、進捗モデル、ベンチマーク、過去の範囲、関連するピアグループが定義されている場合は、それを明示し、状況を評価する前に実績と比較します。

目標に期限がある場合、指標が目標を上回っているか下回っているかだけを報告しないでください。期間終了時に目標を達成するペースにあるかどうかを示します。定義済みの進捗ペースがある場合は、それを使用してください。定義がなく、見つからない場合はユーザーに確認します。計算による代替手法で進める場合は、計算したことを明記し、方法を説明してください。

有用な場合は、目標に対する絶対値とパーセントの差異、および赤・黄・緑のステータスを示します。ステータスラベルがどの比較基準または進捗ペース基準に基づくかを明確にしてください。

6. 検証済みの要因を説明する

KPI の更新には要因の背景が必要ですが、要因に関する主張は説明として提示する前に検証する必要があります。もっともらしい説明だけでは不十分です。

報告で要因の説明が必要な場合は、$metric-diagnostics を使用して要因を特定し、検証してください。信頼できる報告や過去の分析ですでに要因が検証されている場合は、診断をやり直さず、その証拠を使用してください。

7. ビジネスコンテキストと業務上の示唆を加える

考えられる要因を特定した後、$gather-business-context を使用して、何が起きたのか、報告にとってどのような意味があるのかを説明するのに役立つビジネスコンテキストを探します。要因分析を手がかりに探すべきコンテキストを決め、そのつながりが証拠で裏付けられる場合に限り、コンテキストを指標と関連付けてください。

証拠、要因分析、ビジネスコンテキストを、事業にとっての業務上の示唆に結び付けてください。変動が懸念事項か、次に必要な手順や対応は何か、主要 KPI が計画どおりか、リスクがあるか、計画を上回っているかを示します。証拠に裏付けられている場合に限り対応を推奨し、そうでない場合は次に行う検証手順を明示してください。

8. 報告内容を検証する

分析をまとめた後、最終的な報告形式に整える前に、$validate-data を使用し、数値、手法、留保事項、証拠が、主張するステータス、要因、示唆を裏付けているかを確認します。重要な問題は共有前に解決し、残る制約は報告内容に明記してください。

9. 読み取り結果を引き継ぐ

ユーザーがインラインでのチャットのみの簡潔な回答や成果物なしの回答を明示的に求める場合、レポート／ファイル／成果物を作成しないよう依頼する場合、または別の主要な成果物を選択する場合を除き、検証済みのKPI読み取り結果を$build-reportに引き継いでください。簡単な状況報告、簡潔な読み取り結果、チャットでの調査結果の提示は、ユーザーがレポート、ドキュメント、スライド資料、または永続的な成果物も求めていない限り、インライン出力の選択とみなします。人間から明示的な免除の指示がない場合、レポートへの引き継ぎは必須です。ユーザーが「レポート」という言葉を使わなかったことだけを理由に、免除を推測してはいけません。

引き継ぐ前に、読み取り結果を明確にしてください。

• 主なステータスと業務上の示唆
• 実績、目標、ペースの算出基準、比較対象期間
• 検証済みの要因と未解決の不確実性
• 把握できている場合は、対象読者、頻度、希望する配信先
• 読み取り結果を分かりやすくするチャートや図表

引き継ぐ前にreferences/report-templates.mdを読み込み、一致するパターンを$build-reportに渡すソースノートとして使用してください。これがKPI読み取り結果であることを$build-reportに伝え、上記のステータス、ペース、要因、不確実性、対象読者、頻度、配信先、視覚化に関する指針を渡してください。このスキルからチャートを直接作成してはいけません。視覚化の意図と裏付けとなる根拠を$build-reportに渡し、チャートの選定と品質確認は$visualize-dataに任せてください。

ネイティブのスライドやスライド資料を求められた場合は、まず$build-reportを使用してHTMLレポートを作成してください。$report-to-google-slidesは既存のローカルHTML分析レポートを利用し、実行中のMCPアプリのレポートを直接変換できないためです。その後、そのHTMLレポートに対して$report-to-google-slidesを実行してください。MCPアプリのレポートしかない場合は、変換前に、同じソースとなる根拠からHTMLレポートを作成し、別の配信形式として用意してください。

基準

指標の基準

• 定義、ソース、時間範囲、比較基準が不明確な場合、KPIを正確な値として提示してはいけません。
• 解釈に影響する場合は、計算ロジック、対象に含める／除外するルール、粒度、時間の扱いを明示してください。
• 可能な場合は合計値を照合し、前回の報告と比較してください。
• 定義上、互換性のない期間、区分、目標を比較してはいけません。定義の変更、遡及修正、分母の変化、カレンダー上の影響が推移に影響する場合は、その点を明記してください。

ステータスとペースの基準

• ユーザーがより限定的な読み取り結果を求めない限り、主な要点、現在の実績、関連する比較、目標またはペースの状況、要因の概要、示唆を含めてください。
• 利用できる場合は、実績を目標、計画、ベンチマーク、または基準値と並べて示し、読み手がすぐにパフォーマンスを判断できるようにしてください。
• 目標に期限がある場合は、提示されたペースの定義、または算出方法を明記した代替基準を用いて、現在のパフォーマンスがペースどおりかどうかを示してください。
• 実行のたびに、定期的な指標セクションの構成を一貫させてください。データ、定義、または検証が不足しているために求められたセクションを含められない場合は、その理由を簡潔に説明してください。
• 優先すべき対応の判断に役立つ場合に限り、信号機式のステータスを使用してください。色にはテキストを添え、ステータスの根拠を示してください。
• 数値の丸め方を統一し、単位を明記してください。解釈を変える注意点があれば、併せて示してください。

ドライバーに関する基準

• 根拠がある場合は、ドライバーを定量化します。影響の規模を示す代わりに、説明的な文章で済ませてはいけません。
• KPI の変動を解釈するうえで重要な、少数のドライバー、寄与要因、または影響していないと判明している要因を報告します。
• トップライン KPI の変動については、検証済みのドライバーを簡潔な分解として示します。トップラインの実績、構成要因、最大の寄与要因または影響していない要因、残差または未解明の変動を含めます。構成要因がきれいに整合する場合に限り、加算型のブリッジを使用します。それ以外の場合は、関係性と不確実性を説明します。
• 検証済みのドライバーと、事業上の背景情報や仮説を区別します。
• 発生時期、影響を受けた対象者、および測定された変化によって関連性が裏付けられない限り、事業上の出来事を原因として扱いません。
• 変動が広範囲に及ぶのか、特定の領域に集中しているのかによって運営上の判断が変わる場合は、その点を明示します。
• ドライバーの根拠が未解明のままなら、説明を作り上げるのではなく、不確実性や追加調査の内容を示します。

表現に関する基準

• 斜め読みする経営幹部や現場担当者に向けて、まず結論を示し、その後に根拠を述べます。
• 123k (+8% w/w, +19% m/m) のような、業務で読み取りやすい数値と簡潔な形式を使います。
• strong、healthy、soft などの一般的な形容詞は、それらを裏付ける指標の数値に置き換えます。
• 留保事項は影響する主張の近くに記載し、解釈に影響しない留保事項は省きます。
• グラフ、表、スコアカード、KPI カードは、要点を理解しやすくし、最終的な提供環境でも読みやすさを保てる場合に限り使用します。