1. はじめに
独力＋AI活用で月商1億円を目指している。
最近、開発用PC、既存端末、AIツール、GitHub、自動テスト、ドキュメントを組み合わせながら、開発体制をかなり試行錯誤している。
現在は、開発用PCを主戦場にして実装を進め、既存端末は節目ごとの実機確認やシナリオ試験に使う方針にしている。
この体制はかなり良くなってきた。
ただ、ふと思った。
もしここに3台目のPCを追加したら、さらに速くなるのではないか。
結論から言うと、3台に増えたら作業は早くなる可能性はある。
ただし、単純に3倍速にはならない。
むしろ役割分担を間違えると、Git衝突、確認漏れ、AIツール消費増、ドキュメント作業の増加で、逆に遅くなる可能性もある。
2. 3台構成は有効。ただし条件付き
今の状況なら、3台目を入れる効果は中〜大くらいあると思っている。
ただし、条件がある。
3台すべてに同じような作業をさせてはいけない。
それぞれの役割を明確に分ける必要がある。
理想は以下の形である。
| 端末 | 役割 |
|---|---|
| 開発用PC | メイン実装、ビルド、自動テスト、修正反映 |
| 既存端末 | 実機UI確認、シナリオ試験、スクリーンショット報告 |
| 3台目PC | サブ作業、ドキュメント整理、軽量UI改善、軽量確認、別ブランチ作業 |
これなら意味がある。
一方で、3台すべてに開発をやらせると危ない。
同じファイルを複数台で触る。
同じ機能を別々のブランチで直す。
仕様が曖昧なまま並行して進める。
複数端末で同じドキュメントを更新する。
こうなると、効率化どころか混乱する。
3. 3台にすると早くなる作業
3台体制で一番効くのは、待ち時間の削減である。
開発用PCで実装している間に、別端末で確認できる。
自動テストを回している間に、別端末でドキュメント整理ができる。
実機確認をしている間に、3台目で次の作業指示を整えられる。
たとえば、以下のような作業は並行しやすい。
ビルド確認
軽量な自動テスト
画面確認
スクリーンショット取得
UI崩れ確認
試験報告の整理
残課題一覧の更新
次回作業指示の整理
これはかなり効く。
特に、AIを使った開発では「待ち時間」が意外と多い。
AIが実装している間。
テストが走っている間。
ビルドが終わるのを待つ間。
GitHub Actionsを待つ間。
PRの状態を確認する間。
この時間に別作業を進められるなら、3台目の価値はある。
4. ドキュメント作業を分離できるのは大きい
今の開発では、ドキュメントもかなり重要である。
作業ルール、残課題一覧、試験結果、Cursorへの指示文、仕様整理、運用計画。
これらが整理されていないと、AIが迷う。
ただし、ドキュメント作業が増えすぎると、実装が止まる。
これは何度も感じている。
AIは、安全に進めようとして、実装ではなくドキュメント整理に寄ることがある。
もちろんドキュメントは必要だが、実装が進まないなら意味がない。
そこで、3台目PCをドキュメント整理や軽量補助に使うのはかなり有効だと思う。
開発用PCでは実装を進める。
3台目では残課題や試験報告、次回指示を整理する。
この分離ができると、開発本線を止めにくくなる。
5. UI改善を別ラインで進められる可能性
3台目PCは、軽量なUI改善にも向いている。
ただし、ここは注意が必要である。
大きな画面改修や共通部品の大改修を3台目に任せると、開発用PC側と衝突しやすい。
同じ画面や同じファイルを触ると、Gitコンフリクトの原因になる。
一方で、以下のような作業なら3台目に任せやすい。
表示文言の微修正
空データ時の表示改善
軽微な余白調整
スクリーンショット整理
デザイン案の棚卸し
UI改善候補の整理
READMEや残課題一覧の更新
試験結果レポートの整理
つまり、3台目は第2のメイン開発機にするより、補助開発＋ドキュメント＋軽量UI＋検証補助として使った方が安全である。
6. 3台にしても速くならない作業
逆に、3台にしても速くならない作業もある。
それは、同じ領域を複数台で同時に触る作業である。
たとえば、
2台以上で同じ主要画面を修正する
2台以上で同じ共通部品を変更する
2台以上で同じデータ構造を変更する
2台以上で同じドキュメントを更新する
仕様が固まっていない機能を複数台で並行開発する
これは危険である。
速くなるどころか、統合が大変になる。
AI開発では、各端末がそれぞれ正しそうなことを言って進めてしまう。
その結果、あとで統合するときに方針がズレていることがある。
だから、重要なロジックやデータまわりは、基本的にメイン開発PCに寄せた方がよい。
3台目は、主戦場ではなく補助戦力にする。
7. 体感速度の見立て
かなりざっくりだが、体感速度は以下のように見ている。
| 構成 | 体感速度 |
|---|---|
| 1台 | 基準 |
| 2台 | 1.3〜1.6倍 |
| 3台 | 1.5〜2.0倍 |
| 3台を雑に使う | 0.8〜1.2倍に落ちる可能性あり |
重要なのは、3台にすれば必ず速くなるわけではないということだ。
管理ルールがない3台体制は危険である。
どの端末が何をするのか。
どのブランチで作業するのか。
どのファイルを触るのか。
どこまで検証するのか。
誰が最終統合するのか。
これが決まっていなければ、3台目は効率化ではなく混乱の原因になる。
8. 3台目に任せてよい作業
3台目に任せるなら、まずは以下がよい。
ドキュメント整理
試験報告の分類
軽微なUI修正
表示文言修正
空データUI改善
スクリーンショット整理
デザイン素材の棚卸し
デザイン反映案の整理
README更新
残課題一覧の更新
テスト結果レポート整理
次回Cursor指示文の下書き
このあたりは、メイン実装と衝突しにくい。
特に、試験報告や残課題の整理は3台目に向いている。
メイン開発PCを止めずに、周辺整理を進められるからだ。
9. 3台目に慎重に任せるべき作業
逆に、以下は3台目に安易に任せない方がよい。
データ構造の変更
マイグレーション
seedの大幅変更
課金処理
認証処理
middleware
共通コンポーネントの大改修
コアロジックの修正
重要な状態管理
これらは影響範囲が広い。
メイン開発PC側で慎重に進めるべきである。
3台目に任せる場合でも、ブランチを明確に分け、作業範囲を限定し、統合前に必ずメイン側で確認する必要がある。
10. 理想の3台フロー
理想の流れは以下である。
1. ChatGPTで作業分担を決める
↓
2. 開発用PCがメイン実装ブランチで作業
↓
3. 3台目PCが別ブランチで軽量作業
↓
4. 既存端末が最新成果物を実機確認
↓
5. 実機確認結果を開発用PCへ戻す
↓
6. 開発用PCがP0/P1を修正
↓
7. 3台目PCはドキュメント・軽微UI・整理を継続
この形なら、3台それぞれの役割が分かれる。
開発用PCは主戦場。
既存端末は確認係。
3台目は補助係。
これが一番安全だと思う。
11. 3台運用のルール
3台体制にするなら、最低限のルールが必要である。
1. メイン開発PCを固定する
2. 既存端末は実機確認・試験報告に寄せる
3. 3台目は軽量作業・ドキュメント・UI補助にする
4. 同じファイルを複数台で触らない
5. ブランチと作業宣言を必ず分ける
6. main直作業は禁止
7. 統合判断はメイン開発PC側に寄せる
8. 重要ロジックはメイン開発PCで扱う
9. 3台目の作業は小さくPR化する
10. 不要なフル検証を増やさない
これを守れば、3台目はかなり有効になる可能性がある。
逆に、これを守らないなら、3台に増やす意味は薄い。
12. 今すぐ3台をフル稼働させるべきか
現時点では、いきなり3台をフル稼働させるより、まずは今の2台運用を安定させた方がよいと思っている。
つまり、
開発用PC中心で実装を進める
既存端末は節目レビューやシナリオ試験に使う
ドキュメント作業を増やしすぎない
Cursor指示を短縮しつつ、進捗報告は省略させない
この運用をまず固める。
そのうえで、3台目を追加するなら、最初は補助作業に限定する。
最初から第2の実装マシンにするのは危険である。
13. 今回の結論
3台体制にすれば、作業は早くなる可能性がある。
ただし、3倍速にはならない。
役割分担がうまくいけば、体感としては1.5〜2.0倍くらいの効率化は期待できる。
しかし、雑に使えば0.8〜1.2倍まで落ちる可能性もある。
3台目を入れるなら、役割は明確にする。
開発用PCはメイン実装
既存端末は実機確認・シナリオ試験
3台目PCは軽量作業・ドキュメント・UI補助
この形なら、かなり有効だと思う。
今のように、実装、UI改善、自動テスト、実機確認、ドキュメント整理がすべて必要な段階では、3台目の意味はある。
ただし、PCを増やすだけでは速くならない。
速くなるのは、役割を分け、作業範囲を限定し、統合ルールを守った場合だけである。
AI時代の個人開発では、端末を増やすこと自体が戦略になる。
しかし、それ以上に大事なのは、端末ごとの役割を明確にすることだ。
3台目を入れるなら、勢いではなく運用設計とセットで考えたい。
0 件のコメント:
コメントを投稿