プロジェクトリーダの役割や必要スキルを徹底解説！PMとの違いとは？
プロジェクトマネージャ(PM)とプロジェクトリーダ(PL)は、どの様な違いがあるのか？とよく質問を受けるのですが、PM/PLは明確に定義されている訳ではなく、「プロジェクトを成功に導く」と言うミッションにおいてPM/PLには差がないのです。
しかしながら、なぜPM/PLと分けられているのかと言いますと、プロジェクトの規模にもよりますが、PM業務に対して役割分担を行い、PM/PLとして守備範囲を狭める必要があるからなのです。もう少し説明を加えますと、そもそもプロジェクトは「規模」や「工数」に比例して、PM業務としての守備範囲が広がります。この様な状態では、PMは細部まで目が行き届かなくなってしまい、直面している問題だけではなく、近未来に発生する可能性があるリスクについても、見落としやすい状態になってしまい、その結果、プロジェクト計画に大きな影響を及ぼしたり、最悪の場合、プロジェクトの遅延や失敗に繋がってしまう事もあり得るのです。
この様な状態を回避する為、PMの業務範囲・守備範囲をPLに分散し、プロジェクトの体制を強化する対策が取られる様になったのです。
では、具体的にPLはどの様な業務を行うのか、どの様にプロジェクトを成功へと導いているのか、ご紹介させて頂きます。
目次
１．プロジェクトリーダとは？
プロジェクトリーダとは、プロジェクトを成功に導く責任を持ち、プロジェクトが抱える技術的な問題・課題をブレイクダウンし、それらを解決へと導く為、チームメンバーを取りまとめる存在や役割を示します。
１-１．プロジェクトマネージャとの大きな違いとは？
プロジェクトリーダとプロジェクトマネージャの大きな違いは、取りまとめる対象・報告すべき会議体・報告すべき相手・対応すべき問題やリスクなど、その「対象」が異なります。具体的な比較は以下の通りです。
表1.1.プロジェクトマネージャとプロジェクトリーダの大きな違い
１-２．担当領域を取りまとめるのがプロジェクトリーダ
プロジェクトマネージャとプロジェクトリーダを比較しますと、対外的な業務範囲と対内的な業務範囲の違いが分かるかと思います。プロジェクトマネージャが全体統制を行うと言っても、末端まで全てを管理する事は不可能な為、領域に分けたグループ若しくはチームを構成し、その範囲を取りまとめるグループリーダやチームリーダを、プロジェクトリーダと呼んでいるのです。
２．プロジェクトリーダの役割
プロジェクトマネージャとプロジェクトリーダの大きな違いをご説明したところで、プロジェクトリーダとしての役割をご説明します。
プロジェクトリーダには、大きく担当領域の「取りまとめ」「問題解決」「メンバー管理」に加え、「他領域との連携」と言う4つの役割に分類されます。
図2.プロジェクトリーダの役割
２-１．担当領域の取りまとめ
プロジェクトのフェーズとしては、大きく「要件定義」「設計・構築」「保守運用」の3つに分類されますが、そのいずれも「グループ若しくはチーム」として担当領域が分割されます。このグループ若しくはチーム毎にプロジェクトリーダを立てるのか、複数をプロジェクトリーダが取りまとめるのかは、プロジェクト規模や予算・企業方針などによって異なりますが、プロジェクトリーダは担当する領域内の「業務タスク」「スケジュール」「工数」「問題・課題」を取りまとめる役割を持っています。
２-２．担当領域の問題解決
後述する「プロジェクトリーダに求められるスキル」でもご説明しますが、プロジェクトリーダは問題解決こそが「仕事」であり、とても大きな役割となります。具体的な問題解決方法などは割愛しますが、どこに問題があり・何が原因なのか、そしてどの様に解決する事が最も望ましいのか等を行います。この様に、担当する領域の問題を把握し、課題へと分析し、メンバーへ的確に指示するのも、プロジェクトリーダの重要な役割となります。
２-３．担当領域のメンバー管理
担当領域におけるタスクを消化するにあたり、プロジェクトリーダが必ず行わなければならないのが「メンバー管理」となります。メンバー管理では、タスクの進捗状況や稼働時間などだけではなく、メンバーの強みとなる技術力や、コミュニケーション力など、プロジェクトメンバーとしての適性状況を把握する事が重要です。プロジェクト規模の拡大と比例し、ITエンジニアが不足している現代では、複数の領域にまたがって活躍するエンジニアも少なくありません。この様なマルチスキルを有するメンバーを見出し、プロジェクト全体として最適なポジションへ推薦する事も、プロジェクトリーダに必要な役割と言えます。
２-４．他領域との連携
プロジェクトリーダは、自チームメンバーを取りまとめ、他の業務チームやプロジェクト全体を繋ぎ合わせ・連携させる役割も持ちます。IT技術の進化・発展に伴い、システムを構成しサービスを提供し続ける為には、ネットワーク・サーバ・ミドルウェア・ソフトウェア・アプリケーション・保守・運用など、多数の業務グループ・チームが必要不可欠となります。これらの業務チームには、それぞれWBS・問題・課題などの管理や取りまとめが必要であり、更に業務チームを横断するプロジェクト課題や全体スケジュールなど、チームとプロジェクト全体を繋ぐ存在が必要となります。これがプロジェクトリーダの存在意義なのです。
３．プロジェクトリーダに必要なスキルとは？
プロジェクトリーダの主な業務は、プロジェクトを成功へと導く為に、担当する領域のWBS作成・チームメンバーへのタスク指示・進捗/問題/課題などの管理及び、プロジェクト全体会議での報告となります。
３-１．プロジェクトリーダに求められるスキル
プロジェクトリーダに求められるスキルを大きく分けると「問題解決力」「高度なITリテラシー」「チーム統率力」「マネージメント力」の4つに分類されます。
図3.1.プロジェクトリーダに求められるスキル
３-１-１．問題解決力
プロジェクトを成功に導く為に必要不可欠なのが、問題解決力です。どれほど計画・調査・検討を行ったとしても、机上の論理だけではプロジェクトは進まず、必ず何からしらの問題やリスクが発生します。この問題やリスクを分析し、課題・タスクとしてブレイクダウンしてメンバーが進めるべき道を示します。問題解決こそが最大の仕事と言っても過言ではないほど、問題の把握・分析・対策を行う能力である「問題解決力」が求められます。
関連記事
３-１-２．チーム統制力(メンバーコントロール)
プロジェクトを円滑に進める上で欠かせないのが「メンバーコントロール」です。その為には、課題・タスクをどのメンバーへ割り振り、どの様に進めさせるかなど、プロジェクトリーダはメンバーの能力・適正・モチベーションを把握していなければなりません。
３-１-３．高度なITリテラシー
メンバーコントロールを行うにしても、メンバーが適正を兼ね揃えているとは限りませんし、必ずしも知見のある技術だけでシステムが構成されるとも限りません。またIT技術の進化により、新しい技術を取り入れる事も珍しくありません。この様な状況の中において、メンバーへ技術的なアドバイスを行ったり、タスクをブレイクダウンして理解させるなど「高度なITリテラシー」が必要となるのです。
３-１-４．マネージメント力
プロジェクトリーダには関係各所とのハブ的な役割がある為、プロジェクト全体会議などへ参加し、全体の状況を把握すると共に「自チームの状況報告」が必要不可欠となりますです。この場面で、自チームの状況を適切に管理出来ていない場合、プロジェクトリーダとしての責務を果たしていないと判断され、場合によってはプロジェクトリーダを降ろされてしまう事もあり得ます。この様にメンバー状況・タスク進捗状況・問題や課題状況など、マネージメント業務が必要な点なども、プロジェクトマネージャの業務と変わりない部分となります。
関連記事
４．プロジェクトリーダの事例
過去にプロジェクトリーダとして対応した事例をご紹介いたします。機密情報である為、詳細な構成・設定などの内容は記載できませんが、プロジェクトリーダとしてどの様に立ち回り、どの様にプロジェクトを成功に導いたのか、参考にして頂ければ幸いです。
４-１．プロジェクトの状態
大手SIerのPMより、「プロジェクトリーダとして力を貸して欲しい」とプロジェクトに召集された際、２ヶ月後にリリース判定が迫っていたが、総合試験における性能が目標値に達しない為、５名の開発プロジェクトメンバーは徹夜で調査・チューニングを行っていました。様々な対応を行っても一向に性能は改善せず、多大な時間を費やしてもゴールが見えない状態となっている事から、メンバーは肉体的・精神的に疲弊しきっていました。いわゆる「デスマーチ」状態だったのです。
４-２．情報の整理
私は早速メンバーを集め「それぞれが調査した内容は整理・共有されているか」確認しました。その結果、当初はファイルサーバにて情報を共有していたものの、結果が出ない事の不満などから、各自が勝手に調査を行い、その情報は整理・共有されていない状態に陥っているとの事でした。次に直近１週間の稼働時間を確認しましたが、全員１週間連続勤務しており、稼働は１００時間を超えている状態でした。
- 情報が整理・共有されていない
- 稼働時間が1日15時間近い
- 休みがない
これら3つの要素は、デスマーチ状態における共通の問題であり、効率の悪い業務を繰り返している事が、最大の原因となります。
問題の確認を行った後、これまで調査した情報の整理及びファイルサーバへの格納を指示し、私はPMの席へ向かい「メンバーを午後には帰宅させ、明日は休みを与えたい」と伝えました。PMからは「リリース判定まで時間がないので、一刻も早く性能が出る様に対応させて欲しい」と言われるのですが、この1日半の休みが、最大のパフォーマンスを発揮させると説き、何とかPMより承諾を貰いました。
関連記事
４-３．周りを巻き込んだ対応
情報の整理・共有を実施させメンバーを帰宅させた後、私は全員の調査範囲・方法・対策をすべて確認しました。当然ですが綺麗にまとまっている訳ではありませんし、それ以前にプロジェクト参画初日なのでシステム確認から始め、徹夜作業となってしまいました。
翌朝、ある程度の情報整理と原因の仮説および、確認ポイントをリストアップしたところで、インフラ (基盤・ネットワーク)チームと他アプリ開発チームのリーダに集まって貰い、現状とゴールを説明し、それぞれのチームにてポイントの確認を依頼しました。すると、ネットワークチームのリーダから「この情報が正しいとすると、ルーティングが誤っている可能性が高い」と意見があがり、インフラを含めた見直しが必要と認識され、全チーム合同での調査が開始したのです。
関連記事
４-４．問題の解決
ここまでの流れが出来上がると、あとは早いものです。調査開始から数時間後、FWに設定されていたルーティングの一部が、その手前にあるルータでスタティックルートとして設定されていた為、本来の設計とは異なったルーティングを行っていた事が発覚。これによりAPサーバからのリクエストに対し、DBサーバの応答が遅延する結果となっていたのです。
(海外拠点を経由していたのには驚きでした。なぜ今まで気付かなかったのかも…。)
その後、1週間程度かかりましたが、別要因でアプリ改修が必要な事も発覚し、リリース判定までに対応しなければならない設定変更・改修作業・再試験などが次々に明確化されました。
４-５．プロジェクの達成
この段階でプロジェクトとしてはゴールが見え、あとは進めるだけなのですが、プロジェクトリーダとしての仕事はまだあります。それは、デスマーチによって狂った「時間感覚の修正」です。
本来仕事とは、「与えられた時間内に、与えられた以上の成果を出す」事で評価されるものです。しかしながら、デスマーチの状態では「まだ22:00かぁ・・・」と時間の感覚がおかしくなり、「まだまだ時間はあるので、後で確認しよう」とか「疲れて来たから少しゆっくり対応しよう」など、本来あるべき「仕事に対する姿勢」を忘れてしまうのです。
これを正す為には一切の残業を禁止し、やむを得ない場合には、私が納得する理由を説明しなければならないルールを制定しました(当然、PMの承認を得た上でのことです)。
その結果、「業務時間内に終わらせなければならない」と意識が変わり、「ヤバい、もう16:00時だ！」と時間間隔が正常化され、無事にリリース判定及びカットオーバーを迎える事が出来たのです。
４-５．これがプロジェクトリーダ
上記事例では細かい説明が出来ませんでしたが、プロジェクトの問題に対し情報の整理・把握・分析を行い、必要であれば周りを巻き込み、必要とあればPMと掛け合い、メンバーを一つに取りまとめ、プロジェクトを達成に導く原動力になる存在。これこそがプロジェクトリーダなのです。
５．さいごに
プロジェクトマネージャとプロジェクトリーダの大きな違いや、プロジェクトリーダとしての役割など、お分かりになったでしょうか。本コンテンツではプロジェクトリーダについてご説明しましたが、あくまでもプロジェクトリーダとは何か？を分かり易く説明したものであり、冒頭に記載した通り、プロジェクトリーダの定義はありません。また、プロジェクトリーダを目指すと言う事は、プロジェクトマネージャを目指すと言う事と変わりませんので、必要な資格や意識などにつきましては、プロジェクトマネージャをご参照頂ければ幸いです。
コメント