開発優先度をどう判断して、意思決定の理由をどう説明していますか？
森口貴之氏：よろしくお願いいたします。最初に、この登壇のタイトル自体も、「その意思決定、説明できますか？」という質問形式だったのですが、プロダクトマネージャーのみなさんに質問です。プロダクトマネージャーが頻繁に行う意思決定である、優先度の判断について、次に取りかかる施策の優先度をみなさんはどのように判断されていますか？
例えば、目標とするKPIに対してどのようなインパクトがあるかを試算したり、緊急度と重要度のマトリクスを考えたり、セールスチームと相談して、温度感が高いものから手をつけるなど、会社やチームの状況に応じていろいろな方法で決められていると思います。
一方で、プロダクトマネージャーが決めた優先度に対して、例えば上司やほかの部署からその意思決定の理由を質問されることも多いかなと思います。
ほかの部署から、要望やこういったことをやってほしいという期待がある中で、要望があった機能の優先度を低く判断した場合、丁寧に説明を行う必要があると思います。もしそこでドライな対応をしてしまうと、その部署からの信頼を失ってしまうことにもなりかねません。
こうした部署が1つであれば説明等々も丁寧に対応しきれるのですが、これが複数存在することも多々あると思います。場合によっては、ステークホルダー間の板挟みの問題になることもあると思います。
このように、説明をすることの難易度、時間的、精神的なコストが高いということがプロダクトマネージャーの業務が難しくなる1つの要因になっていると思います。
板挟み問題が起きやすいプロダクトマネージャーという職務
ここで一度、プロダクトマネージャーの役割を振り返ってみようと思います。プロダクトマネージャーの役割は、経営戦略や事業戦略に基づきながら、その目的の達成のためにプロダクトを前に進めて進化させていくことだと思います。
その中では、プロダクト開発の中心となって、つまり、プロダクト開発のハブとなってプロダクトマネージャーが立ち振る舞うことが必要だと思います。
多様なステークホルダーとコミュニケーションのプロトコルを変えながらやり取りしていく必要があり、その際には説明も多く発生します。各ステークホルダーとの関係値の構築や、それらのコミュニケーション力がPM（プロダクトマネージャー）に求められるのも、こうした構造上の職務要求によるものかなと考えています。
また、先ほども少し触れましたが、板挟みという状況も発生しやすいかなと思います。開発チームと、次に開発する機能を会話するタイミングで、例えばセールスチームから、「次は、こういうターゲットカスタマーがいて、こういう要望があるんだよ」というように要望がどっさり来ることもよくある話ではないでしょうか。
優先度の話であればシンプルですが、別の機能のユーザー体験や重要な指標を毀損してしまうような要求も時折発生するかなと思います。
今回は、登壇のタイトルを「その意思決定、説明できますか？」と題して準備してきました。テーマとして、意思決定を説明しやすくすることや、板挟みによる問題を減らしたい、という思いからお話ししていこうと思います。
そして、PMが本来やるべきことに対して割くための時間が少しでも増えればと思っています。
スマートバンク社・プロダクトマネージャーの森口氏
簡単に自己紹介をさせてください。今、スマートバンクでプロダクトマネージャーをやっている森口と申します。これまでのキャリアとしては、toC向けのプロダクトを中心に、新卒から10年ちょっとほど、ずっとプロダクトマネジメントを行ってきました。
現職のスマートバンクには2021年に入社して、今は2年半ほどずっとプロダクトマネジメントを担当している状況です。
現職のスマートバンクでは、「B/43」というFinTechのプロダクトを開発しています。B/43は、チャージ式のVisaカードと家計簿の管理を組み合わせたアプリで、Visaカードの決済履歴が家計簿としてリアルタイムに自動で記録されます。使いすぎを誰でも簡単に把握できるというところで便利で使っていただいている感じです。
2022年の「Google Play」の「生活お役立ち部門」カテゴリーで大賞もいただいています。B/43は、プロダクトのローンチからもうすぐ3年が経ちます。現在は、30名を少し超える組織で開発を行っています。
冒頭で「優先度をどうやって決めるか？」という質問から、プロダクトマネージャーがコンフリクトの罠に陥りやすいことをお話ししてきました。
今日はこの後、コンフリクトの罠を抜けるために、視点についての距離感をヒントに、説明のしやすい状況をどうやって作るかについてお話しします。
そして、意思決定の判断軸を作るために、どういったことを意識すべきかという点で、プロダクトマネージャーならではの観点からお話ししようと思っています。
最後に時間があれば、おまけの話をちょっと準備してきたので、そちらもお話できればなというかたちで本日は進めていきます。
コンフリクトは近視眼から生まれる
最初に、コンフリクトを受けやすい状況からどのように抜け出すかというところを考えていきます。
先ほどお話ししたとおり、プロダクトマネージャーは、その職種の特性上、ステークホルダーの間に挟まれるハブのような立場に立っています。単純にプロダクトマネージャーは対面する相手が多いのでコンフリクトの発生回数も多いです。
また、意思決定したことを説明する際に、ステークホルダーごとにどういったところを重要とみなすかの要素が異なってくるので、板挟みになりやすい状況です。
私は、意思決定する時に、一つひとつの意思決定の判断の理由を考えるのではなく、その手前の、決めたことをどうやって説明しやすくするかという観点で考えています。
コンフリクトというのは、得てして、近視眼から生まれてしまうことが多いかなと思っています。物事を決める時に、「今この瞬間どちらに行くべきか？」という、今にフォーカスするかたちで都度考えてしまうと、それらをステークホルダーに説明する際に、場当たり的になってしまいやすいかなと思います。
近視眼的な意思決定は、コンフリクトを生みやすく、あるステークホルダーには納得してもらえても、別のステークホルダーには、その理由を納得してもらえないという状況が起こりやすいかなと思っています。
先ほどから、「説明しやすい」みたいなところをキーワードにちょっとお話ししているのですが、説明しやすい状況を作るために、個別の意思決定の理由を練って考えるのではなく、意思決定の軸というか、意思決定をする時の判断軸をしっかり持つことが重要になると思います。
例えば、意見が対立する、コンフリクトする状態でも、たいていの場合、例えば事業やプロダクトの成功みたいな、ちょっと遠い観点で見ると、ステークホルダーとの目的は擦り合うことが多いと思います。
つまり、判断軸として、遠くにある共通のゴールの認識をまず擦り合わせることを意識しています。意思決定する時に、このタイミング、直近のAかBかというかたちではなく、「○○を目指したいからCです」というような判断、説明をするイメージで捉えています。
“遠くのゴール”の具体例
遠くのゴールと申し上げていますが、どういうものがあるか具体例をちょっと持ってきました。
1つは、プロダクトや事業が目指す、こうなりたいという理想状態、目指す姿ですね。2つ目は、KPIなど事業計画の目標になる指標みたいな数字。または、その会社における行動規範やバリューと言われるようなもの。こういったものが挙げられるかなと思っています。
我々はプロダクトマネージャーなので、遠くのゴールを語るのであれば、中長期的にそのプロダクトがどういった状況を目指すか、いわゆるプロダクトビジョンみたいなものを描いて社内でコミュニケーションを取っていくのが適切かなと思います。
どういった機能のアセットを備えているのか、全体としてプロダクトが提供する価値はどういったものか、どういった体験を提供していくか。
例えば、こういったものについてスマートバンクでは、「Figma」を使って、2、3年かけて目指したい具体的なビジョンや機能のアセットみたいなものを描いて共有しています。
この後、実際にプロダクトビジョンを語って共有していくために、どのようなことを意識する必要があるかを考えていこうと思います。
まず、絶対に必要な点として、担当するプロダクトをどういった状態に持っていきたいか、明確な意志を示すことが重要だと思います。
2つ目。掲げたプロダクトビジョンが完成形ではなくて、組織の意識や組織の考えを取り入れながら、組織全体の考えを反映させたものにしていくことが大事かなと思っています。
3つ目は、そこで作り上げられたビジョン、共有されたビジョンを、組織の上位のゴールとして、上から逆算的に考えることが大事かなと思っています。
トップダウンと書いていますが、組織的な上意下達みたいなものを意味するものではなくて、ビジョンから逆算して、ビジョンから考えていくという意味で捉えていただければと思います。
プロダクトビジョンをチームや組織に共有できていますか？
1つ目ですが、みなさんは、プロダクトをどういった状態に持っていきたいかをチームや組織に共有できていますか？ どのような機能のアセットがあって、ユーザー体験やプロダクトが全体的にどういった価値を提供するのか。そういった定義を行えていることが望ましいと思います。
遠くのゴールとして、みんなで目指すゴールとしてプロダクトがどこへ向かうのかをまず示す必要があります。
先ほども簡単に紹介しましたが、スマートバンクではFigmaなどを用いて、実際に数年かけて目指す機能のアセットみたいなものをビジュアル化しています。モザイクをかけていて恐縮ですが、こういったかたちでFigmaで誰でも見られるかたちになっています。
社内から自由にアクセス可能になっていて、例えば他部署のメンバーに手元で見てもらいながら、直接プロダクトの開発やその部署の開発に関係するものではなくても、今後の計画について、こういったビジョンを考慮に入れて検討されているという議論も行われています。
ビジュアルだけではなくて、その提供価値をドキュメントとして言語化して共有するのも、もちろん良いと思っています。
ビジョンを明確にして提示していくというところですが、意思決定というのは、本質的にトレードオフだと思っています。「右に行こう」という判断をしたとすると、それはつまり左へ行くことを諦めるということだと思っています。
意思決定を行う背景として、その意思決定をするのに必要な情報が出揃っていればいいのですが、たいていの場合、情報が出揃っていないことが多く、やってみないとわからない状況で判断を求められることが多いのかなと思っています。
意思決定をするだけでも、難しい中でやらないといけないのですが、プロダクトビジョンを作って共有するのは、さらに不確実だったり、完全な正解であるとはとても言えない状況になるかなと思っています。
そのため、プロダクトビジョンを最初に示すのには、プロダクトマネージャーの勇気や覚悟が必要になると思いますが、この勇気が、組織でビジョンを共有する上で絶対に必要な大事な一歩になると思っています。
プロダクトビジョンに組織全体の考えを取り入れる
そして、そのビジョンに対して、プロダクトマネージャー1人の考えだけではなく、組織としてどう考えるかという意見を取り入れていくことが、すごく重要かなと思います。
プロダクトマネージャーだけの意見だと独りよがりになってしまうので、まず提示して、たたき台として組織全体が考えていることを尊重しながら取り入れていくというスタンスが取れればなと思います。
ここで少し、信頼についてお話ししておくと、信頼というのは、相手やステークホルダーが持っている期待値とその結果のギャップが少ない状態かなと思っています。
それは、「あいつに言えばこれをやってくれる」「あのPMに言えばこれを実装してくれる」みたいなことではなくて、「あのPMはこういうふうに考えているから、きっとこれをお願いするとこう判断するだろうな」みたいな認識を作っていけると良いかなと思っています。
ビジョンの上位ゴールから逆算して判断できるようにする
3つ目ですが、先ほども言ったとおり、トップダウンというのは、上司の命令を受け入れるという組織構造的なことを指しているわけではありません。意思決定においては、「今この状況をどういうふうに判断するか？」ということをやってしまいがちかなと思います。
一方で、ビジョンが共有されているということは、ゴールに向かってどのように進むと最短でビジョンが実現できるかについて考えられるという状況です。そのため、近視眼的な意思決定ではなく、トップダウンの意味は、ビジョンの上位ゴールから逆算して判断できるようにするということです。
プロダクトビジョンについて逆算的に考えたり、議論したりという癖が身につくことで、必然的に遠くや上位のゴールについて考えられます。それが視座や視野の獲得にもつながっていくかなと思います。
まとめ
いったんここまでのまとめです。ハブ的な立ち位置としてPMは立たされているため、コンフリクトが発生しやすい状況に身を置いています。その状況で、その場しのぎ的な近視眼的な意思決定をやってしまうと、「一方には説明できても、全方向には無理」みたいなかたちで、説明しきれない状況になりやすいです。
コンフリクトを回避するためには、遠くのゴールを共有することが大事だということをお伝えしました。
そして、プロダクトビジョンに組織の考えを反映して、そこから逆算的に考えるトップダウン的な思考を、その意思決定の判断軸とすることで、ふだんの意思決定がぶれないようにできるかなと思っています。
これが、プロダクトマネージャーとしての信頼や、視座の獲得にもつながっていくかなと思います。
ビジョンを共有することで、意思決定をPMに依存させない状態を作ることができる
少し時間がありそうなので、おまけのコンテンツにも触れようかなと思います。ここからは、私自身が実践できているわけではなく、今回この登壇の機会でこのテーマについて考える中で、ちょっと考えが深まってきて新しく出てきたアイデアです。
これ自体が今、現状私の中でうまくワークしているわけではありませんが、ちょっとおまけ的にAppendixとしてお話ししようと思います。
例えば、ビジョンが共有されてプロダクトマネージャーの意思決定がぶれない状態、つまり、ステークホルダーが期待する、「あのプロダクトマネージャーならこう考えるだろうな」みたいな予想と、実際のPMの判断の結果がずれなくなったとします。
その場合、プロダクトマネージャーが一つひとつ判断しなくてもいいのでは、つまり、もともとの期待とだいたい同じものが返ってくるのであれば、判断を依頼する必要がどんどん減っていくんじゃないかなと思いました。
ステークホルダー間でもコンフリクトを生まずに判断ができるようになるかもしれません。
つまり、ビジョンがうまく共有されている状態を作れると、プロダクトマネージャーが意思決定に関与する回数が減らせるんじゃないか。そして、組織としてより前線に立っている、そのことについて毎回向き合っている人が高速に判断しやすい状況にできるんじゃないかと思いました。
本に触れられる時間がなさそうですが、これは『OODA LOOP』という本の中で最も効果的と言われる、暗黙の誘導とか暗黙の統制とか、いわゆる判断をショートカットする状態と近いのかなと思います。
『OODA LOOP』の書籍の中では、「大部分の意思決定は暗黙的であり、かつ、そうであるべきだ。暗黙的な意思決定であるべき」と主張されています。つまり、ビジョンが共有されることでショートカットできて、それが速さ、アジリティみたいなものが生まれて競争力につながると解釈をしました。
プロダクトマネージャー＝決めてくれる人、みたいなこともよく言われますが、今の話を踏まえると、これは古い考え方になっていくのかもしれないなと思います。
ビジョンを共有することで、最終的には、その意思決定をPMに依存させない状態を作ることができるかなと思います。私個人的には、PMによる意思決定が必ずしも必要ではないと思っています。
組織としてスピードを持って自分たちで決められるようなチームや、自分たちで決められる組織を意識していこうと思います。
ということで、最後は、おまけの部分で脱線してしまいましたが、今一度お伝えしたかったメッセージを振り返ってみると、覚悟を持ってビジョンを共有して、プロダクトマネージャーが抱えやすいコンフリクトの罠を抜け出せというところをお伝えさせてください。
これで本日のお話は以上です。聞いていただいてありがとうございました。
