「伝書鳩」がプロジェクトを静かに破壊する
IT業界の会議室で、私はしばしば奇妙な光景を目にしてきました。クライアントからの厳しい要求に対し、PM（プロジェクトマネージャー）が「分かりました、持ち帰って検討します」と深く頷く。そして開発現場に戻るやいなや、エンジニアたちに向かってこう言い放つのです。「クライアントが明日までにこの機能を追加してほしいと言っている。なんとかしてくれ」。
エンジニアが「今のアーキテクチャでは無理です」「ライブラリの依存関係で不具合が出ます」と必死に論理的な説明を試みても、そのマネージャーは困り顔で繰り返します。「そこをなんとかするのが君たちの仕事だろう？ 私は進捗を報告しなきゃいけないんだ」。
これが、業界に蔓延する「伝書鳩マネージャー」の正体です。彼らは技術を「ブラックボックス」として扱い、自分は情報の右から左へ流すだけの存在だと勘違いしています。工場で言えば、ネジの締め方もラインの仕組みも知らない人間が、ただストップウォッチを片手に「もっと速く作れ」と叫んでいるようなものだ。この無知からくる「丸投げ」が、いかに現場の士気を削ぎ、プロダクトの品質を内部から腐らせていくか、彼らは気づいていません。
技術を知らないことが、なぜ最大の「リスク」なのか
多くのITコンサルタントやPMは、研修時代に少しだけコードを書いた経験を盾に「自分は技術を分かっている」と錯覚します。しかし、現代の技術スタックは日々進化しており、かつての断片的な知識では太刀打ちできません。技術を知らないマネージャーが介在することで発生する最大の弊害は、「顧客の真のニーズ」と「実現可能性」の乖離です。
伝書鳩は、顧客の「こういうことがしたい」という言葉をそのまま鵜呑みにし、エンジニアに投下します。エンジニア側からすれば、それは非効率でバグの温床になる設計かもしれません。しかし、PMに技術的知見がなければ、顧客に対して「その方法は非効率です。代わりにこのライブラリを使えば、コストを半分に抑えて堅牢なシステムが作れます」という逆提案ができません。結果として、無理な設計で無理な実装を行い、出来上がったのは「誰も幸せにならないガラクタ」という悲劇が繰り返されてきました。
本物のPMは「盾」であり「潤滑油」である
一方で、エンジニアから絶大な信頼を寄せられる「本物」のPMも存在します。彼らの共通点は、自らも設計の良し悪しを判断でき、時にはコードの細部まで議論できる技術的バックグラウンドを持っていることです。
本物のPMは、エンジニアの作業を妨げる「障害物」を特定し、それを排除することに心血を注ぎます。例えば、開発チームが難解な不具合に直面している時、彼らは単に「いつ直る？」と聞くのではなく、「このミドルウェアの仕様が原因ではないか？」「あっちのチームが持っているモジュールを流用できないか？」と、具体的な解決策の糸口を提示します。彼らは指示を出す人ではなく、チーム全体の作業効率を最大化するための支援者なのです。
さらに、クライアントとの交渉においても、技術を武器に「守るべきライン」を明確にします。「この機能を今追加すると、将来的なスケーラビリティが損なわれる。だから今は最小構成でリリースし、次フェーズで拡張すべきだ」という論理的な説明は、技術を知る者にしかできません。これこそが、チームを疲弊から救い、プロジェクトを真の成功へと導く「極意」だと、私自身もそうした姿を見ながら学んできました。
まとめ
マネージャーの仕事は、エクセルで進捗率を更新し、綺麗な報告書を作成することではありません。自分の理解できる枠組みの中で業務を細かく分解し、部下に適切な道筋を示すことです。自分ができないことを丸投げし、進捗だけを管理するのは単なる事務処理であり、マネジメントではないのです。
もし、あなたの周りに「コーディングなんてエンジニアがやればいい」と公言するマネージャーがいるなら、そのプロジェクトの先行きを疑ってみてもよいのではないでしょうか。ITプロジェクトにおいて、技術は言語であり、その言語を話せない者が指揮を執ることは不可能だからです。本物のPMへと脱皮するためには、常に技術の現場に寄り添い、エンジニアと共に汗をかく覚悟が求められるのだと思います。