コンテンツにスキップ

スクラムマスターは観察をするとありますが、具体的に何をすれば良いですか?

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

スクラムマスターが具体的に何を観察し、どう行動に結びつけるかについて、実証研究では「日々の会議や言動の観察」「ふりかえりの質や形式の点検」「外部からの影響と集中」「チームの自律性の段階の見極め」といった多角的な実践と留意点が報告されています。

まず会議や日常の観察において、話が長引くデイリースクラムでは段階的に時間を意識づける促しが試みられた一方、手順の厳格さを求めすぎると反発を招く事例が報告されています。また、メンバー間の対立や個人への責任追及の兆候、会議を妨害・欠席するような言動に対しては、個人的な衝突とせずレトロスペクティブなどの公式な対話の場に持ち込んで客観的な共通課題として認識させた実践がある一方、話し合いだけでは本人の言動が変わらずマネジメントによる対応に至った例もあり、対話の場を設けること自体の限界も示されています。

プロセスの検査と適応(ふりかえり)においては、ふりかえりの質(役に立つ改善の創出・率直な対話・根強い課題の探求)を含む継続的改善の風土が高いチームほど、ステークホルダーへの配慮や応答性の高さに関係していたという大規模調査の分析があります。また事例観察では、毎回同じ定型形式を繰り返すチームよりも、話題や形式を多様化させて多角的に点検するチームにおいて、より広い分野で改善を生み出す傾向が観察されています(形式変更単体の因果効果を測ったものではありません)。

外部との関わりにおいては、外部からの割り込みや要求から開発者を守る緩衝役(バッファ)として機能し、中断のない集中時間を確保する役割が挙げられています。

介入の見極めとしては、基本は「一歩引いてチームに任せる(Step Back)」ことでチーム自身の自己リーダーシップを促しつつ、チームが初期段階で責任を引き受けられない局面では、経験のある立場からの介入が必要になるバランスが語られています。またメンバーの不満の言動を捉える際、自分たちの手の届く範囲に向いていれば改善の契機になり得ますが、チームに自律性がなく手の届かない要因に向いている場合は伝染しやすく破壊的になりやすいと指摘されています。

留意点として、AIツールによる自動生成レポートの確認に偏るとチームとの直接の対話の減少が懸念されるほか、スクラムマスター自身は自分の活動をチームの評価よりも高く見積もる傾向(自己評価と他者評価の乖離)が確認されており、自分自身の関わり方に対する自己評価が甘くなりやすい点に留意が必要です。

Scrum の 3 チームで、スプリントとスクラムマスターで割り込みを緩衝し、静かな時間と担当者への振り分けで、開発に集中する時間を守っていた [Interruptions in Agile Software Development Teams(2021)]

