■本の情報 緑字が私の感想/補足説明です。 リンク先は用語に対する私の解説です。■リーン開発の背景 リーン開発はトヨタ生産方式(TPS:Toyota Production System)をベースに考えられ、1990年にジェームズ.P.ウォマックら著「リーン生産方式が、世界の自動車産業をこう変える」にて、TPSをリーン生産という呼び名に変えたところから始まります。
その後、本著者がリーン開発をソフトウェア開発に適用した場合の開発手法をまとめております。本書以降もリーン開発に関する書籍は出ており、エリック・リース著「リーンスタートアップ」はベストセラーになっています。 ■アジャイル開発との違い アジャイル開発 とリーンソフトウェア開発はセットで語られることがありますが、アジャイル開発とリーンソフトウェア開発の違いについて私の理解を説明します。
アジャイル開発とは、要件定義⇒設計⇒検証を小規模な実装とテストを繰り返して開発を進めるプロセスのことで、リーンソフトウェア開発とは、アジャイル開発を進めるための原理や手法の一つであると理解しております。■要約 ＜7つの原則＞ 以下いずれの原則も本著で発見された原則という訳ではなく、仕事の進め方として、あるいはソフトウェア開発においては一般的な事を述べられていると思いました。
この7つの原則は、数ある仕事の進め方あるいはソフトウェア開発において、特に重要だと考える原則をピックアップしたという点、またそれらを解りやすく解説したという点に、本著の素晴らしさがあると私は考えています。人月の神話 (1975年初版)」をリスペクトしての言葉であると考えます。
もしかして神話を"絶対的に正しいもの"として受け止めたら誤解が生じる可能性があります。 ① ムダをなくす 神話：早く仕様を固めればムダが減るパレートの法則 という)。
コードをできるだけ書かないという事を念頭に本当に必要なものを初めに入れて、必要ないかもしれないと今思えるものは、よく吟味した上で後から入れる (YAGNI:You Aren't Going to Need it 今必要ない機能はつけるな)。
新たな機能を追加する際はリファクタリングしながらコードをシンプルに保つ。または、必要ないと思えても諸事情で致しかたなく入れた機能で、結果的に必要がないと解った機能は後追いでもその機能を削除する事も重要であると思われる。 ② 品質を作りこむ 神話：テストの役目は欠陥の発見だ ③ 知識を作り出す 神話：予測が予測可能性を生むそのとおり文書が膨大だと読み手は読む前にお腹一杯になり読もうとしない。読ませるようにする工夫としては、文書をタグ付け分類するか、検索性を向上させるなどが考えられるが、それでも読まない人は読まない。自ら知識を取りに行くという組織の風土づくりが必要と考える。またプロセスを固定化しないのは同意だが文書化は必要で、すぐに改変できるような体制にすべきと考える。 ④ 決定を遅らせる 神話：計画は決定である私も重要な決断は早く決定した方が、全体としての手戻りが少なくなるので良いと思っていたが、この原則について一理あるなと納得した。この原則を自分の組織で適用しようとした場合、計画は変更されることを前提に動いた方が、結果的には手戻りによる工数をペイできる程価値があると周囲を説得する必要があるので、ここが一番の課題だと思った。 ⑤ 速く提供する 神話：急がば回れとあるが、そんな人材を育成するのが難しい。結局は、この原則以外の原則を実践すれば、品質が上がり、結果として速く提供できるのではないか。
また早く提供できれば、顧客に気を変える時間を与えることなく、ソフトウェアを提供できるというメリットも生まれる。(3) 依頼元は仕事を引き受けてもらえたと判断したら、その仕事が完了するまでの期間が長い分だけ、待ちのストレスがかかるが、そもそも相手が仕事を引き受けていないという状態の方がストレスは少なくなる。
これは混雑中の飲食店でも使われる手法で、接客が回っていない場合は、例えテーブルが空いていても客を店内に案内はせず外で待たせておき、落ち着いていたら案内する方が良いという手法である。
一度店内に案内された客は、その時点で客としての扱いをされるべきという心理が働き、待たされる時間に非常にストレスを感じるが、外で待っている間は、それほどストレスにならない。
⑥ 人を尊重する 神話：唯一最高のやり方が存在する(4)について ⑦ 全体を最適化する 神話：分解によって最適化する個別最適化せずに全体最適化を目指することは誰も異論を唱えないと思うが、それをどうやって実現するかがソフトウェアの世界では非常に難しい。
トップメニューへ