見出し画像

フリーランスPMの備忘録：チームメンバーと友好関係を築くための「心遣い」とは

チャーシュー

多くのPMが悩むエンジニアメンバーとの関係性作り。
この記事では、エンジニアとの良好な関係が生むメリットと
好感度を上げるためにPMができる工夫について
筆者の経験を元にまとめております。


この記事について

この記事は、フリーランスPMとして活動する筆者が
経験から学んだことを忘れないようにするための備忘録です。
あくまでも個人の経験を元にした記事ですので、
参考程度にお読みください。

この記事での「PM」とは

この記事では、
「ITシステム開発プロジェクトのPM」
を指します。

開発チームのマネジメントを主業務としつつ
関連するチーム(インフラ、テスト等) との連携や
顧客への対応・交渉などを行う役割を持つものとします。

フリーランスとして活動をしていると
会社ごとに「PM」が担う役割が大きく異なりますので、
あなたの役割に合う内容を見つけていただけたら嬉しいです。

「チームメンバー」とは誰か

この記事では、
「PMがマネジメントを担当している開発チームのエンジニア」
を指します。

開発チーム以外のマネジメントを担当されている場合でも
活用できる部分もあると思いますので、
最後までお読みいただけたら嬉しいです。

チームメンバーへの「心遣い」とは何か

この記事では、
「チームメンバーが好感を持てるような、PMの態度・行動」
を指します。

好感を持てるような行動と言っても
贈り物をしたり、そのために特別な行動をするわけではなく、
普段の業務の延長線上でできる工夫について記載しています。

また、フリーランスPMである関係上、
チームメンバーもお客様の1人であることが多く、
役職的な上下関係も存在しない関係となります。

そのため、社員としてPMを担当されている方や、
エンジニアが部下となる役職の方とは
若干異なる角度からエンジニアと接しているかもしれませんので、
その違いを比較しながらお読みいただくと面白いかもしれません。

何故PMがメンバーへの「心遣い」を意識するのか

メンバーから嫌われないため

「メンバーから好かれるため」ではないんだ？　
と意外に思われる方もいらっしゃるかもしれませんので、
順を追ってご説明させてください。

先ず、PMというポジションは役割の一部として、
エンジニアがコーディングに集中できる環境を整えるために
スケジュール管理、外部チームとの調整、お客様との交渉等の
集中を妨げるようなタスクを引き受ける役割を持っていますので、
本来であれば好かれるポジションです。

しかし一方で、PMの役割はストレスも多いので
スケジュール調整が上手く出来ないのでエンジニアに無理をお願いしたり、
エンジニアが失敗をした時に強い言葉をかけてしまったりと、
逆に好感度を下げてしまう振る舞いをしてしまう人も見かけます。

実はこの好感度を下げてしまう振る舞いが
非常に問題となります。

人間は「ネガティビティバイアス」という心理特性を持っており、
好印象な振る舞いより、悪印象な振る舞いの方が3倍も印象に残りやすい
とも一説では言われております。

そのため、忙しい時や失敗してしまった時に
無意識にでも強い言動や冷たい態度をとってしまうと、
PM本人にはちょっとした事であっても
エンジニアの好感度を大きく下げてしまう危険があります。

そのため、悪印象な振る舞いを避けるために
好感度を下げる行動とは逆の行動(心遣い) を
日頃から意識して行うことで、抑制していくことが大切だと考えています。

メンバーとの良い関係を築くことが、PMの成果に繋がるため

人間は基本的には自分のために行動する生き物なので
他人が自分のために労力をかけて頑張ってくれることは
親友や恋人などそうそうありません。
なので、メンバーから見てPMの心遣いは良い意味で目立ちます。

そのため、PMがメンバーへの心遣いを忘れずに行動していれば
それはメンバーにも伝わり、少しずつ良い関係性が築けるはずです。

メンバーと良い関係が築けると、
PMにとって下記のようなメリットがあります。

