複数チームへカンバンをスケールする方法とは？組織全体のフロー最適化を実現する考え方

複数チームへカンバンをスケールするとは、単一チームのタスク管理にとどまらず、チーム間の依存関係、部門間の待機時間、組織全体のボトルネックを可視化し、価値提供の流れを改善することです。カンバンは小規模チームの作業管理に使われることが多いですが、本来は組織全体のフローを改善するためにも活用できます。

組織が成長すると、作業は一つのチーム内で完結しにくくなります。企画、開発、デザイン、品質保証、セキュリティ、法務、営業、カスタマーサポートなど、複数のチームや部門が関わることで、依存関係や引き継ぎが増えます。その結果、個々のチームは忙しく動いていても、組織全体としては価値提供が遅くなることがあります。

この記事では、カンバンを複数チームへスケールする必要性、単一チームカンバンの限界、チーム間依存関係の管理方法、エンタープライズカンバン、ポートフォリオレベルのカンバン、組織全体のWIP制限、AI時代におけるカンバンスケーリングの重要性について解説します。

1. なぜカンバンのスケーリングが必要になるのか

カンバンのスケーリングが必要になる理由は、組織が大きくなるほど、仕事の流れが一つのチーム内で完結しなくなるからです。単一チームでは見えていた作業状況も、複数チームや複数部門が関わると、依存関係や待機時間が見えにくくなります。

カンバンをスケールする目的は、単にボードを増やすことではありません。組織全体の価値提供の流れを可視化し、チーム間のボトルネックを発見し、全体最適を実現することです。局所的な効率ではなく、顧客やユーザーに価値が届くまでの流れを改善する必要があります。

1.1. 組織規模の拡大

組織規模が拡大すると、仕事に関わる人数やチームが増えます。小さなチームでは口頭や簡単なボードで共有できていた情報も、組織が大きくなると把握しにくくなります。各チームがそれぞれのボードを持っていても、組織全体として何が進んでいるのか、どこで止まっているのかが見えない状態になりやすいです。

このような状況では、チーム単位のカンバンだけでは不十分です。チームごとの作業状況に加えて、チーム間を流れる仕事、部門横断の取り組み、大規模案件の進捗を可視化する必要があります。カンバンをスケールすることで、組織全体の状態を見えるようにし、より適切な意思決定を行いやすくなります。

1.2. チーム間依存の増加

複数チームでプロダクトやサービスを開発する場合、チーム間の依存関係は避けられません。あるチームの設計が完了しないと別のチームが実装できない、基盤チームの対応が終わらないと機能チームが進めない、品質保証チームの確認が完了しないとリリースできないといった状況が発生します。

チーム間依存が増えると、各チームが自分たちの作業だけを最適化しても、全体の流れは改善されません。依存関係を可視化し、ハンドオフや待機時間を管理することが重要になります。カンバンを複数チームへスケールすることで、依存関係を見える化し、チーム間の調整を具体的に行えるようになります。

1.3. フローの複雑化

組織が大きくなると、仕事のフローは複雑になります。アイデアが生まれてから顧客に価値が届くまでに、企画、設計、開発、レビュー、テスト、セキュリティ確認、承認、リリース、運用など多くの工程を通ることがあります。工程が増えるほど、どこで停滞しているのかを把握することが難しくなります。

フローが複雑化した状態で個別チームの進捗だけを見ていると、全体の問題を見落としやすくなります。たとえば、開発チームは順調でも、承認やレビューで長く待っている場合、顧客への価値提供は遅れます。カンバンのスケーリングでは、各チームの作業だけでなく、価値が流れる全体の経路を見えるようにすることが重要です。

1.4. 全体最適の必要性

複数チームの組織では、チーム単位の最適化だけでは成果が出にくくなります。あるチームが作業を速く完了しても、次のチームで待機が発生すれば、全体のリードタイムは短くなりません。重要なのは、各チームの稼働率ではなく、組織全体として価値がどれだけ速く流れているかです。

全体最適を実現するには、チーム間の境界を越えてフローを見る必要があります。どのチームが忙しいかだけでなく、どの工程が価値提供を遅らせているのかを確認します。カンバンをスケールすることで、局所的な最適化を避け、組織全体の流れを改善する視点を持てます。

2. 単一チームカンバンの限界

単一チームのカンバンは、チーム内の作業状況を可視化し、フローを改善するうえで非常に有効です。しかし、複数チームが関わる組織では、単一チームのボードだけでは見えない問題が多くなります。

特に、部門間の待機時間、依存関係、引き継ぎの遅れ、組織全体のボトルネックは、単一チームのボードだけでは把握しにくいです。そのため、組織規模が大きくなるほど、カンバンをスケールして全体のフローを見る必要があります。

2.1. チーム内しか見えない

単一チームのカンバンボードでは、そのチームが管理している作業は見えます。しかし、他チームに依頼している作業や、他部門の承認待ち、外部チームとの調整状況は見えにくいままです。チーム内では順調に見えても、組織全体では作業が止まっていることがあります。

この限界を超えるには、チーム内のボードだけでなく、チーム間の作業や依存関係を可視化する仕組みが必要です。単一チームの進捗を集めるだけではなく、価値がどのチームを通って流れているのかを見えるようにすることが重要です。

2.2. 部門間の待機時間が見えない

単一チームのカンバンでは、部門間の待機時間が見えにくくなります。たとえば、開発は完了しているが法務確認で止まっている、デザイン確認待ちで実装に進めない、セキュリティレビューが詰まってリリースできないといった状況です。これらは、チーム内のボードだけでは把握できません。

部門間の待機時間は、組織全体のリードタイムを大きく伸ばします。実際の作業時間よりも、確認待ちや承認待ちの時間のほうが長い場合もあります。カンバンをスケールすることで、部門間の待機時間を可視化し、改善対象として扱えるようになります。

2.3. 依存関係を把握しにくい

