「安定したチーム作りと機能不全なチームの対処」でレポートしたように、組織は安定したチームを構築、育成することを望んでいる。だが時として、チーム内あるいはチーム群の構成を変える必要がある。チーム構成を変更する必要があるとき、どのように実施すればよいのだろうか？
Pawel Brodzinski氏は「teams」というブログ記事で、なぜチーム作りに時間がかかるのか、チーム構成を変えるときにどんな影響があるのかを説明している。
「Forming, Storming, Norming, Performing」として知られているTuckman氏のグループ開発モデルは、パフォーマンスが満足できるレベルになるまで、時として苦痛なステージを経験する必要があることを私たちに教えてくれます。(…) チームの再構築は常に大きなリスクとして扱われ、通常、その過程でパフォーマンスは悪化するものです。
Pawel氏はチーム構成を変える理由について、新メンバーを迎えることでチームを新鮮に保つため、そして、うまくいっていないチームを救うため、の2つを挙げている。Pawel氏が言っているように、こうした理由でチーム構成を変えるときには注意が必要だ。
チームに参加している全員が新鮮な血をもたらします。新メンバーの経験、知識、観点を利用して、これまでのやり方を疑うチャンスなのです。(…) 時々、チームに新しい人を追加した方がよいのは、このためです。でも、チームを水増ししすぎて、優れたチームを新メンバーの負荷であふれさせてしまうと、最初からやり直しになることを覚えておきましょう。結局、チームをすぐに解散して、再び作り直すことになります。
ハイレベルな組織観点から、短期的に見れば、トップクラスのチームを守ることに価値があるでしょう。ところが、長期的に見ると、そのカルチャーを他のチームに展開する方が良いでしょう。ただし、繰り返しになりますが、ロックスターチームをすぐに解散してメンバーを組織内に展開する前に、思い出してください。チームをすぐに変えることは魔法ではなく触媒のようなものです。ベストプラクティスや健全なカルチャーを社内に展開することは、役立つかもしれないし、役立たないかもしれません。少しずつ適用していきましょう。さもないと、コストに見合うほどのメリットは得られません。
Edwin Dando氏は「Does your agile team have a bad apple」というブログ記事で、たった一人の不作法なチームメンバーがいかにチーム全体を機能不全に陥らせ、破滅へと導くかについて説明している。彼の意見は、Will Felps氏、Terence R. Mitchell氏、Eliza Byington氏によるネガティブなグループメンバーと機能不全のグループに関する研究結果に基づいている。:
チームに腐ったリンゴが含まれていると、他のメンバーまで腐ったリンゴの性質を帯びてきます。チームに憂鬱な悲観論者（depressive pessimist）、わがままな人（jerk）、なまけ者（slacker）のいずれかで振る舞う人がいたとき、他のチームメンバーも同じように振る舞いました。それがわがままな人だと、他のチームメンバーもわがままに振る舞うようになります。それがなまけ者だと、周りもなまけ始めるのです。
悪いことに、チームメンバーはそういう人に対して、このような振る舞いをするわけではありません。彼らは他のチームメンバーに対して、このような振る舞いをするのです。言い換えると、ある人の悪い振る舞いは、さざ波のようにチーム全体の振る舞いへと伝播するのです。
これは極めて重要な発見です。たった1つの腐ったリンゴが、チーム全員の振る舞いを変えてしまい、チーム全体を腐らせてしまうのです。
この結果に従うと、チームに腐ったリンゴがあるときには対策を講じる必要がある。
こうした振る舞いを大目に見ることはできません。それはチーム全体を破滅させ、プロダクト全体にはね返ってきます。これを許してはいけません。結局のところ、取り得る選択肢は3つしかありません。
- 何もしない – 我慢します。明らかに、よい選択肢とは言えません。
- 予防措置を講じる – チームとして、どんな振る舞いがチームを強くし、お互いに何を期待しているのか、定義して合意します。 (…)
- チームのために、彼らをチームから排除する。難しい？ そうですね – これは非常に難しいことで、これが簡単だという人はいませんでした。 (…)
Len Lagestee氏は「It Only Takes One (Handling a Bad Team Member)」というブログ記事を書いている。そこで彼は、誰かをチームから外したり動かす必要があるときにできること、を提案している。
価値と原則を定義して伝えましょう。 (…) 価値とはあなたの判断を導くものです。
準備しましょう。アジャイル環境で仕事をするために期待している文化的で協調的な性質について、人事部に説明しましょう。 (…)
計画を立てましょう。最初の問題が判明したとき、個人のコーチングが始めやすくなります。 (…)
機会を与えましょう。根付いた価値、人材、そして計画ができたら、それらを変更する機会を与えましょう。それらを改善する機会を与える時間をタイムボックス化するのです。
対策を講じましょう。タイムボックスの終わりになって問題が残っていれば、それを明確にしましょう。うまくいっているか全員で見回すのです。
Vin D’Amico氏は「Don’t Let Your Team Become Complacent and Predictable」というブログ記事を書いている。そこで彼は、新しいチームメンバーを迎えることでチーム構成を変える理由についてこう述べた。
新メンバーをチームに迎えることは、新しいアイデアを生み、イノベーションを促します。新メンバーはチームに新しい経験、新しい観点、新しいエネルギーをもたらします。新人は定着した考えや過去の判断に束縛されません。彼らは自由に、すべてに疑問を持ち、何も受け入れないことができるのです。
チーム構成の変更について、彼はいくつか提案している。
- もし会社に複数のソフトウェア開発チームがあるなら、チーム間で人を動かしてみよう。
- もし会社が小さければ、複数領域にわたるスキルを養えるよう、チームメンバーの責務をローテーションしてみよう。
- 業界外から様々なバックグラウンドを持った人を新しく雇い入れよう。
- 技術者でない人をアナリストやテスターとして開発チームに入れよう。
- 時々みんなを現場に出して、実際のユーザがどのように仕事をしているか観察させよう。
あなたはチーム構成を変えたことがあるだろうか？