・PMのストレスが減る
　→チームミーティングの雰囲気は明るくなり、
　　PMが失敗した時や、少し無茶なお願いをしなければならない時にも
　　少し文句を言いつつも、なんだかんだ引き受けてくれる。
　　そんな状態になります。

　　逆に、良い関係が築けていないと
　　チームミーティングでは誰も積極的に発言をせず
　　PMが少し無茶なお願いをしても聞き入れてもらえず
　　お客様とエンジニアとの板挟み状態で、
　　どちらからも怒られながら難しい調整を迫られます。
　　このような環境で働きたいと思われる方は少ないでしょう。

・情報がリアルタイムに上がってくるようになる
　→メンバーが失敗したり、マズイことに気がついた時には
　　「これを言ったら怒られるかもしれない…」と思ってしまい、
　　報告をするのに相当の勇気を必要とします。
　　
　　この時に、メンバーと良い関係を築けているほど
　　報告が気軽に出来るようになり、
　　気軽なほど、報告を貰えるタイミングは早くなります。

　　逆に悪い関係の場合、
　　メンバーは報告せずにずっと黙っている場合もあり、
　　これがいかに恐ろしいことであるかは、
　　記載せずとも感じていただけると思います。

・エンジニアから提案が来るようになる
　→多くのエンジニアは
　　PMよりも高い技術力を持っています。
　　
　　そのため、PMから依頼された開発を行う中で
　　元々の要件定義よりも良い解決方法を思いついたり
　　既存の不具合や、リファクタリングの必要性に気がついたりします。

　　良い関係性が出来ていて
　　提案をしても否定されず、適切な判断をしてもらえると思えれば
　　エンジニアはPMに提案をしてくれるようになります。

　　そうすれば、PMは自分の能力以上の提案を
　　お客様に対して行える可能性があります。

PMのモチベーションを維持するため

これも以外に思われるかもしれませんが、
エンジニアと良い関係を築くことで
PM自身のモチベーションも高まります。

一般的に、職場に信頼できる友人がいることで
離職率が低下したり、生産性が向上することが
様々な書籍で紹介されています。

また、私個人の経験としても
開発が予定より遅れてしまった時に顧客説明・スケジュール調整をしたり、
本番トラブルが起きてしまった時に、メンバーと協力して乗り越えたり、
メンバーのために自分ができることを考えて行動するうちに、
チームミーティングで自然と感謝の言葉が出るようなチームになれた時には
PMという仕事にやりがいを感じます。

そして、フリーランスを長く続けていると
自分自身のモチベーションの維持に悩むものです。

フリーランスPMの場合は準委任契約になる場合が多いので
成果が出ても出なくても貰える報酬は変わらず、
社員のように出世を目指せるわけでもなく、
そして今の案件がダメでも、次の案件はいくらでもある。
そういう状態だと、何のために頑張れば良いのかが
分からなくなる時があります。
そしてこの状態は非常に辛いものです。

もしあなたもモチベーション維持に悩んでいるのであれば
チームメンバーとの関係性向上を考えてみても良いかもしれません。

フリーランスPMに出来る心遣いとは？

0. メンバー1人1人を仲間として大切にする

これは今後に記載する心遣いの
ベースとなる考え方ですので、「0.」といたしました。

会社によって様々ではありますが、
エンジニアのことを「リソース」と呼んだり、
発注者と受注者の関係で線引をしていたりと、
エンジニアと対等な目線で接していない現場もあります。

そのような関係性では
エンジニアが心を開いてくれることは無く、
それ以上の関係性の改善は望めません。

エンジニアを仲間として考え、
1人1人を名前だけでなく、人柄や価値観も把握するように努め
体調が悪そうなら声をかけて、仕事が終わっていなくても帰らせて、
プライベートな予定があれば有給が取れるようにスケジュール調整して、
仕事の成果よりも、メンバー個人の幸福を優先するよう心がけましょう。

マネージャーも兼任しているPMの方だと
エンジニアとの契約解除など、時には非情な判断が必要な時もあります。
ただ、そうならないために仲間としてサポートをしたり
時には厳しく叱ったりなど、仲間としてやれることもあると思います。

