ふりかえりが浅くなったり、マンネリになったりして、改善につながる議論が出てこない。スクラムマスターはどうふりかえりの質を上げるのが良いか？

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

結論（TL;DR）

ふりかえりの質を上げるスクラムマスターの打ち手の効果を、きちんと比べて確かめた文献は、今回読んだ範囲では見つかっていません。事例の多くは観察や受け止めの報告です。まず、何が浅くしているかを見る材料があります。3 年間のレトロスペクティブの記録を分析した研究では、根本原因分析が本当の原因まで届かず症状を扱っていた例、同じ話題が繰り返し出ても是正策が効かなかった例、発言の 75% が計画・実装・テストに集まり、営業・マネジメント・プロダクトオーナーなどチームの外の領域は拾いにくかった例が報告されています。ふりかえりの頻度が減った主因は、進め方よりも、チームの手が届かない問題の議論が繰り返されたことだった、という報告もあります。打ち手の事例としては、レトロスペクティブゲームの導入で、愚痴中心の議論が解決策を探す議論に変わったと研究者が観察し、気づきからデイリースクラムの開始や承認待ちの解消などの行動につながったチームもありました。一方で、同じゲームを繰り返すと同じ意見ばかり出る、毎回替えると覚え直す負担を嫌がる人もいる、とチームの意見は割れ、会議が長くなったチームもありました。ゲームの手順に慣れると、開発者が自分から進行役を引き受け、スクラムマスターの仕切りすぎに不満のあったチームで歓迎された例もあります。スクラムチームの有効性の研究では、事例の段階で、話題ごとに形式を変えるチームのほうが広い分野で多くの改善を生む傾向があったと著者が観察しています（形式を変えた効果を測ったものではありません）。同じ研究の後半の 1,978 チームの調査では、ふりかえりの質は「継続的改善」の指標の 1 つとして測られていますが、ふりかえりの質だけの効果は分析されていません。リモートでは、会議の最後に要約し、ふりかえりの終わりに完了済みと新規のアクションを振り返る対策が好意的に評価されましたが、ふりかえり単独の効果は切り分けられていません。反対の例もあります。長年同じメンバーで問題はすぐ解決できるとして、ふりかえりをほとんど開かないチームが多かった調査や、15 分ほどに切り上げると実行できる改善項目が出ないと整理した文献レビューがあります。

打ち手と事例

Mad/Sad/Glad で、別のチームとの意思疎通の悪さが見つかり、リーダーの働きかけで開発が速くなった ［Game-based Sprint retrospectives（2021）］

• 状況: ポーランドのソフトウェア会社 Dynatrace の Scrum チーム Dyna_A の報告。このチームは、プロジェクトの一部の作業を手伝うはずの別のチームと組んで進めていた。
• やったこと: 研究者の入れたレトロスペクティブゲームのうち、Mad/Sad/Glad を使った。
• 起きたこと: Mad/Sad/Glad をやって、手伝うはずの別のチームとの意思疎通が、その別のチームのせいで足りていないと分かった。改善の行動として、チームリーダーがそのチームと話し始めた。その結果、意思疎通が良くなり、開発が速くなったと、チームは述べている。
• 注意点: チームの発言にもとづき、意思疎通や開発速度を測った値は無い。 Mad/Sad/Glad は、Mad が Sad と似ていて議論を狭めうると参加者に指摘されている。著者は、このゲームだけでは改善の提案が直接は出にくいとも書いている。
• 根拠: アクションリサーチ／単一チーム。文献: Game-based Sprint retrospectives: multiple action research（2021）。文献の種類: 論文・研究者。位置: 5.4.2 Focus groups（4. Are any of the games particularly useful in some situations/circumstances?）。確認の根拠: 原典
• 原文: “communication between them and another team that was supposed to help with some part of the project was inadequate”

ふりかえりを開いていたチームは対面で開くのが通例で、対面を好む声があり、議論や発案が要る会議は対面向きと整理された ［Hybrid Work in Agile Software Development（2025）］

• 状況: フィンランドの通信機器メーカーの研究開発拠点で、週 2 日出社のハイブリッド勤務をしている 15 のアジャイルチームを、27 人へのインタビューで調べた単一事例研究。チーム単位でふりかえりを開いていたチームは、会議室または社外で開くのが通例で、ハイブリッド形式は、メンバーが出席できないときなどにまれに使う程度だった。
• やったこと: ふりかえりは会議室か社外に集まって対面で開き、ハイブリッドにするのは、メンバーが出席できないときなどまれだった。あるチームのメンバー 1 人は、全員が出社する日にふりかえりを入れる、または事前に予約して全員が出社するようにしていると話した。ふりかえりは 1〜2 時間で、ハイブリッドで開くときは必ずカメラを使った。物理や電子のホワイトボード、付箋、Confluence、Mentimeter の投票などを使っていた。
• 起きたこと: チームのメンバー 4 人が、対面のふりかえりが好ましいと話した。ブレインストーミングを含む会議は対面が良いと述べた人も 6 人いた。自発的な議論がしやすく、物理のホワイトボードを使えるからである。著者は、議論や発案が要る会議（ふりかえりや技術の議論）は対面の出席が向き、情報共有の大きな会議は遠隔でよいと整理している。ふりかえりの質が上がったかどうかは測られていない（結果の記述なし）。
• 注意点: 好みの報告であり、対面で開いたふりかえりの方が議論が深まったという測定はない。ふりかえりを遠隔にしたのは全員が参加できるようにするためだとした別の研究とは異なる結果で、著者もその違いを指摘している。 1 社の 2 部門のみの調査で、結果が当てはまるのは似た状況に限られる。
• 根拠: 事例研究／複数チーム。文献: Hybrid Work in Agile Software Development: Recurring Meetings（2025）。文献の種類: 論文・研究者。位置: IV. RESULTS / D. Agile Team Meetings / 3) Retrospectives / H. Meeting Preferences / V. DISCUSSION / A. Organizing Recurring Meetings。確認の根拠: 原典
• 原文: “We decided to do it on those days when everybody is at the office, or then everybody will come to the office when we book it beforehand.”

ふりかえりの形式と話題を変えるチームのほうが、広い分野で改善を生み出す傾向があった ［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”

考え方の違う人どうしの橋渡し（Moderator）は、開発者に移らずスクラムマスターに残る傾向があった ［An empirical study on changing leadership in agile teams（2021）］

