製品開発プロセスにおける３つの重大な誤解

製品開発プロセスの改革が思うように進まない

ヒット商品がここ何年も生まれていない、同じような製品を開発しているのに同じような問題を繰り返している、日程遅れが常態化しているなど、問題はある程度わかっていて開発プロセスの改革は進めているつもりだ。どこが悪いのか、足りないことは何なのかを知りたい。

日米両国の複数の製造企業の開発現場を知り尽くした立場から、そのような疑問にお答えします。

製品開発プロセスにおける３つの重大な誤解

良かれと思ってやったことが、実は問題の真の原因である場合があります。

製品開発の現場で起きている問題に手を打つときに、製品開発プロセスに何か問題があると考えるならば、ぜひとも以下の３つのポイントについて見直してみて欲しいと思います。

• 早くモノ（試作機など）を作ることを求める
• 設計資産を流用することが大事と考える
• 専門分野を分割して分業することで効率化する

一つ一つのロジックが間違っているのではないかもしれませんが、実は盲目的にこれらを信じて進めることに大きな落とし穴があります。

早くモノ（試作機など）を作ることを求める

”四の五の言わずに作ってしまえ！！”

という言葉が聞こえてきそうですが、理屈を考えてるより作ってしまった方が早い！という考え方も確かにあります。

”考えるよりもまずやってみろ！”というのも場合によっては真理なのだと思います。

ただしここで立ち止まって、製品開発においてもこれが正しいかどうかを考えてみたいと思います。

似たような製品を繰り返し開発している場合でも、多くの製品の構造や動作原理はそれなりに複雑なものです。

同じような製品と言いながらも、新製品として新たな機能、新たなチャレンジが少なからず含まれています。

製品開発プロセスの中で、まず作ってみろとなった場合、作って試して色んなことを学習して、学習した知識を活かしてもう一度初めからやり直すということは、コスト的にも時間的にも無駄なことになるので、まず作ってみろと言って作ったものは、その後の開発のベース（基本設計）として活用されていきます。

つまり、とにかく作ったベース試作機を改良、改善する形で開発が進められます。

実は、このことが最も見逃されがちな大事なポイントで、間違いのスタートとなるのです。

このやり方は、とにかく泥船でもいいから形を作って、そこから継ぎ接ぎしながら、良い製品を目指して改造していくということなのです。

どんなに優秀な整形外科医でも、継ぎ接ぎには限界があります。

最初の試作機（泥船）の出来栄えが、実は最後の製品の質にまで絶対に影響を残してしまいます。

質の悪い試作機は、内部に品質問題のタネを隠しもったまま、問題個所は往々にして量産まで生き延びていきます。

これが、製品開発プロセスで早く試作機を作ってはいけない理由です。

試作機を早く作らないで成功している事例が、トヨタの製品開発手法です。

セットベース開発手法とも言われ、従来のとにかく早く方式を決めて一点突破でモノをつくる方法をポイントベースと言って明確に区別されています。

トヨタのリーン製品開発手法を日本で初めて紹介した稲垣公夫さんの本とタイトルが、「開発戦略は意思決定を遅らせろ」となっていて、早くモノ（試作機）を作ることに一石を投じています。

Amazonで見る

「わからないこと」、「未知のこと」、「チャレンジすること」を小さな単位（Minimum Viable Experimentation:実現可能な最小限の実験）で検証し学習していくことでイノベーションに到達する考え方に変えることが求められています。

設計資産を流用することが大事と考える

過去の設計資産を有効に使いなさい！！

これも上級マネージャーが言いそうなことで、しかも間違っていないように聞こえます。

私は、設計資産の再利用を無理に進めたことによって大失敗した会社を複数知っています。

失敗する理由は２つです。

• 再利用しようとする設計資産が、他で使えるレベルになっていない
• 再利用する技術者が、求められる仕様、品質と再利用する対象の品質を理解していない

性善説という言葉が適当かわかりませんが、ある機種で動いている設計成果物は、どんな機種や環境でも動くものだと思ってしまうのです。

