チームのリードタイムなどの改善が停滞している。どんな打ち手があるか？

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

結論（TL;DR）

文献にある打ち手は、流れを見えるようにして詰まっているフェーズを特定することと、同時に進める仕事を減らすことです。着手前に必要なものをそろえる仕組みや、開発前の詳細な要求調査をやめて段階的に詳しくする形も報告されています。ある会社では、詰まりを 1 か所直すと別のフェーズへ移り、マージの権限を広げて解消したうえで、選んだ指標を毎回のレトロスペクティブで見るようにしていました。待ち時間の原因は互いに依存していて、1 つを潰しても残ることがあるという整理もあります。入ってくる仕事に処理の追いつかないプロジェクトは多く、平均して積み残しも大きかったという分析もありますが、仕掛かりの制限が効く条件を確かめた研究ではありません。一方で、チームの手が届かない組織の問題が繰り返し挙がって何も変わらず、レトロスペクティブそのものが減った事例も報告されています。

打ち手と事例

詰まっているフェーズを可視化して直すと、詰まりが別のフェーズへ移った ［Measuring and Improving Agile Processes in a Small-Size…（2020）］

• 状況: 小規模なソフトウェア会社（ITTI）の製品 CONTRA のスクラムチーム。プロダクトオーナーとスクラムマスターは、チケットがプロセスの各フェーズにどれだけ留まっているかを知りたかった。
• やったこと: 課題管理ツールのデータからプロセスの指標を作り、チケットが各フェーズに留まる時間を可視化した。テストのフェーズが詰まっていると分かったので、テスターを増やした。
• 起きたこと: テスターを増やしても全部は解決せず、詰まりはマージリクエストのフェーズへ移った。コードレビューとマージができる経験豊富な開発者の時間が足りなかったためである。中堅の開発者にマージの権限を与えて解消した。
• 注意点: 介入の前後を比べた数値は示されていない。詰まりを 1 か所直すと別の場所へ移る、という経過の報告である。
• 根拠: 事例研究／単一チーム。文献: Measuring and Improving Agile Processes in a Small-Size Software Development Company（2020）。文献の種類: 論文・研究者。位置: B. Benefits and adoption of process metrics at ITTI。確認の根拠: 原典
• 原文: “the company found out that the bottleneck shifted to the ‘merge request’ phase”

選んだ指標を、毎回のレトロスペクティブで見る ［Measuring and Improving Agile Processes in a Small-Size…（2020）］

• 状況: 小規模なソフトウェア会社（ITTI）のスクラムチーム。プロセスの指標をダッシュボードで見られるようにしたあと、どの場で使うかを決める必要があった。
• やったこと: チームが選んだ指標を、毎回のレトロスペクティブで 15〜20 分かけて可視化し、分析することにした。
• 起きたこと: 指標の値と傾向は、チームの動機づけ、プロセスの改善、問題の特定と解決に使われている、と報告されている。
• 注意点: 指標を見る場と使い方の報告で、指標を見ることの効果を測ったものではない。
• 根拠: 事例研究／単一チーム。文献: Measuring and Improving Agile Processes in a Small-Size Software Development Company（2020）。文献の種類: 論文・研究者。位置: A. Process metrics in the Scrum process。確認の根拠: 原典
• 原文: “the team usually spends 15 to 20 minutes on visualizing and analysing these selected process metrics”

同時に進めるストーリーを減らし、終わったものからデモして閉じる ［Managing the requirements flow from strategy to release…（2017）］

• 状況: 大規模な通信製品を開発する組織（Ericsson）の開発チーム。2 週間のスプリントで動いていたが、スクラムのルールを厳密には守っていなかった。
• やったこと: スプリントの区切りに縛られず、同時に進めるユーザーストーリーを現実的に可能な限り少なくして、リードタイムを最小にすることを目標にした。メンバーの手が空けば、スプリントの途中でもストーリーを足した。ストーリーは準備ができた時点でプロダクトオーナーにデモして閉じ、依存するストーリーにすぐ着手できるようにした。
• 起きたこと: 結果の記述なし。 この運用だけを取り出した結果は書かれていない。
• 注意点: プロセスの記述であり、効果を確かめた報告ではない。
• 根拠: 事例研究／単一チーム。文献: Managing the requirements flow from strategy to release in large-scale agile development: a case study at Ericsson（2017）。文献の種類: 論文・研究者。位置: 5.4 Implementation management process。確認の根拠: 原典
• 原文: “The goal is to minimize the lead time by having as few user stories simultaneously in progress as is practical.”

