木下史彦- 木下史彦
アジャイルチームにおける兼任問題を考察する
Agile Studio プロデューサーの木下です。
「メンバーが兼任なのですが、アジャイル開発はできるでしょうか？」
これは最近よく受ける質問です。
このような質問を発する人は実際に兼任（チームの掛け持ち）をしていて何らかの問題が発生しているか、「アジャイル」に対して持っているイメージで何となく兼任との相性の悪さを感じているかのいずれかに当てはまるケースが多いようです。
では、具体的にどのような問題が発生することが考えられるのでしょうか。
発生する（と想定される）問題
問題A. チームメンバーの時間が合わずチームで仕事をする時間がとれない
スクラムチームがスプリントを1週間でまわしている場合、スクラムガイドによるとチームはスクラムイベントに最大で9時間を使うことになります。
デイリースクラム 15分×5回
スプリントレビュー 1時間
スプリントレトロスペクティヴ 45分
スプリントスプランニング 2時間
バックログリファインメント 4時間
また、ペア作業やモブ作業で仕事を進めていくのであれば、より多くの時間をチームで過ごす必要があるでしょう。
チームメンバーが兼任の場合、メンバーがチームの仕事をする時間帯がお互いにずれているとすれ違いになってしまい、スクラムイベントやペア作業・モブ作業を実施するための時間が合わないという問題が発生します。
問題B. 仕事のスイッチングによるムダが生じる
以下の表は『ワインバーグのシステム思考法』に記載されている「ワインバーグの表」としてい知られている有名な表です。
ある人がひとつの作業に集中できる場合、当然、100%の時間のその作業に充てることができます。では、作業数が2つ、つまり2つの作業を掛け持ちするとどうなるでしょうか？各作業に充てることができる時間は50%ずつ、と言いたくなるところですが、実際にはさまざまな実験の結果、各作業に充てることができる時間は40%になります。40% + 40% = 80%。あれ、残りの20%はどこに消えたの？これがいわゆる「スイッチングコスト」と言われるものです。
スイッチングコストを考慮せずに100%の仕事をアサインし、実際には100%以上の仕事量となってしまい、疲弊している現場がよく見られます。
問題C. 兼任メンバーが抱えている仕事の優先順位や総量の調整が個人任せになる
通常スクラムではプロダクトバックログの優先順位を最終的に決定するのはプロダクトオーナーであると決まっています。また、チームの実績を元にプロダクトオーナーと開発者が相談してスプリントのスコープを決めることで、持続可能なペースを維持していきます。
しかし、兼任となるとそのメンバーは2つのバックログに同時に対応していくことになります。（兼任の仕事がスクラムでないケースもあると思いますが、その場合はバックログではなく何らかのやることリストに対応していくと読み替えてください。）このとき、2つのバックログに入っているバックログアイテムのどちらを優先すべきでしょうか？？？
そうこうしているうちに、兼任メンバーはどちらのチームからも過剰に仕事を受けてしまい、疲弊して行ってしまいます。
さて、ここまで兼任によって発生する3つの問題を取りあげてきました。
問題が明確になれば、解決策が見えてきます。
解決策（チームレベル）
解決策1. 集中デー、集中タイムを設ける
解決策のひとつめは、チーム全員が集まる曜日や時間帯をあらかじめ決めておくという方法です。チームメンバーは兼任の仕事を入れないようにします。割り込みが入らないように、周囲の関係者にも事前に周知おきます。集中デー、集中タイムにはチームのスペースに「割り込み禁止」のボードを掲げているチームもあります。
解決策2. 1日1スプリント
1日のはじめに軽めのプランニングを行い、1日の終わりに軽めのレトロスペクティヴを行います。こうすることで、1日単位で仕事を完結させていきます。
月曜日はAさんとBさん、火曜日はBさんとCさんのように兼任のためにチームメンバーが日によって入れ替わってしまうようなケースでは、1日のはじめに軽めのプランニングを行うことで前日に別の仕事をしていたメンバーもスムーズに仕事をはじめることができます。
解決策（マネージャレベル）
解決策3. スイッチングコストを考慮したメンバーアサイン
前掲の「ワインバーグの表」を元にメンバーをチームにアサインするの際にスイッチングコストを考慮したアサインを行います。
たとえば、2つの仕事を兼任するようなケースでは、最大80%までしか仕事をアサインできないというのをルール化します。
解決策4. 兼任メンバーの仕事優先順位や総量をチーム横断的に調整する
PO同士の話し合いの場を設ける、兼任メンバーをケアする担当者を設置するなどですが、実際の運用は難しそうです。
原因
そもそもなぜこんなことになっているのでしょうか？
「兼任をなくす」という解決策はあり得ないのでしょうか？
ここからは、兼任が発生する原因を考えてみたいと思います。
原因a. 事業やプロジェクトの優先順位付けができていない
あれもこれもやりたい（やらなければならない）と選択と集中を欠いているケースです。
X社の仕事を受注、Y社の仕事も受注、A部長の肝入りの社内プロジェクトも進めなければならない。毎週進捗を報告しなければならないため、プロジェクトを止めているわけにはいかない。
このようにして、複数の事業やプロジェクトを同時並行で進めようとした結果、メンバーの人数に対してプロジェクト数が多くなりすぎ、兼任が発生していきます。
原因b 新規事業と既存事業の折り合い
近頃、多く見かけるのがこれです。
新規事業を推進していくために新たなプロジェクトを立ち上げることになりました。しかし、既存事業をやっている事業部としては大事なメンバーを新規事業に持って行かれるわけにはいきません。なにせ、既存事業は会社の重要な収益源であり、大黒柱です。かといって、全社で取り組む新規事業に既存事業部として協力しないわけにもいきません。
そこで編み出されるのが、メンバーの稼働を新規事業と既存事業で半分ずつ分け合うという折衷案です。このようにして兼任が発生していきます。
原因c. 人数合わせのためのパズル
既にメンバー全員がフルで仕事にアサインされているところに新しい仕事がやってきたケースです。今後の会社間の関係を考えると、無下に断るわけにはいきません。
そこで編み出されるのが、メンバーの稼働を少しずつ集めて人数合わせをするという技です。メンバー20人から10%ずつ稼働を集めて2人月分の稼働が確保出来ました。めでたしめでたし。
このようにして兼任が発生していきます。
原因d. 仕事が個人依存になっている
あの仕事はAさんにしかできない。もしくは、その仕事の存在すら知られていないケースもあります。何やらAさんはいつも忙しそうにしている。仕事を個人で抱えて込んでしまっており、いつまで経っても過去に担当していた仕事を引きずっているようなケースです。
個人が抱えている「謎の作業」が増えていくと、ちょっと別件で外しますということが多発し、チーム作業に悪影響がでます。
原因e. 細切れの仕事が多い
そもそもチームでやるような仕事でない、もしくは、ひとり分の仕事量に満たないような細切れ仕事が多いケースです。
原因を明らかにしたところで、「兼任をなくす」という方向でもう一度、解決策を考えてみたいと思います。
解決策（経営レベル）
解決策5. 事業やプロジェクトの優先順位をつける
スクラムの価値基準のひとつに集中（focus）があります。プロダクトバックログは優先順位をつけて対応していきます。
もう少し視点を広げて、事業も同じことです。限られたリソースの中で成果をだしていかなければならないわけですから、どこに集中するのか優先順位をつけて対応していくことになります。
それができないから困っているという声もよく聞きます。優先順位をつけるということは何かを止める判断をしなければならないわけですから難しいのは分かります。ですが、リーダーシップが決断しなければ誰も代わりに決断できるようなことではありません。
マネジメントが報酬を支払われるのは、判断力に対してであって無謬性に対してではない。
— ピーター・ドラッカー『イノベーションと企業家精神』
解決策（ マネージャレベル）
解決策6. チーム構成の最適化
解決策3により作業のスイッチングコストが見える化され、兼任の場合は100%の仕事をアサインできないということになれば、アサインを決定しているマネージャも兼任をやめて専任化することを考えるようになるかもしれません。
どれくらいの期間で考えるかは状況によってさまざまだと思いますが、「作業のスイッチングコスト ＞ 引き継ぎコスト」となるのであれば、引き継ぎ期間を設けて、人数合わせのためのパズル、個人依存になっている仕事を解消し、チーム構成を最適化していくとよいと思います。
解決策（チームレベル）
解決策7. バックログの統合
最後は、個人で抱えている仕事をチームのバックログに入れてしまうという解決策です。
バックログに入れても最初のうちはその仕事はその人ひとりにしかできないかも知れませんが、そういう仕事があるということが他のチームメンバーに見えるようになることが大きな進歩です。ふりかえりで「◯◯さんしかできない仕事がある」という Problem があがったり、朝会で「その仕事、手伝いましょうか」という声があがったりすればめっけものです。
まとめ
経営レベルからチームレベルまで、また、兼任をなくしていく方法から兼任を認めて付き合っていく方法まで、あわせて7つの解決策を見てきました。
もちろん、解決策はここにあげた7つだけとは限りませんし、組織の置かれている状況によってはこの通りにやってもうまくいかないこともあるでしょう。
大事なのは「これは自分の問題ではない」と他人事にしないことです。経営レベルからチームレベルまで何かしらできることはできることはあるはずです。
また、これは制約事項だからと思考停止に陥らないことも重要です。制約の原因は何なのか、制約はどうすれば取り払えるのかを考えていかないとブレイクスルーはありません。反対に制約を壊す方法だけに固執するのではなく、なんとかして制約と付き合っていくことも大事でしょう。
何よりも大事なのは経営レベルからチームレベルまでみんなが問題の存在を認めることです。そして、すぐに答えは出ないかもしれませんが、一緒に話し合うことです。すぐに解決できないからといって問題がないことにしてはいけません。
Agile Studio ではこのような問題（兼任の問題に限らず組織やチームを取り巻く問題）に対して、絵に描いた餅に終わらない現実的な解決策を導いていくための支援を行っています。お問い合わせはこちらから。
（タイトル写真：Photo by Luis Villasmil on Unsplash）