mcpField
O
outcome-roadmap

outcome-roadmap

github.com/avelikiy生産性10841 回インストール今日更新
リポジトリ

outcome-roadmap について

機能中心のロードマップを、顧客価値と事業への影響を明確にする成果中心の記述へ変換するプロダクト管理スキルです。ロードマップを作成・改善するチームや PM エージェント向けです。

主な機能

  1. 01機能を顧客と事業の成果に書き換え
  2. 02成果記述の定型式を適用
  3. 03成果を戦略テーマ別に分類
  4. 04指標と戦略目標との整合性を確認
  5. 05成果を PM のタスク計画に反映

活用シーン

  1. 01機能ロードマップを成果記述に変換
  2. 02計画中の取り組みに測定可能な目標を追加
  3. 035件以上の成果をテーマ別に整理

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/avelikiy/great_cto --skill outcome-roadmap

インストール後、Claude Code で/outcome-roadmapを入力して読み込まれたか確認します。

詳細

成果ロードマップ — 機能から成果へ

機能中心のロードマップを、成果中心のロードマップに変換します。

基本原則： チームは機能を作りますが、顧客やビジネスが重視するのは成果です。成果ロードマップでは、何を作るかではなく、何が変わるかを伝えます。

変換の公式

ロードマップ上の各取り組みに、次の公式を適用します。

Enable [customer segment] to [desired customer outcome] so that [business impact]

例：

アウトプット（従来）成果（新）
Q2：高度な検索フィルターを構築Q2：直感的な検索機能により、顧客が商品を見つける時間を50％短縮
Q2：AI レコメンデーションQ2：パーソナライズされたレコメンデーションにより、平均注文額を20％増加
Q3：ダッシュボードを再設計Q3：ダッシュボードに費やす時間を80％削減し、オペレーターがすべてのシステムを監視できるようにする
Q3：SSO 連携Q3：エンタープライズ管理者の認証に関する障壁を取り除き、エンタープライズ案件を3件以上成約
Q4：モバイルアプリQ4：ユーザーがモバイルで主要なワークフローを完了できるようにし、7日間の継続率を20％から35％に向上

適用方法

ステップ 1 — 既存のロードマップを読む

ユーザーがロードマップのファイルを提供した場合は、それを読みます。口頭で説明された場合は、取り組みの一覧を抽出します。

各取り組みについて、内部で次の点を確認します。

  • どの機能／プロジェクトが予定されていますか？
  • なぜそれを構築するのでしょうか？顧客やビジネスにどのような変化をもたらしますか？
  • どの指標が、どの程度改善しますか？
  • 同じ成果を達成する、より良い別の方法はありますか？
ステップ 2 — 各取り組みを成果として書き換える

ロードマップの各項目について、次の手順で進めます。

  1. アウトプットを特定する：どの機能やプロジェクトが予定されていますか？
  2. 成果を明らかにする：なぜそれを構築するのでしょうか？実際の顧客価値やビジネス価値にたどり着くまで、「それで何が変わるのか？」と問い続けます。
  3. 書き換える：上記の公式を使います。可能であれば指標を含めます。

「それで何が変わるのか？」の連鎖の例：

  • 「検索フィルターを追加します」→ それで何が変わるのか？
  • 「ユーザーが検索結果を絞り込めます」→ それで何が変わるのか？
  • 「ユーザーが探しているものをより早く見つけられます」→ それで何が変わるのか？
  • 「ユーザーが離脱する前に商品を見つけられるため、コンバージョン率が上がります」✅ これが成果です。
ステップ 3 — 戦略テーマごとに分類する（任意）

ロードマップに5項目以上ある場合は、関連する成果をテーマごとにまとめます。

  • 継続率（解約を減らす成果）
  • 獲得（コンバージョンを改善する成果）
  • 収益化（ユーザーあたりの収益を増やす成果）
  • 運用効率（社内コストや所要時間を削減する成果）
ステップ 4 — 出力形式
## Outcome Roadmap — <Product> <Quarter/Year>

### Strategic context
<1–2 sentences on what the team is optimising for this period>

### Q<N> Outcomes

| Initiative | Outcome Statement | Primary Metric | Target |
|------------|------------------|----------------|--------|
| <original feature name> | Enable [segment] to [outcome] so that [business impact] | <metric> | <target> |

### What we're NOT doing this quarter (and why)
- <deprioritised initiative>: <reason — not enough signal / too early / wrong priority>

### Key assumptions
- <assumption this roadmap depends on — if it's wrong, the outcomes change>
ステップ 5 — 検証する

提示する前に、次の点を確認します。

  • すべての成果に測定可能な要素（％、数値、比率、頻度）が含まれている
  • すべての項目に「それで何が変わるのか？」を適用し、純粋な機能説明が残っていない
  • 「実施しないこと」を少なくとも1つ示している。そうでなければ、スコープに際限がありません
  • 成果が PROJECT.md に記載された OKR または戦略目標と一致している

アンチパターン

❌ 「Xを構築します」 — これはアウトプットであり、成果ではありません。

❌ 「UXを改善する」 — 測定できません。次のように書き換えます：「チェックアウトの完了時間を4分から90秒に短縮する」。

❌ 指標のない成果 — 測定できなければ、達成したかどうかもわかりません。

❌ 特定のソリューションの構築が前提となる成果 — 「モバイルアプリ経由でユーザーが機能にアクセスできるようにする」では、ソリューションが固定されます。より良い表現は、「ユーザーがあらゆるデバイスで主要なワークフローを完了できるようにする」です。

pm エージェントとの連携

pm エージェントが PRD のない機能リストを受け取った場合：

  1. リストがアウトプット（機能名）に見えるか、成果（結果を示す文）に見えるかを確認します
  2. アウトプットの場合は、タスクに分解する前にこのスキルを適用して変換します
  3. 成果の記述を PLAN ドキュメントに渡し、各タスクグループの「理由」として記載します

コメント

Markdown 対応