コンテンツにスキップ
Scrum Knowledge Graph

スクラムチーム (Scrum Team)

概要

Section titled “概要”

スクラムチームは、複雑な課題に対して価値あるインクリメントを反復的かつ漸進的に創出する、スクラムにおける基本的な自律的価値創造単位である。プロダクトオーナー、スクラムマスター、開発者で構成され、内部に階層を持たず単一のプロダクトゴールに向けて全責任を共有する。「機能横断性」と「自己管理性」を核とし、通常10人以下（3〜9人程度）の小規模体制で作業を自律的に組織する。チームの成熟やManagement 3.0等の導入に伴いエンパワーメントやリーダーシップの共有が進む一方、教育やDevOpsなど多様な領域にも展開される。大規模環境や地理的に分散した開発においては、共通目標の共有や依存関係の管理を重視しつつ、トップダウンの統制とボトムアップの自律性の均衡を図りながら全体目標の達成を目指す。

詳細

Section titled “詳細”

構成と基本的な性質

Section titled “構成と基本的な性質”

スクラムチームの各役割は明確に定義されており、内部に明示的な階層構造やサブチーム、従来のプロジェクトマネージャーは存在せず[1]、全員が対等なプロフェッショナルとして協力し[2]、チーム自身で作業を組織して各スプリントでの成果物にコミットメントする責任を持つ[1]。現在では1人のプロダクトオーナー、1人のスクラムマスター、および複数の開発者（デベロッパー／スクラムチームメンバー）という構成の専門家チームとして定義されている[3][4][5][6][7][8][9]。メンバー個別の責任を限定する肩書きやサブチームは存在せず、チーム全体で成果に共同責任を持ち[10][3][7]、持続可能なペースを維持しながら最適化を図り[5]、プロダクトの全ライフサイクルに対して説明責任を負う[2][8][9]。

構成員と役割の変遷・体制・テイラリング

Section titled “構成員と役割の変遷・体制・テイラリング”

初期の定義では「スクラムマスター、プロダクトオーナー、チーム」という明確な役割分担のもとで構成されていた[11][12]。その後の改訂では「プロダクトオーナー、開発チーム、スクラムマスター」という3つの役割による構成表記を経た[13][14][15][16]。一方で、LeSS版スクラムガイドにおいては「スクラムチーム」という用語・全体概念の定義自体は取り払われ、「チーム」と「プロダクトオーナー」という簡素化された構造が採用されている[10]。これは役割の階層を減らし、全員がプロダクトビジョンの達成に直接フォーカスすることを意図している[10]。役割間の関係性と相互作用はスクラムのルールによって規定される[14]。また、顧客ニーズを価値あるソリューションへ変換するために、多分野の役割を備えたクロスファンクショナルな体制を構成する[17][7]。 一方で、実際の開発現場においてはプロダクトオーナーやスクラムマスターを置かない構造や他役割との兼務といったテイラリングの存在が報告されており、チームの成熟度を理由にスクラムマスターを置かない体制を採ることもある[18]。特定ドメインにおいては、教育研究者がプロダクトオーナーを兼ねることで学術的研究目標と実用的なプロダクト開発のバランスを最適化するような体制も実践されている[19]。さらに、プロジェクト駆動型の組織構造の中にあっても安定したプロダクトチームとして編成され、ソフトウェアアーキテクトなどの専門性を含む体制が採られることもある[20]。大規模アジャイル開発の実践事例においても、スクラムマスター、技術アーキテクト、機能アーキテクト、テスト担当者、および4〜5名の開発者からなる混成チームとしてスクラムチームが編成される形態が報告されている[21]。ただし、スクラムの理念から乖離したチーム設計は、アジャイル原則に反するアドホックな開発を引き起こしやすい点に注意が必要である[18]。同じ調査では、スクラムマスターの役割がチームと共有されていたのは、回答者の 20.90% だった[22]。

目的・価値提供と説明責任

Section titled “目的・価値提供と説明責任”

