チーム運用ルール v1

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

基本方針

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

チケットのルール

親チケット(種別: 機能追加 / 改善)

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

子チケット(種別: タスク)

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

原則

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

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

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

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



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



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

- [ ] 
- [ ] 
- [ ] 

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

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



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



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



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

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

## 親課題
関連: 

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

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

## 技術方針(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のレトロでルール自体も見直します。
不都合があれば遠慮なく提案してください。