プロダクトマネージャーの意思決定ロジックの可視化

こちらはGLOBIS Advent Calendar 2020の10日目の記事です。

グロービスには今年の6月にジョインし、早いもので半年が経過しました。現在は特定のプロダクトのPMというより、プロダクトの裏側を整える系のプロジェクトをいくつか動かしています。

そんな私は、社内で「可視化おじさん」と名乗っております。

以前の記事でプロダクトマネージャー（以下PM）がキャッチアップする際に「様々な構造の可視化が大事だよ」と書きました。実際にそれを実践してどんどん可視化しまくった結果、お褒めのお言葉をいただくことが多かったので、調子に乗って名乗ってみました。

というわけで、次に可視化おじさんが可視化を試みようとしているのは「PMの意思決定ロジック」です。この記事では、PMの意思決定ロジックの可視化によるメリットなどを書いていきます。

プロダクトマネージャーの意思決定とは

PMは様々な種類の意思決定をする必要があります。そこには抽象度の高いもの（プロダクト価値の定義やプロダクト戦略など）や、具体性の高いもの（機能の取捨選択や優先度など）があり、この具体と抽象を常に反復横飛びして意思決定し続けなければいけません。

また、この様々な抽象度の意思決定たちは相互に繋がっています。

例えば抽象度の高いプロダクトビジョンを立てたら、それをより具体に落とし込んでプロダクト戦略を立案し、さらに具体に落とし込んで数値目標（KPI）を定義し、次にそのKPIを達成するためにインサイトを捉えてユーザーストーリーを定義するという抽象的な思考を働かせる必要があります。

つまり、一連の意思決定のインプットとアウトプットの抽象度が異なるのです。

このインプットとアウトプットの間には、意思決定ロジックが存在します。ここで言う意思決定ロジックとは「何の情報を基に決めたのか」、逆に「何の情報を使わなかったのか」、そして「どのようなロジックでそのインプットを基にアウトプットを作り上げたのか」を指します。まあプログラムと同じですね。

もちろん意思決定ロジックが異なれば、インプットが同じでもアウトプットは変わります。
 

インとアウトの両方とも具体性が高ければ、意思決定ロジックは比較的単純になります。例えば「アクティブユーザーN人というKPIを達成するために、登録導線を改善しCVR向上に注力する」という意思決定のロジックはそれなりに単純で、GAのデータとユーザーインタビュー結果あたりから原因を特定して改善を決め、逆にそれ以外の情報は意思決定に利用する必要がないと判断するロジックになります。

