プランニングとゴール設定で、チームの協業をどう引き出すか？

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

結論（TL;DR）

プランニングやスプリントゴールの決め方を変えて、メンバーの協業がどう変わったかを比べた文献は、今回読んだ範囲では見つかっていません。拾えたのは、大規模プログラムの見積もりの事例、スクラムチームの観察、文献レビュー、質問紙調査などで、協業を引き出した事例そのものはありません。ここで扱うのは、チームが一緒に計画を立てる場面の工夫です。ルールの理解を確かめる問い（スプリントゴールの変更の可否、プランニングを 1 回にする理由など）とは別で、そちらは扱いません。

最も具体的な材料は、スクラムチームの有効性を 13 の事例で調べた研究です。プロダクトオーナーがプランニングを事業の目的から始め、その目的が作業の並べ方と選び方の指針になった事例が 7 つ、関係のない上位の項目をそのまま選んだ事例が 5 つありました。共有の目標を使っていなかったチームは、使えばチームの士気や協力が高まると認めることが多くありました。ただし、目的から始めて協力が実際に増えたかは測られていません。リファインメントをスプリント中にしたチームではプランニングが早く進む傾向も観察されていますが、協力の度合いへの影響は書かれていません。

大規模な ERP 導入プログラム（20 の Scrum チーム）の見積もりの事例では、見積もりに関わる意欲の弱さと、要件の理解がそろわないことを、それぞれ 5 人が協力面の課題に挙げました。著者らが整理した緩和策のうち、評価した 12 人の専門家はほとんどの案に賛成し（要件を掘り下げて話し合う場で共通の理解をつくる案を含む）、スクラムマスターやアジャイルコーチが見積もりを支える案の賛成が最も高くなりました。いずれも案への賛否で、試した結果ではありません。銀行の 3 チームでは、仕様の確認会やプランニングが同じ理解を持つ助けになったと語られ、1 つのチームは確認会をプランニングの直前に移しました（チームリーダーの語りで、効果は測られていません）。

スプリントゴールや見積もりの扱いに関する調査もあります。ポーランドの 42 人への調査では、スプリントゴールをプランニングの最後に決めるか決めないことを 20 人が、見積もりがチームに押しつけられることを 13 人が、「よくある」「いつも」と答えました。頻度だけで、原因や影響は調べられていません。Scrum のテーラリングの文献レビューは、ゴールを定めないことや、ストーリーを見積もらないことが、目標に身を入れない、やる気を失う、といった失敗につながった例を挙げています。レビューが各研究を要約したもので、個別の結果の根拠は十分でないとレビュー自身が書いています。

どれも、協業を引き出す進め方を比べた記録ではなく、効果が確かめられた打ち手は見つかっていません。

打ち手と事例

ニュージーランドの銀行の 3 つのアジャイルチームで、仕様の確認会やプランニング、スタンドアップが、メンバーが同じ理解を持つ助けになったと語られた［A teamwork effectiveness model for agile software…（2022）］

状況: ニュージーランドの商業銀行で、同じ大部屋で働く 3 つのアジャイル開発チーム（Globe、Tech、Rock）の事例研究。各チームは約 10 人で、同じアジャイルコーチの下にあり、同じ研修を受けていた。著者らはこの事例研究を、別の焦点グループ調査と合わせて、アジャイルチームのチームワークの効果のモデルを組み立てるために使った。
やったこと: この研究は働きかけをしていない。 Globe のチームでは、仕様の確認会（スペックワークショップ。ストーリーのビジネス上の意図を確かめる場）が、チームの共通の理解をつくった。 Tech のチームでは、作業が始まる前に、誰がどの作業に向くかを互いに話し合って決めており、著者らはこれを、プランニングとスタンドアップが増やした共通の理解の例として挙げている。 Rock のチームでは、新しく入ったメンバーが文脈の説明なしに作業を任され、プロジェクトリーダーは、もう少し全体像があればよかったと振り返った。スタンドアップが共通の理解の助けになったと述べたメンバーもいた。
起きたこと: Globe のチームメンバーは、仕様の確認会は退屈なときもあるが、全員が何が起きようとしているかを理解でき、同じことを指しているという明快さが生まれると述べた。著者らは、この発言を、誰が何を知っているかについての共通の理解を示しうるもの（could indicate）と読んでいる。 Rock では、全体像の共有が足りなかったことを、プロジェクトリーダーが自分たちのやり残しとして語った。共通の理解が成果にどう効いたかは、この事例では測られていない（結果の記述なし）。
注意点: 参加者の語りと、それを共通の理解の例と読んだ著者の解釈である。 1 つの銀行の同じ大部屋の 3 チームで、モデルは同じ場所で働くチームを前提にしている。共通の理解が成果に効くという主張は、他の研究を引いたもので、この事例が示したものではない。
根拠: 事例研究／単一チーム。文献: A teamwork effectiveness model for agile software development（2022）。文献の種類: 論文・研究者。位置: 3.2.1 Case Selection / 4.1.1 Empirical Findings on Shared Mental Models。確認の根拠: 原典
原文: “the spec workshop, although I find it boring as hell sometimes, it’s interesting, everybody’s getting an understanding of what’s supposed to be happening.”

