チームがスクラムやアジャイルをできているかを、スクラムマスターはどんな観点やデータで見極めるのが良いか？

実践者の問い（pq-09）。取り込み済みの文献のうち 11 本から拾った 15 件の事例と知見にもとづく。ここに無い打ち手が存在しないという意味ではない。

結論（TL;DR）

チームがスクラムをできているかを見極める手順や、その手順の判定が実態と合うかを確かめた文献は、今回読んだ範囲では見つかっていません。文献が示しているのは、まず形の上の守り方では見分けにくいことです。ポーランドの調査では、スプリントの長さやデイリースクラムの開催は守られていると答えた人が多い一方、スプリントのタスクが終わらない、スプリントゴールが決まらないは頻繁だと答えた人が多くいました。デンマークの調査では、イベントを枠組みどおりに組んでいるという答えは「うまく使えている」という本人の認識と関係しましたが、タイムボックスやスプリントの長さを守っているかは関係が見つかりませんでした。この認識が成果につながるかは調べられていません。スケーリングの枠組みの違いではチームの有効性はほとんど変わらず、アジャイルの経験のほうが大きく関係していたという大規模な調査もあります。研究者が 6 チームのイベントを聞き取ってスクラムガイドと比べた研究では、意図どおりに使っていたのは 1 チームで、そのチームも強いられて従っていました。本人たちは Water-Scrum-Fall だと言わない組織の実態がその形だった例、ステージングへの反映を「リリース」と呼んでいた例、実践を省いた理由を「十分に成熟している」と説明していた例も報告されています。自分の評価と相手の評価のずれも報告されています。メンバーが思うステークホルダーの満足と本人の答えの相関は中程度で、スクラムマスターとメンバーは、それぞれ自分たちの活動を相手がつけるより高く評価する傾向がありました。見極めの材料としては、応答性・ステークホルダーへの配慮・継続的改善・自律・マネジメントの支援の 5 つでチームの有効性の多くを説明できたという調査や、成熟したチームではスクラムマスターの役割の一部をメンバーが担うようになったという聞き取りがあります。成熟度モデルでチームを評価して打ち手を決めた事例もありますが、その評価が実態を正しく見分けていたかを確かめた記録はありません。

打ち手と事例

複数の部署から仕事が流れ込み Scrum が定着しなかった 6 人のチームが、Kanban Maturity Model の順に Kanban を入れ、1 稼働日あたりの完了件数が 3 か月で増えた ［Impact of the Kanban Maturity Model on a Team’s Agile…（2024）］

• 状況: ポーランドの中規模の企業（サイバーセキュリティ）の、開発者 6 人のチーム。メンバーはフロントエンド、バックエンド、クラウド基盤、アーキテクチャ、セキュリティなどの経験者で、作るソフトウェアはプラットフォームの他の部分とつながり、プロダクトチーム、カスタマーサクセス、カスタマーサポート、技術運用、セキュリティの各部署と継続的に連携する。前年に Scrum への移行を試みたが定着せず、不定期のデイリースクラムと、プランニングとレビューの無いスプリントだけが残っていた。著者は理由として、複数の部署から仕事を受け、一部は標準のスプリントの外で届ける必要があったこと、仕事の出どころが多くプロダクトオーナーを決めることとプロダクトバックログの管理が難しかったこと、当時はチーム内で変化への支持が弱く、スクラムマスターの経験も浅かったことを挙げている。調査の時点では、チームは仕事に圧倒されていると述べ、リリースは大きく遅れ、品質も社内外の期待を下回っていた。
• やったこと: CIO・エンジニアリングの責任者・プロダクトマネージャー・アジャイルコーチが新しい変革を始め、複数の仕事の出どころに対処し、新しい役割を置かずに仕掛かり作業を制限する方法として Kanban Method を選んだ。 2023 年 3 月に Kanban Maturity Model（KMM）でチームの成熟度を評価し（最も低いレベル 0）、4 月から 6 月に KMM のレベルの順に実践を入れた。入れた実践の数は 4 月 23、5 月 12、6 月 6 だった。チケットでの作業の可視化、アバターによる個人の負荷の可視化、1 人あたりの WIP 制限、基本の方針と流れの指標、デイリーのカンバンミーティング、レトロスペクティブ、補充のミーティングなどを入れ、他のチームと管理職にも Kanban の研修をした。研究者がチームに関わり、進み具合と問題に応じて打ち手を調整した。
• 起きたこと: チーム全体の 1 稼働日あたりの完了タスク数の平均は、導入前の 3 月が 1.1 件、4 月が 1.33 件、5 月が 2.5 件、6 月が 3.65 件だった。著者は、導入前の月と比べて 3 倍を超えたとしている。
• 注意点: 基準は導入前の 1 か月だけで、比較対象のチームは無く、因果は言えない。研究者がチームの実践に関与していた。研修やミーティングを含む多数の実践が同時に入っていて、どの実践の効果かは分けられない。指標は完了したタスクの件数で、項目の大きさは測っていない（著者は、期間中に作業項目の粒度の変化は観察されなかったと述べている）。Scrum 側は、プランニングとレビューを欠いた部分的な導入だった。研究期間の書き方が揃っていない（本文は 3〜6 月、図 1 の題は 4〜7 月）。ここでは本文の値を使った。顧客が報告した不具合の件数の比較もあるが、対象がチームの製品か会社全体かで本文の書き方が揺れるため載せない。経験者だけの 1 チームで、期間中にメンバーは変わらなかった。
• 根拠: 事例研究／単一チーム。文献: Impact of the Kanban Maturity Model on a Team’s Agile Transformation: Tripling Throughput and Elevating Quality in Three Months（2024）。文献の種類: 論文・研究者。位置: 2 Method and Setting（論文集の p.108–109）/ 3 Results and Discussion（論文集の p.110–112、表 1）。確認の根拠: 原典
• 原文: “reached 3.65 tasks per work day.”

