セットベース開発を理解する - 正しく成果を挙げる実践法 | フューチャーシップの製品開発革新支援

トヨタのリーン製品開発でセットベース開発とはどんな手法？

トヨタが実践していると言われるリーン製品開発手法の中で、セットベース開発が注目されている。要素開発を積み上げていく開発ということだが、それは当たり前のことのように聞こえる。セットベース開発の詳細、特に効果などを知りたい。さらに、セットベース開発をどうやって自社の開発に取り入れるか、その方法についても教えて欲しい。

リーン開発手法の中のセットベース開発について、そのルーツや多くの企業の一般的な開発方法との違い、効果などを紹介しながら、ありがちな誤解などについてもお話しします。

小さく仮説・検証を回すリーンの考え方で一歩ずつ確実に前進することと、「知識」を積み上げる考え方、そしてコンカレント・エンジニアリングとの組み合わせによる効果などを理解いただき、さらにどうやって実践するか、気を付けるべきポイントとともに解説していきます。

多くの企業が進めるポイントベース開発

セットベースの話の前に、多くの企業が行っている一般的な開発方法についてお話ししておきます。

多くの企業の製品開発では、構想段階でターゲットとなる仕様を満足させるための複数の方式案について机上検討を行い、一つの方式案に絞って詳細設計を開始し、出来上がった試作機をテスト・検証して問題を洗い出して修正設計しながら、製品化を目指す方法で開発を進めます。

構想段階で方式を一つに決めることからポイントベース開発とも言われます。

ポイントベース開発は、基本的には従来製品という基盤があって、そこからの飛躍を狙った製品を開発することが前提になりますが、早く製品全体の試作機を作るということを重要視します。

早く作る方が、全体の開発日程も早まるという、一見すると誰も疑いようのない狙いもあるのですが、実はここに思い込みが入っているのだと思われるのです。

実際にポイントベース開発を採用している企業に状況をヒアリングしてみると、

品質問題に追われている
手戻りが多い
膨大な残業時間でメンバーが疲弊している
ヒット商品がなかなか生まれない
チャレンジできない

などの声が聞かれます。

製品全体を一日も早く作るべきという考えが、実は裏目に出ているのだと思います。

実績のある技術と、新製品でチャレンジする技術、未開拓の技術などが組み合わさって出来上がった試作機は、一度問題が出ると、問題が複雑に絡み合っていて、一つを治せば別の問題が新たに出るなど、いわゆるモグラたたき状態になりやすいのです。

実績があると思っていたユニットも、別の新しいユニットとの連携で問題を起こすことがあります。

つまり、出来上がった試作機は最初からリスクだらけなのです。

前期種から大きくは変えてないんだけど、、、と言いながら品質問題対応に追われているという状況になります。

これが多くの企業が抱えている製品開発の問題なのだと思います。

セットベース開発の起源

トヨタ式リーン製品開発理論は、大きく言うと以下の３つの要素からなっています。

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

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

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

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

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

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

飛行機を飛ばすための理論を学び、飛行するために必要な環境や条件などを求めていきます。

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

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

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

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

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

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

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

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

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

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

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

同じような製品の再設計だから、全体の試作を作っちゃった方が早いんだよ、という声が聞こえてきそうですが、本当にそうでしょうか？

パソコンのようなモジュラー型のアーキテクチャーで、各モジュールの仕様がきっちり決まっていれば、一部のモジュールに変更があって問題を起こしてもトラブルは小さく済みますが、モジュール間、ユニット間のインターフェイスが流動的であるすり合わせ型のアーキテクチャーでは、小さな変更で問題が発生したときでも影響範囲が広くなって問題解決が複雑になります。

すり合わせ型のアーキテクチャーでは、モジュールやユニットの変更が小さくても、一つ一つの変更を小さく確認しながら進めるセットベース方式を採用すべきだと考えます。

それが遠回りに見えても、結局は早くて確実な開発方法だということは、ライト兄弟の事例が証明しています。

