いまのやり方がスクラムに合わないと感じたとき、他の進め方に替えるかどうかを、どう考えるか？

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

結論（TL;DR）

他の進め方に替えるかどうかを決める基準を比べた文献は、取り込み済みの範囲では見つかっていません。読めたのは、Scrum から XP に切り替えた事例 1 件と、進め方を割り当てて比べた研究 1 件で、どちらも 1 つの会社の 2 チームか、1 つの製品を作った 4 グループの報告です。替えると何が良くなるかの因果は言えません。

事例では、ブラジルの金融系の 2 チームが、会社が新しく入れた進め方に合わせて Scrum から XP に切り替えました。ペアプログラミングと TDD を使い、儀式の呼び名を「スプリント」から「反復」に変え、計画を必要なら複数回に分け、ステークホルダーを入れた週ごとの会を足しています。メンバーは、コードの質が上がる、新しいエンジニアの学びが早まると述べ、論文は、儀式のテンポを XP に合わせたことが関わりを高めると主張しています。ただし上からの導入で、Scrum の不都合を感じての切り替えではありません。ユーザー中心設計とリーンスタートアップの導入と同時で、聞き取った受け止めだけで測った数値はありません。

比較の研究では、修士学生 4 グループが同じ Android アプリを別々の進め方で作りました。全体の工数は、Scrum+Kanban が 318 時間、XP が 391.5 時間、Scrum が 488 時間で、進め方を決めなかったグループは 1116 時間でした。ただし進め方は割り当てられ、各進め方は 1 グループずつです。差が進め方によるのか、グループや要求の分け方によるのかは切り分けられておらず、著者は Scrum の多さを要求の横割りの分け方と推測しています。

自分たちで「合わない」と感じて替えた事例、替える前と後を測って比べた報告、替えずに Scrum の枠の中で直した場合との比較は、この範囲では確かめられていません。改善が頭打ちになったときの打ち手は別の問い、スプリントを崩さずに流速を上げる打ち手は別の問いで扱っています。

打ち手と事例

ブラジルの金融系の 2 チームが、導入された新しい進め方に合わせて Scrum から XP に切り替え、ペアプログラミングと TDD を使い、儀式の名前と回数も XP のテンポに合わせた［Combining User-Centered Design and Lean Startup with Agile…（2020）］

状況: 7,000 人以上が働く多国籍企業の社内向けソフトウェア製品を作る、ブラジルの金融分野の 2 チーム（各チームはプロダクトマネージャー 2 人、プロダクトデザイナー 1 人、ソフトウェアエンジニア 4 人）。会社は 2015 年に Scrum を主なアジャイルの枠組みとして導入していたが、ユーザー中心設計とリーンスタートアップを組み合わせた新しい進め方に変えることを決め、外部のコンサルティング会社の方法を取り入れた。その方法が XP を前提にしていたため、チームは Scrum をやめて XP に切り替えた。論文は 2 チームを 6 か月観察し、半構造化インタビュー、日々の観察、フォーカスグループで聞き取った。
やったこと: Scrum から XP に切り替え、ペアプログラミング、TDD、ユニットテスト、継続的デリバリーを使った。儀式は、スタンドアップ、レトロスペクティブ、計画を続けながら、「スプリント」という呼び名を「反復（イテレーション）」に変えた。計画は必要なら 1 回にまとめず、反復の前の打ち合わせなどに分けるようにし、オフィスでのスタンドアップと、ステークホルダーを入れた週ごとの会を足した。
起きたこと: 一方のチームのメンバーは、Scrum から XP への切り替えは適していたと受け止め、ペアプログラミング、TDD、ユニットテストが開発を進め、コードの質を上げると述べた。もう一方のチームは、ペアプログラミングが新しいエンジニアの学びを早めると述べた。論文は、儀式のテンポを XP に合わせたことが、チームのメンバーとステークホルダーの関わりを高めると主張し、チームの目から見て新しい進め方の導入は成功したとまとめている。いずれも聞き取った本人たちの受け止めで、数値で測った結果は書かれていない。
注意点: 体感の報告で数値は無い。聞き取った人の受け止めだけで、切り替えの前後を測った比較は無い。上からの導入であり、Scrum の不都合を感じての切り替えではない。XP は会社が導入した新しい進め方（外部コンサルタントの方法）に付いてきたもので、論文自身が上からの変更だったと書いている。ユーザー中心設計とリーンスタートアップの導入と同時に起きたため、結果のうち XP への切り替えの寄与は切り分けられない。 2 チームとも、すでにアジャイルに慣れていたとされ、1 社の社内向け製品の事例である。この事例は、Scrum が合わないと感じたときの選び方ではなく、切り替えたあとの運用（儀式の呼び名と回数）の一例である。
根拠: 事例研究／単一チーム。文献: Combining User-Centered Design and Lean Startup with Agile Software Development: A Case Study of Two Agile Teams（2020）。文献の種類: 論文・研究者。位置: §3.2 Methodological aspects — XP to Boost Code Quality / team rhythm。確認の根拠: 原典
原文: “We continued doing the standup meeting, retrospective, and planning. However, we now have an office standup to be more connected to other teams - also, the ceremony nomenclature change from sprint to iteration.”

