プロジェクトマネジメントについて学んでいると、このような言葉をよく耳にします。

しかし、リーダーシップとは具体的に何をすればよいのでしょうか。

「チームを引っ張ること」と考える人もいるかもしれません。

もちろん、それもリーダーシップの一つです。

一方で、プロジェクトでは、PMが常に先頭に立って指示を出すだけではうまくいかないこともあります。

メンバーの意見を引き出したり、障害を取り除いたり、メンバーが力を発揮できる環境を作ったりすることも、重要なリーダーシップです。

この記事では、プロジェクトマネジメントにおけるリーダーシップについて解説し、近年注目されているサーバントリーダーシップについても紹介します。

一言でいうと

リーダーシップとは、目標を達成するために、人やチームに方向性を示し、行動を促し、力を発揮できるようにすることです。

PMの仕事に置き換えると、

「プロジェクトの目的を示し、メンバーが同じ方向を向いて成果を出せるように導くこと」

と考えると分かりやすいでしょう。

ここで重要なのは、リーダーシップは「命令すること」ではないという点です。

メンバーに指示を出すことだけではなく、目的を共有し、信頼関係を築き、必要な支援を行いながら、チームとして成果を出せる状態を作ることもリーダーシップです。

リーダーシップの目的

リーダーシップの目的は、個人ではなくチームとして目標を達成することです。

プロジェクトでは、一人のPMだけで成果を出すことはできません。

開発、設計、営業、品質管理、顧客、ベンダーなど、さまざまな人が関わります。

そのため、PMには、異なる立場や専門性を持つ人たちを同じ目的に向けていくことが求められます。

PMにリーダーシップが必要な理由

プロジェクトには、通常の業務とは異なる特徴があります。

• 関係者が多い
• 目標や成果物が明確でない場合がある
• スケジュールに制約がある
• 予算に制約がある
• 問題やリスクが発生する
• メンバーがプロジェクト専任とは限らない
• 組織や会社をまたいで活動することがある

このような環境では、単純に「この作業をしてください」と指示するだけでは、チームを動かすことが難しい場合があります。

そこで重要になるのがリーダーシップです。

PMは、

「このプロジェクトは何を目指しているのか」

「なぜこのプロジェクトを行うのか」

を明確にし、メンバーが目的を理解して行動できる状態を作る必要があります。

PMに求められるリーダーシップ

プロジェクトマネージャに求められるリーダーシップには、さまざまな形があります。

方向性を示す

まず重要なのが、プロジェクトの方向性を示すことです。

プロジェクトでは、問題が発生したり、意見が対立したりすることがあります。

そのようなときに、PMが、

「このプロジェクトでは何を実現したいのか」

という軸を示すことで、チームが判断しやすくなります。

メンバーを動機づける

メンバーが「やらされている」と感じている状態では、高いパフォーマンスを発揮することは難しくなります。

そのため、プロジェクトの目的や仕事の意味を伝え、メンバーが主体的に動けるようにすることも重要です。

意思決定する

プロジェクトでは、すべての人の意見が一致するとは限りません。

意見が対立した場合には、PMが判断しなければならないこともあります。

必要な情報を集め、関係者の意見を聞いたうえで、プロジェクトとしての意思決定を行うこともリーダーシップです。

チームを支援する

PM自身がすべての作業を行うのではなく、メンバーが仕事を進められるように支援することも重要です。

例えば、

• 他部署との調整を行う
• 必要な情報を集める
• 意思決定を支援する
• 障害を取り除く
• 必要なリソースを確保する

といった活動があります。

リーダーシップとマネジメントの違い

リーダーシップとマネジメントは、似た言葉として使われることがあります。

しかし、完全に同じものではありません。

ただし、PMにとってはどちらか一方だけが必要なのではありません。

リーダーシップとマネジメントの両方が重要です。

例えば、

「プロジェクトを成功させるために何を目指すのか」を示すのがリーダーシップ。

「その目標を達成するために、どのような計画で進めるのか」を管理するのがマネジメント。

というように考えると分かりやすいでしょう。

サーバントリーダーシップとは？

サーバントリーダーシップとは、リーダーがメンバーを支援することを重視するリーダーシップの考え方です。

「サーバント（servant）」には「奉仕する人」という意味があります。

一般的なリーダー像では、

「リーダーが指示を出し、メンバーがそれに従う」

というイメージがあります。

一方、サーバントリーダーシップでは、

「メンバーが力を発揮できるように、リーダーが支援する」

という考え方を重視します。

例えば、PMがすべての問題を自分で解決するのではなく、メンバーが問題を解決できるように、必要な情報や環境を整えたり、障害を取り除いたりします。

サーバントリーダーシップの特徴

サーバントリーダーシップでは、次のような考え方が重要になります。

• メンバーの話をよく聞く
• メンバーの成長を支援する
• メンバーが働きやすい環境を作る
• チームの障害を取り除く
• 信頼関係を築く
• メンバーの自主性を尊重する
• チームとして成果を出すことを重視する

つまり、リーダー自身が目立つことよりも、チームが成果を出せる状態を作ることを重視します。

アジャイルとサーバントリーダーシップ

サーバントリーダーシップは、特にアジャイルやスクラムとの関連で語られることがあります。

スクラムマスターは、チームがスクラムを適切に実践できるよう支援し、チームが自律的に活動できる環境を整える役割を担います。

そのため、スクラムマスターの役割を理解するうえで、サーバントリーダーシップの考え方は参考になります。

例えば、チームで問題が発生したときに、スクラムマスターがすべての問題を解決するのではなく、

「チーム自身が問題を解決できるように支援する」

という考え方です。

これは、メンバーの自律性を高めることにもつながります。

サーバントリーダーシップは「何でもメンバーに任せる」ことではない

サーバントリーダーシップについて、

「メンバーに自由にやらせること」

と誤解することがあります。

しかし、単に何でも任せることとは違います。

リーダーは、必要な場面では方向性を示し、意思決定を行い、チームを支援する必要があります。

例えば、チーム内で解決できない問題が発生した場合、PMが「皆さんで何とかしてください」と放置するのはサーバントリーダーシップではありません。

PM自身が上位組織や他部署と調整し、チームが問題を解決できる環境を作ることが、サーバントリーダーシップにつながります。

つまり、

「任せる」のではなく「任せられるように支援する」

という考え方が重要です。

リーダーシップのスタイルは一つではない

リーダーシップには、さまざまなスタイルがあります。

例えば、

• 指示型
• 参加型
• 支援型
• コーチング型
• サーバントリーダーシップ

などがあります。

どのスタイルが常に正しいというわけではありません。

プロジェクトの状況、チームの成熟度、メンバーの経験、緊急度などによって、適切なリーダーシップは変わります。

例えば、重大な障害が発生し、今すぐ判断が必要な状況では、PMが明確に方向性を示す必要があります。

一方、経験豊富なメンバーが自律的に活動できている場合は、細かく指示するよりも、メンバーを支援するほうが効果的かもしれません。

状況に応じてリーダーシップのスタイルを使い分けることが重要です。

PMのリーダーシップで重要なコミュニケーション

リーダーシップを発揮するうえで、コミュニケーションは欠かせません。

特にPMは、

• プロジェクトの目的を伝える
• メンバーの意見を聞く
• 問題を共有する
• 意思決定の理由を説明する
• 関係者の認識を合わせる

といったコミュニケーションを行います。

「自分の考えを伝える」だけではなく、「相手の考えを理解する」ことも重要です。

特にサーバントリーダーシップでは、メンバーの声を聞くことが重要になります。

リーダーシップでよくある失敗

PMがすべての判断をする

PMがすべての判断を行ってしまうと、メンバーが自分で考えなくなってしまう可能性があります。

もちろん重要な意思決定はPMが行う必要がありますが、メンバーが判断できることまでPMが決める必要はありません。

可能な範囲でメンバーに判断を委ねることも重要です。

指示を出すことがリーダーシップだと考える

「これをやってください」と指示を出すだけでは、メンバーの主体性を引き出すことは難しい場合があります。

なぜその作業が必要なのか、プロジェクトとして何を目指しているのかを共有することが重要です。

メンバーに任せすぎる

逆に、「自主性を尊重する」という理由で、PMが何も関与しなくなることも問題です。

必要な場面では、PMが方向性を示したり、障害を取り除いたりする必要があります。

自分が一番頑張ればよいと考える

PMが誰よりも多くの仕事を抱えることが、良いリーダーシップとは限りません。

PM自身が頑張るよりも、チーム全体が力を発揮できる状態を作ることが重要です。

プロジェクトマネージャにとってのリーダーシップ

PMにとってのリーダーシップは、「メンバーの先頭に立って引っ張ること」だけではありません。

時には先頭に立ち、時には後ろから支え、時にはメンバーに考えてもらう。

プロジェクトの状況に応じて、役割を変えることが重要です。

例えば、プロジェクトの立ち上げ時には、PMがプロジェクトの目的や方向性を明確に示す必要があります。

一方で、チームが成熟してくれば、メンバーが主体的に判断できるように権限を渡していくことも重要になります。

このように、「自分がチームを動かす」のではなく、「チームが自律的に動ける状態を作る」という視点を持つことが、PMのリーダーシップを考えるうえで重要です。

プロジェクトマネージャ試験ではここが重要

リーダーシップについて学ぶときは、次の用語と関連付けて整理しておくとよいでしょう。

• サーバントリーダーシップ
• チームマネジメント
• チームビルディング
• コミュニケーション
• 動機づけ
• コンフリクトマネジメント
• 意思決定
• 合意形成
• ファシリテーション
• ステークホルダーエンゲージメント
• スクラムマスター
• アジャイル

特に、「指示するリーダー」と「支援するリーダー」の違いを理解しておくと、リーダーシップに関する問題を考えやすくなります。

PM道場のワンポイント

強いPMとは、自分が一番頑張るPMではなく、チームが力を発揮できる環境を作れるPMです。

PMになったばかりの頃は、

「自分が判断しなければ」

「自分が解決しなければ」

と考えてしまうことがあります。

しかし、プロジェクトが大きくなればなるほど、PM一人ですべてを判断することはできません。

そこで重要になるのが、メンバーを信頼して任せることです。

ただし、単純に仕事を丸投げするのではありません。

「メンバーが自分で判断し、行動できるように必要な支援をする」

という考え方が重要です。

これが、サーバントリーダーシップの考え方にもつながります。

PMの役割は、必ずしも「一番前でチームを引っ張る人」ではありません。

プロジェクトの目的を示し、メンバーが力を発揮できる環境を作り、必要なときにはチームを支える。

そんなリーダーシップも、PMにとって非常に重要だと私は考えています。

関連用語

• サーバントリーダーシップ
• チームマネジメント
• チームビルディング
• コミュニケーションマネジメント
• ファシリテーション
• ネゴシエーション
• 合意形成
• 意思決定
• コンフリクトマネジメント
• ステークホルダーエンゲージメント
• スクラムマスター
• アジャイル

まとめ

リーダーシップとは、目標を達成するために、人やチームに方向性を示し、行動を促し、力を発揮できるようにすることです。

PMにとってのリーダーシップは、単純にメンバーへ指示を出すことではありません。

• プロジェクトの方向性を示す
• メンバーを動機づける
• 意思決定する
• メンバーの意見を聞く
• チームの障害を取り除く
• メンバーが力を発揮できる環境を作る

といったさまざまな活動が含まれます。

その中でも、サーバントリーダーシップは、リーダーがメンバーを支援し、メンバーが主体的に活動できる環境を作るという考え方です。

重要なのは、「メンバーに何をさせるか」ではなく、

「メンバーがどうすれば力を発揮できるか」

という視点を持つことです。

プロジェクトの状況によって、強く方向性を示すことが必要な場合もあれば、メンバーに任せて支援することが必要な場合もあります。

その状況に応じてリーダーシップのスタイルを使い分けることが、PMにとって重要なスキルです。

関連記事

• サーバントリーダーシップとは？
• チームマネジメントとは？
• チームビルディングとは？
• ファシリテーションとは？
• ネゴシエーションとは？
• 合意形成とは？
• 意思決定とは？
• ステークホルダーエンゲージメントとは？
• スクラムマスターとは？

よくある質問（FAQ）

Q. リーダーシップとは何ですか？

A. 目標を達成するために、人やチームに方向性を示し、行動を促し、力を発揮できるようにすることです。PMの場合は、プロジェクトの目的を共有し、チームとして成果を出せる状態を作ることが重要です。

Q. PMにリーダーシップは必要ですか？

A. 必要です。プロジェクトでは多くの関係者が関わるため、PMには方向性を示し、関係者をまとめ、必要な意思決定を行うことが求められます。

Q. リーダーシップとマネジメントの違いは何ですか？

A. リーダーシップは方向性を示し、人やチームを目標に向けて動かすことに重点があります。一方、マネジメントは計画、進捗、コスト、品質、リスクなどを管理し、目標達成に向けてプロジェクトを運営することに重点があります。PMには両方が必要です。

Q. サーバントリーダーシップとは何ですか？

A. リーダーがメンバーを支援し、メンバーが力を発揮できる環境を作ることを重視するリーダーシップの考え方です。メンバーの話を聞き、障害を取り除き、成長や自律的な活動を支援します。

Q. サーバントリーダーシップはメンバーにすべて任せることですか？

A. いいえ。何でも任せることではありません。メンバーが主体的に活動できるよう支援しながら、必要な場面ではリーダーが方向性を示したり、意思決定したりすることも重要です。

Q. サーバントリーダーシップはスクラムと関係がありますか？

A. はい。スクラムマスターの役割を理解するうえで、サーバントリーダーシップの考え方は参考になります。スクラムマスターは、チームが自律的に活動できるよう支援し、障害を取り除く役割を担います。

Q. PMは常にメンバーを引っ張る必要がありますか？

A. 必ずしもそうではありません。プロジェクトの状況やチームの成熟度によって、方向性を強く示すことが必要な場合もあれば、メンバーに権限を渡して支援するほうが効果的な場合もあります。状況に応じてリーダーシップのスタイルを使い分けることが重要です。

The post リーダーシップとは？PMに求められるリーダーシップとサーバントリーダーシップ first appeared on PM道場.

PMとして仕事をしていると、一度は考えたことがあるのではないでしょうか。

転職を考えている人なら、特に気になるところです。

「PM経験10年」

「大規模プロジェクトを担当」

「PMP^®を取得」

こうした経歴があれば、市場価値は高いのでしょうか。

私は、PM戦闘力が高いほど、市場価値も高くなると考えています。

ただし、ここには一つ重要なポイントがあります。

それは、

自分のPMとしての価値を、相手にきちんと説明できるか

ということです。

どれだけ高いPM戦闘力を持っていても、それを相手に伝えられなければ、転職市場では正しく評価されない可能性があります。

PM戦闘力が高いほど市場価値も高くなる

これまでの記事で、私はPM戦闘力を次のように考えてきました。

PM戦闘力 ≒（経験 × スキル × 適用力）＋（資格 ＋ 実績）

この考え方からすると、PMとしての経験を積み、スキルを磨き、適用力を高め、資格や実績を積み重ねるほど、PM戦闘力は高くなっていきます。

そして、そのPM戦闘力が高くなれば、基本的には市場価値も高くなっていくと考えられます。

例えば、次のような能力です。