なので、最初から距離を置いてしまうのではなく
PMから近づいてみるのも、可能であれば試していただきたいです。

また、あまりにもチーム規模が大きすぎると
エンジニア1人1人と上記のようなコミュニケーションをするのは
時間的に難しくなってしまいますので、
チームを分ける等の対策も必要かもしれません。

1. 失敗しても許される安心感を与える

日々のチームミーティングなど
エンジニアからタスクの進捗状況などの報告を受ける機会がありますが、
開発が予定より遅れたり、仕様を誤認識していたために開発ミスがあった等
時には悪い報告を受ける時もあります。

こうした時に、反射的に怒ってしまったり、
何故失敗したのかを原因追求するかたちで詰めたりしてしまうと、
「今後も失敗報告をしたら怒られるかもしれない」
という気持ちを抱かせてしまい、
強いストレスをエンジニアに与えてしまいます。

そうなることを避けるため、
先ずは、「報告内容がどのようなものであっても怒らない(詰めない)」
ことを意識しましょう。

上記を読んで、
「間違いを犯したなら怒らないと、同じ過ちを繰り返すのでは？」
との心配をされる人もいるかもしれませんが、それは逆です。

先ず、怒るという行為をしてしまうと、
人間は「ネガティビティバイアス」の影響により
怒られることで受けた恐怖やストレスの印象が強く残ってしまい、
その時に話した改善アドバイスなどの印象が相対的に弱まり、
改善を妨げてしまいます。

更に、子供も大人も怒られるのは嫌なので
次回からは正直に報告をせず、ごまかそうとする場合もあります。。。
※特にオフショア開発などではこの傾向が強いように感じます。

それによって、同じ過ちも繰り返してしまうし、
また怒られるのが怖くて言い出せないし、
最終的には隠していた失敗がバレて、更に怒られてしまうので、
エンジニアはどんどん辛い気持ちになっていきます。

そのため先ず最初は
「報告内容がどのようなものであっても怒らない」ことを徹底しましょう。

悪い報告をしてくれたら
「正直に報告をしてくれてありがとうございます」と先ずお礼を述べて
その次に、何故そうなってしまったのか、やさしく質問していきましょう。
※気をつけないと詰めているように感じれらてしまうので。

こうすることで、エンジニアから見ると
悪い報告をしても決して怒られないため発言がしやすく、
自分の問題に対して真剣に向き合ってくれるPMと感じられるので、
この後に問題改善のためのアクションをお願いした時にも、
素直に取り組んでくれる可能性が高まります。

怒られる恐怖では失敗は防げないので
そのような文化がチームにあるなら、早々に取り除きましょう。
※PMだけでなく、エンジニア同士でも起こり得る問題なので。。。

2. 自分の失敗を認めて誠実に謝る

PMも完璧な人間ではありませんので
失敗を犯して、エンジニアに迷惑をかける時があります。

その失敗によって仕様変更がされ、
余計な開発タスクが増えて、スケジュールが厳しくなった時に
そのしわ寄せを受けるのは主にエンジニアになります。

ただ、エンジニアもプロですので
上記のようなことになっても納期に間に合わせようと
文句を言いつつも、時には残業もして頑張ってくれる場合が多く
最終的には納期までに開発が完了できる場合もあり、
失敗の責任をPM自身が取らずに済んでしまうことがあります。

しかし、だからこそPMが失敗を犯したときに
「PM自身の能力不足による失敗であることを認める」事と
「エンジニアに対してちゃんと謝る」事はとても大切です。

先ず、「PM自身の能力不足による失敗であることを認める」ですが
PMが失敗するときには、お客様や他チームなどが関係している場合が多く
失敗した原因を人のせいにし易い場合が多いです。
※お客様の意見が変わった、他チームが作業遅延を報告していなかった等