銀行のアジャイルチーム Globe は、スプリントの 2 週間前に開いていた仕様の確認会が、ビジネス側の優先順位の変更で無駄になることがあったため、スプリントプランニングの直前に移した［A teamwork effectiveness model for agile software…（2022）］

状況: ニュージーランドの商業銀行の、約 10 人のアジャイル開発チーム Globe。ストーリーのビジネス上の意図を確かめる仕様の確認会（スペックワークショップ）を、週 1 回、数時間かけて開いていた。
やったこと: 確認会をスプリントの 2 週間前に開いていたところ、スプリントに入ってプランニングで何をするか決める段になると、ビジネス側の責任者が優先順位を変えていたり、予定していたことができなくなっていたりして、確認会の作業が無駄になることがあった。そこで、確認会を 2 週間前ではなく、スプリントプランニングの直前に開くことにした。
起きたこと: チームリーダーは、直前に移した方がうまくいったと述べた。優先順位の変更が減ったか、確認会の中身がどう変わったかは、数や記録では示されていない（結果の記述なし）。
注意点: チームリーダー 1 人の語りで、効果は測られていない。確認会を移したのは、優先順位の変更に対する 1 つのチームの対処で、ほかのチームに合うかは分からない。
根拠: 事例研究／単一チーム。文献: A teamwork effectiveness model for agile software development（2022）。文献の種類: 論文・研究者。位置: 4.7.1 Empirical Findings on Adaptability。確認の根拠: 原典
原文: “we would do it immediately before our Sprint planning. And that’s worked out better”

自動車の開発チーム CAR は、プランニングでできるだけ詳細を詰めても、スプリント中に顧客が変えて遅れや二重作業が出たため、顧客をデイリースタンドアップに招き、報告の周期を短くした［Interruptions in Agile Software Development Teams（2021）］

状況: 自動車業界のスクラムのチーム CAR（4 人）。同じ場所で働く。著者らが、アジャイルのソフトウェア開発チームの割り込みを調べた複数チームの事例研究の中の 1 チームである。開発者は要件の確認に多くの時間を使っていた。
やったこと: 開発者は、プランニングでできるだけ多くの詳細を詰めようとしていた。それでも、スプリント中に細部が出てきたり、顧客が変えたりして、遅れや二重作業が出た。チームは、顧客をデイリースタンドアップに招き、報告の周期を短くして、要件の変更に対処した。
起きたこと: 結果の記述なし。 顧客を招き、報告の周期を短くしたことで、遅れや二重作業がどうなったかは書かれていない（結果の記述なし）。
注意点: 付録の、コード化の手順を示す例の 1 行で、結果の記述は無い。全チームが、顧客がスプリント中にも項目を変えると報告している。顧客がプランニングやレビューで変えるときは、スプリント中に変えるときより割り込みが少なかった。本文の表では CAR の「顧客がデイリーに関わる」は No だが、付録は顧客をデイリースタンドアップに招いたと書いており、原文の中で食い違っている。
根拠: 事例研究／単一チーム。文献: Interruptions in Agile Software Development Teams（2021）。文献の種類: 論文・研究者。位置: Appendix / Illustration of Coding Procedure。確認の根拠: 原典
原文: “Team CAR invited the customer to daily”

