**PMOとは「Project Management Office」の略称で、プロジェクトマネジメントオフィスと呼ばれえることもよくあります。**プロジェクトマネジメントと似ているポジションで、*プロジェクトマネージャー（以下、PM）をサポートし、システム開発の効率の向上などプロジェクトを成功に導く職種です。*

また、PMOの仕事内容はPMと類似する点も多いです。よって、PMOはプロジェクト案件の成功に大きな影響を与える重大な責任を抱えています。例えば、プロジェクトにおいてPMやPMOが上手く機能していない場合、プロジェクト管理が滞ってしまいシステム開発が失敗することも少なくありません。

システム開発のプロジェクトに必ずPMOが必要というわけではないですが、小規模なシステム開発プロジェクトの場合、PMだけでプロジェクト管理することも多いでしょう。*一方近年ではシステム開発が大規化したり複雑化したりしているため、PMOを導入することも増加しています。*ここからは、PMOの役割とPMとPMOの違いについて詳しく解説します。

PMOの役割は、品質管理やスケジュール管理・コスト管理・人材育成などのプロジェクト管理の幅広い範囲に及ぶことが多いです。他にも、システム開発の方針書の作成やトラブルが発生した場合の原因究明や再発防止を行うこともあります。**端的に説明すると、PMOの主な役割はシステム開発の進捗状況が納期などをもとに計画したスケジュール通りに進んでいるか管理することです。**また、大規模プロジェクト案件の場合、PMOが複数人登用されて役割を分割する場合もあります。

例えば、大規模システム開発プロジェクトにおいて、PMが1人ではプロジェクト全体を管理することは物理的にも不可能と言えます。よって、PMOはPMに代わってプロジェクトの進捗管理などを担当し、PMの仕事をサポートします。

*以上からも、PMOは担当する仕事の範囲はプロジェクトごとに異なることも多いです。*一般的にはPMOのチームがあり、担当する業務を分担をしてそれぞれ仕事を行います。

**PMとPMOの大きな違いとして、マネジメント権限が挙げられます。**PMはプロジェクト全体を管理するのに対して、PMOは大規模プロジェクトのなかの与えられたプロジェクトを管理します。*したがって、プロジェクト全体を管理するのがPM、全体の一部をマネジメントするのがPMOと言えるでしょう。*

*しかし、担当する業務は異なれど、仕事内容はPMとPMOでは大きな差はありません。*プロジェクトの進捗・品質・コストなどを丁寧に管理し、システム開発のプロジェクトをスムーズに完遂させるという目的はPMもPMOも同様です。つまり、PMOはPMを支える存在です。これまでのプロジェクト管理では、PMの知識や経験などのスキルのみに頼ることが多かったです。

最近では、PMOを登用して組織的にサポートするという体制がシステム開発プロジェクトなどではあります。特に大規模や複雑なシステム開発のプロジェクト案件ではPMOは必要不可欠な存在と言えるでしょう。

ここからは、PMOの職種とその役割について詳しくご紹介します。

**PMOアドミニストレーターは、社内業務の管理をスムーズに進め、事務作業をサポートします。**PMOアドミニストレーターの仕事内容も多岐に渡ります。例えば、プロジェクトに関するデータの収集・分析・情報の共有・会議の調整・経費の精算・書類の作成・メンバーの勤怠管理などが挙げられます。

PMがプロジェクトの事務作業を実施する場合、負担が非常に大きくなり、他のことに手が回らなくなってしまうこともあります。*よって、PMOアドミニストレーターがPMの事務作業をサポートすることで、PMはよりクリティカルばプロジェクト管理に集中することができるでしょう。*

**PMOエキスパートは、プロジェクトのルールを策定し環境改善を行い、プロジェクト管理を画一化させる役割をもっています。**PMOの職種のなかでも幅広い業務を行うため、知識や経験などの高度なスキルが要求されます。

主な仕事内容は、プロジェクト進捗の可視化や文書化、プロジェクトにおける情報収集方法の構築やその社内定着の実施、プロジェクトで扱うツールの開発や改善、顧客の要件やニーズの把握、人材育成などが挙げられます。*PMOエキスパートには、プロジェクト管理に関する豊富なスキルをもっている人材を配置することで、よりスムーズにPMの支援が行うことができるでしょう。*

