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

セットベース開発の考え方はわかったけど、実践は難しくないですか？！

「セットベース開発を理解する」記事を読んで、トヨタ式リーン開発におけるセットベースの考え方はよくわかったけど、開発プロセスの現実を考えると、かなり大幅な変更が必要で、本当に実践できるのか心配があります。どんな障害があって、どうやって克服できるのかを知りたい。

複数の製品開発現場で、挫折や組織の抵抗などを受けながらリーン開発による改革を実現してきた経験から、セットベースの実現の障害とそれに対する対応策についてお話しします。

まず、セットベース開発を実践しようとするときに、いくつかの誤解が生まれます。誤解を放置せずに、手法の本質的な意義を理解することと、そもそも組織として何を成し遂げたいかを明確にして、目標と目標を達成するためのセットベースの意義がマッチしていることを確認の上、ブレることなく改革を進めていただきたいと思います。

もっとも大事なことは、組織の持つ「知識」「ノウハウ」を土台にして、より良い製品を世の中にリリースしていこうとする文化を作ることだと思います。

そのために、「知識」「ノウハウ」に関する情報を、組織内の血液のように循環させる仕組みや考え方を作り上げ、その上に開発の進め方として、セットベース開発というプロセスを作り上げることが大事だと思います。

以下、阻害要因と対応方法について詳細に説明します。

セットベース開発についてのおさらい

セットベース開発の詳細については、以下の別記事を参照ください。

ここでは、ごく簡単におさらいしておきます。

セットベース開発では、製品構想段階では方式を一つに決定しません。

顧客価値に関する知識を含めて、方式を決めるための知識も不足していると考えるからです。

製品構想段階で、わからないこと、チャレンジすること、顧客価値の仮説、トレードオフなどをまとめ、すべてのリスクを出し切って、それらを学習サイクルで一つ一つ潰していきながら、ステークホルダー全員の合意を取りながら、方式を絞っていきます。

学習サイクルを繰り返すことで、技術的な完成度が自然に上がっていき、方式が決定するころには技術課題が無くなっているということと、本当に顧客が欲しいと思ってくれる製品が出来上がっているというわけです。

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

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

セットベース開発の実践を阻害する誤解と障害

結局は要素開発と製品開発を分けるということじゃないの？という誤解

セットベース開発で最も多い誤解は、「結局は要素開発と製品開発を分けるということじゃないの？！」という疑問です。

セットベース開発での学習サイクルは、基礎研究や要素技術開発後の製品開発においても、まだ、未解決な問題やリスクがあるという前提で行うものです。

研究所や要素開発組織では、大きなくくりで新しい技術の探索を行い、実用化の目途を立てます。

その活動が、まったく隙のないもので、あとは図面を描けば品質問題も発生しえない状況であるならば、セットベース開発は必要ないのかもしれません。

しかし、多くの企業では、研究所や要素開発組織から製品開発に受け継がれるのは、ひとつの技術ユニットや技術要素の完成であって、それを製品に仕上げるためにはまだまだ未知のこと、わからないことやリスクが残っているのが普通だと思います。

つまり、研究所や要素開発部門からの新技術の棚入れがあったとしても、製品開発段階でまだたくさんの未知のことやチャレンジが残っているということです。

研究所や要素開発部門から受け継いだ技術以外にも、顧客満足度を上げるために、従来スペックを少し上げたいとか、製品開発のレベルでの創意工夫によって良い製品に仕上げるために、ある程度ストレッチな目標を持つはずです。

それらの未知なこと、チャレンジすることをセットベース開発の学習サイクルで知識を積み上げていくアプローチによって、ゴールへ向けた確実なプロジェクト推進を行うことができます。

時間とコストが従来よりも余計にかかりそうという誤解

方式を決めないで、複数の方式を残して要素ごとに実験をしていたら、時間もコストもかかるじゃないか、という指摘を良く耳にします。

ひとつの方式に絞って、決めたらその方式で試作機を作ってしまった方が圧倒的に早いだろうという考えです。

