そう聞くと、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道場.

• 令和5年度秋期 プロジェクトマネージャ試験 午後Ⅱ
  
  問題冊子はこちら
  
  出典：IPA 独立行政法人 情報処理推進機構

※掲載している問題冊子へのリンクおよび試験問題の著作権は、IPA 独立行政法人 情報処理推進機構に帰属します。最新情報はIPA公式サイトをご確認ください。

ポイントはシンプルです。

• なぜ失敗したのかを深掘りすること
• 同じ失敗を繰り返さない仕組みを考えること

目標未達成の原因究明と再発防止策の立案及び他のプロジェクトに資する教訓について論じましょう。

結論：評価される論文は「原因→対策→定着」まで書けている

高評価につながる論文は、以下の流れが整理されています。

• 失敗の事実
• 原因（直接＋根本）
• 再発防止策
• 組織への定着

この流れが一貫していることが重要です。

設問ア：プロジェクトの全体像は「独自性×目標×影響」で説明する

以下3点について説明します。 独自性、目標、ステークホルダーの関係性を論理的に説明ができると◎

• ①システム開発プロジェクトの独自性
• ②未達成となった目標と未達成となった経緯
• ③目標未達成がステークホルダーに与えた影響

① システム開発プロジェクトの独自性はプロジェクト目標に関連したもの

プロジェクトの独自性とは、今まで経験したことがないこと。それは些細なことでも問題ありません。過去に似た事例があっても、環境・要件・関係者が異なるため全く同じプロジェクトは存在しません。この独自性がそのプロジェクトにおいて注意しなければならないことになります。

独自性の例：

• 品質に対して新しい規格が適用された
• 通常納期が1年のところ、半年で納入しなくてはならない
• プロジェクトメンバーに入社２年目の若手がいる

コツ：目標と関連づけて独自性を説明することがポイントです

② 未達成の目標と経緯は具体的に

未達成となった目標と未達成となった経緯を具体的に説明しましょう。目標は定量的に説明すること。未達成となった経緯は、元々の目標を達成するための計画、実際に起こった事象、その結果どのように目標に影響を与えたのかを時系列で説明しましょう。

ここは具体性が重要です。

• 目標は定量的に示すとわかりやすいです
• 経緯は時系列で整理します

③ ステークホルダーへの影響は要求と目標の関連性を明確に

目標未達成がステークホルダーに与えた影響を論じます。プロジェクトマネージャはプロジェクトを行う上で、ステークホルダーの要求を具体的に把握している必要があり、その要求と目標との関連性を説明できることが重要です。論理的に関連とステークホルダーへの影響を説明しましょう。

プロジェクトマネージャとして重要な観点です。

• 顧客：納期遅延や信頼低下
• 上司：評価への影響
• メンバー：業務負荷の増加

ポイント：目標と影響の関係を論理的に説明することが重要になります

設問イ：なぜなぜ分析で根本原因まで整理することがポイント

下記3点を論じます。

• ①目標未達成の直接原因の内容
• ②根本原因を究明するために行ったこと
• ③根本原因の内容

いわゆるなぜなぜ分析の内容を論理的に説明しましょう。

① 直接原因は簡潔に説明

目標未達成の直接原因を説明しますが、論理的に誰でも簡単に理解できるように説明しましょう。プロジェクトマネージャとしての力の見せ所は②③の論述です。①では、簡単にわかりやすく直接原因を説明することを心がけましょう。

例：

• 要件定義の不備
• スケジュール遅延

ポイント：ここはシンプルに整理すると読みやすくなります

② 根本原因の究明方法では使ったツールや工夫を説明

根本原因を究明するために行ったことでは、使ったツールはもちろん顧客などのステークホルダーや専門家といった第3者の意見も論述の中に含めると、プロジェクトマネージャとして様々な関係者を巻き込んだことをアピールできます。ここでも論理的にわかりやすく説明しましょう。

使える分析手法例：

• 5Whys
• 特性要因図
• FMEA
• パレート図
• フローチャート

ポイント：

• なぜその手法を選択したのかを書く
• ステークホルダーや専門家の意見も取り入れる

このあたりを意識すると説得力が増します。

③ 根本原因は3層で整理

根本原因の内容について論述しますが、直接原因との関連はもちろん、間接原因（背景や条件）→根本原因（本質的要因）といった流れで3層で整理しましょう。さらに影響範囲と再発防止策との関連まで含めると説得力が増します。

以下の構造にすると伝わりやすくなります。

• 直接原因
• 間接原因（背景）
• 根本原因（本質）

例

• 直接原因：要件漏れ
• 間接原因：レビュー不足
• 根本原因：レビュー基準の未整備

ポイント：因果関係を意識して整理することが重要です

設問ウ：再発防止は「仕組み化」がカギ

以下2点を論じます。

• ①プロジェクトマネジメントの観点で立案した再発防止策
• ②再発防止策を組織に定着させるための工夫

エンジニアリングではなく、「プロジェクトマネジメントの観点」というところが肝です。

再発防止は属人的ではなく、仕組みとして設計する必要があります。

① 再発防止策はエンジニアリングの観点にならないように

具体的にその防止策を説明することはもちろん、なぜ防止できるかも論理的に説明しましょう。なお、すでに防止策の効果がわかっている場合は、その効果を定量的に説明しましょう。効果が出ていない場合は、どのようにその効果を測定するかを説明しましょう。

問われているのはエンジニアリングではなくマネジメントの視点です。

例：

• レビュー工程の標準化
• チェックリストの導入
• 進捗管理の強化

書くべき内容：

• なぜ防止につながるのか
• 効果（可能であれば定量的に示す）

② 組織への定着方法

再発防止策を組織に定着させる工夫について説明しますが、様々な方法があります。標準プロセス化・教育研修・監査レビュー・ツール化・教訓共有・マネージャの関与など。定着できたかどうか（例えば他のプロジェクトマネージャへの確認結果）まで論じられると良いです。

方法例

• 標準プロセス化
• 教育・研修
• 定期レビュー
• ツール化
• 教訓共有

さらに良いポイント：他プロジェクトでの適用結果まで書けると強いです

まとめ

• 原因を根本まで整理する
• 再発防止策を仕組みとして設計する
• 組織への定着まで言及する

この流れを意識することで、論文全体の説得力が高まります。

The post IPAプロジェクトマネージャ試験 午後Ⅱ対策 ｜【令和5年度秋 問2】 first appeared on PM道場.