“ただバックログを消化するだけ”のチームを変えるための根回し術

コミュニケーション連載の最終回です。1回目では上司と、2回目はチームと、3回目は部下とのコミュニケーションについて書いてきました。最終回ではその総集編として、コミュニケーションが一番難しいが重要な「本当にやるべきこと」を進めるコミュニケーション術について書いて連載を終えようと思います。

• keyboard_arrow_down 1. はじめに：なぜこの話を書くのか
• keyboard_arrow_down 2. なぜ「本来やるべきこと」は避けられるのか
• keyboard_arrow_down 3. 社内の壁を乗り越える前の準備
• keyboard_arrow_down 4. 承認を得るためのコミュニケーション術
• keyboard_arrow_down 5. “失敗”しても、それは前進
• keyboard_arrow_down 6. おわりに：ヒリヒリする挑戦が、あなたを育てる

プロダクト開発の現場では、どうしても短期の課題に追われがちです。ユーザーの声、社内の要望、締切の迫ったタスク——毎日が「目の前の対応」で埋まっていきます。その結果、プロダクトの連続的な改善は進むものの、プロダクトの目指す姿に向けた大きな前進が後回しになりがちです。そうやって成長が鈍化することに苦しむプロダクトを多く見てきました。

難しいですが、限られたリソースで「もっと数字に貢献できる課題はないか？」「ユーザーにとって価値ある体験とは何か？」と問い続けることもプロダクトマネージャーの大切な仕事です。そして、こうしたテーマに取り組むのは、実行の難しさだけでなく、“社内の共感を得る難しさ”とも向き合うことになります。

次に、どうして目を向けるべき中長期的なチャレンジの優先度が上がらないのか紐解いていきましょう。

そもそも、チャレンジすべき！という発想がない

プロダクトマネジメントの支援をするなかで、中長期的なチャレンジの優先度が上がらない原因として一番多いのはそもそも「チャレンジすべき！という発想がない」ことに見えます。目の前の顧客要望を捌いていくのがプロダクトチームの仕事になっているパターンです。「ビジョンから逆算して仕事をつくっていきましょう」というと「それは私の仕事なんでしょうか。」と不安な顔をされてしまいます。

私はいつもジュニアプロダクトマネージャーのスキルアップに伴走するときに以下2つのマイルストーンを用意します。

プロダクトマネージャーの成長STEP
マイルストーン1： ユーザーの顕在化している課題を解決できること
マイルストーン2： ユーザーがまだ気づいていない課題を見つけ、解決して数字に貢献できること

目の前の顧客要望の解決ができるようになったなら、ぜひ次のレベルにチャレンジしてみてください。

目の前のタスクよりも難易度が圧倒的に高い

2つ目の理由はシンプルです。目の前の顧客要望を解決することに比べて、新しく課題を見つけ、その課題が本当に解決すべきか判断し、顧客要望がまだない中で解決策を考えるのは難易度が高いからです。

人はどうしても確実なものを優先してしまいます。「バックログは山積みなのに仕事を増やすの？」「数字が出る保証はあるの？」という指摘を受けながらも、本来やるべきチャレンジに向き合うには強い心が必要です。チャレンジを繰り返して自分たちにとって確実だと思える領域を増やしていきましょう。

今回の記事は「コミュニケーション」を主軸に書いてほしいという依頼を受けておりますので、ここからは「本来やるべきこと」の見つけ方ではなく「社内での壁の超え方」について記載をします。「本来やるべきこと」を探索するためには別の記事をご参考ください。（参考: 16時間でプロダクトに自信が持てるドリル💪 ※1.5万字）

「本来やるべきこと」を見つけたとき、その一大プロジェクトを進める前の準備が必要です。プロジェクトを立ち上げる前にしておいた方が良いことを3つ紹介します。

信頼貯金とチャレンジの粒度を見極める

まず、本当に実施する価値のあるチャレンジなのか、見極めましょう。

シンプルに言うと、コストよりリターンが大きいことを確認しましょう。開発にかかる工数はきちんと算出して考慮されることが多い一方で、チームの合意を取るコストは見逃されがちです。そして、合意を取るコストの大きさは自分がどれだけ多くの信頼貯金残高を持っているかにも左右されます。

合意を取るコストに比べてリターンが明らかに小さい場合は実施すべきではありません。これは諦めるという意味ではありません。プロジェクトを分解して小さな合意コストで進められるような仮説検証にしたほうがよいということです。いきなり大きな開発工数を使うような変更をするのではなく、その根拠となる数字やユーザーの声を、どうすれば小さい工数で集めることができるのかを考えましょう。