ずっとそのやり方でやってきた安心感と、直感的に早いと感じる思い込みからそう信じているのだと思いますが、セットベースの起源となったライト兄弟の話を思い出してください。

飛行機を飛ばす努力は色んな人たちがトライしてきました。その中で、サミュエル・ラングリーという人は試作機を作っては飛ばし、というアプローチを行った結果、17年間で一度も飛行を成功させることが出来ませんでした。

一方、ライト兄弟は、試作を行わずに基礎実験を繰り返し、知識を積み上げて、一回の試作で飛行を成功させたのです。

セットベース開発による期間短縮は、他にもたくさん実例があります。

これまでの常識にとらわれて、思い込みから脱却できないと、モノゴトの本質を見誤る良い例だと思います。

もちろん障害はありますが、泥船を作ってコツコツ手直ししていくやり方と、最初から制度の高い設計を行うやり方とどちらが優れているかを、もう一度冷静に考えていただければと思います。

小さな実験って難しいのではという疑問

製品全体の試作を作って開発を進めてきた組織にとって、製品の試作を止めて、獲得したい知識だけを学習するための安価で小規模な実験（MVE：Minimum Viable Experimentation）というのは、確かにハードルが高いかもしれません。

やったことがないから、どうやったらいいかわからない、ということですよね。

この考え方自体が、既存製品のマイナーチェンジ的な開発しかして来なかったツケが回ってきたと考えるべきかと思います。

全く新しい製品を開発するためには、逆に最初に全体製品の試作を作る方がリスクが高いことが理解できると思います。

未知の世界に入っていくのですから、一歩ずつ足跡を残しながら進んでいかなければ、失敗のリスクがあるだけでなく、再現性のない一発ものを作るようなもので、技術を維持することすらできなくなるはずです。

製品開発の本質は、

わからないことが何かを理解する
わからないことをわかることに変える

という２つのステップの繰り返しだと思います。

小さな実験を習慣づけるには、モノづくりの基本に立ち返って、思いついたら簡単な装置を作って試してみる、ということを「やって見せて」「やらせてやって」という環境を作ることが大切だと思います。

基本は、良い「実験室」を与えること、「実験室」でイノベーションが起きるという意識を全社で持つことではないでしょうか？

既存プロセスとの整合性が取れないという反対意見

最も大きな障害は、既存プロセスを変えられない、あるいは変えたくないという反対意見かもしれません。

下図は、多くの企業が採用しているフェーズゲート型の開発プロセスです。

企画フェーズでは、企画部門が責任区となり製品の企画を決定します。

つまり、セットベースの考え方で最初に方式を決めないという所と、いきなりコンフリクトが発生します。

製品企画が決まった段階で、設計部門長の責任の下、限られた時間で設計の検証をします。

ここで、学習しながら技術を詰めていくというセットベースの考えとはうまくマッチングが取れませんよね。

セットベース開発は、そもそもフェーズゲート的な考え方は捨てて、チーフエンジニアというカリスマリーダーが全体をリードし、技術を積み上げることと、顧客満足を獲得するための製品構想を同時にやっていくわけですから、上図の一般的な開発プロセスとは相いれません。

つまり、開発プロセスの大幅な変更が必要になるわけです。

プロセスを変えるリスク、プロセスを変えても効果はあるのかという疑問と期待される成果とを組織としてどう判断するかということです。

トップが判断できなければ、改革のスタートラインに立てない

セットベース開発は、顧客価値を理解してイノベーションを起こし、開発の無駄を排除することで開発期間短縮、手戻りなしの開発を手に入れられる優れた手法であるのですが、上述したように、誤解や組織の了解を得られにくいという障害があります。

予測される障害が、組織にとって致命的であり、かつ得られる成果にも期待が持てないと組織のトップが判断するのであれば、この改革は進めるべきではないのだと思います。

しかし、この障害が思い込みや、未知のことへ踏み込むことへの恐怖であるならば、それは突破することができるのだと私は思います。

