「伝言ゲーム」で疲弊しないために。職種間の壁をぶち破るコミュニケーション術

前回の記事では上司とプロダクトマネージャーの関係を取り扱いました。今日は、プロダクトマネージャーの他職種連携についてです。

• keyboard_arrow_down 大変！プロダクトマネージャーの「のり」現象
• keyboard_arrow_down プロダクトマネージャーとしての役割ではなく、プロダクトチームのあり方を考える
• keyboard_arrow_down 理想のプロダクトチームをつくる5つの要素

プロダクトマネージャーがとても頑張っているのに、組織の溝がどんどん拡がっていく。そんなときはプロダクトマネージャーの頑張る方向を見直してみてもいいかもしれません。

教科書には「プロダクトマネージャーは、ビジネス、UX、Techの交差領域である」と書いてあります。その交差領域をとりまく各専門職との関係を結びつける糊（のり）になっていろんな部門の間を飛び回っていませんか？このようになってしまうとプロダクトマネージャー以外の職種の掛け合わせが生まれなくなってしまいます。

少し前に「プロダクトマネージャーの持つべきスキル」だとか、「プロダクトマネージャーの役割とは？」といった議論が盛んでした。正直なところ、私はプロダクトマネージャーの個人としてのあり方を考えることにあまり意味はないと思っています。プロダクトマネージャーの仕事はプロダクトを成功させることであり、そのために必要な仕事はひとりではできません。ひとりで抱え込んでひとりで何でもしようとはせず、プロダクトチームみんなの仕事としてプロダクトマネジメントを担い、その旗振り役として現場にいるメンバーの誰がどこを担うのが最も良いのかを議論するほうが本質的です。

では、理想のプロダクトチームとはどんなものでしょうか？
私は以下の5つが揃っていることだと思います。このあと私にとっての理想のプロダクトチームについて書きますが、プロダクトチームの良さは企業のカルチャーやプロダクトのフェーズによっても異なるはずですので、私のものをたたき台にしてみなさんにとっての理想を考えるのにご利用くださいね。

それぞれについて解説していきます。

① 専門領域が掛け合わさっている

すべてプロダクトマネージャーが決めてその通りに実装することを望む規模なら、外注で十分だと思います。最近は生成AIの性能も向上してきましたし、ひとりで生成AIのパワードスーツを着てすべて実行することも可能でしょう。
しかしながら、「早く行きたければひとりで、遠くへ行きたければみんなで行け」です。
プロダクトチームがいるなら、自分だけのアイデアではなくプロダクトチーム全員の専門性をそれぞれ発揮して自分の発想にはないところまで行くことを目指しましょう。プロダクトマネージャーひとりが、ビジネス、UX、Techのすべての専門性を持つ必要はないのです。

💡 コミュニケーションのヒント
・ 期待を明確にして、ふりかえる
専門性を掛け合わす状態を目指すためには、まず「掛け合わせしたいです！」と大きな声でいいましょう。あなたが何を理想として、何のために動いているかを伝えることが理想に向かう第一歩です。これを言わずにコミュニケーションプロトコルに手を加えようとすると、保守的などこかのマネージャーに突然ちゃぶ台を返されることが起きがちです。
そして、あなたが理想としている状態への移行をひとりでやろうとせず、関係者全員でやりましょう。理想とする状態は全員で同じなのか？その状態に向けて、いまどんな問題があるのか、その問題にどうアプローチすればいいのか。1つずつ取り組んで、定期的にふりかえる時間をもちましょう。

・ 固定値と変数を分けて相談する
とはいえ、全員を集めて「掛け合わせたいです！問題について話し合いましょう！」と言っても議論が盛り上がらないこともあるかもしれません。コミュニケーションについて手を出す前に必要なのは、まず「最近掛け合わさってないと思うんですよねぇ」と課題を感じていることを口に出せる関係性の構築です。大きな会議でのコミュニケーションではなく、常日頃からそういった相談がカジュアルにできる関係性を保ちましょう。
そして、相談をするときには何が動かせない固定値で、何がこれから動かせる変数なのかを分けて相談しましょう。つまり、「うちのチームなんかうまく行ってないと思うんです」と変数を大きくして相談するのか、「うちのチームなんかうまく行ってないと思うんです。そのために、各部のコミュニケーションを密にしたいのですが、どうすればいいと思いますか？」と解決すべき課題を固定値にして、その解決策を変数として相談するのかの違いです。多くの人と相談をすることになるため、有限な時間の中で有意義な議論ができるようにしましょう。

・ みんなで考えるイベントを持つ
専門領域が掛け合わさっていない問題について考える会議を持つのもいいですが、もしかすると「プロダクトをもっと良くするために何をするべきか考える会議」を持つことで結果として専門領域が掛け合わさる第一歩になることもあります。
例えば過去には、メンバーごとに想定しているユーザーのメインのユースケースにズレがあり議論がうまくいかないことが増えたので、異職種でペアをつくり、それぞれにユーザーのカスタマージャーニーを体験してもらうワークを実施しました。それぞれに「〇〇シチュエーションでプロダクトを使って××のゴールを達成してください」と書かれたくじを引いてもらい、それぞれユーザーとして体験後にそこで感じた便利だったところ、不便だったところを発表してもらいました。そして、その解決策を職種を超えて議論してバックログに追加するというワークです。

