いよいよ、営業、企画、設計を交えてのプラットフォーム会議が行われることになった。あなたは携帯ラジオの共通要件を一つひとつ説明し、それらを共通プラットフォームとして開発することを提案した。そして、予想通りオートサウンド機能がないことに対する不満にあなたは反論した。

「何もオートサウンド機能を一切売らないという訳ではありません。すべての製品には搭載しない、と言っているのです。」

すかさず、営業の同期はフォローしてくれた。

「競馬放送を聞くことを中心とするユーザーは、音質について追加費用を払うつもりはありません。むしろ電池の寿命には、追加費用を払ってもいいというデータがあります。」

もちろん、それには予想通りの反論が来た。

「しかし、その市場はコスト競争が激しいから利益率の高い、音質重視の市場を狙うのではなかったのか。」

あなたは、すかさずこう答えた。

「はい。両方狙います。」

 自分でもこのような言葉がためらいもなく、口から出てきたことに驚いた。勝算はあったが、不安もあった。ところが、言った後は妙に清々しい気持ちだ。

 設計者はとかくダントツ製品を作りたくなります。性能で競合を出し抜いた時の爽快感は代えがたいものがあるのではないでしょうか。このようなダントツ製品を開発するには、トレードオフの関係にある複数の性能間の調整をするだけでなく、技術的なブレークスルーが求められます。エンジンで言えば、燃費を下げながら大きな出力を出すことであり、パソコンであれば、より少ない消費電力で処理能力を上げることがブレークスルーです。プラットフォーム化が成功すると、製品ラインナップを増やすと同時に1製品当たりの開発コストが下がるという事業視点のブレークスルーが生まれます。

 単一製品のQCDだけを最適化するタコ壺から出て、製品ラインナップの利益を見渡してみましょう。そこに新しいブレークスルーが見えてきます。

 企画が通ったあとは、とにかくいろいろな設計者と議論を重ねた。まずは現行品の可視化だ。議論をするたびに、システム図には新たな線が増える。自分でもここまで複雑になっているとは知らなかったという発見の毎日である。

 現行の製品ですら、複雑すぎてシステム図が描けないことがあります。図面を描く前の“下書き”をしていないと、つぎはぎばかりのシステムができてしまうからです。

 現状を描いた後は、新システムを描くことにした。まずは、プラットフォーム要件を満たすべき構造を描き、周囲にラインナップを構成するための構造を描いた。各部署の設計者を一堂に集め、描いていった。新製品の構造を考えているというのに、不思議とスムーズに事が進んだ。ベースとなるシステム図があるので、描き加えたり、修正したりがしやすいのだ。おまけに、設計者は線を綺麗に描きたい習性があることが分かった。描くだけで、従来のモデルよりもすっきりとしたインターフェースになっていく。これなら、ロバスト性評価もいらないかもしれない。

 「見える化」は管理者や第三者のため、というイメージがあるかもしれません。でも実は、最大の効果は自分自身のためなのです。目をつぶったまま綺麗な字が書けないのと同じです。

 もちろん、システム図は第三者が確認することも重要です。特に複数製品を扱ったシステム図は色々な人と合意して完成させます。