フィードバックから考える”ちょうどいい”プロダクト品質

こんにちは。プロダクトマネージャーの齋藤です。

この記事は、estie PM Blog Weekの7日目記事です。estieのプロダクトマネージャーが持ち回りでブログを書いています。前日は難しいからこそ価値がある!不動産データへの挑戦です。

はじめに

提供中のプロダクトにおいて、お客様や社内の皆さんからフィードバックをいただけることは、とてもありがたいことです。とはいえ、プロダクトへのフィードバックは適切に管理しなければ、無限に溜まり続け、必要でないものを作ってしまったり、バックログが肥大化して、フィードバックに埋もれてしまいます。

今回は、寄せられるフィードバックから”ちょうどいい”プロダクト品質について考えてみたいと思います。

フィードバックは期待値と提供価値のギャップから生まれる

プロダクトに対して、お褒めの言葉もあれば、お叱りの言葉もありますし、機能改善の要望など様々なコメントが寄せられます。こうしたフィードバックは、ユーザの期待値とプロダクト価値のギャップによって生まれるのではないか?と考えました。

提供しているプロダクト価値が、ユーザの期待値を上回っていれば、ポジティブなフィードバックが多く、逆にユーザの期待値を下回っていれば、ネガティブなフィードバックが多いように思います。また、プロダクト全体が良い評価であっても、機能単体に対し、厳しいコメントをいただくこともあります。

  • プロダクトの提供価値>期待値 →満足度は高く、ポジティブなフィードバックが増える😄
  • プロダクトの提供価値<期待値 →満足度は低く、ネガティブなフィードバックが増える😭

フィードバックは大きく2つに分かれる

そしてフィードバックを大別すると、must have(必須)と、nice to have(あったらいいな)の2種類に分けることができます。

must have(必須)は、ユーザの不満が大きく顕在化しており、解消されないと、サービスの解約や離脱を招きます。プロダクトマネージャーとしては内容を即座に判断し、影響を勘案しながら、何かしらの対策を取った方がよいものです。

nice to have(あったらいいな)は、期待や希望が含まれており、対応すれば、特定ユーザの満足度が高まりやすいものです。プロダクト価値において致命的ではないものがほとんどです。プロダクトマネージャーは、価値につながるものを分別しながら、対応するのかしないのか、どうやるのか、いつやるのかなど、総合的に判断していきます。

狩野モデル(品質モデル)で整理してみる

これらフィードバックは、どのようなユーザ体験の時に発生するのか、狩野モデルで整理してみます。

参考:狩野モデル - Wikipedia

狩野モデル(かのうモデル)は、顧客満足度に影響を与える製品やサービスの品質要素を分類し、それぞれの特徴を記述したモデルである。1980年代に東京理科大学教授であった狩野紀昭によって提唱された。マーケティングや品質管理の分野に対して多大な影響を与えたモデルであり、世界的にはKano Modelとして知られる

プロダクトは、ある機能を提供した結果、顧客の反応が生まれます。 このとき、プロダクト価値がユーザの期待する魅力的品質を満たしていれば、ポジティブなフィードバックが増え、プロダクト価値が当たり前品質に達していなければ、ネガティブなフィードバックが増える傾向にあると思います。普通の品質を満たしていれば、それほど大きな価値と期待値を超えることがないため、サプライズのフィードバックは少ないように思います。

以下の図は、及川さんの記事にフィードバックの質をマッピングしたものです。

及川卓也「ソフトウェア開発は『狩野モデル』で“品質の本質”を見直せ」

早く出すべきか、作り込んでからリリースするべきか?

プロダクト開発において「早く出すべきか、作り込んでから出すべきか」というジレンマが常に存在します。これはトレードオフスライダー(QCDS:Quality, Cost, Delivery, Scope/Service)の問題として有名です。QCDSすべてを良い条件にした状態で、プロダクト開発を進めることは現実的に難しいものです。

トレードオフスライダー

出典:インセプションデッキ(日本語版)

blank-inception-deck1-ja.pdf

機能や品質を最小限にして、早く出すメリットは、素早く価値検証ができて、アジャイルに改善ができることでしょう。またヒットしなかった時の価値転換も素早く行えます。最小すぎて、必要十分な価値を提供できていない可能性もあります。

逆にある程度の機能や品質を作り込んでから出すメリットは、ユーザの満足度は高い状態から始めることができますが、本当に必要じゃない機能を作ってしまったり、過剰な品質実装になってしまうリスクもあります。そして、作り込み過ぎたことにより、本当に伝えたい機能が埋もれてしまう可能性もあります。

作り込みの品質は、何点を目指すべきか?

機能が少なすぎても価値検証ができなくなってしまうため、一定の作り込みは必要です。とはいえ、作り込み過ぎても、無駄なものを提供していたり、時間がかかってしまった結果、ビジネス機会を逃してしまうことがあります。

では、作り込みの品質は、何点を目指すのが現実的でしょうか?

理想的なバランスは、「まずは60点の品質基準を目指してものづくりを進めて、その後70〜80点まで素早く継続的改善をしていくこと」だと思います。作り込みが80点を超えてくると、それ以上の品質を高めていくには、1点に対する時間が掛かりすぎて、労力とリターンが合わなくなってきます。仕事のアウトプットと同じように、完璧を目指しても、一定以上の品質は大差なくなっていきます。

仕事は60点でいい!100点を目指さない決定的な2つの理由!!

まとめ:フィードバックの質をコントロールしよう

フィードバックは、プロダクトを使い続けるユーザがいる限り増え続けます。無くなることはありません。

しかし、フィードバックの質は、コントロール可能です。

プロダクトマネージャーがトレードオフスライダーのバランスをうまくコントロールしてリリースしていくことで、ポジティブなフィードバックを増やし、ネガティブなフィードバックを減らすこともできます。デリバリーと品質のバランスを選択しながら、価値を作れるかが腕の見せどころです。

早く出すか、作り込むか、プロダクトチームで会話しながら、目の前にあるフィードバックに向き合いつつ、最高のプロダクト価値を届けましょう!

estieでは、プロダクトマネージャーを募集中です。ぜひカジュアル面談しましょう。

hrmos.co

また、estieの雰囲気が知りたい方は定期的にイベントを開催していますので、ご参加ください。

estie.connpass.com

© 2019- estie, inc.