プロジェクト管理と製品要件

機能説明

このスキルはプロジェクト管理と製品要件分析専門で、以下を含みます:

• 製品要件文書(PRD)の作成
• プロジェクト計画の策定
• タスク分解と優先順位付け
• ユーザーストーリーと受け入れ基準
• リスク識別と管理
• アジャイル開発プロセス

使用シーン

• 「eコマースシステムの PRD を作成する」
• 「プロジェクト開発計画を策定する」
• 「機能モジュールとタスクを分解する」
• 「ユーザーストーリーと受け入れ基準を定義する」
• 「プロジェクトリスクを評価する」
• 「MVP 機能を計画する」

コア能力

1. 要件の洞察と分析

• 実際のユーザー要件を正確に識別
• コア機能と付加価値機能を区別
• シナリオベースの製品設計
• 競合分析と差別化ポジショニング

2. 機能分解

• マクロレベルの要件を実行可能な機能ポイントに分解
• 入力-処理-出力ロジックを定義
• 依存関係と統合ポイントを識別
• エッジケースと例外を処理

3. 優先順位管理

• P0(Must Have): MVP 必須機能
• P1(Should Have): 重要だが必須ではない機能
• P2(Nice to Have): あると良い機能

4. リスク予測

• 技術実装リスク
• 市場受け入れリスク
• ユーザー採用リスク
• リソースと時間リスク

PRD 文書構造

標準 PRD テンプレート

# [製品名] 製品要件文書(PRD)

**バージョン**: v1.0
**作成日**: 2025-01-01
**作成者**: プロダクトマネージャー
**ステータス**: ドラフト/レビュー中/承認済み

---

## 1. プロジェクト背景と目標

### 1.1 製品ビジョン
製品のコア価値提案と長期ビジョンを簡潔に説明します。

### 1.2 問題陳述
**現在の課題**:
- ユーザーが直面する具体的な問題
- 問題の重大度と影響範囲
- 既存ソリューションの不足

**ターゲットユーザー**:
- 主要ユーザー層(年齢、職業、行動特性)
- 二次ユーザー層
- ユーザーペルソナと典型的シナリオ

### 1.3 成功指標(KPI)
- **ユーザー指標**: DAU、MAU、リテンション率
- **ビジネス指標**: GMV、コンバージョン率、客単価
- **製品指標**: 機能使用率、完了率
- **技術指標**: レスポンスタイム、可用性

### 1.4 ビジネス目標と制約
**ビジネス目標**:
- 短期目標(3 ヶ月)
- 中期目標(6-12 ヶ月)
- 長期目標(1-3 年)

**既知制約**:
- 技術的制限
- 予算制限
- 時間制限
- プラットフォーム制限(iOS/Android/Web)

---

## 2. ユーザー調査と競合分析

### 2.1 ユーザーペルソナ
**主要ユーザー: ホワイトカラー**
- 年齢: 25-35 歳
- 職業: IT、金融、コンサルティング業界
- 課題: 時間管理の困難さ、生産性の低さ
- 期待: シンプルで使いやすく、生産性向上

### 2.2 ユーザージャーニー

問題発見 → ソリューション探索 → 登録・利用開始 → 日常使用 → 他者への推奨

### 2.3 競合分析
| 競合製品 | 強み | 弱み | 差別化機会 |
|----------|------|------|-----------|
| 製品 A | 機能豊富 | 学習コスト高 | 操作フロー簡素化 |
| 製品 B | インターフェース美麗 | パフォーマンス低 | パフォーマンス最適化 |

---

## 3. 機能要件

### 3.1 機能アーキテクチャ図

├── ユーザーモジュール │ ├── 登録・ログイン │ ├── プロフィール │ └── アカウント設定 ├── コア機能モジュール │ ├── 機能 A │ ├── 機能 B │ └── 機能 C └── 補助機能モジュール ├── 通知センター └── ヘルプセンター

### 3.2 ユーザーストーリーリスト

| ID | ユーザーストーリー | 優先度 | 受け入れ基準 | 依存 |
|----|----------|--------|----------|------|
| US-001 | ユーザーとして、アカウントを素早く登録したいので、製品の使用を開始できる | P0 | 1. メール/電話登録をサポート<br>2. 登録フロー3ステップ以内<br>3. 登録成功後は自動ログイン | なし |
| US-002 | ユーザーとして、安全にログインしたいので、自分のデータにアクセスできる | P0 | 1. パスワードログインをサポート<br>2. サードパーティーログインをサポート<br>3. ログイン失敗時は明確なメッセージ表示 | US-001 |
| US-003 | ユーザーとして、タスクを作成したいので、仕事管理ができる | P0 | 1. タスクタイトルと説明を入力可能<br>2. 期限設定可能<br>3. 作成後すぐに表示 | US-002 |

