Kanban

余計な品揃えを作り上げる唯一の方法は余計な人手をつぎ込むことである。

- Eli Goldratt

あるいは特殊化しすぎることかもしれない。

– SAFeの著者

チームカンバンの概要

カンバンシステムは、目的はいくらか違うものの、SAFeのポートフォリオ、価値のストリーム、プログラム、チームの各レベルで使用される。このページでは、チームが価値のフローを促進するのに役立つチームカンバンという手法について説明する。この手法では、ワークフローの可視化、仕掛かり作業制限の確立、スループットの測定、継続的なプロセス改善を行う。

SAFeチームはアジャイル手法を選択することができる。多くの場合は、作業を管理するための、軽量かつ効果的なおなじみの手法であるスクラムが使われる。新規コードを開発するチームでは、XPのプラクティスを適用して、ソフトウェアエンジニアリングやコード品質に焦点を絞ることもある。ただし、一部のチーム、特にシステムチームや、DevOps、保守チームなどは、第一の手法としてカンバンを適用することがある。このようなチームでは、対処が中心の仕事、矢継ぎ早の作業、急速に変化する優先順位、次の反復で正確に何を行うかを計画してもその価値は低いことなど、どれをとってもこの選択につながる。このページでは、SAFeのアジャイルチームに適したカンバンシステムについて説明する。ただし、これらのチームは「列車に乗っている」ため、列車のいくらかの規則も適用しなければならない。

詳細

一般に、カンバンはプルシステムであると言われる。つまり、そのための処理能力があると分かっているときにチームが仕事を「プル」するのであって、チームにスコープが「プッシュ」されるのではない。このページでは、チームが価値のフローを促進するのに役立つチームカンバンという手法について説明する。この手法では、ワークフローの可視化、仕掛かり作業制限の確立、スループットの測定、継続的なプロセス改善を行う。

カンバンシステムは、いくつかの作業フローの状態からなる。ほとんどの状態には仕掛かり作業(WIP)制限があり、ある状態に作業項目をプルできるのは、その状態にある項目の数がWIP制限よりも少ない場合だけである。少数の状態(通常は開始と終了の状態)にはWIP制限がない。WIP制限はチーム自身が決めて調整するため、複雑なシステム開発に特有のフローの変化に素早く適応できる。SAFeにおいて、チームカンバンは、アジャイルリリース列車(ART)のリズムと同期の要件と合わせて適用される。これによって、連携、依存関係の管理、素早い統合ベースの学習サイクルがもたらされ、その結果、大規模なソリューションを前進させるのに必要な客観的な証拠が得られる。

カンバンとは

カンバンは、根本的には、作業を可視化し管理するための手法である。カンバンを開発にどう適用するかの解釈は数多くあるが、開発カンバンシステムの主な側面に以下が含まれることはほとんどの人が合意するところである。

  • システムには一連の状態が定義されていて、作業はその中を通って進む。
  • すべての作業が可視化され、個々の項目の進捗が管理される。
  • チームは、状態ごとのWIP制限に合意し、フローを改善するために必要であればそれを変更する。
  • チームは作業の管理方法に関する具体的な方針を採用する。
  • フローは測定される。作業項目はシステムに入った時点から出る時点まで追跡され、仕掛かり作業の量や現在のリードタイム(1つの項目がシステムを通り抜けるのにかかる時間の平均)の継続的な指標となる。
  • 優先順位付けはサービス等級を割り当てることで行う。サービス等級は遅延コストによって決められる。

フローの可視化とWIPの制限

最初に、チームは通常、現在のプロセスのフローのおおよその状態を出し、何らかの初期WIP制限を決める。図1はあるチームが最初に作成したカンバンボードの例である。ここには、分析-レビュー-構築-統合-テストという現在の作業フローのステップが表されている。

Figure 1. One team’s initial Kanban board
図1. あるチームの初期カンバンボード

図1を見ると、フローの変動を管理しやすいよう2つの緩衝域(「準備完了」)も作成していることが分かる。1つは「レビュー」ステップの前にある。レビューのステップでは外部のその分野の専門家(プロダクト管理など)に参加してもらう必要があるが、彼らの手の空き具合は限られていたり一様でない可能性があるからである。もう1つの緩衝域は「統合とテスト」の前であり、この例の場合はこのステップで共有のテスト用設備やリソースが必要になる。統合とテストは同じ担当者が同じインフラ上で行うため、この2つのステップは1つの状態として扱われている。また、処理コストの理由付けができるよう、このチームでは「レビュー」と「統合とテスト」のステップにそれなりに多い数のWIP制限を許容している。

