先日、iTiDコンサルティングが開催した「ロバストプラットフォームセミナー」を通じて、「プラットフォーム化」を検討している業界が実に多いことを改めて感じることができました。そして、プラットフォーム化の目的も非常に多くなっています。B2Cの製品では、グローバルで不確実な消費者ニーズに効率よく対応すること。ソフトウエアの比率が高い製品では、特別に再利用性の高さが課題です。素材に近いような製品においても、生産設備をうまく集約し、量産効果を出しつつ、多品種を生産できるような概念。そしてB2Bの部品や設備については、カスタマイゼーションを実現するためのプラットフォームが大きな課題になっています。

　そもそも、個別に、カスタムに、“カスタマー”に対応することがB2B製品です。これをマス化、つまり大量に、組織的に行えるようにすることが求められています。顧客からの短納期化やコストダウンの要求に応え、競争力を高めるためにプラットフォームは有効です。多くのB2Bの製品は、機能の数が少ない割に仕様が多く、微妙に異なる性能を顧客のニーズに応じて適合させるような設計が必要になります。『第4回・商品の因数分解とは？』で解説したような大きな括りでの要件ではなく、仕様値などまで細かくばらした「要件ばらし」を行うことで、プラットフォーム化する範囲が見えてくるようになります。

　しかし、難しいのはこの先です。機能単位でオプション化するような設計は想像しやすいのですが、性能を変化させるオプションというのは、ピンときません。ここで思い出して頂きたいと思います。既に微妙に異なる仕様や性能の製品が数多く生まれているわけですから、これらの製品を分解してみればいいのです。分解すると言っても、概略の構造が分かるような『システム図』を描きます。

簡易カメラのシステム図

　プラットフォーム化したい製品に関する一つの『システム図』を描くことで、個別対応する部分といつも変わらない部分が見えてきます。その間にインタフェースを定義できれば、オプションとの組み合わせによってさまざまな顧客のニーズに対応できるような構造に変えることが可能となります。「特注」対応するとしても、オプション部分だけの開発になるため、大幅に工数・納期が削減できます。

　さて、少し話が飛びますが、「開発リスク管理」はiTiDコンサルティングが支援するテーマとして常に人気の上位にあります。「開発リスク管理」においては、実際に問題が出てから対応するのではなく、未然にリスクを挙げることがポイントになります。問題が出てから“モグラたたき”を行っていたのでは、つぎはぎの設計になってしまうだけでなく、修正にコストもかかります。

　出てもいない問題を未然に挙げることが可能なのか？という疑問を持つ読者もいるかもしれません。しかし、過去に発生した問題を思い返すと分かると思いますが、大半は古い問題の焼き直しです。新しい問題の多くも、過去の知見からのアナロジーで挙げることができます。それでも挙げると、残るリスクは、「何だか分からないリスク」となります。このようにリスクを挙げていくことではじめて、未然に対処することができるようになります。余談ですが、「何だかわからないリスク」の対処法は「リスクがあるかどうか調べる」という漠然としたものになりますが、優先して調べ、より細かく対応できるようなリスクへと進化させることが重要です。

　「開発リスク管理」同様に、エンジニアが「特注対応」の“モグラたたき”に忙殺されているとしたら、それは後々来る顧客の要望を事前に考慮していていない可能性が高いです。本当に「思いもよらない」要望というのは案外少ないものです。過去の経験を整理すれば、カスタマイズのポイントは集約していけます。また、最初から100点を目指さなくても、当初50％が特注だった製品群が80％までカバーできるようになれば、大幅な改善です。筆者も以前NASAから突然“宇宙対応”要求が来て驚いたことがありましたが、そういう思いもよらないようなクリエイティブな仕事が飛び込んでくること自体は、歓迎してもいいのではないでしょうか。それに対応できる余力を持つことで、次の大きなブレークスルーが生まれることでしょう。

※　本連載に関連するプロセス改革施策にご興味のある方はこちらも合わせてご覧ください。