リーン開発の本質 ソフトウエア開発に活かす７つの原則

投稿元：

レビューを見る

ソフトウェア開発における開発プロセスは
ウォーターフォールモデルで語られることが多いです。
しかし、ウォータフォールモデルは問題の発覚が
工程の終了間際となり、機動性に欠けます。
特に、問題の原因が要求仕様である場合、
遅れを発生させ、取り戻すことは困難になります。
ウォータフォールモデルは理想であるが、
現実的ではないと言えますが、
ソフトウェア開発における基本プロセスとなっています。

リーンソフトウェア開発とは、
トヨタ生産方式を参考に、ムダを省いたソフトウェア開発といえます。
トヨタ生産方式が万能だと思いませんが、
他分野の良い仕組みをソフトウェア開発に取り込むのが、
革新的といえます。

リーンソフトウェア開発の原則は以下のとおりです。

１．ムダをなくす

個人的な考えですが、ソフトウェアは魔物です。
ソフトウェアはのムダを作ることで仕事となり、
お金がもらえる場合が多々あります。
その結果、使用されないソースコードや機能が多く出来るけどね。

２．品質を作りこむ

３．知識を作り出す

４．決定を遅らせる

この項目が私にとって、一番感銘を受けました。
私の中で、ソフトウェア開発を成功に導くためには、
シンプル（シンプルが性能を含めた品質を向上させ、
開発効率を上げる）、
かつ、
早い判断とぶれない決定が不可欠と考えていました。
この原則は私が今まで柔軟性に欠けていたことを教えてくれました。

５．速く提供する

６．人を尊重する

７．全体を最適化する

投稿元：

レビューを見る

トヨタ生産方式をソフトウェアに応用。その背景、本質を説明。具体的な方策を書いてはいない。日本の製造業を褒めまくり。日本人として、ちとうれしい。

投稿元：

レビューを見る

前書リーンソフトウェア開発を補足・補完する内容。
リーン原則の再説明、リーンを導入する上での注意事項について触れられている。

投稿元：

レビューを見る

ソフトウェアを開発する際に、読んでおくとよい本です。
大規模開発の特定のやり方に依存した説明が蔓延している中で、本当に自分達に必要なことは何かを考える際に、考える視点を与えてくれます。
最後には、自分達の仕事のやり方の原則を作り出し、他の人達とどうやって合意を形成するかを実践していくとよいかもしれません。
実は、これまでやっていたことがすごくよいことに気がつくかもしれません。

投稿元：

レビューを見る

すばらしい本。名が体を現していない、"ソフト開発"だけでなく、IT企業の"組織設計"に多くの示唆を示している。

テイラーの科学的管理法の古典的歴史から紐解き、トヨタ（豊田一族、大野耐一）が元祖となる生産方式が、いかにサプライチェーンやソフトウェア産業に波及しているかを、豊富な事例（海外企業等）を用いて説明。

原則１．ムダをなくす（Eliminate Waste）
原則２．品質を作りこむ（Build Quality In）
原則３．知識を作り出す(Create Knowledge)
原則４．決定を遅らせる（Defer Commitment）
原則５．早く提供する(Deliver Fast)
原則６．人を尊重する（Respect People）
原則７．全体を最適化する（Optimize the Whole）

一番気に入ったのはこれ。
「リーンなマネジメントシステムは、組織の各階層（特に現場）に、熱心で思考力のあるヒトを作り出す。たとえ、自分の組織で『ヒトを尊重する』という原則以外の全てのリーン原則を実践しても、リーンがもたらしうる利益のうち、ほんのわずかしか得られない。逆に、『ヒトを尊重する』という一原則だけを実践すれば、ヒトが残りのリーン原則を発見して、実践してくれるだろう。 P143」

過渡的な個人戦の組織を、グローバルオペレーションをリーンな組織にしてみて、その姿を功労者として眺めてみたい　とつくづく思った。

投稿元：

レビューを見る

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

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

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

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

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

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

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

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

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

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

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

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

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

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

投稿元：

レビューを見る

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

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

投稿元：

レビューを見る

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

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

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

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

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

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

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

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

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

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

投稿元：

レビューを見る

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

投稿元：

レビューを見る

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

投稿元：

レビューを見る

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

投稿元：

レビューを見る

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

投稿元：

レビューを見る

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

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

投稿元：

レビューを見る

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

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

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

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

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

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

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

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