ブログ

日々採用や組織がうまく動くように苦労しているみなさんこんにちは。@ryuzeeです。

ひとりで色々な物事を完結できればこんな楽なことはないのですが、特にシステム開発においてそのような規模のものは多くなく、たいていの場合複数人を集めてプロジェクトを遂行することになります。特に案件ベースで体制を作るシステムインテグレーターなんかを思い浮かべて頂くとわかりやすいかもしれません。

さて、そうやって集められた「人たち」はいきなりうまく機能して、プロジェクトのゴールに邁進できるようになるのでしょうか？というと残念ながら答えはノーです。 以下の図は、心理学者のタックマンが提唱する「タックマンモデル」と呼ばれるチーム(集団)の進化形態をあらわしたものです。

これによると、チームは以下のようなステップを経て変遷していきます。

形成期

とりあえず人が集められた段階でお互いのことを知らない。なぜ集められたのか、自分に期待されることは何なのか、自分がどう貢献すればよいのか、どう振る舞えばよいのかがはっきりとは分かっていない段階。お互いに遠慮があったり、なにかするのに緊張したりすることも多い。また表面的にたくさん会話がなされていても裏では腹の探り合いをしているかもしれない。この段階ではチームというより単なる集団。ゴールもよく分からない段階で誰が何をできるのかもよく分からないが、何か作業をしないといけないという思いはあるのでめいめいに「たぶん必要になりそう」な仕事をする。プロジェクトの初期にふりかえりがお葬式化している場合や、人の意見に何も言わない(警戒している)場合はこのステージであることが多い。形成期から混乱期にかけてはアジャイルなプロジェクトであればインセプションデッキみたいなものを作っておくと良いかもしれない。

混乱期

ゴールや個人の役割・責任、仕事の進め方などをめぐって意見の対立が発生する段階。またそのそも集められた人の中での好き嫌いや、声が大きい人に対する反感、自分が常に少数派であることに対する不満などが渦巻くこともある。このあたりでも「たぶん必要になりそう」な仕事をしている。なお「たぶん必要になりそう」な仕事が無秩序におこなわれた場合にはそれが却って後々足を引っ張るものになる可能性もある。スクラムを採用している場合にスクラムマスターがエンジニアリングの重要そうな部分を抱えていたり他の仕事に時間がとられすぎてて十分にみんなのために時間が使えないとか、ファシリテーションではなく強い指示をしてしまう場合はこの混乱が長く続くことになるかもしれない。 このフェーズをいかに過ごすかがポイントになる。

統一期

ゴールや個人の役割、仕事の進め方などについて一致し、自分たちのやり方が確立する。他人の考え方を理解し感情抜きで議論ができるようになる。 この時期だとファシリテーターが指示をしたり誘導したりしなくても、ある程度自分たちで意見を統一したりできるようにはなって来ますが、一方でちょっと目を離すと逆戻りしていくということもありえる。スクラムのイベントが賑やかな感じになってくればおおよそこの段階。

機能期

チームに一体感がある一方で個人に自立性があり、チームとしてよく機能する段階。ムダな活動が減り、お互いが責任を持ちつつ協力しあう。自分たちで自分たちのやり方をもっと良くしていくといった力が働き人が集まったことによる効果が発揮できる。スクラムマスターがスクラムイベントを仕切らなくても各メンバーが持ち回りで進められる。昔支援したチーム(定期的に訪問してた)だと、行ってみたらカンバンのデザインやレイアウトが変わってたりプロダクトバックログの書き方を変えてたり、新しいメトリクスを取り始めたりみたいなのがよく見られた。

解散期

当初集められた目標を達成したりプロジェクトが終了することによってチームが解散する段階。せっかくうまくいくようになったのにすごいもったいない…

雑多な所感

上で書いたことも含まれますが、このモデルを踏まえて考えておくと良いと思う箇所を列挙しておきます。

• 人を集めたらすぐなんとかなると考える方がおかしい(別に青い銀行の話はしていません)
• ステージが前半であるほどスクラムマスターやファシリテーターといった支援者が必要になることが多い
• この傾向は大きな会社でいきなり集められた集団だったり、複数のパートナー企業から派遣で来てもらうといったケースで顕著。企業文化や組織文化が集団の機能度合いに及ぼす影響は大きい
• スタートアップやサービス系で大きくない企業の場合、知らない人だらけというケースは少ないので、上のケースほどシビアではないかもしれないが、成長中の企業でエンジニアをどんどん増やしているステージだと、あるタイミングからいきなり雰囲気がおかしくなり始めるといったこともある。マネジメント層はそのあたりを考慮すること
• チームビルディングという名のもとに初期の段階で飲み会をする、というのも良く聞くが、個人的には飲み会でチームビルディングできるとはまったく思っていない(そもそもチームビルディングという単語自体も好きじゃない)
• スクラムの場合はチームをうまく機能させるためにスクラムマスターがいるので、必ずしも技術的に一番優秀な人・役職が上の人がスクラムマスターをやればいいという話ではない。むしろあれもこれもやらなきゃいけない、他のプロジェクトもかかわらなきゃいけない等優先順位の付け方・時間の確保の仕方が難しいので、チームの成熟に時間がかかってしまう可能性がある
• チームに途中から人を足すのはこのステップからも分かるように結構大変。これは遅れたプロジェクトに人を足すと更に遅れるという話と根は同じ
• 稼働率みたいな見た目の数字に捕らわれてチームを頻繁に解体したりくっつけたりすると、その分のオーバーヘッドがあるので却って損をする可能性もある。よいチームはすぐには作れない
• 形成期や混乱期にリモートワークを多用すると機能期に至るまでに時間がかかることがある

それでは。