「それ、前にも言ったじゃん…」を無くすためのプロダクトマネージャーの情報共有術
この記事はPharmaXアドベントカレンダー2023の17日目の記事です。
こんにちは。オンライン薬局を運営するPharmaX株式会社でプロダクトマネージャーをやっている稲垣慶典（@InagakiKay）です。
プロダクトマネージャーとして働いていると、人と話すだけで1日が終わることもあるくらい、ずっとコミュニケーションをしているように思います。
ユーザーや関係者の声を「聞く」のもそうですが、役割上、関係者に「伝える」というコミュニケーションもかなりの頻度で行っていると思います。
この「伝える」の難しさを日々感じているのですが、特にそれを象徴する事象が、「それ、前にも言ったじゃん…」と心の中で呟いてしまうような、伝えたつもりが伝わってない問題です。
「伝わる」と「伝える」は違うとよく言われますが、伝える側としてどんな工夫をしてみると良いか考えてみました。
プロダクト開発の現場は情報の嵐
そもそもプロダクト開発をしていると、日々、定型的ではない多様な出来事が発生します。
ユーザーインタビューを通じて新たな示唆が得られたり、開発の進捗に伴う論点が発生したり、難しいお問い合わせ対応が発生したり、事業KPIが意図せぬ変化をしたり…
それに伴って関係者内で大量の情報がやり取りされ、思考され、その結果が情報として関係者内に共有されという営みが行われます。結果として、そのハブとなるプロダクトマネージャーは、情報の波に飲まれるような状態になることも多いのではないでしょうか。
こうしたやり取りで扱われる情報をその性質で整理してみると、「フロー的な情報」と「ストック的な情報」に（半ば強引に）分類することができます。
フロー的な情報：日々新しく登場する断片的な情報
「アクティブティ指標がXX％下がりました」
「お問い合わせで○○○○というご意見をいただきました」
「競合がXXと言う機能アップデートを発表しました」
「○○という検証をやります」
ストック的な情報：蓄積された文脈を持つ情報のまとまり
「○○という仮説を持って検証していたが、反応がいまいちなのでXXと言う仮説の検証に切り替えます」
「ユーザーインタビューを通じて解像度が上がったのでユーザーの定義を言い換えます」
「ロードマップ上この順番でしたが、事業上の優先度が変化したのでこっちを先にやります」
コミュニケーション手段においても、ストック型（notionやGoogleドライブなど）、フロー型（SlackやTeamsなど）という表現で分類されると思いますが、扱う情報の特性と感覚的にリンクしていそうです。
こうして整理してみると、「それ、前にも言ったじゃん…」問題にも、フロー的な情報が伝わってなかった場合と、ストック的な情報が伝わってなかった場合に分けられます。
どちらも問題はではありますが、特にストック的な情報が伝わってない場合は、その認識ズレに伴う影響範囲が広くなりそうで、危険な香りがします。
こういった構造を踏まえながら、伝えたはずなのに伝わらない問題について考えてみます。
「それ、前にも言ったじゃん…」問題
A：「この機能ですが、こういう感じの仕様で進めました。この部分についてはXXXにしています」
B：「あれ、その部分って以前XXXという話していませんでしたっけ？」
A：「え、そんな話してましたっけ？」
大なり小なり、こういう状況に遭遇したことはないでしょうか？
Aさんの心理的には「それ、前にも言ったじゃん…なんで聞いてないの？」となるし、Bさんの心理としては「いや、そんなこと言ってたっけ？絶対言ってないよ」となるし。
前述の通り、日々大量の情報を浴びているプロダクト開発の現場においては、生じて当たり前の事象なので、建設的に向き合っていきたいですよね。
とても大事なのは、こうした問題に直面した際の心構えです。
（会話の文脈的に）「いや、言いましたけど…」と言いたくなる気持ちもわかりますが、あまり意味がないと思います。また、忙しいとイライラしてしまって表情に出てしまいがちですが、それも何も前には進みません。
文脈的に感情が出やすい場面だからこそ、愛想良く、前向きに振る舞うことが大事です。あくまで認識を揃えるための建設的な場になるように向き合う心構えを持ちたいですね。
その上で、発生頻度を下げるために、伝える側の工夫を考えてみます。
そもそもなぜ生じてしまうのでしょうか？
なぜ発生してしまうのか？
原因として以下のようなものが考えられます。
原因１：普通に忘れられていた
受け手側が聞いたことを忘れてしまうケースです。これは人間なので、仕方がないです。
原因２：聞いてたけど、消化されていなかった
改めて伝え直すと、「あーあの話はそういうことだったんですね」となるケースです。結構発生しているようにも思います。
また、同じ原因の事象として、聞いていたものの理解しきれておらず脳内から消されてしまう（＝忘れられてしまう）というパターンもあります。
原因３：異なる理解をされていた
部分的には正しく伝わっていたものの、部分的には意図と異なる伝わり方をしていたというものです。
例えば、「○○という機能追加をしましょう」という部分は伝わっているものの、「XXというニーズがありそうという仮説をもとに」という背景でなく、「短期的に利益を上げないといけないから」という別の背景で進められてしまっていた、というケースです。
このように原因を整理してみた上で、実体験も振り返ってみると、本当に忘れられていたことが原因というケースは、実はそんなに多くないことに気づきます。
むしろ、「それ、前にも言ったじゃん…」問題の原因のほとんどは認識のズレではないかと思います。すなわち、伝えていたつもりが、正しく伝わっていなかったということです。
そう考えると「それ、前にも言ったじゃん…」問題の発生頻度を下げるために、伝える側が工夫できる部分も多分にあるのではないでしょうか。
伝える側としてどんな工夫ができるか
工夫１：伝える情報の優先度をつける
全ての情報を100%伝えきることや、受け手として100%消化（理解）しきることは難しいです。
どうしても情報が溢れてしまうことを踏まえると、伝えるべき情報の優先度をつけると良さそうです。
プロダクトマネージャーの役割を踏まえると、プロダクト開発の関係者内でストック的な情報を優先して共有することが重要です。
優先した場合の行動の変化としては、共有する/しないというものではなく、共有する密度/頻度に差をつけるイメージです。
優先度の高い情報については、何度も口頭で時間をとって伝えるものの、低いものはテキストベースで適宜共有するといった差のつけ方です。
ちなみに、プロダクトマネージャーとトップマネジメント（経営陣）との関係性においては、優先度は変化し、よりフロー的な情報である現場レベルの1次情報を優先的に伝えていくべきだと思います。
優先度は役割関係や状況によって変わりますが、いずれにせよ優先度をつけてすべきものに絞るという捉え方が工夫になりそうです。
工夫２：文脈を意識的に伝える
ストック的な情報で重要なことは、「こうなった」「これをやります」といった結果や方針等の単発的な側面でなく、「こんなことがあったから」「こういうことが観察できたので」と言った背景や理由、きっかけ等を含めた文脈が重要です。
むしろ、文脈こそがストック的な情報そのものだとも思います。前述の原因２や３が生じるのも、この文脈がしっかりと伝わっていないからなのではと思います。
文脈が伝わりづらくなってしまっている要因としては、伝える側自身でも文脈が明確になっていないからや、伝え方の問題として文脈をわかりやすく伝えられていないから、という2点が挙げられます。
工夫2-1：文脈を整理する工夫
前者のケースにおいては、伝える段階の前に文脈を整理することが必要です。ただ、そう捉えるともはや伝える工夫というテーマの範疇を超えてくるので、ここではあくまで伝えやすくするための工夫を紹介します。
伝えやすくなるように、文脈を捉えて伝える内容を整理すると良いです。
この場合の文脈は、「論理の繋がり」と言い換えてみると良いです。例えば以下のようなイメージです。
レイヤーを跨いだ要素の繋がり
例：「ビジネスゴールは○○で」→「それを解決するためのイシューは○○で」→「それを解決するための施策は○○で」→「その結果による示唆○○です、だから〜」
出来事の繋がり
例：「XXXということが観察された」→「だから、XXXというアクションを実施した」→「その結果XXXという示唆が得られた」→「だから、この事象はXXXと捉えている」
状況によって、どういった論理の繋がりで整理すると文脈を伝えやすいかは変わってきますが、予め文脈を明確にしてから伝えると伝わりやすくなります。
工夫2-2：文脈を伝えやすくする工夫
また、文脈をチーム内で理解してもらいやすくするために、どんな論理の繋がりで考えているかをチーム内で共有すると良いです。
例えば、プロダクトチーム内で開発項目を管理するドキュメントをつくるにしても、「ビジネスゴール」「それに紐付くイシュー」「それに紐付く開発項目」と併記することで、論理構造（論理の繋がりの全体像）が把握しやすくなります。
その結果、文脈を共有する際にも「今回はこのイシューに繋がる話か」と理解しやすくなります。
工夫３：しつこいくらい何度も伝える
最後に、よく言われることですが、しつこいくらい伝えるというのは重要な工夫です。
なぜ重要かというと、人間やっぱり忘れちゃうので、複数回伝えることで忘れる可能性を最小化できるからです。また、伝える機会が複数あると、その分理解を深める機会も作れるからです。
ただ、これをやり続けるのが大変だったりします。日々忙しくて時間がなかったり、伝え忘れてしまったり、やること自体が結構カロリー消費したり…。
そのための工夫として以下のようなものがあると思います。
定例会議等の場で共有/確認する固定のコーナーを設ける
箇条書きにせず、文脈が伝わる文章形式でドキュメントに残す
自分と同じくらい話せる伝道師を周囲につくる など
ただ、こればっかりは忙しい中で頑張るしかないとも思っており、これもプロダクトマネージャーの仕事だと割り切るしかないのでしょう。
まとめ
プロダクトチームという形で、異なる職種が一つのプロダクトづくりに向き合っていると、日々様々な認識のズレに直面します。
もちろん長く一緒に働く中で、共通言語化が進み、ズレの発生頻度も減るかもしれませんが、一定は発生し続けます。
その結果として、「それ前にも言ったじゃん…」問題は永遠に発生し続けるでしょう。
ただ、それが起きる原因を考えてみると、発生した際の向き合い方次第で、チーム内における認識のズレを小さくする絶好の機会にもなります。
むしろ、こうしたズレが起きたタイミングでどう立ち回れるかがプロダクトマネージャーとしての腕の見せ所なのかもしれません。
PharmaXのプロダクトチームに興味を持たれた方は、気軽にお声掛けください！
最後に
PharmaXでは、主にエンジニア向けイベントを定期的に開催しています。オンライン開催ですので、お気軽にご参加ください！
この記事が気に入ったらサポートをしてみませんか？