できたこと貯金①：共通言語を持つ
こんにちは。PM歴3年3ヶ月なのに未だに伸び代だらけのPM, みゅーです。
さて、今回は当たり前のことを当たり前に書くだけの、でも当たり前だけどできていなかったことができるようになったことを自分の財産として残すための、できたこと貯金シリーズ第一弾です。
（シリーズとか言いつつ大体途中で頓挫するので、これで終わるかもしれません。終わらないかもしれません。）
今回のできたこと貯金テーマは「共通言語を持つ」です。
お付き合いくださいませませ。
PMという仕事おさらい
前提として、私のnoteではPMを『プロダクトマネージャー』の意味で使います。
いろーーーーんな記事や本にPMとは的なものは記載されているので、ここでは説明を色々省きますが、PMとして忘れてはいけないのがステークホルダーのバックグラウンドによって理解度に差があるということです。
PMというのは、関わる職種が幅広いのが一つの特徴です。
エンジニア、デザイナー、QA、データアナリスト、などからなる開発メンバーだけでなく、
セールス、CSから開発要望をもらって議論したり相談に乗ってもらったり、
UXリサーチャーと一緒にお客様と直接話したりデータをもらったり、
リーガルチームと、開発要件に際して法に抵触するものがないか確認したり、利用規約のアップデートを行ったり、
マーケター、PRとリリース時期を調整したり、
Cレベルの人たちに対して、プロダクト戦略の説明と改修をおこなったり、
企業によっては、PMMと業務を分担してSyncしたり…
と今パッと思いつくだけで12職種の人たちとお話しする機会があるのです。
自分で言うけど、た い へ ん ／(^o^)＼
そんなPMに最も求められる基本的な能力、それは相手の意図を正確に理解し、自分の意思を正しく伝える能力なのです。
PMが持っておくべき「伝える技術」
PMは、一人では何も成し遂げられないので、
それぞれの職種のエキスパートたちへ自分達が成し遂げたいことを「伝えて」、お手伝いしてもらう必要があります。
その「伝える」ための技術で私史上最も効果的な三つが
共通言語を持つ
相手の状況を把握する
情熱
です。
ね、当たり前でしょ？笑
でも、意外とその当たり前ができなくて、
私の場合は一番大事な「共通言語を持つ」が私にとって大きな課題でした。
割とド直球な例を用いて考えてみます。
日本人の私が、「感謝」というメッセージを送ったとします。
きっと日本人の友人は、その一言でほぼ100％私が言わんとしていることは理解するでしょう。何に対する感謝なのか、は気になる人は質問してくれるかもしれません。
しかし、これを受け取ったのが日本人でないとすれば？
きっと中国人の友人なら、たとえ日本語の知識がないとしてもなんとなく意味を理解してくれるかもしれません。100とは言わないまでも、きっと90％くらいはわかってくれるはず。
でも、その友人がたとえばメキシコ人だったら？
英語ともスペイン語とも違う文字を見てどれくらいの人が私が言いたいことを理解してくれるでしょうか？
彼らに理解してもらう方法は大きく分けて2つ。
・日本語がわかる他のメキシコ人に通訳してもらうか、
・私がスペイン語あるいは英語を話すしかないのです。
これが、部署を跨いで業務を遂行するPMがやることです。
エンジニアにはエンジニアに通じる話し方があって、
デザイナーにはデザイナーに通じる話し方があって、
セールスにはセールスに通じる話し方がある。
全員に同じ話し方をしても、納得感が全く違うので常に相手の目線に立ちながら、相手がわかりやすいであろう言葉を選んで話さなければ、私たちがやりたいと思っていることを真に理解して協力してもらうことはできないのです。
そして、私は何を隠そう、根っからの文系なのでデザイナーやCSとの共通言語はたくさん持っていたし、得意だと認識しておりました。
ただ、悲しいかな、エンジニアとの共通言語がやや欠けだったのです
致 命 的 ／(^o^)＼
EMレベルになると、PMと考え方が似てくるので、困った時は彼らに間に入ってもらって通訳してもらったりしておりました。（PMがいる意味よ…）
エンジニアと共通言語をもつ方法
さすがにPMとして一皮剥けるにはある程度エンジニアさんとも共通言語を持ちたい。
そう思って早3年。
何もしてこなかったわけではありません。
Computer Scienceに関しての知識が足りないのだと思って勉強しました。
コードを書けばわかるだろうと思って写経してみました。
いや、アーキテクチャ理解が浅いのかな？と思ってEMの人におすすめされた書物やらツールやらで勉強してみました。
PM力の問題かな？と思ってPMが読むであろう王道書物を読んだりしました。
それでも、なんだかしっくりきていないこの感じ。
伝わっていそうで伝わってない。
この間は伝わったのに、同じ方法をとったのに今回は伝わらない。
とても辛い3年間でした。
ついに、ついに私でもできる効果抜群の方法に気がつきました。
そう、エンジニアが読むものを読む、それだけです。
ね、当たり前でしょ？笑
外部サービス接続に関する仕様に関してお願いしたいなら、
その外部サービスが提供しているAPIの仕様を自分で読めばいい。
内部で仕様を変えたいならエンジニアが書いたスペックを読めばいい。
新規サービスを作りたいなら、それに関係するサービスの設計書を読めばいい。
具体的にエンジニアが何をすればいいのかを自分の言葉で話せるようになれば、コードが書けなかったとしても、読めなかったとしても（本当は読めた方がいいし、簡単なバグ修正くらいなら自分で直せたほうがもちろんいいけど）コミュニケーションコストがグッと下がります。
もちろん努力は大事だけど、
ショートカットできるならショートカットして最大限に自分の労力と時間とお金をセーブして他にもやりたいこと、を考えるほうがPMとしてはもしかしたら成長するのかも、と思った瞬間でした。
この温度を大事にしたいと思って、とりあえず殴り書きして投稿するけど、後で編集するかも。
意外と当たり前のことって聞けなくて教えてもらえなかったりするから、
どこかで誰かの辛い気持ちを救えたらな、と思って自分の恥を晒してみる。
ぼやっと渋谷区OLやってるPMが呟いているTwitterはこちらです。
この記事が気に入ったらサポートをしてみませんか？