IT業界に蔓延する『ナンニデモPM』 それ、本当にプロジェクトマネジメント？

最近、社内で「プロジェクトマネージャー（PM）に技術力は必要か？」という議論がありました。
結論から言うと、私はこう思っています。

• PMに“技術力”は必要
• けどそれは、Javaが書ける／AWSの環境を構築できる、のような「実装スキル」ではなく、 技術的に判断できるための技術リテラシー（判断力） のこと

一方で現場や求人票を見ていると、「PMが全部なんとかしろ」案件がわりと普通に存在していて、PMに求められている技術力とPMの業務範囲が拡大しすぎている（＝PMがPMできない）ケースが起きがちです。

この記事では、

• PMとは何をする人なのか？
• PMに必要な「技術力」とは何か？（どのレベルを目指すべきか）
• 「ナンニデモPM」がなぜ危険なのか
• 不適切なPM求人とは？

を、建設（住宅建築）プロジェクトの例えを使いながら整理してみます。
（※建設実務の専門家ではないので、厳密に違う点があればコメントで教えてください！）

1. ITプロジェクトは「家づくり」と似ている

ITシステム構築は、家を建てるプロセスに例えることができると思っています。

住宅建築だと、だいたいこういう役割分担になりますよね。

• 施主（クライアント）：「こんな家を建てたい」という要望を出し、対価を払うクライアント
• 設計（アーキテクト）：施主の要望を構造的に可能な形に設計し、設計責任を持つ専門家
• 施工管理（PM）：予算、工期、品質を管理し、現場が円滑に回るよう調整する管理者
• 職人（エンジニア）：設計図に基づき、実際に釘を打ち、家を形にする技術者

このように、それぞれの役割が明確に分かれているのが本来の姿です。

2. ケーススタディ：もし「大工さん」が1人欠けたら？

ここからが、私が最も違和感を抱くポイントです。

プロジェクトにトラブルは付き物です。例えば、メンバーの1名が体調不良になったケースを想定しましょう。

2-1. 住宅建築：大工さんが1名欠員になった場合

大工さんが体調不良で1名欠けたとします。このとき施工管理は、次のように動くはずです。

• 追加要員（職人）の手配
• 工程の組み替え（優先順位変更、段取り替え）
• 必要なら施主に事情説明し、納期調整

施工管理の人が 「俺が代わりに釘を打つよ」 とハチマキをして大工になることはまず無いと思います。
（小規模なDIYレベルなら別ですが、少なくとも大規模な環境や役割設計としては不自然かなと）

2-2. しかし、IT業界はどうでしょうか？

同じ状況をITで考えます。アプリエンジニアが体調不良で1名欠けたとします。本来は、

• 追加要員の調整
• 影響範囲の見極め（何が遅れるか）
• スコープ・優先順位・納期の交渉

になるはずです。

……が、なぜかIT業界だと PMがエンジニアを兼務して穴埋め が起きがちです。
PMが自らエディタを開き、コーディングを始めてカバーすることが「美徳」として語られることすらあります。
しかも一度起きると、それが常態化し、最終的にこうなる。

「全部盛り何でも屋さんPM（ナンニデモ＝PM）」の誕生

本来の管理業務を捨て、設計（アーキテクト）や構築（エンジニア）の穴をPMが自らの「技術力」と「稼働時間」で埋め続ける末期的な状態。挙句の果てには若手のOJTまで背負い込み、PMのリソースは完全にパンクします。

3. ナンニデモPMは正しい姿なのか？ そもそもPMとは何をする人なのか？

ここで一旦、PMの役割を言語化します。
私はこの整理に、 IPA（情報処理技術者試験のシラバス） がかなり使えると思っています。あとは次点でPMBOKも。

3-1. IPA（プロジェクトマネージャ試験）のPM人物像

IPAのプロジェクトマネージャはレベル4（高度）で、扱っているのは「実装」ではなく、プロジェクトを成立させるためのマネジメントです。

ざっくり言うと、

