1. はじめに
独力＋AI活用で月商1億円を目指している。
今日は外出予定がある。
普通なら、外出している間は開発が止まる。
しかし、今はAIを使っている。
Cursorに作業キューを積んでおけば、自分が外出している間も、ある程度は開発を進められる。
そこで今回は、少し思い切って、開発範囲のスコープを大きく広げた。
そして、Cursorにかなり多めの指示を投入した。
その数、約60キュー。
正直、ちゃんと動くのか少し不安である。
ただ、今の開発用PCはかなり安定している。
正本ルールも整ってきた。
開発用PCと確認用端末の役割分担も固まってきた。
ブロッカー管理、制限事項管理、完了報告、FixedとConfirmedの考え方も整理されてきた。
だから今回は、外出時間を開発時間に変える実験として、あえて大きめに動かしてみることにした。
2. なぜ60キューも入れたのか
理由はシンプルである。
今日、自分がPCの前にいられないからである。
AI開発では、人間が見ていない時間も作業に変えられる可能性がある。
寝ている間。
外出している間。
移動している間。
食事している間。
別作業をしている間。
この時間に、AIが開発用PC上で作業を進めてくれれば、個人開発としてはかなり大きい。
ただし、何でもかんでもAIに任せればよいわけではない。
大量キューは、うまくいけば強い。
しかし、失敗すると差分が大きくなりすぎる。
途中で方針がズレても、そのまま進む。
ドキュメント更新だけに寄る可能性もある。
ビルド失敗後に変な修正が積み重なる可能性もある。
だから、60キュー投入は、かなり攻めた運用である。
3. 今回スコープを広げた理由
最近の開発では、重要な課題が見えてきた。
それは、単純な機能不足ではない。
もっと根本的に、画面体系や導線設計を見直す必要が出てきた。
これまで機能を増やしてきた結果、既存画面に多くの役割が集まりすぎている。
画面数が足りないのに、機能ばかり追加してきた。
その結果、1つの画面に複数の目的が詰め込まれ、ユーザーが迷いやすくなっている。
つまり、導線カオスである。
これは、少しボタンを直せば済む話ではない。
画面の目的、画面数、画面分割、フェーズ別の導線、常時参照画面、イベント発生画面まで含めて見直す必要がある。
そこで今回は、細かい1件だけを直すのではなく、開発スコープを広げた。
画面体系の整理
導線カオスの解消
主要画面の目的整理
P0/P1作業の継続消化
既知ブロッカー・制限事項の扱い
確認用端末に戻すべき観点の整理
正本ルールに沿った進捗報告
こうした範囲をまとめて進める方向にした。
4. 60キューは効率的なのか
以前、Cursorの大量キュー運用についても考えた。
結論としては、正本ルールが弱い状態で50キュー、60キューを積むのは危険である。
しかし、今のように正本ルールがあり、作業優先順位、停止条件、Git運用、完了報告の型があるなら、大量キューはかなり有効になる。
特に、以下のような条件がそろっている場合は強い。
開発用PCが安定して動く
main直作業を禁止している
featureブランチで作業する
ビルドやテスト失敗時の停止条件がある
ドキュメント更新だけに逃げないルールがある
進捗率や残課題を報告させている
確認用端末で再確認すべき範囲を明記させている
この前提なら、大量キューは「危険な暴走」ではなく、外出中の自走開発バッチとして使える可能性がある。
今回は、まさにそれを試している。
5. ただし、怖さもある
もちろん、怖さはある。
60キューも積むと、途中で何か起きたときに、その影響が大きくなる。
たとえば、
早い段階でビルドが壊れる
その状態で後続の修正が走る
原因がズレたまま修正が積み上がる
ドキュメントだけ更新されて実装が進まない
同じファイルに変更が集中する
差分が大きくなりすぎる
外出から戻ったときに把握が大変になる
こうなると、せっかくの自走が逆効果になる。
だから、今回のポイントは、単に60キューを入れることではない。
60キュー入れても暴走しないように、正本ルールと停止条件を整えておくことである。
6. 最近整ってきたプロジェクト管理ルール
ここ最近、かなりプロジェクトマネジメント寄りの整備を進めてきた。
開発用PCと確認用端末の役割分担。
確認用端末によるシナリオ試験。
既知ブロッカー・制限事項台帳。
FixedとConfirmedの分離。
指摘ID単位の管理。
完了報告フォーマット。
進捗率と残り所要時間の報告。
導線カオスの棚卸し。
画面体系の再設計。
これらは、地味だがかなり重要である。
AIを使うと、作業速度は上がる。
しかし、管理が弱いと、作業が増えた分だけ混乱も増える。
だから今は、AIを使う力よりも、AIを管理する力が重要になってきている。
今回の60キュー投入も、ただの勢いではない。
正本ルールが整ってきたからこそ試せる運用である。
7. 今日の外出中に期待していること
今日、外出している間に期待していることは、完璧な完成ではない。
そこまで期待すると危ない。
期待しているのは、以下である。
P0/P1の一部が進む
画面体系整理が進む
導線カオス解消の土台ができる
ドキュメントと実装の整合が進む
自動テストやビルドで大きな破綻が見つかる
次に人間が判断すべきポイントが明確になる
確認用端末に戻すべき再確認範囲が整理される
つまり、外出中にAIが全部終わらせるというより、次の判断材料を作ってくれることを期待している。
AI開発では、AIが勝手にゴールまで行くわけではない。
人間が戻ってきたときに、差分、検証結果、残課題、リスクを確認して、次の判断をする必要がある。
8. 帰ってきたらまず確認すること
外出から戻ったら、いきなり次の指示を出すのではなく、まず確認する。
見るべきものは決まっている。
git status
変更ファイル
commit / push状況
build / lint / test結果
完了報告
進捗率
残課題
リスク・未確認事項
差分が大きくなりすぎていないか
重要ロジックに不用意に触っていないか
ドキュメントだけで終わっていないか
確認用端末で再確認すべき範囲
特に、今回はキュー数が多いので、差分確認が重要になる。
作業が進んでいても、内容がズレていたら意味がない。
大量キューの成否は、最後の検収で決まる。
9. うまく動けばかなり強い
もし今回うまく動けば、これはかなり強い。
外出中に開発が進む。
寝ている間に作業が進む。
人間が戻ってきたら、報告を見て判断する。
必要に応じて確認用端末で実機確認する。
問題があれば開発用PCに戻す。
この流れが回るようになると、個人開発の限界をかなり押し広げられる。
人間1人では、稼働時間に限界がある。
しかし、AIと安定稼働PCを組み合わせると、自分の不在時間も作業時間に変えられる。
もちろん、品質管理は必要である。
ただ、運用が固まればかなり強い。
10. うまく動かなかった場合も学びになる
逆に、今回うまくいかなかったとしても、それはそれで学びになる。
たとえば、
60キューは多すぎた
停止条件が弱かった
指示が曖昧だった
実装よりドキュメントに寄りすぎた
差分が大きくなりすぎた
途中でテスト失敗を引きずった
外出中に任せる作業の種類を絞るべきだった
こうしたことが分かる。
その場合は、次回から改善すればよい。
たとえば、通常は20キュー、就寝時は30キュー、安定作業だけ50キュー以上にする。
DBや認証、課金のような重要領域は10キューで区切る。
導線整理やUI改善のような範囲に限定する。
停止条件をさらに強める。
失敗しても、運用改善につながるなら意味がある。
11. AIを使うというより、AIを運用している
最近、自分の中で感覚が変わってきた。
AIを使っているというより、AIを運用している。
単発で質問するだけではない。
Cursorに作業を積む。
ChatGPTで指示を作る。
開発用PCに自走させる。
確認用端末に試験させる。
ドキュメントでルールを固定する。
完了報告で検収する。
必要ならキュー数や作業範囲を調整する。
これは、かなりプロジェクトマネジメントである。
人間の作業者を管理するのと同じように、AIにも役割、作業範囲、報告形式、停止条件、完了条件が必要になる。
今回の60キュー投入は、その運用実験でもある。
12. 今回の結論
今日は外出するため、開発範囲のスコープを大きく広げて、Cursorに約60キューを投入した。
正直、ちゃんと動くかは少し不安である。
ただし、今は以前よりも運用ルールが整っている。
開発用PCは安定している。
正本ルールもある。
確認用端末との役割分担もある。
ブロッカー管理や制限事項管理も整ってきた。
FixedとConfirmedの区別もある。
導線カオスや画面体系の課題も見えてきた。
だから今回は、外出中の時間を開発時間に変えるために、あえて大きく動かしてみる。
もちろん、60キューは万能ではない。
うまく進むかもしれない。
ズレるかもしれない。
差分が大きくなりすぎるかもしれない。
ドキュメントに寄りすぎるかもしれない。
帰ってきたら、まず検収する。
作業が進んだか。
品質は保てているか。
ビルドやテストは通っているか。
次に何をすべきか。
AIを寝ている間や外出中にも働かせる。
ただし、暴走させない。
このバランスを取れるかどうかが、独力＋AI活用の開発ではかなり重要になってきた。
