AI時代、全員がPMになる — エンジニアの新しい生存戦略
はじめに
エンジニアとして優秀だった人が、PL（プロジェクトリーダー）になり、PMへと昇格する。このキャリアパスで多くの人が躓きます。見るべき景色がガラリと変わるからです。
エンジニアは技術的な正解やコードの品質を追求する。PMはステークホルダーの政治、予算管理、契約リスク、チームの感情と向き合う。「技術的には正解なのに、なぜプロジェクトはうまくいかないのか」——その答えは、PMに求められるスキルが技術力とは別の次元にあることにあります。
そして現代、AIの登場によりこの話はPMだけの問題ではなくなりました。AIがコードを自動生成する今、エンジニアの仕事は「How（どう実装するか）」から「What（何を作るか）」、「Why（なぜ作るか）」へシフトしています。
エンジニア自身が、ビジネスやプロジェクト全体を俯瞰する「PM的な視点」を持たなければ、AIに使われる側のオペレーターになってしまう。これが2026年の現実です。
コードが書ける価値の相対化
LLMの登場により、「コードが書ける」ことの相対的な価値は下がりました。代わりに求められるのは3つの能力です。
設計力。 ビジネスの要件を正しく理解し、AIに適切な指示を出す。「何を作るか」の解像度を上げる力です。
審美眼。 AIが出力したコードがアーキテクチャ的に正しいか、セキュリティ上の問題はないか、パフォーマンスは十分かを判断する力。レビューできなければ、ブラックボックスが積み上がるだけです。
決断力。 AIが出した複数の選択肢の中から「何をやらないか」を決める力。議事録やスケジュール引きはAIがやります。人間は、ステークホルダー間の政治的な調整と、際どい判断に集中すべきです。
「AIに愛された技術」を選ぶ
20年前、IT業界ではLAMP環境の台頭が話題でした。「流行っているから」という理由だけで技術を採用し、「お守り」ができるエンジニアがいないまま走り出す。結果、3年後には誰にもメンテナンスできない「怪物」が残る。
この教訓は20年経った今も有効です。ただし、技術選定の評価軸は決定的に変わりました。
現代の技術選定の最重要基準は「AIによる開発生産性を最大化できるか」です。
学習データの量。 Python、TypeScript、React、AWS——世界中で広範に使われ、膨大なコードがGitHub上に存在する技術。これらはAIにとっての「母国語」です。AIが最も多くのコードを学習している技術を選ぶことで、コード生成の精度もトラブルシューティングの精度も格段に上がります。
移行可能性。 3年後にその技術が廃れたとしても、AIと共にマイグレーションできる見込みがあるか。マイナーなフレームワークは、衰退した時の移行コストが致命的です。
目的の明確さ。 その技術選定は、ユーザーに届ける価値を最大化するための手段か。それとも、自分たちが触ってみたいだけの目的になっていないか。
「安定したトレンドを持つメジャーな技術」を選ぶことは、保守的な選択ではありません。AIという最強のパートナーの能力をフルスペックで引き出すための、最も合理的で攻撃的な戦略です。
理解なき実装 — 最も質の悪い技術的負債
AIがコードを書いてくれるようになった結果、「自分が深く理解していないフレームワーク」でも動くコードを生成できるようになりました。しかし、これは新たな怪物を生み出すリスクを孕んでいます。
20年前、npm install のような手軽な導入手段はありませんでした。技術を採用するには、そのミドルウェアの設定やチューニングを理解する必要があった。導入のハードルが高い分、理解のハードルとの距離は近かった。
現代は「簡単に導入できる」ことと「安全に使い続けられる」ことの距離が、かつてないほど開いています。AIが書いたコードを中身もわからないまま積み上げたシステムは、20年前の怪物よりもさらに凶悪です。なぜなら、表面上は完璧に動いているように見えるから。
「Build vs Buy」の新次元にも注意が必要です。認証はAuth0、決済はStripe、DBはPlanetScale。便利なSaaSを組み合わせるComposable Architectureは合理的ですが、自社の生命線を外部プラットフォームに委ねるという新たな賭けでもあります。
決断の純化 — 作業はAI、責任は人間
LLMがコードを書き、ドキュメントを整理し、複数の選択肢を提示してくれる今、人間の仕事はますます「決断」に純化されていきます。
AIは「平均的な正解」は教えてくれます。しかし、プロジェクトの運命を左右する「際どい決断」の責任は取ってくれません。
膨大なデータの中から、最後は自分の直感と意志を信じて「こっちだ」と指を差す。その指先に宿るエネルギーこそが、チームを動かす原動力です。
翻訳者としてのPM
現代のPMに求められる重要な役割の一つが「翻訳」です。ビジネスサイドは「LTV」「Churn Rate」で語り、エンジニアは「Microservices」「Latency」で語る。この異なる言語を橋渡しする力が、チームの分断を防ぎます。
「このリファクタリングをしないと、将来の機能追加スピードが半分になります（＝機会損失コスト）」——テレワーク時代だからこそ、この翻訳をテキストで高解像度に残すスキルが不可欠です。
同期と非同期の使い分け
テレワーク時代の「お見合い」（タスクの蒸発）を防ぐには、コミュニケーションのメリハリが重要です。
「誰が・いつまでに・何を」は、NotionやGitHubのIssueでテキスト化し曖昧さを排除する。一方で「なぜやるのか」「正念場だ」という熱量は、Google Meetや対面で伝える。
AIに任せられる作業は全て任せ、浮いた時間で人間同士が膝を突き合わせて「未来」を語ること。これこそが、最強のチームビルディングなのかもしれません。
まとめ
20年前、「ヒト・モノ・カネ」の視点はPMだけのものでした。現代、それはすべての開発者の必須教養です。
AIがHowを担い、人間がWhatとWhyに集中する時代。エンジニアにとっての生存戦略は明確です。
- 技術選定は「AIとの相性」を最重要基準に
- 実装は「理解なき積み上げ」を徹底的に排除
- コミュニケーションは翻訳者として、同期と非同期を使い分ける
- 決断は、AIの提示する選択肢の中から「やらないこと」を選ぶ力
お互いへの敬意を前提とした、一切の手加減をしないコミュニケーション。かつて「対等なパートナーシップ」と呼んだものは、現代では「AIを使いこなすプロフェッショナル同士の高度なコラボレーション」へと姿を変えて求められています。