一方でPMのインとアウトの抽象度が異なる意思決定においては、この意思決定ロジックがかなり複雑になります。インが抽象的でアウトが具体的な場合、例えば「プロダクトに新しい価値として『学習を継続できる』を増やしたいので、マイページをリニューアルする」となった場合、「え、なんでそうなったん？(´･ε･`)」ってなりますよね。実際には「学習を継続するためにはこういうカスタマージャーニーの中で、こういうジョブを解決する必要があることがユーザーインタビューからわかり、さらに現状のマイページにはこれを解決するための機能を実装する上で技術的ハードルがあり…」みたいなめちゃくちゃ複雑なロジックが存在します。こういうケースにおいて、どの情報をどのように使って意思決定ロジックを組み立てるかがPMの腕の見せ所です。

なので複雑になりがちなこの意思決定ロジックを可視化してチームにインストールしようぜという話なのですが、そもそも何故その必要があるのかを次に書きます。

意思決定ロジックがブラックボックスになると何に困るのか？

メンバーやステークホルダーが、インプット発生時にアウトプットの予想できなくなります。つまり何か変化が起こった際、例えば「競合の強力なキャンペーンに対抗する必要が出てきた」という複数の対策（＝アウトプット）を推測できるインプットに対して、PMの意思決定が完全に終わるまでアウトプットの全貌が読めなくなります。また出てきたアウトプットだけ見ても、それがどういうロジックで組み立てられたのか分からないので、メンバーやステークホルダーはそれを理解しようと頑張るところから始まります。

そうなると単純にスピードも遅くなりますし、メンバーやステークホルダーによるフィードバックは一度組み立て終わったアウトプットに対してしかぶつけられないので、意思決定ロジックの問題点に気づきにくくなります。そうなると最悪の場合リリースしてから問題が発覚してしまうかもしれません。

もちろんこれは日々のコミュニケーションでカバーすることも可能です。小さい組織であれば、わざわざ可視化する必要もないかもしれません。またメンバーやステークホルダーのフィードバックを必要としないプロダクト開発現場（請負外注など）も同様です。しかしある程度大きい組織になると常に全員と密にコミュニケーションが取れる訳でもないのでコミュニケーションに依存するのは危険と言えますし、アジャイル開発においてはメンバーやステークホルダーのフィードバックが重要になるため、この問題点は看過できません。

意思決定ロジックを可視化してチームにインストールすると何が嬉しいのか？

スピードが速くなる

インプットが発生した時に、意思決定ロジックがチームにインストールされていれば、アウトプットが出る前に全員がある程度の方向性をイメージできます。仮にPMが忙しくてちゃんとしたPRDやPBIなどのアウトプットにまとめられていなくても、既に議論できる土壌が整っているのですぐ開発に進める可能性が高まります。もちろんじっくり検討や検証が必要なケースはその限りではないですが、早く捌けるものを早く捌くことで、時間を割くべき意思決定にPMのリソースを割くことができます。

チェック機能が働く

意思決定ロジックが完璧なPMなど存在しません。時には間違えます。人間だもの。

メンバーやステークホルダーとPMの間には必ず情報の非対称性があります。カスタマーサクセスはPMよりもユーザーの声を聞いていますし、エンジニアはPMよりも技術的な課題を知っています。それらの知見を集約して意思決定ロジックをチェックすることで、PMが組み立てた意思決定ロジックをより良いものにできる可能性が上がります。もちろん全員の声を反映する必要はなく、意見を取り入れない判断もアリですが、その理由を論理的に説明できないのであれば、まだまだ意思決定ロジックが不十分であるとわかります。

属人性を排除できる

可視化をして何度もチームやステークホルダーに説明しているうちに、その意思決定ロジックが周りにインストールされます。そうなると、PMがいなくなっても同質の意思決定ができるようになります。極端に言えばPMが不要になります。でもそれで同じアウトプットが出せるのならPMなんていなくていいと思います。 逆にPMがいないと何も決められない状態の方が危険です。

もしかするとここに心理的ハードルがあるかもしれません。意思決定がPMの存在理由だとすれば、ここをブラックボックスにした方が自分の強い存在価値になるので、可視化を避けたくなる心理が働くかもしれません。ただそうなるとPMのキャパシティとスキルが、そのチームの限界とほぼイコールになってしまいます。チームの成長とプロダクトの成長を願うなら、勇気を出して属人性を排除すべきです。

どのようにして可視化してチームにインストールするのか？

インプット情報の可視化

まず意思決定をする上でのインプット情報を可視化する必要があります。ただ、さすがに意思決定に使う情報全ての可視化は不可能です。なので今後意思決定をしていく中で頻繁に根拠にしそうな情報を選んで丁寧に可視化します。インタビュー結果のローデータとかブレインストーミング結果のホワイトボードの写真とかをただ共有するだけだと伝わるわけがないし説明しづらいので、しっかり体系化して情報をまとめる必要があります。読みやすさめっちゃ大事です。

ポイントは「まとめた過程」も可視化しておくことです。

ぼかしが強くて何だかわからないと思いますが、これはペルソナ定義をまとめた時の図です。弊社のプロダクトの法人顧客の幅はかなり広いのですが、規模や業種、課題の種類など「顧客属性の変数」を単純に掛け算でパターン化すると、14,580通りにもなってしまいます。最終的に5パターンに単純化したのですが、その過程で残した変数と捨てた変数、そしてその理由もここに記載しています。これなら後で見て「なぜこういうまとめ方になったのか」を思い出せますし、メンバーやステークホルダーも理解しやすいです。また思い通りの結果が出なかった時に振り返って改善することも容易になります。逆にこういう風にまとめてないと絶対に忘れてしまい、ここに問題点があるかどうかのチェックすら怠ってしまうリスクがあります。

ロジックの可視化とチームへのインストール

意思決定の結果としてのアウトプットにはプロダクトロードマップやPRD、PBIなど、色々な粒度のものがあります。どのアウトプットにも共通して「何のインプット情報を基にしたのか」「それらをどう組み合わせたのか」を記載する必要があります。密にコミュニケーションが取れるチームにおいては、プロダクトバックログリファインメントの場などでしっかり説明できれば、わざわざ記載しなくていいかもしれません。とにかくチームやステークホルダーにしっかりロジックを理解してもらう必要があります。アウトプットを理解されるだけでは不十分です。

自分のやり方は、PBIを記載するチケット（Jiraとか）に根拠となったインプット情報のキャプチャを貼りまくるやり方です。GAのグラフやユーザーインタビュー結果をまとめた図式、今期の戦略の概要図などです。これらの元ネタは全員アクセスできる場所にあるので、インプット情報の詳細を知りたい場合はすぐに確認できます。これをある程度繰り返して、インプット情報がメンバー全員の共通理解となったら（＝インストールされたら）省略が可能になりましたが、そうなるまでは多少手間がかかってでも徹底してやっていました。

もちろんリファインメントの場などで「そのロジックおかしくないですか？」と言われることもあります。これは上述の通り意思決定ロジックを磨き上げるチャンスなので大歓迎なのですが、可視化してないとメンバーのロジック理解度が低い状態での指摘になるので、無駄な説明や議論が増えてしまいます。80~100%ぐらい理解してもらってからだと、鋭い指摘を貰えることが多くなります。

あと最後に重要なポイントを。「わからないことはわからないと言う」です。意思決定ロジックを可視化すると、整合性の取れていない箇所や矛盾にすぐに気づくことができます。その場合、まだロジックを組み立てるインプット情報が足りないのであれば、そのように説明すべきです。自分もよく「今の時点ではわかんねえから根拠ないっす！直感です！！（俺を信じてくれ！）」と開き直っていました。検証して新たにインプット情報を得られたらまた組み立て直せばいいのです。そのためのアジャイル開発です。

最終的に目指すところとは…？

ここまで意思決定ロジックを可視化してチームにインストールしていくことをオススメしてきましたが、一つ大きな問題があります。それは「可視化しんどい」です。何かアウトプットを作る度にロジックを可視化するのはやっぱりしんどいです。ただ、ある程度可視化と説明によるインストールを繰り返していくと、いつの間にか可視化しなくてもロジックが「よしなに」伝わるようになると思います。最終的にはここを目指していきたい。

つまりタックマンモデルでいえば「形成期」と「混乱期」において可視化は "コスト＜効果" となるため有効に働き、その結果「統一期」に入ったら徐々に  "コスト＞効果" となるため、頻度を減らしていってもいいと思います。

引用元：https://toyokeizai.net/articles/-/117979?page=2

ただこの可視化とインストールのステップを飛ばしていきなり「よしなに」状態を目指すのは危険だと思うので、まだ「統一期」に入っていない組織のPMは多少しんどくても頑張りましょう。

終わりに

「意思決定はPMの重要な責務なのだから、しっかり自分一人でやりきらなきゃ…！」と思っていませんか？もちろんその心意気は大事なのですが、だからといって一人で抱え込む必要はありません。一人でできることなんてたかが知れています。可視化して仲間にチェックしてもらえる状態を作ることで、個人としてもチームとしても成長できると思っています。

自分はまだジョインして6ヶ月なので、自分がどういう思考回路なのかを知ってもらっているとは全く言えません。なので積極的に頭の中を可視化＆開示していって、息を吐くように意見を言ってもらえるような関係性を構築していきたいと思っています。