Section titled “Scrum の 3 チームで、スプリントとスクラムマスターで割り込みを緩衝し、静かな時間と担当者への振り分けで、開発に集中する時間を守っていた [Interruptions in Agile Software Development Teams(2021)]”
  • 状況: 自動車業界の 2 チーム(CAR は 4 人、FLEET は 8 人)と銀行の 1 チーム(REAL ESTATE は 9 人)の Scrum のチーム。いずれも同じ場所で働く。顧客の依頼は、FLEET と REAL ESTATE の証言ではメールやチケットで届く。全チームが、顧客がスプリントの途中にも項目を変えると述べている。著者の整理では、アジャイルの特徴(顧客の関与の深さと、メンバー間の直接のやりとり)が、割り込みを増やす。
  • やったこと: スプリントを、外部からの割り込みからチームを囲う場として使った(著者の整理)。スクラムマスターが、不要な割り込みからチームを守った。 FLEET と REAL ESTATE(と Kanban の MONITOR)は、割り込みを受けずに作業できる「静かな時間」を設けた。FLEET は、開発者が朝早くに出社して作業する形をとった。顧客の依頼は、Slack や Jira に記録して正しい担当者に割り当て、他のメンバーの手を直接止めないようにした(本文は全チームの報告として書いている)。例として、REAL ESTATE のテスターは顧客に詳細を聞き、実現性と時期の見立てをつけてシステムに入れた。緊急だと考えれば、デイリーで上げた。 FLEET の開発者の 1 人は、チケットとメールを見る時間を午後に確保して優先づけし、それを「計画された中断」にした。これは、この開発者個人の運用として語られている。著者の整理では、チームは送り手・内容・連絡の手段で割り込みの優先度をつけた。 FLEET の開発者は、チャット、チケット、メールの使い分けで緊急度を伝えた。CAR では、人が席まで駆け込んでくるのは緊急のしるしと受け取られた。
  • 起きたこと: FLEET のスクラムマスターは、朝 7 時から 9 時の静かな時間に、開発者が作業の約 8 割を終えると見積もった。9 時以降はミーティングや休憩で中断された。 REAL ESTATE のスクラムマスターは、スプリントの成功の目安を、開発者がスプリントプランニングで合意した作業に使える時間が 8 割を超えることとしていた。達成できたかどうかは書かれていない。これらの対処の効果は、測定では示されていない。
  • 注意点: スクラムマスターと開発者の証言で、効果は測られていない。「約 8 割」は FLEET のスクラムマスターの見積もりで、「8 割を超える」は REAL ESTATE のスクラムマスターの成功の目安であり、達成した実績ではない。全チームが、顧客がスプリントの途中にも項目を変えると述べており、スプリントがすべての割り込みを防ぐわけではない。対処は互いに別の形で同時に行われていて、どれが効いたかは分けられない。流速や開発量の変化は測られていないので、固定期間のスプリントを守る材料にはなるが、スループットを高める根拠にはならない。探索的な定性研究(4 チーム、19 人への面接)で、3 チームとも大企業のチーム。著者は、小さな組織やオープンソースには当てはまらない可能性を認めている。
  • 根拠: 事例研究/単一チーム。文献: Interruptions in Agile Software Development Teams(2021)。文献の種類: 論文・研究者。位置: Results / Interruptions Caused by Programming-Related Work Impediments(PDF p.5)/ Interruptions Related to Team Interactions(PDF p.6)/ Interruptions Imposed by the External Environment(PDF p.8)/ Discussion(PDF p.8–10)。確認の根拠: 原典
  • 原文: “The sprint is an important vehicle to encapsulate the team from external interruptions to concentrate on development tasks.”

会議を妨害し欠席するメンバーの言動を、コーチがレトロスペクティブの話題にし、本人の行動は変わらなかったが、周りは個人的に受け止めずに対処できるようになった [Role clarity deficiencies can wreck agile teams(2019)]

Section titled “会議を妨害し欠席するメンバーの言動を、コーチがレトロスペクティブの話題にし、本人の行動は変わらなかったが、周りは個人的に受け止めずに対処できるようになった [Role clarity deficiencies can wreck agile teams(2019)]”
  • 状況: ドイツのスタートアップの Scrum チーム。ある開発者がキャリアの次の段階としてチームリードになり、他の人に仕事を割り振りたいと考え、マネジメントに申し出たが、アジャイルの働き方に合わないとして断られた。その後、この開発者は会議を妨害したり、会議に出なかったりするようになった。周りのメンバーは理由が分からず戸惑い、朝に仕事へ行きたくなくなりかけるほど居心地の悪さを感じていた。
  • やったこと: コーチ(スクラムマスター)が、この言動を次のレトロスペクティブの話題にした。その場で本人は、アジャイルの枠から外してチームリードの役割を与えるようマネジメントに仕向けるための、意図的なやり方だと説明した。チームはそのことを率直に話し合った。
  • 起きたこと: コーチによれば、話し合いは状況を解決せず、本人の言動も変わらなかった。一方で、他のメンバーはその言動を個人的に受け止めなくなり、より落ち着いて対処できるようになった。著者は、本人の「妨害する役割」をチームが認識した(受け入れはしなかった)ことで、部分的な明確さが生まれ、チームとしてより良く働けるようになったと解釈している。最終的には、マネジメントが本人に別の道を行くことを提案し、本人もそれに合意した。
  • 注意点: 経過はコーチの話を著者が要約したもので、研究者がそのレトロスペクティブを観察したかは書かれていない。本人の言動そのものは変わっておらず、解決は最終的にマネジメントの判断(離職)によっている。著者自身、完全な役割の受け入れは不可能かもしれないとしている。グラウンデッド・セオリーによる質的研究で、効果を測ったものではない。
  • 根拠: 事例研究/単一チーム。文献: Role clarity deficiencies can wreck agile teams(2019)。文献の種類: 論文・研究者。位置: RESULTS / Effects of having Role clarity / Robustness Against Dysfunctional Behavior(Quote No. 10)。確認の根拠: 原典
  • 原文: “The coach t4sm2 makes this behavior a topic of the next retrospective.”

