product-management

スキル：プロダクトマネジメント AI

目的

プロダクト要件定義書（PRD）の作成、機能リクエストの分析、ユーザーリサーチの統合、ロードマップの計画、ステークホルダーやエンジニアリングチームへのプロダクト上の決定事項の伝達など、プロダクトマネジメントの中核となる活動を支援します。

このスキルを使用する場面

• 明確な要件、成功指標、技術的な考慮事項を盛り込んだ PRD を作成または更新する必要がある場合。
• 機能リクエストを評価しており、影響度、工数、優先度を体系的に分析する必要がある場合。
• ユーザーリサーチの結果を実行可能なインサイトに統合する必要がある場合。
• ロードマップを計画しており、計画を整理、優先順位付けして伝える必要がある場合。
• エンジニアリング、デザイン、ビジネスのステークホルダーにプロダクト上の決定事項を明確に伝える必要がある場合。
• 競合分析や市場調査の統合を行う場合。
• 意思決定に役立てるため、プロダクト指標を追跡、分析する必要がある場合。

主な機能

単機能の PM ツールとは異なり、次の機能があります。

• コードベースと統合：実際のコード、API、技術的な制約を参照できます。
• コンテキストを認識：特定のプロダクト、アーキテクチャ、技術的負債を理解します。
• 柔軟なテンプレート：組織のニーズに合わせてドキュメントを調整できます。
• バージョン管理：すべての成果物をコードとともに git で管理できます。
• 共同作業に対応：既存の開発ワークフロー（PR、issue、ドキュメント）内で動作します。

入力

• プロダクトのコンテキスト：現状、主要なステークホルダー、戦略目標。
• 機能リクエスト：ユーザーのフィードバック、ビジネスニーズ、戦略的な取り組み。
• 技術的な制約：既知の制限、依存関係、技術的負債。
• ユーザーリサーチ：インタビューのメモ、アンケート結果、分析データ。
• ビジネス目標：最適化の対象となる指標、OKR、成功基準。

対象外

• 最終的なプロダクト上の決定を行うこと（これは PM の役割です。このスキルはその支援を行います）。
• ステークホルダーとの関係や社内政治の管理。
• 詳細な UI/UX デザイン作業（デザインツールを使用し、デザイナーと協力してください）。
• プロジェクト管理やスプリント計画（プロジェクト管理ツールを使用してください）。

規約とベストプラクティス

PRD の構成

優れた PRD には次の項目を含める必要があります。

1. 問題の説明：どのようなユーザーの課題やビジネスニーズに対応するのか？
2. 目標と成功指標：定量的に見て、どのような状態が成功なのか？
3. ユーザーストーリーとユースケース：誰がどのように利用するのか？
4. 要件：優先順位を付けた機能要件と非機能要件。
5. 技術的な考慮事項：アーキテクチャへの影響、依存関係、制約。
6. デザインと UX に関するメモ：主要なインタラクションパターンやデザイン要件。
7. リスクと軽減策：何が問題になり得るか、どのように対処するか。
8. ローンチ計画：段階的な展開戦略、フィーチャーフラグ、モニタリング。
9. 未解決の質問：今後、何を決定または調査する必要があるか。

機能の優先順位付け

体系的なフレームワークを使用して機能を評価します。

• RICE：リーチ × 影響度 × 確信度 / 工数
• ICE：影響度 × 確信度 × 容易さ
• 価値と工数：価値と実装コストを軸にプロットした 2×2 マトリックス
• Kano モデル：機能を基本、性能、魅力的品質に分類

ユーザーリサーチの統合

リサーチ結果を統合する際は、次の点を考慮します。

1. パターンを特定する：参加者全体にどのようなテーマが見られるか？
2. 発言をそのまま引用する：ポイントを説明するため、実際のユーザーの発言を含めます。
3. 可能な限り定量化する：「参加者 10 人中 7 人がそう答えた」など。
4. 調査結果をセグメント化する：ユーザーのタイプによってニーズが異なる場合があります。
5. 指標と結び付ける：定性的な調査結果は定量データをどのように説明するか？

ロードマップの計画

効果的なロードマップには、次の要素が必要です。

• テーマベース：機能のリストだけでなく、戦略的なテーマごとに作業をまとめます。
• 時間軸を設定：Now / Next / Later、または四半期ごとに構成します。
• 成果を重視：アウトプットだけでなく、目標と成果を重視します。
• 柔軟性を確保：学びや調整の余地を残します。
• 明確に伝達：対象者に応じて異なる見せ方を用意します。

必須の行動

