どうも、Backlogチームの金です。
自社で開発提供しているサービス・プロダクト（以下プロダクト）には、毎日さまざまな要望が届くと思います。
本記事では、ユーザーからの要望をもとにプロダクトを改善するときに、どういうことが重要で、気をつけるべき点は何かを整理してみました。
先日「プロダクトマネージャー・カンファレンス」に参加したので、そこで良いなと思った内容も取り込んでいます。
※タイトルは美人百花さんを意識しました。
目次
はじめに
要望について語り出すと、プロダクト開発からチームコミュニケーションまで、話題が多岐にわたるので、あらかじめ本記事で書くこと・書かないことを定義しておきます。
書きたいこと
プロダクトの機能を改善したり追加するときに重要なこと、気をつけること
書かないこと
誰が何やるべきかとかどうコミュニケーションするかとか、開発方法とか
なぜ改善するのか土台を固める
さて、なぜプロダクトを改善する必要があるのでしょうか？
プロダクトを改善することについてシンプルに表現してみると
“現在のユーザー”や”未来のユーザー”にプロダクトを通してより良い体験をしてもらうため
と、言えます。
シンプルですが、現在のユーザーと未来のユーザーどちらが求めるものを重視するべきかはプロダクトの置かれている状況によって変わり、バランスを取ることはとても難しいものです。
また、それぞれの”ユーザー”もひとかたまりではなく多くの属性をもったユーザーの集まりに別れます。
それぞれのユーザーの好みや習慣が異なるため、良かれと思って何かを改善、追加したとしても、あるユーザによっては意味がない、むしろマイナスだと感じることがあります。確実にあります。
全員の要望に答えることは出来ないですし、全員を満足させる機能や仕様もありません。
なので、
プロダクトが持っている社会的なミッション（長期スパンで実現）や、リアルなビジネス上の戦略（短期的な目標）をおさえた上で、”なぜやるのか”、”それを通して何を実現したいのか”という土台をしっかり固めておくことが重要
と言わせてください。これを明確にすることで、何を作るべきか、どう作るべきか迷ったときに立ち返る場所になります。
Backlogの場合
ちなみにBacklogのミッションステートメントには
「チームではたらくすべての人」のためのプロジェクト管理ツールを提供し、 誰もが笑顔ではたらくことができ、成功するチームを世界中に増やします。
というものがあり、”なぜやるのか”に対する答えが明確に定まっています。
また、Backlogのビジネスは複数プランがある継続課金モデルなので、末永くユーザーに愛してもらう（上位プランを使ってもらって）というのも、より良い体験を作っていく理由となります。
何をもとに改善するのか整理する
やることを決めるにあたって、入力となる要望はたくさんあり、また決めるためのパラメータもたくさんあります。
入力となる要望には以下の3点が挙げられます。
- ユーザーからの直接的な要望（問い合わせ、SNS上のつぶやき、ユーザーインタビューなど）
- データ分析から浮かび上がる潜在的な要望（現在のユーザ志向）
- マーケットチームや経営戦略としてのビジネス的な要望（未来のユーザー志向）
やることを決めるためのパラメータは以下の3点です。
- 開発にかかるリソース（どれくらいの人数と期間が必要か、対応するチームが組めるか）
- どれくらい嬉しいのか（ユーザーの体験として、ビジネス的価値として）
- それらをどれくらい確信しているか（プロトタイプやABテストなど前後での検証が必要か）
以上のパラメータを言い換えると、コスト、メリット、精度といったものが関わってくると言えます。
対応するタスクの順番を決める
以上に挙げた複数の要素をもとに、対応するタスクの順番を決めていきます。
大きな機能や多くの開発リソースが必要なものは期間と人員を見込んだ上で、いつごろ対応するかを決めロードマップとします。
これだけでも要素が多く悩ましいのですが、新しい要望は次から次へと入ってくるので、小さなものは柔軟に素早く対応する必要があります。
これらの要望を、日々アップデート可能で共有可能な優先順位の付いたリストで管理します。
この時の注意点として
目先の声に対応することだけに終始してもいけないし、かといって大きく時間がかかることだけやっていてもユーザー体験の向上が継続的に得られない。バランスを取ることが重要
というのが挙げられます。
また、何が要望として入ってきて、それぞれどう位置づけられて、現在何を対応しているのか、またこれらを共有（可視化）する、ということがプロダクトに関わる人にとって重要です。
ユーザーに対してどう見せるかというのも考える必要があります（後述）。
細かな仕様を決めるのに他人の視点を導入する
細かな仕様が原因となって、本来意図した体験が得られないことも多くあります。
仕様を考える人はその機能について知り尽くしている人間であるため、ユーザーのペルソナとしてはだいぶ偏っています。
初めてその機能を見た人（未来のユーザー）でも迷いなく使えるUI/操作フローなのか遠くから引いた目で見る必要があります。また、可能なら実際にいろいろなユーザーに使い勝手についてヒアリングすることも重要です。
開発に時間がかからないものであれば、リリースを優先し、後に調整するというのも可能です。
しかし、本格的な開発に入る前に、プロトタイプや評価に必要なミニマムな実装（MVP）を触ってもらうといった「検証」をすることはリスクを減らし、トータルコスト抑えるのに必要です。
ベータユーザーとの関係性を普段から作っておく
そのために、カスタマーサクセスを通していち早く機能を試してもらう、招待制の環境でbeta機能を先に試してもらうなど、気軽にテストしてもらえるユーザーとの関係（チャンネル）を作っておくことが重要です。
招待されたbetaユーザーさんとのやり取り
また、仕様を決める過程でこちらを満足させるとこちらが満足できないという選択肢が発生し、どれかを選ばないといけない場面も出てきます。
Backlogのデザインを一新したときにも、スッキリしたデザインを取るのか、デザインとしてはちょっとマイナスだけど古いディスプレイでも見やすくするのかという選択が発生しました。
そういった場合には、前述のなぜそれをやるのかに立ち返りどちらを優先すべきか決めていきます。Backlogの場合は幅広いユーザーさんに楽しく使っていただきたいので苦痛になる要素を取り除く方向で選択しました。（※詳しくはBacklog UI リニューアルの舞台裏で紹介しています）
作っておしまいにせず継続して調整する
当然ですが、要望から作るものを作ってプロダクトとして出して終わりにはなりません。機能にもライフサイクルがあります。
プロダクトのライフサイクル
リリースしたことで満足しがちになるのですが、リリースしたものを運用して実際に狙い通りの効果が得られているか計測し、効果が得られていないなら何が原因か調べ、狙った効果が発揮されるように修正していくプロセスがとても重要です。
リリースしたけど認知されていないからなのか、認知されてるけど期待と違う挙動なのか、トラブルが発生していてうまく使えないのかetc…
続けて新しいものを作るより、作ったもののリリース後のフォローをきちんとして、最大限に活かすところに力を入れる方が少ないコストで大きなリターンを得られます。
少しの調整で利用率が上がることもあるので、ここをきちんとプロセスとしてやる方が良いかと思います。
このリリース後のフォロープロセスがないと、狙いが外れた機能を閉じることが出来ず、無駄にメンテナンスコストを払い続けることになります。関わる人員やサーバーなどのリソースが開放されないことで新しく別のものを作ることが出来ないのはとても勿体ないことです。
ユーザーの期待をケアする
リリース後のフォローに関わりますが、期待する機能を待ってるユーザーに、確実にリリースを知らせて、使ってもらうことも大切です。
そして重要なのが、リリースされたものが期待と違ったユーザーに対しても、理由を丁寧に説明するということです。
具体的には、どうして自分たちはそういう機能として提供したか、どういうことを大切に考えてのことか、そしてどう使ってもらいたいか、というメセージを届けることです。
万人が満足する仕様も個別の設定やパーソナライズによって実現できるかもしれません。
しかし、プロダクトの方向性に関わる部分では妥協せずに、こうしていくというメッセージをはっきり出すことでよりユーザーに愛されるプロダクトとなるのではないでしょうか。
ユーザーからの要望の管理や扱い方を明示する
またリリースされない機能や受け取った要望がどう扱われているか、期待する機能がいつ頃実現されそうかを共有（可視化）することも大切です。
粒度によって可視化の方法も異なり、大きいものはプロダクトロードマップとして、小さいものは優先順位のついた改善リストとして共有されていると安心できます。
重要なことは、どういった表現方法を使うかではなく、どういった基準で、何を優先して対応し、何の優先順位が低いかを共有することです。
共有・可視化イメージ
ユーザーからの要望で、対応する予定がないもの、優先度が低いものは、それをユーザーに的確に伝えましょう。
曖昧にしておくのは、ユーザーが自分たちの抱えている問題を解決するのにより適した別のサービスを使う機会を奪うため、誠実ではありません。
何を開発するか決めるのって難しい
何を作るか、狙いや仕様まで含めて決める工程は、開発の前の工程なのでここを決めないと実際の開発工程には進めません。
そして、開発工程はリソースがかかるので投資と同じで狙いが外れたときにリターンが十分得られないというリスクがその決定には含まれます。
さらに、ユーザーからの要望はお互いに衝突することも多いので一貫性を保つため仕様の調整や、利用状況の調査など時間がかかるものもあります。どれから開発するべきか、優先順位をつけるのもとても難しいです。
決める部分を特定の人に集約することで、一貫性を保てたり、リスクヘッジにつながったりすることも多いです。
しかし、プロダクトの規模が大きくなると機能の数も開発規模も大きくなりがちで、ここを決める工程がボトルネックになります。
事前にチーム内で判断基準のすり合わせが大切
そこで、開発の規模に応じた権限の委譲や、委譲にあたってどういう判断基準なのか認識をすり合わせることが重要です。
今回はどうチームワークするかとかそういうのは書かないと決めたので書きません。
でも、少しだけ。
認識のすり合わせについては事例ごとに判断基準を共有しましょう。細かい体験に関わる部分はドキュメント化が難しいですが、こう感じるという事例の積み重ねで共通感覚をつくるのが良いと思います。
なお、この辺りのチームワークに関する考察は以下の記事などが参考になるかと思います。
おわりに
日々届く要望にふりまわされずにプロダクトが目指す方向を示し、ユーザーを愛し愛され共にプロダクトを育てていく、そんなプロダクトを中心とした良い関係がつくれたら最高ですね。