• 大規模プロジェクトをマネジメントできる
• 多数のステークホルダーを調整できる
• 複数チームをまとめられる
• トラブルを解決できる
• リスクを先回りして管理できる
• プロジェクトの状況に応じてマネジメント方法を変えられる
• プロジェクトを成功に導いた実績がある

こうした能力を持っているPMは、企業から見ても価値のある人材になりやすいでしょう。

つまり、

PM戦闘力を高めることは、市場価値を高めることにもつながる

と考えられます。

「PM経験10年」だけでは市場価値は分からない

では、

「PM経験10年です」

と言えば、それだけで高い市場価値を示せるでしょうか。

私は、そうではないと思います。

同じ「PM経験10年」でも、その中身は人によって大きく違います。

例えば、

• Aさんは、10年間ほぼ同じ規模・同じようなプロジェクトを担当してきた。
• Bさんは、10年間で小規模から大規模まで経験し、複数ベンダー、難しいステークホルダー、トラブルプロジェクトなどにも挑戦してきた。

どちらもPM経験10年です。

しかし、経験の質は同じではありません。

だからこそ、転職などで自分の価値を伝えるときには、

「何年PMをやってきたか」だけではなく、「何を経験して、何ができるようになったのか」

を説明する必要があります。

「どんなプロジェクトを経験したか」が重要

PMの市場価値を考えるとき、経験年数だけでなく、経験の質が重要になります。

例えば、次のような要素です。

• プロジェクトの規模
• メンバー数
• プロジェクト期間
• 予算
• ステークホルダーの数
• ベンダー数
• 技術的な難易度
• 業務上の難易度
• 納期の厳しさ
• トラブルの有無

特に、自分がこれまで経験したことのない難しいプロジェクトに挑戦してきた経験は、PM戦闘力を高める要素になります。

大規模プロジェクトを経験した。

複数ベンダーをマネジメントした。

難しいステークホルダーとの調整を行った。

トラブルプロジェクトを立て直した。

こうした経験は、自分のPMとしての対応力を示す材料になります。

スキルは「持っている」だけではなく「使える」ことが重要

市場価値を考えるうえでは、PMスキルも重要です。

例えば、

「コミュニケーション能力があります」

「リスクマネジメントが得意です」

と言うだけでは、その能力を評価するのは難しいでしょう。

重要なのは、

そのスキルを使って、実際に何をしたのか

です。

例えば、

「プロジェクトの途中で関係者間の認識にズレがあることを発見し、関係者を集めて合意形成を行った」

「重大なリスクを早期に発見し、事前に対応策を実施した」

といった具体的な経験があれば、スキルを実務で使えることを説明できます。

つまり、

スキル → 実践 → 成果

までつなげることが重要です。

適用力も市場価値につながる

PM戦闘力の中でも、私は適用力が重要だと考えています。

PMの仕事では、

「この方法が正解」

というものが必ずしも存在しません。

プロジェクトによって、

• 規模
• 組織
• メンバー
• ステークホルダー
• 技術
• 納期
• リスク

が違うからです。

そのため、

「過去のプロジェクトではこの方法でうまくいった」

だけでは不十分です。

「今回のプロジェクトでは何が違うのか？」

「今回は何を重視すべきなのか？」

を考え、マネジメント方法を変えられる。

この適用力が高いPMほど、さまざまな環境で活躍できる可能性が高くなります。

そして、それは市場価値にもつながっていくでしょう。

資格は「装備」として市場価値を補強する

資格については、これまでの記事でも書いてきました。

私は、資格をPM戦闘力の「装備」だと考えています。

資格そのものがPMの実力ではありません。

しかし、

「PMP^®を取得している」

「IPAのプロジェクトマネージャ試験に合格している」

といった資格は、自分が一定の知識を持っていることを示す材料になります。

特に、初対面の企業や採用担当者には、自分の実力をすべて理解してもらうことはできません。

そのとき、資格は自分の知識を示す一つの材料になります。

ただし、ここでも重要なのは、

資格を持っていることだけをアピールするのではなく、そこで学んだ知識を実務でどう活用したのかを説明すること

です。

資格という「装備」を、実際のPM戦闘力につなげていることを伝える。

これが重要だと思います。

最も重要なのは「実績」を説明できること

PMの市場価値を考えるうえで、特に重要なのが実績です。

例えば、

「大規模プロジェクトを担当しました」

だけではなく、

「100人規模のプロジェクトでPMを担当し、○○という課題に対して○○を実施し、結果として○○を達成しました」

というところまで説明できると、自分の価値が伝わりやすくなります。

実績とは、

自分が何をしたのか

だけではありません。

その結果、どんな価値を生み出したのか

まで含めて考えることが重要です。

例えば、

• コストを削減した
• 納期を守った
• 品質を改善した
• トラブルを解決した
• チームを育成した
• プロセスを改善した
• 仕組みを作った
• 再発防止につなげた

などです。

そして、できるだけ数字で説明できるようにしておく。

これが、PMとしての市場価値を伝えるうえで非常に重要になります。

PM戦闘力が高くても、市場価値が正しく伝わらないことがある

ここが、今回の記事で一番伝えたいポイントかもしれません。

PM戦闘力と市場価値は、基本的には比例すると考えています。

しかし、

PM戦闘力が高い人＝必ず市場で高く評価される人

とは限りません。

なぜなら、

自分の価値を説明できなければ、相手はその価値を判断できないからです。

例えば、非常に難しいプロジェクトを成功させたPMがいたとします。

しかし、その人が、

「大変でしたが、なんとか終わりました」

としか説明できなかったらどうでしょうか。

採用する側からすると、

• 何が大変だったのか？
• 何をしたのか？
• どんな能力があるのか？
• どんな成果を出したのか？

が分かりません。

一方で、

「プロジェクトには○○という課題がありました。私はPMとして○○を実施し、その結果○○を達成しました」

と説明できれば、その人のPM戦闘力をイメージしやすくなります。

だからこそ、

PM戦闘力を高めることと、自分のPM戦闘力を言語化すること。

この2つが重要なのです。

「市場価値を高めるため」ではなく「PMとして強くなる」

では、市場価値を高めるためには何をすればよいのでしょうか。

私は、

まずPMとしての実力を高めること

だと思っています。

転職市場で評価されるために、資格だけを集める。

転職市場で評価されるように、肩書きを増やす。

これだけでは、本当の意味でPM戦闘力が高まったとは言えません。

まずは、

• 質の良い経験を積む
• スキルを磨く
• 適用力を高める
• 資格という装備を身につける
• 実績を作る

そして、その結果としてPM戦闘力が高まる。

PM戦闘力が高まれば、市場価値も高まっていく。

私は、この順番が重要だと考えています。

転職する予定がなくても「市場価値」を考えてみる

「今の会社を辞めるつもりはないから、市場価値なんて考えなくてもいい」

そう思う人もいるかもしれません。

しかし、私は転職する予定がなくても、一度自分の市場価値を考えてみることをおすすめします。

なぜなら、

自分のPMとしての実力を客観的に見るきっかけになるからです。

「自分は何ができるのか？」

「どんなプロジェクトを経験してきたのか？」

「どんな成果を出してきたのか？」

「それを第三者に説明できるのか？」

こうしたことを考えるだけでも、自分の現在地が見えてきます。

そして、もし、

• 意外と自分の実績を説明できない
• 数字で成果を説明できない
• 経験はあるけれど、強みが言語化できない

と気づいたなら、それも一つの発見です。

一度、転職エージェントに相談してみるのも面白い

自分の市場価値を知る方法として、私は一度転職エージェントと面談してみることも良い方法だと思っています。

もちろん、転職することが目的ではありません。

自分の経歴や経験を伝えて、

• 自分は転職市場でどのように評価されるのか？
• どんな求人が考えられるのか？
• 自分の経験のどこが評価されるのか？
• 逆に、何が足りないのか？

を聞いてみる。

そうすることで、自分では気づかなかった強みや弱みに気づけるかもしれません。

また、

「自分の価値をきちんと説明できているか」

を確認する機会にもなります。

転職する予定がなくても、自分の市場価値を確認するための一つの方法として活用してみるのもよいでしょう。

• PM・IT人材のための転職・キャリアサービス一覧

PM戦闘力は「自分の現在地」を知るために使う

PM戦闘力という考え方を作ったのも、まさにこのためです。

PM戦闘力は、

「あなたは○○点だから優秀」

と人をランキングするためのものではありません。

自分が今どこにいるのかを客観的に見るためのツールです。

例えば、

• 「経験は十分だけど、適用力が弱い」
  →プロジェクトごとにマネジメント方法を変えることを意識する。
• 「スキルはあるけれど、経験が足りない」
  →少し難しいプロジェクトに挑戦する。
• 「実績はあるけれど、うまく説明できない」
  →自分の成果を言語化する。
• 「資格がない」
  →必要な資格を検討する。

このように、

足りないものを把握する → 補う → 実践する

ためにPM戦闘力を使ってほしいと思っています。

PM戦闘力を高めることが、結果として市場価値を高める

PMとしての市場価値を高めたい。

そう思ったときに、まず考えてほしいのは、

「どうすれば転職市場で評価されるか？」

ではありません。

「どうすればPMとしてもっと強くなれるか？」

です。

質の良い経験を積む。

スキルを磨く。

適用力を高める。

資格という装備を身につける。

実績を積み上げる。

そして、その経験や実績を自分の言葉で説明できるようにする。

そうすることで、PM戦闘力が高まり、その結果として市場価値も高まっていくのだと思います。

転職する予定がなくても、自分のPM戦闘力を確認してみよう

PMとして働いているなら、一度立ち止まって考えてみてください。

「自分のPM戦闘力は、今どれくらいあるのだろう？」

そして、

「その戦闘力を、第三者にきちんと説明できるだろうか？」

もし説明できないのであれば、それは自分のPM戦闘力を整理する良い機会です。

自分の強みは何か。

足りないものは何か。

どんな経験があるのか。

どんな実績を残したのか。

それを整理する。

必要であれば、転職エージェントなど第三者に話を聞いてもらう。

そこで自分の市場価値を知り、足りないものを見つける。

そして、それをまた次の経験や学びにつなげていく。

PM戦闘力に完成はありません。

自分の現在地を知り、足りないものを補い、実践する。

その不断の努力こそが、PMとしての成長につながり、結果として市場価値も高めていくのだと思います。

あなたは、自分のPM戦闘力と市場価値を、どれくらい客観的に説明できますか？

• PM・IT人材のための転職・キャリアサービス一覧

まとめ：PM戦闘力を高め、自分の価値を言葉にしよう

PMとしての市場価値を高めるために重要なのは、転職市場で評価されるためのテクニックだけではありません。

まずPMとして強くなること。そして、その強さを相手に伝えられるようにすること。

この2つが重要です。

• 質の良いPM経験を積む
• PMスキルを実践で磨く
• プロジェクトに応じた適用力を高める
• 資格を「装備」として活用する
• 実績を作る
• 自分の経験や成果を言語化する

PM戦闘力が高まれば、市場価値も高まっていきます。

ただし、自分の価値を説明できなければ、その戦闘力が正しく評価されないこともあります。

だからこそ、

PM戦闘力を高めることと、自分のPM戦闘力を言語化すること。

この両方を意識してみてください。

市場価値を知ることは、転職するためだけのものではありません。

自分のPMとしての現在地を知り、次に何を伸ばすべきなのかを考えるためにも役立ちます。

あなた自身のPM戦闘力を、一度整理してみてはいかがでしょうか。

PM戦闘力シリーズ

• PM戦闘力とは？PMとしての強さを決める要素を考えてみた
• PM経験年数だけでは戦闘力は上がらない？経験の質が重要な理由
• PM戦闘力を高めるPMスキルとは？重要な4つのスキルを考えてみた
• PM資格は本当に必要？資格を「戦闘力の装備」として考える
• PMの実績とは何か？「トラブルを解決した」だけが実績ではない

• なぜトラブルを起こさないPMは評価されにくいのか？

• あなたのPM戦闘力はどれくらい？PM戦闘力を自己診断してみる
• PM戦闘力を高めるには？「経験→実践→振り返り」の成長サイクルを回そう

The post PM戦闘力と市場価値の関係とは？PMとしての実力を転職市場でどう伝えるか first appeared on PM道場.

PMの資格を取る。

PMBOK®︎を勉強する。

コミュニケーションスキルを磨く。

難しいプロジェクトに挑戦する。

どれもPMとして成長するために重要なことです。

しかし、私はそれだけでは不十分だと考えています。

なぜなら、PM戦闘力は一つのスキルや資格だけで決まるものではないからです。

以前の記事で、私はPM戦闘力を次のように考えました。

PM戦闘力 ≒（経験 × スキル × 適用力）＋（資格 ＋ 実績）

では、このPM戦闘力をどうすれば高めることができるのでしょうか。

私が考える答えは、

「質の良い経験を積み、実践し、振り返る」というサイクルを回し続けること

です。

PM戦闘力は「経験→実践→振り返り」で高めていく

PM戦闘力を高める流れを簡単にすると、次のようになります。

1. 質の良い経験を積む
2. 経験の中で実践する
3. プロジェクトを振り返る
4. 必要なスキルや知識を身につける
5. 再び実践する
6. より難しいプロジェクトに挑戦する
7. 経験が実績になる

そして、そこで得た経験をまた次のプロジェクトに活かします。

つまり、PM戦闘力は一度上げたら終わりではありません。

このサイクルを繰り返すことで、少しずつ高まっていくものだと考えています。

① PM戦闘力を高めるには、まず「質の良い経験」を積む

PM戦闘力を高めるうえで、私が最も重要だと考えているのが経験です。

ただし、ここでいう経験は「PM経験年数」だけではありません。

重要なのは、どのような経験をしたかです。

例えば、

「PMを10年間やっています」

という人と、

「5年間のPM経験ですが、大規模プロジェクト、複数ベンダー、難しいステークホルダーがいるプロジェクトなど、さまざまな状況を経験してきました」

という人がいたら、単純に経験年数だけではPMとしての強さを判断できません。

では、どうすれば質の良い経験を積めるのでしょうか。

私は、良い経験は自分で作るものだと考えています。

② 良い経験は「自分で作る」

同じプロジェクトでも、そこから何を学ぶかはPMによって変わります。

例えば、プロジェクトが無事に終了したとします。

そこで、

「無事に終わった。よかった」

で終わってしまえば、その経験から得られるものは限られます。

一方で、プロジェクトの最初から、

• 今回のプロジェクトでは何を達成するのか？
• 成功とは何か？
• そのために何をするのか？

を考えておく。

そして、プロジェクトを進めながら、

• 計画通りに進んでいるか？
• 想定していたリスクはどうなっているか？
• このプロジェクトでは何が重要なのか？

を考え続けます。

最後には、

• 何が良かったのか？
• 何がうまくいかなかったのか？
• なぜうまくいかなかったのか？
• 次のプロジェクトではどうするのか？

を振り返ります。

そして、それを教訓として次のプロジェクトに活かします。

ここまでできれば、どんなプロジェクトでも良い経験に変えることができます。

つまり、

良いプロジェクトに参加することだけが、良い経験を積む方法ではない。

ということです。

経験をどう捉え、どう活かすかによって、経験の質は自分で高められます。

