PM/PjM/PdM/PL/PMOの違いを解説！

着目する問題：
PM/PjM/PdM/PL/PMOの違い

プロジェクトマネジメントという職能の重要性が社会一般にも広く認知されるようになりました。

言うまでもなく、それはとても良いことなのですが、しかし、プロジェクトマネジメントというものは、わかりそうでわからない、かなり曖昧な概念です。

ある文脈では、PMは、「プロジェクトの責任者」という、ポジションや役割の名称として理解されます。

別の文脈では「プロジェクトを推進、管理する」という、業務や行為として理解されることもあります。

その点があいまいであるゆえに、PM、PjM、PdM、PdM、PL、PMOと、気づけば概念が細分化し、実によくわからない状況が起きています。職業的なプロフェッショナルも、意外とこの点について、あまり深く内省するということはなく、意外と多くの人が、なんとなくのイメージで言葉を使い分けています。

しかし実は、これらの言葉のニュアンスと中身をしっかり理解することには、たくさんのメリットがあります。

～PM、PL等の各概念を、適切に理解するメリット～
●業務の役割分担がしやすくなる
●育成計画が立てやすくなる
●組織構造の見直しが的確にできる

「そういえば、PMとPLって、何が違うんだっけ？」
「PdMって結局のところ、どんな役割なの？」
と、ふと、そんな疑問が湧いた方は、是非、以下の内容をご参考いただけますと幸いです。

ポジションとしてのPMとはなにか

一般的な事業開発におけるプロジェクト組織では、PMのポジション・役割は、以下の表に示すようなものです。

プロジェクト組織には、かならず最終的な責任を負う意思決定者がいます。そうでなければ、プロジェクトは組成されません。通常、その人を、プロジェクト・オーナー（PO）と呼びます。

同時に、どんなプロジェクトでも、作り上げる成果物の仕様を明確にし、それを実現するための設計行為を行う、つまり、具現化をする人がいなければ、成り立ちません。それが「デザイナー」「エンジニア」です。

表のなかにある「UX」や「UI」等の用語から、IT開発（なかでもアジャイル開発的な世界観）を想起される方も多いかもしれませんが、体験設計、意匠設計、内部設計という役割分担は、ITやソフトウェアに限らず、広い分野に共通するものですし、昨今は一般用語としても広まっていますので、この言葉を用いています。

PMという役割の第一義的な意味は、この、意思決定者と実行者の間を取り持つ、というところにあります。つまり、実行計画を立案し、コミュニケーションをスムーズにさせ、こぼれたボールは広い、問題があったら率先して解決にあたる、ということです。

しかしそれはあくまで理想状態での話であり、実践的には、軸足や重心が随分と変わってきます。まさにその、軸足や重心の変化により、PM/PjM/PdM/PL/PMOと、名前が変化していきます。

ただそれらは、個別の場や文脈に依存していて、一般的に定義しようとしても、なかなか難しいものです。ですので、PMとはなんぞや、PjMとは、PdMとはなんぞや、PLは、PMOは？？と、それ単体で、絶対的な意味を問うよりも、これらの言葉が、どのような場や文脈で用いられるか、どんなニュアンスの違いがあるのかに着目するのが、オススメです。

以下の表で、各概念の違いについて、説明します。

名称	違い
一般的な事業会社での PMとPLの違い	一般的な事業組織におけるPMは、管理、調整役の意味合いが強いです。 ・PL：未知に一歩を踏み出し、開発、改善や変革を担うリーダー（上図のPOが近い） ・PM：リーダーを補佐するサポート、軍師役
SI受託開発での PMとPLの違い	SI受託開発の文脈では、以下のニュアンスで理解されることが多いです。 ・PM：開発の総責任者 ・PL：モジュールや小区分ごとのパートリーダー
PMとPMOの違い	大規模開発では、一人ではPMしきれないため、PMOという概念が発生しました。 ・PM：開発の最高責任者 ・PMO：PMの補佐役たち
主にSaaSやアプリでの PjMとPdMの違い	PdMという言葉は、SaaSやアジャイル開発の登場により一躍脚光を浴びました。 こうした場では、以下のように用いられることが多いです。 ・PdM：その製品（事業）の運営、拡張開発全体に対する総責任者 ・PjM：個々の開発案件のパートリーダー

