リーン開発_第10章_旅立ち - ゆるい感じのプログラムを書きたい。

どこに行きたいのか？

「次に何をしたらいいですか？」とよく聞かれる。

第７章では、次の２つの問に答えるところからリーン活動に着手するように勧めた。

１．どのように顧客価値を作り出し、利益を上げようとしているのか？
２．現時点の最大の問題は、具体的には何なのか？

これに、さらに２つの問を加える。

３．今後の存続を脅かすのは何か？
４．人について、何を本当に信じているのか？

車輪をつけたコンピューター

同業他社は、人件費を減らすために自動車工場を最新鋭に自動化していたが、トヨタは、実験の結果、自動化しても総コストを考えれば採算が合わないという結論を出した。
競合他社は、コンピュータによるスケジューリングシステムやクロスドッキングの自動化に重点的な投資を行ったが、トヨタは、生産プロセスの中心には人がいるべきであり、シンプルな手作業によるシステムのほうがうまく機能すると考えた。
トヨタの経営層は、従来、物流や生産スケジューリングに情報システムを用いる事を認めてなかった。
情報システムの利用にそれほど注意深かった企業が、生産プロセス、開発プロセス、そしてその製品に対して、情報システムを活用するリーダーになったことは特筆に値する。

長期的な展望

教会、軍隊、大学などは何世紀も存続する。どうして、大企業は、早く倒産したり、買収されたりするのだろうか？

さらに重要なのは、どうして優秀な企業は、何世代もの経営者にわたって存続し続けられるのかと言う点。
そういった企業は、創業期を乗り越え、成長の痛みに耐えただけではなく、大規模な多国籍企業になった。

しかし世界が変わり、成功していた企業の多くは、新たな現実に順応出来なかった。

一方、成功した組織は、急成長を遂げるなか、市場に十分な需要があるうちに、習慣を確立する傾向にある。

しかし、最終的には、すべての成長要因が勢いをなくし、過去の成功が将来の成長へ道しるべとならなくなってくる。

そうなった場合、学習能力、適応能力を身につけた組織のみが生き残る。
手遅れになる前に将来に適応できるような構想を描くのは、マネージャーの能力であると考えている。

しかし、残念ながら、マネージャーは過去の栄光にこだわりたがり、未来に対して鈍感になりやすい。

この実績のあるマネージャーほど将来を見通せないという考え方は、クレイトン・クリステンセンも著者のなかで繰り返し主張している。
彼は、利益を維持するために高級志向に行こうし、利益率の低い大衆志向の市場を競合他社に譲る企業は「破壊的技術」によって追い抜かれていく場合が多い。

そのような企業は、現在の顧客を非常にうまく満足させているために、将来のリスクや利益の低下などを想像する動機が、まったくと言ってよいほどない。

コンピュータ業界では、小型化、高速化、省エネ化されたハードウェアが、大型の利益率の高い装置に取って代わっているように、常に破壊的技術にさらされている。
ソフトウェア業界では、安価のソフトウェアパッケージが高額の人数比例料金契約に取って代わりっている。
IT業界のように動きの早い業界では、将来の構想を立て、それに適応できるようにしておくことが生き残りを左右する。
組織が長期的な存在を望むなら、常に洞察に満ちた将来の展望を描いて、その長期的なビジョンに基づいて決定を下さなくてはならない。

人を中心に置く

科学者ならば、効果的な問題解決の第一歩は、ものごとが実際にどのようなしくみでうごいているのかを深く理解し、それを反映するための概念的な枠組みの中に問題を置くことだという。

現場での技術の活用法に関しては、２つの考え方がある。

１つ目は作業を遂行するために必要とされる人数や、必要とされるスキルレベルを低く抑えるため、既存の作業を自動化すべきという考え方。
２つ目は作業者の能力を高めるために技術を利用すべき。

トヨタでは２つめの後者の考えに基づいて動いている。

１つ目は何が悪いのか？

繰り返し行われるタスクは、自動化すべきではないだろうか？

実際、８章で記載下通り、ビルドや導入のプロセスを繰り返し行われるタスクお自動化すれば、ばらつきがなくなり、確実で一貫した結果が得られる。しかし、あるプロセスから人を除去すれば（あるいは、人に、あるプロセスを機械的にこなすように求めれば）、そのプロセスでは、もはや何の変化も生まれず、適応も、発見もなくなる。