私はそう考えています。

③ 経験の中で「適用力」を高める

経験を積むことで、PMの引き出しが増えていきます。

しかし、経験が増えれば自動的にPM戦闘力が高まるわけではありません。

重要なのが適用力です。

例えば、以前のプロジェクトで、

「毎週定例会議を開催したらうまくいった」

という経験があったとします。

そこで次のプロジェクトでも、

「前回うまくいったから、今回も毎週定例会議をやろう」

と、そのまま同じ方法を使う。

これは経験を活かしているように見えます。

しかし、本当に重要なのは、

「前のプロジェクトと今回のプロジェクトは何が違うのか？」

と考えることです。

例えば、次のような違いがあります。

• メンバーが違う
• ステークホルダーが違う
• プロジェクトの規模が違う
• 納期が違う
• 技術が違う
• 組織が違う

そうであれば、最適なマネジメント方法も変わるかもしれません。

過去の経験をそのまま使うのではなく、

「このプロジェクトでは何が重要なのか？」

を考えて、経験や知識を使い分ける。

それがPMにとっての適用力だと思います。

④ 振り返ることで「経験」を「成長」に変える

プロジェクトが終わったら、それで経験が完成するわけではありません。

むしろ、ここからが重要です。

プロジェクトを振り返ります。

例えば、次のように整理します。

良かったこと

• ステークホルダーとの合意形成が早かった
• リスクを早期に発見できた
• チーム内の役割分担が明確だった

悪かったこと

• 初期計画が甘かった
• 情報共有が遅れた
• 問題への対応が後手に回った

さらに、

「なぜそうなったのか？」

まで考えます。

そして、

「次のプロジェクトではどうするか？」

という具体的な教訓に変えていきます。

これを繰り返すことで、

経験 → 振り返り → 教訓 → 次の実践

というサイクルが生まれます。

ここまでやって初めて、経験が次のPM戦闘力につながっていくのだと思います。

⑤ 必要なスキルは「実践」して身につける

振り返りをしていると、

「自分にはこのスキルが足りない」

と気づくことがあります。

例えば、

• 「ステークホルダーとの調整が苦手だった」
• 「問題を整理するのに時間がかかった」
• 「リスクへの対応が後手に回った」

のであれば、それぞれに必要な知識を学びます。

• コミュニケーションや交渉について学ぶ
• ロジカルシンキングや問題解決について学ぶ
• リスクマネジメントについて学ぶ

ここで重要なのは、学んで終わりにしないことです。

本を読む。

研修を受ける。

資格の勉強をする。

これらは基本的にインプットです。

インプットしただけでは、まだPMのスキルになったとは言えません。

学んだことを実際のプロジェクトで使ってみる。

つまり、

インプット → 実践 → アウトプット

まで行います。

これによって、知識が少しずつ自分のスキルになっていきます。

⑥ PM資格は「実務につなげて」こそ意味がある

資格についても同じです。

PM資格を取得することは、PM戦闘力の「装備」を増やすことになります。

しかし、

「資格を取ったからPMとして強くなった」

とは限りません。

資格取得のために学んだ知識を、

「この考え方は自分のプロジェクトでも使えるのでは？」

と考えて、実務で試してみる。

そこでうまくいかなければ、なぜうまくいかなかったのかを考えます。

そして、プロジェクトに合わせて方法を変えます。

この繰り返しが重要です。

資格はゴールではなく、実践するためのきっかけとして使う。

そうすることで、資格という「装備」が実際のPM戦闘力につながっていくのだと思います。

⑦ 少し難しいプロジェクトに挑戦してPMの引き出しを増やす

経験を積み、スキルを磨き、適用力を高めてきたら、次はより難しいプロジェクトに挑戦することです。

例えば、次のようなプロジェクトです。

• これまでより大規模なプロジェクト
• ステークホルダーが多いプロジェクト
• 複数ベンダーが関わるプロジェクト
• 技術的な難易度が高いプロジェクト
• 納期が厳しいプロジェクト
• 組織間の調整が難しいプロジェクト

もちろん、いきなり自分の能力を大きく超えるプロジェクトに挑戦する必要はありません。

重要なのは、

「今の自分なら何とか対応できそうだけれど、少し難しい」

くらいのプロジェクトに挑戦することです。

そこで新しい経験を積み、足りないスキルに気づき、学び、実践する。

そしてまた次の難しいプロジェクトへ進む。

この繰り返しによって、PMとしての引き出しが増えていきます。

⑧ 経験を「実績」に変える

そして、これまで積み重ねてきた経験は、やがて実績になります。

ただし、

「プロジェクトを担当しました」

だけでは、PMとしての実績とは言いにくいかもしれません。

重要なのは、

「自分が何をして、どんな価値を生み出したのか」

です。

例えば、次のようなものがあります。

• プロジェクトの目標を達成した
• 納期を守った
• コストを削減した
• 品質を改善した
• チームを育成した
• プロセスを改善した
• 再発防止の仕組みを作った
• PMの方法を標準化した

さらに、

• ○人のチームをマネジメントした
• ○か月のプロジェクトを完遂した
• ○％の工数削減につなげた

など、数字で説明できるようにしておくと、自分のPMとしての価値を客観的に伝えやすくなります。

こうして、

経験 → 実績

へと変わっていきます。

PM戦闘力を高めるために必要なのは「成長サイクル」

ここまでの話をまとめると、PM戦闘力を高める方法は次のようになります。

1. 質の良い経験を積む
2. 経験の中で実践する
3. プロジェクトを振り返る
4. 自分に足りないものを見つける
5. スキルや知識を学ぶ
6. 実務でアウトプットする
7. 適用力を高める
8. より難しいプロジェクトに挑戦する
9. 経験を実績に変える
10. また次のプロジェクトへ進む

このサイクルを回し続ける。

これが、PM戦闘力を高めるための基本的な考え方だと思います。

PM戦闘力は「自分を客観的に見るためのツール」

ここで、PM戦闘力という考え方の意味についても触れておきたいと思います。

PM戦闘力は、

「あなたは○○点だから優秀です」

と人を評価するためのものではありません。

むしろ、

自分のPMとしての現在地を客観的に見るためのツール

だと私は考えています。

例えば診断をして、

「経験は十分だけれど、適用力が低い」

と分かったとします。

それなら、

「過去の成功パターンをそのまま使っていないか？」

と、自分の仕事を振り返ってみる。

あるいは、

「実績はあるけれど、資格や体系的な知識が足りない」

と分かったなら、必要な知識を学んでみる。

「スキルはあるけれど、経験が足りない」

のであれば、少し難しいプロジェクトに挑戦してみる。

このように、

足りないものを見つける → 補う → 実践する

ためにPM戦闘力を使ってほしいと思っています。

PM戦闘力に「完成」はない

PMとして働いている限り、PM戦闘力に完成はありません。

経験を積めば、今まで経験したことのない問題に出会います。

スキルを身につければ、それをさらに難しい状況で使う必要が出てきます。

資格を取れば、それを実務でどう活かすかという課題が出てきます。

実績を積めば、さらに難しいプロジェクトに挑戦したくなります。

だからこそ、PMには不断の努力が必要なのだと思います。

PM戦闘力を高めるというのは、

「SランクPMになったら終わり」というゲームではありません。

自分の弱点を見つけ、それを補い、実践し、また次の課題を見つける。

この繰り返しです。

あなたのPM戦闘力を上げるために、まず何をしますか？

PM戦闘力を高めるために、特別なことを始める必要はないかもしれません。

まずは、今担当しているプロジェクトについて考えてみてください。

「このプロジェクトで、自分は何を経験しようとしているのか？」

そして、

「プロジェクトが終わったとき、何を教訓として残すのか？」

を考えてみる。

そこから、自分に足りないスキルを見つけて、学び、実践する。

そして、次は少し難しいプロジェクトに挑戦する。

そうやって一つずつ経験を積み重ねていけば、PM戦闘力は少しずつ高まっていくはずです。

あなたなら、今のPM戦闘力をさらに高めるために、まず何に取り組みますか？

まとめ：PM戦闘力は「経験→実践→振り返り」の繰り返しで高まる

PM戦闘力を高めるために、資格を取ったりスキルを学んだりすることは重要です。

しかし、それだけでPMとして強くなるわけではありません。

重要なのは、学んだことを実務で使い、経験を振り返り、次のプロジェクトに活かすことです。

PM戦闘力を高める流れをまとめると、次のようになります。

• 質の良い経験を積む
• 経験の中で実践する
• プロジェクトを振り返る
• 足りない知識やスキルを学ぶ
• 学んだことを実務で使う
• 適用力を高める
• 少し難しいプロジェクトに挑戦する
• 経験を実績に変える
• また次のプロジェクトに活かす

このサイクルを回し続けることで、PMとしての引き出しは少しずつ増えていきます。

PM戦闘力に完成はありません。

だからこそ、今の自分に足りないものを見つけ、学び、実践することが大切です。

「経験→実践→振り返り」のサイクルを、今日のプロジェクトから始めてみてはいかがでしょうか。

PM戦闘力シリーズ

• PM戦闘力とは？PMとしての強さを決める要素を考えてみた
• PM経験年数だけでは戦闘力は上がらない？経験の質が重要な理由
• PM戦闘力を高めるPMスキルとは？重要な4つのスキルを考えてみた
• PM資格は本当に必要？資格を「戦闘力の装備」として考える
• PMの実績とは何か？「トラブルを解決した」だけが実績ではない

• なぜトラブルを起こさないPMは評価されにくいのか？

• あなたのPM戦闘力はどれくらい？PM戦闘力を自己診断してみる

• PM戦闘力と市場価値の関係とは？PMとしての実力を転職市場でどう伝えるか

The post PM戦闘力を高めるには？「経験→実践→振り返り」の成長サイクルを回そう first appeared on PM道場.

そんな疑問を可視化する『PM戦闘力診断』を作りました！

全28問（約5分）で、あなたのPMタイプや強み・伸びしろがわかります。

ぜひ診断してみてください。

※この診断はあくまで自己評価です。定量的な結果が出ますが、客観性はないことをご承知おきください。

PM戦闘力診断

あなたのPM戦闘力はどれくらい？

PMとしての「経験」「スキル」「適用力」「資格」「実績」から、 あなたのPM戦闘力を診断します。

全28問 5つの選択肢から回答

約5分 スマホでも診断できます

5つの視点 経験・スキル・適用力・資格・実績

この診断で分かること

• あなたのPM戦闘力
• PMとしてのランク
• あなたのPMタイプ
• あなたの強み
• あなたの伸びしろ
• 次に読むとよい関連記事

診断を開始する → 前回の診断結果を見る

Q1 1 / 28

経験

← 前の質問 次へ →

あなたのPM戦闘力

0

–

–

診断結果をシェアする

あなたのPM戦闘力をXで公開してみませんか？

𝕏で診断結果をシェアする

実力と装備

PM戦闘力は、プロジェクトを成功させる「実力」と、 資格や実績という「装備」の両方から成り立ちます。

実力 0

＋

装備 0

＝

PM戦闘力 0

あなたの能力値

スキル詳細

あなたの強み

次に伸ばしたい能力

あなたへのメッセージ

あなたにおすすめの記事

あなたの診断結果から、PM戦闘力をさらに高めるために 読んでおきたい記事を選びました。

PM戦闘力に「完成」はありません

経験を積み、スキルを磨き、実践の中で適用力を高める。 そして、資格や実績という「装備」を整える。

そうすることで、あなたのPM戦闘力はさらに高めることができます。

もう一度診断する

The post あなたのPM戦闘力はどれくらい？PM戦闘力を自己診断する first appeared on PM道場.

そう評価されるPMを思い浮かべてみてください。

もしかすると、

「大きなトラブルが起きたプロジェクトを立て直したPM」

ではないでしょうか。

顧客から大きなクレームが入った。

スケジュールが大幅に遅れた。

プロジェクトが赤字になりそうになった。

メンバー間で大きな対立が起きた。

そんなプロジェクトをPMが見事に立て直す。

こうしたPMは、確かに目立ちます。

一方で、

「何の問題も起こさず、予定通りプロジェクトを成功させたPM」

はどうでしょうか。

こちらも、もちろん優秀なPMです。

しかし、なぜか前者ほど目立たない。

私は、ここにPMの評価の難しさがあると思っています。

トラブルが起きると、PMは一気に目立つ

特に経営層から見た場合、この傾向は強くなると思います。

経営層は、会社で動いているすべてのプロジェクトを細かく見ることはできません。

数十、数百のプロジェクトが動いている会社であれば、なおさらです。

では、経営層のところにどんなプロジェクトの情報が上がってくるでしょうか。

当然、

• 大きなトラブルが起きた
• 大幅な遅延が発生した
• 大きな損失が発生しそう
• 顧客から重大なクレームが入った
• プロジェクトの継続が危ぶまれている

といったプロジェクトです。

つまり、

問題が起きたプロジェクトほど、経営層の目に入りやすい。

これは、ある意味当然です。

経営層は、問題のないプロジェクトをすべて確認する必要はありません。

しかし、問題が起きているプロジェクトには対応する必要があります。

その結果、

トラブルを解決したPMは、経営層から見ても非常に目立つ。

という構造が生まれます。

「トラブルを解決したPM」が評価されやすい理由

例えば、こんなプロジェクトがあったとします。

プロジェクトAは順調に進んでいます。

PMが、

• リスクを事前に潰す
• 顧客と認識を合わせる
• メンバーの問題を早期に発見する
• スケジュールの遅延要因を事前に潰す

といった活動をしています。

結果として、大きな問題は起きませんでした。

プロジェクトは予定通り完了しました。

一方、プロジェクトBでは大きなトラブルが発生しました。

経営層にも報告が上がります。

担当PMがプロジェクトを立て直し、最終的には成功させました。

どちらのPMが経営層の記憶に残るでしょうか。

おそらく、プロジェクトBのPMです。

なぜなら、

経営層がPMの仕事を見るきっかけがあったからです。

これが、トラブルを解決したPMが評価されやすい理由の一つだと思います。

トラブルがないと、PMの仕事そのものが見えない

さらに問題なのは、

PMが何をしているのかが見えなくなること。

です。

プロジェクトが順調に進んでいると、

「特に問題ありません」

という報告になりがちです。

しかし、その「特に問題ありません」の裏側では、PMがさまざまな活動をしているかもしれません。

例えば、

• リスクを事前に潰している
• ステークホルダーの認識を合わせている
• メンバーの不満を早期に拾っている
• チーム間のコンフリクトを解消している
• 顧客の期待値を調整している
• 遅延につながる要因を先回りして対応している

などです。

ただし、これらの活動は、

問題が起きなかった瞬間に、存在していなかったかのように見えてしまいます。

「何も起きなかった」と「何もしなかった」は違う

ここは非常に重要です。

プロジェクトでトラブルが起きなかった。

だからといって、

「PMは何もしなかった」

わけではありません。

むしろ、

PMが何かをしたから、トラブルが起きなかった。

可能性があります。

例えば、

「顧客から仕様変更の要求が出てきそうだった」

↓

PMが事前に顧客と認識を合わせた。

↓

仕様変更が発生しなかった。

この場合、結果だけを見ると、

「仕様変更はありませんでした」

となります。

しかし実際には、

PMが事前に動いたことで、仕様変更による混乱を防いだ。

