個人開発でやってよかったこと・やらなくてよかったこと：1年間の振り返り
はじめに
個人開発を始めて約1年が経ちました。
この1年間、宅建試験のAI対策アプリ「takkenai.jp」を開発・運用してきて、問題数は1250問を超え、ありがたいことにユーザーも少しずつ増えてきました。技術スタックはNext.js + Supabase + Claude APIという、わりと今どきな構成です。
ただ、順風満帆だったかというと全然そんなことはなく、「なんでこれやったんだろう」と頭を抱えたことも数え切れません。
この記事では、1年間を振り返って**「やってよかった」3つと「やらなくてよかった（やりかけてやめた）」3つ**を、具体的なエピソードと一緒にまとめます。
同じように個人開発をしている方、これから始める方の参考になれば嬉しいです。
やってよかったこと
1. 早期ユーザーフィードバック（リリースは「恥ずかしいくらい」が正解だった）
開発を始めて3週間目、問題数がまだ80問しかない段階で、知人5人にURLを送りつけました。正直、UIはほぼデフォルトのTailwindそのままで、解説文も粗削り。「もうちょっと完成度を上げてから……」という気持ちを抑えて送ったのを覚えています。
結果、自分では絶対に気づけなかったフィードバックがたくさん返ってきました。
- 「スマホで解くとき、選択肢を押した後に正解がすぐ見えちゃって、次の問題への緊張感がない」
- 「間違えた問題だけ復習したい」
- 「何問中何問正解したか、最後にまとめて見たい」
特に1つ目は衝撃でした。自分はPC中心で開発・テストしていたので、スマホでの「親指の動線」をまったく考慮できていなかったんです。この指摘を受けて、正解表示をワンクッション挟む方式に変更したところ、その後に計測した1セッションあたりの平均回答数が4.2問から7.8問に伸びました。
80問の時点で出したからこそ、設計の根本部分を手戻り少なく修正できた。500問作り込んでからだったら、直すのにもっと時間がかかっていたと思います。
学び： 「完成してからリリース」ではなく、「コアの体験が最低限動く段階」で出す。恥ずかしさは3日で消える。
2. 監視ツールの早期導入（個人開発でもオブザーバビリティは必要だった）
「個人開発に監視ツールなんて大げさでは？」と思っていた時期がありました。
考えが変わったのは、リリースから2ヶ月目のある朝。Twitterで「takkenaiが動かない」というポストを見つけて血の気が引いた瞬間です。慌ててSupabaseのダッシュボードを開くと、無料枠のDBコネクション数が上限に達していて、新規接続が全部弾かれていた。障害発生から自分が気づくまで約6時間。 ユーザーにとっては「朝の通勤時間に勉強しようと思ったのにアプリが動かない」という最悪の体験です。
この日のうちに、以下を導入しました。
- Uptime Kuma（セルフホスト）で5分間隔のヘルスチェック → ダウン検知でSlack通知
- Supabaseのメトリクス監視をcronで叩いて、コネクション数が80%を超えたらアラート
- Sentryでフロントエンドのエラーを自動収集（無料枠で十分）
導入コストは丸1日。月額費用はSentryの無料枠 + VPS上のUptime Kumaなのでほぼゼロ。
それ以降、障害の検知時間は平均6時間 → 平均8分に短縮されました。さらにありがたかったのは、Sentryのエラーログから「iOS Safari 16.xで特定の問題タイプだけレンダリングが崩れる」というバグを発見できたこと。ユーザーからの報告を待っていたら、何週間も放置していたかもしれません。
学び： 監視は「大規模サービスのもの」ではない。個人開発こそ、自分の代わりに見張ってくれる仕組みが必要。
3. Claude Code導入（開発速度が体感2〜3倍になった）
開発8ヶ月目にClaude Codeを本格導入しました。それまではChatGPTにコードを貼り付けて相談するスタイルだったのですが、Claude Codeはターミナルから直接コードベースを読み書きできるので、体験がまったく違います。
具体的に一番効果が大きかったのは、問題データの整備と検証の自動化です。
takkenai.jpは1250問以上の宅建問題を扱っていますが、問題データのフォーマット統一・重複チェック・解説文の品質確認は、手作業でやると気が遠くなる作業でした。Claude Codeに「問題データのJSON全件を読んで、解説が100文字未満のものを抽出し、各問題について宅建試験の観点から解説を補強して」と指示すると、1250問のスキャンと修正提案を約15分で完了。手作業なら丸2日はかかっていた作業です。
また、Next.jsのApp Router移行作業もClaude Codeと一緒に進めました。既存のpagesディレクトリの構成を読み取った上で、appディレクトリへの移行計画を提案してもらい、1ファイルずつ移行を実行。移行作業全体で約3日かかる想定が、1.5日で完了しました。
もちろん、生成されたコードを全部ノーチェックでマージしているわけではありません。特にSupabaseのRLS（Row Level Security）ポリシーに関わる部分は、Claude Codeの出力を必ず自分で検証しています。セキュリティに関わる部分を丸投げするのはさすがに怖い。
学び： AIツールは「コードを書いてくれるもの」ではなく「開発のペアプロ相手」として使うと最も効果的。得意領域（データ処理、リファクタリング、テスト生成）を見極めて任せる。
やらなくてよかったこと
1. 過剰な抽象化（DRYを追求しすぎて迷宮を作るところだった）
開発3ヶ月目、「問題を表示するコンポーネント」を作り直した時期がありました。
一問一答モード、分野別モード、模試モード、復習モードと表示パターンが増えてきたので、「汎用Questionコンポーネントを作って全部統一しよう」と考えたのです。Props数は15個、内部の条件分岐は12箇所。自分では「美しい抽象化」のつもりでした。
しかし2週間後、模試モードだけに「残り時間表示」を追加しようとした瞬間、その汎用コンポーネントの中にif文がさらに増え、どの条件がどのモードに対応しているのか自分でもわからなくなりました。
結局、モードごとにコンポーネントを分けて、共通部分だけを小さなパーツとして切り出す方式に戻しました。コードの行数は1.4倍に増えましたが、各コンポーネントの変更にかかる時間は体感で半分以下に。
個人開発は自分しかコードを読まない分、「未来の自分が読んでわかるか」が唯一の基準です。
学び： DRYは手段であって目的ではない。「コピペは悪」という意識が強すぎると、かえって保守しづらくなる。個人開発では「多少の重複 > 過度な抽象化」。
2. 早すぎるマイクロサービス化（モノリスで十分だった）
開発5ヶ月目、ユーザー数が100人を超えたあたりで、なぜか「そろそろスケールを考えないと」と思い始めました。
「問題配信API」「ユーザー管理API」「AI解説生成サービス」を分離して、それぞれ独立してデプロイできるようにしよう——。設計図まで書いて、Dockerfileを3つ作ったところで冷静になりました。
同時接続ユーザー数、最大でも12人。
分割したところで、デプロイの手間が3倍になり、サービス間通信のエラーハンドリングを考える必要が生まれ、ログの追跡も面倒になる。得られるメリットは「なんかプロっぽい構成図が描ける」くらいです。
結局、Next.jsのAPI Routesにすべて載せるモノリス構成のまま運用を続けています。Vercelの無料〜Proプランで問題なく動いており、レスポンスタイムも平均200ms以下。仮にユーザーが10倍になっても、Vercelのエッジ + Supabaseの組み合わせなら、現構成でまったく問題ありません。
あのまま分割に突き進んでいたら、2〜3週間は機能開発が止まっていたはずです。
学び： 「スケールの問題」は、実際にスケールの問題が起きてから考えれば十分。個人開発の敵は"トラフィック過多"ではなく"開発停滞"。
3. 複数SNS同時運用（Twitterだけで十分だった）
リリース直後、「露出を増やさなきゃ」と焦って、Twitter（X）、Instagram、TikTok、noteを同時に始めようとしました。各プラットフォーム用にコンテンツを作り分けて、投稿スケジュールを組んで……。
1週間で破綻しました。
当たり前なのですが、各SNSで求められるコンテンツ形式がまったく違います。Instagramは画像中心、TikTokは動画、noteは長文。それぞれに最適化しようとすると、1日の可処分時間のうち3〜4時間がSNS運用に消えて、肝心の開発が進まないのです。
結局、Twitterに絞って、以下のルールだけ決めました。
- 開発の進捗や学びを1日1ツイート
- ユーザーの声（許可を得て）のリポスト
- 新機能リリース時だけ少し丁寧に告知
これだけで月に2〜3件、自然な流入が発生しています。大きなバズはありませんが、宅建の勉強をしている層がTwitterにいるので、ターゲットとプラットフォームが合っていたのだと思います。
学び： 個人開発者のリソースは有限。SNSは「ユーザーがいる場所」1つに絞って、残りの時間は開発に回す。
1年間を振り返って
6つの項目を並べてみて気づいたのは、「やってよかったこと」はすべて開発・運用の効率を上げるもので、「やらなくてよかったこと」はすべてエンジニアとしての見栄や不安から生まれたものだったということです。
個人開発は、自分のリソース（時間・体力・モチベーション）をどこに配分するかのゲームです。カッコいいアーキテクチャも、映えるSNS運用も、ユーザーに価値が届かなければ意味がない。
逆に、ユーザーフィードバックを早くもらう、障害に早く気づく、AIで開発を加速する——これらは全部、ユーザーに届く価値を最大化するための投資でした。
おわりに
この1年間の学びを詰め込んで作っているのが、宅建試験のAI対策アプリ takkenai.jp です。1250問以上の問題をAI解説付きで提供しています。2025年度の宅建試験を受ける方は、ぜひ使ってみてください。
個人開発は孤独になりがちですが、こうやって振り返りを言語化するだけでも頭が整理されます。同じように個人開発をしている方の参考になれば幸いです。
何か質問やご意見があれば、コメントやTwitterでお気軽にどう