例えば、製薬会社では

何十億ドルもの資金を、繰り返し行われる薬物研究作業の自動化につぎ込んだ。研究室の技術者たちをロボットで置き換えて、
技術者たちが成し得たよりも、はるかに多数の薬物調合をテスト出来るようにした。

そうすれば、はるかに多くの超大型新薬が生まれるはずだと考えたのだが、まったく期待はずれに終わった。多くの人の推測によれば、それは、新薬実験という仕事の「単純作業化」と、人という要素の排除によって、探索すべき領域を企業が暗黙に想定してしましい、予期せぬ結果に気づき新しい実験を試して見る人ならではの能力を生かさなくなったため。

製薬会社でのテスト自動化と、ソフトウェア開発でのテスト自動化との違いソフトウェアでのテストの効果的な自動化は、テスト技術者の「技能向上」につながったという点である。

決まりきった繰り返しテストを自動化したのは、テスト技術者を解放し、開発プロセスのポカヨケの実現、ユーザにとって使いやすいソフトウェアの制作、探索的テストや特性テストの実施に集中させるため。
一言で言えば、単純作業化は交換可能な人を生み、技能向上は思考力のある人を生むということ。

プロセスにどのような態度で取り組んでいるか、考えてみよう

きちんとドキュメン化され、誰もが質問することなく従えるようなプロセスが、正しい道だと考えているだろうか？
プロセスを標準化するのは、その作業をする人に、疑問に思ったり変更したりするための土台を与えるためだろうか？

リーン原則は確実に、後者の考え方に根ざしている。

自分がスケジュールとどう向き合っているのか？

開発チームが時間内で何が出来るのか、自分たちで決めて、それをマネージャーに伝えるように」と言われたら、マネージャー側に決められる場合よりも、不安に感じるだろうか？
作業のアサインについてはどう向き合っているだろうか？
自分たちで次に何をするかを考えるのは、それを指図されるよりも不自然に思えるだろうか？

リーンを成功させるには、作業を行っているその人本人が、その作業のやり方を最もよく知っているのだ、という基本信念を、あなた自身の人に関する概念的枠組みに取り込まなくてはならない。

プロセスから人を排除したり、作業に必要なスキルレベルを下げたりする自動化は、注意が必要。職場での獅子決定に何度もの（あるいは、一度でも）承認が必要となるなら、それをおかしいと思わなくてはならない。

問題を解決するには

本当に、作業を行う人たち自身に、トレーニングを行ったり、ツールや権限を与えたり、支援をしたりして、
自からの問題を解決し、プロセス改善できるようにするのが最善の手法だということを信じる。

リーン以前の改善活動から学ぶこと

何かを変えようとする前に、すでに存在する有益なアイディアを調べて、そこから何か学べるのかを確認するのは良いこと。

シックスシグマとTOC(制約理論)の２つの活動について

シックスシグマ

シックスシグマの初期段階における問題は、製造に適したプラクティスを、開発プロセスに適用したことにある。

開発では、ばらつきが善であり、失敗した実験からも成功した実験と同等の学習効果があることがわかり、企業は、ソフトウェア開発にはシックスシグマの改良版であるDFSS(設計開発のためのシックスシグマ)が適しているということを理解した。

顧客の声の発掘とデータ駆動型の問題解決に重点をおくDFSSは、開発チームに多くの利点をもたらす。

プロセスリーダーと現場の作業チームのリーダー

シックスシグマとトヨタ生産方式の違いは、変革推進者の役割

シックスシグマ 労働力の約１％を「ブラックベルト」と呼ばれるラインの責任を持たないプロセスリーダーとして訓練することを推奨

トヨタ生産方式 プロセスリーダーや変革推進者ではなく、現場の作業チームのリーダを重点的に訓練することを推奨

<理由>

作業のチームリーダこそ、作業チームを率いるべきであり、成果に責任を持たすべきと考えているため。

リーンでは、トヨタ生産方式を踏襲すべきであり、プロセスリーダーよりも、現場の作業リーダーの訓練を重視すべきである。

ツールと成果

