リーン開発の本質 の商品レビュー

メアリーポッペンディーク,トムポッペンディーク【著】,平鍋健児【監訳】,高嶋優子,天野勝【訳】

2019/05/10

リーン開発とは、自動車のトヨタが独自に行っていたトヨタ生産方式またはジャストインタイムと呼ばれる効率的な製造方式を、ソフトウェア開発に応用した開発手法のことです。

トヨタ生産方式といえば、在庫無し生産、かんばん、ムリムラムダをなくす、といったワードが有名ですね。戦後、日本の自動車産業が著しく発展する中で、「このトヨタって会社の生産性は異常に高いぞ！なんでや？！」って感じで、アメリカでトヨタ生産方式が注目され、リーン生産方式という名に変わり、研究が進みます。その後、そのエッセンスがアジャイルに組み込まれ、日本に逆輸入されることになります。

面白いのは、自動車開発での考えを抽象化してソフトウェア分野にうまく応用しているところです。例えば、トヨタ生産方式では在庫を極力持たないことがキーになるのですが、ではソフトウェア開発における在庫ってなんでしょうか？リーン開発では、リリース待ちの案件や、仕様が決まって開発着手待ちの案件を、ソフトウェア開発における在庫とみなします。それらは何も価値を生み出さないものなので、極力持たないほうが良い。あると管理コストがかかりし、またリリースが延びることは機会損失になる、という考えです。

他にも、「（仕様の）揺れ動き」や「機能の作り過ぎ」といったようなムダが、全部で７つあると定義されています。

気になったワードの抜粋です↓

「バリューストリームマップ」
開発プロセスごとに、実働時間と待ち時間を見える化したもの。待ち時間は、リーン開発では在庫にあたり価値を生まないもののため、極力潰すべきものになります。開発フローを見直すためのツールですね。

「プル型のスケジューリング」
タスクは押し付けられるものではなく、自分で引っ張ってくるものだ！

「決定をできるだけ遅らせる」
ウォーターフォールだと、普通はできるだけ早く決定したいところですよね。けどそうではなく、あとから変更の余地があるものは、極力ぎりぎりまで決定せず、柔軟に対応できるようにする、という考えです。

2019/01/20

本書からはいろいろなことを考えさせられた。
実例がこれでもかというくらい盛り込まれているのも良い。

読み終わったら付箋を貼った箇所は30箇所ほどになっているし、アンダーラインを引いた箇所はもっとある。

なかでも「すぐれたソフトウェア製品の開発形態は、もはやプロジェクトではない」というくだりには目鱗だったし、リーン開発からみたTOCに関しての考察が面白かった。

また、平鍋さんによる12ページにもおよぶ「監訳者あとがき」も本書の読みどころのひとつで、これがついている分、原著よりも価値の高い本になっているのではないかと思う。

2018/11/12

トヨタのリーン開発をソフトウェア開発に適用したらどうなるかに取り組んだ本。各社の豊富な事例が示唆に富む。

・欠陥を未然に防止する検査
・何かが起こるまで待ち、それから素早く的確に行動する。未来を予測するよりも、予測可能な成果を生み出せる。
・情勢によって計画はどんどん変えていかなければならない。
・標準は探索のベースラインにすぎない
・リーンにおける標準は、常に現場で指摘を受け、改善されるべき存在である。
・待ち行列は作業の2サイクル分が適当

2017/07/17

リーンと名打ってますが、アジャイルの本質的な書籍。トヨタ方式こそアジャイルの言論であることが分かります。在庫管理のオペレーションを現場に求めることがトヨタ方式であり、これがソフトウェア開発における個々人のモチベーション管理に適用したものがアジャイルとしてまとまっていきます。逆に言えば、古き良き日本の製造業こそアジャイルです。なんで今更アジャイルありがたがってんだ、にっぽん。

2017/03/16

カンバンや豊田のカイゼン方式を発展させたリーン開発を哲学的に捉えるために読みたい本。
手法というより、意識や考え方に重点を置いているので、実践しながら長期間に渡って読み進めるのがよいのではないだろうか。

2014/10/23

2008年の本だけど時代は変わらずで面白かった。間に入ってくるたくさんのコラムや引用が話をくっきりさせる物になっててとても良い。
あとデミングの14項目が印象に残った。

2014/08/08

設計時には気づかず、実装でしか見つけられない不具合はあるので、早く作って早く失敗するというのが大事というのは良くわかる。
あと、運用コストが高いものより、低いものを優先して作るべきっていう考え方は面白かった。

2013/12/23

原則２：”品質を作りこむ”　という言葉が好き。

リリースして、リファクタリングかけて、自動テストして、リリースして。
常にシステムをいい状態においておく。

使う人も、マーケットも、企画も、業務も、
全て流動的で変化し続ける。
だからシステムを時代に追随させていく。

その品質を作りこむことは可能だと思う。

そのために必要な要素は、
人であり、その人の技術力だと思う。

頻繁なリリースを可能にするには、
コードが容易に解読できないと難しいだろうし、
容易なコードにするにはリファクタリングは不可欠だろうし、
リファクタリングをかけるには自動テストは必要だろうし、
自動テストやるには・・・・。

全ての原点には人がいる。
だからその人が知っていて、理解していて、実行できないと、
何もできないのだと思う。

現状を確認して、
方向性を合わせて、
できることを一つずつ増やしていく、
できる人を一人ずつ増やしていく、

