はじめに
ピクスタにて PIXTA を国内で開発している2チームのリーダー/マネージャー業務を行っている tokinaga です。 本記事では、チームの現在と未来を考えていく上で重要な要素の一つであるチーム分割について書こうと思います。
はじめに人数増加に伴うチームの肥大化に対してチーム分割という手段で対処することになる背景を説明します。
その後分割の際に気をつけるべき点をチェックリストという形でまとめます。
最後に、なぜそのチェックリストの項目が重要かを解説します。
チーム分割を行う背景
資本主義社会において、企業は拡大再生産を行います。
ソフトウェア産業においてエンジニアリング組織はビジネスの核となる、いわば生産手段です。 したがってエンジニアリング組織を強化することは設備投資と言えます。
換言すると、ビジネスを加速させるためにはエンジニアリング組織の強化は不可欠ということです。 そしてエンジニアリング組織の強化は、一般的にはチームメンバーの採用と育成によってなされます。
そういうわけで、エンジニアリング組織の人数は一般に増加する傾向にあります。
ではエンジニアリング組織の人数が増加するとどうなるのでしょうか。 当然ですが、チーム一つあたりの人数が増加します。 そして、以下のような問題を引き起こします。
コミュニケーションコストの増大
一対一のコミュニケーションパスは、n人のチームにおいて (n)(n-1)/2 本存在します。すなわち、チームが線形に増加するとコミュニケーションコストは n2 のオーダーで増加していくということになります。
すると、どこかで人数一人増加したときにそのメンバー一人が増えることによる生産性の増加分よりも、コミュニケーションコストの増加分の方が大きい地点が存在するということとなります。
これを防ぐためには、チームの大きさを小さく保つ必要があります。
参考: ブルックスの法則
チームリーダーの負担増
チームリーダーの仕事が何かは組織によって異なるとは思いますが、チームの生産性を高めるため、多かれ少なかれメンバーひとりひとりと向き合っていることと思います(例えば 1on1 を行ったり、コードレビューを行ったり)。
リーダーとして見るメンバーの人数が増加すれば、当然リーダーの負担は増加します。
これを防ぐためには、チームの大きさを小さく保つ必要があります。
分割案のチェックリスト
以下のチェックリストを元に、あなたの考えた分割案が適切に問題を解決するのかを考えてみてください。
- ミッションがあるか
- そのミッションはチームに限定合理的な意思決定をもたらす重力を生み出さないか
- 定常的に仕事が存在するか
- アーキテクチャ、ビジネス境界、チーム境界が一致しているか
- 分割後のチームのチームリーダーを任せられる人物はいるか
- 分割後、メンバー増加に十分耐えうるか
チェックリスト解説
1. ミッションがあるか
ミッションはチームの存在意義です。 「そのチームのミッションは何ですか?」と聞かれたときに即答できなければなりません。
また、そのミッションは会社や事業を考えたときに本当に必要とされているかどうかも踏まえて設定されている必要があります。 場合によっては事業責任者等とのコミュニケーションの上に定めることになるでしょう。
人数の多い状況の問題を回避することのみに意識が向いていると、意外とこういうところが抜けてしまうことがあるので注意が必要です。
2. そのミッションはチームに限定合理的な意思決定をもたらす重力を生み出さないか
チームのメンバーはチームのミッションを達成するために行動します。 そのミッションを達成するためのアクションが全体最適を考えたときのアクションと矛盾するようなものとなってしまう危険性はなるべく減らすことが望ましいです。
例えば、売上 = UU x CVR x 単価
と因数分解し、UU チームと CVR チームと 単価チームに分けたとします。
CVR チームがコンバージョンを高めることだけを考えたら、「販売価格を半額にしよう!」というアイデアが湧いてしまうかもしれません。おそらくそれにより CVR は跳ね上がり CVR チームは目標を達成するでしょう。
一方単価チームは目標を大幅に下回る結果となってしまい、CVR チームに対して敵対心を持つかもしれません。
このように、不適切なチーム分割をしてしまうと限定合理的な行動が促進され、全体最適な意思決定とは程遠い行動を取ってしまう恐れがあるのです。 同じ目標を持ったチームが一丸となってユーザ価値を高めるために邁進できるような分割を行いましょう。
3. 定常的に仕事が存在するか
適切なミッションを設定してチーム分割をしても、仕事が存在しなければミッション達成のために行動することができません。
チーム分割後に仕事が安定的に確保できるかどうかは事前に考えておく必要があります。
4. アーキテクチャ、ビジネス境界、チーム境界が一致しているか
ここでいうビジネス境界とは、ビジネス上の戦略的な課題の境界を意味します。 (ドメイン駆動設計で言うところの境界づけられたコンテキストにあたるものと考えてください)
アーキテクチャとチーム境界は一致していることが望ましいです。また、ビジネス境界とチーム境界も一致していることが望ましいです。
チーム境界が生むコミュニケーションコストの勾配は、重力としてアーキテクチャに影響を与えてしまいます(コンウェイの法則)。 意図せず時間経過により形が変わっていってしまうのは、望ましい振る舞いではありません(それを逆手にとったものが逆コンウェイの法則)。 したがって、アーキテクチャとチーム境界は一致していることが望ましいのです。
ビジネス境界とチーム境界が一致していないというのはそもそも適切なミッションを設定できていないということになるので、これは問題です。
ではアーキテクチャとビジネス境界が一致していない場合はどうすればいいのでしょうか?
中長期的にはこの3つは一致させるのが望ましいですが、短期的にはビジネス境界とチーム境界の一致を優先すべきだと私は考えています。
なぜなら、ビジネス境界でチームが別れてさえいれば、複数チームが同一のアーキテクチャを触る場合でもコミュニケーションコストは抑えられるからです。 またビジネス境界を元にミッションを設定したほうが本質的に解きたい問題に近づくことができます。
一般に、アーキテクチャを変えるのは手間と時間がかかります。アーキテクチャは変えられないが現状の開発組織の肥大化には対応しなければならない、というケースは多く存在するのではないかと思います。 そのようなときにいきなりアーキテクチャからゴッソリと変えて根本解決を目指すのではなく、ひとまずできることからやっていくことをおすすめします。
5. 分割後のチームのチームリーダーを任せられる人物はいるか
チームを分割する際、チームリーダーをどうするかという問題が発生します。
- 新たにチームリーダーを置く
- それまでのチームリーダーが複数チームを見る
前者の場合、候補がいるのかどうかを事前に考えた上で、細心の注意を払ってチーム全体を見ながら任せていきましょう。
後者の場合、チームリーダーの負荷が増加することが考えられますので、注意が必要です。
6. 分割後、メンバー増加に十分耐えうるか
チームの特性上、比較的人を増やしやすいチームもあれば、なかなか人を増やしづらいチームもあります。
例えばスクラム開発を行っているウェブアプリケーションの保守運用チームであれば、比較的容易に人を増やせるでしょう。 これは問題を発見し小さい粒度にブレイクダウンする段階の大部分をプロダクトオーナーが行ってくれるためです。 比較的小さい問題を各メンバーがこなしていくことになるので、リソースが増えればそれだけスループットが増加します。
一方、技術基盤的な役割を担うチームやアルゴリズムの開発を行うチームなどは、人を増やしたからと言って線形にスループットは増加しません。 これは、大きい問題を適切な手順で小さい問題にブレイクダウンしていく過程に多くのコストがかかる一方で、その過程は人を増やしたからといって早く終わるという類のものではないからです。
人数増加への弾力性という観点では、前者はコミュニケーションコストがボトルネックになるケースが多く、後者はリーダーの負荷がボトルネックになるケースが多い印象です。
チームの特性を見極めた上で、分割後の体制がいつまで耐えられるのか、何がボトルネックになるのか、それを踏まえてどのような組織体制にしていくべきなのか、事前に見通しを立てておくべきです。
おわりに
ここまで人数増加に伴うチームの肥大化に対してチーム分割という手段で対処する際に気をつけるべきことを書いてきました。
チェックリストのすべての項目を満たすチーム分割の境界を考え出すのは至難の業です。場合によってはそのような境界は存在しないのかもしれません。
ですが、仮に妥協の上の分割案となるとしても、その分割案がはらむ構造的なリスクは認識した上で舵を切るべきです。
チーム分割は非常に頭と神経を使う難しい仕事ですが、うまく分割をして複数チームを立ち上げることには大きな意味があります。
チーム肥大化に悩むエンジニアリングマネージャの方々が、少しでもこの記事を参考にしてくださったら幸いです。