スプリントプランニングは、出社日に対面で開くチームと、部門全体の遠隔の場で計画するチームに分かれた［Hybrid Work in Agile Software Development（2025）］

状況: フィンランドの通信機器メーカーの研究開発拠点で、週 2 日の出社を基本とするハイブリッド勤務をしている 2 つの部門の 15 のアジャイルチームを、27 人へのインタビューで調べた単一事例研究。どちらの部門も、全チームが 2 週間のスプリントの共通の予定で動いていた。
やったこと: 火曜と木曜を出社日にした部門では、4 チームが、隔週の火曜に出社してスプリントプランニングを開いていた。出社日を柔軟にした部門では、多くのチームが、全チームが隔週で集まる遠隔の「スプリントチェンジ」の場で計画していた。この場では、各チームのコーチが前のスプリントの成果と学びを共有し、その後チームごとのブレイクアウトルームで次のスプリントの作業を話し合った。チームは事前に、成果・学び・次の作業を Confluence に書いて、部門の全員に見えるようにしていた。この部門で、チーム単独のスプリントプランニングを隔週で開いていたのは 1 チームで、主に遠隔の日に開いていた。
起きたこと: あるチームのメンバーは、チームで作業を計画するうえで最も大事な対面の会議はユーザーストーリーの計画で、チームが一緒に座って機能を話し合うべきだと話した。プロダクトオーナーの 1 人は、部門全体の遠隔の場は計画というより「お祝い」に近く、全員に今どこにいるかと、そのスプリントの優先順位の理由を伝える場だと話した。スプリントプランニングは、どれも 30〜60 分だった。どちらの開き方が計画の質に効いたかは調べられていない（結果の記述なし）。
注意点: 語られたのは参加者の受け止めで、計画の質は測られていない。部門ごとの違いは、出社日の決め方だけでなく、開発の進め方（スクラムに近いか、スクラムとカンバンを組み合わせているか）の違いとも重なっている。 1 社の 2 部門だけの調査で、結果が当てはまるのは似た状況に限られる。
根拠: 事例研究／複数チーム。文献: Hybrid Work in Agile Software Development: Recurring Meetings（2025）。文献の種類: 論文・研究者。位置: IV. RESULTS / C. Unit Meetings / D. Agile Team Meetings / 2) Sprint planning and refinement。確認の根拠: 原典
原文: “the most important in-person meeting is user story planning, because there the team should sit together and really discuss the feature that they’re working on.”

大規模な ERP 導入プログラムの見積もりで、要件を掘り下げて話し合う場で共通の理解をつくる案は、評価した専門家が賛成した案の 1 つで、実装前に要件を詳しく確かめる案は意見が割れた［Investigating Effort Estimation in a Large-Scale Agile ERP…（2024）］

状況: ドイツのエネルギー企業の大規模な ERP 導入プログラム（20 の Scrum チーム）の見積もりを調べた単一ケーススタディ。要件の理解が人・チーム・ワークストリームの間でそろわないことが、見積もりを難しくする課題の 1 つに挙がっていた。
やったこと: 著者らは、インタビューと文献から、課題への緩和策を 19 件に整理した。そのうち「掘り下げの会合やワークショップ（deep dive sessions and workshops）」は、要件とその実装を明らかにする場を設けて、依存を早く見つけ、正しい共通の理解をつくり、最初の見積もりの材料を集める案である。顧客側（ここでは子会社）が会議に出ると曖昧さを解きやすい、とも書かれている。この案は、インタビューの参加者 3 人が共通の理解づくりの手段として挙げたものに、文献を足して整理されている。別の案「実装の前に要件を詳しく確かめる期間（pre-implementation phase）」も、同じ目的で挙がっていた。
起きたこと: 最初のインタビューに参加した 12 人の専門家が、案ごとにどの程度賛成するかを 5 段階で答え、感想を述べた。ほとんどの案（掘り下げの会合やワークショップを含む）に賛成が多かった。賛成の程度の数値は本文で述べられていない。「実装の前に要件を詳しく確かめる期間」は意見が割れた。多くの専門家は価値があると見たが、数人は反対し、設計の話に時間をかけすぎて前に進まなければ、多くの時間を失うという意見が出た。案を実際に試して見積もりが良くなったかは調べられていない（結果の記述なし）。
注意点: 案は著者がインタビューと文献から整理したもので、試した結果ではなく、賛否の意見を聞いたものである。評価した 12 人は、最初のインタビューに参加した同じ 1 つのプログラムの人である。
根拠: 事例研究／複数チーム。文献: Investigating Effort Estimation in a Large-Scale Agile ERP Transformation Program（2024）。文献の種類: 論文・研究者。位置: 4.4 Propositions to Mitigate Effort Estimation Challenges（M4）/ 4.5 Evaluation of the Proposed Mitigations。確認の根拠: 原典
原文: “The experts agreed with most propositions (M1, M3–15, M19).”

