Posted on

なぜ優秀なプロジェクトマネージャーが育たないのか

これまでにPM支援やアドバイザーとして多くのシステム開発会社を見てきて感じることは、優秀なプロジェクトマネージャーが少ないということ。将来的にPM候補となり得る優秀な若手がいても、数年後にはマネジメント職についていて、出世していることを嬉しく思いつつも、PMワークから外れてしまっていることに残念さを感じます。日本の会社組織では、昇進するにしたがって会社組織の管理者となり、自社の活動のための知識や経験が必要なゼネラリストを求められます。しかし、システム開発は、クライアントやプロジェクトの内容によって異なり、ひとつとして同じものはありません。プロジェクトマネージャーは、ゼネラリストではなくスペシャリストとして、ひとつの職種としてあるべきだと思っています。今回は、システム開発におけるキャリアの問題点、プロジェクトマネージャーが育たない理由、会社としての優秀なプロジェクトマネージャーを育成する方法ついて記事にしました。

かんたんイラスト(記事を読む時間のない人へ)

プロジェクトマネージャーへの一般的なキャリアパス

システム開発会社のエンジニアがプロジェクトマネージャーを任されるようになるまでには、一般的に以下のようなキャリアパスを描くことが多いと思います。
当然、いち開発者としてプログラミングから始める人もいれば、SEとして設計からスタートする人もいるとは思いますし、途中からプロジェクトマネージャーではなく製品やネットワークなどのスペシャリストを目指すキャリアパスもあります。
1.開発者からスタート:まずはプログラミングと、その前後の詳細設計と単体テストを担当
2.上流工程を経験:プログラミングの後は、上流である基本設計や要件定義を経験
3.チームリーダーを経験:上流工程を経験したら、チームリーダーのポジションを任される
4.プロジェクトマネージャーへ昇格:いくつかのプロジェクトでチームリーダーを経験したら、いよいよプロジェクトマネージャーを託される

会社員エンジニアのキャリア上の問題点

前述のキャリアパスを本人の希望で歩んでいればよいのですが、本人の意思とは関係なく行われている会社もありますし、そもそも本人に目指すキャリアの希望がない、もしくは目指すべきは管理職で、そのためのステップと捉えている人も多いと思います。ここでは、会社員エンジニアのキャリア上の問題点を3つ挙げます。

1.目指すキャリアが明確に定まっていない
プログラマからでも、SEからでも、エンジニアとしてキャリアの目指すべき到達点が決まっていない人が多いです。プログラミングでも開発言語によって専門性はありますし、SAPやOracle、AWSなどの製品スペシャリストや、ネットワークやOSといった領域の専門家の道もあります。本来は、目指すべきキャリアの方向へ、本人の向き不向きを考慮して歩むべきですが、キャリアの行き先をプロジェクトマネージャーに指定されているかのように、当たり前にプログラミングから設計へ、いち担当者からチームリーダーへというポジション変更が行われることが多いと思います。

2.年齢でポジションを決めてしまう
クライアント企業がシステム開発の委託先ベンダーを選定する場合、しっかりとした評価に基づきベンダー選定を行います。その評価項目には、プロジェクトマネージャーの評価も含まれていますが、ベンダーとしての実績や価格に比べると、PM評価の比重はあまり高くないと思います。一方、提案するベンダー側も、PM任命に関しては、大抵、空いているエンジニアの中から年齢や年次の高い順にほぼ消去法で任命することが実態だと思います(クリティカルで将来の試金石となる案件の場合は、別プロジェクトからの玉突き人事を行うこともあるとは思いますが)。システム開発の業界では、従来、年齢(年次)≒経験≒能力といった暗黙的な認識(イメージ)があります。この背景には、エンジニアは技術職なので、能力を説明するためには経験や実績を伝えることになり、年齢が上であれば経験豊富という思考回路からだと思います。昨今、異業種からのキャリアチェンジでIT業界に入る方も増えてきているので、もはやこの認識は正しくないし、そもそも経験=能力ではないのですが、いまだに年齢や年次でプロジェクトマネージャーを任命する会社もあると思います。

3.優秀だと管理職になってしまう
システム開発に携わるエンジニアにとって、キャリアパスの道筋がどうであれ、プロジェクトマネージャーはゴールの一つだとは思います。一方、いまだにシステム開発の炎上プロジェクトの話題は、いろいろなところから聞き、そのプロジェクトマネージャーはとても疲弊しています。会社組織に属する人にとっては、エンジニアであるよりも会社員であることの方が優位であるため、給与があがるわけでもないのにリスクの高いプロジェクトをやることは出来れば避けたいと思う気持ちも理解できます。会社員エンジニアにとっては、もはやプロジェクトマネージャーは目指したくないゴールになっているのかもしれません。
特に優秀な会社員エンジニアは、プロジェクトマネージャーを通過点として捉え、目指すべきは管理職に昇進することと考えていると思います。積極的にプロジェクトマネージャーをやりたい人、その職を追求したい人は、もはや少ないのかもしれません。