• 立ち上げ：目的・成功条件・体制・制約の定義
• 計画：スコープ、スケジュール、コスト、品質、リスク、調達、コミュニケーション、ステークホルダー
• 実行・監視：進捗把握、課題・変更管理、意思決定、合意形成、是正
• 終結：受入れ、引き継ぎ、振り返り（ナレッジ化）

みたいな「PMの仕事」が中心です。

（余談）論文試験の対策をやった人はわかると思いますが、 PMが設計・実装に深く入りすぎる文章を書くと、午後2の論文評価が落ちます。
「PMとして何をしたか？」が問われるので。

3-2. PMBOK（第8版）のPM人物像

PMBOKは「プロジェクトマネジメントの標準・知識体系」を、かなり広い文脈で整理しています。
最近の版では特に、

• 価値提供（Value Delivery）
• 状況に応じたテーラリング（Tailor）
• 予測型もアジャイルも含めた複数のやり方の取捨選択

の色が強い印象です。

また、PMBOKではPMのコンピテンシーを定義した「PMCDフレームワーク」が存在します。
ここではPMの専門性を「知識（ITSS相当）」「実行力（成果を出す能力）」「パーソナル（リーダーシップ・倫理）」の3次元で捉えており、「実作業の代行」は明記されていないように見えます。

4. PMに求められる「技術力」とは？

人物像からPMに求められる物事を判断できる “技術力” は、こういう能力だと思っています。

4-1. 「判断できる技術力」とは（私の定義）

• 専門家、技術者が言っていることを理解できる（通訳がいらない、共通言語の理解）
• トレードオフを比較できる（コスト・期間・品質・リスク・拡張性など）
• 赤信号を検知できる（それはやってはいけないよね？がわかる）
• 質問ができる（何を誰に聞けば不確かさが減るか、プロジェクトが前に進むか、がわかる）
• 意思決定の前提条件を揃えられる（論点・選択肢・根拠・影響範囲）

逆に、PMが必ずしも持つ必要がない（持ってたら強いが必須ではない）ものは、

• 特定言語の実装力（Javaで高速に書ける等）
• 特定クラウドの深い構築スキル（AWSの◯◯サービスの設計・運用を一人で回せる等）
• 特定プロダクト／特定領域の属人的な運用ノウハウ（細かなチューニングや手順の暗黙知までを一人で抱える等）

PMが目指すべきは「スペシャリスト」ではなく「指揮官」 のような立ち位置だと思っています。

5. 「判断できる技術力」の目安：IPAのITSS Level3

私は、IPAのITSS Level3（応用情報）の守備範囲が判断できる技術力のベースだと思っています。

応用情報の範囲は、テクノロジだけでなく、マネジメント・ストラテジまで含むので、PMが判断するための 最低限の共通言語・共通理解になりやすいです。

ここでは、応用情報（レベル3）を「PMが判断に使う観点」に変換して表にしてみました。

5-1. PMが押さえるべきナレッジ、理解レベル

分野	大分類（応用情報のイメージ）	中分類（PMが押さえるべき要点）	PMの判断への活かし方（例）
テクノロジ系	基礎理論・コンピュータシステム	アーキテクチャ概念、仮想化・クラウド、OSSの基本	アーキテクト提案の実現可能性、コスト/運用負荷、拡張性をトレードオフ評価できる
テクノロジ系	技術要素	セキュリティ、データベース、ネットワーク	インシデント時の初動判断、変更時のリスク特定、非機能（性能/可用性）議論の前提を揃える
テクノロジ系	開発技術	要件定義〜テストの流れ、品質、DevOps、CI/CD	予測型/アジャイルの向き不向き、品質確保の打ち手、リリース設計（ゲート/自動化）の判断ができる
マネジメント系	プロジェクトマネジメント	工程、コスト、品質、リスク、資源、調達、変更管理	“気合”ではなく数値と根拠で意思決定できる（見積り、バッファ、クリティカルパス、リスク対応）
マネジメント系	サービスマネジメント・監査	運用設計、ITILの考え方、監査/内部統制の観点	「作って終わり」にしない。SLA/運用負荷/保守体制を踏まえて意思決定できる
ストラテジ系	システム戦略・企画	目的、ROI、要求の優先順位、調達の考え方	“やる理由”と“やらない理由”を整理し、投資として説明できる（優先順位・スコープ調整ができる）
ストラテジ系	企業活動・法務	契約、個人情報、知財、下請/取引、コンプラ	契約リスク、情報漏えいリスク、体制・責任分界の「事故りやすい点」を早期に潰せる

