このスキルは、Droidがプロダクト管理アシスタントとして機能し、PM役割の中核となる文書化、分析、計画立案活動を支援することを可能にします。特化型PMツールとは異なり、このスキルは開発ワークフロー、コードベース、文書と直接統合されます。Documentation Index
Fetch the complete documentation index at: https://factory-docs-auto-sync-jp-docs.mintlify.app/llms.txt
Use this file to discover all available pages before exploring further.
セットアップ手順
このスキルをFactoryで使用するには、リポジトリ内に以下のディレクトリ構造を作成してください：.factory/skills/product-management/
├── SKILL.md
├── prd-template.md (任意)
├── feature-analysis-framework.md (任意)
└── user-research-templates.md (任意)
クイックスタート
-
スキルディレクトリを作成:
mkdir -p .factory/skills/product-management -
以下のスキルコンテンツを
.factory/skills/product-management/SKILL.md（またはskill.mdx）にコピー
FactoryにPRD、機能分析、ロードマップ計画、リサーチ統合の支援を依頼すると、タスク説明に基づいてこのスキルが自動的に呼び出されます。
スキル定義
以下のコンテンツを.factory/skills/product-management/SKILL.mdにコピーしてください：
---
name: product-management
description: PRD作成、機能分析、ユーザーリサーチの統合、ロードマップ計画、プロダクト意思決定の伝達など、中核的なプロダクトマネジメント活動を支援します。コードベースと連携するPMドキュメント、分析、計画ワークフローの支援が必要な場合に使用します。
---
# スキル: プロダクトマネジメント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**: Reach（リーチ） × Impact（影響） × Confidence（信頼度） / Effort（工数）
- **ICE**: Impact（影響） × Confidence（信頼度） × Ease（容易さ）
- **Value vs. Effort**: 価値と実装コストを2×2マトリクスで比較
- **Kano Model**: 機能を基本品質、性能品質、魅力品質に分類
### ユーザーリサーチの統合
リサーチを統合するときは:
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を確認する
- [ ] ステークホルダーからインプットを集める
- [ ] 現状と技術的負債を評価する
- [ ] 可能性のある作業を戦略テーマにまとめる
- [ ] テーマと取り組みを優先順位付けする
- [ ] 規模と依存関係を見積もる
- [ ] 時間軸（Now/Next/Later）で整理する
- [ ] 各取り組みの成功基準を定義する
- [ ] 対象読者ごとのビューを作成する
- [ ] ステークホルダーとレビューし、共有する
## ワークフロー例
### 例1: 新機能のPRDを書く
```markdown
# PRD: 高度検索機能
## 問題の説明
ユーザーは、複数の条件（価格帯、場所、カテゴリ、機能）でカタログ内の特定のアイテムを見つけるのに困難を感じているとの報告が頻繁にあります。現在の検索は単純なテキストクエリのみをサポートしており、以下の結果をもたらしています：
- 検索結果ページの高い離脱率（サイト平均32%に対し65%の離脱率）
- 検索ヘルプを求めるサポートチケットの増加（月150件）
- コンバージョン機会の損失（年間売上影響額推定50万ドル）
## 目標と成功指標
**主要目標**: ユーザーが複数のフィルターを使用して関連するアイテムを迅速に見つけられるようにする。
**成功指標**:
- 検索結果ページの離脱率を65%から40%未満に削減
- 検索からの購入コンバージョン率を25%向上
- 検索関連サポートチケットを50%削減
- 30日以内にユーザーの70%が少なくとも1つのフィルターを使用
## ユーザーストーリー
### 必須
1. 購入者として、予算内のアイテムを見つけられるよう価格帯でフィルタリングしたい
2. 購入者として、近くのアイテムを見つけられるよう場所でフィルタリングしたい
3. 購入者として、アイテムタイプを絞り込むためにカテゴリでフィルタリングしたい
4. 購入者として、必要なものを正確に見つけるために複数のフィルターを組み合わせたい
5. 購入者として、適用前にマッチするアイテム数を知るためにフィルター件数を見たい
### あるとよい
6. 購入者として、再適用の必要がないようフィルター設定を保存したい
7. 購入者として、検索クエリに基づく推奨フィルターを見たい
8. 購入者として、フィルタリングされた結果を関連度、価格、または日付で並び替えたい
### あるとよいもの
9. 購入者として、新しいマッチを通知する保存検索を作成したい
10. 購入者として、フィルタリングされた検索URLを他の人と共有したい
## 要件
### 機能要件
**フィルタータイプ** （優先度: Must Have）
- 価格帯フィルター: 最小/最大入力 + 一般的なプリセット（$0-50、$50-100など）
- 場所フィルター: 半径選択 + 郵便番号入力
- カテゴリフィルター: 複数選択可能な階層カテゴリツリー
- カスタム属性フィルター: アイテムタイプに基づく（サイズ、色、状態など）
**フィルター動作** （優先度: Must Have）
- フィルターは即座に適用（「適用」ボタンなし）または500ms未満の遅延
- アクティブフィルターを反映したURL更新（共有可能リンク）
- フィルターがアクティブな時に全フィルタークリアボタンが表示
- セッション内でフィルター状態が持続
- モバイルフレンドリーなフィルターUI（モバイルではドロワーまたはモーダル）
**検索統合** （優先度: Must Have）
- フィルターがテキスト検索クエリと連動
- テキストクエリに基づくフィルターファセット件数の更新
- 検索語に基づく自動フィルター提案（例：「赤」→ 色フィルターを提案）
### 非機能要件
**パフォーマンス** （優先度: Must Have）
- 初期ページ読み込み時間p95で2秒未満
- フィルター適用応答時間p95で500ms未満
- 性能劣化なしに10,000以上の同時ユーザーをサポート
- 100万以上のアイテムに対する効率的なインデックス化
**スケーラビリティ** （優先度: Should Have）
- コード変更なしに設定可能なフィルター定義
- 50以上のフィルタータイプのサポート
- 新カテゴリ用の新フィルタータイプを簡単に追加
**アクセシビリティ** （優先度: Must Have）
- すべてのフィルターでキーボードナビゲーション
- 適切なARIAラベルによるスクリーンリーダーサポート
- ハイコントラストモードサポート
- モバイルでタッチターゲットサイズ≥44×44px
## 技術的考慮事項
### アーキテクチャ
- **検索バックエンド**: フィルター集計で既存Elasticsearchクラスターを拡張
- **API変更**: フィルター用の新しい`/search`エンドポイントクエリパラメータ; レスポンスでフィルターファセットを返す
- **フロントエンド**: URL状態管理付きReactコンポーネント（React Router）
- **キャッシュ**: フィルター定義とファセット件数をキャッシュ（Redis、TTL 5分）
### 依存関係
- 効率的な集計をサポートするためElasticsearch 8.xへのアップグレード（現在7.x）
- フィルター固有フィールドを含むようアイテムスキーマを更新
- 段階的展開をサポートするバックエンドAPIバージョニング
### データモデル
```typescript
interface SearchFilters {
price?: { min: number; max: number };
location?: { lat: number; lng: number; radius: number };
categories?: string[]; // カテゴリID
attributes?: Record<string, string[]>; // 動的属性
}
interface SearchResponse {
items: Item[];
facets: {
[filterName: string]: {
values: Array<{ value: string; count: number }>;
};
};
total: number;
}
```
### 技術的リスク
1. **Elasticsearchパフォーマンス**: 複雑な集計が検索遅延に影響する可能性
- *軽減策*: 本番データでの負荷テスト; キャッシュ追加; 事前集計を検討
2. **インデックスサイズ拡大**: より多くのフィールド = より大きなインデックスとより遅いインデックス化
- *軽減策*: インデックスサイズを監視; 異なるアイテムタイプに対して分離インデックスを検討
3. **スキーマ進化**: 新しいフィルター追加にはインデックス更新が必要
- *軽減策*: 柔軟なスキーマ設計; 段階的展開を計画
## デザインとUXの注意点
### デスクトップレイアウト
- 左サイドバーのフィルター（持続的、折りたたみ不可）
- 上部にソートコントロールがあるメイン結果エリア
- アクティブフィルターを示すフィルターチップを結果の上に配置
### モバイルレイアウト
- ヘッダーの「フィルター」ボタンがボトムシートを開く
- ボタンにアクティブフィルター件数のバッジを表示
- ボトムシートに適用ボタン（リクエスト削減のためモバイルでは自動適用しない）
### フィルターUIパターン
- 価格: デュアルスライダー + テキスト入力
- 場所: 場所検索オートコンプリート + 半径選択
- カテゴリ: チェックボックス付き展開可能ツリー
- 属性: チェックボックスグループ、折りたたみ可能セクション
## リスクと軽減策
| リスク | 可能性 | 影響 | 軽減策 |
|------|-----------|--------|------------|
| 複雑フィルターでのパフォーマンス劣化 | 中 | 高 | 負荷テスト; キャッシュ; 機能フラグによる段階展開 |
| ユーザーによるフィルター採用率の低さ | 中 | 高 | ユーザーテスト; 目立つUI; 初回訪問時のチュートリアル |
| Elasticsearchアップグレード問題 | 低 | 高 | ステージングでテスト; ロールバック計画; オフピーク時デプロイ |
| フィルターオプションが圧倒的になる | 中 | 中 | フィルター優先順位付けのためのユーザー調査; 「その他フィルター」段階的開示を検討 |
## ローンチ計画
### フェーズ1: MVP (週1-2)
- 価格、場所、カテゴリフィルターのみ
- デスクトップウェブのみ
- パフォーマンステストのため5%展開
### フェーズ2: 拡張 (週3-4)
- カスタム属性フィルターを追加
- モバイル対応デザイン
- 25%のユーザーに拡張
### フェーズ3: 完全ローンチ (週5-6)
- 保存検索設定（ログインユーザー）
- 100%展開
- メトリクス監視と改善
### 機能フラグ
- `advanced_search_enabled`: 機能全体のマスターフラグ
- `advanced_search_filters`: 個別のフィルタータイプを有効/無効にできる
- `advanced_search_saved_prefs`: 保存設定機能
### 監視
- 成功メトリクス（離脱率、コンバージョン、エンゲージメント）を追跡するダッシュボード
- 検索APIのエラー率と遅延
- フィルター使用状況分析（最もよく使われるフィルター、組み合わせ）
- 検索遅延>1秒またはエラー率>1%のアラート
## 未解決の質問
1. **フィルターデフォルト**: ユーザー履歴や場所に基づいて事前適用すべきフィルターはあるか？（担当者: PM、期限: 週1）
2. **パーソナライゼーション**: 保存設定と共有フィルターURLの競合をどう処理するか？（担当者: Eng、期限: 週2）
3. **モバイルUX**: モバイルは即座適用か「適用」ボタンが必要か？（担当者: Design、期限: 週1）
4. **分析**: どの特定のフィルター操作を追跡すべきか？（担当者: Data、期限: 週2）
## ステークホルダーとレビュワー
- **PM担当**: Jane Doe
- **エンジニアリングリード**: John Smith
- **デザイン**: Alice Johnson
- **データサイエンス**: Bob Lee（メトリクスと計装）
- **承認必要**: VP Product、VP Engineering
---
*最終更新*: 2025-11-19
*ステータス*: 下書き → レビュー → 承認 → 進行中
```
### 例2: 機能リクエスト分析
```markdown
# 機能分析: ダークモードサポート
## リクエスト要約
**ソース**: ユーザーフィードバック（過去6ヶ月で150以上のリクエスト）、競合圧力
**説明**: ウェブおよびモバイルアプリにダークモードテーマオプションを追加
## ユーザーニーズ
低照度環境で作業するユーザーが、現在のライトモードのみのテーマで目の疲労を報告。パワーユーザー（DAUの25%）は1日3時間以上アプリを使用し、ダークモードを強く好む。よくあるフィードバック：「他のところではダークモードを使っているのに、なぜここでは使えないのか？」
## 対象ユーザー
- パワーユーザー: 30万ユーザー、1日3時間以上の使用
- 夜間/夜のユーザー: 主に午後6時から午前12時にアプリを使用する45万ユーザー
- アクセシビリティユーザー: 光過敏症や視覚障害のあるユーザー
## 影響評価
### ユーザー影響
- **リーチ**: 約75万ユーザー（ユーザーベースの45%）がダークモードをリクエストまたは使用する
- **影響スコア**: 8/10 - 対象ユーザーには高影響; 他のユーザーには中立
- **確信度**: 85% - ユーザー調査と競合データからの強いシグナル
### ビジネス影響
- **リテンション**: パワーユーザー（高価値セグメント）のリテンション向上の可能性
- **獲得**: 競合ポジショニングのための必要最低条件
- **収益**: リテンションと満足度を通じた間接的影響
- **推定価値**: 全体リテンション+2% = 年間約80万ドルの収益
## 工数評価
### エンジニアリング工数
- **フロントエンド**: 3週間（エンジニア2名）
- デザインシステム更新（カラートークン、テーマプロバイダー）
- コンポーネント更新（約150コンポーネント）
- ブラウザーとデバイス間でのテスト
- **バックエンド**: 1週間（エンジニア1名）
- ユーザー設定保存とAPI
- デフォルトテーマロジック
- **総工数**: 約7エンジニア週
### デザイン工数
- ダークテーマの設計と検証に2週間
- すべての画面とコンポーネントの監査
- コントラスト比のアクセシビリティテスト
### 依存関係
- まずデザインシステム更新が必要（Q2に既に計画済み）
- モバイルアプリにはReact Nativeテーマプロバイダー更新が必要
- メールテンプレートはライトモードのまま（現在の範囲外）
## 検討した代替案
### オプション1: フルダークモード（推奨）
- **長所**: ユーザーニーズに対応; 業界標準; 将来性
- **短所**: 最初により多くの実装作業
- **工数**: 7エンジニア週
### オプション2: 自動ダークモードのみ（システム設定に従う）
- **長所**: よりシンプル（ユーザー設定保存なし）; それでもユーザーを助ける
- **短所**: ユーザーにコントロールを与えない; ユーザー設定に合わない可能性
- **工数**: 5エンジニア週
### オプション3: プレミアム機能（有料ユーザー向けダークモード）
- **長所**: 機能アップグレードからの潜在的収益
- **短所**: ユーザーの反発（必要最低条件として期待される）; 採用を制限
- **工数**: 7エンジニア週 + ペイウォールロジック
## 優先順位スコア
RICEフレームワークを使用：
- **リーチ**: 75万ユーザー = 750
- **影響**: 8/10（対象セグメントに高い） = 0.8
- **確信度**: 85% = 0.85
- **工数**: 7週間 = 7
**RICEスコア**: (750 × 0.8 × 0.85) / 7 = **73.2**
比較：
- 最近の機能A: RICE = 45
- 最近の機能B: RICE = 92
- 平均機能RICE: 55
## リスク
1. **スコープクリープ**: 色についての細かい議論が起こりやすい; 明確なデザイン権限が必要
- *軽減策*: 早期にデザインを確定; フィードバックサイクルを時間制限
2. **アクセシビリティ**: 悪いコントラスト選択がアクセシビリティを損なう可能性
- *軽減策*: WCAG AAテスト; ローンチ前のアクセシビリティ監査
3. **保守負担**: 今後すべてを両モードでテストする必要
- *軽減策*: 自動視覚回帰テスト; CIチェック
4. **不完全なカバレッジ**: 一部がテーマを尊重しない場合にユーザーが気づく
- *軽減策*: 包括的コンポーネント監査; 段階的展開
## 戦略的整合性
**プロダクト戦略**: ✅ 整合 - パワーユーザー（戦略セグメント）のコアユーザー体験を向上
**技術戦略**: ✅ 整合 - デザインシステムとコンポーネントアーキテクチャを近代化
**ビジネス目標**: ✅ 整合 - リテンション目標と競合ポジショニングをサポート
## 推奨事項
**✅ オプション1（フルダークモード）で進める**
**理由**:
- 大規模ユーザーセグメント（ベースの45%）への高い影響
- 強いユーザー需要と競合圧力
- 価値に対して工数が妥当
- RICEスコアが閾値（>50）を上回る
- プロダクト、技術、ビジネス戦略に整合
**推奨タイムライン**:
- 2025年Q2: デザインとデザインシステム更新
- 2025年Q3: 実装とテスト
- 2025年Q4: マーケティングプッシュでローンチ
**次のステップ**:
1. ステークホルダー承認を得る
2. Q2ロードマップに追加
3. デザイン作業を開始
4. エンジニアリングスプリント配分を計画
---
*分析者*: Jane Doe (PM)
*レビュー者*: Design、Engineering、Data
*日付*: 2025-11-19
```
## よく使うPM成果物
### PRD（プロダクト要求仕様書）
何をなぜ作るかを示す包括的な仕様。問題定義、目標、ユーザーストーリー、要件、技術的考慮事項、リスク、ローンチ計画を含めます。
### 機能ブリーフ
PRDより軽量な、主要詳細を含む機能アイデアの簡単な要約。完全なPRDに進む前の初期探索に使用します。
### ユーザーリサーチ統合
ユーザーリサーチ結果（インタビュー、アンケート、ユーザビリティテスト）を、パターン、洞察、推奨事項とともに要約します。
### ロードマップ
時間をかけて何を作るかを示す戦略計画。テーマと時間軸で整理し、アウトプットだけでなく成果に焦点を当てます。
### 意思決定ドキュメント
重要なプロダクト意思決定、検討した選択肢、決定内容、理由の記録。組織の記憶として重要です。
### ローンチ計画
フェーズ、機能フラグ、指標、モニタリング、ロールバック手順を含む機能展開の詳細計画。
### 競合分析
競合の機能、アプローチ、ポジショニングの比較。プロダクト戦略と機能優先順位付けに活用します。
### 1ページ資料
プロダクト施策のエグゼクティブサマリー。リーダーシップへの共有と合意形成に使用します。
## 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ツールを構築する。