製品開発プロセスをどうやって最適化し改革するか

製品開発プロセスはなぜ必要か？！

そもそも製品開発プロセスって何なのか？あるいは製品開発プロセスはなぜ必要なのか？必要だとしたらどうやって作ったらいいのか？あるいはどうやって最適化すべきなのかを知りたい。

製品開発コンサルティングの専門家として、製品開発プロセスをどんな手順で、どんな考え方で作っていくか、あるいは最適化していくかについて解説していきます。

本記事の内容

製品開発プロセスとは何か？という疑問から改革はスタートする

独自の製品を企画し、開発して生産準備をして、量産して販売する。

製造業ビジネスのやり方は、基本的に誰がやっても一本道であるはずですが、実際には企業ごとの競争力ははっきりと差がついています。

この差は、製品の魅力の差から生まれるのか、あるいは営業力の違いなのか、はたまた高品質でものを作る生産力の有無なのか、あるいはそれらを合わせた総合力の差なのか、色々と議論のあるところかもしれませんね。

製品開発プロセスも何か影響しているのだろうと、何となく予想はつくものの、そもそも製品開発プロセスとは何か？あるいはなぜ一本道であるやり方に独自のプロセスが必要なのか、ということを考えてみることにします。

製品開発プロセスとは

新しい製品について何か良いアイデアが浮かんで、それを具現化する方法を見つけ、商品化して量産し販売するという流れを、例えば数人のメンバーでやろうとすれば、全体の流れを考えながら一本道でやるべきことを進めるだけということになり、あえてプロセスということを言うまでもなく、やるべきことを順番にこなしていくことになります。

基本的には、製品開発のプロセスは一つしかないというのが出発点です。

では、製造業企業で開発プロセスとは何かというと、少人数から出発した活動が、継続して組織として製品を生み出すことに変遷していく中で、「組織ごとの役割と、組織ごとの仕事をどのように連携していくかを示す手順とルール」ということだと言えると思います。

大きな視点で、製品企画→製品開発→生産→販売という流れでみると、それぞれを担当する組織の役割と責任、次のステップに引き渡すタイミングと条件などが決められて、責任がバトン式に次のステップに渡されて、最終的に製品が顧客に届けられるようになります。これが広義の製品開発プロセスと言えます。

一方、製品開発という枠だけで見る場合には、製品企画からの要求、つまり製品仕様を受けて仕様通りの製品を作るための設計図、あるいはものづくりをするための情報を生み出すことが製品開発の役割となり、それを実行するための組織があって、組織ごとの役割や責任、作業手順やルールが規定されたものが狭義の製品開発プロセスということになります。

広義と狭義のどちらも製品開発プロセスと考えることが出来ます。

そして、繰り返しになりますが、製品開発プロセスというのは、「製品開発を組織的に、かつ継続的に行うために設定する組織活動の手順とルール」ということになるわけです。

さらに付け加えると、組織的な活動であることから、組織構造そのものも開発プロセスの一部ということが出来ます。

組織がそれぞれどんな役割や権限を持つかということ、さまざまな権限移行場面での決裁者や移行条件なども開発プロセスの一部となります。

そういう意味では、開発プロセスを作るということには組織設計ということも含んでいるのだと思います。

製品開発プロセスを規定する理由

少人数で一つの製品開発を進めるときには製品開発プロセスを作る必要はありません。

組織的に、そして継続的に製品開発をするから、製品開発プロセスを作るということは理解いただけたと思います。

では、もう少し細かく見ていくと、製品開発プロセスを規定する理由は、次の２つの側面から考えることができると思っています。

開発者の能力差を平準化する
組織全体の生産性を上げる

開発者の能力差を平準化する

同じようなことを言いますが、本当に優秀なメンバーが少人数のチームで製品開発を行えば、製品開発プロセスを規定する必要はありません。

やるべきことを全員が理解しているからです。

製品開発プロセスを作る一つ目の理由は、誰がやってもそこそこの製品が開発できるように、開発者の能力の差が結果に出ないように平準化するためということになります。

特に製品のシリーズ展開、マイナーチェンジなどで、製品ラインナップを拡充したいときなどは、全員が優秀ではないメンバーであってもある程度の質の製品開発を行いたいという企業側の要求があって、製品開発プロセスは重要になります。

組織全体の生産性を上げる

「開発プロセスをどうにかしたい」などという時は、こちらの狙いについての開発プロセスがターゲットになっていることが多いのだと思います。

