トヨタ式のリーン製品開発の一つの特徴は「セットベース開発手法」と呼ばれるものです。
セットベース開発の対義語は、ポイントベース開発と呼ばれ、製品開発の構想段階で方式や基本構想を決めてしまって、その決定に従いすぐに設計を開始することになります。
私の知る限り、日本の製造業企業はほとんどこのポイントベース手法で開発をしていると思います。
四の五の言わずに、まずモノを作ってみて、評価しながら仕上げていけばいいじゃないかということかと思います。
トヨタ式リーン製品開発では、開発初期に方式や基本構想を決めないやり方で開発を行います。
開発初期にわからないこと、自社内にない知識や技術、顧客価値に関する仮説やチャレンジなどを、すべて検討すべき項目として出し切って、足りない知識を一つ一つつぶしていく「学習サイクル」を通して、徐々に方式を絞っていくというやり方をセットベース開発と言います。
セットベース開発という言葉は、どうもトヨタが考えたものではないらしく、ミシガン大学のアレン・ウォードという先生が自分で考えた手法ということなのですが、アレン・ウォードがトヨタを視察するために訪日したときに、自分の考えた方法をすでにトヨタがやっていることを知って、そこからトヨタ方式を研究し、リーン製品開発方式として体系化したというのが真相のようです。
セットベース開発についてはアレン・ウォードさんの「リーン製品開発方式」にも書かれていますが、この考え方の基本になっているのは、ライト兄弟の飛行機開発ということです。
ライト兄弟が、世界で初めて飛行機を飛ばすことに成功したことはあまりにも有名ですが、実は、もっと凄いのは、彼らは最初の試作機で飛行を成功させたのです。
4年間で、開発費はたったの1,000ドルだったというのも凄いですよね。
なぜ、彼らは最初の試作で成功することが出来たのかというと、小さな実験を繰り返し、わからないことを一つ一つ知識に変えていって、知識を積み上げることで飛行機全体の設計図を作ったからだということです。
セットベース設計で、この一つ一つの知識を積み上げていくための実験をMVE（Minimum Viable Experimentation）と言います。
MVE、つまり小さな実験を積み重ねてから、詳細設計に入るということが、無駄を最大限に排除し、効率的な開発が出来るということなのです。
多くの人たちが、基本的な考え方には賛同するのですが、自分たちだって要素開発は事前に済ませてあって、かつ従来機種を小変更するだけの部品がほとんどなので、今のやり方でも問題ないはずだと言います。
また、セットベースの話を聞くと、「それはもうやっている」とか「それは出来てるよ」と言う人たちも結構います。
でも、セットベースで「開発期間は短くなってますか？」、「品質問題は減少してますか？」とか「ヒット商品が増えてますか？」と聞くと、「それは別だよ」なんて返ってきます。
要するに本質的なセットベースは出来ていないのですが、なんか技術要素を詳細設計の前に仮説検証する、というところだけをとって出来ていると感じるのかもしれません。
しかし、セットベースの本質は、技術課題、顧客価値についてのチャレンジとリスク回避のバランスを取りながら、仮説検証を小さく早く回すことで、できるだけチャレンジの範囲を広げ、かつリスク回避をしながら良い製品を短期間で開発するということが一つの肝であり、もうひとつは、「知識」ということを組織全体で強く意識することで、知識を蓄積すること、蓄積された「知識」を効率的に再利用しながら、良い製品を早く、組織全体の知識で作っていく体制づくりのことなのです。
だから、要素開発をしっかりやっているから、詳細設計をポイント設計でやっても、開発効率が悪いということはない、などと考えるのは間違っているのです。
例えば、既存機種のマイナーチェンジであっても、わからないことやチャレンジすることはあるはずだし、また、ユニット間や部品と部品の接続方法が変われば、リスクはそこらじゅうに存在し、事前に試しておくべきことは山のようにあるはずです。
でも、多くの人たち、特に上位階層のマネージャーさんは、それでも早くモノを作れと、全体を早く作ることこそが早道だとプレッシャーをかけます。
一見、正しい考えであるように聞こえるし、それに敢えて反論する人もいず、結局、泥船を作って何度も試作を繰り返し、問題解決の時間を読み切れずにいつもスケジュール通りに開発が進まない事態に陥るのです。
イノベーションを起こすという観点からも、セットベースは非常に有効な考え方だと思います。
それは、わからないことの中に、顧客がどんな価値を求めているのか、顧客の潜在的な要望は何なのかを、学習サイクルの中に含ませることが出来るからです。
技術的な知識だけではなく、顧客の反応や顧客とのコミュニケーションを学習サイクルに入れることで、本当に顧客が欲しいものを開発できる確率が格段に高まります。
小さな実験は、技術者の魂も蘇らせるような気がします。
私がロボットを本を見ながら作った話を別の記事で紹介しましたが、本の通りにやったって、実は作っている間にいろんなことが起きます。本に書いてないようなことが次々に起きるのです。
それを一つ一つつぶしていかなければ、モノは出来上がりません。
私がロボット作りで問題にぶち当たったとき、助けてくれたのはWeb上での経験談でした。
同じような問題を経験済みの人たちが、その情報を知識として与えてくれます。
つまり、問題にぶつかって解決した経験や知識は、後に続く人たちの知識ともなっていくのです。
これを企業ぐるみで仕組み化しようというのが、セットベース開発手法ということです。
私が最近の製造業で若いエンジニアと接していて感じるのは、最近はPCの前でほとんどの仕事が出来るので、実験室で考え込んだり、ちょこっと何かを作ったり試したりということをしなくなったような気がします。
あるいは、そういう場が無くなっているのかもしれません。
資料を作る、図面を書く、雑用をこなすのが忙しくて、しかも工場は海外にあって、そもそもモノづくりの現場を良く知らない若者も増えて、さらにモノづくりのための簡単な設備や道具すら近くにない状態で数年間も仕事をしていれば、小さい実験をして何かを試してみようという発想も出てこないかもしれませんね。
もう一度、モノづくりの基本に戻す努力をこれからもしていきたいと思います。
コメント