살아 있는 소프트웨어는 엠파시가 만듭니다

Appearance

スクラムバン(Scrumban) ​

要約一行: スクラムバンはスクラムの構造（役割/会議/バックログの概念）とカンバンのフロー中心・WIP制限（Work In Progress制限）を結合したプロセスです。スプリントの厳格さの代わりにフロー(Flow)とプル(Pull)を重視しつつ、必要な箇所にスクラム式の儀式（計画・振り返り）を維持します。

紹介・定義 ​

スクラムバン(Scrumban)は、ソフトウェア開発およびナレッジワークチームが柔軟にワークフローを管理できるように設計されたハイブリッドプロセスです。

  • スクラム: 反復（スプリント）、固定されたイベント（スプリントプランニング・レビュー・レトロスペクティブ）、明確な役割
  • カンバン: 視覚的ボード、WIP制限、プルベースの作業、継続的改善 スクラムバンは上記2つのアプローチのメリットを取り入れ、現実的なフローの改善に焦点を当てます。

いつスクラムバンを使うのが良いか？ ​

  • 既存でスクラムを使用しているが、頻繁な変更（緊急要請）が多く、スプリントでまとめるのが難しい。
  • カンバンでフローを回しているが、バックログ管理・優先順位・定期的な振り返りのような規律が必要なチーム。
  • 保守・運用・サポート（運用作業＋新機能開発が混在）チーム。
  • 予測よりも継続的デリバリー(continuous delivery)とフローの最適化を重視する場合。

コアコンセプト ​

  1. プル(Pull)システム: 作業はチームが処理可能な時点でのみ開始（次の列に引き込む）。
  2. WIP（進行中の作業）制限: 同時に進行する作業数を制限し、マルチタスクを減らして完了を促進。
  3. 視覚化されたボード: 作業のステータスを明確に示し、ボトルネックを即座に確認。
  4. 定期的な補充(Replenishment) / プランニング: 必要な時にだけバックログから作業を補充（周期的あるいは臨界点到達時）。
  5. 測定と改善: サイクルタイム、リードタイム、スループットなどの指標でフローを改善。
  6. ポリシー(Explicit Policies): 列の移動条件、優先順位のルール、Definition of Ready/Doneの明文化。

スクラム vs カンバン vs スクラムバン ​

項目スクラムカンバンスクラムバン
反復（スプリント）あり（固定長）なし（継続的フロー）選択的 / 短いイテレーションの混用
WIP制限暗黙的（スプリントの範囲）明示的明示的（中核）
計画方式スプリントプランニング補充/プルベース補充 ＋ 必要に応じてプランニング
役割PO/SM/Dev柔軟（役割なし）PO ＋ Flow Manager（あるいはSMの役割維持）
目標コミットメント（スプリントの目標）フローの最適化フローの最適化 ＋ 優先順位管理

役割と責任 ​

  • プロダクトオーナー(PO): バックログの優先順位、ステークホルダーとの調整、ビジネス価値の定義
  • Flow Manager（またはScrum Masterの役割を維持）: フローの監視、ボトルネック解消のサポート、プロセス改善の促進
  • チーム（開発者/テスターなど）: 定義されたポリシーの遵守、WIP制限内でプル方式による作業の開始/完了
  • ステークホルダー: 要求・フィードバックの提供、レビューへの参加（必要に応じて）

役割はチームの状況に合わせて柔軟に調整してください。重要なのはフロー管理の責任が明確でなければならないという点です。

コアアーティファクト・ツール ​

  • カンバンボード（物理またはデジタル） — 列とWIP制限を含む
  • バックログ（優先順位リスト） — プル状態の作業候補
  • 明確なポリシー(Explicit policies) — 列移動のルール、定義(Ready/Done)
  • クラス・オブ・サービス(Classes of Service) — 緊急/固定日/標準などの優先順位のタイプ
  • メトリクスダッシュボード: サイクルタイム、リードタイム、スループット、CFD（累積フロー図）

ボードレイアウト ​

基本的なスクラムバンボード（例）：

列説明推奨WIP制限
Backlog優先順位が付けられたすべての作業—
Ready開始可能な作業（Doingへ移動可能な状態）—
Doing / In Progress実際の作業中3
Code Reviewレビュー待ち2
TestingQA/検証2
Done完了—

シンプルなASCIIボード:

Backlog -> Ready -> [Doing (WIP 3)] -> Code Review (WIP 2) -> Testing (WIP 2) -> Done

ワークフロールールの例 ​

text
Policy: プル条件（Doing列へ移動）
- カードがReady列にあり、Doing列のWIP < WIP制限
- 該当する作業の'Definition of Ready'を満たしている（要件/テストケース/デザインなど）
- 必要なリソース（テスター/レビュアー）の可用性を確認

Policy: Definition of Done（完了基準）
- コードがマージされ、ビルド成功
- 自動/手動テストに合格
- デプロイ（またはQA引き継ぎ）のドキュメント化完了

Classes of Serviceの例

  • Expedite（急行）: 即時処理（作業の優先順位最上位、WIPの例外を許可）
  • Fixed Date（固定日）: 特定の日付が必要 — スケジュールの監視が必要
  • Standard（標準）: 一般的なリクエスト
  • Intangible（無形）: 技術的負債などの長期的価値

イベントと推奨周期 ​

  • デイリースタンドアップ（毎日、10〜15分）: フロー中心に（何をしているかよりもボトルネック/ブロッカーの共有）
  • 補充(Replenishment) / バックログリファインメント（週1回または必要に応じて）: Ready列を補充 — 優先順位の再整備
  • プランニング（必要に応じて）: 大きな作業（エピック）の分解または代替計画 — 短く。
  • レトロスペクティブ（2〜4週周期）: プロセス改善、WIP制限の調整検討
  • サービスデリバリーレビュー / Opsレビュー（月次）: SLA・SLE・指標のレビュー

