チームの課題やボトルネックを発見するために、どのような指標・データを取って活用すべきか？
実践者の問い（pq-05）。取り込み済みの文献のうち 5 本から拾った 5 件の事例と知見にもとづく。ここに無い打ち手が存在しないという意味ではない。
結論（TL;DR）
Section titled “結論（TL;DR）”どの指標を取ればボトルネックを見つけられるかを直接比べた研究は見つかっていませんが、このページの事例と知見で手がかりになったデータは、ボードの日次の更新と累積フロー図（CFD）に表れる作業の分布、WIP 制限の試行で見えた作業の止まり方、入ってくる仕事の速さに対する処理の速さの比（安定度の指標）の 3 つです。取り込み済みの事例研究では、Jiraボードの日次更新と累積フロー図（CFD）の分析を取り入れ、締切直前の突発的な一括作業を抑えて開発作業の平準化を進めたことが報告されています。ただし、この事例では作業総数そのものが急増したわけではなく、また厳格なWIP上限による直接的なサイクルタイム短縮効果の数値計測は行われていません。ソフトウェア開発の Kanban の実証研究を統合したレビューでは、確信度の高い便益として作業の見える化や作業の流れが挙げられ、作業の流れは流れの妨げの発見と結びつけて整理されています（一次研究のほとんどは観察研究です）。また 1 チームの事例では、WIP 制限が低すぎると作業が頻繁に止まり、上げすぎるとコードレビューの効率に響いたため、数週間の試行で合う値を見つけたと報告されていますが、値や止まり方を見たデータは示されていません。ソフトウェア以外の領域では、機械メーカーの設計部門が、制約となる資源（機械設計の技術者）の容量から仕掛かりの上限を決め、案件の同時進行を 3 件に絞った事例があります。ただし作業の止まり方のデータから値を決めたものではなく、効果の数値は図にしか無く、著者も結果は初期的と述べています。さらに 926 件の Jira プロジェクトを待ち行列理論の安定度指標で分析した研究では、72.89%（675件）が入ってくる仕事に処理が追いつかない「不安定」な状態にあり、未解決タスクの平均が限界安定なプロジェクトの 5 倍超（455件 vs 80件）に肥大化していたことが示されています。リトルの法則やWIP制限が機能するにはシステムが安定していることが前提であり、流入率と処理能力のバランスを客観的に捉える重要性が示唆されています。
打ち手と事例
Section titled “打ち手と事例”Kanban を入れたチームで、WIP 制限が低すぎると作業が頻繁に止まり、大きく上げるとコードレビューの効率に響き、数週間の試行で合う値を見つけた ［Impact of the Kanban Maturity Model on a Team’s Agile…（2024）］
Section titled “Kanban を入れたチームで、WIP 制限が低すぎると作業が頻繁に止まり、大きく上げるとコードレビューの効率に響き、数週間の試行で合う値を見つけた ［Impact of the Kanban Maturity Model on a Team’s Agile…（2024）］”- 状況: Scrum が定着しなかった開発者 6 人のチーム（ポーランドの中規模の企業）が、Kanban Maturity Model の順に Kanban の実践を入れていた。著者は、変革の中での主な難しさは、合う WIP 制限を決めることだったと述べている。
- やったこと: WIP 制限を設け（表 1 では 4 月に個人と 1 人あたりの制限、5 月にチームの制限を入れた。どの制限の値を調整したかは書かれていない）、数週間、値を変えて試した。同じ時期に、止まった作業の見える化と、止まっている課題の管理も入れている（表 1）。
- 起きたこと: 最初は低い制限のために、作業が頻繁に止まった。制限をずっと高くしても解消せず、コードレビューの効率に影響した。数週間の試行の後、作業が滑らかに流れる制限の値を見つけたと述べられている。
- 注意点: 制限の値も、止まった件数も示されていない。止まり方をどの指標やデータで見たかも書かれておらず、この悩みの問い（どの指標・データを取るか）には、止まりを手がかりに WIP 制限を見直したという弱い手がかりにとどまる。著者の観察の記述で、測定の結果ではない。 1 チームの事例で、研究者が実践に関与していた。他の多数の実践と同時に入っていて、WIP 制限だけの効果は分けられない。
- 根拠: 事例研究／単一チーム。文献: Impact of the Kanban Maturity Model on a Team’s Agile Transformation: Tripling Throughput and Elevating Quality in Three Months（2024）。文献の種類: 論文・研究者。位置: 3 Results and Discussion（論文集の p.110）。確認の根拠: 原典
- 原文: “Initially, low limits caused frequent task blockages.”
Jiraボードと累積フロー図（CFD）の導入により、突発的な一括作業が減り開発の平準化が進んだ ［Can FOSS projects benefit from integrating Kanban（2017）］
Section titled “Jiraボードと累積フロー図（CFD）の導入により、突発的な一括作業が減り開発の平準化が進んだ ［Can FOSS projects benefit from integrating Kanban（2017）］”- 状況: Kanbanコーチング導入前のチームは、締切直前の突発的な一括作業（binge-worked）や、Jiraボードを不規則に更新しており、進行中の作業の流れが不透明だった。
- やったこと: Kanbanコーチングを行い、日次のボード更新と累積フロー図（CFD）の分析を取り入れて作業の可視化を進めた。
- 起きたこと: CFDとボードの分析の結果、完了した課題の総数自体は急増しなかったものの、作業の分布が以前よりも平準化された。突発的な一括作業が抑制され、定期的な更新サイクルが定着した。
- 注意点: WIP上限を厳格に課したことによる直接のサイクルタイム短縮効果の数値計測は行われておらず、主に可視化と平準化の定性的報告である。
- 根拠: アクションリサーチ／単一チーム。文献: Can FOSS projects benefit from integrating Kanban: a case study（2017）。文献の種類: 論文・研究者。位置: 5.4.2 Evaluating and specified learning / Jira Board and CFD。確認の根拠: 原典
- 原文: “The analysis of the Jira board and CFD (see Additional file 1) showed, that the team was not developing more issues than before, only the distribution was a bit more evenly.”
機械メーカーの設計部門が、制約となる資源（設計者）の容量から仕掛かりの上限を 3 件と決め、複数案件の同時進行を絞った（ソフトウェア以外の領域） ［Managing Multiple Projects in Uncertain Contexts（2020）］
Section titled “機械メーカーの設計部門が、制約となる資源（設計者）の容量から仕掛かりの上限を 3 件と決め、複数案件の同時進行を絞った（ソフトウェア以外の領域） ［Managing Multiple Projects in Uncertain Contexts（2020）］”- 状況: 【ソフトウェア以外の領域の事例】スペインのバスク地方の協同組合の製造会社（従業員 200 人超）で、受注生産の機械の設計・組立・立ち上げを担う事業。複数の案件が同じ資源（とくに機械設計の技術者）を取り合い、短期の要求への対応に追われていた。設計を終えられないまま新しい設計を始める傾向があり、設計段階の仕掛かりが増えてマルチタスクと資源の分散を招いていた。このため、案件の同時進行を制約となる資源に合わせて絞る必要があった。複数の案件が共用の資源を取り合う点が、複数のチームから依頼される横断チームに似ている。
- やったこと: クリティカルチェーン法（CCPM）を土台に、バッファ、着手の条件を満たしてから仕事を流す Full-kit、短期の作業の管理のカンバンを組み合わせて導入した。複数案件の計画では、各段階の制約となる資源（ドラム）とその容量を先に決め、そこから各段階の仕掛かりの上限を決めた。設計段階は機械設計の資源がドラムで、設計の案件を同時に 3 件までに絞った。管理者（マスタースケジューラー）が、全体の優先順位と空いている容量の両方に合わせて案件を着手させる。実行の管理では、バッファの消費の割合を見て、早めの警告と原因の分析に使った。 2018 年 5〜6 月に設計だけを対象にしたパイロットを行い、7〜12 月に社内の他の段階へ広げた。
- 起きたこと: 著者は、仕掛かりの上限が制約となる資源の容量で決まるため、案件が資源の容量に合わせて時期をずらして始まり、マルチタスクが抑えられ、資源が重要な作業に集中できたと述べている。バッファの消費の原因の分析で、これまで思い込まれていた原因（供給の遅れ）が、実は設計の遅れで材料の手配が遅れることだと分かった。カンバンは短期・運用レベルの作業の管理で扱いやすく、報告も簡単だったとしている。設計段階の成果（完了した案件数、案件ごとの所要日数、設計段階の仕掛かりの数、遅れの合計）は図にだけ示され、本文には具体的な数値が無い。著者は、結果は初期的で、計画ほどは出ていないと述べている。
- 注意点: ソフトウェア以外の領域の事例（機械の設計・組立）で、チームの知的作業とは違い、適用にはその違いを考える必要がある。 1 社のアクションリサーチで、同じ時期の比較対象は無く、導入前後の推移だけで、著者自身も一般化を目的としないと述べている。仕掛かりの上限は、作業の止まり方のデータではなく、制約となる資源の容量から決めており、いったん決めた値を見直した手順や記録は書かれていない。数値は図にしか無く本文に具体値が無いこと、著者が結果を初期的で計画ほどは出ていないと述べていることから、効果の大きさは読み取れない。設計部門が中心の観察で、全社の展開後の結果は扱っていない。成功の条件として経営層の支えと、技術者の行動の変化の難しさを著者が挙げている。
- 根拠: アクションリサーチ／複数チーム。文献: Managing Multiple Projects in Uncertain Contexts: A Case Study on the Application of a New Approach Based on the Critical Chain Method（2020）。文献の種類: 論文・研究者。位置: 3.1. Qualitative Results（2 つ目の箇条書き）、2. Materials and Methods（Figure 2 の説明）、4. Discussion。確認の根拠: 原典
- 原文: “Multi-project planning is done by combining the established WIP limit, which is given by the capacity of the limiting resource, and the global priorities.”
前提に反する事例
Section titled “前提に反する事例”今回読んだ範囲では、見つかっていない。
調査から分かっていること
Section titled “調査から分かっていること”ソフトウェア開発の Kanban の実証研究 20 件の統合で、確信度の高い便益は作業の見える化・活動とタスクの統制・作業の流れ・市場投入までの時間の 4 つ、成否を最も左右する課題は組織文化とされた ［On the benefits and challenges of using kanban in software…（2018）］
Section titled “ソフトウェア開発の Kanban の実証研究 20 件の統合で、確信度の高い便益は作業の見える化・活動とタスクの統制・作業の流れ・市場投入までの時間の 4 つ、成否を最も左右する課題は組織文化とされた ［On the benefits and challenges of using kanban in software…（2018）］”- 状況: ソフトウェア開発で Kanban を使った実証研究 20 件を、Structured Synthesis Method で統合したレビュー。一次研究は、既存の 2 つの二次研究（Al-Baik と Miller 2015、Ahmad ほか 2018）から選ばれ、意見だけの研究は除かれた。対象は Anderson が提唱した Kanban（Capital K）で、Scrumban の研究も Kanban として統合されている。一次研究のほとんどは観察研究で、質的な記述が中心である。
- やったこと: 介入の記述ではなく、一次研究が報告した便益（効果）と課題（成否を左右する要因）を、研究の種類と質から計算した確信度（belief value）で統合した結果である。
- 起きたこと: 20 件の一次研究から 16 を超える便益が特定され、確信度が上位 4 分の 1 に入った「作業の見える化」「プロジェクトの活動とタスクの統制」「作業の流れ」「市場投入までの時間」の 4 つが、主な便益とされた。課題では、Kanban の導入の成否を最も左右するのは「組織文化」とされた。著者は、作業の流れの便益を、流れの妨げ（impediment）の発見と結びつけて符号化している（二次研究の Ahmad ほか 2018 が挙げた便益「流れの妨げを見つける」を、表 6 で「作業の流れ」に当てた）。見える化の便益の例として、ボードが開発プロセスの透明性を高め、誰がどのタスクに取り組んでいるかを示すことが引用されている。
- 注意点: 一次研究のほとんどが観察研究で質的なため、各一次研究の確信度は、その種類に応じた低めの範囲から計算されている（統合後の確信度は、研究が重なるほど高くなる）。否定的な結果を報告した研究が見つからず、著者もこれを今の知見の限界としている。表 5 の一次研究には、同じ大学のソフトウェアファクトリーでの研究が複数含まれ（P2 と P5、P13 と P14）、同じ企業の研究も複数含まれる（P17 と P23、P19 と P20）。学生の教育の場での研究も含まれる。対象は Anderson の Kanban（Scrumban の研究を含む）で、Kanban Guide のプラクティスに限らない。どの指標を取ればボトルネックを見つけられるかを直接比べた研究ではなく、見える化と流れについての便益の統合である。
- 根拠: 文献レビュー／複数チーム。文献: On the benefits and challenges of using kanban in software engineering: a structured synthesis study（2018）。文献の種類: 論文・研究者。位置: Abstract / 4 Representation of the benefits and challenges of Kanban（PDF p.13）/ 5 Results（PDF p.15–16）/ Table 6（Appendix A、PDF p.24）。確認の根拠: 原典
- 原文: “from the 20 selected primary studies in which over 16 benefits were identified, four had the most robust results in the aggregation”
入ってくる仕事に処理が追いつかないプロジェクトが多く、平均して積み残しが大きかった ［A Novel Technique to Assess Agile Systems for Stability（2023）］
Section titled “入ってくる仕事に処理が追いつかないプロジェクトが多く、平均して積み残しが大きかった ［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”
探した範囲の文献には見つからなかったこと
Section titled “探した範囲の文献には見つからなかったこと”次のことは、この問いのために探した範囲の文献には見つかりませんでした。「研究が無い」という意味ではありません。
- Work Item Ageの監視をデイリースクラムに組み込んだ際のアクション手順と効果。（探した範囲: 収集ラウンド 9 回・読んだ文献 31 本）
- CFDの異常パターンに対する自動検知やアラート運用の実務事例。（探した範囲: 収集ラウンド 9 回・読んだ文献 31 本）
- 作業の止まり方のデータからWIP制限の値を決め・見直した手順と、その値の記録。（探した範囲: 収集ラウンド 9 回・読んだ文献 31 本）
🔍 妥当性検証レポート（クリックして展開）
- 総合判定: ✅ 合格 (スコア: 100/100)
- 評価の前提: 結論（TL;DR）を、このページに載せた事例と知見だけに照らして評価した
- 形式論理検証: PASS
- LLM批判的評価（agy: gemini-3.8-flash-high）: Faithfulness 5.0/5, Relevance 5.0/5
評価コメント:
- Faithfulness（5点）: 回答文は前提コンテキストの内容および各事例・知見の「注意点」に極めて忠実です。コンテキスト外の一般的なスクラム俗説や勝手なベストプラクティス（安易なベロシティやバーンダウンチャートの推奨など）を捏造・補完することなく、「どの指標を取ればよいかを直接比べた研究はない」という制約を明記した上で記述されています。また、Jiraの安定度指標における数値データ（926件中72.89%、未解決タスク数の対比など）や、各事例の限界（定性的報告である点、作業の止まり方のデータが示されていない点、初期的知見である点）も正確に反映されています。 - Relevance（5点）: 「どのような指標・データを取って活用すべきか？」という質問に対し、コンテキストから導き出せる3つのデータ（累積フロー図に表れる作業の分布、WIP制限試行時の作業の止まり方、流入速度と処理速度の比である安定度指標）を冒頭で明確に提示して直接的に答えています。さらに、それぞれのデータがどのように活用され、どのような注意点が存在するのかを論理的かつ批判的に整理しており、質問の核心に対して過不足なく回答しています。