Amazonで見る

小さな実験（MVE）による学習サイクル

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

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

多くの企業が採用するポイントベース開発は、製品開発の構想段階で一つの方式に決めてしまいます。やり方を一つに決めて、全体の試作・検証・修正を繰り返すことで開発のゴールを目指す方法、つまり、サミュエル・ラングリーのやり方です。

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

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

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

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

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

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

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

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

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

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

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

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

セットベース開発の効果は、リーン製品開発手法を導入している企業で実証されています。

開発期間が30%低減
製品発売後の市場問題が激減
エンジニアの雑用時間が半減
社員のモチベーション向上（離職率低減）

セットベース開発の導入で、学習する組織への変革が進み、そこから様々な成果が期待できるわけです。

セットベース開発のもう一つの側面は、コンカレント・エンジニアリングということです。アレンウォード著「リーン製品開発方式」の中でセットベース開発は、セットベース・コンカレント・エンジニアリング（SBCE)という言葉で説明されています。

上図の中でインテグレーションイベントというのがありますが、これはすべてのステークホルダー、つまり企画、開発、生産、購買、営業、サービスという製品を生み出すためのバリューチェーン全体に関わる人間が参加する会議体で、学習サイクルで得られた新しい知識をもとに、全ステークホルダーが合意の上で次にステップを決定していきます。

トヨタの開発は、大部屋でその車種開発に関わるすべての人が結集して開発を進めます。

決裁者がリレー式で変わっていくフェーズゲート式ではなく、バリューチェーン全体をチーフエンジニアという一人のカリスマリーダーが全体をまとめ上げるというやり方と連携していますね。

学習を積み上げる効果で、良い製品が生み出せるということと、関係者全員で力を合わせて良い製品を短期間で作り上げるという２つの側面があることも忘れてはならないと思います。

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

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

知識資産を育てる考え方

セットベース開発は、小さな実験（MVE）による学習を続けることで、未知のことにチャレンジするということが基本なのですが、学習によって得られる「知識」を会社の資産として捉えて、知識資産を積み重ねることで新しいものを生み出し、会社を成長させるということが考え方の根幹になっています。

実は理論としてのリーン製品開発手法の肝になるのは、この「知識」という考え方なのです。

「知識」というのを言わば組織内を流れる血液のように捉えて、開発プロセスの中心に「知識」を置き、セットベース開発だけでなく、A3報告書文化、チーフエンジニア制と連携させて、理想的な開発結果を手に入れているのだと思います。

下表を使って、ご自身の「知識」を棚卸ししてみてください。

人間の知識には限りがあります。

組織の持っている知識も同じように限界があって、その限界を知ることが大事なことなのです。

自社に知識があることを知っている、というのはある意味当たり前ですよね。

自社に知識がないことを知れば、それを知っていることに変えるのが学習であり、技術開発行為は知らないことを知ることに変える行為とも言えます。

しかし、人間も組織も、知識がないことを知りもしないということの方が多いのではないでしょうか？

なので、「知らないことを知らない」、ということを「知らないことを知る」こともまた学習の一つと言えるのだと思います。

「知らないことを知らない」→「知らないことを知る」に変え、さらに「知っていることを知っている」に変えていくことをやるのが学習であって、学習を小さな単位で早く回しながら目標達成していく開発行為をセットベース開発と呼んでいます。

「知識」を血液のようにというのは、この表のように自分や自社に「知識」があるかないかを強く意識しながら、足りない「知識」を積み上げていく開発プロセスを作っていくことがとても大切です。

また上の表で、知っていることを知らない（暗黙知、知識バイアス）というのがあります。

実は、これも開発組織の中では大切なポイントです。

ベテラン技術者ほど、自分が知っていることは当たり前のことなど思い込んでしまいます。「こんなこともわからないのか？！」というやつです。

このベテランの暗黙知を放置しておくと、ベテランの退職とともに会社の知識資産が失われてしまいます。

