何でも決めたがる上司から権限をつかみ取るプロダクトマネージャーのコミュニケーション術

プロダクトマネージャーからよく聞くお悩みがあります。

「プロダクトチームで決めたことが、創業者CEOからよくわからない理由でひっくり返されてしまいます」
「わたしはプロダクトマネージャーという肩書ですが、実質的に意思決定をしているのは上司です」
「CEOが忙しすぎて、大きな課題は寝かせてとりあえず目の前の課題に注力しています」

大企業からスタートアップまで、上司から権限を受け取れない状況は多くあるようです。私も何度もこういった状況を経験しました。ときには「会社から私に期待されている仕事の範囲を超えているならやらなくていい」とドライに捉えてみたり、「権限を委譲したがらない上司が悪い」とビールを片手に愚痴ってみたり。1人の中間管理職経験者として、この状況を打破するヒントについて考えてみようと思います。

• keyboard_arrow_down 私の理想: スキルによる組織の天井をぶっ壊せ
• keyboard_arrow_down どうして権限を渡せないのか？
• keyboard_arrow_down 権限をもらうための練習
• keyboard_arrow_down 権限をもらうためのコミュニケーション
• keyboard_arrow_down これは部下の仕事でしょうか。いいえ、上司の仕事です

先日、デンマークでKAOSPILOTという団体の「Creative Leadership」というコースを受講しました。このコースでは1人がクリエイティブになるのではなく、チーム全体がクリエイティブになるためのマインドセットを学びました。
私は自分のチームはやるべきことの全体図を色塗りするような形ではなく、各々のスキルを掛け合わせるようなチームをつくりたいと考えており、co-creativeという共にクリエイティブであることを目指す考え方は大変勉強になりました。

この記事でコースの詳細は語りませんが、上司と部下の関係性においても上司が目指す方針に対して部下はそれをより良く肉付けしていくような働き方ができると理想だと考えます。事業が小さいうちは誰か1人がすべて把握し、こだわり抜くことができます。そうやってこだわり抜いた細部にこそ神が宿り、事業成長に貢献することも多々あるでしょう。

しかしながら、事業が大きくなるにつれて1人だけの力では管理できなくなります。1人の限界が事業の成長を決めてしまうことになり、この後の事業成長を左右するのは強い組織と目指す世界を共に支え実現する専門性を持ったリーダーたちです。

きっと誰もが誰か1人ですべてを管理することはできず、分業したほうがよいことは分かっています。しかしながら、頭で分かっていながらも、きちんと権限を委譲できず働きづらい状況を生んでしまいます。自分の目の届く範囲や、自分のスキルとして見える範囲が組織の上限になってしまうことを強く恐れる私でさえ、「わたしはプロダクトマネージャーという肩書ですが、実質的に意思決定をしているのは上司です」という思いを部下にさせたことがある自覚があります。

本来、1人の上司としての私の仕事は部下が働きやすく、能力を最大限に発揮できる環境を整えることですので、私は上司失格でした。権限を渡せなかった経験を思い返すと、大きく以下の3つの原因があったように思います。

1. フィードバックが伝わらない

部下の意思決定をレビューする際に、いくつか質問やフィードバックをすることがあります。そして、このレビューの場でのコミュニケーションがうまくいかなくなると、部下が叩きをつくるより自分でつくったほうが早いとなってしまい、上司が部下の権限を奪いはじめます。
レビューの場で絶対にやらないでほしいのは、分かっていないのに「分かりました」と言うことです。伝えたつもりのことが反映されないのは最も信頼貯金を失います。フィードバックをうまく伝えられないのは上司側が悪いので、分からないことは「分からない」と言ってください。

2. 時間切れである

時間が無限にあれば、部下に任せることができます。しかしながら、部下の育成と事業成長のそれぞれに割ける時間には上限があり、事業成長のほうが優先度が高いです。
この状況では部下に任せている内容の見積もりが間違っていて、スキルや経験に見合わないサイズの仕事を渡そうとしています。仕事を任せる前に時間をとって事前準備が必要になるので、その時間を取るか、上司部下の間での仕事の分担を見直すべきでした。