チームが成熟するにつれ、スクラムマスターが担っていた役割の一部をメンバーが担うようになったと語られ、司会と外からの要求を防ぐ役割は移りにくかった ［Leadership Gap in Agile Teams（2019）］

• 状況: Robert Bosch GmbH の 11 の事業部で、スクラムマスター 22 人、プロダクトオーナー 8 人、メンバー 23 人の計 53 人に聞き取りをした研究（グラウンデッド・セオリー）。対象はソフトウェア開発の 14 チームと、ソフトウェア以外の 15 チームで、チームができてからの期間は 3 か月から 3 年だった。チームは Scrum を主に手直しした形で使っていた。スクラムマスターに人事上の権限は無かった。
• やったこと: スクラムマスターは、最初は 9 つのリーダーシップの役割を自分で担って手本を示し、時間がたつと一部の役割をやめ、マネジメントやプロダクトオーナーがその役割を取らないようにした。著者はこれを「リーダーシップの空白」と呼んでいる。意図して空白を作った例と、スクラムマスターが不在のために空白ができた例があった。
• 起きたこと: 新しくできたチームでは、メンバーは問題をデイリーまで持ち越していたが、時間がたつと、問題が起きたときにすぐ互いに話すようになった。チームの行事をメンバーが自分たちで開くようになった、自分たちの判断でボードに情報を見えるようにした、メンバーどうしでフィードバックをし合うようになった、仲間の終わらない議論を止めるようになった、といった変化が語られた。司会の役割（Moderator）と、外からの不適切な要求からチームを守る役割（Protector）は、チームに移りにくかった。著者は、役割を担う人が偏らずにいる必要があることを例に挙げている。司会については、2 チームが、チームの一員だと議論の中で中立を保ちにくいので、スクラムマスターが担うべきだと考えていた。守る役割については、外からの要求を交代で防ぐ「Batman」という役割を作ったチームがあった一方、スクラムマスターが今は定期的に関われずに苦労している 2 チームや、プロダクトオーナーの不在の間にマネジメントがメンバーを一時的に外したことが 2 回あったと語ったチームもあった。マネジメント・スクラムマスター・プロダクトオーナーが権限を手放さなかったチームでは、メンバーはリーダーの役割を担わなかった。
• 注意点: 聞き取りで語られた、過去を振り返っての話である。著者は、成熟の段階と役割の移り方を量的に対応づけてはいないと書いている。どのくらいの数のチームで起きた変化かは示されていない。著者は、信頼と、役割を担う自由を、欠かせない条件として挙げている。
• 根拠: 事例研究／複数チーム。文献: Leadership Gap in Agile Teams: How Teams and Scrum Masters Mature（2019）。文献の種類: 論文・研究者。位置: 3.2 Context and Subject Selection / 4.1 Nine Scrum Master Roles / 4.2 The Role Transfer Process / 7 Limitations and Future Work。確認の根拠: 原典
• 原文: “Over time, teams started to speak with each other right away when an issue occurred.”

研究者が 6 チームのイベントの実際を、聞き取りとチームの中からの知識で整理してスクラムガイドと比べると、意図どおりに Scrum を使っていたのは 1 チームで、そのチームも強いられて従っていた ［Game-based Sprint retrospectives（2021）］

