Part 6 最終プロジェクト・動画
第21章 個人開発プロジェクト
動画台本ナレーション全文
Slide 01. 個人開発プロジェクト
第21章では、自由テーマの個人開発プロジェクトを始めます。ここまで学んだWeb、データ保存、API、画面作り、テスト、AI、技術文書を使って、小さなアプリを作ります。大切なのは、壮大なものを作ることではありません。誰のどんな困りごとを解くのか、どう動くのか、何を確認したのかを、自分の言葉で説明できる状態を目指します。
Slide 02. この章で持ち帰ること
この章で持ち帰ってほしいことは三つです。一つ目は、自由テーマを、誰の、どんな困りごとを、どこまで扱うかに分けることです。二つ目は、MVP、つまり最初に価値を確かめる小さな形を、受け入れ条件と確認方法まで含めて決めることです。三つ目は、最初の縦切り実装を動かし、セルフレビューとデモまで進めることです。完璧さより、動かして、確認して、説明できることを重視します。
Slide 03. 第20章との接続
第20章では、READMEや設計メモのように、あとから読める形で判断を残す方法を扱いました。第21章では、それを個人開発の土台にします。企画メモ、MVPの範囲、作業計画、進捗ログ、セルフレビュー、デモ台本を残しながら進めます。自由テーマでも、作る理由、今回は作らない範囲、確認方法、残課題を書いておくと、相談とレビューがしやすくなります。
Slide 04. 自由テーマにも条件があります
自由テーマとは、作るものを自分で選ぶという意味です。ただし、メンターが見て判断できる条件は必要です。ユーザー、困りごと、作る範囲、作らない範囲、最初のデモ、確認ログが説明できないテーマは、途中で迷いやすくなります。自分がよく知っている小さな課題から選ぶと、仕様を決めやすくなります。面白さだけでなく、最後まで動かせる範囲を優先します。
Slide 05. テーマ選びの基準
良いテーマは、対象ユーザーと困りごとが具体的です。1人または1種類のユーザーに絞ります。1つの主要な業務、生活、学習、管理の流れに絞ります。最初から多人数利用、課金、通知、外部連携を入れすぎないようにします。小さく具体的な課題を選ぶと、最後まで作りやすくなります。
Slide 06. 避けたいテーマ
最初に避けたいのは、大きすぎるテーマや、扱いに注意が必要なデータを含むテーマです。SNS、課金、外部サービス連携、複雑な認証、実在する顧客情報や個人情報を入れると、確認することが急に増えます。新しい技術を試すだけのテーマも、目的がぼやけやすいです。最初は、ローカルで安全に動かせる小さなWebアプリを目指します。
Slide 07. 企画メモ
作り始める前に、project brief、つまり企画メモを書きます。まず、誰に向けたものか、どんな困りごとを扱うか、今回はどこまで作るかを決めます。次に、成功のサイン、作らない範囲、扱うデータの注意点、AIを使う場面を書きます。いちばん不確かな前提と、確認に必要な証拠も残します。これがあると、途中で目的と範囲が揺れにくくなり、メンターにも相談しやすくなります。
Slide 08. MVP
MVPは Minimum Viable Product の略で、最初に価値を確かめる小さな形です。便利そうな機能を全部入れることではありません。必ず作るもの、できれば作るもの、余裕があれば作るもの、今回は作らないものに分けます。さらに、成功時、失敗時または空状態、再読み込み後に何を確認するかを書きます。MVPを決めるとは、最初に見せる完成形と、完了したと言える証拠を決めることです。
Slide 09. 作らない範囲
個人開発では、作らない範囲を決めることがとても重要です。たとえば、通知は今回は作らない。多人数共有は作らない。外部API連携は作らない。本番公開の確認は第23章で扱う。作らない理由も短く書きます。範囲を削ることは妥協ではありません。最初の価値を届けやすくするための判断です。
Slide 10. 成功条件
完了条件は、実装した、ではなく、確認できた、で書きます。たとえば学習ログアプリなら、ログを登録できる、一覧に表示される、未入力ならエラーが出る、再読み込み後も残る、README通りに起動できる、のように書きます。画面、API、データ保存、入力チェック、テストまたは手動確認を最低限確認します。成功条件は、デモとセルフレビューの材料になります。
Slide 11. 技術構成
技術構成では、新しい技術を試すことだけを目的にしません。研修で使ってきた標準構成を基本にします。Webアプリとして、画面、API、データ保存、テスト、READMEをそろえます。AWSへの接続は第23章で再確認するため、この章ではローカルで同じ動きを再現できることを優先します。外部API、メール、決済、認証は、必要性とリスクを説明できる場合だけ採用します。
Slide 12. 縦切り実装
縦切り実装とは、1つのユーザー操作が、画面、API、データ保存、確認まで通る最小単位です。画面だけ、データ保存だけ、APIだけを長く作り込まないようにします。最初の縦切りには、一覧、作成、更新、状態変更などのうち1つを選びます。まず細い流れを動かし、その後に機能を増やします。縦切りができると、レビュー、デモ、相談がしやすくなります。
Slide 13. タスク分解
タスクは、1つの成果物または1つの確認結果に対応させます。フロント実装、バックエンド実装、という大きなタスクだけでは扱いにくいです。たとえば、保存する項目を決める、ログ登録APIを作る、入力チェックを入れる、登録画面を作る、空の一覧を表示する、READMEを更新する、のように分けます。タスクごとに、目的、完了条件、確認方法を書きます。
Slide 14. AI利用計画
AIは、アイデア出し、範囲の整理、調査、実装、テスト案、レビュー、文書化に使えます。ただし、入力前、採用前、共有前、PR前に確認します。入力前には、APIキーなどの秘密情報や、実在の個人情報を入れないことを確認します。採用前には、AIが作った計画、コード、文章を自分で動かして確かめます。AI利用ログには、採用した提案だけでなく、採用しなかった提案と理由、検証方法も残します。
Slide 15. 進捗ログ
個人開発では、作業の途中経過が見えにくくなりやすいです。進捗ログには、今日やったこと、確認結果、判断を変えたこと、詰まったこと、次にやることを書きます。長文でなくてかまいません。事実と次の行動が分かれば十分です。詰まった内容を早めに共有できると、メンターは助けやすくなります。
Slide 16. セルフレビュー
メンターに見せる前に、自分でレビューします。まず、狙った価値が伝わるか、主要操作が動くか、README通りに起動できるかを見ます。次に、テスト、コードの読みやすさ、データ安全性、セキュリティ、アクセシビリティ、残課題を確認します。失敗したテスト、まだ実行していない確認、既知の問題も隠さず書きます。分かっている問題を見えるようにすることが、第23章の本番前チェックにもつながります。
Slide 17. デモ
デモは、機能一覧を順に見せる場ではありません。誰のどんな課題を、どの流れで解くかを見せます。開始状態、操作、期待結果、うまくいかない時や空状態の扱いを準備します。動かない部分、未対応の部分、次に改善する部分も説明します。デモ台本を作ると、発表前に動作確認しやすくなります。
Slide 18. レビュー依頼
メンターへのレビュー依頼には、目的、見てほしい観点、起動方法、確認方法、既知の課題を書きます。全部見てください、だけではレビュアーが判断しにくいです。たとえば、ログ登録の縦切りが目的です、起動手順と登録動作を見てください、未対応はタグ検索です、のように書きます。迷った技術判断は、選択肢と選んだ理由を添えます。レビューを受けやすい形に整えることも成果です。
Slide 19. 候補A
候補Aは、学習ログ整理アプリです。ユーザーは研修中の受講者。課題は、学んだこと、詰まったこと、次に聞きたいことが散らばることです。MVPは、学習ログを登録できる、タグと日付で一覧を絞り込める、詰まっていることだけを抽出できる、くらいに絞ります。SNS化や通知、複雑な権限管理は避けます。
Slide 20. 候補B
候補Bは、個人タスク棚卸しアプリです。ユーザーは、自分の作業を整理したい若手エンジニアです。課題は、作業、相談、調査、レビュー待ちが混ざり、次に何をするか迷うことです。MVPは、タスクを登録できる、状態を変更できる、今日やるものだけを表示できる、くらいにします。多人数共有やカレンダー同期、複雑な通知は避けます。
Slide 21. 候補C
候補Cは、読書メモと実践メモ管理アプリです。ユーザーは、技術書や記事を読んだあと、実務に活かしたいエンジニアです。課題は、読んだ内容と自分の行動がつながらないことです。MVPは、メモを登録できる、学び、試すこと、結果を分けて書ける、未実践のメモを一覧できる、くらいにします。記事全文保存や外部記事クローリングは避けます。
Slide 22. 候補D
候補Dは、小さな在庫、備品メモアプリです。ユーザーは、個人または小さなチームで備品を管理する人です。課題は、何が足りないか、最後に確認したのがいつか分からなくなることです。MVPは、備品を登録できる、数量と最終確認日を更新できる、不足しそうなものを一覧できる、くらいにします。会計、発注、外部サービス連携は避けます。
Slide 23. 例を企画メモにする
例として、学習ログ整理アプリを企画メモにします。ユーザーは研修中の受講者です。課題は、学んだこと、詰まったこと、次に相談したいことが散らばることです。成果は、今日の学びと相談事項を整理できることです。主な流れは、ログを書く、状態やタグを付ける、一覧で見る、相談したいことを確認する、です。
Slide 24. 例をMVPにする
同じ例をMVPにします。必ず作るものは、ログを登録できる、一覧で見られる、状態で絞り込める、README通りに起動して確認できる、くらいに絞ります。できれば作るものはタグや日付の絞り込みです。余裕があれば簡単な集計も考えます。今回は、SNS化、通知、多人数共有、外部サービス連携は作りません。作らないことを書くと、最初の完成形が見えやすくなります。
Slide 25. 例をタスクにする
MVPをタスクに分けます。まず、保存する項目を決めます。次に、ログ登録API、入力チェック、登録画面、一覧画面を作ります。空の一覧表示、主要操作の手動確認、README更新もタスクにします。最初の縦切りは、ログを1件作成し、一覧に表示する、です。タスクごとに完了条件と確認方法を書きます。
Slide 26. 例をデモにする
デモでは、学習ログが散らばっている状態から始めます。ログを1件登録します。状態やタグを付けます。一覧に表示されることを確認します。詰まっているログだけを見ます。最後に、今回できること、まだできないこと、次に改善したいことを説明します。デモは、価値と動作を短い流れで見せる場です。
Slide 27. 評価観点
この章の評価は、満点のプロダクトを作ることではありません。見るのは三つです。まず、ユーザー、課題、成果、制約、データ安全性が企画メモに書かれているか。次に、MVPが小さく、確認条件がはっきりしているか。最後に、縦切り実装が画面、API、データ保存、確認までつながり、README、確認ログ、セルフレビュー、デモ台本で説明できるかです。限られた時間で範囲を決め、動くものを作り、説明できることを評価します。
Slide 28. 第22章への接続
第21章では、自分で選んだテーマを最初の完成形まで作ります。第22章では、それを既存プロダクトとして見て、小さな仕様変更を入れます。個人開発で作ったものを、第22章の題材にしてもかまいません。大切なのは、ゼロから作ることではなく、すでに動いている作成、一覧、データ、READMEを壊さずに変えることです。
Slide 29. 演習 1
一つ目の演習では、project brief、つまり企画メモを書きます。自分のテーマを1つ選び、ユーザー、困りごと、成功のサイン、作る範囲、作らない範囲、制約、データの注意点、AIを使う場面、いちばん不確かな前提、メンターへの質問を書きます。成果物は project-brief.md です。自由テーマを、レビューできる企画に変える演習です。
Slide 30. 演習 2-3
二つ目の演習では、MVPスコープを決めます。必ず作るもの、できれば作るもの、今回は作らないものに分け、最初のデモで見せる範囲に絞ります。成功時、失敗時または空状態、再読み込み後の確認も書きます。三つ目では、delivery plan、つまり作業計画を作ります。最初の縦切り、保存するデータ、タスク、AIに任せる範囲、人間の確認ポイント、確認コマンド、進捗ログのルールを書きます。
Slide 31. 演習 4-5
四つ目の演習では、最初の縦切り実装を作ります。ローカルで起動し、1つの主要操作が画面、API、データ保存、確認まで通る状態を作ります。五つ目では、セルフレビューとデモ台本を書き、メンターへのレビュー依頼を整えます。提出の中心は、動くアプリ、進捗ログ、README更新、セルフレビュー、デモ台本、レビュー依頼です。
Slide 32. まとめ
第21章では、自由テーマを個人開発プロジェクトに変えます。大切なのは、作りたいものを大きく語ることではなく、誰の困りごとを、どこまで作り、どう確認したかを説明できるようにすることです。小さくても、動くものがあり、レビューを受けられる状態にします。その状態が、第22章以降の改善、運用確認、最終発表につながります。