おなじ「プロジェクト・マネージャー」でも、業界やビジネスモデルが変わると、意味合いやポジションの高低が七変化します。

なんだかとっても、面白いと思いませんか？

ちなみに、上の表も、絶対の正解ではありません。会社や業界によるローカルルールもありますので、これが全て、ということではありません。

会社によっては「PMOとPdMが並び立って、対等な関係のもと協力しあう」といったこともあったりします。考えようによってはかなり摩訶不思議な話ですが、どの会社や組織にも、固有の事情や歴史のもとで、ポジション名が冠されていくものですし、深く話を聞いてみると、一見不思議でも、ある程度の合理性があったりします。

そうした話も頭の片隅に置いていただきつつ、おおむね、このように整理をしておけば、ニュアンスや立ち位置の違いがわかりやすいかと思います。

行為としてのPMに必要なスキルや知識、振る舞い

さて、ポジションとしてのPMには、先述の通り、業態や文脈によって多様性がありますが、行為としてのPM二必要な内的資源（知識、スキル、経験、所作）は、意外と共通している部分が多いものです。

①エンジニアリングに関するドメイン知識

これは実は、考えてみたらごく当たり前の話なのですが、行為としてのPMとは、専門知識を持った技術者を始めとする各利害関係者に、行動を促し、差配する、ということです。必ずしも、PMが技術者の代わりに技術を扱う必要はありませんが、知識や知見がないよりあったほうがいいのは、言うまでもありません。場合によっては、信用を得られず、PMとしての職責が果たせないこともあります。

ただし、一分野に対して狭く、ではなく、広く知っていること。そして、原理と仕組みの基本を理解していることが重要です。

以下は、IT開発のPMに必要な知識、知見の例です。

・コンパイル、アッセンブル等のソフトウェア開発における基本概念
・データ形式や構造、データフロー、アルゴリズム・プログラミング等
・オブジェクト指向/MVCモデル等のクラシックな開発方法論
・マイクロサービスアーキテクチャ　非同期処理等のモダンな開発方法論
・C/C#/C++ JAVA PHP等の、クラシックな開発言語
・ruby/python/GO/swift 等の、モダンな開発言語
・React/Vue/Angular ReactNative等のライブラリや開発フレームワーク
・サーバー・インフラ・ネットワークに関する技術的知識（オンプレミス／クラウド）
・機械学習、深層学習、LLM等のディープテックに関する理論と用途開発
・並列処理に等に関するディープテックに関する理論と用途開発
・セキュリティ
・コンセプトデザイン、UXデザイン
・アートディレクション、意匠デザイン
・データ分析、データ可視化
・業務分析や工程分析、管理、改善

こうした技術的ドメイン知識は、当然ながら、機械なら機械、自動車なら自動車、建設なら建設、バイオならバイオと、分野によって異なります。

ちなみに、技術者であればPMができるかというと、そうでもありません。技術者とは、具体的にその設計課題に、答えを出す存在であり、PMは、そのプロセスを支援する、という関係性があります。ゆえに、PM特有の知識・スキルもまた求められます。

②狭義のプロジェクトマネジメントに関する知識

狭義のプロジェクトマネジメント知識は、ドメイン知識と双璧をなすものと言えます。

・当該顧客や商流における、仕様管理や機能設計に関する文化、ルール
・担当する製品の全体像と、そのモジュールや内部構造に関する知識
・担当するモジュールの機能、内部構造、更新履歴、要注意点等への理解
・関連するモジュールとの関係性、影響範囲に関する洞察
・企画構想の意図を理解し、先々に関係する企業や部署、人物を想定する
・仕様書や設計書を理解し、先々に発生する工程や作業、課題やリスクを想定する
・標準的な開発手順とスケジュールを元に、目の前の案件にマイルストンを置く
・問題発生時のリカバリ策立案やトラブルシューティング
・スケジュールや工数・タスク管理
・バージョン管理やドキュメント管理
・見積もり、計画、実績管理
・製造業で求められる一般的な知識のうち、品質管理に関するもの
・同　リスク管理
・同　コスト管理
・PMBOK系の、いわゆるPjMに関する知識体系における用語
・アジャイル、Scrum系の、いわゆるPdMに関する知識体系における用語

