2025年6月、Claude Codeで複数のAIへ役割を分け、並列に開発させる方法を試しました。 一つのAIへ実装を頼むだけではありません。 PM役のAIが開発者役のAIへ仕事を割り振り、結果を集めて報告する構成です。
まだ自分でも理解しきれていない部分はありました。 それでも、実装にかかる時間が大きく変わることだけはわかりました。
そこで気になったのは、開発速度の先にあるものです。 作れる量が増えたとき、何を作るかは誰が決めるのでしょうか。
実装できることが差にならなくなる#
以前の個人開発では、アイデアがあっても実装が壁になりました。 新しい技術を学び、設計し、コードを書き、エラーを直して、ようやく公開できます。
生成AIは、この壁をかなり低くします。 仕様を言葉にできれば、実装の候補を出し、複数の作業を同時に進められるようになりました。
すると、開発者の価値がなくなるというより、重心が移ります。
- どんな不便を課題として選ぶか
- 解決後の状態をどう説明するか
- 曖昧な願望を、作れる仕様へ変えられるか
- 作ったものを、必要な人へどう届けるか
コードを書く力は引き続き役立ちます。 ただ、コードだけでは作る対象を決められません。
AIで実装が速くなるほど、課題意識の差がそのままプロダクトの差になります。
会社には課題の手触りがある#
個人開発に集中するなら、会社を辞めて時間を増やしたほうがよいと考えたこともあります。 しかし、人と協力して働く環境には、外から眺めるだけでは見えない課題があります。
同じ言葉を使っているのに認識がずれる。 一つの確認に何人もの時間が使われる。 仕組みとしては正しくても、使う人がためらう。
こうした不便は、業務フローの図だけでは見つかりません。 人の感情や関係性を含むからです。
私は会社員として働くなかで、自分の考えと現実のずれを何度も見ます。 そのずれが、「なぜこうなっているのだろう」という問いになります。
会社は、完成したアイデアを配ってくれる場所ではありません。 課題の手触りに触れられる場所です。
課題を持ち帰り、抽象化する#
仕事で見つけた不便を、そのまま個人プロダクトに持ち込むわけにはいきません。 会社の情報や固有の事情を外へ出すことはできませんし、一社だけの問題なら他の人には役立ちません。
そこで必要になるのが、具体と抽象の往復です。
たとえば「特定の資料を毎回手で直す」という不便があったとします。 その会社の資料を再現するのではなく、「情報が変わるたびに複数の場所を更新している」という構造まで引いて考えます。 そこから、別の場面でも起きている問題かを確かめます。
AIは、候補を広げたり仕様へ落としたりする作業を手伝えます。 ただし、最初の違和感まで代わりに持ってくれるわけではありません。
課題意識ドリブンで作る#
当時の私は、帰宅後にAIへ指示を出し、食事をしている間に実装が進む未来を想像しました。 その景色は、以前ほど遠いものではなくなっています。
一方で、作れるから作っただけのプロダクトも増えます。 実装速度だけを競うと、似た機能が短い周期で並ぶことになります。
だから私は、技術ドリブンより先に 課題意識ドリブン で考えたいです。 繰り返し出会う不便を観察し、誰がどこで困っているのかを言葉にしてから、AIへ実装を頼みます。
会社員でいることと、個人開発をすることは、反対ではありませんでした。 昼に人と働くなかで課題を知り、夜に解決の形を試せます。
実装できる量が増えた今、私が増やしたいのはプロダクトの数だけではありません。 見過ごさずに持ち帰れる問いの数です。
課題を見つけるときの具体的な観察方法は、個人開発の題材を、身近な課題から選ぶための観察にもまとめています。
