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

 

 

産業機器メーカーC社(仮設定)の中のひとつの技術開発部門で、自社の製品開発プロセスに対して問題意識を持ったメンバーでリーン製品開発を学び、セットベース開発手法を自社で展開しようとします。

まずは、小さなプロジェクトでセットベースの成功体験をして、それを全社に展開するという作戦で自部門でトライアルを始め、やってみたものの何が成果なのかを掴めないまま、この試みは頓挫してしまいます。

何が問題だったのかを検証していきましょう。

 

 

危機感を共有し、リーン製品開発と出会った製品開発組織

失敗事例として紹介する産業機器メーカーC社は、創業100年を超える老舗のメーカーで、従業員2,000名を超える大企業と想定します。

産業用機器に使われるコンポーネントの開発を担当する製品開発課の山根課長(仮名)は、開発組織のあり方に危機感を持っていました。

何がどう問題なのか、はっきりしたことが見えているわけではなく、自分の若い頃に比べると開発者一人一人の自由度が減っていて、開発者の人数は増えているものの、全体的に活気がないように感じていることと、確かに昔の製品よりは技術的な難易度は上がっているものの、それにしても品質問題が多発していて、開発途中、市場投入後にも開発者が品質問題の対応に追われている時間が多くなって、品質問題に追いかけられているような毎日を送っていて、新しいことにチャレンジしている時間が取れていないような気もしていました。

山根課長は、この危機感についてどう対応すべきか、メンバーにも思いを投げかけて議論を深めていく中で、稲垣公夫さんの「開発戦略は意思決定を遅らせろ」という書籍で、トヨタの開発方式であるリーン製品開発と出会います。

課員の多くもこの本を読んで、確信はないものの、リーン製品開発の考え方を取り入れることで、自社の製品開発も良い方向に変わるのではないかとの期待を持つようになります。

メンバーの間で、もっと理解を深めようという機運が高まり、稲垣さんの本の大元になるアレン・ウォード著「リーン製品開発方式」や、元トヨタの人たちの書いた書籍などを読みあさって、リーン製品開発についての理解を深めていきます。

それぞれが理解したことをメンバー間で共有し、どう進められるかなども検討していき、F社主催の「リーン製品開発実践セミナー」にも参加し、自分たちの理解レベルを検証するということも行い、自分たちの考えが間違っていないことに確信を得ていきます。

アレン・ウォードの「リーン製品開発方式」には、トヨタの開発における様々な構成要素が解説されていますが、その中で、セットベース・コンカレント・デザイン、つまりセットベース開発の考え方と、A3報告書をうまく使うことで、社内の知識を会社全体で活用する開発体制にすることができ、自分たちの抱える多くの問題が解決できるのではないか、という考えに落ち着いていきます。

山根課長もリーン製品開発の考え方に傾倒していき、これを実際の開発でどうやって実践していくかということを考え始めます。

上層部を説得するために、まずは直属の上司である部長に相談すると、大きな方向性や基本的な考え方は賛同してくれて、ただし、小さくても良いから成功例を作って、それを持って全社展開するようにアドバイスを受けます。

山根課長もこの考え方には賛成で、小さなプロジェクト、例えばアイデア発掘から新しい製品アイデアを導く小さな試験的プロジェクトを立ち上げて、そこでセットベース開発を実践し、並行してA3報告書による知識共有を進めることで、成功例の土台を作っていくことで、メンバーとも合意が取れます。

新しいやり方にチャレンジできることで、メンバーの士気も高まりますが、既存の仕事を進めながらのチャレンジであり、山根課長も気を引き締めます。

 

セットベース開発の実践プラン

ここでセットベース開発について、少しおさらいしておきます。