複数チームで働く場合、依存関係は複雑になります。あるチームの作業が別チームの作業開始条件になっていたり、共通基盤の変更が複数チームに影響したりすることがあります。単一チームのカンバンでは、このような依存関係がボード外に隠れやすくなります。

依存関係が見えないと、計画の遅れや手戻りが発生しやすくなります。チームが自分たちの作業だけを見ていると、他チームへの影響を見落とす可能性があります。カンバンスケーリングでは、依存関係をカードやリンク、上位ボードで可視化し、調整しやすくすることが重要です。

2.4. 組織全体のボトルネックが分からない

単一チームのカンバンでは、チーム内のボトルネックは見つけやすいですが、組織全体のボトルネックは分かりにくいです。たとえば、複数チームからのレビュー依頼が一つの専門チームに集中している場合、その専門チームが組織全体の制約になっている可能性があります。

組織全体のボトルネックを見つけるには、チーム単位ではなく、価値提供の流れ全体を見る必要があります。どの工程に作業が溜まっているのか、どのチームに依頼が集中しているのかを可視化することで、全体の改善ポイントを特定できます。

3. カンバンをスケールする基本原則

カンバンをスケールする基本原則は、可視性を拡大し、フロー全体を管理し、システム思考で組織を捉えることです。チームごとの作業管理を増やすだけでは、スケーリングにはなりません。

重要なのは、価値が組織内をどのように流れているかを理解し、その流れを改善することです。個別チームの効率ではなく、顧客やユーザーに価値が届くまでの全体フローを最適化する視点が必要です。

3.1. 可視性を拡大する

カンバンをスケールする最初の原則は、可視性を拡大することです。単一チーム内のタスクだけでなく、チーム間をまたぐ作業、依存関係、待機時間、承認フロー、大規模案件の進捗を見えるようにします。見えない問題は改善できないため、可視化はスケーリングの出発点です。

可視性を拡大する際は、すべてを細かく見せればよいわけではありません。経営層、管理職、チーム、現場担当者では必要な情報の粒度が異なります。目的に応じて、チームボード、プログラムボード、ポートフォリオボードを分けることで、適切な可視性を確保できます。

3.2. フロー全体を管理する

カンバンのスケーリングでは、個々のチームの作業量だけでなく、フロー全体を管理する必要があります。企画からリリース、運用、フィードバックまでの流れを見て、どこで作業が止まっているのか、どこに負荷が集中しているのかを確認します。

フロー全体を管理することで、局所的な改善ではなく全体のリードタイム短縮につなげられます。たとえば、開発速度を上げてもレビュー工程が詰まっていれば、顧客への価値提供は速くなりません。全体の流れを見ながら改善することが、スケーリングの核心です。

3.3. システム思考を持つ

システム思考とは、個別の部分ではなく、全体のつながりや相互作用を見て問題を理解する考え方です。複数チームの組織では、一つのチームの改善が別のチームの負荷を増やすことがあります。そのため、個別の効率だけを見ると、全体としては悪化する場合があります。

カンバンをスケールするには、チームを個別の作業単位として見るのではなく、価値提供システムの一部として捉える必要があります。どのチームがどのサービスを提供し、どこで依存し、どこで待機が発生しているのかを考えることで、より本質的な改善が可能になります。

3.4. ローカル最適化を避ける

ローカル最適化とは、個々のチームや部門だけを最適化することです。あるチームが自分たちの作業を最大化しても、その作業が後工程に大量に流れ込み、レビューやテストが詰まれば、組織全体の効率は下がります。カンバンのスケーリングでは、このローカル最適化を避けることが重要です。

ローカル最適化を避けるには、チーム単位の指標だけでなく、全体のリードタイム、フロー効率、組織単位のWIPを見る必要があります。チームが忙しいかどうかではなく、価値がどれだけスムーズに顧客へ届いているかを基準にすることが大切です。

4. チーム単位の最適化が生む問題

チーム単位の最適化は、短期的には効果があるように見えます。しかし、複数チームが関わる組織では、個別チームの効率化が全体の効率化につながるとは限りません。むしろ、サイロ化や引き継ぎコストの増加を生むことがあります。

カンバンをスケールする目的は、チームごとの成果を競わせることではありません。組織全体の価値提供を改善することです。そのためには、チーム単位の最適化が生む問題を理解し、全体最適の視点を持つ必要があります。

4.1. サイロ化

サイロ化とは、チームや部門が自分たちの範囲だけを見て動き、他チームとの連携が弱くなる状態です。各チームが独自のボードや指標で作業を管理していると、チーム内では効率が良く見えても、組織全体では情報が分断されます。

サイロ化が進むと、チーム間の依存関係や待機時間が見えにくくなります。問題が発生しても、どのチームのどの工程で止まっているのかが分からず、解決に時間がかかります。カンバンをスケールすることで、サイロを越えて作業の流れを見えるようにする必要があります。

4.2. 作業の滞留

チーム単位で作業を最適化すると、後工程に作業が溜まることがあります。たとえば、開発チームが多くの機能を完成させても、レビューやテストを担当するチームの処理能力を超えれば、作業はそこで滞留します。結果として、全体のリードタイムは短くなりません。

作業の滞留を防ぐには、チームごとの生産量だけでなく、後工程の受け入れ能力を見る必要があります。カンバンでは、WIP制限やフロー指標を使って滞留を可視化できます。スケーリングでは、各チームの出力ではなく、全体の流れを管理することが重要です。

4.3. 引き継ぎコストの増加

複数チームで作業する場合、チーム間の引き継ぎが増えます。仕様、設計、コード、テスト結果、リスク、未解決事項などを別チームへ渡すたびに、情報の欠落や誤解が発生する可能性があります。引き継ぎが多いほど、作業の流れは遅くなります。

引き継ぎコストを下げるには、ハンドオフの状態を可視化し、必要な情報を標準化することが重要です。どの情報が揃えば次のチームが作業を開始できるのかを明確にすることで、手戻りや確認待ちを減らせます。カンバンは、引き継ぎの流れを管理するためにも有効です。

