経営陣やマネージャーから、スクラムの効果を数字で示すよう求められた。どう説明すればよいか？

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

結論（TL;DR）

数字を示す方法を比べて、経営の納得や支援がどう変わったかを測った文献は、今回読んだ範囲では見つかっていません。事例の多くは、体験報告、文献レビューの記述、認識の聞き取りです。ここで扱うのは、聞き手が経営の側にあるときの説明です。チームが自分で課題を見つけるために指標を取る話は、別の問いで扱っています。

数字や指標を示した例は 2 つあります。大規模なアジャイル変革の文献レビューが引く 1 事例では、コーチ・研修の予算の増額を求められた管理職が性能改善の証拠を求め、コーチングチームが「性能が 30% 上がる」という見積もりを示すと、管理職が強く納得したとされています。ただし、これは見積もりで、変革の後に測った値ではなく、根拠も書かれていません。ニュージーランドの企業の事例では、変革に抵抗する管理職に、チームがメトリクスとデータで価値を示し、インタビュー対象の 1 人は、管理職と役員の態度が変わったと述べました。一方で、上級職に価値を認めない人が少数残っているという発言もあり、メトリクスの種類や数値は書かれていません。

数字のほかに、見せる場や見せ方を扱った記述もあります。文献レビューには、管理職は成功したパイロットを見てからアジャイルの手法を承認した、という報告が 2 事例あります。政府のフェローシップでは、上司の支持が強かった事例で、管理職・幹部の層に進捗を示す場がありました。 6 つの大規模組織の比較では、パイロットの結果を伝えるのは良いことだが、実際より良く見せると、本物でない・続かないときに逆効果になりうる、という回答者の発言があります。広く拡大した組織は、コスト・品質・市場投入の速さのように測れる目標のある領域を選び、上級管理職をチームの進捗と課題に関わらせる必要があった、と著者は書いています（目標の達成度の数値は示されていません）。ブラジルの研究開発機関では、管理職 3 人が、ボードで仕事の流れが見えることを、進み具合の把握・予測・納期と費用のリスクの把握・採用の計画などに使えると語りました（使い道は人によって違います）。ただし著者は、これは認識で、性能が改善した証拠ではないとしています。

調査の数値もあります。ポーランドの ICT 業界の 288 件の回答では、アジャイルで進めた案件は全体の 48% が成功・8% が失敗、標準的な手法では 15% が成功・18% が失敗でした。ただし、割合は全回答に占める割合で、成功も進め方も自己申告です。因果は示されていません。大規模スクラムの課題を調べた系統的文献レビュー（18 本、査読前）では、上級管理職が新しい手法の有効性と成否を懸念することが、2 本で移行の妨げとして挙がっていますが、その懸念への対処は書かれていません。

打ち手と事例

ソフトウェアとハードウェアが混在する研究開発機関で、管理職 3 人は、ボードで仕事の流れが見えることを、進み具合の把握・予測・リスクの把握・採用の計画などに使えると語った（認識の聞き取りで、成果の測定ではない） ［Scrumban in Hybrid Environments（2026）］

• 状況: ブラジルの研究開発機関（INDT）で、ソフトウェアとハードウェアが相互に依存する案件が増え、チームは Scrumban を採った。著者は、開発チームの 15 人への調査と、導入に関わった管理職 3 人（マネージャー 2 人とディレクター 1 人）への半構造化インタビューを組み合わせ、管理職の側から見た利点を聞いた。
• やったこと: Scrum の儀式と Kanban の可視化を組み合わせた Scrumban を使い、ボードに仕事の全体の流れを見える形で出した。管理職は、そのボードの情報を、案件の管理に使った。
• 起きたこと: 管理職は、ボードの可視化を、計画に対する案件の進み具合の把握と先の活動の予測に使えると語り（M1）、ボードで活動の並行を追えるので管理職にとって見通しがよいとも語った（M2）。 M1 は、納期とお金に関するリスクがずっと見えるようになったと述べた。 M3 は、仕事の流れの情報が採用の計画や新しい案件の見通しにも役立ったと述べた。開発チームの T5 は、端から端までの仕事の地図があれば、納期が長くなる理由を管理職や他の部署に説明しやすくなる、と述べた。一方で著者は、ハードウェアの進みはボード上の作業の移動で十分に表せないことがあり、そのときは可視化が誤解を招きうる、と書いている。
• 注意点: 管理職は 3 人で、導入に関わった本人たちである（著者も、利点の見方が偏りうると認めている）。調査と聞き取りは参加者の認識と経験で、プロジェクトの性能の測定ではない。著者は、見えやすさや予測のしやすさなどを、プロジェクト性能が改善した因果の証拠として読むべきではないとし、リードタイム・サイクルタイム・スループットなどでの確認を今後の課題に挙げている。 T5 の発言は「説明しやすくなるだろう」という見通しで、説明して納得を得た報告ではない。単一の研究開発機関の質的な事例研究。
• 根拠: 事例研究／大規模な組織。文献: Scrumban in Hybrid Environments: An Empirical Investigation of Organizational Use and Impact in Development Teams（2026）。文献の種類: 論文・研究者。位置: 4.3 RQ3: Perceived Organizational Benefits of Scrumban（Visibility and project monitoring / risk management and decision-making / resource and organizational planning）/ 5.2 Visibility as a Benefit and a Boundary Condition / 6 Limitations。確認の根拠: 原典
• 原文: “delivery risks and financial risks became much more visible”

