実装の仕上げ

• 日程: Day 4 / セッション 05
• 時間: 13:00-13:30
• 形式: 実習
• ゴール: APIとUIを統合し、1つのユースケース（例：「新規追加 → 一覧表示 → 編集 → 削除」）がエンドツーエンドで動作する
• 学習形式: ハンズオン実習（AIにバグ修正を相談）

午前で「API」と「UI」が別々に動く状態まで来ました。お昼を挟んだこの30分は、両者をつなぎ込んで1ユースケースが端から端まで動くところまで持っていく仕上げの時間です。

ここで重要な心構えがひとつ。完璧を目指さないでください。Day 4のゴールは「研修発表のために、デモができる状態」を作ることであって、商用品質のソフトを作ることではありません。Walking Skeleton（歩く骸骨）が歩ければ十分。動かないところはAIに聞いて素早く直しましょう。

「動く」と「ちゃんと動く」の間には深い溝があります。次のチェックリストで埋めていきます。

1つのユースケースで全CRUDが回ることを最優先します。複数モデルを薄く中途半端に作るより、1モデルを最後まで仕上げる方が発表で説得力が出ます。

スタートアップの世界に「MVP（Minimum Viable Product）」という言葉があります。Erick RiesがLean Startupで提唱した「最小限の動く製品」のこと。「最小限」が大事で、たくさん機能を作るより1つの価値が動く方が学びが多いという思想です。Day 4の今、皆さんが作っているのはまさにMVPです。

実装で詰まった時の質問の質が、解決速度を左右します。次の型をAIに渡しましょう。

# 状況
〇〇を実装している。〇〇ボタンを押すと△△を期待していた。

# 実際に起きたこと
△△にならず、コンソールに次のエラーが出る：
（エラーメッセージをそのまま貼る）

# 関連コード
（該当部分のコードをそのまま貼る）

# 試したこと
- 〇〇を確認した（問題なかった）
- △△を変えてみた（同じエラー）

# 質問
原因と修正案を、優先度の高い順に3つ示してください。

• エラーメッセージはコピペ。要約しない
• コードはコピペ。「だいたいこんな感じ」では精度が落ちる
• 「3つ示して」で選択肢が広がる
• 「優先度順」で考える順番がわかる

昔の伝説的プログラマは、机にゴム製のアヒルを置き、バグに詰まったらアヒルに向かって「これはこういう処理で…」と説明する習慣がありました（「The Pragmatic Programmer」の有名な逸話）。人に説明する過程でバグを自力で見つけるという現象を活用したテクニックです。AIに状況を説明する行為そのものが、同じ効果を生みます。

8割の統合トラブルはCORSとContent-Typeとexpress.jsonです。最初に疑ってください。

ここまでの内容で疑問があれば、AIに質問してみましょう。たとえば：

• 「次のエラーが出た：（エラーメッセージ）原因と修正案を3つ示して」
• 「APIとUIをつないでデモにする最短手順を教えて」
• 「READMEに最低限書くべき項目は？」

チームで1つのユースケースを選び、エンドツーエンドで動作させてください。例：

• レシピを新規追加 → 一覧で確認 → タイトル編集 → 削除

統合チェックリストの上から順に潰し、READMEに起動方法を書きます。

• 動作するアプリ一式（GitHubの最新コミット）
• README.md（起動手順、使い方、デモ手順）
• 1ユースケースのデモ動画 または スクショ連番

• 全員が同じユースケースに集中する30分。残課題は付箋に書いて発表時に「今後の課題」として共有
• 詰まったら5分で諦めてAIに相談。一人で15分悩むより速い
• 「上手くいかない時こそAIに本気の質問を投げる」が今日一番のスキル
• 動かない部分はモックURLに差し替えてでも、ユースケース通過を優先

エンドツーエンドで動く瞬間、これまで4日間積み上げてきた「情報定義書」「ペルソナ」「情報モデル」「状態遷移」「機能」「プレゼンテーション」「設計アプローチ」「API仕様」が、全部1つの動くアプリに収束します。設計の連続性こそ、皆さんが研修で得た最大の財産です。

次のセッションでは、この成果を5分間のプレゼンに圧縮する発表資料を作ります。

• 自チームのユースケースを口頭で30秒で説明できますか？
• 統合トラブルを1つ挙げ、その原因と修正方法を言えますか？
• READMEに必要な最低限の項目を3つ言えますか？

• 参考リンク: README作成ガイド（GitHub Docs）、corsミドルウェアのドキュメント
• 発展課題: 簡易なエラーハンドリングUI（トースト通知）を追加する