トヨタ式リーン製品開発とは - 手法の本質を理解し戦略的に実践する

トヨタのリーン製品開発とはどんな手法？そしてどうやって自社で実践するのか？

トヨタの生産方式はあまりにも有名ですが、製品開発にも何か特長があるのでしょうか？リーン製品開発が良いということは最近耳にするようになった。チーフエンジニアとかA3報告書という仕組みがあることも何となく知っている。しかし具体的にどんな開発手法なのかを知りたいのと、自社で導入することは出来るのか、どうやって実践するかを詳しく知りたい。

自動車関連、家電製品、通信機器、事務機器、ヘルスケア、金属加工、その他、製品領域に関係なく多くの製造業向けにリーン製品開発手法の指導を行い、組織改革支援を行ってきた経験から、トヨタ式リーン開発手法の３つの重要な要素と、その実践について概要をお話します。

日本のトヨタ自動車の開発手法と言われながら、欧米企業から普及し始め、日本でも少しずつ注目されるようになった手法で、製品開発組織で起こっている様々な問題を解決できるかどうか、その開発手法の本質を読み解いていきましょう。

理論として伝わっている手法を形だけを取り入れるのではなく、なぜこの方法でうまく行くのか、理論をどうやったら自社組織に適用して実践できるのか、ということを解説していきます。

トヨタ式リーン製品開発とは？

トヨタ式リーン製品開発とはいったい何なのか、

その全体像を、できるだけわかりやすく説明していきたいと思います。

トヨタ式というと、リーン生産方式というのが、あまりにも有名ですね。

かたや、リーン製品開発というのは、実はあまり知られていません。

そもそも、各企業の開発のやり方は門外不出であって、普通は外に出ることがありません。

トヨタも、自ら自分たちの開発手法を公開しようとしたのではありませんし、個人的な意見ではありますが、恐らく自分たちが特殊な開発手法を実践しているとも思っていなかったのだと思います。

ではなぜ、トヨタ式開発手法が世に広まったか、まず、歴史的な背景を見ていきます。

1990 年代ころ、ミシガン大学の助教授だったアレン・ウォードは、師匠であるジェフリー・ライカー教授とともに日本の自動車産業の視察に来た時に、トヨタが自分が提唱するセットベース開発を実践していることを知ります。

その後、アレンウォードは、学生をトヨタに派遣してトヨタの開発手法を詳細に調査して、それを体系化していったわけです。

アレンウォードは、その後、コンサルタントとして独立し、米国内でリーン製品開発の布教に努めますが、残念ながら2004 年に飛行機事故で亡くなってしまいます。

彼の死後、彼が執筆中の本の原稿が発見され、周囲の人達の尽力によってLean Product and Process Development という本が出版されて再び、リーン開発の広がりが加速していきます。日本語版は、「リーン製品開発方式」として出版されています。

アメリカでは、ハーレーダビッドソン、ゴルフクラブメーカーの Ping などがリーン製品開発を導入し成果を挙げていきます。

そのなかで、テラダインベンソスという検査機メーカーも、リーン開発を熱狂的に推進し、そこの開発本部長である Bob Melvin という人が、独自のプロセスを作り出し、「Knowledge Based Product Development」という本を発表します。

