はじめに
皆さん、ウォーターフォール（Waterfall）と呼ばれる開発手法を知っていますでしょうか。私はガチガチのウォーターフォールを経験したことがないのですが、調べた感じ以下の定義です。
ウォーターフォール (Waterfall) は、ソフトウェアやシステム開発の手法の一つで、滝のように上流から下流へと工程が流れるように、各工程を順番に完了させていく開発モデルです。要件定義から設計、開発、テストへと、工程を順に進め、前の工程に戻ることは基本的にはありません。
弊社ではハイブランドを中心したクライアント向けに、自社プロダクトのカスタマイズ納品や受託制作を行っていますが、特に受託制作では、事前に要件やデザインを詰めていても、実際に動作するものを見た時や、運用に備えたロールプレイングをした時に新たな要望や変更点が出てくる事が割と多めにあります。
そのため、クライアントのイメージするものに可能な限り近い形でクオリティ高く期日内に仕上げるためには、実際に動作するものを可能な限り早い段階で見て使っていただき、フィードバックを受け、新たな仕様を定義し、修正していく必要があります。
上記を実現させるための一つの手段として、案件によってはマイルストールをいくつか切って各マイルストーン毎に機能なり見た目のチェックを入れるタイミングを作っていたり、クライアント向けのテストアップ（要はクライアントチェック）のタイミングを複数回設けたりしています。
そういった意味で弊社で実践している手法は、ウォーターフォールとは対照的な開発手法になり、広い意味でアジャイル手法と呼べるでしょう。アジャイルの定義は以下です。
アジャイルとは、ソフトウェア開発手法の一種で、顧客のニーズを柔軟かつ迅速に反映させながら、開発を進めていく手法です。短いサイクルで開発とテストを繰り返し、成果物をリリースすることで、プロジェクトを効率的に進めます。アジャイル開発は、ビジネス環境の変化に強く、DX（デジタルトランスフォーメーション）の推進にも役立つとされています。
ではもう少し踏み込んでみると、
アジャイル手法の中で最もよく用いられるスクラムについて調べた感じ、
弊社では近い事をしているが、明確に 実践 している訳ではない、と感じました。
そこで今回は、スクラムについて調べたことを記事に残しておこうと思います。
スクラムとは
スクラムとは、アジャイル開発を実現するための一つのフレームワーク、プラクティスです。明確にスクラムガイドと言われるスクラムの基準が記された聖書が存在します。
スクラムを発明したKen Schwaber氏とJeff Sutherland氏によって2010年に初版が世に出され、そこから継続的に改版がなされており最新は2020年版です。
そして、このドキュメントには以下のように定義されています。
スクラムとは、複雑な問題に対応する適応型のソリューションを通じて、⼈々、チーム、組織が価値を⽣み出すための軽量級フレームワークである。
簡単に⾔えば、スクラムとは次の環境を促進するためにスクラムマスターを必要とするものである。
- プロダクトオーナーは、複雑な問題に対応するための作業をプロダクトバックログに並べる。
- スクラムチームは、スプリントで選択した作業を価値のインクリメントに変える。
- スクラムチームとステークホルダーは、結果を検査して、次のスプリントに向けて調整する。
- 繰り返す
※スプリントの意味については後ほど登場しますので、現段階ではマイルストーンくらいのイメージで認識をお願いします。
これから、ドキュメントの内容を掻い摘んで引用しながら、私なりの解釈で説明していきます。
スクラムの理論
- スクラムは「経験主義（＝観察から判断）」・「リーン思考（＝ムダを省く）」に基づいている
- 検査と適応のための 4 つの正式なイベントを組み合わせており、それらを包含するイベントは「スプリント」と呼ばれる
- これらのイベントが機能するのは、経験主義のスクラムの三本柱「透明性」「検査」「適応」を実現しているからである
三本柱を細かく見ていきます。
透明性
創発的なプロセスや作業は、作業を実⾏する⼈とその作業を受け取る⼈に⾒える必要がある。
スクラムにおける重要な意思決定は、3 つの正式な作成物を認知する状態に基づいている。透明性の低い作成物は、価値を低下させ、リスクを⾼める意思決定につながる可能性がある。
透明性によって検査が可能になる。透明性のない検査は、誤解を招き、ムダなものである。
オープンで障壁のないコミュニケーションを行い、プロジェクトのすべての関係者間で明確かつ率直な情報共有を促進する必要があります。これを実現するための一つのツールとして、JiraやBacklogなどのタスク管理ツールがあるような形です。
スプリントの目標、進捗状況、変更を明確化する事により、チーム内の透明性の維持、検査の実施、変化するプロジェクト・ニーズへの適応がしやすくなります。
検査
スクラムの作成物と合意されたゴールに向けた進捗状況は、頻繁かつ熱⼼に検査されなければならない。これは、潜在的に望ましくない変化や問題を検知するためである。スクラムでは、検査を⽀援するために、5 つのイベントでリズムを提供している。検査によって適応が可能になる。適応のない検査は意味がないとされる。スクラムのイベントは、変化を引き起こすように設計されている。
つまりマイルストーン毎のチェックは入念に行い、これ後で問題起きるな？など感じる点も含めた上でレビューしつつ、そのレビュー内容は、時間が余って対応できたらOK！ではなく必ず対応する必要あります。
適応
プロセスのいずれかの側⾯が許容範囲を逸脱していたり、成果となるプロダクトが受け⼊れられなかったりしたときは、適⽤しているプロセスや製造している構成要素を調整する必要がある。それ以上の逸脱を最⼩限に抑えるため、できるだけ早く調整しなければならない。
関係者に権限が与えられていないときや、⾃⼰管理されていないときは、適応が難しくなる。
スクラムチームは検査によって新しいことを学んだ瞬間に適応することが期待されている。
つまり開発者は仕様変更に対して可能な限り迅速に対応していくことで、後に大きな仕様変更が起きないようにする必要があります。
スクラムの価値基準
この5つを実践できるかどうかでスクラムの成功が決まります。
確約（Commitment）、集中（Focus）、公開（Openness）、尊敬（Respect）、 勇気（Courage）
スクラムチームは、ゴールを達成し、お互いにサポートすることを確約する。スクラムチームは、ゴールに向けて可能な限り進捗できるように、スプリントの作業に集中する。スクラムチームとステークホルダーは、作業や課題を公開する。スクラムチームのメンバーは、お互いに能⼒のある独⽴した個⼈として尊敬し、⼀緒に働く⼈たちからも同じように尊敬される。スクラムチームのメンバーは、正しいことをする勇気や困難な問題に取り組む勇気を持つ。
これらの価値基準は、スクラムチームの作業・⾏動・振る舞いの⽅向性を⽰している。下される意思決定、実⾏される⼿順、スクラムの使⽤⽅法は、これらの価値基準を減少や弱体化させるものではなく、強化させるものでなければならない。スクラムチームのメンバーは、スクラムのイベントや作成物を⽤いながら、これらの価値基準を学習および探求する。これらの価値6基準がスクラムチームや⼀緒に働く⼈たちによって具現化されるとき、経験主義のスクラムの三本柱「透明性」「検査」「適応」に息が吹き込まれ、信頼が構築される。
要は、それぞれの開発者が自立的にスプリントの作業をこなすことに集中し、困難であっても仕様的に正しいと思えることを探究し、勇気を持って取り組む必要があります。そしてその振る舞いをしようとすることに対してお互いに尊敬し合うチームである必要があり、その困難な問題が独力で解決できない場合はプライドを捨ててチーム内に明確に公開し、チームメンバー同士でサポートしあいながら達成させるような関係を構築します。
スクラムチーム
スクラムの基本単位は、スクラムチームという⼩さなチームである。スクラムチームは、スクラムマスター1 ⼈、プロダクトオーナー1 ⼈、複数⼈の開発者で構成される。スクラムチーム内には、サブチームや階層は存在しない。これは、⼀度にひとつの⽬的（プロダクトゴール）に集中している専⾨家が集まった単位である。
スクラムチームは、それぞれのメンバーが自立的に各スプリントをこなすことができるレベルである必要があります。
開発者
開発者はスクラムチームの⼀員である。各スプリントにおいて、利⽤可能なインクリメントのあらゆる側⾯を作成することを確約する。
開発者は常に次の結果に責任を持つ。
- スプリントの計画（スプリントバックログ）を作成する。
- 完成の定義を忠実に守ることにより品質を作り込む。
- スプリントゴールに向けて毎⽇計画を適応させる。
- 専⾨家としてお互いに責任を持つ。
こちらに関しては、上記のスクラムの価値基準に基づき行動する人、という形です。
プロダクトオーナー
プロダクトオーナーは、スクラムチームから⽣み出されるプロダクトの価値を最⼤化することの結果に責任を持つ。組織・スクラムチーム・個⼈によって、その⽅法はさまざまである。
プロダクトオーナーは、効果的なプロダクトバックログ管理にも責任を持つ。たとえば、
- プロダクトゴールを策定し、明⽰的に伝える。
- プロダクトバックログアイテムを作成し、明確に伝える。
- プロダクトバックログアイテムを並び替える。
- プロダクトバックログに透明性があり、⾒える化され、理解されるようにする。
上記の作業は、プロダクトオーナーが⾏うこともできるが、他の⼈に委任することもできる。
いずれの場合も、最終的な責任はプロダクトオーナーが持つ。
記載の通り組織によって様々ではあると思いますが、弊社の受託制作案件で言うとテクニカルディレクションチーム（営業と開発者の間に立ち、案件を成功させるためのディレクションを行う人。弊社内で使用している言葉です）の担当者がプロダクトオーナーに近い仕事をしているかと思います。ただ、弊社ではプロダクトバックログアイテムの作成・並び替えなどは開発者が行っている形となります。
スクラムマスター
スクラムマスターは、スクラムガイドで定義されたスクラムを確⽴させることの結果に責任を持つ。スクラムマスターは、スクラムチームと組織において、スクラムの理論とプラクティスを全員に理解してもらえるよう⽀援することで、その責任を果たす。
スクラムマスターは、スクラムチームの有効性に責任を持つ。スクラムマスターは、スクラムチームがスクラムフレームワーク内でプラクティスを改善できるようにすることで、その責任を果たす。
スクラムの価値基準に基づきチームが動けるようにテコ入れをする役割の人です。
スクラムマスターは、さまざまな形でスクラムチームを⽀援する。
- ⾃⼰管理型で機能横断型のチームメンバーをコーチする。
- スクラムチームが完成の定義を満たす価値の⾼いインクリメントの作成に集中できるよう⽀援する。
- スクラムチームの進捗を妨げる障害物を排除するように働きかける。
- すべてのスクラムイベントが開催され、ポジティブで⽣産的であり、タイムボックスの制限が守られるようにする。
スプリントを達成するために自立的に動くメンバーが困っている時に技術的サポートしたり、例えばシステムのコアとなる機能開発・メンバーの成長に最も必要な機能開発に注力できるよう技術面・事前知識の注入、タスクの優先順位の定義、時には他タスクの巻き取りを行ったりする必要があります。また、障害物の定義は難しいですが、例えばスクラムチーム以外の関係者のレビューにより新規で加わる（そんなに重要でない）仕様追加などで、スプリントの達成が危ぶまれる場合は、その追加仕様を巻き取るか？そもそもその仕様の必要性は妥当か？など諸々調整する働きも必要とされるでしょう。
スクラムマスターは、さまざまな形でプロダクトオーナーを⽀援する。
- 効果的なプロダクトゴールの定義とプロダクトバックログ管理の⽅法を探すことを⽀援する。
- 明確で簡潔なプロダクトバックログアイテムの必要性についてスクラムチームに理解してもらう。
- 複雑な環境での経験的なプロダクト計画の策定を⽀援する。
- 必要に応じてステークホルダーとのコラボレーションを促進する。
スクラムマスターは、さまざまな形で組織を⽀援する。- 組織へのスクラムの導⼊を指導・トレーニング・コーチする。
- 組織においてスクラムの実施⽅法を計画・助⾔する。
- 複雑な作業に対する経験的アプローチを社員やステークホルダーに理解・実施してもらう。
- ステークホルダーとスクラムチームの間の障壁を取り除く。
これらの記述にもよく出てくるフレーズである支援、促進、コーチなどの文言からわかるように、スクラムマスターは メインの開発担当者ではない という事です。
ここに、スクラムチームの開発者一人一人が自立的に責任を持って行動するという価値基準が表れています。
弊社では各開発チーム単位でリーダーが在籍しています。
毎回の案件という訳ではないですが、リーダーがスクラムマスターに近い動きをし、各メンバーが自立的に開発に集中できるようサポートしています。
スクラムイベント
スプリントは他のすべてのイベントの⼊れ物である。スクラムにおけるそれぞれのイベントは、スクラムの作成物の検査と適応をするための公式の機会である。これらのイベントは必要な透明性を実現するために明確に設計されている。規定通りにイベントを運⽤しなければ、検査と適応の機会が失われる。スクラムにおけるイベントは、規則性を⽣み、スクラムで定義されていない会議の必要性を最⼩限に抑えるために⽤いられる。すべてのイベントは、複雑さを低減するために、同じ時間と場所で開催されることが望ましい。
私は最初、スプリントを作るという事は会議が増えるのでは？と考えていました。
しかし定義としては、スクラムで定義されていない会議の必要性を最⼩限に抑えるために⽤いられるようです。大事なことは、決めたスプリントごとに検査と適応を規定通りに運用すること。を守り切る必要があると言う事です。
スプリント
スプリントはスクラムにおける⼼臓の⿎動であり、スプリントにおいてアイデアが価値に変わる。
⼀貫性を保つため、スプリントは 1 か⽉以内の決まった⻑さとする。前のスプリントが終わり次第、新しいスプリントが始まる。
スプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブを含む、プロダクトゴールを達成するために必要なすべての作業は、スプリント内で⾏われる。
1ヶ月以内に1スプリントを定義をするという形ですが、その中で
スプリントプランニング、デイリースクラム、スプリントレビュー、スプリントレトロスペクティブ という作業があります。
それぞれについて記載していきます。
スプリントプランニング
スプリントプランニングはスプリントの起点であり、ここではスプリントで実⾏する作業の計画を⽴てる。
スプリントプランニングは次のトピックに対応する：
トピック 1：このスプリントはなぜ価値があるのか？
プロダクトオーナーは、プロダクトの価値と有⽤性を今回のスプリントでどのように⾼めることができるかを提案する。次に、スクラムチーム全体が協⼒して、そのスプリントになぜ価値があるかをステークホルダーに伝えるスプリントゴールを定義する。スプリントゴールは、スプリントプランニングの終了までに確定する必要がある。
スプリントを作ることの価値を定義し、関係者に伝える。
トピック 2：このスプリントで何ができるのか？
開発者は、プロダクトオーナーとの話し合いを通じて、プロダクトバックログからアイテムを選択し、今回のスプリントに含める。スクラムチームは、このプロセスの中でプロダクトバックログアイテムのリファインメントをする場合がある。それによって、チームの理解と⾃信が⾼まる。
スプリント内でどれくらい完了できるかを選択するのは難しいかもしれない。しかしながら、開発者が過去の⾃分たちのパフォーマンス、今回のキャパシティ、および完成の定義の理解を深めていけば、スプリントの予測に⾃信が持てるようになる。
決めたスプリントでは何が検査できるのか？を定義する。
トピック 3：選択した作業をどのように成し遂げるのか？
開発者は、選択したプロダクトバックログアイテムごとに、完成の定義を満たすインクリメントを作成するために必要な作業を計画する。これは多くの場合、プロダクトバックログアイテムを 1 ⽇以内の⼩さな作業アイテムに分解することによって⾏われる。これをどのように⾏うかは、開発者だけの裁量とする。プロダクトバックログアイテムを価値のインクリメントに変換する⽅法は誰も教えてくれない。
スプリントゴール、スプリント向けに選択したプロダクトバックログアイテム、およびそれらを提供するための計画をまとめてスプリントバックログと呼ぶ。
スプリントが 1 か⽉の場合、スプリントプランニングのタイムボックスは最⼤で 8 時間である。
スプリントの期間が短ければ、スプリントプランニングの時間も短くすることが多い。
決めたスプリントの達成のために必要なタスクを洗い出す。
デイリースクラム
デイリースクラムの⽬的は、計画された今後の作業を調整しながら、スプリントゴールに対する進捗を検査し、必要に応じてスプリントバックログを適応させることである。
デイリースクラムは、スクラムチームの開発者のための 15 分のイベントである。複雑さを低減するために、スプリント期間中は毎⽇、同じ時間・場所で開催する。プロダクトオーナーまたはスクラムマスターがスプリントバックログのアイテムに積極的に取り組んでいる場合は、開発者として参加する。
開発者は、デイリースクラムがスプリントゴールの進捗に焦点をあて、これからの 1 ⽇の作業の実⾏可能な計画を作成する限り、必要な構造とやり⽅を選択できる。これは集中を⽣み出し、⾃⼰管理を促進する。
デイリースクラムは、コミュニケーションを改善し、障害物を特定し、迅速な意思決定を促進する。その結果、他の会議を不要にする。
開発者が計画を調整できるのは、デイリースクラムのときだけではない。スプリントの残りの作業を適応または再計画することについて、より詳細な議論をするために、開発者は⼀⽇を通じて頻繁に話し合う。
毎日15分間どこかの時間を使って進捗確認を行い、1日の作業計画の再考のタイミングを設けます。これをやるから他の会議は削減できるという思想な訳ですね。このタイミングで障害物（行き詰まっていることなど）を明確にし、チームでサポートするなどの方針を明確化します。
スプリントレビュー
スプリントレビューの⽬的は、スプリントの成果を検査し、今後の適応を決定することである。
スクラムチームは、主要なステークホルダーに作業の結果を提⽰し、プロダクトゴールに対する進捗について話し合う。
スプリントレビューにおいて、スクラムチームとステークホルダーは、スプリントで何が達成され、⾃分たちの環境で何が変化したかについてレビューする。この情報に基づいて、参加者は次にやるべきことに協⼒して取り組む。新たな機会に⾒合うようにプロダクトバックログを調整することもある。スプリントレビューはワーキングセッションであり、スクラムチームはスプリントレビューをプレゼンテーションだけに限定しないようにする。
このタイミングで検査し、今後の適応を決定します。
既に申し上げている通り、適応をちゃんと実行しない検査は意味がないので、タスク化するなら確実にやり切る意思と行動が必要となります。
スプリントレトロスペクティブ
スプリントレトロスペクティブの⽬的は、品質と効果を⾼める⽅法を計画することである。
スクラムチームは、個⼈、相互作⽤、プロセス、ツール、完成の定義に関して、今回のスプリントがどのように進んだかを検査する。多くの場合、検査する要素は作業領域によって異なる。
スクラムチームを迷わせた仮説があれば特定し、その真因を探求する。スクラムチームは、スプリント中に何がうまくいったか、どのような問題が発⽣したか、そしてそれらの問題がどのように解決されたか（または解決されなかったか）について話し合う。
スクラムチームは、⾃分たちの効果を改善するために最も役⽴つ変更を特定する。最も影響の⼤きな改善は、できるだけ早く対処する。次のスプリントのスプリントバックログに追加することもできる。
要は決めたスプリントを達成するために行なった様々な行動について振り返りを行い、うまくいった点、うまくいかなかった点、問題を解決した（解決しなかった）点について話し合い、次のスプリントに生かすという動きをします。
スクラムの作成物
スクラムの作成物は、作業や価値を表している。これらは重要な情報の透明性を最⼤化できるように設計されている。作成物を検査する⼈が、適応するときと同じ基準を持っている。
つまり、作ったもの価値や進捗を図るものは、ずばり作成物である。という事。
各作成物には、透明性と集中を⾼める情報を提供する「確約（コミットメント）」が含まれている。これにより進捗を測定できる。
- プロダクトバックログのためのプロダクトゴール
- スプリントバックログのためのスプリントゴール
- インクリメントのための完成の定義
しかしながら、その作成物の透明性を保証したり、開発者が目標に対して集中して作業するための指標として上記3種があり、バックログ管理されるべきという話です。
プロダクトバックログ
プロダクトバックログは、創発的かつ順番に並べられた、プロダクトの改善に必要なものの⼀覧である。これは、スクラムチームが⾏う作業の唯⼀の情報源である。
作業を⾏う開発者は、その作業規模の評価に責任を持つ。開発者がトレードオフを理解して選択できるように、プロダクトオーナーが開発者を⽀援することもできる。
確約（コミットメント）：プロダクトゴール
プロダクトゴールは、プロダクトの将来の状態を表している。それがスクラムチームの計画のターゲットになる。プロダクトゴールはプロダクトバックログに含まれる。プロダクトバックログの残りの部分は、プロダクトゴールを達成する「何か（what）」を定義するものである。
プロダクトとは価値を提供する⼿段である。プロダクトは、明確な境界、既知のステークホルダー、明確に定義されたユーザーや顧客を持っている。プロダクトは、サービスや物理的な製品である場合もあれば、より抽象的なものの場合もある。
プロダクトゴールは、スクラムチームの⻑期的な⽬標である。次の⽬標に移る前に、スクラムチームはひとつの⽬標を達成（または放棄）しなければならない。
これはそのままの意味で、プロダクトのゴールを定義し、それを達成させるためにプロダクトバックログを整備し、開発者が作業をします。
スプリントバックログ
スプリントバックログは、スプリントゴール（なぜ）、スプリント向けに選択されたいくつかのプロダクトバックログアイテム（何を）、およびインクリメントを届けるための実⾏可能な計画（どのように）で構成される。
スプリントバックログは、開発者による、開発者のための計画である。スプリントバックログには、スプリントゴールを達成するために開発者がスプリントで⾏う作業がリアルタイムに反映される。その結果、より多くのことを学ぶにつれて、スプリントの期間を通して更新される。
スプリントバックログはデイリースクラムで進捗を検査できる程度の詳細さが必要である。
確約（コミットメント）：スプリントゴール
スプリントゴールはスプリントの唯⼀の⽬的である。スプリントゴールは開発者が確約するものだが、スプリントゴールを達成するために必要となる作業に対しては柔軟性をもたらす。スプリントゴールはまた、⼀貫性と集中を⽣み出し、スクラムチームに⼀致団結した作業を促すものでもある。
スプリントゴールは、スプリントプランニングで作成され、スプリントバックログに追加される。開発者がスプリントで作業するときには、スプリントゴールを念頭に置く。作業が予想と異なることが判明した場合は、スプリントゴールに影響を与えることがないように、プロダクトオーナーと交渉してスプリントバックログのスコープを調整する。
スプリントのゴールを定めて、スプリントバックログに追加する。
また、スプリントバックログはデイリースクラムで進捗を検査できる程度の詳細さでないといけない。予想と異なりスコープが大きすぎる場合は、プロダクトオーナーと交渉してスコープを調整する必要があります。開発着手してみて初めてわかることは出てくることもあるかと思うので、調整が必要なタイミングもあるでしょう。ここで場合によっては、スクラムの価値基準に基き、スクラムマスターがサポートに入ることなどの検討も必要となります。
インクリメント
インクリメントは、プロダクトゴールに向けた具体的な踏み⽯である。インクリメントはこれまでのすべてのインクリメントに追加する。また、すべてのインクリメントが連携して機能することを保証するために、徹底的に検証する必要がある。価値を提供するには、インクリメントを利⽤可能にしなければならない。
スプリントでは、複数のインクリメントを作成可能である。インクリメントをまとめたものをスプリントレビューで提⽰する。それによって、経験主義がサポートされる。ただし、スプリント終了前にインクリメントをステークホルダーにデリバリーする可能性もある。スプリントレビューのことを価値をリリースするための関⾨と⾒なすべきではない。
確約（コミットメント）：完成の定義
完成の定義とは、プロダクトの品質基準を満たすインクリメントの状態を⽰した正式な記述である。
プロダクトバックログアイテムが完成の定義を満たしたときにインクリメントが誕⽣する。
完成の定義により、作業が完了してインクリメントの⼀部となったことが全員の共通認識となり、透明性が⽣み出される。プロダクトバックログアイテムが完成の定義を満たしていない場合、リリースすることはできない。ましてやスプリントレビューで提⽰することもできない。
そうした場合、あとで検討できるようにプロダクトバックログに戻しておく。
要は、複数のタスクが完了し、「プロダクトの品質基準を満たす価値が確実に積み上がった」という状態かつそれが全員の共通認識としてある状態をインクリメントと定義し、完成の定義としている認識です。
さいごに
スクラムガイドに則ってチーム開発するかどうか？は組織の開発案件内容・開発規模・期間・人員など、様々な要因を加味した上で検討する必要があると思いますが、スクラムガイドに完全に則らなくても、一部取り入れても良いかもしれないと感じる部分はあります。
個人的に、スクラムチーム内にはサブチームや階層は存在せず、⼀度にひとつの⽬的（プロダクトゴール）に集中している専⾨家が集まった単位である。という定義が私が目指すチーム像に近いので好きです。