チームを安定的に運営できる人数は本当に「2枚のピザ」ルールで収まるのか

前段のお話

私のいるチームは今年度から新しいメンバーが追加され、だんだんと大所帯になってきました。それに合わせてメンター制度を敷いたり、マネジメントをうまくやる必要が出てきました。そこでいくつかのマネジメント本¹を読んでいたのですが、その中でも気になったのは、「マネジメントできるのは理論的には何人までか」です。

チームサイズについて言及されている有名なルールのひとつに「2枚のピザ」ルール²があります。これは、「ひとつのチームは二種類のピザがいきわたる程度にするべきだ」（すなわち5～8人）というルールです。

しかし、教育が必要なメンバーもいれば、目標さえ掲げておけば自走するメンバーもいるし、中にはマネージャーの補佐もできるメンバーもいます。極端なことを言えば、新卒メンバーを7人詰め込むと、指示だしや、教育、振り返りのフィードバックだけで手詰まりしてしまうことは自明です。

そこで、指示だしや教育、振り返りのフィードバックといった対面で行う日々のマネジメント業務に着目し、どこまでマトモにマネジメントできるかについて、指導を受けるまでの待ち時間とマネージャーに残された時間を元に、このルールをゆるふわ検証していきたいと思います。

検証手法

今回の検証には、待ち行列理論を用います³。CSの学位をお持ちの方であれば、大抵の方はご存じかと思いますので、数式など詳しい説明はここではしません。wikiの序文⁴を引用して説明に代えることにします。

待ち行列理論（まちぎょうれつりろん　英語: Queueing Theory）とは、顧客がサービスを受けるために行列に並ぶような確率的に挙動するシステムの混雑現象を数理モデルを用いて解析することを目的とした理論である。応用数学のオペレーションズ・リサーチにおける分野の一つに数えられる。

電話交換機や情報ネットワーク、生産システム、空港や病院などの設計や性能評価に応用される。性能評価指標としては、待ち行列長・待ち時間・スループットなどが用いられる。応用の場では、システムの性能がある設計目標を満たすために必要な設計パラメータを決定する際に、その逆問題を提供できる。

身近な例として、「スーパーでレジに並ぶとき」を想像して頂きますとわかりやすいかもしれません。例えば、お客さんがたくさん並んでいるのにも関わらずレジ打ちのスタッフが一人しかいない。会計が終わるまでぼんやりと立ち尽くすしかない状況を人生で一度は経験されたことがあると思います。こういった顧客がサービスを受けるために行列に並ぶような確率的に挙動するシステムの混雑現象をモデル化するのが待ち行列理論です。

ここで、「レジ」を「マネージャー」、「レジに並ぶお客さん」を「マネジメント業務」と見立ててみると、顧客がサービスを受けるために行列に並ぶような確率的に挙動するシステムの混雑現象とみなすことができます。そこで、この待ち行列理論を使って、今回の検証を行うこととしました。

待ち行列理論は、メンバーの退職や急な参加、突然の炎上などといった混雑状態が変わるイベントから十分に時間が経って、安定的に運用されている状態を対象としています。ですので、安定運営など長期的なスパンでのモデリングに向いています。

待ち行列理論以外に、検証に用いるものとして、機械学習⁵や、最適化⁶も頭に浮かびましたが、今回は不採用としました。

検証に当たっての仮定

今回、待ち行列理論を用いるにあたって、マネジメント業務の発生はポアソン分布に従うものとし、マネジメント業務の処理時間は指数分布に従うものとします。また、業務内容を以下のように数値化し、3つのチーム⁷⁸を考えます。

定義	新人だけのチーム	標準的なチーム	シニアだけのチーム
1回のマネジメント業務の平均時間	20分	15分	10分
1メンバー当たりの平均マネジメント回数	3回/日	2回/日	1回/日
メンバーの数	4-7人	4-7人	4-7人
マネージャーの数	1人	1人	1人

それぞれのチームに対して、M/M/1の待ち行列モデルを仮定します。

何を比較するか

それぞれの待ち行列モデルにおける平均待ち時間を比較することにします。この平均待ち時間は、具体的には指導が欲しくなってから（上記の例で言えば、レジに並んでから）実際に指導を受けられるまで（レジ作業が始まるまで）にかかる時間です。つまり、この時間は、チームメンバーの業務が進んでいない時間と考えられるので、マネジメントが出来ているか図るには良い指標でしょう。

もう一つの指標として、自分の業務に使える時間を採用します。これは誰もマネージャーに指導を仰いでいない時（レジに誰も並んでいない時間）と言い換えることが出来ます。M/M/1モデルで言えば、単純にフィードバックする時間を労働時間から引いた時間となります。

実験結果

新人だけのチーム

部下の人数	指示を待つ時間	自分の業務に使える時間
4人	40分	160分
5人	80分	80分
6人	∞	-
7人	∞	-

標準的なチーム

部下の人数	指示を待つ時間	自分の業務に使える時間
4人	6分	360分
5人	6.8分	330分
6人	9分	300分
7人	11.667分	270分

シニアだけのチーム

部下の人数	指示を待つ時間	自分の業務に使える時間
4人	0.9分	440分
5人	1.16分	430分
6人	1.43分	420分
7人	1.7分	410分

考察

新人だけのチームは、6人以上入れるとマネジメント業務だけで手一杯になっていることがわかります。そうでなくても、自分の業務に使える時間がせいぜい3時間だと、指導以外のマネジメント業務すら回らず、ほとんど何もできなさそうですね。

標準的なチームだと急に手が空き始めますが、指示を待つ時間が平均6分と言うことは、実際には、待たせている間、誰かを指導しているので、自分が使える時間は体感的にはそれほど多いものにはならないでしょう。7人になると、指導を受けるのに、常に10分程度待つことになるので、このあたりからマネージャー専業といっても過言ではないと思われます。

