スティーブ・マコネル（Steve McConnell）の著書『More Effective Agile』の第6章で、「ベルビンのチームロール理論」なるものが紹介されている。そこに、「Plant」や「Shaper」「Resource Investigator」など、聞き慣れない9つのロール名が並ぶ。チーム内でこれらのロールのバランスが取れていることと、チームのパフォーマンスの間には、高い相関があるそうだ。
そう言われると興味を持つ。ベルビンチームロールとはどのようなものだろうか。しかし残念なことに、同書からはほとんど情報を得られない。書かれているのは、先の9つのロールそれぞれに関する短い説明文と、次の引用にある記述ぐらいだ。
この理論では、チームにおいて人々がどのように行動するか、人々がどれくらい協力して作業を行うと考えられるか、そして各役割の候補者をどのように選択するかを評価する。
2020年に日本語版が発売された同書を読んでから気になりつつも、調べることを後回しにしているうちにすっかり忘れてしまっていた。それが最近、「チームワーク」について色々と調べているうちに再びこのキーワードに出会い、思い出した。
ベルビンチームロール（Belbin Team Roles）は、チーム内での個人の行動特性をクラスタリングしたものだ。その9つのクラスターを、チームのパフォーマンスに効果的に貢献する「チームロール」として定義している。ソフトウェアプロダクトの開発チームで私たちが普段扱うロールと言えば、「スクラムマスター」や「テックリード」「アーキテクト」のように、チーム内での機能によるものだろう。ベルビンチームロールはそれとは違うようだ。
優れたチームワークを実現するには、チームメンバーそれぞれのソフトスキルやパーソナリティを活かした貢献も評価すべきだと、私は常々考えていた。それは実体験からだ。ソフトウェアプロダクトの開発と運用を小さな安定したチームで継続し続けていて気づいたことが、「チームが機能するかどうかは、メンバー個々の技術スキルの高さだけが決定要因ではない」ということだった。メンバーが互いを補い合っていると言えば良いのだろうか。それぞれの個性を活かしてチームに貢献していた。
ジェフ・サザーランド（Jeff Sutherland）の著書『スクラム』に、次のような一文がある。
チームが一つにまとまりシンクロし始めると、魔法にかかったようになる。チームがいる部屋に一歩入ればそれを感じる。チームが仕事に取り掛かると見えてくる。スムーズに流れるような動き。チームが一つになることで、個々の集まりを超えた境地に到達した状態だ。
私が体験したことはまさにこれだった。このような高いチームワークに再現性を持たせるためにベルビンチームロールは使えるかもしれない。本稿では、ベルビンチームロールを中心に、チームワークについて考えてみたい。
天才神話
チームワークについて考える前に、まず個人に焦点を当ててみる。
先述の書籍『スクラム』では、エール大学のプログラミング授業で出された課題に関する統計について記載がある。そのクラスを取っていたジョエル・スポルスキ（Joel Spolsky）による調査結果では、もっとも速く課題を仕上げた学生は、一番長く時間をかけた学生の10分の1の時間で終わらせていた。これは確か、ジョエル・スポルスキ自身の著書にも書かれていたように記憶している（現在、手元に本が無いので確認できないが）。
書籍『ピープルウエア』には、著者のトム・デマルコ（Tom DeMarco）らが1984年から1986年にかけて行ったプログラミングコンテストに関する記述がある。92社、のべ600人以上が参加したこのコンテストのデータを分析することで、プログラマの生産性にはバラツキがあることが明らかとなった。「コンパイル時のエラーを消し、デバッグに入れる状態までの所要時間」について、ある年のデータを見ると、最優秀者は平均より2.1倍速く、また中央値を挟んで上位半分は下位半分より1.9倍優れていた。他の年でも傾向は同様だったようだ。
トム・デマルコはまた、3つの文献（実際には4つのようだが）の調査結果を分析した結果として、次の3つの経験則を得ている。上記の調査結果は、これに見事に当てはまっている。
- 最優秀者の測定値は、最低者の約10倍である。
- 最優秀者の測定値は、平均的プログラマーの約2.5倍である。
- 上位半分の平均測定値は、下位半分の平均の2倍以上である。
ソフトウェアエンジニアである私たちも、このような個人差は調査に基づかなくとも経験的に知っている。そのため、優れたソフトウェアシステムを生み出しているのは優れたソフトウェアエンジニアだ、と信じてしまいがちだ。書籍『Googleのソフトウェアエンジニアリング』では、これを「天才神話」と呼んでいる。
天才神話は、人間としての我々が、チームの成功を単独の人物／リーダーに帰せずずにはいられないという性向なのである。
身近に優秀なエンジニアがいれば分かると思う。「困難な障害が起きても迅速にシステムを復旧させ、根本的な原因を特定してしまう」「誰も解決できなかったシステムのパフォーマンス問題を粘り強く調査と実験を繰り返して解決してしまう」「皆に先行して設計と実装を進め、どのように開発すれば良いかチームを導く」「技術的な疑問に何だって答えてくれる」など。しかも、これは色んなタイプの天才ではなく、たった1人でこれだけの活躍をしてしまったりするのだ。そんなスーパーエンジニアがチームにいれば、そのたった1人がチームを成功に導いているような錯覚にチームメンバーは陥ってしまうのも仕方がない。
だが違う。同書の言葉を借りれば、「ソフトウェアエンジニアリングとはチームによる取り組み」なのだ。書籍『スクラム』によれば、約3,800のプロジェクトを分析した調査で、1番能力の高いチームが1週間でできた仕事を、1番能力の低いチームは2,000週間かかったと言う。つまりチームのパフォーマンスに2,000倍の開きがあったと言う。この結果はさすがに大きな外れ値に起因するのではないかと感じてしまうが、個人間でのパフォーマンス差の大きさより、チーム間でのパフォーマンス差の方がより大きく、そこにこそ注目すべきだとジェフ・サザーランドは言っているのだ。
※蛇足だが、ソフトウェアエンジニアリングにおける個人の能力は、単純にプログラミングの速さや欠陥の少なさだけでは計測できないと、私は考えている。これについては『Googleのソフトウェアエンジニアリング』でも言及されている「プログラミングとソフトウェアエンジニアリングの3つの違い」と同じ話である。例えばその1つである「時間」としては、「ソフトウェアを保守性のある状態に長期間保つ」という観点となる。書籍『Clean Architecture』でロバート・マーチン（Robert C. Martin）の言うところの「ソフトウェアをソフトに保つ」ということだ。プログラミングコンテストやプログラミング課題に関する調査結果では、この点は評価されていない。
アポロシンドローム
それでは、「天才的な人材ばかりを集めてチームを組めば成功が約束されるのだろうか」という疑問が湧く。ベルビンチームロールの生みの親であるメルディス・ベルビン（R. Merdith Belbin）は、まさにそれを実験していた。参加者が複数のチームに別れて経営手腕を競い合うゲームを実施するにあたり、そのうち1チームは、事前に行われた個人向けの知能テストで高得点であったメンバーのみで構成するようにしたのだ。そして、このチームを「アポロ」と命名した。
もちろん、アポロチームが好成績を収めることが予想されたわけだが、そうはならなかった。最下位となったのだ。その後、数年に渡り同様の実験が繰り返されたが、いずれのアポロチームも結果は散々だった。アポロとして編成された25のチームのうち、優勝したのは3チームのみで、8位以下がほとんどだった。この様子は、メルディス・ベルビンの著書『Management Teams』の2章に詳しく書かれている。
アポロチームの問題は、基本的にチームワークの悪さだ。本来、優秀であるはずの彼らの強みである競争心の強さや、クリティカルシンキングによる分析力・反証力の高さが裏目に出て、チームとしての協働を阻害してしまうのだ。これを「アポロシンドローム（Apollo syndrome）」と呼ぶ。
メルディス・ベルビンは、責任ある立場に知能面での優秀さが特に求められる産業領域として、コンピュータの応用分野と研究開発分野を挙げている。顧客企業にコンピュータシステムをインストールするチームを対象にした調査では、大半が高いクリティカルシンカーであることが分かった。特に、チームの中で最も賢く創造的なメンバーがプロジェクトマネージャーであった場合に、プロジェクトは最も失敗しやすくなるようだ。しかし、よりマネジメント能力に優れ、創造性に劣るメンバーがプロジェクトのリーダーを務めるようにしたところ、チームの技術力や想像力を損なわずに、有効性を高められた。
つまり、個人の優秀さのみにフォーカスした編成では、チームが上手く機能しないということだろう。
ベルビンチームロール
ソフトウェアプロダクト開発に関する書籍で、チーム編成に関する記述を読んでいて感じるのは、チーム内での役割が、プロセスに直接関連するような機能のみに焦点があてられて定義されていることだ。確かに、開発プロセスやプロジェクトを遂行するという観点ではそういった話題は必要だ。だが、成功するチームを作り上げるには、個々のパーソナリティやソフトスキルから生じる行動特性にも目を向ける必要がある。
メルディス・ベルビンによって定義された9つのチームロールを簡単にまとめたものが次のリストとなる。パーソナリティやソフトスキルに基づいた分類であることがよく分かる。
- Plant(PL) - 非常に創造的であり、斬新なアイデアで問題を解決することを得意とする。
- Monitor Evaluator(ME) - 偏見を持たず、ものごとを論理的に観察・判断することに長けているため、あらゆる選択肢を公平に評価できる。
- Specialist(SP) - 特定の領域・分野に関する深い知識や高いスキルでチームに貢献する。
- Shaper(SH) - 目標達成に向けて精力的に突き進む。チームが常に動き続け、集中力や勢いを失わないようにするための原動力となる。
- Implementer(IMP) - アイデアを実行可能で効率的な計画に落とし込み、行動に移す。
- Completer Finisher(CF) - 間違いが無いかをチェックし、納得がいくまで仕上げようとする完璧主義者であり、高品質を追求する。
- Co-ordinator(CO) - 多くの場合でチームリーダーであり、目標を明確化してチームをその達成に集中させる。
- Teamworker(TW) - チームの潤滑油的存在であり、外向的で、メンバーが互いに理解し合えるようサポートすることに長けている。
- Resource Investigator(RI) - 外交的で好奇心旺盛であり、外部から情報を収集し、チームにアイデアを持ち帰る。
1人のチームメンバーが、このどれか1つのチームロールのみに該当するということではない。多くの場合、支配的なチームロールを1つ持ち、副次的なチームロールを2つから3つほど持っている。前者を特に「プライマリチームロール（primary Team Role）」と呼び、後者を「バックアップチームロール（back-up Team Role）」と呼ぶ。メンバーがどのチームロールに該当するかを判別するには専用の質問に回答する必要があるが、自身も含めチームの誰がどれに当てはまりそうか、何となくイメージはできるだろう。
エンジニアになる学生を対象とした調査
『More Effective Agile』内で、ベルビンチームロールに関して参考文献として挙げられているのは、"Optimal selection of team members according to Belbin’s theory" という論文だ。この論文はメルディス・ベルビン本人によるものではないが、エンジニアになる学生を対象とした調査である点が良い。
調査対象となった学生24名は、AからFまでの6つのプロジェクトチームに4名ずつが所属していた。アンケート回答をもとにした彼らの判定結果は次の表の通りとなる（論文中のTable 3を加工）。チームロールの略称が前述のものとは少々異なる。これについては後述する。
列Membersの M や F は、男性か女性かを表している。
列CWからCOまではチームロールを表しているが、ここでは9つではなく8つしかない。それは、学生らがそもそもSpecialistに該当する人物像であったためで、これを除く8つのチームロールのみを扱ったようだ。CWとはCompany Workerであるが、これは上述のImplementer(IMP)のことであり、またCHはChairmanで、これはCo-ordinator(CO)の旧名だ。最後のCOは、Completer Finisher(CF)を指す。この8つのチームロールごとに数値が記載されており、数値が大きいほどそのチームロールに対する強度が高いことを表している。
また、チームロール強度は Very high から Very low まで5段階で評価されており、表内ではそれぞれ次のように表現されている。チームロール強度の値がどのランクに該当するかは、チームロールや性別によって異なる（論文内のTable 2を参照）。
Very high- 太字/下線/白背景High- 太字/白背景Medium- 白背景Low- 薄い灰色背景Very low- 濃い灰色背景
列Gradeは、プロジェクトに対する最終評価結果を表す。3.0未満は、ネガティブな評価である。
注目すべきは、2.0 という最低のGradeとなったチームBだろう。全チームで唯一、ネガティブな評価となっている。彼らには、最高強度が Low となったチームロールがあるうえに、最高強度が Very high となったチームロールがひとつも無い。それに対して、他のチームはいずれも全てのチームロールが Medium 以上であり、Very high と評価されたチームロールを2つ以上含んでいる。
もう少し詳細に見ると、チームBで Low だったチームロールは、Completer Finisherだ。書籍『Management Teams』によれば、Completer Finisherの欠如は、「目標に手が届きそうなのに、最後の最後で挫折してしまう原因」となる。チームBには「やり抜く力」や「細部へのこだわり」が弱かったのだ。
それに加え、チームBは、Very high の強度を持つCo-ordinatorがいない唯一のチームでもあった。そのために、チーム内でのリーダーシップが弱く、「目標を明確化してチームをその達成に集中させる」ことができなかったのだと考えられる。逆に、High のCo-ordinatorが3名も存在したことによって、チームとして目指すべき方向が統一できなかったのかもしれない。
チームビルディング
ベルビンチームロールの特徴は、なんと言ってもチームに焦点をあてているという点だろう。個人のみに焦点をあてた自己分析・他己分析ツールとはそこが違う。チームにおいて個人がどう効果的に貢献するのかをロールが表現している。したがって、メンバーのチームロールを診断しても、それをチーム設計やチームビルディングに役立てなければ意味がない。
メルディス・ベルビンは成功するチームとして4つのタイプを挙げている。その中でも実験を通じて最も成功したタイプが「混合チーム（classic mixed team）」だと述べている。特定のチームロールに偏った編成ではなく、チームが多くのロールをカバーし、それぞれのロールが明確に区別され、メンバー間でのロールの重複が少ないチームのことだ。
チームワークとチームパフォーマンスを高めるなら、混合チームの実現を念頭にチームを編成するのが良さそうだ。しかし多くの場合において、必要なチームロールを初めからすべて揃えられるほど人材は潤沢ではないだろう。その制約を受け入れた上で、バランスの取れたチームを作り上げていくしかない。
チームビルディングのプロセスは、概ね次のような流れになるだろう。前提として、新規で編成するチームではなく、既存のチームを想定したものとなっている。
(1) チームの現状を把握する - チームメンバー全員が診断を受け、一人ひとりのプライマリチームロールとバックアップチームロールが何であるかを明らかにする。それらをチーム全体で表にまとめ、チームにどのようなチームロールが揃っているのか、何が欠けているのかを可視化し、チームで共有する。
(2) チームをデザインする - チームによって、より優先的に求められる特性が異なる。クリエイティブなことが求められるチームなのか、より正確性や安全性が求められるチームなのか。そういった特性によって、優先的に必要となるチームロールやその強度も異なり、チームロールのバランスも変わるだろう。チームロールをできるだけ広くカバーすることを意識しつつ、チームが担うプロダクトやプロジェクトの特性に合わせてバランスの取れたチームをデザインする。
(3) チームを実装する - (2)でデザインしたチームのあるべき姿と、(1)で明らかにしたチームの現状を比較する。そのうえで、チームデザイン上必要とされたチームロールそれぞれに対し、メンバーのプライマリロールを参考にひとりずつアサインする。ひとつのチームロールに対し、それをプライマリチームロールに持つメンバーが複数人存在する場合、誰がそのチームロールを担うのかを取り決めることで重複を排除する。逆に、必要なチームロールであるが、それをプライマリチームロールに持つメンバーが存在しない場合、各メンバーのバックアップロールを用いてバランスを試みる。1人が複数のチームロールを担うことは問題ない。このように一人ひとりのメンバーが、チームにとっていずれのチームロールとしての行動が求められているのかを明確にしておく。それがピグマリオン効果（ローゼンタール効果）を生み、自らがアサインされたチームロールに対し、よりふさわしい振る舞いを取るようになることが期待できる。なお、ここで決めたチーム編成は、図や表に記録しておく。
(4) チームを稼働させる - (3)で決定したチーム編成を前提に、チームとしてソフトウェアプロダクト開発を続ける。
(5) チームを評価する - 数イテレーション、あるいは数か月ごとに、チームでの振り返りを行う。(3)での実装はうまく機能したか、(2)のデザインは正しかったのかを評価し、問題や課題を明らかにする。そのうえで、(2)あるいは(3)に戻る。
このように、(2)から(5)を繰り返すことで、フィードバックサイクルを回しながらチームのパフォーマンスを高めていくことになるだろう。もちろん、定期的に(1)に立ち戻るのも良い。チームでの経験を積んでいくことで、メンバーそれぞれのプライマリチームロール/バックアップチームロールの組み合わせに変化が起きることもあり得るからだ。
先の論文 "Optimal selection of team members according to Belbin’s theory" 内で、混合チームとしてのスコアを算出する方法が提案されている。ごくシンプルなものであり、カバーするチームロールの数とその強さの加重合計となっている。チームAからFまでのスコアとGradeとの相関も0.87と高い。まだまだ検証が不十分な算出法であると思うが、これを利用してみるのも良いだろう。なお、論文内の実験で考慮されていないSpecialistの扱いをどうするかの検討が必要となる。
選択的同質性からの脱却
マネージャーや企業には、同質性の高い組織を形成しようとする傾向があるのではないだろうか。自身と似た人材や、既存の組織文化との親和性の高い人材を採用し、育てようとする傾向があるということだ。メルディス・ベルビンはこれを「選択的同質性の原則（principle of elective homogeneity）」や「クローン文化」と呼んでいる。それが必ずしも悪いとは言わないが、そのように形成された組織には問題もある。過度な同質性は、選択可能なチームロールを偏らせてしまうからだ。あまりに均一で同質性の高い組織では、最も成功率が高いとされる混合チームのようなチーム編成の実現が難しくなってしまう。
ソフトウェアエンジニアリングは、チームによる取り組みだ。たった1人の突出した能力だけで大きな成功を得ることは難しい。チームによる成功の大きさは個人による成功に勝る。開発チームが高いチームワークをもって、より優れたパフォーマンスを発揮するためには、チームに多様な個性を混合させる必要がある。スーパーエンジニアが目立ってしまいがちでも、実際のところその貢献は、多様な個性によって補い合うチームワークによってもたらされている。
無論、チームであっても、ハードスキルの高さはエンジニアの能力に最も重要な要素のひとつであることに変わりがない。しかし、チームをよく観察すると、ハードスキルが並程度であってもその人の振る舞いがチームを上手くまわす潤滑油になっている人がいたりする。チームロールで言えば、Teamworkerがそれにあたる。
こういったエンジニアは、評価されずに埋もれがちになる。チームの中での彼らの行動は、明確に定義されたものではないため、周囲に意識されないのだ。「名もなき家事」という言葉にかけて「名もなきエンジニアリング」とでも言えば良いだろうか。
チームロールは、そこに名前を付けたのだと考えると良い。デザインパターンやプラクティスと同様に、名前が付けば語彙として共有でき、その行動を誰もが認識できるようになる。チームロールによって、エンジニアをハードスキル以外でも評価することが可能になるのだ。そうすれば、同質性の高い組織から脱却しやすくなる。ある意味で多様性のある組織に変貌することにも繋がるのだろう。