### 3.3 機能詳細説明

#### 機能モジュール: ユーザー登録

**機能説明**:
ユーザーはメールまたは電話番号でアカウントを登録し、本人確認後、製品を使用できます。

**インタラクションフロー**:
1. ユーザーが「登録」ボタンをクリック
2. 登録方法を選択(メール/電話)
3. 登録情報を入力
4. 確認コードを受け取る
5. 確認を完了
6. パスワードを設定
7. 登録成功、自動ログイン

**UI 要素**:
- 登録方法選択(タブ切り替え)
- メール/電話番号入力欄
- 確認コード入力欄
- パスワード入力欄(強度表示付き)
- 利用規約同意チェックボックス
- 登録ボタン

**データフィールド**:
| フィールド名 | 型 | 必須 | 検証ルール | 説明 |
|--------|------|------|----------|------|
| email | String | はい | メール形式 | ユーザーメール |
| phone | String | はい | 電話番号形式 | ユーザー電話番号 |
| password | String | はい | 6-20文字、文字と数字を含む | ログインパスワード |
| verifyCode | String | はい | 6桁の数字 | 確認コード |

**ビジネスルール**:
- メール/電話番号の重複登録は不可
- 確認コードは5分間有効
- パスワードは文字と数字を含む必須
- 同一 IP から1日最大3アカウント登録

**例外処理**:
- メール/電話番号既存: 「このアカウントは既に登録されています。直接ログインしてください」と表示
- 確認コード間違い: 「確認コードが間違っています。再度入力してください」と表示
- 確認コード有効期限切れ: 「確認コードが有効期限切れです。再度取得してください」と表示
- ネットワークエラー: 「ネットワーク接続エラー。後でもう一度お試しください」と表示

**API 定義**:

POST /api/auth/register Request: { "email": "user@example.com", "password": "password123", "verifyCode": "123456" }

Response: { "success": true, "data": { "userId": 12345, "token": "jwt_token_here" }, "message": "登録に成功しました" }

---

## 4. 非機能要件

### 4.1 パフォーマンス要件
- **レスポンスタイム**: ページロード < 2秒、API レスポンス < 500ms
- **並行処理能力**: 10,000 並行ユーザーをサポート
- **スケーラビリティ**: 水平スケーリングに対応

### 4.2 セキュリティ要件
- **認証**: JWT Token 認証、7日有効期限
- **認可**: ロールベースアクセス制御(RBAC)
- **データ暗号化**: HTTPS 通信、機密データは暗号化保存
- **保護**: SQL インジェクション、XSS、CSRF 対策

### 4.3 互換性要件
- **ブラウザ**: Chrome 90+、Safari 14+、Firefox 88+
- **モバイル**: iOS 13+、Android 8+
- **画面**: 320px - 1920px 幅に対応

### 4.4 可用性要件
- **システム可用性**: 99.9%(月間ダウンタイム < 43分)
- **データバックアップ**: 日次フルバックアップ、リアルタイム差分バックアップ
- **災害復旧**: RTO < 1時間、RPO < 5分

### 4.5 保守性要件
- **コード規約**: チーム編集規約に準拠
- **ドキュメント**: 完全な API ドキュメントと技術ドキュメント
- **ログ**: 充実したログ記録と監視
- **テスト**: 単体テストカバレッジ > 80%

---

## 5. 技術方案(オプション)

### 5.1 技術アーキテクチャ

フロントエンド: React + TypeScript + Ant Design バックエンド: Node.js + Express + TypeScript データベース: MySQL + Redis デプロイ: Docker + Kubernetes