スクラムチームのモデルは柔軟性、創造性、生産性を最適化するように設計されている[11][12][13][14][15][16][6][1][7]。複雑なプロダクトを反復的かつ漸進的なプロセスで「完成」したプロダクトインクリメントとして届けることでフィードバックの機会を最大化する[13][14][15][16][3][7]。チームが自己組織化されている組織では、そのような行動が見られない組織よりもプロジェクトの成功確率が高くなる[23]。デイリーミーティングやバックログなどのプラクティスを活用して短いサイクルで自律的に開発を進め[17]、プロセス全体の作成と適応および継続的改善を行いながら、要求された出荷可能で価値の高いプロダクトインクリメントをデリバリーする[7][6][2]。しかし実務においては、「タスクが完了したかどうかに関する合意が得られない（完成の定義の不一致）」という反パターンも調査され、表IXの重み付けスコアは27.38%（満点168に対する割合で、組織の割合ではない）であった[24]。チーム内での品質基準や共通認識の共有不足が成果物のデリバリーにおける反パターンとして現れることがある[24]。なお、組織規模の拡大時においても、自律して価値を創出する最小構築ブロック（最小構成単位）およびリファレンスモデル（参照モデル）として位置づけられる[5]。

機能横断性（必要なスキルをチーム内に備える）

Section titled “機能横断性（必要なスキルをチーム内に備える）”

チームに必要なスキルを内部に備えることはパフォーマンス向上に不可欠である[8]。各スプリント終了時までに出荷判断・利用可能なプロダクトインクリメントを作成するために必要なすべての知識と専門スキルをチーム内部に保持し[11][12][13][14][15][16][1]、インクリメントの設計、実装、テストを行って出荷可能な品質を確保する[6][2]。メンバー同士が互いの専門領域や役割を理解し、共通の目的に向けて異なる専門知識を持つメンバー間で迅速に支援や引き継ぎを行うクロスファンクショナルな協調体制がとられる[25][19]。アイデア出しから実装・リリースまでに前工程を挟むことなく、独立して一連のプロセスを遂行できる体制が重視される[5][6][7]。さらにインクルーシブな開発の文脈では、障がいを持つ教育者や学生などのエンドユーザー・ステークホルダーを単なる被験者として扱うのではなく、チーム内の共同設計パートナー（co-designers）として位置づけ、チーム全体でアクセシビリティに対する共同所有意識を育むクロスファンクショナルな体制が実践される[19]。一方で、開発現場の実態としては開発者やテスターの専門分化が固定化してしまい、スプリント内でテストまで完了できないチーム体制が散見されるなど、真の機能横断性の確立が阻害される反パターンも指摘されている[24]。同様に大規模開発の文脈においても、開発者、テスター、アーキテクトなどの専門家をチーム内に統合してエンドツーエンドで機能を開発できる体制を目指すものの、実際には専門特化が依然として残る場合がある[26]。継続的テストを導入した 2 年間のアクションリサーチ（インド拠点の 50 人のスクラムチーム、1 社）の対象チームは、厳格な役割分担のない開発エンジニアとテストエンジニアで構成される機能横断型のチームだった[27]。

自己管理（誰が・何を・どのように行うかをチームが決める）

Section titled “自己管理（誰が・何を・どのように行うかをチームが決める）”

2020年版のスクラムガイドでは、以前の版よりもスクラムチームの自己管理に重点が置かれ、誰が何を・いつ・どのように行うかをスクラムチーム内で決定する「自己管理型」のチームと定められた[3]。プロジェクトマネージャーなどの指示役に依存せず自分たちで作業を定義・管理する体制が特徴である[1][8]。複数チームでの協働時においても、各チームが全体の「完成の定義」を満たすよう自己管理し、統合されたインクリメントの作成に貢献する[4]。とりわけタスク実行の自律性においては、機能の設計、実装、テストといった具体的な開発作業についてチームが完全な実行権限と責任を保持する[26][25]。ドイツの 5 つのアジャイルチーム（観察とインタビューによるグラウンデッド・セオリー）では、チーム内の役割に対する理解が不完全なとき、チームの自己管理が極めて難しくなるという知見が得られた[28]。7 チーム・約 50 人の開発者を持つ事業部のアクションリサーチ（1 組織）では、第 3 の介入からの主な学びとして、チームに自己組織化を任せるだけでは品質プラクティスの定着に不十分だったと報告された[29]。12 の開発チーム・175 人が関与したノルウェーの超大規模開発プログラムの事例研究では、機能アーキテクトなどの追加の役割やオープンスペースなどの場が、チームの自律性の低下につながったと解釈された[30]。

