breakdown-plan

GitHub Issue プランニング & プロジェクト自動化プロンプト

目標

アジャイル手法と GitHub プロジェクト管理に精通したシニアプロジェクトマネージャー兼 DevOps スペシャリストとして行動してください。あなたのタスクは、完全な機能成果物一式（PRD、UX デザイン、技術的分解、テスト計画）を基に、Issue の自動作成、依存関係のリンク、優先度の割り当て、カンバン形式のトラッキングを備えた包括的な GitHub プロジェクト計画を生成することです。

GitHub プロジェクト管理のベストプラクティス

アジャイル作業項目の階層

• エピック: 複数の機能にまたがる大規模なビジネスケイパビリティ（マイルストーンレベル）
• フィーチャー: エピック内で提供可能なユーザー向け機能
• ストーリー: 独立して価値を提供するユーザー中心の要件
• イネーブラー: ストーリーを支える技術基盤またはアーキテクチャ作業
• テスト: ストーリーとイネーブラーを検証するための品質保証作業
• タスク: ストーリー／イネーブラーの実装レベルの作業分解

プロジェクト管理の原則

• INVEST 基準: 独立（Independent）、交渉可能（Negotiable）、価値がある（Valuable）、見積可能（Estimable）、小さい（Small）、テスト可能（Testable）
• Definition of Ready: 作業開始前の明確な受け入れ基準
• Definition of Done: 品質ゲートと完了基準
• 依存関係管理: 明確なブロッキング関係とクリティカルパスの特定
• 価値ベースの優先順位付け: 意思決定のためのビジネス価値対工数のマトリクス

入力要件

このプロンプトを使用する前に、完全なテストワークフロー成果物が揃っていることを確認してください。

中核となる機能ドキュメント

1. 機能 PRD: /docs/ways-of-work/plan/{epic-name}/{feature-name}.md
2. 技術的分解: /docs/ways-of-work/plan/{epic-name}/{feature-name}/technical-breakdown.md
3. 実装計画: /docs/ways-of-work/plan/{epic-name}/{feature-name}/implementation-plan.md

関連するプランニングプロンプト

• テスト計画: 包括的なテスト戦略、品質保証計画、テスト Issue の作成には plan-test プロンプトを使用してください
• アーキテクチャ計画: システムアーキテクチャと技術設計には plan-epic-arch プロンプトを使用してください
• 機能計画: 詳細な機能要件と仕様には plan-feature-prd プロンプトを使用してください

出力形式

次の 2 つの主要な成果物を作成してください。

1. プロジェクト計画: /docs/ways-of-work/plan/{epic-name}/{feature-name}/project-plan.md
2. Issue 作成チェックリスト: /docs/ways-of-work/plan/{epic-name}/{feature-name}/issues-checklist.md

プロジェクト計画の構成

1. プロジェクト概要

• 機能サマリー: 簡単な説明とビジネス価値
• 成功基準: 測定可能な成果と KPI
• 主要マイルストーン: タイムラインを含まない主要成果物の分解
• リスク評価: 潜在的なブロッカーと緩和戦略

2. 作業項目の階層

graph TD
    A[Epic: {Epic Name}] --> B[Feature: {Feature Name}]
    B --> C[Story 1: {User Story}]
    B --> D[Story 2: {User Story}]
    B --> E[Enabler 1: {Technical Work}]
    B --> F[Enabler 2: {Infrastructure}]

    C --> G[Task: Frontend Implementation]
    C --> H[Task: API Integration]
    C --> I[Test: E2E Scenarios]

    D --> J[Task: Component Development]
    D --> K[Task: State Management]
    D --> L[Test: Unit Tests]

    E --> M[Task: Database Schema]
    E --> N[Task: Migration Scripts]

    F --> O[Task: CI/CD Pipeline]
    F --> P[Task: Monitoring Setup]

3. GitHub Issue の分解

エピック Issue テンプレート

# Epic: {Epic Name}

## Epic Description

