終会〜進捗報告と課題共有
概要
- 日程: Day 15 / セッション 3
- 時間: [12:20-12:40]
- 形式: 演習
- ゴール: かんばんを更新し、完成までの残タスクを把握できる
- 学習形式: グループワーク（話す＆行う）
- 本日のテーマ: フィードバック反映の結果を確認し、残り実働2日の現実と向き合う
進め方（20分）
フィードバック反映の1日、お疲れさまでした。今日の終会には特別な仕事があります。
残り実働2日。「全部は作れない」前提で、何を削るかを決めることです。
次の流れで進めます。
| 時間 | 内容 |
|---|---|
| 5分 | 1人1分で報告（できたこと・困っていること・明日やること） |
| 5分 | かんばん更新（Done/Doing/Todoを実態に合わせる） |
| 7分 | 残タスクの棚卸しと「削る」判断 |
| 3分 | 明日（品質向上とテスト）の進め方を確認 |
「削る」判断のやり方
残タスクをすべて並べ、次の問いで仕分けます。
- 発表で見せる「核となる体験」に必要か → 必要なら残す
- なくてもデモが成立するか → 成立するなら削る候補
- 削る場合、作りかけのまま見えてしまわないか → 入口ごと消す方がきれい
判断に迷ったらAIを使いましょう。
- 「残タスク一覧と残り実働2日という条件を貼る。発表デモを成立させる観点で、削る候補を理由つきで挙げて」
- 「この機能を削った場合、画面遷移図のどこに穴が空くか確認したい。遷移図を貼るのでチェックして」
ここがポイント
- 削るのは「失敗」ではなく「設計判断」。実務でもスコープ調整は日常的に行われる
- 削ると決めた機能は、かんばんで「対応しない」置き場に移す。Todoに残すと心理的な負債になる
- 今日デグレード確認で見つけた気になる挙動は、明日のテストのタネとしてメモに残す
まとめ
残タスクが「やり切れる量」になっていれば今日は合格です。明日は作る時間と確かめる時間を分けて、品質を上げる日です。
🔄 振り返りチェック
以下の問いに答えられるか確認してみましょう：
- 完成までの残タスクが何件で、合計どれくらいの時間が必要か言えるか
- 削ると決めた機能と、その理由を説明できるか
- 明日のテストで真っ先に確かめたい箇所を1つ挙げられるか
答えに自信がない場合は、かんばんの前でチームと話し合ってみてください。
学習ガイド
このセクションは、受講者が理解を深めることをサポートする参考情報です。
想定される質問と回答例
| 質問 | ヒント |
|---|---|
| 削る判断にメンバーが反対している | 「核となる体験に必要か」という基準に立ち返る。人の好みではなく、ペルソナとデモの観点で議論する |
| 残タスクの見積もりに自信がない | 今日実際にかかった時間と比べる。「今日の自分たちの実績」がいちばん正確な見積もり材料 |
| 削った機能を発表でどう扱う？ | 隠す必要はない。「今後の拡張」として発表で語れば、むしろ計画性のアピールになる |
つまずきやすいポイント
| つまずきポイント | ヒント |
|---|---|
| 「明日がんばれば全部できる」と楽観して削らない | 今日の実績（完了タスク数）を残り2日に掛け算する。実績を超える計画は計画ではなく願望 |
| かんばん更新が報告と食い違う | 報告した内容をその場でカードに反映する。「あとで更新」は忘れる |
| 困っていることを言い出せない | Day 11から続けてきた文化を思い出す。「困りごとを1つ共有する」は全員のノルマ |