Yes We Kanban!『カンバン ソフトウェア開発の変革』を読んだ

訳者の長瀬さんにいただいた『カンバン ソフトウェア開発の変革』を読み終えました。原書は2010年発売（もっと前かと思ってた）とちょっと古い有名な本なのですが、「カンバンってこんなのだよ」とちゃんと説明した本がなかったので、僕にとっては待望の一冊です。

この本が好きそうな人

長瀬さん曰く「管理者、PM向け」とのことですが、僕も原書を数章読んでそう思いました。たとえば

• 本書のスコープ外なので細かいところまでは書かれてないけど、数値を使って理論的に説明されている。そこらへんにある気持ちがこもったアジャイル本とちょっと違う
• 本書にも書かれているが、会社全体のバリューストリームを意識するところからはじまるので、カンバンを使った変革を進めるならミドル以上の権限があるのが望ましい

と著者もそう意識しているようです。CMMI、PMI、WIP、TOC、待ち行列理論などに興味のある or 知見のある人はより楽しめると思います。

この本をオススメするきっかけ

人それぞれ好きな作り方でいいと思いますが、個人的に思うカンバンのいいところはタイムボックスにしばられなくてもいいところだと思っています。

たとえば、スクラムだとバックロググルーミング、スプリント計画、ふりかえり、レビューやデモと準備と確認をちゃんとやります（僕は細かいところをあまり勉強しないダメな人間なので間違ってたらごめんなさい）。まー、そらそこまで準備すればたいていうまく進むと思うんですよね。

ただ、そういう枠組みをとれない場合もあると思います（そもそもそれがだめじゃん！とも言えますが）。

• 要求の変更が結構ある
• 作業の大きさがばらばら（ちょっとした直し、新機能開発、長期的なインフラ改善など）
• できたらすぐにリリースして反応を見たい

こういう状況で「タイムボックスに入れよう」と努力するのは結構しんどいので、もうちょっとゆるふわでやりたいなーと思っていた頃に知ったのがカンバンでした。

カンバンのいいところ

カンバンだとタイムボックさないでいいので、自分の好きなタイミングでリリースできます。『リーン開発の現場』の事例のように、ある程度成果物がたまったらまとめてQA＞リリースとしてもいいと思います。

また、作業を引き取る形（プル）になると、徐々にチーム内連携が盛んになります。うまくいけば「作業を効率よく流す」から自然に「協力して作業を効率よく流す」ようになります。そういう仕組みなのでスクラムマスターのようなロールも必要ありません（いたらいたでそれはOKだけども）。

そして、僕が一番いいなーと思うのは現状のやりかたを尊重しているところです。今のやり方を確認し、徐々に変化していくのが前提の仕組みです。「いいからこれやれ！」みたいなのがありません。

カンバン本の感想

詳しくは本書で！なのですが、僕の受けた印象としては・・・

• 著者やその友人とやらの経験ベースなので、具体的な出来事が書かれています。ただ、著者が在籍したマイクロソフトの話だとプロダクト感が強いので、読者のコンテキストによってはイメージしにくい部分があるかもしれません
• 使い方のイメージは『リーン開発の現場』のほうがわかりやすいです。そこからさらに掘り下げて・・・という方にはたまらない本だと思います。

• 電子ツールとの連携など、ありがちな課題も丁寧に答えてくれています。著者としてはアナログとデジタルの両方を活用がベストらしいです。

ということで、知識の再確認ができ、新たな発見もある本でした。日本でもカンバンが浸透し、日本の現場がさらに良くなっていくことを祈っています。