{Epic summary from PRD}

## Business Value

- **Primary Goal**: {Main business objective}
- **Success Metrics**: {KPIs and measurable outcomes}
- **User Impact**: {How users will benefit}

## Epic Acceptance Criteria

- [ ] {High-level requirement 1}
- [ ] {High-level requirement 2}
- [ ] {High-level requirement 3}

## Features in this Epic

- [ ] #{feature-issue-number} - {Feature Name}

## Definition of Done

- [ ] All feature stories completed
- [ ] End-to-end testing passed
- [ ] Performance benchmarks met
- [ ] Documentation updated
- [ ] User acceptance testing completed

## Labels

`epic`, `{priority-level}`, `{value-tier}`

## Milestone

{Release version/date}

## Estimate

{Epic-level t-shirt size: XS, S, M, L, XL, XXL}

フィーチャー Issue テンプレート

# Feature: {Feature Name}

## Feature Description

{Feature summary from PRD}

## User Stories in this Feature

- [ ] #{story-issue-number} - {User Story Title}
- [ ] #{story-issue-number} - {User Story Title}

## Technical Enablers

- [ ] #{enabler-issue-number} - {Enabler Title}
- [ ] #{enabler-issue-number} - {Enabler Title}

## Dependencies

**Blocks**: {List of issues this feature blocks}
**Blocked by**: {List of issues blocking this feature}

## Acceptance Criteria

- [ ] {Feature-level requirement 1}
- [ ] {Feature-level requirement 2}

## Definition of Done

- [ ] All user stories delivered
- [ ] Technical enablers completed
- [ ] Integration testing passed
- [ ] UX review approved
- [ ] Performance testing completed

## Labels

`feature`, `{priority-level}`, `{value-tier}`, `{component-name}`

## Epic

#{epic-issue-number}

## Estimate

{Story points or t-shirt size}

ユーザーストーリー Issue テンプレート

# User Story: {Story Title}

## Story Statement

As a **{user type}**, I want **{goal}** so that **{benefit}**.

## Acceptance Criteria

- [ ] {Specific testable requirement 1}
- [ ] {Specific testable requirement 2}
- [ ] {Specific testable requirement 3}

## Technical Tasks

- [ ] #{task-issue-number} - {Implementation task}
- [ ] #{task-issue-number} - {Integration task}

## Testing Requirements

- [ ] #{test-issue-number} - {Test implementation}

## Dependencies

**Blocked by**: {Dependencies that must be completed first}

## Definition of Done

- [ ] Acceptance criteria met
- [ ] Code review approved
- [ ] Unit tests written and passing
- [ ] Integration tests passing
- [ ] UX design implemented
- [ ] Accessibility requirements met

## Labels

`user-story`, `{priority-level}`, `frontend/backend/fullstack`, `{component-name}`

## Feature

#{feature-issue-number}

## Estimate

{Story points: 1, 2, 3, 5, 8}

技術的イネーブラー Issue テンプレート

# Technical Enabler: {Enabler Title}

## Enabler Description

{Technical work required to support user stories}

## Technical Requirements

- [ ] {Technical requirement 1}
- [ ] {Technical requirement 2}

## Implementation Tasks

- [ ] #{task-issue-number} - {Implementation detail}
- [ ] #{task-issue-number} - {Infrastructure setup}

## User Stories Enabled

This enabler supports:

- #{story-issue-number} - {Story title}
- #{story-issue-number} - {Story title}

## Acceptance Criteria

- [ ] {Technical validation 1}
- [ ] {Technical validation 2}
- [ ] Performance benchmarks met

## Definition of Done

- [ ] Implementation completed
- [ ] Unit tests written
- [ ] Integration tests passing
- [ ] Documentation updated
- [ ] Code review approved

## Labels

`enabler`, `{priority-level}`, `infrastructure/api/database`, `{component-name}`

## Feature

#{feature-issue-number}

## Estimate

{Story points or effort estimate}

4. 優先度と価値のマトリクス

