機能リクエストが実はバグレポートである時

「エクスポートの上限を増やす設定を追加してもらえますか」は機能リクエストのように読める。そしてほとんどのトリアージシステムはその場でそう分類する。時にはそうだ。時にはエクスポートは文書化された上限より低い数値で失敗しており、コードを見ることができない顧客は、説明できる最も妥当な解決策をでっち上げている。もっと大きな数字をください、そうすれば動くかもしれない、というふうに。どのラベルが役に立つのかは、バックログを機能リクエストとバグに分ける種類のラベルを扱っている。これは、顧客自身の言葉がラベルを間違った方向に向けてしまうケースであり、間違いのコストは、下を覗いてみれば誰も本当は望んでいないリクエストで満たされたバックログへとゆっくり漂流していくことだ。

実はバグである機能リクエストはどう見えるか

問題ではなく回避策を挙げる。本物の機能リクエストは通常、製品がまったくサポートしていない結果を説明する。「これを後で予定できるようにしてほしい」「ダークモードを追加してほしい」というふうに。誤って分類されたバグは、欠けている設定のように聞こえるが実は症状である、具体的な数字、閾値、振る舞いを説明する。「タイムアウトを増やしてほしい」「再試行オプションを追加してほしい」「一度にもっと多くの行をエクスポートさせてほしい」というふうに。その兆候は、リクエストする側が目標を説明する代わりに実装、設定、切り替え、上書きを提案していることだ。すでに文書通りにその機能を試し、文書が言うべきだと述べていることをそれがしなかったからだ。

なぜこれは思う以上に重要なのか

二つのキューは異なる担当者、タイムライン、成功基準を持ち、機能リクエストとして分類されたバグは機能リクエストに対して優先順位付けされ、バグが値する時間枠で修正される代わりに本物の製品の欠落と注目を奪い合うからだ。機能リクエストの追跡方法は、バグと機能を一つのキューに混ぜることが、最も声の大きい苦情を本物のリクエストより前に進ませてしまう理由を扱っている。密かにバグである機能リクエストは逆の害をなす。基礎となるバグが修正された瞬間に消えるはずの「機能」への投票を集めながら製品バックログに居座り続け、そのバックログを読む誰にとっても優先順位付けのシグナルを無駄にする。

顧客自身の言葉が間違った方向を指しているとき、どう見分けるか

何を追加してほしいかではなく、何が起こると期待していたかを尋ねよ。「エクスポートが500行で頭打ちになり、2,000行必要なので上限を上げてもらえますか」は、フォローアップの質問「500は文書化された上限ですか」が、文書化された数字は5,000でありエクスポートが早期に失敗していることを明らかにするまでは、上限引き上げの機能リクエストのように聞こえる。その一つの質問、何を期待していたかと何が起きたかだけで、分類作業の大部分が終わる。本物の機能リクエストには、それが満たしていない文書化された振る舞いなど存在しないからだ。まだ能力自体が存在しないので、期待すべきものが何もない。

サポート担当者かエンジニアか、どちらがこれを決めるべきか

サポート担当者はチケットを最初に見るので最初の判定を行うが、ラベルは変更しやすく間違えても安上がりであるべきで、その項目を永遠に間違ったキューに固定する一回限りの決定であってはならない。装われたバグの臭いがするものを毎週新しい「機能リクエスト」ラベルの中から見つけるエンジニアという軽量な二次チェックは、コードベースの文脈を持たないサポート担当者には認識できなかったものを捕まえる。これは正式である必要はなく、レビュープロセスというより五分間の一瞥に近い。

本物のバグが見つかった後、ループを閉じる方法は変わるのか

変わる。そして送れるメッセージが改善される。顧客フィードバックループを閉じるは、リクエストがリリースされたときにリクエストした人へ知らせることを扱っている。再分類されたバグはそのメッセージのより良いバージョンを得る。「その背後にあるバグを見つけて修正しました」は能力の高さのように聞こえる一方、「あなたがリクエストした機能を作りました」は偶然にしか真実にならなかったはずだからだ。本物の機能リクエスト、本当により高いエクスポート上限は、バグが消えて元の5,000行の上限で十分になった瞬間、二度と作られないかもしれない。

誤分類が一度も見つからなかったらどうなるか

バックログは本物の需要のように見えて実はそうでないリクエストで満たされ、そのバックログに対して行われる優先順位付けの決定は歪みを引き継ぐ。四十票の「機能」は実際には同じバグに出くわした四十人かもしれず、字義通りのリクエストを構築すること、つまり実際には一度も制約ではなかった上限を上げる設定を作ることは、何も修正しない複雑さをもたらす一方で、基礎となるバグはまだこのスレッドを見つけていない顧客から新しい「機能リクエスト」を生み出し続ける。

FAQ

すべての機能リクエストを既知のバグと照合する正式な手順を追加する価値はあるか? 正式な手順ではなく、むしろ習慣だ。新しい機能リクエストをトリアージする誰もが、ラベルを適用する前に「文書化された振る舞いはすでにこれを行うと主張しているか」を尋ねるべきだ。その一つの質問だけで、プロセスの負荷を増やすことなくほとんどの誤分類を捕まえられるからだ。

バグが見つかった後も顧客が機能リクエストだと主張し続けたらどうするか? 何を見つけたか、そしてバグが修正されれば顧客が提案した設定がもう必要なくなる理由を説明せよ。ほとんどの顧客は、本物の修正が利用できないと思い込んだから回避策を求めているのであり、特にその設定を望んでいたわけではない。

再分類された項目は、機能リクエストとして集めた投票やコメントを失うのか? 可視のまま保持すべきだ。その投票はそもそもバグを見つけることにつながった証拠であり、その痕跡を隠すことは、次に別のチケットで同じ誤分類を捕まえることを難しくするからだ。

逆のことも起こりうるか、実は機能リクエストであるバグレポートは? 頻度は低いが、ある。「これは壊れている」は時に「これは私が想定していた動作をしていない」を意味し、それは欠陥ではなく欠けている能力だ。何を期待していたかと何が文書化されているかという同じ質問が、この方向でも分類を行う。

この記事の技術的な記述は第三者による確認を受けていません。誤りがあればお知らせください。修正します。

changeloopの関連ページ： 開発者向けドキュメント, changelogツール比較