しかし、お客様の意見がころころ変わらないように先手を打ったり、
他チームの作業状況を定期的に確認しつつ、
遅延した時に備えてリカバリープランを事前に立てておくことは
PMの仕事の一部ですので、それを怠って発生した失敗は
PM本人の能力不足が原因となります。

それをPM自身が認めないと、
改善アクションを起こさないので同じような失敗を繰り返します。
また、その状態で「エンジニアに対してちゃんと謝る」ことをしても
その謝罪は心の籠もらないものになるので、
とても不誠実に見えます。

PMがそのような不誠実な態度であれば
PMの失敗のしわ寄せを受ける立場にあるエンジニアとしては、
PMに対する不満が溜まり、エンジニアは自社に苦情を入れるでしょう。
そして、フリーランスPMの契約は解除されます。

逆に、自分の非を認めて、誠心誠意の謝罪をすれば
エンジニアに多少は納得してもらえる可能性はあり、
皆さんの好感度を下げずに済むかもしれません。

言い訳せずに、自分の非を認めることは
実はかなり難しいことですが、頑張って取り組んでみてください。

3. メンバーの仕事に正しく感謝する

お礼の言葉を伝えることには
伝えた側はオキシトシンの分泌によるストレス改善効果があったり、
伝えられた側もモチベーションの向上に繋がったりと
良い効果が沢山あることは様々な記事で書かれています。

また、PMはメンバーに仕事を依頼する側になることが多いので
仕事の完了報告を受ける時に、「ありがとう」と伝えている人も
多くいらっしゃると思います。

それはとても良いことで、
もし仕事が上手くいかなかった報告をもらった場合でも
「調査に取り組んでくれてありがとうございます」
「正直にご報告していただきありがとうございます」など
先ずお礼の言葉から話し始めたほうが
相手が防御姿勢にならないので、
次のアクションについて話を進めやすくなります。

また、お礼をする時に
「そのメンバーの成果に対して適切な評価を伝える」と
より高い効果を発揮します。

そして、そのためには多くの前準備が必要です。

先ず、タスクを依頼する前に
そのタスクの完了条件を明確にしておきましょう。
・タスク完了時に提出される成果物は何か
・その成果物を合格となるために、満たすべき条件はなにか
・その成果物はいつまでに受け取れればよいか

次に、タスクの依頼をする時に、
「期待される結果」を明確にイメージしておきましょう。
・この人に依頼をすると、何%の完成度で返却されるか
・納期を守るためには、進捗確認やリマインドを行うべきか

そして最後に、タスクの完了報告を受ける時に
「期待される結果」と「実際の結果」を比較します。
・成果物は合格条件を期待した%ほど満たしているか
・完了報告のタイミングは期待と比べてどうか

こうすることで、「ありがとう」以外にも
「いつも納期通りに対応してくれるので、安心して任せられます」
「難しいタスクでしたが、頑張ってくれて感謝しています」
「以前よりも良くなっているので、この調子で頑張ってください」
などの言葉を伝えられるようになります。

ここまでやらないと
「ありがとうございます」という言葉は条件反射のようになってしまい
お礼をする側の心が籠らないものになってしまいます。

あなたの依頼した仕事をした相手に対して
心を込めて感謝するように心がけましょう。

4. メンバーの話をちゃんと聞く

PMだけでなく、忙しい管理職の人にも多いのですが、
相手の話が長かったり、要領を得ない場合などに
相手の話を途中で遮って話し始めてしまう人を時々見ます。

上記のようなことをされた人であれば分かると思いますが
された側としてはあまり良い気持ちはしない行動です。

そのような行動を無意識にでも続けていると
メンバーは発言をすること自体に抵抗感を感じるようになり
本来行いたい相談や提案も出来ず、働きにくくなってしまいます。

相手の話をちゃんと聞くためのテクニックは様々ありますが
この記事では私が普段意識しているものをお伝えいたします。

・相手の話を聞くことに集中する
　→資料作成したり、チャットしたりするのを止めて
　　相手の方に視線と体を向けて話を聞きましょう。
　　実際に話を聞いているかより、
　　相手が話を聞いてもらえていると感じることが大事です。