**PMOマネージャーは、PMOチームを管理するための業務を行う役割をもっています。**主な仕事内容は、PMO組織戦略の確立、PMOメンバーの勤怠管理や教育、PMO組織の予算管理、プロジェクトにおけるルール管理、プロジェクト成果の安定化などが挙げられます。*PMOも組織となる場合が多く、1つの部門として扱われるため、PMO組織を管理するマネージャーが必要です。*

## PMOを導入するメリット・デメリット

ここからは、PMOを導入するメリットとデメリットについて解説します。

**PMOを導入する最大のメリットは、システム開発の進捗管理が徹底できる点です。**小規模のシステム開発プロジェクトの場合、PM1人でプロジェクト全体を管理することも可能でしょう。しかし、プロジェクトが大規模や複雑になるほど、PM1人でプロジェクトを管理することができなくなります。

近年では、新しい技術への対応や働き方の多様化などで、協力会社などの人員管理の手間も増加傾向にあります。PMOを導入すれば、PMの管理業務の負担減少につながり、プロジェクトが円滑に進行させることが期待できるでしょう。*したがって、PMOを導入することで、プロジェクト管理の強化に直結させることができます。*

**PMOを導入するデメリットは、進捗管理に重視しすぎて、コミュニケーション不足や他部署への無関心をもたらしてしまう可能性があることです。**PMOが進捗管理に関して集中しすぎると、現場の細かい部分に気を取られてしまうことも多くなります。

*PMOの主な役割は進捗管理ですが、最も重視すべき点はプロジェクト案件を成功に導くことです。*進捗管理にのみ注力しているPMOも少なくありません。進捗管理にのみ追求してしまうと、各部門との連携が上手くとれず、業務の境界が曖昧となり、グレーゾーンといわれる部分は誰も手をつけない場合もあります。これではプロジェクトは失敗してしまいます。**PMOの仕事はプロジェクト管理するだけではなく、チームメンバーの人間関係を適切に築き上げ、チーム全体の能力を向上する役割もあることに注意する必要があります。**

ここからは、PMOに求められるスキルについて4つご紹介します。

### プロジェクトマネジメントに関するスキル

**PMOにはプロジェクトマネジメントに関するスキルが必要です。**PMOはプロジェクトの意思決定を実際に行う場合は少ないかもしれませんが、プロジェクトの計画立案や進捗管理には大きく関わることが多いです。例えば、大規模なプロジェクトでチームが多数ある場合、PMOはプロジェクト開始時点における体制の構築・人員の配置・予算の組立などを担当します。

また、プロジェクト開始した後もプロジェクト全体の管理やPMの支援業務に関わることとなります。*そのため、これまでのプロジェクトに参加した経験や、プロジェクトマネジメントに関する高度なスキルが要求されるでしょう。*

PMとPLの役割の違いとは？ ―若手エンジニアの疑問にスッキリ回答―

**プロジェクト管理の中でも、PMOにとって最も重要な業務が進捗管理です。**納期遅延を起こさないことやコスト削減を実現させるために、常に周囲から情報収集を行い、プロジェクトの進捗状況を正確に把握することが求められます。例えば、トラブルが発生した場合、障害の状況を整理するスキルも必要です。

また、リスク予測を事前に行い、早いうちに対策するスキルも求められます。さらに、システム開発のプロジェクトの場合、人員の入れ替えが激しいため人事マネジメントスキルもあると良いでしょう。

### システム開発に関するスキル

**PMOは、必須ではありませんが、システム開発に関する知識や経験をある程度もっていると企業から重宝される人材となることができます。**PMOが実際にプログラミングなどの開発作業を行うことはありませんが、開発にかんする知識や実務経験がある場合、PMや現場のエンジニアとの相互理解がより深まり、システム開発プロジェクトの進捗状況などについて正確に理解できるでしょう。

スクラム開発とは？エンジニアが知っておきたい情報をまとめました！

**PMOにはコミュニケーションスキルが求められます。**プロジェクト全体の調整を担当することから、コミュニケーションスキルは欠かせません。PMOは、PMや顧客とやり取りすることが多いです。また、PMやエンジニアを集めて会議を行う場合、PMOはファシリテーターを担当することも多いでしょう。

## PMOを導入してシステム開発の効率を向上させよう！

