開発プロジェクトでPM（プロジェクトマネジメント）やPMO（プロジェクトマネジメントオフィス）として参加したとき、こんな状況に直面したことはないでしょうか。
エンジニアが新しい技術を使いたいと提案してきたが、リスクが心配で却下した。その後、エンジニアとのコミュニケーションがぎくしゃくし始めた。進捗確認をしても必要最低限の情報しか共有されず、本音が見えない。気がつけば、PM/PMOとエンジニアの間に見えない壁ができていた。
プロジェクトを成功させるためには、エンジニアとの信頼関係が不可欠です。しかし、技術的な判断の違いや、お互いの理解不足から、信頼関係を築けないケースは少なくありません。どうすればエンジニアと良好な関係を構築できるのか。この姿勢は、プロジェクトの雰囲気と成果を大きく左右します。
PM/PMOが壁を作ってしまう現実
エンジニアとの信頼関係構築は、とても難しい課題です。よくありがちな壁を作ってしまう契機は以下のようなものがあります。
第一に、挑戦しようとしていることを最初から否定するスタンスは、信頼関係を大きく損ねます。「この技術は新しすぎてリスクが高い」「実績のある方法で進めるべきだ」と最初から却下してしまう。これはエンジニアだけでなく、挑戦する誰にでも共通することですが、否定から入られると、それ以降の提案をする気がなくなってしまいます。
実績のある技術で着実に進めたいPMと、最新技術やサービスを試したいエンジニア。プロジェクトリスク低減を優先に作業順序を決めたいPMと、作業や課題を深堀して突き詰めたいエンジニア。こうした対立構造が生まれると、コミュニケーションはぎくしゃくし始めます。
第二に、エンジニア気質を理解せず、頭ごなしに注意する、批判するやり方は逆効果です。エンジニアの方々は課題に対する探究心が強い傾向があります。その結果、PMとしては本来やってほしかった次のタスクがあってお願いしていたものの、その作業をやるのではなく、気になっていた課題の深堀をしてしまって、お願いしていたタスクをやっていない、遅れてしまったといったケースもよく見られます。
そのようなことを何度も繰り返してしまうのは問題ですが、とはいえこのようなエンジニア気質をしっかり理解せず、「こっちをやってといったよね？」といったように頭ごなしに注意する、批判するようなやり方は、信頼関係を大きく損ねるでしょう。
第三に、PM/PMOがあまりにも技術的な内容に理解を示さないことも、信頼関係がうまくいきません。技術はエンジニア、PM・PMOは管理・推進というように壁を作ってしまうと、結局エンジニアとの間には壁が生まれます。技術面に対する理解が浅いPM/PMOを軽視してしまうエンジニアの存在というのも現実にはあります。
第四に、エンジニアを作業者と考えるPM/PMOの存在も問題です。「指示を出せば動いてくれる」「指示通り動くべき」という上から目線の態度は、エンジニアのプロフェッショナリズムを軽視しています。こうした姿勢は、すぐに見抜かれます。
このようなところからコミュニケーションがぎくしゃくし、信頼関係が築けないという状況が発生します。このようなケースはどちらかが歩み寄る必要があります。もちろんエンジニアの方が歩み寄ってくれることも多々ありますが、基本的にはプロジェクト推進をするPM・PMOが歩み寄るべきだと私は思います。
エンジニア気質を理解して歩み寄る
私は、エンジニアには特有の気質があることを理解し、PM側がそこに歩み寄り、丁寧にコミュニケーションをとるという姿勢を推奨しています。
エンジニア特有の気質を知る
エンジニアには、以下のような特有の気質があります。これを理解することが、信頼関係構築の第一歩です。
課されたタスクを適切かつ愚直に遂行したいと思っているエンジニアが一定数います。真面目で誠実、与えられた仕事をしっかりやり遂げたいという意識が強いのです。ただし、その結果として目線はミクロになりがちです。目の前のタスクに集中するあまり、プロジェクト全体の優先順位や進捗状況が見えなくなることがあります。
「完了」という言葉一つとっても定義が違うことがあります。プロジェクト全体の前進を第一に考えるPMとしては「それはないよね？」と思うようなことも発生します。例えば、現時点でエンジニア自身ができることが終われば、残作業があったとしてもそのタスクは完了と報告してしまう人もいます。これは悪意があるわけではなく、「自分ができることは終わった」という認識なのです。
エンジニアは新しい提案をしてきます。新しい技術やサービスに興味があり、それを試したいという純粋な好奇心があります。プロジェクトに参加するエンジニアリーダーは、新しいことに挑戦したいという意欲が特に強い傾向があります。プロジェクトのリスクや制約、スケジュールを十分に考慮せず、「この技術を使えば面白いことができる」と提案してくることがあります。
肯定的な姿勢で接し、リスクを一緒に考える
特にプロジェクトの立ち上げ期で、新規開発で技術やサービス選定もできる状況では、エンジニアがやりたいことのポイントをしっかり理解し、肯定的な姿勢で接することが大切です。それをハナから否定すれば、信頼関係を築くことはできません。
取り入れるためにはどうしたらよいのか、リスクは何があるのかを徹底的にヒアリングします。ヒアリング後は、リスクを低減する計画が立てられないかを考えます。例えば、トライアルで導入して検証するPoC（Proof of Concept：概念実証）的な期間を設けられないか、リスクを低減する似たサービスや技術的な手法を調査する期間を設けられないか、といったことです。
エンジニアの提案を受け入れ、一緒にリスク低減策を考える。こうした姿勢は、「このPMは自分たちの意見を聞いてくれる」という安心感を生み出します。
技術的なポイントを押さえて会話する
ただし、すべてを受け入れるわけではありません。「寄り添う」ことと「すべて受け入れる」ことは違います。すべての提案を受け入れていては、プロジェクトのリスクが膨らみ、スケジュールも守れません。
そのために必要なのが、一定レベルエンジニアの気質をしっかり理解し、新しく取り組みたい技術やサービスのポイント、それを導入することのリスクを明確にすることです。PMはエンジニアほど技術やサービスのことはわからないですが、ここをあまりにもおざなりにしてしまうと、結局すべてのジャッジはエンジニアに頼らざるを得ず、プロジェクトを進めることができないと考えます。
例えば、エンジニアが「この新しいフレームワークを使いたい」と提案してきたとき、「どういう利点があるのか」「既存のフレームワークとどう違うのか」「学習コストはどれくらいか」「本番運用でのリスクは何か」といった質問ができる必要があります。
こうした質問を通じて、提案の妥当性を判断し、リスク低減策を一緒に考えることができます。「それなら、まず小規模な機能で試してみて、問題なければ本格導入しよう」といった現実的な調整ができるのです。
技術の細部まで理解する必要はありませんが、エンジニアのプロトコルで会話できるようになることで信頼関係は築けます。技術的な会話ができるPM/PMOは、エンジニアから尊敬され、「このPMは自分たちのことを理解しようとしてくれている」と感じてもらえます。そして、プロジェクト全体を見た調整も受け入れてもらいやすくなります。
プロジェクトで使われる技術の基礎、業界のトレンド、新しいサービスの特徴など、最低限の知識は常にアップデートすべきです。完全に理解する必要はありませんが、エンジニアと会話できるレベルの知識は維持しなければなりません。
否定ではなく理解から。まずはPM側が歩み寄る
エンジニアとの信頼関係構築において、エンジニア気質を理解せず、挑戦を否定したり、頭ごなしに注意したり、技術面に無関心だったりすれば、壁は高くなるばかりです。
必要なのは、エンジニア特有の気質を理解し、PM側が歩み寄る姿勢です。愚直にタスクを遂行したいと思っている、目線はミクロ、言葉の定義が違う、新しい提案をしてくる。こうした特徴を理解したうえで、丁寧にコミュニケーションをとることが重要です。
一定レベルの技術理解を持ち、新しく取り組みたい技術のポイントとリスクを明確にする。そのうえで、プロジェクトのリスクを踏まえて論理的に調整する。このバランス感覚が重要です。
そして、双方の歩み寄りが必要ですが、まず歩み寄るのはPM側だと確信しています。
完璧な正解はありませんが、否定から入るのではなく、理解から始めるという姿勢こそが、エンジニアとの信頼関係を築く鍵なのです。