・相手が話し終わるまで待つ
　→相手が話している途中で質問したくなっても我慢して、
　　相手を遮らず、最後までじっと聞きます。
　　ただ時々、永遠に話し続ける人がいますので
　　ミーティング等の時間が限られる状況では
　　話の切れ目を見つけて、優しく止めるようにしましょう。

・聞き終わったら、先ずは相手の意見を肯定する
　→相手の話を聞いて、間違いに気がついても
　　「確かにそうだと思います」「あなたの意見に賛成です」等
　　先ずは相手の意見を肯定しましょう。
　　もし相手の意見を訂正したければ
　　「ただ、別の案として…」等の言葉をその後に続けましょう。

・相手の話を正確に理解する
　→相手の意見がどのようなものであっても
　　相手から見て、あなたが相手の意見を正しく理解していると
　　感じてもらえることが大切です。

　　そうしないと、もしあなたが反対意見を言いたい場合に、
　　相手から見ると、ちゃんと理解せずに反論していると感じられ
　　議論がループしてしまう危険があります。

　　正しく理解できているか不安であれば
　　「私は~~~というように理解したのですが、合っておりますか？」
　　と確認するのもオススメです。

・自分ばかり話さず、相手が話せる時間を作る
　→相手の意見を聞きながら、
　　その意見に対する質問をしたいので
　　早く話を終えてほしいと思ったことはあると思います。

　　相手の話を聞くよりも、自分の話を聞いてもらいたいと思うのは
　　人間の性質ですので、相手も同じことを思っている可能性が高いです。

　　自分の話はできるだけ簡潔にまとめて
　　相手が話す時間をより多く確保しましょう。

5. 余裕のある開発スケジュール

多くのプロジェクトにおいて
開発の納期や、バグをテストで潰せているかについては
厳しくチェックされる場合が多いです。

しかし一方で
コードの可読性の高さや、堅牢さ、変更のしやすさ等々
コード品質に関しては納品基準になっていない場合が多いように感じます。

そのため、無理なスケジュールを設定すると、
エンジニアはコード品質を高めるために熟考する時間が取れず
納得のいかない状態でリリースせざるを得ない場合があります。

そして、追加改修を行う時には
納得のいかない状態でリリースしたことで埋め込まれた負債が
エンジニアの足を引っ張り、開発ペースは下がります。

開発ペースが落ちると、
コード品質を高める活動に使える時間はより少なくなり、
負のスパイラルに陥り、負債はどんどん増えていきます。

そうなると、開発納期は守れなくなるし
リリースする度に不具合が発生するような低品質なシステムになり、
エンジニアは不当に低い評価をされるようになり、
やがてその不満がPMに向かう場合もあります。

ここでは、そうならないための工夫について
幾つか記載いたします。

・スケジュールが適切か実装担当エンジニアに確認する
　→開発スケジュールを立てる前に
　　各機能の開発に必要な工数を見積ると思いますが、
　　この見積もりはPMや営業、リーダーエンジニアではなく
　　実装を担当するエンジニアに作ってもらいましょう。

　　実装を担当するエンジニア本人が見積もることで
　　「その人が対応した場合の工数」を出しやすくなりますので、
　　よりブレにくいスケジュールを立てやすくなります。

　　また、自分自身で作った見積もりであれば
　　責任を持ってスケジュールを守ろうとしてくれる場合が多く、
　　それによってブレにくさが更に増します。

・想定されるトラブルに対応できるようバッファを設ける
　→見積もりはあくまでも実装着手前の予想なので
　　どんなに頑張っても、完璧なものにはなりません。

　　そのため、遅延が起こりやすい作業には
　　ある程度のバッファを用意しておくことがオススメです。
　　※どのような作業が該当するのかを書き始めると長くなるので
　　　それについては別の記事でいずれ書きたいと思います。