4.4. 全体効率の低下

チーム単位で最適化を進めると、各チームは忙しく動いているのに、組織全体の成果が出にくい状態になることがあります。これは、チームごとの稼働率を高めることが、必ずしも全体の価値提供速度を高めるわけではないからです。

全体効率を高めるには、組織全体のボトルネックに注目する必要があります。制約になっている工程を改善しない限り、他のチームが作業を増やしても全体の流れは改善されません。カンバンスケーリングでは、全体効率を基準に改善を進めることが重要です。

4.5. チーム最適と全体最適の違い

5. スケーリングにおける可視化の重要性

カンバンを複数チームへスケールするうえで、可視化は最も重要な出発点です。可視化が不十分な状態では、どのチームが何をしているのか、どこで待機が発生しているのか、どの依存関係がリスクなのかを判断できません。

可視化の目的は、監視することではありません。チームや組織が同じ状況を見ながら、改善すべきポイントを発見することです。スケーリングでは、作業の見える化に加えて、依存関係、待機時間、ボトルネックを可視化する必要があります。

5.1. フロー全体を見える化する

複数チームでカンバンを活用する場合、各チームのボードだけではなく、フロー全体を見える化する必要があります。アイデアや要求がどのように企画され、設計され、開発され、検証され、リリースされるのかを可視化することで、組織全体の流れを理解できます。

フロー全体が見えると、どこに作業が集中しているのか、どの工程で時間がかかっているのかを把握しやすくなります。これにより、チーム単位では気づけなかった問題を発見できます。フロー全体の可視化は、全体最適のための基盤です。

5.2. 依存関係を把握する

複数チームでは、依存関係の可視化が欠かせません。あるチームの作業が別チームの前提になっている場合、その関係が見えていないと、計画遅延や手戻りが発生しやすくなります。依存関係をボード上で表現することで、リスクを早めに把握できます。

依存関係は、カード間のリンク、タグ、色分け、依存関係ボードなどで表現できます。重要なのは、依存関係を頭の中や会議資料だけに閉じ込めないことです。チームが日常的に見える場所に依存関係を置くことで、調整がしやすくなります。

5.3. 待機時間を発見する

組織全体のリードタイムを長くする主な原因の一つが待機時間です。承認待ち、レビュー待ち、他チーム対応待ち、意思決定待ちなど、作業していない時間が長いほど、価値提供は遅くなります。待機時間は見えにくいため、意識的に可視化する必要があります。

カンバンでは、待機状態を専用の列やラベルで表現できます。たとえば、「レビュー待ち」「外部確認待ち」「承認待ち」のように状態を分けることで、どこで作業が止まっているのかを把握できます。待機時間を見えるようにすることで、改善対象を明確にできます。

5.4. ボトルネックを特定する

ボトルネックとは、全体の流れを遅くしている制約箇所です。複数チームの組織では、ボトルネックが単一チーム内ではなく、チーム間のハンドオフや専門チームの確認工程に存在することがあります。これを見つけるには、組織全体のフローを可視化する必要があります。

ボトルネックを特定できれば、改善の優先順位が明確になります。すべてのチームを同時に改善するのではなく、全体の流れを最も妨げている箇所に集中できます。カンバンのスケーリングでは、ボトルネックを組織レベルで見つけることが重要です。

6. チーム間依存関係を管理する方法

チーム間依存関係を管理することは、カンバンをスケールするうえで非常に重要です。依存関係が見えないまま作業を進めると、待機、手戻り、調整不足、納期遅延が発生しやすくなります。

依存関係を管理するには、依存タスクを可視化し、ハンドオフを明確にし、ブロッカーを共有し、チーム間のフローを同期する必要があります。これにより、複数チームでも作業を安定して流しやすくなります。

6.1. 依存タスクを可視化する

依存タスクとは、あるチームの作業が別チームの作業に影響するタスクです。たとえば、基盤チームのAPI提供が完了しないと機能チームが実装できない、デザインチームの画面設計が完了しないと開発が進められないといったケースです。こうした依存タスクは、ボード上で明確に示す必要があります。

依存タスクを可視化することで、チームは早めに調整できます。依存関係が見えていれば、作業順序を調整したり、先に確認すべき項目を洗い出したりできます。依存関係を隠したまま進めるのではなく、リスクとして見える場所に置くことが重要です。

6.2. ハンドオフを管理する

ハンドオフとは、あるチームから別のチームへ作業を引き渡すことです。複数チームの開発では、設計から開発、開発から品質保証、品質保証からリリース管理など、さまざまなハンドオフが発生します。ハンドオフが曖昧だと、作業の抜け漏れや待機時間が増えます。

ハンドオフを管理するには、引き渡し条件を明確にすることが重要です。どの情報が揃えば次のチームが作業を開始できるのか、何を完了とみなすのかを定義します。カンバンボード上でハンドオフ状態を見える化することで、引き継ぎの遅れを減らせます。

6.3. ブロッカーを共有する

ブロッカーとは、作業の進行を妨げている障害や未解決事項です。複数チームでは、あるチームのブロッカーが別チームの作業にも影響することがあります。そのため、ブロッカーはチーム内だけでなく、関係するチーム全体で共有する必要があります。

ブロッカーを共有するには、ボード上で目立つラベルや専用列を使うと有効です。ブロッカーが見えるようになれば、どのチームが支援できるのか、誰が意思決定すべきなのかを早く判断できます。ブロッカーは隠すものではなく、早く表面化させるべき情報です。

6.4. フローを同期する

複数チームで作業する場合、各チームのフローが完全に独立しているわけではありません。あるチームの遅れが別チームの待機を生み、後続工程全体に影響することがあります。そのため、チーム間でフローを同期する仕組みが必要です。

フローを同期するには、定期的な確認、共通のボード、依存関係レビュー、チーム間の調整ミーティングなどが有効です。ただし、会議を増やすことが目的ではありません。カンバンボード上の情報をもとに、必要な調整を短時間で行うことが重要です。

