1. はじめに
独力＋AI活用で月商1億円を目指している。
最近は、開発用PCと確認用端末を分けて使う運用が少しずつ形になってきた。
開発用PCでは、実装、ビルド、自動テスト、修正、PR作成を進める。
確認用端末では、実機UI確認、シナリオ試験、スクリーンショット取得、試験報告を行う。
この分担自体はかなり良い。
以前は、確認用端末にも開発をやらせようとして、かえって連携が複雑になった。
今は役割を分けたことで、かなり整理されてきた。
ただし、まだ完全には閉じていない。
現状の弱点は、確認用端末の指摘が、開発用PC側のどの修正で直ったのか、再確認済みなのか、未対応なのかが追いづらいことだ。
つまり、報告と改修はあるが、指摘ID単位のクローズ管理が弱い。
2. 現在の流れはかなり形になっている
今の開発プロセスは、ざっくり以下の流れになっている。
確認用端末が試験する
↓
試験結果を報告する
↓
開発用PCがP0/P1を優先して直す
↓
開発用PCが完了報告する
↓
必要に応じて確認用端末が再確認する
この流れ自体は悪くない。
むしろ、独力＋AI活用の開発体制としてはかなり良い形に近づいている。
特に良い点は以下である。
開発用PCをメイン開発機にしている
確認用端末を実機UI確認・シナリオ試験に使っている
試験結果を記録として残している
開発側が確認結果を見てP0/P1を優先する流れがある
commit、push、build、lint、自動テストの報告文化ができている
進捗率や残作業の報告も意識できている
ここまではかなり良い。
3. 現状の評価は70点くらい
今の連携を点数で言うなら、70点くらいだと思っている。
方向性は合っている。
運用も回り始めている。
確認用端末の価値も出てきている。
開発用PCも指摘を受けて修正する流れになっている。
ただし、まだ足りない。
何が足りないかというと、指摘1件ごとの状態管理である。
確認用端末が指摘した。
開発用PCが直した。
でも、それがどの指摘に対する対応だったのか。
その指摘は再確認されたのか。
まだ未対応なのか。
後回しなのか。
仕様通りとして対応しないのか。
ここが曖昧になりやすい。
このままだと、あとで「あれは直ったんだっけ？」となる。
4. 一番弱いのは、指摘と改修の対応表
たとえば、確認用端末が以下のように報告したとする。
UI-20260501-001
メイン画面のカード表示が崩れている
その後、開発用PC側が完了報告で、
メイン画面のUIを改善しました
と書いたとする。
これだけでは、UI-20260501-001 が本当に直ったのか分かりにくい。
必要なのは、こういう対応である。
UI-20260501-001: 対応済み
- commit: abc1234
- 修正ファイル: 対象画面ファイル
- 検証: build成功、該当画面表示確認済み
- 再確認: 必要
このように、指摘IDと修正内容を明確に紐づける必要がある。
5. 確認用端末がどのバージョンを見たかも重要
もう一つ重要なのは、確認用端末がどのバージョンを確認したかである。
確認用端末が古いcommitを見ていると、開発用PC側で直した内容が反映されていない可能性がある。
そうすると、
「まだ直っていません」
と言われても、実は古い状態を見ていただけ、ということが起きる。
これを防ぐには、確認報告に必ず以下を書く必要がある。
対象ブランチ:
対象commit:
origin/mainとの差分:
起動URL:
確認日時:
これがないと、毎回「それ、最新で確認した？」という問題が出る。
実機確認では、見た画面そのものだけでなく、どの状態を見たのかが重要である。
6. 再確認範囲を絞らないと非効率になる
開発用PCが修正した後、確認用端末に全部再確認させるのは非効率である。
確認用端末のAIツール消費も増える。
時間もかかる。
同じような確認が繰り返される。
本来は、開発用PC側が再確認対象を絞って返すべきである。
たとえば、以下のようにする。
再確認対象:
- UI-20260501-001
- UI-20260501-003
再確認不要:
- UI-20260501-002 は仕様どおりのため対応なし
- UI-20260501-004 はP2として後回し
これなら、確認用端末は対象IDだけ見ればよい。
全体を毎回見直す必要がなくなる。
これはかなり効率化につながる。
7. 理想の流れ
今後は、以下の流れにしたい。
1. 確認用端末が試験する
↓
2. 確認報告に指摘IDを付ける
↓
3. 開発用PCが指摘IDごとに対応方針を決める
↓
4. 開発用PCがP0/P1を改修する
↓
5. 開発用PCが指摘IDごとの対応結果を報告する
↓
6. 確認用端末が対象IDだけ再確認する
↓
7. 修正確認済みならクローズ、未解決ならReopen
重要なのは、指摘ID単位で流すことである。
これにより、報告、改修、再確認、クローズが一本の線でつながる。
8. 追加すべき最小ルール
大きなドキュメントを増やす必要はない。
今の運用に、最小限のルールを追加すればかなり良くなる。
確認用端末側のルール
各指摘には必ず UI-YYYYMMDD-連番 のIDを付ける。
各指摘には P0 / P1 / P2 を付ける。
対象ブランチ・対象commit・スクリーンショットパスを必ず書く。
開発用PC側のルール
確認用端末の指摘を修正した場合は、必ず指摘IDごとに対応状況を書く。
例:
- UI-20260501-001: 対応済み
- UI-20260501-002: 仕様どおりのため対応なし
- UI-20260501-003: P2として後回し
- UI-20260501-004: 再現できず、追加確認待ち
再確認側のルール
開発用PCが指定した再確認対象IDだけ確認する。
結果は以下で返す。
- Confirmed: 修正確認済み
- Reopen: 未修正・再発
- Blocked: 確認不能
これだけでも、かなりプロセスが締まる。
9. 対応表が必要
現状で一番足したいのは、指摘対応表である。
たとえば、以下のような表でよい。
## UI指摘対応表
| ID | 重要度 | 指摘内容 | 開発側対応 | commit | 再確認 | 状態 |
|---|---|---|---|---|---|---|
| UI-20260501-001 | P1 | メイン画面の表示崩れ | 対応済み | abc1234 | 必要 | 再確認待ち |
| UI-20260501-002 | P2 | 文言が弱い | 後回し | - | 不要 | Backlog |
| UI-20260501-003 | P0 | 主要操作不可 | 対応済み | def5678 | 必要 | 再確認待ち |
新規ファイルを作ってもよい。
ただし、ドキュメントを増やしすぎたくない場合は、開発用PC側の完了報告テンプレートにこの表を必須化するだけでもよい。
大事なのは、指摘IDごとに状態が分かることだ。
10. 状態は4種類くらいで十分
状態管理は複雑にしすぎなくてよい。
最初は以下くらいで十分である。
| 状態 | 意味 |
|---|---|
| Open | 未対応 |
| Fixed | 開発側で対応済み |
| Confirmed | 確認側で修正確認済み |
| Reopen | 再確認で未修正・再発 |
| Backlog | 後回し |
| Won’t Fix | 仕様どおり・対応しない |
| Blocked | 確認不能・条件不足 |
これくらいあれば十分だと思う。
最初から重いチケット管理ツールのようにする必要はない。
ただし、最低限の状態は持たせる。
これだけで、かなり追いやすくなる。
11. PCを増やすより先に、対応管理を整えた方が効く
最近は、3台目PCを増やすかどうかも考えている。
ただ、今回の連携問題を見ると、PCを増やす前にやるべきことがある。
それが、指摘IDと対応表の固定化である。
PCを増やしても、指摘が閉じているか分からない状態では、混乱が増えるだけである。
確認用端末が指摘する。
開発用PCが直す。
でも、どれが直ったか分からない。
さらに3台目が別の作業をする。
この状態だと、台数を増やすほど管理が難しくなる。
だから、まずは連携の背骨を作る。
Surface試験結果 → BOS改修 → Surface再確認 → クローズ
この流れをID単位で閉じられるようにする。
端末を増やすのは、その後でもよい。
12. 今回の結論
確認用端末と開発用PCの連携は、かなり形になってきている。
確認用端末が試験する。
報告を残す。
開発用PCがP0/P1を優先して直す。
完了報告する。
必要に応じて再確認する。
この流れはできている。
ただし、まだ完全には閉じていない。
弱いのは、指摘ID単位のクローズ管理である。
今後は、以下の形にしたい。
確認用端末:
指摘ID付きで報告する
開発用PC:
指摘IDごとに対応状況・commit・検証結果を書く
確認用端末:
開発用PCが指定したIDだけ再確認する
最終:
Confirmed / Reopen / Backlog で状態を閉じる
これができれば、確認結果、改修、再確認、クローズがつながる。
今のプロセスは70点くらい。
方向性は良い。
ただし、ID単位の対応表が入れば、80点以上に上げられると思う。
AIと複数端末を使った開発では、作業量を増やすだけでは足りない。
指摘を閉じる仕組みが必要である。
次に改善すべきは、PCの台数ではなく、指摘IDごとのクローズ管理かもしれない。