大規模な ERP 導入プログラムの見積もりで、見積もりに関わる意欲の弱さと、要件の理解が人・チーム・ワークストリームの間でそろわないことが、協力面の課題に挙がった［Investigating Effort Estimation in a Large-Scale Agile ERP…（2024）］

状況: ドイツのエネルギー企業が、合併後に ERP を標準のクラウド製品へ統一する大規模なプログラム（関わる人は計 350 人）。 20 の Scrum チームが 10 のワークストリームに分かれ、見積もりはロードマップの計画、ウェーブの計画、スプリントプランニング、プロダクトバックログのリファインメントで行われていた。著者らは、この見積もりを調べる単一ケーススタディを 2022 年 11〜12 月に行った。プロダクトオーナー、開発者、スクラムマスター、アーキテクトなど 20 人（E1〜E20）への半構造化インタビューが中心である。
やったこと: この研究は課題の聞き取りで、働きかけはしていない。見積もりの課題を 14 件に整理し、「少なくとも 3 人が挙げたもの」だけを載せている。
起きたこと: 協力に分類された課題のうち、「見積もりに貢献する意欲の弱さ（アジャイルへの抵抗、見積もりを余計な作業と見る、見積もりに自信が無い）」は 5 人、「品質基準や範囲を含む要件の理解が、個人・チーム・ワークストリームの間でそろわない」も 5 人が挙げた。「拠点が分かれることによる言語の壁と、見積もりを難しくする遠隔の会議」は 3 人が挙げた。課題を直せば見積もりがどうなったかは調べられていない（結果の記述なし）。
注意点: 1 つのプログラムの当事者の受け止めで、見積もりの精度への影響は測られていない。課題の表は、人数でいえば 3 人以上が挙げたものに絞られている。著者は、結果はこのプログラムに固有だが、他のプログラムにも関連しうるとしている。
根拠: 事例研究／複数チーム。文献: Investigating Effort Estimation in a Large-Scale Agile ERP Transformation Program（2024）。文献の種類: 論文・研究者。位置: 4.3 Effort Estimation Challenges / Table 2（Collaboration: C5・C6・C7）。確認の根拠: 原典
原文: “Missing correct and common understanding of requirements, including quality criteria and scope, between individuals, teams, and workstreams complicates estimating.”

大規模な ERP 導入プログラムの見積もりで、スクラムマスターやアジャイルコーチが見積もりを支え、チームの意欲を引き出す案は、評価した専門家の賛成が最も高かった［Investigating Effort Estimation in a Large-Scale Agile ERP…（2024）］

状況: ドイツのエネルギー企業の大規模な ERP 導入プログラム（20 の Scrum チーム）の見積もりを調べた単一ケーススタディ。見積もりに貢献する意欲の弱さ（アジャイルへの抵抗、見積もりを余計な作業と見る、自信が無い）が課題の 1 つに挙がっていた。
やったこと: 著者らが整理した緩和策の 1 つが、見積もりの間のスクラムマスターやアジャイルコーチによる支えと動機づけである。インタビューでは、アジャイルのやり方で見積もることへの理解・意欲・受け入れを高め、要件の機能の説明の質を上げる助けになる、と語られていた。著者らは、文献にも、スクラムマスターの関わりを勧めるものがあると書いている。
起きたこと: 最初のインタビューに参加した 12 人の専門家が案ごとの賛成の程度を答えた中で、この案の賛成が最も高かった。賛成の数値は本文で述べられていない。支えを入れて見積もりへの関わりがどう変わったかは調べられていない（結果の記述なし）。
注意点: 賛成の意見であり、スクラムマスターの支えで見積もりが良くなったことを測ったものではない。評価した 12 人は、同じ 1 つのプログラムのインタビュー参加者である。
根拠: 事例研究／複数チーム。文献: Investigating Effort Estimation in a Large-Scale Agile ERP Transformation Program（2024）。文献の種類: 論文・研究者。位置: 4.4 Propositions to Mitigate Effort Estimation Challenges（M13）/ 4.5 Evaluation of the Proposed Mitigations。確認の根拠: 原典
原文: “M13 received the highest agreement, followed by M15.”