• 状況: 3 社（OKE Poland、Dynatrace、SentiOne）の Scrum チーム 6 つで、レトロスペクティブの質を上げようとしたアクションリサーチの、最初の診断の段階。どの会社もアジャイルを取り入れていたが、組織としての変革は途中で、階層的な指揮統制の管理のもと、戦略の決定にチームを関わらせていなかった。
• やったこと: チームの一員だった研究者がいる 3 チームは、すでに情報があった。残りのチームでは、チームリーダー・スクラムマスター・開発者に非構造化の聞き取りをし、各イベントがスクラムガイドどおりに行われているかを、チームごとに表にまとめた。続いて、レトロスペクティブについて、価値があるか、繰り返しになっていないか、準備と構造があるか、全員が話しているか、不満を言う場になっていないか、義務でなければ出るか、をメンバーに 1 人ずつ聞いた。ほかのメンバー（特にスクラムマスター）の前では正直に答えにくい内容なので、フォーカスグループではなく個別の聞き取りにし、答えを個人に辿れないことを約束した。
• 起きたこと: Dyna_A を除くチームは、Scrum を意図どおりに使っていなかった。新しいユーザーストーリーの実装が、アジャイルの実践に従うことより優先されていた。 Dyna_A は Scrum に厳密に従っていたが、従うよう強いられており、メンバーのほぼ半分は、義務でなければレトロスペクティブに出ないとした。ほかのチームには、デイリースクラムを開かない（メンバーが別々の部屋にいて、重なる時間が数時間しかない）、レビューとレトロスペクティブを 1 つにまとめる、レビューを報告書に置き換える、時間に追われてレトロスペクティブをたいてい飛ばす、といった違いがあった。レトロスペクティブの聞き取りでは、どのチームも一般的な問題の多くに当たっていたが、必ずしも深刻ではなかった。著者は後で、6 チームのうち 5 チームで Scrum の実施が枠組みから外れており、どの場合も、その外れ方が組織の機能不全を覆い隠していたと書いている。
• 注意点: ガイドとの違いは研究者の聞き取りとチームの中からの知識で整理したもので、決まった尺度で数えたものではない。「機能不全を覆い隠していた」は著者の見立てである。著者は、レトロスペクティブの問題を尋ねたこと自体が、改善が要ると参加者に示して答えを偏らせたかもしれないと書いている。 SentiOne の 1 チーム（Senti_B）のメンバーの多くは Scrum に新しく、レトロスペクティブの質問に答えられなかった。
• 根拠: アクションリサーチ／複数チーム。文献: Game-based Sprint retrospectives: multiple action research（2021）。文献の種類: 論文・研究者。位置: 5.1 Diagnosing（Table 6, Table 7）/ 5.5.8 Lesson 8 / 6.2 Internal validity。確認の根拠: 原典
• 原文: “In all cases, the deviations covered up organizational dysfunctions”

ステージング環境への反映を「リリース」と呼び、本番へのリリースは年 1 回に限られていた例や、内部の役割を「ステークホルダー」と呼ぶ例を、著者たちが見ていた ［Do Agile Scaling Approaches Make a Difference（2024）］

• 状況: スケーリングの枠組みとチームの有効性を比べた研究の考察で、著者たちが自分たちの観察として挙げた例。ステークホルダーと直接やりとりできない例と、内部の役割を「ステークホルダー」と呼ぶ例は、LeSS・SAFe・Scrum of Scrums、スケーリングしない Scrum のいずれの環境でも見たとしている。「リリース」の例は、どの環境のものかは書かれていない。
• やったこと: 本文は、これらのチームに誰かが手を打ったかを書いていない。
• 起きたこと: ステークホルダーと直接やりとりすることを許されていないチームや、プロジェクトマネージャーやプロダクトオーナーのように利用者や顧客と直接やりとりしない内部の役割を「ステークホルダー」と呼ぶチームがあった。ステージング環境への反映を「リリース」と呼び、社内の手続きで本番への実際のリリースは年 1 回に限られていた例もあった。著者は、どの枠組みも、呼び名と役割が変わるだけで、ふるまいの深い変化を伴わない表面的な形で実施されうると考察している。そのうえで、チームが頻繁にリリースしているか、そのリリースでステークホルダーからフィードバックを集めているか、改善の機会を繰り返し作っているか、職能横断で十分に自律しているかを評価することを提案している。
• 注意点: 著者の逸話としての観察で、件数や、どの組織の例かは示されていない。評価の提案は著者の考えで、その評価を使ってどうなったかは試されていない。
• 根拠: 経験報告／複数チーム。文献: Do Agile Scaling Approaches Make a Difference? An Empirical Comparison of Team Effectiveness Across Popular Scaling Approaches（2024）。文献の種類: 論文・研究者。位置: 5.4 Why Agile scaling approaches don’t seem to make a difference。確認の根拠: 原典
• 原文: “The authors have anecdotally observed cases where a release to a staging environment was labeled as a “release””

アジャイルを 5 年を超えて続けた事業部門が、チームの成熟度モデルで定期的にチームを評価し、成熟度の低いチームを見つけて支援できるようにしていた ［An exploratory study of sustaining organisational agility（2025）］

• 状況: ニュージーランドの IT 中心の上場企業の、最大の事業部門（Retail。仮名）。2016 年にアジャイルへの移行を始め、5 年を超えて続けていた（聞き取りは 2022 年の第 4 四半期）。アジャイルの知識と経験の差が、IT と非 IT の部署の間、上級管理職と現場の間にあった。たとえば、プロダクトオーナーやマーケティングのチームの多くは、カンバンとスクラムの実践より先の原則を知らなかった。技術以外のチームは、アジャイルの役割とスクラムのイベントを与えられても、以前の役割のときと同じ働き方を続けたがった。
• やったこと: 全階層での研修、アジャイルの経験のある人を新しいチームや非 IT のチームに付けることに加え、チームの成熟度モデルを入れ、基準のモデルに照らしてチームを評価した。成熟度の低いチームを正式に見つけて支援するためである。成熟度の評価は間隔を置いて行い、プラットフォームや領域ごとの成熟度の評価も作った。外部のコンサルタントに、組織のアジャイルの状態の評価も頼んだ。
• 起きたこと: 本文は、定期的な評価によって、アジャイルの度合いの低い部署を見つけ、俊敏さを高めるよう支援できるようになったと書いている。実際にどの部署がどう変わったかは書かれていない。外部の評価の報告は、経営陣に、社内のアジャイルのチャプターの声を聞くよう勧めた（参加者 1 人の話）。著者は、成熟度の低いチームは、アジャイルの原則への理解が浅いまま、ある実践を硬直的に行い、俊敏さを狭めていたと考察している。
• 注意点: 成熟度モデルの中身（項目や尺度）と、評価の後に何がどれだけ変わったかの数値は書かれていない。単一組織の質的ケーススタディで、インタビュー対象の 9 人は全員アジャイルの専門職である。
• 根拠: 事例研究／大規模な組織。文献: An exploratory study of sustaining organisational agility（2025）。文献の種類: 論文・研究者。位置: 4.1 Case description / 4.3.1 Disparate levels of maturity / 4.4.8 Monitor, measure, feedback, and act / 5. Discussion。確認の根拠: 原典
• 原文: “Agile team maturity was also evaluated at intervals.”

