なぜスクラムチームの開発者が複数チームを兼任しないほうがよいのか

みなさんこんにちは。@ryuzeeです。

よく受ける相談の1つに、「スクラムチームの開発者は複数のチームやプロダクト、プロジェクトを兼任してもよいのか」というのがあります。コーチ業をしている人ならみんな受けたことがあるものだと思いますが、詳しく見ていきます。

まず最初に結論ですが、タイトルにもあるとおり、「スクラムチームの開発者は複数チームを兼任しないほうがよい」です（スクラムガイドには書いていないですが、スクラムガイドは全てを詳細に記したハウツーではありません。あくまでゲームのルールです）。

理由を順番に見ていきましょう。

1. 開発に使える時間がかなり少ない

スクラムチームの開発者はスプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブといったイベントと、プロダクトバックログリファインメントのような活動に一定の時間を使います。チームによって時間は変わりますが、一般的には次のような形になります。

活動	使用時間の割合	1週間換算
スプリントプランニング	5%	2時間
デイリースクラム	1回15分	1時間
スプリントレビュー	2.5%	1時間
スプリントレトロスペクティブ	3時間以内	1時間
プロダクトバックログリファインメント	10%	4時間
合計		9時間

つまり1週間スプリントで40時間の時間がある場合、開発の実作業以外の作業が20%以上を占めます（これ以外にスクラムチーム外の活動として、1 on 1の時間、社内手続き、研修、休暇などもあるため、この割合は更に増えますが、今回は簡単にするために計算には含めないでおきます）。

これを踏まえて、50%アサインの場合に実作業にどれだけ時間を使えるかを表にしたものが以下になります。

	100%アサイン	50%アサイン
利用可能総時間	40時間	20時間
スクラムイベント等	9時間	9時間
開発可能時間	31時間	11時間

つまり、実際には50%アサインの開発者は100%アサインの開発者の三分の一程度しか、実作業に従事できないことになります。50%アサインというと、100%アサインの人の半分くらいは開発に時間を使える想定をしているかもしれませんが、実際にはそうはならないのです。つまり想定しているほどの速度で開発は進まなくなります（そう考えると30%アサインとか10%アサインとかは意味不明です）。

「いや、イベントに参加せず開発に時間を使えばいいじゃないか？」と思うかもしれませんが、そうしてしまったらそのメンバーはスクラムチームのメンバーではありません。スプリントゴールに対する共通理解も、日々のスプリントゴール達成の可能性の最大化も一切気にせず単に作業するだけの作業者になってしまいます。このようなやり方ではコミットメントは果たせません。

2. タスクの仕掛り中の時間が長くなる可能性がある

モブプログラミングのように参加者全員がリアルタイムに同期を取りながら進めるようなやり方ではなく、個人単位で分業してタスクをこなしている場合、タスクの仕掛り時間が長くなる可能性があります。

単純な例として、兼任者が働ける時間が月曜日と水曜日だとした場合、月曜日に着手してその日に終わらなかったタスクは、火曜日ではなく、水曜日に完成することになります。実作業にかかる時間（サイクルタイム）は同じだとしても、着手してから完成までの時間（リードタイム）は増えてしまっています。

このタスクがほかの人に影響を与えない独立したタスクであれば、これでも問題ないかもしれませんが、そうではない場合、全体としてのリードタイムに影響を与えることになり、最悪の場合はスプリント中に当該のプロダクトバックログアイテムが完成しなくなる可能性もあります（少なくともそのリスクが増えています）。

なお、「タスクが日をまたがないようにすればいいじゃないか」というのはそのとおりです。したがってなるべく仕掛り中のまま止まってしまうことのないように、タスクを小さなサイズに分解するのは良い手になります。もちろん仕掛中になってしまったものを誰かに引き継ぐ手もありますが、受け渡しの無駄のオーバーヘッドが生まれてしまいます。

3. 兼任メンバーが増えると制御しきれない

ここまでの話は、兼任している人が少数であれば工夫によって多少のオーバーヘッドで対処できる可能性もありましたが、兼任している人の人数が増えたらどうでしょうか？こんな感じになってしまうことでしょう。

人数が多い割に開発が進まない
全員が揃うのはイベントだけで、チーム内で何かを相談したり意思決定しようとした場合に決まらない
なんとか決まった場合でもその内容を知らない人が増えてくる
タスクを進めようとすると、誰かがロックインしているものが邪魔していちいち確認や調整が必要になる
スプリントの後半になって、スプリントゴール達成の可能性を最大化しようにも、稼働の制約のせいで取りうる手が限られてしまう
結果的に成果が出にくくなる
これをなんとかしようとしてレトロスペクティブで改善案を検討すると、だいたい文書化とかチケットに詳細に書くといった情報の引き継ぎを目的としたオーバーヘッドの大きい対処方法を選択してしまう
結果としてさらに開発が進まなくなる

4. ストレスがたまり目的を見失う

以上のようなやり方をすると認知負荷が高くなりストレスが溜まります。ストレスが溜まると、探索や実験といった学習に時間を使うのではなく、とりあえず今の状況をなんとかやり過ごそうとする力が働きます。結果としてプロダクトに対する関心は減り、ただ終わらせようとする力が働きます。

じゃあ、どうすればいいの？

兼任を避けましょう。以上。

「いや、そうはいっても会社からいっぱい仕事振られるんですが」という場合は、そもそも仕事の優先順位の判断が組織的にできておらず、なんでも同時並行で進めようとしている可能性があります。マネージャー等を交えて、組織の戦略を踏まえて、フォーカスすべきことを明確にしましょう。ピーナツバターを薄く塗るかのように、戦力を分散しても勝てません。

兼任の理由が「特殊なスキル」の場合は、そこがボトルネックなので、ボトルネックの処理能力を増やすことになります。例えば以下のような対処になります、

特殊なスキルを持っている人は、ほかの人でもできる仕事をやらないようにする
そもそもスクラムチームのなかに入れるのではなく、スクラムチーム外のタイガーチームとして扱い、必要に応じて作業を依頼する
特殊スキルを特殊でないようにする。つまり特殊スキルを持っている人は実作業を担当するのではなく、その作業を他の人でもできるようスキルトランスファーするという仕事をする

本日は以上です。