WILLを固める：誰のせいでもなく、自分の意思であること

次に、その挑戦はあなたのWILLであることを認識しましょう。誰のせいにもできません。

顧客要望がある課題に取り組むときや、トップダウンに降りてくる機能実装とは異なります。この4回の連載のほぼすべてで言い続けていることですが、自分で説明責任を果たし、最後までオーナーシップを持って走り続けると腹を括りましょう。（参考: 第1回「何でも決めたがる上司から権限をつかみ取るプロダクトマネージャーのコミュニケーション術」）

なぜ何度も書くかというと、これができないプロダクトマネージャーを多く見てきたからです。

自分でWILLを持つこと、そのWILLに責任を持って推進することをせずに、社内調整ばかりやっている人は2つ目の章で述べたマイルストーン1までしか達成していない半人前です。放棄せずに最後までやり遂げられる人は、たとえそれがうまく行かなかったとしても必ず大きな成長をします。

フィードバックを受け止める力を育てる

WILLを固めることが重要であり、1人で100点の成果物を出せなくて構わないと思っています。

たたき台を出すのがプロダクトマネージャーの仕事です。そして、たたき台なので未完成であるのは当然です。

1人でたたき台ではなく完成できるスーパーマンならチームのレビューも不要と考えるかもしれません。でも、それはつまり、一緒にプロダクトをつくるメンバーにタスクだけを渡し、その通りに遂行してほしいということになります。例えばエンジニアには開発だけを求めるということです。社内受託のような状態になるでしょう。内製チームがあって、開発にもプロダクトの議論に積極的に参加してほしいなら積極的にたたき台を出して意見をもらいましょう。

しかし、フィードバックを素直に受け止めるのは難しいことがあります。

頭ではわかっていても、批判とフィードバックの区別がつかずうまく咀嚼できず、批判されているような気持ちになってしまうときもあります。「どうしてこの仕様はこうなんですか？」「ここは検討されていますか？」という純粋な質問でさえ、「XXを考えきれていないからダメだ」という批判コメントに聞こえます。

まわりの人はあなたを攻撃したいのではなく、あなたのアイデアの成功確率を上げる仲間だということを胸に刻んで心が傷つかないようにしてください。フィードバックをくれる人に素直に「ありがとう」を伝えましょう。失敗するより事前に失敗の芽を摘むほうがずっと賢いことを忘れないでくださいね。

驚かせない。根回しは“気持ちの準備”

突然の提案は、どんなに正しくても拒否されやすいものです。

重要なのは突然“驚かせない”ことです。特に、目の前の顧客要望の優先度を下げて、新しいことを始めたいなんて提案をいきなりされると、短期的に起きる問題ばかりが頭に浮かんでしまいます。

一番良くないのは「突然、よくわからない案件が差し込まれた！」と思われることです。「根回し」というとごますりや裏工作のような悪いイメージを持たれるかもしれませんが、気軽な相談でいいのです。「もしかするとユーザーはこうすると喜ぶのでは？と思いついたんですがどう思います？」とカジュアルに相談できる関係を常日頃からつくっておきましょう。

形式ばった説明を準備しなくとも同僚をランチに誘って、その場で相談をしてみましょう。相手の時間を使うことに抵抗があるかもしれませんが、一緒に働く相手からランチに誘われたり、頼られることは喜ばれるものです。肩肘張った説明ではなく、「最近こういうことを考えているんです」と日々伝えておきましょう。

ワクワクとリスクの両輪で語る

良いところだけを説明されると、どうしても「本当だろうか？」と疑う気持ちが出てしまうものです。

承認を得たいがために、良い面だけを説明してリスクを隠してしまいたくもなりますが、リスクもきちんと考慮したうえでメリットが上回ると考え尽くしていることをアピールしましょう。

承認を得てプロジェクトとして開始するということは、主語が「私/I」から「私たち/We」に変わることです。1人で背負わないで、チームみんなでリスクを理解したうえで、よりよい方法を模索するのが理想です。

また、良いところを語るときは、ロジカルなメリットはもちろんですが一緒にワクワクできる状態をめざしましょう。プロダクトが改善することでユーザーは何ができるようになり、それがどんなゴールをもたらすのか、それがプロダクトビジョンにどう貢献するのかを自分が油田となって色んな人にガソリンを注ぎ込んでいくイメージで熱意を持って語りましょう。

上司の信頼を借りる工夫

自分ひとりでは始められないと感じるときは、当たり前のことですが上司を頼りましょう。

