カンバンを導入する間違った理由5個

みなさんこんにちは。@ryuzeeです。

ちょっと古い記事ですが、TargetProcessのサイトMichael Dubakov氏による5 Wrong Reasons To Apply Kanbanという良い記事があったので、抜粋・意訳にてご紹介します。

5つの間違い

1.ユーザーストーリーの多様性

我々のストーリーは1ポイントから40ポイントまでさまざまなので、大きいストーリーがスプリントに入らない。なのでカンバンを使う

2.スプリントがうまくいかない

1スプリントの中でほとんどのストーリーが完成しない。なのでカンバンを使う

3.ふりかえりミーティングがうまくいかない

ふりかえりミーティングが無駄になっている。チームメンバーはプロセスの改善に協力してくれず、ミーティング自体をなくしたい。なのでカンバンを使う

4. 人的リソースの共有と機能別組織

開発チームが１つで、プロジェクト間でメンバーを共有しており、しっかりしたプロジェクトチームを作ることができない。なのでカンバンを使う

5.シンプルさ

カンバンはとってもシンプルだ！計画も見積りもスプリントもオーバーヘッドもない。なのでカンバンを使う

さすがにこんな現場ないでしょ？という気がしなくもないですが、それぞれについて私見を述べたいと思います。

1. ユーザーストーリーの多様性

ストーリーポイントによる見積りがフィボナッチ数列になっている理由は、見積りが大きくなるほど、見積りが不正確になり、1ポイントの持つ意味が少なくなっていくためです。以前書きましたが、チームの性質として、自分たちがハンドリングできる範囲を超えると、何でも「大きい」と判断してしまう傾向があります。大きい見積りはそれ自体、大きいことは分かっていても、小さいストーリーを合算した同数のストーリーポイントと同等の規模であるかどうかは分かりません。したがってまずやるべきことは、40ポイントのような大きなストーリーを小さなストーリーに分割することです。分割したら合計のストーリーポイントはもっと多くなるかもしれませんが、分割したストーリーの中には優先度が低い項目もあるかもしれません。

参考：[Agile]ストーリー分割のメリット

2. スプリントがうまくいかない

スプリントがいつも完了しないの意味にもよりますが、もし全てのストーリーが完了しないのであれば、それはスプリントの中でミニウォーターフォールのようなことをやっているからでしょう。最後に全てのテストを残しているような状態は好ましくない（仕掛品の無駄が大量にあることになる）のです。テスト自体はスプリントの最初から最後まで常に行われるべきです。まずはカンバン云々の前にそのあたりの改善が必要になります。なお、複数のストーリーのうち、一部が完了しない状態は結構な頻度で発生します。その場合は残ったストーリーを次のスプリントで行うかどうかを決めれば良いだけです（プロダクトオーナーは新たに優先順位を振り直します。すぐに次のスプリントでやるとは限りません）。

参考：スクラムのスプリントにおけるコミットとは何か

3. ふりかえりミーティングがうまくいかない

うまくいかない場合は往々にして、以下のようなことが起こっています。

毎回同じ問題が出る。愚痴を言って終わる
前回のアクションアイテムができていない。もしくはアクションアイテムの結果が検証されていない
個人攻撃が行われる
コーチやファシリテーターがおらず、特定の個人しか発言しない

ふりかえりがうまくいっていないということは、検証と調整・改善のループが回っていないということになります。カンバンに変える前にミーティングのファシリテーションやコーチングを行うとともに、継続的な改善に価値を置くようにする必要があります。

参考：ふりかえりをうまくやるコツ

4. 人的リソースの共有と機能別組織

マルチタスクやマルチプロジェクトによるスイッチングコストが極めて高くて無駄である、ということを直視すべきです。往々にして組織のマネージャは、「稼働率」という謎の数値を高くするために、個人を複数のプロジェクトに割り当てようとしますが、結果として多くの無駄を生んでいることに気付くべきなのです。それから機能別組織は組織間の壁をつくりセクショナリズム、責任逃れを生みやすくなります（マイクロソフトのようにバーチャルチームとして組織間で横櫛を通すことでこの問題に対応しているケースもあります）。そしてこの問題はカンバンを利用したところで変わりません。最初からメンバーを働きにくくして成果をあがりにくくしているわけですから当然です。