最近の個人開発は、実装のほとんどをClaude Codeに任せています。ただ、うまくいくかどうかは実装よりも「指示書を書くまで」でだいたい決まる、というのが今のところの実感です。
思いついたアイデアをClaude Codeに渡すまでに、何をしているかを書きます。
アイデアを考える
着想はいつも次のどちらかです。
- 自分が使いたいもの
- 誰かが困っていて、アプリを作ったら解決しそうなもの
ここは急がず、何日か寝かせて考えます。
アイデアを言語化する
ある程度固まってきたら、チャットの方のClaudeに渡します。このとき、いつも使っているライブラリの一覧も一緒に渡すようにしています。
最近は似たようなライブラリセットを使い回しているので、この一覧はほとんど変わりません。それでも毎回渡すのは、ライブラリ名を共有しておくと、AIと自分のあいだで完成イメージのすり合わせがしやすくなるからです。
あわせて、類似ツールがあるかどうかも調べてもらいます。見つかった場合は、そのツールについて詳しく教えてもらったうえで、自分が作るものはどこで差が出るのかを考えます。その差の部分が、そのまま価値になると思っています。
サークルスケジューラーであれば、画面の情報量の少なさとアプリのシンプルさを、ずっと価値だと考えて作りました。連絡や共有はLINE・Discord・Googleドライブでできるので、そちらは既存のアプリに任せる。「メンバーの出欠登録・確認」「所属ごとの集計」だけがサークルスケジューラーの役割、という切り分けです。
このやりとりで、
- どんな機能を持つか
- どのようなライブラリを使うか
を決めます。
何を作らないかを決める
将棋ジェネシスでは、ここに加えて「何を作らないか」をかなり考えました。
最初の段階では、CPU対戦機能とオンライン対戦機能を作らないことにしました。代わりに、盤面を横並びで2つ配置して、画面共有しながら2人で対戦できるようにしています。
通信機能を作り込むより、まず遊べる形にすることを優先しました。動くものが速く完成したほうが、次に何を足すかの判断もしやすくなります。
最後に「Claude Codeに指示出すから指示書作って」のように頼んで、ここまでの話をまとめてもらいます。
実装
リポジトリを作って、指示書を貼り付けます。
最近はSkillsも用意したので、それにも従ってもらうようにしています。いつものライブラリのセットアップ手順や、コーディング・コメントの方向性などをここに書いています。
できあがったあと
よほどのことがなければ、この指示で作りたいものは完成します。自分で触ってみて、問題がなければ一区切りです。
可読性や保守性が下がらないように作らせているので、この後の修正もそこまで大変にはなりません。
結局のところ、指示書を作るまでの段階でイメージが明確になっているほど、その後の改善は楽になります。手を動かす前に考えている時間が、いちばん効いている気がします。