トヨタのリーン開発手法の話は良く聞くけど、何がどう良いのですか?

リーン製品開発という中で、チーフエンジニアとかA3報告書などの話をたまに聞くことがあるけど、普通のやり方とどこが違うのか?トヨタが勝ち組なのはわかるけど、具体的なメリットを知りたい。

 

トヨタ式リーン開発は、ミシガン大学のアレン・ウォードという人がトヨタ開発の実態をモデルに体系化したもので、「リーン製品開発方式」という本にまとめられています。

組織のあり方、リーダーシップや開発プロセスまで、かなり詳細に解説されているのですが、この本から読み取れるのは、特にセットベース開発とA3報告書を使った開発の考え方から、「知識資産」、つまりナレッジを開発の核としてイノベーションを起こしていく開発システムを作るべきだということです。

リーン製品開発手法から「知識資産」を利活用する、すなわちナレッジマネージメントを軸にした開発システムという考え方を読み解いていきます。

 

 

 

理論としてのリーン製品開発手法

 

トヨタの開発手法が広まったルーツは、ミシガン大学のアレン・ウォード元助教授の「Lean Product & Process Development」という著書であり、日本語に訳されたものが「リーン製品開発方式」になります。

 

>>Amazonで見る

 

この本の冒頭で述べられているのは「どうしたらすべての製品開発プロジェクトが大きな利益を出すと同時に、楽しい経験とすることが出来るかーこの質問に答えるために私は本書を書いた。」ということです。

また、こんな一節もあります。

”リーン製品開発は、「高速開発」「堅牢開発」「責任に基づく開発」「知識ベース開発」など他の名前で呼んでもらっても構わない。リーン製品開発の最終目標は、良い製品をつくる方法を素早く学習することにある。”

この本の目次を追っていくと、「起業家的システム設計者」「セットベース・コンカレントエンジニアリング」「リズム・流れ・プルで乱流を乗り切る」「責任ある専門家チームをつくる」など、ちょっとわかりづらい表現もありますが、この本を日本語に翻訳した稲垣公夫さんの著書「開発戦略は意思決定を遅らせろ」は、リーン製品開発手法の入門書のような本で、アレン・ウォードの本をわかりやすく読み解いています。

アレン・ウォードの著書の中で、一つのキーになるのが「セットベース・コンカレントエンジニアリング」、少し省略していうと「セットベース開発」になると考えていますが、著書の中でも触れられていますが、アレン自身が研究していたセットベース開発の手法を実際に活用している会社を探していたところ、トヨタがこれを実践していることを発見したという背景があります。

そこでアレン・ウォードは学生をトヨタに派遣し、トヨタの実情を調査した上でこの手法を体系化し本としてまとめたのですが、あくまでアレンが作った理論であることを忘れてはなりません。

実際にトヨタの人たちが自分たちの開発のやり方が特別なことだと発信している情報は、私自身は発見していません。

トヨタ出身の方から聞かれるのは、チーフエンジニア制度(あるいは主査制度)というカリスマリーダーによる組織能力強化と、A3報告書を書く文化によって報告のスキル、情報伝達がうまく行ったという話です。

チーフエンジニア制度については、アレンの著書の中に面白い記述があって、”アメリカの自動車会社が、トヨタのプロジェクトリーダー(チーフエンジニアのこと)がなぜ主としてシステム設計者であるかを理解せず、本格的なプロジェクトマネージャー制を導入(トヨタの主査制度を制度として取り入れたという意味)した。システム設計者とはシステムの様々なトレードオフについて決定を下す人だが、欧米企業はプロジェクトマネージャーを単なる調整役と位置付けたため、官僚制度におけるもうひとつの歯車と化してしまった。”

この記述は、リーン製品開発手法、つまりはトヨタのやり方をそのまま真似するのでは、うまく行かないということを意味しています。

リーン製品開発手法は、良い製品を作るための考え方、プロセスの作り方、組織能力をどう高めていくかなど、非常に有用な内容となっています。

しかしながら、このような体制でない状態から、理論上の状態にどうやって変わっていくかということまでは与えられていないのです。

どうやって実践するかということは、各企業がリーン製品開発の理論としての本質をしっかりと捉えた上で、現状から目指す姿までのギャップを認識して、トップと現場が一体となって一歩ずつ確かめながら変わっていくしかないのだと思います。

問題は、リーン製品開発の理論としての本質の捉え方なのです。

 

参考記事:

 

 