ふりかえりの形式と話題を変えるチームのほうが、広い分野で改善を生み出す傾向があった [A Theory of Scrum Team Effectiveness(2022)]

Section titled “ふりかえりの形式と話題を変えるチームのほうが、広い分野で改善を生み出す傾向があった [A Theory of Scrum Team Effectiveness(2022)]”
  • 状況: スクラムチームの有効性の研究の前半で行った、複数の組織の事例観察。多くのチームは毎スプリントふりかえりを開いていたが、頻度の低いチームもあった。観察では、ふりかえりが同じ課題を長く出し続けるか、表面の症状でなく深い問題まで掘り下げるか、出た改善策が実行されるかといった点が、チームによって違っていた。
  • やったこと: 定義、顧客満足、コードの質など、話題ごとに形式を変えてふりかえるチームがあった。少数のチームは毎回同じ形式を使い、その形式は「良かった点と変えたい点」を挙げる一般的な型の変形だった。
  • 起きたこと: 同じ形式を繰り返すチームと比べて、形式と話題の幅が広いチームのほうが、より広い分野でより多くの改善を生む傾向があったと、著者は観察している。
  • 注意点: 複数の事例の観察からの傾向で、形式を変えたことの効果を測ったものではない。形式の多様さ以外の違い(チームの経験や組織の状況)との切り分けは書かれていない。同じ形式を使うチームが少数だったため、比べられた数は小さい。
  • 根拠: 事例研究/複数チーム。文献: A Theory of Scrum Team Effectiveness(2022)。文献の種類: 論文・研究者。位置: 4.4.5 Continuous Improvement(Sprint-Retrospective Quality)。確認の根拠: 原典
  • 原文: “a more diverse range of formats and themes tended to generate more improvements in a broader range of areas”

デイリーで話が長い人に時間を区切るなど、規律を求めるスクラムマスターの役割は、利点を感じる人と「人より手順」と受け取る人に分かれた [An empirical study on changing leadership in agile teams(2021)]