ある向上で、劇的に改善が見られたが非常に低い評価しか得られなかったケースが有る。
それは、「不可欠」と見なした、企業内で認定済みのプロセス改善ツールを採用しているという証拠を支持しないまま、優れた結果として出したため。
すべてのツールは、特定の問題を解決するために作り出されたものである。

あるツールが、当面の問題を解決するのに最善と言えないのなら、そのツールは使うべきではない。作業チームやそのリーダーは、経験に基づいて問題を解決するように訓練されるべき。

今抱える最大の問題の解決に、適したツールを採用出来るだけの権限が与えられるべき。

TOC(制約理論)Theory of Constraint

TOCという言葉を生み出したエリヤフ・ゴールドラットは 技術では、何かの制限を軽減しない限り(制約を取り除かない限り)、何の利益も生まない、という命題を掲げている。

制約を新技術を導入するだけで、排除すべき制限が取り除かれるとは限らない。
その制限に対処するために作り出された適用手段(accomodation)は、企業にあまりにも深く染みついて、認識すらされていないから。

例えば

ISPが一般的に電子メールサービスを提供するようになっても、大企業が自社の電子メールを外部に開放するまでに何年もかかった。
家庭では、家から外部に対して電子メールを送れるようになってから、かなりの時間を用いいてようやく会社の電子メールシステムを使って、ベンダーとコミュニケーションを取れるようになった。

制限を取り除く上で、難しいのはその制約を乗り越えなくてはならないだけではなく、その制約に対処するために作った過去の適用を認識して（これは難しいタスク）それからその手段を除去し、最後に新たなルールに置き換えなくてはならない。

新技術を導入するために、ゴールドラットは次の４つの問に答えなくてはならないと言っている。

1.その新技術には、どのような威力があるのか？
2.その新技術には、どのような制限を軽減するのか？
3.その制限に対処するために、そのようなルールが役に立ったか？
4.その制限が置き換えられたら、どのようなルールを採用すべきか？

ERP(統合業務ソフト)を例に考えてみよう。

マネージャーが、適切に意識決定を行いやすいように、大量の情報へのアクセスを可能にしたかつての新技術。

ERPが存在する以前はシステム全体に関する決定を行うためのデータがなかったため、部分最適を生み出すルールに基づいて決定が行われた。

例えば

製造のマネージャーは機械の効率を最適化しようとしていた
営業のマネージャーは製品の価格を決定するために、原価計算式を用いていた

上記のように、そうするしかなかった頃は、部分最適化に元で浮いて決定を下すは、最適な手法で、きまぐれな決定に比べれば、はるかによい成果を生み出した。

しかし、ERPによってシステム全体を見渡したうえで、より適切な決定をくだせるようなデータが得られるようになったのなら、部分最適のためのスルールを捨てなくてはならない。

そうしないとERPの実力が発揮できない。
ERPが失敗した原因の多くは、ERP以前に使われていた手段の撤廃やルールの見直しができなかった点にある。

クリティカルチェーン

クリティカルチェーンとは、ゴールドラットがTOCプロジェクトに適用する際に使用した言葉。

プロジェクトの重要な制約は、見積もりが確約と見なされた時に生まれる。
プロジェクトに携わる人達は、それぞれの活動に必要となる作業量を見積もるように指示される。
プロジェクトはそれぞれ1回限りの取り組みで、見積もりは憶測になる。
プロジェクトは未知の要素でいっぱい
見積もりを出す人は、万一の場合に備えて大量の「ゆとり」を含めようとする
ただ、上手く言った場合も、結局は見積もった時間をすべて使い切る、何故なら見積もりを出した側は、過剰な見積もりをしたと思われたくないから。

見積もりをあくまで見積もりとしてとらえて、個々の見積もりに加えられたゆとりを除去し、プロジェクトバッファとして一括管理することを推奨この手法によって、はるかに素早く完了し、プロジェクトバッファを使って、あらゆる変動を吸収することができるようになる。

注意しなくてはならないこと

目標と報酬のメカニズムに組み込まれた過去のプラクティス（日常的な活動）への適応手段を変えないかぎり、プロジェクトバッファがプロジェクト全体のスピードアップにつながらないという点

