本連載ではこれまで、自動車部品メーカーが抱える課題、開発マネジメントの実態を踏まえて、開発イノベーションを図る上での15の主要テーマについて述べてきました。開発現場のコンサルティング案件では、新規事業の立ち上げや次世代技術の開発を妨げるさまざまな問題が見受けられます。「“手戻りバタバタ開発” が改善されない」「本来かけるべき業務に工数が投入できていない」「忙しくて変革どころではない」といった問題を解決するポイントとして整理したのが15の主要テーマでした。
これらのどのテーマを重点として取り組むかは、企業の状況や改革の進展に応じて変わりますが、改革活動を推進する上ではテーマが何であってもベースとして押さえておくべき共通の指針があります。今回は、改革推進に向けて以下に示す7つの指針を解説し、連載を締めくくりたいと思います。
- 開発アセスメントでは「結果系」と「原因系」の両データをひもづける
- 開発工数削減には「効率」と「規模」の両面を見る
- 工数削減効果は先に刈り取らないと出ない
- 改革活動で最も重要なのは「定着化」
- 「2：6：2の法則」――改革は前向き2割をまず巻き込む
- 改革否定論者に対して、やむを得ない場合はしかるべき対策を講じる
- 「動員力」を持つキーパーソンを押さえる
それでは1つずつ解説していきます。
1. 開発アセスメントでは「結果系」と「原因系」の両データをひもづける
改革活動を始めるにあたり、開発部門の現状実態を調査・分析する開発アセスメントから入るケースが多いでしょう。その際、「結果系データ」と「原因系データ」の両方を組み合わせて見ることが重要です。
結果系データは、開発部門全体の開発効率（図1）や各製品の最終的なQCD（品質・コスト・納期）データ（図2）などが相当します。いわば、開発部門のダイレクトな成果を示すための指標がこれに分類されます。代表的な結果系データの概要は以下の通りです。
- 開発部門全体の開発効率（開発生産性）：ある期間における、各年度の開発部門全体の開発工数や開発人員数を開発テーマ数や開発規模で割った数値
- Q（品質）：SOP（量産開始）後に発生した品質問題数の計画（想定）および実績
- C（コスト）：SOPから数年たった時点までの開発費・製造原価の計画および実績
- D（リードタイム・納期）：開発期間全体（開発キックオフから量産開始まで、など）のリードタイムの計画および実績
もう一方の原因系データは、結果系データを生み出している原因に相当する、戦略検討面、業務推進面、組織運営面、仕組み整備面のあらゆるデータを指します。本連載の第3回で、日経BPとPwCコンサルティングが連携して実施した「開発マネジメント実態調査」の結果を解説しました。この調査で対象とした各種マネジメント水準（「開発戦略」3項目、「開発プラットフォーム」4項目、「開発推進力」2項目）が原因系データと呼ばれるものです。
この調査では、筆者らが定義する開発マネジメントのフレームワークを活用しており、同フレームワークは原因系の項目で構成しています。原因系データのカテゴリーに含まれるものとしては他にも、各開発フェーズで発生する不具合個数の計画（想定）／実績値や、工数・リードタイムの計画／実績値、開発現場で抱えている懸念点や問題点、課題などが挙げられます。
改革活動を始める際によくある失敗例として、現場の困り事を網羅的にヒアリングしたり、業務プロセスを書き出して問題点をプロットしたりし、そこから今後の目指す業務の姿を描き、改革テーマを導出する進め方があります。これでは、原因系データの一部を対象に分析するだけで改革テーマを導出していることになります。結果系データの分析がなく、結果系データと原因系データのひもづけも行われていません。そうなると、改革効果が「出たとこ勝負」、すなわち活動を進めてみないと改革効果が分からず、効果的・効率的な活動になっているか検証できない状況になってしまいがちです。
本来、開発業務の改革で狙う効果は結果系データのレベルアップ（開発効率化やQCD高度化）であり、その目標を達成するためには原因系データのどこに着目して何に取り組むべきか、といった手順で改革テーマを導出する必要があります。はじめに手段ありきの改革テーマ設定にならないよう、結果系データと原因系データを網羅的に調査・分析し、ひもづけることが改革成功の第一歩となります（図3）。
