「開発戦略は「意思決定」を遅らせろ! ─トヨタが発想し、HPで導入、ハーレーダビッドソンを伸ばした画期的メソッド「リーン製品開発」」を読んだ。
製造業の製品開発がメインなのだが、アジャイル開発に似ているなあ、でも違いは何だろう、と思いながら読んでみた。
ラフなメモ。
リーン製品開発の４つの礎石。
セットベース開発、チーフエンジニア制度、流れとリズムの確立、責任ある専門家チーム。
LAMDAサイクルとは、look, ask, model, discuss, act。
PDCAのうち、PとCはLAMDAサイクルで回す。
つまり、PDCAサイクルのうち、PlanとCheckに力点を置く。
セットベース開発は、多数の代替案を平行で評価しながら、徐々に絞り込んでいく。
代替案の収束の時系列図は、不確実性の時系列図に似ている。
たぶん、製品開発でも当初はどの案が自分たちが求めるものなのか分からない状態で、そこから複数の代替案を実験し、試行錯誤を繰り返していくうちに、あるべき姿が明確になってくるイメージなのだろう。
つまり、製品開発も当初はリスクが非常に高いが、経験値が増えるに従って、リスクを受容できるようになり、不確実性はコントロールできる範囲に落ち着く。
チーフエンジニア制度とは、トヨタを真似たもの。
スクラムのプロダクトオーナーに似ているし、スクラムマスターの役割も兼ねているように思える。
チーフエンジニアは、顧客を代表し顧客価値を最大化させることに注力する。
チーフエンジニアは、部品メーカーから工場、生産システムまでの生産バリューストリームを設計する。
チーフエンジニアは、機能別部門の開発者の対立を調停し、トレードオフを主導する。
チーフエンジニアは、インテグレーション・イベントで代替案を披露し、それに向かって開発のプロジェクト管理を行う。
チーフエンジニアは、ビジョンを提供し、開発資源を確保する。
チーフエンジニアは、製品ビジョンを実現するための技術の方向性を示す、技術的リーダーシップを発揮する。
インテグレーション・イベントとは、学習サイクルを管理するために一定期間で行う。
多数の視点から代替案を検討し絞り込む。
各チームが獲得した知識を共有し、将来のために記録する。
開発の計画と実績を対比し、開発ペースを管理し、開発にリズムと流れを導入する。
インテグレーション・イベントは、スクラムのスプリントに似ている。
ただし、インテグレーション・イベントでは、開発段階で得られた知識のレビューに力点が置かれる。
セットベース開発では、開発当初に詳細な仕様を厳密に決めるのではなく、複数の代替案を元に、開発しながら技術的知識が増えるにつれて、徐々に仕様をより細かく、具体的にする。
一方、ポイントベース開発のように、実際に製品の試作品を作り、それから試験して通過すればよいが、試験が通らなければ、出直し設計となり、量産開発に至るまでに膨大な開発コストがかかる。
開発上の技術的知識の多くは、トレードオフ曲線で表現される。
たとえば、ある部品の強度を強くしたら、大きくならざるを得ないとか。
つまり、２つの製品特性に対し、正や負の相関関係がある事実を実験で新たに見出す。
重要なのは、低コストで知識を獲得する工夫を行うことだ。
通常、必要な知識とは、設計パラメータ間の相関関係である事が多い。
製品開発の最大の無駄は、せっかく獲得した知識を捨てること。
蓄積した知識を次の製品開発に利用せず、同じ知識を得るために貴重な開発資源を浪費すること。
セットベース開発では、代替案が棄却されても、そこで得られた知識はチームに残り、A3文書に記録されて、後で再利用される。
あらゆる開発上の知識はA3報告書に１枚に記録する。
ナレッジはA3報告書で蓄積される。
この話で面白いと思ったのは、メーカーの製品開発でも、インテグレーション・イベント（スプリント）単位に設計し、そこで得られた知識はトレードオフ曲線で表現されているので、それらをA3報告書に記録してナレッジを共有する一連の流れがあることだ。
スクラムでも経験主義が強調されるが、リーン製品開発では、製品特性のトレードオフ曲線というナレッジがA3報告書１枚に記録され、失敗した経験から得られた知識も蓄積されていく。
それら技術的知識はチームメンバーに共有されて、インテグレーション・イベントを経るごとに、新製品のあるべき仕様が分かってきて、最終的に固まる。
そうすれば、試験も通過しやすいし、量産体制に入っても、蓄積された技術的知識を活用すれば生産プロセスを改善しやすい。
リーン製品開発を取り入れたハーレーダビッドソンは、リーン製品開発ではなく、知識ベース開発と呼んでいるらしいが、そちらの方が理解しやすい気がする。
リーン製品開発の効果は、競争力のある新製品を従来よりも短いリードタイムで開発できるだけではない。
実は、技術者の士気が大きく向上したらしい。
リーン製品開発に取り組んだ技術者の話が「開発戦略は「意思決定」を遅らせろ! ─トヨタが発想し、HPで導入、ハーレーダビッドソンを伸ばした画期的メソッド「リーン製品開発」」にあるが、その理由はこうだ。
従来の開発手法では、トップダウン式で製品企画が決まり、技術的に意味のないペーパーワークや会議に時間が取られていた。
一方、リーン製品開発では、試行錯誤しながら、問題を発見し、解決方法に関する仮設を立てて、それを実験により検証する、という技術者本来の仕事を中心に進められる。
実際、複数の代替案を作り、大まかな仕様を元に、問題を発見して解決して得られた技術的知識はトレードオフ曲線として表現され、それらはA３報告書に残る。
つまり、仮説検証による技術的問題解決を行っているわけであり、技術者本来の仕事なわけだから、モラールが向上するのは当たり前だ。
そして、できればそこで得られた技術的知識は、学術論文で投稿できたり、特許として認定できれば、技術者のモチベーションももっと上がるだろう。
クネビンフレームワークの複雑系の問題領域では、そもそも問題が何なのか分からない。
専門家が何度も調査して検証して、初めて因果関係が分かる。
その知識は経験として得られるものであり、トップダウンで分かるわけではない。
リーン製品開発も、クネビンフレームワークの複雑系ドメインの問題解決の手法の一つと捉えることはできる。
「開発戦略は「意思決定」を遅らせろ! ─トヨタが発想し、HPで導入、ハーレーダビッドソンを伸ばした画期的メソッド「リーン製品開発」」のあとがきの一節がとても気になった。
筆者は、TOCという生産改善手法を日本に初めて紹介したり、EMSを紹介したり（たとえば、台湾のフォックスコンなど）、トヨタ生産システムも翻訳したらしい。
いずれも、日本でそのアイデアが生まれて、アメリカ人が徹底的にその手法を分析評価して、フレームワークとして体系立てて、日本に逆輸入されている。
アジャイル開発も結局同じだ。
なぜ、日本人は、自らのアイデアを抽象化したフレームワークにまとめて、誰もが普遍的に扱えるような形にしなかったのだろうか？
なぜ、日本人は、自らのアイデアをアメリカ人にキレイな体系として理論化されたものを、ありがたがって受け入れざるを得なかったのだろうか？
最近のコメント