長く繰り返された品質の問題は、テストとバグ修正に十分な労力をかけたあとで、話題に出なくなった ［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.”

サイクルタイムを測り始めたあとの 4 四半期で、全チームの平均は 34.6、20.4、23.5、14.7 営業日と推移した。ほかの介入と効果は分けられていない ［Quality culture boosts agile transformation—Action research…（2022）］

• 状況: 北欧の金融向けソフトウェア会社の事業部で、チームは 7 つあった。品質を促す介入と、チームの作業の流れの可視化が進み、チームの作業の流れが安定したあとの時期である。
• やったこと: 2020 年に、開発の開始からテストの終わりまでの平均サイクルタイムを、組織で測る指標に加えた。このほかの介入として、動きの遅い作業をレトロスペクティブで取り上げることも行っていた。
• 起きたこと: 四半期ごとの全チームの平均は、順に 34.6、20.4、23.5、14.7 営業日だった。著者は、品質が上がったことで、サイクルタイムも縮み始めたと推測している。ただし、動きの遅い作業をレトロスペクティブで取り上げる介入も並行していたので、品質の向上がどの程度効いたかは、はっきりしないと述べている。
• 注意点: 測り始めたあとの値の推移である。原文に、介入の前のサイクルタイムの値は示されていない。四半期の値は 4 点だけで、単一のチームではなく、事業部の全チームの平均である。サイクルタイムの範囲は、開発の開始からテストの終わりまでで、顧客に届くまでではない。研究者が介入したアクションリサーチで、1 つの事業部の事例である。著者の推測は検証されていない。
• 根拠: アクションリサーチ／複数チーム。文献: Quality culture boosts agile transformation—Action research in a business-to-business software business（2022）。文献の種類: 論文・研究者。位置: 3.15 Evaluation (Intervention 3)。確認の根拠: 原典
• 原文: “a reduction of cycle time was observed (all team averages per quarter in workdays: 34.6, 20.4, 23.5, and 14.7)”

品質の促進とコードレビューの強制を重ねた期間に、顧客報告の欠陥が、2018 年の平均で約 300 件から、2020 年の平均で 100 件未満に減った ［Quality culture boosts agile transformation—Action research…（2022）］

• 状況: 北欧の金融向けソフトウェア会社の事業部（開発者は約 50 人、チームは 7 つ）。アジャイルの実践を導入して約 7 年になる。主な手法はスクラムだったが、品質と収益の問題は残っていた。インタビューでは、コードレビューは行われていないという声があった。 2018 年末の粗い見積もりの数字は、コードレビューの依頼 63%、完了 48% だった。
• やったこと: 3 つの介入を重ねた。 1 つめは、四半期ごとの計画イベント（SAFe 由来）の導入、チームを事業領域ごとの編成にして安定させること、かんばんの可視化をそろえることである。 2 つめは、品質を重んじる文化を、非公式のチームの会合と 1 対 1 の対話で広めることである。かんばんの開発とテストの間に「in review」の列を足して、コードレビューを推奨した。強制にせず推奨から始めたのは、変化への抵抗を避け、先に取り入れる人から広げるためだった。 3 つめは、「すべてのコードをレビューする」を 2019 年の目標としてチームに伝え、実際にレビューされた変更の割合を毎月伝えることである。
• 起きたこと: 顧客報告の欠陥は、2018 年の平均で約 300 件だったものが、2020 年の平均で 100 件未満になった。コードレビューの実施率（変更のうち実際にレビューされた割合）は、第 3 の介入を始めてから 1 年で、75% から 88% に上がった。著者は、ポアソン分布を仮定した検定で、減少が偶然で説明できる確率は 0.0000 だったとしている。請求できない作業の時間が減ったことも、著者は観察している。著者は、チームの自己管理に任せて品質の実践に行き当たるのを待つだけでは足りず、アジャイルのチームでもコードレビューは強制する必要があるとまとめている。
• 注意点: 欠陥は、事業部全体の顧客報告の分を、四半期ごとに数えたものである。コードレビューの依頼と完了の割合（63% と 48%）は粗い見積もりで、何に対する割合かは本文に書かれていない。 2018 年の値は、介入 1 と 2 が始まった時期と重なり、介入の前の基準値ではない。平均の単位（四半期あたりか）は、原文に明示がない。 3 つの介入が重なっていて、減少のうちどれの効果かは分けられていない（最初の 2 つの介入は時期も重なっている）。研究者が介入したアクションリサーチで、1 つの事業部の事例である。著者は、ほかの要因が結果に影響したかは明確でなく、ソフトウェアプロセス改善の成熟度も測っていないので、成熟度の上昇が結果の一部を説明した可能性があるとしている。 2020 年の最後の数か月に、事業部の収益性（profitability）が記録を更新した。これについて著者は、新型コロナによる出張の減少など別の事情の可能性も認めている。スクラムが主な手法だったが、結論は「アジャイルのチーム」一般に述べている。著者は、対象がスクラムの指針を十分に守っていなかった可能性を、限界として挙げている。リードタイムなどの流れの指標ではなく、欠陥数の事例である。
• 根拠: アクションリサーチ／複数チーム。文献: Quality culture boosts agile transformation—Action research in a business-to-business software business（2022）。文献の種類: 論文・研究者。位置: 3.9 Taking action (Intervention 2) / 3.12 Diagnosis (Intervention 3) / 3.14 Taking action (Intervention 3) / 3.15 Evaluation (Intervention 3) / 3.16 Learnings (Intervention 3)。確認の根拠: 原典
• 原文: “The number of defects reduced from an average of almost 300 in 2018 to an average of under 100 in 2020”

