複数のプロジェクトから別々の業務を依頼される横断チームで、どのようにフローを維持・管理すればよいか？

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

結論（TL;DR）

文献にある打ち手は、大きく 4 つです。13 件の事例のうち、効果を数値で示したのは 5 件です。同じ時期の比較対象のチームと比べたものは無く、導入前との比較、別の製品どうしの比較、比較の無い数値のいずれかです。ほとんどは 1 つの組織の記録です。3 件はソフトウェア以外の領域（病院の手術室の調整 2 件、航空機の整備部門 1 件）の事例で、チームの仕事とは条件が違います。

1 つ目は、依頼の窓口と優先順位の判断をまとめることです。複数のプロダクトオーナーから別々の依頼を受ける Scrum チームに、プロジェクト間の優先順位を判断して窓口を一本にする Team Portfolio Owner を置いた会社では、参加者全員が有用と受け止め、その役割は会社全体で採用されました。ただし数値の効果は測られておらず、その工数は顧客に請求できないオーバーヘッドでした。16 チームの大規模開発（PubTrans）では、優先順位の対立に対し、臨時のタスクフォース、物理ボードの前でのプロダクトオーナーとチームリーダーの協議、遅れたチームの仕事を別のチームが引き受けることで対応しました。数値での検証はありません。

2 つ目は、流れを見えるようにし、状態の定義やポリシーを明示することです。分散 FOSS プロジェクトでは、ボードにコードレビューや UX 統合の状態を定義し、ポリシーを明示しました。上位のチームと UX のチームのコーディネーターは新しいワークフローを前向きに受け入れ、他のチームとのやりとりが円滑になったと報告されています（学生主体のプロジェクト 1 件の記録）。ソフトウェアとハードウェアが混在する組織では、ハードウェアのデイリーを週 1〜2 回に減らし、両領域の代表者による週次の確認の場を設け、カードの種類ごとにワークフローを分けました。複数の部署から仕事が流れ込む 1 チームでは、Kanban を段階的に入れ、1 稼働日あたりの完了件数が導入前の 1 か月の 1.1 件から 3.65 件に増えました。ただし比較対象のチームが無く、因果は言えません。チームが増えた医療機器の事業部では、Scrum を Kanban に替えて SAFe を入れた後継の製品で、大きなリリースの間隔が前の製品の 26.2 か月から 13.3 か月になりました。別の製品どうしの比較で、どの打ち手の効果かは分けられていません。

3 つ目は、割り込みを緩衝することです。Scrum の 3 チームは、スプリントとスクラムマスターで割り込みを緩衝し、顧客の依頼を記録して担当者に振り分けていました。うち 2 チームは静かな時間を設けていました。ある運用チームの開発者は、10 分未満で済むものはその場で直し、それ以外はチケットにしていました。これは同じプロジェクトの顧客からの割り込みへの対処で、複数のプロジェクトからの依頼の振り分けの事例ではありません。どちらも面接での証言で、効果は測られていません。

4 つ目は、緊急の依頼を別の入口に分け、定期的に見直すことです。多くのプロジェクトが共用する Wikimedia の課題管理では、担当者が最上位の優先度の課題を毎週見直す習慣を始めました。また、本番の緊急事態は障害を扱う別のプロジェクトで扱うことにしました。最上位の優先度は各チームが引き続き自由に使ってよいとされ、見直しでもその優先度は下げませんでした。規則と習慣を始めた記録で、効果は測られていません。

ソフトウェア以外の領域では、複数の部門が共用の資源に別々の仕事を依頼する場面の事例があります。ブラジルの大学病院は、予定外の手術を緊急度で区分して許される待ち時間の枠を決め、全診療科が見るカンバン形式の表示板と毎日の調整会議を入れました。導入の前後の各 3 か月を比べると、手術までの時間の中央値は 17 時間 20 分から 8 時間 52 分になりましたが、同じ時期の比較対象は無く、区分・表示板・会議のどれの効果かは分けられていません。中国の航空機整備部門では、機体ごとのプロジェクトが共用の作業場と人員を取り合います。そこに 3 種のカンバンの表示板を入れた後、扱った機数は前の 12 か月の 53 機から 99 機に増えました。ただし、機体の受注量の違いは除かれていません。いずれもチームの仕事ではなく、適用には領域の違いを考える必要があります。

特急枠のようなクラスオブサービスや優先度の使いすぎを防ぐ規則を入れ、その効果を導入前後や比較対象と比べて確かめた報告は、探した範囲の文献にはありませんでした。Wikimedia の規則も、使いすぎそのものを止めるものではなく、緊急事態を別の入口に分けるものです。病院の例も、緊急度の区分を入れた効果の報告で、区分の使いすぎを防ぐ規則の効果ではありません。

打ち手と事例