6.5. 図解推奨：チーム間依存関係の可視化例

このように依存関係を可視化すると、どの作業がどのチームに依存しているかが分かりやすくなります。依存先が止まっている場合、早めに調整や優先順位の見直しができます。

7. サービス指向でフローを考える

複数チームへカンバンをスケールする際は、チームを単なる作業単位ではなく、サービス提供者として捉えることが有効です。各チームは、他チームや顧客に対して何らかの価値や成果を提供しています。

サービス指向で考えると、チーム間の関係を需要と供給として整理できます。どのチームにどのような依頼が集まり、どの程度の処理能力があり、どのサービスレベルで対応するのかを明確にすることで、フローを改善しやすくなります。

7.1. チームをサービス提供者として捉える

チームをサービス提供者として捉えるとは、そのチームが誰に何を提供しているのかを明確にすることです。たとえば、基盤チームは認証やインフラを提供し、品質保証チームは検証サービスを提供し、デザインチームは画面設計やユーザー体験設計を提供します。

この視点を持つと、チームの作業は単なる内部タスクではなく、他者に価値を提供するサービスとして見えるようになります。サービスの利用者、入力、出力、期待される品質を定義することで、チーム間の連携が明確になります。

7.2. 需要と供給を管理する

サービス指向では、需要と供給のバランスを管理することが重要です。あるチームに依頼が集中し、そのチームの処理能力を超えると、作業は滞留します。これは組織全体のボトルネックになります。

カンバンを使うことで、各チームへの依頼量、進行中の作業、待機中の作業を可視化できます。需要が供給を超えている場合は、優先順位を調整する、支援体制を作る、作業を減らすなどの対策が必要です。需要と供給の管理は、組織全体のフロー改善に直結します。

7.3. サービスレベルを定義する

複数チームで働く場合、サービスレベルを定義することが有効です。サービスレベルとは、ある種類の依頼に対して、どの程度の時間や品質で対応するかを示す期待値です。たとえば、標準的なレビューは3営業日以内、緊急障害対応は即日対応といった形です。

サービスレベルが定義されていると、依頼側と対応側の期待値が揃いやすくなります。すべての依頼を同じ緊急度で扱うのではなく、種類や重要度に応じて扱い方を変えられます。カンバンでは、クラス・オブ・サービスと組み合わせて運用できます。

7.4. フロー効率を高める

サービス指向でカンバンを運用すると、フロー効率を高めやすくなります。各チームが自分たちの作業だけでなく、他チームへ提供する価値や待機時間を意識するようになるからです。これにより、チーム間の引き継ぎや依存関係を改善しやすくなります。

フロー効率を高めるには、作業中の時間だけでなく、待っている時間を減らすことが重要です。サービスとしての入力と出力を明確にし、依頼がどこで止まっているのかを可視化することで、組織全体の流れを改善できます。

8. エンタープライズカンバンとは

エンタープライズカンバンとは、企業や大規模組織全体でカンバンを活用し、複数チームや部門をまたぐフローを管理・改善する考え方です。単一チームのタスク管理ではなく、組織全体の価値提供を可視化することに重点があります。

エンタープライズカンバンでは、現場の作業だけでなく、プログラム、ポートフォリオ、戦略的施策、投資判断なども対象になります。目的は、組織の各階層をつなぎ、戦略から実行までの流れを見えるようにすることです。

8.1. 組織全体の可視化

エンタープライズカンバンでは、組織全体の作業や取り組みを可視化します。チームごとのボードだけでは見えない、大規模案件、部門横断プロジェクト、戦略的施策、承認待ちの作業を上位ボードで管理します。

組織全体の可視化により、経営層や管理職は、どの取り組みが進んでいるのか、どこで止まっているのかを把握しやすくなります。また、現場チームも、自分たちの作業がどの戦略や価値に結びついているのかを理解しやすくなります。

8.2. 複数チームの連携

エンタープライズカンバンは、複数チームの連携を支援します。各チームが個別に動くのではなく、組織全体のフローの中で自分たちの役割を理解することが重要です。依存関係やハンドオフを可視化することで、チーム間の調整をしやすくなります。

複数チームの連携では、共通の作業ルールや指標も必要になります。完了の定義、優先順位の判断基準、エスカレーションルールが揃っていないと、チーム間で認識のずれが生まれます。エンタープライズカンバンでは、連携を支える共通基盤を整えることが重要です。

8.3. 戦略と実行の接続

エンタープライズカンバンでは、戦略と実行を接続することが重要です。経営戦略や事業目標が現場のタスクにどうつながっているのかが見えなければ、組織は多くの作業をしていても、価値ある成果に結びつかない可能性があります。

ポートフォリオレベルのカンバンを使うことで、戦略的な取り組みがどの段階にあり、どのチームが関わり、どこで止まっているのかを可視化できます。これにより、経営層と現場が同じ情報を見ながら、優先順位や投資配分を議論しやすくなります。

8.4. フロー全体の最適化

エンタープライズカンバンの目的は、組織全体のフローを最適化することです。個々のチームが効率的に働いていても、部門間の待機時間や承認待ちが長ければ、顧客への価値提供は遅くなります。全体の流れを見て改善する必要があります。

フロー全体の最適化では、リードタイム、フロー効率、組織WIP、ボトルネックを確認します。どの工程が全体の速度を制約しているのかを見つけ、そこに改善を集中させます。エンタープライズカンバンは、組織全体の価値提供能力を高めるための方法です。

9. ポートフォリオレベルのカンバン

ポートフォリオレベルのカンバンとは、組織の戦略的な取り組みや大規模案件を可視化し、優先順位や投資配分、実行状況を管理するためのカンバンです。チームレベルのタスクではなく、より大きな単位の仕事を扱います。

