良いチームをつくる3つのポイント。
陥りやすい罠をチームビルディングで乗り越える

「有識者の罠」の解決から学んだ
「チームが大事」という考え方

プロジェクトは、一人でやり遂げられるものではありません。どんなに優れたPMでも自分だけでプロジェクトを成功させることは不可能です。大規模なプロジェクトは、一人のエースではなく、チームのみんながいてはじめて成功します。今では「チームであることが大事」という考えに至っていますが、この気づきを与えてくれたのは、過去の経験でした。

以前、長期にわたる大規模な開発プロジェクトがあり、100人以上のメンバーが新たに加わりました。私はそのプロジェクトに前から参加しており、「自分さえいれば現場は回る」という自信を持っていました。

当時の私は、新規参画者に信頼を置くことができず、私が「有識者の罠」と呼んでいる閉鎖的な思考に陥っていました。この場合の有識者とは、以前からプロジェクトに関わり、知見を蓄積してきた者という意味合いで、有識者からすると新規参画者は「仕事に必要な知識を持たない新参者」に見えてしまいます。

当初は自分の力に頼ってプロジェクトを回せていたのですが、途中から進捗が停滞し始めました。そのときに、「仕事を分割し、新規参画者にうまく任せる方法」について考え始めたのです。

そこから数年後、今度は私が新規参画者として既存プロジェクトに加わり、現場のメンバーを率いることになりました。有識者たちから教えてもらう立場になったわけです。ここでは「最優先事項はプロジェクトを完遂させること。全体を俯瞰し、次のステップに進むためには、誰に何を担当してもらうべきか」という采配に注力しました。一人ひとりのスキル、得意領域を知り、適材適所に配置することから取り組んだのです。

これらの経験を経て学んだのが、「有識者と新規参画者の間にある壁を壊さなければいけない」ということです。すべての参加者がお互いをリスペクトしながら一人ひとりが活躍できる。その環境を整えることがPMの重要な役割だと分かってきたのです。

良いチームをつくる3つのポイント

チームビルディングを成功させるためには、何が求められるのでしょうか。大きく３つのポイントがあると考えています。

1.チームを作る／変える勇気を持つ

プロジェクトは長いものになると、5年、10年を超えることもあります。長く続くプロジェクトの場合、古株メンバーである「有識者」が新規参画者との間に壁を作ってしまうこともあります。

途中から加わった新規参画者は、SEとしてのスキルは持っていても、そのプロジェクトに求められる独自のノウハウを持っていません。そのため有識者に教えてもらう必要があるのですが、有識者の多くは無意識に「自分でやったほうが早い」「やりがいのある仕事は楽しいので、自分で取り組みたい」という閉鎖的な考えを持ちがちです。ところが有識者が仕事を独占すると、新規参画者に教える機会、仕事に巻き込むきっかけが失われ、チームビルディングの妨げになりかねません。これを私は有識者の罠と呼んでいるわけです。

もちろん、プロジェクトを成功させるためには、経験豊富な有識者の存在は欠かせません。しかし、大規模なプロジェクトを成功へ導くためには、新規参画者にこそ能力を発揮してもらい、チーム全体で進んでいく必要があります。

この問題を解消させるには、参画者をプロジェクトに巻き込む工夫が必要です。例えば、新規参画者向けの勉強会。プロジェクトが目指す「機能追加の内容」や「本番でのインシデント」「重要な課題」といった内容を体系立てて説明することで、新人でもプロジェクトに参加しやすい状況を作ります。

そのような活動と並行して、有識者側の意識改革を進めていく必要もあります。現場を支えてきた人たちに「新規参画者を育てよう」という気持ちを伝え、チーム内に「新規参画者や若手に技術を教えたくなる」雰囲気が醸成できれば、有識者の罠を壊すことにつながります。このように、新規参画者を巻き込みながらチームを変えつつ、推進させていくこともPMに求められる重要な役割です。

また協力会社のメンバー、クライアント企業であるお客様とのコミュニケーションも大切です。NTTデータアイが扱う開発プロジェクトのほとんどは、オーダーメイドのシステムである点が挙げられるからです。

