Day 13 - 本日のサマリー: レビューで磨き、明日のデモから逆算する日

• 日程: Day 13
• 本日のゴール: チームレビューで実装の品質を高め、中間発表（明日）の準備状況を確認できる
• 対応する到達目標: No.7
• 本日の成果物: レビュー済みコード、中間発表の準備チェックリスト、デモシナリオメモ

実装3日目、明日はいよいよ中間発表です。今日は実装の手を一旦止めて、書いたコードをチームで見せ合います。レビューは時間を食うので、朝会で時間配分（レビュー枠の先取り）を必ず決めます。明日のデモで「動くもの」を最低1つは見せる必要があるので、今日のゴールは「明日のデモから逆算した最低ライン」を死守すること。全機能完成より「画面→処理→データが一本通る骨組み」が動いていることを優先します。中間発表は採点ではなく「フィードバックをもらうチャンス」なので、完璧を目指さなくて大丈夫です。

朝会10分・実装2時間40分・終会20分のリズムは継続。実装の時間は「セルフレビュー準備20分→相互レビュー80分→修正と残実装50分→明日のデモ通し確認10分」のような配分が目安です。

夕方の時点で「明日見せるデモが通しで動く」「レビュー指摘の優先度『高』が反映されている」「進捗を数字で言える（例: 全15タスク中Done 10/Doing 3/Todo 2）」「相談したい課題が3件以下に絞れている」状態が理想。具体的には、ログイン → 一覧 → 登録 → 一覧反映のような一連の流れが通せて、操作する人と説明する人の役割分担が決まっていれば、明日に胸を張って臨めます。

• レビューで指摘が人格攻撃に聞こえてしまう → 主語を「このコード」「この変数名」にする。「Aさんは」と言わない
• 指摘が多すぎてレビュー時間が膨らむ → 観点を3つに絞る。残りは次回レビューで
• 指摘を全部反映できずに発表当日を迎える → 優先度「高」のみ反映、「中・低」は後日タスク化。完璧主義を捨てる
• 「とりあえず全部レビュー」と決めて結局時間切れ → 必達ラインに関係するものから先にレビュー
• 通しリハをせずに本番を迎える → 終会の最後5分で必ず1回通す
• 当日朝の動作確認を忘れる → チェックリストに「当日朝」項目を必ず入れる

安心材料として、レビューで「良い点が見つからない」と感じても、「1日かけて動かしたこと自体」が立派な良い点です。

人間のレビューの「あと」にAIを使うと、観点の漏れを補えます。AIには必ず設計書も一緒に渡すと、表面的でない指摘が返ってきます。

• 「以下のコードをレビューしてください。言語: [○○]、機能: [1文]、設計書の該当部分: [貼る]、コード: [貼る]。観点は『設計書との整合・異常系の対応・読みやすさ・重複と再利用・セキュリティ』の5つ。それぞれ良い点と改善提案をペアで、優先度（高/中/低）も付けてください。中間発表が明日なので、優先度の低いものは『後回しでOK』と明記してOKです」
• 「中間発表の進捗報告で『順調です』を使わずに数字で言い換えるフレーズ集を作ってください」

AIの指摘の取捨選択は人間の仕事。AIの言いなりにならないことが今日の鍵です。