project-management

プロジェクト管理

このスキルを使うと、AI エージェントがソフトウェアチームのプロジェクト管理を支援できます。上位目標を受け入れ条件付きの実行可能なタスクに分解することから、ストーリーポイントによる工数見積もり、スプリントやカンバンボードへの作業の整理、バーンダウンデータによる進捗管理、ブロッカーやリスクの特定、ステークホルダー向けの進捗レポート作成まで、ライフサイクル全体をカバーします。エージェントは Jira、Linear、GitHub Issues、Trello と連携するため、すべての変更がチームの実際のプロジェクトトラッカーに反映されます。

ワークフロー

1. プロジェクトのコンテキストを収集する プロジェクト名、チームメンバー一覧（役割と稼働可能量を含む）、上位目標、重要な期限、希望する方法論（スクラム、カンバン、またはハイブリッド）を収集します。すでにプロジェクトトラッカーを使用している場合は、その API に接続し、現在のバックログ、ラベル、スプリント設定をインポートします。これにより、エージェントは何もない状態からではなく、既存の状態を基に作業を開始できます。

2. 作業をタスクに分解する 各上位目標をエピックに分解し、さらにユーザーストーリー、最後に 1〜2 日で完了できる大きさのサブタスクに分解します。各ユーザーストーリーは、標準形式「[役割]として、[メリット]のために[機能]がしたい」の形で記述します。すべてのストーリーにチェックリスト形式で受け入れ条件を追加します。タスク間の依存関係を特定し、クリティカルパスを形成するものがあればフラグを付けます。複雑さ、不確実性、工数に基づいて、フィボナッチ数列（1、2、3、5、8、13）を使ってストーリーポイントを見積もります。

3. スプリントを計画するか、ボードに作業を登録する スクラムチームの場合は、開始日、終了日、スプリント目標を設定してスプリントを作成します。優先順位付けされたバックログの上位から、チームのベロシティ（過去の 1 スプリントあたりのストーリーポイントの平均）に達するまでストーリーを取り込みます。カンバンチームの場合は、各列に仕掛かり中作業（WIP）の上限を設け、ボードの列がチームのワークフロー（例：バックログ → 進行中 → レビュー → 完了）と一致するようにします。API を介して、計画を接続済みのプロジェクトトラッカーに反映します。

4. 進捗を追跡し、ブロッカーを明らかにする 設定可能な間隔（デフォルト：毎日）でプロジェクトトラッカーをポーリングします。バーンダウンと累積フローメトリクスを算出します。タスクが見積もり時間を超えて「進行中」になっている場合は、リスクありとしてフラグを付けます。上流のブロックされたタスクが下流の作業を停滞させている依存関係の連鎖を特定します。完了した項目、進行中の項目、ブロッカーをまとめた日次ダイジェストを、チームの Slack または Teams チャンネルに投稿します。

5. リスクと依存関係を管理する リスク登録簿を管理し、各項目に説明、発生可能性（低／中／高）、影響度（低／中／高）、担当者、軽減計画を含めます。チームメンバーの休暇やサードパーティ API の廃止など、新しいリスクが特定された場合は登録簿に追加し、プロジェクトリードに通知します。外部課題をリンクしてチーム間の依存関係を追跡し、そのステータスが変わったときにアラートを送信します。

6. 進捗レポートを作成する スプリントレビューまたは週次の進捗レポートを Markdown で作成します（または PDF／Confluence にエクスポートします）。各レポートには、スプリント目標と達成状況、完了したストーリーとそのポイント合計、次期に持ち越すストーリー、バーンダウンチャートのデータ、過去 5 スプリントのベロシティの推移、主なリスク、次期のアクションアイテムを含めます。対象者に合わせて詳細度を調整します。経営幹部向けには 1 ページの概要を、チーム向けには詳細な内訳を作成します。

使用方法

プロジェクトの詳細と必要な内容をエージェントに伝えてください。エージェントは方法論と使用ツールに合わせて対応します。

"Create a sprint plan for the TaskMaster mobile app. We're a team of 4 with a velocity of 34 points. Sprint starts Monday and runs two weeks. Pull from the existing backlog in Linear."

"Generate a weekly status report for Project Atlas. Include burndown, completed items, and open risks."

"Break down this feature into user stories with acceptance criteria: 'Users should be able to export their data in CSV and JSON formats.'"

"Add a risk to the register: 'Payment provider is deprecating API v2 on March 1. We need to migrate to v3.'"

例

例 1 — ユーザーストーリーを含むスプリント計画の作成

ユーザー入力：

"Plan sprint 12 for the Lumen project. Sprint goal: launch the notifications feature. Team: Alice (frontend, 8 pts capacity), Bob (backend, 10 pts), Carol (fullstack, 8 pts). Two-week sprint starting Feb 17."

エージェントの出力：

## Sprint 12 — Lumen
**Goal:** Launch the notifications feature
**Dates:** Feb 17 – Feb 28, 2025
**Team capacity:** 26 story points

### Selected Stories (26 pts)

| ID     | Story                                              | Points | Assignee | Depends On |
|--------|-----------------------------------------------------|--------|----------|------------|
| LUM-41 | As a user, I want to receive in-app notifications    | 5      | Alice    | —          |
| LUM-42 | As a user, I want to receive push notifications      | 8      | Bob      | LUM-41     |
| LUM-43 | As a user, I want to configure notification prefs    | 3      | Alice    | LUM-41     |
| LUM-44 | Build notification service with WebSocket delivery   | 8      | Bob      | —          |
| LUM-45 | As a user, I want to see a notification history page | 5      | Carol    | LUM-44     |
| LUM-46 | Write integration tests for notification flow        | 3      | Carol    | LUM-42     |

