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

スクラムマスター (Scrum Master)

概要

Section titled “概要”

スクラムマスターは、スクラムチームの有効性向上とスクラムプロセスの確立に責任を持つ真のリーダーである。経験主義と自己管理を基盤とし、命令的統制ではなくサポートと信頼により心理的安全性の高い協働環境を醸成する。各種イベントの進行や要件精緻化・品質管理などのプロセス定着を支え、障害の排除やコーチングを通じてプロセスの継続的改善を導く。また、計画や設計などの意思決定で合意形成が難航した際には対立調停を担い、チームの自律性と組織統制の緊張を緩和して意思決定の境界線を明確化する。チーム内外での円滑な知識伝達を促して組織学習を支えるとともに、チームの成熟に応じた役割委譲を進めつつ外部の不当な介入を防ぐ。小規模から大規模スケーリング、変革期に至るまで、組織的課題の是正と持続的な価値創出を導く要として位置づけられる。

詳細

Section titled “詳細”

スクラムガイドが定める3つの支援対象（プロダクトオーナー・スクラムチーム・組織）

Section titled “スクラムガイドが定める3つの支援対象（プロダクトオーナー・スクラムチーム・組織）”
  • プロダクトオーナーへの支援において、アジャイルの価値、原則、プラクティスのトレーニングを行い、プロダクトバックログの有効な管理方法の提示や理解促進、価値の最適化手法やスクラムの役割の浸透を図る[1]。
  • チームがスクラムの理論と実践を理解・遵守し、自己管理型かつ機能横断的な状態になるようコーチング、メンタリングを行い、自律的かつ効率的に機能して価値の創造に集中できるよう支援する[2][1][3][4][5][6][7][8]。開発チーム・スクラムチームへの支援において、経験主義や自己管理に基づき効果的に活動できるよう支援する[9]。
  • 組織、サポーターおよびステークホルダーへの支援において、組織全体のスクラム理解、導入計画策定・教育・定着を強力に主導し、経験的プロセスの定着やスクラムの理論・プラクティスの理解と実施を促す[1][3][4][5]。

定義と版による変遷

Section titled “定義と版による変遷”

経験主義と自己管理の基盤上、チームの妨害排除、イベントファシリテーション、コーチングを通じて自律的成長と継続的改善を支援する[9]。大規模開発や分散環境、データ駆動型意思決定など多様なコンテキストに対応し、スクラムの確立と価値創出に貢献する専門的な役割として位置づけられている[5][9]。版による定義・呼称および役割の位置付けの変遷は、2009年版ではプロセスの理解と追従に責任を持つ役割として記述され、2010年以降は「サーバントリーダー」と明確に位置付けられた[2][1][3][4][10]。2020年版では、スクラムを確立させることの結果とスクラムチームの有効性に責任を持ち、スクラムチームとより大きな組織に奉仕する真のリーダーとして記述されている[5][7]。『Scrum Guide Expansion Pack』では、スクラムマスターは1人の人間であり、ガイド・コーチ・メンター・障害物除去者・ファシリテーターとして多角的に機能し、模範を示してチームをリードするチェンジエージェントとして補強されている[9]。

主な活動とサーバントリーダーシップ

Section titled “主な活動とサーバントリーダーシップ”

スクラムマスターは、ファシリテーション、メンタリング、交渉、プロセスの適応、調整、障害の排除という6つの主要なコア活動を担当する[11]。スクラムの原則やルールの遵守を保証しつつチームメンバーに対してアジャイルのコーチングを行い、デイリースクラム等で抽出された障害（ブロッカー）を記録・追跡し、その除去に責任を持つことでチームの価値提供と改善を促進する[12][8]。プロセスの遵守と妨害からの防護に注力し、スプリントイベントの質を向上させ、継続的改善の風土や心理的安全性をチーム内に定着させる役割も果たす[11]。チームおよび組織の「How」（どのように進めるか）の効率性と健全性を向上させる責任を負い、スクラムチームが進捗を妨げられることなく活動できるよう障害物を除去・支援する真のリーダーとして機能し、チーム管理者に陥ることなくチームの自己管理と自律的成長を推進する[9][6]。スキルとコンピテンシーの基準・専門性の向上において、スクラムマスターはアジャイルコーチやリーダーと共に、チームや組織が持続可能な価値を届けるための支援と成長の促進を担う[13]。自身のアジェンダよりもチームやビジネスのニーズを優先するサーバントリーダーシップを基礎とし、コーチング、ファシリテーション、メンタリング、ティーチングといった専門スキルを駆使することが求められる[13]。10年以上にわたりアドキンスやスペイドのモデルなどがスクラムマスターのスキルやコンピテンシーを定義する標準基準として活用されてきており、アジャイルコーチとの共通基盤のもと、体系的なスキル向上と成長の基準が適用されている[13]。