クリティカルチェーンを機能させるためには、上級管理者から見積もり作業を行う人達まで、全員がこの期待をすてないと、結局、個々の見積もりにバッファを含めることになってしまう。

クリティカルチェーンをソフトウェア開発に適用する際の注意点

開発を完了させるのに必要な全ての活動が事前にわかっていて、その活動間の依存関係を明らかにしなくてはならない、という想定があるが。これは殆どのソフトウェア開発では不適切な想定になる。

何よりもまず、開発作業が始める時点ですべての欲求が出揃っているべきだという考えを捨てなくてはならない。依存性を解消するために最大の工夫を行う。

上位レベルにおいては、クリティカルチェーンのプロジェクトバッファは有用かもしれないが、詳細レベルでは、それは過去への適応手段になる。

依存関係を解消し、少しづつ動くソフトウェア開発する専属チームを出来ることが出来たら、クリティカルチェーンが解決しようとしていた問題は存在しなくなる。

適応手段(accommodation)

プラクティスやプロセスやルールには、現実の、あるいは想像上の制約への適応手段がいくつも組み込まれている。ただ、実践しているプラクティスの多くは、すでに古かったり、実際には起こり得ない問題の対処するために導入されることが多い。

例えば

コスト、スケジュール、スコープを早期に定義し、プロジェクトの始めにはすべての資金を確定させるというプロセスがあるとする。

しかし、たいていの新製品開発の場合みたいに、プロジェクトへの資金調達が段階的に行われるのであれば、プロジェクトを始める前に確定させる必要はない。

開発環境ですら、年数が経つと異なってくる。
当初は、限られたメモリー領域や処理能力、コミュニケーション手段、選択できるソフトウェアの対応を行うために作り出した適応手段も、すでに適切ではない。
そのように急速に変化を続ける環境においては、既に存在しない、古い制約のために、対処法を作り続けないよう、警戒が必要。

リーン開発を着手するため仮設を立てる

リーン開発に着手する、最も有効な手法は以下の通り

(変革推進者よりも)チームリーダーと監督者を訓練する。
(ドキュメントよりも)実地の思考を重視する
(多くのデータを計測するのではなく)要となる少数の指標を計測する。

訓練

チャールズ・アレンという科学者は、マサチューセッツ州ニューベッドフォードで産業教育プログラムを開発していた。チャールズ・アレンは、訓練の大部分は実地で行われるべきだと考え、監督者に作業者の訓練方法を教えることに重点を置いた。

監督者は自分の監督する作業に関して、高度な技術を備えている必要があると考えた。
あれンの訓練プログラムでは、準備、実演、適用、試験の４段階に分けて、監督者に知識を伝達する方法を教えている。
アレンは造船監督に作業者と協力し合って問題を解決するように言っている。
彼の哲学は「学習する側が学習しないのは、教える側が教えていなかったことであえある」というもの

1940年にアメリカの軍需生産委員会で、監督訓練(TWI)を開発したこの訓練プログラムでの骨子は、次のようなもの

■教える技能(JI=Job Instruction) この訓練プログラムでは、ベテラン作業者が作業は非常に的確に行えるものの、その作業のやり方をほとんど教えてことがないという前提で作られている。

監督者は

１．作業者に準備させ
２．業務を実施し
３．作業者に業務をやってみせ
４．頻繁にチェックし、質問を促し、作業者が熟練していくにつれて徐々にコーチングを減らすようにフォローする

■改善する技能(JM=Job Method) この訓練プログラムは、作業者本人が改善に関する優れたアイディアを数多く持っているのだが、そのアイディアに沿った行動を必ずしも取れないという前提に立って作られている。

監督者は、作業差が

１．作業ブレークダウンし
２．細部を吟味し
３．同僚とともに新たな手法を作り出し
４．その手法を広く受け入れさせ、承認を取ってそれを適用できるように手助けすること。

■職場の人間関係(JR=Job Reliations) この訓練プログラムは、監督者が作業者を個人として扱い、彼らが「人間関係」の問題を効率よく公平に解決する手助けとなるように、と教えている。

監督者は

１．全体像をつかみ
２．問題に優先順位をつけて結論を急がず
３．責任転嫁せずに自ら行動を起こし
４．フォローアップをして結果をチェックする

思考