チームのカンバンボードは反復的に進化する。プロセスの初期ステップとWIP制限を決めた後、しばらく実施すると、チームのボトルネックが浮かび上がるはずである。そうでなければ、チームは、状態を洗練したりさらにWIPを削減していって、どの状態が「飢えて」いてどの状態がいっぱいかが明らかになるようにし、より最適なフローになるよう調整を行う。想定の正当性を確認していく過程で、WIP制限の調整やステップのマージ、分割、再定義が行われる。

フローの測定

フローとプロセスを理解し改善できるよう、カンバンチームは客観的な測定値を使用する。これには平均のリードタイム、WIP、スループットなどがある。よく使われるのは図2に示す累積フロー図(Cumulative Flow Diagram:CFD)である。

Figure 3. Cumulative Flow Diagram (CFD) shows how lead time and WIP evolve over time
図2. 累積フロー図(CFD)にはリードタイムとWIPが時間の経過と共にどう変わるかが表される

各バックログ項目には、作業フローに入ったとき(チームのバックログからプルされて実装が始まったとき)と完了したときの両方の日付が記録される。到着曲線は、バックログ項目がどれだけプルされて作業が始まったかを示す。出発曲線は、それがいつ受け入れられたかを示す。X軸は平均のリードタイム、つまり項目がシステムを通り抜けるのに平均でどれだけの時間がかかったかを示す。Y軸はWIP、つまり任意の時点においてシステム内に存在する項目数の平均である。スループット、つまりある期間ごとに完了したストーリーの数は、もう1つの重要なメトリックスとなる。SAFeのカンバンチームは反復のリズムで動いているため、スループットは反復ごとのストーリーで測定する。

累積フロー図のデータをもとに、チームは現在の反復のスループットを計算することができる。平均のWIP数を平均のリードタイムで割ると、一日に処理できる平均のストーリー数が求められる。これに14(1つの反復の日数)をかける。その結果求められるのが反復の平均スループット(反復ごとのストーリー数)であり、これが計画策定時に役立つ。(これは「導出ベロシティー」の計算にも重要である。これについてはこのページの後の部分で説明する。)

累積フロー図は、フローの大きな変動を可視化するという重要な役割も果たす。この変動は、チームが気付いていない組織内の妨害や、フローを妨げる外部の力が原因となっている場合がある。CFDは、カンバンチームを容赦なく改善するのに役立つ客観的な測定値のよい例である。

サービス等級によるフローの改善

さらに、チームは依存関係を管理したり、マイルストーンによって確実に足並みを揃える必要がある。カンバンでサービス等級というメカニズムを使用すると、チームがバックログ項目の実行を最適化するのに役立つ。サービス等級は、遅延コストによってバックログ項目を区別する1つの方法である。サービス等級ごとに、チームが合意した実行方針が決められている。たとえば次のようなものである。

  1. 標準。ほとんどのバックログ項目は標準に分類される。具体的な日付に依存しない新規開発などである。標準の項目では遅延コストは線形である。つまり、納品されるまで価値は達成されないが、決まった期限は要求されない。
  2. 日付固定。日付固定の項目は、先に日付が決まっているマイルストーンや依存関係を表す。遅延コストは線形ではない。これらの項目は、その日付までに終了できるよう必要なときにプルされて開発が行われる。予想リードタイムを洗練するために追加で分析をしなければならない場合や、チームに遅れが生じたら「緊急」に変更しなければならない場合もある。
  3. 緊急。「緊急」のバックログ項目とは、遅延コストが受け入れ難いため、即座に対処が必要なものである。現在のWIP制限に違反してプルされることすらある。通常、「緊急」にできるのは、システム内で一度に1つの項目だけである。その項目がシステムを急いで通り抜けられるよう、総力を挙げて対処するための方針をチームが設定することもある。

多くの項目を緊急にする必要があるなら、システムの負荷が高すぎる可能性がある。要望が処理能力を超えているか、入力プロセスの規律が取れていない可能性がある。いずれにしても、プロセスを修正する必要がある。

図3に示すように、サービス等級は通常、「レーン」として可視化される。

Figure 3. Classes of Service on the Kanban board
図3. カンバンボードにおけるサービス等級