チームの有効性と成熟

Section titled “チームの有効性と成熟”

チームの有効性（Scrum Team Effectiveness）は、応答性（responsiveness）・ステークホルダーへの配慮・関心（stakeholder concern）・継続的改善（continuous improvement）・チームの自律性（team autonomy）・マネジメントの支援（management support）という5つの要因に大きく依存すると理論化されている[8]。外部からの指示に頼らない自己管理性と、必要なスキルを内部に備える機能横断性を高めることがパフォーマンス向上に不可欠である[8]。明確な責務のもと相互に協力し、共通目標に向かって進む姿勢もまた有効性に寄与する[9]。一方で、アジャイルのプラクティスを導入しているチームであっても、チーム自体の成熟度が低ければ高いパフォーマンスを発揮できず、初期段階では適切な管理や支援が必要となる[31]。チームが成熟するにつれて、スクラムマスターが担っていた複数のリーダーシップ役割をチームメンバー自身が引き受けて協調的に推進する「リーダーシップの共有（シェアードリーダーシップ）」へと進化する[25]。また、対等な関係性のもとで相互信頼と心理的安全性を築き、問題が発生した際には即座に対話し、互いにフィードバックを提供し合う開かれたコミュニケーション文化を形成することが有効な協働を支える[25]。さらに集団で作業する際、個人が単独で作業する場合と比べて努力量を減少させてしまう現象（社会的怠惰／ソーシャル・ローフィング）がチームの協調において観察されることがある[31]。加えて実際の開発組織では、「会議に全員が積極的に参加しない」という反パターンも調査され、表IXの重み付けスコアは32.14%（満点168に対する割合で、組織の割合ではない）であった[24]。チーム全体でのオーナーシップ共有や主体的関与の欠如が機能不全を招く要因として報告されている[24]。アジャイルチーム有効性モデル（ATEM）は、共有メンタルモデル、コミュニケーション、相互信頼の3つを主要な調整メカニズムとし、これらがアジャイル環境におけるチームの有効性に大きな影響を与えると仮定している[32]。Scrum チームのメンバー 182 人への調査（自己申告の横断データ）では、チームが存続してきた期間で測った成熟度と、成功しているという認識の間に中程度の関連（γ=0.537）があり、長く存続しているチームほど成功の認識が高かった[33]。Strode らは、同一拠点のアジャイル開発チーム向けに、5 つの構成要素と 3 つの調整メカニズムからなる有効性モデル（ATEM）を提案した（モデルの優劣や構成要素どうしの関係は未検証）[34]。ロバート・ボッシュの 75 人へのグラウンデッド・セオリー研究（1 社）では、スクラムマスターが担う 9 つのリーダーシップの役割は、初期段階ではむしろ 1 人の専任スクラムマスターに集中し、より成熟したチームではむしろ分散していた[35]。

チームの規模と複数チームの連携・制約

Section titled “チームの規模と複数チームの連携・制約”

