朝会〜本日の作業計画

• 日程: Day 13 / セッション 1
• 時間: [9:30-9:40]
• 形式: 演習
• ゴール: 本日の作業予定とレビューの時間配分をチームで合意できる
• 学習形式: グループワーク

おはようございます。実装3日目、そして明日は中間発表です。

今日のキーワードは「チームコードレビュー」と「中間発表準備」です。実装の手を一旦止めて、書いたコードをチームで見せ合います。レビューは時間を食うので、今日の時間配分を朝会で必ず決めます。

明日に「動くもの」を最低1つは見せる必要があります。今日の終わりまでに何が動いている状態を作るか、ここで合意します。

実装スプリント時間は2時間40分（途中休憩あり）。これをどう使うかを決めます。

レビュー枠を「先取り」で確保するのがコツです。実装に夢中になるとレビューは後回しになり、結局やらずに発表当日を迎えがちです。

朝会で決める時間配分テンプレート。

【本日の時間配分】
- 9:40-10:00 セルフレビュー準備 (各自、自分のコードと設計書の対応を整理)
- 10:00-11:00 相互レビュー前半 (Aさん→Bさん、Cさん→Dさん)
- 11:10-11:30 相互レビュー後半 (Bさん→Aさん、Dさん→Cさん)
- 11:30-12:10 指摘事項の修正と残実装
- 12:10-12:20 明日のデモシナリオ通し確認

【レビュー対象】
- Aさん: 会員登録機能
- Bさん: 会員一覧機能
- Cさん: ログイン機能
- Dさん: 共通コンポーネント

時間と対象を朝会で全員が見える形にします。

• レビュー時間を先に固定する
• 1人のレビューに長くても30分程度
• 明日のデモ確認を必ず最後に入れる

「パーキンソンの法則」というものがあります。「仕事は割り当てられた時間を全て使い切るまで膨張する」という法則です。レビューに3時間あれば3時間使い、30分しか無ければ30分で済ませる、というやつです。逆に言えば、時間を区切ればちゃんと終わります。レビューは「時間を区切る」ことが品質より大切な日もあります。

明日の中間発表で何を見せるかを、今日の朝に逆算します。

「動くもの」最低ライン宣言例。

【明日のデモで必ず見せるもの】
1. ログイン → 会員一覧表示 (1ユーザーで操作する一連の流れ)
2. 会員登録 → 一覧に反映される確認

【見せられたら見せたいもの】
3. 検索機能
4. 退会処理

→ 1と2は何があってもDoneにする。3、4は時間が余ったら。

優先度を明確にして、捨てる勇気も持ちます。全部完成は目指しません。

• 「明日見せるもの」を最初に決めて逆算する
• 必達ライン（最低限）と努力目標を分ける
• 全機能完成より「一連の流れが動く」を優先

ソフトウェアの世界では「動く骨組み（walking skeleton）」という言葉があります。最初から全機能を載せようとせず、画面→処理→データの細い一本道だけまず通し、そこから肉付けする考え方です。明日の中間発表で見せるのは、この骨組みで十分です。むしろ骨組みすら無いと、何も説明できなくなります。

朝会で決めにくいときAIに聞けること。

• 「レビューにかける適切な時間を、コード量から見積もる方法は?」
• 「中間発表で動かすべき機能の優先順位の付け方を教えて」
• 「『動く骨組み』の作り方を初心者向けに説明して」

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

1. 前日困りごとのフォロー
2. 今日の時間配分の合意（レビュー枠を先取り）
3. レビュー対象とレビュー担当の決定
4. 明日のデモ必達ラインの確認
5. 解散

• 時間配分が反映されたかんばん
• レビュー対象・担当の一覧
• 明日のデモ必達リスト

今回学んだことを一言でまとめると「今日はレビュー枠を先取り、明日のデモから逆算」です。

• レビュー時間を最初に確保（後回しにすると消える）
• 明日のデモ必達ラインを朝に決める
• 捨てる機能と残す機能を合意

次は実装スプリント3。チームコードレビューです。

• 今日のスプリントでレビューに何分使うことにしましたか?
• 明日のデモで必ず見せると合意した機能は何ですか?
• 時間がなくなったら最初に捨てる機能は?

• 参考リンク: 自チームのかんばん、レビュー対象コード一覧
• 発展課題: 「動く骨組み」の概念をAIに解説してもらい、自チームの骨組みが完成しているか確認する

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