複数の部署から仕事が流れ込み Scrum が定着しなかった 6 人のチームが、Kanban Maturity Model の順に Kanban を入れ、1 稼働日あたりの完了件数が 3 か月で増えた ［Impact of the Kanban Maturity Model on a Team’s Agile…（2024）］

• 状況: ポーランドの中規模の企業（サイバーセキュリティ）の、開発者 6 人のチーム。メンバーはフロントエンド、バックエンド、クラウド基盤、アーキテクチャ、セキュリティなどの経験者で、作るソフトウェアはプラットフォームの他の部分とつながり、プロダクトチーム、カスタマーサクセス、カスタマーサポート、技術運用、セキュリティの各部署と継続的に連携する。前年に Scrum への移行を試みたが定着せず、不定期のデイリースクラムと、プランニングとレビューの無いスプリントだけが残っていた。著者は理由として、複数の部署から仕事を受け、一部は標準のスプリントの外で届ける必要があったこと、仕事の出どころが多くプロダクトオーナーを決めることとプロダクトバックログの管理が難しかったこと、当時はチーム内で変化への支持が弱く、スクラムマスターの経験も浅かったことを挙げている。調査の時点では、チームは仕事に圧倒されていると述べ、リリースは大きく遅れ、品質も社内外の期待を下回っていた。
• やったこと: CIO・エンジニアリングの責任者・プロダクトマネージャー・アジャイルコーチが新しい変革を始め、複数の仕事の出どころに対処し、新しい役割を置かずに仕掛かり作業を制限する方法として Kanban Method を選んだ。 2023 年 3 月に Kanban Maturity Model（KMM）でチームの成熟度を評価し（最も低いレベル 0）、4 月から 6 月に KMM のレベルの順に実践を入れた。入れた実践の数は 4 月 23、5 月 12、6 月 6 だった。チケットでの作業の可視化、アバターによる個人の負荷の可視化、1 人あたりの WIP 制限、基本の方針と流れの指標、デイリーのカンバンミーティング、レトロスペクティブ、補充のミーティングなどを入れ、他のチームと管理職にも Kanban の研修をした。研究者がチームに関わり、進み具合と問題に応じて打ち手を調整した。
• 起きたこと: チーム全体の 1 稼働日あたりの完了タスク数の平均は、導入前の 3 月が 1.1 件、4 月が 1.33 件、5 月が 2.5 件、6 月が 3.65 件だった。著者は、導入前の月と比べて 3 倍を超えたとしている。
• 注意点: 基準は導入前の 1 か月だけで、比較対象のチームは無く、因果は言えない。研究者がチームの実践に関与していた。研修やミーティングを含む多数の実践が同時に入っていて、どの実践の効果かは分けられない。指標は完了したタスクの件数で、項目の大きさは測っていない（著者は、期間中に作業項目の粒度の変化は観察されなかったと述べている）。Scrum 側は、プランニングとレビューを欠いた部分的な導入だった。研究期間の書き方が揃っていない（本文は 3〜6 月、図 1 の題は 4〜7 月）。ここでは本文の値を使った。顧客が報告した不具合の件数の比較もあるが、対象がチームの製品か会社全体かで本文の書き方が揺れるため載せない。経験者だけの 1 チームで、期間中にメンバーは変わらなかった。
• 根拠: 事例研究／単一チーム。文献: Impact of the Kanban Maturity Model on a Team’s Agile Transformation: Tripling Throughput and Elevating Quality in Three Months（2024）。文献の種類: 論文・研究者。位置: 2 Method and Setting（論文集の p.108–109）/ 3 Results and Discussion（論文集の p.110–112、表 1）。確認の根拠: 原典
• 原文: “reached 3.65 tasks per work day.”

Kanban の運用チームで、一部の顧客がどの問題も緊急として電話してくる状況に、10 分未満で済むものはその場で直し、それ以外はチケットにして緊急性を理解したと伝えて対処した ［Interruptions in Agile Software Development Teams（2021）］