さらに、「新機能」、「調査スパイク」、「モデリング」など、バックログ項目の種類ごとに個別の色を決めておくこともある(PI計画を参照)。こうすると、行う作業を理解しやすくなる。

フローの構造をよく観察することで、カンバンチームは、そうでなければ見逃していたかもしれない改善の機会を得ることができる。たとえば、累積フロー図の変化から平均WIP数の増加(リードタイムの増大の原因となる)が読み取れる場合がある。これはより深い問題の症状でしかないかもしれないが、チームはその問題を発見する手段を手に入れたことになる。プロセスについて定期的に検討し、修正することは、フローの可視性を上げたことによる恩恵を手にするための必要な手段である。

SAFeのカンバンチームは列車に乗っている

SAFeのカンバンチームは、ソリューションを構築するという広いコンテキストで仕事をするが、このソリューションは、複数のアジャイルチームが必要だったり場合によっては複数のアジャイルリリース列車(ART)にまたがったりする。構築を成功させるには、チームは、通常のカンバンの指針だけでなく、SAFe固有の規則にも従う必要がある。この規則とは、チームが協力して計画すること、協力して統合とデモを行うこと、共に学ぶことである。これについては、アジャイルチームのページで詳しく説明する。協力して計画することについては、さらなる議論が必要である。これは下で取り上げる。

作業の見積もり

一般に、カンバンチームはスクラムチームほど見積もりやタスク管理に時間を割かない。それよりも、必要な作業に目を向けて、必要に応じて大きな項目を分割し、結果として作成されたストーリーを完成まで導く。このとき規模についてはそれほど気にしない。ただし、SAFeチームは、PI計画向けに要望を処理能力に照らして見積もれなければならないし、大きなバックログ項目については経済的見積もりに参加しなければならない。また、正しい予測をするためには、列車上の他のチームやART全体のベロシティーと一貫したやり方でチームのベロシティーを理解しておく必要がある。

見積もりの共通出発点の設定

最初、新しいカンバンチームは自身のスループットについての知識を持たない。これは過去の事柄に基づいて後から測定するものだからである。まず、SAFeのカンバンチームには、作業を見積もるための手段が必要である。通常これは、最初のPI計画セッションから使われる。スクラムチームと同様に、処理能力の初期見積もりは標準化された見積もりによって始められる(反復計画を参照)。その後、カンバンチームは、見積もったストーリーを反復に追加する。これもスクラムチームと同様である。開始時の処理能力は、少なくとも最初のプログラムインクリメント(PI)の時点では、推測によるベロシティーである。

導出ベロシティーの計算

このように出発した後、カンバンチームは累積フロー図を使用して、実際のスループット(反復ごとのストーリー数)を計算する(または単純にカウントして平均を計算してもよい)。その後、スループットに平均のストーリーサイズ(通常は3~5ポイント)をかけて、「導出ベロシティー」を計算する。こうすることで、SAFeのスクラムチームとカンバンチームは、より大きな経済的枠組みに参加することができる。この経済的枠組みはポートフォリオにとっての主要経済コンテキストとなる。

大きな作業項目の見積もり

ポートフォリオ価値のストリームのレベルでは、多くの場合、大きな作業項目(エピックおよびシステム能力)を見積もって、取り組みの経済的実現性の見込みを判断する必要がある。さらに、ARTや価値のストリームのロードマップを作成するには、見積もりの知識(項目の大きさはどれくらいか)とARTのベロシティー(それを行うためのARTの処理能力はどれだけあるか)の両方が必要である。そのために、カンバンチームでは大きな取り組みをストーリーに分割して見積もりを行う(これはスクラムチームと同じである)。それによって、大きな項目を見積もるのに必要な細かいレベルの情報が得られる。その後、標準化されたストーリーポイントでストーリーの見積もりを行う。こうすることで、企業は必要以上の議論をすることなく、(さまざまな種類の)さまざまなチームから出された見積もりを集約することができる。


さらに知りたい場合

[1] Anderson, David. Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press, 2010.(邦訳:カンバン ソフトウェア開発の変革、リックテレコム、2014)

[2] Kniberg, Henrik. Lean from the Trenches: Managing Large-Scale Projects with Kanban. Pragmatic Programmers, 2012. (邦訳:リーン開発の現場 カンバンによる大規模プロジェクトの運営、オーム社 、2013)

Last update: 30 November 2015