# チーム運用ルール v1

3人チーム(室長 / シニアエンジニア / ジュニアエンジニア)の運用ルールとチケットテンプレート集。

---

## 基本方針

- スクラムは組まない。**カンバン + 週1棚卸し**で回す。
- チケットは2層構造: **親(What/Why) × 子(How/How much)**
- 技術スタックの決定は**技術チームを必ず通す**

---

## チケットのルール

### 親チケット(種別: 機能追加 / 改善)
- **書く人**: 依頼者(主に室長)
- **内容**: What(何を) / Why(なぜ) / 完成の判断基準 / 希望時期
- **書かないこと**: 技術スタック、実装方法(技術チームで検討します)
- **起票タイミング**: 随時。週1棚卸しで整えます。

### 子チケット(種別: タスク)
- **書く人**: 技術チーム(シニア or ジュニア)
- **内容**: 前提確認 / 技術方針 / サブタスク / 見積り / リスク
- **起票タイミング**: 週1棚卸しで親を分解、または着手前

### 原則
- 親チケットの**完成の判断基準が埋まっていない**場合、着手しない
- 子チケットの**前提確認欄は必ず文字で書く**(口頭で済ませない)
- 範囲外の追加依頼は**必ず子チケット化して見積りを出してから着手**

---

## 親課題テンプレート(種別: 機能追加 / 改善)

Backlog設定 → 種別 → 各種別の「テンプレート」欄に貼り付け。

```markdown
## 何をしたいか(What)
> 実現したいことを1〜3行で。技術用語は不要、やりたいことをそのまま書いてください。



## なぜやりたいか(Why)
> 背景・目的。どの課題を解決するか、誰が嬉しいか。



## 完成の判断基準(Acceptance Criteria)
> 「こうなっていればOK」を箇条書きで。3〜5個目安。
> ここが埋まっていないチケットは着手しません。

- [ ] 
- [ ] 
- [ ] 

## 優先度・希望時期
- 優先度: 高 / 中 / 低
- 希望時期: YYYY/MM/DD 頃

## 参考情報(任意)
> 参考URL、類似サービス、関連資料など。雑でOK。



## 技術的な希望(任意)
> 使ってほしい技術、参考にしたい仕組みなどがあれば記入してください。
> **指定する場合は「なぜそれを使いたいか」もあわせて書いてください。**
> (例: 「◯◯を使いたい。理由は過去案件で実績があるため」)
> 理由が技術的に妥当か技術チームで確認し、より適した選択肢があればご提案します。



## 技術チームへの相談事項(任意)
> 「ここは任せたい」「この方法でできる?」など、迷っている点があれば。
> ここは気軽に書いてください。技術的な答えはこちらで整理します。



---
### 記入ガイド
- 技術スタックや実装方法は基本的に書かなくてOKです(こちらで検討します)
- 書きにくければ箇条書きで投げてください、週1棚卸しで一緒に整えます
- 子課題(実装タスク)は技術チームが作成します
```

---

## 子課題テンプレート(種別: タスク)

```markdown
## 親課題
関連: 

## 前提確認
> 親課題を読んで、自分の理解を明文化。認識齟齬を防ぐための欄。
> 口頭で済ませず必ずここに文字で書く。

- やること: 
- やらないこと: 
- 不明点・確認したいこと: 

## 技術方針(How)

### 使用技術・ライブラリ
> 親課題に技術指定があった場合、その妥当性検証結果もここに記載。


### 実装アプローチ
> どういう構成で作るか。ファイル構成、データフロー、主要な設計判断。


### 影響範囲
> 既存のどこに触るか、依存関係。


## サブタスク分解
> AIに投げやすい粒度(1タスク1ファイル/1関数目安)まで分解。

- [ ] 
- [ ] 
- [ ] 

## 見積り(How much)
- 想定工数: 〇人日
- 着手可能日: YYYY/MM/DD
- 完了目標: YYYY/MM/DD

## リスク・懸念
> 技術的に引っかかりそうな点、事前に潰しておきたい点。
> ここに書いたことは週1棚卸しで共有。



## AI活用メモ(任意)
> どの部分をAIで進めるか、プロンプト方針など。
> **AIに投げる前に「自分はこう思う」という仮説を1行書いてから投げる。**


```

---

## ミーティング

### 週1チケット棚卸し(30分〜1時間)
- **参加者**: 全員
- **内容**:
  - 新規の親チケットを一緒に整理(室長の口頭依頼をその場でチケット化)
  - 既存チケットの優先度・進捗確認
  - 子チケット分解と見積り
  - リスク・懸念の共有

### 週1レトロ(15〜30分)
- **参加者**: 技術チーム(必要に応じて室長も)
- **内容**:
  - 詰まった点の共有
  - AI活用の効率化ポイント
  - プロセス改善の提案

### デイリーは非同期
- 朝会はなし。進捗共有は**Slackの分報 or Backlogのコメント**で。
- 詰まったら即Slackで相談する。

---

## ガントチャート

- **親チケットのみ表示**(種別フィルタで「機能追加 / 改善」に絞る)
- 子チケットはボードで管理、ガントには出さない
- 親の期間は、子の見積り合計を反映してから確定
- 長期案件はマイルストーンで節目を可視化

---

## AI活用ルール

### プロンプトを打つ前に仮説を1行書く
- AIを「答えの出力装置」ではなく「検証装置」として使う
- 子チケットの「AI活用メモ」欄に仮説を記入
- シニアレビュー時は仮説部分にもコメントする

### チケット粒度はAIに投げやすい単位まで分解
- 1タスク1ファイル / 1関数を目安
- 分解自体がシニアの設計判断

---

## 技術スタックの決定

- **技術スタックは技術チームを必ず通す**
- 案件ヒアリング段階から技術チームが関与
- 室長の独断で技術選定・発注はしない
- 親チケットに技術指定がある場合、**指定理由を明記してもらう**
  - 理由の妥当性を技術チームで検証
  - より適した選択肢があれば代替案を提示
- 事前相談がなかった案件でトラブルが発生した場合、対応は**工数計上した上で**引き受ける

---

## トラブル・振り返り

- 技術的な齟齬やトラブルが発生した案件は、**技術ログ**として記録を残す
- 責めるためではなく、次に同じ事が起きた時の参照資料
- Wikiに「技術ログ」ページを作成し、案件ごとに追記

---

## 禁則事項

- 技術スタックを技術チーム不在で決めない
- 「わかってるから作れ」での丸投げ依頼(完成の判断基準を必ず書く)
- 口頭指示での作業開始(必ずチケット化)
- チケットなしの追加作業(後で揉める)

---

## 運用の見直し

このルールは固定ではありません。月1のレトロでルール自体も見直します。
不都合があれば遠慮なく提案してください。