大抵の改善前活動では、ドキュメントを必要以上に重視しすぐていて、各人に常に自分の作業環境の改善方法を考えさせることに、あまり重点を置いていない。
ほとんどの企業が、社員に十分改善について、考えさせていると思っているが、いいアイディアがあればそれを書き留めて提出できる提案システムを作業者に用意しているが、おの提案活動も改善という点から見れば、ほとんど効果はなかった。
ソフトウェア開発では、振り返りを使って変更すべき点を書き出したりするが、同じ内容が何度も繰り返しで出てくることが多い。
提案活動やブレインストーミングで出されたアイディアの多くは、誰かに引き継がれて、評価されたり、ときには実現されたりするのは間違ったやり方
アイディアを持っているチームメンバー自身が、自らのアイディア実現すべきで、他の人が実現することを前提に、提案システムにアイディアを出させても意味がない。
優秀なアイディアの長いリストに、自分のアイディアをただ付け足しているだけではだめ。
改善に関する優れたアイディアが、誰か別の人の問題として手渡されたら、発案者はそのアイディアを自分で推し進めようとしなくなる。
その問題についての暗黙知もまた、発案者の頭の中に残されたままになる。
すべての作業者が自分たちの現在行っているプロセスのシクミに、常に疑問を感じるべきであり、新しいアイディアを試したり、うまくいくアイディアを実現したりするために、効果的な問題解決テクニックを積極的に使うように推奨されなくてはならない。
この問題解決プロセスの基盤として、ドキュメントが存在すべき。
このドキュメントは、作業チームが作って、使い、保守し、手軽に変更できるようでなければならない。

<考えを変えないといけない部分>

やる気と思考力のある人材に価値があると考えるなら、ドキュメントのにもとづいたプロセス評価を見直す必要がある。
通常、そのような評価は、組織が、ドキュメント化された手続きに従っているかどうかで、その組織の成熟度を計る。
一見、この目的は無害に見えるが、実際には、評価プロセスは組織にドキュメントを凍結するように強いるのが常なので、そのプロセスを変えさせまいと圧力もかかっている。
その結果、困ったことに、第一線の作業者たちから「考える権利」を奪ってしまう。
作業者はドキュメントに書かれている通りにやるように促される。

<変えるためには>

作業者は、ドキュメントに書かれている内容に、常に疑問を持つように促されるべきである。
ドキュメント重視のプロセス評価は、ドキュメントの安定性を重視しがち。
実際は、ドキュメントの頻繁な変更こそ、その組織が思考できるようになった証拠だと考えるべき。

計測

開発チームを効果的に計測するの方法を見つけるのは難しい。なぜなら、開発作業が終了してからしばらく立たないと、その効果が目に見えない場合が多い。

そのため、プロセスの各部分が最適化されれば、プロセスの成果物も最適化されるという前提から、計測を増殖させることになる。
この前提は「システム」としてのものの見方からすれば、根本的に間違っている。
まったく制御不能なプロセスをスタート地点とするのであれば、プロセスを部分毎に最適化しても利益はある、だた、部分最適化によって、システム全体の最適化を妨害することになる。
誤った計測を改善しようとしても、間違った誘因を作り出すことになり、多くの場合は意図しなかった結果につながる。

例えば

プロジェクトマネージャーがよく、アーンド・バリューに基づいて計測される。
しかし、アーンド・バリューを検測すれば、計画通りに進めたかどうかを計測することになる。
つまり、その計画が望まれた結果を達成するための最善の方法で合ったかどうかという点は、まったく無視されてしまう。
これが予定通り、予算内で計画通りのスコープを完成させた形でソフトウェアを提供しても、やはり顧客に不満を抱かせる理由になる。

では、どのような計測基準を採用すればいいのか。

計測点を増殖させるのではなく、計測対象を減らし、サブシステムレベルでの正しい行いを促すようなシステムレベルでの計測点をみつけるのが良い。

リーンな組織では、何を計測すればよいか？

サイクルタイム、財務上の成果、顧客満足

サイクルタイム

サイクルタイムが一番基本的な計測基準になる。

