IT企業におけるエンジニアを中心とした(PLなども含む)のチーム運用としてちょっといいものを思いついた気がするので書き記しておきます。
前提
後述するチーム運用については関係ない前提ですが、クラスター運用についての企業的な前提を挙げておきます
- エンジニアだけで2桁人数がいる企業
- 技術方面での企業文化が芽生えてない企業
チーム運用
開発チームに関わる職種としては
- エンジニア
- デザイナー
- PL/PM/ディレクター
など様々ありますが、開発の中心となるエンジニアに着目して考えていきます。
チームの最少人数
チームを組むうえでチームとして成り立つ最少人数を決めておいた方がいいでしょう。
自分は「少なくとも3人以上」と定義しておきます。
なぜ3人は必要なのか？という点ですが、これは近年のエンジニアの労働市場の売り手有利が遠回しの理由です。エンジニア売り手市場とチームの最少人数はまったく関係ないことですが、情報量の損失リスクから結び付けることができます。
チーム内のエンジニアが保有する情報量が均等に一定だとして、チーム内のエンジニアが退職した場合の情報量喪失割合を考えます。
| チーム人数 | 1人辞めた場合の損失情報量 | 2人辞めた場合の損失情報量 |
|---|---|---|
| 2人 | 50% | 100% |
| 3人 | 33% | 66% |
| 4人 | 25% | 50% |
(値は小数点切り捨て)
同時に3人以上辞めることはまずないので、2人までを考えます。
均等に情報量を割り振ってることによって人数の大きいチームであればあるほど、1人辞めるあたりの情報量喪失割合は少ないというのは、ごくわかりきったことでしょう。ここで注目すべきは2人チームは致命的にリスクが高過ぎるという点です。1人辞めるだけで50%の情報量喪失がありえるならば、チームとして成り立たせることは難しいでしょう。また2人なら同時に辞めることも考えられます。
そこで少なくとも3人以上という条件を導き出すことができるのです。
開発体制
担当する案件の規模によってエンジニアチームは様々な体制にすることを検討しましょう
- 大規模案件の場合: チーム全員を投入する、あるいは他チームと合同で開発する
- 小規模案件の場合: 1人を開発に回し1人は他の開発へ、残った1人はそれぞれのコードレビューをする
どうしても小規模案件の場合チーム全員を関わらせるのは難しいですが、少なくともコードレビューなどを含めて2人が関われるようにしておく必要があると考えます。(情報量・教育のために)
これは他の職種チームにも適用できると思いますが、自分はエンジニア職なので詳しいことはわかりません；；
チームの集合体
前々項でチームの最少人数は3人以上と定めたので、エンジニア3人チームを用意するとします。
しかし、当たり前ですが、エンジニアだけでは開発は行えません。他の職種のチームが必要になってきます。そこで、他の職種のチームも同じ最少人数条件で用意していくことにしましょう。
- エンジニア3人チーム
- デザイナー3人チーム
- PL/PM/ディレクター3人チーム
これが1つの開発の集合体となるわけです。この基本陣形を崩さずに、エンジニアチームを増強(追加)するなりデザイナーチームを増強(追加)するなりして、1つの開発の集合体を成り立たせていきましょう。
なぜ各職種チームも最少人数制限を課すか
デザイナーチームに関してはエンジニアと同じように情報量喪失の観点から最少人数制限を設けれますが、数こそ稀少なPL/PM/ディレクターチームにも付けるのはもう一歩先の考えもあります。
企業における教育体制は2種類あると考えています。1つ目は新人研修、2つ目は幹部研修。エンジニア・デザイナーチームに関しては3人以上のチームを組むことによってOJTのようにチーム内から学ぶことができます。
ここで、PL/PM/ディレクターチームを最小運用単位(1人とか2人とか)にすることで、新人研修の必要はないにしても、幹部研修、つまり将来の幹部候補育成という機会が喪失してしまいます。それを避けるべく無理にでも3人以上の単位にして、他チームの規模を調節してチームの集合体を成り立たせていったほうがいいと考えています。
クラスター運用
前提を挙げてから長々とチーム運用について書いてきましたが、ここからもうちょっと発展した運用方法を書いていきます。(というかこれをおもいついたので記事に書いている)
もう一度挙げますが
- エンジニアだけで2桁人数がいる企業
- 技術方面での企業文化が芽生えてない企業
前提はこのような感じです。エンジニアが2桁必要な感じに思えますが、エンジニアじゃなくてもいいです()
開発部隊としてある程度の規模があるという前提となります。
企業文化という側面
話が逸れますが、企業における文化はどういった表現をすることができるでしょうか。自分が考えるなりに以下があります。
- 企業の強み
- 企業方針
- 一致団結
まぁ、言葉はたやすいですが、文化というのはある程度の効果があると思います。そこで前提に上げている文化がない企業だとどうなるかです。
各々の社員が違う方向に頑張っていたら、それを合わせた合成ベクトルは図のようになります。しかし、本来進まなければならない方向が45°の角度だとすると、各々の頑張りの一部は関係ない方向へ突き進んだだけで無駄となってしまいます。
言ってしまえばまとまりのない企業ほど、各々違う方向に頑張って、アウトプットされる企業としての強み(さまざまな指標)がそれぞれの指標において微小となってしまいかねないです。
そのため、企業としては技術力を磨くだったりデザインを極めるだったりある種の方向性を用意し、それを文化として芽生えさせるものかと思いますが、それが芽生えていない企業で、もはや文化として成り立たせるには成熟しすぎた(規模が大きくなりすぎた)企業で、どうやって方向性をまとめるかを考える際に、ここで提唱するクラスター運用が有効ではないかなと思います。
クラスター構成
自分にとって身近な存在で説明します。
エンジニアが12人いるとして、それぞれ重要視していることが違うものとします。(そもそも同じだったらそれはすでに文化として芽生えてる)
その中から重要視する要素を挙げます。たとえば
- 新しい技術に挑戦する
- アーキテクチャー・デザインパターンを極める
- 生産性を向上させる
といった風にチームとして分けれる最大数までの要素を挙げます。その中から各々が一番重点している要素ごとにわけ、それをチームとして組織しましょう。(ここで、重要視してる要素の定員に満たないことがあるかもしれませんが、それは要素を諦めるか妥協して違う重要視要素のチームに入ってもらうか調整しましょう)
このチームをクラスターチームとします。
クラスター運用の利点
クラスター運用の利点は、各々の頑張る方向をクラスターチームとしてまとめるという点です。これは企業方針として大きくまとまった企業にはかないませんが、それと同様な効果がミクロ単位で期待できます。
たとえばですが、先ほどの例で挙げるならば、新しい技術に挑戦することを重要視しているエンジニアと生産性を向上させることを重要視してるエンジニアは同じチームで組織するのは相性がよくないと言えます。新しい技術に挑戦することによって生産性が上がることがあるかもしれませんが、生産性を上がる要因はそれだけではありません。場合によっては既存技術の使いまわしによって生産性を向上させることもあります。そのような相容れない重要視要素を持つエンジニア同士で開発チームを回すのは、それぞれの強みを台無しにしています。
すべての重要視要素をクラスターチームとしてまとめ上げることができないかもしれませんが、大枠でまとめあげることができれば、それぞれの要素の強みの恩恵を得ることもできるでしょう。
おわりに
かなりマネジメント寄りなチーム運用・クラスター運用を書いていきましたが、重要なことを申し上げる必要があります。自分はマネジメントしたことのないエンジニアなので考え方としてあってるかは不明です()
いろいろと考える機会があって、ちょうどいい机上の空論を思いついたのでアウトプットしてるだけで、実践してうまくいったとかではないです。なので、これを実践してうまくいったとか失敗したとかあればコメントなりなんなり頂けると机上の空論が進化するかもしれないです。
ちなみに
ちなみにですが、最近映画を見て熱がぶり返してきてる幼女戦記では魔導士部隊の運用単位は以下のようになってます
- 小隊: 4人
- 中隊: 3小隊 = 12人
- 大隊: 3中隊 = 36人
- 増強大隊: 4中隊 = 48人
最小単位が4人となってますが、小隊 = チーム, 中隊 = チームの集合体と捉えて、それらの組み合わせで戦場(案件)で戦っていけばいいんじゃないかなーーーと(ただのこじ付けですが)思ったり思わなかったり
大隊を場合によっては増強して運用していくというのは、チーム運用の面で参考になる部分があったりするんじゃないかなと思ったりするところで、このチーム運用・クラスター運用の話は終わりにしようと思います。
あ、クラスター運用とかクラスターチームとかいう名前はてきとーにでっち上げた考えた名前ですので深い意味はないです。
