この記事は裏freee developers Advent Calendar 2018の23日目の記事です。

こんにちは、freee 株式会社で会計 freeeのプロダクトマネージャーをやっております@fuji_tipです。趣味は飲酒と交互浴です。

日々プロダクトづくりをしていますと、お客さまからのプロダクトに対する要望（フィードバック）をたくさんいただきます。
私自身、月間数百件のフィードバックに目を通し、それらをやるかやらないか意思決定しております。数が多くなってくると、この処理だけで何時間もかかるようになり、ルーチン化したこの仕事は、他の緊急性・重要性の高い仕事に忙殺されてしまうと、忘れ去られてしまいます。

freee内でも各プロダクトマネージャーが、お客さまから寄せられるフィードバックを処理・管理していたのですが、下記のような状態となってしまっていました。

freeeでのフィードバック管理の現状と課題

現状

・JIRAでフィードバックを管理している
・フィードバックに対して主に行うアクションは主に下記5つで、特に1、2のアクション内容がPdMによって管理方法が違う
　1. 同種のフィードバックは何かしらの方法で、数を定量化する
　2. 新しいフィードバックは何かしらの方法でバックログ化する
　3. すでにできることは、起票者に連絡する
　4. 中身をみてフィードバックの内容がわからないものは、起票者に質問する
　5. 確実にやらないor物理的に不可能なことはやらないこととして処理する

課題

・フィードバックが多く、一つ一つ見て処理してくのが時間がかかる
・同じ趣旨のフィードバックはたくさんあるが、それらを構造化して管理できていない（それにより、下記のような課題が生まれている）
　　・開発完了後、顧客まで連絡が行えていない
　　・同種のフィードバックの定量化ができていないし、見返す際のコストが大きすぎる
・フィードバックの数も増えてきて、なかなか開発まで着手できないことから、社内全体にフラストレーションが溜まってきている
　　・情報の伝達が隅々まで行われていないことから、開発された機能の認知が足りないことも課題
・現行のフィードバック運用が、プロダクトマネージャーが少数だったときのもので、組織の拡大に合わせて進化しきれていない

フィードバックの重要性

フィードバックに対する私個人の見解は下記の通りです。

・フィードバックはユーザー課題の源泉
・プロダクトが巨大になっていくほど、ユーザーは新しい機能/改善に気づきにくくなる
・プロダクトが複雑になっていくほど、プロダクトバックログの管理や開発の意思決定は難しくなる
・同種のフィードバックでも、その理由は様々で、構造化して管理しておかないと、あとで見返すときのコストが非常に高くなる（結果、意思決定に時間がかかったり、正しい意思決定ができなかったりする）

ちゃんとフィードバック管理やるぞ

ということで、今回のゴールを「フィードバックのライフサイクルを、作って顧客に連絡するまでとする」として、フィードバック管理全体のプロセスを見直すこととしました。
ゴールを達成するために、フィードバックを開発バックログと結びつけて管理することとしました。

フィードバックを開発バックログと結びつける？
一般的にfreee内では、開発プロジェクトは常にフィードバック起点で行われるものでもなく、ビジョンドリブンで開始されるものや、販売する上での障壁になっているバックログを開発する等、様々です。
つまり、開発バックログはプロジェクト別に別途管理されていることがほとんどで、それらがフィードバックとの関連性を持っていませんでした。

そこで、実際の開発プロジェクト内の開発バックログと、フィードバックを関連付けることで、同種のフィードバックを一つのバックログにまとめて管理しようと思い立ちました。

幸い、JIRAには"リンク"という機能が存在し、これを利用することでバックログとフィードバックを結びつけて、構造化・定量化しようと思い立ちました。
こうすることにより、フィードバックの多いバックログを次の開発に載せる等の意思決定もやりやすくなるし、（後述しますが）開発が完了したら、バックログに紐付いているフィードバックの起票者に連絡を行うことができるため、お客さままで開発完了を知らせるプロセスをつくることができます。

全体プロセス

1. フィードバック起票時点で、その機能の担当者にチケットをアサイン

freeeでは、お客さまからのフィードバックをJIRAチケットとして管理しており、お客様から要望をもらったfreeeのメンバーが、専用の登録フォームから所定の項目を入力すると、JIRA上にチケットができる仕組みになっています。
フィードバック起票時、どの機能に対するフィードバックか？という項目を入力してもらうことになっているので、Automation for JIRAというJIRAの拡張機能を使って、チケット作成時に機能ごとに担当PdMにアサインするようにしました。
※Automation for JIRAについては、Eurekaさんの事例が参考になりますのでよろしければご覧ください。

2. フィードバック処理自体を、Googleスプレッドシートで行う

ここは地道にGoogle Apps Scriptを作って、下記アクションをスプレッドシート上で行えるフィードバック処理専用のGoogleスプレッドシートを作成しました。（Google Apps Scriptを書いて、JIRA APIを叩いてチケットの内容を読み込んだりしています）

1. 同種のフィードバックは、すでに作成済みの他のバックログと結びつける
2. 新しいフィードバックから、新しい開発バックログを作成する
3. すでにできることは、起票者に連絡する
4. 中身をみてフィードバックの内容がわからないものは、起票者に質問する
5. 確実にやらないor物理的に不可能なことはやらないこととして処理する

Googleスプレッドシートを利用した理由としては下記が挙げられます。

・検索性の向上
　JIRA上でのリンク操作では、フィードバックのチケットからバックログをリンクする際に、バックログチケットを思うように検索することができません。結果別タブで検索用のJIRAを開き、対象のバックログを見つけてキーをコピペする操作が必要でした。Googleスプレッドシートだと、バックログチケットをシートに読み込んだ後、ページ内検索ですぐ見つけられるので楽です。

・一瞥性の向上
　フィードバックを一瞥できるかどうか？は非常に重要な機能要件でした。フィードバック処理は、なるべく負荷が低いものから順にやっていきたい気持ちが強い（個人的感覚）ので、まずフィードバックの一覧をざっとみて、処理しやすいものから処理できることが必要でした。

・同じ操作を行うようなチケット処理の効率化
　フィードバックを一瞥していくと、同種のフィードバックがいくつもある場合があるので、その場合はただ同じ処理を行いたいのですが、JIRAだとそれができませんでした。Googleスプレッドシートの場合、処理内容をコピペするだけで済むので非常に楽です。

※非常に見づらいスクリプトではありますが、もしご興味がある方がいらっしゃれば、ご連絡いただければ公開いたします。

3. 紐づけたバックログを開発完了状態にすると、関連するフィードバックすべてが開発完了状態となり、起票者にメールが飛ぶ

これもAutomation for JIRAを利用し、開発バックログチケットを開発完了ステータスに変更するだけで、紐付いているフィードバックも同時に開発完了状態になったうえ、起票者にメールを飛ばすというプロセスをつくることができました。

結果はどうなのか

先月から回し始めたプロセスのため、まだうまく回っていないことも多いですが、取り急ぎ自身のフィードバック処理自体の負荷が非常に下がった所感はあります。
これから各チームをもっと巻き込んで、フィードバックのライフサイクルを作っていければと思います。

さて、明日は惜しまれながらもfreeeを辞めてしまった闘争エンジニア、@toshi0607がクリスマス・イブを彩ります。