実力者を集めたのに手戻りが止まらなかった ― 「チーム」の原則は協働を仕組みで作ること

初めて率いた20名規模の混成チーム。実力あるメンバーは揃っていたのに、手戻りが妙に多い——原因は個人のスキルではなく、情報が「所属会社ごと」に分断されている構造にありました。この記事では、その現場で何が起きていて、朝会ひとつでどう変わったかから始めて、PMBOK第7版の原則②「チーム」が本当に言いたいことを掘り下げます。

この記事でわかること

実力者を集めてもチームが機能しない構造(スキルの総和ではない)
所属会社の壁を越えてチームを機能させた現場の工夫
「チームビルディング=懇親会」という誤解のほどき方

SIerでPMをしている筆者が、PMPを学び直しながら「チームがうまく回った案件と回らなかった案件は何が違ったのか」を振り返って書いた記事です。

PMBOK第7版の「チーム」の原則が言うのは、個々のスキルを足し算するだけではチームの成果にはならないということです。協働しやすい環境、心理的安全性(安心して発言できる空気)、多様性を活かす仕組み——これらを意図してつくれるかどうかが成果を左右します。優秀な人を集めるのは出発点にすぎず、その力が噛み合う「場」を設計するのがPMの仕事です。

所属会社の壁が手戻りを生んでいた
協働について、私が勘違いしていたこと
なぜ「集めれば動く」では回らないのか
今、意識していること
よくある質問(FAQ)
ここまでの整理
関連記事

所属会社の壁が手戻りを生んでいた

初めて、自社メンバーと協力会社を合わせた20名規模の混成チームを率いたときの話です。スタート当初、実力あるメンバーは揃っていました。それなのに、手戻りが妙に多い。原因がしばらく分かりませんでした。

よく観察して気づいたのは、情報が「所属会社ごと」に分断されていたことです。自社メンバーは自社の連絡ルートで、協力会社は自社内で完結していて、困りごとがチーム全体に届く前に個社の中で抱え込まれていた。結果、問題が表面化するのはいつも手遅れになってからでした。

そこで、朝会を「全員参加の共通の場」に一本化しました。しかも、進捗報告だけでなく「今、困っていること」を必ず一言ずつ共有するルールにしたのです。最初はぎこちなかったのですが、続けるうちに協力会社側からも「実はここが不安で」と早い段階でリスクが上がるようになりました。手戻りは目に見えて減りました。特別なことは何もしていません。困りごとが自然に集まる「場」を一つ作っただけ。それがチームを機能させる第一歩でした。

協働について、私が勘違いしていたこと

正直に言うと、私はかつて「チームビルディング=懇親会や飲み会」だと思っていました。もちろん関係づくりに意味はあります。でも原則が指しているのは、そこではありません。

チームの原則が本当に言っているのは、日々の意思決定の進め方や、情報が流れるコミュニケーションの構造そのものを設計すること。飲み会で一時的に仲良くなっても、翌日の朝会で困りごとが言えない空気なら、チームは機能しません。「イベント」ではなく「日常の仕組み」——ここを取り違えないことが大切です。

なぜ「集めれば動く」では回らないのか

プロジェクトは一人では完成しません。特にSIの現場では、自社・協力会社・顧客と、立場も所属も違う人が同じゴールを目指します。ここで「集めれば動く」と考えていると、必ずどこかで歯車が空回りします。個々は自分の持ち場で最善を尽くしているのに、間をつなぐ構造がなければ、困りごとは持ち場の中に沈んだままになる。だからこそ、チームを「仕組み」として捉える視点が要るのです。