ROIをもとに、機能の優先順位を判断する
――ベルフェイスでは、社員のプロダクト愛が強いことも大きな特徴だとか。
吉本：そうですね。自社の社員が日常的にプロダクトを使っている一番のユーザーですので、その結果、プロダクトへの思い入れが強くなっています。かつ顧客の声を聞き続けているため、数多くの機能改善要望が挙がってきます。
初期の頃から、社内向けのチャットツール上にプロダクトへのフィードバック用チャンネルをつくり、社員の意見を拾い上げられる体制を構築してきました。また、声を挙げやすくするための活動として、当時のセールス、カスタマーサクセスのメンバー複数名に1on1を実施もしていました。それからメンバーも増え出したタイミングでGoogleスプレッドシートや他ツールなどを用いて要望を管理するようにしていました。
とはいえ、今後も企業が成長していきさらに人数が増えることを考えると、既存の仕組みを同じように運用していくことは難しいと考えており、新たな仕組みを、石田をはじめとしたメンバーに構築してもらっているところです。
石田：いま吉本から説明があったとおり、社員が増えていき、たくさんの改善要望が出る状態になれば、全ての案を実装することは現実的に難しくなっていきます。そのため、「どのような基準で優先順位をつけているのかを可視化すること」を、私はいま目指しています。
仮に特定機能の実装が後回しになった場合、優先順位のつけ方がブラックボックスになっていれば、社員は不信感を抱いてしまいます。一方で基準が明確になっていれば「○○という理由で自分の提案した機能は優先順位が低いから、他の機能が先に実装されるのは妥当だ」と、社員も納得感を持つことができます。
――どのような方法で、優先順位を可視化していく方針でしょうか？
石田：わかりやすく、機能のROI（投資利益率）をベースに優先順位をつけることを考えています。機能を提案してくれたメンバーに「その機能によって得られる効果は5段階評価のうち何点ですか？」とヒアリングし、開発担当者にも「開発の難易度は5段階評価のうち何点ですか？」とヒアリングする。2つの指標を計算してROIを求めます。5×5の25パターンの優先順位づけが可能になるため、シンプルですが効果の高い手法です。
いきなり労力の大きいオペレーションを導入しようとすると、現場が混乱してしまいます。将来的にはデータを活用した定量的な分析手法もROIの算出に取り入れていきたいですが、それはこの手法にメンバーが慣れてからで構いません。「メンバーが継続可能な運用方法にする。最初から複雑なことをやりすぎない」という指針は、何かのオペレーションを導入する際に強く意識しています。
ユーザーを見るのではなく、ユーザーの立場“から”見る
――最後にお二人から「ベルフェイスのプロダクトマネージャーとして重要な要素」を挙げていただけますか？
吉本：個人的には「代表が何を考えて施策に取り組もうとしているのか」を解像度高く理解することが重要だと考えています。これは、単に代表に言われたものをつくる、ということではなく「代表が話していることの意図を本質的に理解し、成功確率が高そうであればその方針に沿って全力で走る。失敗の可能性が高そうであれば適切にハンドリングする」ということを意味します。
基本的に代表は、時代の一歩先ではなく三歩先や四歩先を見ています。挙がってきた意見をそのまま実装してうまくいくケースも多々ありますが、ときには「世の中がまだ追いついていないから、今すぐ取り組むと失敗する可能性が高い」アイデアもあるわけです。
そうしたときに「ユーザーはいま○○の段階ですから、現時点でその機能を出しても大半の方が使いきれない可能性が高いです」と別の方針を示せなければいけません。もちろん、そうした説明をするには適切にユーザーのことを理解できていることが大前提になります。
石田：私は「ユーザーの視点からサービスを見られるか」がとても重要であると考えます。注意していただきたいのは“ユーザーを見る”ではなく“ユーザーの視点から”だという点です。ユーザーから挙がってくる意見をただ聞くのではなく「業務のなかでどのような課題に直面しているからこそ、そうした声を発しているのか」を理解したうえで、プロダクトの機能に落としこむことが重要です。私はこれを「ユーザーを憑依させる」と呼んでいます。
メンバーにそのスキルを身につけてもらうため、定例の場でメンバーにゼロからユーザー体験を経験してもらう、通称「イタコ会議」を毎週やっているくらいです。そのくらい、ユーザーを憑依させることは良質なプロダクトを開発するうえで重要になります。メンバー全員にこの視点が身につけば、必ずより良い価値提供につながると考えています。
――ベルフェイスにおけるプロダクト開発の指針が伝わりました。ありがとうございました！