前提に反する事例

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

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

同じ製品を 4 グループの修士学生が別々の進め方（Scrum+Kanban、XP、Scrum、決まった進め方なし）で作った比較で、Scrum+Kanban の工数が最も少なく、Scrum は XP より多かった［Comparing Requirements Decomposition Within the Scrum, Scrum…（2017）］

状況: イタリアとフィンランドの 2 大学の修士学生 4 グループ（Scrum+Kanban 5 人、Scrum 5 人、XP 4 人、決まった進め方なしの 6 人）が、起業家（ソフトウェアの経験が無いデザイナー）をプロダクトオーナー役にして、同じ Android アプリ（13 の要求）を作った。要求の出し方と時期は 4 グループで揃え、全グループが 2 週間の反復で、最低 250 時間を使うことが求められた。学生は無作為に割り当てられ、進め方も学生が選ぶのでなく割り当てられた。
やったこと: グループごとに、Scrum（2 週間のスプリント）、Scrum+Kanban、XP（テストを先に書く）、決まった進め方なし（論文は「バナナ」と呼ぶ）のどれかで開発した。 3 つのアジャイルのグループは、要求を機能の縦割り（動く単位）でユーザーストーリーに分け、決まった進め方なしのグループはユーザーストーリーでなくタスクに分けた。
起きたこと: 4 グループとも、要求を欠かさず実装した。開発全体の工数は、Scrum+Kanban が 318 時間、XP が 391.5 時間、Scrum が 488 時間、決まった進め方なしが 1116 時間だった。決まった進め方なしのグループは、Scrum+Kanban の約 3.5 倍の工数がかかった。著者は、Scrum のグループの工数が他のアジャイルより多かったのは、層や作業の種類で要求を分ける横割りの分け方を多く使ったためではないかと推測している。
注意点: 学生 4 グループが 1 つの製品を作った比較で、各進め方につき 1 グループだけである。繰り返しも統計的な検定も無く、人数もグループで違う（4〜6 人）。進め方は割り当てられたもので、Scrum が合わないと感じたチームが他の進め方に移った事例ではない。割り当てられた 1 グループずつの比較で、原因は切り分けられていない。工数の差が進め方によるのか、グループの力量や要求の分け方によるのかは切り分けられておらず、著者は Scrum の工数の多さを分け方のせいと推測している（検証はしていない）。本文は Scrum の工数を 478 時間と書くが、表の合計は 488 時間で、ユーザーストーリー以外の作業 10 時間を含む。ここでは表の合計を使った。論文の主題は要求の分け方で、進め方の選び方を調べたものではない。
根拠: 事例研究／複数チーム。文献: Comparing Requirements Decomposition Within the Scrum, Scrum with Kanban, XP, and Banana Development Processes（2017）。文献の種類: 論文・研究者。位置: §4 Study Results — Table 1 (M4) and the following paragraph。確認の根拠: 原典
原文: “Taking into account the required effort, the team developing with Scrum with Kanban was the most efficient one, spending a total of 318 h on development.”

出典一覧

文献	年	ライセンス	記録の数
Combining User-Centered Design and Lean Startup with Agile Software Development: A Case Study of Two Agile Teams	2020	CC BY 4.0	1
Comparing Requirements Decomposition Within the Scrum, Scrum with Kanban, XP, and Banana Development Processes	2017	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点。前提コンテキストの内容（ブラジルの金融2チームにおけるXP切り替え事例、大学院生4グループによる工数比較研究）および双方の注意点（因果関係の切り分け不能、数値データの欠如、上からの導入、サンプルサイズや割り当ての制約など）を極めて正確に反映しています。独自の俗説やコンテキスト外の勝手な断定・推測の混入は見られません（末尾の「別の問いで扱っています」というメタ言及はありますが、コンテキストの事実関係を歪めるものではありません）。 - Relevance（適合性）: 4点。質問「どう考えるか？」に対し、冒頭で「判断基準を比べた文献は見つかっていない」と結論づけ、提示された事例が「合わないと感じて自発的に切り替えたケースではない」という限界を明確に示している点は論点に即しています。ただし、回答の大半が2件の研究内容・注意点の詳細要約に割かれており、質問の核心である「判断の枠組みや思考のステップ」への直接的な示唆・考察という観点からは、文献の不在報告にとどまる消極的な回答となっています。