3. 腹をくくれていない

正直なところ、私が権限を渡せない理由は部下側が「腹をくくれていない」に尽きるのかもしれません。言い方が悪いかもしれませんが「適当に考えて思いついた良さそうな私っぽい案を持ってきてみました！」というマインドセットで仕事をしている間は権限を渡すことはありません。
限られたリソースの中で最もユーザーを幸せにできるのは？最も事業成長に貢献するのは？最も一緒に働くメンバーがワクワクできるのは？と考え尽くして「これです！」と腹をくくって持ってきてくれる方には上司もどんどん権限を渡すことができます。

上司としてもっとできたこともいくつか反省がありますが、私にはこれまで部下として上司からガツガツ権限を奪ってきた成功と失敗の経験があるので、ここからは部下側として権限を奪うためにやってきたことを書こうと思います。

「俺の考えた最強のA案」ではなく3案もっていく

意思決定をするときに、最終的には自分でできることを目指すので「絶対にこれである！」という案を選ぶのが良いです。しかしながら、権限を貰えない状況においては自分と相手で「良さ」の定義が異なります。このとき、1案を詰めて持って行く前に3案のドラフトを考えて各々の長所・短所を整理してみましょう。
この何を長所・短所として見ているのかの軸を上司部下で揃えることが「良さ」の共通認識を取るきっかけになるのでおすすめです。

また、自分の考えたアイデアというのは可愛いものです。それが一蹴された時には、まるで自分まで否定されたような気持ちになることもあるでしょう。しかし、事業のために必要なのは最も事業に貢献するアイデアです。自分の最初に思いついたアイデアを贔屓してしまう気持ちを手放すためにも別の視点から複数案考えて、一番良いものを選ぶ発散と収束の検討は癖づけておくといいでしょう。

良い案の定義、仮説の連鎖を理解する

今求められている意思決定はどんな軸で実施すべきなのか、その長所・短所を洗い出すのも最初は難しいでしょう。私はプロダクトマネジメントをするときに、以下の仮説のミルフィーユと呼んでいるものの一つ上の階層にあるものによってそれぞれの意思決定の良さは定義されると考えています。
ぜひこの図も参考にして、今求められている意思決定は何を満たすと良いのかを考えてみてください。

自分に何ができて、何ができないのかを客観視する

まず、安心しましょう。なんでもできるスーパーマンを求められているわけでも無ければ、上司のようにこれまでの経緯をすべて知っているわけではないので、権限をもらったとしても全部自分でやる必要はありません。自分が何ができて、何は他を頼らなければ行けないか知っている人であれば安心して仕事を任せることができます。
このときにおすすめなのがDACIというフレームワークです。

決定する項目ごとに、推進者（Driver）、承認者（Approver）、貢献者（Contributor）、報告先（Informed）の権限を誰が持っているのかをあらかじめ合意をすることで、承認者が不明確な状況なまま進み意思決定が遅くなることや、合議制によって凡庸な結論となること、さらにはステークホルダーによる予期せぬ介入を避けることができる。
引用元: 『プロダクトマネジメントのすべて』（翔泳社）

最初にこの表を埋めておくことで、誰とどんな議論をして進めようとしているのかを上司と部下の間で認識合わせができるので、安心して任せてもらうことができるようになります。

	上司	自分	開発部長	営業部長	CS部長	…
目標指標の設定	Approver	Driver	Contributor	Contributor	Contributor
ロードマップづくり	Approver	Driver	Contributor	Contributor	Contributor
ターゲットの選定	Informed	Approver	Informed	Contributor	Contributor

▲DACIフレームワーク

事業に対するWILLを持つ

私が一番嫌いな組織は、WILLのないリーダーが意思決定をしている組織です。本来、意思決定をする人たちは事業をどう成長させたいとか、組織をこう改善したいとか、WILLを持っていてそのWILLを達成するために権限を持っているはずです。そして、そのWILLが同じ方向を向くようにすることがマネジメントだと思います。事業に対するWILLを失った人は、もうリーダーではありません。