• 状況: Bosch の複数の部門でスクラムマスター・開発者・プロダクトオーナーに聞き取りをした、グラウンデッドセオリーの研究。著者は、職能横断のチームでは考え方・振る舞い・性格が人によって違い、専門の言葉や仕事の習慣の違いから互いをうまく理解できないことがあると書いている。あるプロダクトオーナーは「自分たちはよく議論するので、スクラムマスターが会話を進め、違う見方の間を取り持つ必要がある」と語った。
• やったこと: 複数のスクラムマスターが、異なる領域の人どうしの間を取り持ち、互いの見方を受け入れられるよう手助けしていた。著者はこれを、会議を進行し、見方や領域の間に橋を架ける Moderator の役割と呼んでいる。
• 起きたこと: 著者は、開発チームが Moderator の役割を担えたチームに出会わなかった。開発者が進行した、よく準備された会議は、レトロスペクティブのはずが計画づくりで終わった。 2 つのチームは、チームの一員として作業していると議論の中で中立を保つのが難しいので、スクラムマスターが Moderator である必要があると考えていた。著者は、Moderator と Protector の役割は、成熟したチームでも専任のスクラムマスターに残る傾向があったとしている。
• 注意点: 取り持ちの対象は、専門領域の違いからくる見方の違いで、特定の人の繰り返す言動ではない。取り持ちによって議論がどう変わったかの記述は無い。ふりかえりに関する根拠は、開発者の進行した会議が、ふりかえりの予定だったのに計画づくりで終わったという一文だけで、ふりかえりの質を上げる手段を示したものではない。インタビューにもとづく 1 社の研究で、結果は一般化できないと著者は書いている。
• 根拠: 事例研究／複数チーム。文献: An empirical study on changing leadership in agile teams（2021）。文献の種類: 論文・研究者。位置: 4.1.6 Role 6: Moderator / 4.2 The Role Transfer Process（third step）。確認の根拠: 原典
• 原文: “We have not come across any team within which the Development Team succeeded in playing the Moderator.”

レトロスペクティブの前に毎回「誰かを責める場ではない」と伝えるスクラムマスターがいた。別のチームでは、個人に向いていた話が自分たちで変えられることに移った ［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”

長く繰り返された品質の問題は、テストとバグ修正に十分な労力をかけたあとで、話題に出なくなった ［Recurring opinions or productive improvements—what agile…（2016）］

• 状況: 欧州の複数の国に分散した Scrum の開発組織。開発者の増加とともに、レトロスペクティブで「バグが多い」という発言が長く繰り返された。著者は、厳しいスケジュールの圧力などの外部要因のために、チームが本当の原因を解けなかったと見ている。
• やったこと: レトロスペクティブごとに、是正策が出た。例として、コミット前のコード規約のチェックの強制、新しい機能の実装でのテストの時間の確保、変更に関わる API の網羅的な試験が出た。組織は、スプリントを段階的に長くし、さらにテストのための期間を足した。
• 起きたこと: 未解決のバグ数は、第 3 段階で 90 件を下回る水準に落ち着いた。バグについての繰り返しの発言は、そのころに止まった。著者は、組織がテストとバグ修正に十分な労力を投じたあとで、問題が話題に出なくなったとしている。見積もりの精度と違い、是正策に効果があったと述べている。
• 注意点: スプリントの延長、テスト期間の追加、個々の是正策が重なっていて、どれの効果かは分けられていない。組織の成長とも重なる期間の出来事である。レトロスペクティブの発言は、バグ数のデータとおおむね合っていた。ただし、バグ数が少ないと感じた水準の理由は、著者も説明できないとしている。バグ数は、リードタイムなどの流れの指標ではない。単一の組織の事例で、記録されたレトロスペクティブの成果にもとづく。
• 根拠: 事例研究／複数チーム。文献: Recurring opinions or productive improvements—what agile teams actually discuss in retrospectives（2016）。文献の種類: 論文・研究者。位置: 4.3.3 What Corrective Actions are Developed for the Recurring Discussions? (RQ 3.3) / 4.3.4 Reflections / 4.4.2 State of bug Fixing。確認の根拠: 原典
• 原文: “After the organisation invested enough effort in software testing and bug fixing, the problem stopped recurring in the discussions.”

見積もりの精度に是正策を重ねても、データの上では精度が上がらなかった ［Recurring opinions or productive improvements—what agile…（2016）］

• 状況: 欧州の複数の国に分散した Scrum の開発組織。導入から数年のあいだに、開発者が増えてチームが分かれていった。各チームはスプリントの終わりにレトロスペクティブを開き、原因の分析、投票、得票の多い問題への是正策づくりを繰り返した。前のレトロスペクティブの成果は、次の会議の入力に使われていなかった。「見積もりが不正確だった」という発言が、何度も繰り返された。
• やったこと: 見積もりの不正確さについて、レトロスペクティブごとに是正策を出した。例は、Wideband Delphi の利用、設計や分析のタスクの前倒し、過去のスプリントのポイントの平均の利用である。ほかに、調査用のタスクの確保、不確実さの係数の導入、自分の見積もりと実績の見比べもあった。
• 起きたこと: 繰り返された話題の中では、見積もりの精度に是正策がいちばん多く出て、是正策全体の 8% を占めた。それでも「見積もりが不正確だった」という発言は、35% のレトロスペクティブで繰り返された。タスク管理のデータで見ても、見積もりの精度は上がらなかった。著者は、3 年のあいだ大きな効果が無かったとしている。
• 注意点: 対象は見積もりの精度で、リードタイムなどの流れの指標ではない。著者は、この話題が、コミュニケーションや人員・日程の問題を覆う手近な理由になっていて、チーム単位では解けない問題だったと解釈している。この解釈は検証されていない。単一の組織の事例で、著者自身も数の一般化はできないとしている。記録されたレトロスペクティブの成果にもとづく分析である。
• 根拠: 事例研究／複数チーム。文献: Recurring opinions or productive improvements—what agile teams actually discuss in retrospectives（2016）。文献の種類: 論文・研究者。位置: 4.3.3 What Corrective Actions are Developed for the Recurring Discussions? (RQ 3.3) / 4.3.4 Reflections。確認の根拠: 原典
• 原文: “despite the repeating discussions and numerous corrective actions, the estimation accuracy did not improve”

会議の最後の 3 分で要約し、ふりかえりでは完了済みと新規のアクションを振り返る対策が、好意的に評価された ［Overcoming Challenges of Virtual Scrum Teams（2023）］

