雰囲気でカンバンやってませんか - 『カンバン仕事術』を読んだ

　結構長い間、『カンバン仕事術』という本を読んでいます。

カンバン仕事術

　数ヶ月前、業務でカンバンツールを取り入れる機会を得ました。近くの部署の方々に話を聞いたりパブリックになっているカンバンを眺めながらなんとなーく運用をしてきたのですが、今のところあまりうまくいっていません……。
　正直カンバンツールを入れれば自然と上手くいくじゃろ、と思っていた節もあり、なんとかしようと思っていた所この本と出会いました。まだ読み終わってはいないのですが、途中までのまとめと現時点での感想・反省を書き残しておきたいと思います。続編として書くかはまだ決めていませんが、この溢れ出る思いをなんとか今のうちに書き残しておきたい……と待ちきれなくなり書き始めてしまいました。

チームについて

• 開発者3人(自分含む)、マネジメント層数人
• 運用作業はまだない
• カンバンツール導入まではGithub issueベースのタスク管理をしていた
• カンバンツールとしてTrelloを導入

本について

　大きく３章で構成されています。

• 第I部 カンバンの学習
  • 開発プロセスに悩むチームが、カンバンを実際に導入する(したくなる？)までの流れが物語形式で書かれています。
  • カンバンの紹介です
  • チームメンバーのうち何人かには、本書を回してとりあえずこの章だけは読んでもらいました。
• 第II部 カンバンの理解
  • カンバンの生まれてきた背景や概念について説明しています。
  • 第I部で出てきた用語が詳しく紹介されていきます。
• 第III部 カンバンの応用
  • まだ読んでません！

学び

カンバン導入のメリットは「改善の機会」を洗い出すこと

　冒頭で、カンバンツール導入があまりうまくいっていないと書きました。具体的には、途中からみんながカンバンに状況を反映しなくなったり、手元のお気に入りのツールにメモしてしまったりで、カンバンに情報が集まらなくなってしまったんです。
　そもそも、本来カンバンツールって何？ってところから考える必要がありました。
　導入時には「タスク管理ツール」として、以下のようなメリットを想定していました。

• タスクの進捗が見えやすくなる
• 脱Excelを達成し、キレイなUIでモチベが上がる
• Githubのコードとの連携が楽

　要は、Excelで作った職人技ガントチャートを脱して、少しでもナウい開発現場を作ろうとしていました。ガントチャート作成の手間やら管理の手間やらを減らし、少しでも長くコーディングの時間を確保したかったんです。
　ところが、結果は先程書いたとおりです。各自お気に入りのタスク管理方法があったため、なかなか情報がカンバン上に集まってきませんでした。

　この本では、カンバン導入の効果はチームの「改善の機会」(問題のこと。本書の中ではこのような表現を意図的に用いているようでした)を可視化することだとありました。つまり、ただタスク全体を見やすくして期限までに全ての作業を完了させるだけではありません。
ただタスクを全部終わらせて満足ではなく、常にその時その時の状況に応じて最適化へ向けて変化し続けるチームを作る/になること。配属以来なかなか意識できていませんでした……。

レーンの決定は真似すればいいものじゃない

　何となく導入したカンバンを見ると、大抵は「Backlog」「Ready」「OnGoing」...などのレーンが並んでいるはずです。僕のいる部署のことです。出処は色々あると思いますが、とりあえず始めてみようかーといってざっくりレーンを作ると大抵こんな感じになるのではないでしょうか。
　結論から言うと、この時点で使われないカンバン作りは完成です。使われないどころか、何も業務を見せてくれないカンバンが出来上がります。業務の流れを勝手に想像で決めてしまうと、見えるはずのものも見えなくなってしまいます。業務と業務の間にある隠れタスクを洗い出すこともカンバンの大きな役割でした。
　カンバンを使って業務を流れとして明確にすること。これって、Rx系のStreamの定義と近いところがあるように思えます。データ(タスク)の流れを定義する。どこかで処理が失敗したり、バッファから溢れそうなときはちゃんとエラー処理をする。コードやシステム上であれば想定しやすいし、完全にはできなくても考える意識は持てるはずです。何より、開発メンバーにはこっちの方が響くような気がしています！(明日伝えてみよう)

イケてるツールがカンバンツールの全てではない

　カンバンツールと聞くと、TrelloやらZenhubやら、最近だとGithub projectが上がってくると思います。カンバンを導入した際も、これらの中から検討して現在はTrelloを使っています(最低限の機能はありながら、あまり縛りがない点が気に入っています)。
　ですが、これらって結局カンバンの電子ツールの側面でしかないんですよね。立派なツールでなくても、ホワイトボードと付箋さえあればカンバンは始められます。今いる会社は業務上の都合上、電子ツールを選択するしかありませんでした。結果的にセーフでしたが、ツールの使用許可が下りず断念するくらいなら、カッコつけておしゃれなツールを使う必要はないということは覚えておきたいです。

反省

• カンバンでタスク管理だけをやろうとしない。チーム全体の隠れ作業を暴き出そう。
• カンバンのカラムはチーム全員で決めよう。その辺のボードを真似して終わりではない！
• PCやスマホ、ネット環境がなくてもカンバンは始められる！

おわりに

　本当はカンバンの原則を紹介したり、WIP制限などの具体的なカンバン運用の話をしたほうがいいのかもしれません。が、憧れだとか前の現場で使ってたからだとかで導入する際に躓いたこと、といった観点でまとめてみました。カンバン運用などについてはその先にある話だと思います。
　試行錯誤をしながら作り変えていくものなので、なかなかみんなが気持ちいい形に落ち着くことはできなさそうですが……。早めに数字として結果を計測できるようにしていくことが大事ですね。今後も本書は手元に置きつつ、定期的に見直していきたいと思います。

　また、本書ではカンバン運用のみならず、TDDやBDDなどの開発手法、さらには上手な付箋の剥がし方(！)まで触れられています。普段技術書しか買わない、といった方も、意外な発見があるかもしれません。