インタビューを数えて優先する課題を選んだあと、「定義が無い」「コードレビューが無い」という声を確かめ直すと、実際とは違う面があった ［Quality culture boosts agile transformation—Action research…（2022）］

• 状況: 北欧の金融向けソフトウェア会社の事業部で、開発者は約 50 人、チームは 7 つあった。アジャイルの実践を導入して約 7 年がたっていたが、期待した効果はまだ得られていなかった。研究者が、事業部の 41 人にインタビューし、聞いた内容を 354 行に書き出して、似たものをカテゴリに分けて数えた。
• やったこと: インタビューの発言を、似たもの同士でカテゴリに分けて数え、結果を組織と事業部の経営チームで話し合った。そのうえで、事業上の必要と、理論上の成功の見込みから、優先して取り組む課題を選んだ。優先課題の一つである品質について、介入 2 の診断の中で、インタビューで挙がった「完成の定義が無い」と「コードレビューが行われていない」を、実際にそうなのかを確かめ直した。
• 起きたこと: 優先する課題には、文化と安定性、そして品質（プロセスと製品）が選ばれた。品質の 2 つの声を確かめ直すと、完成の定義は存在したが、見つけにくく、かなり無作為に守られていた。チームがそれを強制できる点も、プロセスの中になかった。コードレビューは、インタビューではほとんどの人が「行われていない」と述べた。しかし確かめると、一部の人は時々行っており、そのための道具もすでにあった。著者は、品質があまり重く扱われておらず、品質は個々の開発者の技能の問題で、組織で改善できるものとは考えられていない傾向があるとまとめている。
• 注意点: インタビューの発言は主観的で、著者自身がそう述べている。確かめ直したのは、品質に関する 2 つの声（完成の定義とコードレビュー）だけで、ほかの声を同じように確かめたとは書かれていない。確かめ直しは、介入 2 の診断の中で行われたもので、優先課題を選んだあとの作業である。優先する課題は、組織と事業部の経営チームでの議論のあとに選ばれた。選んだ主体は、原文に明示がない。研究者が介入したアクションリサーチで、1 つの事業部の事例である。
• 根拠: アクションリサーチ／複数チーム。文献: Quality culture boosts agile transformation—Action research in a business-to-business software business（2022）。文献の種類: 論文・研究者。位置: 2.4 Diagnosing / 3.1 Initial results leading to interventions / 3.7 Diagnosis (Intervention 2)。確認の根拠: 原典
• 原文: “However, checking this fact revealed that there was one, although it was hard to find and was followed quite randomly.”

クリティカルチェーンを補強した方法の中で、設計段階の同時プロジェクト数に上限を設けた ［Modern Project Management Approaches in Uncertainty…（2020）］