• 状況: ポーランドにあるシステム会社の 2 つの Scrum チームが、急な遠隔勤務への移行後、会議で情報を取りこぼしやすくなり、情報が増える一方で具体的な内容が減っていると確かめられた。
• やったこと: 第二周期の 3 スプリントのあいだ、会議の最後の 3 分を短い要約にあてた。デイリースクラムではスクラムマスターが重要な情報を要約して全員が理解したことを確かめた。スプリントレトロスペクティブでは、終わりに、完了済みのアクションと新しく決めたアクションを振り返った。同時に、カメラとマイクを入れたままにする対策も行った。
• 起きたこと: 評価では「会議の要約をつくると要点の保持が進んだ」かどうかを尋ね、第二周期の対策全体への反応は圧倒的に好意的だった。著者は、会議の最後の短い要約で想起が良くなり、課題への意識が高まると結論づけた。ふりかえりだけでの効果や、アクションの実行率への影響は分けて報告されていない（結果の記述なし）。
• 注意点: 評価はアンケートと議論に基づく主観的なもので、効果の測定値はない。要約と、カメラ・マイクを付ける対策は同時に行われ、要約だけの効果は切り分けられていない。ふりかえりでの効果は個別に評価されていない。対象は 1 社の 2 チームで、参加者の偏りの可能性を著者が挙げている。
• 根拠: アクションリサーチ／複数チーム。文献: Overcoming Challenges of Virtual Scrum Teams: Lessons Learned Through an Action Research Study（2023）。文献の種類: 論文・研究者。位置: 3.2 The Second Action Research Cycle。確認の根拠: 原典
• 原文: “During the Sprint Retrospective, both the completed action points and newly established ones were to be recapped at the end.”

遠隔に移ったチームで、ふりかえりが長すぎ、形だけで開かれていると感じられるようになった ［Overcoming Challenges of Virtual Scrum Teams（2023）］

• 状況: ポーランドにあるシステム会社で、航空会社向けのシステムとモバイルアプリを開発する 2 つの Scrum チームを対象にした、6 か月のアクションリサーチ。急な遠隔勤務への移行後の課題を、診断で探した。ふりかえりは、チームごとにオンラインのツール（Timbo と TeamRetro）で開いていた。アンケートと議論で、遠隔では会議の質が落ちたとチームの多くが同意した。沈黙が増え、やりとりが減り、ふりかえりに使うツールがばらついた。
• やったこと: 研究者は、第二周期の行動計画で、カメラとマイクを入れたままにする、会議の最後の 3 分で要約する、などの対策を決めた。ふりかえりについては、終わりに、完了済みのアクションと新しく決めたアクションを振り返ることを決めた。ふりかえりの長さや関心の低下を直接の対象にした対策は、記されていない。
• 起きたこと: 2 チームのうち、Group App のチームは、特にふりかえりに問題があると挙げた。参加者は、ふりかえりが長すぎる、関心を失いつつあると示唆し、「ふりかえりは開くために開かれている」と感じる人が複数いた。経験や Scrum の知識が豊富な人は、ふりかえりの一部が Scrum ガイドに沿わなくなったとも指摘した。ふりかえりの長さや関心の低下に絞った介入の結果は、報告されていない（結果の記述なし）。
• 注意点: 診断は参加者の受け止めに基づき、ふりかえりが長い、または関心が落ちた程度は測られていない。ふりかえりの質に絞った対策と評価はなく、ここから分かるのは遠隔で起きた問題の記述に限られる。著者は、評価が主観的で、遠隔勤務を好む参加者に偏りがある可能性を限界として挙げている。
• 根拠: アクションリサーチ／複数チーム。文献: Overcoming Challenges of Virtual Scrum Teams: Lessons Learned Through an Action Research Study（2023）。文献の種類: 論文・研究者。位置: 3.2 The Second Action Research Cycle。確認の根拠: 原典
• 原文: “retros were held for the sake of holding them”

ゲームの手順に慣れると、開発者が自分から進行役を引き受けるようになり、スクラムマスターの仕切りすぎへの不満があったチームで特に歓迎された ［Game-based Sprint retrospectives（2021）］

• 状況: ポーランドの複数の会社の Scrum チームでのアクションリサーチ。 Dyna_A のチームでは、メンバーの一部が、スクラムマスターがレトロスペクティブを仕切りすぎていると不満を述べていた。
• やったこと: 研究者が、手順の決まったレトロスペクティブゲームを導入した。 2 回目からは、ルールと手順が分かっている状態で行った。
• 起きたこと: 2 回目のゲームでは、いろいろな開発者が自分から進行役を引き受けて会議を進めた。研究者は、ゲームを使うとある程度は進行が自己完結し、準備の手間も減ると観察した。この進め方は、特に Dyna_A で歓迎された。
• 注意点: 研究者の観察で、進行役の交代が議論の質にどう影響したかを測った値は無い。 Dyna_A のスクラムマスターは、偏りを避けるためにアンケートに答えなかった。ゲームを使った会議が従来より長くなったチームもあった。
• 根拠: アクションリサーチ／複数チーム。文献: Game-based Sprint retrospectives: multiple action research（2021）。文献の種類: 論文・研究者。位置: 5.5.4 Lesson 4: Retrospective games organize both the meeting as well as the discussion。確認の根拠: 原典
• 原文: “voluntarily took over the role of a”

ゲームで出た気づきが、デイリースクラムの開始やプルリクエスト承認の遅れの解消など、具体的な改善の行動につながったチームがあった ［Game-based Sprint retrospectives（2021）］

• 状況: ポーランドの複数の会社の Scrum チームでのアクションリサーチ。介入の前の診断では、OKE_A はレトロスペクティブとレビューを 1 つの会議にまとめ、デイリースクラムも行っていなかった。レトロスペクティブに得るものが少ないと感じるメンバーもいた。
• やったこと: 研究者が、レトロスペクティブゲーム（Sailboat など）を OKE_A に入れた。チームは、レビューとレトロスペクティブを別の会議に分けることにも同意した。
• 起きたこと: OKE_A はフォーカスグループで、ゲームが作業の効率と Scrum の進め方の改善に役立ったと述べた。デイリースクラムを始めた。プルリクエストの評価の待ち時間を、承認の権限を別のプログラマーに与えて減らした。プロダクトオーナーが開発チームのために使える時間が増え、プロダクトオーナーが開発チームの抱える多くの問題に気づいた。グラフィックデザイナーを雇う必要が分かり、研究の終了後まもなく満たされた。 MVC のコントローラーを Angular の REST API にリファクタリングした。ゲームはチームに一体感も生んだと述べている。一方、OKE_B では、ゲームのほとんどが、プロダクトオーナーと開発チームの意思疎通の隔たりという似た結論で終わり、時間に追われる中でゲームは時間がかかりすぎると見られた。スクラムマスターもゲームを子どもっぽいと見たが、3 スプリントに 1 回ほどは続けたいとし、JIRA の使い方についての新しい気づきは得られたとしている。
• 注意点: チーム自身の報告で、各行動の効果を測った値は無い。 OKE_B では、ゲームの価値は小さいと受け取られた。 OKE_A は、診断で Scrum の運用が枠組みから外れていたチームのひとつで、会議を分けたことの影響とゲームの影響は切り分けられていない。
• 根拠: アクションリサーチ／複数チーム。文献: Game-based Sprint retrospectives: multiple action research（2021）。文献の種類: 論文・研究者。位置: 5.4.2 Focus groups（1. How do you assess the new way of running retrospective meetings）。確認の根拠: 原典
• 原文: “they decreased the pull request evaluation latency by granting the approval permission to another programmer”

