1. はじめに
独力＋AI活用で月商1億円を目指している。
最近は、開発用PCで実装を進め、確認用端末で実機確認やシナリオ試験を行う体制が少しずつ見えてきた。
ただ、ここで新しい課題が出てきた。
確認用端末が指摘する。
開発用PCが修正する。
PRを作る。
mainに反映する。
再確認する。
この流れ自体はかなり良い。
しかし、実際に運用してみると、どの指摘が、どのPRで直ったのかを追いづらいという問題がある。
指摘はドキュメントに残る。
修正はGitHubのPRに残る。
作業報告もある。
ただ、指摘1件ごとの状態管理が弱い。
そこで、GitHub Issuesを使うことを考え始めた。
2. 今の課題
今の開発体制では、確認用端末の役割がかなり重要になっている。
実機で画面を見る。
シナリオ試験をする。
スクリーンショットを残す。
P0 / P1 の問題を指摘する。
その指摘を開発用PCが修正する。
この流れは良い。
ただし、現状のままだと、こうなりやすい。
確認用端末が指摘する
↓
開発用PCが直す
↓
ただし、どの指摘がどのcommit / PRで直ったか追いづらい
↓
再確認したかどうかも追いづらい
↓
完了したのか、まだ残っているのか曖昧になる
これはかなり危ない。
AIを使って開発していると、作業量はどんどん増える。
PRも増える。
ドキュメントも増える。
指摘も増える。
その中で、P0 / P1 の重要指摘が埋もれると、品質管理が崩れる。
3. GitHub Issuesは相性が良さそう
そこで、GitHub Issuesを使う。
GitHub Issuesは、作業や不具合、改善点を1件ずつ管理できる。
さらにPRと紐づけることもできる。
これを使うと、かなり分かりやすくなる。
確認用端末の指摘1件 = GitHub Issue 1件
開発用PCの修正PR = そのIssueにリンク
PRマージ = IssueをClose
確認用端末の再確認 = IssueコメントでConfirmed / Reopen
この形にできれば、かなり整理される。
特に、PR本文に Fixes #123 のように書いておけば、PRマージ時にIssueを自動で閉じることもできる。
これはかなり便利である。
4. いきなり全部をIssue化しない
ただし、ここで注意したい。
いきなり全残課題をGitHub Issuesへ移すのは危険である。
今でも残課題一覧はかなり多い。
後回し機能も大量にある。
仕様メモや将来構想も多い。
これらを全部Issue化すると、管理対象が増えすぎる。
Issueを作ること自体が作業になってしまう。
Issue管理のためのIssue管理になってしまう。
それは避けたい。
まずは、確認用端末から出たP0 / P1指摘だけをIssue化するのがよい。
5. Issue化するもの、しないもの
最初の運用では、Issue化する対象を絞る。
Issue化するもの
・確認用端末のP0 / P1指摘
・再現性のある不具合
・初期公開をブロックする問題
・PRと紐づけたい修正作業
・再確認が必要な問題
Issue化しないもの
・P2以下の細かい改善
・単なる感想
・記事ネタ
・大きすぎる構想
・将来やりたいこと
・既存の残課題一覧にある大量の項目すべて
これくらい割り切った方がよい。
GitHub Issuesは、全体構想の置き場ではなく、今閉じるべき作業の管理に使う。
6. 残課題一覧との役割分担
ここはかなり重要である。
今後は、以下のように分けたい。
残課題一覧:
全体のロードマップ、仕様メモ、P0/P1/P2、後回し機能の正本
GitHub Issues:
今すぐ閉じるべきP0/P1の実行管理
GitHub Projects:
Issue / PRの進捗ボード
つまり、GitHub Issuesは残課題一覧の置き換えではない。
残課題一覧は、全体像を見るために必要である。
GitHub Issuesは、実際に閉じるチケットを管理するために使う。
この役割分担を間違えると、二重管理になる。
逆に、役割を分ければかなり強い。
7. ラベルは最小限でよい
ラベルも、最初から増やしすぎない方がよい。
最初はこれくらいで十分だと思う。
source:review
priority:P0
priority:P1
priority:P2
type:bug
type:ui
type:e2e
type:docs
status:needs-recheck
status:confirmed
status:blocked
大事なのは、ラベルの多さではない。
P0 / P1 が見えること。
再確認が必要なものが見えること。
ブロックされているものが見えること。
PRと紐づいていること。
これができれば、まずは十分である。
8. GitHub Projectsも使えそう
Issueが増えてきたら、GitHub Projectsも使える。
たとえば、以下のような列を作る。
Todo
In Progress
Fixed
Needs Recheck
Confirmed
Backlog
これなら状態がかなり見やすい。
確認用端末がIssueを作る。
開発用PCがIn Progressにする。
PRがマージされたらFixedになる。
確認用端末が再確認する。
問題なければConfirmed。
直っていなければReopen。
これができれば、かなり実務的な管理になる。
9. Issueテンプレートを作る
確認用端末の指摘を安定させるには、Issueテンプレートが必要である。
たとえば、以下のような形でよい。
## 概要
## 重要度
- [ ] P0
- [ ] P1
- [ ] P2
## 確認対象
- branch:
- commit:
- URL:
- 実施端末:
- 実施日時:
## 再現手順
1.
2.
3.
## 期待結果
## 実際結果
## スクリーンショット
## 開発側対応
- 対応方針:
- PR:
- commit:
- 再確認要否:
## 再確認
- [ ] Confirmed
- [ ] Reopen
- [ ] Blocked
このテンプレートがあれば、指摘の品質が上がる。
単なる感想ではなく、修正できるチケットになる。
10. 実際の運用フロー
理想の流れはこうである。
1. 確認用端末がP0 / P1を見つける
2. GitHub Issueを作る
3. Issue番号を確認報告にも書く
4. 開発用PCがIssue番号を見て修正ブランチを切る
5. PR本文に Fixes #Issue番号 を書く
6. PRマージでIssueをClose
7. 確認用端末が再確認する
8. 問題なければ Confirmed コメント
9. 直っていなければ Reopen
この流れができれば、指摘から修正、再確認までがつながる。
今一番弱いのは、この「クローズ管理」である。
Issueを使えば、ここがかなり改善する。
11. AI開発との相性も良い
GitHub Issuesは、AI開発とも相性が良いと思う。
AIに対して、
「Issue #123を修正してください」
「PR本文にFixes #123を書いてください」
「Issueの再現手順に従って修正してください」
「対応後、再確認対象を報告してください」
と言える。
これは、曖昧な自然言語の指示より強い。
AIは曖昧な指示だと逃げることがある。
ドキュメントだけ直すこともある。
論点をずらすこともある。
しかし、Issue番号があると、作業対象が明確になる。
これはかなり大きい。
12. PCを増やす前に、管理を強くする
最近、PCを増やしたら作業が早くなるかも考えている。
それ自体は悪くない。
ただ、PCを増やすより先に、作業管理を強くした方が効果が出る可能性もある。
特に、確認用端末のP0 / P1指摘をIssue化し、PRと紐づけ、再確認まで追えるようにするのはかなり効果が高い。
端末を増やしても、指摘が閉じられなければ意味がない。
開発を進めても、何が直ったか分からなければ危ない。
再確認されないまま完了扱いになると、品質が落ちる。
だから、GitHub Issuesの導入は、PC追加より先にやる価値があるかもしれない。
13. 今回の結論
GitHub Issuesは、今の開発体制にかなり合っている。
ただし、最初から全残課題をIssue化する必要はない。
まずは、確認用端末から出たP0 / P1指摘だけでよい。
確認用端末のP0/P1指摘だけIssue化する
PRで Fixes #番号 を付ける
PRマージでIssueをCloseする
再確認結果をIssueコメントに残す
残課題一覧は全体正本として維持する
この運用なら、いま弱い「指摘ID単位のクローズ管理」がかなり改善する。
独力＋AI活用では、作業量が増える。
AIも動く。
PCも増える。
PRも増える。
ドキュメントも増える。
だからこそ、重要指摘を閉じる仕組みが必要である。
GitHub Issuesは、そのためのちょうどよい道具になりそうだ。
まずは小さく始める。
P0 / P1だけIssue化する。
PRと紐づける。
再確認する。
この流れができれば、品質管理は一段上がると思う。
0 件のコメント:
コメントを投稿