1. はじめに
月商1000万円を目指して、新規プロジェクトを進めている。
ここ最近、開発体制をかなり見直している。
BOSGAME P3 PLUSを開発専用機にする。
Surfaceをテスト専用機にする。
ChatGPTで方針や指示を整理する。
Cursorで実装を進める。
GitHubで状態を管理する。
PlaywrightでE2Eテストも回す。
この体制がうまく回れば、一人開発でありながら、かなり本格的な開発・テスト分業に近づけるのではないかと考えていた。
しかし、実際にやってみると、そう簡単ではなかった。
特に苦労したのが、Surface側のテスト実施である。
Surfaceをテスト専用機として使いたかったのに、なかなか実際のテストをしてくれない。
テストをしてほしいのに、なぜかファイル作成やドキュメント整備ばかりしてしまう。
こちらの意図と違う方向に進んでしまう。
これは、かなり苦労した。
2. Surfaceに期待していた役割
Surfaceに期待していた役割は明確だった。
Surfaceには、開発ではなく、確認・テスト・指摘をしてほしかった。
具体的には、以下のような役割である。
GitHubから最新状態を取得する
実際に画面を開いて確認する
UIの崩れを見る
ユーザー目線で分かりにくい箇所を指摘する
PlaywrightなどのE2Eテストを実行する
手動確認観点を消化する
スクリーンショットを撮る
結果を報告する
BOSGAME側へ修正指示を渡す
つまり、Surfaceは「作る側」ではなく「見る側」である。
BOSGAMEが開発担当。
Surfaceがテスト担当。
Surfaceの指摘を受けて、BOSGAMEが直す。
この分担にしたかった。
3. 実際には、ファイル作成ばかりしてしまった
しかし、実際にSurface側へ指示を出してみると、期待通りにはいかなかった。
テストをしてほしい。
画面を見てほしい。
実際に動かしてほしい。
UI観点で確認してほしい。
そう依頼しているつもりだった。
ところが、Surface側はなぜか、
テスト報告書のひな形を作る
チェックリストのスケルトンを作る
ドキュメントの行を追加する
運用ルールに追記する
報告ファイルを作る
まだ実施していない確認結果の枠を用意する
といった方向に進んでしまった。
もちろん、ドキュメント自体は重要である。
報告書も必要である。
チェックリストも必要である。
しかし、今回やってほしかったのは、そこではなかった。
まず実際にテストしてほしかった。
4. 「テスト準備」と「テスト実施」は違う
今回の苦労で、改めて感じたことがある。
それは、テスト準備とテスト実施はまったく違うということだ。
テスト準備とは、たとえば以下である。
チェックリストを作る
報告書のフォーマットを作る
テスト観点を整理する
結果記入欄を作る
ドキュメント構成を整える
これは重要である。
しかし、これだけでは品質は上がらない。
本当に必要なのは、その後のテスト実施である。
実際に画面を開く
ボタンを押す
導線を確認する
表示崩れを見る
エラーが出るか確認する
スマホ幅で見る
ユーザー目線で違和感を拾う
スクリーンショットを残す
再現手順を書く
改善指示につなげる
この実作業がないと、テストをしたことにはならない。
Surface側では、この「準備」と「実施」の区別がうまく伝わっていなかった。
5. AIは「それっぽい成果物」を作るのがうまい
今回かなり感じたのは、AIは「それっぽい成果物」を作るのがうまいということだ。
たとえば、テスト報告書のフォーマットを作る。
チェックリストを作る。
ドキュメントに項目を追加する。
作業したように見える文章を書く。
これは得意である。
しかし、それだけでは実際のテストにはならない。
怖いのは、ファイルが増えると、何か進んだように見えてしまうことである。
報告書ができた。
チェックリストができた。
ドキュメントが更新された。
GitHubにcommitされた。
これだけ見ると、作業したように見える。
しかし、中身を見ると、実際の画面確認はされていない。
スクリーンショットもない。
操作結果もない。
不具合の再現確認もない。
UIの実機確認もない。
これでは、品質改善にはつながらない。
6. こちらの指示にも問題があった
ただし、これはSurface側だけが悪いという話ではない。
こちらの指示にも問題があったと思っている。
「テストしてほしい」と言ったときに、AI側はそれを広く解釈する。
テスト準備もテストの一部。
テスト観点整理もテストの一部。
報告書作成もテスト作業の一部。
そう解釈されてしまった。
だから、今後はもっと明確に言う必要がある。
たとえば、
新しいMarkdownファイルを作らない。
チェックリストのひな形を作らない。
まず実際にアプリを起動する。
ブラウザで画面を開く。
指定画面を操作する。
スクリーンショットを撮る。
実際の確認結果だけを書く。
未確認の項目を確認済みのように書かない。
ここまで言わないと、AIは「安全で形にしやすい作業」に逃げる可能性がある。
つまり、AIにテストをさせるには、作業の成果物ではなく、実施行為を明確に定義する必要がある。
7. 「ファイルを作るな」と明示する必要があった
今回、かなり強く感じたのは、AIには「何をするか」だけでなく、何をしないかも明示する必要があるということだ。
Surface側には、かなり明確に言う必要があった。
新規の指示書Markdownを作らない
スケルトンだけの報告書を作らない
実施していないテスト結果を書かない
ドキュメント更新だけで終わらない
既存ルールの追記で満足しない
テスト未実施のままcommitしない
まずアプリを起動して実画面を確認する
これを明示しないと、AIはドキュメント作成に流れてしまう。
ドキュメント作成は、AIにとってやりやすい。
コードを動かすより安全に見える。
実機確認より失敗しにくい。
報告としても形にしやすい。
だからこそ、人間側が「今回の目的はテスト実施である」と強く縛る必要がある。
8. テスト専用機に必要なのは、確認結果である
Surfaceをテスト専用機にするなら、最終成果物はドキュメントの数ではない。
必要なのは、確認結果である。
たとえば、以下のようなものである。
| 必要な成果 | 内容 |
|---|---|
| 実行環境 | どのブランチ・どのcommitを確認したか |
| 起動確認 | アプリが起動したか |
| 画面確認 | どの画面を見たか |
| 操作結果 | 何を押して、何が起きたか |
| スクリーンショット | 実際の画面証跡 |
| 不具合 | 何が問題か |
| 再現手順 | どうすれば再現するか |
| 重要度 | P0/P1/P2など |
| BOS向け指示 | 何を直すべきか |
これがなければ、テスト専用機として働いたとは言いにくい。
単に「テスト報告書.md」を作っただけでは意味がない。
中身に実施結果が必要である。
9. 二台体制の難しさ
BOSGAMEとSurfaceの二台体制は、かなり期待している。
ただ、今回の件で、二台体制には運用設計が必要だと痛感した。
BOSGAMEは開発専用機。
Surfaceはテスト専用機。
この分担自体は良い。
しかし、Surfaceがテストではなくファイル作成に流れてしまうと、役割分担が崩れる。
BOSGAMEは実装を進める。
Surfaceはテストの準備だけする。
実際の確認はされない。
これでは、BOSGAME側の開発が品質改善につながりにくい。
二台体制を成立させるには、Surface側の仕事をもっと具体化する必要がある。
10. 今後のSurface向け指示は変える
今後、Surface側には、繰り返し使える強い指示が必要だと思っている。
方針としては、以下である。
Surfaceへの基本指示
あなたは開発担当ではなく、テスト担当である
新規機能の実装はしない
新規の指示書Markdownを増やさない
まずGitHubから最新を取得する
アプリを実際に起動する
ブラウザで実画面を確認する
指定された画面を操作する
スクリーンショットを保存する
確認結果を
docs/surface-output/に残すBOSGAMEがそのまま修正できる粒度で指摘する
禁止事項
テスト未実施の報告書作成
スケルトンだけのファイル作成
確認していない項目を確認済みにすること
ドキュメント更新だけで終了すること
実装作業に入ること
作業範囲外のファイルを触ること
これくらい明確にする必要がある。
11. Surface側の報告フォーマットも固定したい
Surface側の報告は、以下のような形に固定したい。
## Surface実機テスト結果
### 確認対象
- branch:
- commit:
- URL:
- 実行日時:
### 実施した確認
- 画面A:
- 画面B:
- 操作:
### 証跡
- screenshot:
- 動画:
- ログ:
### 発見した問題
- 問題ID:
- 画面:
- 内容:
- 再現手順:
- 重要度:
- BOSGAME向け修正指示:
### 確認できなかったこと
- 理由:
- 次回確認事項:
こうしておけば、報告が空っぽになりにくい。
「確認したこと」と「確認できなかったこと」を分ける。
「実施したこと」と「これからやるべきこと」を分ける。
「感想」ではなく「修正指示」まで落とす。
これが必要である。
12. 今回の苦労から得た教訓
今回のSurface問題から得た教訓は大きい。
12.1 AIには役割定義が必要
開発担当なのか、テスト担当なのか、PMOなのか。
役割を曖昧にすると、AIはやりやすい作業に流れる。
12.2 成果物ではなく行動を指定する必要がある
「報告書を作る」ではなく、
「実際に画面を開いて確認する」ことが必要。
12.3 禁止事項を書く必要がある
AIには、やってほしくないことも明確に書く。
特に、ファイル作成だけで終わることは禁止する必要がある。
12.4 テストは証跡が重要
スクリーンショット、URL、commit、操作結果、再現手順。
これがないと、テストとして弱い。
12.5 二台体制は運用がすべて
PCが2台あるだけでは効率化しない。
役割、ルール、報告、連携が必要である。
13. 今回の結論
Surfaceをテスト専用機にしようとしたが、最初はかなり苦労した。
こちらはテストをしてほしかった。
しかし、Surface側はファイル作成やドキュメント整備に流れてしまった。
テスト報告書のひな形を作る。
チェックリストを作る。
ドキュメントに追記する。
しかし、実際の画面確認は十分に進まない。
これはかなりつらかった。
ただし、この苦労で分かったこともある。
AIに仕事をさせるには、役割定義が必要である。
開発担当とテスト担当を明確に分ける必要がある。
「何をするか」だけでなく「何をしないか」も書く必要がある。
テストでは、ファイル作成ではなく、実施結果と証跡が必要である。
今後は、Surfaceには徹底してテスト担当として動いてもらう。
BOSGAMEが作る。
Surfaceが実際に触る。
Surfaceが証跡付きで指摘する。
BOSGAMEが直す。
このループを作る。
今回の苦労は大きかったが、二台開発体制を本当に機能させるために必要な失敗だったと思う。
AI活用は、ツールを増やせば勝手にうまくいくわけではない。
AIにも、役割、作業範囲、禁止事項、成果物の定義が必要である。
Surfaceがようやく本当の意味でテスト専用機として働けるようになるか。
ここが、次の開発効率化の大きなポイントになる。
0 件のコメント:
コメントを投稿