敏捷性と高い生産性を維持するための適正人数について、かつては「通常7±2名」とされていたが[12][1]、現在では「通常10人以下（プロダクトオーナーとスクラムマスターを含む）」という小規模構成が標準として定義されている[3][10][5][7]。理想的な規模を6〜9名程度とする見解や、研究・文脈によって4〜5人程度を最適とする主張が存在する一方、現場や組織によっては3〜5名のより小さな構成から10名規模の構成まで幅広く実践されている[5][9][20]。しかし、チーム規模が25人を超えるような過大な拡大や、フロントエンドとバックエンドの技術領域を無理に1つのチームに集約して推奨最大人数（10人程度）を大幅に超過した場合には、チームが機能不全に陥ることがある[31]。また、リモートワーク環境下においては、チーム規模が拡大するほどコミュニケーションの遅延や調整上の摩擦が増大しやすいため、規模の適正化には留意を要する[9]。並びに、認知的多様性を保持しつつ小規模さを保つことが推奨される[2]。 大規模展開においては、およそ3〜9のスクラムチームが単一プロダクトの開発のために集まり、共通のプロダクトゴールおよび単一のプロダクトバックログに向けて連携する構造が採られる（Nexusなど）[4]。各チームは共有されたプロダクトバックログからアイテムを選択し、チーム間の依存関係を認識・削減しながら自律的にスプリントを推進する[4]。適切なメンバーが統合チームや共通イベントに代表として参加することで全体連携が図られる[4]。ただし、大規模プロジェクトにおいて数百人・多数のチームが並行稼働する状況ではチーム間の連携・調整が最大の課題となり、他チームとの依存関係の認識不足や共通メンタルモデルの欠如がプロジェクトの失敗を招く要因となる[31]。これに対し、マルチチームシステム（大規模アジャイル開発）の実践では、12の機能チーム（スクラムチーム）が編成され、3週間のイテレーションサイクルに従って作業し、共通のデモンストレーション日に成果を提示する体制が採られる[21]。そこでは相互依存関係を管理してシステム全体の目標達成を担うため、デイリースタンドアップ、スクラム・オブ・スクラム、メタ・スクラムといった公式な連携メカニズムを活用しつつ、同一フロアへの近接配置によってチーム間の共有メンタルモデルや信頼関係を構築するアプローチが実践されている[21]。 なお、チーム規模の大小やメンバーの成熟度に応じて、特定イベントの参加者を制限するなど協働構造を変更したり、役割の省略・調整がなされたりする場合もある[18]。さらに、大規模環境では単一チームが完全に独立して自律性を発揮することは難しく、組織全体の整合性や他チームとの依存関係の管理との間でバランスを取る必要がある[26]。チーム全体のアーキテクチャ方針、品質基準、共通ツールの利用などは個々のチームの裁量を超えてプロジェクト全体で統一される組織的制約を受ける一方で、チーム代表や専門家が参加するコミュニティを形成することで、トップダウンの統制に頼らずボトムアップでチームが上位の意思決定や方向性設定、チーム設計、プロセス定義に関与する形態が有効に機能する[26]。大規模なアジャイル ERP 変革プログラム 1 件のケーススタディでは、各スクラムチームは 7〜12 名のメンバーで構成されていた[36]。 大規模アジャイル変革の文献レビュー（一次文献の大半は体験報告）が紹介する 1 つの事例では、Scrum-of-Scrums による調整は最大 5 チームまでは機能したが、チームが自分たちの作業に集中し、新しいプラクティスがコミュニケーション経路を狭めたため、グローバルなレベルにはスケールしなかった[37]。

自律的なチームと作業の共有

Section titled “自律的なチームと作業の共有”

プロダクトオーナーとスクラムマスターも自己組織化されたスクラムチームの正式なメンバーであり、開発作業・PO作業・SM作業といったチームのあらゆる作業を共有し合う自律的チームとして機能することが強調されている[38]。また、プロダクトは単なる成果物ではなくチームが提供する「成果（Outcomes）」であると捉えられる[38]。規模の異なる 10 社の専門家 13 人（アジャイルリーダーを自認）への半構造化インタビューでは、リーダーシップはチームメンバー間で動的に共有され、チームへの帰属意識を生み出し、対立する組織文化のバランスを取ることに関わると報告された[39]。

作業の流れ（フロー）と継続的改善

Section titled “作業の流れ（フロー）と継続的改善”

進行中の作業（WIP）制限やアクティブな作業管理を通じて、自己管理、フォーカス、確約（コミットメント）、コラボレーションを向上させることが求められる[40]。また、各種スクラムイベントを通じてワークフローの定義やフロー指標（流れの指標）を検査・適応し、継続的な改善のフィードバックループを自ら創出する[40]。

開発手法・領域特化のプラクティスとの連携

Section titled “開発手法・領域特化のプラクティスとの連携”

ビヘイビア駆動開発（BDD）やオントロジーを活用するアプローチにおいては、スクラムチームが受入テストの作成やユビキタス言語に基づく実装を直接担い、高品質な成果物の作成とスプリント目標の達成を目指す[6]。

DevOpsのプラクティスとデリバリー指標の活用

