『リーン開発の現場』

スウェーデンの警察で使う捜査情報管理システムを、60人くらいで開発した記録がこの本である。前から自分はやりかけのことがたくさんあって困ったものだくらいに思っていたが、この本を読んで、新しいことに着手するのは当分あきらめようと決めた。「何かを始めるよりも先に、今の作業に集中して終わらせること」と書いてある。

この本の途中に、別の言い方で、「あらゆるキューを制限することだ！」と書いてあって、仕掛かりの作業の数を減らすという作戦が行き渡っていた。なんとバグは重要なものから30個しか管理しないという。結局のところ、仕掛かりの作業の数が減ると、やりはじめてから成果になるまでの時間が短いというよいところがあって、顧客からのフィードバックを得るまでの時間も短くなる。というか、やりかけのことがたくさん溜まっていても、外からみて嬉しいことがなくて、その無駄を省ける。

もうひとつの大切な点は、ホワイトボード上を進行していく付箋の群れの前でミーティングして、状況把握を共有するということである。面とむかって情報共有したほうが早いときはそうするという作戦なので、バグを見つけたときにシステムに登録しないでもそこのコードを書いた人に直接話して直してもらったほうがいいということになる。

現在の状況を把握するだけではなくて、付箋が動いていくのを観察していると、開発をはじめてからできあがるまでの時間は作業日数の5倍から10倍ほどで、作業していない間は待ち時間だということがわかったりもする。つまり、開発中のことは5〜10個くらいにしておけばいいだろうということになるのだろう。自分の状況を考えると、たいして人を待っている時間はないので、実は、やりかけのことはひとつかふたつというふうになっていいはずなのである。まあ、作業の種類が少ないと飽きるので、ちょっと多めにしてもいいような気がするが。

仕掛かりの作業の数を減らすとなると、次になにに手をつけるのか選択するのが大事なのである。そこで、大事なことからやるのは当然として、この本には「どの機能[の開発]が知識を生み出し、その知識によってリスクを減らせるか」とも書いてある。勝手に言いかえると、まだ扱ったことのない技術であるとか、顧客がどういう反応をするかわからないような技術、リスクがある開発を優先して行うということである。はっきり言うと研究所の仕事はこういうことであるはずなので、あまり結果がわかるようなつまらないことをしていてはいけないと思った。同じようなことはほかにも書いてあって、決定をできるだけ遅らせるということも書いてあった。

リーン開発って知らなかったのだが、実例に徹して見せてもらえて、わかりやすかった。