組織が複雑化したり、製品システムが肥大化してくると、製品開発プロセスにほころびが出始めます。

「製品開発プロセス」に欠陥がある、あるいは「製品開発プロセス」がきちんと設計されていない、ということだと思います。

理想的な製品開発プロセスでは、組織そのものが無駄なく機能し、組織間の連携がスムーズで、出来上がる製品の品質も高く、また市場からの評価も高くなるような開発が常に出来るようになります。

最初の「組織そのものが無駄なく機能」という所は、組織を構成する人員の質の高さにも依存します。

逆にいうと、優れた製品開発プロセスは優秀な人材を生み出し、組織を強くすることが出来るものだということです。

組織間の連携、責任分担がうまく回り、製品の品質や顧客の評価などを監視し、必要に応じてフィードバックされて修正される手順やルールが明確になっています。

つまりは組織全体の生産性が高いということになり、人員や組織の力に合致した製品開発プロセスを規定することで、組織の生産性を最大化することが狙いとなります。

製品開発プロセスは改革し続けるもの

企業コンサルをやっていて、多くの製造業企業で、製品開発に関する問題が多発していて困っているように見受けられます。

代表的な例としては下記のような問題が挙げられます。

日程遅れが常態化している
品質問題が多発している
若手が伸び悩んでいる
仕様変更が多く手戻りが多発している

このような問題が起こる、あるいは継続して起こる原因は一つではないかもしれませんが、「製品開発プロセス」が不完全なものであるということもあると思われます。

理想的な「製品開発プロセス」は、組織の力、及び個人の能力とも繋がっているので、プロセス単独で作り上げるのではなく、組織の現状、個人能力の状況に合わせて、一緒に成長させていく必要があります。

つまり、「製品開発プロセス」は、継続して改革しながら作り上げていくものだと思います。

継続的に同じ問題を繰り返すようであれば、製品開発プロセスを改革すべきだというサインです。

誤解してはいけないのは、製品開発プロセスを形として捉えてしまうことです。

製品開発プロセスは、人と一緒に成長する生き物のように考えて、水をやり食料を与えながら育てていってください。

製品開発プロセスはどうやって改革するのか？

製品開発組織内で同じような問題が継続的に起きている。

「製品開発プロセス」が原因かもしれないと思ったら、そこからが改革のスタートです。

どんな手順で、どんなことをやるべきか解説します。

外の世界を知る

自社の「製品開発プロセス」に疑問をもったら、まずは外の世界を見てみましょう。

製造業で強い組織能力を持っている、あるいは持っていると言われている会社、例えばトヨタなどを研究しましょう。

弊社で推奨しているのは、トヨタのリーン製品開発手法に従った開発プロセス作りです。

トヨタ方式に関しては、生産系の情報が圧倒的に多いですが、最近では開発系の書籍や情報も増えつつあります。

Amazonで見る

成功している企業の製品開発プロセスを見るときに注意して欲しいのは、開発プロセスの形そのものを見るのではなく、どういう歴史的な背景でそのプロセスを構築したかということ、あるいは開発プロセスが出来るまでの紆余曲折や、プロセスを作り上げる途中でうまく行かなかったことなどを学んでほしいと思っています。

その理由は、例えばトヨタの開発方式で有名なチーフエンジニア制度ですが、これを真似しようとする会社はたくさんあるのですが、形だけを真似ようとしてほとんどの企業が真似することに失敗します。

アメリカのフォードですら、トヨタのチーフエンジニア制度を真似ようとして出来なかったという逸話もあるくらいです。

組織の形やプロセスそのものを成功企業から持ち込もうとしてもうまく行きません。

なぜそのプロセスになったのか、その本質的な理由、背景を理解して、その導入方法を真似ることが大事なのです。

また、開発プロセス改革と人の能力、組織の能力は同期しながら進めなくてはなりません。

プロセスや組織体制が実際の能力を超えていては、実行が伴わないプロセスになってしまいます。

参考記事：「トヨタ式リーン製品開発とは」

なぜ今のプロセスになっているのかを理解する

自社の現状の開発プロセスがなぜ今のようになっているか？

そういう疑問を持つことは、非常に重要なことです。

製品開発プロセスに関する一つの落とし穴は、現状のプロセスが正しいものという思い込みをしてしまうことです。

例えば、

製品企画部門から仕様書が開発部門に提示されると、開発部門は仕様を実現するためにフィージビリティ―・スタディー（実現性検討）を行って製品化構想をまとめます。