リーン開発手法の本質

 

アメリカでは、いくつかの企業がリーン製品開発手法を展開しています。

ハーレーダビッドソン、ゴルフクラブメーカーのピンなどが有名ですが、テラダインベンソスの事例なども書籍として紹介されています。

この会社の社長だったRon Marsiglioと開発本部長のBob Melvinは二人三脚でリーン製品開発手法を参考にして改革を成功させます。

彼らがやったことは、最初のモデルプロジェクトで成果を出すのに2年間、その後、全社の開発プロセスをリーンの形に変革するのに3年、つまりトータル5年かけて大きな成果を勝ち取るのですが、Bobは、この改革の経過、どんなプロセスを作ったか、どんな苦労をしたかを「Knowledge Based Product Development」という本に書き残しました。

 

この本のタイトルに注目してください。

そうなんです。彼らは自分たちの作った新しい開発プロセスを、「知識(ナレッジ)ベース開発」と呼んでいます。

この会社の一番最初の取り組みは、すべての情報をA3報告書に残すことでした。

社長だったRonは、「A3に書いていないものは、すなわちこの会社に存在していないものだ。」と言います。

この会社の新入社員研修でやることは、開発を始めるときに、今、自分たちがわからないことをリスト化することを徹底することだそうです。

未知なこと、チャレンジすることは勿論、自分自身が不勉強で知らないことも含めて、すべてをリスト化するのだそうです。

そして、未知のこと、知らないことを一つずつ小さな実験で新たな「知識(ナレッジ)」として積み上げていく、つまりはセットベース開発を行っていくということです。

積み上げた「知識」は、A3報告書としてまとめられ、会社の知識資産となり後々活用されます。

さらに次の開発では、A3報告書として残っている「知識」を棚卸しして、そこにない「知識」を学習していきます。

 

私は、このストーリーを考えると、リーン製品開発手法の本質は、ナレッジ(知識)・マネージメントなのだと考えたわけです。

 

また、リーン製品開発方式の中で言われている「知識(ナレッジ)」は、

  • 技術革新に関する知識
  • 顧客が求める価値に関する知識

の2つだということです。

競合に勝る製品を開発するためには、技術革新が一つの重要要素になります。

競合よりも早く知識(ナレッジ)を習得して、新しい製品に組み込んでいく必要があります。

しかしながら、技術革新さえ伴えば良いというわけではありません。

競合に勝つということは、競合よりも技術で勝てば良いということではなく、競合よりも売れる製品を開発するということなのです。

競合よりも売れる、ということは、競合製品よりも顧客が欲しいと思う製品ということです。

だから、顧客がどんな製品を望んでいるのか、どんな製品が高い顧客価値を提供できるのか、ということも企業にとっての「知識(ナレッジ)」だということです。

 

リーン製品開発手法を活かす、つまりリーン製品開発手法の目的である、「製品開発プロジェクトが大きな利益を出し、楽しい経験をする」ことができるためには、開発プロセスの中心に知識、すなわちナレッジを置いて、知識(ナレッジ)を軸にした開発プロセス、開発システムを作り運営することだと考えます。

チーフエンジニア制を導入する、A3報告書を使ってみる、セットベース開発手法を学んでやってみる、ということの前に、知識、つまりナレッジマネージメントのシステムをどう作って、どうやってそこから良い製品を開発していくか、という発想をすることが、リーン製品開発導入の本質だということです。

 

間違ったナレッジ・マネージメントの考え方

 

ナレッジ・マネージメントという言葉は様々な企業で頻繁に使われています。

しかしながら、その目的はどんなことでしょうか?

「社内にある情報を整理して、うまく検索して再利用できること」のような目的設定をしていることが多いのではないでしょうか?

この考え方そのものが間違っているとは思いませんが、この目的設定は十分でしょうか、という問いかけをしたいのです。

この記事の冒頭で申し上げたようにリーン製品開発の目的は、「製品開発プロジェクトで大きな利益を出すこと」でした。

つまり、良い製品を開発すること、顧客に認めてもらって買ってもらえる製品を生み出すことが究極の目的であるはずですよね。

ナレッジ・マネージメントも本来は、リーン製品開発の究極の目的と同じであるべきと思うわけです。

そしてこの目的の設定の違いによって、得られる結果も違ってくるのだと私は思うのです。

多くの企業が進めているナレッジ・マネージメントは、今ある情報、つまりは報告書や過去の経験(トラブルなど)を出来るだけ簡単に引き出せるようにすることを目指します。

