「あなたがリーダーですか？」という問いの危うさ
プロジェクトの킥オフミーティングで、こんな場面を見たことはないだろうか。PMが全体の進行を仕切り、メンバーは指示を待ち、質問はすべてPMに集中する。一見、秩序立ったチームに見える。しかし数週間後、そのチームは「PMが忙しくて判断が下りてこない」「何をしていいかわからない」という状態に陥っていることが多い。
これは、リーダーシップが「PM一人に集中している」ことから生まれる構造的な問題だ。チームビルディングを語るとき、多くの議論は「PMがどう振る舞うか」に終始する。だが本当に重要なのは、チーム全体にリーダーシップをどう分散させるか、という設計の問題である。
なぜ「分散型リーダーシップ」が必要なのか
プロジェクトの複雑性が増す現代において、PMがすべての判断を下すことはもはや現実的ではない。技術的な判断、顧客との折衝、チーム内の人間関係の調整——これらを一人でこなそうとすれば、PMはボトルネックになり、チームは思考停止に陥る。
分散型リーダーシップとは、「特定の役割に応じてリーダーシップを担う人が変わる」という考え方だ。技術的な判断はシニアエンジニアが担い、品質管理の局面ではQA担当がリードし、顧客コミュニケーションはビジネスアナリストが主導する。PMはその全体を俯瞰し、方向性を守る役割に徹する。
この設計の最大のメリットは、チームの「自走力」が生まれることだ。誰もがある局面でリーダーとなり得るとわかれば、メンバーは受け身ではなく、主体的に考え行動し始める。
分散型リーダーシップを機能させる3つの設計原則
① 「誰が何をリードするか」を明示的に合意する
暗黙の期待はトラブルの温床だ。プロジェクト開始時に、「この領域ではあなたがリードする」という役割の明示的な合意が必要になる。
実践Tips：キックオフ時に「リーダーシップマトリクス」を作成しよう。縦軸にプロジェクトの主要な意思決定領域（技術、品質、スケジュール調整、ステークホルダー対応など）、横軸にメンバーを置き、「主導する人」「支援する人」「承認する人」を明記する。RACIチャートに近い発想だが、ここでのポイントは「主導する人」をメンバー自身が選び取る形にすることだ。
② PMは「答えを出す人」から「問いを立てる人」へシフトする
分散型リーダーシップの最大の障壁は、実はPM自身の行動習慣にある。メンバーから相談を受けたとき、反射的に「こうしよう」と答えを出してしまうPMは多い。これは一見、頼もしいリーダーシップに見えるが、メンバーの思考力と主体性を奪う行為でもある。
実践Tips：「あなたはどう思う？」「今考えられる選択肢は何か？」という問い返しの習慣を意識的に取り入れよう。最初はメンバーが戸惑うこともあるが、繰り返すうちに「自分が判断する」という意識が根付いていく。PMの役割は、答えを与えることではなく、メンバーが良い判断を下せる環境と問いを設計することだ。
③ 「小さなリーダーシップ体験」を意図的に設計する
リーダーシップは、与えられるものではなく、経験によって育つものだ。だとすれば、チームビルディングの核心は「メンバーがリーダーシップを体験できる機会を設計すること」にある。
実践Tips：週次の進捗会議の司会をメンバーがローテーションで担当する、特定のサブタスクのオーナーシップを明確に委ねる、ステークホルダーへの報告資料の一部をメンバーが単独で作成・説明する——こうした「小さなリーダーシップ体験」を積み重ねることで、メンバーは徐々に自信と責任感を獲得していく。
「心理的安全性」はチームビルディングの前提条件である
どれだけ優れたリーダーシップの設計をしても、メンバーが「失敗したら責められる」「意見を言ったら否定される」と感じている環境では、主体的な行動は生まれない。心理的安全性は、チームビルディングにおける「土台」だ。
PMにできる最も即効性のある行動は、自分自身が「わからない」「失敗した」と口にすることだ。PMが弱さや不確実性を開示することで、メンバーは「この場では正直に話してよい」と感じるようになる。チームの心理的安全性は、PMの自己開示から始まる。
チームは「作るもの」ではなく「育てるもの」
チームビルディングをイベントや研修として捉えている限り、本質的な変化は起きない。強いチームは、日々のプロジェクト運営の中で、意図的な設計と小さな積み重ねによって育っていくものだ。
PMの本当の仕事は、「自分がいなくても動けるチーム」を作ることかもしれない。それは自分の存在価値を消すことではなく、チームの可能性を最大化することだ。分散型リーダーシップの設計は、その最も確実なアプローチの一つである。
あなたのチームには今、「リーダーシップを担える機会」が十分に設計されているだろうか。その問いから、チームの変革は始まる。
