固定期間のスプリントを崩さずに、チームの流速や開発量（スループット）を高めるにはどうすればよいか？

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

結論（TL;DR）

スクラムの枠組み（スプリント、レトロスペクティブなど）を維持しながら、バックログ内の進行中作業（WIP）に上限を設けてフロー原則を取り入れるアプローチ（Scrumban）が知られています。ソフトウェアとハードウェアが混在するハイブリッド開発組織の実証調査では、固定スプリントの枠組みを共有しつつ、ハードウェア側のデイリー頻度削減や週次チェックポイント、領域別のワークフロー定義によって摩擦を減らし、進捗監視やボトルネック特定を改善した事例が報告されています。また医療機器開発の事例では、ScrumからKanbanおよびSAFeへの移行によってリリース間隔が短縮されたと報告されています。 Scrum の 3 チームへの面接では、スプリントを外部の割り込みから守る場として使い、スクラムマスターが割り込みを防ぎ、静かな時間を設けていました。流速や開発量の変化は測られておらず、固定期間のスプリントを守る材料にとどまります。スタートアップ 1 社で同等の機能要求の 4 プロジェクトを比べた事例研究では、計画を毎日行うと計画者の不在で稼働時間の相当部分が使われず、2 週間のスプリントが最も安定していました。納期の遅れと不具合の数が測られていますが、WIP 制限やフロー指標は測られておらず、日次の不調には計画者の集中も影響しています。ただし、WIP上限単独の効果や、スプリントゴール達成率への定量的な影響検証は今後の課題として残されています。スプリントとフローを両立させる際は、領域ごとの開発リズムに応じた適応的な調整が重要です。

打ち手と事例

同等の機能要求の 4 プロジェクトで計画の間隔を日次・週次・2 週間に変えて比べたところ、日次は計画者の不在で稼働時間が使われず、2 週間のスプリントが最も安定した［Strategic Effectiveness of Agile Approaches（2026）］

状況: トルコ・ノルウェーの研究者による、スタートアップ 1 社の比較事例研究。5 人ずつのチーム（チームリード、バックエンド、フロントエンドかモバイル、デザイナー）が、4 つのプロジェクトを進めた。著者は、機能要求は同一（抄録と 3 章の冒頭）、あるいは同等（3.1 節）で、見積もりの技法（フィボナッチ数列のストーリーポイント 1・3・5・8）や技術の条件を揃えたと述べる。計画の間隔だけが違い、プロジェクト X は日次（毎朝チームリードが担当を割り振り、夕方に確認）、Y は週次、Z と W（モバイル）は 2 週間のスプリントだった。
やったこと: 計画と受け渡しの間隔を、1 日・1 週間・2 週間に変えた。 Y は週初めの計画会議（20 分以内）と、進捗と妨げを確かめる最長 15 分の毎日の立ち会議を開いた。Z は 2 週間のスプリントの初めに 30 分以内の計画会議を開き、スプリントゴールと作業範囲を決め、毎日の立ち会議を続けた。W も同じ 2 週間のスプリントと毎日の立ち会議である。
起きたこと: 日次の X では、チームリードが不在だった日（インフラの障害や欠勤）に計画ができず、積んであった作業だけで動いたため、計画した稼働時間の相当部分が使われなかった。図 1・2（個人 1 人分）では、計画が遅れた日や省かれた日に完了作業量が大きく落ちている。著者は Table 2 で、納期の遅れと不具合の総数を、X が 23 日・57 件、週次の Y が 8 日・32 件、2 週間のスプリントの Z が 2 日・17 件、W が 1 日・23 件と報告している。 Z は稼働時間の使われ方が最も安定し、日々の完了作業量のばらつきが最小だった。Z では、スプリントの作業が見込みより少ないとき、前のスプリントの追加の作業を引き取れ、士気と効率に寄与したとされる。著者は 2 週間のスプリントを、適応性と安定のバランスが最も良いと結論づけた。
注意点: スタートアップ 1 社の 4 プロジェクト（チームは 5 人ずつ）で、著者自身が一般化の限界を認めている。日次の不調は、計画の責任がチームリード 1 人に集中していた組織構造の影響も大きく、間隔そのものだけの効果ではないと著者は述べる。比べたのは計画の間隔で、WIP 制限やフロー指標は測っていない。スループットの数値は表になく、日ごとの完了作業量が図 1・2 で示されるだけである。図は個人 1 人分で、観察期間が短いと著者も認めている（pq-06 の「WIP 制限導入後のスプリントゴール達成率の変化」は埋まらない）。 Z と W は同じ 2 週間でも不具合が 17 件と 23 件で、W はモバイルで構成も異なる。著者が結論で示す「遅れ 65% 以上の減少」「不具合約 50〜70% の減少」は著者の計算で、週次の Y（57 件から 32 件で約 44%）は後者の範囲に入らない。
根拠: 事例研究／単一チーム。文献: Strategic Effectiveness of Agile Approaches: An Inter-Method Comparative Study（2026）。文献の種類: 論文・研究者。位置: 3.1 Case Design and Common Characteristics（Table 2）/ 3.2 Project X（Figures 1–2）/ 3.3 Project Y / 3.4 Project Z / 3.6 Comparative Findings / 5 Conclusions / 6 Limitations。確認の根拠: 原典
原文: “Project Z achieved the most consistent utilization of working hours and the least variance in daily completed work units.”

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.”

