機能リクエストを見失わずに追跡していく方法

機能リクエストの追跡は、ほぼ常に二つの方法のどちらかで失敗する。リクエストが行き先を持たず、受信箱やSlackのスレッドに住み着いて一つずつ忘れられていくか、行き先はあるが誰もそこに戻ってこないため、まとめて忘れられていくかだ。機能する仕組みは両方の失敗に耐えなければならない。すべてのリクエストが着地する一つの場所と、来月その場所をもう一度開く理由が必要だ。

機能リクエストは実際どこから来るのか

ほとんどの追跡システムが想定するよりも多くのチャネルからだ。「あったらいいのに」を含むサポートチケット。公開ロードマップへのコメント。見込み客が取引を妨げているまさにその一点を名指しする営業電話。製品内のウィジェット。それぞれのチャネルには独自の担当者と独自のツールがあり、まさにそのためにリクエストは分散する。サポートのチケットキューと製品チームのバックログが同じシステムであることはめったになく、どちらか一方にしか届かないリクエストは、実質的に一つの部門にしか届いていない。

すべてのチャネル向けの単一の受付フォームはうまくいかない。誰も採用しないからだ。うまくいくのは、ルーティングが自動化されるまで一日五分のコピーアンドペーストで行う人力であっても、すべてのチャネルが流れ込む一つの行き先だ。

機能リクエストの追跡を実際に壊すものは何か

ほぼ常に二つのことだ。一つ目は行き先の欠如で、リクエストは届いたチャネルで返答され、どこにも永続的には記録されないため、三人の異なる顧客からの同じリクエストが、一つの信号ではなく三つの無関係な単発の返答のように見える。二つ目は、より多く見られるもので、いっぱいになって読まれなくなる行き先だ。フィルタリングされていない400行のスプレッドシートは、もはや追跡システムではない。たまたま編集可能なアーカイブだ。

二つ目の失敗の方が危険だ。追跡が機能しているように見えるからだ。リクエストは記録される。誰かが「何人がXを求めたか」と尋ねるまで何も壊れているようには見えず、正直な答えは「知るには400行すべてを読まなければならない」だ。

機能リクエストは実際何を記録すべきか

元のメッセージを読み返さずに後で三つの質問に答えられるだけの内容だ。何が求められたか、可能であればリクエストした本人の言葉で。誰が求めたか、そして答えが結局「作った」になった場合にどう連絡を取るか。そしてこれが一般的なリクエストなのか単発の事例なのかを知るために何が必要か。逐語的な引用は言い換えより価値がある。なぜなら、リクエストをトリアージした人が書いた言い換えはすでにその人自身の読み方を含んでおり、まさにその読み方こそ、六か月後に二人目が確認できないものだからだ。

どのラベルが役に立つのか

二つあり、それぞれ異なる質問に答える。種類のラベルは機能リクエストをバグレポートから分ける。両者には異なる担当者と異なるタイムラインが必要で、一つのキューに混ぜると最も声の大きい苦情がリクエストを追い越してしまうからだ。low、medium、highのような小さなセットに保たれた優先度のラベルは、「誰かが製品を使うのを妨げている」を「あったら嬉しい」から分ける。両者は非常に異なる対応時間に値し、どちらも相手のペースを受け継ぐべきではないからだ。種類のラベルを正しく付けることは、そのリクエストが名乗る通りのものであることを前提としている。機能リクエストが実はバグレポートである時は、顧客自身の言葉がそのラベルを間違った方向に向けてしまうケースを扱っている。

自動トリアージはリクエストが届いた瞬間に両方を適用できる。changeloopでは、ウィジェットからの送信は同じステップでfeature-requestかbugのラベルとpriority:low|medium|highのラベルを受け取り、さらにアイテムを開かなくてもソースが分かるようにfrom-widgetタグが付く。これだけで、午後をかけずに一分でバックログをフィルタリングできる。今月ウィジェットから来た優先度の高い機能リクエストをすべて見せて、というふうに。

三つ目のラベルは、公開ロードマップができた時点で役に立つ。リクエストした本人が自分で確認できるステータスだ。公開ロードマップがplanned、building、shippedの状態を完全に扱っている。簡単に言えば、このラベルは非公開のキューを、リクエストした本人が再度尋ねることなく確認できるものに変える。

次に何を作るかはどう決めるのか

数える前にグループ化する。同じ根本的な能力を異なる言い方で求めた十件のリクエストは、スプレッドシートに散らばった十行のように読める。しかしグループ化されれば強い信号になり、そのグループ化こそが通常欠けているステップであり、数えることではない。グループ化なしの生の数は、その背後にある実際の需要が最も大きい機能ではなく、最もキャッチーな名前を持つ機能に報いる傾向がある。

何人が求めたかだけでなく、誰が求めたかで重み付けする。更新の近いアカウントからのリクエストは、トライアル登録からの同じリクエストとは異なる緊急性を持つ。この文脈を裸の数字のために捨てる追跡システムは、最も役立つ数字ではなく、最も計算しやすい数字を最適化している。

ここでのすべての決定は、負けるリクエストも生み出し、それらも返答に値する。機能リクエストの断り方が、通らなかったリクエストをした人に何を伝えるべきかを扱っている。グループ化と重み付けは「次に何を作るか」の半分にすぎず、機能リクエストの優先順位付けが実際のフレームワーク、RICE、収益による重み付け、そして生の数値と、それぞれがどこで破綻するかを扱っている。

何かがリリースされたとき、どうループを閉じるのか

これは追跡システムが最も見落としがちなステップであり、リクエストした人が実際に気づくステップだ。顧客とのフィードバックループを閉じるがその仕組みを完全に扱っている。ここで当てはまるのは、ループを閉じることは元のリクエストがリクエストした本人と結びついたままである場合にのみ機能するということだ。GitHub issueから作られた機能リクエストのテンプレートで、リクエストした本人の身元がコメントに埋もれるのではなくissueに紐づいていることが、誰かが送るのを覚えていなければならない通知ではなく、自動の「リリース済み」通知を可能にするものだ。機能リクエストのテンプレートが具体的なテンプレートと各フィールドの役割を示している。

FAQ

機能リクエストの追跡にはどのツールを使うべきか? チームがすでに毎日確認しているものは、誰も開かない専用ツールに勝る。エンジニアリングがすでにそこに住んでいるならGitHub issueトラッカーがうまく機能し、製品がそこに住んでいるなら軽量なボードがうまく機能する。ツールそのものより、再び開かれるかどうかの方が重要だ。

機能リクエストの重複をどう防ぐか? 言い回しでトリアージする前に、根本的な能力でグループ化する。新しいものを作る前に既存のリクエストを検索することで、ほとんどの重複を捕まえられる。月次のグループ化作業で残りを捕まえる。 元の声を失わずに重複を統合するは、グループ化そのものが終わった後で言い回しをどう扱うべきかを扱っている。そうすれば統合が最初に届いた提出物へとリクエストを静かに狭めてしまうことはない。

すべての機能リクエストに返答すべきか? すべてに、短くても確認応答をすべきだが、すべてがすぐに決定を必要とするわけではない。リクエストした本人が自分で確認できるロードマップのラベルのような見える形のステータスは、チームが個別に負うはずだったほとんどの返答を置き換える。

機能リクエストの追跡と公開ロードマップの違いは何か? 追跡は、決してリリースされないものも含めた、すべてのリクエストの内部記録だ。公開ロードマップは、チームが公に約束するその部分集合であり、リクエストした本人が再度尋ねることなく見られるステータスを伴う。

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

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