CEO と幹部が主導した変革で、抵抗する管理職に、チームがメトリクスとデータで価値を示し、1 人は態度が変わったと述べた ［An exploratory study of sustaining organisational agility（2025）］

• 状況: ニュージーランドの IT 中心の上場企業の、最大の事業部門（Retail。仮名）。アジャイルへの変革は 2016 年に始まり、CEO と一部の役員・上級管理職が主導した。導入が進んでも、上級管理職からバリューストリームオーナー、個々のチームまで、さまざまな階層に抵抗が残った。
• やったこと: チームの側が、管理職に、アジャイルの価値と有効性を示すメトリクスとデータを示した。組織は、アジャイルへの移行の経験がある上級管理職 2 人を海外から採用し、新しい CEO も採用した。導入後レビューでチームの意見を集め、運用モデルの改訂とアジャイルの周知・研修を続けた。賛成しているバリューストリームオーナーを「アンバサダー」にして、仲間の圧力を作ろうともした（P3）。
• 起きたこと: インタビュー対象の一人（P2）は、マネジメントと役員が、自分たちが得ている価値をとても簡単に見られるようになり、「態度が変わった」と述べた。別の一人（P3）は、上級職に価値を認めない人が少数残っていると述べた。本文も、さまざまな階層で抵抗が続いたと書く。経験のある上級管理職と新しい CEO の採用で、組織はかなり速く進められたとも書かれている。
• 注意点: 変革は CEO・上級幹部の主導で、現場のチームから始まったものではない。この記録は、導入の初期から拡大の過程で続いた管理職の抵抗への対処の報告である。「態度が変わった」の根拠は 1 人の発言（P2）で、因果を示した調査ではない。メトリクスの種類や数値は書かれていない。単一組織の質的ケーススタディで、インタビュー対象の 9 人は全員アジャイルの専門職。
• 根拠: 事例研究／大規模な組織。文献: An exploratory study of sustaining organisational agility（2025）。文献の種類: 論文・研究者。位置: 4.1 / 4.3.2 Resistance to change。確認の根拠: 原典
• 原文: “At the level of teams, the teams provided empirical evidence to the management, with metrics and data, to show the value and effectiveness of the agile way of working.”

前提に反する事例

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

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

政府のイノベーションフェローシップで、上司の支持が強い事例は管理職・幹部に進捗を示す場を得て、上からの支援と管理職の認識が欠けた事例はアジャイルの拒否に向かったと報告された ［Resolving Agile Ambidexterity（2026）］

