1. はじめに
月商1000万円を目指して、新規プロジェクトを進めている。
ここまで、新PCの導入、Cursor Ultraへのアップグレード、PlaywrightによるE2Eテスト、ChatGPTとの壁打ち、GitHub連携などを使いながら開発を進めてきた。
そして最近、ようやくPC2台体制の使い方が見えてきた。
結論から言うと、
BOSGAME P3 PLUSを開発専用機、Surfaceをテスト専用機として分担させる形が一番分かりやすい。
以前は、両方のPCに開発をやらせることも考えていた。
しかし、実際に進めてみると、両方で開発すると連携に無駄が出る。
どちらがどのファイルを触っているのか、どのブランチで作業しているのか、どちらの変更が最新なのか、確認コストが増える。
その結果、2台あるのに、かえって管理が難しくなる可能性があった。
そこで、役割を分けることにした。
2. BOSは開発専用機
BOSGAME P3 PLUSは、開発専用機として使う。
役割はかなり明確である。
Cursorで実装する
コードを修正する
新機能を追加する
UIを改善する
E2Eテストを追加する
lint / format / build を実行する
commit / push まで行う
mainやfeatureブランチの作業を進める
つまり、BOSは作る側である。
新PCを買った目的は、まさにここにある。
実装、ビルド、E2E、commit / pushまでを安定して回す。
開発作業を止めない。
Cursorを本格的に使う。
この役割にBOSを集中させることで、かなり分かりやすくなった。
3. Surfaceはテスト専用機
一方で、Surfaceはテスト専用機に寄せる。
Surfaceでは、BOSが実装したものを確認する。
役割としては、以下である。
GitHubから最新を取得する
mainまたは指定ブランチを確認する
UI観点で画面を見る
Playwrightや手動確認を行う
スマホ・タブレットに近い見え方を確認する
Surface側の確認結果をドキュメント化する
BOS向けの次回指示を作る
docs/surface-output/に確認結果や改善指示を置く
つまり、Surfaceは見る側・試す側・指摘する側である。
この分担にすると、非常に分かりやすい。
BOSが作る。
Surfaceが見る。
Surfaceが指摘する。
BOSが直す。
この流れにできれば、開発とテストが自然に分かれる。
4. 両方に開発をやらせると無駄があった
最初は、BOSもSurfaceも両方開発に使えば、単純に2倍速くなるのではないかと思っていた。
しかし、実際にはそう単純ではなかった。
両方で開発すると、以下の問題が出る。
同じファイルを触るリスクがある
ブランチ管理が複雑になる
どちらの作業が最新か分かりにくい
pull / rebase / merge の確認が増える
作業宣言が重くなる
Git競合のリスクが高まる
片方の成果をもう片方が把握するまでに時間がかかる
結局、連携確認に時間を使う
つまり、2台で同時に開発すると、開発速度が上がるどころか、調整コストが増える可能性がある。
特に今は、まだ一人用確認版の品質改善が重要な時期である。
この段階でGit競合やブランチ混乱に時間を使うのは避けたい。
だから、役割を分ける方がよい。
5. 開発とテストを分けると、確認観点も整理される
BOSを開発専用、Surfaceをテスト専用にすると、確認観点も整理しやすい。
BOS側では、実装者目線になりやすい。
コードが通るか
buildが成功するか
E2Eが通るか
エラーが消えたか
commitできるか
これは重要である。
しかし、ユーザー目線とは少し違う。
Surface側では、実装者ではなく確認者として見る。
画面が分かりやすいか
デザインがひどくないか
初回ユーザーが迷わないか
ボタンの位置は自然か
文言は分かりやすいか
スマホやタブレットで見づらくないか
一人用確認版として触れるか
人に見せられる品質に近づいているか
この分担はかなり重要である。
最近、一人用確認版を見て、デザイン品質・機能品質の低さにかなり不安を感じた。
だからこそ、Surface側でユーザー目線・テスト目線の確認を強める必要がある。
6. Cursor Ultraにしたことで、開発側の余力は増えた
さらに、CursorはUltraにアップグレードした。
現在のプランは、Cursor Ultra $200/月。
使用量はリセットされ、現在は以下のような状態になっている。
| 項目 | 状況 |
|---|---|
| プラン | Cursor Ultra |
| 月額 | $200/月 |
| 次回リセット | 5月31日 |
| Total使用量 | 1% |
| Auto + Composer | 1% |
| API | 0% |
| API枠 | 少なくとも$400分含む |
これまでのPro+では、Total 90%以上、API 100%まで到達していた。
そこからUltraに上げたことで、かなり余裕が出た。
これは大きい。
今後は、Cursorの使用量制限を気にしすぎず、BOS側で開発・修正・品質改善を進めやすくなる。
ただし、Ultraにしたからといって、無駄に使ってよいわけではない。
月額200ドルを払っている以上、成果に変えなければならない。
7. Ultraでやるべきことは、機能追加より品質改善
今の最重要課題は、単なる機能追加ではない。
一人用確認版を実際に見た結果、品質への不安が大きくなった。
デザイン品質が低い
機能品質が弱い
画面のつながりが悪い
初回体験が弱い
人に見せるにはまだ怖い
E2Eが通っていても体験品質が足りない
だから、Cursor Ultraでやるべきことは、機能をむやみに増やすことではない。
むしろ、以下を優先したい。
主要画面のUI改善
一人用確認版の通し導線整理
空データ・エラー表示の統一
スマホ・タブレット表示改善
操作後のフィードバック改善
人に見せられる画面の品質向上
Surface指摘の反映
E2Eと手動確認の組み合わせ
P0残課題の集中消化
Ultraは、量を増やすためだけではなく、品質を上げるために使う。
ここを間違えないようにしたい。
8. 自動実行で分業できる期待
今後は、BOSとSurfaceの両方で、ある程度自動実行させることを考えている。
BOS側では、開発タスクを連続的に実行する。
実装
修正
E2E追加
build確認
commit / push
作業報告
Surface側では、テスト・確認タスクを連続的に実行する。
最新取得
画面確認
UI観点チェック
E2Eまたは手動確認
不具合・改善点整理
BOS向け指示作成
docs/surface-output/への保存
この形がうまく回れば、かなり効率が上がる可能性がある。
BOSが作っている間に、Surfaceが確認する。
Surfaceが指摘をまとめている間に、BOSが次の実装を進める。
SurfaceのアウトプットをBOSが次回優先して読む。
このループができれば、かなり開発体制らしくなる。
9. 今後の理想フロー
理想としては、以下の流れで進めたい。
ChatGPTで方針・課題・指示文を整理する
BOSに実装指示を出す
BOSがCursorで実装・E2E・build・commit / pushを行う
Surfaceが最新を取得してテスト・UI確認を行う
Surfaceが確認結果を
docs/surface-output/にまとめるBOSがSurfaceの指摘を読み、次の修正に入る
ChatGPTで進捗・課題・記事化を行う
この流れが定着すれば、かなり強い。
一人で進めているが、実質的には、
ChatGPT：PMO・壁打ち・議事録
BOS + Cursor：開発担当
Surface：テスト担当
GitHub：状態管理
Playwright：自動確認
という体制に近づく。
これは、AI時代の個人開発としてかなり面白い形だと思っている。
10. 懸念もある
もちろん、懸念もある。
BOSとSurfaceで分担したからといって、すべてが解決するわけではない。
主な懸念は以下である。
| 懸念 | 内容 |
|---|---|
| Surface側の確認品質 | テスト専用機として十分な観点で見られるか |
| 指摘の粒度 | BOSが実装しやすい形で指摘できるか |
| docs/surface-output運用 | 確認結果を安定して保存・参照できるか |
| Git運用 | 最新取得・ブランチ確認を徹底できるか |
| Cursor Ultraの浪費 | 使用量が増えても成果につながらないリスク |
| 品質改善の優先度 | 新機能追加に流れてしまうリスク |
| 自動実行の停止 | AIが途中で止まり、人間の確認待ちになるリスク |
特に重要なのは、Surface側のアウトプット品質である。
「見た」だけでは意味がない。
BOSがそのまま修正に入れるように、具体的な指摘として残す必要がある。
11. 一人用確認版への影響
この分担がうまく回れば、一人用確認版への到達はかなり現実的になる。
これまでの見立てでは、一人用確認版の到達度はおおよそ50%前後。
ただし、実際に触ってみると品質面に大きな不安が出た。
つまり、今後の進捗は単純な機能実装率ではなく、品質改善率で見る必要がある。
BOSを開発専用、Surfaceをテスト専用にすることで、以下が期待できる。
品質指摘が増える
UI改善の優先度が上がる
通し導線の不具合に気づきやすくなる
スマホ・タブレット観点を拾いやすくなる
E2Eだけでは拾えない違和感を拾える
開発と確認のループが早くなる
これにより、一人用確認版の完成時期は少し現実的になる。
ただし、品質が想定より低かったため、楽観はできない。
5月中の一人用確認版を目指す方針は維持したいが、
「動く」ではなく「触って次に進める品質」 を基準に見直す必要がある。
12. 今回の結論
BOSを開発専用機、Surfaceをテスト専用機に分けることで、ようやく2台体制の使い方が見えてきた。
両方に開発をやらせると、連携に無駄が出る。
ブランチ管理やファイル競合、作業範囲の確認に時間を取られる。
それよりも、役割を分けた方がよい。
BOSは作る
Surfaceは見る
Surfaceが指摘する
BOSが直す
この形が分かりやすい。
さらに、Cursor Ultra $200/月にアップグレードしたことで、BOS側の開発余力は大きく増えた。
現在の使用量はTotal 1%、Auto + Composer 1%、API 0%。
これまでの制限ギリギリの状態から、一気に余裕ができた。
ただし、重要なのはここからである。
Ultraにしたからといって、無駄に機能を増やしてはいけない。
今やるべきことは、品質改善である。
一人用確認版を確認して、デザイン品質・機能品質に不安が出た。
だからこそ、BOSとSurfaceの分担を活かして、開発とテストのループを早く回す。
この体制がうまく回れば、かなり効率化できるはずである。
ようやく、AIと複数PCを使った個人開発体制が形になり始めた。
ここからは、投資した分を成果に変えるフェーズである。
0 件のコメント:
コメントを投稿