カンバン方式: 連続フローと WIP 制限
カンバン に基づくアジャイル手法です。 連続的な流れ 仕事の、 タイムボックス化された反復なしで。トヨタ生産方式を起源とするかんばん方式は、 視覚化, WIP の制限 (作業中) e フローの最適化.
🎯 何を学ぶか
- カンバンの 4 つの基本原則
- カンバンの6つの実践（見える化、WIP制限、フロー管理）
- 効果的なカンバンボードを作成して使用する方法
- WIP 制限: 制限の内容とその決定方法
- フロー指標: リードタイム、サイクルタイム、スループット
- ボトルネックを特定するための累積フロー図 (CFD)
- カンバンとスクラム: 違いとそれぞれをいつ使用するか
カンバンの起源
カンバン（看板、文字通り「カード」）は 1940 年代に誕生しました。 トヨタ 生産管理システムとして ジャストインタイム (JIT)。 目標は、必要なときに、必要なものだけを生産し、廃棄物と在庫を削減することです。
🏭 製造からソフトウェアまで
2004年に、 デビッド・J・アンダーソン カンバンをソフトウェア開発に適応させ、 WIP 制限、フロー メトリクス、継続的な進化的改善などの概念を導入します。
- 2004年: アンダーソンはマイクロソフトでカンバンを適用します
- 2007年: Corbis で文書化された最初のカンバン システム
- 2010年: 書籍『カンバン: テクノロジー ビジネスの進化的変化を成功させる』
- 今日： アジャイルとDevOpsで広く採用されているカンバン
カンバンの 4 つの基本原則
基本原則
🔵 1. START WITH WHAT YOU DO NOW
└─ Non serve rivoluzione: inizia dal processo attuale
🔵 2. AGREE TO PURSUE INCREMENTAL, EVOLUTIONARY CHANGE
└─ Cambiamenti piccoli e continui (no big bang)
🔵 3. RESPECT CURRENT ROLES, RESPONSIBILITIES & TITLES
└─ Nessun cambio organizzativo drastico richiesto
🔵 4. ENCOURAGE ACTS OF LEADERSHIP AT ALL LEVELS
└─ Chiunque può proporre miglioramenti🌱 進化的アプローチ
スクラム (特定の役割と決まった儀式が必要) とは異なり、カンバンは 進化的な: 既存のプロセスの上に適用され、徐々に改善されます。
例：
- チームはすでにアドホック プロセスを使用していますか? → 現在の流れを地図上に表示、船上で表示
- 2 週間後: 「進行中」に WIP 制限を導入します (例: 最大 5 つのタスク)
- 1 か月後: 「コード レビュー」列を追加して、そのステップを明示します。
- 継続的: リードタイムの測定、ボトルネックの特定、適応
カンバンの 6 つの実践
1. ワークフローを可視化する（Visualize）
作品とその流れを作る 明示的で目に見える カンバンボードを介して全員に送信します。
例: 開発チームのかんばんボード
KANBAN BOARD - Software Development
┌────────────┬────────────┬────────────┬────────────┬────────────┬────────────┐
│ BACKLOG │ TO DO │IN PROGRESS │CODE REVIEW │ TESTING │ DONE │
│ │ │ (WIP: 5) │ (WIP: 3) │ (WIP: 4) │ │
├────────────┼────────────┼────────────┼────────────┼────────────┼────────────┤
│ │ │ │ │ │ │
│ [Story 50] │ [Story 12] │ [Story 8] │ [Story 5] │ [Story 3] │ [Story 1] │
│ [Story 51] │ [Story 13] │ [Story 9] │ [Story 6] │ [Story 4] │ [Story 2] │
│ [Story 52] │ [Story 14] │ [Story 10] │ [Story 7] │ │ │
│ ... │ │ │ │ │ │
│ │ │ │ │ │ │
│ 100+ items │ 10 items │ 3 items │ 3 items │ 2 items │ 25 items │
└────────────┴────────────┴────────────┴────────────┴────────────┴────────────┘
🔴 WIP LIMIT VIOLATED: "Code Review" ha 3/3 items → BLOCCO!
⚠️ Team deve completare review prima di pullare nuovo lavoro✅ 良いボード
- 実際の流れを反映した列
- WIP 制限が表示される
- 重要な情報が記載されたカード
- ハイライトされたブロッカー (🚫)
- 優先順位/タイプ別のスイムレーン
- リアルタイムで更新されます
❌ 無効な取締役会
- 一般的な列 (To Do/Done)
- WIP制限なし
- 詳細のないカード
- 隠れたブロッカー
- 現実を反映していない
- 決して更新されない
2. 進行中の作業を制限する (WIP を制限する)
カンバンの最も重要な概念: 限界 実行できるタスクの数 各列に同時に「進行中」と表示されます。
🎯 WIP を制限する理由?
- 集中： マルチタスクが減る = 集中力が高まる
- 品質： 仕事は始めて放棄するよりも完了させる方がよい
- スループット： 逆説的ですが、WIP を制限すると生産量が増加します (リトルの法則)
- ボトルネックの可視性: 列がいっぱいになると問題が明らかになる
- コラボレーション： チームは列全体を「空にする」のを支援します（群がる）
WIP 制限を決定する方法
📊 METODI PER CALCOLARE WIP LIMIT
🔵 METODO 1: Number of People
WIP limit = Numero di persone × 1.5
Es: Team di 5 persone
- In Progress WIP = 5 × 1.5 = 7-8 task max
🔵 METODO 2: Start Conservative
WIP limit = Numero di persone ÷ 2
Es: Team di 6 persone
- In Progress WIP = 6 ÷ 2 = 3 task (molto stretto!)
- Adatta se team si blocca troppo spesso
🔵 METODO 3: Current State + Reduce
1. Conta quanti task sono tipicamente "in progress"
2. Riduci del 20-30%
3. Monitora e adatta
Es: Mediamente 12 task in progress
- Imposta WIP limit = 8-10
- Osserva effetti su lead time
🔴 REGOLA D'ORO: Start low, adjust up
È meglio iniziare con WIP limit troppo basso e alzarlo
che viceversa (limiti alti = status quo)⚠️ WIP 制限に違反しました: どうすればよいですか?
シナリオ： 「コード レビュー」列には WIP 制限 3 があり、いっぱいです。
❌ してはいけないこと: 制限を無視してタスクを追加します
✅ やるべきこと:
- ラインを停止します: その欄に新しい作品を持ち込まないでください
- 群がる: チームは協力して列を空にします (全員がコードレビューを行います)
- ボトルネックを特定する: なぜその欄が埋まってしまうのでしょうか？ (例: 1 人のコードレビュー担当者?)
- 根本原因に対処します: 是正措置 (例: より多くのレビュー担当者をトレーニングする)
3. フローの管理
を監視して最適化する 流れ システムを通じた仕事の推進。客観的： スムーズで予測可能な流れ 蓄積や閉塞がありません。
🌊 良い流れの特徴
- スムーズ（滑らか）： 仕事はスパートではなく着実に進む
- 予測可能 (予測可能): 一貫したリードタイム
- 速い (速い): ご依頼から納品までの時間を短縮
- ブロッカーなし: 障害物はすぐに取り除かれます
問題のある流量インジケーター
🚨 RED FLAGS
❌ ACCUMULO (Queue Buildup)
Colonna sempre piena, task si accumulano
└─ Bottleneck! Aumenta capacità o riduci WIP a monte
❌ BLOCKERS FREQUENTI
Task bloccati (🚫) per giorni
└─ Dipendenze non gestite, decisioni lente
❌ LEAD TIME CRESCENTE
Tempo medio per completare task aumenta nel tempo
└─ Sistema sta rallentando, technical debt?
❌ LAVORO "SALTATO"
Task saltano colonne (es: To Do → Done senza Code Review)
└─ Board non riflette processo reale
✅ GOOD FLOW INDICATORS
✅ Work moves steadily left-to-right
✅ Lead time stabile o in diminuzione
✅ WIP limits rispettati
✅ Throughput consistente (es: 10 task/settimana)4. ポリシーを明示的にする
を明確に定義します。 ルール タスクが 1 つのタスクから移行できるときのために 列を別の列に移動します (各ステップの完了の定義)。
例: 移行ポリシー
📋 PULL POLICIES (Quando posso muovere una card?)
To Do → In Progress:
✅ Acceptance criteria chiari
✅ Dependencies risolte
✅ Assegnata a developer
✅ WIP limit "In Progress" non raggiunto
In Progress → Code Review:
✅ Codice compilato senza errori
✅ Unit tests scritti e passati
✅ Self-review completato
✅ WIP limit "Code Review" non raggiunto
Code Review → Testing:
✅ Almeno 2 reviewers hanno approvato
✅ Tutti i commenti risolti
✅ Merged su branch principale
✅ WIP limit "Testing" non raggiunto
Testing → Done:
✅ Test plan eseguito
✅ Nessun bug P0/P1 aperto
✅ Product Owner ha accettato
✅ Deployato in staging5. フィードバックループ
システムの検査と適応のために定期的なフィードバック ループを実装します。
🔄カンバン会議
- 毎日のスタンドアップ: 15 分、ボードを右から左に歩きます
- 補充： いつタスクをボードに追加するか (例: 毎週)
- 配送計画: 配信の約束 (例: 隔週)
- サービス提供のレビュー: 指標とパフォーマンス (月次)
- 運用レビュー: システム改善（四半期ごと）
📊 確認すべき指標
- リードタイムの傾向
- カラムあたりのサイクルタイム
- スループット (タスク/週)
- 流量効率
- ブロッカーの頻度
- WIPの配布
6. 協力して改善する
科学的モデルと実験的手法を使用して、 カイゼン （継続的な改善）。
🔬科学的アプローチ
- 仮説： 「WIP 制限を 8 から 5 に削減すれば、リードタイムは短縮されます。」
- 実験： 2週間変化を試してください
- 測定： 前後のリードタイムを比較する
- 彼は次のように決めます。 改善する場合はそのままにし、改善しない場合はロールバックする
カンバン指標: リードタイム、サイクルタイム、スループット
1. リードタイム
意味： タスクがシステムに入ってから完了するまでの合計時間。
リードタイムの例
📅 STORY #123: "Add forgot password feature"
Timeline:
├─ Day 1: Task aggiunto al Backlog
├─ Day 3: Task pullato in "To Do"
├─ Day 5: Development inizia ("In Progress")
├─ Day 8: Code review ("Code Review")
├─ Day 9: Testing ("Testing")
└─ Day 10: Done
📊 LEAD TIME = 10 giorni (da entry a done)
📊 CYCLE TIME = 5 giorni (da "In Progress" a "Done")
Lead Time include il tempo di attesa in backlog/queue
Cycle Time è solo il tempo di lavoro attivo📈 リードタイム
- 顧客対応時間
- ご依頼からお届けまで
- 待機列を含む
- 外部コミットメントの指標
- 目標：継続的に削減
⏱️サイクルタイム
- 実労働時間
- 最初から最後まで
- 待機/キューを除外する
- チーム効率の指標
- 目標: 低く安定した状態を保つ
2. スループット
意味： 単位時間当たりに完了したタスクの数 (例: タスク/週)。
スループットチャート
Tasks Completed per Week
↑
14 │ ●
12 │ ● ●
10 │ ● ● ●
8 │ ● ●
6 │
4 │
2 │
0 └───────────────────────────────→ Weeks
W1 W2 W3 W4 W5 W6 W7
Average Throughput: 10 task/week
Min: 8, Max: 14
📊 INSIGHTS:
- Team completa mediamente 10 task/settimana
- Usare per forecast: "80% confidence: 8-12 task/settimana"
- Variabilità relativamente bassa (good!)3. 累積フロー図 (CFD)
Il CFD カンバンで最も強力なチャートです。作業の蓄積を示します。 時間の経過とともに各列に表示されます。
CFDの読み方
Cumulative Tasks
↑
60 │ ┌─ DONE
│ ┌────┘
50 │ ┌────┘ ├─ TESTING
│ ┌────┘ ├─ CODE REVIEW
40 │ ┌───┘ ├─ IN PROGRESS
│ │ ├─ TO DO
30 │ │ └─ BACKLOG
│ │
20 │ │
│ │
10 │ │
│ │
0 └─┴────────────────────────────────→ Time
W1 W2 W3 W4 W5 W6
✅ HEALTHY CFD:
- Bande parallele (flusso costante)
- Larghezza banda = WIP in quella fase
- Pendenza = velocità di completamento
🚨 PROBLEMI VISIBILI:
- Banda "TO DO" si allarga → Accumulo! Bottleneck downstream
- Banda "CODE REVIEW" molto larga → WIP limit troppo alto o processo lento
- Bande irregolari → Flusso instabileカンバンとスクラム: 詳細な比較
| 待ってます | カンバン | スクラム |
|---|---|---|
| 反復 | 継続的な流れ、スプリントなし | スプリントのタイムボックス化 (1 ～ 4 週間) |
| 役割 | 規定された役割はありません | PO、スクラムマスター、開発チーム |
| 会議 | 必要に応じてオプション | 5つの義務的な儀式 |
| 献身 | 範囲に関するコミットメントなし | スプリントへの取り組み |
| 優先度 | 継続的に変化する可能性がある | スプリント中に修正されました |
| WIP 制限 | 明示的かつ必須の WIP 制限 | 暗黙的 (キャパシティ スプリント) |
| メトリクス | リードタイム、サイクルタイム、CFD | ベロシティ、バーンダウン |
| ボード | 継続的で常に表示される | スプリントごとにリセットする |
| 変化 | 進化的、段階的 | 完全な導入が必要 |
| ベストフォー | サポート、メンテナンス、おっと | 製品開発、プロジェクト |
カンバンを使用する場合
✅ カンバンは次の場合に最適です。
- サポートとメンテナンス: 作業項目は継続的に到着します (バッチなし)
- 運用/DevOps: インシデント管理、導入パイプライン
- 成熟したアジャイル チーム: スクラムよりも柔軟性を求めている
- 可変優先度を使用して作業します。 頻繁に発生する緊急事態 (重大なバグなど)
- 複数の関係者: さまざまなところからのリクエスト
- 継続的配信: 非常に頻繁なデプロイ (毎日でも)
⚠️ カンバンは次の場合に困難になる可能性があります:
- アジャイルを初めて使用するチーム: スクラムよりも構造が弱く、規律が必要
- 期限が決まっているプロジェクト: スプリントはペースとマイルストーンを提供します
- 規律のない分散したチーム: 同期するには儀式が必要です
- コミットメントに慣れている関係者: 彼らは「スプリント X の準備が整うもの」を好みます。
スクラムバン: 両方の長所
スクラムバン スクラムとカンバンを組み合わせて、両方の長所を活かします。
スクラムバンハイブリッドアプローチ
🔵 DA SCRUM:
├─ Sprint time-boxed (1-2 settimane)
├─ Sprint Planning meeting
├─ Sprint Review/Demo
├─ Retrospective
└─ Ruoli opzionali (PO, SM)
🟢 DA KANBAN:
├─ Kanban board con visualizzazione flusso
├─ WIP limits espliciti
├─ Pull system
├─ Metriche: Lead Time, CFD
└─ Nessun commitment fisso su scope
✅ QUANDO USARE SCRUMBAN:
- Team Scrum che vuole più flessibilità
- Kanban team che vuole ritmo regolare
- Supporto + development misti
- Transizione graduale Scrum → Kanbanカンバンの実装: ステップバイステップ ガイド
🚀 カンバン導入のロードマップ
1～2週目: 見る
- 現在のワークフローを（実際に）マッピングする
- 物理ボードまたはデジタルボード (Trello、Jira など) を作成する
- 実際のステップを反映する列を定義する
- 現在の作業項目をボードに入力します
第 3 ～ 4 週目: WIP を制限する
- 通常、各列にどれくらいのタスクがあるかを確認します。
- 初期 WIP 制限を設定します (保守的)
- 意味と重要性についてチームを教育する
- 違反とブロックを監視する
2 か月目: フローの管理
- 毎日のスタンドアップ（ボードを歩く）を実施する
- 阻害要因を特定して表示する
- リードタイムの計測を開始する
- 最初の CFD を手動またはツールを使用して作成する
3 か月目以降: 最適化
- 明示的なポリシーの定義 (各列の DoD)
- 定期的なフィードバック ループの導入
- 改善のための管理実験（カイゼン）
- データに基づいてシステムをスケーリングまたは適応させる
結論
カンバンは手法です 強力かつ柔軟な ワークフローを管理するため、 特に次のようなコンテキストに適しています 高い変動性 e 継続的デリバリー。 成功の鍵は、WIP 制限を遵守する規律と、目標を達成するための指標の一貫した使用です。 改善。
💡 キーポイント
- カンバンはタイムボックス化された反復ではなく、継続的なフローに基づいています
- WIP 制限はかんばんの中心です: 焦点とボトルネックの可視性
- 主要な指標: リードタイム、サイクルタイム、スループット、CFD
- 進化的アプローチ: 今やっていることから始めて、徐々に改善していきます
- カンバンはスクラムほど規範性が低く、より規律が必要です
- さまざまな優先順位を持つサポート、運用、チームに最適
- スクラムバンはスクラムとカンバンよりも優れた組み合わせです
📚 次の記事
次の記事では、詳しく見ていきます XP、リーン、DevOps: 極端な技術的実践 (TDD、ペア プログラミング、CI/CD)、無駄の排除、継続的デリバリーのための DevOps 文化。