② ユーザーが主語にあり、本質的な問いに向かっている

「私はこの案がいいと思います」「いいえ、私はあちらの案が良いです」と、理由を述べず結果だけで話すと多数決以外に決める根拠がなくなります。私は経営会議で「前の案のほうが好みだった」と言われたときに「あなたはターゲットユーザーですか？」と真顔で聞き返して場を凍らせたことがあります。当時は好みで意思決定をされる状況にイライラしていましたが、今は単純に私の力不足だったと分かります。実際にユーザーがどういう意見を持っているのかの調査結果を以て、どうして新しい案が優れているのかを伝えるべきでした。

💡 コミュニケーションのヒント
・ ユーザーのファクトを理解する
転職してきてすぐのプロダクトマネージャーはまだ意思決定ができる状態ではありません。ユーザーを理解して、意思決定のものさしをつくる必要があり、そのためには多くのユーザーに会う必要があります。それと同じことがプロダクトマネージャー以外の多職種にも起こり得ます。同じチームで働いているので同じ量の情報が得られていると勘違いしてしまいますが、それぞれ職種ごとに見ているユーザーが異なります。例えば、開発者は不具合報告をするエンドユーザー、CXは問い合わせをする窓口となるユーザー、営業は導入意思決定者となるユーザーを見ているような場合、それぞれユーザーといった時に想像するものが異なります。事実としてユーザーが何を言っているかを資産として溜め、全員がユーザーがどんな人で何を求めているのかの共通認識が持てるようにしましょう。

・ 定期的に一次情報に触れる機会を持つ
今までコミュニケーションに苦労していたが、一度ユーザーインタビューに出てもらってから魔法のように言葉が通じるようになった！という経験を聞くのは一度や二度ではありません。インタビュー結果をまとめたドキュメントにも価値はありますが、やはり一度生身のユーザーの声を聞くことはモチベーションにもつながりますし、ユーザーを主語にして考えるマインドセットに切り替わる効果があります。職種を問わず、普段仕事で対面しないユーザーと話す場を持つことはとても大切です。

・ evilな振る舞いを許さない
ユーザーのためにならない、短期的な利益を追うような施策は必ず社内に軋轢を生みます。例えば、法的にグレーなことをする、品質や安全基準を守らない、お金を稼ぐためにユーザー体験を毀損するなどです。プロダクトに携わることに誇りを持っていられなくなると、疑心暗鬼になり、他責になり、チーム間のコミュニケーションがどんどん悪い方に進んでいきます。プロダクトマネージャーとして全員が誇りを持てるプロダクトの成長を描くことには責任を持ちたいです。

③ 「良さの定義」が揃っている

組織が大きくなるにつれて、いろんな視点のメンバーが増えてきます。営業と開発の間で溝が生まれている状態の会社に呼んでいただくと「彼らは何も分かっていない」「彼らはあまり優秀ではない」などと強い言葉での批判を耳にしますが、対立は同じレベルでしか起きないというのはよく言ったものだと思います。多くの場合、そのどちらもが言っていることは正しいのです。ただ、良さの定義が異なり、別の良さに向かって成長しようとしているだけです。
これは、営業と開発のような部門間での問題に留まりません。「せっかくアイデアを提案してもあの上司は自分の意見に固執するばかりで取り入れない」とか、「隣の部のPOは、うちの部のために必要な機能をいつまで経ってもつくってくれない」などの問題も本質は同じです。

💡コミュニケーションのヒント
・ ビジョンのワクワクを伝える
分かりあえないときは、仮説の階段を登りましょう。どの機能が良いか？を合意できないなら、その機能をなぜ作るのかは合意できるか。それも合意できないなら、ユーザーが誰かは合意できるか。ユーザーが誰かが合意できないならビジョンは合意しているか。
ビジョンから合意できないのであれば、残念ですが1つのチームとしてやっていける相手ではありません。プロダクトを分割するか、ビジョンを1つに定めるのか、トップが判断する必要があります。
多くの場合、この階段のどこかで合意できるポイントがあるはずです。合意できないときこそビジョンに立ち返ること、ネガティブになりそうなときこそどうしてそのビジョンにワクワクできるかを語ることで問題の本質に立ち返り同じ「良さの定義」をものさしにすることができます。

・ 他職種のゴールを知る
一番良くないのは「彼らは何も分かっていない」と批判することです。同じ会社の同僚が理解不能な行動をしているときは、会社のためにも止めてあげてください。そして、そのためには目の前でやっていることではなく、どうしてその行動をするのか、他者のゴールは何であるのかを理解しましょう。それを理解せずに「止めなさい」と言うのはリスペクトがありません。
他職種のゴールを理解して、それを自分の専門性をかけ合わせるとどううまくゴールを達成できるのかサポートしてあげましょう。それの繰り返しにより良好な関係を築くことができます。