ポートフォリオレベルのカンバンを使うことで、組織は何に投資しているのか、どの取り組みが進行中なのか、どこで意思決定や承認が止まっているのかを把握しやすくなります。戦略と実行をつなぐために有効です。

9.1. 戦略的優先順位を管理する

ポートフォリオレベルでは、戦略的優先順位の管理が重要です。すべての案件を同時に進めようとすると、リソースが分散し、どの取り組みも遅くなります。カンバンを使うことで、今本当に進めるべき取り組みを選び、進行中の案件数を制御できます。

戦略的優先順位を可視化すると、組織内の意思決定がしやすくなります。どの案件が事業目標に貢献するのか、どの案件を延期すべきか、どの案件に追加投資すべきかを議論できます。ポートフォリオカンバンは、戦略的な選択を見える化するための道具です。

9.2. 投資配分を可視化する

ポートフォリオレベルのカンバンでは、組織の投資配分を可視化できます。たとえば、新規開発、既存改善、技術的負債対応、運用保守、リスク対応にどれだけの作業量や予算が使われているかを見えるようにします。

投資配分が見えると、組織の意思決定が現実的になります。新規機能ばかりに投資して品質改善が不足していないか、短期案件が多すぎて長期戦略が進んでいないかを確認できます。カンバンは、投資判断を感覚ではなく可視化された情報に基づいて行うために役立ちます。

9.3. 大規模案件を管理する

大規模案件は、複数チームや複数部門にまたがるため、進捗や依存関係が複雑になります。ポートフォリオカンバンを使うことで、大規模案件がどの段階にあり、どのチームが関わり、どこにリスクがあるのかを把握できます。

大規模案件を管理する際は、細かいタスクまで上位ボードに載せる必要はありません。上位ボードでは、エピック、施策、プロジェクトなどの単位で状態を管理し、詳細は各チームのボードで管理します。階層ごとに適切な粒度を使い分けることが重要です。

9.4. 実行状況を把握する

ポートフォリオカンバンは、戦略的な取り組みの実行状況を把握するために役立ちます。計画中、承認待ち、実行中、検証中、完了といった状態を見える化することで、組織全体の進捗を確認できます。

実行状況を把握できれば、早めに軌道修正できます。進行中の案件が多すぎる場合は新規着手を抑え、特定の承認工程で止まっている場合は意思決定プロセスを見直します。ポートフォリオカンバンは、戦略を実行可能な流れに変えるための仕組みです。

9.5. チームカンバンとポートフォリオカンバンの関係

このように、チームカンバンとポートフォリオカンバンは扱う粒度が異なります。両者をつなげることで、現場の実行と組織の戦略を結び付けやすくなります。

10. 複数チームにおけるWIP制限

複数チームにおけるWIP制限では、チーム単位のWIPだけでなく、組織全体のWIPも考える必要があります。各チームが適切にWIPを制限していても、組織全体として案件を抱えすぎていれば、フローは悪化します。

スケーリングされたカンバンでは、ローカルWIPとグローバルWIPの両方を管理します。チーム内の作業量を制御しながら、組織全体で進行中の取り組みを増やしすぎないことが重要です。

10.1. チーム単位のWIP

チーム単位のWIPとは、各チームが同時に進める作業数のことです。開発中、レビュー中、テスト中などの工程に上限を設定することで、チーム内の作業過多を防ぎます。これは、単一チームのカンバンでも基本となる考え方です。

複数チーム環境でも、チーム単位のWIP制限は重要です。各チームが自分たちの処理能力を超えた作業を抱えないことで、品質低下やリードタイムの悪化を防げます。ただし、チーム単位のWIPだけでは全体最適には不十分です。

10.2. 組織単位のWIP

組織単位のWIPとは、組織全体で同時に進行している大きな取り組みや案件の数を制限する考え方です。大規模案件、部門横断施策、戦略的プロジェクトが多すぎると、チームや部門が分散し、どの案件も遅くなります。

組織単位のWIPを管理すると、経営層や管理者は「今、本当に進めるべき案件は何か」を判断しやすくなります。新しい案件を始める前に、既存の案件を完了させる意識が生まれます。これは、組織全体のリードタイム短縮に効果があります。

10.3. フロー全体の最適化

WIP制限は、フロー全体を最適化するために使うべきです。チームごとのWIPだけを守っていても、上流から大量の案件が流れ込めば、組織全体では作業過多になります。全体のフローを見ながら、どこに制限を置くべきかを考える必要があります。

フロー全体を最適化するには、ボトルネックとなっている工程の処理能力を考慮します。制約工程に過剰な作業を流し込まないようにすることで、待機時間を減らせます。WIP制限は、単なる数値ルールではなく、全体フローを守るための制御装置です。

10.4. 作業過多の防止

複数チームでは、作業過多が見えにくくなります。各チームが少しずつ無理をしていても、組織全体としては多くの案件を抱えすぎている場合があります。この状態では、優先順位が曖昧になり、レビューや承認も遅れやすくなります。

WIP制限を組織レベルで設定することで、作業過多を防ぎやすくなります。進行中の案件数を絞ることで、チームは重要な取り組みに集中できます。作業を増やすよりも、価値あるものを確実に完了させることが重要です。

10.5. ローカルWIPとグローバルWIPの違い

11. 共通の作業ルールを整備する

複数チームへカンバンをスケールするには、共通の作業ルールを整備する必要があります。各チームが独自のルールで運用していると、状態の意味や完了条件が揃わず、組織全体の可視化が難しくなります。

ただし、すべてを完全に統一する必要はありません。共通化すべき部分とチームごとに柔軟に調整する部分を分けることが重要です。スケーリングでは、共通性と適応性のバランスが求められます。

11.1. 完了の定義を統一する

完了の定義を統一することは、複数チームのカンバン運用で非常に重要です。あるチームでは実装完了をDoneとし、別のチームではレビューとテスト完了までをDoneとする場合、組織全体の進捗を正しく比較できません。

