チェンジログ側から顧客フィードバックループを閉じる方法
1分で読めます
顧客フィードバックループが閉じるのは、フィードバックを寄せた本人がそれがどうなったかを知らされたときだ。ファイルされたときでも、優先順位が付けられたときでも、出荷されたときですらない。伝えられたときだ。ほとんどのチームは最初の三つのステップをうまくこなすが、最後の一つはまったくこなさず、そしてなぜフィードバックを送ってくれる人々が送らなくなっていくのか不思議に思う。
この記事はその最後のステップについてのものであり、一つの具体的な主張についてのものだ。チェンジログこそがループを閉じるのにふさわしい場所である。なぜならそれは、ループを閉じられる瞬間にすでに存在している唯一の成果物だからだ。
顧客フィードバックループとは何か
顧客フィードバックループとは、ユーザーがあなたに何かを伝えることから、そのユーザーがあなたがそれに対して何をしたかを知るまでの経路のことだ。四つのステップがある。フィードバックを集める、それをどうするか決める、結果を出荷する、そして依頼した人に伝える。四つ目のステップが起こるまでループは開いたままだ。フィードバックを集め、修正を出荷しても、誰にも伝えないチームが持っているのは、ループではなく受信箱だ。
| ステップ | 何が起きるか | どこで壊れがちか |
|---|---|---|
| 収集 | フィードバックが届く：ウィジェット、サポート、営業、インタビュー | 何も壊れない。すべてのチームがこれを行う |
| 決定 | トリアージされ、重複と統合され、受理または却下される | 却下が伝えられることは決してない |
| 出荷 | 誰かがそれを作り、公開される | マージの時点で依頼へのリンクが失われる |
| 伝達 | 依頼者がそれが出荷されたことを知る | 省略されるか、声の大きい依頼者にだけ行われる |
この記事が扱うのは四つ目の行だ。それが壊れるのは文化的な理由ではなく、構造的な理由による。機能が出荷される頃には、それを引き起こした依頼は、出荷されたものとは別のシステムの中にあり、両者を結びつけることを仕事としている人は誰もいない。ループはもっと前、そもそも依頼をどう聞くかから始まっており、その文面とタイミングは顧客フィードバックの聞き方で扱っている。
なぜフィードバックループは開いたままになるのか
フィードバックループが開いたままになるのは、依頼と出荷された変更が別々の場所に存在し、その間のリンクが、あるとしても手作業で作られるからだ。依頼はフィードバックツール、サポートの受信箱、あるいはスプレッドシートの中にある。変更はpull requestの中にある。告知はチェンジログかメールの中にある。三つのシステム、三人の所有者、そして三つ目から一つ目へと戻るリンクは、誰かが数か月後に誰が依頼したかを思い出す、という形で作られる。
もう一つの理由がある。伝達のステップは通常、サポートのタスク（「その人に返信する」）としてではなく、マーケティングのタスク（「機能を告知する」）として捉えられている。告知は全員に向けて送られ、特定の誰にも届かない。三月に機能を依頼した人が六月の告知を読んだとしても、それは返信としてではなく、ニュースとして読まれる。ループが閉じるのは、そのメッセージが本人に宛てられているときだけだ。
なぜチェンジログ側からループを閉じるのか
チェンジログの項目こそが、まさに正しい瞬間に存在し、まさに正しい言葉を含み、まさに正しい人によって書かれる唯一の成果物だからだ。それは変更が公開されたときに存在し、それ以前には存在しない。それは何が変わったかを読者の言葉で述べており、それこそが依頼者が必要としているメッセージだ。そしてそれは、たった今そのpull requestを読んだ人によって書かれる。それは元の依頼へのリンクがまだ見える唯一の瞬間だ。
代替案と比較してみよう。フィードバックツール側からループを閉じるには、その機能がいつ出荷されたかをフィードバックツールが知る必要があり、それは誰かが手作業でステータスを更新することを意味する。pull request側から閉じるには、変更がまだ公開されていないマージの時点で顧客に伝えることになり、デプロイが遅れれば、それはタイムスタンプ付きの破られた約束になる。マーケティングの告知側から閉じるには、告知が出るのを待つことになるが、出荷された変更のほとんどには告知など出ない。
チェンジログはその中間に位置する。マージの後、リリースの瞬間に、言い回しがすでに仕上がった状態で。
ループはどのように、一段階ずつ閉じるのか
これは私たちが実行している仕組みだ。ここでは製品ツアーとしてではなく仕様として説明する。どのステップも手作業や他のツールで行えるからであり、重要なのは順序だ。
- フィードバックは、それを修正するリポジトリのissueになる。 ウィジェットからの投稿は、ラベル付きのGitHub issueとしてファイルされる（
feature-requestまたはbug、優先度、そしてfrom-widget）。投稿者のメールアドレスはissue本文に入れない。issueはコードのすぐそばに存在するため、三つ目のステップがそれを見つけられる。手でファイルされたissue、たとえば機能要望のテンプレートから作られたものはこの経路の外にある。五つ目のステップはそこにコメントしないので、そのループは自分で閉じよう。 - 修正がそのissueを参照する。 pull requestは
Fixes #142と記述する。GitHub自身のクローズキーワードだ。新しく学ぶことは何もなく、開発者がすでに書いているのと同じ文だ。 - チェンジログの項目はマージされたpull requestから下書きされ、リンクを運ぶ。 マージの時点で下書きが作成され、
#142がPR本文から読み取られ、下書きに紐づけられる。リンクはまだ安価なうちに、機械によって、すでにそこにあるデータから作られる。 - 人間がその項目をレビューする。 言い回し、対象読者、そもそも公開すべきかどうか。破棄された下書きは何も閉じない。それは正しいことだ。たまたまissueを参照していただけの内部リファクタリングはニュースではないからだ。
- 承認されると、依頼者に伝えられる。 フィードバックから作られたissueにコメントが投稿される。「Shipped —」に続けて項目のタイトルと、公開された項目へのリンクだ。そしてウィジェットは投稿者に、同じ出荷済みの項目を表示する。一度だけ、二度と繰り返さず、そして人間がその項目を公開した後にだけ。同じ項目は依頼していなかったすべての人にもフィードとウィジェットを通じて配信される。
ステップ五の順序こそがこの設計のすべてだ。マージの時点で依頼者に伝えることの方が早く、簡単だっただろうが、それはデプロイが遅れる頻度とほぼ同じ頻度で間違ったものになっていたはずだ。フィーチャーフラグはこの順序さえも壊す。承認と公開が、機能が依頼者のアカウントにとってまだ見えない間に起こりうるからだ。フィーチャーフラグと機能リクエストは、フラグが絡んだときにこのステップが必要とする追加のチェックを扱っている。
顧客にとって、閉じたループはどう見えるか
それは返信のように見える。顧客はウィジェットを通じて依頼を送った。そしてある日、ウィジェットがそれを出荷済みとして表示し、彼らの言葉でそれを説明する項目へのリンクが添えられる。GitHub上では、issueにも同じ知らせがコメントとして付く。彼らはニュースレターを購読したわけでも、ロードマップを確認したわけでも、チェンジログを検索したわけでもない。伝えられたのだ。
その体験こそが、二回目のフィードバックを引き起こす。人々は、答えてくれるプロダクトにフィードバックを送るものだ。チェンジログの例のページには、ユーザーが目に見えて依頼を送り続けているチームの項目が集められており、その共通点はツールではない。項目が返信として読めることだ。
フィードバックループはどう測定するか
出荷された変更のうち、少なくとも一人の依頼者に伝えたものの割合と、出荷から伝達までの時間を測定しよう。二つの数字であり、リンクが存在すればどちらも簡単で、存在しなければどちらも不可能だ。
- クローズ率：今月公開されたチェンジログの項目のうち、少なくとも一つの依頼にリンクしていたものはいくつあり、そのうち依頼者に通知したものはいくつあるか。二つ目の数字が一つ目よりずっと低いなら、通知が機能していない。一つ目が低いなら、依頼がpull requestから参照されておらず、その修正はPRテンプレートに一文を加えることだ。
- 出荷から伝達までの時間：項目が公開されてから依頼者に伝えられるまでの時間。上記の仕組みがあれば数秒だ。手作業では通常数週間か、あるいは永遠に来ない。そしてその「永遠に来ない」が重要な数字だ。
集めたフィードバックの量でループを測ってはいけない。収集は簡単なステップであり、それを測定するチームはそれを最適化してしまい、より多くの開いたループを生み出すことになる。
ロードマップはどこに位置づけられるか
公開ロードマップは、ループを早い段階で閉じる一つの方法だ。依頼者に、彼らの依頼が出荷される前にすでに聞き届けられていたと伝える。有用ではあるが、最後のステップの代わりにはならない。「予定」は未来についての約束であり、「出荷済み」は現在についての事実だ。公開ロードマップを同じissueから、列ごとに一つのラベルで運用しよう。そうすれば同じ依頼が、どこにも再入力されることなく予定から出荷済みへと移動する。出荷済みへの移動はラベルの変更（roadmap:shipped）であり、項目が承認されても何かが代わりにやってくれるわけではないので、同じレビューの中で行おう。
FAQ
顧客フィードバックループの四つのステップとは何か? 収集、決定、出荷、伝達だ。四つ目のステップが起こるまでループは開いている。多くのフレームワークは中間に分析や優先順位付けのステップを加えるが、それらは「決定」の精緻化にすぎず、どれも何かを閉じるものではない。
依頼を却下する場合も顧客に伝えるべきか? そうすべきであり、それはループの中で最も見過ごされているメッセージだ。「これは行わない、その理由はこうだ」という明確な言葉は待ちを終わらせる。沈黙はループを永遠に開いたままにし、顧客に確認させ続けることになる。
ループを閉じることと機能を告知することはどう違うのか? 告知は全員に向けて送られる。ループを閉じることは、依頼してきた人々に、彼らが依頼した経路で返信することだ。両方を行おう。それらは異なる読者への異なるメッセージだ。
依頼者がGitHubを使っていない場合はどうするか? ほとんどの依頼者は使っていないが、それで問題ない。ウィジェットは送ったものの状況を、出荷済みの項目とそのリンクも含めて表示し続けるので、彼らには書き込んだページ以外に何も必要ない。issueへのコメントは、リポジトリを見られる人のためのものだ。
このループはGitHubの代わりにGitLabやBitbucketでも機能するか? ウィジェットとチェンジログは機能するが、ステップ五の自動コメントは今のところ機能しない。GitLabやBitbucketを使うチームでも、すべての提出は受け取られ、issueとして記録され、依頼者にはウィジェットで状況が表示されるが、そのループをissue自体に閉じて戻す部分だけは、その連携が実現するまで手作業で行うステップになる。
この記事の技術的な記述は第三者による確認を受けていません。誤りがあればお知らせください。修正します。