Section titled “デイリーで話が長い人に時間を区切るなど、規律を求めるスクラムマスターの役割は、利点を感じる人と「人より手順」と受け取る人に分かれた [An empirical study on changing leadership in agile teams(2021)]”
  • 状況: Bosch の複数の部門でスクラムマスター・開発者・プロダクトオーナーに聞き取りをした、グラウンデッドセオリーの研究。はじめは、スクラムのやり方に従うのを渋るメンバーがいた。あるスクラムマスターは、デイリーで 15 分を過ぎてもまだ話し続ける人がいたと語っている。
  • やったこと: そのスクラムマスターは、2、3 回は様子を見てから、それではうまくいかないと慎重に指摘し、だんだんはっきり伝え、最後はスタンドアップに時計を置いて「時間切れだ」と言った。ほかのスクラムマスターも、デイリーで話す時間を守ることや、レトロスペクティブで合意した取り組みの追跡のような規律を求めた。著者はこれを、肩書きや地位の力ではなく対等なやりとりで規律を保つ役割(Disciplinizer on Equal Terms)と呼んでいる。
  • 起きたこと: スクラムマスターたちによれば、規律を求めると、メンバーはその利点を理解し始めた。一方で、この役割を快く思わず、ある振る舞いを強いられていると感じた開発者もいた。時間の管理を歓迎する人もいれば、手順を守らせることに関心があって人を気にかけていないと感じる人もいた。著者は観察から、いくつかのチームでは時間が経つと開発者のほうがスクラムマスターに、遅刻しないことや話す時間を守ることなど合意したルールを守るよう言うようになったとしている。終わらない議論をやめるよう仲間に促す開発者もいた。
  • 注意点: 対象は、会議で話し過ぎるといった進め方の規律で、他のメンバーとぶつかる言動そのものではない。受け止めが分かれたことは書かれているが、それぞれの人数や、その後の関係の変化は書かれていない。分かれたのは規律を求める役割全体への受け止めで、デイリーの時間を区切ったこと単独への反応としては書かれていない。著者は、この役割がアジャイルの役割と言えるかに確信を持てないと書いている。
  • 根拠: 事例研究/複数チーム。文献: An empirical study on changing leadership in agile teams(2021)。文献の種類: 論文・研究者。位置: 4.1.2 Role 2: Disciplinizer on Equal Terms。確認の根拠: 原典
  • 原文: “others felt that the Disciplinizer was more interested in following a process than caring for people”

レトロスペクティブの前に毎回「誰かを責める場ではない」と伝えるスクラムマスターがいた。別のチームでは、個人に向いていた話が自分たちで変えられることに移った [An empirical study on changing leadership in agile teams(2021)]

Section titled “レトロスペクティブの前に毎回「誰かを責める場ではない」と伝えるスクラムマスターがいた。別のチームでは、個人に向いていた話が自分たちで変えられることに移った [An empirical study on changing leadership in agile teams(2021)]”
  • 状況: Bosch の複数の部門でスクラムマスター(社内では Agile Master と呼ぶ)・開発者・プロダクトオーナーに聞き取りをした、グラウンデッドセオリーの研究。あるスクラムマスターは、チームの最初のレトロスペクティブはかなりひどく、話がいつも外に向いていて、「マネージャーが何もしない」「チームがあれをしない」のように、いつも個人に焦点が当たっていたと語っている。
  • やったこと: 別のスクラムマスターは、レトロスペクティブの前に毎回、目的は誰かを責めることではなく、互いに建設的に話し合って成長することだと説明し、失敗してもよい雰囲気を作ろうとしたと語っている。チームの振る舞いを観察し、生じつつある対立を表に出したと話す回答者もいた(著者はこれを Coach の役割と呼ぶ)。
  • 起きたこと: 最初のレトロスペクティブを語ったスクラムマスターによれば、やがてチームは自分たちが影響でき変えられることを話せるようになった。大きな変化ではないが、それが自分の動機づけになったと述べている。この変化と、毎回「責める場ではない」と伝えたこととの因果は、原文には書かれていない(別々の回答者の話である)。ある開発者は、レトロスペクティブで意見を言ったり心を開いたりするよう促され、ほかのメンバーも「これは不満だ」と言うようになり、そのように率直に話すことはそれまで無かったと語った。著者は、レトロスペクティブが心理的安全性や互いの違い(性格や仕事の進め方)の共有を育てたとまとめている。
  • 注意点: インタビューでの本人の回想で、レトロスペクティブの前後を測ったものではない。特定の人の言動が他のメンバーとぶつかる状況を扱った事例ではなく、チームの話し合いの向きが個人から自分たちの行動に移った報告である。研究の焦点はスクラムマスターからチームへのリーダーシップの移り変わりで、対立の解消は主題ではない。結果は 1 社の文脈に限られると著者は書いている。
  • 根拠: 事例研究/複数チーム。文献: An empirical study on changing leadership in agile teams(2021)。文献の種類: 論文・研究者。位置: 4.1.3 Role 3: Coach / 4.4 Retrospective。確認の根拠: 原典
  • 原文: “the purpose was not about blaming someone but to discuss constructively with each other and to develop further”

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