コンセプトがキャッシュとなるまで、あるいは、顧客の「注文」がソフトウェアの導入に至るまで、平均でどれだけの時間がかかるのかを計測する。
プロセス性能がシステムレベルで計測でき、システム内のあらゆるムダが露呈する。
不足しているスキルや、稼働能力低さ、欠陥の多い実装が、サイクルタイムを長くしている。
一度にあまりに多くのことに対処しようと頑張ると、複雑性や不要な依存性、変更の容易性の欠如と同様に、サイクルタイムを長くする。

サイクルタイムを計測する際

システム内での最短のサイクルタイムを計測してはいけない。
どれだけ、上手に応急処置が取れるかを計測しても意味がない。
リーンな開発環境では、応急処置は必要でなかれば、好ましいものでもない。
重要なのは、どれだけ早く提供できるかではなく、どれだけ速く、繰り返しかつ確実に、新たな機能を提供したり、顧客要求に応えたり出来るか。

開発組織の目標

作業分類ごとに、繰り返し、確実に提供できるサイクルタイムを確立すること。
継続的な改善によって、そのサイクルタイムを短縮すること。
サイクルタイムだけを計測することによって、組織の全領域でのすばらしい振る舞いを引き出す。

上記のよって、全員が正しいトレードオフを行えるようになる。

タイムサイクルの短縮を重視すれば

全員が価値を付加する活動に一生懸命になる共同作業が促され、世界最高水準の品質へと近づき、標準化も進む。

それ以外の計測対象すべて(締め切りに間に合わせる能力、完成させる作業量、そして利用率さえも)がサイクルタイムの短縮に伴って改善させれる。しかし、その逆は当てはまらない。サブシステムの計測結果を最適化しようとしても、サイクルタイムは短縮されないでだろう。

どのようなサイクルタイムを計測すべきか 例：

欠陥リストに欠陥が加えられたら、その日付を控える
上記の欠陥が解決したら、この欠陥がリストに乗っていた期間を計算
期間を記録し、解決した欠陥の平均サイクルタイムと標準偏差、欠陥リストにあった期間の平均を出す。
ある項目が製品のバックログに入ったら、その日付を控える。
その項目が小項目に分割されたら、それぞれの小項目にもともとの日付を付ける
２つの項目が組み合わさって新たな項目にになったのなら、新しい項目に古い方の日付を付けておく
ある項目が導入されたら、導入日からそれが作られた日付を引く
上記はタイムサイクルになる。
平均サイクルタイムと、項目の各リリースでの標準偏差を計算する
また、バックログにある項目の平均待ち時間も計算する。

バックログに大規模な項目が追加し、対応に膨大の時間が掛かるため、誰も時間を割いて無く、顧客も「依頼」とは考えてない場合。

上記の場合、バックログの項目を３つのカテゴリに分けて考える。

A.顧客が「依頼」と考える機能、あるいは、計測可能な時間をすでに掛けた項目
B.アーキテクチャーについて考えたり、全体のスケジュールを見積もったりするために出す必要のある項目
C.本当に必要な製品ロードマップに載せる項目

バックログ項目は、A,B,Cの順に見ていき最初に当てはまるカテゴリに入る。つまり、ロードマップ項目で待ち望んでいる顧客がいるのであれば、それはAに入る。

バックログに入るもの全てに日付を付ける
項目がCからBに移動したら、新しい日付をつけ加える
それが、Aに移動したら、もう一度日付を加える。

項目を分け終わったら、３つのカテゴリのサイクルタイムを計算する。

次の数字を出す。

１．カテゴリAに振り分けられてからの経過時間
２．カテゴリBに振り分けられてからの経過時間
３．カテゴリCに振り分けられてからの経過時間

リリース毎に、３つのカテゴリの平均サイクルタイムと標準偏差を算出する。

上記の数字が何を語っているのか、考えてみよう。

別のカテゴリ分けをする必要があるだろうか？
バックログに残ったカテゴリAの項目は、そこに追加されてから平均して、どのくらいの時間がたっているだろうか？
リリースに含まれているA項目の平均サイクルタイムは、リリース１〜２回分に収まるだろうか？
A項目が追加されてからの平均経過時間がリリースサイクル２回分よりもはるかに長いようなら、作業を許容量までに制限していないということである。

財務上の成果

