handover-process

name	handover-process
description	バックエンド/フロントエンド間などの領域を跨ぐ変更依頼や情報共有（申し送り）のプロセスをGitHub Issue中心で定義

申し送り処理ガイド (Issue Base)

本ドキュメントは、バックエンド/フロントエンド間などの領域を跨ぐ変更依頼や情報共有（申し送り）のプロセスを定義します。

変更点(v2.0): ファイル管理（JSON）を廃止し、GitHub Issueを中心としたコミュニケーションに統合しました。

---

1. 申し送りとは

開発中にバックエンド(BE)とフロントエンド(FE)、あるいはインフラなどの間で発生する、相互の変更依頼や情報共有のことです。

1.1 申し送りの種類

方向	種別	ラベル	説明
BE→FE	API変更	handover:api-change	API仕様の変更通知
BE→FE	エラーコード	handover:error-code	新規エラーコードの通知
FE→BE	API要望	handover:api-request	必要なAPIの作成依頼
共通	仕様変更	handover:spec-change	設計書自体の修正が必要な場合

---

2. 運用フロー（GitHub Issue活用）

2.1 申し送りの作成（起票者）

実装中に他領域への依頼が発生した場合、現在の作業Issueに以下のフォーマットでコメントを投稿します。 可能であれば、相手側の担当者をメンションしてください。

テンプレート:

## :mega: 申し送り事項 (Handover)

**対象領域**: [Frontend / Backend / Infra]
**種別**: [API変更 / 要望 / その他]
**優先度**: [High / Medium / Low]

### 内容
[変更や依頼の概要を簡潔に]

### 詳細・変更点
- **Before**: [変更前]
- **After**: [変更後]

### Action Required
- [ ] [具体的なタスク1]
- [ ] [具体的なタスク2]

cc: @frontend-team

2.2 申し送りの検知と対応（受取手）

1. 実装開始前: Issueのコメントを「Handover」や「申し送り」で検索し、未完了のチェックボックス（- [ ]）があるか確認します。
2. 対応:
   • 依頼内容を実装します。
   • 完了したらチェックボックスを埋めます（- [x]）。
3. 疑問点: そのコメントへの返信（Reply）で確認します。

2.3 設計書への反映（重要）

申し送り内容が「設計書」と乖離する場合、実装より先に設計書の修正が必要です。

1. コメントに spec_update_required と明記します。
2. /request-design-fix コマンドを使用して設計書の修正を依頼するか、軽微な場合は自分で修正PRを含めます。

---

3. シナリオ別対応

Case A: バックエンド実装中にAPIレスポンスが変わった

1. BE担当: 実装修正。
2. BE担当: Issueに「BE→FE申し送り」コメント投稿。
   • レスポンスのDiffを貼る。
   • 「FEの型定義更新をお願い」とチェックボックスを作成。
3. FE担当: 実装開始時にコメント確認。型定義を更新し、チェックボックスをOnにする。

Case B: フロントエンド実装中にAPI不足に気づいた

1. FE担当: 実装の手を止める（またはモックで進める）。
2. FE担当: Issueに「FE→BE申し送り」コメント投稿。
   • 「この画面でこのデータが必要」と具体的に記述。
3. BE担当: 通知を受け取り（または翌日確認し）、APIを追加実装。完了報告。
4. FE担当: API結合実装。

---

4. ルール

1. チェックボックス必須: タスクは必ずチェックボックス形式にし、完了状態を可視化する。
2. Issueを分けすぎない: 密結合な機能の場合、同じIssue内で会話する方が効率的。
3. 解決しないとClose禁止: IssueをCloseする際、未消化の申し送り（未チェックの箱）がないか必ず確認する。