• 状況: ヨーロッパの国の連邦政府が導入したイノベーションフェローシップ。連邦の省庁がプロジェクトの案を公募に出し、選ばれた案に、民間または非営利のスタートアップや独立のコンサルタントから来たフェローが半年間ついた。フェローは公務員とタンデムを組んでアジャイルの進め方を持ち込んだ。著者は、プログラムを運営するデジタルサービスチームと組み、複数の期の公務員・フェロー・運営者・外部の関係者にインタビューし、研修や会議を観察した。
• やったこと: 介入の効果を比べた研究ではなく、フェローシップのタンデムが、アジャイルの進め方を省庁の既存の手順にどう取り込んだか（または取り込まなかったか）を、インタビューと観察から 3 つの経路に分けた質的研究である。
• 起きたこと: 新しい働き方を省庁の手順に取り込めた事例では、公務員は変わる意欲が高く、部署の中の通常業務だけでなくプロジェクトチームで働くことに慣れていた。こうした事例では、上司の支持も強く、アジャイルの進め方と学びを組織のほかの部分へ持ち込むために多大な努力をした。フェローは働き方を紹介する場に招かれ、管理職・幹部の層への進捗の披露は、フェローシップの経験から学ぼうとする全般的な開かれた姿勢に支えられた。一方、手順との緊張が解けなかった事例では、公務員はアジャイルを通常業務の「上乗せ」の仕事に感じ、フェローシップだけでは組織のほかの部分の働き方に合わせられないと見た。彼らは、上からの支援が無く、管理職の認識が欠けていたことが、アジャイルの拒否につながったようだと述べた。
• 注意点: 原文は変革の起点を上下の言葉で分類していないが、政府が導入したフェローシップの枠組みで、省庁が案を出して始まった取り組みである。手直しの経路の事例では、公務員は上からの指示なしに主に自発的な参加で個々の手法を使い始めた。いずれも、現場のチームが自分たちで組織の変革を始めた記録ではない（ボトムアップで始まった事例ではない）。上司の支持をどう得たか、経営層がまだ関与していない状態から巻き込んだ手順は、書かれていない。部署の全体がアジャイルに変革した事例は 1 つも無く、取り込めた事例では、アジャイルは問題に応じて選ぶ手法の 1 つとして受け入れられた（著者はこれを両利きが受け入れられた状態と書く）。最も多かったのは、アジャイルの手法を省庁の文脈に合わせて手直しする経路で、この記録は、取り込めた経路と拒否に向かった経路の対比だけを載せている。事例ごとの数や比率は書かれていない。著者はこの結果から根拠に基づくモデルと命題を導き、ほかの文脈へ移しうる仮説と理論的な命題を立てる材料と位置づけている（検証はされていない）。対象は 1 つの国の 1 つのプログラムで、著者自身が統計的な一般化はできないと書く。
• 根拠: 事例研究／大規模な組織。文献: Resolving Agile Ambidexterity: Between Ambivalence, Adaptation, and Accommodation（2026）。文献の種類: 論文・研究者。位置: §3.1 Choice of Setting and Subjects / §4.2 Pathway 1 / §4.3 Pathway 2 / §4.4 Pathway 3 / §5 Discussion / §6.3・§6.4（PDF の通し番号 p.4、p.6〜9）。確認の根拠: 原典
• 原文: “They also had stronger buy-in from their superiors and made immense efforts to bring agile work practices and their learnings into the rest of the organization.”

拡大を広く進めた組織は、測れる目標のある領域を選んで広げ、PHARMA はコスト・品質・市場投入の速さを目標に道筋を作った。広く広げるには、上級管理職をチームの進捗と課題に関わらせる必要があった ［How to Implement Bottom-Up Organizing（2025）］

• 状況: アジャイルの導入を始めた 6 つの大規模組織の比較事例研究。拡大に進んだ 3 組織（IT・BANK・PHARMA）のうち、PHARMA と BANK は、階層のままの部署とアジャイルの部署が混在する形で広く広げた。 PHARMA は、革新を生み出しても妥当なコストで患者に届けられなかったため、患者への近さを高めるためにアジャイルを入れた。
• やったこと: PHARMA は、拡大を、市場投入の速さを上げながら品質を保ち、社会のコストを下げる必要に導かれて進めた。測れる目標（コスト・品質の水準・市場投入の速さ）を置き、地域の内と外で扱う話題を慎重に選んで、調整できる道筋を作った。
• 起きたこと: 著者は、広く拡大した組織は、測れる目標のある重点の領域を選び、組織の構造を整えながらアジャイルのチームを少しずつ組み込んでいたと書く。著者は、これでアジャイルの原則が既存の構造とすぐに衝突するリスクが下がるとする。また、広く拡大するには、アジャイルのチームの進捗、チームが立ち上げで当たった課題、拡大に必要な調整を、上級管理職に関わらせる必要があった、と書いている。
• 注意点: PHARMA 1 組織の記述と、著者による、広く拡大した組織（PHARMA・BANK）のまとめである。目標の達成度や、コスト・品質・速さの数値は示されていない。上級管理職に何をどんな形で伝えたか（どの数字を見せたか）は書かれていない。リスクが下がるという部分は、著者の解釈で、比べて測った結果ではない。大規模組織の導入研究で、スクラムの 1 チームの話に限らない。
• 根拠: 事例研究／大規模な組織。文献: How to Implement Bottom-Up Organizing: Lessons from Agile Piloting and Scaling（2025）。文献の種類: 論文・研究者。位置: Tensions in the Scaling Phase / Structure Tensions: Intensive Versus Extensive（PHARMA の段落とその後のまとめ）。確認の根拠: 原典
• 原文: “With these clear and measurable goals (cost, quality level, and speed to market) in mind, they carefully selected topics within and also across regions, which created an adjustable road map for the scaling of agile.”