セットベースとは、従来の(多くの企業が行っている)開発方式が、目標となる仕様を実現するための方式を開発初期で一つに絞って開発を進めるポイントベースであることに対して、複数の代替え案を残したまま、未知のことを小さな実験によって既知に変えるという学習を繰り返しながら、良い製品を作っていくという考え方の開発方式です。(参考記事:セットベース開発を理解する

 

 

 

山根課長とそのメンバーは、この考え方を出来るだけ忠実に再現しようと考えます。

製品全体の開発でこれを導入するのはなかなか難しいと考えて、まずは、製品化を目指しつつまだ製品化出来るかどうかわからない、いわゆるアイデアから実用化に向けた先行技術開発にセットベースを当てはめようと考えたわけです。

このチャレンジに専任メンバーを当てるのは、実質的に無理であったので、10名程度のメンバーをアサインし、メンバーは他のテーマを抱えながら何とか30%~50%の時間を確保して、新たなチャレンジに入っていきます。

開始時期が年度の途中でもあり、年度内に一度状況を確認するということで、10か月で結果を残すことを目標とします。

山根課長とメンバーは、セットベースの実践方法を検討し、以下のような進め方を決めます。

まず、対象製品と課題を設定し、課題達成についてメンバーでアイデア検討を行い、候補となったアイデアについて詳細に検討します。

検討するの内容は、新たなアイデアの未知のこととは何か?ということで、それをブレークダウンすると

  • アイデアを実現するために越えなければならない壁は何か?
  • アイデア実現の障害は何か?
  • アイデアが採用されるために必要な条件は何か?

というようなことを洗い出します。

そして、これらのことを学習すべきリストとしてまとめ、どんな実験をするとこれらのことが明確になるかを検討します。

通常の開発活動では、すでに企画部門が作ったロードマップに従って既定路線での開発が多く、製品になるかならないかも不明なチャレンジなテーマを進めるということで、メンバーの士気も高まります。

10か月という時間はあっという間で、自分たちのアイデアに関する技術の詰めを行って、技術はある程度見通しが立って、これから製品提案ができるかもしれないという状況にはなったのですが、、、

しかし...

 

見失っていた目的と目標

あるとき、C社の山根課長からF社のコンサルタント芳賀氏に連絡が入ります。

C社がリーン製品開発手法を学んだ時に、F社の「リーン製品開発実践セミナー」に参加し、そこでセットベースの実践方法を学んだことを思い出して連絡をしたわけです。

どうやら、セットベース開発をやってみたものの、開発期間が短くなったわけでもなく、何が成果になったのか、自分たちでもわからなくなって相談したかったようです。

山根課長から一通りの経緯を聞いた芳賀氏は、山根課長に尋ねます。

「そもそもセットベース開発を導入する目的は何だったのですか?」

山根課長は、なぜそんな当たり前のことを聞くのかと訝るような表情で応えます。

「それは、、開発期間の短縮とか、品質問題の低減など、今の開発組織の課題を解決するためです。」

芳賀氏はさらに質問を続けます。

「では、現状でなぜ開発期間が長くなっているのか、そしてなぜ品質問題が多発しているかは、掴んでいらっしゃいますか?」

山根課長は、視線を落として応えます。

「それは..ある程度はわかっているつもりですが..」

明確な答えは返ってきません。芳賀氏は更に続けます。

「では、質問を変えると、なぜセットベース開発を導入すると、期間短縮や品質向上が図れると考えたのですか?」

山根課長は、今度は少し自信を取り戻して、大きめの声で答えます。

「それは、書籍や芳賀さんのセミナーで学んだように、小さな実験を積み上げることで知識を積み上げることが、急がば回れの教えのごとく、結局は近道であって品質の詰めにおける漏れもないと考えたからです。」

芳賀氏は少し微笑みながら続けます。

「そうですね。それがセットベースの狙いですよね。では、二つ質問をします。最初の一つは、開発期間が長くなっている、品質問題が多発しているのはどういう状況で起きていますか?ということ。二つ目の質問は、では、セットベースを導入すると、その状況がどんな風に変化すると予想されていたのですか?」

山根課長の表情が少し曇ります。

「起きているのは製品開発プロジェクト全体を通してです。セットベースを導入することで、状況がどんな風に変化するかは...そうですね...単純に品質問題が起きなくなって、それによって計画通りに開発が進む状況になっていくと考えていました。」

芳賀氏は、表情を引き締めてまっすぐに山根課長を見て話し始めます。

「まず、山根さんたちが試してみたのは、製品開発全体にセットベースを導入したのではなく、前段階のアイデアの詰めのところでセットベース的な考え方を導入してみた、ということのように思えるのですが、いかがですか?そして、製品開発の前段階でアイデアを詰めるやり方は、これまでのやり方と何か違ったのですか?」

山根課長は少し不満そうな表情を浮かべて応えます。

「確かに全体プロセスを通してやったわけではありませんが、複数の代替え案を並行して検討し、かつ未知のことを小さな実験で学習しながら進めるというセットベースの手法はしっかりと取り入れて実践できたと思っています。我々の部隊は、要素開発的なことはあまりやっていなくて、従来機のマイナーチェンジの開発をいきなり始めるケースが多いので、前段階のアイデアの詰め方が従来とどう違うかはあまり意識していませんでした。」

芳賀氏は、山根課長の不満を和らげるように、もう一度笑顔を作って語り掛けます。

「山根さん、私は山根さんたちがやってきたことを全面的に否定しようと思っているわけではありません。真剣に取り組んでこられたことは十分に伝わってきます。そして、確かにアレン・ウォードや稲垣さんの本には、セットベースの定義が山根さんがおっしゃるように書いてあります。でも、もっとも大事なことは、成果が出なければ意味がないということなんです。成果が出ないということは、目的が達成されていないということなので、どこかに見落としがあったと考えてみてください。失礼ながら申し上げると、目的が開発期間短縮と品質問題の低減とおっしゃいましたが、山根さんたちのやってきたことを考えると、その目的達成に関するこだわりが弱く、その証拠に、セットベースを導入していく過程で、目的の達成度がチェックされていないように思います。どんな改革をする場合も、目的を達成することが何よりも重視されるべきなのですが、山根さんたちのお話しを聞いていると、アレン・ウォードの言うセットベースの形を作ることに注力されていたような気がしてしまいます。目的や一定期間内での達成目標が見失われていたのではないでしょうか?別の言い方をすると、御社の抱える課題を深堀りしてみれば、アレン・ウォードのセットベースが御社にとっての正解かどうかもわからないのではないでしょうか?だから、なぜセットベース開発はトヨタのような会社で成功するのか、そしてそれが御社に本当に適用できるのか、ということも含めて、御社の目的を第一に考えて検討するべきなのではないでしょうか?今回、今まで山根さんたちがやってこられたことは、決して無駄ではなくて、この結果を踏まえてもう一度、本当に目指すことは何かということに立ち戻って、基本からやり直して成果を勝ち取ればいいのです。」

 

セットベース実践の戦略立て直し

さて、みなさんはこの事例をどのように考えますか?

この事例は、特定の企業や組織固有の話ではなく、複数の実際に起きた事例を一般化して物語風に表現したものです。(特定の企業の失敗を公開することを目的にしたものではありません。)

しかしながら、実はリーン製品開発に限らず、組織問題を解決して良い方向に変革しようとする企業や組織にとって、陥りがちな問題を多数含んだ事例でもあります。

特に重要な問題は、本来目指すべきこと、つまり改革活動の本来の目的を見失ってしまうことです。

弊社の革新支援は、この陥りやすい課題にしっかりと対応できるものになっています。

キーワードは、”戦略的アプローチ”です。

戦略とは、

  • 自社の現状を正確に理解し、
  • 適切な目的、目標を設定し、
  • 目標と現状のギャップを埋める施策を賢く採用する

というステップを踏み、

シンプルで驚きの基本方針を決定することです。

この事例でも明らかなのは、自社の状況を感覚的にしか捉えずに、他社の成功事例の状態に依存しようとする誤りです。

 

大事なことは、魔法の手法などはあり得ないということをメンバー全員が理解することです。

自分たちの課題は、自分たちの知恵で解決するしかないということです。

他社の真似では、自社の本質的な問題を解決することは出来ないということを、初期の段階で理解できていれば、この事例のような遠回りは避けることが出来たと思います。

フューチャーシップの開発革新支援は、手法や理論をお伝えするだけのコンサルタントではありません。

フューチャーシップの開発革新支援は、戦略思考をベースに、組織課題の本質を追及し、その解決策に適した世の中の成功事例を探し、そしてその成功事例が本当に企業の目的を達成出来るかを検証した上で、革新活動を計画し実践することをフルサポートします。

C社は、この後、芳賀氏の支援を受け入れて、組織問題の状況把握から戦略的アプローチで改革を進めていくことになります。

戦略的アプローチは、難しいことではありません。

現状の正しい理解→目標の設定→現状と目標のギャップを埋める確率向上

ということです。

企業や組織の改革は、戦略的アプローチでなければ成功は覚束きません。

 

そして、改革のための正しい行動計画を立てるためのキーワードは、「連鎖」です。

現状が良くない状況になっていることは、実は何か一つか少数の問題を出発点にした連鎖によって起こっています。

これが組織問題の本質です。

そして、リーン製品開発にしろ、その他の理論や手法にしろ、何かを変えるための施策を打つなら、その施策によって組織がどのような連鎖で変化していくかを予測、言葉を変えると設計する必要があるのです。

弊社は、このようなアプローチを「連鎖式組織改革法」と呼んでいます。(フューチャーシップのサービス内容

トヨタが実践して成功していると言われている「リーン製品開発」手法ですが、その手法を盲目的に展開しようとするのではなく、自社の課題を正確につかみ、採用しようとする手法や理論の本質を学び、戦略的なアプローチで改革を成功させてください。

フューチャーシップは、製造業の製品開発革新のプロフェッショナルです。

 

 

この記事を書いた人

賀門 宏一

製品開発組織の改革に永年携わり、考えるエンジニアを育成することで、新製品、新事業を次々に生み出す組織に変革させる製品開発革新のプロパートナー。