プロジェクトリーダーとプロジェクトマネージャーの違い、あるいは会社にとって死活的に大事なのはどちらか？

» 2017/06/12

2015年12月に「会社のITはエンジニアに任せるな」という本を出した。
「経営にとって、ITとは？」がテーマの本なので、「ITを担わせる人材をどう育てるべきか？」という章をもうけたのだが、意外だったのは、「プロジェクトリーダーとプロジェクトマネージャーの違い」という短いコラムへの反応が多かったことだ。
実は用語の混乱を避けるために書いただけなのだが、結構本質的な問いかけも混ざっている。この記事で、少し掘り下げてみたい。
※以下、プロジェクトマネージャー⇒PM、プロジェクトリーダー⇒PLと表記する

★何が混乱の元なのか？
大きめのプロジェクトだと、たいてい体制図が作られ、色んなカタカナの役職の人が登場する。ただ、この手の役職名は会社ごとに定義がマチマチなので、毎回関係者間で「これって結局何をする人？」のすり合わせが必要となる。

日本には、「PMはPLより偉い」というルールを採用している会社が多い。体制図を見ると、「名目上の偉い人≒PM」で「実際に現場を取り仕切る人≒PL」となっていたりする。なので、「要は部長と課長みたいに、偉さの度合いの違いでしょ」と思われているフシがある。
（以下に説明するように、僕はPMとPLについて別の考えを持っているが、お客さんの肩書がすでに決まっている時は、無用な混乱を起こしてもしょうがないので、そのまま受け入れることにしている・・）

更にややこしいことに、重要なプロジェクトでは「実際にこの人はプロジェクトの責任者を務める時間も能力もないけど、入れとかないとマズイからPLという肩書をつけておこう」的な配慮が頻繁にされる。だから実態と名目が食い違うことのほうが多く、観察していても理解は深まらない。
こういう本音と建前の乖離は混乱のもとになりかねないので「なんだかな～」と思うのだが。

★LeadとManageとでは、役割が違う
僕がリーダーとマネージャーについて教わったのはケンブリッジの「プロジェクトリーダーシップトレーニング」でのことだ。アメリカ人が作ったトレーニングなので英語的な解釈も正しいし、内容にもしっくり来たので、以来17年、その用語を採用している。

まず、当たり前の話から。
プロジェクトマネージャーとは、プロジェクトを管理する人のこと。
プロジェクトリーダーとは、プロジェクトを導く人のこと。

どちらが偉いというのではなく、違う仕事なのだ。
僕が教わった、大昔のトレーニング資料から抜粋してみる。

XX_20170611_PLtraining_2_PMとPL.jpg

なんとなくイメージが伝わっただろうか？
この考え方をベースに、当時の自分の仕事について「マネジメント要素」と「リーダーシップ要素」に分けてみた10年前の資料があったので、こちらも紹介しよう。

XX_20170611_PLtraining_2_PMとPL2.jpg

★プロジェクトにおける、PMとPL
上記の比較表を見ると分かるのだが、PMとPLというのは、「人が違う」「別の役職」というよりも、仕事の種類が違う。

PMはその名の通り管理者、つまり予算や進捗状況を把握し、問題があったら調整するのが仕事。しょっちゅうスケジュール表とにらめっこするような姿がイメージに近い。
プロジェクトマネジメントについての知識体系としてPMBOKがあるが、ここで定義されている、

・スコープ管理
・タイム管理（スケジュールなど）
・コスト管理
・品質管理
・人的リソース管理
・コミュニケーション管理
・リスク管理
・調達管理

などの観点でプロジェクトが予定通り遂行されているかをチェックし、問題があれば手を打つのが、まさにPMの仕事となる。

一方でPLとは、プロジェクトチームをまとめ、ゴールまで導くリーダーのこと。
例えばITシステムを構築するプロジェクトで言えば、関係者を巻き込み、納得させ、やるべきことをやってもらい、様々な問題を乗り越えながら、狙い通りのITをつくり上げるのがPLの仕事となる。
もちろんほとんどのITプロジェクトは業務改革と共に取り組むので、業務ルールや役割分担の変更なども同時にPLが取り仕切る。
PMのようなマネジメントの専門スキルというよりは、変革をやり遂げるためのリーダーシップが求められる。