レトロスペクティブを減らした主因は、チームの手が届かない問題の議論が繰り返されたことだった ［Game-based Sprint retrospectives（2021）］

• 状況: ポーランドの複数のソフトウェア会社の Scrum チームを対象に、レトロスペクティブの質を上げようとしたアクションリサーチ。診断では、ほとんどのチームが Scrum を本来の形で運用していなかった。レトロスペクティブは飛ばされたり、同じ意見が毎回出たり、得るものが少ないと感じられたりしていた。会社は階層的な指揮統制の管理で、チームを戦略の決定に関わらせていなかった。
• やったこと: 研究者が、レトロスペクティブゲーム（Sailboat、Mad/Sad/Glad など）を各チームに入れた。アンケートとフォーカスグループで評価した。組織の問題の解決は、研究の合意の範囲外だったので、手を付けていない。
• 起きたこと: すべてのチームでゲームによって解消した問題は、参加の偏りだけだった。「得るものが少ない」は、全チームで一部しか解決しなかった。 2 チームは、診断で挙げた 5 つの問題のうち 3 つが解消したと述べた。 6 チームのうち 5 チームで、Scrum の運用が枠組みから外れていた。著者は、レトロスペクティブの頻度を減らした主因を、進め方ではなくチームの統制の外にある繰り返しの問題についての成果の出ない議論だとしている。例として、要求を確かめたいときにプロダクトオーナーがいないこと、チーム間の連絡の不足、メンバーが複数の部屋に分かれていることを挙げている。フォーカスグループでは、開発者とプロダクトオーナーやチーム間の連絡の難しさ、スプリントバックログの詰め込み、複数のチームへの兼務が以前から挙がっていたとされる。これらは、会社の統治に反するか組織としての是正が要るため、何も行われなかった。その不満から会議が飛ばされたと、著者は書いている。研究者は、新しいアクションリサーチのサイクルを始めても付加価値が小さいと判断し、始めなかった。
• 注意点: ゲームの評価は参加者の受け止め（アンケートとフォーカスグループ）が中心で、リードタイムなどの測定値ではない。研究者の現場ノートに、重要な事実の記録の抜けがあったと著者は認めている。「主因」は研究者の見立てで、他の要因との切り分けはしていない。組織の機能不全を直す権限が研究に無く、その解決策は試されていない。
• 根拠: アクションリサーチ／複数チーム。文献: Game-based Sprint retrospectives: multiple action research（2021）。文献の種類: 論文・研究者。位置: 5.4.2 Focus groups / 5.5.8 Lesson 8: Organizational culture and managers’ mindsets are still significant barriers to the successful adoption of agile practices。確認の根拠: 原典
• 原文: “unproductive discussions on recurring problems that were beyond the control of the team”

前提に反する事例

長年一緒に働いてきたチームの多くは、課題が少ないことを理由に、チーム単位のふりかえりをほとんど開いていなかった ［Hybrid Work in Agile Software Development（2025）］

• 状況: フィンランドにある通信機器メーカーの研究開発拠点で、週 2 日の出社を基本とするハイブリッド勤務の下、2 つの部門の 15 のアジャイルチームを調べた単一事例研究。 27 人の半構造化インタビューで、定例の会議の開き方を聞いた。チームごとのふりかえりを隔週で開いていたのは 1 チームだけだった。 6 チームは 1〜6 か月に 1 回、ごくまれに、または必要なときだけ開いていた。残る 8 チームは、チーム単位のふりかえりを開いていなかった。
• やったこと: この研究は会議の開き方を調べたもので、ふりかえりを開かない状況への働きかけはしていない。ふりかえりを開かない理由として、3 人が「長く一緒に働いていて、問題が起きてもすぐ解決できる」ことを挙げた。ふりかえりを定期的に開いていない別のチームの 1 人は、メンバーが長年同じ分野の知識を持ち、目的や目標も揃っているので、議論が少なく頻繁なふりかえりは要らないと話した。
• 起きたこと: ふりかえりを開かないチームのうち、効果を述べたのは 1 人だけだった。その人は、話し合わなければ何を改善すべきか分からないので、毎スプリントでなくとも数スプリントに 1 回は定期的に開くべきだと述べた。ふりかえりを開かなくなった結果として、成果や課題がどう変わったかは調べられていない（結果の記述なし）。
• 注意点: インタビューは 1 社の 2 部門だけで行われ、語られたのは参加者の受け止めである。ふりかえりを開かない影響は測られていない。チームには特定のスクラムマスターがおらず、事情が一般のスクラムチームと違う可能性がある。著者自身、結論の適用範囲は、ハイブリッド勤務を採る大規模アジャイルの似た状況に限られるとしている。
• 根拠: 事例研究／複数チーム。文献: Hybrid Work in Agile Software Development: Recurring Meetings（2025）。文献の種類: 論文・研究者。位置: IV. RESULTS / D. Agile Team Meetings / 3) Retrospectives。確認の根拠: 原典
• 原文: “Most of us have been together very long and it’s been kind of smooth working in this team.”

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

ふりかえりの質を含む継続的改善の風土が高いチームほど、ステークホルダーへの配慮と応答性も高かった ［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”

遠隔の会議でカメラを付けるのは有用だとインタビューの多数が答え、ふりかえりのような話し合う会議で特に役に立つという声があった ［Hybrid Work in Agile Software Development（2025）］

