タスク管理や業務改善を体験できる『かんばんゲーム』がすばらしすぎる

2013_ 2_21_19_25

永和システムマネジメントさんで開催された「第108回 DevLOVE − Play! かんばんゲーム リベンジ」に参加してきました。DevLOVEに参加するのは2010年以来ではないか!@yattomさんの「かんばんゲーム」は、ずっとやってみたかったので夢が1つかないました。

かんばんゲームのルール

はじめに言葉の定義としてタスクとかを貼りつける板を「かんばん」に統一。「TODO・DOING・DONE」や「設計・開発・テスト」といったそれぞれを「ステージ」と呼んでます。

このゲームをざっくり説明すると、実際に「かんばん」を使い、タスクを消化していくゲームです。さらに「Eventカード」や「Problemカード」や「Solutionカード」がゲームを盛り上げます。

2013_ 2_21_21_36

タスクにはコスト(ストーリーポイント)が書かれているので、出したサイコロの目の数だけ減っていきます。今回は1テーブル5人で、メンバー全員がサイコロを順番に1回ふり、1順したら1日とみなします。1イテレーションは3日に決定。

そして、各イテレーションはじめに、ステージごとの担当者数決めます。各チームで「設計2人、開発2人、テスト1人」みたいに配分を考えて、担当するステージのカードのみ消化していきます。

以下に感想をまとめてみます。記憶を頼りにしているので間違ってたらごめんなさい。

「かんばん」は1つじゃない

実際の仕事で、はじめはTODO・DOING・DONEのかんばんを使っていました。ただ、それだけだと「タスクの状態の管理と見える化」しかできずものたりなくなってきたので、現在は自分たちの業務に合わせてステージを増やしてます。

Screen Shot 2013-02-23 at 4.11.15 PM

写真はDevLOVE2012で紹介させていただいたかんばんです。使い方については前にブログを書きました。これを使うようになって、作業のタイムボックスの考え方が変わりました。

例えば、右端までたどりついた機能は、いつでもリリースできる状態になっています。よって、Pull型が進むにつれて定期的なイテレーション計画よりも、「減ったら増やす」ようになってきたからです。スコープも都度考えているのでより柔軟になっていきました。これは「いつでもリリースできる」という強みだと思います。

平鍋さんの記事である「かんばん」をソフトウェア開発に適用する: アジャイルからリーンへの言葉をお借りすると、このかんばんは「持続的かんばん」になります。

ゲームでは徐々にかんばんが複雑になっていきます。「ステージを分けると複雑になる」というのはもちろんなんですが、僕の仕事は大抵が「ある程度複雑」なので、複雑が悪いと考えるのではなく、その複雑さを知ることが重要なのでしょう。

逆に、仕事をシンプルにするのも大変な作業です。自分の場合、大抵はデザイナー・プログラマ・テスターなどに専門がわかれているので、シンプルさにも限界があります。それぞれの状況に応じてかんばんを進化させていく必要があるのでしょう。

なぜ待ち作業の制限をするの?

設計、開発、テストのようにステージにわかれたかんばんの場合、各ステージはさらに「WIP」と「待ち作業(Queue)」にわかれています。

2013_ 2_21_21_36 (1)

WIPは仕掛り品(Work in Progress)の制限を意味していて、数字の数だけしかカードをステージに置くことができません。そして、ゲームでは「待ちステージ」にも制限がつけられました。今回だと、開発担当が2人なら+1して3とか。

このが制限の意味がいまいちよくわからない。最後に質問させていただいたのですが、以下のような話や意見をいただきました。記憶をたよりに書いてます。

はじめのステージから最後のステージまでの「時間(サイクルタイム)」を早くするのが目的だから、待ち作業をためていくのは良くない。

でも疑問が浮かびました。ルール上、イテレーションごとでしか担当分けをできないし、他の担当を手伝うこともできません。なので、待ち状態の制限により、やることがなくなっちゃうときがありました。

ただ、その代わりにソリューションカードを引くことができるため、「待っている間勉強する」とか「腕を磨く」意味合いがあるということでしょう。でも、「手伝えない」ことによって、セクショナリズム感を感じてしまいます。自分たちさえよければいいのか?みたいな。そしてなんかすごい歯車感がある。

これについては負けてゐる日誌さんでも話題になってみたいですね(憤慨に共感)。

「なぜ担当者がいない(少ない)からといってそのステージのキューに置けないのか」と疑問・憤慨する点も含め全員納得してくれましたし。

キューの話を後でしてうまくいったそうなんですが、そのキューの話を聞きたい!マルチタスク防止以外のキューの意味ってあるのかな?平鍋さんの記事にはこう書かれていました。

よりよいプロセス制御 – WIPを制限しながら継続的流れを維持する。

じゃ、実際にキューをなくしてまち作業をたくさんつくったらどうなるか考えてみます。

待ち作業をたくさん作ったらどうなるの?

待ってる間に作業を進めたらどうなるでしょう。「開発できる状態」や「テストできる状態」にしておいたらいいんじゃないかしらん?とも思います。

そこででてきたのは「手戻りがあったら無駄になる」という意見。それをいったら全部の作業が無駄になる可能性持っているわけなのでうーん納得できない。

1イテレーションでたまる在庫ってそんなにムダ?なのでしょうか。少なくとも自動車の部品のように場所を取るわけでもないでしょうし、あきらかに目立ってきたらイテレーションの最後に対策を考えればいいはず(途中で考えなおすことができないルールですから)。

「システムの一部分が高速になっても、全体が高速になるわけではない」という話を聞いたことがあります。たしかに、明らかにステージごとで処理できる能力が違ってくると、流れはスムーズになりません。

ということは、実際の現場でスムーズな流れを作るなら、WIPを閾値みたいにして、そこに達したら何かが変だ!なんとかしなきゃ!というシグナルになるのかなぁと思いました。

全員で各ステージやればいいんじゃないか?

「各担当全員で設計をやって、開発をやって、テストをやるにすればいいんじゃ?」に対して「ウォーターフォールではないか?」という意見もありました。

ステージの区切りがいらないから、一番シンプルなかんばんになる気がするんですが、平鍋さんの記事に書かれているように「まとめて作業する」のがWFであれば、たしかに「作業が流れる感」がありません。ということは、

  • Pull型
  • 作業の流れ感
  • WIPの制限

がかんばんにとって大切な要素だというのは確かにそうだと思います。ただ、全員でやったほうが効率がいい場合はあると思うので、これもまたケースバイケースといえるかもしれません。実はWFのほうが効率がよかったとかありえますし。

おまけ:かんばんなんて必要ない!について

前に日本に来たコープさんが「かんばんなんて必要ない」と言ってたらしく、自立したチームならそんなの必要ないみたいなニュアンスだったらしい。

聞いた話でしかないですが、だとすれば結構な理想だとは思うんですが、あまりに高い理想は現実味がないなぁと思いました。だって、うちだと新人くるし、自立できるまでの時間で困るもん。海外の有識者の言葉が「正」みたいな感じになるの怖い。

でも2012年 CSM研修 (東京)を振り返るに書かれている「工場が1つなら〜」というのはわかる気がします。「ワンピース連続フロー – かんばんに代われるか?」というのも見つけたのであとで読んでみよう。

まぁ、うまくいくならなんだっていいんですよ。うまく使えればいいわけで。だから「べき」とか「ない」とかいう言葉には注意したいものです。

さいごに

このゲームはアメリカナッシュビルで開催されたAgile 2009で「The Kanban Game」という名前で発表されたものです。当時はKanbanブームもあって100人以上セッションに参加したのこと。やっとむさんすげーな!

これまでこういったワークショップは「マシュマロチャレンジ」がNo1でしたが、個人的に「かんばん」は仕事でも使っているので「かんばんゲーム」のほうがインスパイヤー!!された気がします。

ゲームのルールからゲーム中の体験まで、いろいろと示唆に富んでいるので、あんこがギッシリつまった「たい焼き」みたいなゲームでした。すごく面白かった。

資料

資料はいくつか公開されているみたいです。@yattomさんに確認させていただいたところ「興味のある方は教えてね!」ということだそうなので、Twitterでメンションしたり、最近だとFacebookに「Project Games」というページができたので、そちらにお問い合わせくださいませ。新人研修とかでも使えそう。

すくすくスクラムで開催された時の説明スライド。

当日配られたプリント。