第8回 イノベーションで突破する! 〜開発プロセスと開発組織を抜本的に革新〜

開発のあり方が変わる! RAPID革新とは?

革新を牽引する3つの要素 哲学・ビジョン・スタッフィング

抜本革新を成功させるためには、必須といわれるものがある。それは、明確なコンセプト(思想)だ。自社が“どういう将来を実現しようとしているのか”“どうなっていくのか”、誰から見てもわかるよう、方向性がはっきりと示されていなければならない。
さらに、抜本革新を支える3つの要素があると、塚松は解説する。「その要素の1つは、まず『哲学』。革新に堂々と胸を張って取組めるものが必要ですね。創業時から受け継いだもの、中興の祖が定めたものなど、その企業ならではのよりどころとなるものです。2つめは『ビジョン』です。ビジョン(夢)を持つということは、この革新によってプロセスが変わった結果、どういった製品を社会に提供できるようになるのか、その姿が見えているということです。どうしても実現したいビジョンが存在していることは、さまざまな困難を克服していくうえで、とても大切です。最後は、取組むことができる『スタッフィング』ですね。抜本革新を実現するために、きちんとリソースを割いてくれる体制があるということですね」この3つは、その企業が従前からもっている体質や風土とも関係がある。
こうした土壌のうえに抜本革新を断行できる人材がいて、初めて実現は可能になる。「当然、日常改善の継続も大切なことです。それを継続しつつ、抜本革新を実現するための人材を育成しなければならないでしょう。この人材は、長期的かつ広範囲にものごとを考えられる人物でなければなりません」(塚松)そのためには、人材教育にも見直しが必要な場合もあるかもしれない。「最近の若手社員に物足りなさを感じる経営陣も、少なくないでしょう。けれど、力不足を感じたとしても、人材は経験を積ませることで育成できるのです。抜本革新の実施とともに、それを今後実行し、現場を担っていく人材育成を行うことも忘れてはならないポイントです」(塚松)JMACは、人材育成という面においても各企業の事情と要望に合わせた幅広い提案を行っている。

研究開発プロセスを貫く思想 RAPIDによる3つのプロセス

現在企業がかかえている、研究開発分野での改善・革新の問題とはなんだろうか? 塚松は「ツールの導入、開発プロセスの革新、品質保証の仕組み化などといった個々の取組みがバラバラに行われていること」を取上げる。こうした個々に実施される数々の取組みは、導入や実施に労力がかかるわりには、期待した効果を得られないという現象が起きやすい。開発現場の革新を手がける際には、個々の取組みをバラバラに実施するのではなく、全体を貫くコンセプトを用意して、一貫した改善案を実行することが重要なのだ。
JMACでは、具体的な手段として『RAPID』という考え方を提唱している。「RAPIDとは、研究開発のプロセスをResearch(研究)、Advanced Platform(先行標準化)、Integrated Development(統合的開発)の3つにわけ、それぞれの頭文字を取って名付けたものです。この3つに含まれるプロセスは、本来研究開発の現場で当たり前に行っている過程です。しかし、それらを“意味合いの異なる3つのプロセス”として明確に意識・区別し、各プロセスで求められる成果に合わせた革新を同時に行っていく考え方です」(塚松)
「このようにプロセスを明確に切り分けることで、従来起きやすい問題を未然に防止し、効率的な研究開発が可能になる」と塚松は解説する。たとえば、技術開発と製品開発を1つのプロセスとしている現場では、製品化する際になって技術開発時点で解決すべきだった問題に対応しなくてはならない事例が起きる。技術開発を“何をもって完了とするか”、現場の担当者たちが把握できていないために、研究が足りないまま製品化に着手してしまったためだ。結果、製品開発をしながらモグラ叩きのように個々の問題に対処しなくてはならなくなる。

プロジェクト制からセル制へ! 少数の開発者で小回りの利く体制を作る

問題を防止し、効率的な開発を可能にする“意味合いの異なる3つのプロセス”の定義を、塚松はこう説明する。「Researchは研究。技術原理の発見・技術知識の創造・技術完成度の保証を行います。このプロセスは、後の工程に渡したときに技術的な問題が起きないようなレベルで完了となります。次のプロセスでうまくいかないとしたら、技術研究の完成度の低さが原因と考えていいでしょう。次のAdvanced Platformは、先行標準化と位置づけています。商品化をはじめる前に、技術、製品、業務それぞれのプラットフォーム(根幹部分)をあらかじめ決定し、標準化します。次のプロセスで、商品開発がうまくいかないとしたら、プラットフォームが適切ではなかった、と解釈しようということなのです」“前例をそのままプラットフォームとする”のは、よくある失敗例の1つだという。類似の商品開発を行う場合に、前の製品と同じ、または同様のプラットフォームを採用してしまうが、きちんと考えられていないので、効率の低下やトラブルにつながるというパターンは意外と多いのだ。
「3つめのIntegrated Developmentは、統合的開発です。少ないイタレーション・少ない人数での開発・少ないすりあわせによって、統合的な商品開発を行うのです」多くの企業で、開発チームはプロジェクト制を採用していることだろう。多数の開発担当者がおり、フェーズの変化によって人員は増やされる。それぞれの役割は細分化して分業し、矛盾が起きたときには調整によって解決を図るというやり方だ。だが、調整にたよると、どうしても意思決定に時間がかかってしまう。「たとえば、問題解決の決定をする際にも関係者全員の意見をまとめなければなりません。いろいろ話し合ったあげく、どう落とし所を見出せばいいか困ってしまうこともあります。みな狭い領域のみを担当しているためです。これに対して、RAPIDでは、セル体制を提案しています。少数の開発担当者で製品の一世代を担うという考え方です。1人が広い範囲を担当するので、矛盾が起きたときには、多くの人と調整するのではなく、必要な情報を得て少人数で意思決定ができます。意思決定者が少なければ、スピーディな開発が可能になる、ということです」(塚松)

ページ上部へ