大規模プロジェクトを成功させるためのチームビルディング（前編）

Web制作・システム開発会社「サービシンク」は従業員約30名の少数精鋭〜中堅規模に該当する企業です。しかしこれまで多くの大規模プロジェクトの発注を受けてきました。初期費用の段階で数百万円を要する案件から、一億円を超えるプロジェクトまで、多種多様な制作実績がそろっています。制作実績のページはこちらからご覧ください

なぜ、少ない社員数でも、このような大規模プロジェクトの開発を行うことが可能なのでしょうか？ その秘密は、個々の開発メンバーのスキルアップを図る、チームビルディングにあります。

今回は、プロジェクト成功のために、チームリーダーたちがチームビルディングにどのような工夫をこらしているかを、前後編に分けてご紹介します。

前編（この記事）では、チームを導くにあたってのビジョンの描き方について、ご紹介します。 後編では、チームビルディングの具体的な方法について、ご紹介します。

 

チームビルディングの重要性

チームビルディングとは？

そもそも、チームビルディングとは、どういう意味なのでしょうか？
簡単にいえば、それは「より良いチーム作り」を指しています。チームビルディングの狙いは、メンバー一人一人のスキルや個性を引き出し、チームとしての成果を最大限に発揮することです。

良いチームは、個々のメンバーが生み出す成果を高めるだけではなく、それぞれのメンバーたちの間に、「シナジー効果」をもたらします。シナジー効果が生まれているチームは、非常に強力で、ただメンバーを寄せ集めただけの集団よりも、何倍もの素晴らしい成果を上げることが可能です。

しかしながら、時にはチームメンバー同士が摩擦を起こしたり、せっかくメンバーが生み出した成果を、うまく生かせなかったりする場合もあります。この時、チームとしての力は大きく減退し、時には、互いに足を引っ張り合うという状況に陥ってしまうことすらあるのです。

そして、ここが重要なのですが、どれほどスキルの高いメンバーをそろえたとしても、最初から最高のチームになるわけではありません。 良いチームは、プロジェクトの中で「育てる」ものなのです。 チームビルディングを意識しても、すぐには効果が発揮されません。時間が経つにつれて、チーム全体が磨かれてゆき、特にプロジェクト中盤以降からその効果が目に見えてくるはずです。

まさに、メンバーはダイヤの原石。輝かせるのも、曇らせるのも、チームビルディングが大きく関わっている、と言っても過言ではないでしょう。

チームビルディングをした場合、しなかった場合の違いは？

それでは、チームビルディングを積極的に行ったチームと、行わなかったチームでは、プロジェクトに対して、どのような成果の差が生まれるのでしょうか？

一つの例を想像してみましょう。

あるプロジェクトでは、非常に難解な仕様のシステムを開発しなければなりません。仕様は複雑に絡み合い、理解するまでに大きな労力を要します。

プロジェクト開始段階で、Aチームは、リーダーが先行きを案じて、チームレベルでの対策を取ることにしました。

「仕様で分からないことがあったら、全て私に聞いてください」とリーダーは、チーム内のメンバー全員に伝えます。

一方のBチームは、リーダーが「難解な仕様である」ことをしっかり自身の肝に銘じ、「自分が完璧に仕様を把握しなければ」と意気込みましたが、チーム全体で何か対策を取るということはしませんでした。結局、「仕様で分からないことがあったら、全てリーダーに聞く」というルールだけが、チーム内に伝達されることになりました。

さあ、この場合、AチームとBチームとの間に、どのような差が現れるでしょうか。

まず、Aチームのリーダーが取った対策の意図は、明らかです。
プロジェクト初期段階では、個々のメンバーからの仕様確認に答えることは容易でも、いずれ仕様が複雑化してゆくにつれて、リーダー一人ではとてもまかなえなくなってしまう事態を危惧したのでしょう。 そのため、自分が完璧な統率者として振る舞うことよりも、チームを「育てる」道を選択し、必要な手を打ったのです。

