終会〜進捗報告と課題共有

• 日程: Day 15 / セッション 03
• 時間: [12:20-12:40]（20分）
• 形式: 演習（グループワーク）
• ゴール: かんばんを更新し、完成までの残タスクを把握できる

  • 行動: 終会フォーマットで進捗共有し、残タスクから「削る候補」を1件以上挙げる
  • 条件: 20分以内に、残り日数（Day16-17）から逆算する
  • 基準: 残タスクが残り日数で消化可能な量に収まっている、または削減候補が明示されている
• 学習形式: グループワーク

実装スプリント4お疲れ様でした。フィードバック反映、進みましたか？

ここからが正念場です。明日Day16はテスト・品質向上、明後日Day17は仕上げ。実装期間は実質あと2日。残タスクを今日終会の時点で正確に把握しないと、Day17に「あと10個残ってる…」というパニックが起きます。

そして、今日の終会で身につけてほしい姿勢があります。間に合わない機能は削る判断をする。「全部やる」を諦める勇気は、Day14の終会と同じテーマですが、今日は「自分たちが作ったもの」を削る場面が出てきます。これは精神的にしんどい判断です。でも、ちぐはぐな完成より、中核の完成度を優先します。

終会で共有するのは、朝会と似た3点セットですが、内容が違います。

朝会との違いは「Doneに移した実績」を必ず言うこと。「やったつもり」ではなく「Doneに移した」が基準です。

終会議事録テンプレート

# Day15 終会議事録
日付: YYYY-MM-DD / 12:20-12:40
出席: 〇〇, 〇〇, 〇〇, 〇〇

## 個別共有（1人1分）

### 〇〇（PM）
- 完了: スマホ対応の調査、ライブラリ選定
- 困りごと: レスポンシブ対応は工数オーバー、MVP範囲再検討必要
- 明日: MVP範囲を再合意して着手

### 〇〇（リーダ）
- 完了: エラー文言修正（チケット#3、Done）、デグレード確認OK
- 困りごと: なし
- 明日: テスト計画の作成に協力

### 〇〇（開発）
- 完了: 予約一覧キャッシュ導入（チケット#1、Done）
- 困りごと: キャッシュ無効化のタイミングをもう少し詰めたい
- 明日: テスト実施、デグレードチェック

## かんばんサマリー
- Done: 12タスク（昨日比+2）
- Doing: 3タスク
- Todo: 7タスク（残り2日で消化）

## 削減候補（チーム合意が必要）
- スマホ対応の全画面適用 → ペルソナ主要動線（トップ→予約）のみに縮小
- ロゴデザイン刷新 → 見送り（Day22以降）

## 明日の優先順位
1. テスト計画作成
2. デグレード総点検
3. スマホ対応MVP範囲の実装

「Doingが3つ以上」は危険信号。誰か1人に集中している場合は明日助けに行く判断をします。

要件管理の世界には「MoSCoW法」という優先順位の付け方があります。M=Must（必須）、S=Should（重要）、C=Could（できれば）、W=Won't（今回はやらない）の頭文字を取ったもの。「やる/やらない」ではなく、4段階で仕分けると判断がしやすくなります。残り2日でM=Must だけは絶対終わらせる、Cは余裕があればやる、と決めると気持ちが軽くなります。

「自分が作ったものを削る」のは辛い判断です。基準があれば迷いません。

「核となる体験」とは、CJM（To-Be版）の中心動線。ペルソナが「これがあるから使いたい」と思う部分です。装飾的な機能（アニメーション、見栄え系、おまけ機能）は削っても核は揺らぎません。

終会のたびにかんばんを更新します。ここで甘くするとDay17で実態が分からなくなります。

「ほぼDone」「コードはDone」は禁止語。完全に4点揃ったらDone、それ以外はDoing。これで実態がブレません。

Done定義は曖昧にしない。チームで「Doneとは何か」を一度明文化して、終会の時に毎回確認する。

終会の後、AIに以下のように相談しましょう。

• 「以下の残タスク一覧から、Day16-17で完了不可能なものを抽出して理由も：（タスク一覧貼り付け）」
• 「以下の機能のうち、ペルソナの『核となる体験』に必要なものを判定して：（機能一覧貼り付け）」
• 「Day16のテスト計画案を作って。観点は機能・デグレード・異常系：（残タスク貼り付け）」

20分の終会で以下を完了させてください。

1. 終会フォーマットで3点セットを共有
2. かんばんをDone/Doing/Todoの実態に合わせて更新
3. 残タスクから「削減候補」を1件以上挙げてチーム合意
4. Day16の優先順位を3つ決める

• 終会議事録
• 更新済みかんばん（Done/Doing/Todoの数値つき）
• 削減候補リスト（または「削減不要」の明示的判断）
• Day16優先順位リスト

• 「Doing」が増えすぎていたら、明日完了するものに絞る
• 削る判断で迷ったら「ペルソナが気づくか？」を基準に
• 削減判断に時間がかかる場合、AIに優先度提案を依頼

終会は3点セット（完了/困りごと/明日）。かんばんは実態に合わせて更新（Done定義を厳密に）。残タスクが多いなら削る判断を今日する。明日Day16はテスト、明後日Day17は仕上げ。残り2日を見据えて選択と集中。

• 今日Doneに移したタスクを言えますか？
• 残タスクが残り日数で消化可能な量か判断できましたか？
• 削るか残すかの判断に「ペルソナの体験」基準を使えましたか？

• 参考: MoSCoW法、スコープボックスとタイムボックス、リーン開発の「ムダの排除」
• 発展課題: Day16朝会用に「テスト計画の骨子」を1ページにまとめておく