1. コンテキストを深く理解する：変更を提案する前に、既存のドキュメント、コード、過去の議論を確認します。
2. 明確化の質問をする：決めつけず、曖昧な要件や目標を明確にします。
3. 具体的で実行可能な内容にする：曖昧な表現を避け、具体的で検証可能な要件を提示します。
4. トレードオフを考慮する：さまざまなアプローチのメリットとデメリットを明確に説明します。
5. 戦略とのつながりを示す：機能や意思決定を、より上位の目標に結び付けます。
6. ステークホルダーを巻き込む：レビューまたは承認が必要な関係者を特定します。
7. エッジケースを検討する：問題なく進むケースだけに注目しないようにします。
8. 測定可能にする：成功を追跡するための具体的な指標を提案します。

必要な成果物

タスクに応じて、次の成果物を作成します。

• PRD ドキュメント：Markdown 形式の包括的な製品要件。
• 機能分析：機能リクエストの構造化された評価。
• 調査結果の統合：ユーザー調査の知見と洞察の要約。
• ロードマップドキュメント：テーマと期間ごとに整理された作業計画。
• 意思決定ドキュメント：主要な製品決定とその根拠の記録。
• 競合分析：競合製品の機能とアプローチの比較。
• 指標の定義：成功指標とその測定方法の明確な定義。

実装チェックリスト

PRD の作成

• 問題領域と戦略的背景を理解する
• 関連するコード、API、技術的制約を確認する
• 主要なステークホルダー（エンジニアリング、デザイン、ビジネス）にヒアリングする
• ユーザーニーズと競合状況を調査する
• 問題の説明と目標を作成する
• ユーザーストーリーとユースケースを定義する
• 機能要件と非機能要件を明記する
• 技術的な考慮事項と依存関係を記録する
• 成功指標と測定方法を定義する
• リスクと軽減策を特定する
• 段階的な展開とローンチ方法を計画する
• ステークホルダーとレビューし、反復する

機能リクエストの分析

• ユーザーの問題またはビジネスニーズを明確にする
• 対象ユーザーとユースケースを特定する
• 影響（影響を受けるユーザー数、ビジネス価値）を見積もる
• 実装の工数と複雑さを評価する
• 依存関係とリスクを特定する
• 製品戦略との整合性を確認する
• 代替案と比較する
• 優先順位スコア（RICE、ICE など）を算出する
• 明確な根拠とともに推奨案を示す

ユーザー調査の統合

• すべての調査資料（文字起こし、メモ、データ）を確認する
• 主要なテーマとパターンを特定する
• 代表的な引用を抽出する
• 必要に応じてユーザーの種類ごとに調査結果を分類する
• 定性的な調査結果を定量データと結び付ける
• 洞察とその意味をまとめる
• 実行可能な提案を作成する
• 影響度に基づいて提案に優先順位を付ける

ロードマップの計画

• 戦略目標と OKR を確認する
• ステークホルダーから意見を集める
• 現状と技術的負債を評価する
• 取り組み候補を戦略的なテーマにまとめる
• テーマと取り組みに優先順位を付ける
• 規模と依存関係を見積もる
• 時間軸（今／次／後）ごとに整理する
• 各取り組みの成功基準を定義する
• 対象者ごとのビューを作成する
• ステークホルダーとレビューし、内容を共有する

ワークフローの例

例 1：新機能の PRD を作成する

# PRD: Advanced Search Functionality

## Problem Statement
Users frequently report difficulty finding specific items in our catalog when they have multiple criteria (price range, location, category, features). Our current search only supports simple text queries, leading to:
- High bounce rates on search results pages (65% bounce rate vs 32% site average)
- Increased support tickets asking for search help (150/month)
- Lost conversion opportunities (estimated $500K annual revenue impact)

## Goals and Success Metrics
**Primary Goal**: Enable users to find relevant items quickly using multiple filters.

**Success Metrics**:
- Reduce search result page bounce rate from 65% to <40%
- Increase search-to-purchase conversion rate by 25%
- Reduce search-related support tickets by 50%
- 70% of users engage with at least one filter within 30 days

## User Stories

### Must Have
1. As a buyer, I want to filter by price range so I can find items within my budget
2. As a buyer, I want to filter by location so I can find items near me
3. As a buyer, I want to filter by category so I can narrow down item types
4. As a buyer, I want to combine multiple filters so I can find exactly what I need
5. As a buyer, I want to see filter counts so I know how many items match before applying

### Should Have
6. As a buyer, I want to save my filter preferences so I don't have to reapply them
7. As a buyer, I want to see suggested filters based on my search query
8. As a buyer, I want to sort filtered results by relevance, price, or date

### Nice to Have
9. As a buyer, I want to create saved searches that notify me of new matches
10. As a buyer, I want to share a filtered search URL with others

例 2：機能リクエストの分析

# Feature Analysis: Dark Mode Support