チーム・組織への支援の実践

Section titled “チーム・組織への支援の実践”

チームやメンバーに対してアジャイルの価値、原則、プラクティスのトレーニングを提供し、プロセスを適切に実践および遵守しているかを確認することで、チームの能力発揮と自律的成長を支える[12]。アジャイルや行動駆動開発（BDD）などの開発プラクティスの円滑な適用をサポートし、チームの有効性やダイナミクスを高めてハイパフォーマンスな状態への進化を促す[13]。成果への集中や中立的な協働環境を創出し、建設的な対立解決や自律的な意思決定を促すとともに、課題や障害を排除してチームの生産性とコラボレーションを最適化する[13][14]。従来のプロジェクトマネージャーのようにメンバーへ直接作業を割り当てる権限を持たず、チーム管理者に陥ることなく成長を支援し、アジャイルの価値観や原則、プラクティスについての指導やコーチングを行ってプロセスが適切に守られているか確認する[2][12][14][15]。また、命令型の管理を行うのではなく、サポートと信頼の環境を提供するサーバントリーダーとして行動し、チームメンバーが互いに助け合い、積極的に問題解決に取り組めるよう心理的安全性の高い環境を醸成する[16]。さらに、チームを外部や内部の妨害から守り、チームの進捗を妨げる障害物（ブロッカー）を特定・除去してタイムボックスやスクラムルールの遵守をサポートする[2][1][3][5][14][15][9][6][8][7]。チームレベルのアジャイル手法において、組織からの負の影響を遮断し、外部環境によって引き起こされる障害を解決する役割としても位置づけられる[17]。プロダクトオーナー、開発者だけでなく、ステークホルダー、サポーター、ならびに組織全体に対してそれぞれ適切な指導と支援を提供し[9]、スクラムチームの生産性向上に向けた組織的な変化を促す。アジャイルおよびリーンの価値観を浸透させ、組織全体における継続的な学習と改善の文化の育成をサポートする[13]。さらに、組織内およびステークホルダー間の障壁を取り除いて組織全体の適応性を向上させることが強調されている[7]。

スクラムイベントと継続的改善の支援

Section titled “スクラムイベントと継続的改善の支援”

レトロスペクティブや反復計画などのプラクティスを円滑に進行させ、チームの自己管理と継続的改善を支える[16]。スプリントイベントの質を向上させ、チーム内に改善のサイクルを定着させる[11][18]。特にデイリースクラム等で抽出された障害を記録・管理し、タイムリーな除去につなげる[12]。イベントのファシリテーションやチーム外部との必要な調整することで、各種ミーティングやイベントが効果的で目的に沿ったものとして行われることを保証する[3]。さらに、開発チームが異種アプリケーションからのデータ抽出やデータ駆動型意思決定を行う際の運用上の課題を把握し、解決を図る立場として機能する[18]。また、チームの健全性評価や改善活動を主導し、診断ツール等を通じた振り返りやステークホルダーとの連携を促進する役割も担う[19]。Scrum チームのメンバー 182 人への調査（自己申告の横断データ）では、スクラムマスターがすべてのイベントを確実に開催させる能力は、成功しているという認識に特に影響が大きい要素の一つだった[20]。6 つのスクラムチームでのゲーム型レトロの Action Research は、スクラムマスターが利用できるレトロスペクティブゲームのツールボックスを用意し、どのゲームが効果的かをチームが経験的に見極めるのを支援し、チームが望むなら切り替えるべきだと結論づけた[21]。37 回のレトロを追った事例研究の組織では、レトロはスクラムマスターが進行し、各回に約 3〜5 人のチームメンバーが出席したが、プロダクトオーナーは定期的には参加していなかった[22]。継続的テストを導入した 2 年間のアクションリサーチ（インド拠点の 50 人、1 社）では、開発マネージャーとスクラムマスターに、スプリントのコミットメントが遅れても柔軟性を提供してチームを後押しすることが期待された[23]。 スクラムマスターは、スプリントレトロスペクティブ等のイベントにおいて心理的安全性を確保し、チームの感情的健全性の把握や対立解消を支援する役割を担う[24]。

