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

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

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

Success Signal

読み：サクセスシグナル（success signal／成功のサイン）
一言で言うと：MVPが価値を見せられたと言える、観察可能な操作や結果。
くわしく：Outcomeは「ユーザーの状態がどう良くなるか」を表す。Success Signalは、それをデモや確認でどう見るかを表す。「相談前に整理できる」がOutcomeなら、「ログを1件登録し、相談したいログだけを一覧で見せられる」がSuccess Signalである。数値指標でなくてもよいが、操作と結果で確認できる形にする。
具体例：READMEの手順でローカル起動し、ログを登録し、一覧に表示し、状態で絞り込める。
つまずきやすい点：「便利になる」「使いやすい」のような感想だけにすると、完了判断やレビュー依頼に使いにくい。
関連語：Outcome（第2章）、受け入れ条件（第9章）、demo script（第21章）
テキスト本文での登場箇所：第21章「Project Briefは、開発の基準点である」

Riskiest Assumption

読み：リスキエストアサンプション（riskiest assumption／いちばん不確かな前提）
一言で言うと：外れているとMVPの価値や実装計画が大きく崩れる前提。
くわしく：個人開発では、全部を先に調査できない。だから、最初にいちばん怪しい前提を一つ選び、どんな証拠があれば確認できるかを書く。「状態を3種類に絞って足りる」「外部APIなしでも価値を見せられる」「ローカルDBで十分」などが前提になる。Riskiest Assumptionを書くと、AIやメンターへ相談するときの焦点が明確になる。
具体例：学習ログ整理アプリで「未整理、相談したい、解決済みの3状態で相談準備に足りる」と置き、Evidence Neededに「相談したいログだけを表示できる」と書く。
つまずきやすい点：すべての不安を並べて焦点がぼやける。最初のMVPに最も影響するものを一つ選ぶ。
関連語：MVP（第2章）、Project Brief（第21章）、Mentor Review Request（第21章）
テキスト本文での登場箇所：第21章「Project Briefは、開発の基準点である」

Data Lifecycle

読み：データライフサイクル（data lifecycle）
一言で言うと：データを保存するか、どこで使うか、どう更新・削除するか、AIへ入力してよいかを確認する観点。
くわしく：個人開発でも、データを保存するなら扱いを決める必要がある。特に公開リポジトリの研修成果物では、secret、実在の個人情報、顧客情報、本番ログを保存しない。サンプルデータだけで作る場合も、削除方法や初期化方法、AIへ入力してよい範囲を書くと安全性を説明しやすい。
具体例：学習ログtitleとbodyは架空データだけ保存し、実名やメールは保存しない。ローカルDBを削除すれば初期化できる、とREADMEに書く。
つまずきやすい点：小さな個人開発だからといって、実在人物の情報や社内ログをサンプルとして入れてしまう。
関連語：Data Safety（第21章）、secret（第14章）、個人情報（第14章）
テキスト本文での登場箇所：第21章「Data Safetyを最初に見る」

AI利用ログ

読み：エーアイりようログ
一言で言うと：AIに何を頼み、何を採用し、何を採用せず、どう検証したかの記録。
くわしく：AI利用ログは、AIを使った事実を残すだけではない。採用した提案、採用しなかった提案、入力に危険な情報を含めていないこと、採用後に実行したコマンドや手動確認を書く。これにより、AIの出力をそのまま受け入れたのではなく、人間が判断した範囲を説明できる。
具体例：「MVPのMustを3つに絞る提案は採用。通知機能の提案はMVP外として不採用。READMEのコマンドは実行して確認」と書く。
つまずきやすい点：AIを使ったかどうかだけを書く。重要なのは、どの提案をどう扱い、何を検証したかである。
関連語：AI利用計画（第21章）、AI差分レビュー（第19章）、文書レビュー（第20章）
テキスト本文での登場箇所：第21章「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章）、small diff（第19章）
テキスト本文での登場箇所：第21章「Delivery Planで、作業をレビュー可能な単位にする」「GitHub IssuesやProjectsを使うなら、情報を重複させすぎない」

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