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

• 日程: Day 12 / セッション 3
• 時間: [12:20-12:40]
• 形式: 演習
• ゴール: かんばんを更新し、進捗の遅れがあれば原因と対策をチームで1つ以上決められる
• 学習形式: グループワーク（話す＆行う）

実装2日目の終会です。今日は昨日の終会に1つ要素が加わります。「遅れの扱い方」です。

実装期間は実働あと5日、明後日は中間発表。計画とのずれが見え始める頃です。ずれ自体は問題ではありません。天気予報と同じで、予報がずれたら直せばよいのです。問題なのは、ずれを見なかったことにすることです。

1. 1人1分で報告する（人数×1分）

   • 今日できたこと（かんばんのタスク名で）
   • 困っていること（必ず1つ）
   • 明日やる予定
2. かんばんを実態に合わせて更新する（4分）

   • Done/Doing/Todoを正直に動かす。設計書の更新漏れがないかも確認
3. 遅れの確認と対策決め（5分）

   • 計画（ガントチャート）と現状を見比べ、遅れているタスクを特定する
   • 遅れの原因を「タスクの大きさ・順序」の言葉で言い直す
   • 対策を1つ以上決める（分割する／順序を変える／助けを入れる／削る候補にする）

大事な約束があります。遅れは「人」ではなく「タスクの大きさ・順序」の問題として扱います。「○○さんが遅い」は禁止です。「このタスクが思ったより大きかった。2つに割ろう」が正しい言い方です。同じ事実でも、人を責める言葉はチームを止め、タスクを見る言葉はチームを進めます。

• 遅れの報告を歓迎する。早く分かった遅れは対策できる遅れ
• 対策は具体的に1つ決める。「頑張る」「急ぐ」は対策ではない
• 明後日が中間発表。「発表で見せたい機能」から逆算して残タスクを眺める

「遅れているプロジェクトに人を追加すると、さらに遅れる」。これはソフトウェア工学の古典『人月の神話』（1975年）で示された有名な法則で、ブルックスの法則と呼ばれます。新しい人への説明に時間を取られるからです。つまり遅れの対策は「人を増やす」より「タスクを小さくする・減らす」が基本なのです。半世紀前の知見が、皆さんのかんばんの上で今日も生きています。

以下の問いに答えられるか確認してみましょう：

• 遅れは「人」ではなく何の問題として扱いますか？
• 今日チームで決めた対策は何ですか？
• 設計書とかんばんは、今日の実態と一致していますか？

答えに自信がない場合は、該当部分を読み返すか、AIに質問してみてください。

このセクションは、受講者が理解を深めることをサポートする参考情報です。