たまに設計の責任者の方に「最近どうですか？」と尋ねると、直近の開発課題ではなく、数年前に開発した製品が円高の影響で儲かっているといった返事があります。設計部のミッションは測ることが難しいため、総合的に売れたかどうか、儲かったかどうかというのが評価基準になっているようです。会社規模で考えることができているともいえますが、丼勘定とも言えます。財務諸表から容易に読み取れる「売上」「利益」とは異なり、開発力の向上は把握しにくいものです。実際に、この3～4年で自社の開発力が向上していると自信を持つ技術者は全体の35％しかいないのが実情です。
製品の品質やコスト、開発期間や開発費用を指標にすれば、開発力はある程度把握できます。ここで注意すべきは、これらの指標は各製品の難易度に依存しているということです。開発費用に合わせて目標仕様を落としたり、スケジュールありきで簡単な焼き直し開発を行ってしまったりするケースをよく見かけます。これでは、目標を達成しながらも、開発力が衰えることすらあります。
このような状況に陥らないためには、「開発ロードマップ」を策定することが重要です。
開発ロードマップには、数年先までの開発モデルと主要な性能を書きます。時間軸と性能軸に開発モデルが描かれた文字通りの地図は開発力向上のシナリオとなります。
開発ロードマップを書きたいが、書けない、という悩みを聞くこともあります。数年先までの見通しを立てたいと思いながらも、何を根拠に、何を書いてよいのか、検討がつかないという悩みです。その原因は大きく分けて二つあります。一つ目は、仮に書いても“画に描いた餅”になりそうだから書かないというものです。二つ目は、ロードマップに書くべき主要な性能が抽出できない、というものです。つまり、顧客が製品を選んでくれる理由は多すぎて、平面の地図では書ききれない、という悩みです。一つ目の原因に対する対策は、実現できなかったとしても、目指すべき姿とのギャップが見えるように、とりあえず書いてみることをお勧めします。さらに、後述する方法で主要な性能が抽出できれば、それを実現する道筋も見えてくるようになります。
さて、ロードマップに書くべき主要な性能とプラットフォームとの関係は何でしょうか。これまで見てきたように、製品のプラットフォームには主要で普遍的な要件が含まれています。プラットフォームとオプションに分けることは、製品要件を普遍性が高いものと、それ以外に分けることのほかありません。タイムリーに市場にマッチさせるためのオプションは機敏に対応することが求められ、製品の中核となるプラットフォームには中長期的な計画が必要となります。プラットフォームの要件の中でも、時間的なロバスト性が低いものがでてきます。市場からの要求が漸増するような仕様がそれに当たるでしょう。例えば、エンジンの省エネ性や、デジカメの画素数、プリンタの解像度などです。この要件を軸にロードマップを書きます。製品間の細かな違いではなく、プラットフォームの進化が明確になるということは、そのまま製品ロードマップが明確になるということです（6月17日に大阪で開催する「ロバストプラットフォームセミナー」では、プラットフォーム構築のヒントをご提供します）。
※ 本連載に関連するプロセス改革施策にご興味のある方はこちらも合わせてご覧ください。