• 状況: フィンランドの通信機器メーカーの研究開発拠点で、ハイブリッド勤務をしている 15 のアジャイルチームなどから 27 人にインタビューした単一事例研究。遠隔やハイブリッドの会議でのカメラの使い方を尋ねた。
• やったこと: チームや個人の判断で、遠隔・ハイブリッドの会議でカメラを付けていた。ふりかえりをハイブリッドで開くときは、カメラを必ず使っていた。
• 起きたこと: インタビューを受けた 27 人のうち 18 人が、遠隔の会議でカメラを使う方が良いと述べた。チームの単位では、デイリーやふりかえりのように互いに話し合う会議で、カメラが特に役に立つと語られた（多数の回答とまでは書かれていない）。バックログ・リファインメントのように全員が共有画面を見る技術的な会議では、あまり役に立たないとされた。カメラを切って別の作業をしているのではという懸念を 1 人が述べたが、会議中に別の作業をしたと話したのは 3 人だけで、そうした振る舞いはこの研究の結果では目立たなかった。
• 注意点: 語られたのは参加者の受け止めで、カメラがふりかえりの議論の深さを高めたかは測られていない。ふりかえり固有の結果ではなく、会議全般の中での言及である。著者は、この領域は追加の研究が必要としている。
• 根拠: 事例研究／複数チーム。文献: Hybrid Work in Agile Software Development: Recurring Meetings（2025）。文献の種類: 論文・研究者。位置: V. DISCUSSION / C. Using Cameras in Meetings / IV. RESULTS / H. Meeting Preferences。確認の根拠: 原典
• 原文: “At the team level, the use of cameras was discussed as particularly beneficial for meetings like the dailies and retrospectives”

チームのレトロスペクティブの是正策は、協力や優先順位の問題にはほとんど出なかった ［Recurring opinions or productive improvements—what agile…（2016）］

• 状況: 分散した Scrum の開発組織で、長期間のレトロスペクティブの記録を、研究者が話題の種類ごとに分類して数えた。数えたのは、否定的な発言の数と、そのうち是正策がつながった数である。
• やったこと: 介入ではなく、記録の分析である。
• 起きたこと: タスクの結果についての否定的な発言 72 件に、是正策は 62 件が対応した。作業の仕方では 57 件に 36 件だった。一方、協力についての発言 13 件に是正策は 0 件、タスクの優先順位は 13 件に 2 件、タスクの進捗は 27 件に 2 件だった。著者は、チームが統制できると感じる問題に偏って是正策が出たと解釈している。外部のステークホルダーとの協力や、事業上の判断が要る問題は、チーム単位では扱われにくく、組織の支援が要るとしている。
• 注意点: この解釈は著者の仮説で、検証されていない。単一の組織の事例である。分類は研究者の判断による。協力の種類の是正策は出ていたが、協力についての否定的な発言を対象にしたものではなかった。記録されたレトロスペクティブの成果にもとづく分析である。
• 根拠: 事例研究／複数チーム。文献: Recurring opinions or productive improvements—what agile teams actually discuss in retrospectives（2016）。文献の種類: 論文・研究者。位置: 4.2.1 What Discussion Topics Most Often Result in the Development of Corrective Actions? (RQ 2.1) / 4.2.3 Reflections。確認の根拠: 原典
• 原文: “the participants tend to focus on solving problems that they feel are under the team’s control”

原因分析をしても、是正策は出された問題の原因ではなく、見えている症状に向いていた ［Recurring opinions or productive improvements—what agile…（2016）］

• 状況: 欧州に分散した Scrum の開発組織。各チームは 1 時間ほどの対面のレトロスペクティブを、スプリントの終わりに開いていた。参加者は 3〜5 人ほどで、スクラムマスターが進行した。良かったこと、悪かったこと、改善案を挙げ、悪かったことには根本原因分析（RCA）で原因を書き出して掘り下げ、得票の多い問題に是正策を作った。研究者は、記録された是正策が、どの問題を対象に作られたかを分類して比べた。
• やったこと: 介入ではなく、記録の分析である。
• 起きたこと: 是正策の約 10% は協力についてだったが、協力が是正策の対象に選ばれたことは一度も無かった。プロセスについての是正策も約 10% あったが、対象に選ばれることはほとんど無かった。一方、タスクの結果や見積もりなどは、是正策そのものより、対象に選ばれることのほうが多かった。著者は、チームのレトロスペクティブでは、根本原因分析が本当の原因までは届かず、見えている症状を扱っていると読んでいる。それでも参加者は、症状の裏の因果を知っていて、原因を言葉にしないまま、見積もりの悪さに対して、プロダクトオーナーと開発者の協力を良くする是正策を直接出していた。
• 注意点: 原因の推論が暗黙のまま進むため、その推論が網羅的か正しいかは分からないと、著者も述べている。単一の組織の事例で、分類は研究者の判断による。記録されたレトロスペクティブの成果にもとづく分析で、面談の中身を確かめたものではない。原因分析の進め方を変えたときに深さが増すかは、調べられていない。
• 根拠: 事例研究／複数チーム。文献: Recurring opinions or productive improvements—what agile teams actually discuss in retrospectives（2016）。文献の種類: 論文・研究者。位置: 4.2.1 What Discussion Topics Most Often Result in the Development of Corrective Actions? (RQ 2.1) / 4.2.3 Reflections。確認の根拠: 原典
• 原文: “the root cause analysis does not uncover the actual causes of the negative experiences, but deals more with the visible symptoms”

同じ話題が長く繰り返され、是正策が積まれても効果が出ない議論は、ふりかえりの無駄になりうる ［Recurring opinions or productive improvements—what agile…（2016）］

• 状況: 欧州に分散した Scrum の開発組織。導入から 3 年のあいだ、チームのレトロスペクティブの記録を研究者が分析した。前のレトロスペクティブの成果は、次の会議の入力には使われていなかった。
• やったこと: 介入ではなく、記録の分析である。研究者は、同じ趣旨の発言が何度も出る話題を探し、その性質を分類した。
• 起きたこと: 2 回以上出た発言は 43 件だった。繰り返された割合は、肯定的な発言で 23%、否定的な発言で 9% だった。是正策の 19% は、繰り返される話題のために作られた。繰り返される話題は、見積もりの精度、バグの状態、仕様や情報の不足の 3 つだった。著者は、これらを「手近な身代わり」（本当は複雑な問題を単純な理由に置き換える）、「解けない問題」（チームの統制を超える）、「自然に繰り返す問題」（バグ）の型に分けた。そのうえで、繰り返される話題を見分けることには意味があり、繰り返しは、非生産的な議論と効かない是正策の兆しになりうるとしている。バグのように、組織がテストと修正に十分な労力を投じると繰り返しが止まった話題もあった。
• 注意点: 型の分類と、それぞれの原因は著者の仮説で、検証されていない。仕様や情報の不足の話題は、突き合わせられるデータが無く、性質を確かめられていない。著者は、結果を参加者に確かめておらず、予備的な結果を会社の担当者に話しただけだとしている。単一の組織の事例で、記録されたレトロスペクティブの成果にもとづく。
• 根拠: 事例研究／複数チーム。文献: Recurring opinions or productive improvements—what agile teams actually discuss in retrospectives（2016）。文献の種類: 論文・研究者。位置: 4.3.2 What Discussions Keep Recurring Over Time? (RQ 3.2) / 4.3.4 Reflections / 5.1 Implications for Continuous Retrospective Practice。確認の根拠: 原典
• 原文: “The recurrence could be a sign of unproductive discussions and ineffective corrective action innovations”