• 状況: 機械を設計・組立し、顧客の受入試験を経て納める事業部。各フェーズは期限と能力の制約を守る必要があり、受入試験のフェーズは顧客の都合で遅れることが多かった。
• やったこと: クリティカルチェーン・プロジェクトマネジメント（CCPM）を補強した方法を、事業部全体に入れた。補強の要素は、プロジェクトのライフサイクル、フェーズ間の区切り、着手前に必要なものをそろえる仕組み（フルキット）、カンバンによる仕掛かりの制御である。その中で、ボトルネックである設計者を基準にして、設計段階で同時に進めるプロジェクトの数に上限を設けた。
• 起きたこと: 新しい方法全体の結果として、スループットが増え、サイクルタイムが短くなったと報告されている（数値は図に示され、本文には書かれていない）。必要な設計時間は、機械の種類によって平均で 5〜10% 減った。著者が仕掛かりの上限に帰しているのは、少ない案件へ資源を集中でき、計画が短くなり、複数プロジェクトの計画が容易になったことである。遅れの兆しを早く見つけられるようになったのは、フルキットの監視による。
• 注意点: 仕掛かりの上限だけの効果を、分けて測ってはいない。上限の値を決めた手順は書かれていない。理由として、スループットと資源の使い方で適切な結果を出すためと述べられている。
• 根拠: アクションリサーチ／複数チーム。文献: Modern Project Management Approaches in Uncertainty Environments: A Comparative Study Based on Action Research（2020）。文献の種類: 論文・研究者。位置: 4.1 Case 1（本文 / Results）。確認の根拠: 原典
• 原文: “In the case of the design stage, the WIP was limited to three concurrent projects, in order to produce suitable results in terms of throughput and resource usage.”

仕掛かりを少なく保つ簡素な方法を、複数のチームに入れた ［Modern Project Management Approaches in Uncertainty…（2020）］

• 状況: プロジェクト管理の方法を 2 つの組織で試したアクションリサーチの、2 つ目の組織。建設業向けの部品を設計・製造する企業の研究開発部門で、複数の製品チームが対象だった。遅れが主な問題で、チームの多くは若く、プロジェクト管理の経験が乏しかった。
• やったこと: 優先順位を守ることと、仕掛かりを少なく保つことを軸にした簡素な方法を入れた。情報の管理にはスプレッドシートの道具を作り、使い方を訓練した。着手前に必要なものをそろえる仕組みに主要なステークホルダーを入れ、目的と受け入れ基準を一緒に決める責任を持たせた。
• 起きたこと: 新しい方法で一定期間働いたあとのインタビューで、マネージャー・チームリーダー・メンバーの全員が肯定的に評価した。仕掛かりの削減、優先順位付け、リソースの集中の組み合わせで、リソースの管理がしやすくなり、プロジェクトの速度と生産性が上がったと述べた。ほぼ全てのサブプロジェクトが、計画どおりか計画以上に進んでいた。 1 つのチームは、毎週の共有のフォローアップを他より進めて実施した。
• 注意点: 着手前に必要なものをそろえる仕組みは、メンバーがマネージャーほど評価しなかった。訓練のあとも、リーダーには追加の支援が必要で、細かく計画しすぎる傾向が繰り返し見られた。道具の限界が、情報の管理と伝達を難しくした。新しい方法は手間が増えると、マネージャーも認めている。評価は主にインタビューと研究者の観察による。
• 根拠: アクションリサーチ／複数チーム。文献: Modern Project Management Approaches in Uncertainty Environments: A Comparative Study Based on Action Research（2020）。文献の種類: 論文・研究者。位置: 4.2 Case 2 / 4.2.1 Adaptation of the Methodology to Case 2 / 4.2.2 Results。確認の根拠: 原典
• 原文: “They also highlighted the positive effect of combining WIP reduction, prioritization of activities, and the concentration of resources”

段階ゲート型の製品開発にタスクボードとスプリント計画を重ね、遅れを見つけやすくなったが、委員会の決定を待つ遅れが残った ［The interrelationship between the agile approach and project…（2026）］

• 状況: 機械製品を作る大手の製造会社の、製品開発プロジェクト。競争が厳しく、開発の終盤の遅れは損失が大きいので、遅れを減らし、リードタイムを縮めたいと考えていた。従来のステージゲート型のプロセスは残したまま、その上に別の進め方を重ねた。運営委員会が、重要な節目で優先順位と資源の割り当てを決める。
• やったこと: 従来のプロセスの上に、アジャイルな進め方を重ねた。プロジェクト、部門、プロジェクトのポートフォリオの各層で、タスクボード、パルスミーティング、スプリント単位の計画、定期のデモとレトロスペクティブを使った。
• 起きたこと: 著者は、インタビューと文書の分析から、タスクボードが活動の遅れを見つけたり予測したりする道具になり、課題への対処や議論を早く始められたとしている。スプリント計画では、プロジェクト全体より短い期間のほうが、工数や依存関係を見積もりやすかった。一方で、運営委員会があまり開かれないため、計画の見直しが要る問題では、チームは決まった決定の機会まで待たなければならず、意思決定が遅れた。リードタイムが実際に短くなったかどうかは、報告されていない。
• 注意点: インタビューと社内文書にもとづく評価で、リードタイムなどの数値の変化は示されていない。従来のプロセスの規則や、国際的な品質規格に合わせた手順が、反復的な進め方を制約している。チームの意思決定の自律性は、運営委員会の権限で限られていた。対象は、ある会社の製品開発の事例である。
• 根拠: 事例研究／大規模な組織。文献: The interrelationship between the agile approach and project complexity in product development（2026）。文献の種類: 論文・研究者。位置: 6.4 The agile approach and development complexity / 6.5 The agile approach and organizational complexity。確認の根拠: 原典
• 原文: “task boards functioned as tools for identifying or predicting work delays, thereby supporting and streamlining the flow of activities”