アジャイルになろうとしていると答えた大企業 4 社の 8 人は、誰も Water-Scrum-Fall だとは言わなかったが、聞き取りから見えた実態はその形だった ［Real-Life Water-Scrum-Fall（2023）］

• 状況: チェコの市場で事業をする、従業員 5000 人を超え、規制の強い業種の大企業 4 社。どの会社も、ウォーターフォールで進めていたところにアジャイルの実践を取り入れていた。 4 社のうち 1 社は、聞き取りの時点でアジャイルな働き方への移行を進めていた。チームリーダー・開発者・プロジェクトマネージャー・スクラムマスターの 8 人が聞き取りに答えた。
• やったこと: 研究者が、計画と要求の収集、Scrum の役割とイベント、展開、プロジェクトの成功率、評価、今後の計画を主題に半構造化の聞き取りをし、主題分析をした。
• 起きたこと: 全員が、自分の組織はアジャイルになろうとしていると答えた。Water-Scrum-Fall に従っていると明言した人はいなかったが、著者は、結果は Water-Scrum-Fall が実態だったことを示したと書いている。開発の段の Scrum は手直しされていて、デイリーを 2 日に 1 回 30 分ほど開く、必要に気づいていないのでレトロスペクティブを開かない、といった例があった。スプリントレビュー、顧客との密な協働、開発中のほかのフィードバックの仕組みに触れた人はいなかった。リリースは会社全体のリリース枠（ある会社では月 1 回）に合わせていて、スプリントごとではなかった。 3 人は、プロジェクトのほぼ 100% が納期と予算どおりに届くと述べたが、その納期と予算は変更要求で動かされていた。著者は、参加者が成功の要素として納期と予算だけを考えていて、作ったものが役立つかの評価は完了後の段で行われていると書いている。
• 注意点: 雪だるま式に集めた 8 人への聞き取りで、チェコの市場の会社だけを対象にしている。著者は一般化が難しいとしている。 Water-Scrum-Fall かどうかは研究者の主題分析による判断で、決まった尺度で測ったものではない。本人たちの認識と実態のずれを、それ自体として調べた研究ではない。
• 根拠: 事例研究／大規模な組織。文献: Real-Life Water-Scrum-Fall: Insights from Large Companies in Czech Republic（2023）。文献の種類: 論文・研究者。位置: 3 Research Method / 4 Results（Scrum / “Fall” / Project Success Rate）/ 5 Discussion。確認の根拠: 原典
• 原文: “None of the interviewees explicitly said that they are following Water-Scrum-Fall. However, the results showed that Water-Scrum-Fall was the reality.”

前提に反する事例

今回読んだ範囲では、見つかっていない。

調査から分かっていること

メンバーが専任で、誰が何をどうやるかをチームの中で決め、スクラムの価値基準が仕事の向きを決めているチームほど、「うまく使えている」と答えた ［Mastering scrum with a focus on team maturity and key…（2023）］

• 状況: スクラムチームのメンバー 182 人への横断的なアンケート。「自分のチームはスクラムをうまく使えている」という本人の認識と、チームの構成・スクラムの価値基準についての項目との関係を調べた。
• やったこと: 介入ではなく、関係の分析である（カイ二乗検定とロジスティック回帰）。
• 起きたこと: チームの構成では、自己管理（誰が何をいつどうやるかをチームの中で決める。カイ二乗 39.970）、アジャイルの研修（22.396）、必要な技能と専門性がチームにそろっている（14.347）、メンバーが専任（14.315）、入れ替わりが少ない（10.826）が「うまく使えている」という認識と関係し、メンバーが同じ場所にいるか（2.363）は関係が無かった。縮小モデルに残ったのは、専任・研修・自己管理だった。価値基準では、6 項目すべてが関係し、縮小モデルには「5 つの価値基準がチームの仕事の向きを決めている」「チームとステークホルダーが仕事と課題について率直に話している」「メンバーに、正しいことをして難しい問題に取り組む勇気がある」が残った。
• 注意点: 項目も認識も回答者本人の答えで、横断的な調査である。因果は言えない。データの収集は COVID-19 で在宅勤務が強いられた時期と重なっていたと著者は書いており、同じ場所にいるかの結果はその影響を受けている可能性がある。
• 根拠: 調査（アンケート）／単一チーム。文献: Mastering scrum with a focus on team maturity and key components of scrum（2023）。文献の種類: 論文・研究者。位置: 4.2（Table 5, Table 6）/ 4.3（Table 7, Table 8）/ 5.2 Team composition。確認の根拠: 原典
• 原文: “However, co-location of team members (TC2) does not influence the perception of being successful at Scrum.”

