「カンバン仕事術」を読みました

ちょっと読むのに時間かかってしまった、カンバン仕事術。最初読んでるときは、カンバンもよさげな開発手法だなとは思いつつ、実業務の中で活かしどころがイメージできてなかったのですが、読んでるうちにちょっと霧が晴れてきた気がしたので、2周読んだ感じ。

カンバン仕事術

カンバン3原則

• 見える化
• WIPの制限
• 流れの管理

カンバンって何となく、最初の「見える化」したものって思ってたのですが、それだけでなく「WIPの制限」とそれによる「流れの管理」も必須なんだなと理解できました。見える化だけでもある程度は解決するものもあるでしょうが、カンバンから継続的な改善を引き出すには後ろ二つが重要になってくると。

「流れ」対「リソースの稼働率」

WIPとリードタイムについて疑似体験するゲーム、コイン渡しゲームの結果を受けての一言。

逆に、最後のイテレーションでは、リードタイムは短くなりましたが、それぞれの作業者の作業時間は長くなりました。効率が落ちたのです。ですが、チーム全体としては一番でした。

「WIPを小さくして流れを早くすると、個々のリソース（開発者）の効率は落ちる」ってのは、目からうろこでした。ついリソースの稼働率を気にしちゃうけど、稼働率が max なのがそのままユーザにとっての価値につながるわけじゃないですもんね。ならば、稼働率にとらわれ過ぎるのではなく、リードタイムを短くして流れを早くし、より早くユーザに届けることを意識するのは理にかなってると思いました。

そのままキャプチャで抜粋させてもらいますが、同様のことを言ってるやりとりがこちら。これはがつーんときましたね。意識改革が必要なんじゃないかと思ったところ。個人個人がそれぞれで動くのではなく、チームとして動くべき一つの理由になると思いました。

デイリースタンドアップ

他の手法でのスタンドアップミーティングとは違って、「個人の作業ではなくてチーム全体の作業・流れについて着目する」ってのはなるほどなと思いました。

多分、この辺のことを意識せずに普通にスタンドアップを開くと、「昨日やったこと」「今日やること」「困ってること」をそれぞれ個人に聞く形式をしそうだなと思ってました。だけど、カンバンでは「ボードを右から左に歩く」つまり完了に近い方から見ていって話し合うというやり方がいいようです。

---

ほかにも色々実運用を考える際に参考になるところはあったのですが、大きく揺さぶられたのはこの辺ということで。カンバン使えそうな気がするので、もうちょい追ってみようかと思ってます。