※この表は細かすぎない粒度に丸めています。更に詳細化するなら、応用情報のシラバス項目に紐づけていくのが良いかな～と思っています。

6. なぜナンニデモPMは危ないのか？

私が危ないと思う理由はシンプルで、PMがPMできなくなるからです。

全部盛りPMが発生しやすい要因（例）：

• そもそもアーキテクト/テックリード不在（または役割が曖昧）
• 人手不足で、追加要員がすぐ手配できない
• 予算制約が強く「できる人がやるしかない」になりがち
• 兼務の前提でスケジュールが組まれている（最初から無理）
• 技術課題が表面化して“火消し”が常態化している
• 変更管理が弱く、後半に仕様追加が雪だるま式に増える
• ベンダ/委託先の責任分界が曖昧で、結局PMが吸う
• ドキュメント/標準化が弱く、属人化して引き継げない
• 「管理＝事務作業」と誤解され、軽視される

PMが実装側に寄ると、だいたいこうなります。

• ステークホルダー調整が遅れる（意思決定が詰まる）
• 進捗の見える化が遅れる（気づいたら手遅れ）
• リスクの早期潰しができない（後半で大爆発）
• 品質ゲートが機能しない（テスト/レビューが薄くなる）
• メンバーのモチベーションが低下する可能性がある（もう全部PMで良くね？私達いらなくね？）
• 結果としてQCDが落ち、炎上しやすくなる
• 炎上すると社内外のエグゼクティブ層の関与が増え、更に報告が増える（悪循環）

そして、デスマーチと化する……

7. ただ、小規模なら兼務もアリ（DIYレベル）

小さい規模の仕事なら、1人が複数ロールを兼ねるのは自然です。
住宅で言えばDIY。ITでも似ています。

たとえば、

• チーム内の業務効率化の小ツール（ローコード/スクリプト）
• 小規模なRPA・自動化（定型作業の削減）
• 既存SaaSの設定変更や軽微な連携（影響範囲が限定的）
• PoC（失敗前提で学びが目的、スコープが小さい）
• 高いレベルの品質、厳格なスケジュールを求めない

このレベルなら、そもそもPMは不要だと思っていて、リーダー／担当者くらいの呼び方で充分かなと思っています。

DIYレベルならいいんです。本当にDIYレベルならね……

8. 企業の採用担当者にぜひ見てほしいこと

求人票で「PM募集」と書かれているのに、内容を見ると
“PM兼テックリード兼アーキテクト兼エンジニア” みたいなものが時々あります。

求めていることを全て書くのは悪いことではなく、役割名がズレているだけだと思っています。
（期待値ミスマッチが起きやすいのが問題）

8-1. 募集要項の良くない例／危ない例（サンプル）

項目	「ナンニデモPM」の求人例
職種名	プロジェクトマネージャー（PL/テックリード兼務）
仕事内容	・プロジェクトのQCD（品質・コスト・納期）管理 ・お客様、社内CxO,関係部門との交渉折衝 ・様々なシステム全体を俯瞰して、整合性がとれた全体最適化されたアーキテクチャの策定 ・AWS/Azureでのクラウド基盤構築 ・クラウド基盤最適化、チューニング ・緊急時のバグ修正・ソースコードレビュー ・若手メンバー3〜5名の技術指導（OJT）
必須スキル	・PMP、プロジェクトマネージャ試験（PM）等の高度専門資格保持 ・開発費数億円以上の大規模開発のプロジェクトマネジメント経験 ・戦略策定、要件定義から保守・運用までの全フェーズの経験 ・AWS/Azure/GCP等のクラウド基盤環境の構築経験5年以上 ・Java/Python/TypeScript等の開発経験5年以上 ・Terraform/Ansibleを用いたIaCの実装経験 ・大規模DBの設計・運用経験 ・若手メンバーへの育成経験
歓迎スキル	・ビジネス英語レベル（英語でのプレゼンテーションが可能なレベル） ・UI/UXデザインの知識 ・組織マネジメント、ピープルマネジメントの経験
求める人物像	・「自分が最後の砦である」という強い自負がある方 ・スピード感を持って、自ら手を動かして解決できる方 ・様々な難問や困難にも立ち向かい、自分事で物事を成し遂げる方

