たまに耳にする「スクラムバン」が気になったので調べてみました。元ネタはCorey Ladasさんによって書かれた「Scrum-ban(スクラムバン)」です(2008年の記事なのでちょっと古いけど)。なかには読み間違い、勘違いがあるかもしれないですが、読んで感じた私の主観をふまえてまとめてみます。
スクラムバン?
スクラムが世界的に広がっているので、その中でカンバン(方法論としてのカンバンです)に興味を持っている人を見つけるのはかなり簡単でしょう。なぜなら、みんなプロセス改善やマネジメント、リーンのアイデアなどに興味があり、仕事で活用したいと思っているからです。
カンバンはチームの性能を高めることに役立ちます。すでに現在、スクラムに取り組んでいるところでも活用できるはずです。スクラムバンでは、スクラムとカンバンのハイブリッドを現場で活用する方法が説明されています。
価値と量をコントロールする
著者のCorey Ladasさんは、通貨や値段の仕組みを説明しながら、カンバンの情報カードの意味合いを説明しています。お金はモノやサービスと交換され、さらに値段は需要と供給によって変動します。
お金やモノには価値がありますが、それだけでなく量もうまくコントロールしなければ、インフレになって「レタス1つが100万円」とかになってしまいます。 カンバンを流れていく情報カードは『リーン開発の現場』でも「通貨」と表現されています。
機能カードは、ボード上の重要な価値の単位、つまり、「通貨の単位」といえる。 ―― 第4章プロジェクトボードより
通貨と同じように「量のコントロール」がカンバンでも鍵となってくるのです。そして、スクラムバンではトヨタのかんばん方式についてこう書かれています。
トヨタのかんばん方式の重要な要素は、かんばん(プラスチックのカード)を使うと数の管理が楽になること、そして1枚動いたらそれが返ってくるまで待つことだ。
しかし、(ソフトウェア開発の)カンバンの場合、トヨタのかんばんをそのまま適用できない部分が多々あります。たとえば、カンバンでは情報カードや付箋を使い捨てるので、「返ってくるまで待つ」ができません。よって、かんばん方式の利点をソフトウェアでも活用するためには別の仕組みが必要になってきます。
そういうわけでカンバンが誕生したのでしょう。では、カンバンとは何でしょうか? タスクボードと何が違うのでしょう? たとえば、こんな言葉が原文にはでてきます。
量が制限されていないタスクボードはカンバンではない
この説明は書籍『Kanban』にも書かれています。カンバンについて詳しくは「トヨタのかんばんとソフトウェア開発のかんばんの違い」あたりを参考にしていただければと思います。
スクラムをカンバンで強化する
スクラムだとタイムボックスで量をコントロールしていて、カンバンではそれをWIP制限でコントロールします。当然ですが「かんばん」と「カンバン」のように、両者には違いがあります(このあたりの違いは『かんばんとスクラム 両者のよさを最大限ひきだす』がオススメ)。
たとえば、カンバンではプル型が重要な意味を持っていますが、スクラムだとスプリント計画でやることが決まるので「プル型」とはいいにくいかもしれません。ただ、バックログが優先順位付けされると上から取っていくように見えるので「プル型」とも言えるかもしれません(もちろん無理に一緒にする必要はないですね)。
両者に違いがあれど、リーンなワークフローを目指すことは両者にとって価値があります。Corey Ladasさんはたびたび「スクラムを強化」と書いているので、合体させて強くさせようとしているのかもしれません。
スクラムがリーンに進んでいく方法とそのためのシンプルなアプローチとして、スクラムのサイクルを回しながら、プル型の仕組みを取り入れていく方法があります。例としてマルチタスクの制限からはじめることができます。たとえば、
- 作業が終わったら次の作業に入れる
- ひとりひとつ作業すること。ただし、それが途中止まってしまう作業(ブロッカー)だった場合に限り、もうひとつ作業していい
といったルールを定義することで制限できます。
ただ、注意しないといけないのは、スプリント計画で5タスクを5人でこなすため、メンバーひとりひとりにアサインしてしまうと、その人が休んだときに影響が出ます(ヒューマンクリティカルパス)。なので早めにアサインするのではなく可能な限りぎりぎりでアサインすることで(the late binding of tasks to ownersなのでそういう意味かなと……)、リーンでいう「可能な限り決定を遅らせる(Last Responsible Moment)」のように知識の最大限化へと近づけます。
もちろん、個人での最適化を広げるために「Doingはチームで5個」といったWIP制限を用いることもできます。さらに、バックログとDoingの間に「Ready」というキューを入れて、優先順位付けしたカードを貼り付けると、手の空いた人が上から順番にカードを引き取っていけるので、プル型に近づいていきます。また、Readyキューにも小さなWIP制限をすることで、本当に次やるべきことがより明確になります。
ここまでくると、シンプルなプル型のカンバンシステムになっているので「スクラムバン」のできあがりです!
さらに、カンバンの状態をわけた場合は、それぞれの状態で「何をやったら次に進めるのか?」を定義(完了の定義、準備OKの定義)するとさらにわかりやすくなるでしょう。
スクラムバンは単純に「スクラムでカンバンを使うこと」のように見えますが、原文を読んでいると、「スクラムで」をしっかり考えてる印象を持ちます。そして、ツールを活用してスクラムとカンバンの差分を埋めようとしています。
例をあげるとカンバンでサイクルタイムを安定化できれば、入力(新しい作業)に対する出力(リリース)の予想が簡単になります。そうするとバーンダウンチャートも予想可能になっていきます。規則性が生まれることでプランニングも単純作業になりそうです(悩ましい優先順位付けは残りますが)。
プランニングの単純化によって、バックログのWIP制限が可能になります。ベロシティが安定しているのでそれをWIP制限にして、スプリントごとにその枚数を貼り付ければOKということでしょうか。「それだけで足りるの?」と心配するなら1つか2つ追加して様子を見ることも可能でしょう。
きっと、それぞれのカードや付箋の見積り(大きさ)のバラつきが均一であれば(逆に言うとそういうストーリー分割をすれば)、プランニングの手間を最小限におさえることも可能です。そしてその空いた時間で品質管理や検査に時間を割く……という作戦も使えそうです。
スクラムバンを読んでみて
私はスクラムバンを誤解していました。前に記事か講演で聞いたときは「Todo Doing Done」のシンプルなカンバンを「スクラムバン」と呼んでいるようでした。しかしそうではなく、「スクラムをカンバンで強化する」ものをスクラムバンと呼ぶことを知りました。
スクラムだけでも、カンバンだけでも十分機能するでしょうが、最近だといろいろな手法を組み合わせる事例をよく聞くので、(ちょっと古い話しですが)こういったアイデアはなかなかおもしろいものです。
だって改善にはこういったアイデアがつきものですから。
コメントを残す