セットベース開発手法を導入しているが、なかなか成果が表れない？
トヨタのリーン製品開発手法の中でもセットベース開発に注目し、開発期間短縮やイノベーションの加速を狙って自社のプロセスに導入しようとしており、ある程度プロセスの改革は進めたつもりだが成果が出ない。どうやったら狙った成果が出せるのかを知りたい。
製品開発現場では日程遅れや、手戻り多発、若手の伸び悩みなど様々な問題を抱えているケースが多く、トヨタのリーン製品開発手法を学んで、改革しようという動きが見られます。
しかしながら、リーン製品開発の重要要素であるセットベース開発手法は、理屈としてはわかりやすいのですが、実際には誤解も多く、間違ったやり方も多く散見されます。
本記事では、陥りやすい間違いなどを見ながら、成果を勝ち取るための大事な考え方について解説していきます。
本記事の内容
セットベース開発手法の本質を見極める
セットベース開発、あるいはセットベース・コンカレント・エンジニアリング（SBCE）は、稲垣公夫著「開発戦略は意思決定を遅らせろ」やアレン・ウォード著「リーン製品開発方式」などに詳細が説明されています。（弊社HPの記事も参照ください。「セットベース開発を理解する」）
セットベース開発の概要をここで簡単にまとめておきます。
- 開発における未知の領域に対して複数の代替え案を出す
- 多数の代替え案を並行検討して、徐々に絞り込む
- 仕様案が一つに決まったら、そこから詳細設計を始める
- セットベースは知識創造と知識の再利用が重視される
文面だけ見ると、何だか当たり前のことを言っているようにも見えるし、代替え案を簡単に捨てないで並行検討するというところが、普通のやり方と一番違う所かな？などと思う方もいるかもしれません。
企業によって開発体制やプロセスは様々ですが、よくあるパターンとしては、研究開発部門で基礎研究や要素開発を進め、新しい技術の実用化に目途がついたところで製品開発に移行するということがあります。
セットベースの進め方でいうと、代替え案を並行検討するところが要素開発にあたり、製品開発のところが詳細設計ということになり、セットベースの考え方は良くある当たり前の進め方だと受け止める方もいるのです。
しかしながら、アレン・ウォードや稲垣さんが言おうとしているのは、この要素開発と製品開発というステップとは少し違うと筆者は考えています。
理論、あるいは手法としてのセットベース開発の本質は、
- セットベースは知識創造と知識の再利用が重視される
というところにあるのだと思います。
そして、組織内の知識を結集することで、未知の状態から既知を作り出すことによって大きな価値を生み出そうとすることが、セットベースの本質だと考えています。
ライト兄弟の偉業がセットベース開発のルーツ
セットベース開発のルーツはライト兄弟の偉業にあると言われています。
ライト兄弟は、世界で初めて飛行機を飛ばすことに成功した人たちですが、その開発過程こそセットベース開発そのものであったということです。
ライト兄弟がやったことは、空を飛ぶという未知のことに対して、一つひとつ未知を既知に変えていって、学習が完了したところで飛行機を設計したということです。
未知を既知に変えるために、翼や風洞の模型を作り、模型を使って簡易な実験装置を作って揚力や抗力を測定し、結果を克明に記録していくことで知識を積み上げていったということです。
ライト兄弟のやり方ではない、多くの他の人たち、飛行機に挑戦していた人たちは、とにかく試作機を作って試してみて、ダメなところを修正して試作をやり直して挑戦するというやり方でした。
もちろん他の人たちも、技術的な背景や理論を全く持たなかったわけではないと思います。
部分的な知識や理論を使って後はとにかく試してみよう、という発想なのだと思います。
実は、ここがセットベースの本質を理解する上で重要なことになります。
従来のやり方との違いに着目する
セットベースの本質を理解するためには、従来のやり方との違いに着目する必要があります。
飛行機設計の例でいうと、従来は部分的な知識や理論をベースに、後は実際に試しながら良いものを作ろうというアプローチですが、ライト兄弟の場合は、理論を一つ一つ積み上げて、未知のことがすべて既知に変わるまで学習を済ませてから全体設計を行ったわけです。
つまり不完全な知識と完全な知識という違いです。
完全というと多少語弊があるかもしれませんが、わからないと自分たちが意識していたことを'わかること'に変えるまでは学習を続けるということが、セットベースの肝ということなのです。
ここで、多くの企業の製品開発現場のことを考えてみましょう。
重要な新規技術は、研究開発部門や要素開発を担当する部門で実用化レベルまで検討されていますが、それ以外のことはどうでしょうか？
通常、新しい製品の仕様は営業部門と企画部門が連携して、顧客ニーズに応えられるような仕様が提示されます。
当然、実用化検討が済んだ技術の採用を意識したものですが、それ以外にも従来製品では実現できていなかった新たな要求が加わったりしています。
また、新たな製品を実現する方法については、完全に詰められていない場合もあります。（実現方式までは要素開発として取り扱われていないということ）
さらに言うと、実現方法が複数ある場合もあるのですが、通常、製品開発フェーズに移行した後では、実現方法を複数検討することは稀で、構想検討段階で机上検討によって実現方法は一つに絞られます。（これが、セットベースに対して従来方式をポイントベースと呼ぶ背景になります。）
従来の多くの企業が行っている製品開発では、キー技術の実用化開発は済んでいるものの、その他の小さな仕様変更、実現方法の検討などは、まだ未経験の領域であって、製品開発と同時に試してみるという方針で進められます。
ここが、ライト兄弟のやり方と決定的に違うのです。
自分たちが意識する未知のことをしっかりと学習を済ませてから詳細設計に移る、という考えではなく、キー技術の要素開発は済んでいるものの、その他の仕様実現や実現方式などの未知のことは、やりながら詰めるというのが従来のやり方になります。
セットベースを導入しようとするときに、このポイントを掴めていないと、代替え案を並行検討することだけがセットベース方式としてクローズアップされてしまうのです。
セットベースの本質は、代替え案を並行検討するということだけではなく、未知のことをしっかりと詰めてから詳細設計ということが大事だということです。
セットベース開発導入の落とし穴
開発組織の諸問題を解決すべくセットベース開発を導入しようとする企業が増えています。
しかし、セットベースの本質を理解しないで進めても成果は期待できません。
前述したように、セットベースを複数の代替え案を並行検討することだと捉えてしまうと、要素開発と製品開発を分けること、つまりは当たり前のことをやるだけになってしまい失敗します。
このことは、別記事「リーン製品開発、セットベース開発を正しく実践して成果を出す戦略的アプローチ」にも詳しく記載していますので、参考にしてください。
そして、もう一つセットベース開発導入における落とし穴があります。
それは、成果目標を曖昧にしたまま導入を進めることです。
組織の様々な改革を行おうとするとき、多くの場合、組織で起きている問題は単純ではなく、様々な細かな問題が絡み合って様々な現象が発生しています。
製品開発組織においても、
- 日程遅れの常態化
- 品質問題に追われている
- 同じような品質問題を繰り返す
- 開発途中で仕様変更が頻発し手戻りが多発する
- 若手が伸び悩む
など、たくさんの悪い症状が起きています。
組織改革を行う時、これらの問題すべてを解決したいと考えるのは当然ですね。
そして、うまくやっている成功事例を探して、その事例を真似することですべての問題をきれいさっぱり解決したいと考えるわけです。
リーン製品開発やセットベース開発は、トヨタが実践して成功しているから、うちも導入することで多くの課題を一辺に解決できると考えます。
実はここに落とし穴があるのです。
セットベース開発が何か魔法のツールのように錯覚してしまうのかもしれません。
なぜセットベース開発を導入すると問題が解決されるかという根拠を持たずに導入することで、成果を出すことが出来ず、さらになぜ成果が出ないのかと悩むことになってしまいます。
ここに２つの問題があります。
- セットベース開発で問題が解決されるロジックを持っていないこと
- セットベース導入の過程で、成果に向かって変化している状況をテストしないこと
セットベースの本質を見失って、とにかくやってみようというアプローチでも、場合によっては成果を得られるかもしれないのですが、少なくとも上記の１、２の落とし穴を理解して、自分たちなりに成果を生み出すロジックを持ち、成果の状態を測定してPDCAを回すことをやっていれば、改革は前に進めることが出来ると思うのです。
セットベース開発導入を成功させる重要ポイント
セットベース開発を導入して成果を勝ち取るためには、まず第一にこの記事の最初に書いたように、セットベース開発の本質を理解することです。
複数の代替え案を並行検討することだけではなく、知識を獲得し、組織内の知識を再利用することで、未知の知識を無くすまで学習した後に製品の詳細設計を行うことで、顧客の求める製品を高品質に作り上げることです。
抜け漏れなく学習することで遠回りに見えるのですが、'急がば回れ'を地で行くように、結果的には開発期間も短縮されるということです。
この原理をしっかりと理解した上で、さらに考えるべきポイントは以下の５ステップです。
- セットベースの展開よりも何を達成したいかが先
- 現状の組織の悪さ、問題を正しく認識する
- 目指すゴールに到達するようセットベース開発をカスタマイズする
- カスタマイズしたセットベースで組織がゴールに近づくシナリオを設計する
- シナリオを手掛かりにPDCAを回す
１．セットベースの展開よりも何を達成したいかが先
まず、セットベース開発ありきの考え方をやめましょう。
そもそも自分たちは何を達成したいかが先です。
何となくずべてがうまく行くという考えでなく、自分たちの状況を自分たちで考えて、自分たちで変えていくという当たり前の考え方を持つことが大事なのです。
前述したように、製品開発組織には様々な問題や課題があることが多いと思います。
その中で何が一番大きな問題なのか、ということを考えてみましょう。
日程遅れの常態化を何とかしたいということが第一優先なのか？
品質問題を起こさない、起きても迅速に対応できる組織力を求めるのか？
まずは、自分たちが何を達成したいのかを決めてください。
そして、その達成したいことに対して、セットベース開発が本当に解決策になるのか、という順番で考えてみてください。
２．現状の組織の悪さ、問題を正しく認識する
そもそも何を達成したいのか、という考えを持ったなら、次になぜ達成したいことが今出来ないのか、つまり元々の組織の悪さや組織問題の本質を捉えていきます。
組織には様々な課題があるものですが、実は問題は一つ一つ独立して起こっているのではなく、それぞれの悪い症状は、多くの場合お互いに影響しあって、因果関係の繋がりで連鎖しているのです。
ある一つの問題が原因となって別の問題を起こし、さらにその問題が別の問題を起こしていく、ということです。
弊社が推奨する「連鎖式組織改革法」は、この因果関係で繋がった問題を構造化します。（参考記事：開発組織における問題の構造化）
そして組織問題の因果関係を原因から結果に向かって矢印でつなげていき、矢印の元を辿っていくと組織問題の根本問題にたどり着くのです。
そして、その根本問題を解決することで、ステップ１で挙げた達成したいことが達成できるかどうかを考えていけばいいということなのです。
３．目指すゴールに到達するようセットベース開発をカスタマイズする
組織問題の構造が明らかになり、問題の根本を掴むことが出来たなら、その根本問題を解決することが次のステップです。
その解決策にセットベース開発が本当に適しているのかを考えるのですが、ここでセットベース開発の本質の話を思い出していただき、セットベースを教科書通りに展開するのではなく、その要素を自分たちの組織やプロセスに当てはめることができるのか、そして当てはめたことで問題解決につながるのか、というように考えていきます。
例えば、品質問題が多発して、開発が進んだ状態で問題対応に追われているという問題を解決したい場合、上流で品質問題を起こさないようにするための学習サイクルをどうやって作れるのか、というように考えます。
構想段階で、問題が起こりそうなユニットや技術要素を予測して、そのユニットや技術要素についての学習計画を重点的にチェックするようなやり方が出来るかどうかをメンバーで話し合って、それを自分たちのプロセスに入れ込むということをやっていきます。
アレン・ウォードや稲垣さんの著書に書いてあるセットベースの考え方を基本としつつ、良いとこどりをして、自社独自の開発システムを作ってください。
４．カスタマイズしたセットベースで組織がゴールに近づくシナリオを設計する
弊社の「連鎖式組織改革法」では、組織問題の現状分析において個々の問題を因果関係で連鎖式に構造化していきますが、解決策からゴール到達までの組織の変化についても因果関係で検証していきます。
つまり、根本問題を特定し、セットベース開発を自分たちなりにカスタマイズする対策を打つことで、組織がどのように変化して、最終的に目指すべきゴールにどうやって到達するかを設計するわけです。
どんな改革でも、手を打ってすぐに成果が出るわけではありません。
改革は組織が変化することであり、組織変化にはある程度の時間も必要です。
長い時間を必要とするものもあれば、比較的短期間で変化が現れるものもあります。
変化の連鎖が起きて、様々な組織の悪さが良い方向に変化していく状況を自分たちで作り上げます。
TOC（制約理論）の世界では、この連鎖を示した図を未来ツリーと呼びます。
組織の未来の姿を描いていき、組織の変化をシナリオとして表現するのです。
参考記事：「製品開発プロセス改革の設計図はTOCの未来ツリーを使ってPDCAを回す」
５．シナリオを手掛かりにPDCAを回す
- 何を達成したいのか、を明確にします
- 組織の根本問題を突き止めます
- 根本問題を解決するセットベースのカスタマイズを行います
- ゴール到達までのシナリオを設計します
ここまで出来たら、後は実行あるのみです。
シナリオに従ってPDCAを回すときに重要なことは、目指すべきゴールに近づいているかどうかを測定することです。
進捗を評価する、しかもデジタル評価で数値で捉えられるようにすることが重要です。
そして、進捗評価が'何を達成したいか'ということとかけ離れないようにします。
例えば、品質問題の発生を抑えたいといことを達成したいとき、セットベースを導入して、品質問題の発生件数を把握すべきところを、問題発生のリスクを学習サイクルで管理するという施策で解決しようとして、学習サイクルで管理している技術要素の数で代替え評価しないようにしたいということです。
施策の進捗を評価するのではなく、あくまで達成したいことが達成されつつあるかどうかを評価しましょう。
また、改革はシナリオに従って実践していくのですが、どんなに優秀なシナリオも完ぺきというわけにはいかないかもしれません。
予期せぬことも起こるし、副作用や障害だってあり得ます。
間違った予測をしていたかもしれません。
シナリオはあくまで仮説であって、カット&トライの考え方で進めてください。
出来るだけ小さなPDCAを回すことでリスクを回避することが大切です。
弊社は、セットベース開発の実践方法を熟知しています。
企業ごとの状況を分析した上でセットベースをカスタイマイズして展開するノウハウがあります。
お気軽にご相談ください。
組織改革を成功させる指南書
無償配布：「連鎖式組織改革法」のプレゼン資料
トヨタの組織力から学び、TOC（制約の理論）の戦略アプローチを採用した弊社独自の手法！！
「連鎖式組織改革法」のpdf版をご希望の方に無料で進呈しています。
50年勝ち続けられる組織を作る
効率化、チェックリストなしで実践できる組織改革の仕組み
この方法があればトヨタのような強い組織が作れる！！
無料にてPDFをダウンロードできます。下記フォームよりお申込みください。
「連鎖式組織改革法（pdf）」無料ダウンロード
この記事を気に入ってくれたら、下の'いいね'ボタンをお願いします！！