優秀なプロジェクトマネージャーが育たない理由

優秀なプロジェクトマネージャーが育っていない要因は、前述の問題点「3.優秀だと管理職になってしまう」に書いた、会社組織の構造的な問題が関係していると思っています。優秀な人材は、会社において課長や部長などの役職に昇進することが多く、優秀であればあるほど、早い段階からマネジメント業務へシフトしていくからです。
つまり、優秀な人材は早期に昇進しプロジェクトマネージャー職の経験値が少なく、一方、優秀ではない年齢のいった人材がプロジェクトマネージャー職の経験を多く積むという矛盾した構図になっているのです。そのため、プロジェクトに参画する若手エンジニアにとっては、優秀だけど経験値が少ないプロジェクトマネージャー、あるいは優秀ではないプロジェクトマネージャーの下で働くことになります。つまり、キャリアパスのゴールにプロジェクトマネージャーを見据えている若手エンジニアにとっては、お手本となる人がいない環境でシステム開発に携わり、プロジェクトマネージャーとしての考え方やスキルを学習する機会が少ないまま、キャリアを進めていくのです。こんな環境でも優秀な人は自ら感じ取って学び、優秀なプロジェクトマネージャーとして評価されることになるでしょうが、このような優秀な方は、すぐに昇進をして、管理職になってしまうのです。
このような負のスパイラルが繰り返されることが、なかなか優秀なプロジェクトマネージャーが育たない要因のひとつだと思います。
会社によっては、昇進しても、あるいは管理職になっても、複数のプロジェクトを掛け持ちでPM的な役割でプロジェクトに参画することもあるかと思いますが、自社のマネジメント業務と複数プロジェクトを掛け持ちで毎回良い結果を出せるほど、システム開発プロジェクトは簡単ではありません。

SEにプログラミング経験は必要か?

少し話が変わりますが、システム開発に関わる人にとって普遍的なキャリアの疑問として、「SEにプログラミング経験は必要か?」というものがあります。あくまで個人的な見解ですが、「プログラミング経験は無いよりもあった方が良い」と思っています。SEにプログラマ経験があった方が良い理由は、2つあります。

1.小規模プロジェクトでは分業は実質成立しない
昨今、特に大規模なシステム開発案件をウォーターフォール型で進める場合、設計と開発で完全に工程が分かれて、設計工程はSEが、開発工程はプログラマが主役となります。大規模になれば、開発を丸っとオフショアに委託したりもするので、より分業化しています。この分業制のもとであれば、設計とプログラミングのマルチスキルを必ずしも持っている必要はないのですが、小中規模なシステム開発案件になると、設計者がそのまま開発を(あるいは、その逆に開発者が設計を)することはざらにありますし、小規模で分業していたら、引継ぎやリスクを考えるとコスト的にも期間的にもクライアントの希望にミートしないです。つまり、プロジェクトマネージャーからしても、いちエンジニアとしても、上流から下流まで一通りの工程を出来る人の方が有用です。


2.プログラミングを知ることで設計品質を高められる
システム開発において、前工程での漏れは手戻りとなり、ひいては炎上に繋がります。設計工程での漏れの多くは、ケースの検討漏れですが、プログラミングの思考で設計していれば漏れなく検討できていた場面が多々あります。特定の開発言語をゴリゴリに書ける必要はないですが、プログラミングの心得は設計時に役立ちます。また、設計時に実装難易度の感覚を持っておくことで、設計段階から作り込み過ぎを抑制できることもありますので、プログラミング経験はあった方が良いと思っています。

プロジェクトマネージャーに必要な能力とは

