スクラムの開発チームを10人以上で回すツラミ

スクラムガイドでも以下のように書かれているように、スクラムチームにおける開発チームの規模は、3~9人が良いらしいです。

開発チームに最適な人数は、小回りが利く程度に少なく、1 つのスプリントで重要な作業が成し遂げられる程度に多い人数である。(中略)メンバーが 9 人を超えた場合は、調整の機会が多くなってしまう。また、チームの規模が大きいと経験的プロセスが複雑になり、有益ではなくなる。スプリントバックログの作業に携わらないのであれば、プロダクトオーナーとスクラムマスターはこの人数に含まない。
スクラムガイド P6

特に人数が多い場合、有益的ではなくなると書いてありますね。

実は僕が所属しているチームは現状10人以上で構成されており、この辛みに直面しています。

そこで、開発メンバーが多いチームでのスクラムが具体的にどう辛いのかをシェアしようと思います。

なお僕が所属しているスクラムチームの開発メンバーは以下の構成で、合計で11人います。

・クライアントエンジニア(iOS/Android) × 2
・サーバーエンジニア × 4
・QA × 4
・デザイナー × 1

スクラムイベントの時には、これに加えてスクラムマスター、複数の企画(PO)や分析のメンバーも加わり、会議体の参加者は15人を超えることもあります。

スプリントプランニングでの辛み

まずは、スプリントプランニングと、その前準備としてのプロダクトバックログリファインメント(PBR)について。

そもそも、大人数で会議体を持つと、適切な議論ができなかったり、出席してるだけで実際には参加してないメンバーが増えるなどして、「無駄な会議」になりがちです

参考：ジェフ・ベゾスの秘策｢ピザ2枚｣ルール。 アマゾンはこれで無駄をなくした)

そのため、「僕らはスクラムチームだ！みんなで議論して共通認識を作って良い計画を立てよう！」と開発チーム全員でプランニングに取り組もうとすると、例えばその前段階のPBRを開催しても、まず一つ一つのプロダクトバックログアイテム(PBI)のリファインメントが雑になります。

このユーザーストーリーの背景って何？
どんなユーザー体験にしたいのか？
どういう手段でそれを実現するのか？
受け入れ基準や完了条件は何か？
開発規模はどのくらいか？
1スプリントで収まる適切なサイズに分解されているか？

こういった観点をPOと開発メンバーとで相互にコミュニケーションをしながら精度を高めようと思っても、ただの傍観者状態の参加者が増えてしまい、相互コミュニケーションが起きにくくなります。ファシリテーターが一人一人に「どう思う？」と聞くにしても全員に聞く時間もないし、聞いたとしても「すみません聞いてませんでした」となることもザラ。10人で意見を交わしてチームとして結論を出すのは至難の業なんですね。

結果、以下の画像右側のような、開発メンバーからの質問がほぼなく質の低いリファインメントとなってしまいます。

出典：アジャイル開発におけるプロダクトバックログのリファインメント方法の提案

さらに、開発メンバーの数が多く消化できるPBIの数も多くなるため、それだけ多くの時間をPBRに費やすことになります。つまり、質の低いリファインメントに多くの時間を費やすことになります。あるいは、その時間を確保できず、PBRをしないままプランニングに持ち込むPBIも出てきます。

このような状態でスプリントプランニングに取り組んでも、一つ一つのバックログアイテム(PBI)のリファインメントが雑なので規模見積もりやチケット分解も雑になり、プランニングの精度がかなり低くなってしまいます。あるいは、プランニングの時間中にPBRもすることになってしまい、さらにプランニングの精度が低くなることも。

そうすると、スプリントが始まった後に「このチケットの受入条件ってなんでしたっけ？」という会話になったり、タスク分解不足でスプリント内で成果物を出せない、ということが頻発するようになります。

結果、ユーザー(顧客)への価値提供が遅れてしまったり、ユーザーストーリーに対しての議論が少ないことで価値のないものを届けてしまう、といったことにも繋がってしまうかもしれません。

このように、開発メンバーの数が多く、かつメンバー全員でプランニングやPBRをしようとすると、スプリントのスタート地点で暗雲が立ち込めることになります。

デイリースクラムでの辛み

いざスプリントが始まり、開発チームの進捗の検査のためにデイリースクラムを始めます。一般的には、デイリースクラムは10~15分のタイムボックスに収めることになっています。理由は開発時間に支障をきたさないようにするのと、時間を決めることでその時間内で本当に必要な情報だけを話すようにする意識を持ってもらい無駄な時間を作らないようにするためです。

しかし、開発メンバーの人数が多いとデイリースクラムを15分に収めるのも大変になり、「何かあったら検知して助け合う」ための場ではなく、ただの報告会の場になりがちです。

レトロスペクティブ（ふりかえり）での辛み

なんとかスプリントが終わり、チームをさらに良くするために皆で振り返る時がきました。ここでも、やはり人数が多いことによる弊害が出てきます。

もうお察しの通り、今後のために建設的な議論をしようと思っても、どうしても一部のメンバー間だけのやりとりになってしまいますし、そもそもトピックを何も出さないメンバーも多くなってしまいます。こちらが名指しで何か改善点などを聞いても、「特にありません」という回答が出やすく、もちろん本当に特にないこともあるでしょうが、開発メンバーの数が多くなると当事者意識が低くなり自分たちで改善しようというマインドを持ちにくくなるのではないかと思います。

そうすると、経験をもとに自分たちでチームを改善していくことが困難になり、チームとして成熟しにくくなります。そうすると、リーダ的立場の人が必要になってその人が中心に物事を進めることになり、俗人的なチームになってしまいます。

経験的プロセスは、スクラムの中でも大事なポイントですね。

スクラムは、経験的プロセス制御の理論（経験主義）を基本にしている。経験主義とは、実際の経験と既知に基づく判断によって知識が獲得できるというものである。スクラムでは、反復的かつ漸進的な手法を用いて、予測可能性の最適化とリスクの管理を行う
スクラムガイド P4

まとめ

以上、開発チームメンバーが多いことでスクラムを回すことの辛みを共有させていただきました。

全体的に、開発メンバーの人数が多いと、チームとして話をすることが難しくなり、１つ１つのスクラムイベントの質が低下してしまいがちです。

その結果、効率的に成果物を届けることが困難になり、ユーザーへの価値提供が遅れる、あるいは価値のないものを届けてしまうといった支障がでてきます。また、開発チームが自分たちで成熟していくことが困難で、いつまでも俗人的なチームになってしまいます。

ただ、じゃあ大人数のチームを少人数にしようにしても、人材不足や組織的な都合などでそう簡単には行かないこともあるかと思います。
(そこをなんとかするのもスクラムマスターの仕事ではありますが。。)

もし貴方のスクラムチームが大人数になりそうになった場合には、ここであげた辛みが参考になれば嬉しいです。