1. はじめに
独力＋AI活用で月商1億円を目指している。
最近は、開発用PCと確認用端末を分けて、開発と試験を並行できる体制を整えている。
開発用PCは実装、修正、自動テスト、ビルド、PR作成を担当する。
確認用端末は実機UI確認、シナリオ試験、スクリーンショット取得、試験報告を担当する。
この分担はかなり形になってきた。
ただし、問題も見えてきた。
確認用端末が指摘する。
開発用PCが修正する。
でも、その指摘がどの修正で直ったのか。
再確認されたのか。
まだ未対応なのか。
後回しなのか。
ここが追いづらい。
前回は、GitHub Issueを使えばよいのではないかと考えた。
しかし、今すぐ外部チケット運用を増やすと、逆に管理対象が増えすぎる可能性もある。
そこで今回は、GitHub Issue運用は使わず、docs配下のMarkdownだけで、試験 → 修正 → 再試験 → Close相当まで回す軽量運用を考えることにした。
2. 今回やりたいこと
今回やりたいのは、新しいツールを増やすことではない。
GitHub Issueを使わない。
外部チケット管理も増やさない。
既存のMarkdown運用の中で、確認用端末と開発用PCの連携を少しだけ強くする。
追跡したいのは、以下である。
確認用端末がどの試験を実施したか
どの指摘を出したか
開発用PCがどの指摘を確認したか
どのcommitで修正したか
どのブランチ・commitに反映されたか
修正後に再試験されたか
最終的にClose相当になったか
まだReopen、Backlog、Blockedなのか
つまり、目的はシンプルである。
指摘を出しっぱなしにしない。
修正しっぱなしにしない。
再確認まで含めて状態を閉じる。
3. 現状の弱点
今の開発プロセスでは、試験と修正の流れ自体はできている。
確認用端末が試験する。
Markdownで報告する。
開発用PCがP0/P1を優先して修正する。
commit、push、検証結果を報告する。
必要に応じて確認用端末が再確認する。
ここまでは良い。
ただし、指摘単位で見ると弱い。
たとえば、確認用端末が、
UI-20260502-001
主要画面の導線が分かりづらい
と報告したとする。
その後、開発用PCが、
主要画面の導線を改善しました
と報告しただけでは、UI-20260502-001 が本当に直ったのか分かりにくい。
必要なのは、指摘IDごとの対応状況である。
UI-20260502-001: Fixed
- 修正commit: abc1234
- 修正ファイル: 対象画面
- 検証結果: build成功、該当画面確認済み
- 再確認: 必要
この粒度で残しておけば、後から追いやすい。
4. Close相当をどう定義するか
一番大事なのは、Close相当の定義である。
開発用PCが修正しただけでは、Close相当にはしない。
開発用PCができるのは、原則として Fixed までである。
その後、確認用端末が再確認し、問題が解消されていることを確認したら Confirmed にする。
この Confirmed をClose相当として扱う。
この考え方はかなり重要である。
開発側は「直した」と思っている。
でも、確認側で見るとまだ直っていないことがある。
別の環境では再発することもある。
期待していた改善と違うこともある。
だから、開発側のFixedと、確認側のConfirmedを分ける。
5. 状態ステータスを決める
Markdown運用でも、最低限の状態ステータスは必要である。
複雑なチケット管理ツールのようにする必要はない。
ただし、以下くらいは定義しておきたい。
| 状態 | 意味 | 主担当 |
|---|---|---|
| New | 確認用端末が新規に報告した状態 | 確認用端末 |
| Acknowledged | 開発用PCが確認し、対応方針を決めた状態 | 開発用PC |
| Fixed | 開発用PCが修正し、commitや検証結果を記録した状態。再確認前 | 開発用PC |
| Confirmed | 確認用端末が再確認し、解消を確認した状態。Close相当 | 確認用端末 |
| Reopen | 再確認で未修正・再発を確認した状態 | 確認用端末 |
| Backlog | 後回し。未対応だが意図的に保留 | 開発用PC |
| Won’t fix | 対応しない判断。理由必須 | 開発用PC |
| Blocked | 環境不足・再現不能・データ不足などで確認不能 | 確認用端末 / 開発用PC |
このくらいなら重すぎない。
Markdownでも十分運用できる。
6. Close相当になるもの、ならないもの
Close相当になる状態は明確にする。
Close相当は以下である。
Confirmed
Won’t fix
Confirmedは、確認用端末が再確認して直っていた状態。
Won’t fixは、対応しない判断を明確な理由付きで行った状態。
一方で、以下はClose相当ではない。
New
Acknowledged
Fixed
Reopen
Backlog
Blocked
特に重要なのは、FixedはClose相当ではないという点である。
開発用PCが修正しただけでは、まだ終わっていない。
確認用端末が再確認して初めてClose相当になる。
ここを明確にしておくと、修正漏れや確認漏れが減る。
7. ライフサイクル
通常の流れはこうである。
New
↓
Acknowledged
↓
Fixed
↓
Confirmed
修正不足や再発があれば、こうなる。
Fixed
↓
Reopen
↓
Fixed
↓
Confirmed
後回しにする場合はこうである。
New / Acknowledged
↓
Backlog
対応しない判断をする場合はこうである。
New / Acknowledged
↓
Won’t fix
確認不能の場合はこうである。
New / Fixed
↓
Blocked
これを決めておくだけで、かなり見通しがよくなる。
8. 確認用端末側の報告ルール
確認用端末側では、各指摘に必ずIDを付ける。
たとえば、以下のような形式である。
UI-YYYYMMDD-001
UI-YYYYMMDD-002
このIDを、報告本文、スクリーンショット、再確認結果に紐づける。
報告には以下を含める。
実施日
実施端末
対象ブランチ
対象commit
起動URL
試験種別
試験範囲
総合結果
指摘ID
優先度
状態
画面
内容
スクリーンショット
開発用PCへの依頼
これがあれば、後で追える。
9. 個別指摘のテンプレート
個別指摘は、以下くらいの粒度でよい。
## UI-YYYYMMDD-001
- 優先度: P0 / P1 / P2 / P3
- 状態: New / Reopen / Blocked
- 画面:
- URL:
- 確認環境:
- 指摘種別:
- 内容:
- 再現手順:
1.
2.
3.
- 期待結果:
- 実際の結果:
- 影響:
- スクリーンショット:
- 開発用PC側への依頼:
- 補足:
ここで大事なのは、感想で終わらせないことである。
「見づらい」だけでは修正しづらい。
どの画面で、何をしたときに、何が期待と違ったのかを書く必要がある。
10. 開発用PC側の完了報告
開発用PC側の完了報告には、指摘対応表を必須にしたい。
## UI指摘対応表
| 指摘ID | 優先度 | 対応 | 修正commit | 修正ファイル | 検証結果 | 再確認 | 状態 |
|---|---|---|---|---|---|---|---|
| UI-YYYYMMDD-001 | P1 | 導線を修正 | abc1234 | 対象画面 | build成功 / 画面確認済み | 必要 | Fixed |
| UI-YYYYMMDD-002 | P2 | 後回し | - | - | - | 不要 | Backlog |
| UI-YYYYMMDD-003 | P1 | 仕様どおりのため対応なし | - | - | 仕様確認済み | 不要 | Won’t fix |
これがあると、確認用端末側も再確認しやすい。
何を見ればよいのか。
どのIDを確認すべきなのか。
どれは後回しなのか。
どれは対応しないのか。
この整理ができる。
11. 再確認依頼もID単位にする
開発用PCが修正した後、確認用端末に全部再確認させてはいけない。
それでは非効率である。
再確認対象は、ID単位で絞る。
## 再確認依頼
今回、再確認が必要なIDは以下です。
- UI-YYYYMMDD-001
- UI-YYYYMMDD-004
再確認対象画面:
- 対象画面A
- 対象画面B
再確認してほしい操作:
1.
2.
3.
再確認不要な範囲:
- 対象外画面
- 変更していない導線
Full E2E要否:
- 必要 / 不要
理由:
-
これなら、確認用端末の作業量を抑えられる。
AIツールの消費も減る。
同じ画面を何度も見る無駄も減る。
修正箇所に集中できる。
12. Full E2Eを毎回要求しない
もう一つ重要なのは、Full E2Eを毎回要求しないことだ。
毎回フルテストを回すと、時間もAI消費も重くなる。
Full E2Eが必要なのは、影響範囲が大きいときである。
たとえば、
DB変更
認証変更
中核ロジック変更
データ整合性に関わる変更
サービス公開判定前
P0修正後に関連導線全体の再保証が必要な場合
一方で、通常のUI修正、文言修正、空データ表示の改善なら、以下で十分な場合もある。
format確認
lint
build
smoke
該当画面確認
必要に応じた関連E2E
確認の重さも、変更内容に応じて調整する必要がある。
13. 今回やらないこと
今回の目的は、運用ルールを整えることである。
だから、以下はやらない。
新規の管理ツール導入
外部チケット運用の追加
新規ドキュメントの大量追加
同じ説明の複数ファイルへの長文重複
大型の残課題ファイルの大幅編集
アプリコード変更
CSS変更
DB変更
E2E変更
packageや環境変数の変更
毎回Full E2Eを必須にするルール追加
確認用端末に毎回全画面再確認させるルール追加
目的はあくまで、軽量に閉じる仕組みを作ることだ。
試験実施。
指摘記録。
開発用PCで修正。
修正commit記録。
確認用端末で再確認。
Confirmed、Reopen、Backlog、Blocked、Won’t fixで管理。
この流れをMarkdownで回せるようにする。
14. GitHub Issueを使わない理由
GitHub Issueを使う案も悪くない。
ただ、今すぐ導入すると、運用が一段増える。
Issueを起票する。
ラベルを付ける。
PRと紐づける。
Closeする。
再確認する。
Projectsで管理する。
これはきれいだが、今の段階では少し重いかもしれない。
特に、すでにMarkdown運用がある程度できているなら、まずは既存の運用の中で閉じられるようにした方がよい。
いきなり外部チケット運用を増やすより、今あるMarkdown報告にID、状態、再確認、Close相当の定義を足す方が軽い。
これが今回の判断である。
15. 今回の結論
確認用端末と開発用PCの連携は、かなり形になってきている。
ただし、まだ完全には閉じていない。
弱いのは、指摘ID単位の管理である。
そこで今回は、GitHub Issue運用は使わず、Markdownだけで以下を回すルールを整える。
確認用端末が試験する
↓
ID付きで指摘する
↓
開発用PCが確認する
↓
P0/P1を優先修正する
↓
修正commitと検証結果を記録する
↓
確認用端末が指定IDだけ再確認する
↓
Confirmed / Reopen / Backlog / Blocked / Won’t fix で管理する
重要なのは、開発用PCが修正しただけでは終わりにしないことだ。
FixedはClose相当ではない。
確認用端末が再確認してConfirmedになって初めてClose相当である。
このルールにすれば、今よりかなり追いやすくなる。
AIと複数端末を使った個人開発では、作業を増やすだけでは足りない。
指摘を閉じる仕組みが必要である。
今回は、そのための軽量な運用ルールを作る一歩である。
