ブログ

ryuzeeによるブログ記事。不定期更新

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

みなさんこんにちは。@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. ストレスがたまり目的を見失う

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

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

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

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

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

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

本日は以上です。

アジャイルコーチングやトレーニングを提供しています

株式会社アトラクタでは、アジャイル開発に取り組むチーム向けのコーチングや、認定スクラムマスター研修などの各種トレーニングを提供しています。ぜひお気軽にご相談ください。

詳細はこちら
  • スクラム実践者が知るべき97のこと
  • 著者/訳者:Gunther Verheyen / 吉羽龍太郎 原田騎郎 永瀬美穂
  • 出版社:オライリージャパン(2021-03-23)
  • 定価:¥ 2,640
  • スクラムはアジャイル開発のフレームワークですが、その実装は組織やチームのレベルに応じてさまざまです。本書はスクラムの実践において、さまざまな課題に対処してきた実践者が自らの経験や考え方を語るエッセイ集です。日本語書き下ろしコラムを追加で10本収録
  • プロダクトマネジメント ―ビルドトラップを避け顧客に価値を届ける
  • 著者/訳者:Melissa Perri / 吉羽龍太郎
  • 出版社:オライリージャパン(2020-10-26)
  • 定価:¥ 2,640
  • プロダクト開発を作った機能の数やベロシティなどのアウトプットで計測すると、ビルドトラップと呼ばれる失敗に繋がります。本書ではいかにしてビルドトラップを避けて顧客に価値を届けるかを解説しています。
  • SCRUM BOOT CAMP THE BOOK 【増補改訂版】
  • 著者/訳者:西村直人 永瀬美穂 吉羽龍太郎
  • 出版社:翔泳社(2020-05-20)
  • 定価:¥ 2,640
  • スクラム初心者に向けて基本的な考え方の解説から始まり、プロジェクトでの実際の進め方やよく起こる問題への対応法まで幅広く解説。マンガと文章のセットでスクラムを短期間で理解できます。スクラムの概要を正しく理解したい人、もう一度おさらいしたい人にオススメ。
  • みんなでアジャイル ―変化に対応できる顧客中心組織のつくりかた
  • 著者/訳者:Matt LeMay / 吉羽龍太郎、永瀬美穂、原田騎郎、有野雅士
  • 出版社:オライリージャパン(2020-3-19)
  • 定価:¥ 2,640
  • アジャイルで本当の意味での成果を出すには、開発チームだけでアジャイルに取り組むのではなく、組織全体がアジャイルになる必要があります。本書にはどうやってそれを実現するかのヒントが満載です
  • レガシーコードからの脱却 ―ソフトウェアの寿命を延ばし価値を高める9つのプラクティス
  • 著者/訳者:David Scott Bernstein / 吉羽龍太郎、永瀬美穂、原田騎郎、有野雅士
  • 出版社:オライリージャパン( 2019-9-18 )
  • 定価:¥ 3,132
  • レガシーコードになってから慌てるのではなく、日々レガシーコードを作らないようにするにはどうするか。その観点で、主にエクストリームプログラミングに由来する9つのプラクティスとその背後にある原則をわかりやすく説明しています。
  • Effective DevOps ―4本柱による持続可能な組織文化の育て方
  • 著者/訳者:Jennifer Davis、Ryn Daniels / 吉羽 龍太郎、長尾高弘
  • 出版社:オライリージャパン( 2018-3-24 )
  • 定価:¥ 3,888
  • 主にDevOpsの文化的な事柄に着目し、異なるゴールを持つチームが親和性を高め、矛盾する目標のバランスを取りながら最大限の力を発揮する方法を解説します
  • ジョイ・インク 役職も部署もない全員主役のマネジメント
  • 著者/訳者:リチャード・シェリダン / 原田騎郎, 安井力, 吉羽龍太郎, 永瀬美穂, 川口恭伸
  • 出版社:翔泳社( 2016-12-20 )
  • 定価:¥ 1,944
  • 米国で何度も働きやすい職場として表彰を受けているメンローの創業者かつCEOであるリチャード・シェリダン氏が、職場に喜びをもたらす知恵や経営手法、より良い製品の作り方などを惜しみなく紹介しています
  • アジャイルコーチの道具箱 – 見える化の実例集
  • 著者/訳者:Jimmy Janlén / 原田騎郎, 吉羽龍太郎, 川口恭伸, 高江洲睦, 佐藤竜也
  • 出版社:Leanpub( 2016-04-12 )
  • 定価:$14.99
  • この本は、チームの協調とコミュニケーションを改善したり、行動を変えるための見える化の実例を集めたものです。96個(+2)の見える化の方法をそれぞれ1ページでイラストとともに解説しています。アジャイル開発かどうかに関係なくすぐに使えるカタログ集です
  • カンバン仕事術 ―チームではじめる見える化と改善
  • 著者/訳者:原田騎郎 安井力 吉羽龍太郎 角征典 高木正弘
  • 出版社:オライリージャパン( 2016-03-25 )
  • 定価:¥ 2,138
  • チームの仕事や課題を見える化する手法「カンバン」について、その導入から実践までを図とともにわかりやすく解説した書籍。カンバンの原則などの入門的な事柄から、サービスクラス、プロセスの改善など、一歩進んだ応用的な話題までを網羅的に解説します。
  • Software in 30 Days スクラムによるアジャイルな組織変革“成功"ガイド
  • 著者/訳者:Ken Schwaber、Jeff Sutherland著、角征典、吉羽龍太郎、原田騎郎、川口恭伸訳
  • 出版社:アスキー・メディアワークス( 2013-03-08 )
  • 定価:¥ 1,680
  • スクラムの父であるジェフ・サザーランドとケン・シュエイバーによる著者の日本語版。ビジネス層、マネジメント層向けにソフトウェア開発プロセス変革の必要性やアジャイル型開発プロセスの優位性について説明
  • How to Change the World 〜チェンジ・マネジメント3.0〜
  • 著者/訳者:Jurgen Appelo, 前川哲次(翻訳), 川口恭伸(翻訳), 吉羽龍太郎(翻訳)
  • 出版社:達人出版会
  • 定価:500円
  • どうすれば自分たちの組織を変えられるだろう?それには、組織に変革を起こすチェンジ・マネジメントを学習することだ。アジャイルな組織でのマネージャーの役割を説いた『Management 3.0』の著者がコンパクトにまとめた変化のためのガイドブック