プロジェクト初期段階のリーダーは、確かに大変かもしれませんが、やがてそれぞれのメンバーたちは自立の方向へと向かってゆきます。
リーダーの掲げた「仕様確認を最優先とする時間帯を設ける」文化は、チーム内に根付くこととなり、メンバー同士のコミュニケーションは依然として活発に行われています。それに応じて、メンバーからの提案やアラートもスムーズに伝えられ、すぐに然るべき対応が行われます。
こうして、気になることは早期に対策され、特にプロジェクト中盤以降において、開発は円滑に進んでゆきます。

それでは次に、Bチームのケースを考えてみましょう。
Bチームのリーダーは、プレイヤーとして非常に優秀です。しかしながら、プロジェクトが進むにつれて、どんどんとメンバーからの仕様確認に時間を奪われてゆき、自分の仕事になかなか手が回りません。

その様子を見て、メンバーたちは、こう考えるようになるでしょう。「リーダーはとても忙しそうだ」「このくらいのことで確認するのは申し訳ない」。やがてメンバーたちは、指示されたことだけをこなすようになり、個々人の判断で、仕様確認を諦めるようになってしまいます。

このような事態に陥ってしまうと、しばしば、メンバーは自閉的になりがちです。「とにかく、自分は自分の担当領域だけやろう」「他の人の仕事に首を突っ込む余裕はない」……こうして、チームとしての成果（＝納品物の成果）から、自分の仕事の成果へと、次第にフォーカスが絞られていってしまうのです。

特に、メンバーが自閉的になってしまったチームの特徴として、「おや？」と思ったけど重要ではないと判断されたことが、そのままアラートとして上げられずに、見過ごされやすい傾向にあります。すると、見過ごした当初は良くても、後からじわじわと大きな反動となって返ってきます。
これがいくつも積み重なることで、結果的に、納品物の品質低下や、度重なる修正による工数の増大化を招いてしまうのです。

チームビルディングに求められるものとは？

さて、それでは、チームビルディングを行うのに必要なことは、一体何でしょうか？
リーダーによってさまざまな答えがあると思いますが、特に、以下の二点が重要なのではないでしょうか。

• チームを機能させるシステムづくり
• チームメンバーの指導とケア

それでは、それぞれどんな内容を指し示しているのか、順番にみてゆきましょう。

チームを機能させるシステムづくり

まず一つ目に重要なのは、チームをうまく機能させるためのシステムづくりです。ここでのシステムとは、チーム運営のためのルールや文化、環境のことを指しています。
良いチームを目指すには、まず、メンバーの成長を促す、健全なシステムが機能している必要があります。

システムは、メンバーの成果の限界を規定します。どれほど素晴らしいスキルを持ったメンバーがいたとしても、チーム内のシステムがメンバーを阻害しているならば、その能力を存分に発揮させることはできません。反対に、例え不慣れだったり、スキルにまだ不安が残るメンバーであっても、システムが十分に機能しているのであれば、自然と学習・成長し、自身の能力を開花させてゆくのです。

また、システムは、チーム内で一度構築したら、それで終わりではありません。プロジェクトの状況に応じて、きめ細やかに修正してゆく必要があります。

有名な「タックマンモデル」というモデルは、チームの形成から解散に至るまでのフェーズを、5段階に分けて説明したものです。チームビルディングを扱う書籍では、しばしば、このタックマンモデルを取り上げて、チームの状況と必要なシステムを理解してゆきます。

例えば、プロジェクトの最初期にあたる「形成期」では、メンバー同士が交流を深め合えるイベントを。次の段階、最もチームが動揺しやすい「混乱期」では、メンバー同士の衝突を乗り越えるための説明機会や、手厚いフォローを……このように、段階に応じて、チームに必要とされるシステムの方針は異なってくるでしょう。

もちろん、チームが辿る変遷は、タックマンモデルよりももっと繊細で、複雑になることが大半です。チームリーダーは、現在、プロジェクトがどのような状態にあるのか、またチームメンバーたちが何を求めているのかを敏感に察知し、臨機応変に手を打つ必要があります。