• 状況: 保険会社の、Kanban を使う 4 人のチーム（開発者 3 人とプロジェクトリーダー 1 人。全員が同じ場所で働く）。複数の保険ソフトウェアの運用の自動化・管理・監視を担当する。著者は、このチームには、手順を計画してチームと社外の関係者に課す強いマネージャーがいたと述べている。顧客は通常、メール受付のチケットシステムに障害を報告し、進み具合もそこで追う。特に緊急なときだけ電話でチームに連絡するよう求められていた。しかし開発者の 1 人によれば、一部の顧客はどの問題も緊急として扱ってすぐに電話した。電話に出ないと、本社ビルの地下にあるチームの部屋まで来て、作業を中断させた。
• やったこと: この開発者の対処は次のとおり。中断は迷惑だが追い返さず、まず用件を聞いて手伝う。 10 分未満で済むもの（例: システムの再起動）はその場で直して切り上げる。それ以上かかるものは新しいチケットを起こし、緊急性と重要性を理解したことを顧客に伝える。チームの仕組みとしては、メールのチケットシステムを標準の窓口とし、電話は特に緊急な場合に限っていた。
• 起きたこと: この対処で、緊急扱いの電話が減ったかどうか、チームの作業の流れがどう変わったかは書かれていない。開発者は、中断は「うっとうしく、していた作業から引き離される」と述べつつ、職場の雰囲気が良いので追い返さずに手伝うと述べている。
• 注意点: 開発者 1 人の証言で、対処の効果は測られていない。電話やチケットの件数、応答までの時間も示されていない。「どの問題も緊急」と扱うのは一部の顧客の行動として書かれている。チームが特急枠のような優先度の規則を決めて運用していたという記述ではなく、この開発者個人の対応の流儀である。同一のプロジェクトの顧客からの割り込みへの対処で、複数のプロジェクトからの依頼の振り分けの事例ではない。このチームは強いマネージャーが手順を決めて社外の関係者にも課していた点が、同じ研究の Scrum のチームと違う。著者は一般に、顧客に依頼の優先づけを教える必要があると述べているが、このチームがそうしたという記録ではない。探索的な定性研究（4 チーム、19 人への面接）で、MONITOR チームの面接は 4 人。4 チームとも大企業のチームで、著者は小さな組織やオープンソースには当てはまらない可能性を認めている。
• 根拠: 事例研究／単一チーム。文献: Interruptions in Agile Software Development Teams（2021）。文献の種類: 論文・研究者。位置: Results / Interruptions Related to Team Interactions（PDF p.6）/ Table 1（PDF p.4）/ Discussion（PDF p.8, p.10）。確認の根拠: 原典
• 原文: “you just open another ticket and signal that you understood the urgency and importance.”

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

複数のプロダクトオーナーから別々の依頼を受ける Scrum チームに、チームポートフォリオオーナーを置き、プロジェクト間の優先順位の判断と依頼の窓口を一本にした ［Team Portfolio Scrum（2016）］

• 状況: オランダの受託ソフトウェア開発の会社。約 20 人で、半数が開発者である。2 つのチームが、ほぼ常に 2 人以上のプロダクトオーナー（PO）の仕事を受けていた。年に、極小のプロジェクトが 2 つと、「個別」から「極小」までの規模のプロジェクトが 30 から 40 ある。保守は緊急で、期限が 1 日か 2 日のものが多い。人手が足りず、作業量は常に多かった。 Scrum は導入していたが、並行するプロジェクトと顧客の依頼のために、実践に苦労していた。診断では、開発者が複数の PO との議論で気を散らされていた。ポートフォリオ全体の判断も開発者が下していた。
• やったこと: ポートフォリオボード、ポートフォリオチーム、チームのポートフォリオバックログを置いた。そのうえで、Team Portfolio Scrum（TPS）を始めた。 TPS は、1 週間の Scrum のサイクルで、PO の代わりに Team Portfolio Owner（TPO）を置く。TPO には、そのチームの PO だった 3 人のうち 1 人を任命した。 TPO は、プロジェクト間の優先順位を、チーム、ポートフォリオチーム、顧客と調整する。複数のプロジェクトを、1 つのチームバックログにまとめる。作業が長引く場合や、緊急の別の仕事が入る場合と、スプリントプランニングで、プロジェクト間の優先順位を守る。チームへの連絡の単一の窓口になり、週次のポートフォリオ会議とデイリーに出る。
• 起きたこと: 参加者全員が有用と受け止め、研究の終了の後に、TPO の役割が会社全体で採用された。著者はこれを成功の指標とみなしている。著者の評価では、導入前は開発者が優先順位を決め、責められていた。TPO の導入で、その判断から開発者は外れた。観察と複数の関係者の発言でも確かめられたと、著者は書いている。著者の記述では、以前は PO が席に来て質問し、段取りを決め、自分のプロジェクトのために働きかけていた。開発者は、自分たちを守りやすくなり、開発に集中する余地が増えたと述べている。スプリントゴールを危うくする作業が出たら、開発者は TPO に直接伝え、落とす作業は TPO が決める。開発者は、これがとてもうまくいっていると述べた。一方で、TPO の工数は顧客に請求できないオーバーヘッドだった。TPO は忙しく、終盤は負荷が高かったと、TPO 本人が述べている。並行するプロジェクトの数も増えた。 （数値の報告あり。この記録には数値を書いていない）
• 注意点: 1 社（約 20 人）の 1 サイクルのアクションリサーチで、著者自身が、1 つの研究にとどまることを限界に書いている。第 2 著者はその会社の従業員で、ワークショップや議論を進めた。本文に割り込みの件数などの数値は無く、著者は効果の定量化を今後の研究に残している。効果は、参加者の受け止めと、全社で採用されたという著者の判断による。チームリーダーが途中で退職し、士気に影響した。 TPO に十分な権限が無いと、PO に確認する段が増えて、オーバーヘッドになる（チームの証言）。PO は、計画の粒度が粗くなったと述べ、小さなプロジェクトと保守は計画しにくいと述べている。優先順位の調停の手順としては、TPO の責務の一覧と運用の記述にとどまる。優先順位が衝突したときの決め方（基準や会議体の規則）は書かれていない。既存の顧客の仕事は断れず、選べるのは新しい顧客だけだと、参加者は述べている。並行するプロジェクトの数については、著者は文献をもとに、1 日に大きな文脈の切り替えを 1 回までとする目安を挙げている。
• 根拠: アクションリサーチ／単一チーム。文献: Team Portfolio Scrum: An Action Research on Multitasking in Multi-project Scrum Teams（2016）。文献の種類: 論文・研究者。位置: 5 Action Research（5.1 Diagnosing・5.2 Action Planning・5.3 Action Taking・5.4 Evaluating）/ Table 2（論文集の p.84–88）。確認の根拠: 原典