最初の設計者が、自分の設計成果物があらゆる環境や機種で動くように設計して、かつ、あらゆる環境で動くことが検証されていれば100点満点。

少なくとも設計者が、あらゆる環境や機種で動くような配慮をして設計していれば70点（検証されていないから―30点）。

しかしながら、私が見て来た設計資産の再利用では、ある機種で動くことのみを想定して設計されたものを、そのまま他の機種で使おうとして失敗します。

これは、言われれば当たり前なのですが、上級職のマネージャーの中には、このあたりのバラつきに対する感度の低い方が結構いらっしゃいます。

再利用することありきで、開発プロセスが組まれるのです。

ちょっと頑張っているマネージャーでも、別機種でも使える設計になっているよな、と設計者にプレッシャーをかけますが、前述のように検証されてないので70点の状況です。

しかも、問題は単に設計資産の一部を入れ替えるという単純な問題ではなく、入れ替えようとする周辺の設計も大きく変わっている場合が多いのです。

モジュール設計を進めているから、という簡単な問題でもありません。

とにかく、理屈上でいえば、別機種で動いているものは、他でも使えるはずという建前を崩さないで結局大きな品質問題を発生させるのです。

さらに、そういう危険な状況であれば、本来は設計資産を引き継ぐ設計者が気づかなければならないのですが、ここで2番目の理由にあるように、再利用しようとする設計者が、このリスクに気が付かないのです。

もっと端的にいうと、モジュール単位で再利用を前提に開発プロセスが組まれているということは、そのモジュールは技術的に完成しているから、中身を見なくても大丈夫という大きな誤解がはびこること、そのモジュールは、良くわからないやつでも出来ると判断して、技術的に未熟な設計者が割り当てられること、などが背景にあって、現場で歯止めがかからないのです。

設計資産を再利用することを、「設計の結果をそのまま使うこと」という大きな誤解をしているのだと思います。

本来の設計資産の再利用は、「技術やノウハウを再利用する」ことでなければなりません。

設計結果（図面やソフトウェアのソースコード）を利用することから、「なぜこのような設計をしているかという背景、技術やノウハウ」を再利用する開発プロセスが必要です。

それが組織内の技術伝承となり、技術伝承によって若手が育ち、ベテランの技術が会社に残っていくことになります。

専門分野を分割して分業することで効率化する

同じような機種を複数、継続的に開発する場合に、開発効率を上げるために専門領域を細かく分けて、専門家集団を機能組織化して分業して開発するということを推進する会社が多くあります。

思想としては間違ってないと思うし、技術者として一本筋の通った専門を持つことも大事なことだと思います。

問題は、専門領域に没頭しすぎることで、他の分野、他のユニット/部品との連携に関する問題に対処できなくなることなのです。

専門領域内の問題はすぐに対応できるのに、品質問題が起きたときに、自分のユニットに問題があるかどうかだけを見ようとして、自分の担当領域に問題ないという証拠を取ったら、あとは自分の問題ではないと責任を排除してしまう技術者をたくさん見てきました。

複数のユニット間にまたがる問題、複合的に発生する問題、ユニット間の連携が設計通りになっていない問題などが、どの専門分野の問題とも特定できずに放置されていきます。

また、実際にこのような問題が起こったときに、問題解決に必要以上の時間がかかります。

製品開発には、アーキテクトと呼ばれる製品全体の構造や原理を深く理解し、各ユニット/部品がどのように連携して動作原理を成り立たせているかの全体設計を行い、また、その連携をマネージする人が絶対に必要です。

製品開発組織には、普通は何人かのアーキテクトと呼ばれる人がいます。

ちなみにトヨタには、このアーキテクトであり、さらに製品設計を超えて企画、販売、製造、サービス、購買にいたる全バリューチェーンをコントロールするチーフエンジニア（主査制度）という人がいますが、こういうスーパーマンまで行かなくても、技術開発、製品開発の全体をコントロールする人が、製品開発において重要な役割を果たします。