プロダクトオーナーがプランニングを事業の目的から始めた事例が 7 つ、関係のない上位の項目を選んだ事例が 5 つあり、共有の目標を使っていなかった 3 つの事例のチームは、使えばチームの士気や協力が高まると認めていた［A Theory of Scrum Team Effectiveness（2022）］

状況: 2014〜2019 年に行われた 13 の事例（各事例に 1 つ以上のスクラムチームが入り、観察は数か月から 1 年）から、スクラムチームの有効性の要因を調べた研究。スプリントゴールなどの「共有の目標」の使い方は、事例によって大きく違った。
やったこと: 7 つの事例では、プロダクトオーナーがスプリントプランニングを事業上の目的を述べることから始め、その目的が、その回の作業の並べ方と選び方の指針になった。 5 つの事例では、互いに関係のない項目でも、上から順に選んでいた。共有の目標を使っていなかったチームは、使えばチームの士気、顧客志向、協力が高まると認めることが多かった（3 つの事例）。
起きたこと: 目的から始めたことで協力が実際に増えたかは、測られていない（結果の記述なし）。目標を使わないチームが「使えば協力が高まる」と認めていた、という観察にとどまる。
注意点: 観察と聞き取りにもとづく記述で、目標の使い方と成果の関係は、事例の記述では確かめられていない。「使えば高まる」は、目標を使っていなかったチームの本人たちの受け止めである。同じ事例の中に、目的から始めたチームと、始めなかったチームが混じる場合がある（事例 #1、#7 は両方の記述に出る）。
根拠: 事例研究／複数チーム。文献: A Theory of Scrum Team Effectiveness（2022）。文献の種類: 論文・研究者。位置: 4.4 Results from the case studies / 4.4.3 Stakeholder Concern / Shared goals。確認の根拠: 原典
原文: “Teams that did not use shared goals often acknowledged that it would bolster team spirit, customer orientation, and collaboration if they would”

スプリント中にリファインメントをするチームは、プランニングが早く進む傾向があり、リファインメントの不足は、何が必要かをはっきりさせたい、プランニングを楽にしたいなどの理由でふりかえりに繰り返し上がった［A Theory of Scrum Team Effectiveness（2022）］

状況: 2014〜2019 年に行われた 13 の事例（各事例に 1 つ以上のスクラムチームが入り、観察は数か月から 1 年）から、スクラムチームの有効性の要因を調べた研究。チームごとに、大きな項目を 1 スプリントで届けられる大きさに分ける作業（リファインメント）のやり方が違った。
やったこと: ほとんどのチームは、全員が出る週次のワークショップでリファインメントをしていた（5 つの事例）。ほかのチームは、おもにスプリントプランニングの中で行っていた（3 つの事例）。ほとんどのチームが、リファインメントをしていても、もっとすべきだと感じていた。
起きたこと: 著者らは、スプリント中にリファインメントをしたチームでは、スプリントプランニングが早く進む傾向があったと観察している。ほとんどのチームが、リファインメントの不足をふりかえりで繰り返し話題にしていた。理由は、何が必要かをはっきりさせたい、外部との依存を早く知りたい、プランニングを楽にしたい、というものだった。あるスクラムマスターは、リファインメントのおかげで「スプリントがずっと滑らかになる」と述べた。
注意点: 観察にもとづく傾向で、リファインメントの量とプランニングの所要時間は測られていない。リファインメントを重く見ないチームもあり、スプリントを人為的な区切りと見て、終わらない作業を次のスプリントに回してよいと考えていた。協力の度合いへの影響は書かれていない。
根拠: 事例研究／複数チーム。文献: A Theory of Scrum Team Effectiveness（2022）。文献の種類: 論文・研究者。位置: 4.4 Results from the case studies / 4.4.2 Responsiveness / Refinement。確認の根拠: 原典
原文: “we observed that Sprint Planning tended to go faster for teams that refined during the Sprint.”