チームメンバーの指導とケア

二つ目に重要なのは、チーム内のメンバーに対する継続的な指導とケアです。
メンバーに必要とされるスキルは、常に一定ではありません。とにかく納期が短いプロジェクトと、複雑な要件を要求されているプロジェクトでは、必要とされるスキルは異なります。さらには、それぞれのメンバーの個性や、相性、プロジェクトの時期によっても、求められるスキルは事細かに変わってくるはずです。

そこで、プロジェクト初期段階から、リーダーは、メンバーに期待する役割を明確に伝える必要があります。さらには、プロジェクトが完了するまで、教育とチェックを続けることが重要です。

意外かもしれませんが、メンバーのスキルは、高ければ高いほど良いというものではありません。チームから求められている立場を理解していないメンバーは、自身の高いスキルを発揮したがるあまり、時にはチームワークを乱してしまうこともあります。 また、本人の意思や特性、プライベートの事情などで、どうしてもチームから求められている役割を果たすのが困難な場合もあります。

その場合は、けして一方的に押しつけるのではなく、まずはメンバーに丁寧なヒアリングを行い、互いの求める姿を明確にする必要があります。

その上で、改めてプロジェクトの優先順位を確認したり、チームメンバーに期待する役割を見直したり、あるいはメンバーの配置替えを行って、より個人の成果がチームの成果に繋がるよう、根気強く指導してゆくことが大切です。

まずは「良いチーム」のビジョンを描く

さあ、ここまでで、チームビルディングに重要と思われる二点をご紹介いたしました。
さて、それでは実際にチームビルディングを始める前に必要な下地は何でしょうか？

それは、「理想のチーム」のビジョンを描くことです。
これが今後のプロジェクトの全ての土台となるとともに、メンバーたちの道しるべとなります。

とは言っても、いきなりビジョンを描こうとしても、なかなか簡単にはいかないものです。まずは、ビジョンを描くためのステップとして、

• プロジェクトの特徴を考える
• リーダーの特徴を考える
• メンバーの特徴を考える

の三つを順番に行ってみることにしましょう。

プロジェクトの特徴を考える

まずは、これから携わるプロジェクトには、どんな特徴があるのかを考えてみます。
あまりプロジェクトの全貌が掴めていない段階でも、以下のような特徴があるかどうかは、判断がつきやすいのではないでしょうか。

• スケジュールは長いか、短いか？
• ステークホルダーは多いか、少ないか？
• 仕様はシンプルか、複雑か？
• メンバーは多いか、少ないか？
• 意思決定はスムーズに行われるか、時間がかかるか？
• 途中での仕様変更は頻繁に起こるか、起こらないか？
• 内容が未確定の範囲はどのくらい？
• その他、気をつけなければならない点は？

リーダーの特徴を考える

次に、リーダーの特徴を考えてみます。そして、それをプロジェクトの特徴と照らし合わせてみた場合に、どんなところがプラスに働き、どんなところがマイナスに響きそうか？　を洗い出してみましょう。

リーダーはプロジェクトの柱です。そのため、プロジェクトの成果にもっとも大きな影響を及ぼします。プロジェクトの進行をもっとも円滑にできるのがリーダーであれば、もっとも深刻なボトルネックとなってしまう恐れがあるのも、リーダーです。

そのため、リーダーがプロジェクトを担当するに当たって、事前に想定しうる危険性（リスク）を洗い出しておくことが重要です。

以下は、プロジェクトの特徴とリーダーの特徴を照らし合わせて考えてみた例です。どのケースにおいても、リーダーの特徴がプラスに働く場合と、リスクに繋がる場合の両方が考えられると思います。

• 「長期のプロジェクト」×「いくつもの案件を抱えているリーダー」
  • プラス面
    他案件の最新のナレッジを共有できる
  • リスク
    他案件にかかりきりになると、長期プロジェクトの方はおざなりになりがち。特にスケジュール管理が不安