とも考えられます。

この差は非常に大きいと思います。

予防型PMの成果は「起きなかったこと」

トラブルを起こさないPMの特徴は、

成果の中に「起きなかったこと」が多い。

ことです。

• 発生しなかった遅延
• 発生しなかったクレーム
• 発生しなかった品質問題
• 発生しなかったコンフリクト
• 発生しなかったコスト超過
• 発生しなかった重大リスク

こうしたものは、実際にはプロジェクトにとって非常に価値があります。

しかし、

起きなかった問題には、目に見える「事件」がありません。

そのため、評価する側からすると難しいのです。

「トラブルがないPM」と「トラブルを解決したPM」を比較してみる

もちろん、これは「トラブルを解決するPMより、トラブルを起こさないPMのほうが必ず優秀」という意味ではありません。

予想外の問題に対応する能力も、PMにとって重要なスキルです。

ただ、

評価されやすさには違いがある。

ということです。

では、評価されないことを受け入れるしかないのか？

私は、そうは思いません。

ここで重要なのが、

PM自身が自分の仕事と実績をPRする。

という考え方です。

「トラブルが起きなかったから、自分の仕事を説明できない」

ではなく、

「なぜトラブルが起きなかったのか」を説明すればいい。

のです。

例えば、

「問題なくプロジェクトを完了しました」

だけではなく、

「プロジェクト開始時に15件のリスクを特定し、そのうち重要度の高い5件について事前対策を実施しました。その結果、重大な遅延や品質問題を発生させることなく完了しました。」

と説明する。

これなら、PMが何をしたのかが見えてきます。

重要なのは「定量化」

ここで特に重要になるのが、

実績を定量的に示すこと。

です。

「ステークホルダーとの関係を改善しました」

という説明では、人によって評価が変わります。

「かなり改善した」と感じる人もいれば、

「それで何が変わったの？」

と思う人もいるでしょう。

一方、

「ステークホルダーとの定例会を月1回から週1回に変更し、意思決定事項を○件明確化した」

などと具体的に示せば、評価する側も判断しやすくなります。

「リスクを潰した」を数字で示す

例えば、リスクマネジメントなら、

「リスクを適切に管理しました」

ではなく、

「プロジェクト開始時に20件のリスクを特定し、重要度の高い8件について事前対策を実施した」

とします。

さらに、

「そのうち3件は、対策をしなければ納期遅延につながる可能性があった」

まで説明できれば、より価値が伝わります。

もちろん、数字を作るために無理に数値化する必要はありません。

大切なのは、

自分が実際に行った活動と、その結果をできるだけ客観的に示すこと。

です。

プロジェクトによって「重要な活動」は違う

ここで注意したいのは、

「PMはリスクを何件潰せばいい」

という単純な話ではないことです。

プロジェクトによって、重要なポイントは変わります。

あるプロジェクトではリスクマネジメントが重要かもしれません。

別のプロジェクトではステークホルダーとの認識合わせが重要かもしれません。

また別のプロジェクトでは、メンバーの育成やチーム間の調整が重要かもしれません。

だからこそ、

何をしたかではなく、そのプロジェクトにとって何が重要だったのか

を説明する必要があります。

私自身も「トラブルを起こさないためのPM」を経験した

以前紹介した、若手2人と進めた小規模プロジェクトがあります。

メンバーは入社3年以内の若手でした。

前のプロジェクトでは、メンバーがプロジェクトマネジメントについて十分に理解していなかったことで、指示がうまく伝わらず、納期遅延を起こしてしまいました。

そこで次のプロジェクトでは、その経験を教訓にしました。

単に、

「これをやってください」

と指示するのではなく、

なぜ計画段階でリスクを考えるのか。

なぜスケジュールを立てるのか。

なぜコミュニケーションルールを決めるのか。

といったことまで説明しました。

その結果、メンバー自身がプロジェクトマネジメントを理解するようになりました。

そしてプロジェクトの途中では、メンバー自身が新たなリスクに気づき、

「このリスクがあります」

と自発的に伝えてくれるようになりました。

プロジェクトも問題なく進めることができました。

このプロジェクトで、私は大きなトラブルを解決したわけではありません。

しかし、

過去の失敗から教訓を得て、次のプロジェクトでトラブルを防ぎ、さらにメンバーを成長させた。

これも、PMとしての一つの実績だと考えています。

評価されるPMになるために、トラブルを起こしてはいけない

ここで一つ、絶対に間違えてはいけないことがあります。

「トラブルを起こしたほうが評価されるなら、トラブルを起こせばいい」

ということではありません。

当然ですが、これは本末転倒です。

PMの目的は、

自分が評価されることではなく、プロジェクトを成功させること。

だからです。

トラブルを起こして目立つより、

トラブルを起こさずプロジェクトを成功させる。

そのうえで、

「なぜ成功できたのか」を説明する。

これがPMとして正しい方向だと思います。

「評価されるPM」ではなく「評価できるPM実績」を作る

だから私は、

評価されるために仕事をするのではなく、評価できる形で実績を残す。

ことが重要だと考えています。

例えばプロジェクト終了時に、

• プロジェクトの目標
• 目標達成度
• プロジェクトの難易度
• 重要だった課題
• 自分が実施した施策
• 事前に防いだリスク
• 定量的な成果
• メンバーや組織に残したもの

を振り返ってみる。

そうすると、

「このプロジェクトでは何を成し遂げたのか？」

が見えてきます。

「何も起きなかった」を実績に変える

PMの評価を考えるとき、私はこの視点が重要だと思います。

例えば、

「納期遅延が発生しなかった」

だけでは、単なる結果に見えます。

しかし、

「過去のプロジェクトで納期遅延につながった要因を分析し、今回は○○という対策を実施。その結果、納期遅延を発生させずに完了した。」

と説明すればどうでしょうか。

そこには、

経験

↓

教訓

↓

対策

↓

結果

というPMの仕事が見えてきます。

これなら、「何も起きなかった」という結果も、PMの実績として評価できます。

PMの実力と評価のギャップを埋める

私は、PMには、

「プロジェクトを成功させる力」

と、

「自分がプロジェクトを成功させたことを説明する力」

の両方が必要だと思っています。

これは少し厳しい話かもしれません。

しかし、どれだけ優秀なPMでも、自分の実績を説明できなければ、市場では評価されにくいからです。

だから、

「自分はトラブルを起こさないPMだから、評価されなくても仕方がない」

と諦める必要はありません。

むしろ、

「トラブルを起こさないために、自分は何をしたのか？」

を整理する。

そして、

できるだけ定量的に示す。

これが重要です。

まとめ：トラブルを起こさないPMは、自分の仕事を見える化しよう

なぜトラブルを起こさないPMは評価されにくいのでしょうか。

それは、PMとしての実力が低いからではありません。

トラブルが起きないと、PMの仕事が見えにくいからです。

特に経営層は、すべてのプロジェクトを細かく見ることができません。

そのため、トラブルが起きて報告が上がってくるプロジェクトや、そのプロジェクトを立て直したPMのほうが目立ちやすくなります。

一方、トラブルを起こさないPMは、

リスクを潰した。

認識を合わせた。

問題を早期に発見した。

メンバーを支援した。

ステークホルダーを調整した。

といった仕事をしていても、それが見えにくい。

だからこそ、

PM自身が自分の実績をPRすることが重要です。

特に、

「何をしたのか」だけではなく、「どれだけの成果につながったのか」を定量的に示す。

これがポイントです。

トラブルを起こさないことは、決して「何もしなかった」ということではありません。

むしろ、

何も起きなかったという結果の裏側に、PMの高度なマネジメントが隠れていることがあります。

だから、PMとして目指したいのは、

トラブルを起こして目立つPMではなく、トラブルを起こさず、そしてその価値を説明できるPM。

私は、そんなPMこそ「PM戦闘力の高いPM」だと考えています。

あなたは、最近のプロジェクトで「起きなかったトラブル」をいくつ説明できるでしょうか？

そして、その中で自分がどんな行動をしたのか、数字で説明できるでしょうか？

PM戦闘力シリーズ

• PM戦闘力とは？PMとしての強さを決める要素を考えてみた
• PM経験年数だけでは戦闘力は上がらない？経験の質が重要な理由
• PM戦闘力を高めるPMスキルとは？重要な4つのスキルを考えてみた
• PM資格は本当に必要？資格を「戦闘力の装備」として考える
• PMの実績とは何か？「トラブルを解決した」だけが実績ではない

• あなたのPM戦闘力はどれくらい？PM戦闘力を自己診断する

• PM戦闘力を高めるには？「経験→実践→振り返り」の成長サイクルを回そう

• PM戦闘力と市場価値の関係とは？PMとしての実力を転職市場でどう伝えるか

The post なぜトラブルを起こさないPMは評価されにくいのか？ first appeared on PM道場.

転職活動などで、こう聞かれることがあります。

そのとき、あなたなら何を答えるでしょうか。

「大規模プロジェクトを成功させました」

「トラブルになったプロジェクトを立て直しました」

「○億円規模のプロジェクトを担当しました」

こうした経験は、確かに分かりやすい実績です。

特にPMの場合、トラブルが発生したプロジェクトを立て直した経験は、非常に目立つ実績になります。

しかし、私はそれだけがPMの実績ではないと考えています。

トラブルを起こさず、プロジェクトを当初の目標通りに成功させたことも、立派なPMの実績です。

では、PMにとって「実績」とは何なのでしょうか。

今回は、PM戦闘力という考え方から、PMの実績について考えてみます。

PMの実績とは「プロジェクトの目標を達成したこと」

私は、PMの実績をシンプルに考えています。

プロジェクトの開始時に掲げた目標を達成したかどうか。

これがPMの実績の基本だと思います。

例えば、プロジェクトの目標が、

• システムを予定通りリリースする
• 顧客の要求を満たす
• 予算内で完成させる
• 品質基準を満たす
• 新しい技術を実用化する
• 新規顧客との関係を構築する
• 若手メンバーが自律的にプロジェクトを進められるようにする

というものであれば、それを達成することが成果になります。

つまり、

「何を達成したのか」ではなく、「そのプロジェクトで何を目標としていたのか」が重要なのです。

実績の「強さ」は目標の難易度で変わる

もちろん、目標を達成すればすべて同じ価値の実績になるわけではありません。

目標の難易度によって、実績の強さは変わります。

例えば、2人のチームで定型的なプロジェクトを予定通り完了させた。

これも立派な実績です。

一方で、

100人規模のメンバーを複数チームに分け、複数のベンダーを管理しながら、難しい顧客とのプロジェクトを成功させた。

となれば、求められるPM能力は大きく異なります。

さらに、前例のない技術を使い、成功確率が低いプロジェクトを、重大なトラブルを起こすことなく成功させた。

となれば、さらに難易度は高くなります。

だから私は、

PMの実績は「何を達成したか」だけでなく、「どれだけ難しい目標を達成したか」まで考える必要があると思っています。

なぜ「トラブルを解決した実績」は目立つのか？

では、なぜPMの実績というと、「トラブルになったプロジェクトを立て直した」という話が目立つのでしょうか。

理由は単純です。

多くの関係者の目に触れるからです。

特に大きなトラブルになると、プロジェクト内部だけの問題ではなくなります。

• 顧客が問題を認識する
• 上司が問題を認識する
• 部門長が問題を認識する
• 場合によっては、さらに上位のマネジメントまで報告される

つまり、

トラブルが大きくなるほど、そのプロジェクトを担当しているPMも目立つのです。

そこでPMがプロジェクトを立て直せば、「あのPMが問題を解決した」という評価につながります。

これは決して悪いことではありません。

実際、難しいトラブルを解決することは高いPM能力を必要とします。

しかし、ここには一つの問題があります。

「トラブルを起こさないPM」は目立たない

プロジェクトで何も問題が起きなかったとします。

• 顧客から大きなクレームもない
• スケジュールも遅れない
• 予算も超過しない
• 品質問題も起きない
• プロジェクトメンバーも大きな不満を抱えていない
• 予定通りプロジェクトが完了した

これはPMとして素晴らしい成果です。

しかし、周囲から見ると、「特に問題はなかった」だけに見えてしまうことがあります。

PMが、

• リスクを事前に洗い出していた
• ステークホルダーの認識を合わせていた
• メンバーの不満を早期に拾っていた
• 問題が起きる前に対策していた
• プロジェクトで重要なポイントを見極めていた

としても、問題が起きなければ、それらの努力は見えにくくなります。

これが、PMの評価の難しいところだと思います。

「何も起きなかった」は「何もしなかった」ではない

ここは、PMの実績を考えるうえで非常に重要なポイントです。

何も起きなかった。

この結果だけを見ると、PMは何もしていなかったようにも見えます。

しかし実際には、

「何も起きないようにしていた」

可能性があります。

例えば、プロジェクト開始時にリスクを洗い出していた。

重要なステークホルダーと事前に認識を合わせていた。

メンバーが困っていることを早期に把握していた。

問題が大きくなる前にエスカレーションしていた。

こうしたPMの行動によって、トラブルが発生しなかった可能性があります。

つまり、

トラブルが起きなかったこと自体が、PMのマネジメントの成果である場合があるのです。

トラブルを解決することと、トラブルを起こさないこと

もちろん、トラブルを解決する能力は重要です。

プロジェクトでは、どれだけ準備しても予想外の問題が発生することがあります。

そのときに冷静に状況を整理し、関係者を巻き込み、解決に導くことができるPMは強いPMです。

しかし、

そもそもトラブルを発生させないこと

も同じくらい、あるいはそれ以上に重要ではないでしょうか。

顧客はトラブルを望んでいません。

プロジェクトメンバーも望んでいません。

会社も望んでいません。

それなら、

トラブルを解決できるPMより、トラブルを起こさせないPMのほうがプロジェクトにとって価値がある

と考えることもできます。

「トラブルを起こさない」は何もしないことではない

もちろん、「トラブルを起こさないPM」と言っても、「何もしなかったら問題が起きなかった」という意味ではありません。

むしろ逆です。

プロジェクトにとって何が重要なのかを見極め、その重要なポイントに対して適切なマネジメントを行う必要があります。

例えば、

あるプロジェクトでは、リスクを事前に潰すことが重要かもしれません。

別のプロジェクトでは、ステークホルダーの認識を合わせることが重要かもしれません。

また別のプロジェクトでは、メンバーの不満を早期に拾うことが重要かもしれません。

どんなプロジェクトでも同じことをすればよいわけではありません。

そのプロジェクトにとって何が重要なのかを把握し、それを実行する。

これがPMの重要な仕事だと私は考えています。

実績は「プロジェクトの規模」だけでは決まらない

PMの実績を語るとき、「何億円規模のプロジェクトを担当しました」「100人規模のプロジェクトをマネジメントしました」という説明をすることがあります。

確かに、規模は実績の強さを判断する一つの材料になります。

しかし、それだけではありません。

例えば、小さなプロジェクトでも、

• 経験の浅いメンバーを育成しながら進める
• 難しい顧客との関係を構築する
• 新しい技術を扱う
• 限られた期間で成果を出す
• プロジェクトの進め方そのものを改善する

といった難しい目標が設定されていることがあります。

逆に、大規模プロジェクトだからといって、必ずしも難易度が高いとは限りません。

だから、