イベントを枠組みどおりに組んでいるという答えは「うまく使えている」という認識と関係したが、タイムボックスやスプリントの長さを守っているかは関係が見つからなかった ［Mastering scrum with a focus on team maturity and key…（2023）］

• 状況: スクラムチームのメンバー 182 人への横断的なアンケート。「自分のチームはスクラムをうまく使えている」という本人の認識と、イベントとスクラムマスターの役割についての項目との関係を調べた。
• やったこと: 介入ではなく、関係の分析である（カイ二乗検定とロジスティック回帰）。
• 起きたこと: 4 つのイベントを枠組みどおりに組んでいるかは、どれも「うまく使えている」という認識と有意な関係があった（カイ二乗はスプリントレトロスペクティブ 26.177、スプリントプランニング 11.626、スプリントレビュー 5.117、デイリースクラム 3.968）。一方、「すべてのイベントがタイムボックスに収まっている」（0.520）、「スプリントは 1 か月以内」（2.631）、「イベントの外の会議が要る」（0.241）は有意な関係が無かった。イベントの特徴の 5 項目でロジスティック回帰をしても、有意な項目は無かった。スクラムマスターの項目では「すべてのイベントが開かれるようにしている」が縮小モデルに残り、「イベントをタイムボックスに収めている」は有意な関係が無かった（1.037）。
• 注意点: イベントを枠組みどおりに組んでいるかも、うまく使えているかも、回答者本人の答えである。横断的な調査で、因果は言えない。関係が見つからなかったという結果は、タイムボックスに意味が無いことを示したものではない。
• 根拠: 調査（アンケート）／単一チーム。文献: Mastering scrum with a focus on team maturity and key components of scrum（2023）。文献の種類: 論文・研究者。位置: 4.4（Table 9, Table 12）/ 4.5 How does Scrum events impact the perception of successful application of the Scrum framework?（Table 13）。確認の根拠: 原典
• 原文: “No link is seen for the last four (SE7–SE10).”

長く一緒に働いてきたチームのメンバーほど、「自分のチームはスクラムをうまく使えている」と答えた ［Mastering scrum with a focus on team maturity and key…（2023）］

• 状況: デンマークの企業を中心に、スクラムチームのメンバー 182 人へ横断的なアンケートをした研究。「自分のチームはスクラムをうまく使えている」か「スクラムの使い方を改善する必要がある」かの二択で答えてもらい、チームが一緒に働いてきた年数（1 年未満・1〜3 年・3 年超）との関係を調べた。
• やったこと: 介入ではなく、関係の分析である（カイ二乗検定）。
• 起きたこと: 「うまく使えている」と答えたのは、1 年未満のチームで 43 人中 12 人、1〜3 年のチームで 95 人中 51 人、3 年を超えるチームで 44 人中 33 人だった（カイ二乗 19.420、ガンマ 0.537）。著者は、研修や認定だけでは足りず、経験を通じて時間をかけて成熟したチームがうまくいきやすいと考察している。
• 注意点: 「うまく使えている」は回答者本人の二択の認識で、外から確かめた判定ではない。著者は、プロジェクトの成果（納期・費用・ステークホルダーの満足）は調べておらず、スクラムをうまく使えていることが成果につながるかは何も言えないと書いている。成熟は一緒に働いてきた年数だけで測っている。横断的な調査で、因果は言えない。調査は知人と LinkedIn を通じて配っており、回答者に偏りがありうる。
• 根拠: 調査（アンケート）／単一チーム。文献: Mastering scrum with a focus on team maturity and key components of scrum（2023）。文献の種類: 論文・研究者。位置: 4.1 Does team maturity impact the perception of successful application of the Scrum framework?（Table 4）/ 5.1 Team maturity / 6. Limitations。確認の根拠: 原典
• 原文: “we cannot say anything about if being successful at a particular agile method, Scrum, will also impact project outcome success”

応答性・ステークホルダーへの配慮・継続的改善・チームの自律・マネジメントの支援の 5 つで、チームの有効性の差の多くを説明できた ［A Theory of Scrum Team Effectiveness（2022）］