Section titled “DevOpsのプラクティスとデリバリー指標の活用”

アジャイルやカンバンに加え、CI/CDプロセス（Jenkins等）やコンテナ基盤（OpenShift、Docker等）を活用したDevOpsプラクティスを統合して導入する事例がある[20]。安定した基幹プロダクトチーム等において、週1回の定期会議等で自動測定された4つの主要指標（FKM：デプロイ頻度、変更リードタイム、サービス復旧時間、変更失敗率）を継続的に監視・議論する実践が報告されている[20]。Jira等の課題管理システムを活用したインシデント起票から解決までの追跡データによる自動算出などを通じ、プルリクエストの早期マージやフィーチャーフラグの活用促進、デプロイに対する不安や痛みの軽減、改善に向けた責任感やチーム一体感の向上がもたらされる[20]。

実験と創発的なソリューション

Section titled “実験と創発的なソリューション”

短時間かつ失敗しても安全な実験と継続的なフィードバックを通じ、創発的なソリューションを生み出すアプローチを実践する[2]。

セキュリティ要件の定義とセキュアな開発での連携

Section titled “セキュリティ要件の定義とセキュアな開発での連携”

プロダクトオーナーやステークホルダーと密接に連携してセキュリティ要件の定義や優先順位付けを行い、セキュリティ課題の促進要因および阻害要因をチーム内で協働して特定・明確化することで、安全性を考慮したセキュアなソフトウェア開発する・推進する[41]。

教育・能動的学習（eduScrum）への展開

Section titled “教育・能動的学習（eduScrum）への展開”

教育現場におけるeduScrum手法では、学生のグループによってチームが構成され、能動的な学習プロセスを自律的に遂行する学習単位として機能する[42]。教師から細かな指示を直接受けるのではなく、提示された学習目標を達成するためにチームで協力してタスクや課題の解決に取り組み、受動的な講義の聴講から能動的な知識獲得と責任の分担へと転換を図る[42]。またオンライン環境下においても、自己紹介やチームビルディングを経て編成され、オープンな対話を通じてスクラムマスターを選出するなど自己組織的に運営される[42]。

完成の定義（DoD）は、プロダクトのインクリメントを完成させるものは何かについて、スクラムチームが持つ共通見解を表す[43]。

リモートワークへのスクラム実践の適応を扱ったデルファイ調査（予備的）では、対面コミュニケーションの不足を補うため、チームが専用のチームビルディングセレモニーを導入し、その形式にはゲーム、カジュアルな雑談、ソーシャルアクティビティなどが含まれると報告された[44]。

大規模アジャイル開発の2社の事例では、スクラムマスターが持ち回りで専属のプロダクトオーナー役もなく、リファインメントミーティングの継続性を欠いていた[45]。

鉄道向けの研究開発 1 件で検証された Scrum for Safety（S4S）では、検証者・妥当性確認者・評定者はスクラムチームの外部の人員とされ、テストの正確性、要件の妥当性、規格への適合を監督する[46]。

スクラムチームは、スクラムマスター、プロダクトオーナー、開発者の3つの役割で構成され、共通の目標達成に向けて自律的に機能する自己管理型のチームである[47]。

スクラムチームは、自己管理型で機能横断型の構造的特徴に加え、感情知能や心理的安全性などの社会感情的力学を持つ協働単位である[48]。

分類・所属

Section titled “分類・所属”
  • 所属タグ: Scrum LeSS Self-Management Cross-Functional
  • カテゴリー: Scrum Core

オントロジー上の位置

Section titled “オントロジー上の位置”

Process Constraints (プロセス制約)

Section titled “Process Constraints (プロセス制約)”

