賀門 宏一 
トヨタが実践しているといわれている「リーン製品開発」ですが、世の中に広まっている情報源は、アレン・ウォードが著した「リーン製品開発方式」であるようだ。
難解な本で、自社の開発とどう比べてどうやって自社に取り入れたらいいのか？
あるいはそもそも自社のやり方と具体的にどう違うのか、もう少しシンプルに解説して欲しい。
リーン製品開発手法普及の背景と注意ポイント
トヨタが実践しているとされるリーン製品開発は、ミシガン大学の助教授であったアレン・ウォードらによって2007年に出版された“Lean Product and Process Development”によって欧米諸国で広まり、2014年に日本語版「リーン製品開発方式」として日本に紹介されるようになりました。
それと並行して、「リーン製品開発方式」の日本語訳を行った稲垣公夫さんによって、2012年に「開発戦略は意思決定を遅らせろ」が出版され、リーン開発手法がわかりやすく解説されたという経緯があります。
さらにトヨタ出身者などからの書籍や情報が出回るようになり、トヨタ製品開発の強みが少しずつ世の中に知られるようになったわけなのです。
ここで注意したいのは、広まったすべての情報が実際にトヨタが実践しているものと完全に一致しているとは言えないのではないかということです。
特に「リーン製品開発方式」に描かれた内容は、アレン・ウォードの個人的な理解、考え方を少なからず含んでいるものと筆者は考えています。
もちろん、アレン・ウォードは実際にトヨタが実践する開発プロセスを自身や自身が送り込んだ学生からの情報をもとに著書をまとめているので、まったく的を得ていないわけではないものの、もともとアレン・ウォードは製品開発の研究者として、自身の持つ理想の開発プロセスを論じていて、著書の内容にトヨタと自身の考え方が一致しているというアレン・ウォードの考え方のバイアスが働いている可能性を排除できないと思っています。
具体的には、トヨタの開発手法として、明らかにトヨタが実践していることとして、チーフエンジニア（主査）制度による強力なリーダーシップ、およびA3報告書を使ったナレッジ共有システムについては、反論の余地がないところかと思います。
しかしながら、「リーン製品開発方式」に出てくる、セットベース・コンカレント・エンジニアリング（セットベース開発）、LAMDAサイクル（PDCAの発展形）、そしてリズム・流れ・プルなどは、トヨタ出身者からは全く聞こえてこないワードであり、もともとアレン・ウォードが考えていた理想のプロセス（ただし、トヨタも同様の考えであると彼が考えたもの）を表現したものと推測しています。
筆者としては、アレン・ウォードの功績は尊重しつつ、アレン著の「リーン製品開発方式」を読み解きながら、リーン製品開発の本質をシンプルにわかりやすく解説し、様々な企業でリーン製品開発手法をどのように取り入れていくべきかという考え方のヒントにしていただければと思っています。
理想の開発プロセスで目指すこと
リーン製品開発は、プロジェクト・マネージメントの教科書ととらえてもいいのではないかと思っていますが、「リーン製品開発方式」の冒頭で、リーン製品開発とは次のようなことを実現できる、という記載があります。
- 開発期間と消費資源を最大1/4に削減する
- 品質問題、スケジュールや予算の超過、失敗する製品のリスクを1/10に低減する。
- イノベーションを最大10倍に増やす。
- 生産システム、部品を再利用し、設備コストを削減し、品質を向上する。
ということなのですが、そもそも何に対して、1/4、1/10、あるいは10倍なのだろうか、と素朴な疑問を感じます。
トヨタ以外でも優れたプロセスで成果を挙げている企業はあると思うのですが、何かトヨタのみを神格化するような冒頭の記載に少し違和感を感じます。
ただし、好意的に解釈すれば、多くの企業の開発プロセスには大きな課題があることは事実であって、著書を参考にすれば、必ず大きな成果が得られますよ、と読めなくもなく、出発点としてトヨタを別にして、多くの企業で開発プロセスの問題を抱えているのではないか、という仮定からスタートしているものと考えることにします。
もうひとつ、「リーン製品開発方式」で述べられているのは、開発を評価する場合に、投資収益率（ROI）を使うことを推奨しています。
そして、ROIを左右するのは、プロジェクトの失敗確率であって、失敗には、１）市場を外してしまうこと、２）コストや品質問題、３）時間と予算超過が大きな要因であると述べています。
この辺りは、言われてみると当たりまえのことばかりなのですが、ひとつ注目しておきたいのは、プロジェクト評価に投資収益率（ROI）を使うというところで、プロジェクトを実行するリーダーたちが、経営的な視点をもってプロジェクトを遂行するというところが重要なポイントで、この後説明するチーフエンジニア（主査）と呼ばれるトヨタの開発リーダーの多くが経営レベルでプロジェクト管理を行っているという事実とつながってきます。
さらに、開発中のムダを排除するということにも注力すべきという記載があり、トヨタの大野耐一さんが生み出したリーン生産の思想が徹底的にムダを排除するということであることから、開発の中でも徹底的にムダを排除すべきであると述べています。
開発におけるムダとして、
- 散乱のムダ・・・知識が必要な場所に届くのを妨げるムダ
- 手渡しのムダ・・・責任、知識、行動、フィードバックを分離することによるムダ
- 希望的観測のムダ・・・データなしでの意思決定。あるいは利用可能な知識を捨ててしまうことによるムダ
表現が難しいので、少し解説をしておきます。
1は、情報伝達の問題を指摘していて、必要な情報が様々なところに散らばっていて、必要なときに必要な情報が入手できないことによるムダを指摘していて、結論から言うと、だからトヨタのＡ３報告書を使った知識マネージメントは有効だということにつながっていきます。
2は、もっとも深刻なムダと表現されているのですが、これも少しわかりづらいかもしれません。組織間、個人間、立場間の断絶というように捉えてもらうとわかりやすいかもしれません。知識や経験、情報など、チーム内で共有することでもっと効率的な仕事ができるはずなのに、断絶が起こって、知識、経験、情報がムダになっていることを指摘しています。責任の分断も大きな問題であって、トヨタはチーフエンジニア（主査）の存在によって、責任は一気通貫となっており、チーフエンジニアを中心に大部屋方式でステークホルダーが一堂に会して開発を進めることで、このような断絶を防いでいることに繋がります。
3は、簡単に言うと、客観的データや情報を使った意思決定になっていないことと、せっかく生み出した知識、経験、情報が、利用可能な形式、つまり報告書として残っていないことで、知識、経験、情報が捨てられてしまうことへの危機感を指摘しています。これもＡ３報告書の重要性に繋がっていますが、大事なことは、単に紙に書いて残すということだけでなく、“利用可能”、つまり内容がしっかりしていて信頼できるものであるというところも注意が必要です。
参考記事：「失敗学から学ぶA3報告書ナレッジマネージメント」
価値創造に集中する
開発のムダを減らして、よい開発システムを作るということは、価値創造に集中するということだと述べています。
そして、価値創造に集中する開発システムを作るためには、以下の５つが必要だと言っています。
- 素早い学習サイクルで、利益の出る生産バリュー・ストリームに集中する。
- これを起業家的システム設計者（Entrepreneur System Engineer=ESD）が具現化する。
- セットベース・コンカレント・エンジニアリング（セットベース開発）でこれを実現する。
- セットベース開発をリズム化し、流れとプルによって負荷変動を最小化する。
- 責任を持つ専門家チームで新たな知識を作り出す。
これも少し解説しておきます。
1は、いわゆる仮説検証、PDCAを小さく早く回すことで、機動力のある価値創造を行うことを意味していて、2は、それをESD、つまりはトヨタでいうチーフエンジニアが中心になって行うという意味になり、3は、素早い学習サイクルをセットベース開発で行うこと、4は、セットベース開発で、インテグレーションイベントで定期的で自主性の高い活動によってセットベース開発を強力に推進するということ、5は、チームの一人ひとりが、自分の仕事を自分で設定しながら、自ら考え行動することで、開発を淀みなく進めることを意味しています。
アレン・ウォードは、価値創造を推進するためにLAMDAサイクルを提唱しています。（ただし、これはトヨタが実践しているのではなく、アレン・ウォードの独自の考え方と推測されます）
LAMDAサイクルは、Look（見る）、Ask（質問する）、Model（モデル化する）、Discuss（議論する）、Act（行動する）というサイクルを繰り返すことで、学習を進めていくということで、PDCAサイクルとちょっと似ているのですが、特にDiscussというところが、チーム内のコミュニケーションを活性化させる意味でユニーク、かつ有用な考え方であると思います。
LAMDAは、価値創造におけるチームでの思考プロセス、ワークフローのガイドとして提供されているものですが、厳密な使い方が定義されているわけではなく、企業ごとに様々に解釈され、アレンジされて活用されているようです。また、そういう意味では、例えばPDCAをきちんと回せている企業であれば、特にLAMDAサイクルを意識する必要はないかもしれません。
あえて導入するとすれば、PDCAのP（計画）の段階で、なぜなぜ思考でAskを深め、共通認識を確かにするためにModel化し、チーム内でしっかり議論ができるように、プロセスをブレークダウンすることで、PDCAのPの質を高めるということをやってみてもいいかもしれません。
参考記事：「リーン製品開発、セットベース開発を正しく実践して成果を出す戦略的アプローチ」
起業家的システム設計者（＝チーフエンジニア）
「リーン製品開発方式」の中で、起業家的システム設計者の役割は非常に重要なものと位置付けられています。
つまり、起業家的システム設計者は、まさにリーン製品開発を具現化するための要となるリーダーであり、具体的にはトヨタのチーフエンジニア（主査）のことを指しています。
チーフエンジニアは、ある意味スーパーマンのような能力が要求されるのですが、必要な要件しては下記のようなことが挙げられています。
- 新しく魅力的で実現可能なバリュー・ストリームのビジョンを作り出す
- 自ら偉大な製品を想像することを渇望し、周囲の人間をも奮い立たせる
- 製品とバリュー・ストリームに対する明確なアーキテクチャーを定義する
- 多様な技術や機能に関して素早く学び、技術的リーダーシップを提供する
- 素早く正しい決断をする
- 開発プロセスのムダを避けながらプロセスを管理する
トヨタのチーフエンジニアは、技術に関する知識や開発プロセスに関する知識だけでなく、それを実行する行動力、リスクを感知してリスク回避の行動をとる、さらにはチームメンバーとのコミュニケーションを活性化させるための人間的な魅力を兼ね備える必要もあります。
しかしながら、当然、こういう人材を見つけてくる、あるいは育成することは、実は簡単なことではありません。
多くの企業でもリーダー育成には苦労があると思いますが、チーフエンジニアの育成はさらに必要要件が幅広く深いため、多くの企業がその育成方法を知りたがっていると言えると思います。
トヨタの初代クラウンの開発で生まれた主査制度
トヨタのチーフンジニアは、初代クラウンの開発リーダーであった中村健也さんがルーツといわれています。当時、自家用車の開発は日本企業では無理と言われていたのを、豊田喜一郎さんはどうしても日本で自家用車を開発したいと強い思いを持っていたといわれていて、その思いと同じくらい強い思いを持っていた中村さんが指名されて、トヨタは初代クラウンの開発に挑戦して、成功させました。この話は長くなるので、ここでは省略しますが、初代クラウンの後も、中村さんに続けとばかりに、強力なリーダーが次々と生まれていくDNAがトヨタ内部に作られたのだと思います。
「リーン製品開発方式」の中で、リーンプロジェクトリーダーを選び育成する方法についての記載があります。
いくつかのリーダーとして必要な資質が挙げられています。
例えば、
- システムを設計した経験
- 技術面でも他の面でも学ぶのが速い
- 自ら手を汚して苦労する
- 自分が作りたいと思っているシステムを心に描くことができる
- 鋭い技術的、事業的直観を持っている
など、ある意味、納得感のある説明ですが、もうひとつ特徴的なことは、その職位（つまりチーフエンジニア）を欲しがっている、という記載があります。
これは、実は非常に重要な要素と考えていて、先人の優秀なチーフエンジニアがいて、その人に憧れて、その人のようになりたいという強い思いが人を育てる、とうことなのだと思います。
待遇がいいから、キャリアパスとして自慢できるから、などの動機もあるかもしれませんが、そこを目指す、ということが最高のモチベーションとなることと思っています。
参考記事：「トヨタのチーフエンジニア制度から読み解く強い開発リーダーの育成法」
セットベース・コンカレント・エンジニアリング（セットベース開発）
セットベース・コンカレント・エンジニアリング（SBCE）、あるいはセットベース開発は、アレン・ウォードの著書の中でもっとも重要な要素ではあるものの、実はトヨタ出身者からこの言葉（セットベース開発など）が発せられるのを筆者は見聞きしたことがありません。
つまりアレン自身の理想の考え方でありネーミングであると考えています。
ただし、もちろんアレンの主張する考え方からは学ぶことも多く、また、実際にトヨタも基本的な考え方では一致している部分も多いのだとは考えています。
著書のなかで、アレンが指摘している従来の考え方とは、以下のようなプロセスだと指摘しています。
- 誰かが製品の仕様を決定する
- いくつかのコンセプトが候補に挙がる
- チームが早々と１つのコンセプトを選ぶ
- チームはコンセプトを「詳細化」し、サブシステムの仕様を提供する
- チームがサブシステムを試験する
- チームがシステム全体を試験する
- 評価後にコンセプトを少しずつ改善する
- 以上のプロセスを繰り返す
これは、まさに多くの製造業企業で行われている開発プロセスで、構想段階で誰かが仕様を決定し、それを実現するためのコンセプト、つまり実現方式と言ってもいいものを１つ選んで決めてしまい、以降、そのコンセプトに従って詳細な設計、試験を行って、問題点を少しずつ改善して最終製品に仕上げていくという、ごく一般的なやり方のことを言っていて、これをアレンはポイントベース開発と呼んでいるわけです。
この従来のやり方がうまく行かない理由として、アレンなりの解説をしていますが、注目すべき点は、“古いデータに基づく”とか“古い知識を元に決められる”など、そもそも出発点が間違っているのではないか、というのが一点、そして古い知識からスタートしていることよる制約が大きく、設計者は未確認の将来の技術を無理やり採用することを強制され、さまざまな問題によって混乱が生じている、ということを述べています。
著書の中でアレンは様々な持論を展開していますが、まとめるとセットベース開発の考え方は以下のようになります。
- 古い情報や希望的観測で不確かな意思決定をしない
- サブシステムを小さな単位とし、各サブシステムで複数のコンセプトを作る
- 各サブシステムを厳しい条件で評価し、問題点を新しい知識として蓄積しながら、有効なコンセプトを絞っていく
- コンセプトの精度、詳細度とコスト見積の精度を上げていきながら、コンセプトの完成度を最適化していく
ここで、間違った理解をしないために少し解説を加えておきます。
上記のセットベース開発の説明から、サブシステムの複数のコンセプトを作って並行して評価していきながら、１つのコンセプトに絞っていくというところだけを切り出してしまうケースが見受けられます。
サブシステムを小さな単位として複数のコンセプトを作るのは、未知のこと、未確認のことを早期につぶしていくこと、及びサブシステム間の組み合わせで問題が出ないかを早い段階で確認することで、正しい設計空間を確定していく作業であると考えるべきと思います。
また、構想時点で１つのコンセプトに絞らずに、複数の代替え案を持つということは、イノベーションの可能性を広くしていることを意味しており、構想段階でイノベーションの可能性を自ら計画することに繋がります。
さらに、小さなサブシステムの評価によって、学習のスピードを上げることができ、仮説検証を高速に回しながら、失敗したことを含めて多くの有用な知識を残していくこともセットベース開発の効果といえます。
複数の代替え案を並行して検討することは、一見するとコストや時間が過大になるように思われますが、小さく高速な検証の積み上げによって、無駄な学習を徹底的に排除することがセットベースの肝でもあり、新しい知識を無駄なく高速に積み上げるノウハウこそが、セットベース開発成功の秘訣でもあると考えています。
参考記事：「セットベース開発の導入で成功させるための大事な考え方」
トレードオフ曲線でイノベーションポイントを見つける
「リーン製品開発方式」の中で、トレードオフ曲線は非常に重要なものとして解説されています。トレードオフ曲線の役割は、データを有用な知識に転換することができるか。最適化に向けて設計を支援できるか。どうしたら顧客よりも顧客ニーズをよく知ることができるか。その製品が製造可能であることを保証できるか。これらを実現できるのだと述べています。
そして、リーン製品開発を指向するためには、「このシステムの性能を左右する基本的なトレードオフは何か」を自問することが重要だとも述べています。
シンプルに解釈するならば、製品や部品に関するデータを意味のあるものに変換して、開発に活かすものだと言えるのだと思います。
そして、筆者自身の解釈としては、トレードオフ曲線は現時点での製品、部品や技術の限界を示しているものであって、トレードオフをブレークスルーすることが、ある意味イノベーションの目標となるわけなので、トレードオフをとらえることは、イノベーションの起点となるのだと考えています。
筆者自身のトレードオフの使い方については、別記事「因果関係マップを活用して製品開発革新を加速させる」に記載してありますが、対象製品や部品を顧客価値変数と技術変数に分離し、顧客価値のトレードオフに技術がどう関連しているかを分析することで、イノベーションのポイントを見つけていくという使い方を推奨しています。
まとめ
アレン・ウォードの「リーン製品開発方式」をシンプルに読み解くというのが本記事の目的でありますが、まだまだ記事でカバーできていない内容もたくさんあります。
まずは、第1回目の解説記事として共有したいと思います。
私が強調したいことは、リーン製品開発方式を難しいものにしてほしくないということです。
製品開発の本質は、実はシンプルだと思っています。
ただし、各企業の長い歴の中で、少しずつ歪んでしまった開発プロセスや考え方を見直してみるときに、一つの手がかりとしてトヨタが実践しているといわれている「リーン製品開発方式」を考察してみるのも有効なのだと思います。
記事に関して異論、反論もあるかと思います。
ぜひ意見交換などさせていただきたいと思いますので、ご連絡をお願いします。
