プロジェクト・マネージャーに問われる「原点回帰」

記事をシェアする:

著者：上坂 貴志 Takashi Uesaka

執行役員：グローバル・ビジネス・サービス事業本部、サービスデリバリー担当統括・品質担当

AI化が進みプロジェクトの難易度が増している中で、プロジェクト・マネージャーへの期待も高まっています。このような状況下で、プロジェクト・マネージャーとしてより一層の飛躍を実現するためには、今こそ原点への回帰が重要です。このブログではプロジェクト・マネージャーにとって「回帰原点」とは何かを語ります。

プロジェクト・マネージャーの原点！

ウィキペディアには「プロジェクト・マネージャ（英: project manager）とは、プロジェクトの計画と実行に於いて総合的な責任を持つ職能あるいは職務である。プロマネと略されることもある。プロジェクト・マネージャーには系統的な経営管理能力は勿論、透徹とした質問を発し、暗黙の前提を発見し、プロジェクトチームの意見をまとめ上げる能力が必須となる。プロジェクト・マネージャーの職務に於いて鍵となるのは、プロジェクトの実行に影響を与えるリスクを認識すること。同時に、そのリスクについてプロジェクト期間を通じて、公式・非公式に見積もらなければならないことを理解することである。」とまとめられています。IBMのプロジェクト・マネージャーには、まさに「プロジェクトの計画と実行に於いて総合的な責任」を担って頂いていると確信しています。

私がプロジェクトを担当する時は、この総合的な責任に拘ってきたと思っています。プロジェクトの品質、コスト、納期に対して責任を負うだけでなく、お客様が満足してくださるか？ チームメンバーのモチベーション、健康状況は大丈夫か？さらには、 今回のシステムの根幹となる部分は自分の目で設計内容をじっくり見るなどは無論、上司や営業チームへの必要な情報展開もその範疇と考えてきました。

プロジェクトのComplexityや多様性が高まっている今日において「Agile開発でPMなんて必要なのでしょうか？」という声や、「AI化が進むとPMの役割はなくなるのでは？」などの意見をいただきますが、逆に、これは私の持論であり、極論ですが「PMこそ必要であり、真のPMがいればなんでもできる！」と言いたいところです。

これは「独自のプロダクト、サービス、所産を創造するために実施する有期性のある業務」であるプロジェクトには、総合的な責任者が必ず必要だと考えているからです。言い方を変えれば、コンサルタントやアーキテクトやデベロッパーのプロフェッションの方が、プロジェクトの総合的な責任を担っているのであれば、その方はそのプロジェクトのプロジェクト・マネージャーであると考えています。

ただし、その前提として、総合的な責任を担うには、PMBOKに代表されるプロジェクト・マネージメントの知識を有し、これまでのプロジェクト経験を応用した予測と判断、そして情熱を持って取り組まねばならないことは言うまでもありません。

プロジェクト成功の原点は「人」である！

プロジェクトは人が行うものですから、チームの戦力がプロジェクトの成否の鍵を握る最も大きな要素であることは間違いありません。優秀なPMになればなるほど、その重要性を理解しており、何よりも優先して共に戦うチームの組閣に努めます。私自身もそうですが、ここへのこだわりはグローバルのIBMの中でも、群を抜いており、日本IBMのプロジェクト・マネージャーの最も大きな特徴かもしれません。

要員調達の目処が立った後は、チーム力の強化、つまり育成に努めます。このプロジェクトでのOJT（On-the-Job Training）こそ最もスキルアップするものと思いますし、プロジェクトに参画したメンバーがプロジェクトを通じて成長することは、プロジェクトのQCD（quality、cost、delivery）に加えて、プロジェクトの成功を図るKPIと言えると思います。

メンバーを集めることができる人望、メンバーの成長を気遣う配慮、気配り、そして、チーム力を高めるリーダーシップは教科書には書かれていませんが、実践プロジェクト・マネージメントにおいては欠かせない素養だと考えます。中国に「魚をあたえるのではなく、漁を教えてあげろ」という諺がありますが、結果だけを出そうとするのではなく、お客様やプロジェクト・チームに何を残せるかを考えているプロジェクト・マネージャーこそ真のプロジェクト・マネージャーであり、そのような人には自然と人が集まっていると思います。

また、私にとってはプロジェクトに携わる際に「この人の為ならがんばろう！」という動機は非常に大きなものです。これは、その人の人間的な魅力もありますが、プロジェクトの中身に踏み込んで関心を示し、共感を得ることが大きな要素になると思います。プロジェクト・メンバーが ”やらされている” と感じるか、”一緒に作っている” と感じるかは、生産性や品質にも大きな影響を与えるだけでなく、”やりがい” や ”生きがい” といったレベルにまでつながっていると思います。プロジェクト・マネージャーとプロジェクト・メンバーが共感し合えているプロジェクトは、風通しの良いコミュニケーションがとれ、リスクに対する横断的な課題対応なども高いレベルでできており、その結果として、健全にプロジェクトが遂行され、成功につながっていると思います。

プロジェクト・マネージメントの原点！

「プロジェクトは計画に基づいて遂行するものである。」当たり前ですね。では、プロジェクト3大計画書は？といって、ピンと来ない方もいるのではないでしょうか？こちらの3つがそれにあたります。

1. プロジェクト管理計画
2. 全体テスト計画
3. 移行計画

2016年に日本IBMを代表するプロジェクト・マネージャーやアーキテクトが集って作成した「SEハンドブック」にも記載していますが、プロジェクト・マネージャーはこの3大計画の作成に、自らの戦略を込める必要があります。そのためには「今回のプロジェクトのお客様の本当の狙いはなにか？」「システムのエンドユーザーは誰か把握できているか？」にはじまり、プロジェクトの外部要素に依存したり、他システムと結合したり、 先行している案件の対応結果を踏まえて調整するなどのリスク考慮をし、更には、お客様やプロジェクト・メンバーのスキルレベル、特性を鑑みて計画を錬る必要があります。私自身はこの計画作成がなんと言っても、プロジェクト・マネージャーの醍醐味だと思っています。

提案時にはどうしても詰めきれていなかったSOWが具体的になることで、段階的に詳細化していかねばならないことも言うまでもありません。こうした変化への対応姿勢から、真のプロジェクト・マネージャーかどうかが問われます。自ら踏み込んで内容を確認していくプロジェクト・マネージャーと、詳細はチームに任せようとするスタイルの人に分かれます。

自ら確認し、納得した計画であれば、その進捗報告を受けた際にも、自分が想定したレベルと相違がないか？或いは、依存関係のある双方が確認取り合っているかなど、本質的な進捗管理ができると思います。また、共に作成した計画であれば、想定よりも結果的に時間や工数を要したとしても、チームを闇雲に追い込まず、その対策を共に検討すると思います。

逆に、任せきった計画となると、遅延理由や再発防止の妥当性も、任せっぱなしのやり方しかできなくなると思います。予定が間違っているケースも当然あるのですが、なぜ計画と乖離がでたのかを理解せずに「とにかく遅れを取り戻せ！」と問い詰めるのは、マネージメントではないと思います。プロジェクト・マネージャーは計画、すなわち、管理するベースラインをしっかりと確認し、チームと合意した上で、フェアに遂行してもらいたいと思います。

プロジェクト・マネージャーへの期待も難易度もますます高まっておりますが、この原点回帰を徹底いただければ、ますますの飛躍は間違いないと思います。