この記事は、自分の開発運用で試している見積もりのやり方を、AIに整理してもらいながら下書きしています。
実際に使っていること、仮説、まだ未検証のことを分けて書きます。
結論
AIに見積もりの答えを出させるより、プランニングポーカー前の論点整理役にする方が使いやすいと感じています。
AIの数字をそのまま採用するわけではありません。
見たいのは、次のような点です。
- どの作業が重そうか
- どこが未確認か
- 過去のどのチケットに近いか
- AIで短くなりそうな作業と、短くなりにくい作業は何か
先にこれを出しておくと、人間同士の見積もり会話が始めやすくなります。
AIにそのまま見積もらせると困ること
最初は、こんな聞き方をしていました。
このチケットを見積もってください。
これでも、AIはすぐに 3SP のような数字を返してくれます。
ただ、その数字だけだと困ります。
A: AIは3SPと言っているけど、本当に3でよい？
B: 実機確認や証跡も入っている？ API側の変更は見ている？
数字だけ出ても、何を含めた見積もりなのかが分からない。
そこで、AIには最初から数字だけを聞かないようにしました。
AIに出してもらうもの
今は、見積もり前に次の形で出してもらっています。
| 出してもらうもの | 何を見るか |
|---|---|
| 5軸評価 | 複雑さ、影響範囲、不確実性、依存関係、テストの重さ |
| 過去の比較例 | 小さめ、中くらい、大きめのどれに近いか |
| AIで短くなる作業 | 類似実装探し、影響箇所洗い出し、テスト雛形など |
| AIでも残る作業 | 仕様判断、実機確認、証跡、関係者確認など |
| 上振れ条件 | 何が分かると見積もりが重くなるか |
この時点では、AIの見積もりを正解とは見ません。
むしろ、AIがどこを軽く見ているかを確認します。
例: 画面に1項目を追加するだけに見えるチケット
たとえば、ある画面に表示項目を1つ追加するチケットがあったとします。
ぱっと見ると軽そうです。
でも、実際には次の確認が必要でした。
- APIの返却項目はすでにあるか
- 表示条件はユーザー状態で変わるか
- 似た画面にも横展開が必要か
- widget testやsnapshotを更新するか
- 実機で表示崩れを見る必要があるか
- 証跡としてどのパターンを残すか
この場合、AIには次のように出してもらいます。
| 観点 | AIのたたき台 | 人間が見ること |
|---|---|---|
| 複雑さ | 局所修正に見える | 横展開があるなら中くらい |
| 影響範囲 | UI中心 | API返却や状態管理まで触るか |
| 不確実性 | 仕様次第 | 表示条件が未確定なら上振れ |
| テスト | widget testで足りそう | 実機確認や証跡が必要か |
| 過去の比較例 | 小さめより重く、中くらいより軽い | 過去の似た画面追加と比べる |
この表があると、AIの数字が外れていても使えます。
「どこが見落とされているか」を話せるからです。
SPと人日を分ける
自分の運用では、SPと人日は分けて扱っています。
| 種類 | 扱い |
|---|---|
| SP | 開発、テスト、レビュー対応を含む相対サイズ |
| 調査・設計 | 必要なら人日で別に見る |
| 証跡 | テストパターンを列挙して積み上げる |
| POレビュー・コードレビュー | サブタスク工数には原則含めない |
特に証跡は、固定で 0.5人日 のように置くと外れやすいです。
正常系だけなのか、異常系や端末差分まで見るのかで変わるからです。
プランニングポーカーでの使い方
流れはシンプルです。
AIの役割は、最後に答えを出すことではありません。
最初に、見積もりで話す点を並べることです。
使っているプロンプト
実際に使うなら、このくらいで始められます。
このチケットをプランニングポーカーのたたき台として整理してください。
出してほしいもの:
- 5軸評価
- 過去の似たチケットとの比較
- AIで短くなりそうな作業
- AIでも短くなりにくい作業
- 上振れ条件
- 人間に確認したいこと
注意:
- SPは相対サイズとして扱う
- 実機確認、外部連携、証跡取得を軽く見ない
- 不明点は推測せず、未確認として書く
チケット概要:
...
影響しそうな範囲:
...
過去の比較例:
...
注意点
このやり方にも穴があります。
1. 過去の比較例が古い
チームの状態やテスト基盤が変わると、昔のチケットは比較しづらくなります。
比較例には、いつの事例か、何を含めたSPか、今でも使えるかを残した方がよさそうです。
2. AIが仕様を埋めてしまう
AIは、未確定の仕様も自然な文章で補ってしまいます。
出力には「前提」「未確認」「上振れ条件」を入れて、分からないことを分からないまま残すようにしています。
3. AIあり見積もりが短くなりすぎる
AIを使うと短くなる作業はあります。
ただ、仕様判断、実機確認、証跡取得、関係者確認は残ります。
なので、自分は「AIありなら半分」とは置かず、短くなる作業と残る作業を分けて見ています。
まだ未検証のこと
この運用は、見積もり会話のたたき台としては使えています。
ただし、まだ次は測れていません。
- 見積もりブレがどう変わったか
- 実績工数との差分を見られるか
- 複数人で使ったときに納得感が上がるか
- AIあり見積もりで過小評価が増えないか
ここは今後、チケットごとに記録して見たいところです。
小さく始めるなら
最初は、これだけでよいと思います。
- 過去チケットを小・中・大で3件選ぶ
- 見積もり前にAIへ5軸評価と過去の比較例を出させる
- 会議後に「どの軸が外れたか」だけ残す
AIに正解を出させるのではなく、人間が見落としやすい論点を先に並べてもらう。
そのくらいの距離感が、プランニングポーカーでは扱いやすいと感じています。