prd-writer

PRD Writer

概要

PRD Writer スキルは、チームが機能仕様を共有できるよう、明確で実行可能な製品要件ドキュメントを作成する際にプロダクトマネージャーを支援します。ユーザー中心の設計、技術的な明確さ、ビジネスの背景を組み合わせ、実装の成功を確実にします。

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

• 開発する新機能や新製品を定義するとき
• エンジニアリングチームに要件を伝えるとき
• ロードマップ全体で機能の優先順位を決めるとき
• 開発前に機能仕様を文書化するとき
• ステークホルダーに製品ビジョンを伝えるとき
• デザインチームや QA チーム向けの仕様を作成するとき

PRD のテンプレートと構成

エグゼクティブサマリー

機能名： [明確で具体的な名前] オーナー（PM）： [名前] ステークホルダー： [エンジニアリング、デザイン、マーケティング、法務など] ステータス： [ドラフト、レビュー中、承認済み、開発中] 最終更新日： [日付]

ビジョンステートメント： [全体像を説明する 1～2 文] 例：「ユーザーがプロジェクトでリアルタイムに共同作業できるようにし、コミュニケーションの負担を減らして、チームの連携を強化します。」

ビジネス目標：

• 主な目標：[リテンション／収益／効率の向上]
• 測定可能な目標：[指標を X% 改善]
• 期間：[四半期／年間の目標]

解決するユーザーの課題： [この機能で解決する課題を説明します] 「ユーザーは現在、プロジェクトの状況を手作業で同期するために、会議に 30 分以上かけています。この機能により非同期で更新できるようになり、会議時間を 50% 削減します。」

成功基準：

• 利用状況：[3 か月以内に機能を利用するユーザーの割合]
• エンゲージメント：[毎週この機能を利用するユーザーの割合]
• NPS への影響：[NPS を 5 ポイント向上させる目標]
• 収益：[MRR を X ドル増加、またはコストを X ドル削減]

---

ユーザーストーリーとユースケース

主なユースケース：

ユースケース 1：チームでのリアルタイム共同作業

• アクター：[プロジェクトチームのメンバー]
• 事前条件：[ユーザーがログインし、プロジェクトを開いている]
• 主なフロー：
  1. ユーザーがタスクのステータスを更新する
  2. 更新内容がチームに即座に配信される
  3. アクティビティフィードに通知が表示される
• 事後条件：[すべてのチームメンバーに更新後のステータスが表示される]
• 代替フロー：[接続が切断された場合、オフラインモード]

ユースケース 2：非同期でのステータス報告

• アクター：[リモートチームのメンバー]
• 事前条件：[ユーザーが異なるタイムゾーンにいる]
• 主なフロー：
  1. ユーザーがタスクにコメントを追加する
  2. コメントがフィードに表示される
  3. マネージャーが日次ダイジェストを受け取る
  4. マネージャーが非同期で返信する
• 事後条件：[同期的な会議が不要になる]

ユーザーストーリーのフレームワーク

ストーリー 1：リアルタイム更新を表示する

As a [project manager]
I want to [see live updates of task status]
So that [I can monitor progress without status meetings]

Acceptance Criteria:
- When a team member updates task status, I see the update within 2 seconds
- Status changes show in the main project view
- Activity timeline shows all updates with timestamps
- Notifications alert me to priority changes
- I can filter updates by assignee or task type

Definition of Done:
- Code reviewed and approved
- Unit tests pass (>80% coverage)
- QA tested on Chrome, Firefox, Safari
- Product Manager has signed off
- Updated help documentation

ストーリー 2：アクティビティ通知を受け取る