XX_20170611_PLが三者をつなぐ.jpg

PLを「ゴールまで導くリーダーのこと」というだけだと、少し分かりにくいかもしれない。ITに関わるプロジェクトの場合、PLの役割は、プロジェクトに関わる3つの関係者、経営者/業務担当者/IT担当者をつなぐこと、と言い換えても良いだろう。
プロジェクトゴールを説き続けたり、業務担当者から事情を聞き出して整理したり、経営者の代わりに会社としての意思決定をしたり、参加するメンバーのモチベーションを上げるような役割だ。もちろん、経営幹部とプロジェクト方針を議論するのもPLの役割だ。

★PMもPLも役職ではなく、役割
PMやPLというのは役職ではなく、役割のことなので、1人がPMとPLの両方を兼ねている場合もある。もちろん、ほぼ100%PMの人や、ほぼ100%PLの人もいる。
例えば、業務部門出身でITのことなど全く分からないけれども、プロジェクトとして達成したいことのビジョンを描き、IT部門にITのことを教わりながら業務改革プロジェクトをリードするリーダーがたまにいる。そういう人はPM的なスキルも持ち合わせていない代わりに、チームをリードすることはできる、純度100%のPLなのだ。

僕自身で言えば、最初は100%のPMだった。PMの教科書どおり、タスクを整理してスケジュールを引いて、情報の集約と配信に気を配っていた。そしてメンバー（部下）が作るものの品質管理をしたり、尻ぬぐいをしたり。
だが、ケンブリッジに転職して総合的なスキルがあがるとともに、PMは他の人に任せられるようになっていった。それとともに徐々にPL要素が増え、今ではほとんどPL的な仕事しかしていない。

PMは「決められたプロジェクト計画どおりに進んでいるか？」が仕事のベースになる。典型的なPDCA（Plan⇒Do⇒Check⇒Action）のサイクルを回すのが仕事だ。
だが、実際にプロジェクトをやると、それほどきれいなものではない。最初に決めたPlanは後から振り返ると常に曖昧で使い物にならず、走りながらPlanを作っていったり、方針転換していかなければ、ゴールにたどり着けない。スケジュール表とにらめっこするのではなく、そういったことを考え、意思決定し続けるのがPLの仕事となる。
僕は性格的にPLの方が向いているし、やれる人材があまりいないのもPLだと思っているので、必然的に自分をPLにシフトさせていった。

★買ってこれるPM、買ってこれないPL
PMも様々なスキルが必要な専門職であり、優秀なPMは希少資源である。ただし、ノウハウとして確立しており、外から買ってきやすい。優秀なPMをスカウトすることもできるし、システムベンダーに丸投げすることで、PM機能をアウトソースすることもできる。コンサルティング会社もPMOという名目でPM機能を販売している。

一方、PLを外から買ってくることは困難だ。
・関係者を巻き込み、協力を取り付ける
・経営者に代わって、会社として意思決定する
・コストと品質のバランスについて、IT部門に指示を出す
というような仕事は、立場上、社外の人間がやるのはかなり難しい。

※僕らコンサルタントはPL機能を提供するのが仕事だが、それでも建付けとしては、お客さんにPLとして立ってもらい、その補佐をする。それしかできない。

お金を出して外部から買ってこれないからこそ、僕は「経営のスピード、特に変革のスピードは、ITプロジェクトを任せられるプロジェクトリーダーの数で決まる」と考えている。
そして、（PMではなく）PLを任せられる人材を育てることは、極めて重要な経営課題なのだ。

皆さんの会社には、PMだけでなくPLを育てる仕組みがあるだろうか？
ビジネス規模に比して、十分な数のPLが育っているだろうか？

そうではない会社が多いみたいなので、プロジェクトを通じてお客さんのPLを育てる僕らの取り組みが大変評価されている。世の中にとって良いことなのか、分からないのだけれども。

*********************2019/4/12追記

この記事のテーマに関連した本を新たに書きました。「変革をリードできる人材を、プロジェクトの現場で育てる」という本です。
いつもの様に、お客さんと実際にやったプロジェクト事例や図表がぎっしり詰まった本になりました。PLに関心がある方は是非どうぞ。