1. はじめに
独力＋AI活用で月商1億円を目指している。
最近は、開発用PCと確認用端末を分けて使う体制がかなり固まってきた。
開発用PCでは、実装、修正、自動テスト、ビルド確認、PR作成を進める。
確認用端末では、実機UI確認、シナリオ試験、スクリーンショット取得、試験報告を行う。
この分担はかなり有効だと思っている。
ただ、運用しているうちに、別の問題も見えてきた。
確認用端末が試験をすると、当然いろいろな問題が出てくる。
しかし、その中には、すぐ直すべき不具合もあれば、既に分かっている制限事項もある。
さらに、上流の問題が解消しない限り、下流の画面や操作を何度試しても意味がないケースもある。
このままだと、同じ問題を何度も報告してしまう。
既知の制限事項を毎回P0/P1として量産してしまう。
本来は上流ブロッカーを直すべきなのに、下流の現象ばかり追ってしまう。
そこで、既知ブロッカー・制限事項の台帳を作ることにした。
2. なぜ台帳が必要なのか
確認用端末の試験は重要である。
実際に画面を触ることで、自動テストでは拾いにくい違和感や導線の弱さが見えてくる。
シナリオ試験をすると、単体画面では分からない流れの詰まりも見つかる。
ただし、試験を増やすほど問題も起きる。
一番困るのは、既知のブロッカー配下で、同じような指摘が増え続けることである。
たとえば、ある上流処理が詰まっていて、そこから先の操作に進めない状態があるとする。
その状態で下流の確認を何度も行うと、
この画面に進めない
この操作ができない
この後続機能を確認できない
このシナリオが完走できない
という指摘が大量に出てくる。
しかし、根本原因は一つかもしれない。
その場合、本当に直すべきなのは上流ブロッカーであり、下流の指摘を大量に増やすことではない。
だから、既知ブロッカーとその影響範囲を台帳で管理する必要がある。
3. 残課題一覧とは役割が違う
ここで大事なのは、既知ブロッカー台帳は、残課題一覧の代わりではないということだ。
それぞれ役割が違う。
| 管理対象 | 役割 |
|---|---|
| 既知ブロッカー・制限事項台帳 | 試験可否、Blocked by、再開条件を管理する |
| 残課題一覧 | 開発用PCが実装する課題を管理する |
| 後回し機能一覧 | 初期公開では追わない機能や将来対応を管理する |
これを混ぜると、運用が混乱する。
確認用端末が見つけた問題を、全部そのまま開発残課題に入れると、残課題一覧が膨れ上がる。
逆に、後回し機能として登録していたものが、実は主要導線を止めている場合もある。
その場合は、後回しではなく、ブロッカーまたは残課題として再分類しなければならない。
つまり、台帳の役割は、単に問題を増やすことではない。
何が試験を止めているのか。
何が既知の制限事項なのか。
何を直せば再試験できるのか。
これを整理することである。
4. 台帳で管理したいもの
今回作りたい台帳で管理するのは、主に以下である。
既知ブロッカー
制限事項
Blocked by 関係
再開条件
残課題一覧との関係
後回し機能一覧との関係
開発用PCが対応すべきか
確認用端末が再試験すべきか
特に重要なのは、Blocked by 関係である。
下流の問題が、上流のどの問題によって確認不能になっているのか。
これを明確にする。
たとえば、ある初期導線が詰まっているため、後続の確認ができない。
この場合、後続の確認項目を全部P0にするのではなく、
上位ブロッカーが未解消のため、後続項目はBlocked byとして扱う
という整理にする。
これで、無駄な試験と重複報告を減らせる。
5. 状態を整理する
台帳には状態も必要である。
最低限、以下のような状態を使いたい。
| 状態 | 意味 |
|---|---|
| New | 新規に確認された状態 |
| Blocked | 上位問題や環境不足などで確認できない状態 |
| Fixed | 開発用PCが修正した状態。ただし再確認前 |
| Confirmed | 確認用端末が再確認し、解消を確認した状態 |
| Reopen | 再確認で未修正または再発を確認した状態 |
| Backlog | 後回しにする状態 |
| Won’t fix | 対応しない判断。理由必須 |
| Limitation | 現時点の制限事項として扱う状態 |
ここでも重要なのは、FixedとConfirmedを分けることである。
開発用PCが修正しただけでは、まだ完了ではない。
確認用端末が再確認して、解消を確認して初めてConfirmedになる。
これは、前回考えたMarkdown運用のClose相当ルールともつながる。
6. 既知ブロッカー配下を何度も試験しない
今回の台帳で一番効果が出そうなのは、既知ブロッカー配下の再試験抑制である。
確認用端末が長編シナリオ試験をしていると、途中で詰まることがある。
そのとき、下流工程を無理に全部確認しようとすると、試験結果が膨大になる。
しかも、多くは同じ上流原因に起因する可能性がある。
だから、今後はこうする。
上位ブロッカーが未Fixedの場合、下流工程を無理に繰り返し試験しない。
下流工程はBlocked byとして記録する。
上位ブロッカーがFixedになった後、指定範囲だけ再試験する。
これにより、確認用端末の作業効率が上がる。
AIツールの消費も減る。
報告書も読みやすくなる。
開発用PCも、どこを直せばよいのか判断しやすくなる。
7. 既知の制限事項を毎回P0/P1にしない
もう一つ重要なのは、制限事項の扱いである。
現時点では、まだすべての機能や導線が完成しているわけではない。
そのため、今は確認できない範囲もある。
それを毎回P0やP1として報告してしまうと、開発側の優先順位が崩れる。
すでに分かっている未実装範囲。
意図的に後回しにしている範囲。
現時点では確認できない範囲。
こうしたものは、制限事項として台帳に記録する。
そして、同じ理由で毎回新規P0/P1にしない。
ただし、別原因の問題が見つかった場合は、新しい指摘IDを採番する。
この切り分けが重要である。
8. 台帳は確認用端末ではなく開発用PC側で準備する
今回の判断として、台帳とルール整備は、確認用端末ではなく開発用PC側で行うのがよい。
理由はシンプルである。
確認用端末は、検証担当である。
実機確認、シナリオ試験、スクリーンショット、再確認に集中させたい。
そこに管理設計や台帳構造の整備までやらせると、また混乱する。
以前も、確認用端末に広い裁量を持たせすぎると、実際の試験ではなく、テンプレート作成やドキュメント作業に寄ってしまうことがあった。
だから、今回は開発用PC側で台帳を準備する。
そのうえで、確認用端末は台帳を見て試験する。
開発用PCは台帳を見て修正する。
両方が同じルールで動く。
この形がよい。
9. 今回は実装しない
今回の作業は、アプリ本体の実装ではない。
UI修正もしない。
DB変更もしない。
E2E修正もしない。
やるのは、ドキュメント、台帳、Cursor指示文の整備である。
これは一見、地味な作業である。
しかし、今後の開発効率にはかなり効くと思っている。
試験結果、既知ブロッカー、制限事項、残課題、後回し機能が混ざったままだと、開発が進むほど混乱する。
今のうちに分類ルールを作っておくことで、後の試験と修正の流れがかなり楽になるはずである。
10. 繰り返し指示にも反映する
台帳を作るだけでは足りない。
今後の繰り返し指示にも反映する必要がある。
開発用PC向けには、以下のような内容を入れたい。
確認用端末の報告がある場合は、既知ブロッカー・制限事項台帳も確認する。
既知ブロッカーはID単位でP0/P1を優先する。
修正後はFixedとして、commit、修正ファイル、検証結果、再確認対象を明記する。
Blocked by配下の下流工程を個別に大量修正対象にせず、まず上位ブロッカーを解消する。
Close相当は確認用端末の再確認でConfirmedになった場合のみとする。
確認用端末向けには、以下のような内容を入れたい。
試験前に既知ブロッカー・制限事項台帳を確認する。
Blocked byの上位IDが未Fixedの場合、下流工程を無理に再試験しない。
制限事項に登録済みの内容は、同じ理由で新規P0/P1にしない。
別原因の場合のみ、新しい指摘IDを採番する。
これで、台帳が実際の運用に組み込まれる。
11. 台帳を作ることで期待する効果
今回の台帳で期待している効果は大きい。
| 期待効果 | 内容 |
|---|---|
| 重複指摘の削減 | 同じ問題を何度もP0/P1にしない |
| 試験効率の向上 | 上位ブロッカー配下を無理に繰り返し試験しない |
| 優先順位の明確化 | まず直すべき上位ブロッカーが見える |
| 開発側の判断改善 | 残課題、制限事項、後回し機能を切り分けられる |
| 確認側の負担軽減 | 再試験範囲を絞れる |
| 古い指摘の保全 | 過去の報告やスクショを捨てずに扱える |
特に、長編シナリオ試験では効果が大きいはずである。
途中で詰まったときに、下流工程を全部P0にしない。
上位原因を記録し、下流をBlocked byとして整理する。
この運用ができると、試験結果がかなり読みやすくなる。
12. 今回の結論
確認用端末と開発用PCの連携は、かなり形になってきている。
ただし、試験結果、既知ブロッカー、制限事項、残課題、後回し機能が混ざると、運用が混乱する。
そこで、既知ブロッカー・制限事項台帳を作ることにした。
この台帳は、残課題一覧の代わりではない。
後回し機能一覧の代わりでもない。
役割は、試験可否、Blocked by、再開条件、制限事項を管理することである。
開発用PCは、この台帳を見て上位ブロッカーを優先修正する。
確認用端末は、この台帳を見て無駄な下流試験を避ける。
修正後はFixed、再確認後にConfirmed。
ConfirmedがClose相当である。
今回はアプリ本体を直すわけではない。
しかし、これは今後の開発と試験を安定させるための重要な整備である。
AIと複数端末を使った開発では、作業量を増やすだけでは足りない。
何を試験するのか。
何が既知なのか。
何がブロッカーなのか。
何を後回しにするのか。
何が解消されたら再開するのか。
これを整理する必要がある。
今回の台帳作りは、そのための一歩である。
0 件のコメント:
コメントを投稿