「知識」を大事に扱う必要があるという背景はここにもあるわけです。

コラム：知識ベース開発とも言われるリーン製品開発手法

リーン製品開発手法は、知識ベース（ナレッジベース開発）と呼ばれることもあります。

アメリカでリーン開発を導入して成功したテラダイン・ベンソスという検査機メーカーでは、リーン製品開発手法を導入して成し遂げた自社独自の開発プロセスをナレッジベース開発（知識ベース開発）と呼んでいます。

開発システムの中心に置いているのは、会社の知識資産であり、この会社ではそれをA3報告書で蓄積し流通させています。

リーン製品開発手法の本質は、セットベース開発とA3報告書文化との組み合わせで、ナレッジマネージメントを完成させることではないかと考えています。

ナレッジマネージメントで陥りやすいのは、文書管理システムを作ればナレッジマネージメントがうまく行くという勘違いだと感じています。

もっとも重要なことは、知識情報（ナレッジ情報）の質を高めることで、知識情報が広く読まれ、正確に理解され、そこから新たな技術や新たな顧客価値が生み出されることで、製品開発プロジェクトに大きな利益をもたらすことです。

セットベース開発を、質の高い知識情報を組織内に流通させ、それによって開発行為の質を高め、イノベーションを加速させることと考えていただきたいです。

参考記事：「トヨタのリーン製品開発から学ぶ本当のナレッジマネージメント」

さて、セットベースの話をすると、「それは要素開発と製品開発を分けることだろう。そんなことはうちもとっくにやっているよ。」という人や、「セットベースの勉強をして、うちの会社ではもう実践してますよ」という人が結構たくさんいます。

一番最初に「もうやっているよ」と言ったのは、私が以前勤めていた会社の役員さんでした。

では、その結果、「開発期間は短くなりましたか？」、「品質問題は激減したんでしょうか？」とか「新しいコンセプト商品をたくさ出せてますか？」と聞くと、「いや成果はまだだ」みたいな答えが返ってきます。

要するに、肝心な目標が達成されていなければ、それはセットベース開発が出来ているとは言えないのだと私は思います。

確かに、要素技術を一つ一つ詰めていく行為を製品開発と分けている企業はあると思います。

しかし、セットベースの本質は、要素技術と製品開発を分けることでもないし、技術要素開発の仮説検証を詳細設計前にやること、だけでもないのです。さらに言うと、複数の代替え案を並行で検討すること＝セットベースでもありません。（後述します）

セットベースの本質は、広い可能性を見据えて、チャレンジの幅を広くとることと、リスクを回避するための安全策を複数残しつつ、仮説・検証を出来るだけ小さく早く回すことで、できればチャレンジ度の高い製品を目指しつつ、リスク回避も忘れないで、結果、短期間に良い製品を高品質で開発することなのです。

そしてセットベースのもう一つの狙いは、MVEによって組織内に「知識」を蓄積し、必要に応じて蓄積された「知識」を再利用することで、組織全体の知識を使って良い製品を早く高品質に開発するシステムを構築することなのです。

つまり、セットベースの考え方は、要素開発の後の製品開発をさらに踏み込んだ先にあると考えてください。

セットベースの考え方を導入すると、要素開発と製品開発を分けた後の製品開発においても、未知のこと、チャレンジすべきことをしっかりと抑えて、学習サイクルを継続します。

技術に関する学習だけでなく、顧客価値に関する学習、時間軸での技術や市場要求の変化にも対応しながら、発売するときに競争力が落ちることのない開発を実現することが出来ます。

つまり、セットベース開発は、単に要素技術開発と製品開発を分けるだけではないことを付け加えておきたいと思います。

セットベース開発の導入には様々な障害も考えられます。

小さな実験（MVE）という考え方の導入も工夫が必要です。

そもそも小さな実験って何をやるの？という質問を受けることもあります。（顧客価値同士のトレードオフを調べることから始めてくださいとお答えしてます。）

