重複する機能リクエスト、声を失わずに統合する
1分で読めます
三人の顧客が三つの異なる週に、三つの異なる言い回しで同じ機能を求める。重複を捕まえるために構築されたトリアージプロセスは仕事をこなす。それらをグループ化し、三票を持つ一つのリクエストとしてカウントし、バックログはきれいなままだ。それが簡単な部分だ。どのラベルが役に立つのかは、言い回しでトリアージする前に根本的な能力でグループ化することを重複の機械的な修正として扱っている。それが扱っていないのは、三つのリクエストが一行になった瞬間に言葉そのものに何が起こるかであり、その損失は通常、それが解決した重複カウントの問題より大きい。
重複が統合される時、実際に何が失われるのか
各リクエスト提出者が使った具体的な言い回しで、それが崩れ込む投票数よりも情報量が多いことが多い。ある顧客は「フィルタリングされた結果をエクスポートする方法」を求め、別の顧客は「保存したフィルターを尊重するCSVエクスポート」を求め、三人目は「隠れた列を含まないエクスポート」を求めるかもしれない。三つとも同じ根本的なリクエストであり、正しくグループ化されているが、それぞれの言い回しはその人にとって何が重要かについてわずかに異なる強調を持ち、最初の提出の言い回しだけを保持する統合は他の二つを完全に捨ててしまう。カウントは生き残る。誰かが機能の正しいバージョンを構築するのを助けるであろう質感は、生き残らない。
投票数がすでに需要が存在すると言っているのに、なぜ質感が重要なのか
需要と設計は異なる質問であり、二番目の質問に答えるのは具体的な言い回しだけだからだ。「エクスポート」への十票はチームに機能を構築する価値があると伝える。それは「エクスポート」がCSVを意味するのか、PDFを意味するのか、予定されたメールを意味するのか、APIエンドポイントを意味するのかについて何も語らない。最初の言い回しを優先して十のうち九の元の提出を捨てる統合は、他の九人がわずかに異なる何かを望んでいたとしても、たまたま最初のリクエスト提出者が求めたものへと静かに仕様を狭めてしまう可能性がある。機能リクエストが実際何を記録すべきかは、まさにこのギャップを受付側から扱っている。重複を統合することは、それが受付後に再び現れる場所であり、チームが実際に求められたことの範囲を最も必要とするまさにその点だ。
言い回しを捨てるのではなく保持する統合プロセスはどのようなものか
置き換えるのではなく追加すること。正典的な項目はバックログビューのために一つのタイトルを保持するが、統合された各提出の元の言い回しは引用のリストとして、あるいはリンクされたソースチケットとして、それに付随したままになる。そうすれば後で項目をレビューする誰もが、チームメンバー一人の要約の代わりに、人々が求めたことの実際の範囲を見ることができる。これは構築するのにほとんど何もかからない。新しいシステムの代わりにチケット上の一つのフィールドであり、情報を圧縮する統合とその表示だけを圧縮する統合の違いだ。
機能：フィルタリングされたCSVエクスポート
投票数：12
統合されたリクエスト：
- "フィルタリングされた結果をエクスポートする方法" (acct_4421)
- "保存したフィルターを尊重するCSVエクスポート" (acct_8832)
- "隠れた列を含まないエクスポート" (acct_1097)
...すべての重複が統合に値するのか、それとも誤った一致があるのか
一部は誤った一致であり、「似ているように聞こえる」を「同じリクエストである」として扱うことはそれ自体の失敗モードだ。「私のデータをエクスポートさせてほしい」と「フィルタリングされたビューだけをエクスポートさせてほしい」は、実際には同じ一般的な能力の二つの異なる範囲を説明しているにもかかわらず、「エクスポート」というキーワードの一致によってグループ化されるかもしれない。それらを統合すると、間違ったものの投票数を膨らませるか、もっと悪いことに、たまたま最初に到着したという理由で狭いバージョンを出荷してしまう。グループ化に対する人間による通過、素早いものであっても、それが積み重なる前にこれを捕まえる。自動的な類似度マッチングだけでは、語彙に基づいて過剰に統合し、意図に基づいて統合不足になる。
重複チェックは実際にはいつ実行すべきか、受付時か、それとも後からか
両方だ、理由はそれぞれ異なる。受付時のチェックは明白なケース、つまりすでに開いている何かを言い換えただけの新しいリクエストを、それが独自の未追跡の項目になる前に捕まえる。提出時点で公開中のリクエストに対する類似度検索は、人間を介さずにこれらのほとんどを処理する。後からの、より遅いペースでの二回目のチェックは、受付時に見逃されるケースを捕まえる。つまり、当時はキーワードや埋め込みの一致をすり抜けるほど異なる言葉を使っていた二つのリクエストが、チームが十数個のバリエーションを見た後になって、実は同じ根底の機能を説明していたと判明するケースだ。二回目のチェックを省くと、ほぼ重複するリクエストが別々のタイトルの下に無期限に散らばったままになり、それぞれが独自の小さな投票数を持ちながら、それが出荷につながるだけの数に決して積み上がらない。
リクエスト提出者は自分の提出が既存の項目に統合されたことを知るべきか
はい、そしてこれは顧客フィードバックループを閉じると同じ規律を通常より一歩早く適用したものだ。何かを提出して二度と何も聞かないリクエスト提出者は、それが最終的に出荷された他の十一票を持つ項目に正しく統合されたとしても、自分のリクエストがどこにも行かなかったと結論づける。「これを、他の人々も行った既存のリクエストと組み合わせました」という短い確認は一つのメッセージのコストで済み、顧客がそれが実際に追跡されたことがあるかどうかについての可視性を持たないために、数か月ごとに同じリクエストを再提出するのを防ぐ。
統合は機能が出荷される時に誰が功績を得るかを変えるのか
最初に提出した人だけでなく、全員を含めるべきだ。フィードバックループを閉じるは、リクエストが出荷された時にリクエスト提出者に知らせることを扱っている。統合された項目にとって、それは正典的なタイトルになった言い回しの持ち主だけでなく、統合に付随するすべてのアカウントを意味する。なぜなら各リクエスト提出者の視点からは、彼女はこれを求め、それが出荷されたのであり、トリアージプロセスがたまたまどの言い回しを保持したかには関係ないからだ。Changeloopでは、それはpull requestがリンクされたすべてのissueを指定するということだ（Fixes #142, fixes #187）。指定されていないissueにはコメントが付かない。
FAQ
統合されたリクエストごとに、引用か完全なチケットリンクか、どれだけの言い回しを保持する価値があるか? 短い引用は通常、一般的なケースには十分だ。その目的はレビュアーが言い回しの範囲を一目で見られるようにすることだからだ。元のものにスクリーンショットや、一行の引用が平坦化してしまうであろう詳細なワークフローの説明のような重要な追加のコンテキストがあった場合は、完全なチケットリンクも保持せよ。
各重複の言い回しを保持することはバックログをスキャンしにくくするか? デフォルトで折りたたまれていればそうではない。正典的なタイトルはざっと目を通すレビュアーが見るものだ。統合された言い回しはクリック一つか展開一つ離れたところにあり、より深い調査をする人のために存在するが、投票を数えるだけの人のためのビューを散らかすことはない。
二つのリクエストが同一に見えるが、構築されると異なるものを望んでいることが判明したらどうするか? それが明らかになった瞬間に再び分離し、元の統合を、繰り返しを避けるべき間違いとしてではなく、その時点で利用可能だった情報で下された合理的な決定として扱え。何も分割し直さないグループ化システムは、最終的にいくつかの間違った統合が永久に焼き付けられることになる。
統合されたリクエストが根本的な言い回しの人間によるレビューを受けるべき投票の閾値はあるか? 固定された数字はないが、構築の決定に近づいているどんなリクエストも、投票数にかかわらずそれに値する。なぜならそれが「エクスポート」と「保存されたフィルターを使ったCSVとしてのエクスポート」の違いがニュアンスであることをやめ、仕様になり始める点だからだ。
この記事の技術的な記述は第三者による確認を受けていません。誤りがあればお知らせください。修正します。