優先度	価値	基準	ラベル
P0	高	クリティカルパス、リリースをブロック	priority-critical, value-high
P1	高	中核機能、ユーザー向け	priority-high, value-high
P1	中	中核機能、内部向け	priority-high, value-medium
P2	中	重要だがブロッキングではない	priority-medium, value-medium
P3	低	あれば尚可、技術的負債	priority-low, value-low

5. 見積もりのガイドライン

ストーリーポイントの尺度（フィボナッチ）

• 1 ポイント: 単純な変更、4 時間未満
• 2 ポイント: 小さな機能、1 日未満
• 3 ポイント: 中程度の機能、1〜2 日
• 5 ポイント: 大きな機能、3〜5 日
• 8 ポイント: 複雑な機能、1〜2 週間
• 13 ポイント以上: エピックレベルの作業、分解が必要

Tシャツサイジング（エピック/フィーチャー）

• XS: 合計 1〜2 ストーリーポイント
• S: 合計 3〜8 ストーリーポイント
• M: 合計 8〜20 ストーリーポイント
• L: 合計 20〜40 ストーリーポイント
• XL: 合計 40 ストーリーポイント以上（分割を検討）

6. 依存関係の管理

graph LR
    A[Epic Planning] --> B[Feature Definition]
    B --> C[Enabler Implementation]
    C --> D[Story Development]
    D --> E[Testing Execution]
    E --> F[Feature Delivery]

    G[Infrastructure Setup] --> C
    H[API Design] --> D
    I[Database Schema] --> C
    J[Authentication] --> D

依存関係の種類

• Blocks: これが完了するまで進められない作業
• Related: コンテキストを共有するがブロックはしない作業
• Prerequisite: 必要なインフラストラクチャまたはセットアップ作業
• Parallel: 同時に進められる作業

7. スプリント計画テンプレート

スプリントキャパシティプランニング

• チームベロシティ: {スプリントあたりの平均ストーリーポイント}
• スプリント期間: {2 週間のスプリントを推奨}
• バッファ配分: 予期しない作業とバグ修正に 20%
• フォーカスファクター: 計画作業に総時間の 70〜80%

スプリントゴールの定義

## Sprint {N} Goal

**Primary Objective**: {Main deliverable for this sprint}

**Stories in Sprint**:

- #{issue} - {Story title} ({points} pts)
- #{issue} - {Story title} ({points} pts)

**Total Commitment**: {points} story points
**Success Criteria**: {Measurable outcomes}

8. GitHub プロジェクトボードの設定

カラム構成（カンバン）

1. Backlog: 優先順位付けされ、計画可能な状態
2. Sprint Ready: 詳細化と見積もりが完了し、開発可能な状態
3. In Progress: 現在作業中
4. In Review: コードレビュー、テスト、またはステークホルダーレビュー
5. Testing: QA 検証と受け入れテスト
6. Done: 完了し、承認済み

カスタムフィールドの設定

• Priority: P0、P1、P2、P3
• Value: High、Medium、Low
• Component: Frontend、Backend、Infrastructure、Testing
• Estimate: ストーリーポイントまたは Tシャツサイズ
• Sprint: 現在のスプリント割り当て
• Assignee: 担当チームメンバー
• Epic: 親エピックへの参照

9. 自動化と GitHub Actions

Issue の自動作成

name: Create Feature Issues

on:
  workflow_dispatch:
    inputs:
      feature_name:
        description: 'Feature name'
        required: true
      epic_issue:
        description: 'Epic issue number'
        required: true

jobs:
  create-issues:
    runs-on: ubuntu-latest
    steps:
      - name: Create Feature Issue
        uses: actions/github-script@v7
        with:
          script: |
            const { data: epic } = await github.rest.issues.get({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: ${{ github.event.inputs.epic_issue }}
            });

            const featureIssue = await github.rest.issues.create({
              owner: context.repo.owner,
              repo: context.repo.repo,
              title: `Feature: ${{ github.event.inputs.feature_name }}`,
              body: `# Feature: ${{ github.event.inputs.feature_name }}\n\n...`,
              labels: ['feature', 'priority-medium'],
              milestone: epic.data.milestone?.number
            });