何より、これまでのやり方を180度変えることに対する抵抗は並大抵ではないかもしれません。

どれくらい効果があるかも説明が難しいですね。

個別組織向けに単発でセミナーなどもお受けしています。（セットベース開発の実践法など）

セットベース開発の実践で迷いなどがあれば、ぜひ弊社まで問い合わせフォームを通してご相談ください。

また、ぜひ、下記の関連記事も参考にしてください。

関連記事：

セットベース開発の実践を阻害する障害とトップをロジカルに説得する方法

因果関係マップを活用して製品開発革新を加速させる

「製品開発組織改革、リーン開発導入の失敗パターンから正しい改革の進め方を学ぶ」

理論はわかるが実践が難しいセットベースを実践する

「セットベース開発は理論としては理解できるが、実践するイメ―ジが沸かない」

「小さな実験（MVE）って、具体的にはどういうことで、どうやるの？」

というコメントをいただくことがあります。

現状のやり方と大きく違うということが背景にあるからかもしれません。

一点突破のポイントベース開発に慣れてしまって、どこから手を付けて良いかがわからないからかもしれません。

しかしながら、ライト兄弟の飛行機開発の例をよく考えてみてください。

今まで開発したことのないモノを作ろうとすれば、逆にこのやり方以外は考えにくくありませんか？

継続して既存製品を開発するプロセスだから、一点突破ですぐに製品試作を作ることが当たり前になっていませんか？

製造業で継続的に製品開発をしている技術者にとって、まったくゼロベースで新しい製品を開発することの方が珍しいことになっています。

まったく新しい製品を開発するためには、どんな手順で技術を詰めていくかを考えますよね？

どうやって開発するかを考えることが、実はセットベースだと言えるのだと思います。

確かに、ずっと既存製品のマイナーチェンジばかりをやってきたならば、どうやってゼロから開発するかを考える必要がありません。

そこに落とし穴があるのだと思っています。

フューチャーシップの製品開発革新サービスでは、既存製品の開発においてもセットベースの考え方に変えていく、あるいは基本に戻していくための変革プロセスを提案することが出来ます。

複数方式を並行して検討することがセットベースではない

セットベースに関する誤解で、方式を絞らずに複数の代替え案を並行検討することがセットベースと誤解されるケースがあります。

確かにセットベースの定義があるとすると、複数の代替え案を残したまま開発をする、ということも一つの定義ではありますが、これでセットベースと考えるのは誤りです。

例えば、新たな機能を達成するための最適な方式を見つけたい、と言うようなときに、候補となる複数の案を同時に検証するというのは、これは機能要件を達成する新たな方式を探索するために、当然やらなければならないことであって、セットベースとは言えません。逆に一つ一つに決め打ちして進め、ダメだったら他を採用するということにはならないはずです。

要するに、出発点は今どんなやり方をしているか、ということです。

今のやり方で問題なければ、新しい手法を取り入れる必要はありません。

今、問題があるから、新しい試みをするということです。

では、今どんな問題があって、それをどう変えたいか、ということが出発点にあるはずです。

セットベースを導入する一般的なパターン（他にもありうる）は、構想段階で方式を１つに絞って、製品全体の試作をすぐに始めるポイントベース開発によって、品質問題が多発し、開発者の負担が増大、日程遅れが常態化しているという問題に直面している組織が、セットベースによって、遠回りに見えるけど、方式案を絞らず、未知のこと、一つひとつの技術要素を小さな実験で潰していきながら、良い製品を今までよりも短期間で開発しようということになります。

品質問題を低減させ、日程短縮を狙うという明確な目標を持てば、セットベースの形にとらわれることなく、本質的な改革をすることが出来るはずです。

セットベース開発を展開するための参考情報

セットベース開発を展開しようとして成果が得られない失敗事例

セットベース開発の導入で成功するための大事な考え方