SRO (Scrum Reference Ontology) に基づく、この概念に関係する制約です。各制約の括弧内は、その制約が対象とするクラスです。

  • S7 (ScrumTeam): スクラムチームは正確に1人のスクラムマスターを持たなければなりません。スクラムマスターを置かない、またはプロジェクトマネージャー・チームリード・開発者などがスクラムマスターを兼ねるテーラリングが報告されています。スクラムマスターを置かない理由としては、チームが自らを十分に成熟していると考えていたことが挙げられています（Özkan & Özcan-Top, 2022）。
  • S7 (ScrumTeam): スクラムマスターとプロダクトオーナーは同一人物が兼任できません。スクラムガイドのプロダクトオーナーの定義に基づけば、プロダクトオーナーがスクラムマスターの役割を兼ねることはできないと整理されています。一方で、スクラムマスターがプロダクトオーナーを務める、あるいはスクラムマスターをプロダクトオーナーなどの他の役割で置き換えるテーラリングが報告されています（Özkan & Özcan-Top, 2022）。
  • S7 (ScrumTeam): スクラムチームは正確に1人のプロダクトオーナーを持たなければなりません。プロダクトオーナーを置かない、または同じチームに複数のプロダクトオーナーを置くテーラリングが、プロダクトオーナーの役割のテーラリングとして2番目に多く報告されています（Özkan & Özcan-Top, 2022）。
  • S7 (ScrumTeam): スクラムチームは少なくとも1人以上の開発者を持たなければなりません。

脚注