超音波機器の開発で、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.”

開発前の詳細な要求調査をやめ、段階的に詳しくする形に置き換えた ［Managing the requirements flow from strategy to release…（2017）］

• 状況: 大規模な通信製品を開発する組織（Ericsson）。以前は、長いリリースごとに最初の数か月で計画を固めていた。その時期を逃した要求は、次のリリースまで待つことになった。
• やったこと: 開発の前に行う詳細な要求の調査をやめ、要求の情報を段階的に詳しくしていくプロセスに置き換えた。次のリリースで確実に出せる範囲（最小限の市場性を持つフィーチャー）という考え方も入れた。
• 起きたこと: リードタイムは、最短 2 年から最短数か月に短くなったと認識されている。市場の変化に応じて開発の重点を変えられるようになり、採算の合わない要求を早い段階で捨てられるようになった。
• 注意点: 結果は、組織のメンバーの認識にもとづく。効果の大きさを測る定量的な研究が今後必要だと、著者自身が書いている。開発者には、要求とシステム全体を理解するための学習の負担が生じた。
• 根拠: 事例研究／大規模な組織。文献: Managing the requirements flow from strategy to release in large-scale agile development: a case study at Ericsson（2017）。文献の種類: 論文・研究者。位置: 6.2 RQ2: What are the perceived benefits of the requirements management processes?。確認の根拠: 原典
• 原文: “This had drastically reduced the lead time from a minimum of two years to a minimum of a few months.”

前提に反する事例

見積もりの精度に是正策を重ねても、データの上では精度が上がらなかった ［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”

レトロスペクティブを減らした主因は、チームの手が届かない問題の議論が繰り返されたことだった ［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”

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

スクラムマスターの成功したリーダーシップは、エンパワーリングとメンバー支援、良好な人間関係にあり、チームの自己管理と知識管理に密接に結びついている ［Selbstorganisiert und dennoch geführt（2024）］

• 状況: ソフトウェア開発において広く用いられるスクラムでは、チームは自己管理（Self-Managing）、スクラムマスターはサーバントリーダーとされるが、実務におけるスクラムマスターのリーダーシップ行動には大きなばらつきがあった。
• やったこと: スクラムチームのメンバー11名に対するガイド付き専門家インタビューを実施し、質的内容分析を用いて成功するリーダーシップ行動と前提条件のプロセスモデルを構築した。
• 起きたこと: 成功するリーダーシップ行動は、エンパワーリング・リーダーシップ（Empowering Leadership）、チームメンバーへの支援、および良好な人間関係によって特徴づけられることが示された。エンパワーリングを超える純粋なサーバント・リーダーシップ概念は下位の役割にとどまり、技術的・組織的・コミュニケーション能力が不可欠な前提条件であった。リーダーシップの成功は、チームの自己管理と知識管理と密接に結びついていた。
• 注意点: ドイツ語圏を中心とする11名の専門家インタビューに基づく質的探索研究であり、プロセスモデルの定量的検証は今後の課題とされている。
• 根拠: 事例研究／複数チーム。文献: Selbstorganisiert und dennoch geführt – eine explorative Studie zur Führung durch Scrum Master（2024）。文献の種類: 論文・研究者。位置: Zusammenfassung (GIO, 2024)。確認の根拠: 原典
• 原文: “Das Prozessmodell stellt dar, dass erfolgreiches Führungsverhalten von Scrum Mastern durch Empowering Leadership, die Unterstützung der Teammitglieder und gute Beziehungen zu den Teammitgliedern gekennzeichnet ist. Konzepte von Servant Leadership, die über Empowering hinausgehen, spielen nur eine untergeordnete Rolle für den Führungserfolg. Eine wichtige Voraussetzung für erfolgreiche Führung ist die technische, organisatorische und kommunikative Kompetenz der Scrum Master. Der Führungserfolg ist zudem mit der Selbstorganisation des Teams und dem Wissensmanagement im Team eng verknüpft.”