スクラムのようにすべての会議を厳格に決めておく必要はありません。フローを妨げる箇所が見えたら会議を導入してください。

見積もり・計画方法 ​

  • ストーリーポイントの維持: スクラムから移行するチームに適合。スループットに対する予測に有利。
  • No Estimates（見積もり省略）: カードの単純カウント ＋ サイクルタイム/スループットで予測。
  • バケット（期間ベース）計画: 月別に完了可能な作業量(throughput)を基準に補充。
  • 推奨: 重い見積もり活動を減らし、実際のデータ（サイクルタイム、スループット）で予測してください。

コアメトリクス（定義・活用） ​

  • リードタイム(Lead Time) = カードがバックログ（または作成）された時点 → 完了時点
  • サイクルタイム(Cycle Time) = 作業開始(Doing) → 完了
  • スループット(Throughput) = 特定の期間内に完了したカード数
  • WIP（平均進行中の作業数）
  • 累積フロー図(Cumulative Flow Diagram, CFD): 各列の累積領域でボトルネック・フローの変化を視覚化
  • サービスレベル期待値(SLE): 例: 85%の作業が10日以内に完了すること

参考活用法

  • リトルの法則(Little’s Law): WIP = Throughput × Cycle Time（平均値を使用） — 予測および限界の把握に有用
  • 目標: サイクルタイムの安定化 → 予測可能性の増加

スクラムからスクラムバンへ ​

  1. 現在のプロセスのマッピング: どのような仕事がどのように流れるかを視覚化
  2. ボードの構成: 最小限の列で開始（Ready → Doing → QA → Done）
  3. WIP制限の設定: 保守的に開始（例: Doing = チームメンバー数 ÷ 2）
  4. 補充ルールの決定: いつBacklogからReadyに補充するかを決定（週次/閾値）
  5. データの収集: サイクルタイム・スループットの収集（2〜4週間）
  6. 調整の反復: 振り返りでWIP・列・ポリシーを調整

カンバン/スクラムバン導入チェックリスト ​

  • [ ] ボードはチームの現実を反映しているか？
  • [ ] WIP制限が設定されており、全員が理解しているか？
  • [ ] Definition of Ready/Doneがドキュメント化されているか？
  • [ ] Replenishmentの周期（またはルール）が決まっているか？
  • [ ] デイリースタンドアップでボトルネック中心の議論が行われているか？
  • [ ] サイクルタイム・スループット・CFDを収集し分析しているか？
  • [ ] クラス・オブ・サービスとポリシーが定義されているか？
  • [ ] 定期的なレトロスペクティブでプロセスの変更が反映されているか？

実践のヒントとベストプラクティス ​

  • 小さく始める: ボードとWIP制限を小さくし、素早くフィードバックを受ける。
  • Stop starting — start finishing: 新しい作業を始めるよりも進行中の仕事を終わらせる文化。
  • WIP違反時のチームの規律: 即時議論（なぜ違反したのか、ボトルネックの原因把握）。
  • 視覚的シグナル: ブロッカー/緊急カードは別の色/ステッカーで表示。
  • ポリシーはドキュメント化: 「いつカードを移動させるか」を明確に書き留める。
  • 自動化: CI/CD、自動テストでサイクルタイムを短縮。
  • データ駆動の意思決定: 見積もりよりも実際のサイクルタイム/スループットで計画。

よくある間違い ​

  • WIP制限だけを設定して守らない場合
  • スクラムの儀式をそのまま維持しつつ、WIP・プルの概念を無視する
  • クラスを作って何の基準もなく使用する（優先順位の混乱）
  • 指標を収集せず「感覚」だけで意思決定する
  • 列/細分化が多すぎてボードが複雑になる場合

テンプレート: Replenishment会議（シンプルなアジェンダ） ​

  1. 先週完了した作業（簡単なレビュー） — 5分
  2. Ready列の状態確認（優先順位の再並べ替え） — 10〜20分
  3. WIP制限に対する現在の可用リソースの確認 — 5分
  4. 新規作業のプル決定（優先順位順に補充） — 10〜20分
  5. ブロッカー / 危険要因の共有 — 5分

FAQ ​

Q. スプリントは完全になくなりますか？ A. チームが望めば、短いイテレーション（例: 2週間）を維持しながらスクラムバンの原則を適用できます。重要なのはフローの改善です。

Q. ストーリーポイントを使い続けるべきですか？ A. 必ずしもそうする必要はありません。スループットとサイクルタイムで予測する方法も多く使用されています。チームの文化・報告の必要性に応じて決定してください。

Q. WIP制限はどのように決めますか？ A. 保守的に開始します（チームメンバー数を基準とするか、または過去のスループットから推定）。制限を守りながら段階的に調整します。

適用例 ​

  • チームメンバー5人 → Doing WIP = 3（同時作業の制限）
  • Replenishment : 週1回（月曜日）
  • Retrospective: 2週間ごと（オンライン・オフライン混合）
  • 指標: 週次スループット ＋ 4週累積サイクルタイムの観察

締めくくり — スタートガイド ​

  1. ボードを作り、
  2. WIP制限を定め、
  3. プル(Pull)のルールとDefinitionをドキュメント化した後、
  4. データ（サイクルタイム・スループット）を2〜4週間収集し、レトロスペクティブで調整してください。

Last updated: