2013/2/21、develovのワークショップ「かんばんゲーム」(永和システムマネジメントの安井 力さん講師)に参加して参りました。
サイコロを使って数人で協力してよいスコア出すという、ゲームとしてもとても楽しさがあり、タスクボードからかんばんまで、その違いや価値を理解できるワークになっていると思います。

かんばんゲームの進め方は、2009年に実施された際の、川口さんのレポートがあるのでそちらをご確認ください。

また、先日のデブサミで川口さんがオープンジャムで発表された資料もかんばんを理解するのにとてもいいと思います。

かんばんゲームでは、

• 1) 普通のタスクボード(ToDo, Doing, Done)
• 2) Doingが、デザイン、開発、テストの3段階にさらにステージ分けされたボード
• 3) デザイン、開発、テストにさらに、queue、WIPをもうけた「かんばん」

のように、3段階にボードが進化していきます。

2)の段階

2)の段階では、

• i) デザインが終わらなければ、開発が着手できない、開発が終わらないとテストが着手できない
• ii) Problemが発生したストーリーは、Solutionで解決しない限り次の行程に着手できない

という制限も追加されます。

実際の仕事でも、

• 仕様の合意がとれなければ開発に着手できない
• 開発が終わらなければ受け入れテストできない

といった i) のようなことは存在しますし、

• 受け入れテスト時に仕様理解の齟齬があった
• 解消しなければDoneできない

といったii)のようなことも存在します。

実際に利用するボードもこのようにフェーズ分けをしたり、実際に問題が生じたストーリーに対して、Problemのラベルを張ることで、

• Doingのより具体的にどの作業で止まっているのか?
• どうして止まっているのか?

ということがより見える化でき、改善策を検討することができるようになると感じました。

たとえばデザインが開発に比べて進行が遅いので、「デザインを増員しよう」、といった対処が容易にできるようになるし、デザインで生じたProblemをテスターが解消するといった、「部門を超えた協力関係を促す」ことができます。
(例えばデザインが遅いということは、テスターが暇であることの見える化に繋がるため)

また、そういった分門を超えた協力関係を実現するために、いかに多能工であることが価値あることかということを気づかせてくれるツールでもあると思いました。

3)の段階

3)の段階では、ステージ上の次の行程(デザインから見た開発、開発からみたテスト)のqueueが詰まっていたら、前の行程も着手できない、というさらに厳しい制限がつきます。

つまり、ざっくりいえば、テスターに対して、「これ」と「あれ」と、いくつもの仕事を与えておき、順次やっといてね、ということはできず、

今のが終わったら「これ」やってね

という待ち行列を次の1つ分までしか登録できないという仕組みです。これをwip limitというそうです。
(wipはwork in progressの略)

これは、トヨタ生産方式のジャストインタイム生産方式とかプル型の考え方が反映されたものらしいです。
こうすることで、

各ステージ間の生産スピードをできるだけ同じにする
問題が発生したら他ステージからも素早くサポートして解消する(どこかが止まると、ボトルネックとwip limitですべてのステージが止まってしまうため)
といったことを促し、結果的にしがかり中の仕事などの無駄を極力減らしながらベロシティー最大化することに注力できるのだと理解しました。
大変勉強になりました。

是非、実際の仕事で活用してみたいと思いました。