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

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

前回の記事では、チームの規模と性質について解説しました。本記事では、チームの規模に応じた適切な行動についてご紹介します。小規模チーム(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枚のピザ理論」 | ライフハッカー[日本版]

筆者の経験:開発プロジェクトは3人から9人がちょうど良い

実際に私も2人のチーム、もしくは10人以上のチームで開発を進めようとしたことがありますが、なかなか難しいものがありました。

2人のチームは多様性が少ないというデメリットがあります。具体的には

  • ふりかえりをしてもアイデアが広がらない
  • チームとして施策をこなすスキルが足りない

といった課題がありました。

逆に、10人以上のチームはコミュニケーションコストが高くなるデメリットがありました。例えば

  • コミュニケーションコストを抑えようとするとチーム内でサブチームができる

という状況がおきていました。せっかく決めた10人という、人数の意味がない状況になってしまったのです。この経験からも、実務を進める上で3人から9人程度というのはちょうど良い規模だと言えます。

2枚のピザで賄える人数に抑える中規模のチームは2枚のピザで賄える人数が目安

まとめ

前編と後編にわたって、チームの規模に応じた性質と適切な行動について紹介しました。

自分たちがどういう課題を抱えていて、その課題を解決するのに適切な行動・チーム規模はどの程度なのか、というのを一度立ち止まって考えてみると良いでしょう。

小規模チームは意思決定に適している、中規模チームは実務を進めるのに適している、といったそれぞれの特性を踏まえ、目的に応じてチーム編成をすることで、あなたのチームはより高い効果を発揮するでしょう

この2つの規模のチームに加えて、10人以上の大規模チームにも特性と規模に適した行動があります。「10人以上の大規模なチームビルディングと理想的な行動とは?」では、大規模なチームに焦点を置いて、チームの特性と規模に適した最適な行動についての考察をお届けします。

Backlogバナーリンク

▼チームビルディングに関連する記事はこちら

チームで使えるプロジェクト・タスク管理ツールならBacklog

  • お役立ち資料

    Backlogの資料のほか、タスク管理に関する最新情報や事例・ノウハウをダウンロードできます。

    お役立ち資料を見る
  • 無料説明会

    Backlog導入時の基本操作説明や導入後の活用セミナーをオンラインで開催しています。

    開催スケジュールを見る
  • お問い合わせ

    導入前から導入後まで、Backlogの使い方や導入方法などお悩みや不明点にお答えします。

    サポートに問い合わせる