IT企業において、技術者からPM（プロジェクトマネージャー）へのキャリア転換は、多くの企業で確立された、一般的なキャリアパスである。
技術者として専門性を深め、確かな技術力を身につけた後、プロジェクト全体を俯瞰し、チームを牽引するPMへとステップアップする。このキャリアプランは、個人の成長を促進するだけでなく、企業全体のプロジェクト成功率向上にも大きく貢献する。
しかし、技術者からPMへの転換は、単に役職が変わるだけではない。
それは、自身の役割、責任、そして働き方を根本から変える、キャリアにおける重要な転換点である。
技術者として培った専門知識を基盤に、プロジェクトマネジメントの知識とスキルを習得し、チームを成功に導くリーダーへと成長する道である。
この記事では、技術者がPMに転向する際に直面する具体的な変化、そしてPMとして成功するために必要な知識、スキル、心構えについてさえずっていこうと思う。
PMの役割とは？
PM（プロジェクトマネージャー）とは、プロジェクトの成功に向けて、計画・実行・管理を行う責任者のことを指す。それに対して、技術者とは、専門的な知識やスキルを活かして、プロジェクトの具体的な作業を担当する人を指す。
PM（プロジェクトマネージャー）と技術者は、プロジェクトを成功させるために協力し合う重要な関係にあり同じ目的を持ちながらも役割や仕事内容が異なるものである。
PMと技術者の違い
PMと技術者は、それぞれ以下の観点で違いがある。
| PM | 技術者 | |
|---|---|---|
| 役割と責任 | プロジェクト全体の責任者であり、計画、実行、管理を担当する | 特定の技術分野の専門家であり、実際の開発や設計などの作業を担当する |
| 主な業務 | 計画立案、進捗管理、リスク管理、予算管理、コミュニケーションなど | 設計、開発、テスト、実装、保守など |
| 必要なスキル | コミュニケーション能力、リーダーシップ、計画力、管理能力、プロジェクト進行面での問題解決能力など | 専門的な技術知識、技術スキル、技術面での問題解決能力など |
| 視点 | プロジェクト全体の成功を重視し、チーム全体の視点から業務を行う | 担当分野における技術的な成果を重視し、専門的な視点から業務を行う |
PMの主な業務範囲（計画、実行、管理）
PMの主な業務は、プロジェクトの計画、実行、管理である。
PMはプロジェクトの各工程において、様々な観点から計画を立て、プロジェクトの状況を管理する必要があるため、タスクを細分化すると膨大な量となる。
そのPMが実施すべきプロセスと管理領域を分かりやすくまとめたものが、PMBOK（ピンボック）である。
PMBOKとは、”Project Management Body of Knowledge”の略であり、日本語では「プロジェクトマネジメント知識体系ガイド」と訳される。
PMBOKで提唱されている、PMが意識すべき5つのプロセス群と10の知識エリアは、以下の通りである。
PMになると変わる様々なこと
初めてPMを経験すると、技術者としてプロジェクトに参画していた時とは異なる、様々な変化を感じるだろう。
技術者からPMに転向した際に生じる変化は、主に以下の通りである。
仕事の内容が変わる
技術者時代は、専門的な技術スキルを活かし、個々のタスク遂行に重点を置く。具体的な業務は、製品やシステムの実装、開発、テストなどである。
PMに転向すると、プロジェクト全体の計画、実行、管理が主な業務となり、チーム編成、進捗管理、リスク管理など、多岐にわたる管理業務を担う。
責任が重くなる
技術者時代は、個々のタスクやプログラム品質、納期に対する責任が中心である。
PMに転向すると、プロジェクト全体の成功に責任を負うことになる。プロジェクトの遅延、予算超過、品質問題など、あらゆる問題に対して責任範囲が大きく広がる。
技術以外の知識が必要になる
技術者時代は、専門的な技術知識や開発スキルを磨くことが重要である。
PMに転向すると、プロジェクトマネジメント（PMBOKなど）、リーダーシップ、コミュニケーション能力、交渉力、財務知識など、ビジネスやマネジメントに関する幅広い知識が必要となる。
対人関係が変わる
技術者時代は、主にチーム内の技術者やプロジェクトリーダーとのコミュニケーションが中心である。
PMに転向すると、チームメンバーに加え、顧客、上司、他部署担当者など、多岐にわたる関係者とのコミュニケーションが求められる。ステークホルダーとの円滑な関係構築と調整が重要な役割となる。
プレッシャーやストレス
技術者時代は、技術的な課題や納期に対するプレッシャーが中心である。
PMに転向すると、プロジェクト全体の成功に対するプレッシャーや、関係者との調整によるストレスが増加する。予期せぬ問題やリスクへの対応など、精神的な負担が増大する可能性が高まる。
自分がやったほうが早いというジレンマ
『自分でやった方が早い』
という考えをいかに早く捨てられるかが、技術者からPMへの転向の速度と質を左右する。
PMに転向した技術者が、ほぼ例外なく最初に抱くのが「自分でやった方が早い」という感覚である。
多くの場合、この感覚は的を射ており、実際のプロジェクトでもメンバーに依頼するよりも、自分が手早く処理した方が開発完了が早まり、高品質なプログラムが完成することは少なくない。
この感覚は、しばしば「自分でやった方が早い病」と揶揄される。
システム開発プロジェクトは、大規模なものであれば複数名のチームで取り組むのが一般的だ。PMは、チームに所属するメンバーをまとめ、それぞれの役割を割り当て、プロジェクトの完了を目指すことになる。
チームメンバーの技術経験は様々で、数十年の経験を持つベテランから、入社間もない新人までが参加することもある。
システム開発の世界では、同じ作業を複数のメンバーに依頼した場合、完成までの速度や品質に差が生じるのは当然のことだ。
そのため、自分のプロジェクトに参加するメンバーの作業速度が遅かったり、プログラムの品質が低いと、どうしても「自分でやった方が早い」と感じてしまうのである。
特に、技術経験が豊富でスキルが高い人ほど、PMになった当初はこのジレンマを強く感じるだろう。
しかし、PMはまずこの考え方を払拭しなければならない。「自分でやった方が早い病」を克服しないと、以下のような弊害が生じるからだ。
- チームの成長を阻害する
- PMが全てのタスクを抱え込んでしまうと、チームメンバーは成長の機会を失ってしまう。
- メンバーは指示された作業のみを行うようになり、自発性や問題解決能力が育たなくなる。
- 結果として、チーム全体のスキルレベルが向上せず、プロジェクトの成功にも悪影響を及ぼす。
- PM自身の負担が増大する
- PMが過剰なタスクを抱え込むことで、時間的・精神的な余裕を失ってしまう。
- 疲労やストレスが蓄積し、判断力や集中力の低下を招いてしまう。
- 結果として、プロジェクト全体の管理がおろそかになり、品質や納期に問題が生じる。
- チームのモチベーションを低下させる
- PMがメンバーを信頼せず、仕事を任せないことで、メンバーが不信感や不満を抱いてしまう。
- 「どうせ自分に任せてもらえない」という気持ちが生まれ、メンバーのモチベーションが低下してしまう。
- 結果として、チーム全体のパフォーマンスが低下し、プロジェクトの成功を阻害する。
PMBOKを知ってるからといってPMが出来るわけではない
PMの仕事をしていると、PMBOK（ピンボック）という言葉をよく耳にする。PMBOKとは、”Project Management Body of Knowledge”の略であり、日本語では「プロジェクトマネジメント知識体系ガイド」と訳される。
プロジェクトマネジメント協会（PMI）が認定する有名なPM資格であるPMP（Project Management Professional）も、PMBOKガイドに基づいて、プロジェクトマネジメントに関する知識と経験が一定水準に達しているかを証明する資格である。
私はこれまで、PMP資格保持者やPMBOKに精通したPMを何人も見てきた。しかし、その方々が必ずしも優れたPMであったとは言えない。
もちろん、PMP資格を保持し、優れたプロジェクトマネジメントを行っていた方も多数いた。しかしその一方で、PMBOKの知識をひけらかしながらプロジェクトを炎上させているPMも少なからずいたのである。
PMBOKを知っているからと言って、PMができるわけではない。なぜならば、PMBOKはあくまで「知識」であり、実際のプロジェクトでそれらの知識を「実践」できるかどうかは別の問題だからである。
PMを担当するにあたって、座学や知識の習得は間違いなく必要である。しかし、知識だけを蓄えても、それを本番で実践できなければ宝の持ち腐れである。
これからPMに挑戦する方は、ぜひ知識の習得に捉われず、実践経験を通してPMとしてのスキルを磨き続けることを重要視していただきたい。
まとめ
今回は、技術者がPM転向する際の変化点や注意点についてさえずってみた。技術者からPMへの転身は、キャリアにおける大きな転換点であり、様々な変化を伴う。
PMBOKなどの知識を蓄えることも重要だが、知識だけでは真のプロジェクトマネジメントは実現できない。
知識と実践経験の両方を積み重ね、より高度なPMスキルを持つPMを目指していってほしい。