チームのレトロスペクティブの是正策は、協力や優先順位の問題にはほとんど出なかった ［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”

最初の介入のあと離職の問題が減った。作業の流れの可視化が先にあったから、コードレビューの実践を広げやすかったと著者は述べている ［Quality culture boosts agile transformation—Action research…（2022）］

• 状況: 北欧の金融向けソフトウェア会社の事業部で、チームは 7 つあった。インタビューでは、次の声が出ていた。人があちこちのチームへ動かされている。仕事の文脈が分からない。チームの安定が足りない。著者は、チームが 7 つあることで、アジャイルのスケールがうまくいっていないと考えた。
• やったこと: 最初の介入として、四半期ごとの計画イベントを入れ、チームを事業領域ごとの編成にして安定させ、かんばんの可視化をそろえた。チーム編成の変更は、最初の 3 か月が終わってから始めた。
• 起きたこと: 離職の問題が減り、調査の期間を通じて、会社の平均より少ない水準にとどまった。インタビューでは、満足度が上がり、チームの安定がおおむね保たれて、チームの結びつきが強まったと語られた。仕事の文脈が分からないという不満も減った。著者は、主な学びとして、チームを比較的安定させ、作業の流れの可視化を確実にしておくこと、四半期の計画のような追加のプロセスでチーム間の情報共有の仕組みを設けることを挙げている。また、チームの作業の流れの可視化が先にできていなければ、あとのコードレビューの実践を、あれほど容易に広げることはできなかっただろうと述べている。
• 注意点: 計画イベントの導入、チーム編成の変更、かんばんの可視化の統一が重なり、どれの効果かは分けられていない。チーム編成の変更は、最初の 3 か月のあとに加えた。かんばんの統一の時期は、原文に明示がない。離職が会社の平均より少なかったとあるが、離職の測り方は原文に書かれていない。満足度が上がったことは、インタビューで語られたことにもとづく。あとのコードレビューの実践が広がりやすかったと原文が述べているのは、作業の流れの可視化についてで、チームの安定については述べていない。著者は、結果は予測どおりだったが、予想よりずっと遅く起きたとしている。チーム編成は、フィーチャーチームではなく、事業領域の専門性にもとづくものだった。著者は、事業領域の複雑さと製品の大きさが関係している可能性があるとしている。四半期の計画イベントは SAFe 由来である。研究者が介入したアクションリサーチで、1 つの事業部の事例である。
• 根拠: アクションリサーチ／複数チーム。文献: Quality culture boosts agile transformation—Action research in a business-to-business software business（2022）。文献の種類: 論文・研究者。位置: 3.2 Diagnosis (intervention 1) / 3.4 Taking action (Intervention 1) / 3.5 Evaluation (Intervention 1) / 3.6 Learnings (Intervention 1) / 3.11 Learnings (Intervention 2)。確認の根拠: 原典
• 原文: “it is important to keep the teams fairly stable and ensure that there is a visualization of the workflow”

スクラムチームの有効性には、従来の認知的・構造的調整に加え、4つの感情的要因（感情知能・対人スキル・紛争解決・心理的安全性）の組み込みが実務者から有用と評価された ［STEM-EF（2026）］

• 状況: スクラムを採用するソフトウェア開発のチームにおいて、有効性モデルはコミュニケーションや調整、共有リーダーシップなどの行動・構造的側面に偏り、感情のダイナミクスが見落とされていた。
• やったこと: 感情知能（EI）、対人スキル（IS）、紛争解決（CR）、心理的安全性（PS）の4つの感情的要因を、スクラムのイベント・役割・作成物に組み込んだチーム有効性測定モデル（STEM-EF）を開発した。スクラム専門家11名、チームメンバー56名、心理学者2名へのインタビュー、フォーカスグループ、調査を通じて妥当性を検証した。
• 起きたこと: 専門家評価において高い内容妥当性（S-CVIが関連性1.00、一貫性1.00、簡潔性0.99）が示され、技術受容モデル（TAM）の評価でも有用性と採用意向に関して良好な評価が得られた。著者は、チーム改善やパフォーマンスに影響を与える感情的ダイナミクスを構造的に評価・支援する手段になると結論づけている。
• 注意点: モデルの設計および内容妥当性・受容性（TAM）の評価を中心とする混合研究であり、介入の前後でチームのベロシティやリードタイム等の客観的成果指標が定量的に向上したかを長期追跡・比較した実証ではない。
• 根拠: 調査（アンケート）／複数チーム。文献: STEM-EF: A Scrum Teamwork Effectiveness Model Based on Emotional Factors（2026）。文献の種類: 論文・研究者。位置: Abstract / Method / Results (ICSE 2026)。確認の根拠: 原典
• 原文: “Existing models focus on behavioral and structural dimensions such as communication, coordination, and shared leadership, but largely overlook emotional dynamics. … STEM-EF demonstrated high content validity across relevance, coherence, and simplicity (S-CVI-Relevance = 1.00, S-CVI-Coherence = 1.00, S-CVI-Simplicity = 0.99). TAM results indicated favorable perceptions of usefulness and intention to adopt the instrument.”

