1. はじめに
独力＋AI活用で月商1億円を目指している。
最近、BOSGAME P3 PLUSとSurfaceの2台体制について、かなり試行錯誤してきた。
当初は、BOSを開発専用機、Surfaceをテスト専用機として使えば、開発と確認を並行できて効率が上がるのではないかと考えていた。
BOSが実装する。
Surfaceがテストする。
Surfaceが指摘する。
BOSが直す。
この流れがうまく回れば、独力開発でありながら、開発担当とQA担当を分けるような体制に近づける。
しかし、実際にやってみると、現時点ではその運用がうまくはまっていない。
そこで、いったん Surface側の試験を止める 方向で考えることにした。
2. Surface側の試験で期待していたこと
Surface側に期待していたのは、開発ではなくテストだった。
具体的には、以下のような役割である。
BOS側が実装した内容を確認する
実際に画面を開く
UIの崩れを見る
導線の分かりにくさを指摘する
Playwrightや手動確認を実行する
スクリーンショットを残す
BOS側に修正指示を返す
つまり、Surfaceは「作る側」ではなく「見る側」として機能させたかった。
開発者目線では気づけないことを、別端末で確認する。
特に、デザイン品質やユーザー導線の粗さを拾う。
一人用確認版の品質を上げるために、Surface側をQA役として使う。
これが最初の狙いだった。
3. 実際には、期待したほど機能しなかった
しかし、実際には期待したほど機能しなかった。
Surface側にテストを依頼しても、なかなか実画面確認に入らない。
テスト結果ではなく、報告書のテンプレートやファイル作成に流れてしまう。
「試験をしてほしい」のに、「試験のためのドキュメント準備」をして終わってしまう。
もちろん、ドキュメントやチェックリストは重要である。
ただ、今必要だったのはそこではない。
必要だったのは、実際に画面を開いて、動かして、問題を見つけて、BOSに直させることだった。
Surface側がそこまで到達しないと、2台体制の意味が薄い。
4. Surfaceを動かすための管理コストが高かった
Surface側の試験で一番問題だったのは、管理コストが高いことだった。
Surfaceに正しくテストしてもらうには、かなり細かく指示する必要がある。
新規ファイルだけ作らないこと
実画面を必ず確認すること
スクリーンショットを残すこと
未確認項目を確認済みにしないこと
テスト結果だけを書くこと
BOS向けに修正指示を出すこと
どのブランチ・commitを確認したか残すこと
ここまで細かく指示しないと、Surface側が期待と違う作業をしてしまう。
つまり、Surfaceにテストさせるために、自分がかなりの管理をしなければならない。
これは本末転倒になりかねない。
Surface側を使って効率化したいのに、そのSurface側を動かすために指示・確認・修正が必要になる。
その結果、BOS側で実装を進めるよりも、Surface側の調整に時間を取られる。
この状態では、効率化とは言いにくい。
5. Cursorの消費ももったいない
もう一つ大きいのが、Cursorの消費である。
現在はCursor Ultraに月額200ドルを払っている。
Ultraにしたことで使用量には余裕が出たが、それでも無駄遣いしてよいわけではない。
Surface側に試験をさせるためにもCursorを使う。
しかし、その結果が実テストではなく、テンプレート作成やファイル作成に流れるなら、消費に対するリターンが低い。
今の最重要課題は、一人用確認版の品質改善である。
それなら、CursorのリソースはまずBOS側に集中させた方がよい。
BOS側で開発・UI改善・E2E・build・commit / pushを進める。
Surface側の調整にリソースを割くより、BOS側で直接品質改善を回した方が、現時点では効率がよさそうである。
6. 今はBOSに専念した方がよい
現時点の判断としては、BOSに専念する方が効率がよい。
理由は明確である。
BOSは開発専用機としてかなり機能している。
実装できる
E2Eを追加できる
buildを回せる
lint / formatを確認できる
commit / pushまでできる
Cursor Ultraを活かしやすい
一方で、Surface側はまだ安定してテスト担当として機能していない。
であれば、いったんSurface側を止めて、BOS側に集中した方がよい。
これはSurfaceを捨てるという意味ではない。
今の段階では、Surfaceを無理に動かすより、BOSで一人用確認版の品質改善を進める方が優先度が高いという判断である。
7. Surfaceを止めることで期待する効果
Surface側の試験をいったん止めることで、期待している効果は以下である。
| 効果 | 内容 |
|---|---|
| 管理負荷の削減 | Surfaceへの細かい指示・確認が減る |
| Cursor消費の集中 | 開発・品質改善にCursorを使える |
| 作業方針の明確化 | BOS側にP0/P1改善を集中できる |
| Git混乱の回避 | 複数端末・複数ブランチの管理が軽くなる |
| 品質改善の加速 | 主要画面・導線改善に集中できる |
| 判断の単純化 | まずBOSで進める、という方針にできる |
2台体制は魅力的だが、今はまだ運用が重い。
今必要なのは、理想的な体制づくりではなく、一人用確認版の品質を引き上げることである。
そのために、いったんSurfaceを止める。
これは後退ではなく、集中するための整理である。
8. Surface再開のタイミング
Surfaceを完全に使わないわけではない。
ただし、再開するタイミングは考えたい。
Surface側を再びテストに使うなら、以下の条件が整ってからの方がよい。
BOS側で主要画面の品質改善がある程度進んだ
一人用確認版の通し導線が見えてきた
Surface向けの指示テンプレートが固まった
docs/surface-output/の運用ルールが明確になったSurface側が「ファイル作成」ではなく「実画面確認」を確実に行える
チェック対象画面と確認観点が明確になった
特に重要なのは、Surfaceに渡すタスクを限定することである。
たとえば、
このURLを開く
この3画面だけ確認する
スクリーンショットを撮る
P0/P1/P2を最大10件だけ出す
新規テンプレート作成は禁止
実施結果だけを書く
このくらい絞った方がよい。
Surfaceに広い裁量を与えすぎると、またファイル作成に流れる可能性がある。
9. 二台体制はまだ有効な可能性がある
ここで誤解したくないのは、二台体制そのものが失敗というわけではないことだ。
BOSとSurfaceの併用には、まだ可能性がある。
ただし、現時点では時期尚早だった。
BOS側の開発品質がまだ不安定。
Surface側のテスト運用もまだ安定していない。
この状態で両方を動かすと、管理負荷が増える。
まずはBOSで品質改善を進める。
その後、Surfaceを限定的にテストへ復帰させる。
この順番がよいと思っている。
二台体制は、最初からフル稼働させるのではなく、必要なタイミングで段階的に使うべきだと分かった。
10. 今の最優先は品質改善
一人用確認版を触ってみて、デザイン品質・機能品質にかなり不安が出ている。
この課題は重い。
今やるべきことは、Surface運用の実験ではない。
今やるべきことは、BOS側で以下を進めることである。
レース詳細の情報設計改善
ダッシュボードの改善
初回導線の整理
遊び方・ヘルプ導線の改善
空データ・エラー表示の統一
スマホ表示の確認
一人用通し確認の障害除去
E2E回帰の維持
人に見せられる画面への改善
ここに集中したい。
Surfaceを使うかどうかは、その後でよい。
11. 今回の判断
今回の判断は、以下である。
Surface側の試験はいったん止める。
BOS側に開発・品質改善を集中する。
Surfaceは後で、限定的な実画面確認タスクとして再開する。
これは、二台体制を諦めたわけではない。
むしろ、二台体制を本当に活かすために、いったん止める判断である。
今のままSurfaceを動かしても、管理コストが高く、Cursor消費も増え、実テストの成果が薄い。
であれば、いったん止めた方がよい。
まずはBOSで進める。
BOSで品質を上げる。
確認対象が明確になったら、Surfaceをピンポイントで使う。
この方が現実的である。
12. 今回の結論
BOSとSurfaceの併用について検討した結果、いったんSurface側の試験を止める方向にした。
当初は、BOSを開発専用機、Surfaceをテスト専用機にすれば効率化できると考えていた。
しかし、実際にはSurface側のテスト運用に誤解が多く、ファイル作成やテンプレート整備に流れやすかった。
実画面確認まで持っていくための指示・管理コストも大きかった。
今は、Surfaceを無理に動かすより、BOS側に集中した方がよい。
Cursor Ultraも契約した。
BOS側の開発環境は整っている。
一人用確認版の品質改善が最優先である。
だから、当面はBOSに専念する。
Surfaceは、後で必要になったタイミングで、確認対象を絞って再開する。
PCが2台あるからといって、常に両方を動かす必要はない。
AIが使えるからといって、常に並列稼働させる必要もない。
重要なのは、今どの使い方が一番サービスインに近づくかである。
現時点の答えは、BOS集中。
まずはBOSで、一人用確認版を「動く」から「見せられる」に引き上げる。
Surfaceは、その次の段階で再投入する。
0 件のコメント:
コメントを投稿