前述のSEにプログラミング経験が必要な理由と同様に、プロジェクトマネージャーには、上流から下流まで全工程の経験があることが理想です。少なくとも、無いよりはあった方が良いです。その上で、さらに必要な能力として代表的なものを3つ挙げます。この3つの必須スキルは、設計やプログラミングの技術とは異なり、座学や独学で学習することは難しく、この能力に長けた人の下で働くことで経験と共に学び得ることが必要です。
・論理的思考
プロジェクトマネージャーは、プログラム一つ一つの詳細まで把握することはほぼ不可能ですが、システム全体を俯瞰して理解しておかなければなりません。そのためには部分的に濃淡をつけつつも全体を構造的に捉えることが必要となり、その構造化する能力には、論理的思考が必須です。
・リーダーシップ
プロジェクトマネージャー自身はモノ作りをしません。プロジェクトのメンバーがモノ作りをして、その個々をまとめ、同じ目的へと向かって推進させていきます。そのためには、プロジェクトチームを率いるリーダーシップが必要となります。リーダーシップは技術というよりも考え方だと思います。その考え方に基づいた言動がリーダーシップとして表現されるのです。
・コミュニケーション
単に会話が得意ということではありません。クライアントの本質的なニーズの読み取り、状況によっては、予算や納期の交渉、マネジメントへの適切で簡潔な報告も必要です。
また、大規模プロジェクトになれば、複数のベンダー企業との協業やオフショア開発など立場も文化も異なる様々な関係者とのコミュニケーションが必要となります。
プロジェクトに関わる全ての人が停滞なく効率的に前進するためのメッセージや、時に説得などの様々なコミュニケーションが必要です。

優秀なプロジェクトマネージャーを育成する方法

企業が優秀なプロジェクトマネージャーを育成するためには、キャリアパスや育成計画を立てる必要があります。
ITエンジニアとして上流工程から下流工程まで一通りの経験をさせる人事、複数のチームリーダーポジションのローテーションなど、プロジェクト内ではできることに限界があるため、会社として育成計画を実践することが必要となります。その上で、若手のPM候補が、優秀なプロジェクトマネージャーの下で働き、プロジェクトマネージャーとして必須な能力を経験と共に学び備えていくことで、次の優秀なプロジェクトマネージャーが育成されるという連鎖が理想的です。
具体的には、例えば、会社の中で、優秀なプロジェクトマネージャーを選定し、また将来のPM候補となる優秀な若手社員もピックアップしておきます。この優秀なプロジェクトマネージャーとPM候補をペアリングして、同じプロジェクトに参画させることで、PM候補がプロジェクトマネージャーの正解像を近くで見て学習していくのです。このペアリングを定期的に変えることで、PM候補にとっては思考の選択肢の幅が広がり、より優秀なプロジェクトマネージャーとして育成されることになります。

スペシャリストとしてのプロジェクトマネージャー職を設定すべき

最近のIT業界では、データサイエンティストやAIエンジニアなどスペシャリストの活躍が多く見られます。これらの職種がスペシャリストとして確立した要因には、就職・転職マーケットにおける報酬が高いことや、大手SIerなどでキャリアのひとつとして設定され始めたことが挙げられるでしょう。
オーケストラでは指揮者が最も高額な報酬を得られ、指揮者によってオーケストラの評価が変わります。同じように、プロジェクトマネージャーはプロジェクトの指揮を担うスペシャリストであり、一つの職と言えます。
システム開発会社によっては、既にプロジェクトマネージャーをひとつの職種と設定している会社もありますが、いまだに課長職のような社内をマネジメントする職とキャリアパスを一緒くたにしている会社も多いと思います。マネジメント職とプロジェクトマネージャーのスペシャリスト職は明確に分け、報酬も別に設定すべきです。プロジェクトマネージャーをプロジェクトの指揮に集中させることで、炎上するシステム開発を減らし、そこで働くメンバーも不幸な状況に合わなくてよくなります。さらに優秀なプロジェクトマネージャーの下で働く若手エンジニアも、その仕事ぶりを見てプロジェクトマネージャーをゴールとしたキャリアパスを早い段階から考える人が増えていくでしょう。

まとめ

近年はIT企業が急増し、またクライアントのビジネス競争も激しいため、価格は安く、期間は短く、品質は高く、という高度なQCDが当たり前に求められる世の中です。優秀なプロジェクトマネージャーの必要性はどこの企業も理解していることと思いますし、転職マーケットでもプロジェクトマネージャーの求人が絶えない状況からもニーズに対して不足していると考えられます。一方、会社員エンジニアにとってプロジェクトマネージャーのポジションは、ハイリスクローリターンのうまみの無いポジションであり、炎上した場合には、全ての責任を負い、半端ない苦労をすることも容易に想像できるため、もはや目指すべきキャリアのゴールではないのが実情なのかもしれません。このような状況では、炎上プロジェクトは当分の間なくならないと思います。多くのシステム開発会社でスペシャリストとしてのプロジェクトマネージャー職を設定し、PMを目指す人が増えること、そして、プロジェクトマネージャーに必須な能力を学習できる機会が増えて欲しいと思っています。

出典:柴田秀夫@ARAKADO※転載は筆者承諾済