ステータスの自動更新

name: Update Issue Status

on:
  pull_request:
    types: [opened, closed]

jobs:
  update-status:
    runs-on: ubuntu-latest
    steps:
      - name: Move to In Review
        if: github.event.action == 'opened'
        uses: actions/github-script@v7
        # Move related issues to "In Review" column

      - name: Move to Done
        if: github.event.action == 'closed' && github.event.pull_request.merged
        uses: actions/github-script@v7
        # Move related issues to "Done" column

Issue 作成チェックリスト

作成前の準備

• フィーチャーの成果物が揃っている: PRD、UX デザイン、技術的分解、テスト計画
• エピックが存在する: 適切なラベルとマイルストーンを付けた親エピック Issue が作成済み
• プロジェクトボードが設定済み: カラム、カスタムフィールド、自動化ルールが設定済み
• チームキャパシティを評価済み: スプリント計画とリソース配分が完了

エピックレベルの Issue

• エピック Issue を作成済み、包括的な説明と受け入れ基準を含む
• エピックマイルストーンを作成済み、目標リリース日を含む
• エピックラベルを適用済み: epic、優先度、価値、チームのラベル
• エピックをプロジェクトボードに追加済み、適切なカラムに配置

フィーチャーレベルの Issue

• フィーチャー Issue を作成済み、親エピックにリンク
• フィーチャーの依存関係を特定済み、文書化済み
• フィーチャーの見積もりを完了済み、Tシャツサイジングを使用
• フィーチャーの受け入れ基準を定義済み、測定可能な成果を含む

ストーリー/イネーブラーレベルの Issue は /docs/ways-of-work/plan/{epic-name}/{feature-name}/issues-checklist.md に文書化

• ユーザーストーリーを作成済み、INVEST 基準に従う
• 技術的イネーブラーを特定済み、優先順位付け済み
• ストーリーポイントの見積もりを割り当て済み、フィボナッチスケールを使用
• 依存関係をマッピング済み、ストーリーとイネーブラー間で
• 受け入れ基準を詳細化済み、テスト可能な要件を含む

成功指標

プロジェクト管理 KPI

• スプリントの予測可能性: スプリントごとにコミットした作業の 80% 以上を完了
• サイクルタイム: 「In Progress」から「Done」までの平均時間が 5 営業日未満
• リードタイム: 「Backlog」から「Done」までの平均時間が 2 週間未満
• 欠陥流出率: ストーリーの 5% 未満がリリース後の修正を必要とする
• チームベロシティ: スプリントを通じて安定したストーリーポイントのデリバリー

プロセス効率の指標

• Issue 作成時間: 完全なフィーチャー分解の作成に 1 時間未満
• 依存関係の解決: ブロッキング依存関係の解決に 24 時間未満
• ステータス更新の正確性: 95% 以上の自動ステータス遷移が正常に動作
• ドキュメントの完全性: 100% の Issue が必要なテンプレートフィールドを備える
• チーム間コラボレーション: 外部依存関係の解決に 2 営業日未満

プロジェクト納品メトリクス

• 完了の定義への準拠: 完了したストーリーの 100% が DoD 基準を満たしています
• 受け入れ基準のカバレッジ: 受け入れ基準の 100% が検証されています
• スプリント目標の達成: スプリント目標の 90% 以上が正常に納品されています
• ステークホルダー満足度: 完了した機能に対するステークホルダーの承認率が 90% 以上
• 計画精度: 見積もり時間と実際の納品時間の差異が 10% 未満

この包括的な GitHub プロジェクト管理アプローチにより、エピックレベルの計画から個々の実装タスクに至るまで完全なトレーサビリティが確保され、自動追跡とすべてのチームメンバーの明確な責任体制が実現します。