ふりかえりでの実感は、バグ数のようなデータとは合っていたが、見積もりの精度とは合っていなかった ［Recurring opinions or productive improvements—what agile…（2016）］

• 状況: 欧州に分散した Scrum の開発組織。チームは、レトロスペクティブで、バグの多さや見積もりの精度についての実感を語っていた。レトロスペクティブの前に、バグ数や見積もりの実績のデータは示されていなかった。研究者は、その発言を、バグ管理とタスク管理のデータと突き合わせた。
• やったこと: 介入ではなく、記録の分析である。
• 起きたこと: バグの発言は、未解決のバグ数の増減とおおむね合っていた。「バグ数が少ない」という発言は、未解決のバグが約 90 件以下のときに出た。見積もりの精度の発言は、実績のデータと矛盾していた。発言で「見積もりが良かった」とされたスプリントと「不正確だった」とされたスプリントで、実際の精度に明確な差が無い組もあった。著者は、参加者の個人的な経験の偏りが、ふりかえりの結果の信頼性に影響するとしている。著者は、バグ数のデータを事前に示すことができたと述べている。
• 注意点: 突き合わせたのは、バグ数と見積もりの精度の 2 つだけである。実績工数が計画と同じに入力された可能性は著者が挙げているが、ほとんどの場合は異なっていたとしている。「バグ数が少ない」と感じる水準が約 90 件以下だった理由は、著者も説明できないとしている。データを事前に示せばふりかえりが良くなるかは、この研究では試されていない。単一の組織の事例である。
• 根拠: 事例研究／複数チーム。文献: Recurring opinions or productive improvements—what agile teams actually discuss in retrospectives（2016）。文献の種類: 論文・研究者。位置: 4.4.1 Estimation Accuracy / 4.4.2 State of bug Fixing / 4.4.3 Reflections / 5.1 Implications for Continuous Retrospective Practice。確認の根拠: 原典
• 原文: “the comments on poor estimation accuracy, did not match the situation reflected by the task repository data on task estimates and actual efforts”

チームのレトロスペクティブは、営業・要求・マネジメントなど、チームの外の領域の問題や成功を拾いにくかった ［Recurring opinions or productive improvements—what agile…（2016）］

• 状況: 欧州に分散した Scrum の開発組織。チームがスプリントごとにレトロスペクティブを開き、プロダクトオーナーは定期的には参加していなかった。研究者は、記録された発言を、営業・要求、マネジメント、プロダクトオーナーなどの工程領域ごとに分類した。
• やったこと: 介入ではなく、記録の分析である。
• 起きたこと: チームの日々の仕事に近い、計画・実装・テストの 3 領域が、発言の 75% を占めた。営業・要求、マネジメント、プロダクトオーナーの領域は、肯定的な発言が 3〜4 件ずつにとどまった。チームの外の領域では、参加者は既にある問題を挙げる発言が中心だった。著者は、チームの統制の外にある問題は、組織レベルのレトロスペクティブのほうが向くかもしれないとしている。
• 注意点: 単一の組織の事例で、著者自身も量の一般化はできないとしている。チームのレトロスペクティブにプロダクトオーナーが定期的に出ていなかったことが、この偏りに関わるかは、検証されていない。記録されたレトロスペクティブの成果にもとづく分析で、面談の中身を確かめたものではない。組織レベルのレトロスペクティブが実際に効くかは、この研究では確かめていない。
• 根拠: 事例研究／複数チーム。文献: Recurring opinions or productive improvements—what agile teams actually discuss in retrospectives（2016）。文献の種類: 論文・研究者。位置: 4.1.4 Reflections / 3.3 The Retrospective Methods Used in the Case Organisation。確認の根拠: 原典
• 原文: “weak at recognising issues and successes related to the process areas that are external to the concerns of the teams”

是正策の約 3 分の 2 は、参加者が投票した問題から作られた ［Recurring opinions or productive improvements—what agile…（2016）］

• 状況: 欧州に分散した Scrum の開発組織。チームのレトロスペクティブで、悪かったことを挙げて原因を分析したあと、各参加者が重要な改善対象に投票し、得票の多い問題について是正策を作っていた。研究者は、記録された是正策が、投票された問題から作られたのかを数えた。
• やったこと: 介入ではなく、記録の分析である。
• 起きたこと: 是正策の 66% は、参加者が投票した否定的な発言をもとに作られていた。著者は、投票のやり方が是正策づくりの方向を決めていたとしている。
• 注意点: 残りの是正策の作られ方は、原文ではここで説明されていない。投票を使うことが是正策の質を上げるかどうかは、この分析では見ていない。単一の組織の事例で、記録されたレトロスペクティブの成果にもとづく。
• 根拠: 事例研究／複数チーム。文献: Recurring opinions or productive improvements—what agile teams actually discuss in retrospectives（2016）。文献の種類: 論文・研究者。位置: 4.2.1 What Discussion Topics Most Often Result in the Development of Corrective Actions? (RQ 2.1)。確認の根拠: 原典
• 原文: “The majority (66 %) of corrective actions were developed based on the negative statements that participants voted for.”

レトロスペクティブゲームで、愚痴中心の議論が解決策を探す議論に変わったと研究者は観察した ［Game-based Sprint retrospectives（2021）］