ソフトウェアとハードウェアが混在するハイブリッド組織で、スプリントのケイデンスとセレモニー頻度を領域ごとに適応させて連携した ［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.”

航空機の整備部門が、機体ごとのプロジェクトと共用の作業場にカンバンの表示板 3 種を入れ、1 年で処理した機数が前年の 53 機から 99 機に増えた（ソフトウェア以外の領域） ［Kanban in Aviation Maintenance（2025）］

• 状況: 【ソフトウェア以外の領域の事例】中国の航空機整備会社の、機体の定期整備を担う部門。A〜D 点検に対応し、6 機種を扱う。機体 1 機ごとをプロジェクトチームとし、プロジェクトの管理と作業場の管理を組み合わせて進める。プロジェクトチームには各作業場から人が出るため、同じ作業場の人が複数の機体のプロジェクトに関わる。点検で見つかった不具合で、計画が頻繁に変わる。計画の進み具合や人員の配置は、押し出し型の管理で、実際の作業の状況が見えにくかった。複数のプロジェクトが共用の作業場と人員を取り合う点が、複数のプロジェクトから依頼される横断チームに似ている。
• やったこと: 3 種のカンバンの表示板を、手書きの物理ボードで入れた。人員配置の表示板（作業場 1 のみ）、プロジェクト管理の表示板、全機体の進み具合を集める生産管理の表示板。プロジェクト管理の表示板では、品質・コスト・納期・安全・人などの項目を、日ごとに赤・黄・緑で示し、計画と実績の差を見えるようにした。毎朝、プロジェクトマネージャーが各チームの前でカンバンの会議を開き、その日の生産計画を出して表示板を更新した。導入の前に、全員が 2 週間の研修を受けた。
• 起きたこと: 導入後 1 年で、いくつかの機体の作業の所要日数が減った。A320 の Wi-Fi 取り付けは 7 日から 4 日、A320 の 4C 点検は 11 日から 9 日、A330 の 4C 点検は 25 日から 23 日、A321 の塗装剥離は 12 日から 10.5 日。導入前の 12 か月と導入後の 12 か月を比べると、扱った機数は 53 機から 99 機に、整備の停止の合計（原文の Maintenance Downtime、単位は原文に明記が無い）は 1,854 から 2,577 に増えた。著者はこれを年間の生産能力の増加とみている。月ごとの平均の成果額（原文の benefit）は、導入後の期間で約 15% 増えたとしている。
• 注意点: ソフトウェア以外の領域の事例で、チームの知的作業ではなく航空機の整備であり、適用にはその違いを考える必要がある。 1 社の 1 部門の事例研究で、同じ時期の比較対象は無い。導入前後の比較は機数と整備の停止の合計だけで、所要日数の「初期」と「現在」の基準の時期・件数は原文に書かれていない。導入後の月ごとの成果額は、図から読んだ約 15% の増加で、導入前の同じ指標との比較ではない（導入後の最初の月は分析から外している）。受注した機体の量や機種の構成が前年と同じとは限らず、機数の増加がカンバンの効果かは分けられていない。仕掛かりの上限（WIP 制限）や、特急の仕事の扱いの規則は書かれていない。
• 根拠: 事例研究／複数チーム。文献: Kanban in Aviation Maintenance: A Case Study of a Chinese Aircraft Maintenance Enterprise（2025）。文献の種類: 論文・研究者。位置: 4. Results and discussion（Table 1・Table 2、Figure 9）。確認の根拠: 原典
• 原文: “Quantitatively, the average monthly benefit increased by approximately 15% over the implementation period.”

分散FOSSプロジェクトでKanbanのワークフロー可視化とポリシー明示を導入し、横断チーム間の調整が改善した ［Can FOSS projects benefit from integrating Kanban（2017）］