セットベースの考え方を使って組織改革を進めたいと、例えば中間管理職の方々や、あるいは現場の技術者の方が考え始めたとしたら、最大の問題はそれをトップに提案して、どうやってトップを納得させるかということです。

次のステップで、どうやってセットベースによる改革をトップに納得させるかを説明していきます。

参考記事：

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

「リーン製品開発、セットベース開発を正しく実践して成果を出す戦略的アプローチ」

ロジカルにトップを説得してセットベース開発を進める方法

セットベースに限らず、組織内で何らかの改革を進めるためには、周囲の理解、特にトップの同意と支援が必要ですよね。

しかしながら、今回のテーマであるセットベースを使って改革を進めるには、上述したようにたくさんの誤解や障害があります。

弊社では、組織改革や組織の問題解決にTOC（制約の理論）の思考プロセスを使用します。

TOC（制約の理論）では、組織内で何かをしようとしているとき、抵抗の６つの階層（下図参照）があると考えます。

誤解と障害の中で、「結局は要素開発と製品開発を分ける話じゃないか」という疑問は、ソリューションの方向性に同意できないということになり、「時間とコストが余計にかかるのではないか」という誤解は、ソリューションが問題を解決するとは思わない、ということに通じるように思います。

さらに、「小さな実験が難しい」、及び「既存プロセスと整合性が取れない」という指摘は、ソリューションの実行を妨げる障害があることを意味しています。

これらの組織内の抵抗に打ち勝つには、説得するしかないですよね。

では、どうやって説得するか、口先だけの説得や定性的な説明では、人はなかなか納得しないものです。

トップを説得するためには、下記のポイントを強く意識して提案書を作成しましょう。

現状分析の客観性、信憑性をデータとロジックで示す
トップの想い、トップが達成したい重要課題を理解する
トップの重要課題を解決するためのストーリーを提案する
ベストプラクティス（例えばセットベース）の成功例を具体的に示す
提案する施策の副作用や障害、リスクを丁寧に分析し対策を明示する

一つずつ見ていきましょう。

現状分析の客観性、信憑性をデータとロジックで示す

何かを改革しようとするときには、戦略的な思考が非常に重要です。

戦略的思考をするときに、まず最初にやるべきことは正確で客観性のある現状分析です。

今、自分たちが立っている場所を、的確に表現できなければ改革そのものも覚束ないことになります。

現状起こっていること、問題だと感じていることに関する状況を測定しデータ化できるものはしていきます。

例えば、各ステージでの品質問題の発生件数、問題解決までの対応時間などを、過去と現在で比較してみると、状況がどう変化しているかが客観的にわかります。

また、類似問題の発生頻度などは、組織としての経験が生かされていない、とか「知識」や「知恵」が共有されていない問題などを表すことになり、セットベースやA3報告書などの有効性の説明に繋がっていきます。

日頃からデータを中心にした議論をするようになっていれば、思い込みなどが起きにくくなり、健全な改革活動に繋がります。

データを伴って、組織の問題がリストアップされたあと、もう一つ大事なことは、個々の問題の根本原因を見つけることです。

よくある悪い例としては、複数の問題をリストアップして、一つ一つに何か手を打とうとすることです。

根本原因について分析せずに、起きている現象を捉えてそこに手を打とうとする間違いです。

TOC（制約の理論）を使った問題解決のフレームワークでは、複数の問題点を悪い症状として捉え、その悪い症状同士が因果関係で結ばれていると考えます。

つまり、悪い現象は、小数の根本問題が起点となって、負の連鎖によってたくさんの症状として表れていると考えて、問題の連鎖図を作成します。（現状ツリーと呼ぶ）

因果関係の連鎖でつながれた連鎖図（現状ツリー）の大元をたどっていくと、それが組織の根本問題ということになります。

現状ツリーの作成方法は、別記事「開発組織における問題の構造化」（全5回の連載記事）を参照ください。

トップの想い、トップが達成したい重要課題を理解する

