リーン開発の現場 カンバンによる大規模プロジェクトの運営
リーンというソフトウェア開発手法についてちょっと勉強したくなったので。
もともとはトヨタ生産方式が源流だそうで、そこからイロイロあってリーンという考え方が生まれて、そのリーンをソフトウェア開発に当てはめたのが、リーンソフトウェア開発なんだとか。
簡単に言えば機能をカードにしてボードに貼り付けて、各機能がどのステージ（設計中？実装中？テスト中？）にあるのかを見える化して管理する。という感じなのかな？
一つのシステムをインクリメンタルに拡張しながら開発していくには、なかなか良さげな印象でした。どこがボトルネックになっているのか分かりやすそうだしね。
あとはまぁ、デイリーミーティングとか、テストの自動化とか、いわゆるアジャイルな開発手法との共通点も多い印象です。
とはいえ、本書の特徴はフレームワーク的な話ではなく、実際に行われた開発現場での出来事に基づいているので、臨場感が半端ないんですよね。
現場を知ってれば「あぁ、起こる起こる！」みたいな問題にいかにして著者が対応してきたかというのが、とても参考になるんです。なるほどねぇ。みたいな。
結局はいかにしてチームを一つにするのか？ なわけだけど、どこからでも誰でも見れる物理的なボードと、全員が一箇所に集まって作業することの効果って、やっぱり大きいんだな。というのは、認識を新たにしたところです。
あと、なるほどね。と思ったのはバージョン管理の使い方なんですよね。リリースを予定しているバージョンに対して行われたバグフィクスを、いかにして次のリリースに向けて既に開発を進めているバージョンに落とし込んでいくか？ というところは非常に興味深かったです。
でもこれって、おそらく Git でないとちょっと難しいかな？ という気はしましたけど。
あぁ、そのへんの Git の知識も足りてないんだよなぁ・・・。勉強しやんとな。
その他で非常に興味深かったのは、バグをすべて潰しているわけではないというところなんです。
これはアジャイルとかリーンと言うよりも、このプロジェクトにおける判断なのかな？
実務で開発をしてると、見つかったバグはすべて修正するもの。という先入観があるわけですが、発生頻度が低くクリティカルでないバグは無視するという判断をしてるんですね。
そのバグを修正してテストしてリリースするためのリソースで、新たな機能を開発した方が顧客にとって価値がある！ という事なのかも。
個人的には「運用でカバー」という言葉は大キライなのですが、めったに起きないくて、そんなに困った事にならないのであれば、そのバグを修正しない。というのは、アリかもな。と、ちょっと目からウロコではありました。
この辺は顧客の意向も絡んでくるでしょうけれど・・・。
あとはシステムのクリティカルさとかね。人命が関わるようなシステムだと、バグを潰さないなんてありえなさそうですもんね。
結局のところはコンテキストに対してどう最善を探るかというところなのかなと。
それから本書で紹介されている事例は、おそらくトップダウンによる施策だと思われますが、マネジメントの達人ならではの手腕がいろいろと書かれてないところにありそうで、素人が同じことやっても崩壊しそう・・・。というのが正直な感想だったりして。
というか、チームをどういう状態に導くか？ というビジョンがないと判断を誤りそうというか。この辺は他のアジャイル関連の本を読んでも思うんですけど、確かに手法は手法ではあるんだけど、マインドというか心意気というか、そういうハートの部分が大事なんでしょうね。
なんじゃそりゃ？ ってところなんですが、それを突き詰めたものが「アジャイル宣言」のような気がします。なんとなくですけど。
で、自分の現場に活かせるものはあった？ となると、これがちょっと難しかったりして。
結局のところ身の丈に合った、できそうなプラクティスからやっていくのが正解な気しかしないわけですが、それでも引き出しは多いに越したことはないですから。
そういう意味でいろいろと引き出しを増やしてもらえた１冊だったかな。
つか、60人規模の開発でも、アジャイルってちゃんと効くんですね。スゴイ！