「プロダクトマネージャーはプロダクトに関する意思決定権限を持つべき」という理想を目指した結果、どうも上司を頼らないプロダクトマネージャーが多いように感じます。プロダクトマネージャーとその上司は一般的な上司部下の関係ではなく、どうしても抽象と具体の綱引きをしたり、トップダウンとボトムアップの間に立って調整をしあう関係になってしまったりして、素直に頼ることが難しいこともあるようです。

しかし、上司は上司なので、プロダクトマネージャーが仕事をしやすい環境を整えることが仕事です。プロダクトマネージャーのレイヤーからの変革がしづらくとも、上司のレイヤーからトップダウンに意思決定済みの案件として落としてもらったほうがうまくいくこともあります。特に、プロダクトの中長期に関するチャレンジは事業全体に関係する話題なので上司にあたる方と二人三脚で進める体制が望ましいです。うまく甘えてみましょう。

しかしながら、「本来やるべきこと」へのGOが組織で出せないこともあります。

GOサインがもらえなかったとしても、重要なのはその経験から学び、次の挑戦に活かすことです。自分の最初のアイデアに愛着があればあるほど、悲しい気持ちになることもあるかもしれませんが、その気持ちをバネに、そして失敗を受け入れられる自分を誇りに思ってもう一度チャレンジしてみてください。

その挑戦は「小さく失敗をして、成功に近づく」という仮説検証のカルチャーを醸成します。

ただ、もしその頓挫した理由に納得できないならもう少しふりかえってみましょう。私はプロダクトの意思決定は連鎖していると考えています。「仮説のミルフィーユ」と呼んでいる下の図にあるように、Core/Why/What/Howのそれぞれの階層の意思決定の良さを定義するのは、1つ上の階層だと考えています。

このCore/Why/What/Howの社内事情を読み取って、もし納得感のない階層が見つかったら、その1つ上の階層を担当しているチームと話してみることをおすすめします。自分を過小評価せず、自分が4つの階層すべてに納得感を持って意思決定できるように議論をしておきましょう。

私はプロダクトをつくる仕事はヒリヒリするものだと思っています。

私が間違えると、プロダクトチームのみんなが納得感を持ってやりがいのある仕事ができなくなるかもしれません。社内だけではなく、多くのユーザーにご不便をおかけしてしまうこともあります。そのプレッシャーは私にとってヒリヒリするものです。

しかし、ヒリヒリするようになったのは実はここ最近のことです。

プロダクトマネージャー1年目のときは、自分のプライドばっかりで、自分のことばかり考えていました。会社の貴重なお金を使って仮説検証をしていることの実感もなく、自分が考え尽くせていないと何が起きるかわかっていませんでした。

ヒリヒリできるようになったのは、失敗を重ねたからです。

失敗をして、他の人の人生の大切な時間を無駄にしてしまったことを心の底から後悔しました。私があのとき、もっと考え尽くしていれば、根回しをして経営を味方につけていれば、データをしっかりと分析していたら。たくさん失敗をしてその繰り返しで成功もできるようになったこと、多くの方に助けていただいたこと、勇気をもって打席に立ってフルスイングしたことが自分の成長に繋がりました。

それから部下を持ち、クライアントのプロダクトマネージャーの伴走をするようになって、ヒリヒリしている人としていない人を見比べる機会が増えました。そして、残念なことにヒリヒリしている人のほうが必ずしも評価されているわけではないことに気づきました。ヒリヒリしていない人のほうがコミュニケーションがうまく行っているように見えたり、チームからの評価が高かったりするのです。

プロダクトを良くするために考え抜いている人ほど、直前のインタビュー結果をもとに突然の仕様変更を提案したり、チームにとって驚きのあるコミュニケーションを取ったりして、「仕事を増やしてくる人」という不本意な評価をされることがあります。

しかし、プロダクトマネジメントに向き合うチームなら全員が理解しているとおり、ただタスクを完了させても、ユーザーが価値を感じなければそのタスクを完了させた意味はありません。プロダクトをより良くするには、ヒリヒリしながら「もっといい案はないか？」を考え続けなければなりません。社内で議論をしている時間はコストです。少しでも早く価値を届けるコミュニケーションを上手に工夫しましょう。

この4回の連載が、変化を恐れずプロダクトがもっと良くなるための前向きな力となることを願っています。

プロダクトマネージャーという職種はチームに1人しかいなく、時に心細くなることもあるでしょう。私はそんな方の支えになる存在でありたく、お困りの際はSlackコミュニティ「プロダクト筋トレ」にお越しください。

最後までお読みいただき、ありがとうございました。