それが品質を作りこむことなのだと思う。

（以下抜粋。○：完全抜粋、●：簡略抜粋）
○マネージャとは、その人が監督する分野で名人になった教師なのである。
　新人のエンジニアを訓練し、弟子から職人へ、
　職人から名人エンジニアへと変えていくのだ。（P.19）

○ソフトウェアの機能の半分以上は、最初のリリース以降に開発される（P.25）

○優れたソフトウェアデザインとは、
　妥当な実行性能を実現しながら、
　ソフトウェアの構築・修正・保守にかかる時間を最短にするものである。（P.25）

○ソフトウェア業界では、価値が変わりやすい。
　それはたいてい、顧客自身が、
　自分たちの欲しいと思っているものを本当には知らないからだ。（P.28）

○ソフトウェアのムダを排除する、
　最高のチャンスをもう一度振り返って見よう。
　それは、「コードをできるだけ書かない」ことである。（P.35）

○専門知識をすべて外注に任せている企業は、
　競合他社も同様に外注できる、ということに気づくだろう。
　専門知識など必要ないと考えている企業は、
　維持可能な競争優位を何ひとつ持ち合わせていないことに気づくはずだ。
　聡明な企業なら、確実に、目的に合ったエキスパートエンジニアを育成して、
　目標達成に必要な専門知識を備えた人員を配備しようとする。（P.45）

●コンピュータ化とは、標準化することであり、目標を絞って行う。
　（中略）
　開発者はシステム機能を最大にするのではなく、最小に絞る。（P.85）

○ソフトウェア製品に対して見境なく機能を詰め込むのは、
　マーケティングをサボっている証拠だ。（P.87）

○すべてのコードは、書くのにもお金がかかるが、
　サポートするのにさらにお金がかかる。
　不要なコードを書くぐらいなら、
　開発者にはサーフィンでもしてもらっていたほうがよっぽどいい。（P.87）

○トヨタの真の強みが、『普通の』従業員の知恵を終結する能力にある（P.143）

○本当にコーディングを学びたいのであれば、
　オープンソースプロジェクトに参加するとよい。（P.243）

○最初にテストを書くと、通常は設計がシンプルになる。
　テスト可能なコードを書いていると、コードの結合度が弱くなるからだ。（P.248）

○プロジェクトはそれぞれ1回かぎりの取り組みであるため、
　見積もりは憶測にすぎない。
　つまり、プロジェクトはそもそも、
　未知の要素でいっぱいだということだ。（P.288）

○監督者は自分の監督する作業に関して、
　高度な技術を備えている必要があると考えた。　（P.291）

2013/07/21

Implementing Software Development
From Concept to Cash
ソフトウエア開発に生かす７つの原則

問題が発生したら、ほぼ間違いなく、その原因はシステムに内在している。
したがって、それはマネジメント側の問題である。（デミング）

2013/02/11

ソフトウエア開発にリーン開発を適応するための7つの原則について書かれた本。
アジャイル＋トヨタ生産方式＝リーンソフトウエア開発
といったところか。

事例も多くわかりやすく、アジャイル開発がベースとなっていて、TOCの理論まで広げて語られています。さらに、筆者は日本のこと（トヨタのこと）をよく研究しており、トヨタの改善活動から始まり、日本の論文も引用されているので、より理解を助けられます。5Sについても語られていて、ちょっと面白いです。

一通り読み終わった後で、監訳者(平鍋さん)のあとがきがあります。ここを読むだけでも十分では?と思えるほど、まとめとして理解を助けてくれます。

さて、リーン開発をソフトウエア開発に活かす7つの原則とは

１．ムダをなくす
２．品質を作りこむ
３．知識を作り出す
４．決定を遅らせる
５．早く提供する
６．人を尊重する
７．全体を最適化する

の7つです。
それぞれにより詳細に
１．ムダをなくす
・マーケティングと技術の両方を理科強いているリーダを任命する
・価値のみを生み出す
・コードを出来るだけ書かない

２．品質を作りこむ
・同期する
・自動化する
・リファクタリングする

３．知識を作り出す
・設計･構築チームをつくる
･継続的な改善を行う文化を守る
・問題解決手法を教える

４．決定を遅らせる
･完全に使用を決定してから開発に着手するのが良い方法である、という考えは捨てる
・依存性を断ち切る
・選択肢を持ち続ける

５．早く提供する
・小さなバッチで作業を進める
・作業を許容量までに制限する
・利用率ではなく、サイクルタイムを重視する

６．人を尊重する
・チームリーダや監督者を訓練する
・責任や意思決定を出来るだけ下のレベルに委譲する
・技術へのプライドを育てる

７．全体を最適化する
・バリューストリーム全体、製品全体を通してリーン手法を実践する
・計測基準を作り直す
・境界越えのコストを減らす

本書のあちこちにヒントとなるトピックやエピソードがちりばめられています。
ちょっと面白いトピックスはグループとチームの違い。よく、XXチームとか言って使っていますが、実際には、それはグループだったのね。って反省。
そんなところから、やはり、最も重要なのは「人」。本書では、技術的なところや仕組み的なところはもとより、やはり「人」に対するメッセージ性が出ています。

一度読んだだけでは、十分に理解できたとは思えません。繰り返し読みこなす必要がありそうです。
お勧め!