第21章 個人開発プロジェクト

学んだことを一つの成果へ統合する部である。 企画・改善・本番前確認・発表の進め方が中心で、独立して解説する一般的な専門用語は少ない。 各章では、その章で新しく出る一般用語だけを取り上げ、すでに解説した語は参照でつなぐ。

第21章は、これまで練習した型を一つの小さなプロダクトに統合する章である。企画・範囲決め・確認の多くは本書独自の文書（Project Brief など）や課題の提出物として進めるため、ここで独立して解説する一般的な専門用語は多くない。この章で繰り返し使う MVP・Must/Should/Could/Won’t・Outcome は第2章、受け入れ条件（acceptance criteria）は第9章で解説した語をそのまま使う。第21章では、それらをSuccess Signal、Riskiest Assumption、Data Lifecycle、AI利用ログ、縦切り実装へつなげる。

vertical slice（縦切り実装）

• 読み：バーティカルスライス（vertical slice／縦切り実装）
• 一言で言うと：一つのユーザー操作を、画面・API（または処理）・データ保存・確認まで、細くても端から端まで通す最小単位。
• くわしく：画面だけを作り込む、DBだけを先に作り込むといった横方向の進め方ではなく、機能の一筋を縦に貫通させる作り方である。細い流れでも端まで動くと、早い段階で全体がつながり、相談やレビューがしやすくなる。「ここまで動いていて、次にこれを足す」と説明できる。後から、壊してはいけない既存動作として守る対象にもなる。
• 具体例：学習ログ整理アプリなら、最初の縦切りは「ログを1件作成し、一覧に表示する」でよい。保存項目・入力画面・保存処理・一覧画面・確認手順が一筋に含まれる。タグ検索や集計は後でよい。
• つまずきやすい点：画面を完璧にしてからAPI、その後DB、と横に積むと、最後までつながらず確認が遅れる。細くても先に縦へ通す。
• 関連語：MVP（第2章）、受け入れ条件（第9章）、Pull Request（第6章）
• テキスト本文での登場箇所：第21章「縦切り実装で、最初の細い流れを通す」

GitHub Issues / GitHub Projects

• 読み：ギットハブ イシューズ／プロジェクツ（GitHub Issues / GitHub Projects）
• 一言で言うと：作業を追跡できる小さな単位（issue）として記録し、表・ボード・ロードマップで計画と進捗を見るGitHubの仕組み。
• くわしく：Issuesは、アイデア・タスク・バグを記録する単位で、sub-issues・dependencies・labelsで分けて追跡できる。Projectsは、issuesやpull requestsと連動するtable・board・roadmapで作業を見る。研修で必ず使う必要はないが、「作業を追跡できる小さな単位にする」という考え方はどのツールでも同じである。
• 具体例：学習ログ整理アプリの作業を「保存項目を決める」「登録処理を作る」「一覧画面を作る」「READMEを更新する」などのissueに分け、Projectのboardで進捗を見る。
• つまずきやすい点：ツールを入れること自体が目的になり、粒度の大きすぎるissueを1枚だけ作る。レビュー可能な小さな単位に分ける。
• 関連語：Pull Request（第6章）
• テキスト本文での登場箇所：第21章「Delivery Planで、作業をレビュー可能な単位にする」「GitHub IssuesやProjectsを使うなら、情報を重複させすぎない」