すべての企業における共通の経営目標は、利益を出すこと、つまり儲け続けることです。

この儲け続けるという絶対的な課題に対して、そこに到達するアプローチ方法は経営者によって異なるかもしれません。

自社のトップが考えるアプローチ方法、あるいは儲けるための第二水準の目標があるはずです。

それは、ビジョンや経営方針、中期の経営計画などに表れているはずだし、普段からのメッセージを思い起こしてしっかりと理解しましょう。

今回の提案が、トップの目指す目標や基本方針とどう関わるのか、その答えをしっかりと持っている提案であれば、トップの理解が得られ、かつ実行時に全社が一丸となれる改革になり、究極の目的である収益改善につながっていきます。

例えば、トップの想いが既存事業から新規事業へ緩やかにシフトしながら収益を拡大したいという考えなのか、既存製品のラインナップをコストを上げずに増やすことで収益アップを目指すのか、あるいは、新たなビジネスモデルへ挑戦しながら収益源を広げようとしているのか、トップの想いに沿った提案にすることが重要です。

自分の考えを曲げて提案しろということではなく、自分の提案を生かしてトップの想いをいっしょに叶えると考えることです。

＜補足説明＞

実は、セットベースを進めようとする実行サイドにも一つ落とし穴があります。

それは、セットベースの形が出来上がっている（と思っている）のに、成果が出ていないということです。

開発期間短縮を第一の目標にセットベースを実践したい。

セットベースのやり方は理解した。

モデルプロジェクトでセットベースをやってみた。

何とかセットベースの形が出来たけど、開発期間がまったく変化していない。

これは、本人たちはセットベースをわかったつもりになって、出来ているつもりですが、結果が出なければ全く意味がありません。

トップはこういう所は敏感です。

間違ったインプリに陥らないようにするには、手法の実践を目標にしないことです。

あくまで目標は開発組織やプロセスの課題解決です。

課題解決がどの程度出来たかというチェックを入れながらPDCAを回すことが重要です。

トップの重要課題を解決するためのストーリーを提案する

「セットベースを導入すると、開発期間が４０％低減できるのですよ。」

あなたがこのようにトップに提言したとして、トップの想いが前項のようにもっとハイレベルなところにあるとしたら、

「だからどうした？」

となるのではないでしょうか？

あるいは、仮に４０％の開発期間低減の先に、市場投入が早まることで販売機会の増大→売り上げアップ、というシナリオが理解されたとして、懐疑的なトップは、

「なんでそんなことが出来るの？」

と聞きますよね。

ローマは一日にしてならず、と言われるように、課題が大きいほど改革も簡単ではありません。

トップもそんなことは百も承知です。

だから、改革のシナリオをロジカルに、かつシンプル（複雑になりすぎず）に説明すべきです。

下図は、TOC（制約の理論）の問題解決フレームワークで使う未来ツリーと呼ばれるものです。

現状ツリーで発見した組織の根本問題を解決するための、数個（２~３）の施策（TOCではインジェクションと呼ぶ）を設定し、施策（インジェクション）を起点として、ポジティブな連鎖によって、良い状況に変わっていく様子を図示したものです。

インジェクションから因果関係ロジックで、目指すべき未来をトップに示すことができます。

根本問題からインジェクション（施策）を見つけていく方法については、「開発組織における問題の構造化（第四回）」を参照ください。

ベストプラクティス（セットベース開発）の成功例を具体的に示す

ここまで、トップをどうやってロジカルに説得するかという方法論の話を、TOC（制約の理論）の基本的な考え方を少しだけ示しながら説明してきました。

TOC（制約の理論）の手法については、この記事では書ききれません。興味がありましたら、別記事「開発組織における問題の構造化」を参照ください。

ここでは、セットベース開発についてのトップの同意を得る方法についてお話します。

前項で、根本問題に対する施策（インジェクション）の話をしましたが、セットベース開発で得られる利点を深く理解した上で、どんな状態を作り出すかということをインジェクションとして表現します。