さて、専門分野に分割して分業することを良しとするのが、なぜ誤解かというと、製品開発中に起きる問題は、ユニットの内容だけではなく、むしろユニット間の連携、全体構成の中での動作原理に起因する問題の方が多いのです。

技術者に専門分野を持たせること、そして専門分野を会社として育てていくことは大事なのですが、それと同じか、あるいはそれ以上に全体構成での動作原理を理解し、機能配分することができるアーキテクトを育てることも製品開発組織としては重要です。

アーキテクトか専門家かというよりも、少なくとも、専門分野を担当しながら、他のユニットとのつながりに目を向けて責任を取れる専門分野エンジニアを育てる必要もあります。

専門分野を担当する機能組織の責任や意識を必要以上に強めてしまうことで、製品全体への帰属意識が低下し、また、全体の問題を見れない技術者が大多数を占めるようになってしまうということが実際に多くの会社で起きていると私はみています。

参考記事：　「リーン開発の理論と現実のギャップを学び実践する」

製品開発プロセス改革の本質的取り組み方

製品開発プロセスにおける３つの重大な誤解を見てきました。

いずれも、一つ一つの考え方が悪いのではなく、運用の過程で本質からずれていることが問題なのだと思っています。

製品開発プロセス改革を考えるとき、３つの誤解から以下のポイントを抑える必要があると思います。

これらは、製品開発の本質であると思っています。

そしてこの本質を取り戻すためには、プロセスそのものを変えるというより、一人一人の技術者がこの本質を体に刻み込むことだと思っています。

かつて、アメリカのEMS企業で開発部門（日本法人）の責任者をしていたときに、アメリカ本社の上司でIQ250という天才技術者と開発プロセスに関する話をしていたときに、彼が言ったのは以下のことでした。

「優秀なメンバー（Aプレイヤーと呼ぶことにします）だけがいる組織にはプロセスは不要なんだよ。Cプレイヤー、Dプレイヤーがいても一定の成果を出すためにプロセスというのは作るんだよ。」

私はショックを受けると同時に、強い納得感も感じました。

今回指摘した３つの誤解に関わる開発プロセスは、どれも技術者を信じていないというか、私の上司が言ったようにCプレイヤー、Dプレイヤーでも開発がそこそこ進められるように設定したものではないかということです。

だったら、本質的にやるべきことは、プロセスやルールで縛ることではなく、多くの技術者をAプレイヤーにすることではないかと考えるようになりました。

成功モデルで思想統一して、自社独自のモデルに変えていく

開発プロセスの見直しを考えて、開発プロセス改革を進めるために、おすすめの方法があります。

上記の製品開発の本質を捉えた事例としては、トヨタ式リーン製品開発手法があります。

• 未知のことを一歩ずつ詰めていく開発手法　→　セットベース開発
• 技術やノウハウを再利用する　→　A3報告書文化
• 製品全体の原理を理解する　→　チーフエンジニア制度

※リーン開発手法の概要は、「トヨタ式リーン製品開発とは」をご参照ください。

まさに、３つの誤解に応える模範的なモデルになりえます。

ただし、トヨタ式リーン開発として世の中に広まっているのは、実はアメリカの学者さんたちが、トヨタのやっていることを体系化した理論になっています。

なので、実践には、一工夫というか一苦労があるのだと思います。

リーン開発手法を理論として捉え、それによって社員の意識改革を行って、実践はあくまで自社の独自のモデルに変えていきます。

弊社は、リーン製品開発手法を理論として指導すること、及び、会社ごとの事情や制約の中で独自のプロセス、あるいは文化に変えて実践するノウハウを持っています。

製品開発プロセス改革あるいは意識改革を検討されているなら、ぜひ一度、弊社にご相談ください。下記フォームをご入力いただければ、こちらからコンタクトさせていただきます。

この記事を気に入ってくれたら、下の”いいね”ボタンをお願いします！！