・ ユーザーが誰で、価値提案が何なのかぶらさない
誰が言っていることも間違っていません。きっと、スープには里芋をいれても美味しいし、ラー油を入れても美味しいし、トマトソースを入れても美味しいですが、全部をいれると美味しくないです。職種間でのコミュニケーションがうまくいかないとき、組織の問題ではなく事業として今から作ろうとしているのが芋煮なのかミネストローネなのかという重要な意思決定を経営ができていないことに起因する状況をいくつか見たことがあります。私たちが作ろうとしているものは何なのか？という難しい意思決定を先延ばしにせず、ただのスープではなくミネストローネであると解像度を上げること、そして同じゴールを全員で共有して向かうことがコミュニケーションの解決策になります。

④ 今向かうべき問いに群がっている

「良さの定義」が揃っているチームでも「今」「次」「未来」のタイムラインが揃っていないこともあります。この状態では、常に「プロダクトをよくするには？」という大きな問いに向き合うことになり、抽象的な議論が続いてしまったり、五月雨式に色々な課題を対処してユーザーへのメッセージがちぐはぐになりがちです。
「今はどういう時期でどんなものの優先度が高いのか」を伝えましょう。プロダクトを良くするためにするべきことは無限にありますが、その中で現在優先度が高いのはどんなものなのか、それは何なのかを伝えることで、考えやすくなります。

💡 コミュニケーションのヒント
・ KPIとその根拠を伝える
今期の目標としている数値は何なのかを各職種につたえましょう。ときどき、エンジニアは事業数字で評価しないというカルチャーではエンジニアが事業数値をしらないという話を聞きます。評価とプロダクトの目標は切り離して考えてください。プロダクトの目標やKPIは、私たちがつくるプロダクトがうまく行っているか、行っていないかを何で測るかを決めたものです。この指標を知らない状態では、いま何について意見を出すことが求められているのかも分かりません。そして、ただ「継続率を上げます」ではなくて、どうして今継続率に向き合う必要があるのか、達成できないと何が起きるのかを伝えましょう。

・ ロードマップを自分ごと化する
プロダクトチーム全員でプロダクトの成功を自分ごと化して考えるために、私はロードマップに全員が納得することが必要不可欠だと思っています。そのために、現場と経営を巻き込んで下図のような3本線のロードマップを作ることにしています。事業サイドがみている数字と、それを目指すための戦略、その戦略にあったプロダクトの機能がブレることなく議論できることが重要です。（詳細: ロードマップに機能を書くべからず）

この3本線がうまくリンクしている組織はコミュニケーションがうまく行っています。事業ロードマップとプロダクトロードマップ、開発ロードマップをそれぞれが作るのではなく、紐づきがあるものにしましょう。

⑤ 意思決定の背景が明らかである

プロダクトチームの健全な議論を妨げるものに不透明性があります。誰がどういう背景で意思決定をしているのかわからなければ、どうして自分が正しいと思うものが却下されるのか納得できず、誰に何を話しても無駄だと思われてしまいます。反対に意思決定の背景まで理解しておけば、同じ軸を以て行動することができるようになります。

💡 コミュニケーションのヒント
・ 組織構造をみんなで知る
一度、大きめの会社で働いているときに勉強会でプロダクトチームに向けて組織構造とステークホルダーを紹介する資料を共有したところ、想像以上に大変好評でした。私からすると、日々相対している経営や隣のチームの意思決定者であるので、他のメンバーも同様に知っているのかと思ってしまいましたが、プロダクトチームメンバーは全くチームの外側にどんな人がいて、どんな利害関係で動いているのか知らなかったのです。会社が大きい場合にはどんなゴールを持ったご近所さんがいるのかを伝えるのもいいでしょう。

・ 大きな意思決定については伝える場を持つ
また、私はAll Hands Meeting（全体集会を格好良く言ったもの）が好きでよく実施しています。目標設定の時期に合わせて定期的に実施することが多く、プロダクト開発のリズムもつくることができます。また、この場で大事にしているのは質問や議論の時間です。例えばプロダクトとして次のフェーズに移るとき、上手に伝えなければ今のフェーズで向き合っているユーザーを蔑ろにして別のユーザーを優先するように伝わってしまい、ユーザーとの距離が近いメンバーほど恐怖を感じることもあります。伝えたつもりにならないために、何を決めてその背景は何なのかをしっかり伝え、議論をする時間があると齟齬が生まれづらいです。
また、職種を超えて全員で集まる機会があるだけでもコミュニケーションはスムーズになります。

以上が、私が思う理想のプロダクトチームと、それに向かうコミュニケーションのヒントです。ぜひ、みなさんがどんなプロダクトチームを目指したいのかについても議論をしてみていただけると嬉しいです。

本連載は全4回で、今回が第2回になります。残りの回もどうぞよろしくお願いいたします。