　　また、遅延が起こりやすいバッファは作業一つ一つに
　　必要な分を考えて、少しずつ積んでいくのがオススメです。
　　そうすると、スケジュール全体では結構なバッファを持てますが、
　　お客様に説明する時には、そんなに悪目立ちせずに済みますので。
　　※お客様の中にはバッファを嫌う人もおりますので。。。

・エンジニアは早くならないことをPMが理解する
　→前述した通り、エンジニアを急かすことで
　　リリースを納期に間に合わせることは出来る場合はありますが、
　　それは本来必要だった肯定を省くことで、
　　早くなったように見えるだけです。

　　また、アジャイル開発などで
　　スプリントを重ねるごとに開発ペースが早くなることを
　　期待するお客様もいらっしゃいますが、
　　新人でない限りそこまで目に見えてスキルアップはしませんし、
　　エンジニアにとって開発ペースを上げるメリット(昇給など) が無ければ
　　基本的には早くはなりません。

　　お客様が開発ペースを上げたいのであれば、
　　開発するものを絞ったり、不要な開発フローを削ったり、
　　エンジニア自身の高速化以外に出来ることが無いかから考えましょう。

・残業や休日出勤はさせない
　→時々「エンジニアが早くならないなら、勤務時間を伸ばせばいい」
　　と考える人がいますが、私個人としては反対です。
　　
　　確かに超短期的に見れば
　　納期に間に合わせることは可能ですが、
　　残業による疲れや、休日出勤による予定の消滅により
　　エンジニアはとても嫌な思いをします。
　　
　　そして、上記のようなことがあった後
　　エンジニアは見積もりを行う時に、
　　PMには内緒にしてより多くのバッファを積みます。
　　また、PMから工数を短縮できないか相談を受けても拒絶して、
　　自分たちを守ろうとします。

　　そのため、中長期的に見れば開発ペースは遅くなる上に、
　　信頼関係が失われたことで仕事が円滑に進みにくくなり
　　PM個人の仕事も遅延する可能性が高まります。

6. エンジニアから意見を言える

一定以上のスキルと情熱を持つエンジニアであれば、
ユーザーにより良い価値を提供することを意識して
「この機能の仕様をもっとこう変えた方が良いのでは」等々
自分の意見を持ちながら働いている人が多いです。

しかし、エンジニアの立場からすると
直接お客様と話せなかったり、
エンジニアに依頼が来る時点で要件が固まってしまっていたりして、
そうした意見を言えないまま働くことになる場合も多いです。

逆に、エンジニアが意見を言える環境を作り
その意見を取り入れつつ開発案件を進めていくことで、
エンジニアは納得して自分の仕事に取り組めるようになり、
フラストレーションが溜まりにくくなる効果もあります。

そのため、先ずはエンジニアから意見を引き出すために
私がしている工夫について記載します。

・仕様が固まる前にエンジニアにレビューしてもらう
　→開発するシステムの仕様については
　　PMとお客様で相談しつつ固めていく場合が多いですが、
　　ある程度固まった段階で、エンジニアに持っていきます。

　→何を作りたいかだけでなく、
　　何故そのシステムが必要なのかからご説明して、
　　かつ、エンジニアの意見で仕様変更可能であることを伝えます。
　　その上で、現在の仕様がユーザーにとって良いものかを
　　エンジニアと話し合います。
　　
　→ただ、エンジニアとお客様で
　　良いシステムの理想形が違う場合が多いので、
　　最終的にはPMが両方の観点を持って仕様を決めていきますが、
　　このときも、何故その仕様にしたのかをエンジニアに説明します。

・工数を小さくすることばかりを要求しない
　→開発工数を見積る時に、お客様からすれば
　　より小さい方が低コストになるので喜ばれますが、
　　それは開発期間を短くすることでもあるので
　　エンジニアが細部にこだわる余裕を奪ってしまいます。