Section titled “チームが成熟するにつれ、スクラムマスターが担っていた役割の一部をメンバーが担うようになったと語られ、司会と外からの要求を防ぐ役割は移りにくかった [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.”

ウクライナの大学の報告(対照群のある比較)では、スクラムマスターが自動のレポートに頼り、チームと直接話すことが減った例が観察された [AI-Augmented Scrum(2025)]

Section titled “ウクライナの大学の報告(対照群のある比較)では、スクラムマスターが自動のレポートに頼り、チームと直接話すことが減った例が観察された [AI-Augmented Scrum(2025)]”
  • 状況: 3 つの IT 会社で、Scrum の 12 チームに AI ツールを入れて 6 か月追った対照群のある比較。著者は、導入に伴う危険を、観察の範囲で整理している。
  • やったこと: 介入ではなく、導入したチームで観察された危険の記述である。開発者が Copilot の提案をほとんど確かめずに受け入れる例と、スクラムマスターが自動のレポートに頼って、チームと直接話すことが減った例があった。
  • 起きたこと: 著者は、この傾向を、AI がもっともらしく見えるが最適でない案を出すことがあるため、危険になりうると書いている。確かめずに信用すると、技術的負債や見落とした問題につながりうるので、AI が作ったものを検査し、チームで話し合う批判的な思考の文化が要るとしている。著者は、この実験では AI の誤りによる重大な事故は起きなかったとも書いている(ただし、この点はチームのリーダーが常に管理していたと続ける)。スクラムマスターが自動のレポートに頼った結果、チームの状態の把握やチームとの関係がどうなったかは書かれていない(結果の記述なし)。
  • 注意点: 「ある例があった」という著者の観察の記述で、何チームで起きたか、頻度は示されていない。小さな標本の比較で、方法の記述が薄い。著者は、先進的な会社が選ばれた可能性や新奇性の影響を限界に書いている。スクラムマスターが減らした対話が、チームにとって不足だったかは確かめられていない。原文はウクライナ語で、ページに異言語文字を出さない規則のため、原文の引用は書かない(原文を読んで確かめた)。
  • 根拠: 事例研究/複数チーム。文献: AI-Augmented Scrum: Empirical Analysis of the Impact of Implementing AI Tools on the Results of IT Projects(2025)。文献の種類: 論文・研究者。位置: 考察の節(AI 導入の危険の段落)。確認の根拠: 原典

ふりかえりの質を含む継続的改善の風土が高いチームほど、ステークホルダーへの配慮と応答性も高かった [A Theory of Scrum Team Effectiveness(2022)]

Section titled “ふりかえりの質を含む継続的改善の風土が高いチームほど、ステークホルダーへの配慮と応答性も高かった [A Theory of Scrum Team Effectiveness(2022)]”
  • 状況: スクラムチームの有効性の研究の後半。1,978 チーム・4,940 人の回答を構造方程式モデルで分析した。「継続的改善」は、心理的安全性、品質への関心、ほかのチームとの学び合い、学べる環境、そしてふりかえりの質(「少なくとも 1 つは役に立つ改善が出る」「改善について率直に話す」「根強い課題の解決策を探る」の 3 項目)で測っている。
  • やったこと: 介入ではなく、関係の分析である。
  • 起きたこと: ふりかえりの質は継続的改善の指標の 1 つで、因子負荷(標準化)は .713 だった。継続的改善は、ステークホルダーへの配慮(標準化係数 .545)と応答性(.340)に関係していた。チームの自律性は継続的改善に強く関係し(.655)、マネジメントの支援も関係していた(.168)。ふりかえりの質だけを取り出した効果は、分析していない。
  • 注意点: ふりかえりの質は継続的改善の 1 指標で、単独の効果は分からない。横断的なデータで因果は言えず、著者もそう述べている。成果は自己報告である。ふりかえりの質の項目は、著者が事例研究から作った尺度である。
  • 根拠: 調査(アンケート)/単一チーム。文献: A Theory of Scrum Team Effectiveness(2022)。文献の種類: 論文・研究者。位置: 6.4 Hypothesis Testing and Interpretation / 7 Discussion。確認の根拠: 原典
  • 原文: “Sprint Retrospectives that result in actionable improvements”

メンバーの不満の言動は、チームに自律性が無く手の届かないことに向かうときに伝染しやすく破壊的になると、著者はリーダーたちの語りからまとめている [What makes effective leadership in agile software…(2022)]

Section titled “メンバーの不満の言動は、チームに自律性が無く手の届かないことに向かうときに伝染しやすく破壊的になると、著者はリーダーたちの語りからまとめている [What makes effective leadership in agile software…(2022)]”
  • 状況: 自分をアジャイルのリーダーと考える実務者(スクラムマスター、創業者、アジャイルコーチ、プロジェクトマネージャーなど)へのインタビューによる質的調査で、チームのメンバーがリーダーシップを担うことについて語られた部分。
  • やったこと: 介入ではなく、リーダーたちの見方を分類した結果である。
  • 起きたこと: インタビューに答えたリーダーたちは、メンバーが自分たちで状況を良くする立場にあると感じている限り、不満を言うことは必ずしもチームの有効性を損なわないと考えていた。著者は、チームに自律性が無いと、メンバーは自分たちの手の届かない要因について不満を言いがちで、そのときの不満はより伝染しやすく破壊的に見えるとまとめている。また別のリーダーは、一人のメンバーの受け身の姿勢が、チームの能動的な働き方を作れなくし、チームの有効性を損ないうると語った。著者は、これが機能不全のチームについての先行研究と重なるとしている。
  • 注意点: リーダーの立場から見た語りで、不満の広がりや自律性との関係を測ったものではない。不満への具体的な対応や、その結果は書かれていない。受け身のメンバーの話は 1 人のリーダーの語りである。
  • 根拠: 調査(アンケート)/複数チーム。文献: What makes effective leadership in agile software development teams?(2022)。文献の種類: 論文・研究者。位置: 3.1.1 Have Team Members that Take Initiative and Responsibility。確認の根拠: 原典
  • 原文: “Complaining seems more infectious and destructive if teams do not have autonomy because they tend to complain about factors beyond their control.”

アジャイルのリーダーたちは、一歩引いてチームに任せることを重んじつつ、経験のある上司が介入する必要がある場面もあると語った [What makes effective leadership in agile software…(2022)]

Section titled “アジャイルのリーダーたちは、一歩引いてチームに任せることを重んじつつ、経験のある上司が介入する必要がある場面もあると語った [What makes effective leadership in agile software…(2022)]”
  • 状況: 自分をアジャイルのリーダーと考える実務者(スクラムマスター、創業者、アジャイルコーチ、プロジェクトマネージャーなど)13 人への半構造化インタビューによる質的調査。参加者は米国・ブラジル・ドイツ・英国・チュニジアの、規模の異なる会社に属していた。
  • やったこと: 介入ではなく、リーダーたちが語った効果的なリーダーシップの特徴を分類した結果である。
  • 起きたこと: 13 人中 10 人が、チームのリーダーシップはチームで分かち合われるときにだけ効果的だと述べた。 8 人は、チームを取り巻く従来型の管理者がチームの自己リーダーシップを損ないうると述べた。リーダーが一歩引くことは、早い段階では導きが要り、個人やチームがより大きな責任を負える時期を見極めにくいため、難しいと語られた。一方で 2 人は、自己組織化を目指していても、経験のある上司が介入する必要がときどきあると明言した。そのうち 1 人は、介入の仕方がはっきりしていたのでチームに歓迎されたと述べ、もう 1 人は、チームがなかなか責任を引き受けないため自分が判断を助けざるをえないことに苛立ちを語った。先輩の社員の支えがあると、メンバーは問題をチームに持ち帰る前にその人に確かめられて助かるとも語られた。
  • 注意点: リーダーの立場から見た語りだけで、チームのメンバーの側の受け止めや、介入の結果は調べていない。介入の具体的な中身(どんな問題に、どう介入したか)は書かれていない。対人の摩擦や対立に特定した話ではなく、リーダーシップ全般についての語りである。参加者は少数で、第一著者の自動車会社でのアジャイルの経験が分析に影響した可能性を著者は認めている。
  • 根拠: 調査(アンケート)/複数チーム。文献: What makes effective leadership in agile software development teams?(2022)。文献の種類: 論文・研究者。位置: 3.1 Dynamic Team Leadership(3.1.2 Let Team Members Lead / 3.1.3 Step In, If Needed); 2.1 Participants; 6 LIMITATIONS。確認の根拠: 原典
  • 原文: “Two of the interviewees explicitly stated that, even if they strove for self-organization, an experienced supervisor sometimes needed to intervene.”

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

Section titled “スクラムマスターもメンバーも、自分たちのリーダーシップの活動を、相手がつけるより高く評価する傾向があった [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”
文献年ライセンス記録の数
AI-Augmented Scrum: Empirical Analysis of the Impact of Implementing AI Tools on the Results of IT Projects2025CC BY 4.01
An empirical study on changing leadership in agile teams2021CC BY 4.02
What makes effective leadership in agile software development teams?2022CC BY 4.02
Interruptions in Agile Software Development Teams2021CC BY 4.01
Leadership Gap in Agile Teams: How Teams and Scrum Masters Mature2019CC BY 4.01
A Quantitative Exploration of the 9-Factor Theory: Distribution of Leadership Roles Between Scrum Master and Agile Team2020CC BY 4.01
Role clarity deficiencies can wreck agile teams2019CC BY 4.01
A Theory of Scrum Team Effectiveness2022CC BY 4.02

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

評価コメント:

  • 【総評】提示された前提コンテキストの全事例・知見・注意点を余すところなく正確に反映しており、コンテキスト外の俗説や勝手な断定を排した極めて精度の高い回答です。質問の「具体的に何をすれば良いか」に対しても、観察の対象とそれに応じた具体的アクション・留意点という形で論理的に構造化して的確に答えています。【Faithfulness(忠実性)の評価: 5点】 - 前提コンテキストに含まれる多様な実証研究・事例(Boschでの規律維持や対立の顕在化、スタートアップでの妨害言動とマネジメント介入、ふりかえりの質・多様性と改善の傾向、AIツール導入による直接対話の減少、リーダーシップの移譲と上司の介入、自己評価と他者評価の乖離など)が正確に網羅されています。 - 各知見の「注意点」(形式変更単独の因果効果が未検証であること、話し合いだけでは本人の言動が変わらなかったこと、自己評価が甘くなりやすい傾向など)についても、過度な一般化を避ける形で本文中に織り込まれており、誠実な記述となっています。 - 些細な点として、「不満の言動…改善の契機になり得る」という表現はコンテキストの「必ずしもチームの有効性を損なわない」からやや能動的に意訳されている点や、「プロセスの検査と適応」というスクラムガイド由来の用語が補足されている点は見られますが、コンテキストの趣旨を逸脱・捏造するものではなく、許容範囲内と判断できます。【Relevance(適合性・関連性)の評価: 5点】 - 「スクラムマスターは観察をするが、具体的に何をすれば良いか」という問いに対し、単に「見る」だけに留まらず、「何を観察対象とし(発言時間、対立や妨害の兆候、不満の向かう先、ふりかえりの形骸化、自身の対話頻度や評価の乖離など)、それをどのように行動や介入(時間の意識づけ、レトロスペクティブでの共通課題化、形式の多様化、一歩引く・介入する判断)に結びつけるか」を明確に整理して回答しています。質問の核心に直接かつ網羅的に答えています。