完了の定義を統一すると、作業状態の信頼性が高まります。どのチームのカードも同じ基準で完了していると分かれば、上位ボードやポートフォリオレベルでも進捗を把握しやすくなります。完了の定義は、品質と可視性を支える基本ルールです。

11.2. クラス・オブ・サービスを定義する

クラス・オブ・サービスとは、作業の種類や緊急度に応じて扱い方を分ける考え方です。たとえば、通常作業、固定期限作業、緊急対応、リスク対応などを区別します。複数チームでは、すべての作業を同じ優先度で扱うと混乱が起こります。

クラス・オブ・サービスを定義すると、作業の優先順位や対応ルールを明確にできます。緊急対応はどのように扱うのか、固定期限のある作業はどのタイミングで着手するのかを決めておくことで、チーム間の判断が揃いやすくなります。

11.3. エスカレーションルールを整備する

複数チームで作業する場合、ブロッカーや意思決定待ちが発生したときのエスカレーションルールが必要です。誰に相談すべきか、どの条件で上位判断を求めるのかが曖昧だと、作業が長く止まってしまいます。

エスカレーションルールを整備することで、問題を早く表面化できます。ブロッカーが一定期間解消されない場合は上位ボードに表示する、依存関係の遅れは関係チームで確認するなど、具体的なルールを設けると効果的です。

11.4. 可視化ルールを統一する

複数チームでカンバンを使う場合、可視化ルールの統一も重要です。カードの色、ラベル、状態、優先度、ブロッカー表示がチームごとに異なると、全体を見たときに意味を理解しにくくなります。最低限の共通ルールを決める必要があります。

一方で、チームごとの業務特性に合わせた調整も必要です。全社共通の基本ルールを持ちながら、チーム固有の列やラベルを追加できるようにすると、運用しやすくなります。可視化ルールは、統一と柔軟性の両方が重要です。

12. フロー指標を統一する

カンバンをスケールするには、フロー指標を統一して測定することが重要です。チームごとに異なる指標を見ていると、組織全体の状態を把握しにくくなります。共通の指標を使うことで、全体の改善ポイントを見つけやすくなります。

代表的な指標には、リードタイム、サイクルタイム、スループット、フロー効率があります。これらはチームを評価するためではなく、フローを改善するために使うべきです。

12.1. リードタイム

リードタイムとは、作業が依頼されてから完了するまでの時間です。複数チームのカンバンでは、リードタイムを見ることで、組織全体として価値提供にどれくらい時間がかかっているかを把握できます。

リードタイムが長い場合、作業そのものに時間がかかっているとは限りません。承認待ち、他チーム待ち、レビュー待ちなどの待機時間が長い可能性があります。リードタイムを測定することで、どこで価値提供が遅れているのかを確認できます。

12.2. サイクルタイム

サイクルタイムとは、作業に着手してから完了するまでの時間です。チームや工程ごとの処理速度を把握するために役立ちます。複数チームでは、どの工程のサイクルタイムが長いかを見ることで、改善ポイントを見つけられます。

サイクルタイムが長い工程は、ボトルネックになっている可能性があります。たとえば、開発は短いが品質保証のサイクルタイムが長い場合、検証体制やテスト自動化を見直す必要があるかもしれません。サイクルタイムは、工程ごとの改善に役立ちます。

12.3. スループット

スループットとは、一定期間に完了した作業量です。チーム単位では完了カード数、組織単位では完了した施策や案件数として見ることができます。スループットを見ることで、組織が安定して成果を出せているかを把握できます。

ただし、スループットは作業の粒度に影響されます。小さな作業と大きな案件を同じ1件として扱うと、判断を誤る可能性があります。そのため、スループットを見る際は、対象の粒度を揃えるか、レベルごとに分けて測定することが重要です。

12.4. フロー効率

フロー効率とは、作業が価値を生む活動として進んでいる時間と、待機している時間の割合を見る指標です。多くの組織では、実作業よりも待機時間のほうが長くなっている場合があります。フロー効率を見ることで、待機時間の多さに気づけます。

フロー効率を改善するには、作業時間を短くするだけでなく、待ち時間を減らすことが重要です。承認待ち、レビュー待ち、依存関係待ちを減らせば、全体のリードタイムを短縮できます。フロー効率は、複数チームの改善で特に重要な指標です。

12.5. スケーリングカンバンで活用する主要指標

13. ボトルネックを組織レベルで管理する

複数チームにカンバンをスケールする場合、ボトルネックを組織レベルで管理する必要があります。チーム内のボトルネックだけでなく、部門間、承認工程、専門チーム、レビュー工程などが全体の制約になることがあります。

組織レベルのボトルネックを管理するには、制約条件を特定し、フローを改善し、待機時間を削減し、全体最適化を進めることが重要です。ボトルネックを見つけても、チーム単位でしか対応しなければ根本改善にはつながりません。

13.1. 制約条件を特定する

制約条件とは、全体の流れを最も制限している要素です。複数チームの組織では、特定の専門チーム、承認者、レビュー工程、テスト環境、意思決定プロセスが制約条件になることがあります。まずは、どこが全体の速度を決めているのかを特定する必要があります。

制約条件を特定するには、WIP、リードタイム、待機時間、滞留箇所を確認します。作業が常に溜まっている工程や、依頼が集中しているチームは、制約になっている可能性があります。制約を見つけることが、組織改善の第一歩です。

13.2. フローを改善する

制約条件が分かったら、フロー改善に取り組みます。制約となっている工程の処理能力を高める、依頼量を制御する、作業を小さく分ける、事前確認を強化するなどの対策が考えられます。重要なのは、全体の流れを改善することです。

フロー改善では、制約ではない部分を改善しても効果が小さい場合があります。たとえば、開発速度をさらに上げても、リリース承認が詰まっていれば全体のリードタイムは変わりません。ボトルネックに集中して改善することが効果的です。

13.3. 待機時間を削減する