分散・リモート・ハイブリッド環境での役割

Section titled “分散・リモート・ハイブリッド環境での役割”

分散アジャイル・リモートワーク環境における支援と課題において、分散アジャイルチームにおけるコミュニケーションと調整（C and C）フレームワークにおいて、スクラムマスターは技術支援とコミュニケーション調整という二重の責任（役割）を果たし、チーム間の円滑な意思疎通と調整を推進する[25]。また、リモートワーク環境の適用においては、プロセスマネジメントの有効性と開発者側の認識との間における評価ギャップの発生が指摘されている[8][25]。ハイブリッドワーク環境における支援と適応において、スクラムマスターはマネージャーやアジャイルコーチとともに、アジャイルソフトウェアチームにおける働き方の変遷やその影響を把握・評価する重要な実践者として位置づけられる[26]。COVID-19パンデミックの直前・渦中・後におけるチーム構成の進化や、動的な作業スケジュール・作業場所への適応において現場の状況を伝える役割を担い、組織、リーダーシップ、マネジメント、およびチームレベルでのポリシー変更の影響を評価しつつ、ハイブリッド環境下におけるソフトウェア開発プロセスの改善と実践を推進する[26]。多国籍電気通信企業 Ericsson の 2 ユニット（15 チームの 27 人へのインタビュー）では、どのチームにも、スクラムマスターとして専任で活動する特定のメンバーはいなかった[27]。

デザインベース研究（DBR）との統合

Section titled “デザインベース研究（DBR）との統合”

デザインベース研究（DBR）との統合環境における支援において、チーム内のコミュニケーション円滑化やスクラムイベントの進行、スクラムの実践・原則に従った運用を支援する役割として配置される[28]。アジャイル開発の運用支援に加え、ユーザビリティテストのスケジューリングなど研究上の追加ニーズの円滑化も担う[28]。実践現場やフィールド研究に固有のスケジュール衝突や遅延といった阻害要因・障害物を取り除き、研究活動と開発タスクの双方が円滑に進行するよう調整と支援することで、DBRとアジャイル・スクラムを統合したハイブリッド手法の導入推進および効率的なチーム運営をサポートする[28]。

スケーリングフレームワークにおける役割

Section titled “スケーリングフレームワークにおける役割”

SAFe導入環境および実態調査における位置付けにおいて、SAFe導入に関する実証調査において、スクラムマスターはアジャイルコーチと共に「プロセス関連の役割」として分類されている[29]。同調査の回答者属性において、このプロセス関連の役割は全体の57%と最大の比率を占めており、大規模組織におけるアジャイル変革やスケーリングフレームワークの定着を支援し、プロセス定着や実践を担う重要職種として高い関心を集めている[29]。さらに、ビジネスチームがアジャイル変革を行い、価値ストリームと連携する過程において導入される重要なスクラムの役割としても挙げられている[17]。チーム間の障害除去やボトムアップの経験的プロセスの維持を推進し、Nexus全体の有効性を高めるコーチングを担当する[30]。また、Nexus統合チームのスクラムマスターは、Nexus内に存在する個別スクラムチームのスクラムマスターを兼任可能である[30]。Scrum@Scaleにおける役割と支援において、スクラムマスター組織の一員として、障害物除去や継続的改善、チーム横断の調整を強力に推進する役割を担う[6]。チームの枠を超えて障害物を取り除き、組織的なスクラムマスターサイクルを推進するほか、スケール環境においてはスクラムオブスクラムマスター（SoSM）やエグゼクティブアクションチーム（EAT）と連携してチーム間調整や組織変革に寄与する[6]。さらに、Scrum@Scaleなどの大規模フレームワークでは、Scrum of Scrumsのファシリテーションやエグゼクティブ・アクション・チームと連携した障害排除の実践にも寄与する[19]。意思決定と自律性の観点でスクラムマスターの役割が明示されているのはSAFeに限られるものの、イベントの協調方法やスケーリングされたレトロスペクティブなどでは重要な役割を果たす[31]。例えばSAFeでは、スクラムマスターはイベント期間中の協調・協力方法を決定できる自律性を有しているとされる（他のフレームワークでは明示されていない）[31]。また、LeSSやSAFeにおいては、MVP（実用最小限の製品）の決定時にビジネス価値を評価し助言を提供する役割を果たすことができる[31]。さらにScrum@Scaleでは、各チームのスクラムマスターが集まり、改善項目（RR6）および次スプリントでの改善方法（RR7）を決定する意思決定者となるほか、完成の定義の策定においてはプロダクトオーナーチームとともにスクラム・オブ・スクラムマスターが合意形成の主体となる[31]。