③利害関係・社内手続き、コミュニケーション

ある程度、②に含まれますが、特筆して重要なのは、コミュニケーションに関する知識やスキルです。

・関連する法人や部署間の関係性やパワーバランス、キーパーソン把握
・社外ステークホルダーと上層部・ビジネス側と、開発側の関係性への理解
・各業務を進めるための正式な申請、稟議、決裁プロセス
・エグゼクティブとの交流、交渉におけるマナーや語彙
・エンジニアリングや製造、流通現場での交流、交渉におけるマナーや語彙
・各宗教や地域における価値観、禁忌への理解
・社内の公式な会議、文書を扱うためのリテラシ、語彙力
・メールやSlack等の読み書き、レスポンス速度
・オフの場で他者と打ち解け、フランクに付き合える開放性

④ビジネススキル／マネジメント系知識

これもある程度、②に重なりますが、いわゆるMBAビジネス知識、スキルも、基本的なものは必要とされます。

・文書作成
・ロジカルシンキング
・プレゼンテーション
・問題解決
・交渉
・会計、ファイナンス
・経理、財務
・法務、契約
・マーケティング
・組織マネジメント

⑤所作

以上に挙げた、言語化可能なハードスキルに加えて、無意識的な、所作、としか言いようのないものもあります。この所作こそが、PMとしての力の本質だったりもします。

所作には、日常習慣的なものと、問題発生時のような、非日常的なものがあります。

（日常）
・時間を守る、納期を守る、約束を守る
・嘘をつかない　つかなくてよい状況を作る
・細かな数値計算を厳密にし、誤差を小さくする
・ディティールよりも戦略や方向性を大事にする
・少ない情報からより多くを洞察する
・自己主張を抑制し、相手の内心や思いを聞く
・伝聞情報に頼らずに一次情報に当たって事実誤認を抑制する
・コミュニケーションコストを削減するドキュメンテーション
・問い合わせやリクエストに対する応答の迅速性、正確性
・過度にコントロールしようとせず、相手や状況に任せる

（非日常）
・筋を通すために、ときには横車も押す
・柔軟に発想し、変化球を投げる
・複雑な問題でも、答えをとにかく形で出す、示す
・一歩下がって広く見て考える　広く多くの人にメッセージを訴えかける
・他者の思想に働きかけ、制御する

⑥基礎教養、リベラルアーツ

最後の最後、底力になるのが、リベラルアーツです。こうした人類や森羅万象への関心を持つことは、業務に直接関係しないように見えて、実は、PMという行為を支える土台となります。

・哲学、美学
・歴史、国際関係
・マクロ経済、金融
・政治、軍事、戦争
・文化、民俗学、社会学、人類学
・映画、文学、音楽、絵画
・近大数学、物理学、化学
・現代数学、物理学、化学
・工学、解析学、システム工学、人工物工学
・認知科学、行動経済学、進化生物学
・建築、都市開発、地域社会
・遊戯　ゲーム

PM概念別の、内的資源の優先順位

上記の内的資源は、PM概念によって、必要とされる領域が微妙に異なります。

代表的なロール別の色分けを、以下の表で示します。

領域	事業開発 におけるPL	SI開発 におけるPM	PMO	PdM
①技術的ドメイン知識	★	★★★	★	★
②狭義のPM知識	★★	★★★	★★	★★★
③コミュニケーション	★★★	★★	★★	★
④ビジネススキル	★★	★	★★★	★★★
⑤所作	★★	★★	★★★	★★
⑥リベラルアーツ	★★★	★	★	★★

いかがだったでしょうか、具体的に考えていくと混乱しやすいPM概念について、参考になれば幸いです。

PMには、ポジションとしての側面と、行為としての側面がある。
ポジションとしてのPMは、文脈によって意味が変わる。
行為としてのPMを支える内的資源は、ある程度共通している。

と、このように、考えてください。