セットベースの長所を十分に理解いただいていればおわかりと思いますが、いくつか例を示します。

わからないこと（未知のこと）、チャレンジすること、仮説などをすべてリストアップしてから開発を開始する
仮説検証が終わるまでは方式を決定しない
学習結果で知識を積み上げながら、チーム全体で意思決定をしていく
社内の「知識」をA3報告書化して、「知識」のみを根拠に開発を進める

要するに、セットベース開発の形を取り入れるのではなく、セットベースの良い点を引き出して自社に適用することを提案します。

理論としてのセットベースから、良いとこどりをする感覚です。

すべてのことが一度に達成できるわけではありません。

時間の経過、繰り返し行うことで改善しながら達成していくこともあります。

セットベースの良い点を取り入れたときに、それぞれの点で具体的にどんな成果が期待できるのかをトップに示します。

例えば、未知のことやチャレンジをリスト化して開発することで、事前の検討不足による品質問題が限りなくゼロになる、のような因果関係として説明します。

このことが、他社事例などでエビデンスがあればそれが一番説得力がありますが、事例として説明できなければ、仮説であると宣言した上で、信憑性のある仮設と納得してもらうことです。

セットベースの要素を分解してその利点をトップを含めたメンバーが納得していくことで、自分たちなりの解決策を新たに見出すことができるようになります。

一歩一歩変化を継続していくことで、大きな革新を行っていきます。

一つ一つ成果を積み上げていくという考え方、つまり具体的な成功例を全員がクリアにイメージしていくことが大切です。

提案する施策の副作用や障害、リスクを丁寧に分析し対策を明示する

誤解と障害のところで説明したように、理論としてのセットベース開発をすべて実践しようとすると、組織にとっての懸念が多数残ります。

障害、副作用、リスクを十分に認識していることを示すことは、トップに対して安心感を与えます。

どれだけ深く考えているかという証明でもありますが、この考え方自体がセットベース的ですよね。

わからないこと、チャレンジをリスト化して一つ一つ学習していくのがセットベースですから、改革も障害、副作用、リスクを明確化して一つ一つ丁寧につぶしながら進めていくということです。

セットベースを勧める人間が、セットベース的な改革の考えを持っていないのは示しがつきませんね。

TOC（制約の理論）のフレームワークには、副作用、障害を事前に考えながら計画を立てるプロセスが含まれています。

弊社の改革では、TOCのフレームワークで副作用や障害に対応していきます。

ただし、TOCのフレームワークを使わなくても、本質的な考え方はいっしょです。

施策（インジェクション）を起点にして、ひとつのことを変化させると、その結果、良いことが起こっていき、そのよい結果からさらに次の良いことが起こってというポジティブな連鎖を考えるとき、中には良いことばかりではなくて、副作用として悪いことが起こる可能性があることもあります。

ポジティブ連鎖を考えるときに、副作用がないかをチェックして、可能性のある副作用をピックアップし、ピックアップした副作用に対して新たな施策を考えます。

TOCでは、ネガティブブランチという言い方をしますが、TOCを使わなくても副作用を予測して対応を考えることはそんなに難しいことではありません。

障害に関しては、ある施策（インジェクション）を実施することを考えるとき、すぐには達成できないこと、達成するための障害を取り除きながら進める必要があることを見極めます。

例えば、「学習しながら意思決定をしていく」という状態にしないときに、今までのリレー式のフェーズゲートのプロセスを何らかの形に変えなければならないとか、学習プロセスを誰がリードするのか、トヨタ式で言うとチーフエンジニアとなりますが、チーフエンジニアほど広範囲の責任を持たないまでも、学習サイクルをコントロールする新たなリーダーを育成する必要もあります。

このように、目指すべき状態にする前に、中間にマイルストーンを設定していく必要がある場合があります。

成すべき施策（インジェクション）すべてに対して、障害をピックアップし、障害を乗り越えるためのマイルストーンを設定していくことで、実現性の高い計画にしていくことが出来るわけです。