　→そのため、先ずはエンジニアが
　　「この見積もりだったら安心して開発できる」
　　と思える見積もりを作ってもらい、
　　その見積もりでいかにお客様にご納得いただけるか
　　説明や交渉についてPMが頭を使って考えましょう。
　　そして、どうしてもご納得いただけない場合は
　　スコープを削る、納期を伸ばす等のご提案を考え、
　　エンジニアからもらった見積もりを削らないようにしましょう。

　→また、真面目なエンジニアの場合は、
　　あまり見積もりが大きいと怒られるかと思い
　　自分達に負担がかかるような見積もり数字を出してくる人もいます。
　　そういった場合は、PMからバッファ工数の追加を提案しましょう。
　　大抵の場合はほっとしたリアクションをしてくれます。

・お客様と交渉可能であることを伝えておく
　→エンジニアが開発を進めていく中で
　　どうしても仕様通りの実装が難しい場合や、
　　より良い仕様を思いつく場合があります。

　→ただ、仕様についてはお客様が最終決定権を持っており、
　　PMを介してお客様と交渉する必要がある場合が多いので、
　　エンジニアからするとお客様との交渉は
　　ハードルが高い手段となります。

　→そのため、PMはエンジニアチーム側の人間であることを
　　エンジニアに伝える (又は伝わるような行動) をしておき、
　　お客様との交渉のハードルを下げておきましょう。

7. お客様交渉の透明性

お客様との交渉はPMが担う場合が多いので、
PMがエンジニアに伝える情報は
最終的な結論のみになってしまう場合が多いです。

しかし、交渉結果がエンジニアの期待と異なる場合など
エンジニアからすると、PMの交渉スキルに問題があると感じて
納得して結論を受け入れられない場合があります。

とは言え、お客様との交渉の席に
PMとエンジニア全員で参加すると
コストパフォーマンスも良くないので、
私が普段行っている工夫を下記に記載いたします。

・公開チャンネルでチャットする
　→お客様との交渉をチャットで行う場合は
　　エンジニア全員が参加しているチャンネルで会話をすることで
　　どのような説明をしているのか、お客様は何と回答したのかを
　　ノーコストで共有できます。

　→ただ、時々シークレットな会話 (人員交代など) をする場合もあるので
　　お客様とPMのみのチャンネルも用意しておきましょう。

・エンジニアに伝えるときに背景を説明する
　→エンジニアに結論を伝える時に
　　その結論に至った理由や背景なども説明しましょう。

　→また背景を伝えた上で納得してくれない場合もありますが
　　その場合はより詳細な説明を行ったり
　　お客様と再交渉するなりして、
　　エンジニアが納得してくれるまで対応しましょう。

・時にはエンジニアに会議同席してもらう
　→基本的にはタイムパフォーマンスが悪いので
　　会議への同席は避けた方が良いのですが、
　　会議の雰囲気、お客様の人柄などの
　　口頭では伝えにくい情報を伝えるためには、
　　会議に同席してもらうのは有効です。

おまけ：フリーランスではやりにくい心遣い

最後に、フリーランスPMの立場では難しいのですが、
エンジニアからの好感度を上げるために
社員やマネージャーなら出来る手段は幾つもあります

・給料UP
・ハイスペックなPCの支給
・フレックスタイムの導入 (朝早く出社しなくてもOKとする)
・リモートワークの許可
・取りやすい有給
etc…

これらについては本記事には書いておりませんが
エンジニアから要望があれば、検討してみる価値はあるかもしれません。

終わりに

本記事で記載させていただいた工夫は
誰でもすぐに始められるものが多いので、
もし宜しければ、どれか一つでも実践してみていただけると嬉しいです。

ただ、心遣いだけを意識しても
PMとしての役割をちゃんと果たせていなければ
最終的にエンジニアにしわ寄せが行き、PMの好感度は下がります。

また、エンジニアから好かれていても
お客様や、関連チームから嫌われていては
仕事が上手く回らなくなる場合もあります。

心遣いはあくまでも
良い関係性を築くための1つの要素だと考えていただければ幸いです。

この記事が参加している募集

PMの仕事

1,183件

この記事が気に入ったらサポートをしてみませんか？