前回のコラムで解説したように、『システム図』を描くことによって、プラットフォームの姿およびプラットフォームがカバーする製品ラインナップが見えてきます。システム図に描かれたインタフェースは、プラットフォームの“輪郭”となります。この輪郭は、プラットフォームとそれを補う周辺のオプションの境目を表すことで、製品の構造を具体化させます。

　その後、内部を開発していく過程で、一度決めた輪郭が見直されることがあります。これが一つの製品であれば、この輪郭を修正しながら開発を進めたところで大きな問題とはなりません。ところが、複数製品のラインナップ開発となると、プラットフォームが共有されず、失敗に終わります。

　この失敗の原因はプラットフォームの“輪郭”、すなわちインタフェースを決める時の見通しの甘さです。「この仕様でも大丈夫だろう」「その国の情報はないから仕方がない」「とりあえず、ルールでしばろう」。このような考えでは、「使えない」プラットフォームとなってしまいます。

　かといって、100％の確証を持ってベストな仕様に仕上げることや、市場情報を完璧に収集することは現実的に不可能です。また、ルールでプラットフォームの活用を定めたところで、その時の市場ニーズに合致したものでなければ、かえって無駄なルールとなってしまいます。

　市場にはあいまいさや揺らぎは存在し、いかなる予測も不確実性をはらみます。このような不確実な環境のなかで役に立つのが「ロバスト性」という考えです。ロバスト設計とは、外乱や誤差は必ずあるものだ、という前提にたって、頑強なシステムをつくることを指します。

　前提が明確で誤差もない場合には、目標を無駄なく満たすような最適な設計が行われます。しかし、このような設計を行った場合には、実際に外乱や誤差が存在してしまうと、脆さが出てしまいます。例えば、部品メーカーが変わったり使用環境が変わったりすると、性能が劣化したり故障したりと、大きな影響がでることになります。

　これに対して、外乱や誤差に対して製品の振る舞いがあまり変化せず、影響が小さくなるように設計するのがロバスト設計です。野球に例えると、必要最小限の動きで内野ゴロを処理するのではなく、多少無駄があっても正面でゴロを捕らえ、イレギュラーに備えるのがロバスト設計とでも言えるでしょうか。現実の開発では、設定する目標や前提には曖昧さが含まれ、市場情報には不確実性があり、目標は開発途中で変わることがあります。ロバスト設計では、このような曖昧さや誤差、外乱に強く、鈍感な設計を目指します。とはいえ、ロバスト設計は無駄を奨励するものではなく、現実の不確実性を考慮して現実解を求めるものと捉えた方が良いでしょう。