役割の境界とリーダーシップ

Section titled “役割の境界とリーダーシップ”

初期のスクラムガイドでは、役割間の制約としてプロダクトオーナーとスクラムマスターの兼任が明確に禁止されていた[2][32]。一方で、スクラムマスターが従来のプロジェクトマネジメント業務を兼任すると摩擦が生じ、チームのパフォーマンスに悪影響を及ぼす可能性があると指摘されており、明確な役割の境界を維持しつつチームの自律性を促すリーダーシップへ転換することが重要視されている[11]。非中立なファシリテーターとチーム自立支援において、スクラムマスターは単に障害を外部から取り除いてあげるのではなく、チーム自身が自己組織的に障害を解消・軽減できるよう支援するファシリテーターであるとされる[33]。中立的な傍観者ではなく、チームの一員としてチームの成功とプロセスの継続的改善に深く関与し、組織変革の推進者として機能する[33]。スクラムマスターが意図的に沈黙を守ったり特定の行動を停止したりすることで生じるリーダーシップの空白である「リーダーシップギャップ」は、チームメンバーが主体的に責任と役割を引き受ける契機となる[34]。ただし、議論の中立性を保つ「調整役」や、経営層や外部からの不当な介入・過剰な作業要求を防ぐ「守護者」の役割は、チームメンバー自身による代替が難しく、スクラムマスターが継続的に担うべき委譲困難な役割とされる[34]。ロバート・ボッシュの 11 の事業部門の実務者 75 人へのグラウンデッド・セオリー研究（1 社）では、スクラムマスターから開発者へ 9 つのリーダーシップの役割が成熟に伴い移譲され、その移譲はリーダーシップの空白とチーム内部の協力的な風土に促され、役割の衝突に妨げられうると報告された[35]。11 社のアジャイルリーダー 15 人へのインタビュー（テーマ分析）では、成熟したチームではリーダーが一歩引いてチームの作業プロセスのファシリテーションに回る一方、成熟度の低い、または新しく結成されたチームには、より多くの方向付けと指導が必要だと報告された[36]。

大規模開発・組織変革での実践

Section titled “大規模開発・組織変革での実践”

大規模開発における配置形態と自律性の擁護において、1つのチームに専従する形態のほか、複数チーム間で兼任・共有される形態や、組織的なコーチとして外部から関与する形態が取られる[37]。また、トップダウンによる過剰なプロセス強制や一方的なチーム編成の変更に対して現場の視点から異議を唱え、チームの士気とエンパワーメントを保護する役割を担う[37]。さらに、スクラムマスター同士が集まるコミュニティ・オブ・プラクティス（CoP）を定期的に開催してアジャイルプラクティスの改善やチーム間の協調課題について議論するほか、レトロスペクティブをファシリテーションし、チームが独自の働き方を定義・進化させることを支える[37]。

導入時の課題とアンチパターン

Section titled “導入時の課題とアンチパターン”