• 状況: 複数プラットフォーム（Android, iOS等）のアプリを開発する大規模分散FOSSプロジェクト。上位チーム（super-team）やUXチームなど複数チーム間の依存関係があり、コードレビューの停滞や仕様調整の摩擦が存在した。
• やったこと: アクションリサーチにより、Kanbanのワークフロー可視化、ポリシーの明示化、およびチーム間フィードバックループを導入した。Jiraボード上にコードレビューやUX統合の明確なステータスを定義した。
• 起きたこと: 上位チームおよびUXチームのコーディネーターが新しいワークフローを前向きに受け入れ、コードレビューのステータス追加やUX統合の改善提案が自発的に行われるようになった。他チームとのコミュニケーションが円滑になったと報告された。
• 注意点: 学生主体のハイブリッドFOSSプロジェクト1件のアクションリサーチであり、商業組織とはインセンティブ構造が異なる。
• 根拠: アクションリサーチ／複数チーム。文献: Can FOSS projects benefit from integrating Kanban: a case study（2017）。文献の種類: 論文・研究者。位置: 5.2.2 Evaluating and specified learning / Inter-team feedback。確認の根拠: 原典
• 原文: “Both coordinators, from the super-team and the UX team, reacted positively to the new workflow. The super-team coordinator even showed some interest in adopting it for his team.”

病院の緊急手術で、緊急度の区分・共有のカンバン表示・毎日の合同の会議を入れると、手術までの待ち時間が約半分になった（ソフトウェア以外の領域） ［Impact of implementing a prioritization process on waiting…（2025）］

• 状況: 【ソフトウェア以外の領域の事例】ブラジルの大学病院の救急部門で、多くの診療科（消化器外科・一般外科・脳神経外科・血管外科・眼科・整形外科など）が、同じ手術室を使って予定外の手術を依頼する。手術の優先順位は、医師ごとの判断で分散して決まっていた。そのため診療科の間で予定がぶつかり、なぜその順になったかが見えず、避けられる遅れが出ていた。 1 つの共有の資源に、複数の診療科から別々の仕事が流れ込む。この点は、複数のプロジェクトから依頼される横断チームに似ている。
• やったこと: 緊急度の基準で手術を区分した。区分ごとに、手術までに許される時間の枠を決めた（1 時間以内・1〜6 時間・6〜24 時間・24〜48 時間・48 時間超）。待っている手術を、全診療科が見られるリアルタイムのカンバン形式の表示板に並べた。毎日、多職種で手術の順番を調整する会議を開いた。導入は 2022 年 9 月で、9〜10 月は研修と調整の期間として分析から外している。
• 起きたこと: 導入前の 3 か月（2022 年 6〜8 月、967 件）と導入後の 3 か月（2022 年 11 月〜2023 年 1 月、884 件）を比べている。手術の必要が決まってから手術までの時間の中央値は、17 時間 20 分から 8 時間 52 分に減った（p < 0.001）。許される時間の枠に収まった手術の割合は、60.5% から 77.1% に増えた（オッズ比 2.205）。区分ごとに見ると、1 時間以内の最も緊急な区分では有意な差が出ず、著者は既存の緊急対応の手順があったためとみている。 1〜6 時間・6〜24 時間・24〜48 時間の区分では有意に改善した。待ち時間が悪化した診療科は無かったが、診療科ごとに有意な差が出たのは脳神経外科・眼科・形成外科・その他だった。
• 注意点: ソフトウェア以外の領域の事例で、チームの仕事ではなく病院の手術室の調整であり、適用にはその違いを考える必要がある。導入前後の比較で、同じ時期の比較対象は無い。後ろ向きの 1 病院の観察研究。緊急度の区分・表示板・毎日の会議を同時に入れていて、どれの効果かは分けられていない。表示板に仕掛かりの上限（WIP 制限）は書かれていない。診療科の構成が 2 つの期間で有意に違い（p = 0.025）、期間の違いによる影響を除いていない。「許される時間の枠」を守ることが目標であり、緊急の区分の使いすぎを防ぐ規則の効果を測ったものではない。区分の付け方の揺れ（本来は緊急でない手術を緊急に入れる）への対処は、この報告では測られていない。許される時間の枠に収まった割合は、表の件数（681/884）から計算すると 77.0% で、本文は 77.1% としている。
• 根拠: 事例研究／大規模な組織。文献: Impact of implementing a prioritization process on waiting time for non-scheduled surgeries in a tertiary emergency unit（2025）。文献の種類: 論文・研究者。位置: Abstract / Results（Outcomes, Table 2・Table 3）。確認の根拠: 原典
• 原文: “Compliance with acceptable waiting time windows increased from 60.5 % to 77.1 %”

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

16 チームの大規模開発で、優先順位の対立と遅延に対し臨時タスクフォースや物理ボードでの PO 協議、他チームのタスク引き受けで対応した ［Coordination Strategies（2021）］

