リーン製品開発、セットベース開発を書籍通りに実践しているが成果が全く出ていない！？
リーン製品開発の参考書籍を読んで、A3報告書やセットベース開発を実践している。書籍の通りにやっているつもりだが、開発期間は短くならない、品質問題も治まっていない、さらにヒット商品が出るようになったとも思えない。一体何が間違っていたのか知りたい。
組織や仕組みの形を真似ても成果は出ません。そもそも解決したい問題は何で、どういうゴールを目指すのかを決めずに、手法ありきで形を導入しても全く意味がありません。
本記事では、まずどんな考え方で組織改革に臨むべきなのか、そして自組織の目標を達成するために、リーン製品開発やセットベース開発から何を取り出して実践すべきなのか、ということを解説していきます。
本記事の内容
事例で見るリーン製品開発やセットベース開発がうまく行かないケース
現場は一所懸命にやっているのに、何だか成果が挙がっていない。
どんなケースがあるか、２つほど例を挙げてみたいと思います。
ケース１：A3報告書の数は溜まってきたが活用されていない
リーン製品開発手法（詳細は「トヨタ式リーン製品開発とは」参照）の３つの重要要素は
- チーフエンジニア制
- セットベース開発
- A3報告書
ということですが、比較的導入しやすくて、成果も見えやすいということで、まずはA3報告書を展開して社内の知識伝達をスムーズにしたいという取り組みがされることがあります。
これ自体はまったく問題ないし、最初のステップとしても良い方法だと思います。
導入手順としては、まずはA3報告書を展開することで、組織として何を狙うのかということを周知します。
次に、A3報告書の書き方などのガイダンス、見本提示などを行い、どんな風に書けばいいかを簡単に指導します。
そして、そこから実際に書き始めるのですが、組織としてこの活動を加速するために、メンバーに報告件数のノルマを課したりします。
この辺りが少し微妙なところになりますが、のんびり待っているわけにもいかないので、ある程度のノルマ化はやむを得ないかもしれません。
しばらくするとA3報告書の件数も増えてきますが、どうも報告書の質がマチマチで、活用されないものを書き残しても意味がないので、A3報告書のレビュー会などを実施し、その場で書かれたA3報告書を公開し、参加者からの意見によってレベルアップする活動が始まります。
これもとても良いことで、報告する側は、質向上のためのポイントを理解できるようになるし、周りの人たちも自分に置き換えて報告書の質について考えることができます。
ただし、ここでの問題は、共有された報告書に対して、どこまで突っ込んだ指摘が出来るか、あるいは正しく指導できる人が何人くらいいるのか、ということが組織全体の質向上の進捗を左右することになります。
適切な指導が出来る人がいなければ、レビュー会そのものがあまり意味のないものになってしまいます。
ここが一つ目のチェックポイントです。
さらに時間が経過していくと、活動そのものがマンネリ化していくリスクがあります。
この辺りでメンバーが認識できる成果が出ていないと、そもそも何のためにやっているのかという疑問が現場から湧き上がってきます。
現場の負担を増やすだけではないかという声も出始めてくるかもしれません。
何より、成果が出ない状況でこの状態を長く続けるのは、組織として健全ではありません。
見失ってしまったのは成果の刈り取り
このケースの場合、A3報告書活動の立ち上げそのものには大きな間違いはないのですが、成果、つまり活動の正しい目的・目標を明確に設定して、それを時間軸の中で測定しなかったことが問題だったと思われます。
このケースでは、A3報告書を毎期最低何枚は蓄積するという目標設定になってしまったため、現場から見ると、自分たちの負担が増えた形跡だけしか見えないことになって、不満が表れるわけです。
本来の目的は、社内の情報伝達をスムーズにすることで、これを具体的な目標に落とすと、例えば、出された報告書の数ではなく、実際に他者に伝達されて役に立った報告書が何枚あったかということにするべきだったのです。あるいはもっと先を行くと、その結果どんな良いことが起こったかなどを指標にすべきでした。
管理するべきは、当初の目的に近づいているかどうかなのですが、報告書の数が増えることが、目的達成に繋がらないことがうまく行かなかった原因ではないかと考えられます。
また、成果の刈り取りと同様に、現場に対する見返りということも欠けていたように思います。
現場にとっては、A3報告書のノルマは大きな負担になります。
ノルマを達成しなければ人事評価がマイナスになる、という構成では、現場のエネルギーが沸いてきません。
本来の目的を達成するために自分が貢献することで、確かに会社に有益であったことが自他とも認められ、かつ人事考課でもポイントが付くようになれば本人たちのモチベーションも高まります。
会社としての成果と本人の成果が認められる工夫が足りなかったのかもしれません。
ケース２：セットベース開発と当たり前の手順を混同して成果が出ない
セットベース開発（詳細は「セットベース開発を理解する」参照）は、説明を聞くと、実は当たり前のことを言っているようにも聞こえます。
私自身も始めて聞いたときに「それって当たり前のことじゃないですか？」と言ったことを思い出します。
その後、セットベース開発について多くの人に説明をする立場になってからも、聞く人によって「それってもうやってるよ。」という反応が返ってくることがしばしばあります。
つまりここで言いたいことは、自分たちがやろうとするセットベースが、これまでの当たり前の範疇なのか？あるいはリーン製品開発手法として成果を出せる新しい考え方になっているのかが混同されて、今までのやり方の一部分をセットベースを採用したやり方と考え違いするケースがあるということです。
製品開発の基本的な流れは、大きく捉えると要素開発と製品開発の２つのフェーズに分かれます。
製品を構成するための小さな単位に分かれた技術要素を予め検討し、一つ一つの要素技術を完成させてから、その要素を積み上げる形で製品開発フェーズに移ります。
この辺りが、セットベース開発ということの理解で誤解が生じるポイントになるのですが、製品開発の前段階で要素技術を詰めることはリーン開発でいうセットベースの範疇からは外して考えるべきなのです。
つまり、要素開発段階で複数の方式を残して、一歩一歩知識を積み上げるのは、当たり前にやらなければならないことで、すべての企業が普通にやっていることです。
リーン開発手法でセットベースと言っているのは、製品開発フェーズに移ってからも、一点決め打ちでないやり方を残すことで、より良い製品を作る、不確実な開発行為のリスクを低減するということなのです。
なので、製品を構成するための要素技術を確立するための並行検討はセットベースとは言うべきではないと思っています。
ただし、製品そのものがほぼ一つの要素技術で出来上がっているものもあり、この場合は、製品開発の中で複数方式を同時並行で検討していくことになりますが、これも敢えてセットベースと呼ぶ必要もないわけで、これは当たり前のやり方として並行検討すべきことであると思います。
少し違う視点でいうと、セットベースと呼ぶかどうかは、実はどうでもいいことで、要するにこれまでのやり方では問題があって、それをどのように変えたくて、だからリーン製品開発手法のセットベース開発を参考に、何かを変えて見ようということをやっていただきたいと思います。
そもそも「セットベース開発」という言葉は、アレン・ウォード著「リーン製品開発方式」の中で出てくる言葉ですが、トヨタの人が自分たちのやり方が「セットベース」だと言っているのを私は聞いたことがありません。（あくまで筆者の知っている範囲でということです）
大事なことは、不明確なこと、未知へのチャレンジ、要素技術の不完全さ、新しい技術ユニット間のインターフェイスなど、製品開発にはリスクがたくさん潜んでいます。
要素開発段階で、十分に技術は詰め切ったと思っていても、製品開発フェーズでの様々な不明確なこと、チャレンジなどは残っているケースが非常に多いのです。
だから、要素開発後の製品開発フェーズでも学習サイクルと関係者全員参加で小さな意思決定（インテグレーション・イベント）をやりながら、本当に顧客に受け入れられる良い製品を作るということが、セットベース開発のあるべき姿ということを改めて理解いただきたいと思います。
リーン製品開発、セットベース開発を導入する場合の、正しいアプローチ方法
リーン製品開発の参考書は色々とありますが、その中でも次の2つが比較的多くの人が参考にしている書籍だと思います。
- アレン・ウォード著「リーン製品開発方式」
- 稲垣公夫書「開発戦略は意思決定を遅らせろ」
どちらもトヨタ研究をされた著者による優れた書籍だと思いますが、実はどちらの書籍もトヨタの実態を外から研究して、トヨタ内で出来上がった理想の状態について解説したものであることを忘れてはいけません。
つまり、トヨタ以外の企業が、その理想の状態をどうやって作れるのか、あるいは極論するとトヨタと全く同じ状態などは作れるはずもないわけで、どうやってその企業独自の開発システムを作れるかということは一切書いてないということなのです。
多くの読者が勘違いするのは、これらの本に書いてある手法や理論を採用しさえすれば、トヨタのような強い会社、あるいは強い組織が自然に出来上がるのだ、という大きな誤解です。
どんな優秀な企業でも、トヨタの真似をすることでトヨタになることは絶対に出来ません。
その会社のDNAや基本方針があり、また扱う製品などによっても目指すべき姿は違ってくるはずです。
しかも、今現時点でその企業がどんな状態なのか、どんな問題、課題を抱えているかによって、目指すべきゴールがどのくらい遠いのか、あるいはすぐ近くにあるのかが変わります。それを見ずに、闇雲に手法を取り入れて成果を出せるわけがないということに、まずは気づいて欲しいと思っています。
結論は、リーン製品開発、セットベース開発を導入して成功させるためには、以下のようなことをしっかりと考えて欲しいと思っています。
- 自社の現状、組織問題とその根本原因（戦略的アプローチ）
- 自社が目指すべき姿（戦略的アプローチ）
- リーン製品開発、セットベース開発の本質的意義
- ゴール達成までの道のり設計（仮説・検証）
リーン製品開発、セットベース導入の前に戦略的思考で改革を考える
どんな手法や理論を導入するときも同じことが言えますが、その手法をなぜ導入するのか、そして導入したことでどうなるのか、ということを考えるのは非常に重要なことです。
言われてみれば当たり前のことですが、うまく行かないケースで紹介したように、この当たり前をスキップしてしまうことが実際に起きています。
私はこの当たり前のプロセスを敢えて戦略的アプローチという言い方で、良くお話しするのですが、
- 現状分析
- ゴール設定
- そのギャップを埋める戦略の設定
というアプローチ、思考プロセスを徹底していただきたいと思っています。
弊社では、この戦略的アプローチにTOC（制約の理論）の思考プロセスを使っています。
多くの組織で起きている組織問題は、一つ一つが単独で起こっているのではなく、それぞれが因果関係で繋がって、因果の元を辿っていくと一つかごく少数の根本問題にたどり着くという考え方で、その根本問題（組織のボトルネック）に手を打つことで、問題解決がうまく行くという考え方です。
また、TOCの思考プロセスは、何を変えるか（現状認識）、何に変えるか（ゴール設定）、どのように変えるか（ギャップを埋める戦略）というステップで進めるのですが、まさに戦略的アプローチと同じ考え方なのです。
具体的な考え方は、本ホームページ上の別記事で解説していますので、そちらも参考にしてください。
TOC（制約の理論）関連記事：
TOC思考プロセスでUDEを使って組織問題の本質を突き詰める
製品開発プロセス改革の設計図はTOCの未来ツリーを使ってPDCAを回す
リーン製品開発、セットベース開発の本質を正しく捉える
うまく行かなかったケースを見ると、A3報告書のケースでは、A3報告書展開による達成目標を見失っていました。
セットベースのケースでは、そもそも本来のセットベースが何故有用なのかという点を深く見ずに、セットベースの実践形態にフォーカスしすぎていたことで、当たり前のことをやることとセットベースとを誤解していたケースでした。
どちらもリーン製品開発手法、あるいはセットベース開発の本当の意義、つまり本質をしっかり見ていないことが原因で、うまく行かなかったのだと見ています。
では、リーン製品開発手法やセットベース開発の本当の意義とは何でしょうか？
それを読み解くのは、本来は手法を導入しようとする本人がどう感じるかということが最も重要ではあるのですが、ここはリーン製品開発を専門として活動している立場でいくつかのヒントを提供しておきます。
トヨタの初代チーフエンジニアであった中村健也さんの言葉で
”うまくいくかいかないかわからないから開発するんだよ。”
というのがあります。
わからないことにチャレンジして成功させる、リーン製品開発やセットベースは、まず、それをどうやってやるかという道すじを示しているものと理解して欲しいと思います。
昨今の多くの企業の製品開発は、既存製品の改良を繰り返すことが多く、本来のチャレンジすることから遠ざかっているように思います。
リスクを取らず、失敗せずに、誰がやってもそこそこの製品が出来るプロセスで、作れば売れる時代を送ってきた企業は、チャレンジすることを少し忘れかけているのだと思います。
リーン製品開発、セットベース開発を導入するということは、このチャレンジする考え方を取り戻す、というところから意識を持っていただきたいのです。
そして、製品開発は時間との闘いでもあります。
限られたリソース、限られた時間で、競合他社よりも顧客に喜ばれる製品を早く出したい、という願いが開発プロセスに表れているわけです。
競争に勝つために、全社が一丸となって、リソースや時間を無駄にせずに、良い製品を出すということを目指した結果、出来上がった考え方がリーン製品開発であり、セットベース開発であるということを深く胸に刻んで欲しいのです。
チーフエンジニア制は、先の中村健也さんのDNAを受け継ぐ形で、他社（中村さんの場合はアメリカに負けないという想い）に負けない、お客様を喜ばせ、企業の収益に貢献する製品（自家用車）を早く世の中に出したいという想い、目標をもった一人のカリスマリーダーのもとで、開発期間中、つまり開発、生産、販売というバリューチェーン全体でその思想が途切れることなく、最後まで、目標達成までやり切る体制を維持するために生まれ、引き継がれている制度です。
多くの会社が、チーフエンジニア制を真似して導入し、結果、単なる部門間の調整役を設定して終わっているのですが、もう一度、本来の目指すべき姿を見直して欲しいと思っています。
セットベース開発は、すでに説明したように、単に方式を絞らずに並行検討することでリスクを分散させるという考え方ではなく、要素開発が完了して製品開発に移行した後でも、顧客価値に関する仮説、新たな要素技術にもチャレンジしてみたい欲求、要素技術同士のつながり（インターフェイス）に関する未知のリスクなど、まだまだ分からないことがたくさんあるという前提に立ち、つまり中村健也さんが言うところの「うまくいくかいかないかわからない」ところからのスタートという認識で、チャレンジするための手法と捉えて欲しいのです。
通常のやり方では、要素開発で技術を詰めてあるから、後は組み上げるだけ、つまり生産と同じように作業として製品を組み上げる、だからリスクも少ないし、予定通りに出来るはず、という考えでなく、要素開発完了時よりも、さらに良い技術も多少追加しながら、あっと驚く製品を作ってやろうというチームを支援するのがセットベース開発ということです。
A3報告書は、過去の失敗事例を教訓として同じ失敗をしないようにするためのデータベースとか、ベテランのノウハウを会社に残すためという理由で採用されるケースがあります。
これはこれで全く問題ないし、ぜひ、その目的も達成して欲しいのですが、リーン製品開発におけるA3報告書は、会社の知識資産を血液のように社内で循環させることで、知識を無駄にしない体制を作り、知識から次の知識、つまり現存の知識に上乗せする形でイノベーションを起こしていくために、全社で作り上げた知識循環システムだと私個人は考えています。
トヨタでは、自動車開発において品質はもちろん、コストや納期に対する市場と経営陣からの強いプレッシャーを受けながら開発が進められます。（多くの企業が同じだとは思います）
そこで、納期を縮めるためには、社内の先駆者の情報は非常に重要だという考えがあるようです。
前期種の情報を使えば、自分たちのやるべきことを減らすことが出来るという発想です。
そしてこの発想を全社の人が持つためには、存在する情報（報告書）は信頼に足りるものという認識です。
すなわち、報告書一つ一つの質が悪ければ、知識情報も信頼できず、つまり再利用されることがなくなるわけです。
A3報告書活動は、A3報告書を貯めるだけでなく、報告書、つまり知識情報の信頼性を上げる（質を上げる）とともに、社内で再利用される文化と仕組みを作る必要があるということです。
そしてA3報告書活動は、セットベース開発による成果刈り取りにも寄与するものと考えています。
セットベースでは、未知の情報は何かということを明確化するところから活動が始まります。
つまり知識情報の棚卸しをして、足りない情報を小さな実験（MVE；Minimum Viable Experimentation）を繰り返すことで積み上げていきます。
この時、自分たちに足りない情報のうちで、他の部門で持っている情報がA3報告書になり、すでに存在する情報であれば再利用できるということです。
そしてセットベース活動で新たに得られた知識情報を、A3報告書にすることで他の部門や後続の開発者に役立てることができるわけです。
このようにA3報告書とセットベースが連携・連動することで、リーン製品開発というのは、会社全体での究極のナレッジマネージメント・システムではないかというのが、私個人の意見ということです。（参考「リーン製品開発の完成形は本物のナレッジマネージメント・システム」）
すべての活動で仮説・検証を忘れない
リーン製品開発、セットベース開発の導入で成果を挙げるためのアプローチ方法として最後に申し上げたいのは、仮説・検証の考え方を忘れないでください、ということです。
手法の導入に限らず、すべての活動で仮説・検証の考え方によって正しく成果を得ることが出来ます。
何故かと言うと、リーン製品開発手法もセットベース開発も、手法や理論は成功するための仮説にすぎないということなのです。
うまく行かないケースを見ても、手法や理論を書籍で教えられた通りにやれば、うまく行くと思い込んで失敗していることが多いように感じています。
事例をそのまま導入すればうまく行く、だからたくさんの事例を聞きたい。
私はそれは自分自身で考えることを放棄しているように感じています。
書籍から学んだことを一つの候補として考える。しかもそれはまだ仮説にすぎないと考えることが大事なのです。
どんな良い手法であったとしても、そもそも自社で実行できるかどうかもわからないわけです。
自社で取り入れると、思わぬ障害があったり、副作用が予想されることもあるはずです。
戦略的アプローチが必要ということを言いましたが、まずは自社の状況をしっかりと掴まないと、仮説にすらならないこともあるということです。
そして、例えばですが、A3報告書とセットベースで知識情報の循環させるシステムが出来るという仮説を立てたとして、この仮説が成り立つためには、前述したように報告書の質を上げることで知識情報の信頼度を上げる必要があると申し上げました。
では、一体、どのくらいの質になったら知識情報が思うように循環して開発効率が上がり、良い製品が出来るようになるのか、つまり仮説を成り立たせる条件というのが出てくるはずなのです。
条件は一つではないかもしれません。
すべての条件をクリアして、達成したい目標に到達するためには試行錯誤、つまりPDCAをしっかりと回していく必要もあります。
さらに、PDCAを回しながら条件を一つ一つクリアしていくときの時間感覚をどのように持つかということも重要です。
何か手法を導入すれば、形を真似ればすぐに成果が表れるわけでありません。
一つずつステップをクリアして、ある期間、活動を継続することで得たい成果に到達できるわけです。
そしてPDCAを回し、ステップを踏んで目標を目指すときに大事なのは、途中の状況を評価する方法を持っていることです。
感覚的な評価ではなく、できれば数値で評価することで、客観的で正しい評価によってPDCAを回すことができ、そのことが成功のために非常に重要だということです。
プロのアドバイスを受けるメリット
リーン製品開発、セットベース開発を正しく実践して成果を挙げるには、
- 戦略的アプローチ
- 現状の根本問題を把握する
- ゴールを明確に設定する
- 手法の本質的な意味を深く理解する
- 仮説・検証でPDCAを回して成果に到達する
ということをお話ししてきました。
言われてみれば当たり前のことばかりなのですが、では何故最初から出来ないかということが問題です。
この記事で説明してきたうまく行かないケースは、なぜ防げないかを考えてみてください。
実はトップマネージメント、中間マネージャー、現場まで、これまでのやり方、つまりまずは形を導入すること、手法を展開することが目的にすり替わってしまうことに問題意識を持っていない可能性があります。
個人というよりは、組織の思い込みは実はとてもたちが悪いのです。
この記事を読んで、内容に納得していただいたとしても、これを組織内で共有し、理解し、そして行動を変えるのは容易ではありません。
なので、改革の正しい進め方、考え方、戦略的アプローチを社内で実践するために我々のような組織改革のプロにお任せいただきたいと思っています。
今回説明した戦略的アプローチでリーン製品開発、セットベース開発を導入する手順を、弊社では「連鎖式組織改革法」と呼んで、クライアント企業といっしょに改革活動を続けています。
この改革法、ステップを学べるワークショップを提供しています。
そこで、リーン製品開発、セットベース開発の正しい進め方を習得し、社内に布教することが出来ます。
詳しくは下記を参照ください。
さて、リーン製品開発やセットベース開発を実践しているけども成果が挙がらないというお悩みは解決できそうでしょうか？
本記事の内容について、無料にて相談をお受けします。
下記の問い合わせフォームよりお問い合わせください。
この記事を気に入ってくれたら、下の”いいね”ボタンをお願いします！！