組織レベルの改善では、待機時間の削減が重要です。作業そのものは短時間で終わっていても、承認待ちや他チーム待ちが長ければ、価値提供は遅れます。待機時間は見えにくいため、意識的に測定・可視化する必要があります。

待機時間を削減するには、ハンドオフ条件の明確化、レビュー体制の改善、意思決定ルールの整備、WIP制限の導入が有効です。作業を速くするだけでなく、作業が止まらないようにすることが重要です。

13.4. 全体最適化を進める

ボトルネック管理の目的は、組織全体を最適化することです。個々のチームが最大限忙しく働くことではなく、価値が顧客に届くまでの流れを最短化し、安定させることが重要です。そのためには、チーム間の協力が欠かせません。

全体最適化を進めるには、共通の指標と可視化が必要です。各チームが同じフローを見ながら、どこを改善すれば全体に最も効果があるかを考えます。組織レベルのカンバンは、全体最適のための対話を生む基盤になります。

14. スクラムチームとカンバンスケーリング

スクラムチームが複数存在する組織でも、カンバンスケーリングは有効です。スクラムはスプリントを中心に開発を進めますが、複数チーム間の依存関係や組織全体のフロー管理には、カンバンの可視化とWIP制限が役立ちます。

スクラムとカンバンは対立するものではありません。スクラムのイベントや役割を維持しながら、カンバンでフローを見える化し、チーム間調整や継続的改善を強化できます。

14.1. スクラムとの併用

スクラムチームは、スプリントバックログや作業状態をカンバンボードで可視化できます。スプリント内の作業を「未着手」「開発中」「レビュー中」「テスト中」「完了」といった状態で管理すれば、スプリント中のフローが見えやすくなります。

複数のスクラムチームがある場合は、各チームのボードに加えて、チーム間の依存関係を管理する上位ボードを用意できます。これにより、スクラムの枠組みを保ちながら、組織全体の作業の流れを改善できます。

14.2. フロー管理の強化

スクラムでは、スプリントゴールの達成が重要です。しかし、スプリント内で作業が滞留している場合、チームはゴール達成に苦労します。カンバンを併用すると、作業がどこで止まっているのかを把握しやすくなります。

フロー管理を強化することで、スクラムチームはスプリント終盤の未完了作業を減らしやすくなります。レビュー待ちやテスト待ちのWIPを制限し、完了を優先することで、スプリントの安定性が高まります。

14.3. クロスチーム調整

複数のスクラムチームでは、チーム間調整が重要になります。あるチームの作業が別チームの前提になる場合、依存関係を早めに把握し、計画に反映する必要があります。カンバンは、この依存関係を可視化するために有効です。

クロスチーム調整では、定例会議だけに頼るのではなく、ボード上で依存関係やブロッカーを見えるようにすることが重要です。これにより、会議の内容も具体的になり、調整の速度が上がります。

14.4. 継続的改善

スクラムでは、レトロスペクティブを通じて継続的改善を行います。カンバンを併用すると、リードタイム、サイクルタイム、WIP、滞留時間といったデータを使って改善を議論できます。感覚だけでなく、フロー指標に基づく改善が可能になります。

継続的改善では、チーム内だけでなくチーム間の課題も扱う必要があります。複数チームの依存関係や待機時間を可視化すれば、組織レベルの改善テーマを見つけやすくなります。カンバンは、スクラムの改善活動を補強する役割を持ちます。

14.5. スクラム・オブ・スクラムとカンバンスケーリングの違い

15. AI時代におけるカンバンスケーリング

AI時代において、カンバンスケーリングの重要性はさらに高まります。AIによってコード、テスト、ドキュメント、タスク案、改善案の生成速度が上がる一方で、それらを確認し、レビューし、組織のフローに乗せる管理が必要になるからです。

AIは作業生成を加速しますが、価値提供までの流れを自動的に最適化するわけではありません。むしろ、生成物が増えすぎることでレビュー工程や意思決定工程がボトルネックになる可能性があります。

15.1. タスク生成速度の向上

AIを活用すると、ユーザーストーリー、技術仕様、コード、テストケース、改善案を短時間で生成できます。これにより、チームは以前より多くの作業候補を持つようになります。生成速度の向上は大きなメリットですが、同時に管理すべき作業量も増えます。

カンバンスケーリングでは、AIによって増えた作業候補を適切に選別し、優先順位を付け、WIP制限で流量を管理する必要があります。生成できる量ではなく、確認し、完了できる量を基準にすることが重要です。

15.2. レビュー工程の増加

AIが生成した成果物は、人間によるレビューが必要です。コード、仕様書、テストケース、設計案などは、AIが作ったからといってそのまま安全に使えるわけではありません。組織全体でAI活用が進むと、レビュー工程に負荷が集中しやすくなります。

レビュー工程がボトルネックになると、生成物は増えているのに完了が遅くなる状態になります。カンバンでは、レビュー中のWIPや待機時間を可視化することで、レビュー負荷を管理できます。AI時代には、レビュー工程を組織レベルで見ることが重要です。

15.3. フロー管理の重要性向上

AIによって個別作業の速度が上がっても、全体のフローが良くなるとは限りません。生成、レビュー、修正、承認、リリース、運用のどこかで詰まれば、価値提供は遅れます。AI時代ほど、フロー管理の重要性は高まります。

カンバンスケーリングは、AIによって増えた作業を組織全体でどう流すかを考えるために有効です。単にAIを導入するのではなく、AIが生み出した作業をどの工程で確認し、どの基準で完了させるのかを設計する必要があります。

15.4. ボトルネックの変化

AI時代には、ボトルネックの位置が変わる可能性があります。以前は実装がボトルネックだったチームでも、AIによって実装が速くなると、レビュー、品質保証、セキュリティ確認、プロダクト判断が新たなボトルネックになることがあります。

ボトルネックが変化するため、組織は継続的にフローを観察する必要があります。一度改善した工程が、将来も制約であり続けるとは限りません。カンバンを使ってフロー指標を確認し、現在のボトルネックに合わせて改善を続けることが重要です。