プロジェクトの規模は実績の一つの要素であって、実績そのものではない

と考えるべきだと思います。

「人を育てた」こともPMの実績になる

ここで、私自身の経験を紹介します。

ある小規模なプロジェクトで、私以外のメンバーは入社5年以内の若手が2人でした。

経験も浅く、そのままではプロジェクトを進めていくことに不安がありました。

そこで私は、プロジェクトを進めるだけではなく、

プロジェクトマネジメントそのものをメンバーに教えながら進める

ことにしました。

例えば、

• なぜ計画段階でリスクを考えるのか
• なぜスケジュールを立てるのか
• なぜコミュニケーションのルールを決めるのか

といったことを説明しました。

単純に、「これをやってください」と指示するのではありません。

「なぜ、これをやる必要があるのか」まで理解してもらうことを意識しました。

結果として、プロジェクトだけでなくメンバーも成長した

このプロジェクトは、結果としてうまく進めることができました。

しかし、私が実績として特に価値があると感じているのは、それだけではありません。

プロジェクトを進める中で、若手メンバーがプロジェクトマネジメントについて理解するようになりました。

さらに、あるときメンバー自身が新しいリスクに気づき、「このリスクがあります」と自発的に伝えてくれるようになりました。

これは、プロジェクトマネジメントを教えたことが、単なる知識の習得で終わらず、メンバー自身の行動に変わったということです。

プロジェクトを成功させる。

そして、メンバーも成長させる。

私は、この両方がこのプロジェクトの成果だったと考えています。

そして、この若手メンバーの育成については、会社からも評価してもらうことができました。

「成果」はプロジェクトの目標によって変わる

この経験からも分かるように、「人を育てたことは実績なのか？」という問いに対する答えは、

プロジェクトの目標だったのであれば、実績になる

です。

例えば、「若手メンバーが自律的にプロジェクトを進められるようになる」ということをプロジェクトの目標として設定していたのであれば、それを達成したことは明確な成果です。

一方、プロジェクトの目標に含まれていないのに、「若手を育てました」とだけ言っても、それがどれだけPMとしての実績になるのかは判断しにくいでしょう。

だからこそ、

実績を考えるときには、まずプロジェクトの目標を見る

ことが重要です。

実績とは「何をやったか」ではなく「何を達成したか」

ここは、転職などでPMの実績を説明するときにも重要です。

例えば、「100人のプロジェクトをマネジメントしました」だけでは、実績としては十分ではありません。

重要なのは、

その100人のプロジェクトで何を達成したのか？

です。

例えば、

「100人規模のプロジェクトで、複数チームをマネジメントし、納期・品質・コストの目標を達成した」

となれば、かなり具体的になります。

さらに、

「複数ベンダー間の調整が課題だったが、役割とコミュニケーションルールを明確化し、納期遅延を発生させずに完了した」

となれば、

• どんな難しさがあったのか
• 何をしたのか
• 何を達成したのか

まで分かります。

PMの実績を説明するときは、

プロジェクトの目標 → 難易度 → 自分の行動 → 結果

という順番で整理すると、自分の実績を伝えやすくなります。

資格と実績は役割が違う

前の記事では、資格を「装備」と表現しました。

では、実績は何でしょうか。

私は、

• 資格＝「この知識・能力を持っている」と示す装備
• 実績＝「実際にこれを成し遂げた」という証拠

だと考えています。

例えば、PMP®を持っている。

これは、一定の知識や経験を持っていることを対外的に示す材料になります。

一方、

「○○規模のプロジェクトで、○○という課題に対して○○を実施し、○○という目標を達成した」

という実績は、

実際にプロジェクトで何を成し遂げたのか

を示します。

だからこそ、PM戦闘力を高めるうえでは、

資格と実績の両方

が重要になります。

「市場で強いPM」は実績を説明できる

PMとして実力があっても、それを相手に伝えられなければ、市場では評価されにくいことがあります。

例えば転職活動で、「PMとして10年経験があります」だけでは、あなたの強さを十分に伝えられません。

しかし、

「難しいステークホルダーが関わるプロジェクトを担当し、事前にリスクと関係者の認識を整理することで、大きなトラブルを発生させずにプロジェクトを完了させた」

と説明できれば、PMとしてどのような力を持っているのかが見えてきます。

さらに、

「その経験を次のプロジェクトでも活かし、若手メンバーが自律的にリスクを発見できるようなマネジメントを実践した」

となれば、

経験 → スキル → 実績

というつながりも見えてきます。

これが、市場で評価されるPM戦闘力につながるのだと思います。

実績を作るために「目立つ仕事」をする必要はない

ここまで読むと、「では、転職で評価されるために、難しいトラブル案件を担当しなければならないのか？」と思うかもしれません。

私は、そうは思いません。

むしろ、トラブルを起こさないことも実績です。

重要なのは、

自分が担当したプロジェクトで、何を目標として掲げ、その目標をどのように達成したのか

を説明できることです。

そのためには、プロジェクト開始時から、

• 何を成功とするのか
• 何を目標とするのか
• 何が難しいのか
• 何に注意する必要があるのか

を意識しておくことが重要です。

そうすれば、プロジェクトが終わったときに、「このプロジェクトで自分は何を成し遂げたのか？」を振り返ることができます。

PMの実績は、プロジェクトが終わってから作るものではない

私は、実績はプロジェクト終了時に突然生まれるものではないと思っています。

プロジェクトの開始時に、

「このプロジェクトは何を達成すれば成功なのか？」

を明確にする。

そして、

「そのためにPMとして何をするのか？」

を考える。

プロジェクトを進める。

最後に、

「目標を達成できたのか？」

を振り返る。

この一連のプロセスによって、実績が生まれます。

だからこそ、

PMとしての実績を作ることは、プロジェクトの目標を達成することとほぼ同じ

だと私は考えています。

まとめ：PMの実績は「目立った出来事」ではなく「目標を達成した証拠」

PMの実績というと、「大規模プロジェクトを担当した」「トラブルプロジェクトを立て直した」といった、目立つ経験を思い浮かべるかもしれません。

もちろん、それらは価値のある実績です。

しかし、それだけではありません。

私は、

PMの実績とは、プロジェクトの開始時に掲げた目標を達成したこと

だと考えています。

その目標が、

• 納期を守る
• 品質を確保する
• 予算を守る
• 顧客の要求を満たす
• 難しいステークホルダーをまとめる
• リスクを事前に潰す
• メンバーを育成する
• メンバーが自律的に動けるようにする

など、何であっても構いません。

重要なのは、

そのプロジェクトにとって何が成功なのか

です。

そして、トラブルを解決したことだけが実績ではありません。

トラブルを起こさず、何事もなくプロジェクトを成功させたことも、PMにとって立派な実績です。

むしろ、その「何事もなかった」という結果の裏側で、PMがどれだけリスクを潰し、ステークホルダーと認識を合わせ、メンバーを支援していたのか。

そこにPMとしての実力が隠れているかもしれません。

だから、PMとしての実績を振り返るときには、

「私はどんなトラブルを解決したか？」

だけではなく、

「私はどんなプロジェクトの目標を達成したか？」

と考えてみてください。

もしかすると、あなたが「大した実績ではない」と思っていたプロジェクトの中にも、PMとしての大きな実績が眠っているかもしれません。

そして、その実績を言語化することが、PMとしての市場価値を高める第一歩になるのだと思います。

PM戦闘力シリーズ

• PM戦闘力とは？PMとしての強さを決める要素を考えてみた
• PM経験年数だけでは戦闘力は上がらない？経験の質が重要な理由
• PM戦闘力を高めるPMスキルとは？4つのスキルを考えてみた
• PM資格は本当に必要？資格を「戦闘力の装備」として考える
• なぜトラブルを起こさないPMは評価されにくいのか？
• あなたのPM戦闘力はどれくらい？PM戦闘力を自己診断する
• PM戦闘力を高めるには？「経験→実践→振り返り」の成長サイクルを回そう
• PM戦闘力と市場価値の関係とは？PMとしての実力を転職市場でどう伝えるか

転職エージェントを使って自分の実績を評価してもらってみませんか？

自分の実績を客観的に評価してもらう方法として転職エージェントを使うことをお勧めします。

転職を決めていなくても、
「今の自分にはどんな選択肢があるのか」を知るために転職サービスを使う のはとても有効です。

• PM・IT人材のための転職・キャリアサービス一覧

The post PMの実績とは何か？「トラブルを解決した」だけが実績ではない first appeared on PM道場.

PMを目指している人なら、一度は考えたことがあるのではないでしょうか。

実際、PMの仕事では資格がなくてもプロジェクトをマネジメントすることはできます。

では、資格を取る意味はないのでしょうか。

私はそうは考えていません。

むしろ、PMとして強くなりたいのであれば、資格は取ったほうがいいと考えています。

ただし、資格そのものがPM戦闘力になるわけではありません。

私は資格を、

「PM戦闘力の装備」

だと考えています。

資格という装備を身につけることで、対外的な評価を高めることができます。

そして、資格取得のために学んだ知識は、自分自身のPMとしての実力になります。

今回は、PM戦闘力という考え方から、PM資格の意味について考えてみます。

PM資格は「装備」である

RPGのキャラクターをイメージしてみてください。

キャラクター自身の能力値が、

• 経験
• スキル
• 判断力
• 適用力

だとします。

そこに武器や防具を装備することで、さらに強くなります。

PMにとって、その「装備」にあたるものの一つが資格です。

例えば、

• IPAプロジェクトマネージャ試験
• PMP®
• CSM®
• その他のPM・アジャイル・スクラム関連資格

などがあります。

資格を取得したからといって、突然PMとしての実力が上がるわけではありません。

しかし、資格を取得することで、

「この人は一定の知識を持っている」

ということを、第三者に示しやすくなります。

これが資格の大きな価値です。

資格には「見栄え」の価値もある

資格を「装備」と表現する理由は、もう一つあります。

対外的に見栄えがするからです。

少し身も蓋もない話に聞こえるかもしれません。

しかし、PMとして仕事をするうえで、これは非常に重要です。

例えば、初対面の人から、

「あなたはどのくらいPMができますか？」

と聞かれたとします。

PMの実力を正確に伝えることは簡単ではありません。

「10年間PMをやっています」と伝えても、相手はその10年間にどのような経験をしたのか分かりません。

一方、

• 「IPAプロジェクトマネージャ試験に合格しています」
• 「PMP®を取得しています」

と伝えれば、相手は一定の評価をしやすくなります。

つまり資格には、

自分の実力を第三者に分かりやすく伝える

という機能があります。

これは転職でも、社内評価でも、顧客との関係でも役立ちます。

「プロジェクトで強い」と「市場で強い」は違う

ここはPM戦闘力を考えるうえで重要なポイントです。

私は以前の記事で、

プロジェクトの中で強いPMと、市場で強いPMは必ずしも同じではない

と考えました。

例えば、実際のプロジェクトでは非常に優秀なのに、その実力を客観的に示せる資格や実績を持っていないPMもいるでしょう。

逆に、資格をたくさん持っていても、実際のプロジェクトではうまくマネジメントできない人もいます。

理想は、

プロジェクトでも強く、市場でも強いPM

です。

そのためには、

• 経験
• スキル
• 適用力
• 資格
• 実績

が必要になってきます。

資格は、その「市場での強さ」を支える装備の一つなのです。

なぜ資格を取ったほうがいいのか？

私が資格を取ったほうがいいと考える理由は、大きく2つあります。

① 対外的な評価につながる

これは先ほど説明した通りです。

資格を持っていることで、

• 転職時のアピール
• 社内での評価
• 顧客からの信用
• PMとしての能力の証明
• 官公庁などの案件での要件への対応

などにつながります。

特に案件によっては、PMに資格保有者を配置することが条件になっているケースもあります。

つまり、資格は単なる自己満足ではありません。

実際の仕事の機会につながる可能性がある装備です。

② 資格取得を目的にすると、知識が身につきやすい

もう一つ、私が資格をおすすめする大きな理由があります。

それは、

資格取得を目的にすることで、体系的に知識を学びやすくなる

ことです。

PMについて勉強しようと思っても、

「今日は何を勉強しよう？」

となってしまうことがあります。

一方、資格試験には試験範囲があります。

合格という明確な目標もあります。

そのため、

「資格に合格する」という目的を持って勉強することで、PMに必要な知識を体系的に学びやすくなる

のです。

私は、これが資格の非常に大きな価値だと考えています。

私が取得して感じた資格の価値

私自身も、

• IPAプロジェクトマネージャ
• PMP®
• CSM®

などの資格を取得しました。

それぞれ、得られたものが違いました。

IPAプロジェクトマネージャ試験

IPAプロジェクトマネージャ試験を取得したことで、ITプロジェクトのPMとして必要な知識を体系的に整理できました。

特に良かったのは、

自分が経験していない分野のプロジェクトについても理解しやすくなった

ことです。

自分が実際に経験しているプロジェクトだけでは、どうしても経験できる領域に限界があります。

しかし、試験勉強を通じてさまざまなITプロジェクトについて学ぶことで、

「こういうプロジェクトでは、こういう問題が起きる可能性があるのか」

と、自分の経験の外側にある知識を得ることができました。

これは、私が講師としてPMを教える際にも役立ちました。

受講者にはIT系の方も多かったため、自分自身が経験していないITプロジェクトについても理解するための土台になったからです。

PMP®

PMP®では、PMBOK®︎を中心としたプロジェクトマネジメントの体系を学ぶことができました。

実際にPMとして仕事をしていると、目の前のプロジェクトを何とか成功させることに集中しがちです。

その結果、

「自分はこの方法でやっているけど、本当にこれが一般的なプロジェクトマネジメントなのだろうか？」

と感じることもあります。

資格取得の勉強をすることで、自分の経験を体系的なプロジェクトマネジメントの知識と照らし合わせることができました。

これは非常に大きな意味があったと感じています。

CSM®

CSM®では、アジャイルやスクラムの考え方を学びました。

これも、自分が経験してきたプロジェクトだけでは得られなかった知識です。

資格を取ることそのものだけではなく、

「自分が知らなかったプロジェクトマネジメントの考え方を学ぶきっかけになる」

というところに資格の価値があります。

ただし、資格を取っただけではPMとして強くならない

ここは非常に重要です。

資格はおすすめします。

しかし、

資格を取れば優秀なPMになれる

とは思っていません。

むしろ、資格を取得して初めて、

「ここからが実践だ」

と考えるべきだと思っています。

資格取得の勉強では、プロジェクトマネジメントの体系を学ぶことができます。

しかし、それを実際のプロジェクトで使うのは別の話です。

「リスク登録簿」を作れることと、リスクをマネジメントできることは違う

例えば、リスクマネジメントについて考えてみます。

PMP®の資格取得に向けて勉強すると、

• リスクを特定する
• リスクを分析する
• 対応策を検討する
• リスクを監視する

といった、リスクマネジメントの考え方を学ぶことができます。

リスク登録簿についても、

「こういう項目を整理して管理する」

という方法を知ることができます。

しかし、実際のプロジェクトでリスク登録簿を作ろうとすると、話が変わります。

例えば、

そもそも、どんなリスクを洗い出せばいいのか？

という問題があります。

さらに、

• そのリスクの発生確率や影響度をどう判断するのか？
• どんな対応策が本当に有効なのか？
• どのリスクを優先して対応するべきなのか？

