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