いつものかんばんをリーンかんばんに進化させる方法

  • このエントリーをはてなブックマークに追加
  • このエントリーをはてなブックマークに追加
Kanbanboards by Marcus Hammarberg

Kanbanboards by Marcus Hammarberg

ソフトウェア開発において、Todo、Doing、Doneを貼りつけた、シンプルな「かんばん」を使っている人は多いと思います。ただ、「リーンなかんばん」を使っている人は、まだまだ少ないでしょう。ここでいう「リーンなかんばん」とは、Kanbanという方法論で使われるツールです。

今回は、リーンかんばんの作り方について、Marcus Hammarberg氏の「Kanban in practice」という資料をベースに解説してみたいと思います。

用語について

この記事では、わかりやすくするために、従来のかんばんとリーンかんばんをわけて表現します。また、かんばん上の縦の領域をステージ(舞台・段階)と呼び、横の領域をレーンと呼んでいます。

さらに、かんばんにはカードや付箋が貼りつけられます。カードと付箋の使い分けについては、また別の機会に整理したいと思います。

いつものかんばん

Kanbanboards by Marcus Hammarberg

Kanbanboards by Marcus Hammarberg

従来のかんばんとは、Todo、Doing、Doneを貼りつけた、シンプルなかんばんです(資料ではScrum boardって書いてますね)。タスクボード、ソフトウェアかんばん、タスクかんばんなど、いろんな呼ばれ方をしています。従来型のかんばんは、タスクなどの状態を見える化したいときに、とても効果があります。状態もTodo、Doing、Doneの3つとシンプルですし、簡単な道具で、簡単に導入することができます。

そして、リーンかんばんは、従来型をさらに拡張したかんばんです。なんだか期待がふくらみますが、リーンかんばんを使っても革命は起こりません。ただし、リーンかんばんは進化します。この進化とは、現状のプロセスに対して、リーンかんばんをステップ・バイ・ステップで適用することを意味しています。

それでは、従来型のかんばんを、リーンかんばんへと進化させていきましょう。

ステップ1:今の作業の流れを反映する

Kanbanboards by Marcus Hammarberg

Kanbanboards by Marcus Hammarberg

はじめ方は簡単です。まず、今の作業の流れ(ワークフロー)を整理しましょう。Todo、Doing、Doneより、ちょっとでいいのでもう少し詳しく考えてみます。ここでは、それぞれステージにあるカードや付箋の状態や、それぞれのステージの担当者を意識する必要はありません。要求の定義、開発、テスト・・・など、現状のプロセスを意識してみましょう。

そして、思いついた作業のステージを、リーンかんばんに反映します。そのときに、以下の様な各ステージの意味合いも考えるようにしましょう。

・そのステージにあるカードや付箋は、どういった意味を持つのか?
・どうすれば、次のステージに行くのか?

これらの情報は、各ステージの上部に貼りつけておくと、利用者の理解が進むでしょう。

ステップ2:各ステージの状態を反映する

Kanbanboards by Marcus Hammarberg

Kanbanboards by Marcus Hammarberg

それぞれのステージのステータス(状態)を考えます。よくあるケースはDoingとDoneでしょう。もしかすると、DoingとDoneの間にReviewがある現場もあるかもしれません。カードや付箋が、どういった状態になりながら、入り口であるTodoから出口まで流れていくかを意識しましょう。

写真ではDoingとDoneを追加していますが、Doingは作業量が問題になりやすいステージです。Doingにカードがたまると大変そうです。Doneは完了というイメージですが、Doneにあるカードは、次のステージのTodoにもなります。AnalyzeのDoneにあるカードは、Devの準備ができたカード(Ready for Dev)とも言えます。

また、上の写真ではTestステージのステータスをわけていませんね。きっと、Testステージの次がDoneなので、Testステージ自体がDoingを意味しているのでしょう。

ステップ3:WIP制限を設定する

Kanbanboards by Marcus Hammarberg

Kanbanboards by Marcus Hammarberg

上でちょっとでてきましたが、Doingというステータスは気をつけなければならない状態です。中途半端な作業はテストもできませんし、リリースもできません。他の開発に影響をあたえる可能性もありますね。また、開発だけが進んでも、テストが進まなければバッファがあふれてしまいます。

こういった問題に立ち向かうために、WIP(Work in Progress)を制限します。WIPは中途半端な作業(仕掛り作業)を指しています。全体の流れをスムーズにするため、ちょうどいい制限をかけなければなりません。

WIPの決め方はいろんな方法があります。

・開発2人でテスター2人のチームなら、DevステージのWIPを2、TestステージのWIPを2とする
・AnalyzeとDevを開発者1名が担当するなら、AnalyzeとDevにまたがって制限をかける
・チーム1つに対してWIP制限1とする
・開発者1名に対してWIP制限2で始める(私の場合はこれが多いですね)
・開発がボトルネックならば、ボトルネックに合わせてWIPを決める

WIPは少なければ少ないほどいいのですが、テストチームが10人なのに、テストステージのWIP制限を1にすると、9人が暇になっってしまいます。WIPはちょうどよく少なくしなければなりません。そして、状況に合わせて変えていきましょう。

WIPが決まったら、各ステージに設定します。Doingだけに設定しても、Doneにカードがたまってしまうと、全体としての流れが遅くなってしまいます。Doneはかんばん全体の流れの中で、バッファのような機能を持ちますが、あふれてしまっては意味がありません。

リーンかんばんの進化

今回は、いつものかんばんを、リーンかんばんに進化させる方法をご紹介しました。

はじめにも書いたのですが、リーンかんばんは進化させやすいツールなので、いきなり細かいステージに分けなくても大丈夫です。使っていくうちに、必要なステージ、必要なステータス、最適なWIPが徐々にわかってくるようになります。

また、リーンかんばんに貼られたタスク等を、次の担当者が引っ張ってくる(プル)形にすれば、プル型システムとして機能させることも可能です。プル型とWIPはリーンかんばんを構成する重要な要素でもあります。

リーンかんばんはとても始めやすく、理解しやすいツールです。『Lean from the Trenches』の中では「5歳の子供でも理解できる」と書かれています。今のプロセスが複雑ならば、リーンかんばんを使ってダイエットしてみてはいかがでしょう?

*

今回の記事は、Marcus Hammarberg氏の「Kanban in practice」という資料をベースに解説させていただきました。


この資料はSlideshareにあるKanban系資料の中でも人気ナンバー1で、CCライセンスで公開されています。作り方の他に、細かいケーススタディが説明されている(パラパラ漫画みたいに)ので、ページをめくるだけで楽しく学ぶことができます。

タグ:
カテゴリー: 記事

コメントを残す

アーカイブ