• 状況: ノルウェーの公共交通機関（PubTrans）の大規模アジャイル開発プログラム（16チーム、約100名）の定性的事例研究。政治改革による厳しい固定納期と複数クライアントからの要求過多により、優先順位の競合が発生した。他チームに依存する作業の途中で依存先が別タスクへ切り替えられ、関連チーム全体に遅延を及ぼす事態が生じていた。また、顧客による Slack 等での直接的な要望持ち込みにより、優先順位のプロセスが混乱していた。
• やったこと: チーム間の優先順位を管理する戦略（Strategy 3: Prioritization）として複数のメカニズムを導入した。 (1) 複数チームに跨がる急務機能の実装のため、4チームからメンバーを集めた臨時タスクフォースを編成し、専用の朝会を開いて集中対応した。 (2) 遅延が発生した際、手一杯のチームに代わって余裕のある別チームがその機能（決済ソリューション等）を丸ごと引き受けて実装した。 (3) プロダクトオーナーとチームリーダーが集まるチーム間ステータスミーティングを物理的なタスクボードの前で開催し、最優先事項をすり合わせたほか、PO同士の週次ミーティングと共有バックログの洗練を進めた。
• 起きたこと: 臨時タスクフォースによって複数チームが関わる機能を早期に完了させることができた。また、別チームへのタスク移譲（決済機能の実装など）は大きな成功と評価され、チーム間の柔軟な助け合いとして機能した。物理タスクボードを用いた PO・リーダー間の協議により、重要なチーム間優先順位が可視化され、相互調整が促された。
• 注意点: 政治改革に伴う強い納期圧力とクライアント数の急増という特有の文脈がある。単一の大規模プログラム（PubTrans）を対象とした質的ケーススタディであり、定量的メトリクス（スループットやサイクルタイムの数値）による効果検証は行われていない。他チームのタスクを肩代わりする柔軟性はアジャイルな文化・マインドセットに依存する。
• 根拠: 事例研究／大規模な組織。文献: Coordination Strategies: Managing Inter-team Coordination Challenges in Large-Scale Agile（2021）。文献の種類: 論文・研究者。位置: 4.3 Managing Prioritization Issues / 5 Discussion (5.1 Prioritization)。確認の根拠: 原典
• 原文: “To manage the prioritization process, PubTrans used inter-team status meetings for product owners and team leaders, where they discussed top priorities from the different teams toward the overall deliveries. These were conducted in front of a physical task board showcasing the most important inter-team prioritizations.”

病院の予定外手術で、優先度を書く申込み票・共有の表示板・毎日の調整会議を入れて、1 年目に過半の手術が推奨の時間内に収まった（ソフトウェア以外の領域） ［Resource management strategies for prioritizing…（2024）］

• 状況: 【ソフトウェア以外の領域の事例】ブラジルの大学病院の救急部門で、年に 4 万件を超える救急受診から、月に約 280 件の予定外の手術が出る。手術室は 24 時間使えるが、手術の優先順位は医師ごとの判断で決まっており、判断の不一致・非効率・診療科の間の不和・手術計画の難しさを招いていた。複数の診療科から同じ手術室へ仕事が流れ込む。この点は、複数のプロジェクトから依頼される横断チームに似ている。
• やったこと: 専門医 17 人が 50 件の実際の症例の優先度を評価して、評価がそろうことを確かめた。そのうえで、優先度を決める要因（手術の重要度・病気の進行への影響・待ち時間、同時の手術の負荷・手術の時間・術後の病床の空き）を整理した。診療科が合意して、手術までの目標の時間を、1 時間以内・1〜6 時間・6〜24 時間・24〜48 時間・48 時間超に分けた。手術室を申し込む際に、優先度を 6 段階の色分けで書く票を記入させた。優先度は、患者の状態の変化や、予定より待っている時間によって変えてよいとした。待っている手術の優先度、手術室の状況、待ち時間、キューの中の状態を、全診療科が見る共有の電子表示板に出した。毎日、各診療科の外科医・手術部門・救急部門・栄養・物品などが集まる会議で、その日の手術の順番を決めた。
• 起きたこと: 最初は優先度の算法の補助なしで試した。その後の導入で、最初の月に審議した 134 件のうち 81% が、提案された優先度に従った。表示板を導入した後の 2023 年の暫定の数値では、予定外の手術 2,508 件のうち 80% を超える手術が、推奨の時間内に行われた。優先度が高い区分ほど、待ち時間は有意に短かった。導入前の基準との比較は、この報告には無い。
• 注意点: ソフトウェア以外の領域の事例で、チームの仕事ではなく病院の手術室の調整であり、適用にはその違いを考える必要がある。実施した側（病院の担当者）による編集記事で、暫定の数値であり、導入前の基準や比較対象との比較は無い。待ち時間の短さは「優先度の高いものが先に行われた」ことを示すにとどまり、導入の効果は測っていない。優先度の使いすぎ（緊急でないものを緊急に入れる）を防ぐ規則は書かれていない。優先度を変えてよいとした条件（待ち時間が予定を超えた場合など）が、使いすぎをどれだけ抑えたかも測られていない。同じ導入の導入前後の比較は、2025 年の論文（non-scheduled-surgery-prioritization-kanban-waiting-time-2025）の記録にある。
• 根拠: 経験報告／大規模な組織。文献: Resource management strategies for prioritizing non-scheduled surgical procedures in a tertiary public hospital（2024）。文献の種類: 記事・研究者。位置: 本文（優先度の区分と申込み票の段落、共有の表示板と毎日の会議の段落、最初の月の遵守率と 2023 年の暫定データの段落、Table 1）。確認の根拠: 原典
• 原文: “subsequent implementation showed 81 % adherence to suggested priorities among 134 procedures deliberated in the first month”