社外とのコミュニケーションがおろそかになると、プロジェクトの成果に悪影響を及ぼします。一緒に課題を把握し、開発を進めていく。「お客様もチームの一員」と考え、チーム作りをしていきます。

2.チームの切り方を考える

多くのPMを悩ませる課題に「縦割り問題」が挙げられます。一般的に、プロジェクトは設計、製造、テストという工程を踏んでいきます。開発する機能ごとにサブチームに分けると製造段階ではスムーズに進みますが、テスト段階ではサブチーム間のコミュニケーションが取りにくくなることもあります。

その対策として、工程ごとにチーム編成を変えるという手もありますし、テスト段階を見据えて、関連する機能を最初から1チームにまとめておくという手もあります。プロジェクトの特徴を踏まえて、「最適なチームの切り方は何か」を熟考して、チーム構成を決めなくてはいけません。時には、一度決めたチーム構成を途中で変える判断も必要となるでしょう。

ただし、明確に担当を分ければ問題が出ないというものではありません。仕事というものは、厳密に分けられるものではないので、スキマにこぼれる仕事が必ず生まれます。その結果、「それはあなたの仕事でしょう」「いや、あなたの担当でしょう」という負のコミュニケーションが出てくるのです。とくに新規参画者にはスキマが見えないので、有識者のサポートが必要です。

私は、担当を分けつつも「お互いの役割を一歩ずつ踏み込んで、スキマを埋めよう」と呼びかけています。それでも埋められそうにないときは思い切って役割分担を変える、そのスキマの仕事に新たな担当者を配置するなど、柔軟に考えるようにしています。そうやって、プロジェクトがうまく回っていくようになると、お互いの信頼関係が深まります。

このようにPMは、プロジェクト全体を俯瞰しながら、課題や進行状況を見極めつつ、それぞれの作業範囲をシンプルにする、必要に応じて変更するなど、思い切った役割分担を行う必要があります。

3.チーム間の役割整理を明確にする

システムが完成に向かうにつれ、サブチームごとに開発してきた機能を統合していきますが、機能をつなぎ合わせた段階で新たな問題が生じることもあります。そこで重要になるのが、それぞれを調整する仕事です。

例えば、機能Aと機能Bが関連するシステムで問題が起こったとします。それぞれの機能単体では問題ないのに、連携させるとうまく動かない。そのようなとき、「A担当のサブチームで修正するか」「B担当で対応するか」を判断しなくてはいけません。

PMとしては「Aに問題がある」と責任を押し付けるのではなく、「Aで対応するほうが進捗の影響が少ない」など、納得してもらいやすい客観的な根拠をもとに説得していきます。場合によっては顧客要件をもとに全体俯瞰からあるべき姿を再検討し修正方法や担当を決めることもあります。大規模なプロジェクトではそういう検討や調整、判断も多くなるので、PMとは別に横ぐしで検討・調整・判断する専門のチームを作って対応することもあります。

以上の三つはPMにしか決断できないことといえます。何か問題が起こったときにはきちんと介入し、メンバーの納得と相互理解を積み重ねていく。このような姿勢がプロジェクトを好転に導くのです。

プロジェクト成功の喜びを、
すべての参画者と共有できるPMでありたい

PMとしての醍醐味、満足感を抱く場面は、やはりシステムが完成したときです。一人ひとりが自らの役割を全うし、互いの業務を尊重し続けた結果、素晴らしいシステムができあがる。さまざまな課題を乗り越えて、喜びを共有するメンバーを見ながら、「これを采配したのは自分なんだなあ」と感じる瞬間は、PMでなければ得られない喜びです。

端的に言えば、PMとは「与えられた目標を、与えられたリソースで、達成へと導く」仕事です。その過程には、困難も少なくありません。しかし、そのゴールには「みんなと一緒に仕事をして、信頼が生まれ、協力関係ができて、達成感が得られる」という楽しさが待っています。今後もその楽しさを多くの人に感じてもらえるよう、プロジェクトをマネジメントしていきたいと考えています。