曖昧なJiraチケットが生む隠れたコスト
曖昧なJiraチケットは、最初はあまり危険に見えません。本当の問題は後から出てきます。人によって抜けた部分を違う前提で補い、数日かけた集中作業が結局は別の方向を向いていたと分かるからです。
なぜ曖昧なチケットは生き残るのか
月曜の朝、あるバックエンドエンジニアがチケットを拾います。タイトルは一見すると具体的です。「注文更新時のユーザー通知を追加する」。説明欄には2文と、3週間前のSlackスレッドへのリンクがあるだけです。ぱっと見では十分に思えます。彼女は3日かけて、注文ステータスが変わるたびに動くメール通知の仕組みを作りました。
木曜、PRレビューの場でPMが入ってきてこう言います。「そういう意味じゃなかった。必要だったのは発送イベントに対するアプリ内通知だけで、しかもユーザーはそれをオフにできる必要があった」。誰も間違っていません。誰も怠けていません。ただ、そのチケットが抱えていた判断事項を、最初から表に出せていなかっただけです。
わざと曖昧なチケットを書く人はいません。会議の合間の2分で書いて、あとで戻って詳細を足すつもりでいるのです。でも、その「あとで」はだいたい来ません。書いた本人の頭の中には、すでに必要な文脈がそろっています。どの出来事が重要か、どの通知経路を想定しているか、どのユーザーに影響するかも分かっています。
けれど、その多くはページ上に残りません。本人には明白に思えるからです。ほかの人にとっては、まったく明白ではありません。
Jiraはこれを悪化させます。理由は、あまりにも簡単に作れてしまうからです。何が明確に範囲外なのかを問う必須項目はありません。20語未満の説明をはじくような仕組みもありません。要約欄に3語だけ入れて、説明を空にしたまま Create を押しても通ります。Jiraは止めません。それは便利さでもあり、罠でもあります。その結果、一見すると完成しているように見えるのに、実際に誰かが作業を始めて初めて曖昧さが露呈するチケットが、backlogに大量に積み上がります。
実装準備ができた計画には何が入っているのか
多くのチケットが答えているのはひとつの問いだけです。何を作りたいのか。実装準備ができた計画は、6つの問いに答えます。
| 項目 | 何に答えるか |
|---|---|
| 範囲 | 何が入るのか、そして何を明確に入れないのか |
| 制約 | 何を変えてはいけないか、何を壊してはいけないか |
| 手順 | 何が必要で、どの順で進むのか |
| 例外ケース | 当然と思っていた流れが崩れたときに何が起きるか |
| 依存関係 | 先に存在していなければならないものは何か |
| 完了の定義 | 本当に終わったと全員がどう判断するか |
これはbacklog内のすべての小さなバグ修正に使う確認表ではありません。でも、スプリントに入るもの、誰かの時間を数時間以上使いそうなものには、作業開始前にこの問いへの答えが必要です。チームがもっとも飛ばしがちなのは範囲です。何をやらないのかを明記するのは、やることに気持ちが向いていると不要に見えます。けれど、驚くほど多くの手戻りはそこから始まります。
制約は、声に出されにくい要求です。
- 既存の注文メールフローを壊さない。
- 現在の通知サービスの中で完結させる。
- このスプリントでは新しいインフラを増やさない。
こうした内容は、書いた本人が「みんな知っているはず」と思っているため、書き残されないことがよくあります。実際には知っていません。そして完了の定義は、「たぶん終わった」と「全員が終わったと合意している」の境目です。よい完了の定義は、観察できて、検証できます。
構造より先に問いが必要
どのJira環境でも、いずれ同じ流れをたどります。誰かが説明テンプレートを追加し、Summary、Acceptance Criteria、Technical Notes、Out of Scopeのような欄を作ります。数週間のあいだは、みんなそれを埋めます。ところがその後は、以前は空っぽの説明欄にあった曖昧な言葉が、ただラベル付きの箱に分散するだけになります。構造は改善しました。でも、考え方は変わっていません。
テンプレートでは解決できません。問題が構造ではなく、認知にあるからです。書いている本人は、自分が何を落としているかに気づいていません。Edge Cases と書かれた空欄があっても、まだ例外ケースを考えていない人には役に立ちません。役立つのは問いです。判断を迫る、具体的な問いです。
隠れた判断を引き出すうえで、とくに効く問いが5つあります。
- システムの振る舞いは何が変わるのか。
- 主役となるのは誰で、その人は何を達成したいのか。
- どんな場合には、これは起きてはいけないのか。
- これを出さなかったら、何が壊れるのか。
- これは既存ユーザー向けか、新規ユーザー向けか、それとも両方か。
これらが効くのは、答えられるだけの具体性がありつつ、ほとんどの機能チケットに使えるだけの広さもあるからです。答えていく行為そのものが計画づくりです。テンプレートは、答えが落ち着く場所にすぎません。
具体例
実際にはこうなります。元のチケットはとても小さいものです。「注文更新時のユーザー通知を追加する」。説明には、注文ステータスが変わったら通知を送るべきだということと、見た目はデザインに確認すること、これしか書かれていません。スプリントに入れるには足りますが、自信を持って実装するにはまったく足りません。
短い明確化のやり取りだけで、状況は大きく変わります。
| 明確化の問い | 回答 |
|---|---|
| どのステータス変更が重要か | 発送済みと配達済みだけ |
| どのチャネルか | このスプリントではアプリ内のみ |
| ユーザーはオフにできるか | できる。初期状態はオン |
| オフラインのユーザーはどうするか | 次回ログインまで通知をキューに入れる |
| 既存注文にも適用するか | しない。新しい注文だけ |
| 配信に失敗したらどうするか | 1回だけ再試行して、その後ログに残す |
15分後には、そのチケットが意味するものは全員にとってひとつになります。更新後の版には、実際の範囲、実際の制約、順序づけられた手順、現実的な例外ケース、そしてテスト可能な完了の定義があります。同じチケットなのに、明確さはまるで違います。違いはテンプレートの良し悪しではありません。作業に入る前に、意図して少し質問したことです。
この流れの中でAIが向いている位置
AIがチケットを書くわけではありません。チケットを書くのは人です。でもAIは、流れの中のある一点ではとても役に立ちます。意図はもうあるけれど、構造がまだ固まっていない段階です。言語モデルは、曖昧な説明を読んで「ユーザーがオフラインのときにどうなるかは考えましたか」と聞けます。Slackスレッドに散らばった答えを、範囲、制約、手順に整理できます。計画にはデータベース移行が書かれているのに、依存関係の一覧には適切なレビュー担当が入っていない、といったズレにも気づけます。
ただし、AIが得意ではないのは、プロダクト判断を代わりに下すことです。メールにすべきか、pushにすべきか、アプリ内にすべきかを問いかけることはできます。でも、そのどれが自分たちのユーザーとこのスプリントにとって正しいかは決められません。もっともらしい完了の定義を出すことはできても、それが本当に正しいかどうかはプロダクトを理解している人にしか分かりません。
パターンは単純です。人が決めて、AIが整理する。人が範囲を決めて、AIが抜けを見つける。Jira内の Just on Atlassian Marketplace も、この「明確化して、計画して、実行する」という流れの上に作られています。同じ流れは手作業でも成り立ちます。AIはそれを速くするだけです。
今日からできる3つのこと
- 次のスプリントの前に、backlogの中でもっとも曖昧なチケットをひとつ選び、この文章にある5つの問いを、誰かがコードを書き始める前に投げてみてください。少なくとも2つは、まだ決められていない判断が見つかるはずです。
- その答えを、範囲、制約、テスト可能な完了の定義として、別ドキュメントではなくチケット本体に書いてください。実装する人が本当に見るのはそこだからです。
- 上のテンプレートは出発点として使ってください。絶対の標準としてではありません。チームの言葉に合わせて変えてよいですが、問いだけは飛ばさないでください。もし、曖昧なチケットがそのままAIに渡される時代に、この明確化の段階がなぜさらに重要になるのかを大きな視点で知りたいなら、この連載の最初の記事がalignment problemを詳しく扱っています。なぜ多くのJira向けAIツールは、alignment problemを良くするどころか悪化させるのか。
