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