スクラムチームのためのカンバンガイド by Scrum.org
※本記事は旧版です。最新版（2019年9月）はオフィシャルサイトからPDFをダウンロード可能です。
この作品は The Kanban Guide for Scrum Teams の翻訳です。クリエイティブ・コモンズ 表示 — 継承 4.0 国際 ライセンスの下に提供されています。
目的
カンバンにおけるフローベースの考え方は、スクラムフレームワークとその導入を強化・補完する。チームがこれからスクラムを使う場合でも、これまで長年スクラムを使ってきた場合でも、カンバンは適用可能である。
この「スクラムチームのためのカンバンガイド」は、Scrum.orgのコミュニティのメンバーとカンバンのコミュニティのリーダーがコラボレーションして生み出した結果である。その両者が協力して「スクラムチームのためのカンバンガイド」を支援している。カンバンとスクラムを組み合わせれば、プロのソフトウェアの実践者が恩恵を受けることができるだろう。そのことが、両者の共通した信念である。
スクラムガイドとの関係
本ガイドは、スクラムガイドを置き換えるものではない。軽視するものでもない。スクラムフレームワークのプラクティスを強化・拡張するために設計されたものである。本ガイドの読者は、すでにスクラムフレームワークを使ってプロセスを運用しているものとする。したがって、スクラムガイドも全体的に適用される。
カンバンの定義
カンバン（名詞）：見える化され、進行中の作業（WIP: work in progress）が制限されたプルシステムを使用するプロセスにより、ステークホルダーの価値の流れを最適化する戦略。
カンバンの定義の中心にあるのは「流れ（フロー）」の概念だ。流れとは、プロダクト開発のシステム全体における顧客価値の動きである。プロセスの全体的な効率性・有効性・予測可能性を向上させることで、カンバンは流れを最適化する。
カンバンとスクラムの理論
まずは、スクラムガイドの重要な教義を簡単に復習したい。
スクラムは、経験的プロセス制御の理論（経験主義）を基本にしている。経験主義とは、実際の経験と既知に基づく判断によって知識が獲得できるというものである。経験的プロセス制御の実現は、透明性・検査・適応の3本柱に支えられている。
スクラムでは、スプリントバックログの透明性を義務付けているが、その実現方法の指針についてはほとんど提示されていない。また、作業項目がプロダクトバックログに入るまで、プロダクトバックログからスプリントバックログに至るまでの流れについて、あるいはインクリメントが「完成」したあとで作業項目に発生するあらゆることについても、透明性を確保する方法は定義されていない。
そこで、カンバンの登場だ。スクラムチームは、作業項目を新たな方法で見える化することで、本ガイドで紹介しているプラクティスを適用し、価値の提供をうまく最適化できるだろう。なお、これらのプラクティスは、リーンシンキングの原則、Product Development Flow、待ち行列理論などを参照・応用したものである。
価値の流れを最適化することで得られる有益な副作用は、プロセスとプロダクトに対する検査と適応の機会が増えることだ。カンバンによって顧客のフィードバックループを強化するというのは、経験的なプロセス改善の実績のある戦略である。
カンバンの透明性・見える化・流れに対する過剰なまでのフォーカスと、スクラムフレームワークを組み合わせれば、最適な顧客価値を提供するプロセスをデザインする強力な基盤となるだろう。
ワークフローの定義
流れを最適化するには、スクラムの文脈における流れの意味を定義する必要がある。スクラムチームは、以下のような要素を含む「ワークフロー」の定義を作らなければいけない。
- スクラムチームが作業の開始と終了を認識する時点
- スクラムチームのシステムを流れる顧客価値の単位（通常はプロダクトバックログアイテム（PBI）になるだろう）
- PBIの誕生から終了までの流れを示すワークフローの各状態（少なくとも1つはアクティブな状態が必要になる）
- 作業が各状態を流れていく明確な方針（スクラムチームの「完成」の定義やステージ間の引き取りの方針の定義などが含まれる）
- 進行中の作業（WIP）の制限
- 作業項目が完了するまでにかかる時間を予測するサービスレベル期待値（SLE: Service Level Expectation）
ワークフローを定義するのはスクラムチームの責任だが、以下のような考慮すべき要素がいくつかある。
- まだアクティブではない作業項目を「開始していない」と認識すること
- アクティブになった（開始された）作業項目を「進行中（WIP）」と認識すること
- 事前に用意したアクティブな状態をすべて通過した作業項目を「終了した」と認識すること
以上をまとめると、「ワークフロー」の定義には、作業そのものの定義（作業項目）、プロセスの開始状態、作業項目のアクティブな状態、プロセスの終了状態に関するスクラムチームの共通認識が含まれる。
注意してほしいのは、「ワークフロー」の定義における状態は、スプリントバックログで定義された状態とは一致しないことがある、ということだ。たとえば、スクラムチームの「ワークフロー」の定義には、スプリントバックログの上流・下流・内部・外部の状態が含まれる可能性がある。同様に、ワークフローを移動する作業項目はプロダクトバックログアイテムには当てはまらず、スプリントバックログやスクラムにも該当するものがない可能性もある。すべての状態を通過しない作業項目もあれば、アクティブな状態を順番に流れていかない作業項目もある。
「ワークフロー」の定義の作成と適応は、既存の作成物に影響を与えたり、逆に影響を受けたりする可能性がある。ただし、プロダクトオーナーと開発チームの作成物に対する責任については、スクラムガイドに従うべきである。
サービスレベル期待値（SLE）
SLEとは、任意の項目がワークフローの開始から終了まで流れる時間を予測するものである。SLEには2つの部分が含まれる。経過日数とその確率だ（例：「作業項目の85%が8日以内に終了する」）。SLEはスクラムチームの過去のサイクルタイムをベースにしている。サイクルタイムを計算したらカンバンボードに貼り付けておこう。サイクルタイムのデータがなければ、まずはスクラムチームで最善の推測を行い、SLEを計算するのに十分なデータが集まったあとで置き換えればいい。
スクラムチームが「ワークフロー」をどのように定義しようとも、本ガイドの中心的な概念はワークフローである。本ガイドのあらゆる要素は、スクラムチームがどのように「ワークフロー」を定義しているかに大きく依存する。スクラムチームが作業の流れを経験的に改善していくにつれて、ワークフローの定義も変わる可能性があるだろう。むしろ、変わるべきである。なお、本ガイドのその他の要素と併用するときには、一貫した「ワークフロー」の定義を用いるべきである。一貫性によって、カンバンの透明性に対する完全性が保証されるからだ。
カンバンのプラクティス
スクラムチームは、以下の4つの方法を使用して流れの最適化を実現する。
- ワークフローの見える化
- WIPの制限
- 進行中の作業項目のアクティブな管理
- 「ワークフロー」の定義の検査と適応
ワークフローの見える化―カンバンボード
カンバンボードを使った見える化は、スクラムチームがワークフローを透明化する方法である。カンバンボードによって、適切な時期に適切な会話を促すことができる。また、改善の機会を積極的に提案することができる。
WIPの制限
WIP（Work in Progress）とは、スクラムチームが作業を開始したが、まだ終了していない作業項目のことを指す。カンバンボードを使用するスクラムチームは、これらのWIPを「開始」から「終了」まで明確にコントロールする必要がある。そのコントロールは、通常はカンバンボードの数値で示される。この数値のことを「WIP制限」と呼ぶ。WIP制限は、ひとつの列、複数まとめた列、ボード全体の作業項目に対して設定できる。スクラムチームがWIP制限を設定すると、ワークフローのその部分にはWIP制限の数値以上の作業項目を引き取ることができない。スクラムチームは、何を制限とするか、それをどのように適用するかをコントロールする。
WIPを制限すると、主な副作用として「プルシステム」が生まれる。作業を開始すべき明確なシグナルを受け取ったときに、スクラムチームが作業を開始する（プルする）ことから、「プルシステム」と呼ばれている（要求されたときに作業を開始する「プッシュ」システムとは異なることに注意）。定義された値をWIPが下回ると、それが新しい作業を開始するシグナルになる。
スプリントもWIP制限の一種と考えることができる。スプリントの定義によれば、これは一定期間内に開発チームが取り組む作業量をコントロールする方法である。開発チームが（通常はスプリントプランニングで）選択したときにだけ、作業項目がスプリントバックログにプルされる。意図するしないにかかわらず、スクラムはこのような流れの基本的なプラクティスを最初から受け入れてきた。カンバンのWIP制限は、スプリントよりもさらに粒度が細かく、明確なものである。これは、ワークフローを支援するだけでなく、スクラムチームのフォーカス、コミットメント、コラボレーションについても改善してくれるものである。
進行中の作業項目のアクティブな管理
WIP制限は流れの実現に欠かせない要素だが、それだけでは十分ではない。流れを実現する3つめの方法は、進行中の作業項目のアクティブな管理だ。アクティブな管理には、以下のようなものがある。ただし、これらに限定されるものではない。
- ブロックされた作業項目にすばやく反応する
- 作業項目がワークフローを出ていくのとほぼ同じ速度で、新しい作業項目がワークフローにプルされるようにする
- 作業項目が放置されず、設定したSLEに従って完了できるようにする
- 1つ以上の列に積み重なった作業を取り除く
これらの多くはデイリースクラムで扱うことになるだろう（「フローベースのデイリースクラム」を参照）。ただし、進行中の作業項目に対するプロアクティブ（事前）、アクティブ（最中）、リアクティブ（事後）の継続的な管理については、スクラムチームの責任で確実に実施する必要がある。
ワークフローの検査と適応
方針とは何か。これはスクラムチームにおけるワークフローの「ゲームのルール」と考えてほしい。方針の小さな変更が、スクラムチームのパフォーマンスに重大な影響を与える可能性もある。スクラムガイドには、最小限の明確な方針と、文脈固有の方針（例：スクラムチームの「完成」の定義）を見つけるための方法が記載されている。スクラムチームがカンバンを適用する場合、スクラムガイドにカンバンのプロセスの明確な方針を補完したいと考えるだろう。こうした方針は、スクラムチームの「ワークフロー」の定義に含まれることになる。
「明確」とは、これらの方針が何らかの形で書き記されていて、あるいは見える化されていて、スクラムチーム全体が理解していることを意味している。スクラムチームのメンバーがわかるように、カンバンボードには必要な方針や参照先をすべて貼り出しておくべきだ。
明確にすべき方針の例として、作業項目が「開始前」から「開始」、「進行中」から「終了」へと移動するタイミングをスクラムチームがどのように定義するか、がある。スクラムチームは間違いなく、本ガイドで求められる方針とは別に新たな方針を追加することになるだろう。
流れの指標と分析
スクラムの文脈にカンバンを適用するには、最低限の流れの指標の収集と分析が必要になる。これらの指標は、進行中の作業項目のアクティブな管理に欠かせない。また、流れを透明にして、フローベースの検査と適応を可能にする。これらの指標は、スクラムチームのアプローチの現在の健康状態とパフォーマンスを反映している。また、スクラムチームの機能と提供する価値を改善するポイントを指し示している。
流れの基本的な指標
カンバンを使用するスクラムチームが追跡すべき基本的な4つの指標を以下に挙げる。
- Work in Progress（WIP）：開始されたが終了していない作業項目の数（開始や終了はスクラムチームの「ワークフロー」の定義に従う）。
- サイクルタイム：作業項目が開始してから終了するまでの経過時間。
- 作業項目の年齢：作業項目が開始してから現在までの経過時間。
- スループット：単位時間あたりの「終了した」作業項目の数。スループットの測定値は作業項目の個数であることに注意。
サイクルタイムと作業項目の年齢を計算するには、スクラムチームが（少なくとも）各作業項目の開始日と終了日を記録する必要がある。
これらの指標はスプリント全体で（特にスクラムイベントで）監視する必要がある（後述のフローベースのイベントの項目を参照）。もちろんスクラムチームが検討したい指標は他にもあるだろう。これらは最低限の指標である。
フローベースのイベント
スクラムの文脈におけるカンバンは、スクラムガイドに記載されているイベント以外のイベントを必要としない。ただし、フローベースの視点を使用すると、スクラムのイベントが強化されるだろう。
スプリント
スプリントとは、検査と適応のリズムであり、定期的な「心拍」である。スプリントの定期的なサイクルと要素は、そのままでも流れの管理に適している。スプリントには、スプリントプランニング、デイリースクラム、開発作業、スプリントレビュー、スプリントレトロスペクティブが含まれる。スプリントに含まれるイベントは、カンバンの流れの指標を検査するフィードバックループとして機能する。同様に、カンバンのアプローチは、スクラムの導入を検査するフィードバックループとして機能する。
フローベースのスプリントプランニング
フローベースのスプリントプランニングでは、流れの指標を使いながらスプリントバックログを構築する。たとえば、過去のスループットを使用して、スクラムチームの次のスプリントにおけるキャパシティを把握する。スクラムチームのSLEは、スプリントの最初の数日間の作業に影響を与える可能性がある。
フローベースのデイリースクラム
フローベースのデイリースクラムでは、流れを維持するためにスクラムチームができることすべてを実行しているかを確認する。デイリースクラムの目的はスクラムガイドの記載と同じだが、カンバンボードを囲みながらミーティングを開催すること、流れが滞っているところやスクラムチームが流れを回復できるところにフォーカスしていること、といった部分が異なる。フローベースのデイリースクラムで考慮すべき追加事項は、以下のとおりだ。
- ブロックされている作業項目は何か？スクラムチームがブロックを解除するにはどうすればいいか？
- 進行中の各作業項目の年齢は？SLEを違反している（違反しそうな）作業項目は？スクラムチームがそれらの作業項目を完了させるために何ができるか？
- カンバンボードに記載されていない作業項目について、スクラムチームがそれらを完了させる能力に影響を与えるような懸念事項はあるか？
フローベースのスプリントレビュー
スクラムガイドには、スプリントレビューのプロセスの詳細な骨子が記載されている。こうした活動だけでなく、カンバンの流れの指標を検査することで、進捗をモニタリングする新たな対話が生まれる。たとえば、スループットをレビューすると、プロダクトオーナーが有望な予定日やデリバリーの日程を検討するときに役立つ情報が手に入るだろう。また、スクラムチームのSLEをレビューすると、プロダクトオーナーがプロダクトバックログを修正する機会が生まれるだろう。
フローベースのスプリントレトロスペクティブ
フローベースのスプリントレトロスペクティブでは、流れの指標や分析を検査することで、スクラムチームのプロセスの改善（プロセスにはスプリントレトロスペクティブも含まれる）を判断するのに役立つ。カンバンを使用しているスクラムチームは、次のスプリントの流れを最適化するために「ワークフロー」の定義を検査・適応できる。スクラムチームのWIPを見える化するために累積フロー図を使用していれば、平均サイクルタイムや平均スループットも役に立つだろう。
スクラムガイドでは、スプリントレトロスペクティブはスプリントレビューが終わってから、次のスプリントプランニングが始まる前に実施することになっている。カンバンを使用するときもこれは変わらない。ただし、フローベースのレトロスペクティブはスプリントの境界と一致させる必要はない。「ジャストインタイム」で実施して構わない。ただし、それによってチームの「ワークフロー」の定義がいつでも変更される可能性が出てくる。そうした変更はスクラムチームのパフォーマンスに大きな影響を与えてしまうため、スプリントレトロスペクティブの定期的なリズムで変更したほうが、複雑性が軽減され、透明性が向上するだろう。
最後に
スクラムはプロセスやテクニックではない。人々が複雑で変化の激しい問題に対応するためのフレームワークであり、可能な限り価値の高いプロダクトを生産的かつ創造的に提供するためのものである。スクラムガイドが指摘するように、その他のテクニック、方法論、プラクティスの入れ物としても機能する。
流れを最適化するカンバンのプラクティスは、適切なものを適切な時期に検査し、その検査にもとづき、必要に応じて適応する機会をスクラムチームに与える。カンバンの透明性・見える化・流れに対する過剰なまでのフォーカスは、フィードバック、経験主義、最終的には顧客価値の提供を最大化するだろう。
歴史と謝辞
一般的に「カンバン」と呼ばれるプラクティスの集合は、2006年にCorbisのチームで生まれたものである。これらのプラクティスは多種多様な国際コミュニティに急速に広まった。こうしたコミュニティが、長年にわたりこの手法を強化・進化させてきたのである。
本ガイドは、Scrum.org、Professional Scrum Trainerのコミュニティ、Steve Porter、Yuval Yeret、Daniel Vacantiによって共同開発されたものである。
Louis-Philippe CarignanとCharles Bradleyの協力に感謝したい。また、これまでにカンバンを成長させ、成功したリーン・アジャイル戦略にしてくれた実践者たちにも大いに感謝している。
