チームが成熟され続ける仕組み（エンジニアリングマネージャーの取り組み）

## はじめに

新チームを、自律自走するチームへ移行させるテーマで記事を書いていきますが、
一番の肝は **『もしかして、あなたのチームは、新チームなのでは！？』** という点です。
新チーム≒未成熟なチームだとすると、
歴の長いチームだからと言って成熟したチームであるとは限りません。

- 優秀なメンバーが揃っていても、今ひとつスピードが出ない
- 何かとアクシデントが多い
- マネージャーが説明ばかりしている

これらはチームが成熟しておらず、統率が取れていない証拠です。

**・チームが統率されていないことに気がつく**
**・チームが自ら統率された状態をつくる環境構築**
という流れを書いていきます。

## 「新チーム」はぬるっとやってくる

新チームを受け持ったマネージャーのために記事を書いていますが、
チーム・ピープルマネジメントにおいて問題が発生するケースの多くは
「新プロジェクトが発足した」ようなタイミングよりも
**いつのまにか新チームになっていたが、それに気がついていなかった時** だと思っています。

どういうことでしょうか。

チームビルドではお馴染みの「タックマンモデル」を用いて説明します。

<img src="https://cdn-ak.f.st-hatena.com/images/fotolife/t/terapon-chanpon/20211221/20211221185701.jpg" width="700px">

[画像出典 『チームビルディング』タックマンモデル](https://terapon-chanpon.hatenablog.com/entry/2021/12/23/070000)

タックマンモデルとは、心理学者のブルース. W. タックマンが1965年に提唱した、
チームビルディングにおける４つの発展段階です。

『チームが形成されると、5つのステージを経て生産性が徐々に改善していく（一時は低下する）』
という内容なのですが、今回伝えたいポイントは２つです。

**① チームの成熟には、統一を図る努力が必要**
**②「新しいメンバーを迎えたチームは、初期状態である形成期の状態に戻る」** 

図では横軸が時間になっていますが、
時間が経てば勝手に統率が取れるわけではありません。
チーム内で意見を伝え合い、認識をそろえ、
統率をとることで、やっとチームは成熟し成果を出せるようになります。

また、新しいメンバーがチームに加わると
新しいコミュニケーションパスが発生するため、成果を出すためのフローが初期化されます。

それゆえにチームの人数が増減すると、
その人数がたとえ僅かであっても「チーム」という前提条件に大きな影響を与え、
これまでと同じ認識のままでは成果が出せなくなります。

これらを踏まえると、多くのマネージャーが担当しているのは
新チーム（未成熟なチーム）でしょう。

## 新チームは勿体ない

上記のタックマンモデルからも分かる通り
**メンバー個々人の生産性の総和 ≠ チームの生産性** です。

もちろん個々の成長によって、個人の生産性を上げていくことも重要ですが
それと同様かそれ以上に、チームとしての生産性を上げていくことは重要です。

短期間のプロジェクトごとに、チームを解散していると
このチーム生産性を短期間でリセットしてしまうことになります。

組織設計の書籍「チームトポロジー」では次のように表現しています。

> ハイパフォーマンスなチームを解散するのは、単なる破壊行為では済まない。
**企業レベルのサイコパスと呼ぶべきものだ。**
<a href="https://amzn.to/3NWw8nL"><img src="https://m.media-amazon.com/images/I/51HEm7DocNL._SX351_BO1,204,203,200_.jpg" alt="チームトポロジー"  width="200px"></a>

サイコパスだそうです。
とはいえ『 1人でも人が増えたら別チームなんだから、人を増減させるな 』
というのは中期的な視点で無謀です。

ではどうするか。

それは、初期状態に戻ったら素早く次のステップへ成長していくことでしょう。
そのためにもまずは **「初期状態に戻った」という事実を認める**ことが第一歩になります。

## 「新チームだ！」と認識しないと事故る

なぜ初期状態であることを認める必要があるかといえば
そうしないと事故るからです。

- これは"みんな"知っていることだ → 知らない
- "みんな"納得しているハズだ → 納得いっていない
- メンバーは仕事に当事者意識を持ってくれる → これは自分の仕事じゃない

こんな感じで、
ヒューマンエラーからバグにつながったり、
不満が募ったりします。

## 成長中の企業ほど人は流動的になる

せっかくチームが成熟しても、
人の増減によってまた初期状態に戻ってしまう。

しかし、成長中の企業であれば事業拡大にあたって
より多くの人材が必要になり、増員は必須でしょう。

「月に1度は人が入る」というケースも珍しくはありません。

そんな環境でマネージャーは何をすべきことは
成熟度がリセットされても、**自動的に（自発的に）** 成熟していく環境を整えることです。

ここでのポイントは、
マネージャーや、一部の優秀なメンバーの名プレーによって統率を取るのではなく、
チーム自体が自分たちの問題点を見つけ改善していく仕組みを支えることです。

## 自己組織化による統率

「統率を取る」とはつまり、
個々の意見の集合だった状態から、チームとしての共通認識で動ける状態にすることです。

もちろん、トップダウンでリーダーが強い力で号令を掛け、統率を取る方法もあります。
しかし、それは**作業が単純で、すべての業務を指示できるケース**でのみ有効です。

メンバー自身が不確実性を抱えるシステム開発などでは
一人ひとりのメンバーにリーダーが適切な指示をすることはできません。

トップダウンではなく、ボトムアップで統率を取るには
チームが意見を話し合い、認識の違いに気が付き、共通認識を形成し、一丸となる工程が必要です。


チーム自体が
**・誰が**
**・どのように**
**・何をするか**
を決めることができる状態を「自己組織化されたチーム」と表現しますが(※)
自己組織化によって統率をとる、また**チームに変化が起きてもまた統一へ向かい続ける**ことが、
変化の多い組織でチームを成熟させる（させ続ける）方法です。


(※)最近のスクラム開発では、この状態を「自己組織化」ではなく「自己管理」と呼ぶようです。
[出典：スクラムガイド2020](https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf)



## マネージャーのしごと

マネージャーは、リーダーとしてトップダウン的な号令を掛けるのではなく
ファシリテート役に徹するのが良いでしょう。

しかし、チームに強い影響力を持っている、
特にリソース（予算・スケジュール）の決定権を持つ、または関与できる
マネージャーだからこそできる支援もあります。

ポイントは2つです。

**① 改善策は、極力マネージャーではなくメンバーが意思決定する**
**② 小さな改善でも構わないが、確実に実行する**


### ① 改善策は、極力マネージャーではなくメンバーが意思決定する
目的は、自己組織化、そして当事者意識の醸成です。
一方で、限られた組織のリソースの中で
メンバーが真の意味で意思決定を行うことは困難です。
マネージャーはファシリテートをしながら
現実的に選択可能なプランを数パターンサジェストするなどで支援しましょう。
（誘導的になりすぎないように注意）

### ② 小さな改善でも構わないが、確実に実行する
せっかくチームが改善策を立案しても
「いつか、やりましょう」と先延ばしになってばかりいると
**「どんなに改善策を考えてもムダ」とチームは改善することを辞めてしまいます。**

#### 改善の歩みを止めないことはそれ自体が大きな価値

もちろん予算は限られており、
理想的な課題解決プランを実行できることは少ないでしょう。
短期間で大きな成果は期待できないかもしれません。


大きな成果とは、高速で坂を転がる巨大な雪玉のようなものです。
最終的な結果だけを見ると「あんなに大きな質量を、高速で動かすなんて大変だ」と思いますが、
どんな成果も最初は小さな雪玉を、コロコロと転がすところから始まるのです。

自律的な成果の仕組みとは
小さな雪玉をチームメンバーが回し続ける仕組みのことです。


## まとめ

「チームが成熟され続ける仕組み」を要約すると

① 新チームであることを認識する
② チームが自律的に課題を洗い出し、改善策を捻出するルーティンを作る
③ マネージャーとしてリソースを捻出し、改善策を実際に実行する
④ 繰り返す

です。
ハイパフォーマンスなチームを目指して雪玉を転がしていきましょう！