Day 9 - 本日のサマリー: 設計から実装へ、7日間の航路を描く日

• 日程: Day 9
• 本日のゴール: タスクを洗い出し、WBS・ガントチャート・かんばんで Day10-17 に収まる開発計画を時間内に作る
• 対応する到達目標: No.6
• 本日の成果物: タスクの洗い出し、WBS、ガントチャート、かんばん

8日間かけて設計書まで作った。このまま実装に突入すると「誰が何をやるんだっけ」「あと何日あるんだっけ」で事故が起こる。今日はそれを防ぐため、やることを見える化する3つの道具を学び、自チームの開発計画に落とす。守るべき制約は3つ。実装期間は Day10-17 の7日間、Day14 は中間発表（動くものが必要）、Day17 で実装完了。この箱に収まる計画を作って実装フェーズに渡す。

午前は「手法を学ぶ → 身近な題材で手を慣らす」、午後は「設計書を入力に本番の計画を組む」リズム。身近な題材を挟むのは、設計の難しさと管理手法の難しさが同時に襲ってくるのを避けるため。

最終成果物のかんばんは、各カードに「タスク名・担当者・所要時間・成果物・終了条件・状態」が埋まっている状態。例えば「予約登録 API 実装」カードなら、担当=田中、所要時間=4時間、成果物=動作する API、終了条件=「ローカルで POST /reservations が成功し、reservations テーブルに行が作られる」、状態=Todo のように具体的に書ける。ガントチャートには Day14 中間発表のマイルストーンが立ち、Day13 までに「動くもの1セット」が並んでいる。バッファタスクを Day13 と Day17 に1枚ずつ置いておくと安心。

各セッションファイルの「つまずきやすいポイント」から特に効きそうなものを抜粋する。

• WBS を完璧に作ろうとして時間を使いすぎる（S1）: WBS は生き物。最初は7割で動かし、走りながら更新する。完璧な計画より、動く計画。
• 終了条件に「ちゃんと」「しっかり」を使ってしまう（S2）: 第三者でも確認できる事実で書く（例: 「3人にレビューを依頼し、全員が OK と回答済み」）。語尾は「〜が完成している」「〜が決定している」。
• タスクが粗すぎて「予約機能実装（3日）」のような塊になる（S3）: 「予約登録 API 実装」「予約一覧画面実装」のように、半日で完了する粒度まで分解する。
• 中間発表（Day14）を意識せず後半に詰め込む（S3）: 「Day13 までに動くものを1本」をマイルストーンに必ず置く。後半に積むと取り返しがつかない。

安心材料: 担当者の偏りやスキル差はペア作業で吸収できる。設計書の機能が多すぎるなら、優先順位を「核／あったら良い／無くても困らない」の3段階に分け、後ろから削る勇気を持つ（MVP の発想）。

まず自分でタスクを洗い出す → AI に「漏れ」と「クリティカルパス」を聞く、が今日の基本姿勢。

• 「以下のテーブル定義書と機能一覧から、必要な実装タスクを末端レベル（半日以内）で列挙してください。[設計書貼付]」
• 「私たちのガントチャート（貼付）でクリティカルパスはどれですか？ Day14 の中間発表に間に合わないリスクと、漏れているタスクを指摘してください」