ソフトウェアとハードウェアが混在するハイブリッド組織で、スプリントのケイデンスとセレモニー頻度を領域ごとに適応させて連携した［Scrumban in Hybrid Environments（2026）］

状況: ブラジルの研究開発機関（INDT）において、ソフトウェア開発者（Scrum経験あり）とハードウェアエンジニア（アジャイル未経験）が連携する学際的ハイブリッドプロジェクト。当初は2週間の固定スプリントと標準的なScrum儀式（デイリー、プランニング、レビュー、レトロスペクティブ）をそのまま適用したが、物理部品・サプライヤー依存を抱え開発サイクルが長いハードウェア領域では一律のスプリント運用が摩擦を生んだ。
やったこと: Scrumbanを固定的なルールとしてではなく適応的な調整構造として再設計した。スプリントの全体枠組みや可視化ボードを共有しつつ、ハードウェアチームのデイリー頻度を週1〜2回に削減して情報の質を高め、両領域の代表者による週次チェックポイント（依存関係やボトルネックの特定）を設けた。また、カードの種類ごとに異なるワークフロー（ソフトウェアはレビュー・テストを含む多段階、ハードウェアは発注・検証を含む長期段階）をボード上に定義した。
起きたこと: 技術チームと管理職の双方において、領域横断のコミュニケーション、進捗監視、ボトルネックの早期発見、意思決定の迅速化などの利点が確認された。一律のスプリント強制を避け、ドメインの特性に応じて柔軟に調整することで、固定スプリントとフロー原則の両立が可能となった。
注意点: ブラジルの1研究開発機関を対象とした定性的な事例研究（アンケート15名・インタビュー3名）であり、サイクルタイムやスループットの定量的数値データは計測されていない。
根拠: 事例研究／複数チーム。文献: Scrumban in Hybrid Environments: An Empirical Investigation of Organizational Use and Impact in Development Teams（2026）。文献の種類: 論文・研究者。位置: 3.3 Scrumban Implementation and Adaptation / 4.2 RQ2 / 5.4 Lessons Learned。確認の根拠: 原典
原文: “Scrumban was not introduced as a fixed process.”

超音波機器の開発で、Scrum を Kanban に替えて SAFe を入れた後継の製品は、大きなリリースの間隔が短くなった［Integration and Implementation of Scaled Agile Framework…（2024）］

