テーマ： 「プロジェクトリーダーにおけるキャリアの転換 - 現状分析」
～アンケートから見えたプロジェクトリーダーの姿とP2Mの役割～
・・・ 森 邦夫 （元・電機メーカー 人事部門）
＜配布資料＞
＜講話・議論概要＞ 文責：岩下
「プロジェクトリーダーにおけるキャリアの転換 - 現状分析」
～アンケートから見えたプロジェクトリーダーの姿と P2M の役割～
・・・ 森 邦夫 （元・電機メーカー 人事部門）
本日のテーマは、昨年末に実施された「PL／PM のキャリア転換の意識調査」結果の共有です。この調査は森さんの発案で行われました。森さんはキャリアコンサルタントの国家資格も持っておられますので、専門的な視点から興味深いお話が聞けると思います。ご期待ください。
＜森さん講話−１部＞
プロジェクトリーダーにおけるキャリアの転換についてお話します。私はかつてある電機メーカーに在籍していました。当時私が携わっていた施策について、有資格者 PMR と国家資格のキャリアコンサルタントの立場からお話しできればと思います。
(p3)
私は 1981 年に入社し、情報システム部門、官公庁営業、経理、関連会社の業務などを経験しました。さらに、人事総務本部にて人材開発や組織活性化、採用業務を担当しました。2018 年 11 月に定年退職し、その後は嘱託雇用として採用業務を担当。2023 年 11 月に嘱託満了となりました。2024 年からは、「ビューティフルエイジング協会」という業界団体で活動し、シニア向けのライフデザインアドバイザーとして研修講師等を務めています。また、各大学の就職課の皆様と連携して、主に理工系学生の研究内容やその進め方をもとに、対話を通じて最適な職種を選択できるように就活支援を行っています。また、IT 系の就職・転職は人気がありますが、落とし穴も多いため、転職フェア他でキャリア相談員や、東京都と提携した DX 人材育成機関で転職支援のためのキャリアコンサルタント活動も行っています。
P２M との関わりについて
かつて弊社の人事管理職には、階層系のマネジメント研修の講師を務める慣例がありました。私は階層系のマネジメント研修に加え、製品開発マネジメントの教育が必要と考え、様々な取り組みを行いました。そのためには、まず自分が PM のことを知る必要があり、2009 年に PMR の資格を取得しました。
当社の研修体系になります。
新入社員研修：仕事の基礎を学ぶ。
入社 2～3 年目（初級研修）：メンバーの役割認識や基礎習得、仕事の進め方を学ぶ。
入社 3 年目以降（中級研修）：リーダーの役割認識やプロジェクトリーダーとしてのスキルを習得する。
特に重要なポイントは、以下の 2 点です。
ベンダーマネジメント研修 ：
単なる「外注管理」ではなく、発注側と受注側の両方の視点を持つことを踏まえた内容です。当時、他社と連携したビジネスが多くなったため、この研修を実施する意義が高まりました。
プロジェクトリーダー育成施策：
具体的なビジネステーマに基づき、プロジェクトリーダーを育成する施策です。この中で PMC 資格の取得も目標としました。この施策はチーム型 OJT です。実際のテーマに基づき、PMO の私と外部コンサルが 9 か月間伴走する形で進めます。1 か月に 1～2 回の頻度で関わり、PMO としての役割を果たします。この育成施策がきっかけとなり、プログラムマネージャーやプロジェクトリーダーのキャリア形成について考える契機となりました。
(p4)
プロジェクトリーダー育成における課題：
一般にマネジメント研修は座学で階層別に行われますが、プロジェクトマネジメントの教育は OJTが適していると思います。しかし、現実には以下のような問題が生じています。
上司の多忙による指導不足：
上司が忙しく、指導に十分な時間を割けない。
指導の質のばらつき：
上司の知識や経験に依存するため、指導の質に偏りが出る。
メンバーの参加減少：
チーム型 OJT にプロジェクトリーダーは参加するが、メンバーが徐々に不参加になる。
複数案件の掛け持ちによる負担増：
ほとんどのメンバーが複数の案件を担当しており、且つ一同に集まる機会が少ないため、プロジェクトの初期段階で業務課題や技術課題を十分に洗い出せないままプロジェクトが進行します。その結果、後半になってトラブルが多発するという悪循環が生じます。
解決に向けた取り組み：
この状況を少しでも改善するため、改めて全員を集めて開発初期段階に技術課題・業務課題を洗い出し、更にプロジェクトの負荷状況を可視化した上で、メンバーの参加を確保して活動することに注力しました。この負荷状況の把握とその対応によって、実効性ある施策を立案し、推進できると思います。
一例ですが、あるプロジェクトで負荷状況を算定したところ、月で 300%という数値が確認されたことがあります。300%の負荷とは、出勤日は定刻通り出勤し、更に月 320 時間の残業に相当します。これは、平日 20 日間のすべてを 4 時間残業し、毎週土日もすべて出勤し、更に夜 10 時まで働いたとしても、まだ足りない計算になります。このような状況では、業務が正常に進みません。しかし、驚いたのは負荷 300%の人よりも、負荷 150%の人のほうが厳しい表情をしていることでした。意外にも、負荷 300%の人は、本人が自分の負荷を知らされていないとか、「どうせできない」という諦めの心理が働いていたのです。上司は負荷が 300％の人が涼しい顔しているので、大丈夫と思って仕事を割り当てたそうです。
この高負荷状況は、マトリックス組織において上司と部下のプロジェクトが違う場合、報連相が不十分なために発生していることがわかりました。また、厳しい話しになりますが、例えば月 40 時間の残業を前提にプロジェクト予算が組まれていましたが、私から見てどうみても今の人員では少ないと思ってプロジェクトリーダーに質問したところ、「月 40 時間の残業で申請しないと、プロジェクト着工の許可が下りない。しかし、上司と折衝していると工程が遅れる」という悩みでした。これは大変なことになると思い、上層部に報告して負荷軽減を踏まえた対策を考えて実行してもらいました。
受注があることは有難いのですが、無理な業務負荷がかかると、品質問題や納期遅延のリスクが発生し、結果的には顧客からの信頼を失うことにもつながります。そして、人事総務部門が最も恐れる健康問題や離職問題に発展します。こうした悪循環を防ぐために、対策を講じる必要があります。この状況を踏まえ、どうすれば社員が健康で、且つ適切なキャリアを築きながら業務を遂行できるのかを考えるようになりました。
(p5)
PMAJ における活動について：
現在も PMAJ のオンライン講座で、『振り返り分析』『プロジェクトミーティングの進め方』を公開しております。 過去には『P２M プログラム実践研修』を実施し、PMAJ ジャーナルへの寄稿も行っていました。但し、定年後は現場を離れましたので、関わりは減っています。
(p6)
P２M の認知度が低いという課題は、2008 年頃も指摘されていましたが、現在も同様です。比較として PMS と PMP のデータを示します。2005 年の PMS は受験者 1468 名、合格者 684 名でしたが、昨年は受験者 408 名、合格者 217 名です。応募者は 72%も減少しています。PMP は年間平均 1700 名の合格者がいると見込まれ、PMS の約 5 倍になります。PMS だけでなく、PMR 受験者もなかなか増えません。PMS と PMR の受験者数に大きな隔たりがあります。色々な要因はありますが、経営と連動するプログラムマネジメントと、現場に対応するプロジェクトマネジメントの間に乖離があり、とりあえず PMP と同等の PMS で十分という気持ちではないかと思います。
私は 2009 年に PMR を取得しましたが、改定３版・改訂４版については精読しておりません。現場を離れた私はまず実態確認の必要性と、それを皆さんと共有して意見交換することが重要と考え、今回アンケートを行いました。それをベースに私の考えを展開する形にしました。
(p7)
・プログラムマネジメントとプロジェクトマネジメントの間のキャリア：
多数のプロジェクトを推進する際には、「マルチプロジェクトマネジメント」が重要であると考えています。これは第 2 版・第 3 版には含まれていましたが、第 4 版では無くなったようです。
・社内規定や設計支援ツールと P2M の関係 ：
各種社内規定、コンプライアンス対応、設計支援ツールの下で短納期開発を求められる中で、そこに P２M を導入すると、現場は過剰な負担感を感じて、活用しようという気持ちが低下します。
・ＩＴ業界での P2M の導入可能性：
私は現在転職支援の活動をしていますが、ＩＴ業界の人々と話す機会を持ちつつ、P２M の活用を模索してきました。しかし、この業界では重装備のマネジメントを求めてはいないと思います。
・人手不足と他社資産との連携：
現代のビジネスでは、一社単独で完結することは少なく、一社の技術・リソースだけでは対応しきれません。そのため、ベンダーマネジメントが重要になります。外注する側・される側の管理を適切に行う必要があります。
・業界構造の問題：
日本の業界構造は階層的で、多くの企業が下請け的な立場でプロジェクトに関わっています。その立場では低価格・短納期・高品質が求められます。一方でプロジェクトマネジメントは、プライム企業の立場、特に大企業を想定しています。そのため、中小企業への拡散は難しいと思います。ゆくゆくは、P2M 経験者が経営者となり、その企業経営に P2M を導入して成果を上げることが、P2M の普及の鍵になると考えています。
標準ガイドブックは現在のページ数でよいと思います。但し、実務で活用するには、さらにビジュアル化して分かりやすく解説した 250 頁程度の書籍も必要です。PMP 試験関連の PMBOK では新版が出るたびに 3〜4 冊の分かりやすい市販本が出版さ
れており、非常に活用しやすい状況になっています。
(p8 は割愛)
(p9)
プロジェクトマネジメントに従事する人のキャリア(多品種非量産・受注開発)：
「プロジェクトマネジメント」「マルチプロジェクトマネジメント」「プロジェクトメンバー」「リーダー」「マネージャー」などの用語が混在しているため、整理して説明します。
・プロジェクトメンバー：プロジェクトに携わる人たち
・プロジェクトリーダー：管理職または非管理職で、プロジェクトの運営を担うプレイヤー
（例：ラグビーのスタンドオフの役割。戦況を見て判断、パス・キック他を決断・指示・実行）
・プロジェクトマネージャー：プロジェクト全体の責任者で、管理職に該当する。
（例：チーム全体の監督的な立場で責任を持たされている）
実際の現場では、プロジェクトマネージャーがリーダーを兼ねることも多く、特に課長クラスの立場では両方の役割を担うことが多いです。
・プログラムリーダー:例えば大規模システム(サブプロジェクト群含む)を推進するリーダー
・プログラムマネージャー：例えば大規模なシステム等(サブプロジェクト群含む)の責任者。
（例：金融システムの開発、大規模建築プロジェクトなど）
マルチプロジェクトマネジメントの課題：
マルチプロジェクトとは、複数の独立したプロジェクト群が同時並行する状態を指します。
マルチプロジェクトリーダーは、ミッションやプログラムの全体最適よりも、売上・利益の最適化を優先します。経営層も特に株主等に配慮して単年度の業績を意識すると、プログラムマネジメントのミッションよりも売上・利益を優先することがあります。
現場の課題：
複数のプロジェクトに関わる人が多く、チームとしてまとまりにくい。
スキルやリソースが分散し、リソースの配分における難題が発生。
収益性の低いプロジェクトが途中で打ち切られる可能性がある。⇒顧客・社員の不信を招く。
本来、プログラムマネジメントの適切な運用が求められますが、プログラムが不振な場合は、現場では売上・利益を優先し、他のプロジェクトで穴埋めを図ります。
(p10)
マトリックス組織の問題：
縦軸が機能組織（ライン組織）で、横軸が複数のプロジェクトが並行して進行するマトリックス組織になっています。人事部門は縦の機能組織の観点で評価を見ますが、実際の業務は職場単位よりもプロジェクト単位が中心となるせいか、評価に納得できないことがあります。
人事部門が行う従業員満足度調査の結果でも、日常的にはライン組織よりもプロジェクトのほうに意識が向いているため、同じ職場でも自分とは異なるプロジェクトに携わっている人のことはよく分からないと言われています。これはマトリックス組織の宿命と思います。
アンケートでは「上司からの指導がない」と感じている社員が多いことが分かります。もちろん、上司自身がプレイヤーとして忙しいという事情もありますが、マトリックス組織の場合、その構造上、指導を受ける機会がない状態になります。横のプロジェクトリーダーたちが次々と業務負荷をかけた結果が 300%といった状況になった時、現場では諦めもあり、あまり危機感を持たないケースも見られました。プロジェクトの進行状況によっては、前工程が終わらないと自分の工程を始められないため、結果的に待ち時間が発生し、傍からみていると余裕があるようにも見えるのです。
このような課題を踏まえ、私はプロジェクトマネジメントの教育や育成施策に取り組んできました。
(p11)
今回のアンケート結果を見ましょう。アンケート回答者の属性について詳細な説明は省略します。
P2M 関係者や PMP 資格保持者を含め、合計 29 名に回答して頂きました。但し、今回のアンケートはあくまで意見の収集を目的としており、精密な分析ではないため、質問の精度や設問間の関係性、同一質問の反復の確認、事前考察などは十分に行っていません。そのため、回答者の皆様には回答に混乱を招いたと思います。お詫び致します。また、評価が極端な回答も見受けられますが、これによりプロジェクトマネジメントのスキルや知識の優劣を問うものではなく、意見の傾向を示すものとしてご理解ください。
(p12)
1 部:PL/PM における「キャリアの転換」について
【質問 1】現在のキャリアにおいて、次のステップを明確に描けていますか？
・「そう思う」および「少し思う」と回答した人は 46%
⇒約半数の人が次のキャリアステップを描けている
(p13)
【質問 2】プロジェクトリーダーとしての経験が自身のキャリア転換に役立つと感じていますか？
・「役立つ」と回答した人は 82%
⇒「キャリア転換」には様々なプロセスがあります。例えば、プロジェクトリーダーからマルチプロジェクトリーダーやプログラムリーダーへの昇格、転職、人事異動などが含まれます。キャリア転換に役立つと考える人が多い一方で、次のステップを明確に描けている人が半数以下に留まっていることから、ギャップがあると考えられます。
(p14 は割愛)
(p15)
【質問 4】キャリア転換の際に、組織から十分なサポートを受けられていますか？
・「受けられている」と回答した人は 14%
⇒上司が部下のキャリア転換を積極的に支援するかどうかについても課題が見えます。キャリア転換を好まない上司がいると考えられます。何故なら異動するとリソースを失うからです。また、短納期開発ではゆっくり指導できない問題があります。また、PMP や PMC・PMS・PMR の資格を持つプロジェクトリーダーや管理職が、次世代リーダーを育成できているか否かも重要な視点です。
(p16)
【質問 5】キャリア転換に関する具体的な目標を設定していますか？
・「明確に設定している」と回答した人はごく少数
・「多少設定している」と回答した人は 38%
⇒具体的な目標がない場合、会社の決定に従う傾向があり、結果として現状維持に留まる傾向になると考えられます。
(p17)
【質問 7】キャリアの展開について、周囲から積極的に意見やアドバイスをもらっていますか？
・「もらっている」と回答した人は少数
⇒プロジェクトリーダーが孤独に奮闘している様子が伺えます。周囲からのアドバイスやサポートが少ないことは、キャリア形成において重大な問題と言えるでしょう。
(p18～p20)
新しいキャリアに必要な専門知識や技術を学ぶための時間の確保について、約半数の人がなんとか自分で時間を作って学んでいるようです。また、キャリア転換に伴うリスクを受け入れる心構えができているかという点についても、半数の人が心の準備ができているようです。実際にそうなった場合には、挑戦しようという気持ちもあるようです。
自身のキャリア転換に必要な人脈やネットワークがあるかという点についても、半数の人が何らかのネットワークを持っていると感じています。
(p21)
コメント欄に寄せられた意見をいくつかご紹介します。一部の方から、プロジェクトマネージャーを前面に出したキャリア転換には、(会社として)前向きではないという意見がありました。理由として、経営層がプロジェクトマネジメントに対する不安/不信を感じていることが挙げられています。更には、適切な計画を立てて進めることよりも、無理な計画や無計画でも言われた通りに実現に向けて進めることを期待していると感じているようです。
ここまでの内容について、何かご意見やご質問があれば、お聞きしたいと思います。
＜ディスカッションー１＞
非常に新鮮なご意見をいただき、ありがとうございました。これまであまり注目していなかった点について、今後の議論においても重要であると感じました。今後もこのような議論を続けていく必要があるのではないかと思いますが、皆さんのご意見をお聞きしたいです。感想でも構いませんので、ぜひお聞かせください。
・（参加者）プロジェクトマネージャーがラインの管理職としっかり話をしながら、メンバーの人事評価を適切に行うべきだという点はよく聞きますが、実際にはうまくできていないと感じます。プロジェクトマネージャーの立場としては、プロジェクト内のメンバーのことしか見えなくなりがちです。そのため、より広い視点で評価を考える必要があると改めて気づかされました。
プロジェクトに参加してくれたメンバーについては、面談の前に彼らの活躍をまとめたレポートを作成し、ラインの管理職に「このメンバーはこういう形で貢献しました」と伝えていました。こうした取り組み自体がまだ十分に浸透していないことも実感しました。
⇒（森さん）プロジェクトマネ－ジャーとメンバーの関係が悪いとプロジェクトが破綻することがあります。人間関係の修復は難しくても、報連相だけでも徹底して欲しいです。尚、部下が優れたパフォーマンスを発揮しても、評価が適切でない場合があります。人間関係が不調だと、問題が長引くこともあります。また、技術だけで人を評価する技術系管理職にある困りごともあります。
実際に現場をよく見ていない人事部門が、部門の査定を正確に評価するのは難しいです。現場から上がってくる評価は尊重しますが、それだけで査定を決定するのは難しいです。この問題に対しどのように対応するべきかという課題が残ります。
例えば教育部門と人事部門の連携はキーとなります。教育部門は新入社員研修を通じて、将来的に成長する可能性がある人物を見極めております。可能性のある人物が評価されていない場合、人事部門に情報提供することがあります。このような連携を強化して、適切な評価を行う体制を作るべきだと考えます。教育部門は単に研修を実施するだけでなく、受講生と接点を持ち、必要に応じて人事にフィードバックすることが重要です。
・マトリクス型組織図の左端に PMO がありますが、これはどういった意味ですか？
⇒実際は、PMO が存在する時期とそうでない時期がありました。事業部内では、進捗等の管理面を中心に見ていて、従業員個人のことはあまり見ていない状況でした。これでは偏りがあると感じ、私は PMO と連携するようにしました。ヒトの面も考慮しないと、プロジェクトの進行に支障をもたらします。単に工程が間に合うだけではなく、人の側面にも注力すべきだと思います。
・PMO の役割は、プロジェクトの管理支援、標準整備／活用支援、そして PM 育成の 3 つがあります。私は製造業で 20 年、IT 部門で 10 年の経験があり、IT 部門では PMO として活動していました。PMO に求められる役割を果たすため、特にプロジェクトマネージャーの支援や育成を行い、これにより PMO としての成果を上げました。
・キャリア転換とは、キャリアパスと同じ意味ですか？
⇒違います。キャリアパスは、例えばプロジェクトリーダーからプロジェクトマネージャー、さらにプログラムマネージャーへの進行を示します。一方で、キャリア転換は転職を含み、整備されたキャリアパスとは異なる方向に進むことも指します。企業内でのキャリアパスと、外部の転職を含むキャリア転換を区別して認識しています。
また、キャリアデザインについても考えるべきです。PM から PL（プロジェクトリーダー）、PL からPM（プロジェクトマネージャー）、更にプログラムマネージャーに進むには、どのようにキャリアをデザインしていくかを考えることです。この支援は PMO の役割とも関連します。
・PMO のメンバーは他部署から来た人たちで構成されていることが多いのですが、現場からはそれがうまく機能しない場合もあります。例えば、大企業のプロジェクトマネジメントのやり方を小規模な会社に当てはめても、うまくいかないことがあるため、現場では PMO の支援が邪魔だと感じることもあります。
・P2M の資格取得者数について、PMP に比べて P2M の認知度は低いという課題があります。そのため、個人ではなく、例えば人事部門など企業内で影響力を持つ人をターゲットにする方法が有効ではないかと思いますが如何でしょうか。
⇒P2M の資格取得施策を行いましたが、個人のアプローチだけでは浸透しにくかったです。会社全体で推進するためには、人事部門などとの連携が必要です。資格取得について、当社では社内で60 名ほどの PMC 資格者を養成しました。しかし、資格取得だけで留まっていることが問題だと思います。特に、P2M を導入する際、膨大なガイドブックの内容が負担となっており、現実的で使いやすい形で自社版テキストが提供されることが重要だと思います。
一方で、P2M を学ぶことで却って問題が明確に浮き上がり、プロジェクトの問題解決を諦める人もいます。困ったことは、管理者サイドや PMO の厳しい指摘を受けて、現場の人たちは「現場に批判的なことしか言わない」「正論だけ」「報連相をすると、却って仕事が増えるだけ」と被害者意識で捉えることです。双方ともに言い方には気を付けないといけません。
更には「(PMO 等が上から目線の場合、)口だけで支援しない。コメントするくらいなら現場に入ってリーダーをやるべき」と管理者サイドや PMO 側に批判的な意見も持っています。この状況下で、自分は PMO と現場の溝、意識の乖離を埋める作業をやっておりました。
また、普及に関して言えば、P2M を導入する企業の経営者が本気で推進しない限り、普及は進まないと思いました。尚、後付けで P2M の視点から成功事例を紹介した事例はありますが、冒頭から P2M を使って成果を出した事例は少ないため、実際に企業がどのように P2M を活用して成功したかという具体例が求められていると思います。
・コメント欄を見て、経営層がプロジェクトマネージャー（PM）に対する認識に不安/不信を抱いていることに驚きました。経営層は、組織文化や風土の活性化が欠かせないものと捉えているべきだと思いますが・・・
⇒自分は組織文化や風土の活性化施策も担当していましたが、業績が良ければ組織文化や風土は良くなり、業績が悪ければ(組織文化・風土も)悪くなるというのが定番です。組織文化や風土を活性化させるための施策をいくら試みても、必ず成果が上がるわけではありません。長年にわたる活性化施策を担当してそう思います。
・現在の DX（デジタルトランスフォーメーション）に関しても、経営層がリーダーシップを発揮しない限り、会社は DX を実現できません。組織文化や風土に情熱が重要で、これがなければ成功は難しいと思います。これを実現するために、経営層、上位管理者、現場のプロジェクトマネージャーという 3 つの壁を越える必要があります。経営層がその認識を持たなければ、会社は危機的な状況に陥る可能性があります。
⇒経営層、上位管理者、現場のプロジェクトマネージャーは、会社全体の上位 20%を占めていますが、私の認識では残りの 80%の社員の意識も重要と思います。この層はリソースです。この 80%の社員が無関心とか、それ以上に面従腹背の姿勢になったら危機です。命令に従う人⇒主体者意識の乏しい人⇒「笛吹けど、(社員は)踊らず」となったら組織は終わりです。
＜森さん講話：第２部＞
【質問 11】P2M に関する基本的な知識は持っていますか？ (p22)
ほとんどの方が持っていると思います。
【質問 12】P2M が自身のキャリアに役立つと感じていますか？ (p23)
多くの方がポジティブに感じているようです。
【質問 13】実務で P2M を活用した経験がありますか？ (p24)
有資格者の多くは実際に活用しています。
【質問 14】P2M を使ってプロジェクト成果が向上した経験があるか? (p25)
72%が「成果が向上した」と答えています。
【質問 15】P2M を活用することでキャリア転換の選択肢が広がると感じますか？ (p26)
2/3 の方が肯定的な回答をしています。
【質問 16】P2M を参考にしたプロジェクト運営が職場で行われているか? (p27)
約 3 割の方が職場で P2M を活用していないと感じているようです。
【質問 17】キャリア転換において P2M を活用する具体的なイメージはありますか？ (p28)
P2M を活用するイメージを持っている方が多いです。
【質問 18】P2M を理解するために追加の研修が必要だと感じますか？ (p29)
約 3/4 の方が追加研修の必要性を感じています。
【質問 19】P2M は従来のプロジェクト管理方法より優れていると思う方が約 6 割です。(p30)
【質問 20】P2M に基づくプロジェクトマネジメントが組織全体の成果を向上させると考えていますか？
62%の方がそれを実感しています。 (p31)
(p32)
皆様からのコメントの中に、P2M の理解が不十分なため設問に回答しにくい部分もあったというご意見を頂きました。申し訳ございませんでした。
P2M は日本の風習に馴染みやすいと感じている方、また経営層がプロジェクトマネジメントを理解していないと感じている方もいます。
資格よりも上司や先輩から学ぶ部分が多いという意見もありましたが、現実的には入社数年後には自分で学ぶべきという立ち位置になります。
プロジェクトマネジメントは計画を重視しますが、実際にはドタバタをうまくまとめた人＜火消し屋＞が評価されることが多いという現実を他社さんからもよく聞きます。計画段階の重要性が強調される一方で、人の評価は、プロジェクトの対応力に重きが置かれています。
＜ディスカッションー２＞
・成果は出ているのに、職場で P2M が進まないのはなぜなのでしょうか？
⇒P2M を使っていると言っても、それが広まっているのではなく、使っている個人の認識があるだけと見ています。また、自分が取得した資格について、失礼ながら「自分が取った資格で成果が出た」と思い込みたい点もあります。これに関しては他の資格でも同じことが言えます。
・PMI の方法論が多く使われているため、P2M と PMBOK の差が縮まらないのもその一因です。IT業界では、プロジェクトマネジメントの方法論に関しては、70%が PMBOK に基づいています。この差は簡単には縮まらないのが現実です。
⇒PMI の方法論に従って研修を依頼された際にも、「PMBOK ガイドベースにして欲しい」と言われることが多いです。それは 70%の業界標準に基づくものなので、納得できます。
P2M の導入についても悩みがあります。社員との会話では、「分厚い本を読むのは無理だ」という意見が多く、PMBOK の方が使いやすいとの声が上がっています。特に市販の PMP ガイドなどは目次があり、簡単に検索できる点が利点です。
＜森さん講話；第３部＞
【質問 21～24】 (質問 25～30・p37～p42 については特に言及無し)
P2M のフレームワークを活用することで、プロジェクト目標の達成に寄与するという結果が得られました(48%)。
実際、P2M を使用したプロジェクトで 60%のケースが成功し、リスク管理やステークホルダーとのコミュニケーションも改善されたという結果が出ています(55%)。
P2M のフレームワークは、汎用性が高いとされております。しかし、P2M が特に効果を発揮するのは、上流段階（初期段階）がしっかり固まっている場合です。現実には、上流が曖昧なままで進行することも多く、これはプロジェクトの進行中にリスクや問題を引き起こす原因となります。
P2M の学びを深めることでプロジェクト運営が改善できるという点に関しては、具体的な方法を知ることが重要です。例えば、ガイドブックの熟読や、過去のプロジェクトを P2M のフレームワークで評価するなどです。しかし、実務では複雑すぎるツールや管理方法に対して、シンプルで実用的なものが求められるという意見もあります。
P2M のすべてを最大限に活用するのは良いことですが、より簡単で手軽に成果を上げられるフレームワーク集が欲しいそうです。例えば OJT（オン・ザ・ジョブ・トレーニング）では、OJT に使えるフレームワークを素早く選んで役立てる。そういうツールがあるとよいという意見もありました。
＜ディスカッションー３＞
・今日の話は、普段のフレームワークに基づく議論とは違って、もっと本音の話が多く出てきました。中にはうまく対応できない部分もありますが、このような本音の議論をしっかりとクリアしない限り、P２M の普及も難しいと感じています。諦めずに議論を続けていただきたいと思います。
⇒私は IT 業界の転職支援を行っており、例えば「あなたの仕事をマネジメント的に説明してほしい」という依頼をよくします。しかし、実際には 30 代でも PDCA サイクルを回せる人は少ないのが現実です。自分の技術については PDCA を展開できても、例えば人や物、金に関するマネジメントについては考えていないこともございます。
しかし、35 歳でマネジメント経験がないと、より高いレベルでの転職は難しいという現実はあります。このため、35 歳前後でマネジメントスキルをしっかりと身につけて、その後のキャリアに活かす姿勢は大切です。
因みに、転職を考えている人には、まず過去のプロジェクトを振り返り、その成果・反省を次の計画に生かすように指導しました。この手法を学部生や院生に対してもアドバイスしています。PDCA を使って物事を進めることは、実際に就職・転職活動で成果を上げるためには非常に有効です。
PDCA サイクルのうち、「C（チェック）」に焦点を当てて、実験や研究のような検証作業をしっかりと行うこと。特に、院生などが研究や就職活動で成功するためには、こうした検証や分析が欠かせません。実際、研究で失敗を繰り返していた学生を指導したことがありますが、PDCA を活用して質疑応答を繰り返した結果、それまで落ちていた難関企業の研究職に内定を獲得できました。
マネジメントスキルを身につけることで、キャリアは大きく変わると思います。最初は P2M や PMPといった資格を取るのは難しいかもしれませんが、PDCA をしっかりと理解し、分析・検証のスキルを磨くことが大切だと思います。それがまず第一歩です。
プロジェクトマネジメントのフレームワークに関しては、最初に要件定義を行ってプロジェクトがスタートします。しかし、その前に課題の解決策をモデル化するためにデザイン思考などの手法を使うことが必要です。その後、アジャイル開発を進め、実践と実証を繰り返すことでビジネスモデルを構築していきます。このような流れを理解していない人には、プロジェクトマネジメントがうまく進まないこともあります。
＜森さん講話：第４部＞ (p44)
P2M を普及させる障害について、いくつかの問題点が指摘されました。
【質問 31】内容が専門的で難しい (p44)
P2M の内容は膨大で専門的なため、初心者には難しいと思われているようです。例えば、標準ガイドブックが 700 ページ以上もあり、これが壁となっています。但し、標準ガイドブックは絶対に必要です。実際に PMBOK でもガイドブックはありますが、これらは初心者には難解です。シンプルで理解しやすいものがあれば、普及が進むのではないかと考えられています。
【質問 34】リソース不足 (p47)
P2M を活用するためには時間や人的リソースが不足しているという問題があります。これが原因で導入に対する意欲が薄れる場合もあります。P2M を導入しても、劇的な改善が見込めないと思うこともあります。
(時間の関係で質問 35・36 p48・p49 は割愛)
【質問 37】教材の不足 (p50)
P2M に関する情報や教材が十分に提供されていないという指摘もあります。資料が提供されていても、それが広く活用されていない可能性もあり、十分に理解されるための工夫が必要です。P2M の認知度の低さも影響しています。
(時間の関係で質問 38 p51 は割愛。ある種の共通理解)
【質問 39】経営者の経験の重要性(p52)
経営者が P2M で成功する経験を持つことは重要です。これにより、現場での適用方法が具体的に示され、周囲にも影響を与える可能性があります。しかし、経営層が支持してくれない原因としては、理解不足であるという意見もあります。
【質問 40】学習のコスト (p53)
P2M を学ぶためのコストが高いと感じる人が多いということです。合格する自信がないと思っているのかもしれません。しかし、PMR 取得後に実際の開発案件で PMR を活かして成果を上げたという報告が、一般の人に「まさにこの事例だ」と認識されない限り、PMR まで学ぼうとはしないでしょう。経営層もそんな高度な資格が本当に使えのるかと必要性を疑っています。
＜ディスカッションー４＞ (p54)
・P2M は PM の中でもあまり認知されていないので、PMP などと混同されがちです。この認知度の低さが、普及を妨げている要因の一つとして挙げられています。これらの問題点を解決するためには、シンプルで効果的なガイドブックの作成や、経営層の理解を得るための努力が必要です。また、P2M を学ぶためのコストやリソースについても再考が求められます。
・2 部での P2M に対する評価は比較的高かったと思います。その後、P2M を知っている人がプロモーターとして次の普及に繋がっていないことが課題だと感じています。この問題は、体制が整っていないことや、支援が不足していることが影響しているのかもしれません。そこで、P2M プロモーターを育成する方法が必要ではないかと考えますが如何ですか。
⇒その件について、社長と話したことがあります。社内で行っているプロジェクトリーダー育成施策について、社長は「(ひとりのリーダーに対して)1 年の施策では定着しない、(ひとりに対して)3 年くらいかけるべき」という指摘でした。しかし、私たちのリソースでは、1 年しかできないのが現実でした。そのため、普及に徹底して 1 年でできるだけプロジェクト数を増やして対応していましたが、確かに 3 年くらいかけて定着させる必要があったと思います。
社長からは、更にプロジェクトを展開するには、もっと時間をかける必要があるとも言われましたが、実際、最初の 1 年はコンサルタントと私がサポートし、家庭教師のような形で手取り足取り進めていました。しかし毎日はできません。要するに、社長は私たちがいなくても自走できるようにするためには 3 年かかるという意味を言っていたのです。それは本当にその通りだと思います。確かに、私たちがいつまでもサポートするのではなく、自走するためには時間が必要です。それを体系立てて地道にコツコツやれる指導者がいるかいないかです。
キャリアパスの整備について：
私の中では、育成という視点で今回のキャリアパスを構想しておりました。プロジェクトメンバー →プロジェクトリーダー → プロジェクトマネージャー → プログラムリーダー → プログラムマネージャーという構造ですが、制度にはしていません。
ここで重要なのは、キャリアパスは育成のための指標であり、実際の組織にそのまま当てはめるのは難しいということです。人事の視点では、機能組織の上に配置したい意図がありますが、必ずしもプロジェクトで成果を上げた人が、機能組織のリーダーとして適しているとは限りません。
プロジェクトリーダーの成長プロセス：
キャリアパスを具体的に考えると、プロジェクトリーダーの中級レベルは、入社 6〜9 年目で、プロジェクト規模と難易度も考慮して設定しています。また、新入社員や若手向けに、1 年目・3 年目の基礎研修を設けることで、ベースの部分は適切なキャリア形成ができるようにしています。但し、実際には、事業部ごとに技術特性が異なるため、一律に適用するのは難しいのが実情です。
事業特性による違い：
例えば、ある技術分野では進化が急激で、一気にステージが上がることがあります。一方、45 度の角度で成長する分野もあります。そのため、技術の成熟度や進化の速度に応じて、キャリアパスの設計も異なってきます。
異なる技術領域との融合の難しさ ：
異なる技術分野が共存する会社では、同じキャリアパスを適用しようとすると、話が噛み合わないことがあります。IoT は IT とハードウェアが融合したシステムです。顧客がそれを望んでいます。ただ単に IT 製品やハード製品のキャリアパスを作るのではなく、IoT という概念そのものからキャリアパスを作ることが求められるのではないかと思います。
＜森さん講話：第５部＞ (p55)
【質問 41～45】P2M 普及のための活動について (p55～p59)
自社内で PM の研修を定期的に実施し、P2M の活用事例を共有する場としてミーティングや報告会を設けました。また、プロジェクトの計画段階で P2M のフレームワークを積極的に取り入れる試みも行いました。P2M を学ぶための教材やマニュアル、e ラーニングも用意しました。しかし、成果が出て、更に定着したとはいえません。根の深い問題です。
【質問 46】PM 導入の理解を深めるため、全社的な説明会を実施する案もありましたが、必要性が低いとの考え方もあり、別の方法が模索されました。(p60)
【質問 47】プロジェクトメンバー向けに P2M の基礎知識を習得するための教育も実施しましたが、取り組みの内容にばらつきが見られました。(p61)
【質問 48～50】他のプロジェクトマネジメント手法との違いや P2M の意義を明確にし、実際のプロジェクトで試行してその有効性を検証(17%)する試みもありました。また、P2M に関連する資格取得を推奨する活動も行いました。(p62～p64)
＜ディスカッションー5＞ (p65)
⇒新入社員向けに P2M 資格（PMC）の受験支援も行いました。なお、社内では P2M を推進している個人に対する報奨制度は設けていません。その代わり、教育部門が費用負担しました。総じて P2M の普及活動は社内にとどまることが多く、積極的な外部展開には至っておりません。普及活動としての取り組みが十分とは言えない中、実務の中で P2M を広めたいという意識はあるものの、PR や具体的な普及策に問題があると考えられます。
・普及プロモーションがほとんど行われていないため、認知度が低いのも納得できるデータです。
⇒資格を取得することと、それを教えることは別の話です。資格を取っただけで教えられるわけではなく、P2M に関して実務で経験を重ねて身につける必要があります。そのため、普及のためのプロモーションが難しい面があります。このギャップを埋めるのは簡単ではありません。
PM 資格を持つ人は、単に資格を持っているだけでなく、その視点や考え方を実務に活かして欲しいです。プロジェクトマネジメントの実行において、PM 資格の知識や考え方を活用することが重要です。私自身も P2M そのものの指導はしていませんが、プロジェクトメンバーに不足している点をアドバイスすることはあります。例えば、プロジェクトのメンバーは QCD（品質・コスト・納期）だけを重視しがちですが、それだけではうまく進まないことを理解してもらっています。
・個人のモチベーションに頼った普及は難しく、仕組み化されていないのが課題です。第 4 版が出た際には、P2M 資格保持者向けにアップデート講座を提供し、資格保持者がブラッシュアップできる環境を整えるべきです。その上で、職場でのプロモーション活動を促進する仕組みを作ることが重要です。また、普及に貢献した人に対して何らかのインセンティブ（褒美）を用意するなど、モチベーションを高める仕組みも必要ではないでしょうか。現在のように、個人に負担をかける形ではなかなか行動につながらないため、より効果的な制度の整備が求められます。
⇒P2M に限らず、PMBOK などを学ぶことで多くの知識や考え方を習得できます。しかし、それによる「負の効果」もあります。知識や見方が増えることで、問題の深刻さがより明確に分かることです。何も知らない人よりも問題がはっきり見えてることで、結果として思考・言動が委縮してしまうことがあります。プロジェクトの結果を見通すと、「これは無理」と思い、積極的且つ柔軟な対応をしなくなります。また、「自分はプロジェクトのリーダーであっても、(管理職ではないから)責任者ではない」と逃げます。その人の上司が逃げる管理者だと、まさしくそうなります。
もう一つの問題点として、プロジェクト組織と機能組織のミスマッチがあります。多くの企業では、この二つの組織が並存しているものの、どちらを優先すべきかが明確になっていません。本来、プロジェクト組織と機能組織は相容れない部分があり、水と油の関係のようになっています。
それにもかかわらず、機能部門を維持したままプロジェクトを推進しようとするため、評価が曖昧になります。その結果、プロジェクトマネージャーが努力しても正当な評価を得られず、モチベーションが下がることがあるのではないでしょうか。
この点に関して、電機メーカーの事例ではうまくいかないケースが多く見られました。一方で、自動車メーカーは比較的成功しているようです。最近では、車にも IT が組み込まれるようになり、課題は増えていますが、それでもマトリックス型の組織運営では自動車メーカーの仕組みが参考になります。
この違いはどこにあるのかというと、自動車メーカーには「プラットフォーム」という基盤があり、それをベースにオプションを追加していく方式を取っている点です。電気業界では、プロジェクトのスタート時点で仕様が固まっておらず、顧客自身も具体的な仕様を決められないことが多い。しかし、納期だけが先に決まっているため、開発側が焦って混乱してしまう状況になります。
同じマトリックス型組織でも、自動車業界のような環境と、仕様が不明確な状態からスタートする業界では、状況が大きく異なると思います。この問題は単に組織の問題ではなく、ビジネスの進め方に起因するものではないかと感じます。
ちなみに、マルチプロジェクトやマトリックス組織に関する研究は少なく、1996 年に延岡健太郎氏が『マルチプロジェクト戦略』という本を出版したのが最後のようです。それ以降、特化した研究はほとんど見られません。この組織運営の問題を深く掘り下げた研究が少ないのは、それだけ難しいテーマだからなのでしょうか。
・「管理職のプロジェクトリーダーと非管理職のプロジェクトリーダーの違い」について説明をお願いします。
⇒プロジェクトリーダーには管理職の人もいれば、非管理職の人もいます。これは社内の階層とは関係なく、プロジェクトの規模や難易度、期間などによって決まります。比較的シンプルなプロジェクトであれば、管理職ではない一般社員がリーダーを務めることもあります。
一方で、複雑で規模の大きいものは管理職がプロジェクトリーダーを兼ねるケースが多いです。管理職と非管理職の違いとして、責任の所在が異なります。非管理職のプロジェクトリーダーは、最終的な責任を追及されることがないのに対し、管理職はその責任を負う立場にあります。非管理職の多くはリソースの権限がないため、その割り当てが不十分で、規模・難易度の割には納期遅延・赤字・不具合のリスクを軽視できません。しかし、マネジメント経験の少ない彼ら・彼女たちが「リソース不足で」と訴えても、もっと規模の大きいプロジェクト(＝売上が大きい)も同様なため、上司から「考えろ」としか言われません。これは気の毒で、社内で孤立感・無力感を感じてモチベーションダウン、或いは離職の誘因にもなります。
プロジェクトマネージャー（PM）を一つの専門職として考えた場合、管理職と対等な立場で活動する PM が存在する組織もあります。例えば、IT 系で専門的な PM は高い評価を受け、30 歳で年収1000 万円といったケースもあります。しかし、製造業等でリストラなどで管理職のポジションが減ると、元々ライン長（課長・部長）だった人が「プロジェクトリーダー」や「プロジェクトマネージャー」という肩書きを与えられることがありますが、この場合、本当に PM としての能力があるかは別問題で
す。残念ですが、ポジション調整のための「PM」と認識されます。
・管理職がプロジェクトリーダーになる場合、コストしか見ないコスト管理のみを担当していることもあります。
IT 系の企業では、キャリアパスが明確に分かれています。具体的には、「プロジェクトマネージャー」「テクニカルスペシャリスト」「サービスマネージャー」の 3 つの職種が縦に並びます。
例えば、技術系のエンジニアがキャリアを積む中で、レベル 3 になるとプロジェクトマネージャーへシフトし、プロジェクトリーダーとしての役割を担うことがあります。これは典型的なキャリアパスの一例です。
IT 系では、上位に進むほど管理職の役割を担う傾向があります。テクニカルスペシャリストも、レベル 4 やレベル 5 になると管理職になることがありますが、一部はプロジェクトマネジメントや保守運用のサービスマネージャーへとシフトすることもあります。このように、キャリアパスは個々の志向に応じて設計されています。この点で、製造業のキャリアパスとは異なると感じます。
・遅れて参加したので、皆さんの議論を少し聞いていました。ちなみに、延岡健太郎さんは私の大学のクラブの 1 年後輩で、よく知っています。彼の書いているマネジメント論や技術論については、まだ完全に理解できているわけではありません。彼はもともと広島の自動車会社の出身ですが、会社によって考え方が異なり、自動車業界でもかなり違いがあるように感じます。
森さんが指摘されたように、自動車メーカーはプラットフォームを持っているため、マトリックス組織での運営が比較的やりやすいという側面があると思います。一方で、それなら「プラットフォームを創るのは誰か？」という問題が出てきます。実際、プラットフォームを作れる人材がいなくなったケースもありますし、そもそもプラットフォームの概念が強い会社と弱い会社が存在します。
プラットフォームを持たない企業は、新たに作るという決断をするか、既存のものを活用しようとするかでアプローチが異なります。この違いは、何を実現したいのかというプランニングの最上流、つまり「企画」の段階で決まると思います。どの車にどんな価値を持たせるのか、なぜそれを市場に出すのか、自社が出す意義は何なのかが明確でなければ、「あるもので作ればいいじゃないか」という発想になりがちです。もちろん、それは投資やコストの面では合理的ですが、本当に実現したいことが達成できないのであれば、見かけ上の効率は上がっても、最終的な成果には届かない可能性があります。
私がいた会社は、プラットフォーム戦略がかなり曖昧でした。これは良い面もありますが、1990 年ごろまでは、自分たちが作りたいものを自由に作る風潮が強かったですね。軽自動車、乗用車、スポーツカーを製造していましたが、RV のような車種のラインナップが抜けていました。商用車やトラックのプラットフォームがなく、それが制約となり、商用車市場への参入が遅れたのです。その結果、一時的に会社の存続が危ぶまれる状況にもなりました。
本当に問題だったのは「何を作るべきか」という上流の議論が十分になされていなかったことです。
経験の延長で試行錯誤を繰り返すばかりで、根本的な戦略を考えられていなかったのではないか、という指摘がありました。そこで急遽、約 10 人のメンバーを集め、新たに企画部門を立ち上げることになりました。それまで企画部門が存在しなかったというのも驚くべき話です。
この新しい企画部門では、見えていなかった課題を洗い出し、改めて学び直す必要がありました。各分野に精通した人材が集められ、「このプロセスが分からなければ、この人に聞け」といった役割分担を明確にしました。結果として、プロジェクトと機能が交差する形で進められることになりました。
但し、企画をどう実行に移すかという仕組みは整っていませんでした。時間の猶予がなく、社長がトップダウンで「この企画を採用する」と決断。現場には社長自らが説明し、短期間で RV のラインナップが一気に拡充されました。
想定外の問題も次々と発生しました。その都度、現場が知恵を絞り、何とか形にしていきました。現場にはそれだけの力があったのです。企画が現場の実情とあまりにもかけ離れていると、「机上の空論だ」と受け入れられません。そのため、「この人が言うなら聞いてみよう」と思われるような信頼関係を築くことが重要でした。現場と企画のスムーズな連携を確立するには、相当な苦労が伴ったのが実情です。以上が、私の経験から得た教訓です。
＜森さん講話：第６部＞ (p66)
プログラムマネージャーの壁：
プログラムリーダーのキャリアについてお話しします。現在、このキャリアパスはまだ十分に確立されていませんが、重要なポイントとして、プログラムリーダーの次のステップは経営者候補であることが挙げられます。優秀なプログラムリーダーは、やがて経営者予備軍となり、最終的には経営者へと進んでいきます。
この過程において、多くの企業では人材開発の一環として育成プログラムを実施しています。しかし、単なる研修として形だけのものになってしまうこともあります。重要なのは、事業経営から企業経営へと視点を移し、経営理念に基づいた思考・判断や行動へと転換することです。ここで、プログラムマネジメントの意義が問われることになります。
特に注視する点としては、コンプライアンス、人事、経理、法務、知的財産といった部門との連携が挙げられます。経営者としての適性を判断するポイントになります。しかし、中にはこれらの部門との連携を軽視し、これらの部門が有する知識・視点を学ぼうとせず、部門に丸投げしてしまう人がいます。
例えば他社さんの例ですが、リストラが行われた時、工場長が「なんで工場長がリストラ対策をするのか?」と言った結果、社長の怒りを買ったという事例を聞いたことがあります。因みに工場長は経営者です。申し上げたいことは、これらの部門の個別業務を知るべきと言っているのではなく、経営的視点を有する立場の人には視点・考え方が必須と申し上げております。
経営の視点を持つためには、PL（損益計算書）発想から BS（貸借対照表）発想へと移行することが不可欠です。例えば、将来の BS から現在の BS を差し引いて、どのような PL を実現すべきかを考えたり、現在の BS からどのような PL を作るかを見極めたりする視点が求められます。事業部単位の損益計算書だけを意識するのではなく、ROE（自己資本利益率）など経営指標を理解していないのであれば、経営者としての資質を問われることになります。
さらに、プロジェクト単位での業務が単なる外注管理にとどまらず、他社との連携を視野に M&A を入れる必要もあります。これらの経験を積むことで、経営視点を養う必要があります。日本は高度成長期に売上や利益を追求することで強くなりましたが、その結果として環境問題などの社会問題も生じました。こうした外部要因も考慮しながら、プログラムリーダーが経営者へと転換することは、非常に大きな壁であると感じています。
プロジェクトリーダーとプログラムリーダーの壁 (p67)：
プロジェクトリーダーには、プログラムリーダーとしての役割を備える能力と、マルチプロジェクトマネジメントをしっかり遂行できる能力が求められます。
ミッションに基づくプログラムマネジメントの課題 ：
ある企業では、ミッションに沿った事業を行うためにミッション以外の事業を切り離した施策を進めました。しかし、切り離された事業(会社)は、その後成長し、結果的に売上が倍増しました。経営側は「ミッションに基づいて事業を行う」と説明しましたが、現場は勝てる事業を切り離したことを不安視していました。そのため、経営と現場の間に溝が生じたと聞いています。
これでは、プログラムマネジメントは機能しないのではないかと思います。また、ミッションと企業の強みが一致していない場合、プログラムマネジメントの実行が不十分になり、期待する成果が得られにくくなると思います。この点について、改めて考える必要があると感じています。以上が私のプレゼンの要点です。
＜ディスカッション−６＞
・先ほどのプログラムマネージャーの次のキャリアは、P2M における PMA（Program Management Architect）に相当するのでしょうか？
⇒私ははっきりと「経営者」だと考えています。
・もちろん、PMA もほぼ経営者に近い立場です。最後に説明があったポートフォリオの概念が含まれている点に注目しました。P2M にはまだ十分に反映されていません。
⇒一般的に財務会計や管理会計の話は損益計算書（PL）から貸借対照表（BS）へと移る形で整理されますが、実際にはそれだけではありません。現在の BS と将来の BS を考慮し、どのようなビジネスや仕組で実現するかを考えることが重要であり、これは経営者の視点が求められます。こうした思考を身につけるためのトレーニングが必要だと感じています。そのための教育も行っていますが、実際には非常に難しいです。経理知識がある人は計算自体はできても、ビジネス全体を見通す視点を持てるかです。このような観点を育てるための研修を実施しています。
・ポートフォリオのプロモーションの観点から、このページがすごく良いと思ったのは、P2M や PMIのポートフォリオ・プログラム管理から、さらに経営とのギャップを埋める部分がしっかり示されている点です。プロジェクトに関わる人だけではこのギャップを埋めることは難しいので、この部分をしっかり教育していく必要があります。
このような意識を持つ組織は発展していけると思います。ただ単にプロジェクトリーダーやプログラムリーダーを育成するだけでは不十分で、プロジェクトマネジメント全体に関する理解を深める必要があります。
私自身も、例えば e-tax でいくら利益が出たか、損失を出したかなど、すべて自分で管理していますが、それをできるようにするための教育が大切です。プロジェクトリーダーに対してそのような教育ステップを作っていくことが重要だと感じています。
・評価される人物が、結局「火消し屋」タイプになるという話が印象に残りました。特に、困難なプロジェクトでは、成功を収めた人物が注目される傾向があります。以前、JAXA の方から聞いた話では、「はやぶさ」のプロジェクトは、実は非常に難しいものでした。最終的にプロジェクトが成功したのは、「火消し屋」のような役割を果たす人がうまく問題を解決したからです。本来は計画段階でしっかり準備をしていれば、あんな問題は起こらなかったという話を聞いたことがあります。
お話にもありましたが、消火活動が得意な人から若い人が学んでも、結局は計画や上流段階で問題を解決できる人ではなく、現場で問題をなんとか収める「火消し屋」タイプの人が育ってしまうのではないかと思いました。
・「P2M 普及推進部会」では、どのように P2M の普及を進めていくかが課題となっています。どのように新たなメンバーを引き寄せ、P2M に関心を持たせるかが重要なテーマです。特に、アンケートの第 4 か第 5 項目あたりがヒントになりそうなので、それを参考にしつつ、P2M の拡大を図りたいと考えています。その際には森さんにご協力いただけるとありがたいです。人事担当者から見たP2M 資格の取得や普及に関する視点も、参考になるのではないかと思います。
・今回のアンケートをそれぞれの組織で実施されることをお勧めします。無記名アンケートですから、よりリアルな情報が得られると思います。組織ごとのバラツキも見えてくるはずです。この方法が P2M/PM の状況を把握するのにも役立つと思いますので、ぜひ実施を検討してみてください。
それでは、特に他にご意見がなければ、これで本日の会議を終了します。ご参加ありがとうございました。
※以下の内容は、時間の関係で割愛しました。
・『プログラムマネジメント』と『マルチプロジェクトマネジメント』を分ける別の理由(p68)
企業理念をプログラムミッションとして推進した結果、経営不振を招いたケース
・相互に補完するアジャイルプジェクト群を統合するプログラムマネジメント(p69)
個々のアジャイルプロジェクトに AI が搭載されたケースを想定
以上
＜注＞
資料は改訂される可能性がありますのでご了承ください。