待ち時間の原因は互いに依存していて、1 つだけ潰しても残ることがある ［Data-Driven Identification and Analysis of Waiting Times…（2024）］

• 状況: 業務プロセスの待ち時間を、データから特定して分析する手法についての体系的な文献レビュー。ソフトウェア開発に限らない、プロセス一般の研究である。
• やったこと: 介入ではなく、既存の研究の整理である。
• 起きたこと: 記録から分かる待ち時間の原因は 4 種類に整理される。リソースの取り合い、リソースの不在、優先順位付け、まとめ処理である。既存の手法は原因を 1 つずつ切り離して見るが、原因どうしは依存している。たとえば人を増やして取り合いを減らしても、同じプロセスに週 1 回のまとめ処理が残っていれば、待ち時間は残る。
• 注意点: 分析の結果を具体的な打ち手に結びつける提言が既存の研究に欠けている、と著者は指摘している。開発チームでの検証ではない。
• 根拠: 文献レビュー／大規模な組織。文献: Data-Driven Identification and Analysis of Waiting Times in Business Processes（2024）。文献の種類: 論文・研究者。位置: 4.3 Sources of waiting time / 5.1.2 Need for multi-causal analysis approaches。確認の根拠: 原典
• 原文: “there are clear dependencies between the different sources of waiting time in a process”

入ってくる仕事に処理が追いつかないプロジェクトが多く、平均して積み残しが大きかった ［A Novel Technique to Assess Agile Systems for Stability（2023）］

• 状況: 公開されている課題管理ツール（Jira）のデータを、待ち行列理論の「安定」の考え方で分析した研究。複数の組織の多数のプロジェクトを対象にした。入ってくる速さに対する処理の速さの比を、安定度の指標として定義している。著者は、仕掛かりの数と滞留時間の関係（リトルの法則）が、安定した待ち行列を前提にすると位置づけている。
• やったこと: 介入ではなく、データの分析である。
• 起きたこと: 926 件の Jira プロジェクトのうち、安定度の指標が 1 未満（入ってくる仕事に処理が追いつかない）だったのは 72.89%（675 件）だった。指標が 1 を超えたのは 24.92%（231 件）、ちょうど 1 だったのは 2.16%（20 件）だった。未解決の仕事の数の平均は、指標が 1 未満のプロジェクトで 455.39 件、1 を超えたプロジェクトで 126.55 件、ちょうど 1 のプロジェクトで 80.25 件だった。積み残しの平均が最も小さかったのは、指標がちょうど 1 のプロジェクトだった。著者は、処理が追いつかない状態を、定義上、積み残しが増え続ける状態だとしている。
• 注意点: この指標で仕掛かりの制限が有効かを判断する使い方は、著者が今後の応用の可能性として挙げたもので、研究はまだ途中だとしている。抄録の積み残しの比較は、表の平均と合わない。記録は表の値を書いた。対象のプロジェクトがスクラムやカンバンを使っていたかは、確実には分からない。プロジェクト全体の平均で見ており、時間による変化を見ていない可能性がある。課題の作成と解決の記録が正確だと仮定している。積み残しの大きさと安定度の因果関係は、実際のチームでの検証が要ると著者は述べている。実際のチームに介入した研究ではない。
• 根拠: データ分析／大規模な組織。文献: A Novel Technique to Assess Agile Systems for Stability（2023）。文献の種類: 論文・研究者。位置: 4.1 Stability of JPs / 4.2 Stability and Backlog Size / 5 Discussion / 5.1 Potential Application of this Metric / 6 Limitations。確認の根拠: 原典
• 原文: “Our results show that there is a discrepancy between the assumed stability of Agile systems and the reality of how systems operate in practice”

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

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