Section titled “脚注”

  1. Scrum: An Agile Software Development Process and Metrics — 「プロダクトオーナー、スクラムマスター、スクラムチームです[14]。」（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  2. Scrum Guide Expansion Pack — 「スクラムチームは、スクラムを実践し、スクラムマスター、プロダクトオーナー、プロ ダクト開発者というスクラムの 3 つの 説明責任 を担い、ステークホルダー(顧客やユー ザーを含むがこれらに限定されない)の問題や機会に対応し、スクラムチームとステーク ホルダーの視点から、プロダクトゴールに向けて有用で利用可能かつ潜在的に価値のある インクリメントをデリバリーするチームである。」（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  3. Scrum Guide 2020（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5

  4. Nexus Guide — 「Nexus とは、 1 つのプロダクトを協力しながらデリバリーする、およそ 3〜9 のスクラムチーム からなるグループである。」（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5

  5. Scrum@Scale Guide — 「Scrum@Scale は、スクラムガイドに従って機能しているチームのネットワークが、複雑 適応系の問題に対処しつつ、最高の価値のプロダクトを創造的にデリバリーすることを 可能とする、軽量級の組織フレームワークである。」（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  6. ScrumOntoBDD: Agile software development based on scrum, ontologies and behaviour-driven development（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  7. Agile Software Development and Reuse Approach with Scrum and Software Product Line Engineering（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8

  8. A Theory of Scrum Team Effectiveness（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  9. Applicability of the Scrum Methodology in Remote Work Environments and the Challenges Encountered（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5

  10. Scrum Guide (LeSS Version)（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4

  11. Scrum Guide 2009（ライセンス: ライセンス不明） ↩ ↩2 ↩3

  12. Scrum Guide 2010（ライセンス: ライセンス不明） ↩ ↩2 ↩3 ↩4

  13. Scrum Guide 2011 October（ライセンス: All Rights Reserved） ↩ ↩2 ↩3 ↩4

  14. Scrum Guide 2013（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5

  15. Scrum Guide 2016（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4

  16. Scrum Guide 2017（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4

  17. An Ontology-based Approach to Enable Data-driven Decision-making in Agile Software Organizations（ライセンス: CC BY 4.0） ↩ ↩2

  18. Tailoring Choices Made in Scrum Projects: A Systematic Literature Review — 「スクラムガイドに与えられているプロダクトオーナーの役割の定義に基づけば、すべてのスクラムチームにはプロダクトオーナーが必要であり、その人物がスクラムマスターの役割を兼ねることはできない[6]。」（原文: “Based on the definition of the Product Owner role given in the Scrum Guide, every Scrum team needs to have a Product Owner and that person cannot have the role of Scrum Master [6].”）（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

  19. Integrating Design-Based Research and Agile Scrum for Inclusive Educational Technology Design（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

  20. Measuring Software Delivery Performance Using the Four Key Metrics of DevOps（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5

  21. Inter-team Coordination in Large-Scale Agile Development: A Case Study of Three Enabling Mechanisms — 「さらに、別の研究では、スクラムチームの連鎖を、規模が150、34、および5チームの組織で調査しています [16]。」（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

  22. A Quantitative Exploration of the 9-Factor Theory: Distribution of Leadership Roles Between Scrum Master and Agile Team — 「回答者の20.90%において、スクラムマスターの役割が共有されていた。」（原文: “20.90% of the respondents share the Scrum Master role.”）（訳）（ライセンス: CC BY 4.0） ↩

  23. The Impact of Identified Agility Components on Project Success—ICT Industry Perspective — 「チームが自己組織化されている組織におけるプロジェクトの成功確率は、そのような行動が見られない組織よりも大幅に高くなる」（訳）（ライセンス: CC BY 4.0） ↩

  24. Exploring the Prevalence of Anti-patterns in the Application of Scrum in Software Development Organizations（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4 ↩5

  25. Leadership Gap in Agile Teams: How Teams and Scrum Masters Mature（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4

  26. Finding the sweet spot for organizational control and team autonomy in large-scale agile software development — 「つまり、ここでのチームとは、POを含むスクラムチームではなく、スクラムガイドの意味における開発チーム（Development Team）を指している」（原文: “This means that our teams refer to the Development Team in the Scrum guide sense, not the Scrum Team, which includes the PO”）（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4

  27. The continuous testing practice: A two-year action research study to streamline software quality in scrum teams — 「スクラムチームは、厳格な役割分担のない開発エンジニアとテストエンジニアで構成されるクロスファンクショナルなチームでした。」（訳）（ライセンス: CC BY 4.0） ↩

  28. Role clarity deficiencies can wreck agile teams — 「チーム内の役割に対する理解が不完全な場合、自己組織化は極めて困難になる。」（訳）（ライセンス: CC BY 4.0） ↩

  29. Quality culture boosts agile transformation—Action research in a business-to-business software business — 「第3の介入からの主な学びは、単にチームに自己組織化を任せ、偶然に品質プラクティスに行き当たるのを待つだけでは不十分であるということだった。」（原文: “The main learning from the third intervention was that it is not sufficient to simply let teams self-organize and stumble upon quality practices.”）（訳）（ライセンス: CC BY 4.0） ↩

  30. Exploring software development at the very large-scale: a revelatory case study and research agenda for agile method adaptation — 「開放的な作業エリアは迅速な口頭での調整を可能にしたが、追加の役割（機能アーキテクトなど）や場（オープンスペースなど）の存在は、チームの自律性の低下につながった。」（原文: “The open work area enabled quick oral coordination, but the extra roles (such as functional architect) and arenas (such as the Open Space) led to less autonomy for the team.”）（訳）（ライセンス: CC BY 4.0） ↩

  31. Systematic Literature Review Report on the Challenges of Agile Scrum（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4

  32. Development and Validation of a Theoretical Model for Addressing Problems in Agile Meetings: A Systematic Literature Review and a Qualitative Study — 「このモデルは、3つの主要な調整メカニズム（共有メンタルモデル、コミュニケーション、相互信頼）と、5つの重要な構成要素（共有リーダーシップ、チーム志向、冗長性、適応性、ピアフィードバック）を特定している。」（訳）（ライセンス: CC BY 4.0） ↩

  33. Mastering scrum with a focus on team maturity and key components of scrum — 「表4から明らかな2つの変数間の中程度の関連（γ = 0.537）は、成功の認識が成熟度レベルに依存していることを示している。したがって、長年にわたって存続しているスクラムチームほど、スクラムフレームワークの適用において成功する可能性が高いことが確認できる。」（訳）（ライセンス: CC BY 4.0） ↩

  34. A teamwork effectiveness model for agile software development — 「われわれのアジャイルチームワーク有効性モデルは、共有型リーダーシップ、チーム志向、冗長性、適応性、ピアフィードバックから構成される。」（原文: “Our model of agile teamwork effectiveness is composed of shared leadership, team orientation, redundancy, adaptability, and peer feedback.”）（訳）（ライセンス: CC BY 4.0） ↩

  35. An empirical study on changing leadership in agile teams — 「これらの役割は、初期段階ではむしろ1人の専任スクラムマスターに集中しているのに対し、より成熟したチームではむしろ分散していることが分かった。」（訳）（ライセンス: CC BY 4.0） ↩

  36. Investigating Effort Estimation in a Large-Scale Agile ERP Transformation Program — 「各スクラムチームは7〜12名のメンバーで構成されている。」（訳）（ライセンス: CC BY 4.0） ↩

  37. Challenges and success factors for large-scale agile transformations: A systematic literature review — 「Scrum-of-Scrumsを用いた調整は最大5チームまでは機能したが、チームが自分たちの作業に集中し、新しいプラクティスがコミュニケーション経路を狭めてコミュニケーションの破綻を招いたため、グローバルレベルにはスケールしなかった。」（原文: “Coordinating using Scrum-of-Scrums worked for up to five teams, but did not scale to a global level, as teams were focused on their own work and the new practices narrowed communication channels and created communication breakdowns.”）（訳）（ライセンス: CC BY 4.0） ↩

  38. Scrum Guidebook: Analysis of the 2017 Scrum Guide（ライセンス: CC BY-SA 4.0） ↩ ↩2

  39. What makes effective leadership in agile software development teams? — 「半構造化インタビューから得られたデータにより、リーダーシップは、(1) チームメンバー間で動的に共有されること、(2) チームへの帰属意識を生み出すこと、(3) 対立する組織文化のバランスを取ること（例：新しいアジャイル文化と従来のマイルストーン主導の文化とのバランスを取ること）に関わっていることが明らかになった。」（訳）（ライセンス: CC BY 4.0） ↩

  40. Kanban Guide for Scrum Teams 2021（ライセンス: CC BY-SA 4.0） ↩ ↩2

  41. Agile Software Development with Secure and Scrum-Centric Approach（ライセンス: CC BY-SA 4.0） ↩

  42. An Implementation and Evaluation Report of the Active Learning Method EduScrum in Flipped Class（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

  43. On the Benefits And Problems Related to Using Definition of Done — A Survey Study — 「これは、プロダクトのインクリメントを完成させるものは何かについてのスクラムチームの共通見解を表している。」（原文: “It expresses a shared view of a Scrum Team on what makes an increment of their product complete.”）（訳）（ライセンス: CC BY 4.0） ↩

  44. A Delphi Study on the Adaptation of SCRUM Practices to Remote Work — 「その形式は様々だが、一般的にはチームの結束とエンゲージメントを高めるためのゲーム、カジュアルな雑談、ソーシャルアクティビティなどが含まれる。」（訳）（ライセンス: CC BY 4.0） ↩

  45. Challenges in Large-Scale Agile Software Development Projects — 「CaseJとCaseHの双方において、スクラムマスターの役割はチームメンバー間で持ち回りとなっており、チーム内に専属のプロダクトオーナー役は存在しない。リファインメントミーティングの継続性の欠如により、チームメンバーはやや方向性を見失った状態になっている」（原文: “In both CaseJ and CaseH, the SCRUM master role is rotated between team members and has no dedicated product owner role in their teams. A lack of continuity in refinement meetings leaves team members somewhat directionless”）（訳）（ライセンス: CC BY 4.0） ↩

  46. Scrum for safety: an agile methodology for safety-critical software systems — 「一方で、検証者、妥当性確認者、評定者（assessor）といった役割は、スクラムチームの外部の人員であり、テスト活動の正確性、要件の妥当性、およびプロジェクトの規格適合性を監督しなければなりません。」（原文: “Whereas the verifier, validator and assessor figures, who are external personnel from the scrum team, have to supervise the correctness of testing activities, requirements validity, and project standard-compliance.”）（訳）（ライセンス: CC BY 4.0） ↩

  47. Scrum: A Systematic Literature Review — 「スクラムチームのもうひとつの特徴は自己組織化である。」（原文: “Another Scrum team characteristic is self-organization.”）（訳）（ライセンス: CC BY 4.0） ↩

  48. STEM-EF: A Scrum Teamwork Effectiveness Model Based on Emotional Factors — 「スクラムチームのパフォーマンスにおける感情の役割に関する実証的証拠が増えていることを踏まえ、チームの有効性に不可欠な感情の構成概念を統合しながら、STEMの構造的な強みを維持することを目指しました。」（訳）（ライセンス: CC BY 4.0） ↩