• 状況: ポーランドの 3 社、6 つの Scrum チームで、レトロスペクティブの質を上げるアクションリサーチを行った。介入の前は、そのうち Dynatrace と SentiOne のチームで、実りの薄い議論や愚痴がときどき長く続いていた。そのため、本当に大事な問題を話す時間が足りず、問題の原因を突き止めたり改善の行動を出したりする前に終わり、議論が未完のまま終わった印象が残っていた。
• やったこと: 研究者が、付箋に各自が書き出す形のレトロスペクティブゲームを各チームに入れた。ゲームは、項目ごとに個人で書き、貼り出して読み上げ、関連する付箋をまとめ、テーマごとに話して改善の行動を決める流れだった。必要なら、ドット投票で話す項目を絞った。
• 起きたこと: 研究者は、ゲームが会議の進め方と議論の焦点を整え、愚痴中心の議論から、解決策を探す建設的な議論に変わったと観察した。付箋の数が多い問題が見つけやすくなり、その問題を解決の見通しとあわせて話せるようになったので、会議の生産性が上がったと述べている。進行の準備の手間も減り、ゲームはある程度ひとりでに進行できるとしている。一方、OKE の 2 チームでは、議論がずっと広く深くなったので、ゲームを使った会議のほうが従来より長くなった。著者は、これを欠点と見る従来型の管理職もいるかもしれないと述べている。著者は別の箇所で、ゲームが画期的な発見を生む役割は誇張されている、と書いている。
• 注意点: 「議論の質が上がった」は研究者の観察と参加者の受け止めにもとづき、議論の内容を測った値は無い。ゲームを嫌う参加者もおり、ゲームが子どもっぽいと受け取られることがある。時間に追われるチームでは、ゲームの説明やルールを覚える時間が負担になった。この観察は、Dynatrace と SentiOne のチームについて書かれたものである。
• 根拠: アクションリサーチ／複数チーム。文献: Game-based Sprint retrospectives: multiple action research（2021）。文献の種類: 論文・研究者。位置: 5.5.4 Lesson 4: Retrospective games organize both the meeting as well as the discussion。確認の根拠: 原典
• 原文: “a paradigm shift from complaint-orientation to constructive solution-oriented discussions”

同じゲームを繰り返すと同じ意見ばかり出るが、毎回違うゲームにすると覚え直す負担でかえって嫌がるメンバーもいた ［Game-based Sprint retrospectives（2021）］

• 状況: ポーランドの複数のソフトウェア会社の 6 つの Scrum チームで、レトロスペクティブゲームを入れたアクションリサーチを行った。介入の前の診断では、診断では 5 チームで「ふりかえりが単調」という問題が挙がり（Dyna_A は少数）、「同じ案が毎回出る」という指摘も出ていた（Senti_B は経験が乏しく回答できなかった）。
• やったこと: 研究者が Sailboat・Mad/Sad/Glad などのゲームを複数入れた。フォーカスグループで、ゲームを会議ごとに替えるか、特定のゲームを続けるかをチームに尋ねた。
• 起きたこと: Dyna_A のチームは、同じゲームを繰り返すと似た意見ばかりになり、カテゴリーの違う新しいゲームを入れると参加者がより深く考えて新しい結果が出る、と述べた。 OKE_B のチームは、自分たちのプロジェクトでは目標・脅威・問題がほとんど変わらないので、Sailboat を何度もやっても似た結果になる、と述べた。研究者は、ゲームが習慣化した進め方を崩し、従来の会議で起きていた居眠りのような状態を防ぐ、と観察した。一方、チームの意見は割れた。 OKE の 2 チーム、Dyna_A、Senti_A は、ゲームを替えるほうが飽きず、いろいろな問題が見つかるとした。 Dyna_B と Senti_B は、ルールを覚えるまで数スプリント同じゲームを続けてから替えたいとした。研究者は、毎回新しいゲームを入れると負担になるチームもあったので、スクラムマスターはチームに、新しいゲームを覚える準備があるかを尋ねるよう勧めている。
• 注意点: チームごとの発言と研究者の観察にもとづき、ゲームの替え方と議論の深さの関係を測った値は無い。チームの意見は割れていて、一律の答えは示されていない。ゲームが画期的な発見を生む役割は誇張されている、と著者は書いている。
• 根拠: アクションリサーチ／複数チーム。文献: Game-based Sprint retrospectives: multiple action research（2021）。文献の種類: 論文・研究者。位置: 5.4.2 Focus groups（Q3 / 1. How do you assess the new way of running retrospective meetings / 2. Should we use the games alternately） / 5.5.1 Lesson 1。確認の根拠: 原典
• 原文: “playing the same game over and over brings similar comments”

リモートのスクラムでは、書き言葉での誤解とチームの結びつきの弱まりが報告され、レトロスペクティブで本当の問題が率直に話されるとは限らなかった ［Applicability of the Scrum Methodology in Remote Work…（2026）］

• 状況: リモートまたはハイブリッドでスクラムを経験した IT・ソフトウェア開発の実務者（開発者・スクラムマスター・プロダクトオーナー）へのアンケート調査。リッカート尺度の評定と自由記述を組み合わせ、自由記述は主題分析で分類している。
• やったこと: 介入ではなく、リモートの働き方と、コミュニケーション・チームの結びつき・心理的安全性についての受け止めを調べたものである。自由記述では、困りごとを和らげるのに効いた方法も尋ねている。
• 起きたこと: 書き言葉のコミュニケーションは誤解を生みやすいと受け止められていた。チームの結びつきが弱まるという受け止めは、プロダクトオーナーより開発者とスクラムマスターに多く、完全リモートの人のほうがハイブリッドや出社の人より強く同意していた。自分の意見や問題を口に出すことについては、困らない人もいれば受け身になる人もいて、経験が分かれていた。著者は、レトロスペクティブで本当の問題がいつも率直に話されるわけではないことを、心理的安全性を支える必要の表れとしている。自由記述では、スクラムマスターとプロダクトオーナーが進め方をより積極的に規律をもって管理することが効いたという声と、対面で集まる機会を増やしたいという提案があった。困りごとを和らげる方法を特に使っていないという回答もあった。
• 注意点: ある時点のアンケートで、回答者は職業上のつながりなどから集めた便宜的な標本であり、結果は回答者の受け止めである。集計は割合と平均だけで、要因と結果の関係を統計的に検定してはいない。特定のメンバーが他者とぶつかる言動を扱った調査ではなく、提案された打ち手の効果も確かめられていない。レトロスペクティブ固有の根拠は、率直に話せるかを尋ねた 1 つの設問の結果と著者の考察の一文である。自由記述の「進め方を規律をもって管理する」は書き言葉の誤解への対策として挙がったもので、レトロスペクティブ固有の対策ではない。
• 根拠: 調査（アンケート）／複数チーム。文献: Applicability of the Scrum Methodology in Remote Work Environments and the Challenges Encountered（2026）。文献の種類: 論文・研究者。位置: 5.4 Communication and Coordination / 5.5 Team Engagement and Psychological Safety / 5.10 Thematic Analysis of Open-Ended Questions。確認の根拠: 原典
• 原文: “real issues are not always openly expressed during Retrospective meetings”