日本では、リーン生産やトヨタの研究者として有名なライカー教授の本の翻訳などをやっていた稲垣公夫さんが（グローバリング(株）社長）、「開発戦略は意思決定を遅らせろ」という本を 2012 年に出版して、リーン製品開発手法を日本に紹介します。

この辺の流れが、歴史的な背景となります。

ここでわかるように、トヨタ式リーン製品開発と言っても、実際はアメリカの学者によって理論化されて、はじめは欧米で普及したものだったのです。

アメリカからの本の翻訳や稲垣さんの本によって、日本でもこれから広まっていくだろうリーン開発手法も、出発点はトヨタではあるのですが、伝わっているものは学者さんたちの手が入った理論であるということをまずは理解すべきだと思います。

理想論を読むだけでは現場での改革は出来ませんよね。理想論から本質を読み取っていくことが大切だと思います。

それでは、リーン製品開発の全体像を見ていきましょう。

アレン・ウォードの「リーン製品開発方式」などリーン製品開発についての書籍などを読むと、複雑な手法、複雑なシステムなのかと思われがちですが、実はキーとなる大事な仕組みは、以下の３つだけなのです。

チーフエンジニア制
セットベース開発
A3 報告書

この中で、チーフエンジニア制と A3 報告書は、比較的有名な制度で、知っている方も多いかもしれません。

チーフエンジニア制などは、いろんな企業が真似て取り入れようとしています。

名前を変えて Product Manager 制とかProject Manager 制などと言ってやっている企業もあるのですが、私の知る限り、形だけ真似ているだけで、トヨタが実現出来ている本来求めているような効果を得られていない企業が多いのだと思います。

同様にA3 報告書も、取り入れている、あるいはこれから取り入れようとする会社はたくさんあるのですが、A3報告書を定着させることで何を狙おうとするかが曖昧で、実際に成果を出せていないケースをよく目にします。

このように、リーン製品開発の３つの仕組みは、仕組みを作ればいいということではなく、その仕組みによって達成すべきことが大変重要になってきます。

３つの仕組みで求めるものは、

開発期間を短縮する
組織の知識を最大限に活用する
企画、設計、購買、製造、販売が一体となり無駄を排除する
手戻りなしのプロセスを作る
顧客が本当に欲しい製品を開発する
学習し、改善し続ける組織にする
人材を伸ばす組織を作る

というようなことを達成することが本質的な目的であって、仕組みはそのための手段であることをしっかりと認識したいところです。

仕組みやプロセスを作ることで、どんな効果が得られるかを学び、企業ごとに達成したい目的をしっかりと設定して、その企業にあった仕組みやプロセスを作り上げることがもっとも大事なことです。

それでは、トヨタ式リーン製品開発手法の3つのしくみを1つずつ見ていきましょう。

Amazonで見る

チーフエンジニア制

まず最初は、チーフエンジニア制です。

一般的な開発プロセスでは、企画、設計、生産準備、生産、販売というバリューチェーンをフェーズ毎に管理して、各フェーズの責任者が、フェーズゲートを管理しながらリレー式に責任というバトンを引き継いでいきます。

一方、リーン製品開発では、チーフエンジニアと呼ばれるひとりのスーパーマンが、バリューチェーン全体を一気通貫で管理します。

チーフエンジニアは、プロジェクト管理だけでなく、担当する機種のPL責任、つまり収益の責任まで負うことになります。

チーフエンジニアは、マーケッターとしての能力も求められ、顧客が本当に欲しい製品を企画し、外注との関係を強化、維持し、機能別組織をコントロールし、人材の最適活用、学習プロセスの運用など、幅広い知識やノウハウを活かして、プロジェクトを成功に導きます。

バリューチェーン全体で、責任を一人に集中させることで、開発思想や方針の一貫性を維持し、フェーズ間の意思疎通をスムーズにして、コミュニケーションの問題、組織の壁などで起こる手戻りや無駄を大幅に防ぐことができます。

しかしながら、このようなスーパーマン、スーパージェネラリストを育てるのは容易ではなく、おそらく、トヨタの強さは、このような人材を生み出す文化や歴史、ノウハウ継承の仕組みにあって、そこが他社が容易に真似ができないゆえんだと思います。

そもそもチーフエンジニア制を実践するためには、フェーズゲート式の開発プロセスを撤廃する必要もあります。

組織構造、製品開発から製造、販売までのプロセス全体を見直す必要があるということです。

ここまでの大胆な変更が出来ないまでも、製品開発プロジェクトの範囲内という限定であっても、チーフエンジニアに匹敵するような強力なリーダーによるプロジェクト推進をしたいという企業もたくさん存在します。

チーフエンジニア制の良いところを真似して、仕組みとして取り入れようとプロジェクトマネージャー（PM）を組織化し、強いリーダーを作り出そうとします。

ただし、トヨタでなぜ優秀なチーフエンジニアが生み出せるのか、組織構造だけでなく、文化的な背景や、最初に誰が成功して、それがどのように継承されていったかなどを含めて、その秘訣を読み解かなければ、PMというタイトルだけをつけた、組織間にまたがる単なるネゴシエイターとなってしまい、理想とはかけ離れたオペレーションに終わるだけだと思います。

下記の参考記事で、トヨタのチーフエンジニア制度について詳細に解説しています。参考にしていただければと思います。

参考記事：チーフエンジニアのすごさを意識して、まずは優秀なPMを育てましょう！

トヨタのチーフエンジニア制度から読み解く強い開発リーダーの育成法

トヨタのチーフエンジニアについては、色んな書籍で紹介されていますが、元トヨタのチーフエンジニアである北川尚人さんの「トヨタ　チーフエンジニアの仕事」という本は、非常にわかりやすくトヨタのチーフエンジニアがどんな風に育成されて、実際にどんな仕事をしているかを教えてくれます。

セットベース開発

2番目の仕組みは、セットベース開発ということですが、セットベースの話をするまえに、従来の開発の問題点を見ておきます。

セットベースという言葉に対して、従来の方法をポイントベースと呼びます。

多くの企業では、開発の構想段階で目標とする仕様を達成するための方式を検討しながら、採用する方式を一つに決めて、それに従って開発を進めます。

ポイントベースの名前の由来でもあります。

構想段階では通常、未知のことやチャレンジするべきことが多数あって、このとき、チャレンジするために考えられる方式の候補が普通は複数存在します。

複数の候補から、最適な方式を選定していくときに、様々な評価項目について、有識者で仮説や意見を集めて、喧々諤々の議論をして、○×式のような形で一つの方式を選び、正式に決定します。

この過程では、評価は事実と予測や意見が混在していて、最後はまあこれが一番良さそうだね、ということで方式を決定していきます。

方式を決めると、あとは、早くモノを作ることが優先されて、詳細設計をして試作して評価して、問題点を出して、修正しもう一度試作するということを繰り返しながら、量産、販売開始を目指して、問題つぶしと格闘していくわけです。

言ってみれば、泥舟をつくって、問題をつぶしながら品質を確保しようという考え方なのですが、複雑に絡み合った問題解決に時間がかかったり、副作用によってモグラ叩き状態になったり、何より解決までの時間が読みきれず、精神論で時間短縮を図ったりすることで、日程遅れが常態化し、手戻り、過大な残業時間の問題などが発生します。

そもそも開発初期段階に方式を決めてしまっているので、製品としての出来栄えは、構想段階で決めたもの以上にはなりません。

開発者が開発しながらワクワクするような製品にはなりにくいのです。

問題解決も時間との戦いになり、どうしても解決しきれない、あるいは問題が見つからないままに販売を開始して、市場問題になるケースも後を絶ちません。

市場問題に対する問題解決に開発者が駆り出されて、新しいことをやる時間を奪われていきます。

少ない人員で、多くの機種を継続的に開発しようとした結果、実は悪循環を生むような開発手法になっていたのかもしれません。

このような問題を解決できるのが、セットベース開発ということになります。

構想段階で、新しい顧客価値をどうやって生み出せるのか、技術的チャレンジは何か、自社にない知識は何か、トレードオフは何で、どう解決するか、新たな知識をどうやって獲得するかなどを出し切って、それらを一つ一つ解決していきます。

小さな実験や、小さな仮説検証を繰り返しながら、組織として学習し続け、学習結果から意思決定を叙々に進めていきます。

学習サイクルの中で、インテグレーションイベントと呼ばれる小さな意思決定のイベントを設け、学習結果から次のアクションを決め、また方式を絞っていきます。

学習サイクルを進めることで、技術的な問題や、顧客価値についての仮説検証が進んでいき、方式が決定する時には、技術課題も解決され、顧客が求めるワクワクするような製品が完成していくというわけです。

インテグレーションイベントは、基本は全ステークホルダーが参加するので、あとで意思決定が覆って手戻りすることもなく、また、学習サイクルで細かな技術課題も解決していくので、一見すると、余計な時間がかかりそうな手法と思われがちですが、トータルで考えると、実は大幅な時間短縮も図れます。

セットベース開発の考え方を説明すると、うちの会社でも要素開発と製品開発は分けてやっているから、こういうことはすでにやってるという大手企業の役員クラスの方が時々います。

でも、セットベースの考え方は、要素開発と製品設計をわけるレベルではなく、製品設計のなかで、未知のこと、すなわち考えられるリスクをすべて出して、開発を進めながら、リスクや知識習得を進めていくことで、言ってみれば、開発におけるFMEAやFTAを事前にやっておいて、問題を後から発生させないようなプロセスにした開発手法だと言えるのだと思います。

セットベース開発は、なかなか正確に理解しにくい仕組みで、また実際にどう実践するか悩ましい手法でもあります。

セットベースが出来ているか、出来ていないかは、「開発期間は短縮出来てますか？」、「品質問題は以前より格段に減ってますか？」、そして「顧客に受け入れられる良い製品を生み出せてますか？」という疑問に答えてみてください。成果が出ていないものは、出来ていないと考えてください。

セットベースの本質は、技術要素開発の仮説検証を行うだけでなく、設計の可能性を広くみて、チャレンジの領域とリスク回避の領域を持ちながら、仮説・検証を小さく早く回して、できるだけチャレンジ度の大きい開発に着地させることで、短期間に良い製品を高品質で開発する考え方であり、さらに言うと、MVE（Minimum Viable Experimentation：実現可能な最小の実験）によって新たな「知識」を生みだし、それを組織内で蓄積し、必要に応じて「知識」を再利用することで、組織全体で良い製品を短期間に勘発するための仕組み、システムを構築することなのです。

この考え方をどうやって自社のプロセスに当てはめて、実践していくかというアプローチをぜひ考えてみてください。

セットベースの実践方法に関しては、理論の解説から実践サポートまで弊社で支援することができます。

関連記事：

セットベース開発を理解する

セットベース開発の実践を阻害する障害とロジカルにトップを説得する方法

トヨタのリーン製品開発手法の本質を捉え、
若手エンジニアのモチベーションによる改革を目指し、
トヨタの真似でない独自の世界観で
組織改革に挑む姿を描いています。

詳しくは、「製品開発組織の常識をぶち壊せ！！」出版のご案内を参照ください。

A3報告書

リーン製品開発手法の3つ目の仕組みは、A3報告書です。

Amazonで見る

トヨタ式A3報告書は、単なる報告書ではありません。

セットベース開発プロセスとも密接に連携し、学習サイクルで獲得した知識を社内に蓄積するために活用します。

会社の知的資産となるものであって、ベテランの暗黙知を資産として残し、同じ失敗を繰り返さないための情報源となり、イノベーションを起こすための原動力となるものです。

書いたらそれで終わりではなく、上司と部下で改善し育てていくなかで、上司にとっても部下にとっても自身の育成にもつながるものです。

一枚で簡潔に、かつ社内の読み手に正しく伝えて、活用されるためには、短時間で理解できるようにしっかりとしたストーリーで書かれなければなりません。

A3報告書が組織に定着すると、組織全体の考える力が向上し、組織力が大幅に高まります。

A3報告書は、一見わかりやすいし、成果も見えやすいので導入しようとする企業が多数あります。

しかし、単に報告書のフォーマットをA3化して、社員にとにかく書けと書かせるだけでは真の効果は得られないことは注意いただきたいと思います。

A3報告書の質に関して、少し考察をしてみました。

背景としては、最近になって注目されている「失敗学」について考えてみたことです。

失敗学は、組織として失敗を許容し、失敗から学ぶことで進化していこうという考え方ですが、過去の失敗を活かす考え方はA3報告書の一つの目的でもあります。

しかし、単に過去のトラブルをA3化するだけでは、後進の人たちにうまく使われないケースもあります。

過去の失敗を活かして活用し、成果を出すためには、読み手側が失敗事例を自分ごととして捉えることが必須なのです。

問題の事象、背景、解決策などを表面的に書いただけでは、読み手が自分にも使えるチャンスを逃してしまう可能性があります。

チャンスを逃さないためには、失敗情報から知恵を取り出した「知識化」という作業が必要です。

特定のプロジェクト、特定の状態の問題を一般化、抽象化することが出来れば、多くの人が失敗情報を活用できるチャンスが広がります。

A3報告書を展開するのであれば、失敗情報の知識化を含めて組織的な報告書の質向上の仕組みも一緒に考えていただきたいと思います。

関連記事：

A3報告書文化による製品開発革新

報告書の書き方改善で組織改革を行う事例

A3報告書活動を導入して成果を挙げるための指導体制

失敗学から学ぶA3報告書ナレッジマネージメント

リーン製品開発手法の本質

リーン製品開発の3つの仕組みはご理解いただけたでしょうか？

リーン製品開発手法の本質的な意味を考えるには、３つの仕組みを総括してみる必要があります。

結論から言うと、リーン製品開発手法の本質、肝となるものは「知識」だと考えていて、下記の２つのことをシームレスに実現する開発システムを作ることだと思うわけです。

新たな「知識」を生み出すこと
社内に蓄積された「知識」を利活用すること

顧客が喜ぶ車、会社に利益をもたらす車を作るためにチャレンジをリードするチーフエンジニア、未知の知識、チャレンジするために得るべき知識を、小さな実験（MVE）で小さな学習サイクルを回しながら獲得していくセットベース開発、セットベース開発で得た知識を社内に循環させ、知識資産を使って開発効率を高め、知識資産を上積みすることでイノベーションを起こしていくA3報告書マネージメントという「知識」を中心に開発システムが動いているというのがリーン製品開発手法の本質です。

さらには、この開発システムによって人材育成なども同時に行えるような仕組みなのだと思います。

経験から、トヨタのリーン製品開発システムの究極の狙いは、本物のナレッジマネージメントなのだと思っています。本物というところがミソで、世の中には成果を出すことから程遠いナレッジ・マネージメントもたくさんあります。（参考：「リーン製品開発の完成形は本物のナレッジマネージメント・システム」）

そして、開発システム改革の前提にあるのは、現状の開発のやり方では、情報の流れがスムーズでないことによって様々な問題が起こっているということです。

逆にいうと、開発組織の問題の原因が、情報の流通が滞っているということであれば、「知識情報」の流れを改革するという考えがぴったりと当てはまるのですが、組織問題の原因が別のところにあれば、この考え方は当てはまりません。

まずは、現状の組織問題の根本原因をしっかりと正確に把握することで、トヨタ式リーン製品開発手法が使えるのかどうかを判断することが大事だと思います。

トヨタの場合、実質的に国産初の自家用車である初代クラウンの開発のときに、豊田喜一郎さんの「3年でアメリカに追い付け」という当時は無謀とも思わるチャレンジをしたときから、チャレンジし続ける開発システムが生まれて成長し続けて、今の姿があるように思います。

チャレンジし続けるために、必然的に出来た開発システムであり、長い歴史の中でさらに磨きをかけたものです。

他社が一朝一夕に真似できるようなものではありません。

「改革」するということは、現状を変えるということです。

なぜ変えるのか？

どう変えるのか？

という指針がなければ改革は成功しませんね。

何となくトヨタが成功しているから真似してみよう、という考えでは絶対に失敗します。

まず大事なことは、一つひとつの要素でなく、開発システムを変えるという考え方で取り組むことが大事だと思います。

コラム：ナレッジマネージメントを成功させる秘訣

ナレッジマネージメントというと、文書管理システムということと誤解するケースが時々見受けられます。

文書管理もナレッジマネージメントの一つの手段かもしれませんが、現存する報告書など、ノウハウや知識をデータベース化して、検索して容易に閲覧できるシステムを導入して終わりでは、実は成果は期待できません。

ナレッジマネージメントで見過ごされがちなのは、ナレッジを共有するコンテンツの質の問題です。

ナレッジ（知識情報）は、広く読者に読まれ、しっかりと理解されて活用されなければ価値が発揮できません。

そのためには、知識情報の質を高める必要があるのです。

多くの企業の報告書は、書き手主導のものがほとんどです。

書き手が書きたいように書き、それを利用できるかどうかは読み手次第ということでは、現実に知識情報が生かされなくなります。

読み手主体にすることで、知識情報の流通を活性化することができます。

知識情報は市場における商品と同じです。

商品を出来るだけ多く市場で流通させるには、顧客（読み手）が求める商品にしていく必要があります。

知識情報の質を組織として高めることからナレッジマネージメントは始めるべきであり、そうでないと知識情報が開発現場で生きた情報にならないのです。

参考記事：「トヨタのリーン製品開発から学ぶ本当のナレッジマネージメント」

リーン開発手法の難しさを理解し戦略的に実践する

リーン製品開発の本質を理解したら、次はどうやって自社で実践するかということですね。

下の図は、テラダインベンソスというアメリカの会社がリーン開発を学び、少しずつそのエッセンスを取り入れながら、改善を重ねて、5年ほどかけて作り上げたプロセスです。ご紹介した「Knowledge Based Product Development」という本の中で、この会社が取り組んだ改革の話が詳しく紹介されていますが、最も難しかったのは、理論を自社のプロセスとして定着させることだったとこの本の作者、開発本部長のBob Melvinは言っています。