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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

書籍などを読むと、複雑な手法、複雑なシステムなのかと思われがちですが、実は仕組みとしてやっているのは、3つだけなんです。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

多くの企業では、開発の構想段階で、まず最初に基本的な方式を一つに決めて、それに従って開発を進めます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

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

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

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

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

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

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

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

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

初めにお話ししたように、リーン製品開発手法は、理論として提供されたもので、これを企業で取り込んで実践していくには、3つの仕組みの本質的な意味を理解した上で、自社の事情や拘りを考慮し、達成したい目的を明確にして、独自のプロセスを作っていく必要があります。

下の図は、テラダインベンソスというアメリカの会社が、リーン開発を学び、少しずつそのエッセンスを取り入れながら、改善を重ねて、5年ほどかけて作り上げたプロセスです。

 

開発プロセスとA3報告書のデータベースとの関係を明確化し、自社独自の決済システムを構築しています。

テラダインの開発部長は、社長自らが先頭にたって改革を進めたから出来たことだと振り返ってくれました。

ただ、同時に、改革着手から7年たっても、チーフエンジニアはまだ育っていない、候補は2人ほどいるけどね、と言っていたのが印象的でした。

さて、トヨタ式リーン製品開発とは、というテーマでお話ししてきましたが、いかがでしたでしょうか?

何かヒントを掴んでいただけたなら、大変うれしいです。

あるいは、当たり前のことじゃないか、と思われた方もいらっしゃるかもしれません。

実は、当たり前のことをしっかりと実践することが何よりも大事なことだと私は思うのですが、今できていない当たり前を実践するというのは、骨の折れることだと思います。

私どもは、リーン開発手法を企業内で実践し、定着させるためのノウハウを持っています。

 

リーン製品開発の概要を理解し、プロセス改革の進め方を演習を交えて学べる「リーン製品開発実践セミナー」をオープン講座で実施しています。

 

ただし、リーン製品開発手法は、組織の中で一人だけが理解しても意味がありません。

組織の大多数がその利点を理解し、マネージメント層の支援がなければ実践は出来ません。

組織全体への理解、マネージメント層の説得方法なども弊社に経験があります。

ご興味ありましたら、下記問い合わせボタンからご相談ください。