はじめに
私はテスターとして働いています。
仕事では設計書を読んで仕様書を作り、DBにデータを入れてAPIの挙動を確認する——そういったテストが日常です。「正しいデータが返ってきているか」を確かめるのは得意でも、自分でコードを書いてアプリを作った経験はありませんでした。
「コードが読めたり書けたりできたら、もっと幅が広がるだろうな」——そう思いながらも、仕事と学習の両立の難しさや、何から手をつければいいかの迷いで、個人開発はずっと後回しになっていました。テストを通じてシステムの動きは分かるのに、いざ「自分で作る」となると全然違う話でした。
もう一つ、踏み出せなかった理由が、
「どうせやるなら完璧に作りたい」という気持ちです。
仕様書もテストも、仕事では「抜け漏れをなくすこと」が当たり前の世界にいます。その感覚が個人開発にも出てしまって、「まだ準備が足りない」「もっと勉強してから」と先延ばしにしていました。
それが変わったのは、SNSで見た言葉がきっかけです。
「完璧であることより、まず終わらせることが重要だ」— Mark Zuckerberg
作ってみないと見えないものがある。スピード感を持って動いた方がいい。 そう思えたとき、最初の一歩が踏み出せました。
そんな私が、Claude（AIアシスタント）と Claude Code（AIコーディングツール）を使って、個人開発アプリのPhase 1（ローカル動作版）を完成させました。
まだ完成品ではありません。Web公開・DB移行・OCRスキャン機能などは今後のPhaseで実装予定です。ただ、「個人開発を始めることができた」 という体験と、テスター視点だからこそ気づけた学習スタイルをリアルにまとめていきます。
同じように「開発側に踏み出したいけど最初の一歩が出ない」と感じているテスター・QA・非開発エンジニアの方に、特に読んでほしい記事です。
作ったもの：LoadLog（筋トレノート管理アプリ）
きっかけ
ジムに通っていて、トレーニング中のメモはノートに手書きしていました。でも、ノートだと「先月のベンチプレスの重量なんだっけ？」と見返しにくい。かといって、スマホアプリに入力するのはトレーニング中に面倒。（トレ中にスマホばかり見ていると思われたくない..）
「ノートとアプリを組み合わせたい」 という自分の課題がそのままアプリのコンセプトになりました。
Phase 1で実装した機能
- トレーニング中は手書きノートに記録
- 帰宅後にアプリへ転記（重量・レップ数・RPE・メモ）
※Ph2以降でノートをスキャンして自動転記できるようにしたい - 部位・メニューのマスタ管理
- カレンダーで「いつどの部位をやったか」を確認
- 重量推移グラフでPR（自己記録）を追跡
技術スタック（Phase 1）
| レイヤー | 技術 |
|---|---|
| バックエンド | Python + FastAPI |
| DB | SQLite |
| フロントエンド | HTML / CSS / JavaScript |
| 認証 | JWT（python-jose + passlib） |
| 開発ツール | VSCode + Claude Code |
「AIに実装させる」は「ズルをする」じゃない
ここで正直に話しておきたいことがあります。
Claude Codeに実装を指示すると、コードが自動で書き上がります。「それって自分で作ったと言えるの？」と感じる人もいると思います。私も最初はそう思っていました。
でも今は、これはズルではなく「AI時代のプログラミング学習スタイル」だと思います。
「AIは道具」。使いこなすのも技術
電卓が出てきたとき「計算を機械にやらせるのはズルだ」という人はいませんでした。今では電卓を使いこなせる人が「計算が得意な人」です。
Claude Codeも同じです。AIに「このAPIを実装して」と指示するだけでは何も生まれません。
- 何を作るか設計する
- どのファイルに何を書くかを判断する
- 出てきたコードが正しいかレビューする
- バグが出たときに原因を切り分ける
- 次に何をすべきか決める
これらは全て自分の頭で考える必要があります。 AIはコードを書いてくれますが、「何を作るか」「なぜその設計か」を考えるのはあくまで人間です。
AIを使った学習サイクル：「まとめを読んでから質問する」
これが今回の開発で一番気づきになったことです。
最初は「分からないことを聞く→答えをもらう→また分からないことが出る→聞く」というラリーを繰り返していました。これは悪くないのですが、質問の質がなかなか上がりませんでした。
途中から変えたのが、「まず周辺をまとめてもらってから、不明点を聞く」 というサイクルです。
① 分からないことが出る
↓
② 「この周辺のコードとフローをまとめて説明して」とAIに依頼
↓
③ まとめた説明を読んで全体像を把握する
↓
④ 本当に分からない部分が具体的になる
↓
⑤ ピンポイントで質問する → 理解が深まる
例えばFastAPIの Depends() が分からなかったとき、最初は「Dependsって何ですか？」と聞いていました。でも「Dependsが使われている処理の全体フローをまとめて、各行の意味を説明して」と聞いた方が、コードの文脈ごと理解できました。
「まとめを読む」を資産にする
このまとめをExcelドキュメントとして保存しておくと、さらに効果的でした。
今回の開発では、こんな学習ドキュメントをAIと一緒に作りました。
- LoadLog Backend解説.xlsx：フォルダ構造・各ファイルの役割・ライブラリ解説・Django対比
- リクエストフロー解説.xlsx：1リクエストをコードで追う（正常系・エラー系）
- FastAPI構文解説（初学者版）.xlsx：L1〜L5のレイヤーで構文同士のつながりを理解
- Python基本構文解説.xlsx：型ヒント・クラス・デコレータ等の基本構文
これらは「AIに作ってもらった参考書」ですが、読むことで自分のコードへの理解が格段に上がりました。
「分からない → すぐ聞く」より「分からない → まず全体像を整理 → ピンポイントで聞く」の方が、時間短縮にも質問の質向上にもなります。
私がAIが書いたコードに対してやったこと
実装はClaude Codeに任せながら、こんなことを繰り返していました。
-
「このDepends(get_db)って何をやってるの？」→ Claudeに質問 -
「Djangoのviews.pyとどう違うの？」→ 対比で解説してもらう -
「このエラーはなぜ起きた？」→ 原因と解決策を一緒に考える -
「このファイル構成をDjangoと比較してExcelにまとめて」→ 資産として保存
結果的に、「手で書いたことはないけど、このコードが何をしているか説明できる」 という状態になりました。これが今の個人開発学習の一つの形だと思っています。
このシリーズで書くこと
Phase 1（ローカル開発）
※ 記事の内容・順序は執筆中に変更される可能性あり
| # | タイトル | 内容 |
|---|---|---|
| #1 | 設計フェーズ | AIとの対話で要件を言語化・設計書を作る |
| #2 | システム設計書 | ER図・API設計書・画面設計書を作った話 |
| #3 | 画面モックアップ | コードで画面の見た目を先に作る方法 |
| #4 | 環境構築 | venv・.env・Gitの初期設定を丁寧に解説 |
| #5 | Git・GitHub | ブランチ戦略とコミットメッセージの設計 |
| #6 | Claude Code活用① | CLAUDE.md・AGENTS.md・RULES.mdの設計 |
| #7 | Claude Code活用② | 完了メッセージを学習用にカスタマイズ |
| #8 | Claude Code活用③ | AIが書いたコードを自分のものにする方法 |
| #9 | FastAPI理解① | Djangoをちょっとかじった私がFastAPIのファイル構成を理解するまで |
| #10 | FastAPI理解② | FastAPIの「Depends」を理解したら、コードの流れが見えてきた |
Phase 2以降（これから）
| # | タイトル | 内容 |
|---|---|---|
| #11 | Renderデプロイ | Web公開する手順と詰まったこと全記録 |
| #12 | DB移行 | SQLite→PostgreSQLへの移行体験記 |
| #13 | React移行 | HTML/JSからReact（Vite）へ |
読んでほしい人
このシリーズは、こんな人に向けて書いています。
- プログラミングの勉強は続けているが、個人開発経験がない
- チュートリアルは終わったが「次に何をすれば良いか」が分からない
- ポートフォリオとして個人開発を始めたいが、何から手をつけるか迷っている
- AI（Claude / Claude Code）を開発に活用したいが、どう使えばいいか分からない
逆に、「完全にゼロからコードを書く方法を学びたい」人にはこのシリーズは向いていません。 従来のチュートリアルや書籍から始めた方が良いかもしれません。
最後に
「個人開発、始めてみたい」と思いながら後回しにしていた気持ちはよく分かります。
でも、AIというサポーターができた今、個人開発の障壁は以前より確実に下がっています。設計書の作り方も、環境構築の手順も、エラーの原因も、「なぜこう書くのか」という疑問も——全部AIと一緒に考えながら進めることができます。
ゴールは「完璧なコードを書けるようになること」じゃなくて、「自分が使いたいものを作り上げる経験を積むこと」 だと思っています。