これまでにPMOの詳細やPMとPMOの違い・PMOの職種・メリット・デメリット・PMOになるために必要なスキルについて解説しました。PMOの業務は多岐に渡り、職種も多数あります。**PMOの主な役割はシステム開発プロジェクトの進捗管理です。**また、PMとPMOの違いは、プロジェクト全体を管理するのがPM、全体の一部をマネジメントするのがPMOと言えます。PMOを導入することで、**PMの管理業務の負担減少につながり、プロジェクトを円滑に進ませることができるでしょう。**

PMOが担当する役割は、プロジェクトが大規模や複雑になるほど大きくなる傾向があります。PMOも複数人で担当する場合も多く、チームワーク力も重要です。また、近年ではPMO配置のためのサポート活動も活発に行われています。*エンジニアとしてのキャリアアップの選択肢の1つとして、PMOを選択してみるのはいかがでしょうか。*

PMOはプロジェクトマネージャーをサポートし、システム開発の効率の向上などプロジェクトを成功に導く職種です。当記事では、PMOの詳細やPMとPMOの違い・PMOの職種・メリット・デメリット・必要なスキルについてご紹介します。

PMOの主な役割はシステム開発の進捗管理を行うこと

プロジェクト全体を管理するのがPM、全体の一部をマネジメントするのがPMO

PMOを導入することで、PMの管理業務の負担減少につながり、プロジェクトを円滑に進ませることができる

PMOの役割とは？メリット・デメリット、必要なスキルも紹介！

EVMとは｢Earned Value Management(アーンド・バリュー・マネジメント)｣の略語で、**プロジェクトにおける計画、作業工程、成果物などを全てコストに換算し、｢計画(予算)｣と「実績｣、｢要したコスト｣を比較して、｢どの程度進んだのか｣｢費用はいくら掛かったのか｣を把握するための手法**です。

これらを分析することで、**プロシェクトの進捗状況を把握し、将来的に発生する可能性のある問題を予め察知**します。このようにEVMはコストの視点を取り入れたプロジェクト管理の有効な手法のひとつです。

EVMは元々、米国総務省における物資調達規則の一部として制定されたのが始まりです。その後、国家的なプロジェクトのパフォーマンスを上げるために何度も見直しが行われ、発展を繰り返しています。

**EVMの大きな特徴は、従来のプロジェクト進捗管理においてはメジャーな指標だった時間軸だけではなく、コスト指標を取り入れた点です。**日本においては、経済産業省において*EVMに関するガイドライン策定の動き*があり、今後政府案件では、受注条件に「EVM」を用いた管理の採用を含めるべきとの意見もあります。

### これまで利用されることが多かったのは、PERT図とWBSという手法

これまでIT開発のプロジェクトでは、プロジェクト管理に*PERT図*や*WBS*がよく利用されていました。これらは時間軸（スケジュール）でプロジェクトを管理する手法です。

*PERT図*は、なじみのある方が多いと思いますが、プロジェクトの流れや所要時間を図に表し、業務計画を立てます。

 複数の作業が並行して行われるプロジェクトでは、1つの作業が遅れると他方の作業が遅れ、結果として全体が遅れます。このように、*各作業間の依存関係や重要性がよく分かり、進捗管理がしやすいというメリット*があります。

一方で*WBS*も、よく用いられる手法なのでご存知の方が多いと思いますが、プロジェクトの目的達成に必要なタスクを洗い出し、各タスク毎のスケジュールを明確にします。*各タスクの工数も見積もるため、全体工数が把握でき、進捗管理がやりやすくなるというメリット*があります。

**いずれも進捗管理の指標は時間です。それらに対し、コストとスケジュールの両面から管理するのがEVMです。**

PERT図とは？目的・種類・構成要素・作成方法とメリットを解説！

IT開発プロジェクトで必須のWBSについて、改めて見直してみよう

あなたが仮にプロジェクトリーダーを任され、EVMを用いたプロジェクト管理を行うことになったとしましょう。プロジェクトメンバーには、EVMについて説明をしなければなりません。

しかも簡潔に、分かりやすく説明をしなければ、メンバーはあなたに従わないかもしれません。かといって、勉強会を開くほどの時間もありません。そんな時は次のような説明してみてください。

**「EVMはプロジェクト管理の手法で、すべてをコストに換算し、計画に対して進捗をコストで管理するやり方です」**と。

では続いてEVMに対する理解を深めるため、EVMを採用するメリット、デメリットについて考えてみましょう。

## EVMのメリット・デメリットについて

