エンジニアの信頼を一発で失う、5つのNG行動
現場で繰り返し見てきた「壁を作るプロマネ」の典型を整理します。
新しい挑戦を最初から否定する
「この技術は新しすぎてリスクが高い」「実績のある方法で進めるべきだ」と、エンジニアの提案を頭から却下する。これは、エンジニアに限らず誰にとっても効果は同じで、否定から入られた相手は二度と本気の提案をしてくれません。
知見も多く、実績のある技術でリスクを抑え、着実に進めたいプロマネ。正直、自分の興味やスキルアップという側面もありつつ、最新の技術やサービスを試したいエンジニア。この構造はプロジェクト立上げ初期にはよく起こります。この対立構造を放置し、プロマネが一方的にプロジェクトを立ち上げようとした瞬間、コミュニケーションはぎくしゃくし始めます。
エンジニア気質を理解せず、頭ごなしに注意する
エンジニアは、課題に対する探究心が強い人が多くいます。プロマネとしては「次にやってほしかったタスク」があるのに、エンジニアが気になっていた別の課題を深掘りして、お願いしたタスクが進んでいない。こういうことは現場でよく起こります。
繰り返しすぎるのは確かに問題です。しかし、なぜそちらを掘っていたのか、その背景を聞かずに「こっちをやってって言ったよね？」と詰める。これは信頼関係を一発で破壊するやり方です。
技術的なことを「わからないので任せます」と丸投げする
技術はエンジニア、管理はプロマネ。そう壁を作って、技術への興味を一切示さないプロマネは、エンジニアから軽視されます。「この人は、自分たちの仕事の中身に関心がない」と判断された瞬間、エンジニアは表面的な報告しか上げてこなくなります。
進捗会議で「で、いつ終わるんですか？」しか聞かない
何が難しいのか、どこで詰まっているのか、何があれば前に進めるのか。そこに踏み込まずに、終了予定だけを問うプロマネは、現場では「催促マシーン」として扱われます。
エンジニアを「指示通り動く作業者」として扱う
「指示を出せば動いてくれる」「指示通りに動くべき」という上から目線は、エンジニアのプロフェッショナリズムを軽視している姿勢です。そしてこの姿勢は、必ず見抜かれます。
エンジニアの本音──「この人、わかってない」
エンジニア視点に立てば、こうしたプロマネはこう映っています。「この人は、こっちの仕事の中身を理解する気がない」「何を提案しても、最終的には却下される」「深掘りした作業の価値を、わかってもらえない」「相談しても、何も返ってこない」。
結果、エンジニアは表面的な「大丈夫です」「問題ありません」しか返さなくなります。本音は別の場所、別のチャンネル、別のコミュニティで話す。
プロマネには「報告通りに進んでいる」ように見える。しかし実態は、もう何も伝わっていません。肌感でまずいと気付いていつつも、もう適切に情報をもらうことすら叶わない。
プロジェクト終盤、想定外の問題が連発する大きな原因の一つです。
エンジニアの「完了」は、プロマネの「完了」と違う
ここで、マネジメントの側面でプロマネが知っておくべき、「エンジニアとプロマネの感覚の違い」に関するとある事例を1つご紹介します。
「タスクの完了」という言葉、プロマネは間違いなくそのタスクで”やるべき作業が全て終わっていること”と定義するでしょう。一方、エンジニアが言う「完了」は、現時点で自分ができることが終わっていれば、残作業があっても「完了」と報告する人がいます。これは、悪意があるわけではありません。
「今、自分ができることは、たしかに終わった。続きは、Aさんの作業が終わらないとできないし、そのタイミングでまたやろう。」という認識なのです。タスクの全量ではなく、あくまで今、自分ができることは、です。タスクを定義したのはプロマネであり、その定義を正しく伝えることなく、完了＝タスク全量と考えるのは、プロマネの思い込みでしかありません。そして、このすれ違いを「虚偽報告」と捉えて怒るプロマネは、エンジニアの言語、感覚、そしてタスクそのものを正しく理解していないのです。
エンジニアの気質は、まず4つの軸で押さえておく必要があります。
愚直さ：誠実にやり遂げたい意識が強い
課されたタスクを、適切に、誠実にやり遂げたいと思っているエンジニアは多いです。真面目で、与えられた仕事をしっかり仕上げたいという意識が強い。ただし、その分、目線はミクロになりがちです。
ミクロ目線：目の前のタスクに集中しがち
目の前のタスクに集中するあまり、プロジェクト全体の優先順位や進捗が見えなくなることがあります。
定義のズレ：「完了」「問題なし」の意味がプロマネと違う
「完了」「問題なし」「大丈夫」といった言葉の意味が、プロマネの想定と微妙に違うことがあります。
好奇心：新しい技術やサービスへの興味が強い
新しい技術やサービスへの興味が強く、純粋に「試したい」「使ってみたい」という欲求がある。プロジェクトのリスクや制約を考慮せず、提案してくることもあります。
この4つを知らずに「指示違反」「報告ミス」「自分勝手」と詰めるプロマネは、ただの監視員に成り下がっていきます。
信頼を取り戻す、3つの歩み寄り方
壊れた信頼を立て直す方法は、シンプルです。プロマネ側から歩み寄ること。JQが現場で実践してきた歩み寄りには、大きく3つの軸があります。
肯定的な姿勢で、リスクを一緒に考える
特に立ち上げ期で、技術選定の余地がある段階では、エンジニアがやりたいことのポイントをまず理解する。「なぜそれを使いたいのか」「どんな利点があるのか」「既存のものとどう違うのか」を、肯定的な姿勢で聞く。
そのうえで、リスクの低減策を一緒に考えます。たとえば、まず小規模な機能でPoC（概念実証）を回せないか。リスクを抑えた似た技術はないか。検証期間を別途設けられないか。「却下する」ではなく「条件付きで取り入れる方法を考える」。
この姿勢が、エンジニアに「このプロマネは話を聞いてくれる」という安心感を生みます。
エンジニアのプロトコルで会話できる技術理解を持つ
ただし、すべての提案を受け入れるのとは違います。「寄り添う」と「言いなりになる」は別物です。すべてを受け入れていたら、リスクは膨らみ、スケジュールは守れません。
そこで必要なのが、エンジニアのプロトコルで会話できるレベルの技術理解です。技術の細部まで完全に理解する必要はありません。
しかし、「このフレームワーク、利点と欠点は何か」「既存のものとどう違うのか」「学習コストはどれくらいか」「本番運用でのリスクは何か」「PoCで検証できる範囲はどこまでか」といった問いが立てられる必要があります。
この質問が立てられないプロマネは、結局すべてのジャッジをエンジニアに丸投げすることになり、プロジェクト全体の整合性を取ることができません。逆に、技術的な会話ができるプロマネは、エンジニアから尊重されます。
「このプロマネは、自分たちの世界を理解しようとしてくれている」と感じてもらえれば、プロジェクト全体の調整も受け入れてもらいやすくなります。
使われる技術と業界トレンドを、最低限アップデートし続ける
プロジェクトで使われている技術の基礎、業界のトレンド、新しいサービスの特徴。完全に理解する必要はありませんが、エンジニアと会話できるレベルの知識は、常にアップデートしておく必要があります。ここを怠ると、信頼の貯金は徐々に減っていきます。
否定ではなく、理解から始める
エンジニアと信頼関係を築く方法は、結局のところ1つに集約されます。否定ではなく、理解から始めること。
エンジニア気質を知り、定義のズレを前提として受け止め、技術の言葉で会話できるようになり、提案に寄り添い、一緒にリスク調整していく。双方の歩み寄りが必要だとしても、最初に動くのはプロマネ側です。これは「立場」の話ではありません。
プロジェクトを推進する側にいる「責任」の話です。
エンジニアから尊重されないプロマネの下で、難しいプロジェクトが成功した例を、私は見たことがありません。技術はエンジニア、管理はプロマネ、と壁を作ったその瞬間から、信頼は静かに崩れていきます。
「なんでこっちやってないんですか？」と聞きたくなったとき、まずひと呼吸置いてください。そこに、なぜエンジニアがそちらを掘っていたのか、聞くべき問いが眠っているはずです。