• 「仕様が複雑なプロジェクト」×「完璧主義者のリーダー」
  • プラス面
    常に仕様を把握している人間が一人は存在する状態にできる
  • リスク
    リーダーに負荷が高まりそう。精神的に疲弊するかもしれない

• 「納期が短いプロジェクト」×「プレイヤー志向のリーダー」
  • プラス面
    緊急の場合は、最悪、リーダーが巻き取れる
  • リスク
    リーダーが軽率に手を出してしまい、結果、リーダー以外誰も仕様や実装方法が分からない箇所が生まれてしまう

さて、この作業により、プロジェクトの未来が次第に露わになってきました。ここで想定されるリスクには、何らかの対策が必要です。

メンバーの特徴を考える

それではここで、プロジェクトの登場人物を、一人追加してみます。自分以外のメンバーに、どのような対応をしてもらえれば、このプロジェクトのリスクを回避できるのか、想像してみましょう。

• 「長期のプロジェクト」×「いくつもの案件を抱えているリーダー」
  • リスク
    • 他案件にかかりきりになると、長期プロジェクトの方はおざなりになりがち。特にスケジュール管理が不安
  • リスク回避の手段
    • 進捗確認役のメンバーを一人用意し、リーダーのスケジュールが詰まってきた場合は、そのメンバーと毎日、進捗確認MTGを行う

• 「仕様が複雑なプロジェクト」×「完璧主義者のリーダー」
  • リスク
    • リーダーに負荷が高まりそう。精神的に疲弊するかもしれない
  • リスク回避の手段
    • 時間のかかるドキュメント作成は別メンバーに担当させ、リーダーは指示とフィードバックのみを行う

• 「納期が短いプロジェクト」×「プレイヤー志向のリーダー」
  • リスク
    • リーダーが軽率に手を出してしまい、結果、リーダー以外誰も仕様や実装方法が分からない箇所が生まれてしまう
  • リスク回避の手段
    • リーダーが実装するのは、大枠とコメントのみ。以降は、ベテランのメンバーに実装を任せる

このように深掘りしてゆくと、「このプロジェクトを成功させるには、どのようなメンバーが必要なのか？」「対象メンバーには、どんな働きを期待しているのか？」が、徐々に浮かび上がってきます。ここで浮かび上がってきたメンバーこそが、リーダーを支える、このチームのキーパーソンとなるのです。

そして、今後はこのキーパーソンについて、どんなリスクが想定されるか？　それをカバーするには、どんなメンバーが必要なのか？　……と、リソースが埋まるまで、どんどん繰り返してゆきましょう。

重要なのは、メンバーに必要な要素として、最初から必要な特性と、プロジェクトの中で育成すべきスキルを、分けて考えることです。プロジェクト参加時点で、求められる全ての要素を兼ね備えているメンバーは、ほとんどいないと言ってよいでしょう。

特に後者の、「プロジェクトの中で育成すべきスキル」については、この時点で指導案を練っておくとベターです。後の工程が、よりスムーズに進められます。

優先順位をつける

さあ、プロジェクト、リーダー、メンバー、全てのリスクと回避策を洗い出せたら、一度、ざっと全体を確認してみましょう。

ここで出来上がった内容は、全て、プロジェクトの始まる前に描いた青写真です。全てが全て、予定通りに進められる訳ではありませんし、想定外のこともたくさん発生するでしょう。

そこで、

• 絶対に回避しなければならないリスク
• 致命的ではないが、常に意識しなければならないリスク
• 問題が発生した段階で対処すれば良いリスク

を色付けして、優先順位をつけてみてください。
今後、チームビルディングの具体的な施策を行う段階で、きっと役に立つことになるでしょう。

ここまで、チームビルディングを行うための下準備をご紹介してきました。
後編では、実際にチームビルディングを行う際の方法についてご紹介します！
ぜひ公開をお待ちください！

また、サービシンクへのWeb制作・システム開発に関するご相談は、お問い合わせフォームよりお気軽にご連絡ください。