「PMにとって（地味だけど）重要な「相談される」スキル」とは note版（地味PMmeetup #2 登壇テーマ）
こんにちは。GMOペパボ株式会社で、「SUZURI byGMOペパボ」というオリジナルグッズ作成・販売サービスのPMをしているマキヤマミルテです。
先日、hey株式会社の永嶋さん（@_nagacy）とNstock株式会社のさとじゅんさん（@junsam22）が主催されている「地味PM meetup #2」にて登壇したのですが、口頭でお話しした部分なども補填した内容をnoteでも公開したいと思います。
▼登壇資料
今のSUZURI事業部の状況
まず前提として、私が所属しているSUZURI事業部は、出社ルールや組織図上の都合で、リモート勤務派と出社派が混在していたり、開発メンバーが所属していないチームがあったりします。
このような体制下で起こり得ることとして、リモート・出社メンバー間での情報格差が発生したり、別チームの動向や前提条件を把握しにくい、そもそもチーム外のメンバーへの話しかけハードルが高い、といったケースがあります。
こうした条件下では、できるだけ「情報の透明性」を保つ工夫をしないと、コミュニケーションの齟齬が発生しやすいです。
情報の透明性とは何なのか
よく耳にするこの「情報の透明性」ですが、どのような状況であればこの「透明性」が高いと言えるのでしょうか。
よく言われることとしては、「経緯や議論をオープンにしよう！」という論調で、話したことをテキストで残して誰でもみられるようにする だったりとか、オープンな場で議論する だったりかなと思います。
もちろん、この2つはとても重要なことで、SUZURI事業部でも基本的な行動指針として守られています。
ただ、この2つを満たしていても、特にうちのような人数が多い組織になってくると、「情報を届けること」はできても、「情報を正しく理解し、行動してもらう」には不十分だということがわかってきました。
では、「情報を正しく理解し、行動してもらう」どうすれば良いのか。と考えた時、前述の2つの要素に加えて、
「わからないことがあったら聞いてみよう」と思ってもらえる関係性を作る
ということが、「情報を正しく理解し、行動してもらう」ということに繋がり、真に情報の透明性を高めるのだ、ということを知りました（出典は後述）。
このことを自分自身の振る舞い方に置き換えてみた時、次の結論に辿り着きました。
それは、自分自身がいかに「相談しやすいPM」であれるか ということです。
「わからなかったら聞いてみよう」と思われる関係性を作る、ということは、基本的に職位も職種も関係なく重要です。
ただ、普段から様々なステークホルダーとのやりとりを通じて不確実な物事を減らしていき、プロダクトの価値を最大化していくPMにとって、「相談しにくい」と思われることは致命的な要素ともいえます。
だからこそ、PMは特に、普段から「相談しやすい」と思われる存在として振る舞う必要があると思っています。
相談しやすいPMとはどんなPMなのか
では、「相談しやすいPM」とはどういうPMなのだろう、と考えてみました。
その結果、自分の中で2つの要素が導き出されました。
1つめは、話しかけるための（精神的・物理的）準備がいらない ということ。
もう1つは、「相談したあと、悩みの解決率が高い」ということです。
①話しかけるための準備がいらない
これを体現するために普段工夫していることとして、まず1つめは、「いつどのタイミングで話しかけられても機嫌を一定にする」ということです。（これはマネージャーを始め、組織の中でのハブ的な存在になりうる人は誰にでも必要なことかもしれません。）
一度でも「不機嫌なとき」を作ると、「あの人、今機嫌悪そうだから話しかけるのやめておこう」とか、「話しかけるとめんどくさいことになる」とか、「適当に相談すると怒られるからちゃんと準備しないと…」など、本来考える必要がない部分でロスが生じ、結果的に物事のスピード感が落ちる要因となります。
そのため、どんなに忙しくても、もしくは何らかの要因で落ち込んでいても、一度でも「機嫌が不安定なことがある」と思われてしまうだけで一気に話しかけられハードルが上がってしまうぞ、ということを、普段から自分に言い聞かせています。
▼ニュアンスは少し違いますが、PMに話しかけちゃいけないタイミングなんてないのだ、という意味で共感したツイート
PMに話しかけてもいいタイミング pic.twitter.com/iSvyTNnxqW
— のなと@もちねこはIT屋さん (@Nonato_Note) April 20, 2022
続いて、2つめの工夫（というか心構え）としては、相手が「相談してくれた」という行為を尊重する ということです。
例えば機能追加の相談で、いまいち要求定義や課題がわからない時、開発チームが「手段から入らずに課題を教えてください！」なんて伝えるケースはよくあるのではと思います。
ただ、この時、相手にだけ説明責任を求めるのではなく、こちら側も質問責任を持つという前提で、相手が持っている課題をヒアリングを通して明らかにする、という姿勢を持つようにしています。
そもそも、そうした相談をフックに、「ターゲットが持つ課題に対して、今この段階では何が最善か？」を考え導くのが、PMの役割でもあるはずです。
相談された時、相手の「できていないこと」を糾弾することはただの自己満足にすぎません。また、相手も「相談すると怒られる」と学習してしまうことで、相談や提案をされる機会が減り、結果的に自分にはなかった視点や意見を取りこぼしてしまうことにもつながる、ということを知っておくことは重要です。
※とはいえもちろん、一方的に質問責任だけを追う必要もないと思っています。相手が（こちらにとって必要な）説明責任を果たしやすいようにフォーマット化できる部分はしたり、ヒアリングを重ねることで相手に「まずは課題から気軽に相談しよう」と思ってもらえることもまた重要だと思っています。
②相談した後、悩みの解決率が高い
これは、自分が全知全能であれ、ということではありません。
大切なのは、
・相手と本質的な部分で議論ができる状態にすること
・相談の結果相手がきちんと何らかの形で次に進める状態にすること
だと思っています。
そのための手段として、まず大事にしているのは、「相手と言語を合わせる」ことです。
ソクラテスは「大工と話すときは、大工の言葉を使え」と説いた。 コミュニケーションは受け手の言葉を使わなければ成立しない。受け手の経験に基づいた言葉を使わなければならない。
こちら側がわかっている言葉でも、相手が理解していなければ、まず相手はそれぞれの意味を理解しようとするところから始まります。それは結果的に、余計な部分で相手の思考を止めてしまい、本質的な部分での議論の進行を阻害する要因となります。
また、上記に加えて、相手を再び迷子にしたり、誤った情報が伝播することを予防するためにも、サクッと口頭で話したことについても内容やネクストアクションをテキストで明確にしておく、ということも必ず行っています。
口頭では「わかりました！」と言ってても、実は自分の中で理解まで落とし込めてない、といったことは往々にしてあります。だからこそ、特に誤解が生じそうな部分や、背景のロジックの理解が難しいものについては、理由もセットでテキスト化しておくことで、相手が他の人に一次情報を共有できるようにしたり、やることの認識がふんわりしてきても反芻することができる状態にし、「これって結局どういうことだったのでしたっけ…？」とか、「〜だと思ってたのですが…」となることを防ぎます。
このように、いかに普段から「あの人に相談すると、余計なストレスもなく、物事が進展する」と思ってもらえるか、ということが、「相談しやすさ」に繋がっていくと思っています。
まとめ
PMは、普段から様々な職種や職位の人たちとのやりとりを通じて、物事の不確実性を減らしていくことが仕事の1つだと思っています。
これをこなすためには、日頃のコミュニケーション設計を通じて、他のメンバーが「相談したくなる」存在でいるということが、（特にコミュニケーションハードルが高くなりがちなリモート下では）特に重要です。
今日お話しした工夫は、当たり前のように見せかけて油断するとすぐに忘れてしまう観点でもあります。（正直、私もまだまだできてないときはあります。）
地味な部分ではありますが、こうした積み重ねが、結果的に良いサービスを提供することに繋がっていくはずだ、と思っています。
追記①登壇中にあった質疑応答
Q. 今回の発表のようなマインドに至ったのは、自身の元々の性格に起因するものか？
A. 昔から誰かに相談されるのが好きなタイプだったので、そうとも言えるかもしれません。ただ、（ディレクター出身ということもあり）自分は昔から「わからない」側の人間である機会が多かったからこそ、非開発メンバーの思考回路やわからないポイント、ちょっと傷ついたコミュニケーションなどを理解している、というのは大きいです。
Q. PMはスケジュールがぎちぎちになりがちなので、そもそも相談する時間がない！と言われることもあるがどのように相談に対応している？
A.まず、相談内容的にテキストで完結するようならそうなるようにすることを優先しています。その際、なるべく無駄なラリーをしないためにも、相手の背景や意図を汲んだ上で意見や選択肢、アクションの提案を行うようにしています。（相手が何回も質問する必要があるコミュニケーションは取らないようにしています。例えば、「できません」「わかりません」だけで答えるなど）
また、自分がボトルネックにならないようにするために、SUZURIではグループメンションを積極的に活用しています。バイネームのメンションではなく、エンジニアやデザイナー含めたプロダクトチームメンション もしくは プロダクトのディレクター（およびPM）のグループメンションで声をかけてもらうことで、他の人でも返答できるような仕組みになっています。
上記でもカバーできない、そもそもしっかり議論して決めたほうがよさそうなことがあった時に、初めてMTGをセッティングしています。
追記②今回の発表内容で影響を受けた書籍
「情報の透明性」についての考え方について、「最近知りました」という表現をしましたが、その元となったのはこちらの書籍の一節です。
「情報の透明性」とは、意思決定と意思決定に関わる情報が、組織内に正しく整合性をもって伝達されるように継続して努力し、何かわからない決定があったとしても、それは隠そうとしたわけではなく、抜けてしまったのか、自分が聞き逃したのだから、直接聞いてみようという関係性をつくることです。情報公開が情報の透明性を作るわけではありません。
最後に
SUZURIでは現在、一緒に働いてくれるエンジニアを募集しています！
今回の登壇を通じて興味を持ってくださった方は、ぜひTwitterDMでお気軽にお声がけください。
Twitter：@_mmakiyama
