Top

Issue作成方針

本ドキュメントでは、Issue（課題）を作成する際のガイドラインをまとめます。 円滑な開発と進捗管理、および情報の透明性を高めることを目的としています。

目次

• Issueの粒度
• Issueの構成
  • タイトル
  • 本文
• Issue構成の参考例
• 運用ルール

---

Issueの粒度

Issueは、作業の最小単位として定義されることが望ましいです。

• 1つのIssue = 1つの具体的な目的（タスク/バグ修正/機能提案）:
  • 複数の異なるタスクが含まれる場合は、チェックリストを活用するか、複数のIssueに分割してください。
• 完了定義（Definition of Done）が明確であること:
  • 何をもってこのIssueが「完了」したと言えるかを明確にします。

Issueの構成

誰が見ても内容が理解できるように、情報を整理して記載します。

タイトル

• 簡潔かつ具体的: 内容が一目でわかるようにします（例: ログイン画面のバリデーション不具合の修正）。
• プレフィックスの活用: 可能であれば、カテゴリを明示します。
  • feat:: 新機能
  • fix:: バグ修正
  • docs:: ドキュメント修正
  • chore:: 雑務、環境構築など

本文

以下の情報を網羅するように記載します。

• 背景・目的: なぜこの作業が必要なのか。
• 対応内容: 具体的に何をすべきか（タスクリスト形式を推奨します）。
• 完了条件: 作業完了と判断する基準。
• 参考情報: 関連ドキュメント、スクリーンショット、参考URL、関連するPRなど。

Issue構成の参考例

Issue作成時は、以下の構成を参考に必要な情報を記載してください。

【バグ報告の場合】

## 概要
（バグの簡潔な説明）

## 再現手順
1. 
2. 
3. 

## 期待される挙動
（本来どうなるべきか）

## 実際の挙動
（実際はどうなっているか）

## 環境
- OS/ブラウザ: 
- バージョン: 

## その他
（スクリーンショットやログなど）

【機能追加・改善・タスクの場合】

## 概要・目的
（何のために、何をするのか）

## 対応内容
- [ ] 
- [ ] 

## 完了条件
- [ ] 

## 参考情報
- 

運用ルール

• アサイン: 着手する際は自分をアサインし、ステータスを明確にします。
• PRとの紐付け: PR作成時は、Closes #123 のように記載し、IssueとPRを関連付けます。
• コメントでの議論: 設計判断や懸念点はIssueのコメントに残し、後から経緯を追えるようにします。

---

関連ドキュメント:

• Pull Request作成方針
• コードレビュー観点
• コミット規約