16. スケーリングでよくある失敗

カンバンのスケーリングでは、よくある失敗があります。ボードだけを増やす、指標を共有しない、ローカル最適化に陥る、フローを測定しないといった失敗は、組織全体の改善を妨げます。

スケーリングは、単にツールやボードを大規模に展開することではありません。組織全体のフローを見える化し、データに基づいて改善し、チーム間の協力を促すことが目的です。

16.1. ボードだけを増やす

よくある失敗は、各チームにカンバンボードを作るだけで満足してしまうことです。ボードが増えても、チーム間の依存関係や組織全体のフローが見えなければ、スケーリングにはなりません。むしろ、情報が分散し、全体像が見えにくくなることもあります。

ボードを増やす場合は、ボード同士の関係を設計する必要があります。チームボード、プログラムボード、ポートフォリオボードをどのようにつなげるのか、どの情報を上位に集約するのかを決めることが重要です。

16.2. 指標を共有しない

チームごとに異なる指標を使っていると、組織全体の改善が難しくなります。あるチームは完了数を重視し、別のチームは稼働率を重視し、さらに別のチームは期限だけを見ている場合、全体のフローを比較できません。

カンバンをスケールするには、共通のフロー指標を共有する必要があります。リードタイム、サイクルタイム、WIP、スループット、フロー効率などを共通言語にすることで、チーム間の対話が具体的になります。

16.3. ローカル最適化に陥る

ローカル最適化に陥ると、各チームは自分たちの効率を高めようとしますが、組織全体の流れは改善されません。あるチームが大量に作業を完了しても、後工程が詰まれば全体のリードタイムは短くなりません。

ローカル最適化を避けるには、全体のフロー指標を見る必要があります。チーム別の成果だけでなく、顧客に価値が届くまでの時間を重視します。カンバンスケーリングでは、チームの成功と組織全体の成功を結び付けることが重要です。

16.4. フローを測定しない

カンバンを導入しても、フローを測定しなければ改善は感覚的になります。どこで作業が止まっているのか、リードタイムが伸びている原因は何か、WIPが増えすぎていないかを確認できません。測定しないフローは改善しにくいです。

フローを測定することで、改善の優先順位が明確になります。数値はチームを責めるためではなく、システムを改善するために使います。カンバンスケーリングでは、可視化と測定をセットで運用することが重要です。

16.5. カンバンスケーリングでよくある課題と対策

17. 複数チームへのカンバン導入を成功させる方法

複数チームへのカンバン導入を成功させるには、可視化から始め、フロー全体を見て、データに基づいて改善し、継続的に進化させることが重要です。最初から完璧な仕組みを作る必要はありません。

重要なのは、組織の現状を見えるようにし、小さな改善を続けることです。カンバンのスケーリングは一度の導入プロジェクトではなく、組織の働き方を継続的に改善する取り組みです。

17.1. 可視化から始める

複数チームへのカンバン導入は、まず可視化から始めるべきです。現在どのチームが何をしているのか、どの作業が他チームに依存しているのか、どこで待機しているのかを見えるようにします。可視化がなければ、改善すべき問題を特定できません。

最初から複雑なボードを作る必要はありません。まずは主要な作業の流れ、依存関係、ボトルネックを見える化することから始めます。現状を正しく見ることが、スケーリングの第一歩です。

17.2. フロー全体を見る

カンバンを複数チームへ広げる際は、チーム単位ではなくフロー全体を見ることが重要です。企画からリリースまで、価値がどのように流れているかを確認します。チーム内の効率だけを見ていると、全体のボトルネックを見落とします。

フロー全体を見ることで、改善の優先順位が変わることがあります。最も忙しいチームではなく、全体の流れを制約している工程に集中すべき場合があります。全体視点を持つことが、カンバンスケーリングの成功につながります。

17.3. データに基づいて改善する

スケーリングされたカンバンでは、データに基づく改善が重要です。リードタイム、サイクルタイム、WIP、スループット、フロー効率を確認することで、感覚ではなく事実に基づいて改善できます。データは、組織全体の状態を理解するための共通言語になります。

ただし、データは評価や監視のためだけに使うべきではありません。目的は、チームや組織を責めることではなく、フローを妨げているシステム上の問題を見つけることです。データをもとに対話し、改善策を試すことが大切です。

17.4. 継続的に進化させる

カンバンのスケーリングは、一度設計して終わりではありません。組織の構造、チームの役割、事業戦略、技術環境が変われば、カンバンの運用も変える必要があります。継続的に見直し、進化させることが重要です。

継続的に進化させるには、定期的な振り返りと改善が必要です。ボードの構成、WIP制限、指標、依存関係の管理方法を見直し、現状に合った形へ調整します。カンバンは固定された仕組みではなく、組織とともに成長するフロー改善の方法です。

おわりに

複数チームへカンバンをスケールする目的は、単にチームごとのボードを増やすことではありません。組織全体の価値提供の流れを可視化し、チーム間の依存関係や待機時間、ボトルネックを明らかにし、全体最適を実現することです。単一チームのカンバンでは見えない問題も、スケーリングによって組織レベルで扱えるようになります。

カンバンスケーリングでは、可視性の拡大、フロー全体の管理、システム思考、ローカル最適化の回避が重要です。さらに、チーム間依存関係の可視化、サービス指向の考え方、ポートフォリオレベルのカンバン、組織単位のWIP制限、共通の作業ルールとフロー指標が必要になります。これらを整えることで、複数チームでも安定したフローを作りやすくなります。

AI時代には、カンバンスケーリングの重要性がさらに高まります。AIによってタスクや成果物の生成速度が上がる一方で、人間によるレビュー、品質確認、意思決定の工程が新たなボトルネックになる可能性があるからです。組織全体のフローを見える化し、WIPを適切に制御し、データに基づいて継続的に改善することで、複数チームはより速く、より安定して価値を届けられるようになります。