権限をもらうためには、権限を持ったうえで事業をどうしたいのか、それに対して自分がどんな権限を持つことで貢献したいのかを明確にしなければいけません。プロダクトマネージャーであれば、プロダクトのビジョンを自分のWILLとして語ることができ、その中でまず自分の担当領域がビジョンの実現にどう貢献し、今後どう発展していくとよいのかを語れるようになってください。これができていない状態では行く場所も決まっていないのに海の上に放り出されているようなものです。私はこれができなくなるとプロダクトマネージャーの肩書を持っていられないと感じるので、最優先で行き先となるWILLを決めるようにしています。

頑固さと素直さの綱引き

プロダクトマネージャーとして仕事をするとき、私は誰よりも考え尽くしているという自負をもって仕事をしています。（その自負が持てるまでの長い議論と仮説検証後にその自信が打ち砕かれるところまでがセットですが。）そのため、自分の仕事に対して何か意見や質問をもらったときにも、早口の長文で様々な側面から説明でき、それにより強いリーダーとしてチームにブレない意思決定の軸をつくることができます。

一方で、大変頑固にも見えるでしょう。善意でもっとこうすればいいのでは？というアイデアを出してもらっても、そのアイデアを採択しない100の理由をノータイムで説明できるのでチームは萎縮してアイデアを伝えるモチベーションを失います。これは私が目指すお互いに相乗効果をもってクリエイティブになるチームではありません。そして、場合によっては上司からのフィードバックに耳を貸さない振る舞いにもなりかねません。

忙しくなればなるほど私もできなくなることが多いのですが、何かきっかけをもらったときには即座にNOを言うのではなく、その人の頭になって一緒に発散をして他の良さの世界線を見てみることも自分の固執した頭の中になかったものを見つけるきっかけになります。他の人から学ぶ素直さも心がけてみると、視野が広がって仕事を任せてもらいやすくなります。

「権限をください」のまえに信頼貯金を貯める

自分の中で権限をもらうための準備が終わったら、上司とのコミュニケーションを進めて権限を委譲してもらえるように進みましょう。しかし、ここではいきなり「権限をください」と言うのではなくまず信頼貯金を貯めて安心して権限をもらえる状態の準備をしましょう。
そのためには、上司が意思決定するタイミングであったとしても自分なりの意思決定とその理由を併せて持っていって、「こちらの意思決定でいかがでしょうか？」と提案することを繰り返しましょう。それを何度か繰り返したあとに、事業の意思決定のスピードが遅いことで起きている課題を説明して、その解決を目的に権限を委譲してもらうことを打診するとうまくいきます。

「意思決定」ではなく「壁打ち」を依頼する

権限を委譲されたからといって、すべてを自分で決めて良いわけではありません。自分では決められないことは適宜上司に委ねなければいけませんし、上司と自分の間で良さの基準が揃っている状態を維持する必要もあります。そのため、上司にはApproveを渡すのではなく自分が意思決定をするまでの検討について意見をもらう壁打ちのコミュニケーションを依頼することをおすすめします。

常にどんなことで悩んでいるのか、意思決定を迷っているのかを上司に伝え、その解決に向けて一緒に検討をしながら進める時間を持っておくことでお互いに安心して仕事に取り組むことができます。

上司に期待する役割を明確にする

上司から部下に対して期待する役割を明確にするのと同様に、DACIなどを使ってどこまでを自分の責任範囲としたいのか、どこからは上司にサポートしてほしいのかを伝えましょう。上司としては任せてしまうことで本来よりよくできたサポートが手薄になることを申し訳なく思うこともあります。上司のほうがうまくできることはしっかり甘えて、事業全体としてうまくいくような設計をこころがけましょう。

冒頭にも書きましたが、本来は部下がこういったコミュニケーションを戦略的にとることなく上司側から働きかけるものです。しかしながら、それを誰もしないのなら、誰かのせいにせずに誰かから動き出さなければいけません。
この記事が何か少しでも読んでくださった方が前向きに心地よく仕事をするためのお役に立てたら嬉しく思います。がんばりましょう。