何が起こるかというと、文書管理システムを作って、簡単に文書を検索するシステムを作ろうとするのです。

今ある情報をシステムに入れ込んで、検索して閲覧できるシステムを導入して、「はい、出来ました。」というようなことをやっていないでしょうか?

これで、「社内にある情報を整理して、うまく検索して再利用できること」という目的は確かに達成されたことになりますが、実は、「製品開発プロジェクトで大きな利益を出すこと」という目的は達成されたとは言えません。

これが、多くの企業がナレッジ・マネージメントを間違って捉えているということなのです。

では、ナレッジ(知識)を活用して「製品開発プロプロジェクトで大きな利益を出す」ためにはどうしたらいいかを次のステップで考えていきましょう。

 

ナレッジを流通させるマーケットを社内に作る

 

ナレッジ(知識)によって「製品開発プロジェクトで大きな利益を出す」ためには、リーン製品開発手法の本質である技術革新と顧客価値に関する「ナレッジ(知識)」を他社よりも早く積み上げて製品を開発する必要があります。

そのためには、積み上げた良い「ナレッジ(知識)」を再利用することと、新しく生み出した「ナレッジ(知識)」を使いやすい形で残していく仕組みを作ることが大事だということです。

ナレッジ(知識)を蓄積する方向と、ナレッジ(知識)を引っ張り出す方向の両方とも重要なのです。

前述の間違ったナレッジ・マネージメントでは、実は引っ張り出す方向だけがフォーカスされているのです。

多くの企業がここで間違ってしまうのですが、そもそも再利用しようとしているナレッジ(知識)あるいは「情報」と読み変えても良いかもしれませんが、それは正しくて使える情報なのでしょうか?

使えない情報、あるいは使いづらい情報をいくら蓄積しても、大きな利益にはつながりません。

では、使える情報、あるいは使いやすい情報とはどんなことなのか?ということを考えてみます。

それは、読み手が欲しい情報であり、読み手が再利用することで価値がある情報ですよね?

 

ナレッジ(知識)、つまり情報を、商品として考えることを提案しています。

「情報」という商品を、製品開発組織、あるいは全社内で流通させるということです。

「商品」ですから、当然、品質が問われます。

質の高い商品は、流通量が上がり社内という市場で活用されていきます。

質が低ければ、流通せずに活用されないということになります。

多くのナレッジ(知識)が、高い質で社内で流通し、活用される場が広まれば、製品開発プロジェクトにおける利益につながります。

ナレッジ(知識)という情報商品が、開発現場という市場(マーケット)で流通するということは、ここに需要と供給という考えが出てきます。

情報商品を欲しいと願う顧客、つまり市場(需要)と、ナレッジ(知識)を他者に提供する開発者(供給)とのバランスが生まれます。

供給側は、自分が提供する情報商品が広く活用されることを願うようになり、すなわち市場が求める情報は何かということを考え始めます。

そして、情報の残し方(報告書の買い方)にも変化が出てくるはずです。

情報商品は、読まれて再利用されることに価値があります。すなわち、読まれないもの、あるいは読まれても理解されないものは価値がないということになります。

良い情報商品は、読み手が読みやすくて、かつ活用することで価値が出るような書き方に変わってくるということです。

 

前述の間違ったナレッジ・マネージメントでは、書かれた内容は不問になりがちです。

だから、書き手主導、マーケティング的な表現をすると、プロダクトアウトな報告書になっているわけです。

如何に優秀な検索エンジンを作っても、そもそも読んでも理解できない報告書や、読んでも活用できないものを検索されても価値を生み出すことはありません。

 

ナレッジ・マネージメントで最初にやるべきことは、読み手が望む報告書を書く、そして読み手に伝わる報告書を書くスキルを組織的に上げることなのです。

良い報告書が書ける組織になって、そこからどうやって社内、あるいは開発組織内に流通させるかなのですが、ここで流通商品のマーケットを作ることで、書き手が読み手を顧客として捉えるようにすることで、開発組織の学習サイクルの効率化が図れるはずなのです。

 

関連記事:「A3方向書活動を導入して成果を挙げるための指導体制

 

フューチャーシップが提供するリーン開発教育

 

リーン開発実践セミナー

  1. リーン製品開発の理論
  2. リーン製品開発導入事例
  3. 自社での導入方法

 

 

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

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

 

 

Pocket