開発作業は、「投資対効果検討書」に基づいて資金を得る
開発の成功を計るのなら、投資対効果検討書の実現度を計測することをお勧めする。
現実的な投資対効果検討書だけを開発の正当化に利用すべきであり、実際の結果を計測した結果、投資対効果検討書を修正する必要も生じる。
投資対効果検討書を実現するためには時間もかかる、他にも影響を与える要因もあるはず。
基本原則として、本当に手に入れたいと考えている対象を計測すれば、それが手に入りやすくなるものである。
開発の最終目的が高い収益が得られるの製品を作ることなら、開発チームは製品の損益（PL）モデルを理解しなければならない。
そうすれば、収益が最高となる製品を生み出せるように、お互いの作業を噛み合わせることが出来る。
社内開発、請負開発、非営利目的の開発のいずれの場合でも、チームは適切な投資対効果(ROI)を実現したり、ほかのビジネス指標(例えば、スループットなど)がその投資を正当化するかどうかを見極めたりするように、務めなくてはならない。
ほとんどの企業では、開発作業の財務上の意味合いを、開発チームには知らせない。
しかし、どのようなチームも、自分たちの作業の財務上の目的を理解し、その目的を念頭においてトレードオフを行い、その目的達成によって得られる達成感に、喜びを感じるもの。
開発チームを結成する際の最初のステップは、何が成功になるかという点について、明確で魅力的なメッセージを伝えることである。
最終ステップは、その成功(失敗)を計測し、目に見える形にすること。

顧客満足度

リーン開発の目標は、顧客の状況を深く理解し、問題を完璧に解決することによって、顧客を喜ばせる方法を見つけることでなくてはならない。

ブラッド・ライクヘルドは以下のことを言っている。 著書『顧客ロイヤルティを知る「究極の質問」』

顧客を喜ばせる企業は、持続的な競争優位を得る。
顧客をいらだたせる企業は、より魅力的な選択肢が出てきた時点で顧客を失う。

顧客が喜んでいるかどうかを見極めるために、ひとつだけ簡単な計画を行うように提案している。

それは「推奨者の正味比率」の計測

顧客に次の簡単な質問をしてみよう「あなたの製品を、どれだけ薦められますか？」

顧客には以下の点数をつけてもらう。 0(薦めない)〜10(絶対に薦める)

その回答を以下のようにグループ分けする。０〜６：批判者７〜８：中立者９〜１０：推奨者

推奨者の正味比率を算出するには、推奨者の割合(パーセント)から批判者の割合を引く
マイナス１００%からプラス１００％までの数字が出る。
平均的な企業なら、点数は１０％戦後
マイナスになったら、深刻な問題につながると思ったほうが良い。

推奨者の比率が、ひとつの数字だけで顧客満足の概略を表すものであるとし、マーケットシェアと収益性の両方に深く関わっているという証拠を示している。

ロードマップ

１．今いるところからはじめる。 　どのように価値を生み出し、利益を出しているだろうか？

２．最大の制約を見出す。 　価値を生み出し、利益を出す能力の足かせとなる、最大の問題は何なのか？

３．最大の脅威を思い描く 　長期的に見た場合、価値を生み出し続け、利益を出し続ける能力に最大の脅威となるのは何か？

４．文化を評価する 　第一線にたつ作業者やパートナーに対して、深い敬意を抱く文化を確立し、強化する。技術へのプライドを持つことを邪魔すものを排除する。

５．訓練する 　チームのリーダーや、監督者、マネージャーに、統率の仕方、教え方、それに、作業プロセスの改善のために規律ある手法を作業者に使わせる方法を訓練する。

６．最大の問題を解決する 　最大の制約を作業チームが自由に変えられるようにする。いろいろな試みを繰り返し、最終的に解決への道を見つける。

７．制約への過去の適応手段を排除する 　制約に対処するために出来たルールを見つける。新たなルールはどのような内容にすべきかを決定する。

８．計測する 　最初から最後までのサイクルタイムや、実際の収益性、実際の顧客満足度が改善されたかどうかを見極める。

９．実現する 　成果に裏付けされた変化を取り入れる。

１０．サイクルを繰り返す 　最大の問題を解決されたら、何か別の問題が最大の問題になる。それを見出し、問題解決のサイクルを繰り返す。