6 つの大規模組織の比較で、パイロットの結果を伝えるのは良いことだが控えめに慎重に、と見られ、PHARMA の回答者は、成果を実際より良く見せると、本物でない・続かないときに逆効果になりうると述べた ［How to Implement Bottom-Up Organizing（2025）］

• 状況: アジャイルの導入を始めた 6 つの大規模組織（PEACE・INSUR・CONSTRUCT・PHARMA・BANK・IT）の比較事例研究。全組織がパイロットを行い、3 組織（IT・BANK・PHARMA）は拡大に進んだ。著者は、各組織で 3〜8 件のインタビューをし、最長 12 か月追って、パイロットから拡大に移る過程を調べた。
• やったこと: 介入の比較ではなく、パイロットの結果を組織の中で伝える進め方についての観察と、回答者の発言である。
• 起きたこと: 著者は、パイロットの結果を伝えること自体は一般に良いことと見られたが、控えめに慎重に行うのがよいと書いている。 PHARMA の回答者は、勢いをつけるために成果をできるだけ良く見せたくなるが、それが本物でない、または続かないものだと逆効果になりうる、と述べた。
• 注意点: 「慎重に」の根拠は、PHARMA の回答者 1 人の発言と著者のまとめで、伝え方の違いが拡大の結果をどう変えたかは比べていない。誰に向けて伝えるのか（経営層か現場か）は、この箇所では限っていない。結果を数字で示したのか、示した数字は何かも書かれていない。大規模な組織のアジャイル導入の研究で、スクラムの 1 チームが経営層に効果を説明する場面に限った話ではない。
• 根拠: 事例研究／大規模な組織。文献: How to Implement Bottom-Up Organizing: Lessons from Agile Piloting and Scaling（2025）。文献の種類: 論文・研究者。位置: Three Types of Agile Implementation / From Pilot to Scale-Up (or Not)。確認の根拠: 原典
• 原文: “It is tempting to dress up the outcomes as positively as possible to help build momentum for change, but this can also backfire if those results are not authentic or cannot be sustained.”

ポーランドの ICT 業界の 288 件の回答で、全回答に占める割合は、アジャイルの案件が成功 48%・失敗 8%、標準的な手法の案件が成功 15%・失敗 18% だった（各手法の件数は同じでない。自己申告の調査） ［The Impact of Identified Agility Components on Project…（2023）］

• 状況: ポーランドの企業またはその支社にいる ICT 業界の人（プロジェクトマネージャー、プロダクトマネージャー、経営の担当者など）への質問票調査。大規模な投資案件を管理した経験を持つ人を選んだ目的標本で、回答は 288 件。回答者の 85% が受注側、15% が発注側だった。質問票は 8 つの質問で案件の成功（予算・納期・機能・顧客の満足など）を 5 段階で聞き、合計が基準の 24 点を超えたものを成功とした。
• やったこと: 介入ではなく、案件の進め方（アジャイル・標準的な手法・手法なし）と、案件が成功か失敗かの関係を調べた調査である。
• 起きたこと: 案件の成功は全体の 67%、失敗は 33% だった。進め方との組み合わせ（全回答に占める割合）は、アジャイルが失敗 8%・成功 48%、標準的な手法が失敗 18%・成功 15%、手法なしが失敗 6%・成功 4% だった。進め方と成否の関連は有意で（χ² = 53.036、自由度 2、p < 0.001）、Cramér の V は 0.425 で、著者は中程度の相関としている。アジャイルの水準（得点）の中央値は、成功した案件が 36、失敗した案件が 16 だった。著者は、アジャイルの水準が高いほど成功の見込みが上がると結論し、同時に、アジャイルの要素のうち 1 つだけを満たしても成功は保証されないとしている。
• 注意点: 表の割合は全回答に占める割合で、進め方ごとの成功率ではない。成功も、アジャイルの水準も、回答者の自己申告の 5 段階評価を合算したもので、成功の区切り（3n）は著者も恣意的と認めている。案件が終わってからの回答で、著者は、失敗が見込まれたときに管理の仕方を変えた可能性などを限界に挙げる。因果は示されていない。著者自身、満足度の高いチームがアジャイルに働きやすいという逆向きの関係もありうると書く。ポーランドの ICT 業界に限った調査で、スクラムに限らない「アジャイル」の回答であり、各社が経営に数字として示した例ではない。
• 根拠: 調査（アンケート）／大規模な組織。文献: The Impact of Identified Agility Components on Project Success—ICT Industry Perspective（2023）。文献の種類: 論文・研究者。位置: Analysis of project success（Table 5）/ Agility and project success（Table 6）/ Limitations and future research。確認の根拠: 原典
• 原文: “The performance of work using agile methods resulted in project success in 48% of cases, whereby failure was reported in 8% of cases.”

