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

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

2日目の終会です。今日は設計書との突き合わせがテーマでした。設計を更新した人、コードを直した人、それぞれの結果を持ち寄りましょう。

ここで大切なことを1つ。進捗が遅れていたとき、それは「誰かのせい」ではありません。

遅れは「人」ではなく「タスクの大きさ・順序」の問題として扱う。

これがチーム開発のルールです。原因を人に向けると、次から正直な報告が出なくなり、チームの目が曇ります。

20分の使い方は昨日と同じです。

今日は「設計変更の共有」が増えました。誰が・どの設計書を・なぜ・どう変えたかを30秒で共有します。

報告テンプレート。

【できたこと】
- 会員登録 入力チェック実装、Done。

【設計変更】
- 機能設計書 §3.2 にパスワード確認入力欄を追加。理由: ユーザーが入力ミスに気づけないため。

【困っていること】
- 重複チェック処理が遅い。検索インデックスについて明日AIに相談したい。

【明日の予定】
- 会員一覧 検索機能 着手。お昼までに動く状態を目指す。

• 設計変更は必ず全員に共有する（昨日と前提が変わった人がいるかも）
• 「困りごと」は今日も1つ
• 遅れは数字で報告。「3割遅れ」より「予定2タスクのうち1つ未着手」が伝わる

進捗の伝え方の研究で、「順調」「遅れ気味」のような感覚語で報告された進捗は、後で実態と60%以上ずれていた、というデータがあります。一方、数字（完了タスク数/全タスク数）で報告された進捗のズレは15%以下でした。言葉のあいまいさは善意でも害になります。終会では数字で話しましょう。

遅れがあったら、原因をチームで分析します。視線を「人」に向けない型を使います。

遅れ対策の合意例。

【遅れたタスク】会員登録の入力チェック (予定: 完了 → 実態: 80%)

【原因分析】
- タスクが大きすぎた (5項目分の入力チェックを1タスクにしていた)

【対策】
- タスクを2つに分割: 「必須項目チェック」と「形式チェック」
- 形式チェックは明日午前にAさんが担当 (Bさんとペア)

【決定者】チーム全員、終会時刻 12:35

「Bさんの作業が遅い」ではなく「タスクが大きすぎた」と言い換えることで、解決可能な問題になります。

• 主語を「人」ではなく「タスク」「順序」「環境」にする
• 対策は1つ以上、必ず決める（先送り禁止）
• 決定はかんばんに反映してから解散する

「責めない・隠さない・嘘つかない」を意味する Blameless（ブレームレス）という文化が、近年のIT現場で広がっています。GoogleやNetflixでは、大障害の事後分析（ポストモーテム）で個人を責めない決まりがあります。理由は単純で、責めると次から正直な情報が出なくなり、もっと大きな障害を招くからです。研修中の終会も、同じ精神で運営しましょう。

終会の質を上げるためにAIに聞けること。

• 「Blameless culture（責めない文化）の実例を3つ教えて」
• 「タスクが大きすぎた、を判定する基準は?」
• 「終会で対策を決めるとき、抜けがちな観点を教えて」

司会1名・書記1名を決めて、終会を実施してください。

1. 司会宣言
2. 1人1分の報告（できたこと・設計変更・困りごと・明日の予定）
3. 設計変更の全体共有
4. かんばん更新
5. 遅れがあれば原因と対策をチームで合意
6. 解散

• 実態に合ったかんばん
• 設計変更の記録（今日更新した設計書一覧）
• 遅れ対策のメモ（明日の朝会で再確認）

今回学んだことを一言でまとめると「遅れは正直に・原因はタスクへ・対策は1つ決めて解散」です。

• 設計変更は終会で全員共有
• 進捗は数字で報告
• 遅れの原因は「人」ではなく「タスク・順序・環境」

明日はチームコードレビューです。レビューに出すコードを意識しておきましょう。

• 遅れの原因を分析するとき、視線を向けてはいけないのは?
• 進捗報告は感覚語と数字、どちらで?
• 設計変更を終会で共有する理由は?

• 参考リンク: 自チームのかんばん、当日更新した設計書
• 発展課題: Blameless culture について調べてチームに3分で発表する準備をしておく

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