Shibuya.trac #13でKanbanについて話してきました。

かれこれ半年前に福井に引っ越しました。はてダではご報告せずに申し訳ないです。2011/12/10に行われたHangerFlight - Snow Barrage -で話すことになり、ついでにShibuya.tracでも話して、ということで、Kanbanについて話してきました。@kanu_さんが素振りで良かったんじゃ、とおっしゃってくださったんですが、お客さんの層が違うと思ったんですよ。だから、新幹線の中でシコシコ資料を作っていましたよ。
資料を作成し始めたら結構まとめないといけない事が多くてですね、半分もしゃべれなかった。Kanbanとは何か、ちゃんと説明されている資料は、自分も翻訳しているばかりなので、あんまりなかったのかもしれないですね。
Kanban! お客さんの視点に立ったアジャイルなやり方
Pasona Techさんで今回は開催させて頂いたのですが、会場はとても素晴らしく、おしゃれすぎて自分は場違いなんじゃないかと感じました(ぉ)。ただ、惜しいのは会場スペースではあの有名な水耕栽培スペースにもなっていて、常時点灯されているうえに、プロジェクターのライトが弱かった成果、自分の作成した資料の字が大変見辛くなってしまいました。あれだけ素晴らしい会場なので、プロジェクターは新しいものにされた方が良いのではないかと、本気で思いました。
今、紆余曲折あって、頑張ってDavid AndersonさんのKanbanを翻訳してます。まだかかりそうですが、裾野を広げるために、今回本の中の話をかいつまんでこの資料にしました。もし、この内容にピンときた方がいらっしゃれば、訳書が出てから是非お買い上げいただけたらと思います。

Kanbanというのはどういうやり方なのかと言うと、WIPを制限することで作業の流れを整理することで、スループットとリードタイムを向上させるためのやり方です。WIPというのは、(Work In Progress)の略で、仕掛かり中の作業の事をいいます。同時に進められる作業の量を制限するわけです。スループットと言うのは、ある期間内にリリースできた要求の量、リードタイムと言うのは、欲しいと思った要求が実際にリリースされるまでの時間です。「納期」だとか、「見積り」だとか、そういう話をわきにおいてみて、お客さんの立場になって考えてみると、これって結構当たり前のことだと思います。

例えば、みなさんAmazonでよく本をお買い上げになると思うんですが、Amazonのすごいところの一つは、「大抵の商品は翌日に自宅に届く」って言うところにあると思うんですよ。あれは、「「欲しい」とお客さんが思ってから手に届くリードタイムがほぼ1日」と言えます。スループットは、Amazonでどれだけの量の商品が出荷されているか、という量です。

で、例えばAmazonで在庫切れになっている商品があれば、入荷できそうかどうかで、「2-3日後配送」とか、「1週間後配送」とかなるじゃないですか。Kanbanだと、2週間以上かかりそうな要求であれば、要求元に知らせる。で、要求元は、必要なら開発キューに載せますが、必要なければと判断すれば、開発キューから取り除くとか、判断できるもの、というやり方をとったチームの事例がのってます。ただ、基本的にほとんどの機能は25日以内に納品する事が義務づけられていました。面白くないですか？こうなると、「納期」の概念がだいぶ弱くなるんです。

そのチームだと「見積り」自体がスループットを下げる要因になっていたので、「見積り」もなくしているんですが、その代わりに上記の「2週間かかるかどうかを判断する」というルールが追加されています。それで十分うまく行っているチームもあるんです。(CMMI Lv5だからできたのかもしれないですけど)

なんかソフトウェア開発には「納期」が無いといけない物だ、という常識に縛られてしまって、そういう質問が結構飛び交ったんですけど、Webサービスをやっている会社さんだったりすると「リリースしたい機能が溜まったらリリースする」という運用もできますよねー。だから、一回そういう常識から意識をずらすのはどうだろうか、という話で今回はタイムアップでした。

その後は、「なんで見積りがなくてもいいのか」とか、Kanban本の中で取り上げられている中で面白かったサービスクラスの話を資料に乗っけてます。

見積りをしても、実際に作業をしてみると、うまくいったり、うまくいかなかったりするもんだとKanban本に書かれてます。それは「ゆらぎ(variability)」と名付けられています。その辺りは確率的に存在するものなので、それ自体をコントロールするのではなく、そのゆらぎが産まれる事を前提にプロジェクトを回すようにしてみたらどうだろうとか書かれてます。

サービスクラスは、例えると飛行機のファーストクラスとエコノミークラスの違いみたいな話です。出てくる料理も違えば、ファーストクラスには特別なラウンジがあるなど、お客さんが払っているシート料金ごとに違う扱いをしますよね。要求にもそういうクラス分けを導入してみるといいよ、という話です。要求には緊急度があるはずなので、それを主にお客さんがつけられるようにします。緊急で必要な要求は、割り込んでチームにお願いできるのですが、チームのWIPが決まっているので、今手がつけられている作業は強制的にPENDになります。そして、緊急な作業自体にも一度に同時に作業するのは唯一つだけ、という制限をかけておくと、お客さんにとっても本当に一番手をつけて欲しい作業をお願いする、となる訳です・・・みたいな話をまとめてみたのでちらっと読んでみてください。