「リーン開発の本質」を再読

皆さん、あけましておめでとうございます。今年もマイペースで更新しますが、どうかよろしくお願いします。

昨年、市谷さん、藤原さんが監訳されたリーン開発の現場 カンバンによる大規模プロジェクトの運営 | オーム社eStoreは、今迄のリーンソフトウェア開発の書籍では紹介されていなかった現場での具体的なやり方が詳細に説明されています。また、この本が素晴らしいと思ったところは、色々な具体的な方法を紹介するだけではなく、「私たちが何故、システムを作るのか？」ということとしっかりと繋がっていることです。

この本を読んだことがキッカケで、数年前に読んだ日経BP書店｜商品詳細 - リーン開発の本質を再読したくなり、読み返していました。以前、読んだときとは、自分の立場などが異なっていることもあり、沢山の気付きがありました。

リーン開発では、ムダが無いかの指標としてスピードを重視しています。ムダが無いかどうかを調べるのに、よく単位時間あたりのコード行数や、ドキュメントページ数のような、一つの作業をこなすスピードを計測することがありますが、リーン開発でのスピードは、一つの作業ではなく、顧客のニーズを顧客価値として提供するスピードです。バリューストリームマップは、このスピードに着目してムダを見えるようにする強力なツールです。以前、読んだときもこの辺は同じように理解していましたが、現在は、「誰と誰と一緒にこれをやろう」と自分の行動に反映できそうに思いました。
あと、デミング博士について、7ページくらいを使って紹介されていました。今回読んで、デミング博士は「従業員に対する毎年の査定をやめる。個人の成績を評価して、チーム内の協力関係を崩してはならない」とおっしゃっていたと書かれていたことです。6章では、このようなチームや個人に対する評価について書かれており、数年前に読んだときには、あまり入ってこなかったのですが、現在自分が評価をしなければならない立場になって読むと「こんなこと書いてあったのか」と思います。
昔は、リーン開発は、考え方は理解できるけど「自分が実践する」という気持ちにはならなかったのですが、今、「リーン開発の現場」と「リーン開発の本質」を読んで、自分が実践することを念頭において勉強しなおしてみたいと思いました。