スクラムマスターおよび指導的役割の課題において、アジャイル・スクラムへの移行や大規模開発環境への移行時には、適切な知識やアジャイルマインドを持ったスクラムマスターやコーチなど指導者の不足が、従来の開発手法との摩擦やプロセスの不適切な実装、導入失敗を招く主な原因として挙げられている[38]。また、大規模な開発環境においては有機的で柔軟なリーダーシップだけでは不十分であり、規律を持った統制と柔軟性を適切に組み合わせたリーダーシップスタイルの適用が求められる[38]。さらに、チーム内外で発生する依存関係やコミュニケーションの不備を解消し、自律的な開発を継続できる環境を整えるチーム支援と障害排除の役割が不可欠であると指摘されている[38][39]。チーム結成後、メンバー同士のオープンな議論を通じて担当者が決定され、チームメンバーが協調して課題解決や知識獲得に主体的に取り組めるよう環境と活動のファシリテーションや支援を行う[39]。アンチパターンの是正と組織的課題の解明における役割において、スクラムマスターはチーム内でのスクラムプロセスの遵守を促し、組織的な障害を排除する役割を担う[40]。また、著者らは今後の研究として、反パターンが発生・持続する原因を、それらに直面した経験のあるプロジェクトマネージャーやスクラムマスターへの詳細なインタビューで調べる計画を述べている[40]。 大規模アジャイル変革の文献レビュー（一次文献の大半は体験報告）には、プロジェクトマネージャーとスクラムマスターの役割を兼任させたことが利益相反を生み、その役割がチームを支援するものから監視するものに変質した事例の報告がある[41]。

実証研究にみる実践領域

Section titled “実証研究にみる実践領域”

小規模企業におけるプロセス改善の事例では、ソフトウェア製品の品質を保証することと、チームとプロセスの有効性を促進することが、プロダクトオーナーとともにスクラムマスターの課題とされている[42]。また、スプリントプランニング、レトロスペクティブ、プランニングポーカーなどの会議体をファシリテーションし、チームメンバー全員の参加と共有理解を促進する[43]。さらに、チームの自律性とマネジメントによる統制の緊張関係を緩和して意思決定の境界線（Decision Boundary）を明確化するとともに、意思決定プロセスの透明性を高め、チーム内の偏った意見や過度な権力勾配による歪みを防ぐ支援を行う[43]。プロダクトオーナー、アーキテクト、開発者が参加する要件精緻化会議をファシリテートし、スプリント後の品質管理会議に出席して、実行したタスクの結果や仮説の評価の見直しに加わる事例も報告されている[44]。 スクラムマスターは、プロダクトオーナー、チームとともにスプリントプランニングミーティングに参加し、次のスプリントで何を行うかを議論する[45]。

分類・所属

Section titled “分類・所属”
  • 所属タグ: Scrum Master Scrum Role Scrum Core Roles Agile Coaching
  • カテゴリー: Scrum Core

オントロジー上の位置

Section titled “オントロジー上の位置”
  • 上位クラス（直接の親から順に）: Organizational_Role
  • 兄弟クラス: Developer、ProductOwner
  • 他の概念との関係:
    • ScrumTeam → hasScrumMaster → この概念
  • 関連する検証ルール: 未定義
  • 関連CQ: 未対応
  • 原文: 未定義
  • オントロジー階層: オントロジー階層で見る

脚注