といった判断が必要になります。

ここには、単純な知識だけでは対応できない部分があります。

つまり、

資格で学んだ知識を、実際のプロジェクトで使えるスキルに変える必要がある

のです。

資格は「装備」、実務は「使いこなす場所」

ここまでをRPGに例えると、さらに分かりやすいと思います。

資格を取得する。

↓

新しい装備を手に入れる。

しかし、強い武器を手に入れただけでは、強いキャラクターにはなりません。

その武器を使って実際に戦う必要があります。

PMで言えば、

資格取得

↓

PM知識を身につける

↓

実際のプロジェクトで使う

↓

経験を積む

↓

失敗・成功から学ぶ

↓

スキルとして定着する

という流れです。

だから、

資格はPM戦闘力そのものではなく、PM戦闘力を高めるための装備

なのです。

資格取得によって「自信」という装備も増えた

私自身、資格を取得して感じたことがあります。

それは、

自信がついた

ということです。

資格を取得したことで、

• 「自分はこれだけ勉強した」
• 「一定の基準をクリアした」

という感覚を持てるようになりました。

これも「装備」の一つだと思っています。

もちろん、自信だけでプロジェクトを成功させることはできません。

しかし、PMとして難しい判断をするときに、

「自分はPMについて体系的に勉強してきた」

という感覚があることは、心理的な支えになります。

資格という目に見える装備が加わったことで、自分自身の自信にもつながりました。

PM経験によって、取得すべき資格は変わる

では、どんな人がどんな資格を目指せばよいのでしょうか。

私は、PM経験によって考え方を変えるとよいと思います。

PM経験が浅い人

まだPM経験が浅いのであれば、

PMOなどの立場でプロジェクトマネジメントを学びながら、資格取得を目指す

という方法が考えられます。

まずは、

• プロジェクトとは何か
• PMは何をするのか
• スコープとは何か
• リスクとは何か
• ステークホルダーとは何か

といった基本的な知識を体系的に学ぶ。

資格勉強を、そのためのきっかけとして使うのも良いでしょう。

PM経験がある人

すでにPM経験があるのであれば、

自分の経験を体系化するために資格を活用する

という考え方がおすすめです。

例えば、

• IPAプロジェクトマネージャ
• PMP®
• アジャイル関連資格
• スクラム関連資格

など、自分が携わっているプロジェクトや、今後目指したいキャリアに合った資格を選ぶ。

実務経験があるからこそ、

「あのプロジェクトで起きていたことは、この考え方だったのか」

と、資格勉強で得た知識を自分の経験と結びつけることができます。

PM経験が豊富な人

PM経験が豊富になってくると、

資格取得だけを目的にするのではなく、実践と知識習得を同時に進める

ことが重要だと思います。

実際のプロジェクトで課題を感じる。

↓

その課題について学ぶ。

↓

資格や研修などで体系的な知識を得る。

↓

実際のプロジェクトで使ってみる。

↓

結果を振り返る。

こうした循環を作ることで、資格が単なる「肩書き」ではなく、PM戦闘力につながっていきます。

資格は「市場での強さ」を高める装備でもある

ここまで、資格の知識面について話してきました。

しかし、もう一つ忘れてはいけないのが、

対外的な評価

です。

PMとしての実力を第三者に伝えるのは簡単ではありません。

「私はプロジェクトを成功させられます」

と言っても、それだけでは判断できません。

しかし、

• PMP®を取得している
• IPAプロジェクトマネージャ試験に合格している

といった情報があれば、相手は一定の評価をしやすくなります。

転職でも同じです。

資格だけで採用が決まるわけではありません。

しかし、

経験＋スキル＋資格

が揃っていれば、自分のPMとしての強さをより説明しやすくなります。

資格は、

「自分のPM戦闘力を市場に見せるための装備」

でもあるのです。

だから、PM資格は「取ったほうがいい」

ここまでの話を踏まえて、私は、

PM資格は取ったほうがいい

と考えています。

理由はシンプルです。

資格には、

① 対外的な評価につながる

という価値があります。

そして、

② 資格取得を目標にすることで、PM知識を体系的に学べる

という価値があります。

さらに、資格取得によって得た知識を実務で使えば、

③ 経験とスキルを高めることができる

可能性があります。

つまり、

資格 → 知識 → 実践 → スキル → 経験

という流れを作ることができます。

そして資格という「装備」は、

自分のPMとしての実力を対外的に示す

ことにも役立ちます。

まとめ：資格はPM戦闘力そのものではなく、「戦闘力を高める装備」

PM資格は必要なのか。

私は、

取ったほうがいい

と考えています。

ただし、

資格を持っている＝強いPM

ではありません。

資格はあくまで「装備」です。

資格証や合格実績は、対外的に自分の能力を示すための装備です。

そして、資格取得のために学んだ知識は、自分自身のPMとしての実力になります。

しかし、その知識を実際のプロジェクトで使えるようにするには、さらに経験と実践が必要です。

だからこそ、

資格を取って終わりではなく、資格で得た知識をプロジェクトで使う。

これが重要です。

資格という装備を手に入れる。

↓

知識を身につける。

↓

実際のプロジェクトで使う。

↓

経験を積む。

↓

スキルとして定着させる。

↓

さらに強いPMになる。

私は、このサイクルを回すことがPM戦闘力を高める一つの方法だと考えています。

あなたは今、どんな「装備」を持っていますか？

そして、その装備を実際のプロジェクトで使いこなせているでしょうか？

PM戦闘力シリーズ

• PM戦闘力とは？PMとしての強さを決める要素を考えてみた
• PM経験年数だけでは戦闘力は上がらない？経験の質が重要な理由
• PM戦闘力を高めるPMスキルとは？重要な4つのスキルを考えてみた
• PMの実績とは何か？「トラブルを解決した」だけが実績ではない
• なぜトラブルを起こさないPMは評価されにくいのか？
• あなたのPM戦闘力はどれくらい？PM戦闘力を自己診断する
• PM戦闘力を高めるには？「経験→実践→振り返り」の成長サイクルを回そう
• PM戦闘力と市場価値の関係とは？PMとしての実力を転職市場でどう伝えるか

プロジェクトマネージャ試験についての記事はこちら

• 【合格体験記】IT未経験からプロジェクトマネージャ試験に合格するまでの勉強法を公開
• 【2026年版】プロジェクトマネージャ試験おすすめ参考書ランキング｜合格者が本当に役立った3冊を比較

The post PM資格は本当に必要？資格を「戦闘力の装備」として考える first appeared on PM道場.

「PMとしてもっと成長したい」

そう思ったとき、何を身につければよいのでしょうか。

コミュニケーション能力でしょうか。

リーダーシップでしょうか。

ロジカルシンキングでしょうか。

あるいは、プロジェクトマネジメントの専門知識でしょうか。

PMに求められるスキルは非常に多くあります。

そして、PMとして経験を積めば積むほど、

「PMに必要なスキルは一つではない」

ということを実感するようになります。

私は、PMに必要なスキルを大きく4つに分けて考えています。

• 対人スキル
• 思考系スキル
• PM専門系スキル
• 業務・技術系スキル

そして、私が重要だと考えている順番もこの順番です。

特に重要なのは、対人スキルです。

PMは「人を通じて」プロジェクトを動かす

なぜ対人スキルが一番重要なのでしょうか。

PMは、必ずしも自分自身が専門技術を使って成果物を作る仕事ではありません。

プログラマーのようにプログラムを書くわけでもありません。

ハードウェア設計者のように設計をするわけでもありません。

品質保証の担当者のように、品質そのものを管理するわけでもありません。

もちろん、こうした業務や技術を理解することは重要です。

しかし、PMの仕事の中心にあるのは、人と人の調整です。

• プロジェクトメンバーとの調整
• チーム間の調整
• 顧客との調整
• 上司との調整
• ベンダーとの調整
• ステークホルダーとの調整

つまり、

PMは、人を通じてプロジェクトを動かす仕事です。

だからこそ、私は対人スキルを最も重要だと考えています。

① 対人スキルはPM戦闘力の土台になる

PMに必要な対人スキルには、さまざまなものがあります。

コミュニケーション

自分の考えを伝えるだけではありません。

相手の理解度を確認し、認識を合わせ、必要な情報を必要な人に伝える。

PMにとって基本となるスキルです。

ファシリテーション

会議を開催するだけではありません。

• 論点を整理する
• 意見を引き出す
• 対立を整理する
• 合意形成する
• 次のアクションにつなげる

といったことが求められます。

交渉

プロジェクトでは、すべての要求をそのまま受け入れられるわけではありません。

納期、コスト、品質、スコープなど、さまざまな制約の中で関係者と合意を作る必要があります。

リーダーシップ

PMは、役職上の上司とは限りません。

自分の部下ではないメンバーや、別会社のベンダー、顧客などを巻き込みながらプロジェクトを進める必要があります。

そのため、単純な「指示する力」だけでは足りません。

傾聴

PMが話すだけでは、プロジェクトの状況を正しく把握できません。

• メンバーが何に困っているのか
• 顧客が何を不安に思っているのか
• ステークホルダーが何を求めているのか

こうした情報を拾うためには、傾聴する力が必要です。

サーバントリーダーシップ

PM自身がすべてを指示するのではありません。

メンバーが力を発揮できる環境を作ります。

必要な障害を取り除き、メンバーを支援する。

こうした考え方も、PMにとって重要なスキルだと考えています。

コミュニケーションが苦手でもPMはできる

ここで、私自身の経験を少し紹介します。

私は、もともとコミュニケーションが得意なタイプではありません。

それでもPMとして仕事をする中で、

「コミュニケーションが苦手だからPMができない」わけではない

と感じるようになりました。

私の場合、コミュニケーションそのものを得意にするというより、

コミュニケーションを仕組みとして設計する

ことを意識するようになりました。

その一つが、キックオフミーティングです。

キックオフでは、単にプロジェクトの予定や役割を説明するだけではありません。

• なぜこのプロジェクトをやるのか
• プロジェクトの目的は何なのか
• 何を大切にして進めるのか
• メンバーにはどのように関わってほしいのか

といったことを、最初にしっかり伝えるようにしました。

すると、プロジェクトメンバーがプロジェクトの目的や重要性を理解しやすくなりました。

モチベーションを高めることにもつながりました。

結果として、プロジェクトをより効果的にマネジメントできるようになりました。

これは、

コミュニケーションが得意だからできたことではなく、コミュニケーションをどう設計するかを考えた結果

だと思っています。

② 思考系スキルは問題を解決する力になる

2つ目は思考系スキルです。

具体的には、次のようなスキルです。

• ロジカルシンキング
• 問題解決
• 判断力
• リスクを予測する力
• 政治力
• 全体を俯瞰して見る力

PMは、日々さまざまな問題に直面します。

そのとき、

「何となく問題がありそう」

だけでは、適切な対応はできません。

• 何が問題なのか
• なぜ問題なのか
• どこに影響するのか
• 何を優先すべきなのか
• 誰に相談すべきなのか
• どうすれば問題を防げるのか

こうしたことを考える力が必要になります。

「全体を見る力」がPMには必要

PMは、個別のタスクだけを見ていてはいけません。

例えば、あるチームの作業が1週間遅れるとします。

単純に、

「1週間遅れているから、そのチームに頑張ってもらおう」

と考えるだけでは不十分です。

その遅れによって、次のような影響を考える必要があります。

• 次のチームにどんな影響があるのか
• スケジュール全体にどう影響するのか
• コストは増えるのか
• 品質に影響するのか
• 顧客への説明が必要なのか
• 他のリスクが増えるのか

つまりPMには、

個別の問題を見ながら、同時にプロジェクト全体を見る力

が求められます。

③ PM専門系スキルはプロジェクトを管理する専門力

3つ目は、プロジェクトマネジメントそのものに関する専門スキルです。

例えば、次のようなものがあります。

• スコープマネジメント
• スケジュールマネジメント
• コストマネジメント
• リスクマネジメント
• コミュニケーションマネジメント
• ステークホルダーマネジメント
• リソースマネジメント
• 品質マネジメント

こうしたPMの知識を体系的に学ぶことは重要です。

PMBOK®︎などを通じて、プロジェクトマネジメントの考え方を体系的に学ぶこともできます。

ただし、ここでも注意したいことがあります。

知識を知っていることと、PMとして使えることは別です。

「知っている」と「できる」は違う

例えば、リスクマネジメントについて知識があったとしても、

「このプロジェクトでは、どんなリスクが重要なのか？」

を判断できなければ、実務では十分に活用できません。

コミュニケーションについて知っていても、

「誰に、いつ、何を伝えるべきなのか？」

を判断できなければ、プロジェクトはうまく動きません。

つまり、

PMスキルは、知識を持っているだけでは完成しません。

私は、

知る → 身につける → 体現する

という3段階が必要だと考えています。

④ 業務・技術系スキルはプロジェクトを理解する力になる

最後が、そのプロジェクトに関する業務・技術系スキルです。

例えば、次のようなものがあります。

• プログラミング
• ハードウェア設計
• 品質保証
• 製造
• 建設
• ITインフラ
• 業界固有の知識

PMが必ずしも専門家である必要はありません。

しかし、そのプロジェクトで何が行われているのかを理解するためには、一定の業務・技術知識が必要です。

技術的な難しさを理解できなければ、リスクを把握できないこともあります。

顧客の要求の難しさを判断できないこともあります。

そのため、業務・技術系スキルもPM戦闘力を構成する重要な要素です。

ただし、私はPM専門系スキルよりもさらに上位に、

対人スキルと思考系スキル

があると考えています。

専門技術が高い人が、必ずしも強いPMになるわけではない

ここはPMを目指す人に伝えたいポイントです。

技術者として非常に優秀だった人がPMになるケースは多くあります。

そして、技術を理解していることは大きな武器になります。

しかし、

技術力が高い＝PMとして強い

ではありません。

PMになった瞬間、仕事の中心が変わるからです。

自分で設計する。

自分でプログラムを書く。

自分で成果物を作る。

という仕事から、

人を動かし、調整し、判断し、プロジェクト全体を成功に導く仕事

へ変わります。

そのため、技術力をさらに高めるだけではなく、対人スキルや思考系スキルを身につける必要があります。

スキルは「持っているだけ」ではPM戦闘力にならない

ここまで、PMに必要なスキルを紹介してきました。

しかし、PM戦闘力という観点では、もう一つ重要なことがあります。

それは、

スキルを持っているだけでは不十分

ということです。

例えば、ファシリテーションの本を読んだ。

研修を受けた。

資格を取得した。

これらはスキルを身につけるための重要なステップです。

しかし、それだけで実際のプロジェクトをうまくファシリテーションできるようになるとは限りません。

実際の会議では、想定外の意見が出てきます。

参加者同士が対立することもあります。

話が脱線することもあります。

誰も発言しないこともあります。

そうした状況の中で、実際にスキルを使ってみる。

そして、うまくいかなかったところを振り返る。

次の会議で改善する。

この繰り返しによって、スキルが「自分のもの」になっていきます。

PMスキルは「知る→身につける→体現する」

私は、PMスキルを身につける流れを、

知る → 身につける → 体現する

と考えています。

① 知る

まず、そのスキルが存在することを知ります。

