大規模組織におけるソフトウェア開発の誤解その２:すべてのチームが等しい価値の業務に取り組んでいるか？
7つのチームを持つ会社の人間がスクラムを表面的にしか理解していない場合、各チームは個別の業務リストを持つべきだと考えるかもしれません。それによってチームが「生産的」になるはず･･･でしょう？
従業員を忙殺することが目的なのであれば、この考え方は良いでしょう。しかし、最も優先すべき、最も価値の高い業務の達成を目指すのであれば、次のような稀な状況が揃っているのではないならば、理に適った考えとはいえません。
-
各チームのバックログに優先順位が同じ業務、つまり価値の等しい業務が含まれること。 チームAの最優先アイテム（A-1）とチームGの最優先アイテム（G-1）とは、顧客へのインパクトが等しいものでなければなりません。 現実の組織の中でしっかり目を見開いてそれなりの時間を過ごした経験があれば、大局的には、あるチームの業務が他のチームの業務よりも重要であるのはご存知でしょう。現実の世界においては、その価値の差が1000対1以上に開くことも想像に難くありません。社内に存在するのがフィーチャーチームではなく、単一機能のチーム（設計のみ、テストのみなど）またはコンポーネントチーム（バックエンドのみなど）である場合には、この問題は覆い隠されていることでしょう。
-
時間経過にかかわらず各チームのサブリストの優先順位が不変であること。顧客のニーズに対する理解を深めることができても、チーム毎のリストという限定的なコンテキストを超えて、優先順位を変更するのは不可能でしょう。 各チームの業務の価値判断を、事前に、一度きりで決定しなければならなくなります。アジリティが不要な場合は、このような「スクラム」は機能するかもしれません。もちろん、少しズルをしてチームCとチームDの間でリストのアイテムを移すこともできます。しかしそれはとりもなおさず、本当のところは1つのリストしかなく、それをわざわざ分割しただけであると認めることです。(優先順位を密かに変更するもっと一般的な方法は、資源管理、つまりキーパーソンを引き抜いて別の業務に移動させることで、これは慣行として広まっています。このような慣行は、「うわべだけのスクラムは実際にはアジリティを減少させる」ということの現れとして捉えられるべきです。マネージャーはこのような慣行を回避しなければなりません。)
-
各チームがすべてのアイテムを同じ速度で完了させること。チームBが優先順位2位のアイテム（B-2）を始めるのよりも先に、チームAが優先順位3位のアイテム（A-3）に取り掛かってしまったとすると、より価値の高い業務を犠牲にして、既に価値が低いと判断されている業務に取り組むことになってしまいます。スーパーでレジに並んだとき、遅く来た人が違う列で先に買い物を済ませてしまったという経験はありませんか？
以上は、いわゆる「Spotifyモデル」（別名：シャイニー・ハッピー・ピープル）を推奨する人々が大抵見逃しているポイントです。生産的だという感覚と、実際に価値の高い業務を遂行できていることとは別物です。従業員の満足度は、便利な指標となり得ます。しかし、それ自体がアジリティの目的を成し遂げられているかについて証明するものではありません。アジリティの目的とは、プロダクト開発組織が、事実が明らかになっていくにつれてそれに学び適応するということです。
リストを分割する理由は他にもあるかもしれません。もしかしたら、各リストのプロダクトが、本当に、全然、全く、無関係のものであるのかもしれません。ただし、この点については懐疑的であるべきです。スキルと知識との間に乗り越えられないギャップがあるように見えるために、過度の専門化に縛られているのかもしれません。能力の低い開発者をチームFにとどめておくという決定をマネジメントが下したのかもしれません。または、チームX及びチームYは地球の真裏に位置しているので重要な業務を任せたくないのかもしれません。これらについてには、ケン・シュウェーバー氏の組織の障害という用語を用いましょう。
読者の皆さん、あなた方がご自身の状況において何をするべきかは私には分かりません。せめてこの記事によって、スクラムにおいてはチームの数に関わらずプロダクトごとに1つのプロダクトバックログしか存在しない理由をお分かりいただけたなら幸いです。