状況: 規制の厳しい医療機器（超音波診断装置）を作る事業部。製品ライフサイクルのプロセスを V モデルに当てはめて開発している。最初の製品は 2006 年に始まり、早い段階から Scrum と顧客の早期のフィードバックを使った。後継の製品は 2017 年に始まり、V モデル・製品ライフサイクルのプロセス・Scrum で進めていた。
やったこと: 後継の製品で、純粋な Scrum を Kanban に置き換えた。理由は、仕事の性質に合い、チームが機敏になって価値の流れが途切れにくくなるからだとされている。チームが増えて調整が要るようになったため、2018 年に SAFe を入れた。機能は SAFe の Kanban を流れ、状態を移る基準と、検証や文書の確認を含む状態変更のチェックリストを通る。列車の指標を集め、リリースに入れる機能を決める際の予測に使っている。
起きたこと: 最初の製品は 131 か月に大きなリリースが 5 回で、1 回あたり 26.2 か月だった。後継の製品は 93 か月に 7 回で、1 回あたり 13.3 か月だった。著者はこれを、SAFe を使わなかった最初の製品と比べて約 50% の改善としている。著者は SAFe の導入でリリースの予測のしやすさも大きく改善したとしているが、その測定値は示されていない。
注意点: 比べているのは別の製品で、同じチームの導入前後ではない。 Kanban への切り替え、SAFe の導入、製品や時期の違いが重なっていて、どれの効果かは分けられていない。仕掛かりの上限だけの効果は測っていない。測っているのはリリースの間隔で、チームのリードタイムやサイクルタイムの指標ではない。製品の評価は著者（事業部の担当者を含む）による報告である。
根拠: 事例研究／大規模な組織。文献: Integration and Implementation of Scaled Agile Framework and V-Model in the Healthcare Sector Organization（2024）。文献の種類: 論文・研究者。位置: 4.3 Application of SAFe / 5. Conclusions。確認の根拠: 原典
原文: “Acuson Sequoia had 7 major releases in the duration of 93 months (Table 2), i.e., 13.3 months per release.”

前提に反する事例

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

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

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

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

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

打ち手: 動くソフトウェアを、できるだけ短い間隔でリリースする

出典: アジャイル宣言の背後にある原則（原則 3。全文は公式ページ）
証拠: 2 件（条件付き 2）
- 条件付き（ソフトウェア開発のチーム）: 同じ要求の 4 プロジェクト（同じ組織のスタートアップ、各 5 人）で、計画の間隔を日次・週次・2 週間（2 件）に変えて比べた事例研究。Table 2 では、日次が遅れ 23 日・バグ 57、週次が 8 日・32、2 週間が 1〜2 日・17〜23 だった。極端に短い間隔（日次）は、計画者が不在の日に作業が止まるなど、かえって流れを乱すとして、「できるだけ短い間隔」の下限を限定する。一方で 2 週間は有効だったと述べ、2〜3 週間から短い側という原則の範囲そのものは覆さない。測ったのは計画・引き渡しの間隔で、リリースの間隔そのものではない。日次の不調は計画者がチームリード 1 人に集中していたことの影響も大きいと著者自身が述べる。4 プロジェクトの 1 組織の比較で、確からしさは弱い。文献: Strategic Effectiveness of Agile Approaches: An Inter-Method Comparative Study。位置: Abstract、§3.2 Project X、§3.6、§5（Table 2）。同じ文献の知見は、上の事例・知見の節にもある。
- 条件付き（ソフトウェア開発のチーム）: OSS の頻繁なリリースに関する系統的文献レビュー（2006〜2016 年の 33 本）。利点（市場投入の短縮、フィードバック、品質への集中など 9 つ）の一方で、短いリリースの課題として、新版の信頼性、技術的負債、担当者への圧力、コミュニティへの依存を挙げる。短くするほど良いとは限らず、テスト時間の短縮や再設計の後回しという代償がある、という意味で「できるだけ短い間隔」を限定する。対象は OSS（Firefox・Chrome など）で、二次研究。レビューが引く先行レビュー（本文の [18]）は、頻繁なリリースの利点と欠点を実証した研究はまだ乏しいと結論づけている。確からしさは弱い。文献: Frequent Releases in Open Source Software: A Systematic Review。位置: §5.4 Advantages and Challenges（Challenges and Issues）。

考え方: 持続可能な開発を促進し、一定のペースを維持する