Section titled “脚注”

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

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

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

  4. Scrum Guide 2016（ライセンス: CC BY-SA 4.0） → Scrum Guide Readerで原文の該当箇所を読む ↩ ↩2 ↩3

  5. Scrum Guide 2020（ライセンス: CC BY-SA 4.0） → Scrum Guide Readerで原文の該当箇所を読む ↩ ↩2 ↩3 ↩4 ↩5

  6. Scrum@Scale Guide — 「スクラムマスター組織(スクラムマスター、スクラムオブスクラムマスター、エグゼクティブアクションチーム)は、スクラムマスターサイクルのコンポーネントを実装するために全体として機能する。」（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5

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

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

  9. Scrum Guide Expansion Pack — 「スクラムマスターはチェンジエージェントであり、組織全体のあらゆるレベルや事業領域で活動する。」（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  10. Scrum Guide 2017（ライセンス: CC BY-SA 4.0） → Scrum Guide Readerで原文の該当箇所を読む ↩

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

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

  13. Agile Coaching Growth Wheel（ライセンス: CC BY-SA 4.0） ↩ ↩2 ↩3 ↩4 ↩5 ↩6

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

  15. Agile Software Development and Reuse Approach with Scrum and Software Product Line Engineering — 「スクラムマスターの主な責任は、チームの障害を取り除き、スクラムのプラクティスが確実に遵守されるようにすることです。」（訳）（ライセンス: CC BY 4.0） ↩ ↩2

  16. Relationships between Agile Work Practices and Occupational Well-Being: The Role of Job Demands and Job Resources（ライセンス: CC BY 4.0） ↩ ↩2

  17. Dependencies of Agile Teams – An Analysis of the Scaled Agile Framework — 「チームは、典型的なスクラムのプラクティス（スプリント計画、デイリースクラム、デモ、レトロスペクティブ）を適用し、スクラムの役割（スクラムマスターとプロダクトオーナー）を使用します。」（訳）（ライセンス: CC BY 4.0） ↩ ↩2

  18. An Ontology-based Approach to Enable Data-driven Decision-making in Agile Software Organizations — 「アジャイルの文脈における意思決定のための組織のデータニーズを満たすために、アプリケーションに保存された既存データを統合する目的でオントロジーを使用することは、有用かつ実現可能か？」（訳）（ライセンス: CC BY 4.0） ↩ ↩2

  19. Do Agile Scaling Approaches Make a Difference? An Empirical Comparison of Team Effectiveness Across Popular Scaling Approaches（ライセンス: CC BY 4.0） ↩ ↩2

  20. Mastering scrum with a focus on team maturity and key components of scrum — 「特に影響が大きいのは、計画を適応させる開発者の能力、優先順位を決定するプロダクトオーナーの権限、そしてすべてのイベントが確実に開催されるようにするスクラムマスターの能力である。」（訳）（ライセンス: CC BY 4.0） ↩

  21. Game-based Sprint retrospectives: multiple action research — 「したがって、スクラムマスターは利用可能なふりかえりゲームのツールボックスを用意し、どのゲームが効果的かをチームが経験的に見極められるよう支援し、チームが望む場合にはゲームを切り替えるべきである。」（訳）（ライセンス: CC BY 4.0） ↩

  22. Recurring opinions or productive improvements—what agile teams actually discuss in retrospectives — 「ふりかえりのミーティングには、参加可能なすべてのチームメンバーが出席し（各ミーティングで約3〜5名）、スクラムマスターによってファシリテートされた。ただし、プロダクトオーナーはふりかえりのミーティングに定期的には参加していなかった。」（訳）（ライセンス: CC BY 4.0） ↩

  23. The continuous testing practice: A two-year action research study to streamline software quality in scrum teams — 「開発マネージャーやスクラムマスターには、スクラムチームがスプリントにおけるコミットメントの達成で予定より遅れた場合でも、柔軟性を提供しチームを後押しすることが期待されました。」（訳）（ライセンス: CC BY 4.0） ↩

  24. STEM-EF: A Scrum Teamwork Effectiveness Model Based on Emotional Factors — 「スクラムの専門家はスクラムマスター、プロダクトオーナー、開発者、ステークホルダーなどの役割を担っており、業界経験は1年から8年以上に及んでいた。」（訳）（ライセンス: CC BY 4.0） ↩

  25. ChainAgile: A framework for the improvement of Scrum Agile distributed software development based on blockchain — 「このフレームワークは分散アジャイルチームを取り入れており、スクラムマスターが技術支援とコミュニケーションの役割を果たしています。」（訳）（ライセンス: CC BY 4.0） ↩ ↩2

  26. Hybrid Work in Agile Software Development（ライセンス: CC BY 4.0） ↩ ↩2

  27. Hybrid Work in Agile Software Development: Recurring Meetings — 「どちらのユニットのチームにも、スクラムマスターとして専任で活動する特定のメンバーはいない。」（訳）（ライセンス: CC BY 4.0） ↩

  28. Integrating Design-Based Research and Agile Scrum for Inclusive Educational Technology Design — 「プロセスの円滑化を行うスクラムマスターや、スプリントゴールを達成するために自己組織化する開発チームなど、これを支える役割が定義されています。」（原文: “Roles are defined to support this, such as the Scrum Master who facilitates the process and a development team that self-organizes to meet sprint goals.”）（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

  29. Benefits and Challenges of Adopting SAFe - An Empirical Survey（ライセンス: CC BY 4.0） ↩ ↩2

  30. Nexus Guide — 「Nexus 統合チームのスクラムマスターは、Nexus のスクラムチームのスクラムマスター になることもある。」（ライセンス: CC BY-SA 4.0） ↩ ↩2

  31. Decision-Making and Team Autonomy in Large-Scale Agile Software Development: An Analysis of Scaling Frameworks — 「意思決定と自律性に関してスクラムマスターの役割が能動的であるのはSAFeのみであり、イベント中にどのように協調するかを決定できますが（Ex4）、これは他のフレームワークでは明示的に述べられていません。」（原文: “The Scrum Master role is only active in SAFe regarding decisions and autonomy, as they can decide how to collaborate during events (Ex4), which is not explicitly stated in other frameworks.”）（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3 ↩4

  32. Tailoring Choices Made in Scrum Projects: A Systematic Literature Review — 「最も一般的にテーラリングされているスクラムの役割はプロダクトオーナーであり、次いで開発チーム、スクラムマスターでした。」（訳）（ライセンス: CC BY 4.0） ↩

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

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

  35. An empirical study on changing leadership in agile teams — 「私たちは、リーダーシップの空白とチーム内部の協力的な風土が役割の移譲プロセスを促進する要因である一方、役割の衝突が役割の移譲を阻害する可能性があることを明らかにした。」（訳）（ライセンス: CC BY 4.0） ↩

  36. What an Agile Leader Does: The Group Dynamics Perspective — 「要約すると、最初に見出された課題は、アジャイルリーダーは成熟したチームから一歩引き、チームを取り巻くエコシステムとの関係においてチームの作業プロセスをファシリテーションする必要があるということである。」（訳）（ライセンス: CC BY 4.0） ↩

  37. Finding the sweet spot for organizational control and team autonomy in large-scale agile software development — 「あるスクラムマスターは、仕事の進め方を選ぶ自由について次のように説明した。」（原文: “A Scrum master described the freedom of choosing how to work as follows:”）（訳）（ライセンス: CC BY 4.0） ↩ ↩2 ↩3

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

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

  40. Exploring the Prevalence of Anti-patterns in the Application of Scrum in Software Development Organizations — 「14人のソフトウェア開発者を含む、2つのチームを観察し、これらチームのメンバーが、プロダクトオーナー、アジャイルコーチ、またはスクラムマスターとして活動するMortadaら[9]は、これらのチーム間で個別に実践されている4つのスクラム活動について調査しました。」（訳）（ライセンス: CC BY 4.0） ↩ ↩2

  41. Challenges and success factors for large-scale agile transformations: A systematic literature review — 「また、プロジェクトマネージャーとスクラムマスターの役割を兼任させることが利益相反を生み出し、スクラムマネージャーの役割がチームを支援するものではなく監視するものに変質してしまったことも説明されている [P30]。」（原文: “It was also described how mixing the role of project manager and Scrum master created a conflict of interest, and turned the Scrum manager’s role into one of policing instead of supporting the team [P30].”）（訳）（ライセンス: CC BY 4.0） ↩

  42. Measuring and Improving Agile Processes in a Small-Size Software Development Company — 「スクラムマスターにとっての課題は、少なくとも2点あります。ソフトウェアプロダクトの品質を保証すること、そしてチームとプロセスの有効性を促進することです。」（訳）（ライセンス: CC BY 4.0） ↩

  43. Decision-Making in Agile Software Engineering: A Systematic Literature Review of Models, Methods, Actors and Lifecycle Contexts — 「レビュー対象の研究において、我々は3つの主要なアクターグループを用いた。」（訳）（ライセンス: CC BY 4.0） ↩ ↩2

  44. ArchHypo: Managing Software Architecture Uncertainty Using Hypotheses Engineering — 「これはスクラムマスターがファシリテーションを行い、プロダクトオーナー（PO）、アーキテクト、開発者が同席して約2時間行われた。」（訳）（ライセンス: CC BY 4.0） ↩

  45. Development and Validation of a Theoretical Model for Addressing Problems in Agile Meetings: A Systematic Literature Review and a Qualitative Study — 「スプリントプランニングミーティングは、プロダクトオーナー、スクラムマスター、チームが参加する月次のミーティングであり、次のスプリントで何を行うかを議論します。」（訳）（ライセンス: CC BY 4.0） ↩