はじめに
この記事は、個人開発サイトの認知獲得のためにClaudeさんと一緒に考えて作りました。宣伝です。
私はWebエンジニアとして働いていて、仕事では「これ作って」と言われたものは作れます。でも自分のことになると、「そんなん作ってもなぁ」「あれがないとできないよなぁ」とうだうだ悩んで、結局何も始められない日々を過ごしていました。
そんな私が、Claude Codeを使い始めてから個人開発が動き出しました。この記事では、キャリア相談から始まって実際にサイトを公開するまでの経緯を書きます。
きっかけ：キャリア相談で怒られた
最初はコードを書かせるつもりで使い始めたわけではありません。
将来のことを漠然と心配していて、Claude Codeでキャリア相談をしていた折り、「時間と収入を切り離したい」「何か収益化できるものを作りたい」という話をしていたら、プロダクト開発の話に発展しました。
でも相談の中で出てくる不安。
- 「売れるかどうか心配」
- 「競合が多くて埋もれそう」
そんなことをうだうだ言っていたら、Claudeさんに怒られました。
「最初から売れなくていい。完成させるのが先。その経験を積むのが目的」
正直まだ不安です。これに意味があるのかと未だに悩んでいます。でも動かないとまた同じ日々なので、ひとまず動き始めることにしました。
作ったもの：海外ゲーム向け英語学習サイト
何を作るか本当にわからなくて、「今困っていることない？」とClaudeさんに聞かれました。
出てきたのが「英語できない」という話。とはいえただの英語学習サイトを作っても埋もれてしまう。そこで私の「英語しかないゲームを遊びたいのに遊べない」というちょっとニッチな需要に絞って、海外ゲーム向けの英語学習ツールを作ることにしました。
当初は会社で使っている技術（AWSとか）を自分でゼロから構築して身につけたいと考えていました。でもまた怒られました。
「そんなもんいらねえ、AWS？Vercelで十分。まずつくるところから始めなさい」
ということで、最小構成でクイズ10問、Vercelで公開、という形になりました。
作ったサイト → ゲーム英語の読解クイズ
海外RPG風の英文を読んで、内容理解を問うクイズサイトです。
全部Claudeさんと相談しながら決めました。一人で悩んでいたら決まっていなかったと思います。
仕組み化した3つのこと
ご存知の通り、Claudeさんは記憶を引き継ぎません。コンテキストがあふれたら新しいClaudeさんになります。一週間フレンズならぬ1セッションフレンズです。かなしい。
これをなんとかする、対話のための仕組みを設けました。Claude Codeのカスタムスラッシュコマンド機能を活用しています。
1. ログで経緯を残す
もともと日々の相談ごとをログに残していたので、それを開発にも転用しました。
- 方針の決定
- 今の課題
- これからやること
- なぜそう決めたか
これを dev-log/YYYY-MM-DD.md のような形で記録してリポジトリで管理してしまう。こうしておくことで後から「なんでこうしたんだっけ」を振り返れるようになりました。
実際のログはこんな感じです。
## 認知獲得戦略の再検討
### 背景
- 現状: 月間0人
- SNS投稿がヒットしない（フォロワー0）
### 問題点
- フォロワー0でSNS投稿しても届かない
- 交流でフォロワーを増やすのは負担が大きい
### 検討結果
| 施策 | 判断 |
|------|------|
| 技術記事 | 一方向発信できる。やる |
| SNS投稿 | 投稿頻度を上げて並行で進める |
### 決定
記事執筆を主、コンテンツ拡充を従として並行で進める。
フォーマットは固定していません。「背景→問題点→検討→決定」のような流れで書くこともあれば、箇条書きだけのこともあります。大事なのは「なぜそう決めたか」が残っていること。
2. /start で文脈を引き継ぐ
上述のログを、セッション開始時に /start コマンドを実行し読み込ませることで「前回ここまでやりました。今日はどうしますか？」と聞いてくれます。方針に悩んだときはもっと過去のログを、決定を、経緯を漁ることができます。
平日は開発できないけど週末に記憶を取り戻せる。これが地味に助かっています。
3. おまけ：もうちょっと楽をしたい
ログを残して読ませる仕組みができれば、ベースは完成です。
あとはもうちょっと楽をしたいなと思って、開発フロー全体を整えてみました。
| フェーズ | やること | コマンド |
|---|---|---|
| 方針確認 | Claudeさんと対話。何を作るか、なぜ作るかを整理 | /start |
| 設計 | 設計書を作成してもらい、さらにその設計をレビュー |
/issue, /design-review
|
| 実装 | Claudeさんに丸投げ。E2Eテストも書いてもらって動作確認。スクショも撮って見てもらうことでレイアウト確認も |
/branch, /e2e
|
| PR | 実装単位でPR作成。この時、実装内容のレビューもClaudeさんにしてもらう |
/pull-request, /review
|
| マージ | ぱっと見て問題なければマージ | /pull-request merge |
このフローであれば設計も実装にも自動でチェックが入ります。不足を感じたら確認の際に読み込ませるルールを拡充し、理想のコード品質に近づけていきます。
理想は要望を投げたら全部回ってものができる状態。きっとすでに先駆者はいらっしゃるはず。わたしのはまだ発展途上ですが、少しずつ近づいています。
まとめ
正直、これが成功するとは思っていません。でも、いい開発体験にはなっています。
個人開発なのに議論の相手がいる。これは今までになかった体験でした。
もし同じように動けなくて困っている人がいたら、試してみてください。
そして、この記事が私の個人開発サイトの認知獲得の一助となることを願っています。