大規模スクラムの課題を調べた系統的文献レビュー（18 本）で、上級管理職が新しい手法の有効性と成否を懸念することが、移行の妨げの 1 つとして 2 本（P15・P17）に挙がった ［Systematic Literature Review Report on the Challenges…（2025）］

• 状況: 大規模なソフトウェア開発でスクラムを使う組織の成功・課題を報告した事例・経験報告・実証研究を、PRISMA の手順で探した系統的文献レビュー。 183 本から全文を調べた 26 本を選び、18 本を対象にした。課題を 8 つの主題と 46 の副主題に整理し、「変化への抵抗」の主題に「管理職の抵抗」の副主題がある。
• やったこと: 介入ではなく、課題の整理である。レビューは、管理職の抵抗の副主題を、18 本のうち 2 本（11%、P15・P17）が挙げたものとして数えている。
• 起きたこと: レビューは、新しい手法の有効性と成否についての上級管理職の懸念が、アジャイルへの移行のつまずきの 1 つだと書いている（P17）。上級管理職の賛同を得られないとアジャイルは組織で根づかず、管理職のためらいと抵抗が採用の障害になる、とも書く（P15）。この懸念に、チームがどう答えたか、その結果はどうだったかは書かれていない。
• 注意点: 査読前のプレプリントである（原文に「Not peer-reviewed version」とある）。対象は 18 本で、この副主題は 2 本（11%）にしか挙がっていない。2 本の中身は、このレビューの要約を通してしか確かめていない（P17 は UAE の通信業の経験報告）。大規模スクラムの導入の課題の整理で、現場のチームが経営に効果を説明する場面を扱ったものではない。懸念への対処は書かれていない。
• 根拠: 文献レビュー／大規模な組織。文献: Systematic Literature Review Report on the Challenges of Agile Scrum（2025）。文献の種類: プレプリント・研究者。位置: 4.1.1.6 Resistance to Change / Management Resistance to Change（件数は Appendix A、対象の数は 4. Analysis の冒頭）。確認の根拠: 原典
• 原文: “The upper management concerns on the effectiveness and success of the transition to a new method is one of the stumbling blocks for agile transition [P17].”

管理職は、成功したパイロットを見てからアジャイル手法を承認した、という報告がある（2 事例、P14・P47） ［Challenges and success factors for large-scale agile…（2016）］

• 状況: 大規模アジャイル変革の系統的文献レビューで、成功要因の 1 つ「Start with a pilot to gain acceptance（受け入れを得るためにパイロットから始める）」は、複数の事例で挙げられた（P3・P9・P38）。パイロットは、特に管理職の受け入れを得るうえで重要だったと述べられている。
• やったこと: パイロットプロジェクトを実施した。
• 起きたこと: パイロットが成功したのを見てから、管理職がアジャイル手法を承認した事例が報告された（P14・P47）。成功したパイロットの例を見ると、ほかの部署の管理職も新しい手法を試したがり、広がりを助けると述べた報告もある（P39）。
• 注意点: 承認の記述は 2 事例（P14・P47）、他の部署への波及は 1 事例（P39）の体験報告。パイロットの主導者は、書かれていない。誰が誰に成果を見せたかも、書かれていない。
• 根拠: 文献レビュー／大規模な組織。文献: Challenges and success factors for large-scale agile transformations: A systematic literature review（2016）。文献の種類: 論文・研究者。位置: 4.3.5 Piloting / Start with a pilot to gain acceptance。確認の根拠: 原典
• 原文: “Cases reported that management gave approval for agile methods only after seeing successful pilots [P14, P47].”