このとき、多くの企業の開発プロセスでは、与えられた仕様を実現するために複数の実現方式があったとすると、最も実現性の高い、あるいは製品としての価値が高まる方式を一つ選択して実現方式を決定します。

実現方式が決定すると、それに従って詳細設計を開始し、製品の試作機を完成させます。

この一連のやり方は、開発プロセスの一部であるのですが、このプロセスは決して唯一無二のプロセスではありません。

このやり方を当たり前と思うか、なんか他に方法がないかと考えるかが改革に対するマインドの大きな差になります。

早く製品全体の試作を作るというプロセスがなぜ採用されているのか？

全く新しい製品を開発するのなら、いきなり製品全体を作るのではなく、機能を実現する要素を一つ一つ確かめながら、サブユニットや部品の機能や性能を少しずつ作りこんでいく方法の方が優れていませんか？

なぜ、すぐに製品全体の試作機を早く作るのでしょうか？

類似機種を開発した経験があるから、前期種を参考にして作っちゃった方早いよね、ということならそれでも構わないのですが、本当にその方法が一番いいかどうかを疑ってみて、違う方法だとどうなるかを考えることが重要なのです。

また、組織構成として、一つの機種を開発するために関係者全員を集めて、一機種ごとに最適な布陣で開発を進めるやり方と、専門領域ごとに組織を作って、技術領域ごとの開発完成度を高めることを優先して、複数機種に出来るだけ共通技術を供給するような進め方とどちらがいいプロセスか、という議論もあります。

一つ一つの製品、一機種を個性を持たせながら最適開発をしていくという目的で開発プロセスを作るか、複数の機種を効率的に開発する、あるいは複数の機種に共通の技術を搭載することで一貫性を持たせることを目的にするか、という選択で開発プロセスが組まれていると考えることが出来ます。

現時点での自社の開発プロセスは、どんな理由で今のやり方を採用しているかを考えてみてください。

今の開発プロセスで得られるメリットと犠牲にしたもの

今の製品開発プロセスを採用している理由、目的がわかったら、次にその目的を達成するために犠牲にしてしまったことはないかを考えます。

事例で考えてみます。

既存事業で売り上げを拡大している企業にありがちなのは、既存事業の立ち上げ当初は、一つ一つの機種を丁寧に開発し販売するために、機種ごとに必要な開発者を集めて製品開発するプロセスを採用していましたが、事業が軌道に乗り、販売量が増えていくと製品のライフサイクルが短くなり、製品ラインナップの拡充が市場から要求されるようになって、一度にたくさんの機種開発をする必要に迫られます。

そうなると、効率的な製品開発が求められ、機種群ごとの開発を一度に行う考え方が採用され、そのために専門技術領域ごとに専門家が一か所に集められ、一人の専門家、開発者が複数の機種に関わるプロセスに変化していきます。

同じ領域の専門家を集めることで、それぞれの技術領域のレベルアップも図れるようになり、お客様から見たときに機種間でコンセプトの差がないので、一貫性を維持することが出来ます。

しかし、専門領域ごとの組織化で効率化を求めるプロセスで、一方で犠牲にしてしまったのは、機種ごとの個性と、一機種だけの開発を見たときの効率です。

同じ専門家同士のコミュニケーションが密になる代わりに、機種内の他の技術領域のメンバーとのコミュニケーションが疎かになる危険をはらんでいます。

一機種開発に必要なメンバーを集めて開発を行うと、開発者は他の専門家がどんな仕事をしていて、何に悩んでいて、どんな解決策を取ろうとしているかが、意識していなくても伝わってきて、そのことによって開発メンバーは機種開発全体に関する知識や知恵を何気なく吸収することができるのですが、専門家同士がつながることで、機種内の他の専門家が普段何をやっているかがわからなくなって、結果、機種全体のことに関する知識がつかなくなってしまいます。

専門領域の技術力を上げることで、製品全体の構成、動作原理、ユニットや部品間の繋がりなどに関する知識が組織から失われていくわけです。

そして、この犠牲にしたことが大問題に発展していくのですが、それは製品開発プロセスを変えることで、得られるメリットが出てくる時間と、犠牲にしてしまったことが症状として表れる時間に差があることで、問題認識が遅れることによって問題が大きくなってからしか問題が認識されないためなのです。

上述の例では、専門家集団を形成することによる開発効率はすぐに上がるのですが、製品全体の知識が着かないということは、それによって技術者のレベルが下がってしまうまでには、数年の時間がかかります。

多くの企業が、このような時間差での問題発生に悩んでいるのだと思っています。