シニアだけのチームはとても安定しているといって良いでしょう。7人でもおおよそ2分程度待てば、指導が受けられるのはとてもありがたいことです。300分は確保できているので、マネジメント業務を除いても十分プレイングマネージャーでやっていけそうです。

まとめ

チームの急成長により、新規メンバーのオンボーディングが追い付かず、チームがギスギスしたり、何をしたらよいのかわからないメンバーが出てきて、人数に対して成果が出ない、なんてことは現実でも多々あることだと思います。そういったときに、マネジメントにどれだけ時間を使うべきか、あるいはそもそもチームとして太刀打ちできないのであれば、一旦人数を減らして続行するも一つの策⁹だと思うので、その判断の後押しになれば幸いです。

参考文献

• 塩田茂雄, 川西憲一, 豊泉洋, 会田雅樹, "待ち行列理論の基礎と応用", 共立出版, 2014
• 滝根哲哉, "複数の到着流をもつ単一サーバ待ち行列", 1999

備考欄

記事を完走した感想ですが、なんの基準もなくこの記事を書き始めてしまったせいで、参考にした論文の数が極端に少ないように感じました。そのせいで、一番簡単なM/M/1を使わざるを得ませんでした（それ自体は良いのですが、もっとあったやろ）。本来であれば、この記事を支えた論文があっただろうに、普段から読んでいないせいで記事にかけなかったことはとても残念です。

書きたいと思ったけれど枝葉の部分だからと削った文章は脚注として復活を遂げました。見てもらうとわかる通り、この記事の30%くらいを占めています。本当は記事の方向がガンガンぶれるので良い表現ではありません。ただ、文章表現欲を満たすことも考えると、こういうのがないと面白くない、と屁理屈をこねて残すことにしました。

この記事を書くのに、ほぼ丸2日をかけているのですが、だらだら書くのはやはりよくないですね。途中で飽きてきてしまうし、勢いがそげてしまう。こういうおちゃらけの記事なんか、ぱぱっと勢いで出しちまえばいいんだ、なんて思いますが、そこでそれなりのものを出そうと拘ってしまうところが悪いですね。慣れ親しんだ待ち行列理論だったので、舐めて実験を最後にしたのもまずかった。文章構成や目的がいきあたりばったりになってしまったので、次は実験に着手してからやろうと思います。

---

1. エンジニアのためのマネジメントキャリアパス ―テックリードからCTOまでマネジメントスキル向上ガイド や生産性マネジャーの教科書、管理職1年目の教科書などを読んでいました。おすすめ順に並べて書いています。特に一番最初の本は、マネジメントをしないと決意されている方も読んでみてほしいです。 ↩

2. Wikiでの出典をたどると、Wall Street Journal誌に行き着きますが、2004年のFast Company誌も存在していておそらく原典でないと思われます。結局、原典までたどり着けなかったため、これがどのような経緯で語られたのか、明らかにはできませんでした。 ↩

3. 単純計算だといかんのか、という突っ込みがあると思います。筆者の主張としては、仮にマネジメント業務が定型作業であればそれでよいですが、そんな訳ないよね、ということ、もう一つは、チームによって大きく状況は違うが、それでも個々の状況に合わせた解が欲しいために、解析的に解きたかったということ。前者は、例えば、「マスターブランチに成果物をプッシュしてしまった」などであれば、ある程度の時間で済みますが、お客さんの本番環境をぶっ飛ばしたりすると、えらい時間がかかりますよね。このあたりを考慮して、指数分布に従ってほしいなと思いました。後者はほぼそのままの意味で、毎回巨大な数値計算するよりかは、それぞれのケースに即してすぐに計算できるほうがよいだろうということです。何か突っ込みがありましたらコメント欄に書いてください。 ↩

4. https://ja.wikipedia.org/wiki/%E5%BE%85%E3%81%A1%E8%A1%8C%E5%88%97%E7%90%86%E8%AB%96 ↩

5. 自分が機械学習に疎すぎて、どのようなタスクに落とし込むか、よくわからなかったので採用できませんでした。今年はこのあたりの落とし込み力をkaggleを通して身に着けたいです。 ↩

6. 仮に最適化をとるとしたら、いわゆる時間を対象にした長方形詰め込み問題的な解き方をすればよく、「目的関数を満たす解の存在」＝「運営できる」と問題設計すればよさそうです。ただし、そもそもマネジメント業務にかかる時間はノイズが多く、さらなる展開を考えたときに乱数付きの詰め込み問題になるので、「時と場合によってキャパオーバーする」パターンをうまく識別できないと考えました。「キャパオーバーになりにくい」前提のもと、「どのようにマネジメント業務をこなすべきか」という問題だったらはまり役だと思いました。 ↩

7. 本当は、新卒、標準、シニアの混合チームを考えたかったのです。これはサービス時間分布が到着流毎に異なる複数の到着流をもつ単一サーバ待ち行列を考えることになり、この投稿の内容 がぴったり当てはまります。ただ、私の力ではこの論文内容を（お正月中に）実装することができなかったため、まずはシンプルなM/M/1で妥協しました。つよつよエンジニアの皆様にはぜひ実装をお願いしたいです。 ↩

8. この値はフィクションです。いいですか？フィクションです。また、職場によってこのあたりの数値はブレると思ったのでざっくりと値を決めて計算しました。 ↩

9. チームを小さくすることは決断の難しい判断だと思います。急成長するチームは、実現性を担保した状態で成長しているパターンもあれば、偉い人が訳も分からず投資！投資！で回してるパターンもあります。後者であれば、偉い人の感情を宥めるのに適切な言い回しが必要になるでしょう...。 ↩