イキイキR&Dでイノベーションを起こせ！

ある会社で開発部門の業務量調査を行ったところ、設計や実験といった設計業務が2割程度で、それ以外は、間接業務でした。また、業務の中を思考分析・情報収集・実作業・会議など分類したところ、思考分析が15％しかありませんでした。実作業や資料作成、会議の時間の方が思考分析より多いのです。

設計業務の実作業としては、CADの操作が最も多く、多くの開発者がCADオペレーターになってしまっています。
また、資料作成や会議は、デザインレビュー（DR）関連が最も多くを占めています。開発品質の向上のためには、DRは必要なものと言えますが、現実には時間の掛け過ぎと言えるようです。

思考分析以外の作業が多いとエンゲージメントやイキイキ度が下がる傾向があります。また、開発者の方々も「新しいことや新しい技術を考えることに多くの時間を使いたい」と訴えます。従って、開発部門の活力を取り戻すためには、こうした思考分析以外の作業を減らすことからまず始めなければいけません。

資料作成や会議が多くなる原因としては、開発工程の上流で製品の作り込みが弱く、下流でトラブルや課題が発生し、後追い作業としての資料作成や会議に割く時間が多くなることが挙げられます。そしてこのトラブル対応が上流での製品作り込みの工数を奪い、更にトラブルや課題が無くらないという悪魔のサイクルに陥っているのではないでしょうか。

問題には発見と解決があり、それらのタイミングは問題が発生する前と後があります。問題の発見と解決を事前にやるのが「予防的アプローチ」であり、事後にやるのが「対処的アプローチ」です。一般に、労力が掛かるのは対処的アプローチです。
予防的アプローチは、開発領域ではフロントローディングとも言われていますが、上手くいっている企業も少ないのではないでしょうか。

予防的アプローチを組織に根付かせるために、心理学者のゲイリー・クラインが提唱した「事前検視」を試すのも一つです。
事前検視は、プロジェクト開始時点で「このプロジェクトは失敗した」ということを前提にその原因（リスク）を議論していきます。「何故失敗したのか」「どうすればよかったのか」といったことを、オープンに話し合います。
日本人はリスクを言葉に出すことを非常に躊躇する「言霊文化」があります。しかし、リスクマネジメント観点からは、リスクは躊躇なく広く特定することが重要です。リスクを恐れず、この心の壁を壊してオープンに議論してはいかがでしょうか。

コンカレントエンニアリングといった言葉はありますが、実際出来ている会社は少ないのではないでしょうか。
商品企画、営業、開発、調達、生産、品証といった部門が、それぞれタコツボ化しサイロ化して、部門間に大きな見えない壁が存在するからです。

弊社のコンサルティングの現場でも、各部門同士の悪口を耳にすることがあります。「うちの会社の××は○○だから」「××は他の部門の話を聞かない」といったような言葉です。
さらに悪いことにこれを面と向かって言わないことです。文句があるなら、はっきり面と向かって言えばいいじゃないかと思いますが、表立って波は立てないのが日本的です。問題がありそうでも、自ら言わず、何かあれば他の部門の責任にできるように、用意周到に言い訳を用意しているケースも見受けられます。

イノベーションを起こすためには、各部門を跨いだ本当の知のバトルが必要ですから、この組織の壁を打破すべきです。しかし、社内だけでは、今までのしがらみやプライドなどが邪魔して中々進みません。
弊社では、外部の視点からあるべき姿を示して説得し、また、プロジェクト活動を通じた相互の連帯感を生み出すことによって、お客様と一緒にこの壁を壊していきます。

開発部門は、色々な知見と交流することにより、新しい知（イノベーション）を生み出すことが使命です。しかし、顧客と会ったことのない開発者、サプライヤーなどのパートナーと会ったことのない開発者なども多く見受けられ、外部との交流にも課題があるのではないでしょうか。

経営学に「情報の粘着性」という言葉があります。顧客や現場の価値のある情報は暗黙知が多く、そこに行かなければ得られないということです。
自分たちの製品がお客様の現場でどう活用されているのか、お客様の事業にどう貢献しているのかを実体験しなければ、市場が求めていることは掴めません。実はお客様は別の事を望んでいるけど、他に代替方法がないため、現在の製品を利用しているかもしれないのです。
また、自分たちが設計した部品が、サプライヤーでどう作られているのかを見たことのない開発者もいます。サプライヤーの生産現場では「こうすればもっとQCDが向上するのに、何故顧客の開発者は分からないのか」といった声も聞きます。

オープンイノベーションといった言葉で、異業種と交流する以前に、もっとお客様やパートナーと交流し現場にある粘着性のある情報を獲得すべきではないでしょうか。

開発企画、開発管理といった開発部隊に対する支援部門はありますが、オペレーション業務が中心になっているケースも見受けられます。

開発支援部門は、技術戦略を立て開発部隊と協働で技術開発や製品開発を進める役割（戦略家機能）と技術に関する知見・ノウハウ等の開発・蓄積や開発環境などのインフラ整備といった役割（専門家機能）が求められます。しかし、実際は予算管理や開発費処理などのオペレーションを中心とした役割（実務家機能）になってしまっていることが多いのではないでしょうか。

また、管理面や事務処理面から開発者に様々な提出物やドキュメントを要求し、開発者の間接作業を増やしているケースも見受けられます。開発者からは、開発を支援するというより、開発の足を引っ張ると見られていることさえあります。

しかし、開発部門の活力を向上させるためには、開発支援部門が積極的に改革の旗を振り、各種施策の立案と実行を進めていくことが重要です。従って、戦略家/専門家/実務家の観点から開発支援部門改革も同時に進める必要があります。

今回は、日本企業のR&D部門や開発部門の活力を奪っている「開発あるある症候群」をご紹介しました。各症状に対する処方箋の詳細については是非お問合せ下さい。
皆様と一緒に、活力のある開発部門への変革を推進し、イノベーションを実現したいと思っております。