エンジニアとのコミュニケーションの質を高めるためのPdMの思考と行動
こんにちは、いまふく（@happy_imafuku）です。
PdMの勉強会やコミュニティに参加していると、特にエンジニア経験のないPdMの方から、エンジニアの方とのコミュニケーションに課題を抱えているという話をよく聞きます。
自分自身もエンジニア経験のないPdMですが、ありがたいことにエンジニアの方とのコミュニケーションに課題を感じることはほとんどないです。（もちろん0ではないです。）
所属する会社のエンジニアレベルが高いというのもあるので、あまり偉そうなことも言えないのですが、エンジニア経験の無い私がエンジニアの方とのコミュニケーションにおいて普段から考えていること・実践していることを整理してみました。
（前提）質の高いコミュニケーションの定義
前提として、私は以下の要素を持った情報のやりとりのことを質の高いコミュニケーションと考えています。
相手の意図を正確に理解すること
認識の齟齬を抑えながら効果的に情報を伝えること
そのやりとりによって、効果的に物事が進むこと
コミュニケーションがうまくいかない要因
色々な方々の話を聞いていると、3つの要因があるのではないかと考えています。
知識による認識の齟齬
技術への苦手意識
極端な役割意識
知識による認識の齟齬
要因の1つ目は、知識による認識の齟齬です。
エンジニアリングは多大な専門知識が必要なため、エンジニアと（エンジニア経験の無い）PdMには開発に関する知識量に乖離があるケースが多いです。
前提知識に乖離があると、伝える側は補足したり抽象レベルを調整したりする必要があり、コミュニケーションの難易度が上がります。
その結果、認識の齟齬が生まれてしまい、その結果、手戻りやインシデント、スケジュール遅延などの問題が発生します。
技術への苦手意識
要因の2つ目は、技術への苦手意識です。
エンジニア経験がないPdMは、エンジニアリングという未知数なものに漠然とした苦手意識を持ちがちです。
ただその苦手意識は「技術のことは自分には関係ない」という思考につながり、技術が関わるイシューは何も考えずに丸投げしたり、エンジニアの方がやっている業務に関心を持たなかったりといった行動に繋がりやすいです。
その結果、エンジニアの方からの信頼を損ないかねません。
人間は信頼してない人の言うことを積極的に聞こうとしないものなので、信頼を損なうことはコミュニケーションの質にダイレクトに影響します。
偏った役割意識
要因の3つ目は、極端な役割意識です。
「PdMは何を作るか考える人」「エンジニアはコードを書く人」という感じで役割を分断してないでしょうか？
アジャイル開発では、PdMとエンジニアは一緒にプロダクトを考えて作っていきます。
もちろんメインの業務はそれぞれ分かれていますが、完全に分かれていると意識すると、PdMは業務を依頼する人、エンジニアは依頼を受けてアウトプットを出す人という関係性になり、本来はフラットなはずのPdMとエンジニアの関係性が崩壊します。
具体的には、細かい点までPdMがエンジニアに指摘したり、期限の迫った要望をいきなり出したり、エンジニアのアウトプットに対して上から指摘するなどが挙げられ、これからの行為はエンジニアの不満に繋がりやすいです。
また役割が明確に分かれると情報が分断されやすくなり、PdMとエンジニア間で情報の非対称性が生まれ、認識の齟齬も生まれやすくなります。
コミュニケーションの質を上げるための思考と行動
こういった要因を受けて、コミュニケーションの質を上げるにはどういった思考で、どのような行動をとればいいのかをそれぞれ説明していきます。
知識による認識の齟齬を防ぐ
いきなりエンジニアの方と同等の知識を付けることはできませんが、その時の業務で最低限必要になる知識を集中的にインプットすることはできますし、真剣に知ろうとする姿勢を見せればエンジニアの方は丁寧に教えてくれるものです。
コミュニケーションを取っていて分からないことがあった場合は、分からないことを正直に伝えて教えてもらうか、それを理解するのに参考になる記事や書籍を教えてもらいましょう。
特に後者のやり方は説明するエンジニア側の負担も軽くなりますし、それが共通の知識になってコミュニケーションが捗る上に自分自身の深い理解にも繋がるのでおすすめです。
なお聞くことが恥ずかしいという意識は多少はあるもので、その意識が強い方は、「聞かないことによってプロダクトの価値が下がってチームの成果に悪影響が出るかもしれないけど、それでも聞かないのか？」ということを自分の頭の中で考えみると、恥ずかしさよりも聞くというアクションが勝ちやすくなります。
また学んだ知識はSlackのtimes（分報チャンネル）に投稿するなどしてアウトプットするととてもよいです。
自分の言葉で言語化することで理解が深まりますし、それを受けてエンジニアの方からフィードバックをもらって認識のすり合わせをすることもできますし、「教えたらちゃんと学ぶ人」と認識してもらえて信頼関係の醸成にも繋がります。
知識による認識の齟齬を防ぐ 思考
日々のコミュニケーションで分からないと感じたことは、積極的に聞いたり学んだりすることで、認識の齟齬が起きにくくなる
知識による認識の齟齬を防ぐ 行動
分からないと感じたら、分からないことを正直に伝えて質問するか、理解するためにおすすめの記事や書籍を聞く
学んだことをアウトプットして、共通認識にする
技術への苦手意識を克服する
知識はもちろん大切ですが、成功しているPdMのいちばん重要な特徴と言われているのが、「好奇心」です。
（参照：『プロダクトマネージャーのしごと 第2版 ―1日目から使える実践ガイド 』第3章 p.32）
PdMは何事にも興味関心を持って、貪欲に学ぶ姿勢が大切です。
技術に対する苦手意識を持たないための方法としては、大きく2つの方向性があると思っています。
技術に少しでも触れてみる
技術を扱う人間に関心を持つ
技術に少しでも触れてみる
技術に対して苦手意識のある方は、ほとんど技術に触れておらず、漠然とした抵抗感を持っているのではないでしょうか。
人間は分からないものに対しては漠然とした恐怖感を持ってしまい距離をとってしまいがちです。
今の世の中はProgateやドットインストールなど安価にプログラミング学習を始められるサービスもありますし、Bubbleなどノーコードでアプリケーションを作れるサービスもあります。
少しでも技術に触れてみて少しずつ理解できることを増やしていくことで、好奇心が湧いてきて苦手意識を減らしていけるはずです。
個人的に最初の一歩としておすすめなのは、SQLを勉強することです。
比較的学習の難易度が低く、1ヶ月ほどあれば基礎的な内容はインプットできるのと、データ分析として実務で使えるため、勉強のモチベーションも上がりやすいです。
私は以下のドリルで短期集中的にSQLを学習していました。
技術を扱う人間に関心を持つ
技術に苦手意識がある場合でも、それを扱う人間と近づくことができれば苦手意識は消えていきます。
例えばアートに苦手意識がある方も、画家の人生や人間性を知ることで、苦手意識がなくなることがあります。（ピカソは生涯めっちゃ離婚をしていて、歴代の妻が絵のモデルになっているなど）
技術も同じで、技術に対して苦手意識があっても、エンジニアの方のパーソナリティを把握したり交流を深めることで、技術に対する意識も変わってくると思います。
私は実際に
エンジニアの勉強会やカンファレンスに参加する
エンジニアチームの飲み会に参加する
エンジニアのSlackへの投稿を見て、考えていることや関心事を把握する
といったことをやっています。
特にカンファレンスへの参加は、エンジニアの方の興味関心やパーソナリティがひしひしと伝わってきますし、とても面白いので非常におすすめです。（自分もPHPコミュニティに参加していて、実際に登壇なんかもしてます。）
技術への苦手意識を克服する 思考
技術に少しでも触れてみることで、苦手意識が弱まる
技術を扱う人間に関心を持つことで、技術に対する印象が変わる
技術への苦手意識を克服する 行動
プログラミングを学習する（特にSQL）
エンジニアが参加するイベントに参加してみる
エンジニアが投稿したメッセージを見て、思考や関心事に目を向ける
偏った役割意識を捨てる
まずは「エンジニアはコードを書く人」という意識を速攻で捨てましょう。
エンジニアの方は一緒にプロダクトの目標を追い、一緒にプロダクトを創っていくメンバーです。
まずはエンジニアに対して「どのように作ってほしいか」というHowばかりを伝えるのではなく、「なぜ必要なのか」「それによってどういったアウトカムが生まれるのか」といったWhyを伝えるところから始めましょう。
Whyを知ることでHowの精度が格段に高まりますし、開発に対する納得感やモチベーションが上がりやすくなります。
またエンジニアの方と一緒にWhyを考えるようにしましょう。
多くのHowを知っているエンジニアは、それを抽象化してWhyを考えることも得意な方が多いので、要求の中身を詰める際や優先順位を考える際も、エンジニアの方を積極的に頼っていくべきです。
なお悪戦苦闘しながら問題を一緒に解くことは、フラットで良好な関係性構築にも繋がりやすいです。
エンジニアの方との関係性に悩んでいる方も、積極的に実践してみてください。
（参照：『プロダクトマネージャーのしごと 第2版 ―1日目から使える実践ガイド 』第3章 p.39）
偏った役割意識を捨てる 思考
エンジニアはプロダクトの目標を一緒に追うメンバーであり、一緒にプロダクトを創っていくメンバーである
偏った役割意識を捨てる 行動
PdMはWhyを考え抜き、そのWhyをエンジニアに伝える
エンジニアを頼って、Whyを一緒に考える
終わりに
今回はエンジニアの方のコミュニケーションの質を高めるための思考と行動について解説してきました。
特に自分と同じようなエンジニア経験のないPdMの方々やエンジニアの方と業務で関わる方々の参考になれば幸いです。
対エンジニアでのPdMの思考と行動についての話でしたが、対PdMでのエンジニアの思考と行動については以下の資料で解説しています。
ぜひ参考にしてみてください。