第23章 現在の製品を改善する
改善とは機能を追加することではない
できあがってしまった製品の開発を続けるという話になると、多くのプロダクトマネージャーは、何をすればいいのかわからないでいる。たいていは、詳細な製品ロードマップがあって、そこには、製品開発チームが追加したいと思っているあらゆる機能のすばらしいアイデアが示されている。あるいは、ロードマップには、特定の顧客からの「もしこの製品を買ってほしいなら、次の 6つの機能を追加してもらいたい・・・」というような要求で埋め尽くされている。
ソフトウェア製品を開発する会社というのは、基本的に機能を作り出す工場である (ところどころでバグの修正もやるけれど)。彼らの頭の中には、機能を追加することしかない。
でも、機能を追加することは、結果的に状況を悪くするだけで、何の改善にもならないことがあまりにも多い。そこで、私は、製品開発チームには、製品の改善を違う角度からアプローチしてもらうように心がけている。
製品の改善は、新しく製品を開発する場合と同じように、何を達成しようとしているのかをよく理解するところからすべてが始まる。たとえば、保険会社のプロダクトマネージャーが、オンラインでの保険の新規申込みを担当しているとしよう。
このとき、いろんな種類の数値を測定して推移を見ていく必要がある。申込み手続きの開始画面にアクセスしたユーザーは何人か？ 手続きの途中、それぞれのページで何人のユーザーが挫折したか？ 個人情報の入力を拒否したユーザーは何人か？ 電子メールのアドレスを確認してくれたユーザーは何人か？ 申込み手続きを完了したユーザーは何人か？
仮に、今日、登録手続きを始めた人の中で、実際に手続きを完了したのは 7% しかいなかったとしよう。もしこれを 15% まで上げることができれば、その製品を見事に改善して、会社に多大な貢献をしたことになる。
この目標を達成するためには、もしかしたら、新しい機能が必要だという判断になるかもしれない。その機能追加が妥当かどうかは、それによって、上で挙げたような数値をどれくらい改善できるか次第である。
ユーザーエクスペリエンスにも改善できるところがあるはずだ。たとえば、申込みの段階では、思っているほどには、ユーザーに細かい個人情報を入力してもらう必要はないかもしれない。あるいは、なぜこの情報を入力する必要があるのかについて、説明が十分ではないのかもしれない。あるいは、ユーザーは、この会社にこういうデータを出して大丈夫なのか、と迷っているのかもしれない。
プロダクトマネージャーとしての仕事は、こういういろいろな数値とにらめっこすることなのだ。毎日、数字を改善するために何ができるか、と自問自答するのだ。そして、インタラクションデザイナー、ユーザーリサーチャー、主任エンジニアといっしょになって、どこをどう改善できるか知恵を絞ろう。
何が起きているかを深く理解するのにいちばんいい方法は、サイト分析をしっかりやることと、現実のユーザーで製品を試すことだ。また、ネットプロモータースコア (顧客満足度を表す指標) の追跡データ、顧客サービス部門や営業部門からの情報、Win/Loss 分析の結果などのデータも集めることになるだろう。
こういう方法で製品を改善すると、時として大きく報われることもある。特に、インターネットサービスの場合はそうだ。というのは、ほとんどリアルタイムでたくさんのデータを入手できるので、それらが即、自分たちの製品のアイデアに対するフィードバックとなるのだ。そういうデータから学んだことを実行に移せば、どれほど素早く劇的にビジネスの改善につながるか、驚かされることだろう。
一部の顧客が追加を望んでいる機能であるとか、調査結果だからとか、フォーカスグループがそう言っている、というような話ではないことを忘れないでほしい。大切なのは、製品の出来を表す数値を狙った方向に動かしてくれるのは何であるか、ということだ。
だから、今ある製品を改善しようとするなら、主観的なフィードバックを集めてしまう、顧客を誘導してまでどうしてほしいかを聞き出す、新たな機能を追加しようとする、といった罠にはまってはいけない。そうではなくて、製品の利用実態を調べて、指標となる数字をあるべき姿に持っていくことで、そうした数値の改善を徹底的に追求することに集中しなければならないなのだ。
参考事例
プロトタイプテストで質問する内容の具体例は、次のウェブページで閲覧できる。www.svpg.com/examples
Inspired日本語版 