Wikimedia の課題管理で、最上位の優先度「Unbreak Now」の課題が長く開いたままになる問題を議論し、本番の緊急事態はすべて障害を扱う別のプロジェクトで扱うことにした ［T140207 Consider alternative processes for Unbreak Now bugs,…（2016）］

• 状況: Wikimedia の Phabricator は、本番に配備された拡張機能から pywikibot のような外部のプロジェクトまでが同居する課題管理で、最上位の優先度「Unbreak Now」（何をおいても今すぐ直す）を持つ。 2016 年の本番障害のあと、原因が分かりにくく複数のコンポーネントにまたがる「Unbreak Now」の課題が長く開いたままになるのを防ぐ進め方が議論された。課題管理の担当者は自分の見方として、この優先度が一部のチームで使われすぎていると述べた。承認待ちの進め方のために何週間も開いたままの課題もあり、本当の緊急事態を見分けて催促しにくいという。リリースエンジニアリングの担当者は、旧システムからの移行時に最上位の優先度をそのまま対応させたと記憶しており、一時はこの優先度の課題が大量にあったと書いている。同じ優先度でも、本番に配備された拡張機能と、本番の外のプロジェクトとでは意味が違うという指摘もあった。
• やったこと: 案として出たのは、この優先度の課題が残っていると定期的にチャットに通知する案、本番の緊急事態を表す別の優先度や印を作る案、その優先度を設定できる人を絞る案などである。設定時に確認の画面を出す案は、挙げた本人が全員に一つの使い方を強いるという難点を述べ、別の参加者は優先度の名前どおりに使うべきだと返した。最終的に、リリースエンジニアリングの担当者が、障害の記録のマイルストーンの親にもなるプロジェクト（Wikimedia-Incident）を作り、本番の緊急事態はすべてそこで扱うよう告げて閉じた。そのボードは「受け付け」「対応中の緊急事態」「後追いの作業」のような列で運ぶ案だった。「Unbreak Now」は特別扱いせず、各チームが自分のプロジェクトで自由に使ってよいとした。その一覧は、障害のふりかえりの提案で先に始めていた毎週の見直し（別のタスク）で、担当者が引き続き見る。
• 起きたこと: 結果の記述なし。 障害を扱うプロジェクトを作ったあと、優先度の使いすぎが減ったか、緊急事態への対応が速くなったかは、このタスクには書かれていない（結果の記述なし）。
• 注意点: 規則を作った経緯の議論の記録で、効果を測った記述は無い。「Unbreak Now」の課題の件数は、議論の途中の個別のコメントに、その時点の数として書かれているだけで、規則の前後を同じ方法で数えた比較ではない。使いすぎの指摘は参加者の一人の見方で、決定の理由として書かれてはいない。対処は、最上位の優先度の使いすぎそのものを止める規則ではなく、本番の緊急事態を別の入口に分ける規則である。最上位の優先度は、各チームが引き続き自由に使ってよいとされた。一つの組織の課題管理の共用の場の事例で、カンバンのクラスオブサービスとして設計されたものではない。
• 根拠: 経験報告／大規模な組織。文献: T140207 Consider alternative processes for Unbreak Now bugs, especially those which cross-cut components（2016）。文献の種類: ウェブページ・実践者。位置: タスク T140207 の説明と議論（2016 年 7 月 13 日〜25 日のコメント、7 月 27 日の閉じるときのコメント）。保存版: http://web.archive.org/web/20260214112634/https://phabricator.wikimedia.org/T140207。確認の根拠: 原典

Wikimedia の課題管理で、障害のふりかえりの提案から、担当者が最上位の優先度「Unbreak Now」の課題を毎週見直す習慣を始め、本当の緊急事態かを見分けて状況を尋ねた ［T141130 Institute a weekly review of all UBN! tasks（2016）］