Scrum のテーラリングを集めた文献レビューで、ふりかえりを 15 分ほどで切り上げる、または開かない進め方は、改善につながる議論が出ず継続的な改善の段階が無くなった例として挙がっていた ［Tailoring Choices Made in Scrum Projects（2022）］

• 状況: Scrum を各社がどう自分たちの文脈に合わせて変えているか（テーラリング）を調べた体系的文献レビュー。対象の論文のうち、スプリントレトロスペクティブの変更例を含む論文を拾い、変更の型と結果を整理している。レビューは、スプリントレビューを変えている例ではレトロスペクティブも変えている例が多かったと書いている。
• やったこと: 介入ではなく、各社が実際にしていたレトロスペクティブの変え方の整理である。本文が挙げているのは、Scrum と Agile への理解が足りずレトロスペクティブを開いていない会社、議論を 15 分ほどで終えるように開いている会社、まったく開かない、またはまれにしか開かない例である。
• 起きたこと: レビューは、レトロスペクティブを 15 分ほどで終えるという短い時間の選び方では、効率のよい議論ができず、実行に移せる改善項目を見つけられないとしている。レトロスペクティブが短すぎる、または開かれない変え方は、場当たり的な開発の進め方になり、チームに継続的な改善の段階が無いという結果になった、とまとめている。著者は、短くする、または開かないという選び方は組織にとって悪い結果につながりうるとし、Scrum ガイドに反する「誤ったテーラリング」の例とみなせると書いている。
• 注意点: レビュー全体で、個々の Scrum の実践を変えた結果についての根拠は十分ではない、と著者自身が書いている。レトロスペクティブの結果は個別の調査の数値ではなく、レビューによる整理である。短い時間にした理由や、延ばしたら改善されたかは書かれていない。「誤ったテーラリング」という評価は、Scrum ガイドとの照らし合わせにもとづく著者の判断である。ふりかえりが浅くなる原因を、チームの規模や関係などの要因ごとに切り分けた記述は無い。「15 分ほどで終える」例は文献レビューに「報告された」とあるだけで出典の番号が文に付いておらず、「短いと実行できる改善項目が出ない」も個別の調査結果ではなくレビューの記述である。
• 根拠: 文献レビュー／大規模な組織。文献: Tailoring Choices Made in Scrum Projects: A Systematic Literature Review（2022）。文献の種類: 論文・研究者。位置: 4.1 RQ 1.1-Tailored Scrum Practices and Tailoring Choices / 4.4 RQ 2 Positive and Negative Evidences on the Consequences of Tailoring Choices。確認の根拠: 原典
• 原文: “This short duration preference leads to not being able to run efficient discussion and identify actionable improvement items.”

規範文書が勧める打ち手と、その証拠

規範文書（コーチングの枠組みなど）が「こうするとよい」と勧めている文と、その主張を確かめた研究。上の事例・知見とは根拠の性質が違う。証拠の分野がソフトウェア開発の外の研究もある。

打ち手: 洞察の構築（Building Insights）：パワフルな質問、沈黙、比喩などのツールや技法を使って、クライアントの洞察と学びを促します。

• 出典: Agile Coaching Growth Wheel v3.2（coaching・Coaching Skills）
• 証拠: 2 件（支持 2）
  • 支持（ソフトウェア開発のチーム）: アジャイルコーチ 19 人へのインタビュー研究（HICSS 2021）。コーチは、良い問いでチーム自身が変えられるようにした、振り返りで開いた問いを使って懸念を言葉にさせた、と語った。問いで洞察を促すという文を支える認識の報告で、成果は測っていない（弱）。CC BY-NC-ND の文献で quote は空。 文献: The Agile Coach Role: Coaching for Agile Performance Impact。位置: §4.1 Strategies・§4.3（p.6819・6821）。
  • 支持（ソフトウェア開発のチーム）: Bosch のグラウンデッド・セオリー（ソフトウェアのチーム 14 とそれ以外のチーム 15、聞き取り 22 件と 53 件、会議の観察）。Scrum Master などの語りから「Coach」の役割を抽出し、チームの行動を観察して、適切な時に適切な問いを投げ、成長を促すと説明された。問いで洞察を促す、という文を支える。効果は測っていない質的な記述で、理論は特定の組織の文脈に限られると著者が書く（弱〜中）。 文献: An empirical study on changing leadership in agile teams。位置: §4.1.3 Role 3: Coach。同じ文献の知見は、上の事例・知見の節にもある。

この節の出典は、次のとおり。

文献	年	ライセンス	行の数
Agile Coaching Growth Wheel（規範文書）	v3.2	CC BY-SA 4.0	文 1
The Agile Coach Role: Coaching for Agile Performance Impact	2021	CC BY-NC-ND 4.0	証拠 1
An empirical study on changing leadership in agile teams	2021	CC BY 4.0	証拠 1

出典の文書: Agile Coaching Growth Wheel v3.2（CC BY-SA 4.0）。日本語訳と文の分割は本サイトによる。

出典一覧

文献	年	ライセンス	記録の数
An empirical study on changing leadership in agile teams	2021	CC BY 4.0	2
Game-based Sprint retrospectives: multiple action research	2021	CC BY 4.0	6
Hybrid Work in Agile Software Development: Recurring Meetings	2025	CC BY 4.0	3
Overcoming Challenges of Virtual Scrum Teams: Lessons Learned Through an Action Research Study	2023	CC BY 4.0	2
Recurring opinions or productive improvements—what agile teams actually discuss in retrospectives	2016	CC BY 4.0	8
Applicability of the Scrum Methodology in Remote Work Environments and the Challenges Encountered	2026	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	2

---

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

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

評価コメント:

• Faithfulness（5/5）: 前提コンテキストに記載された事実・観察結果・注意点（因果関係が実証されていないことや主観的報告である点など）に極めて忠実であり、コンテキスト外の独自解釈やアジャイルの一般的な俗説・勝手な断定は一切含まれていません。各事例の限界や留保事項も正確に反映されています。 - Relevance（5/5）: 「ふりかえりが浅くなる・マンネリ化する原因（症状への対症療法にとどまる、チーム外の課題の繰り返しなど）」と「スクラムマスターが取り得る打ち手（ゲームの導入、形式や話題の多様化、進行役の交代、アクションの振り返りなど）」およびその副作用・注意点について、質問の核心に対して過不足なく的確に回答しています。比較検証された決定打が存在しないという前提の限界を踏まえた上で、実践的な知見を整理して提示できています。

---

関連する用語

• スクラムマスター
• スプリントレトロスペクティブ
• 心理的安全性