As a [team lead]
I want to [control which activities trigger notifications]
So that [I'm not overwhelmed with alerts]

Acceptance Criteria:
- Notification settings are accessible in preferences
- I can enable/disable alerts by activity type
- I can choose delivery method (in-app, email, Slack)
- Settings persist across devices
- Changes apply immediately

Definition of Done:
- Backend stores notification preferences
- Frontend UI implemented and tested
- Email delivery tested
- Slack integration verified
- Analytics event added for tracking

ストーリー 3：モバイル通知を配信する

As a [remote employee]
I want to [receive notifications on my phone]
So that [I stay informed while away from desk]

Acceptance Criteria:
- Push notifications delivered to iOS and Android apps
- Notifications respect local time zone
- User can tap notification to jump to relevant item
- Notification includes context (project, task, change)
- Deep linking to specific feature works

Definition of Done:
- Push service integrated (Firebase Cloud Messaging)
- iOS and Android implementations complete
- Battery/battery testing on both platforms
- Deep linking tested on Android and iOS

---

詳細仕様

機能仕様の概要

機能名： [名前] スコープ： [対象に含むものと、明示的に対象外とするもの] 依存関係： [先に存在している必要がある機能] データモデルの変更： [データベーススキーマの更新]

機能要件

要件 1：リアルタイムのステータス更新

• システムは、タスクのステータス変更を 2 秒以内にすべてのプロジェクトメンバーへ配信する
• 配信内容には、タスク ID、新しいステータス、変更前のステータス、タイムスタンプ、変更を行ったユーザーを含める
• システムは、ステータス配信の稼働率 99.9% を維持する
• システムは、プロジェクトごとに最大 1,000 件のステータス更新を同時に処理する

要件 2：アクティビティフィードの表示

• フィードには、すべてのアクティビティを新しい順に表示する
• 各アクティビティ項目には、アクター、アクション、対象、タイムスタンプ、コンテキストを含める
• フィードは 20 項目単位でページネーションする
• ユーザーは、アクティビティの種類、担当者、タスク、日付範囲でフィードを絞り込める
• フィードの読み込み時間は、初回読み込みで 1 秒以内、ページネーションで 500 ミリ秒以内とする

要件 3：通知の配信

• システムは、アクティビティの発生から 5 秒以内に通知を配信する
• ユーザーは、アクティビティの種類ごとに配信方法（アプリ内、メール、Slack、モバイルプッシュ）を選択できる
• 通知は、設定されている場合、おやすみ時間に配慮する
• システムは、通知疲れを防ぐために通知をまとめる（メールは 1 時間あたり最大 1 通）

技術仕様

技術スタック：

• フロントエンド：[React 18、TypeScript]
• バックエンド：[Node.js、Express]
• データベース：[PostgreSQL]
• リアルタイム：[WebSockets、Socket.io]
• 通知：[メール用のSendGrid、モバイル用のFCM、Slack API]

API エンドポイント：

POST /api/tasks/{taskId}/status
Updates task status, triggers broadcast

GET /api/projects/{projectId}/activity
Fetches activity feed with pagination

PUT /api/notifications/preferences
Updates user notification settings

POST /api/notifications/subscribe
Subscribes to WebSocket for real-time updates

データベーススキーマの変更：

CREATE TABLE activity_feeds (
  id UUID PRIMARY KEY,
  project_id UUID REFERENCES projects(id),
  actor_id UUID REFERENCES users(id),
  action_type VARCHAR(50), -- task_updated, comment_added, etc.
  target_id UUID, -- task, comment, project
  target_type VARCHAR(50),
  changes JSONB, -- before/after values
  created_at TIMESTAMP DEFAULT NOW()
);

CREATE TABLE notification_settings (
  id UUID PRIMARY KEY,
  user_id UUID REFERENCES users(id),
  activity_type VARCHAR(50),
  email BOOLEAN DEFAULT true,
  in_app BOOLEAN DEFAULT true,
  slack BOOLEAN DEFAULT false,
  mobile_push BOOLEAN DEFAULT true,
  dnd_start TIME,
  dnd_end TIME
);

---

UI/UX 仕様

ワイヤーフレームの説明

画面1：アクティビティフィード

[Header: "Activity"]
[Filter bar: Activity Type dropdown, Date range picker]
[Activity Item 1]
├─ [Avatar] [Name] [Action] [Context]
├─ [Timestamp] [2 hours ago]
└─ [Details: Task name, Previous → New status]

[Activity Item 2]
...
[Load more button]

画面2：通知設定モーダル

[Header: "Notification Preferences"]
[Tabs: Delivery Methods | Do Not Disturb]

[Activity Type Toggles]
├─ Task Status Updated
│  ├─ ☑ Email ☑ In-app ☑ Mobile Push
│  ├─ Batch these notifications (dropdown: real-time, daily, weekly)
├─ New Comment
│  ├─ ☑ Email ☑ In-app ☑ Mobile Push
├─ Task Assigned to Me
│  ├─ ☑ Email ☑ In-app ☑ Mobile Push

[Save] [Cancel]

デザイン上の考慮事項

• 視覚的な階層： アクティビティ項目では、最も重要な情報を最初に表示します
• 段階的な開示： 項目をクリックすると詳細全体を確認できます
• アクセシビリティ： 色だけをインジケーターにしません（ステータス変更は✓と色で示します）
• パフォーマンス： 大規模なフィード（1000件以上）では仮想スクロールを使用します
• モバイル： 1列のレイアウトにし、タップしやすいターゲット（最小44px）を用意します

---

優先順位付けフレームワーク：RICE

RICE スコアの計算式：（リーチ × インパクト × 確信度）/ 労力

リーチ（3か月間に影響を受けるユーザー数）

• 例：アクティブユーザーの80% = 8,000人
• 範囲：0～10,000人以上

インパクト（この変更がユーザーの成果にどれほど影響するか）

• 非常に大きい（3倍）：ワークフローが大幅に改善します
• 大きい（2倍）：効率が大幅に向上します
• 中程度（1倍）：目に見える改善があります
• 小さい（0.5倍）：わずかな改善です

確信度（この見積もりにどれほど確信があるか）

• 高（100%）：顧客データ／利用パターンに基づきます
• 中（75%）：ユーザーフィードバックと推測の両方に基づきます
• 低（50%）：推測に基づいており、検証が必要です

労力（実装に必要な人週）

• 小：1～2週間
• 中：3～4週間
• 大：5～8週間
• XL：8週間以上

RICE の計算例：

• リーチ：8,000人
• インパクト：2倍（大）
• 確信度：75%
• 労力：4週間

RICE スコア = (8000 × 2 × 0.75) / 4 = 3,000

---

別の優先順位付け方法：MoSCoW

必須（未完成のままでは機能をリリースできない項目）

• リアルタイムのステータス更新
• アクティビティ通知システム
• メールによる通知配信

推奨（重要で、最初のイテレーションでリリースする項目）

• モバイルプッシュ通知
• 通知設定／環境設定
• アクティビティフィードのフィルタリング
• おやすみ時間のスケジュール設定

あるとよい（あると便利で、今後のイテレーションで対応する項目）

• Slack 連携
• 通知のカスタム一括配信
• 高度なアクティビティ分析
• アクティビティのタイムライン表示

対象外（明示的にスコープ外とする項目）

• SMS 通知
• 音声通知
• 通知のカレンダー連携

---

タイムラインとリリース計画

フェーズ1：MVP（4週間）

• リアルタイムのステータス配信（WebSocket）
• アクティビティフィード（基本表示）
• メール通知
• 基本的な通知設定
• リリース： 四半期末を目標

フェーズ2：機能強化（3週間）

• モバイルプッシュ通知
• 高度なフィルタリングと検索
• おやすみ時間のスケジュール設定
• アクティビティ分析
• リリース： 次の四半期に入って2週間後

フェーズ3：連携（4週間）

• Slack 連携
• カレンダー同期
• 通知カスタマイズ UI の改善
• リリース： 四半期半ば

---

成功指標

導入：

• 機能の発見率：ユーザーの60%が30日以内に機能を見つける
• 初回利用開始率：ユーザーの40%が1週目に少なくとも1件の通知を送信する
• 週間アクティブユーザー：3か月目までにユーザーの70%が毎週機能を利用する

エンゲージメント：

• 日間アクティブユーザー：アクティブユーザーの50%が毎日利用する
• アクティビティフィードの閲覧数：ユーザーあたり1日平均8回
• 通知の開封率：配信した通知の35%が開封される

ビジネスへの影響：

• 時間の節約：ステータス確認にかかる時間が30%減ったとユーザーが報告する
• 会議の削減：会議時間が週平均15分短縮される
• リテンション：機能を利用するユーザーの12か月後のリテンションが10%高い

品質指標：

• 通知配信：配信成功率99.9%
• レイテンシ：更新の95%が2秒以内に配信される
• エラー率：操作の0.1%未満でエラーが発生する

---

リスクと軽減策

リスク	影響度	発生確率	軽減策
WebSocket のスケーラビリティの問題	高	中	リリース前に同時接続ユーザー数 10K で負荷テストを実施する
通知疲れによるオプトアウト	高	中	スマートな一括配信とデフォルトの「おやすみモード」を実装する
モバイルアプリの通知許可	中	高	許可を求める前に、通知のメリットを明確に説明する
Slack 連携の遅延	低	中	まず Slack なしで構築し、フェーズ 2 で追加する

---

PRD 承認チェックリスト

• ユーザーストーリーが明確で、テスト可能である
• 受け入れ基準が包括的である
• エンジニアリングチームが技術的な実現可能性を確認している
• デザインのモックアップがレビューされ、承認されている
• 成功指標が定義され、測定可能である
• スケジュールが現実的で、見積もられている
• リスクが特定され、軽減策が計画されている
• 依存関係が文書化されている
• ステークホルダーの承認を得ている
• PRD がデザイン、エンジニアリング、QA、マーケティングの各チームによってレビューされている
• 未解決の質問が解決されている
• 開発キックオフの準備ができている

成果物

1. PRD 全文 - 上記のすべてのセクション、15〜20 ページ
2. デザインのモックアップ／ワイヤーフレーム - 高精細なモックアップ、または詳細なワイヤーフレーム
3. 技術仕様書 - API コントラクト、データモデル、スキーマ
4. ユーザーストーリーと受け入れ基準 - JIRA 対応形式
5. 成功指標ダッシュボード - すべての KPI の定義
6. スケジュール／ロードマップ - 段階的なリリース計画
7. リスク登録簿 - リスクと軽減策