1+1を4にもできる！チームの理想的な規模と行動（後編）

by Nulab

2019年4月12日

鼻水が止まらなくなったのでとうとう花粉症デビューかと震えていたけど、単に風邪引いただけっぽい中村です、こんにちは。

前回の記事では、チームの規模と性質について解説しました。本記事では、チームの規模に応じた適切な行動についてご紹介します。小規模チーム（1人から3人）と中規模チーム（3人から9人）のそれぞれの特性と規模に応じた行動や手法について考察していきます。

小規模チームの特性「意思決定」

1人から3人程度の小規模なチームでは、意思決定を下すのに適切です。小規模なチームの中でも、いくつかパターンがあります。

1人

1人では、パターンの選択の余地はありません。ですが、1人でじっくり考える時間は必要です。

前回の記事で取り上げた「社会的手抜き」に説明されるように、複数人での会話ばかりだと自分で考えずに声の大きな人に流されるということが無意識のうちに起こりえます。

うまく設計されたワークショップでは、たとえ大人数が参加するものでも、1人で考える時間が組み込まれています。

2人チーム

2人以上になると、人と人のコミュニケーションが発生します。コミュニケーションのタイプは大きく分けて、以下の2つのタイプに大別されます。

2-a : 同じ立場の者同士でのコミュニケーション
2-b : 相談者と、壁打ち相手・メンターとしてのコミュニケーション

2-b について、一人では煮詰まりそうなときも、壁打ち相手に話しかけるだけで整理されるということは、経験したことあるなら分かっていただけると思います。

実は、「ペアプログラミング」ならぬ「ベアプログラミング」として、テディベアに話しかける手法として古くから紹介されています。

自分のコードを他人に説明してみよう。自分のコードを誰かほかの人に説明して聞かせるのも効果的なテクニックだ。こうすると自分自身にバグが見えてくることが多い。場合によっては説明し始めた途端に気がついて「あ、もういいや、変なところがわかったよ。ごめんごめん」などと言って照れくさい思いをすることもある。

このテクニックは意外なほど有効だし、聞き手は別にプログラマでなくてもかまわない。ある大学の計算機センターのヘルプデスクのそばにはテディベアのぬいぐるみが常備されており、摩訶不思議なバグに悩む学生は、人間のスタッフに相談する前にぬいぐるみに向かって説明しなければならないことになっていた。

プログラミング作法 by Brian Kernighan, Rob Pike

困ったら、テディベアに話しかけてみよう

3人チーム

3人以上に規模になると、コミュニケーションのタイプは大きく3つに大別できます。

3-a : 全員が同じ立場の者同士でのコミュニケーション
3-b : 2人が同じ立場で、1人がファシリテーターとして入るコミュニケーション
3-c : 1人の相談者を、2人のメンターで支援するコミュニケーション

個人的に、3人というのはバランスが取れていると感じています。

基本は3-aで進めつつ、状況に応じて3-bのように1人が俯瞰した目線で見ることができるというのは、大きなメリットです。

「3名で会社創業したんだけど、そういう理由もあるんだよね」と、とある会社の創業者に聞いたことがあります。

筆者の経験：新入社員研修に3-cのコミュニケーションを試した結果

3-cのパターンについては、新入社員研修時のメンターで試しに実験してみて、非常に効果的に進められました。

もともとは2-bのように1対1で対応していましたが、忙しくなってくると「なかなかメンターのための時間が取れない」「判断に迷うときがある」という課題がありました。

そこで試しにメンターを2人体制にしたところ、うまくハマりました。

1人のメンターがいなくても概ね問題なく進められるし、判断に迷ってももう1人のメンターがいればそうおかしな方向にはずれない。

メンターの指導や助言を受ける側（メンティー）にとっても、2人の意見なら納得感が大きくなる、というメリットがありました。

中規模チームの特性「実務：実際に物事を進める」

実務を進めるという点で、チームとして力を発揮できるのは3人から9人程度の規模でしょう。

ひとりでは実現できないことも、背中を預けられるメンバーと共にチーム一丸となって大きな物事を成し遂げる、チーム作業、チーム開発の魅力ではないでしょうか。

中規模チームを表す概念を、2つほどご紹介します。

1. スクラムガイド

開発チームのメンバーが3人未満の場合は、相互作用が少なく、生産性の向上につながらない。また、開発チームの規模が小さいと、スキル不足が原因でリリース判断可能なインクリメントを届けられない可能性もある。メンバーが9人を超えた場合は、調整の機会が多くなってしまう。また、チームの規模が大きいと経験的プロセスが複雑になり、有益ではなくなる。

スクラムガイド

2. two-pizza rule

ものすごい食欲を目の前にして2枚のピザを注文したと想像してみましょう。この2枚のピザでいったい何人を賄えるでしょう？その答えがチームプロジェクトに参加させるべき人数だというのです。だいたい5人から8人くらいといったところでしょう。この数字を越えると、チームワークが破綻する可能性が増えていきます。

米AmazonのCEOジェフ・ベゾスが提唱する｢2枚のピザ理論｣ | ライフハッカー［日本版］