経済産業省によるガイドライン策定を筆頭に、日本国内において導入しようという動きが高まっているEVMですが、メリットだけではなく、もちろんデメリットも存在します。

ここでは、そんなEVMのメリットとデメリットを解説します。

前述の通り、EVMはコストによる管理を取り入れたプロジェクト管理手法です。それを踏まえたうえで、次の2点が*メリット*として挙げられます。

*1.プロジェクト管理をより客観的に管理ができる*
従来のプロジェクト管理手法はあくまでもスケジュール面の進捗管理が主であり、「計画に対して遅れている」「計画よりも早く進捗している」という点でしか、進捗が把握できませんでした。

**EVMにはコスト指標が加わり、コストマネジメントの要素が入ることで、より客観的、合理的な判断や意思決定を促す**ことができます。

*2.プロジェクトの予測精度が高まる*
プロジェクト管理に**コスト指標が加わったことで、将来予測の精度が高まります。**例えば、プロジェクトの折り返し地点で、スケジュール進捗率が50%、予算進捗率が50%なら、プロジェクトは予定納期と予定コスト内で収まる可能性が高いことが分かります。

仮に予算進捗率がスケジュール進捗率を上回っている場合は、コスト圧縮策を講じる必要が出てきます。逆に予算進捗率がスケジュール進捗率を下回っている場合は、さらなるリソース確保が可能と判断され、*いずれにしても早めの対策を打つことができます。*

一見、万能に思えるEVMですが、次のような*デメリット*を抱えており、プロジェクトの前に何らかの補完策を講じておく必要があります。

*1.品質コントロール機能がない*
EVMにはコストとスケジュール以外の指標がなく、**品質を管理するためには別の管理手法を追加する必要**があります。

*2.クリティカルパスが不明確*
プロジェクトの工程にはクリティカルな工程があります。この工程を他の工程と同様にコストだけで管理すると、その工程で問題が発生した際に、他の工程や全体工程に影響を及ぼす可能性があります。

**クリティカルパスはプロジェクト管理の基本ですので、必ずこの管理手法を除外しないよう気を付ける必要**があります。

ここまでで、EVMの概念はある程度理解されたかと思います。続いて、*EVMの構成要素*について触れておきます。次の(a)から(e)まで、5つの構成要素(指標)は頭に入れておいてください。

### (a). PV (Planned Value)－計画価値

**計画作成段階で見積もった予算**を意味し、ある期限までに完了しなければならない作業に対する総予算・総コストのことです。たとえば「〇〇ツールの開発にあたり、1カ月間に必要な予算はいくらか」という視点で、主に開発要員のコストを推定して算出することです。

1カ月間に人件費が50万円/月の初級プログラマーを投入する計画であれば、PVは50万円です。50万円が基準値(ベースライン)となり、60万円/月の中級プログラマーを投入した場合は、10万円のコストオーバーが発生し、この10万円が基準値からの*遅れ*と判断されます。

### (b).AC (Actual Cost)－実際に要したコスト

**ACは実コストのことで、ある時点から特定の時点までに要したコストのこと**です。

例えば「〇〇ツールの開発にあたり、1カ月で実際にかかったコストは60万円」というようにACを用いて表現します。

### (c).EV (Earned Value)－出来高実績値

**EVMのEVのことで、｢出来高実績値｣とも訳されます。**作業の達成度を時間で判断するのではなく、金銭的価値に置き換えて判断します。

AC(実際に要したコスト)に対するEV(出来高実績値)の比率を*CPI(Cost Performance Index)*と称します。CPIは「コスト効率指数」という指標で、*『EV ÷ AC = CPI』*の算式で表され、1を下回るとコスト超過と判断します。プロジェクト進行管理で、コストが予算内に収まっているか否かを判断する際に用います。

### (d).SV (Schedule Variance)－スケジュール差異

**SVはスケジュール差異を示します。EV(出来高実績値)と、PV(計画価値)の差分です。**

*『EV ‐ PV = SV』*の算式で表され、結果がプラスなら、オン・スケジュールと判断し、結果がマイナスならスケジュール遅延と見なします。

 例えば、「〇〇ツールの開発」にあたり、2カ月目までのEV(出来高実績値)が80万円、2カ月目までのPV(計画価値)が70万円なら*『EV(80万円）－PV(70万円） = SV(10万円）』*で、スケジュールは計画よりも早く進んでいると判断できます。

### (e).CV (Cost Variance)－コスト差異

**CVはコスト差異を示します。AC(実際に要したコスト)と、EV(出来高実績値)との差分です。**

*『EV－AC = CV』*の算式で表され、結果がプラスなら、その時点でのコストは予算内、マイナスの場合は予算オーバーと判断できます。

例えば、「〇〇ツールにあたり」、2カ月目までのEV(出来高実績値)が70万円、2カ月目までにのAC(実際に要したコスト)が90万円なら、*『EV（70万円）－AC(90万円）= CV(－20万円）』*となり、予算オーバーと判断します。

以上5項目がEVMの基本的な指標です。EVMに対するイメージが明確になったのではないでしょうか?まずはプロジェクト管理でこの5つの指標を実際に用いてみることをおすすめします。

従来型のIT開発プロジェクトにおいて、主に重きを置かれたのはスケジュールでした。納期厳守のためにSEやPGの徹夜を黙認するような風潮すらありました。この結果、**プロジェクトが終了してから、予算オーバーが発覚するという事態が常態化**してきました。

これは、日本のIT開発の生産性が高まらない1つの原因と見られています。*EVMがそのスケジュール偏重のプロジェクト管理を打破する1つの手段*です。

EVMと聞くと、何か難しいことのように感じますが、この記事をお読みになられた方は意外に簡単だということを理解されたと思います。

**EVMでは、EV(出来高実績)、PV(計画価値)、AC(実コスト)の各指標について縦軸をコスト、横軸を期間とするグラフで、3本の曲線で表します。**

このグラフを基にして、*リソースの使用状況が明瞭になり、完成時点の数値まで見積もることができます。*EVMの管理をする上で、このグラフを用いることで「予算に対して、消費したコストは下回っているのか、上回っているのか?」、「使用したコストに対して、成果は上回っているのか、下回っているのか?」が一目瞭然となり、**プロジェクト内の情報共有や上層部への進捗報告にも有効なツール**になるでしょう。

**EVMは計画と実績の見える化**です。各指標は数字で表さなければなりません。数値化するには*人的資源能力*や*品質出来高*をいかに定量的に把握するかによって、精度が変わってきます。まずはこれらの指標の客観的根拠をしっかり形成することが求められます。

*正しい人事評価制度、品質評価の仕組みが必要*になります。関係者で知恵を出し合って、皆が納得し得る基準を設けることで、プロジェクト管理の精度はさらに高まり、メンバーのモチベーションアップにもつながるでしょう。

記事をお読みいただいた皆さんがEVMを更に理解し、自身の関わるプロジェクトに採用されることを願っています。

プロジェクト成功の鍵！プロジェクトリーダーの役割について解説

IT開発のプロジェクト進捗管理に有効と言われるEVM(Earned Value Management)は、PMやSEにとって体得しておくべき管理手法の1つです。ここでは、そんなEVMの概要、メリット・デメリット、構成要素、EVM活用法などを解説します。

EVMは、従来型のスケジュール視点にコスト管理の視点を加えた、プロジェクト管理の手法

EVMには品質管理の視点が不足しており、EVMだけでプロジェクトを管理するのには限界がある

PMやSEはEVMを体得し、スキルアップやキャリアアップにつなげられる

PMやSEに必須のプロジェクト・マネジメント手法のEVMについて理解しよう

## プロジェクトマネージャー(PM)、プロジェクトリーダー(PL)は役職か役割か

プロジェクトマネージャーとプロジェクトリーダーの違いを考えるとき、**当然その「役職名」の違いもありますが、その「役割」の違い**もあります。

###会社によって違うPMとPLの意味や立場

「店長」という肩書きになったが仕事内容は変わらず、変わったのは時間外手当がつかなくなったことだ、などということは良くあります。肩書きや役職名は同じでも、会社が違えば仕事内容も違ってきます。

**PM、PLの意味や立場も会社によって異なります。**そのため、転職した当時は混乱したというエンジニアも少なくありません。プロジェクトの大きさによっても役割は異なるので、PMはいるがPLはいない、複数のPLがいるなど、その在り方は様々です。

###本質的にはPM、PLは役割の違い

あるプロジェクトにPMとPLがいれば、一般的にはPMが上位職でPLがその下に付くことになります。しかし、極端な例をあげると、重要なプロジェクトではIТ企業の創業社長がPLをして、PMを外部から招く、ということもあり得ます。昔取った杵柄で社長が陣頭指揮をとることで現場が活性化すれば、プロジェクトの完成が期待できるからです。したがって、**本質的にはPMとPLは役割の違いであって、上下関係ではありません。**

では、具体的にはPMとPLの役割はどう違うのかを見ていきましょう。

###「マネージ」と「リード」の意味から考えてみよう

プロジェクトマネージャーは「マネージする人」、プロジェクトリーダーは「リードする人」です。「マネージ」は、管理するというより「やりくりする」と考える方が実態に即しています。*与えられた条件の中で「ヒト・モノ・カネ」をやりくりするのです。*「リード」は文字通り「先頭に立って引っ張る」ことです。日々のタスクを方向づけてチームのメンバーに推進力を供給します。

###プロジェクトマネージャーの役割と仕事内容

PMがプロジェクトのやりくりをするとは「環境を整える」ことです。具体的には、ゴールを決める、締め切りを設ける、予算を確保する、人員を配置する、リスクを減らす、トラブルに対処する、などの仕事を行ないます。

経営者やクライアントと協議してプロジェクトの環境を設定し、キックオフの後はその環境をゴールに向かって調整します。

**プロジェクトマネジメントの世界標準と言われる教科書「PMBOK」**には、PMの役割が詳細に(ときには詳細すぎるくらいに)記載されています。一口にプロジェクト管理と言っても、次のような10の管理項目が挙げられています

●スコープ管理(プロジェクトの目標、作業範囲、成果物を定義し、管理すること)

各項目はそれぞれ計画書を作ってから実行するとされています。これを額面通りにやろうとすると、便利な管理ツールを使ったとしても、大変な作業です。教科書どおりにはやれません。しかし、各項目の内容を見ても「やらなくてもいい」ことは1つも含まれていません。ここでも、**理想通りには進まないプロジェクトという生き物を何とかやりくりするのがPMの仕事**だということが分かります。

###プロジェクトリーダーの役割と仕事内容

*PLが現場を引っ張るとは「メンバーに燃料を与え続ける」ことです。*具体的には、ゴールを頭に入れて、タスクを割り振る、進捗が遅れているメンバーの相談に乗る、優先事項とチェック項目を明確にする、トラブルに対処するなどです。PL自身、自分のタスクを抱えていますが、メンバーの心身の健康に気を配ることもPLの重要な役割です。

上記のような役割をこなすためにPLは、各メンバーと「技術内容について語りながら」問題を解決していきます。したがって、設計スキル、プログラムスキルでもメーンバーをリードできる力が求められます。

**PLが現場を「正しくリードする」ためには、プロジェクトのゴールをPMと同じくらい明確に把握している必要があります。**ゴールすなわちUX(ユーザー・エクスピアリエンス)をつねに意識してシステム構築とテストを行なうことで、正しい力加減で正しい方向にプロジェクトを推進することができるからです。

プログラミングなど自分のタスクに集中して取り組んでいるメンバーは、ややもすると意識が蛸壺型になり、ムダなところに力を入れ過ぎることがあります。そんなときにユーザーの顔を思い出させてやることもPLの役割です。

上記をまとめると、PLの役割は次のようになります。

●プロジェクトのゴールとユーザー体験をつねに意識する

●タスクを適切に割り振り、スケジュール管理をする

●トラブルの芽を早期に発見して対処する

●メンバーの声に耳を傾け、チームの士気を高める

●プロジェクト外部の関係者と内部のパイプ役になる

このように、**実際の現場に立ってメンバーを引っ張っていくのがPLの役割です。**

###PMとPLの役割の共通点と相違点

PMもPLも目指すゴールは同じで、リスク管理をして、トラブルに対処するのも同じです。しかし、プロジェクトは計画通りにはいかないもので、**必ず「難所」に遭遇します。**そのときにPMはプロジェクト外部からの雑音からプロジェクトを守る必要が生じることもあります。PLは難所の性質やクリアする方法をメンバーと検討するとともに、それを正確にPMに報告する義務があります。

ゴールの一部変更や締め切りの変更が避けられない場合は、PMが経営者やクライアントと相談しなければいけません。PLはメンバーから見て「いちばんオレ(わたし)の気持ちがわかる人」であるべきです。メンバーが経営者に不満があっても現場の空気が悪くなることはありませんが、*PLに不満があると毎日の仕事が苦痛になります。*

## プロジェクトに欠かせないのはPMかPLか

結論から言えば両方必要ですが、*病気で1週間休まれて困るのはPLです。*それぞれの行動や意識からその役割の違いを見ていきましょう。

###PMのペルソナを想定してみよう

PMはハイレベルなプロジェクト計画、つまり詳細が未定のアバウトな計画でGOを決断する立場にあります。キャリアに裏打ちされた先見力が必要だし、細部にこだわらない鷹揚さや度胸も要ります。必ず生じる遅れや変更に対応する柔軟性も必要です。経営者やクライアントなどのステークホルダーとの交渉力も欠かせません。もめたときやトラブルが発生したときにパニックになってしまわない胆力が求められるのがPMです。**交通事故にあったときに現場から逃走してしまうような人はPMには向いていません。**

プロジェクト内部で進行している業務への目配りが行き届いていること、支援する姿勢があることも重要です。「計画通りにやれ」とハッパをかけるだけでは、活気のあるプロジェクトにはなりません。もちろん、*エンドユーザーに提供するゴールに対する揺るがない視点はPMにとって必須です。*

###PLのペルソナを想定してみよう

PLはPMが整えてくれたプロジェクトの環境の中で、メンバーと共にタスクを積み上げていく立場にあります。明るくて元気な人が人を引っ張る力がありますが、必ずしも体育会系のノリが必要なわけではなく、人の話をよく聞くこと、長所を見つけてそれを活かすことを考えるのが大切です。**社内の営業部からのヒアリングやPMとの緊密な情報交換などのコミュニケーション能力も重要です。**

プロジェクトが胸突き八丁にさしかかると、メンバーの心身の疲労もピークになります。オーバーワークで壊れてしまうメンバーが出ないように目配りし、支援する優しさもPLに求められるキャラです。

###PLがしっかりしていればプロジェクトは機能する?

プロジェクトマネジメントの教科書「PMBOK」にそんなことは書かれていませんが、PMは多少アバウトな性格でもプロジェクトは前に進みます。しかし、それはしっかりしたPLが現場を引っ張っていることが前提です。

一方で、PLにPMの役割も押しつけてしまうのは負担が重くなりすぎます。プロジェクトの規模にもよりますが、理想はPMとPLがそれぞれの役割を担って、お互いに支え合うことです。

## PLのキャリアパスの先にあるのはPMとは限らない

ここまでお読みになって「自分にはPMもPLもできそうにない」と思った人がいたらちょっと脅かしすぎたことをお詫びします。**エンジニアとしてのスキルを磨き、経験を積んでいくことで、おのずとPLやPMの仕事をする能力も身に付いてきます。**たとえリモートワークがメインでも、結局仕事は人と協力することで成り立つものだからです。

また、若手のエンジニアは、PLやPMを目指している人が多いでしょうが、キャリアパスにおいてPLはPMへの通過点だという訳ではありません。

###若手エンジニアはまずPLを目指そう

*プロジェクトに参加する若手エンジニアは、キャリアパスとしてまず実力あるPLになることを目指しましょう。*プログラミングなど与えられたタスクをこなしながら、プロジェクト全体の目的や進行具合にも関心を持ち、そこにどう関わっていくかを学んでいくことが大切です。　　

性格や資質によっては、PMを目指すことももちろん悪くありません。ITコンサルタントとして活躍するという将来もあります。そのためにも、PLとしての実績を積むのは非常に役に立ちます。

プロジェクトにはさまざまな形がありますが、そこで生じる「人間的な諸問題」は共通していることがたくさんあります。**PLの立場でその問題に対処するスキルを磨くことは、転職の際も、ネクストステージを目指すときも貴重な財産になります。**

ITコンサルタントが独立するメリット・デメリットとその方法

ITコンサルタントになるために必要な資格は？仕事内容や年収も

会社やプロジェクトによって、PMとPLとの役割の違いは必ずしも明確ではありません。例えば、PMはいるがPLはいない場合もあり、様々な形態がとられています。それぞれプロジェクトの円滑な推進のために、また将来のキャリアパスのために、PMとPLの役割の違いについて解説していきます。

PMとPLは役職の違いではなく役割の違い

PMはプロジェクトをやりくりする役割。PLは現場を引っ張る役割。

PLとしての実力をつけることで次のキャリアパスが見えてくる

プロジェクト管理の記事（5ページ目）