トヨタ式リーン製品開発は、以下の3つの要素からなっています。

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

今回は、リーン製品開発の重要要素であるセットベース開発について解説します。

セットベース開発の起源は、ライト兄弟だと言われています。

ライト兄弟が、世界で初めて飛行機を飛ばすことに成功した人たちであることはあまりにも有名ですが、なぜ、彼らが成功したかはあまり知られていないかもしれません。

ライト兄弟は、とにかく飛行機の試作機を作って、飛ばしてみてだめなところを修正する、という試行錯誤のプロセスではなく、飛行機を飛ばすための「技術」や「部品の性能」などを、一つ一つ細かく検証しながら、飛行機を飛ばすための未知の知識を積み上げてきます。

翼の模型を作り、揚力や抗力を測定するための簡易な実験装置を作って、実験結果を克明に記録していきます。

飛行機を飛ばすための理論を学び、飛行するための条件を満たすための条件を求めていきます。

わからないこと、未知のことをごまかすことなく、納得するまで理論を追い込んでいって、個々の部品やユニットの必要な技術、必要な条件を満たすことを確認し、それらを統合することで、詳細設計を始めます。

ライト兄弟は、開発開始から4年間で開発を完了し、最初の試作機で飛行を成功させました。

開発費は、1,000ドル程度だったと言われています。

このころ、多くの研究者や技術者たちが飛行機を飛ばすことを夢見て挑戦します。

当時、サミュエル・ラングリーという人が、飛行機に挑戦したのですが、17年間、試作→飛行→失敗→修正を繰り返しましたが、結局一度も成功することはなかったそうです。

開発費は、ライト兄弟の70倍程度はかかったと言われていますが、ちょうど鳥人間コンテストのように、はたから見ていると飛ぶはずもないと素人が見てもわかるようなチャレンジだったのではないかと、個人的には思っています。(鳥人間コンテストを非難するつもりはありません。)

一方で、製造業の製品開発現場はどうでしょうか?

鳥人間コンテストとまでは言いませんが、ライト兄弟のような、ち密な学習を積み上げた製品開発をしているでしょうか?

とにかく試作機を作ってみなければ始まらばい、などという一見正しそうな考え方で、まず、試作をしてみて、問題点を出してそれを修正しようというアプローチになっていないでしょうか?

それでうまくいっているのなら、何も問題はありません。

しかしながら、私が知っている多くの製造業の開発現場は、日程遅れが常態化し、製品が市場に出てから問題が発覚し、技術者が市場フォローに走り回って、新しいことに挑戦する時間もない状態が長い間続いている、というケースが非常に多いと思っています。

セットベース開発は、製品開発の構想段階で、新しい顧客価値にチャレンジすることを前提にします。

顧客価値に関する仮設、技術的なチャレンジを明確化、わからないこと、未知のことを明確化し、すべてのリスク、仮説検証のストーリーを作って、学習サイクルに入っていきます。

製品開発に関するディシジョンは、学習サイクルを繰り返し、全ステークホルダー(企画部長、設計部長、製造部長、品質部長、購買部長、営業部長など)が一堂に会して学習サイクルを見守り、徐々に意思決定していきます。

学習サイクルが進むにつれて、技術の完成度も上がっていき、設計方針が決まって詳細設計するときには、ライト兄弟の飛行機と同様に、失敗する要素が残っていない状態になっています。

製品開発の構想段階で、すべてを決めてしまう方式では、最初に決めた製品構想以上のものは出来ませんよね。

でも、セットベース開発では、構想段階から学習を始めていき、その過程で新たな知識が加わっていくことで、構想段階よりも進化した、あるいは顧客価値の高い製品が出来上がることがあります。

何より、開発者、エンジニアたちがワクワクした気持ちで開発を進めることが出来ます。

セットベース開発の概念図を下記に示します。

 

 

セットベース開発を実践する上で鍵になるのは、小さな実験です。

Minimum Viable Experimentation(MVE)とも言われていますが、獲得したい知識だけにフォーカスした、シンプルで安価な実験です。

ライト兄弟の揚力測定器や抗力測定器などがこえにあたります。

小さな実験方法を考えるのは、いつも製品全体の試作をする開発スタイルをとっていた技術者や組織にとっては、最初は難しいかもしれません。

全部作ってしまえばいいじゃなかという思い込みが入るからです。

何かアイデアが浮かんだり、疑問が浮かんだ時に、すぐに何かを作って試してみるというような癖というか、組織文化を作ることがセットベースを展開する上での秘訣かもしれません。

弊社では、セットベース開発の導入の支援もしています。

現状のプロセス、プロセスを変えられないシガラミや拘りを解析しつつ、組織課題を解決するという目的設定をして、開発プロセスの変革を支援しています。