GitHub Issue作成
.github/ISSUE_TEMPLATE/のテンプレート形式に準拠したGitHub Issueを作成します。
利用可能なテンプレート
| テンプレート | 用途 | ラベル |
|---|---|---|
| bug_report.yml | バグ報告 | bug |
| feature_request.yml | 機能リクエスト | enhancement |
| todo.yml | タスク・作業項目 | todo |
Issue作成原則
- •テンプレート準拠: 必ず既存のテンプレート形式に従う
- •適切な粒度: Pull Requestの粒度と対応するサイズに分割
- •分割戦略: 大きすぎる場合は複数のIssueに分割
- •明確な受け入れ基準: 完了条件を明確に定義
- •関連性の明示: 関連するIssueやPRをリンク
Issue粒度ガイドライン
適切な粒度
- •1つのPRで完結できる作業単位
- •1〜3日程度で完了可能なタスク
- •明確な受け入れ基準を持つ
- •単一の責任を持つ変更
分割が必要なケース
- •複数の機能を含む大規模な変更
- •異なるコンポーネントへの変更
- •段階的にリリースすべき機能
- •依存関係が複雑なタスク
分割戦略
- •機能単位: 各機能を独立したIssueに
- •レイヤー単位: フロントエンド/バックエンドで分割
- •段階単位: Phase 1, Phase 2として分割
- •依存関係順: 依存関係に基づいて順序付け
メインissueとsub issueの活用
大きな機能や改善を複数のPRに分割して実装する場合、メインissueとsub issueの親子関係を活用します。
メインissueとsub issueの定義
メインissue
- •目的: 全体として達成したい大きな機能や改善を表現
- •役割:
- •プロジェクト全体の目的と背景を説明
- •すべてのsub issueの進捗を一元管理
- •完了条件（Definition of Done）を明確化
- •粒度: 複数のPRに分割される大規模な作業
- •完了条件: すべてのsub issueが完了した時点でクローズ
sub issue
- •目的: メインissueを実装可能な単位に分割したタスク
- •役割:
- •個別のPRと1対1で対応
- •具体的な実装内容を詳細に記述
- •独立してレビュー・マージ可能な作業単位
- •粒度: 1つのPRで完結できるサイズ（1〜3日程度）
- •完了条件: 対応するPRがマージされた時点でクローズ
sub issueとPRの関係
- •1対1の原則: 1つのsub issueは必ず1つのPRに対応
- •自動クローズ: PRマージ時に
Closes #123で自動的にsub issueをクローズ - •進捗の可視化: メインissueのタスクリストでsub issueの完了状況を追跡
sub issue作成のガイドライン
作成タイミング
- •メインissueを作成した直後
- •実装計画が明確になった時点
- •必要に応じて段階的に追加
粒度の目安
- •1〜3日で完了可能な作業量
- •単一の機能や責任を持つ変更
- •他のsub issueと独立してマージ可能
- •レビューが容易なサイズ（変更ファイル数: 概ね10ファイル以下）
命名規則
code
[メインissue番号] 具体的な作業内容
例:
- •
#123 ユーザー認証APIの実装 - •
#123 認証ミドルウェアの追加 - •
#123 認証機能のフロントエンド統合
タイトルの付け方
- •メインissue番号を含める（任意だが推奨）
- •実装する機能や変更内容を明確に
- •動詞から始める（実装、追加、修正、更新など）
メインissue本文での進捗管理
メインissueの本文にタスクリストを使用してsub issueを管理します。
タスクリストの書き方
markdown
## Sub Issues - [ ] #456 データベーススキーマの設計と実装 - [ ] #457 APIエンドポイントの実装 - [ ] #458 フロントエンドUIの実装 - [ ] #459 テストコードの追加
GitHubの自動連携
- •sub issueがクローズされると、タスクリストのチェックボックスが自動的にチェックされる
- •メインissueの進捗が視覚的に把握できる
- •すべてのチェックボックスがチェックされたら、メインissueをクローズ
sub issueの関連付け方法
メインissue → sub issue
メインissueの本文に記載:
markdown
## Sub Issues このissueは以下のsub issueに分割されています: - [ ] #456 データベーススキーマの設計と実装 - [ ] #457 APIエンドポイントの実装 - [ ] #458 フロントエンドUIの実装
sub issue → メインissue
sub issueの本文に記載:
markdown
## 関連Issue 親issue: #123
PR → sub issue
PRの本文に記載:
markdown
Closes #456
活用例
例: ユーザー認証機能の実装
メインissue #123: ユーザー認証機能の実装
markdown
## 説明 ユーザー認証機能を実装し、ログイン・ログアウト・セッション管理を可能にする。 ## Sub Issues - [ ] #124 データベースにusersテーブルを追加 - [ ] #125 認証APIエンドポイントの実装 - [ ] #126 認証ミドルウェアの追加 - [ ] #127 ログイン画面UIの実装 - [ ] #128 認証機能の統合テスト ## 完了条件 - すべてのsub issueが完了している - 統合テストがパスしている - ドキュメントが更新されている
sub issue #124: データベースにusersテーブルを追加
markdown
## 説明 ユーザー認証に必要なusersテーブルをデータベースに追加する。 ## 関連Issue 親issue: #123 ## 受け入れ基準 - [ ] マイグレーションファイルが作成されている - [ ] id, email, password_hash, created_at, updated_atカラムが含まれる - [ ] emailカラムにユニーク制約が設定されている
PR #150: データベースにusersテーブルを追加
markdown
## 概要 ユーザー認証機能のためのusersテーブルを追加します。 Closes #124 ## 変更内容 - usersテーブルのマイグレーションファイルを追加 - ...
注意事項
- •過度な分割を避ける: 小さすぎるsub issueは管理コストが増加
- •依存関係を明確に: sub issue間の依存関係がある場合は本文に記載
- •柔軟な調整: 実装中に粒度が適切でないと判明した場合は再分割や統合を検討
- •命名の一貫性: プロジェクト内で命名規則を統一
テンプレート別の記載項目
Bug Report (バグレポート)
- •説明: バグの内容を明確に記述
- •再現手順: ステップバイステップで記載
- •期待される動作: 正常な動作の説明
- •実際の動作: 発生している問題
- •環境: Development/Staging/Production
- •スクリーンショット: 必要に応じて添付
Feature Request (機能リクエスト)
- •問題提起: 解決したい課題
- •提案する解決策: 実装したい内容
- •検討した代替案: 他の選択肢
- •追加情報: モックアップ、参考資料
TODO (タスク)
- •説明: 実施内容の明確な記述
- •優先度: Low/Medium/High/Critical
- •カテゴリ: Feature/Enhancement/Refactoring/Documentation/Testing/Infrastructure/Other
- •受け入れ基準: 完了条件のチェックリスト
- •技術的メモ: 実装の詳細や考慮事項
- •関連Issue: 関連するIssue/PRのリンク
Issue作成手順
- •要件分析: 依頼内容の理解と分析
- •粒度判定: 適切なサイズか評価
- •分割判断: 必要に応じて複数Issueに分割
- •テンプレート選択: 適切なテンプレートを選択
- •内容作成: テンプレートの全項目を埋める
- •関連性設定: 関連IssueやPRをリンク
- •Issue作成:
gh issue createコマンドで作成
出力形式
単一Issue作成時
- •テンプレート種別
- •タイトル
- •各フィールドの内容
- •ラベル
- •作成コマンド
複数Issue作成時（分割）
- •分割理由の説明
- •各Issueの概要と関連性
- •Issue間の依存関係
- •各Issueの詳細（上記と同様）
- •作成順序の推奨