• 状況: 13 の事例研究からスクラムチームの有効性のモデルを作り、1,978 チームの 4,940 人への調査（scrumteamsurvey.org の質問票）で検証した研究。チームの有効性は、ステークホルダーの満足とチームの士気で測っている（どちらもメンバーの自己報告）。
• やったこと: 介入ではなく、構造方程式モデルによる関係の分析である。
• 起きたこと: モデルはデータによく当てはまり、5 つの要因は、ステークホルダーの満足の分散の 57.9%、チームの士気の分散の 34.9% を説明した。著者は、スクラムチームはより大きな組織の中にあるが、チームを有効にするものの多くはチームの単位で設計し、評価できることを示すとしている。
• 注意点: 横断的な調査で、因果は言えない。項目はすべて自己報告で、ステークホルダーの満足もメンバーが思う満足である。著者は、このような感情にもとづく尺度はハロー効果を受けうるとし、ステークホルダー本人に満足を聞くことと、より客観的な尺度を今後の課題にしている。
• 根拠: 調査（アンケート）／単一チーム。文献: A Theory of Scrum Team Effectiveness（2022）。文献の種類: 論文・研究者。位置: 6.3 Model fit evaluations / 7 DISCUSSION / 7.1 Limitations。確認の根拠: 原典
• 原文: “much of what makes Scrum teams effective can be designed and assessed at the team level”

どのスケーリングの枠組みを使っているかでは、チームの有効性とステークホルダーの満足はほとんど変わらず、アジャイルの経験のほうが大きく関係していた ［Do Agile Scaling Approaches Make a Difference（2024）］

• 状況: 2021 年 9 月から 2023 年 9 月までの公開のオンライン調査。チームが自分たちの進め方を自己診断するための公開の調査（scrumteamsurvey.org）に質問を組み込み、 4,013 チームの 15,078 人と、そのうち 529 チームのステークホルダー 1,841 人が答えた。 SAFe・LeSS・Scrum of Scrums・独自の方法・その他・スケーリングなしで、チームの有効性とその 5 つの要因、ステークホルダーの満足を比べた。
• やったこと: 介入ではなく、比較の分析である（分散分析と重回帰分析。チームの経験と組織の大きさを統制した）。
• 起きたこと: 枠組みの違いによる差は小さく、チームの経験と組織の大きさを統制すると大半が消えた。チームの有効性とその要因で残った差は、効果の大きさが「効果なし」と分類される水準だった。ステークホルダーの満足では、ここで挙げた以外の方法（Other approach）を使うチームの、価値への満足に 1 つ有意な効果が残った。本文はこれを中程度（標準化係数 .151）としているが、表 17・表 18 では「効果なし」と分類しており、書き方が揺れている。枠組みだけを入れたモデルが説明した分散はおよそ 1〜2% で、統制変数を入れたモデルは最大 47.5% を説明した。これは主にチームのアジャイルの経験によるもので、標準化係数は .213〜.686 だった。著者は、違いを生むのは枠組みそのものではなく、組織がアジャイルの原則（利用者と密に協働し、頻繁にリリースする）をどれだけ守っているかだと考察している。
• 注意点: 横断的な調査で、因果は言えない。チームの有効性は、メンバーが答えた士気と、メンバーが思うステークホルダーの満足で測っている。公開の調査で、第一著者のブログやポッドキャストなどで広く募った。メンバーは組織の人から招かれて答えているが、自己選択の偏りがありうると著者は書いている。回答率は計算できない。ステークホルダーの満足の比較で、LeSS の群は 7 チーム（ステークホルダー 44 人）だけだった。
• 根拠: 調査（アンケート）／複数チーム。文献: Do Agile Scaling Approaches Make a Difference? An Empirical Comparison of Team Effectiveness Across Popular Scaling Approaches（2024）。文献の種類: 論文・研究者。位置: Abstract / 3.2 Participants / 5.1–5.4 / Table 18 / 5.6 Limitations。確認の根拠: 原典
• 原文: “teams appear to be comparably effective under any scaling approach and their stakeholders are equally satisfied”

メンバーが思うステークホルダーの満足と、ステークホルダー本人が答えた満足の相関は、中程度にとどまった ［Do Agile Scaling Approaches Make a Difference（2024）］

• 状況: スケーリングの枠組みとチームの有効性を比べた大規模な調査（4,013 チーム）のうち、ステークホルダー本人の回答が得られたチームについての分析。メンバーにはステークホルダーが満足していると思うかを聞き、ステークホルダーには価値・応答性・リリースの頻度への満足を聞いている。
• やったこと: 介入ではなく、メンバーの答えとステークホルダーの答えの比較である。著者は、自己報告の評価がハロー効果を受けている恐れを確かめるために、この分析をした。
• 起きたこと: メンバーが答えたステークホルダーの満足と、ステークホルダー本人が答えた満足の相関は .346〜.424 で、中程度だった。著者は、これをハロー効果の一定の根拠としている。ただし、ステークホルダー向けの尺度はより広く多面的で、メンバー向けの項目は満足していると思うかを聞いただけだった、とも書いている。
• 注意点: ステークホルダーはチームが自分で招いている。満足しそうな人だけを招いた可能性や、有効なチームだけが招いた可能性を、著者は否定しきれないとしている（事後の検定では、チームの有効性と招いた人数に有意な関係は無かった）。 2 つの尺度は項目が違うので、相関の低さがすべて見誤りによるとは言えない。
• 根拠: 調査（アンケート）／複数チーム。文献: Do Agile Scaling Approaches Make a Difference? An Empirical Comparison of Team Effectiveness Across Popular Scaling Approaches（2024）。文献の種類: 論文・研究者。位置: 5.6 Limitations（Internal validity）。確認の根拠: 原典
• 原文: “While this provides some evidence of a halo effect”