• 状況: Wikimedia の Phabricator は、募金・アプリ・pywikibot などのプロジェクトが同じ優先度を使う課題管理で、最上位の優先度「Unbreak Now」を持つ。 2016 年の本番障害のふりかえりで、リリースエンジニアリングの担当者がこの優先度の課題を毎週見直し、本当の緊急事態を見分けて早く手を打つことが提案された。課題管理の担当者は後に、それまで自分が隔週ほどを目安に、個々の課題の上で催促してきたと書いている。
• やったこと: 提案を受けて、リリースエンジニアリングの担当者が、この優先度の課題の一覧を毎週決まった時間に見直す予定を立てた。初回の見直し（予定の時間からは遅れた）では、本当の緊急事態と判断した課題に状況を尋ね、すでに作業中のものと、募金・iOS アプリ・pywikibot の課題には手を出さなかった。公開の定例会にするかも話し合ったが、個々の課題の中で議論しているので正式な会議は要らないという意見を受け、担当者の個人の定例と、ホーム画面の一覧で随時見る形にして閉じた。
• 起きたこと: 見直しを始めた後の担当者のコメントでは、残っている「Unbreak Now」の課題は、それぞれのプロジェクトが「全員が手を止める」意味でなく使っているものだったと書かれている。課題管理の担当者は、催促する人が自分だけでなくなったことを歓迎した。見直しによって優先度の使いすぎが減ったか、緊急事態への対応が速くなったかは、このタスクには書かれていない。
• 注意点: 見直しの習慣を始めた報告で、効果を測った記述は無い。課題の件数は、見直しの後の担当者のコメントにその時点の数として書かれているだけで、見直しの前の件数（別のタスクのコメント）と同じ方法で数えた前後比較ではない。見直しは一人の担当者の習慣として続けることになり、公開の会議にはならなかった。見直しでも、各プロジェクトが付けた優先度は下げなかった。一つの組織の課題管理の共用の場の事例で、カンバンのクラスオブサービスとして設計されたものではない。
• 根拠: 経験報告／大規模な組織。文献: T141130 Institute a weekly review of all UBN! tasks（2016）。文献の種類: ウェブページ・実践者。位置: タスク T141130 の説明とコメント（2016 年 7 月 22 日〜8 月 8 日）。保存版: http://web.archive.org/web/20260312061245/https://phabricator.wikimedia.org/T141130。確認の根拠: 原典

前提に反する事例

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

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

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

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

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

• クラスオブサービス（特急レーンなど）の過剰利用を防ぐ規則を入れた効果を、導入前後や比較対象と比べて確かめた報告。（探した範囲: 収集ラウンド 9 回・読んだ文献 31 本）
• 横断チームにカンバンを入れた効果を、比較対象のチームや複数か月の導入前の基準と比べた定量的な検証。（探した範囲: 収集ラウンド 9 回・読んだ文献 31 本）

出典一覧

文献	年	ライセンス	記録の数
Coordination Strategies: Managing Inter-team Coordination Challenges in Large-Scale Agile	2021	CC BY 4.0	1
Interruptions in Agile Software Development Teams	2021	CC BY 4.0	2
Kanban in Aviation Maintenance: A Case Study of a Chinese Aircraft Maintenance Enterprise	2025	CC BY 4.0	1
Can FOSS projects benefit from integrating Kanban: a case study	2017	CC BY 4.0	1
Impact of the Kanban Maturity Model on a Team’s Agile Transformation: Tripling Throughput and Elevating Quality in Three Months	2024	CC BY 4.0	1
Impact of implementing a prioritization process on waiting time for non-scheduled surgeries in a tertiary emergency unit	2025	CC BY 4.0	1
Resource management strategies for prioritizing non-scheduled surgical procedures in a tertiary public hospital	2024	CC BY 4.0	1
T140207 Consider alternative processes for Unbreak Now bugs, especially those which cross-cut components	2016	CC BY-SA 4.0	1
T141130 Institute a weekly review of all UBN! tasks	2016	CC BY-SA 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
Team Portfolio Scrum: An Action Research on Multitasking in Multi-project Scrum Teams	2016	CC BY-NC 4.0	1

---

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

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

評価コメント:

• Faithfulness（忠実性）: 5点。提供された13件の事例および各ケースの「注意点」に極めて厳密に準拠しています。効果を数値で示した事例数（5件）、ソフトウェア以外の領域の事例数（3件）、各事例の具体的な介入策・結果・限界（比較対照の不在、因果関係の言及不能、TPOのオーバーヘッド、非定量的評価など）に至るまで、コンテキストに記載された事実のみで構成されており、独自の憶測や捏造、外部の俗説の混入は一切認められません。 - Relevance（適合性）: 5点。「複数のプロジェクトから別々の業務を依頼される横断チームでフローを維持・管理する方法」という問いに対し、コンテキスト内の多様な事例から「窓口と優先順位判断の一本化」「流れの可視化とポリシー明示」「割り込みの緩衝」「緊急依頼の入口分離と定期的見直し」の4つの具体的アプローチへ論理的に体系化して直接回答しています。さらに、それぞれの打ち手が持つ制約やエビデンスの限界（特急枠の乱用防止策の未検証など）まで網羅して客観的に提示しており、極めて的確です。

---

関連する用語

• プッシュ割り込み
• ワークフローの定義
• 進行中の作業 (WIP)