【PMBOK第8版】チームのリードとは？「人間関係の泥臭さ」をマネジメントする技術

なぜプロジェクトマネージャーは「うんざり」するのか？

プロジェクトマネージャー（PM）を任されると、多くの人が「うんざり」したり、プロジェクトマネジメントそのものを嫌がったりします。その最大の理由は、スケジュールや予算の計算が難しいからではなく、「人間関係の調整（人のマネジメント）」が極めて困難でストレスフルだからではないでしょうか。

「プロジェクトの理想に向かって、全員で一丸となって頑張ろう！」というのが美しい理想ですが、現実はそう甘くありません。
PMBOK第8版の「チームのリード（Lead the Team）」は、まさにこの「人」に焦点を当て、対立（コンフリクト）を解消し、パフォーマンスを最適化するためのプロセスです。

今回は、PMBOKの理論を整理しつつ、フレームワークを杓子定規に当てはめるだけでは解決しない「現場の泥臭いマネジメント」について解説します^[1]Project Management Institute『プロジェクトマネジメント知識体系ガイド（PMBOK®ガイド）第8版』日本語版、第2部 … Continue reading。

「チームのリード」プロセスの基本概念

「チームのリード」とは、コンピテンシー（能力）やメンバー間の相互作用、チーム環境全体を改善することで、チームをマネジメントし、導くプロセスです。プロジェクトの開始から完了まで、継続的に実行されます。

このプロセスには、大きく2つの異なる視点からの働きかけが含まれます。

1. マネジメント活動: 目標達成のための「手段（プロセス、計画、作業の監視など）」に焦点を当てる。
2. リーダーシップ活動: 目標達成のために動く「人（影響を与える、動機付け、傾聴、支援など）」に焦点を当てる。

プロセスのITTO（インプット・ツール・アウトプット）完全網羅

チームを導くために、PMBOKでは以下のような多様な要素（ITTO）が定義されています。特に「ツールと技法」には、人間関係を構築するための様々なアプローチが詰まっています。

インプット（前提となる情報）

• プロジェクトマネジメント計画書（資源マネジメント計画書）
• プロジェクト文書（課題ログ、教訓登録簿、プロジェクト・スケジュール、資源カレンダー、チーム憲章、作業パフォーマンス報告書、プロジェクト・チームの任命）
• チームのパフォーマンス評価（現状の習熟度や強み・弱みのアセスメント）
• 組織体の環境要因（EEF） / 組織のプロセス資産（OPA）

ツールと技法（チームを導くための手段）

• 配置と協働環境: コロケーション（同室配置）、バーチャル・チーム / バーチャル・コラボレーション・ツール、コミュニケーション技術
• 人間関係とチームに関するスキル
  • コンフリクト・マネジメント、影響を与える（Influencing）、動機づけ（Motivation）、交渉、チームビルディング、意思決定、クリティカル・シンキング、コーチングとメンタリング、トレーニング
• 思考・問題解決と振り返り: 問題解決（シックス・シンキング・ハッツ®など）、レトロスペクティブ（振り返り）
• 評価・認知と対人知能: 表彰と報奨、個人とチームのアセスメント、感情的知性（EQ）、組織の文化的知能
• リーダーシップ・モデル: 分散型マネジメント（自己組織化等）、集権型マネジメント（トップダウン型）、サーバント・リーダーシップ（支援型）、タックマンの成長段階（形成期・嵐動期・統一期・遂行期・解散期）
• プロジェクトマネジメント情報システム（PMIS） / データ分析（SWOT分析等） / 会議

アウトプット（導いた結果生まれるもの）

• チームのパフォーマンス評価（チーム全体の有効性や成長度を評価したレポート）
• 変更要求（チーム構造の変更やトレーニング追加の申請）
• プロジェクトマネジメント計画書更新版 / プロジェクト文書更新版（課題ログ、チーム憲章等の見直し）
• EEF更新版 / OPA更新版

PMBOKが定義する「高パフォーマンスなチーム」とは

PMBOKでは、パフォーマンスが高いプロジェクト・チームの条件として、心理的安全性が確保された「オープンなコミュニケーション」、目的を共感している「理解の共有」、そして貢献を適切に認める「表彰（Recognition）」を挙げています。

また、これを実現するために、「サーバント・リーダーシップ」でメンバーの障害を取り除いたり、「タックマンの成長段階」に合わせて指導型から支援型へとアプローチを変えたりする柔軟なリーダーシップが推奨されています。

現場のリアル：参加者は「何を求めているか」

さて、ここまでPMBOKが提示する様々な素晴らしいツールやモデルを紹介してきましたが、実務において最も大切なことは、これらのフレームワークを綺麗に当てはめることではありません（そもそも、権限的にプロマネが表彰できるということも少ないと思います）。

プロジェクトマネージャーが最優先ですべきことは、「参加者（メンバー）が、このプロジェクトに何を求めているのか？」を泥臭く把握することです。

たとえば、同じプロジェクトにアサインされたメンバーでも、思惑は全く異なります。

• Aさん: 「今回の難易度の高いプロジェクトを成功させて、社内で名を上げたい（出世したい）！」
• Bさん: 「言われた仕事は手伝うけれども、プライベートを重視したいから負担は少ない方がいい」

Aさんには「やりがい」や「裁量を与えること（サーバント・リーダーシップ）」がモチベーションになりますが、Bさんに同じアプローチをすると「丸投げされて負担が増えた」と不満に繋がります。Bさんには「明確なタスクの切り出し（集権型マネジメント）」が必要です。

まとめ：理想が通らないときの「次善策」を持とう

「チーム一丸となって理想に向かって頑張ろう！」というのは、あくまで最良のシナリオにすぎません。
現実は、様々な本音やモチベーションを持った人間が入り乱れる泥臭い環境です。だからこそ、「全員がやる気を出してくれなかった場合、どうやって最低限の品質とスケジュールを守るか」という次善策（プランB）を常に考えておくことが、PMの心を守る盾になります。

かっこいいリーダーシップ理論を振りかざす前に、まずはキックオフや1on1の場で「あなたはこのプロジェクトでどんな恩恵を受けたいですか？」「何が一番嫌（我慢できない）ですか？」と、腹を割って本音をすり合わせる時間を作ってみてください。その泥臭い対話こそが、本当の意味で「チームをリードする」第一歩になるはずです。