スクラムマスターもメンバーも、自分たちのリーダーシップの活動を、相手がつけるより高く評価する傾向があった ［A Quantitative Exploration of the 9-Factor Theory（2020）］

• 状況: Robert Bosch GmbH のスクラムチームの 67 人（スクラムマスター 37 人、メンバー 30 人）へのオンライン調査。本文は 19 を超えるチームからの参加としている。チーム名の記入は任意で、記入した 37 人は 19 チームにあたった。回答をチームに対応づけられないため、個人の回答として比べている。スクラムマスターの 9 つのリーダーシップの役割にもとづく 55 項目について、自分についての評価と、相手（スクラムマスターならチーム、メンバーならスクラムマスター）についての評価を、5 段階で答えてもらった。チームと公式のリーダーではリーダーシップのふるまいの評価が分かれることが多いので、両方から評価させたと著者は書いている。
• やったこと: 介入ではなく、記述統計による比較である。
• 起きたこと: 9 つの役割の平均では、スクラムマスターは自分を、チームがスクラムマスターにつけるより高く評価し、チームの活動は低く評価する傾向があった。例外は Networker（つなぎ役）で、スクラムマスターはチームを、チームが自分たちにつけるよりわずかに高く評価した。メンバーも、自分たちを、スクラムマスターがつけるより高く評価し、スクラムマスターの活動は低く評価する傾向があった。
• 注意点: 1 社の 67 人の調査で、記述統計だけである。評価の差が偶然の範囲を超えるかの検定は書かれていない。評価の対象はリーダーシップの活動で、チームがスクラムをできているかそのものではない。
• 根拠: 調査（アンケート）／複数チーム。文献: A Quantitative Exploration of the 9-Factor Theory: Distribution of Leadership Roles Between Scrum Master and Agile Team（2020）。文献の種類: 論文・研究者。位置: 3.1 Company Context and Participants / 3.2 Measurement（Self-Assessment and External Assessment）/ 4 Results。確認の根拠: 原典
• 原文: “the Scrum Master tended to rate herself higher than the team rated the respective Scrum Master, while the Scrum Master tended to rate the agile team lower”

スプリントの長さやデイリースクラムの開催は守られていると答えた人が多い一方、42 人のうち 28 人がスプリントのタスクが終わらないことは頻繁だと答え、20 人がスプリントゴールをプランニングの終わりに決めるか、決めないことが頻繁だと答えた ［Exploring the Prevalence of Anti-patterns in the Application…（2023）］

• 状況: ポーランドのソフトウェア開発の組織で働く 42 人へのアンケート（2022 年 5〜6 月、LinkedIn と SNS で募集）。文献から選んだ Scrum のアンチパターン 35 個について、自分の組織で出会うかを「全くない」から「いつも」の 5 段階と「分からない」で答えてもらった。回答者の多くは開発者（31 人）で、スクラムマスターは 4 人、プロダクトオーナーは 1 人だった。
• やったこと: 介入ではなく、出会う頻度の調査である。
• 起きたこと: 「スプリントで終えるはずのタスクが全部は終わらない」を「全くない」と答えた人はいなかった。42 人のうち 28 人が「よくある」か「いつも」（19 人と 9 人）と答えた。「デイリースクラムが 15 分を超える」は 23 人、「スプリントゴールをプランニングの最後に決めるか、決めない」は 20 人が「よくある」か「いつも」と答えた。一方で、「スプリントが長すぎる」と「デイリースクラムが決まった時間に開かれない」はそれぞれ 33 人、「デイリースクラムが毎日開かれない」は 28 人が「全くない」と答えた。著者は、回答を重み付けした得点で、最も多いアンチパターンを「終わらないタスク」とし、ほかに「デイリースクラムが 15 分を超える」「ユーザーストーリーが十分に詳しくなっていない」「スプリントゴールが決まらない」「バーンダウンチャートを使わない」「テストが次のスプリントになる」を多いものに挙げた。プロダクトオーナーの節は「分からない」の答えが最も多く、著者は、回答者がプロダクトオーナーの役割を十分に分かっていない可能性を挙げている。
• 注意点: 42 人の回答で、募集に応じた人だけが答えている。一国の調査である。回答は人ごとで、組織ごとに集計したものではない。重み付けした得点は満点に対する比で、「その状態にある組織の割合」ではない。頻度は回答者の認識で、記録や観察で確かめたものではない。著者は、アンチパターンが起きる原因は調べておらず、今後の研究にするとしている。
• 根拠: 調査（アンケート）／大規模な組織。文献: Exploring the Prevalence of Anti-patterns in the Application of Scrum in Software Development Organizations（2023）。文献の種類: 論文・研究者。位置: III. SURVEY DESIGN / IV. RESULTS（Table II, Table III, Table V, Table VI, Table IX）/ V. DISCUSSION / VI. CONCLUSION。確認の根拠: 原典
• 原文: “None of the respondents stated that there is never a situation where all the tasks that are supposed to be completed in a sprint are completed.”

Scrum の実践を取り入れていない会社の多くは、要らない、または自分たちは十分に成熟していると説明しており、同じ理由でスクラムマスターを置かない例もあった ［Tailoring Choices Made in Scrum Projects（2022）］