### 5.2 データベース設計
```sql
-- ユーザーテーブル
CREATE TABLE users (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  email VARCHAR(255) UNIQUE,
  phone VARCHAR(20) UNIQUE,
  password_hash VARCHAR(255),
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

---

6. プロジェクト計画

6.1 マイルストーン

フェーズ	期間	成果物	責任者
要件レビュー	Week 1	PRD 文書	プロダクトマネージャー
設計レビュー	Week 2	UI デザイン	デザイナー
開発	Week 3-6	機能コード	開発チーム
テスト	Week 7	テストレポート	テストチーム
リリース	Week 8	本番環境	インフラチーム

6.2 タスク分解

Phase 1: MVP コア機能(P0)

• ユーザー登録ログイン
• コア機能 A
• コア機能 B

Phase 2: 重要機能(P1)

• 機能 C
• 機能 D

Phase 3: 拡張機能(P2)

• 機能 E
• 機能 F

---

7. リスクと対応

7.1 技術リスク

リスク	影響	確率	対応措置
外部 API の不安定性	高	中	フォールバック方案を実装、リトライメカニズムを追加
パフォーマンスボトルネック	中	低	事前に負荷テスト、ホットパス最適化

7.2 ビジネスリスク

リスク	影響	確率	対応措置
ユーザー受容度が低い	高	中	小規模グレイテスト、フィードバック収集と迅速反復
競合製品が先に提供	中	低	開発を加速、差別化優位性を強調

---

8. 受け入れ基準

8.1 機能受け入れ

• すべての P0 機能が完全に実装
• すべてのユーザーストーリーの受け入れ基準を満たす
• ブロッキング Bug なし

8.2 パフォーマンス受け入れ

• ページロード時間 < 2秒
• API レスポンスタイム < 500ms
• 並行テストに合格

8.3 セキュリティ受け入れ

• セキュリティスキャンに合格
• 高リスク脆弱性なし
• データ暗号化が正しく実装

---

9. 付録

9.1 用語集

• DAU: Daily Active Users、日活躍ユーザー数
• MAU: Monthly Active Users、月活躍ユーザー数
• MVP: Minimum Viable Product、最小限の実現可能な製品

9.2 参考資料

• [競合分析報告書]
• [ユーザー調査報告書]
• [技術選定ドキュメント]

9.3 変更記録

バージョン	日付	変更内容	変更者
v1.0	2025-01-01	初版	太郎
v1.1	2025-01-15	機能 X を追加	花子

## アジャイル開発プロセス

### Scrum フレームワーク
```markdown
Sprint サイクル: 2週間

Sprint プロセス:
1. Sprint 計画(計画会議)
   - Sprint 目標を決定
   - ユーザーストーリーを選択
   - タスク分解と見積もり

2. 日次スタンドアップ(毎日のスタンドアップ)
   - 昨日完了したこと
   - 今日の計画
   - 直面している障害

3. Sprint レビュー(レビュー会議)
   - 完了した機能を展示
   - フィードバック収集
   - 製品バックログを更新

4. Sprint 振り返り(振り返り会議)
   - うまくいったことをまとめる
   - 改善機会を識別
   - 行動計画を立案

ユーザーストーリーフォーマット

[ユーザー役割] として
[機能説明] したい
[価値/目標] ため

受け入れ基準:
- [ ] 基準 1
- [ ] 基準 2
- [ ] 基準 3

見積もり: 5 ストーリーポイント
優先度: P0
依存: US-001

プロジェクト管理ツール

推奨ツール

• Jira: アジャイルプロジェクト管理
• Trello: カンバン管理
• Asana: タスク協業
• Notion: ドキュメントとナレッジベース
• Confluence: チーム協業ドキュメント
• Figma: デザイン協業
• GitHub Projects: コードプロジェクト管理

ドキュメント管理

プロジェクトドキュメント構造:
├── PRD/
│   ├── 製品要件文書.md
│   └── 機能仕様書.md
├── Design/
│   ├── UI デザイン
│   └── インタラクティブプロトタイプ
├── Tech/
│   ├── 技術方案.md
│   ├── API ドキュメント.md
│   └── データベース設計.md
├── Test/
│   ├── テスト計画.md
│   └── テストケース.md
└── Release/
    ├── リリース計画.md
    └── リリース前確認チェックリスト.md

ベストプラクティス

要件収集

• ステークホルダーと深い協議
• ユーザーの実際の使用シーンを観察
• データとユーザーフィードバックを分析
• 競合製品と業界トレンドを研究

要件分析

• 要件とソリューションを区別
• 実際のユーザーの課題を特定
• 要件の価値とコストを評価
• 技術的実現可能性を検討

要件管理

• 要件の優先順位体系を構築
• 定期的に要件をレビュー・更新
• 要件変更を管理
• 要件のトレーサビリティを保つ

コミュニケーションと協業

• プロジェクト進捗を定期同期
• 障害問題を迅速に解決
• ドキュメント更新を維持
• フィードバックメカニズムを構築

注意事項

• 常にユーザー価値を中心に考える
• 過度な設計と機能の積み重ねを避ける
• 要件ドキュメントの明確性と実行可能性を保つ
• 要件変更に迅速に対応
• 理想と現実のバランスを取る
• チーム協業とコミュニケーションを重視
• 継続的な学習と改善