もし本当に「兼務」を期待するなら、求人票を出す前に「本当に求めているのは誰か」を明確にして、適切な職種名も合わせた方が誠実だと思っています。

ただ…「マネジメントのプロ」と「実装のプロ」を両方求めている…両方をプロレベルで同時進行できる人は正直、市場にほぼ存在せず、いても数千万円の年収が必要だと思っています。
更には 「他人に頼らず、自分の稼働時間で問題を力技解決しろ」というマネジメントの否定。これは本当に危ないです。プロジェクトが危ないのもそうですが、そのメンバーの心身も。

8-2. 募集要項の良い例（サンプル）

項目	健全な「プロジェクトマネージャー」の求人例
職種名	プロジェクトマネージャー（PM）
仕事内容	・プロジェクトのQCD（品質・コスト・納期）管理、変更管理 ・クライアントおよび社内ステークホルダーとの期待値調整、合意形成 ・アーキテクトやリードエンジニアと連携した技術的リスクの早期検知と意思決定 ・WBSの策定、進捗管理、および課題解決に向けたリソースの動的再配置 ・プロジェクト収益（利益率）の管理と予算コントロール
必須スキル	・プロジェクト管理手法（PMBOK、アジャイル等）の体系的な理解と実践経験 ・PMP、プロジェクトマネージャ試験（PM）等の高度専門資格保持 ・数億円規模、または数十名体制の大規模プロジェクトの完遂経験 ・技術的な課題をビジネス的なリスクやコストに翻訳して説明できる能力 ・複雑な利害関係を紐解き、着地点を見出す高度なファシリテーション能力 ・「技術の専門家を信頼し、適切に仕事を任せる」ためのデリゲーションスキル
歓迎スキル	・数十億円以上、または50名以上の体制の大規模プロジェクトの完遂経験
求める人物像	・個人の技術力ではなく、「チームの成果」を最大化することに喜びを感じる方 ・不確実な状況下でも、冷静に情報を収集し、論理的な意思決定を下せる方 ・技術者への敬意を持ちつつ、客観的な視点でプロジェクトの健全性を評価できる方

PMに求められるのは、「自分が手を動かして解決する力」よりも、チームが解決できる状態をつくる力です。
メンバーを信用し、適切に任せ、必要な情報と判断材料を揃え、合意形成と障害除去を通じて前に進める。
プロジェクトは一人では完遂できません。個人戦ではなくチーム戦として勝つために、PMは自分でやるよりもチームでやるを選ぶべきだと思います。

だからこそ、「自ら手を動かして解決できる方」といった表現は、PMの人物像としてはミスマッチを生みやすいと感じています。
それが必要な場面は確かにありますが、そこを前面に出すほど、PMが本来担うべきマネジメント（QCD・リスク・合意形成）が後回しになり、結果としてプロジェクトが不健全になりやすいからです。

9. まとめ

• PMに技術力は必要
• でもそれは「実装できる」ではなく 「判断できる」ための技術力
• 目安として IPAレベル3（応用情報）相当の知識を持つことはかなり有効でわかりやすい指標
• 役割が全部盛りになると、PMがPMできず、プロジェクトが壊れやすい
• 兼務が必要なケースはあるが、ならば役割名と期待値を揃えた方がよい（少なくともPMだけでは違和感）

「自分の現場だとこうだよ」「建設はここ違うよ」などあれば、ぜひコメントいただけると嬉しいです！