スプリントプランニングを 2 回開く、事前の計画の会を足すといった変え方が挙がり、ある研究は、2 回の計画を含む変え方で全体の成功が上がったと報告していた［Tailoring Choices Made in Scrum Projects（2022）］

状況: Scrum のテーラリングを扱った 23 本の論文の体系的文献レビュー。レビューは、スプリントプランニングの変え方の例を、もとの研究の記述を短くまとめて挙げている。
やったこと: ある研究が報告した 1 つのチームは、プランニングを 1 回ではなく 2 回開く方を選んでいた。分散したチームでは、オフショアのチームと開く会の前に、オンショアのチームとの事前・事後の計画の会を、オフショアのチームとの会の前に開く進め方が好まれた。 EnergyInfo は、オフショアのチームの業務知識を高める目的で、スプリントの事前プランニングを追加した。 CollaborationSoft は、プロジェクトマネージャーとサブチームのコーディネーターが出る毎週のスプリントプランニングを開いた。 TestSoft は、参加者を分けた事前プランニングを追加し、最初のプランニングにはプロダクトオーナーとスクラムマスターだけが出た。
起きたこと: Fitzgerald らの研究について、レビューは、プランニングを 2 回にすることや、ガントチャートとタスク間の複雑な依存を省いて計画を単純に保つこと、スプリントの区切り方の変え方といった変え方の結果として、プロジェクト全体の成功が上がったと書いている。 EnergyInfo などほかの変え方の結果は書かれていない（結果の記述なし）。レビュー自身も、Scrum の実践のテーラリングの個別の結果については十分な根拠が無いと書いている。
注意点: 文献レビューが、もとの研究の記述を短くまとめたもので、もとの研究では確認していない。「成功」の指標は書かれておらず、プランニングを 2 回にしたことの効果と、計画を単純にしたことやスプリントの区切り方の変え方の効果は切り分けられていない。プランニングを 2 回にしたのは 1 つのチームの例で、事前の計画の会は分散したチームの例である。
根拠: 文献レビュー／複数チーム。文献: 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。確認の根拠: 原典
原文: “Fitzgerald et al. [12] states that in one team, two sprint planning meetings were preferred instead of one.”

前提に反する事例

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

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

ストーリーを見積もらないと非現実的な目標でやる気が下がった例と、期限の決まらないスプリントで目標がチームに伝わらず身を入れなかった例が、文献レビューに挙がっていた［Tailoring Choices Made in Scrum Projects（2022）］

状況: Scrum のテーラリングを扱った 23 本の論文の体系的文献レビュー。レビューは、スプリントプランニングのテーラリングの例として、スプリントゴールを定めないことや、ストーリーを見積もらないことを挙げている。
やったこと: 介入ではなく、各研究が報告した変え方とその結果のまとめである。プランニングの変え方として、1 回より多く開く、プランニングにスプリントバックログだけを使う、スプリントゴールを定めない、ストーリーを見積もらない、が挙がっていた。
起きたこと: Eloranta らの研究について、レビューは、スプリントの期限が決まっておらず、目標がチームに明確でなく、スプリントはいつでも延ばせるため、メンバーが目標に身を入れなかったと書いている。同じ研究で、見積もりが無かったため非現実的な目標になり、メンバーのやる気が下がったとも書いている。さらに、スプリントゴールを定めない、ストーリーを見積もらない、スプリントバックログだけを材料にするといった変え方の多くは、重要な機能を実装できない、スプリントゴールを定めにくい、計画の会議が無計画で整理されないといった失敗につながったとまとめている。一方で、レビューは、個別の変え方の結果については十分な根拠が無いとも書いている。
注意点: 文献レビューが、もとの研究の記述を短くまとめたもので、もとの研究では確認していない。スプリントゴールが無いことだけの影響は切り分けられておらず、期限が決まっていないことなどと重なっている。
根拠: 文献レビュー／複数チーム。文献: 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。確認の根拠: 原典
原文: “goals were not clear to the team and team members were not committed to the sprint goals considering that the sprint could be extended at any time”

