スクラムチーム（Scrum Team）は機能横断型（cross-functional）で自己管理型（self-managing）です。
Scrum.org のスクラムガイドによると、スクラムチームについて次のように書かれています。
スクラムチーム内には、サブチームや階層は存在しない。
スクラムチームは機能横断型で、各スプリントで価値を⽣み出すために必要なすべてのスキルを備えている。
https://www.scrum.org/resources/scrum-guide
また、⾃⼰管理型であり、誰が何を、いつ、どのように⾏うかをスクラムチーム内で決定する。
スクラムチームが機能横断的でなければならないというのは、とても分かりやすい話です。必要な全てのスキルを全員が持っていなければならない、というわけではないのですが、必要なスキルを少なくともチームの誰か持っていなければ、さすがに開発することができません。
一方で、スクラムチームが自己管理型であるというのは、実はなかなかイメージがしづらいように思います。
目次
- 1 スクラムチームに階層はない＝上司からの指示で動くのではない
- 2 階層が何より重要な組織ではスクラムチームの在り方が認められない
- 3 スクラムチームをサブチームに分割しない＝全員で話す
- 4 人数が増えたら（階層やサブチームを作るのではなくて）チームを分割する
- 5 開発者は顧客と話すのに慣れていないことが多い（暗黙的な階層やサブチームにならないように気を付ける）
- 6 スクラムチームは自己管理型（セルフマネジメント）＝ Azure DevOps のタスクを自分で In Progress にする
- 7 Azure DevOps のチームとエリアパスをスクラムチームのためにつかう（スクラムチームをサブチームに分ける目的で使わない）
スクラムチームに階層はない＝上司からの指示で動くのではない
スクラムを経験したことがない多くの組織にとってチームとは、チームメンバーが上司・上長・リーダーといった人から指示されたタスクを実施して、進捗をリーダーに報告するもの、というのがあまりにも一般的です。そのため何も準備をしないでスクラムチームを作ると、自然に（何の疑問も持たずに）、チーム内に階層が持ち込まれてしまいます。もし、上司・上長の役職の人がいなくても、「よしわかった！俺がメンバーに指示をするので、みんな俺に進捗を報告してくれ！」という感じのリーダーシップを発揮する人が出てきます。リーダーが不在の場合には、サブリーダーの人が同じような役割を補うのは、一般的な組織にとってごく普通のことです。しかし、これではスクラムはうまくいきません。
スクラムチームに階層がない、というのは、こういったリーダーに指示をされたタスクを実施するような体制ではないということを表しています。もちろん、例えば開発者のリーダーだけがプロダクトオーナー（PO）と話をして、その結果を他の開発者に伝えるような体制でもありません。開発者は全員が PO を含めたスクラムチーム全員とコミュニケーションします。それを通じて、開発者が自分でやるべきタスクを決めて、他の人の指示を待つことなく、自分でタスクを実施します。これがまだ経験したことがない、イメージのできない働き方だという人は、意外にも沢山います。
スクラムチームを作るときには、チーム内に階層がないということ。またそのような人に指示をされて動いて、その結果を人に報告するような働き方はしないのだということを、改めてしっかりと共有しておく必要があります。
階層が何より重要な組織ではスクラムチームの在り方が認められない
組織の文化は、会社や業界などによってかなり違いがあります。その中でも、この「階層」が何よりも重要だと考えている組織では、当然、スクラムはうまくいきません。
もし組織が成果主義であれば、売り上げや開発の効率など、何かしらの数値を評価の基準にしているかもしれません。数値に表せなくても、顧客の評価が高いなどの何かしらの結果を評価しているのであれば、その結果を出すために正しいことをすることが求められる、認められるはずです。しかし、階層を何より重要とする組織ではそうではありません。成果を上げることよりも「誰が指示したことをやったか？」ということが評価されます。当然、そういった組織では、メンバーが自分で判断してタスクを決めて実施することは良しとされませんし、メンバー自身もそんなリスクを冒せません。メンバーにとっても、リーダーにとっても、組織の一員は偉い人に言われたとおりに仕事をすることこそが重要なのです。
例えば、ウォーターフォールのプロジェクトがいつも炎上していて、それでも炎上させている人が評価されている、あるいはその火消しをした人がいつも評価されているような組織は、スクラムには向かないかもしれません。そういったウォーターフォールのプロジェクトでは、EVM（Earned Value Management）は実施されていないはずです。CPIもSPIも計算していないでしょう。そのため、いつも何が原因で炎上しているか？を分析することなく、コストをかけてプロジェクトを収束させて「成功させたこと」にしている。そういう組織には、成果主義よりも階層主義のマインドが蔓延しているのかもしれません。そこにスクラムにすればプロジェクトが成功するはずだと、スクラムチームを作ろうとしても、結局いつの間にかチーム内に階層のようなものを作ってしまって、うまくいかないように思います。あるいは、スクラムの価値に従って働いたスクラムチームのメンバーが、既存の組織や偉い人から認められずに辛い想いをすると言うことにもなりかねません。
逆に、階層や「誰がやったか？」よりも、結果を重視する組織であれば、スクラムがうまくいく可能性が高いと思います。
とは言え、スクラムを経験したことがない多くの組織にとって、チームは（自己管理型ではなく）リーダーから指示をされてメンバーが動くのが一般的です。それは階層を重視する文化であっても、成果主義の文化であっても同様で、なかなか区別できません。自分たちは成果主義だと思っていたが、いざスクラムを導入してみると「チームが自己管理するなんてけしからん」と多くの偉い人から怒られて、そこで初めて自分たちの組織が階層主義だったとわかるということもあるかもしれません。自分たちの組織がスクラムにあっているかどうかは、やってみなければわからない部分もあって、なかなか難しいポイントだと思います。
スクラムチームをサブチームに分割しない＝全員で話す
スクラムチームにはサブチームもありません。これは、スクラムチームの中で、よくコミュニケーションをする人と、そうでない人を分けない、つまり全員で話すべきという意味です。
スクラムの開発者は、例えば「コードを実装する人」と「テストをする人」という風に分けるべきではない、全員が開発者としてコードを所有して、全員でテストをすべきです。それをわかっていれば、実装サブチームとテストサブチームにわけるということにはならないはずです。
また他に、例えばスクラムチームに2つのサブチームがあって、サブチーム内ではよくコミュニケーションをとるけど、もう一方のサブチームとは話をあまりしない。それぞれのサブチームのメンバーには階層的なうごきはなく、サブチームのメンバー全員がプロダクトオーナー（PO）とはよく話をしている。こんな状態で、このチームは本当にスクラムチームとして動けるのでしょうか？スプリントプランニングで前半はサブチーム１が、後半はサブチーム２が話してプロダクトバックログをそれぞれのサブチームで分担する？それはもはやひとつのチームではないし、よくない方法でしたよね。
そこまで極端でなくても、何かの都合があってチームをサブチームに分けたくなることがあるのはわかりますが、それはサブチームに分けたことによってどうしても全員では話さなくなるというデメリットの方が大きくります。サブチームに分けてたのではうまくいかないポイントを、スクラムの役割やイベントのひとつずつで確認していくと、やっぱり分けない方が良いなと実感すると思います。
人数が増えたら（階層やサブチームを作るのではなくて）チームを分割する
そうは言っても、スクラムチームは10人以下なので、チームメンバーの人数が増えたらサブチームに分けるしかないよね、と感じるかもしれません。確かにその感覚は正しいです。例えば 30人の開発者が、全員でスプリントプランニングやデイリースクラムをするのは現実的ではなさそうです。プロダクトオーナー（PO）と話をするのも人数が多すぎます。それならば、リーダーや代表者が取りまとめて・・という階層にしたり、階層がだめならサブチームに分ければいいじゃないか、と思うのはよくわかります。
スクラムチームの人数が増えるなら、スクラムチームの中に階層やサブチームを作るではなく、スクラムチームを分割して、複数のスクラムチームにするべきです。30人の開発者なら、10人ずつの3チームや、6人ずつの5チームなどに分けるのが良いと思います。分割した複数のスクラムチームは、同じ１つのプロダクトバックログを共有して、同時に開発することになります。これをうまくやるには、大規模向けのフレームワークが必要です。
スクラムガイドは、ひとつのスクラムチームがどのようにするか？を定義しているだけなので、複数のチームが、チーム間でどのようにプロダクトバックログや状況を共有すればいいか？を定義してくれていません。チームが多くなるとだんだんとスクラムチームの外や、スクラムチーム間の連携が難しくなっていきます。それについては、大規模向けフレームワークの Nexus や SAFe などのフレームワークのやり方に従うことで、うまくいくようにしていきます。
開発者は顧客と話すのに慣れていないことが多い（暗黙的な階層やサブチームにならないように気を付ける）
従来の文化や多くのウォーターフォールのプロジェクトでは、開発者が階層的な組織で働くことが一般的であったため、経験の長い開発者であっても実は、顧客と直接話す経験自体はそんなに多くない、という場合があります。組織文化によっては、「開発者が顧客と話すなんてとんでもない」とか「（暗黙的に、時間をかけて綺麗に準備したPowerPointなどの）準備なしに顧客と話すなんてできない」というのが当たり前だったりします。しかしそれではスクラムはうまくいきません。
プロダクトオーナー（PO）が顧客で、開発者とは会社組織が違うというのはよくあるパターンです。このスクラムチームで、顧客と開発者が会社が違うからと話せないとか、話すたびに時間をかけて準備しないといけないのでは、とてもアジリティ（素早さ）が出ませんよね、アジャイルにならないのは明らかです。しかし、それがわかっていればできるか？と言うとそうでもないですよね。「PO と開発者の全員が、必要な時にはすぐにコミュニケーションできることが重要だ」と言われているので、顧客と話さざるを得ない。しかし、やっぱりどう考えても自分が顧客と話すのは難しいので、一部のリーダーや限られた人に頼んで顧客＝POと話してもらうようにする。そうしていつの間にか、スクラムチーム内に階層的な役割や、サブチーム的なグループ分けが出来てしまう。明示的な階層やサブチームはなくても、暗黙的にそのように動いている、というのはあり得る話です。
スクラムチームは実際のコミュニケーションの様子をよく確認して、時々振り返って、実質的に階層的やサブチーム的になっていないか？ということに気を付けていきましょう。
スクラムチームは自己管理型（セルフマネジメント）＝ Azure DevOps のタスクを自分で In Progress にする
スクラムチームが自己管理型というのは、なかなか具体的なイメージがしづらいところですが、ここまで「スクラムチームには階層やサブチームはない」という点を考えてみて、どういう状況だと「自己管理型ではない」というのが少しイメージできたのではないでしょうか。そのうえで、誰が何を、いつ、どのように⾏うかをスクラムチーム内で決定することができていれば、自己管理型になっているかということがイメージしやすいと思います。
プロダクトオーナー（PO）はプロダクトゴールとプロダクトバックログと通じて何をすべきか？ということを開発者に示します。またスプリントゴールを明確に開発者に伝えます。開発者はプロダクトゴールやプロダクトバックログとスプリントゴールを実現できるように、必要なタスクを考えて、自身でタスクを選択して実施します。
開発者は（他の誰かにタスクをアサインされるのではなく）自分自身でタスクを取ります。また開発者は（進捗を誰かに報告するのではなく）タスクの状況を Azure DevOps に更新するなど、リアルタイムでスクラムチーム全員に共有します。
Azure DevOps のチームとエリアパスをスクラムチームのためにつかう（スクラムチームをサブチームに分ける目的で使わない）
Azure DevOps を使って開発を行う場合は、スクラムチームのメンバーは全員が Azure DevOps を扱えるようにします。
既定では、Azure DevOps の１つのチームプロジェクトに１つのチームが作られます。チームを複数作成することもできます。複数のスクラムチームが同じプロダクトゴールとプロダクトバックログを共有する場合には、１つのチームプロジェクトに複数のチームを作成します。スプリントのカンバンボードやダッシュボードは、チームごとに専用の表示（画面）が用意されたり、作成したりできます。
各チームは基本的に各スプリントで選択したプロダクトバックログアイテム（PBI）を、スプリントバックログとして計画して作業していきます。複数のチームが Azure DevOps を使う場合に、PBI がどちらのチームに選択されたか？わかりにくい場合には、エリアパスを使って分類することが出来ます。
Azure DevOps のチームプロジェクトの設定でエリアを設定します。チームの既定のエリアも設定できます。Azure DevOps の作業項目（PBI やタスク）にエリアパスを設定すると、エリアごとの作業項目を表示させることが容易になります。
エリアパスを、スクラムチームをサブチームに分けるような使い方で使用しないように気を付けます。
コメント