• 状況: Scrum を各社が自分たちの文脈に合わせてどう変えているか（テーラリング）を扱った、23 本の論文の体系的文献レビュー。変えられていた実践・役割・作成物と、その結果の報告を整理している。
• やったこと: 介入ではなく、各社が実際にしていた変え方と、その理由・結果の整理である。
• 起きたこと: 最も多く変えられていた実践はスプリントレビューで、デイリースクラム、スプリントプランニングとスプリントレトロスペクティブが続いた。特定の実践を取り入れていない会社の多くは、その実践が要らない、または特定の実践が無くてもできるほど成熟していると述べていた。スクラムマスターを置かない理由として、チームが自分たちは十分に成熟していると考え、専任のスクラムマスターの必要を感じていなかった例が、1 本の研究から挙がっていた。著者は、変更から悪い結果を示した会社が多かったとまとめている（スプリントの期限が無い、スプリントゴールがはっきりしない、顧客に価値の無い機能を作った、顧客から頻繁にフィードバックを得られない、非現実的なスプリントゴールなど）。
• 注意点: 個々の実践の変更の結果についての根拠は十分ではないと、著者自身が書いている。「成熟している」という各社の説明が当たっていたかは、確かめられていない。「悪い結果」の整理には、Scrum ガイドとの照らし合わせにもとづく著者の判断も含まれる。対象の研究の多くは調査や聞き取りによる。
• 根拠: 文献レビュー／大規模な組織。文献: Tailoring Choices Made in Scrum Projects: A Systematic Literature Review（2022）。文献の種類: 論文・研究者。位置: 4.1 RQ 1.1 / 4.2 RQ1.2 / 4.4 RQ 2 / 5. Discussion / 5.1 Threats to Validity。確認の根拠: 原典
• 原文: “these team considered themselves mature enough and see no reason to have a dedicated SM”

出典一覧

文献	年	ライセンス	記録の数
Do Agile Scaling Approaches Make a Difference? An Empirical Comparison of Team Effectiveness Across Popular Scaling Approaches	2024	CC BY 4.0	3
An exploratory study of sustaining organisational agility	2025	CC BY 4.0	1
Game-based Sprint retrospectives: multiple action research	2021	CC BY 4.0	1
Impact of the Kanban Maturity Model on a Team’s Agile Transformation: Tripling Throughput and Elevating Quality in Three Months	2024	CC BY 4.0	1
Leadership Gap in Agile Teams: How Teams and Scrum Masters Mature	2019	CC BY 4.0	1
Mastering scrum with a focus on team maturity and key components of scrum	2023	CC BY 4.0	3
A Quantitative Exploration of the 9-Factor Theory: Distribution of Leadership Roles Between Scrum Master and Agile Team	2020	CC BY 4.0	1
Exploring the Prevalence of Anti-patterns in the Application of Scrum in Software Development Organizations	2023	CC BY 4.0	1
Real-Life Water-Scrum-Fall: Insights from Large Companies in Czech Republic	2023	CC BY 4.0	1
Tailoring Choices Made in Scrum Projects: A Systematic Literature Review	2022	CC BY 4.0	1
A Theory of Scrum Team Effectiveness	2022	CC BY 4.0	1

---

🔍 妥当性検証レポート（クリックして展開）

• 総合判定: ✅ 合格 (スコア: 90/100)
• 評価の前提: 結論（TL;DR）を、このページに載せた事例と知見だけに照らして評価した
• 形式論理検証: PASS
• LLM批判的評価（agy: gemini-3.8-flash-high）: Faithfulness 5.0/5, Relevance 4.0/5

評価コメント:

• 【評価理由】 - Faithfulness（5点）: 前提コンテキストの記載内容に極めて厳密に準拠しています。コンテキスト外の独自解釈や俗説、スクラムの一般論（コンテキストにないスクラムガイドの教条主義的な知識等）の混入は一切ありません。各研究の注意点（「因果は言えない」「成果につながるかは調べられていない」「ハロー効果」「実態との整合性を確かめた記録はない」など）を正確に反映し、事実と限定事項を誠実に記述しています。 - Relevance（4点）: 質問である「チームがスクラムやアジャイルをできているかを、スクラムマスターはどんな観点やデータで見極めるのが良いか？」に対し、コンテキストに基づき「形式的遵守（タイムボックスやイベント開催）では見極められないこと」「自己報告データの歪み（ハロー効果や評価の乖離）」といった見極めの落とし穴を指摘した上で、有効性の5要因（応答性、ステークホルダーへの配慮、継続的改善、自律、マネジメント支援）やスクラムマスターからチームへの役割移譲度合いを見極めの材料として提示しており、論理的に回答しています。ただし、質問の核心である「スクラムマスターが着目すべき観点やデータ」に対する直接的な提示よりも、既存研究の要約や「何が見極めとして機能しないか（アンチパターンや形式主義の例）」の列挙に紙幅の多くが割かれており、スクラムマスター視点での観点の整理が後半に圧縮されている構成であるため、厳格な監査基準に基づき4点と評価しました。

---

関連する用語

• スクラムチーム
• チームの成熟度
• 経験主義
• スクラムの価値基準
• ウォータースクラムフォール