### Acceptance Criteria (example — LUM-42)
- [ ] Push notification is delivered to iOS and Android within 5 seconds
- [ ] Notification payload includes title, body, and deep-link URL
- [ ] Notifications respect the user's quiet-hours setting
- [ ] Failed deliveries are retried up to 3 times with exponential backoff

### Dependencies
  LUM-42 → LUM-41 (push requires in-app infrastructure)
  LUM-45 → LUM-44 (history page reads from notification service)
  LUM-46 → LUM-42 (integration tests cover push path)

Sprint pushed to Linear. Slack channel #lumen-dev notified.

例 2 — バーンダウンデータを含むプロジェクト進捗レポートの作成

ユーザー入力：

"Generate the sprint 11 retrospective report for Project Atlas. We use GitHub Issues."

エージェントの出力：

## Project Atlas — Sprint 11 Status Report
**Sprint dates:** Feb 3 – Feb 14, 2025
**Sprint goal:** Complete user profile redesign — ✅ Met

### Summary
- **Planned:** 30 story points across 9 stories
- **Completed:** 28 story points (8 stories)
- **Carried over:** 1 story (ATLAS-87, 2 pts — blocked by design review)

### Burndown Data

| Day       | Ideal Remaining | Actual Remaining |
|-----------|-----------------|------------------|
| Feb 3     | 30              | 30               |
| Feb 4     | 27              | 28               |
| Feb 5     | 24              | 25               |
| Feb 6     | 21              | 22               |
| Feb 7     | 18              | 18               |
| Feb 10    | 15              | 14               |
| Feb 11    | 12              | 10               |
| Feb 12    | 9               | 6                |
| Feb 13    | 6               | 4                |
| Feb 14    | 0               | 2                |

### Velocity Trend (last 5 sprints)
  Sprint 7: 24 pts | Sprint 8: 28 pts | Sprint 9: 26 pts | Sprint 10: 30 pts | Sprint 11: 28 pts
  **Average velocity:** 27.2 pts

### Open Risks
| Risk                                  | Likelihood | Impact | Owner  | Mitigation                        |
|---------------------------------------|------------|--------|--------|-----------------------------------|
| Design system migration incomplete    | Medium     | High   | Alice  | Parallel-run old and new systems  |
| Third-party image CDN latency spikes  | Low        | Medium | Bob    | Add fallback CDN configuration    |

### Action Items
1. Complete design review for ATLAS-87 by Feb 17 (owner: Carol)
2. Schedule performance testing for new profile page (owner: Bob)
3. Update onboarding docs to reflect profile redesign (owner: Alice)

ベストプラクティス

• ストーリーは小さく、テスト可能なものにします。 8ポイントを超える見積もりのストーリーは分割してください。大きなストーリーは複雑さを見えにくくし、進捗の追跡を不確かなものにします。
• 開発を始める前に受け入れ基準を作成します。 基準を定めることで曖昧さがなくなり、テストケースの基礎となり、チームで「完了」の定義を共有できます。
• ベロシティを尊重し、過剰なコミットは避けます。 チームの直近3スプリントの平均をキャパシティの上限として使用してください。過負荷のスプリントは、持ち越しを招き、チームの士気を低下させます。
• ブロッカーはすぐに可視化します。 ブロックされているタスクを日次ダイジェストに掲載し、解決できる担当者にタグ付けしてください。数日間報告されないままのブロッカーは、気付かれないスケジュール上のリスクとなります。
• 常に更新されるリスク一覧を維持します。 各スプリント計画ミーティングでリスクを確認してください。関連性がなくなったリスクは解消し、新たに発生したリスクを追加します。古いリスク一覧は、誤った安心感を与えます。
• レポートの生成を自動化します。 ステータスレポートを手作業でまとめると、誤りが起きやすく、時間もかかります。エージェントを使ってプロジェクトトラッカーから直接データを取得すれば、レポートの正確さと一貫性を常に保てます。

エッジケース

• バックログが空の場合。 スプリント計画の依頼時にストーリーが存在しない場合は、計画を始める前にストーリーを作成またはインポートするようユーザーに促してください。項目がゼロのスプリントは作成しないでください。
• チームメンバーのキャパシティがゼロの場合。 チームメンバーがスプリント期間中ずっと休暇を取る場合は、割り当て対象から除外します。ただし、該当する場合はレビュー担当者またはステークホルダーとして記載したままにしてください。それに応じて総キャパシティを調整します。
• 循環依存。 タスク A が B に依存し、B が A に依存している場合は、循環依存を指摘し、計画を進める前に解決するようユーザーに依頼してください。相互にブロックするタスクを、黙ってスケジュールに組み込んではいけません。
• トラッカー API の停止。 プロジェクトトラッカー API に接続できない場合は、計画を Markdown 形式でローカルに生成し、API の復旧後に同期するようキューに登録してください。変更はローカルに保存されていますが、まだプッシュされていないことをユーザーに伝えます。
• スプリント途中のスコープ変更。 スプリント途中に優先度の高い新しい項目が追加された場合は、スプリント目標への影響をユーザーに警告し、追加の余地を作るために優先度を下げる既存の項目を提案してください。スコープ変更をスプリントレポートに記録します。
• プロジェクト横断の依存関係。 タスクが別のチームまたはプロジェクトの担当作業に依存する場合は、リンクされた外部参照を作成し、依存関係が解消された際にチームへ通知するための Webhook またはポーリングチェックを設定してください。