エムスリーテックブログ

エムスリー(m3)のエンジニア・開発メンバーによる技術ブログです

事業責任者とのコミュニケーションにおける学び〜仮説のタワーマンションを建てないために〜

この記事はエムスリー Advent Calendar 2022 19日目の記事です。前日はエムスリー AI・機械学習チームのRECSYS 2022推し論文を紹介するぜ! - エムスリーテックブログでした。

こんにちは。エムスリーエンジニアリンググループ プロダクトマネージャーの中村です。

今回のテーマは、仕事の9割はコミュニケーションだと言われるプロダクトマネージャー(以下PdMと略します)にとって必須スキルである「報告・連絡・相談」、略して「ホウレンソウ」です。

「ホウレンソウ」といえば、プロダクトマネージャーカンファレンス2022のクライス&カンパニー山本さん・エムスリー山崎さんのセッションで紹介されていたので、記憶に新しい方もいらっしゃるかと思います。

youtu.be

また、先日の髙田さんのブログは、ホウレンソウの「報告」がテーマでした。具体例満載で非常に参考になる内容なので、こちらも合わせてご覧いただけると幸いです。

www.m3tech.blog

これらを踏まえ、今回のブログでは私がPdMとしてホウレンソウにおいてどのような失敗を経験し、それをどう乗り越え、何を学んだのかということをお話しします。

具体的には、事業責任者とのコミュニケーションで陥った失敗についてご紹介します。

はじめに:ホウレンソウを「完全に理解した」

恥ずかしながら私は、「ホウレンソウ」をすでにマスターしていると思っていました。「ホウレンソウ」なんていうものは、社会人1年目の初日にはすでに習っており、10年以上の社会人経験を経てすでに体に染み込んでいるものだ、と。

それが、実際にはそんなことなかった、ということを痛感する出来事がありました。

いわゆる「完全に理解した」という状態だったのです。

何が起こったか

AskDoctorsアプリ*1の2022年下期の方針について事業責任者と合意を得るため、戦略と施策をまとめた資料を作成し事業責任者にプレゼンテーションしました。

結果、事業責任者からフィードバックは得られたものの、事業責任者の推進したい方向性と、PdMとして下期やるべきだと考える方向性との間でズレが生じてしまいました(事業責任者のやりたい方向性も理解していますし、それを実現し事業を成長させるのもPdMの役割です。ただ、ここでは2022年下期というスコープの中でやるべきだと考える方向性にズレが生じました)。

下記がその時の実際の資料です。

実際の資料をマスクしています。雰囲気だけでも伝われば幸いです。

何が問題だったか

事業責任者とのMTGの直後にPdMの師匠である山崎さんとの1on1があり、上記の出来事を話し、この資料についてどう思うかフィードバックを請うてみました。

すると、最初の1ページ+各スライドのサムネイルを見ただけで、「大体わかりました」という返事が返ってきました。 正直、全部説明していないのに何がわかったのだろうかと疑問に思ったのですが、続くフィードバックを聞いて納得のあまり膝を打っている自分がいました。

山崎さんからのフィードバックは以下でした(実際には詳細にフィードバックいただいたのですが、ここではわかりやすくサマってご紹介します)。

まず「ファクト」を揃えましょう。ファクトがないため、その仮説の筋が良さそうなのか、そのオプションの広げ方で良いのか判断できません。さらに仮説の上に仮説が積み重なっており、その施策で本当にKPIが達成できるのか怪しいと感じてしまいます。

つまり私は、

  • 自分のやりたいことを伝えるための資料を作っていた

  • そして仮説に仮説を積み重ねた「仮説のタワーマンション」を建ててしまっていた

というアンチパターンに陥っていたのです。

自分のやりたいことを伝えるための資料を作っていた

資料中にファクトが無い(実際には多少はあったのですが十分ではない)ため、今回の提案は担当者がやりたいことでしかない=「お気持ち」の表明でしかなく、「事業責任者がやりたいこと」VS「PdMがやりたいこと」の対立構造を作ってしまっていたのです。

更に言うと、担当者の「お気持ち」であれば、事業責任者はそれを採用しない、という判断ができてしまいます。

「仮説のタワーマンション」を建ててしまっていた

これはどういうことかというと、ファクトを示さないまま、「AskDoctorsアプリの方向性は○○である」という意見(仮説)に対しそれを実現するオプションを広げていったということです。

そもそもの方向性が仮説でしかないため、相手にとっては、そもそも「AskDoctorsアプリの方向性は○○である」という仮説が正しいかもわからないのに、オプションを広げられてしまっている状態、となります。

フィードバックを受けて行ったこと

ファクトを整理し、数字で語る

そこで改めて、ファクトを整理し、事業を成長させるためのオプションを並べ、数字をシミュレーションしました。 そして、シミュレーションした数字をベースに「AskDoctorsアプリの●●という課題を解決するために、▲▲のオプションを選ぶべきだと思います」という意見を述べる形としました。

そしてこの時点では、個別の施策アイデアにはあえて言及しませんでした。

その結果、事業責任者と共通の課題認識を持っていることが確認出来、オプションの方向性について合意が得られました。 最初の資料とこの時の資料とで最終的な結論は同じでしたが、伝え方により「事業責任者がやりたいこと」VS「PdMがやりたいこと」という対立構造が解消できたのです。

開発チームとのコミュニケーションでも活用

ちなみに、このファクトと意見(仮説)を分けて話すスタイルは、開発チームとのコミュニケーションでも非常に役立っています。

思い返してみると、開発チームとのコミュニケーションがうまく行かない時というのも、「お気持ち先行型」で話してしまっている時でした。 ファクトと意見(仮説)を分けて話すスタイルでは、共通認識が持てている状態からスタートできるため、KPI達成に向けたアイデアが湧き出るようになりました。

事業責任者とのコミュニケーションにおいて気をつけること

今回起こったこと、そしてそこから学んだことをまとめると下記の図のようになります。

以前の私は、自分の考えをいかに上手く説明するか、どのようにして相手に納得してもらうか、ということを考えていました。 しかし、PdMにおける「ホウレンソウ」とは、ファクトを元にオプションを広げた上で自分の意見を述べることである、ということを学びました。 そうすることで、不要な対立構造を生み出さず、更には自分では気づけない視点をフィードバックしてもらえたり、ディスカッションによりアイデアが広がったりするのです。

おわりに:ホウレンソウ「なにもわからない」に少し近づいた

冒頭でご紹介したプロダクトマネージャーカンファレンスのセッションの中で、山崎さんが「私も谷村さん(エムスリー代表取締役)に、『それはファクトなのか、山崎さんの意見なのか』と聞かれることがある」と語られていたのが非常に印象に残っています。

つまり「ホウレンソウ」とは基本であり、基本であるがゆえに常に磨き続ける必要があるのです。 今回の経験を通じて「ホウレンソウ」の重要性と奥深さを学ぶことができました。

We are hiring!!

私が所属する遠隔医療相談サービス「AskDoctors」のチーム紹介資料ができました! ぜひご覧ください。

speakerdeck.com

また、エムスリーエンジニアリンググループでは、一緒に働く仲間を募集しています! AskDoctorsも含め、少しでも興味を持ってくださったら、ぜひカジュアル面談でお話しましょう。 以下のURLよりカジュアル面談のご応募をお待ちしています。

jobs.m3.com

*1:AskDoctorsとは、病気や健康のことで困った時にインターネット上で医師に相談ができる遠隔医療相談サービスです。