コーチが示した 30% の性能向上の見積もりで、コーチ・研修の予算の増額を求められた管理職が納得した（1 事例、P6） ［Challenges and success factors for large-scale agile…（2016）］

• 状況: 大規模アジャイル変革の系統的文献レビューで、成功要因の 1 つ「Create and communicate positive experiences in the beginning（初期に良い経験を作り伝える）」の節にある 1 事例（P6、Benefield。表 7 では Yahoo!）。満足度の調査でアジャイルの満足度を客観的に測り、その良い結果が、チームが働き方を変える決断を助けた。さらに、コーチ・研修の予算の増額を求めたのに対し、管理職が性能の改善の証拠を求めた。
• やったこと: 問い合わせ（inquiries）をしたうえで、コーチングチームが、性能が 30% 上がるという見積もりを示した。
• 起きたこと: コーチングチームが 30% の性能向上の見積もりを示し、管理職は強く納得した（P6）。
• 注意点: 「30%」は、コーチングチームが示した見積もり（estimate）で、変革後に測った数値ではない。見積もりの根拠・算出は書かれていない。レビューが引く 1 事例（P6）の体験報告の記述で、要因と成果の関係を測った結果ではない。口コミで変革が広がったという別の記述（P6・P40）は、この記録とは別の知見として扱う。
• 根拠: 文献レビュー／大規模な組織。文献: Challenges and success factors for large-scale agile transformations: A systematic literature review（2016）。文献の種類: 論文・研究者。位置: 4.3.8 Communication and transparency / Create and communicate positive experiences in the beginning。確認の根拠: 原典
• 原文: “After conducting inquiries, the coaching team was able to present an estimate of a 30% increase in performance, which made management highly convinced [P6].”

出典一覧

文献	年	ライセンス	記録の数
Challenges and success factors for large-scale agile transformations: A systematic literature review	2016	CC BY 4.0	2
An exploratory study of sustaining organisational agility	2025	CC BY 4.0	1
How to Implement Bottom-Up Organizing: Lessons from Agile Piloting and Scaling	2025	CC BY 4.0	2
The Impact of Identified Agility Components on Project Success—ICT Industry Perspective	2023	CC BY 4.0	1
Resolving Agile Ambidexterity: Between Ambivalence, Adaptation, and Accommodation	2026	CC BY 4.0	1
Scrumban in Hybrid Environments: An Empirical Investigation of Organizational Use and Impact in Development Teams	2026	CC BY 4.0	1
Systematic Literature Review Report on the Challenges of Agile Scrum	2025	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/5】前提コンテキストの記述を極めて厳密に遵守しています。コンテキスト外の独自解釈や俗説、勝手な断定は一切含まれていません。特に、「30%の性能向上」が測定値ではなく根拠不明の見積もりに過ぎない点、ニュージーランド企業のメトリクスの種類や数値が不明である点、各事例が因果関係を示すものではなく認識の聞き取りや自己申告である点、ポーランド調査の比率が「全回答に占める割合」である点など、前提コンテキストに記載された注意点・限界事項が漏れなく正確に反映されています。【Relevance（関連性・回答性）: 4/5】質問「経営陣やマネージャーから、スクラムの効果を数字で示すよう求められた。どう説明すればよいか？」に対して、まず冒頭で「数字を示す方法を比較して経営の納得や支援の変化を測った文献は見つかっていない」とエビデンスの不在を明示した上で、コンテキスト内で参照可能な事例（見積もりやメトリクスの提示例、過大に見せない慎重さ、パイロット結果の活用、ボードによる仕事の流れの可視化など）を網羅的に整理して提示しています。ただし、質問が求めている「では具体的にどう説明すればよいのか」という実践的な行動指針や説明方針としての結論・まとめが提示されておらず、関連文献・事例の要約の羅列にとどまっています。末尾も特定の系統的文献レビューの課題の記述で唐突に終了しており、「質問に対する直接の提言・結論」としての構成が弱いため、4点と評価しました。

---

関連する用語

• ステークホルダー
• 価値
• ベロシティ
• チームベロシティ