## Request Summary
**Source**: User feedback (150+ requests in past 6 months), competitive pressure
**Description**: Add dark mode theme option to web and mobile apps

## User Need
Users working in low-light environments report eye strain with current light-only theme. Power users (25% of DAU) spend 3+ hours/day in app and strongly prefer dark mode.

## Prioritization Score

Using RICE framework:
- **Reach**: 750K users = 750
- **Impact**: 8/10 (high for target segment) = 0.8
- **Confidence**: 85% = 0.85
- **Effort**: 7 weeks = 7

**RICE Score**: (750 × 0.8 × 0.85) / 7 = **73.2**

## Recommendation

**Proceed with Option 1 (Full Dark Mode)**

**Reasoning**:
- High impact for large user segment (45% of base)
- Strong user demand and competitive pressure
- Effort is reasonable relative to value
- RICE score above our threshold (>50)
- Aligns with product, technical, and business strategy

一般的な PM 成果物

PRD（製品要件ドキュメント）

何を、なぜ構築するのかを包括的に仕様化したものです。問題の説明、目標、ユーザーストーリー、要件、技術的な考慮事項、リスク、ローンチ計画を含めます。

機能概要

PRD より簡潔な、機能案の主要な詳細をまとめたものです。完全な PRD の作成を決める前の初期段階の検討に使用します。

ユーザー調査の統合

ユーザー調査（インタビュー、アンケート、ユーザビリティテスト）の調査結果を、パターン、洞察、提案とともにまとめたものです。

ロードマップ

時間の経過とともに構築するものをまとめた戦略計画です。テーマと期間ごとに整理し、アウトプットだけでなく、成果を重視します。

意思決定ドキュメント

重要なプロダクト上の決定について、検討した選択肢、決定内容、理由を記録します。組織の知識を蓄積するうえで重要です。

ローンチ計画

機能を展開するための詳細な計画です。各フェーズ、フィーチャーフラグ、メトリクス、モニタリング、ロールバック手順を含めます。

競合分析

競合他社の機能、アプローチ、ポジショニングを比較します。プロダクト戦略の策定や機能の優先順位付けに役立ちます。

ワンペーパー

プロダクト施策のエグゼクティブサマリーです。リーダーシップ層への共有や合意形成に使用します。

AI を活用した PM 業務のベストプラクティス

AI を使って PRD を作成する場合

• プロダクト、ユーザー、技術的な制約について、包括的なコンテキストを提示します。
• 生成された内容を慎重に確認し、編集します。AI は細かなニュアンスを見落としたり、誤った前提を置いたりすることがあります。
• AI は構成や初稿の作成に活用し、人間の判断や関係者からの意見を反映して仕上げます。
• AI が自社のアーキテクチャを理解していると決めつけず、技術的な詳細をエンジニアリングチームに確認します。

AI を使って機能を分析する場合

• 可能であれば、定量データ（利用数、顧客フィードバックの件数など）を提示します。
• 構造化されたフレームワーク（RICE、ICE など）を使い、一貫性と根拠のある分析にします。
• 最終決定を AI に委ねず、考えを整理し、検討事項を洗い出すために活用します。
• AI による分析を、関係者からの定性的な意見や戦略的なコンテキストで補完します。

AI を使って調査結果を統合する場合

• 最良の結果を得るため、書き起こしの全文または詳細なメモを提示します。
• AI にパターンを特定させますが、データを自分で読み返して検証します。
• AI を使って引用を抽出し、テーマを整理します。独自の解釈や示唆を加えます。
• AI に要約しすぎさせないようにします。重要な詳細が微妙なニュアンスの中に含まれていることもあります。

安全性とエスカレーション

• 戦略的な決定：AI は重要なプロダクト上の決定を支援するものであり、決定を下すものではありません。人間の PM や関係者を交えてください。
• ユーザーデータ：適切なデータ取り扱い手順を踏まずに、PII や機密性の高いユーザーデータを AI に入力しないでください。
• 技術的な実現可能性：技術的な前提や工数見積もりは、必ずエンジニアリングチームに確認してください。
• 競合情報：プロンプトに機密性の高い競合情報を含める場合は、慎重に扱ってください。
• トーンと語調：対象読者に合わせてトーンを確認し、調整してください。AI の文章は、堅すぎたりくだけすぎたりすることがあります。

他のスキルとの連携

このスキルは、次のスキルと組み合わせて使用できます。

• データクエリ：プロダクトのメトリクスやユーザー行動データを分析します。
• AI データアナリスト：機能の意思決定に向けて、より詳細な定量分析を実施します。
• フロントエンド UI 連携：PRD で設計した機能を実装します。
• 社内ツール：フィーチャーフラグのダッシュボードやメトリクスビューアーなど、PM 向けツールを構築します。