天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます

This is leanを読んだ

を読んだので感想を書いていきます。

読んだきっかけ

リソース効率とフロー効率という概念を教えてもらい、そこで初めてリーンという単語に触れました。
その後勉強を進めていくにつれて、新版のスクラムガイドに「スクラムは「経験主義」と「リーン思考」に基づいている」という記述が追加されたのを代表に、リーンという単語を目にする機会が増えていったのですが、リーンが何なのか、何のためにできたのかが今一つ理解ができていなかったので、本書で勉強してみることにしました。

リソース効率とフロー効率という概念を知るきっかけになった資料

www.slideshare.net

印象的だった箇所

効率性マトリックス

リソース効率とフロー効率の関係性を整理しつつ、どのような業種でも多かれ少なかれ存在する変動(ソフトウェア開発であれば要求が変わったり...)が効率性マトリックスの位置を制限させてしまう話が書かれていました。
普通に仕事をしていると、リソース効率を上げるように動きがちなので*1、本書の内容を普段の仕事で活かすとなった場合は、効率性マトリックスの話がまず適用できるのかな、と思いました。

また、本書で効率性マトリックスの話を読んでから、改めて本記事の冒頭で添付した黒田さんのスライドを見ると、良くまとまっていて素晴らしい資料だな...!と感激しました。

プロセスは形式的作業ルーチンの塊ではない

まず、プロセスという単語の由来に驚きました。(詳細は本書を参照)
由来を知った上で、プロセスをどう捉えると良いのかというのを考えると、本書で書いてある「プロセスは形式的作業ルーチンの塊ではない。プロセスは形式化されたものではない」という主張に共感することができました。

TPS≠リーン

リーンと言えばトヨタ生産方式(TPS)かと思っていたのですが、関係性はあるものの別概念として発展してきたものだと言うのを本書で初めて知りました。
自分自身の知識が浅かったこと、リーンに対して不勉強だったことを思い知りました。*2

二次ニーズを埋めるための仕事

「私たちがしている仕事の多くは、発生したニーズ(一次ニーズ)を瞬時に満たせないことによって生まれている二次ニーズの充足である。」という本書の主張がぐさっときました。
自分たちのチームでも、リソース効率を重視したが故に仕事のコンテキストスイッチが不要に発生したり、全然違う方向に進んでしまって軌道修正をするのに時間を消費したりといった事態がしばしば起こっているためです。
「とりあえず少し作ってみよう」というのは、情報が足りていない局面などで重要になることもありますが、リソース効率が低くなることが怖くて、「何にもしないよりはましでしょ」という動機で発生した「とりあえず少し作ってみよう」は、チームあるいは個人のフロー効率を低下させるかもしれないので、慎重に取り扱いたいと思いました。

全体を通した感想

自分自身、リーンについて誤解していた部分も多く、リーンが元々どういう意味で使われていたのか、何を解決したかったのかが分かって、良い本でした。
Value Stream Mappingといった具体的な手法ではなくて、リーンという概念について真摯に向き合ってくれている本で、読んでいて楽しかったです。
本書の冒頭部分で書かれていたように、業種・業態を問わず、リソース活用について考える人やマネージャー業の人、ソフトウェア開発に従事する人は、読んでみて損がある内容ではないのかな、と個人的には思いました。
本書にあった、「リーンが元々の意味とは異なる意味で使われ過ぎて、上手くいくための方法が何でもリーンとして捉えられてしまっていたり、本来の意味とはかけ離れた状態でリーンという言葉が使用されていることに危機感を持っている」という主張には、何となくClean Agileっぽさを感じました。

Clean Agile 基本に立ち戻れ

Clean Agile 基本に立ち戻れ

*1:フロー効率を上げるために努力するよりも、リソース効率を努力する方が考えることが少ないので楽だと自分は思ってしまいます

*2:リーンがビッグワードになってしまっているが故に誤解が広がったと本書がフォローしてくれていましたが...