design-kpis

KPI の設計

チームがプロダクトやビジネスに関する意思決定を行うために役立つ、KPI フレームワークの設計、目標の設定、測定計画の策定を行います。

先にデータ品質を確認する場合

既存の指標、ダッシュボード、テーブル、担当者、または信頼できる情報源を整理するタスクでは、まず $analyze-data-quality を使用してください。

今後の指標の定義、KPI フレームワークの再設計、ガードレールの選定、または目標の設定をユーザーが依頼した場合に限り、このスキルに戻ってください。

スキルの設定

情報源の発見と検証

関連するセマンティックレイヤーは出発点として使用し、範囲を限定するものとして扱わないでください。

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

情報源へのアクセスに関するガードレール

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

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

不足している情報源が任意の補足にすぎない場合は、利用可能な中で最も強い根拠を使って続行し、回答に重大な影響がある場合は、その不足を明記してください。

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

ワークフロー

1. 意思決定と運用の状況を明確にする

指標がどのような意思決定を支援する必要があるのか、どのような状況でレビューされるのか、結果を受けて誰が行動するのかを把握します。目標、運用の頻度、または測定上の制約について、入力の不足や曖昧さが推奨内容を変える場合は、ユーザーに確認してください。

2. 指標を推奨する前に根拠を集める

成功の定義を把握するのに十分な情報がプロンプトに含まれていない場合は、指標や目標を推奨する前に状況を把握します。$gather-business-context を使用して、目標、現状、対象者、制約、リスク、既存の定義、過去の意思決定、および指標体系の設計に影響するベースラインや目標に関する情報を把握します。

KPI の設計では、こうした情報を使って、成功の意味、関連指標がこれまでどのように定義されてきたか、そして推奨する KPI、ドライバー、ガードレール、測定計画にどのような制約やリスクを反映すべきかを明確にします。

3. より広範な候補を作成する

候補を絞り込む前に、成果、ドライバー、ガードレールの指標候補を作成します。 各候補には明確な定義と、意思決定との妥当な関連性が必要です。参考になる場合は、以下の指標の例をヒントとして使い、必須のテンプレートとはみなさないでください。

4. 指標を比較して選定する

候補となる指標を、以下の観点から比較します。

• 目標を反映しているか：指標は意図した成果を表す必要があります。代理指標を使う場合は、実際の進捗を反映するはずだと考える理由と、誤解を招く可能性のある点を説明します。
• 実際の意思決定に役立つか：指標の変化によって、チームの行動、優先順位、調査対象が変わる必要があります。
• 意思決定の頻度に合った有用なシグナルを示すか：概念上は優れた指標でも、それを用いる意思決定に対して変化が遅すぎたり、ノイズが多すぎたりする場合があります。たとえば、年間継続率は適切な成果指標でも、より早い指標と組み合わせない限り、週次のローンチレビューには役立たない可能性があります。
• チームが影響を与えられるか：チームが現実的に活用できる手段があるか、またはチームが影響を与えられる要因と組み合わせられる必要があります。
• 運用上、測定可能か：一度限りの手作業に頼らず、一貫して計測の仕組みを整え、算出し、追跡できる必要があります。
• 誤解を招く形で改善しにくいか：指標を改善した結果、品質、信頼、継続率、コスト、その他の重要な成果への悪影響が明らかに覆い隠されるようではいけません。

トレードオフを説明するのに役立つ場合に限り、簡易的なスコアリングを使います。主要 KPI は 1-3 個を推奨し、診断に役立つ場合は各 KPI に対して要因指標を 1-2 個、トレードオフが予想される場合はガードレールを 1-2 個推奨します。意思決定の質を実質的に高めない限り、指標を追加で推奨しないでください。

推奨する指標ごとに、チームが活用できるだけの詳細を含めます。測定対象、重要である理由、算出方法、データの取得元、上記の選定基準に照らした主な長所と短所、注意点や必要なガードレールを説明します。

5. 必要に応じて目標を設定する

