流れを止めるスクラムと流れを促すカンバン

スクラムはタイムボックスだ。そして、タイムボックスの間は、要求の流れを固定化する。スプリントプランニングで、プロダクトバックログから上位のバックログアイテムを選び、それに絞って実装する。その間のバックログアイテムの入れ替えは、開発チームがイエスと言わない限りできない。

一方、カンバンにはタイムボックスの概念はない。要求のバックログが常に優先順位付けされ、上位のモノからプル方式で着手されていく。そして、できあがったモノから順次リリースされていく。タイムボックスではないから、時間軸で固定化されたイベントはない。プランニングやデモが必要ならワークフローに組み込んでいくだけだ。

一般的に、カンバンボードは実際の作業プロセスを反映したボードだ。だから、大抵ToDo, Doing, Done以上のカラム（列）がある。

上記の例では、具体的なワークフローでカラムを切っている。

バックログ
分析
開発
テスト
完了

分析、開発、テスト工程が更に2分割されている。これは、各工程の中で作業が完成したかどうかを判断するためだ。例えば、分析だけのカラムだと、分析中なのか、分析が終っているのかわからない。上記の例では、「未着手」か「分析中」が判断できる。そして分析が完了したら、次の「開発待ち」にタスクが移動する。開発担当者は手が空いたら、このタスクをプルし、開発中のカラムに移動する。

よくあるのは、上記の例のような、

未着手
作業中

または、

作業中
完了

である。

カンバンのよいところは、作業担当者が固定していても導入しやすいことだ。

調査・分析
設計
実装
テスト
受入テスト
リリース

作業毎に、担当者が固定されていても、それなりに回すことができる。メンバーがT型スキルを獲得できておらず専任であっても進めることが可能だ。

カンバンの肝は、プロセス全体を円滑に流すことである。そのために、いくつかのテクニックがある。

各工程の最大作業量の制限
スウォーミング
プロセス改善

カンバンボードを見てみると、常に作業が溢れているところと、いつもスカスカのところがある。これは作業量とキャパシティが上手く噛み合っていないことが原因だ。処理能力を超える作業が来たら、どんどん滞留していく。逆に、処理能力が圧倒的にある場合は、作業があっという間に完了してしまいいつも待ちの状態だ（手待ちのムダ）。プロセスの中でこのようなバラツキがあると非効率なので、工程間のバランスが崩れないよう制限を設ける。作業が3個以上溜まったら、上流工程は手を止めて、次工程の作業を先に流すよう支援する。そして、1つ先に流したら、上流工程に戻ってあらたに1つ流す。

（スポンサーリンク）

作業が滞留している工程を、皆で群がって解消していくことを「スウォーミング」という。皆で力を合わせて、流れを止めている作業を解消する訳だが、スウォーミングを効果的に行うには、ある程度のT型スキルが求められる。実装工程で作業が溜まっている時、支援する為にプログラミングがわからないと話にならない。協力したいという気持ちだけでは役に立てないのである。効果的にカンバンを回すためには、スクラム同様、I型からT型へのスキル拡張が必要になる。

最初は今あるワークフローをそのままカンバンにしても、目に見えると改善点に気づくものだ。どの工程でいつも作業が滞留するとか、どこはいつも暇そうだとか。カンバンボードをチーム全員で見ながら、定期的にふりかえり、プロセスを改善していく。

カンバンの流れを計るメトリクスとして主に次の2つがある。

リードタイムの短縮
スループットの最大化

リードタイムはプロセス全体の処理にかかる時間のことだ。各工程を滞りなく進めることで、全体のリードタイムは短くなる。リードタイムを継続的に計測し、その短縮幅を持って改善を計る。もう一つのスループットは、一定期間における完成量だ。投入されたバックログアイテムが、仕掛品ばかりだといっこうに完成しない。速やかに完成するためには、流れをスムースにして、プロセスのムリやムダを省いていかなくてはならない。リードタイムが短縮するに従って、当然完成量も増える訳だが、1日あたり、または1週間単位の完成個数でスループットを計る。

カンバンにはスクラムのようなタイムボックスはないし、既存の役割を継承して進めやすいメリットがある。それに、スクラムのような定型セレモニーもないから、オーバーヘッドは小さい。だが、ルールが少ないと言うことは、それだけチームに高い意識が求められるということだ。

自律したチームでなくては、カンバンは威力を発揮しない。あなたの組織の状況にあわせてスクラムとカンバンを上手く使い分けてみてはどうだろう。