例えば、

「ファシリテーションというスキルがある」

と知ることです。

② 身につける

本を読んだり、研修を受けたり、実際に勉強したりします。

スキルの考え方や方法を理解します。

③ 体現する

実際のプロジェクトで使ってみます。

そして、

「自分だったらどう使えばいいのか」

を考えます。

ここまでできて、初めてそのスキルがPM戦闘力につながっていくと考えています。

知るための方法として、プロジェクトマネジメントに関わる本を読んではいかがでしょうか。おすすめ本をまとめました。

【厳選】プロジェクトマネジメント（PM）のおすすめ本12選！フェーズ・悩み別に徹底解説

スキルは才能ではなく、意識して伸ばせる

ここまでの話をすると、

「コミュニケーションが苦手だからPMには向いていない」

と思う人もいるかもしれません。

しかし、私はそうは考えていません。

もちろん、人によって得意・不得意はあります。

私自身も、コミュニケーションが得意なタイプではありませんでした。

それでも、

「どうすればプロジェクトメンバーに必要なことを伝えられるか？」

を考えました。

そして、キックオフという場を使って、最初にプロジェクトの目的や方針を共有する方法を実践しました。

その結果、コミュニケーションをPMの武器として使えるようになりました。

大切なのは、

「自分には才能がない」と考えることではありません。

まず、自分に必要なスキルを知ります。

そして、そのスキルについて学びます。

実際のプロジェクトで使ってみます。

振り返ります。

また使ってみます。

このサイクルを繰り返します。

そうすれば、PMスキルは意識して伸ばしていくことができます。

経験とスキルは、お互いにPM戦闘力を高める

前の記事では、PM経験の「質」について考えました。

今回の記事では、PMスキルについて考えました。

この2つは、別々のものではありません。

むしろ、

経験とスキルは相互に作用します。

プロジェクトを経験する。

↓

そこから問題や教訓を得る。

↓

スキルを身につける。

↓

次のプロジェクトで使う。

↓

新しい経験を得る。

↓

さらにスキルを高める。

この循環によって、PM戦闘力は高まっていきます。

だからこそ、

経験年数を増やすだけでもダメ。

スキルを勉強するだけでもダメ。

経験とスキルを、自分自身でつなげていくことが重要なのです。

まとめ：PMスキルは「知識」ではなく「使える力」にする

PMに必要なスキルは、大きく4つに分けられます。

対人スキル

コミュニケーション、ファシリテーション、交渉、リーダーシップ、傾聴、サーバントリーダーシップなどです。

思考系スキル

ロジカルシンキング、問題解決、判断力、リスクを予測する力、政治力、全体を俯瞰して見る力などです。

PM専門系スキル

プロジェクトマネジメントに関する体系的な知識や実践力です。

業務・技術系スキル

そのプロジェクトに必要となる業務知識や技術知識です。

私は、この中でも特に対人スキルを重要だと考えています。

PMは専門技術を自分で使って成果物を作る仕事というより、人を通じてプロジェクトを動かす仕事だからです。

そして、どのスキルについても、

知っているだけではPM戦闘力にはなりません。

知る → 身につける → 体現する

というところまで進める必要があります。

研修や書籍、資格などを通じてスキルを学ぶことは、そのための重要な手段です。

しかし、最終的にそのスキルを自分のものにするのは、実際のプロジェクトで使うことです。

だからこそ、PMスキルは才能だけで決まるものではありません。

自分に必要なスキルを知り、学び、実践し、振り返る。

この繰り返しによって、PM戦闘力は少しずつ高めていけるのだと思います。

あなたは、今どのPMスキルを伸ばしたいでしょうか？

そして、そのスキルを実際のプロジェクトで「体現」できているでしょうか？

PM戦闘力シリーズ

• PM戦闘力とは？PMとしての強さを決める要素を考えてみた
• PM経験年数だけでは戦闘力は上がらない？経験の質が重要な理由
• PM資格は本当に必要？資格を「戦闘力の装備」として考える
• PMの実績とは何か？「トラブルを解決した」だけが実績ではない
• なぜトラブルを起こさないPMは評価されにくいのか？
• あなたのPM戦闘力はどれくらい？PM戦闘力を自己診断する
• PM戦闘力を高めるには？「経験→実践→振り返り」の成長サイクルを回そう
• PM戦闘力と市場価値の関係とは？PMとしての実力を転職市場でどう伝えるか

The post PM戦闘力を高めるPMスキルとは？重要な4つのスキルを考えてみた first appeared on PM道場.

そう聞くと、PM経験5年の人よりもPMとして強そうに感じるかもしれません。

確かに、PMとして長く仕事をしてきたことは、それだけで一つの強みです。

さまざまなプロジェクトを経験し、さまざまな問題に向き合ってきた可能性があります。

しかし、私はPM経験年数だけでは、その人のPM戦闘力を判断できないと考えています。

なぜなら、同じ「PM経験10年」でも、経験してきたプロジェクトの難しさや、そこから何を学んできたかによって、PMとしての強さは大きく変わるからです。

PM戦闘力を高めるために重要なのは、単純な経験年数ではありません。

どのような経験をしたのか。

そして、その経験から何を学び、次のプロジェクトで何を変えたのか。

今回は、PM経験の「質」について考えてみます。

PM経験年数は重要。でも、それだけでは足りない

まず、誤解のないようにしておきたいのですが、私は「PM経験年数なんて意味がない」と考えているわけではありません。

むしろ、経験年数はPM戦闘力を考えるうえで重要な土台です。

1年目のPMと10年目のPMでは、経験してきたことに大きな差があるでしょう。

ただし、

経験年数＝PM戦闘力

ではありません。

重要なのは、

経験をどのようにPMとしての能力に変えてきたか

です。

同じ10年間でも、毎回似たようなプロジェクトを、同じような方法で進めてきた人と、異なる環境・難易度のプロジェクトに挑戦し、そこで得た教訓を次のプロジェクトに活かしてきた人では、経験の価値は変わります。

だから私は、

PM経験年数は「経験の量」を表す一つの指標であって、経験の質まで表しているわけではない

と考えています。

PM経験の「質」は何で決まるのか？

では、どのようなプロジェクトを経験すると、PMとしての経験値が高まるのでしょうか。

私自身の経験から考えると、特に重要なのは次の5つです。

• ステークホルダーの難しさ
• メンバーの多さ
• 技術の難しさ
• メンバーの質
• ベンダーの多さ

もちろん、これだけが全てではありません。

しかし、こうした条件が複雑になるほど、PMにはより高度なマネジメントが求められます。

① ステークホルダーが難しい

私が経験値が高いと感じるプロジェクトの中でも、特に重要なのがステークホルダーの難しさです。

例えば、次のような状況です。

• 初めて取引する顧客
• 自社に対して良い印象を持っていない顧客
• 要求が非常に多い顧客
• 意思決定者が複数いる
• 顧客と自社で利害が一致していない
• 社内でもプロジェクトに対する考え方が異なる

プロジェクトマネジメントは、計画を作って、その通りに進めれば終わる仕事ではありません。

人が関わる以上、認識の違いや期待値の違いが生まれます。

ステークホルダーが難しくなるほど、PMに求められる能力も増えていきます。

• コミュニケーション
• 交渉
• 期待値のコントロール
• 合意形成

そのため、難しいステークホルダーとのプロジェクトを経験することは、PMの戦闘力を高める大きな経験になると考えています。

② メンバーが多い

メンバーが増えると、単純に管理する人数が増えるだけではありません。

例えば、10人のメンバーを一つのチームとして管理するのではなく、複数のチームに分ける必要が出てくるとします。

すると、次のような新しいマネジメントが必要になります。

• チーム間の認識合わせ
• チーム間の依存関係
• チーム間の優先順位
• チーム間のコンフリクト
• 情報共有

人数が増えることで、

「一人ひとりとコミュニケーションを取ればいい」

というマネジメントから、

「チームという単位をマネジメントする」

という段階に変わっていきます。

これもPMとして重要な経験です。

③ 技術的な難しさ

技術的に難しいプロジェクトも、PMにとって貴重な経験になります。

• そもそも技術的に成功する可能性が低い
• やってみなければ結果が分からない
• 前例がない

このようなプロジェクトでは、単純に「計画通りに進める」だけでは対応できません。

例えば、

「もし技術的に実現できなかったらどうするのか？」

というところまで考えておく必要があります。

場合によっては、失敗した場合の代替案や関係者への説明方法まで、事前に準備しておく必要があるでしょう。

つまり、技術的な難しさが増えるほど、

不確実性をマネジメントする力

が求められます。

こうした経験は、次のプロジェクトでリスクを考えるときにも活きてきます。

④ メンバーの質

メンバーの経験やスキルも、プロジェクトの難易度を大きく左右します。

例えば、経験豊富なメンバーが揃っているプロジェクトであれば、PMが細かく指示を出さなくても、それぞれが自律的に動けるかもしれません。

一方、若手メンバーが多いプロジェクトでは、そうはいきません。

プロジェクトを進めるだけではなく、

メンバーを育成すること

も必要になります。

• 何をすべきなのか
• なぜそれをするのか
• どういう観点で仕事をしてほしいのか

こうしたことを伝えながら、プロジェクトそのものも前に進めなければなりません。

これは、単なるタスク管理とは違うPM経験です。

⑤ ベンダーが多い

複数のベンダーが関わるプロジェクトも、PMにとって難易度が上がります。

ベンダーごとの管理だけならまだしも、複数のベンダーが関係すると、

ベンダー同士をどう連携させるか

という問題が出てきます。

例えば、次のような状況です。

• A社の作業が終わらないとB社が作業できない
• A社とB社で責任範囲の認識が違う
• ベンダー間で優先順位が異なる
• 問題が発生したときに責任の所在が曖昧になる

ここではベンダーマネジメントだけではなく、ベンダー間の調整も必要になります。

これもPMとして重要な経験になります。

重要なのは「難しいプロジェクトを経験した数」だけではない

ここまで読むと、

「では、とにかく難しいプロジェクトをたくさん経験すればいいのか？」

と思うかもしれません。

私は、それも少し違うと考えています。

もちろん、さまざまな状況のプロジェクトを経験したほうが、PMとしての引き出しは増えます。

しかし、同じようなプロジェクトでも、経験から教訓を得て、より良いマネジメントができるようになれば、経験値は上がります。

例えば、前回のプロジェクトで、

「メンバーへの指示がうまく伝わらなかった」

という問題が起きたとします。

その原因を分析し、

「メンバーがプロジェクトマネジメントの意図を理解していなかった」

と分かった。

そこで次のプロジェクトでは、

「なぜこの指示をするのか」

まで説明するようにした。

これだけでも、同じような規模のプロジェクトを経験しているにもかかわらず、PMとしての能力は変わっています。

つまり、

経験の質は、プロジェクトそのものの難しさだけで決まるわけではありません。

経験から何を得たか。

これも、経験の質を決める重要な要素です。

失敗は、失敗のまま終わらせなければ戦闘力になる

私は、失敗した経験もPM戦闘力を高める重要な材料になると考えています。

例えば、次のような経験です。

• スケジュールが遅れた
• 顧客との認識が合わなかった
• メンバーへの指示が伝わらなかった
• リスクへの対応が遅れた
• ベンダーとの調整に失敗した

こうした経験は、決して無駄ではありません。

ただし、

「失敗した」という事実だけでは、PM戦闘力にはなりません。

重要なのは、その後です。

• なぜ失敗したのか？
• 原因を分析する
• 次はどうすれば防げるのか？
• 対策を考える
• 次のプロジェクトで実際に対策する
• その結果を確認する

こうして初めて、失敗が「教訓」に変わります。

私は、

失敗を失敗のまま終わらせなければ、その経験は戦闘力になる

と考えています。

私自身の経験：若手メンバーとのプロジェクト

ここで、私自身の経験を紹介します。

ある小規模なプロジェクトで、私以外のメンバーは入社3年以内の若手が2人。

そこに50代の営業担当者が1人。

そして、顧客は要望が多く、プロジェクトを失敗させると厳しいクレームにつながる可能性がある顧客でした。

人数だけを考えれば、それほど大きなプロジェクトではありません。

しかし、PMとしては簡単なプロジェクトではありませんでした。

特に課題だったのが、若手メンバーとどのようにプロジェクトを進めるかでした。

そこで私は、プロジェクトのマネジメント方法を一から伝えることにしました。

そして、キックオフミーティングでは、

「このプロジェクトでは、メンバーとしてこういうことを意識してほしい」

ということを伝えました。

単に「これをやってください」と指示するのではありません。

なぜ自分がその指示をしているのか。

プロジェクトマネジメントの観点から、なぜその行動が必要なのか。

そこまで理解してもらおうとしました。

なぜ、そこまでやったのか？

実は、これは前のプロジェクトから得た教訓でした。

前のプロジェクトでは、メンバーがプロジェクトマネジメントについて十分に理解していませんでした。

そのため、私が出した指示の意図がうまく伝わらず、結果として納期遅延を起こしてしまいました。

そこで私は、

「次のプロジェクトでは、メンバーに指示を出すだけではなく、プロジェクトマネジメントそのものを理解してもらおう」

と考えました。

これが、次のプロジェクトでの行動につながりました。

そして、そのプロジェクトでは、前回の教訓を活かしてプロジェクトを進めることができました。

これこそが「経験が戦闘力になる」ということ

この経験から、私はPMにとって重要なのは、

「何年PMをやったか」ではない

と改めて感じました。

もちろん、経験年数は重要です。

しかし、

前のプロジェクトで何が起きたのか。

↓

なぜ起きたのか。

↓

次はどうするのか。

↓

実際に次のプロジェクトで行動を変える。

このサイクルを回すことが重要です。

前のプロジェクトでの失敗が、次のプロジェクトでの成功につながった。

そして、その成功体験が、さらに次のプロジェクトで使える。

こうして経験が積み重なっていきます。

経験とスキルは相互に作用する

親記事では、PM戦闘力を、

（経験 × スキル × 適用力）＋（資格＋実績）

と考えました。

ここでいう「経験」と「スキル」は、一方通行ではありません。

経験 → スキル

という流れもあれば、

スキル → 経験

という流れもあります。

プロジェクトを経験することで、

「こういうときには、こう対応すればいい」

というスキルが身につく。

一方で、すでに持っているスキルを使うことで、

「このプロジェクトでは、ここが問題になりそうだ」

と気づくこともあります。

つまり、

経験とスキルは、お互いを高め合う関係

なのです。

ただし、ここでも重要なのは、自分で考えることです。

経験しただけ。

研修を受けただけ。

資格を取っただけ。

これでは十分ではありません。

経験から考える。

考えたことをスキルに変える。

スキルを次のプロジェクトで使う。

その結果を振り返る。

また次のプロジェクトで活用する。

この循環を自分自身で作る必要があります。

「経験年数」ではなく「経験をどう変えたか」を考える

PMとして経験を積んでいると、いつの間にか、

「PM歴○年」

という数字を自分の強さの指標にしてしまうことがあります。

しかし、PM戦闘力を高めるうえで重要なのは、単純な年数ではありません。

• どんなプロジェクトを経験したのか
• どんな難しさに直面したのか
• 何に失敗したのか
• 何を教訓にしたのか
• 次のプロジェクトで何を変えたのか

そして、

その経験を、次のプロジェクトで再現できる能力に変えられたのか。

ここまで考えて、初めて「経験」がPM戦闘力につながるのだと思います。

まとめ：経験を積むだけではなく、経験を戦闘力に変える

PM経験年数は、PM戦闘力を考えるうえで重要な土台です。

しかし、

PM経験10年＝PM戦闘力10

のように単純に考えることはできません。

経験の質によって、得られるものは大きく変わります。

特に、次のような要素が複雑になるほど、PMにはより高度なマネジメントが求められます。

• ステークホルダーの難しさ
• メンバーの多さ
• 技術の難しさ
• メンバーの質
• ベンダーの多さ

一方で、難しいプロジェクトだけが価値のある経験というわけでもありません。

同じようなプロジェクトであっても、

過去の教訓を活かして、前回より良いマネジメントができた

のであれば、それもPM戦闘力を高める重要な経験です。

そして、失敗も同じです。

失敗する → 原因を分析する → 対策を考える → 教訓にする → 次のプロジェクトで活かす

このサイクルを回すことで、失敗は戦闘力に変わります。

PMとして大切なのは、

経験年数を増やすことではなく、経験を戦闘力に変え続けること。

私はそう考えています。

あなたは、これまでのPM経験から、どんな教訓を得てきましたか？

そして、その教訓を次のプロジェクトで活かせているでしょうか。

経験を「年数」で終わらせず、「次のプロジェクトで使える力」に変えていく。

それが、PM戦闘力を高める一つの方法だと思います。

PM戦闘力シリーズ

PM戦闘力について、さらに詳しく知りたい方はこちらもどうぞ。

• PM戦闘力とは？PMとしての強さを決める要素を考えてみた
• PM戦闘力を高めるPMスキルとは？重要な4つのスキル考えてみた
• PM資格は本当に必要？資格を「戦闘力の装備」として考える
• PMの実績とは何か？「トラブルを解決した」だけが実績ではない
• なぜトラブルを起こさないPMは評価されにくいのか？
• あなたのPM戦闘力はどれくらい？PM戦闘力を自己診断する
• PM戦闘力を高めるには？「経験→実践→振り返り」の成長サイクルを回そう
• PM戦闘力と市場価値の関係とは？PMとしての実力を転職市場でどう伝えるか

The post PM経験年数だけでは戦闘力は上がらない？経験の質が重要な理由 first appeared on PM道場.

「あのPMはすごい。トラブルが起きたプロジェクトを見事に立て直した。」

PMとして仕事をしていると、そんな評価を耳にすることがあります。

大きな問題が発生したプロジェクトをまとめ、関係者を説得し、遅れを取り戻す。

確かに、簡単にできることではありません。

しかし、私は以前から少し違和感がありました。

本当にPMとして強いのは、トラブルが起きてからプロジェクトを立て直したPMなのでしょうか？

そもそも、トラブルを起こさなければ、プロジェクトはもっと良かったのではないでしょうか。

ステークホルダーも、メンバーも、トラブルなんて望んでいません。

それならば、トラブルが発生してから華々しく解決するPMよりも、トラブルが起きる前に必要なことを考え、問題の芽を潰し、プロジェクトを何事もなく成功させるPMのほうが、本当はPMとして強いのではないでしょうか。

私は、そんなことを考えるようになりました。

そして、PMとしての「強さ」を考えるために、私は「PM戦闘力」という考え方をするようになりました。

あなたのPM戦闘力はどれくらい？PM戦闘力を自己診断する

PM戦闘力とは「プロジェクトを成功に導く総合的な強さ」である

私が考えるPM戦闘力とは、

プロジェクトの状況を把握し、そのプロジェクトで何が重要なのかを見極め、必要なマネジメントを実行することで、トラブルを未然に防ぎ、プロジェクトを成功に導く力。そして、その実力や実績を第三者に示すことができる力まで含めた、PMとしての総合的な強さです。

ここで重要なのは、すべてのプロジェクトに同じマネジメントをすればいいわけではないということです。

あるプロジェクトでは、リスクを事前に潰すことが重要かもしれません。

別のプロジェクトでは、ステークホルダーの認識を合わせることが最優先かもしれません。

また別のプロジェクトでは、メンバーの不満や疲弊を早期に把握することが重要かもしれません。

要求が曖昧なプロジェクトなら、スコープを明確にすることが重要でしょう。

つまり、PMに必要なのは「リスクマネジメントが得意」「コミュニケーションが得意」といった個別の能力だけではありません。

そのプロジェクトにとって何が重要なのかを見極め、必要なことを実行する力。

私は、これこそがPM戦闘力の本質だと考えています。

PM戦闘力は「経験×スキル」だけではない

PM戦闘力を考えるうえで、私は次のような概念式を考えています。

PM戦闘力 ≒（経験 × スキル × 適用力）＋（資格 ＋ 実績）

もちろん、これは数学的にPMの能力を正確に測る公式ではありません。

PM戦闘力を構成する要素を理解するための、私なりの考え方です。

それぞれの要素には、次のような意味があります。

経験は「何年やったか」より「何を経験したか」が重要

これまで、どのようなプロジェクトを経験してきたのか。

単純なPM経験年数だけではありません。

• どのくらいの規模だったのか
• どのくらい難しいプロジェクトだったのか
• どれくらいの人数をマネジメントしたのか
• ステークホルダーはどれくらいいたのか
• どの程度の責任を担ったのか
• どのような問題に直面したのか

こうした「経験の質」が重要になります。

PM経験10年という数字だけでは、その人のPM戦闘力を判断することはできません。

PM経験年数だけでは戦闘力は上がらない？経験の質が重要な理由

スキルは「経験を成果につなげる力」である

経験を成果につなげるためには、スキルが必要です。

私はPMに必要なスキルを、大きく4つに分けて考えています。

① 対人スキル

コミュニケーション、リーダーシップ、ファシリテーション、交渉などです。

② 思考系スキル

ロジカルシンキング、問題解決、判断力、リスクを予測する力などです。

③ PM専門系スキル

スコープ、スケジュール、コスト、リスク、ステークホルダーなどをマネジメントする力です。

④ 業務・技術系スキル

業界知識、製品知識、技術知識などです。

ただし、スキルは「持っているだけ」では十分ではありません。

PM戦闘力を高めるPMスキルとは？重要な4つのスキルを考えてみた

適用力とは「今のプロジェクトで何が重要か」を見極める力

ここがPM戦闘力を考えるうえで、特に重要だと考えています。

例えば、コミュニケーション能力が非常に高いPMがいたとしても、そのプロジェクトで本当にコミュニケーションが最重要なのかは分かりません。

技術的なリスクが最大の問題かもしれません。

スコープの曖昧さが問題かもしれません。

あるいは、メンバーの疲弊が最大のリスクかもしれません。

だからこそ、

「このプロジェクトでは、今何が一番重要なのか？」

を考える必要があります。

そして、必要なスキルを適切なタイミングで使う。

これが適用力です。

PMは、持っているスキルをすべて使えばいいわけではありません。

プロジェクトに合わせて、何を使うのかを選ぶ。

これがPMの難しさであり、PM戦闘力の重要な要素だと私は考えています。

PMの仕事は「トラブルを解決すること」だけではない

PMになると、どうしても「問題解決能力」が注目されます。

もちろん、問題が発生したときに適切に対応できることは重要です。

しかし、私はそれ以上に、

問題が発生する前に、問題の芽を見つけること

が重要だと考えています。

例えば、次のような活動です。

• リスクを事前に洗い出す
• ステークホルダーの認識を合わせる
• 曖昧な要求を放置しない
• 無理なスケジュールを受け入れない
• メンバーの不満を早期に拾う
• プロジェクトの状況を継続的に把握する
• 必要なときには早めにエスカレーションする

こうした活動は、プロジェクトに大きなトラブルが起きなければ、外からは見えにくいものです。

しかし、だからといって価値がないわけではありません。

むしろ、

「何も起きなかった」という結果の裏側に、PMの仕事が詰まっている。

私はそう考えています。

もちろん、どれだけ優れたPMでも、すべてのトラブルを防ぐことはできません。

だからこそ、

トラブルを起こさせない。

そして、

起こってしまったトラブルの影響を最小限にする。

その両方がPMの重要な役割です。

PMの実績とは何か？「トラブルを解決した」だけが実績ではない

資格はPM戦闘力の「装備」である

では、資格はPM戦闘力にどのように関係するのでしょうか。

私は、資格を「装備」だと考えています。

例えば、PMP®やIPAプロジェクトマネージャ試験などの資格を取得したからといって、それだけでプロジェクトを成功させられるようになるわけではありません。

資格を取っただけなら、あくまで「装備」を手に入れた状態です。

しかし、資格取得のために勉強することで得られた知識は違います。

プロジェクトマネジメントの体系的な知識を学び、それを実務で使えば、それは自分自身のPM戦闘力になります。

さらに、資格は第三者に対して、

「私はこうした知識を体系的に学んできました」

と示すための材料にもなります。

つまり資格には、

• 自分自身の知識・スキルを高める効果
• 第三者に能力を証明する効果

の2つがあります。

だからこそ、資格はPM戦闘力を考えるうえで重要な「装備」なのです。

実績もPM戦闘力の重要な要素である

資格だけではなく、実績も重要です。

例えば、次のようなものです。

• 大規模プロジェクトを成功させた
• 難易度の高いプロジェクトを完遂した
• プロジェクトの遅延を防いだ
• リスクを事前に潰した
• 関係者間の対立を解消した
• プロジェクトの進め方を改善した

ここで、私は一つ問題提起をしたいと思っています。

「トラブルを解決した」という実績だけが、PMの実績ではないのではないでしょうか。

大きなトラブルを解決したことは、確かに分かりやすい実績です。

一方で、

「大きなトラブルを発生させずにプロジェクトを成功させた」

という実績は、目立ちにくい。

しかし、PMとしての価値を考えれば、後者も非常に重要です。

何も起きなかったこと自体が、PMの成果かもしれない。

この視点は、PM戦闘力を考えるうえで大切にしたいと思っています。

PMの実績とは何か？「トラブルを解決した」だけが実績ではない

プロジェクトで強いPMと、市場で強いPMは同じなのか？

ここからが、PM戦闘力を考えるもう一つの理由です。

私は、プロジェクトの中で強いPMと、市場で強いPMは、現実には必ずしも一致しないと考えています。

例えば、プロジェクトを安定して運営し、大きなトラブルを起こさず、関係者との調整を行い、予定通りプロジェクトを完了させる。

これは非常に価値のある仕事です。

しかし、その価値を第三者に説明するのは簡単ではありません。

一方、

「大きなトラブルが発生したプロジェクトを立て直した」

という実績は、とても説明しやすい。

資格も同じです。

資格は実際のPM能力を完全に証明するものではありません。

しかし、第三者から見れば、分かりやすい評価材料になります。

つまり、

PMとしての実力

と

PMとしての市場価値

には、ギャップが生まれることがあります。

私は、このギャップはできるだけ小さくしたいと思っています。

理想は、

プロジェクトで本当に強いPMが、市場でも正しく評価されること。

そのためには、自分の経験やスキルだけでなく、資格や実績を含めて、自分のPM戦闘力を第三者に伝えられるようにすることが重要です。

PM戦闘力と市場価値の関係とは？PMとしての実力を転職市場でどう伝えるか

PM戦闘力を高めるには「経験・スキル・適用力・資格・実績」を伸ばす

ここまでの話を整理すると、PM戦闘力を高める方法は一つではありません。

経験を増やす

ただ年数を重ねるだけではありません。

「今まで経験したことのない規模・難易度のプロジェクトに挑戦する」

ということも重要です。

スキルを高める

自分の弱いスキルを見つけて、意識的に伸ばします。

特に、次のような視点で自分に不足しているものを考えてみるのもよいでしょう。

• 対人スキル
• 思考系スキル
• PM専門系スキル
• 業務・技術系スキル

適用力を高める

「PMならこれをやる」という固定観念を持つのではありません。

「このプロジェクトでは何が重要なのか？」

を常に考えます。

そして、必要なマネジメントを選択して実行します。

資格を取得する

資格取得を目的にするのではありません。

知識を身につける＋第三者に証明する

という2つの目的で活用します。

実績を言語化する

自分がプロジェクトで何をしたのか。

どんな問題を防いだのか。

どんな判断をしたのか。

どんな成果につながったのか。

これらを言葉にしておきます。

そうすることで、自分では当たり前だと思っていた仕事が、PMとしての実績として見えてくることがあります。

PM戦闘力を高めるには？「経験→実践→振り返り」の成長サイクルを回そう

あなたのPM戦闘力を高めるために

ここまで読んで、

「では、自分のPM戦闘力はどのくらいなのだろう？」

と思った方もいるのではないでしょうか。

PM戦闘力は、単純に「PM経験○年」「PMP®取得済み」といった一つの指標だけでは判断できません。

経験、スキル、適用力、資格、実績。

それぞれを自分自身に当てはめて考える必要があります。

そこで、このシリーズでは、PM戦闘力を構成するそれぞれの要素について、さらに掘り下げていきます。

• PM経験年数だけでは戦闘力は上がらない？経験の質について
• PM戦闘力を高めるPMスキルとは？重要な4つのスキルを考えてみた
• PM資格は本当に必要？資格を「戦闘力の装備」として考える
• PMの実績とは何か？トラブルを解決しただけが実績ではない
• なぜトラブルを起こさないPMは評価されにくいのか？
• あなたのPM戦闘力はどれくらい？PM戦闘力を自己診断する
• PM戦闘力を高めるには？「経験→実践→振り返り」の成長サイクルを回そう
• PM戦闘力と市場価値の関係とは？PMとしての実力を転職市場でどう伝えるか

それぞれの記事で、PM戦闘力をさらに具体的に考えていきます。

まとめ：強いPMとは、トラブルを解決するPMだけではない

PMとして仕事をしていると、どうしても「問題を解決した経験」が目立ちます。

しかし、本当にPMとして強い人は、問題が起きてから動くのではなく、問題が起きる前からプロジェクトを見ています。

• リスクを見つける
• 関係者の認識を合わせる
• メンバーの状態を把握する
• 曖昧な要求を放置しない
• 必要なときにはエスカレーションする

そして、そのプロジェクトにとって何が重要なのかを判断し、必要なことを実行する。

私は、そんなPMこそ「PM戦闘力が高いPM」だと考えています。

そして、その戦闘力を構成するのが、

（経験 × スキル × 適用力）＋（資格 ＋ 実績）

という考え方です。

もちろん、この式に正解があるわけではありません。

PM戦闘力という言葉自体も、PMBOK®︎などに定義された正式な用語ではありません。

10年間PMとして仕事をしてきた私が、「PMとして本当に強いとはどういうことなのか」を考えた結果として生まれた、一つの考え方です。

あなたは、自分のPM戦闘力をどのように考えますか？

経験は十分でしょうか。

必要なスキルは身についているでしょうか。

プロジェクトごとに「何が重要なのか」を見極められているでしょうか。

そして、その実力を第三者に伝えられる資格や実績を持っているでしょうか。

ぜひ一度、自分自身のPM戦闘力について考えてみてください。

The post PM戦闘力とは？PMとしての強さを決める要素を考えてみた first appeared on PM道場.