出典: アジャイル宣言の背後にある原則（原則 8。全文は公式ページ）
証拠: 1 件（条件付き 1）
- 条件付き（ソフトウェア開発のチーム）: アジャイル開発チームで働く 260 人（スクラムマスター／コーチ約 48%、開発者約 29%、PO 約 18% など）への、約 6 週間隔の 2 回の質問紙調査。結果の向きは原則に沿う（支持）が、次の留保がある。自己組織的なチーム・反復の計画・インクリメント・レトロスペクティブの 4 つの実践の程度が高いほど、感情的な疲労が低かった（総合効果 γ=−0.26、p<.001）。ただし「持続可能なペース」そのものは測っておらず、疲労の低さで代えている。仕事の要求（負荷・時間の圧力・中断）を介した間接効果は −0.09（p=0.042）だがブートストラップの 95% 信頼区間は 0 をまたぎ、高業績の人事施策（HPWS）を統制すると有意でなくなる。2 回の測定で変化が見られず因果は言えない。回答は自己報告で、調査はコロナ禍の最初の半年。質問紙の研究で、1 組織の事例ではない。文献: Relationships between Agile Work Practices and Occupational Well-Being: The Role of Job Demands and Job Resources。位置: 5.2 Total Effects / 5.4 Supplemental Analyses / 6 Discussion。

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

文献	年	ライセンス	行の数
Principles behind the Agile Manifesto（規範文書）	2001	著作権あり・告知を含む全文に限り複製可	文 2
Relationships between Agile Work Practices and Occupational Well-Being: The Role of Job Demands and Job Resources	2022-01	CC BY 4.0	証拠 1
Frequent Releases in Open Source Software: A Systematic Review	2017	CC BY 4.0	証拠 1
Strategic Effectiveness of Agile Approaches: An Inter-Method Comparative Study	2026	CC BY 4.0	証拠 1

出典の文書: アジャイル宣言の背後にある原則（著作権あり・告知を含む全文に限り複製可）。見出しは本サイトによる要約で、原文ではない。

探した範囲の文献には見つからなかったこと

次のことは、この問いのために探した範囲の文献には見つかりませんでした。「研究が無い」という意味ではありません。

ScrumチームがWIP制限を導入した際のスプリントゴール達成率の変化に関する定量的比較。（探した範囲: 収集ラウンド 9 回・読んだ文献 31 本）
スプリントレトロスペクティブでフロー指標（CFDやSLE）を用いた具体的な改善プロセスの記録。（探した範囲: 収集ラウンド 9 回・読んだ文献 31 本）

出典一覧

文献	年	ライセンス	記録の数
Interruptions in Agile Software Development Teams	2021	CC BY 4.0	1
Integration and Implementation of Scaled Agile Framework and V-Model in the Healthcare Sector Organization	2024	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
Strategic Effectiveness of Agile Approaches: An Inter-Method Comparative Study	2026	CC BY 4.0	1

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

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

評価コメント:

Faithfulness（忠実性: 4点）: - 各事例の概要や注意点（「流速や開発量の変化は測られていない」「WIP制限やフロー指標は測られていない」などの限界事項）をコンテキストに沿って正確に反映できています。 - 一方で、冒頭の「バックログ内の進行中作業（WIP）に上限を設けて…」というScrumbanの一般的定義や、末尾近くの「今後の課題として残されています」といった記述は前提コンテキストに直接書かれておらず、外部知識による補完・推測が含まれています。 - Relevance（関連性・回答性: 2点）: - 質問の核心である「固定期間のスプリントを崩さずに、スループットを高めるにはどうすればよいか？」という具体的な方策（How）に対し、回答文は事例の要約と測定限界の列挙に終始しており、直接的な回答になっていません。 - 「固定期間のスプリントを崩さずに」という明確な前提があるにもかかわらず、純粋なScrumをKanbanに置き換えた（スプリントを破棄した）医療機器の事例を取り上げており、質問の前提条件と整合していません。 - 最後の結論も「領域ごとの開発リズムに応じた適応的な調整が重要」という抽象論にとどまり、それがどのようにスループットや流速の向上に結びつくのかという論理的回答が示されていません。