目標設定は、指標選定とは別の判断として扱います。まず測定対象を決め、その後、ユーザーから求められた場合、または推奨を有用にするためにしきい値が必要な場合に目標を設定します。

根拠に最も適した目標設定のアプローチを使います。

• トップダウン：ベンチマーク、過去の実績、類似製品、競合や市場の状況、または意思決定において「良い」状態がどのようなものかについての合理的な見解から始めます。
• ボトムアップ：何をリリースするか、導入がどのように進むと予想されるか、どの運用上の施策で指標を動かすべきかなど、チームが現実的に実行できることから始めます。

データを使って目標を設定、または評価します。目標設定のアプローチが明確になったら、必要となるデータを特定します。たとえば、提示された入力情報、社内の実績データ、外部のベンチマークや市場データ、過去の類似施策の結果などです。

意欲的な目標と、計画済みの作業、利用可能な対象者、予想される導入、過去の変化を通じてチームが現実的に影響を与えられる範囲を比較します。適切な目標は意思決定にとって意味があり、行動の指針となるだけの妥当性も備えている必要があります。目標の根拠となる基準、主な前提、確信度を説明します。最も有力な目標設定手法に必要な情報が不足している場合は、手法を共有し、関連データを提示または特定できるかユーザーに確認します。方向性を示すのに十分な根拠がある場合は、暫定的な範囲として提示します。そうでない場合は、確定的な目標を設定する前に必要な測定を提案します。

6. 推奨事項の提示

最終的な推奨事項は、簡潔で意思決定に役立つ内容にまとめ、原則としてその場で提示します。KPI フレームワークで根拠の使用や候補の比較が必要な場合、または指標が複数含まれる場合でも、それだけを理由に $build-report を読み込まないでください。提案する目標を過去の実績やベンチマークと比較して示す場合や、トレードオフや候補のスコアリングを明確にする場合など、データのビジュアル化によって回答が大きく改善されるときは、$visualize-data と $build-report を使用してください。レポート、ダッシュボード、ノートブック、スプレッドシート、ネイティブドキュメント、スライドデッキが明示的に求められた場合は、それを主な成果物として提示してください。推奨事項には以下を含めてください。

1. 取り組みの概要
2. 推奨する指標候補と、その定義および推奨理由
3. 目標を含める場合は、その推奨値、基準、前提、算出方法
4. 確認した根拠
5. 前提と不足しているコンテキスト
6. リスクとガードレール
7. 未解決の質問

指標の例

状況によって、適切な指標の形は異なります。以下は例として参考にしてください。テンプレートとして使う必要はありません。

• 製品のローンチまたは利用促進：利用拡大や価値実現を示す成果指標に、アクティベーション、エンゲージメント、リピート利用、価値実現までの時間を示すドライバーと、ユーザー体験の品質を守るガードレールを組み合わせます。
• 成長に関する取り組み：チームが改善を目指すビジネス成果（アクティベーション、リテンション、収益化など）を選び、成長がどのように実現すると見込まれるかを説明するドライバーと、品質を守るガードレールを加えます。
• ファネルに関する取り組み：成功を表す進行または完了の成果を選び、ユーザーの進行や離脱が発生する箇所を示すドライバーと、下流工程の品質を守るガードレールを加えます。
• 運営レビュー：健全性、進捗、アクションにつながる指標に焦点を当て、事業が計画どおりに進んでいるか、どこに注意が必要かを示します。
• 実験または介入：意思決定に結び付いた主要な成功指標を 1 つ設定し、変化の理由を説明する診断指標と、意図しない影響を防ぐガードレールを加えます。
• データ、モデル、分析に関する取り組み：技術的なパフォーマンスを、それによって改善される意思決定やワークフローに結び付け、関連する場合は利用状況、信頼性、コスト、公平性に関するガードレールを加えます。
• プラットフォーム、信頼性、運用に関する取り組み：担当チームが対応できる形で、サービスの健全性、処理能力、品質、コスト効率、顧客への影響を測定します。