ポーランドの 42 人への調査で、見積もりがチームに押しつけられることを「よくある」「いつも」と答えた人は 13 人、「全くない」と答えた人は 17 人だった［Exploring the Prevalence of Anti-patterns in the Application…（2023）］

状況: ポーランドのソフトウェア開発の組織で働く 42 人へのアンケート（2022 年 5〜6 月、LinkedIn と SNS で募集）。文献から選んだ Scrum のアンチパターン 35 個について、自分の組織で出会うかを「全くない」から「いつも」の 5 段階と「分からない」で答えてもらった。スプリントプランニングに関する項目の 1 つが「項目の見積もりがチームに押しつけられる」だった。
やったこと: 介入ではなく、出会う頻度の調査である。
起きたこと: 「項目の見積もりがチームに押しつけられる」への答えは、「全くない」17 人、「まれ」6 人、「ときどき」6 人、「よくある」10 人、「いつも」3 人で、「分からない」は 0 人だった。著者は、この項目をとくに取り上げて論じていない。原因や、押しつけられたときの影響は調べられていない（結果の記述なし）。
注意点: 42 人の回答で、募集に応じた人だけが答えている。一国の調査である。回答は人ごとで、組織ごとに集計したものではない。「押しつけられる」を誰が誰にするのか（プロダクトオーナー、管理職など）は、質問からは分からない。頻度は回答者の認識で、記録や観察で確かめたものではない。
根拠: 調査（アンケート）／大規模な組織。文献: Exploring the Prevalence of Anti-patterns in the Application of Scrum in Software Development Organizations（2023）。文献の種類: 論文・研究者。位置: IV. RESULTS / E. Sprint planning（Table VI）。確認の根拠: 原典
原文: “Item estimation imposed to the team”

スプリントの長さやデイリースクラムの開催は守られていると答えた人が多い一方、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.”

出典一覧

文献	年	ライセンス	記録の数
Investigating Effort Estimation in a Large-Scale Agile ERP Transformation Program	2024	CC BY 4.0	3
Hybrid Work in Agile Software Development: Recurring Meetings	2025	CC BY 4.0	1
Interruptions in Agile Software Development Teams	2021	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	2
Tailoring Choices Made in Scrum Projects: A Systematic Literature Review	2022	CC BY 4.0	2
A teamwork effectiveness model for agile software development	2022	CC BY 4.0	2
A Theory of Scrum Team Effectiveness	2022	CC BY 4.0	2

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

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

評価コメント:

前提コンテキストに記載された観察事実や数値（事業目的から始めた7事例、見積もりの課題を挙げた5人、専門家12人の賛成、調査回答の20人・13人など）、および「効果は測られていない」「結果の記述なし」といった制約事項を極めて正確に反映しています。外部のスクラム知識や一般的な俗説による勝手な断定や捏造は一切見られず、忠実性は完璧です。 Relevanceに関しては、「チームの協業をどう引き出すか？」という実践的な問いに対し、「効果が確かめられた打ち手は見つかっていない」と前提の限界を率直に示したうえで、コンテキスト内から協業に関連する工夫（事業目的からの開始、共通理解を形成する掘り下げの場、スクラムマスターによる動機づけ支援）や逆効果（目標の欠如、見積もりの押しつけ）を的確に拾い上げています。ただし、個々の文献・事例の要約を並べる記述が中心となっており、質問に対する「示唆されるアプローチや留意点」としての構造化された整理がやや弱いため、4点と評価します。

プランニングとゴール設定で、チームの協業をどう引き出すか？

結論（TL;DR）

打ち手と事例

ニュージーランドの銀行の 3 つのアジャイルチームで、仕様の確認会やプランニング、スタンドアップが、メンバーが同じ理解を持つ助けになったと語られた ［A teamwork effectiveness model for agile software…（2022）］

スプリントプランニングは、出社日に対面で開くチームと、部門全体の遠隔の場で計画するチームに分かれた ［Hybrid Work in Agile Software Development（2025）］

スプリントプランニングを 2 回開く、事前の計画の会を足すといった変え方が挙がり、ある研究は、2 回の計画を含む変え方で全体の成功が上がったと報告していた ［Tailoring Choices Made in Scrum Projects（2022）］