handover-process

# 申し送り処理ガイド (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**に以下のフォーマットでコメントを投稿します。 可能であれば、相手側の担当者をメンションしてください。 **テンプレート:** ```markdown ## :mega: 申し送り事項 (Handover) **対象領域**: [Frontend / Backend / Infra] **種別**: [API変更 / 要望 / その他] **優先度**: [High / Medium / Low] ### 内容 [変更や依頼の概要を簡潔に] ### 詳細・変更点 - **Before**: [変更前] - **After**: [変更後] ### Action Required - [ ] [具体的なタスク1] - [ ] [具体的なタスク2] cc: `frontend-team` skill ``` ### 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する際、未消化の申し送り（未チェックの箱）がないか必ず確認する。