打ち手: チームが定期的に振り返り、自分たちのやり方を調整する

• 出典: アジャイル宣言の背後にある原則（原則 12。全文は公式ページ）
• 証拠: 2 件（条件付き 2）
  • 条件付き（ソフトウェア開発のチーム）: 分散した大きなアジャイル組織の 37 回のチームレベルのレトロスペクティブを約 3 年追った縦断的な事例研究（1 組織）。チームは自分たちで変えられる話題（作業のやり方・情報の共有・見積り）には改善策を作ったが、協力・優先順位・既存の製品など、外部の支援や経営の判断が要る話題には、否定的な発言が多くても改善策がほとんど出なかった。定期的に振り返って自分たちのやり方を調整することは、チームが制御できる範囲では機能するが、その外の問題は支援なしには動かない。 文献: Recurring opinions or productive improvements—what agile teams actually discuss in retrospectives。位置: 4.2.2 / 4.2.3 Reflections / 5.1 Implications (Table 12)。同じ文献の知見は、上の事例・知見の節にもある。
  • 条件付き（ソフトウェア開発のチーム）: 3 社 6 つのスクラムチームでのアクションリサーチ（レトロスペクティブのゲームを導入）。著者の観察では、継続的な改善はインスペクト・アンド・アダプトとふりかえりが中心の概念でも実現しにくく、6 チーム中 5 チームでスクラムの実施が枠組みからずれ、その陰に組織の機能不全が隠れていた。レトロの頻度を減らした主な理由は、会議の進め方ではなく、チームが制御できない問題（プロダクトオーナーが捕まらない、チーム間の連絡不足など）の議論が繰り返されて生産的でなかったこと。観察は著者の判断。参加チームは「レトロに共通の問題を抱えたチーム」として選ばれた 6 チームの標本で、5/6 はその標本での数字（§6.4）。 文献: Game-based Sprint retrospectives: multiple action research。位置: 5.5.8 Lesson 8。同じ文献の知見は、上の事例・知見の節にもある。

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

文献	年	ライセンス	行の数
Principles behind the Agile Manifesto（規範文書）	2001	著作権あり・告知を含む全文に限り複製可	文 1
Game-based Sprint retrospectives: multiple action research	2021	CC BY 4.0	証拠 1
Recurring opinions or productive improvements—what agile teams actually discuss in retrospectives	2016	CC BY 4.0	証拠 1

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

出典一覧

文献	年	ライセンス	記録の数
The interrelationship between the agile approach and project complexity in product development	2026	CC BY 4.0	1
A Novel Technique to Assess Agile Systems for Stability	2023	CC BY 4.0	1
Data-Driven Identification and Analysis of Waiting Times in Business Processes	2024	CC BY 4.0	1
Game-based Sprint retrospectives: multiple action research	2021	CC BY 4.0	1
Measuring and Improving Agile Processes in a Small-Size Software Development Company	2020	CC BY 4.0	2
Modern Project Management Approaches in Uncertainty Environments: A Comparative Study Based on Action Research	2020	CC BY 4.0	2
Quality culture boosts agile transformation—Action research in a business-to-business software business	2022	CC BY 4.0	4
Recurring opinions or productive improvements—what agile teams actually discuss in retrospectives	2016	CC BY 4.0	3
Managing the requirements flow from strategy to release in large-scale agile development: a case study at Ericsson	2017	CC BY 4.0	2
Integration and Implementation of Scaled Agile Framework and V-Model in the Healthcare Sector Organization	2024	CC BY 4.0	1
Selbstorganisiert und dennoch geführt – eine explorative Studie zur Führung durch Scrum Master	2024	CC BY 4.0	1
STEM-EF: A Scrum Teamwork Effectiveness Model Based on Emotional Factors	2026	CC BY 4.0	1

---

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

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

評価コメント:

• 回答文は前提コンテキストにある内容を正確に反映しており、勝手な断定や俗説は見られません。ただし、Relevanceに関しては、入ってくる仕事に処理が追いつかないプロジェクトが多く、平均して積み残しが大きかったという分析や、チームの手が届かない組織の問題が繰り返し挙がって何も変わらず、レトロスペクティブそのものが減った事例など、改善停滞の原因に触れている部分はありますが、具体的な打ち手としての詳細な提案や、これらの事例が直接リードタイム改善にどのようにつながるかについての説明が不足しています。

---

関連する用語

• サイクルタイム
• 進行中の作業 (WIP)
• スプリントレトロスペクティブ