空洞

Hearthstone(ハースストーン)の話など。雑記もあります。

干渉設計と独立設計に関して(ゲームに適用してみよう)

 
 
 

失敗しない設計は、干渉設計ではなく独立設計である。

 

要求機能(Functional Requirement)をすり合わせて設計する干渉設計では、要求機能が増えたときに調整ができなくなる。
公理とは証明しなくてもいい真理であるが、「要求機能が干渉せずに、互いに独立した設計の方が良い設計である」という“独立公理”と、「要求機能の成功率が高い(必要な情報量が少なくて済む)設計の方が良い設計である」という“情報公理”である。

要求機能(FR)と設計解(Design Parameter、DP)をベクトルで、それらの関係を設計行列で表した設計方程式の話は省こう。

・・・干渉設計の利点としては、車のようにボディ・サスペンション・タイヤの3つの設計解によって干渉しながら要求を満たすものには非常に有用で、容易には真似することができない。日本人の得意とするところである。半導体などは組み合わせ設計の典型例で、独立した各層やプロセスの設計を組み合わせて大規模なシステムを構築するが、コピーしやすく、日本がアメリカを真似したように、韓国や台湾に真似されてしまった。

話を戻すと、要求機能が増えた場合に、つっかえ棒が外れたように全体が崩壊してしまうのが干渉設計の欠点である。変化に対しての設計変更が失敗しやすいのだ。その点、独立設計であればコストダウンや新しいバージョンを出すときに圧倒的に失敗しにくいのである。

また、要求機能群については、極力FRの次数を減らすために一緒くたに列挙しないことは設計前の重要なポイントだ。できるだけ要求機能を整理してから、設計解の選定に取り掛かるべきである。

やるべきでないことは、“流用設計”である。手ごろな市販品を組み合わせたり、もったいないから遊休品を流用して、構造を仮決めして、その後に要求機能に合うように最適化する。この構造はもろく壊れやすい。基本的にはニーズを基にシーズを使うべきである。

このあたりの考え方はHearthstoneのデッキメイクにも適用できるのではないだろうか。

原理としてはこの程度にしておいて、ここからが難しいところだ。
機能や出来事を列挙した後、要求機能・設計解・効果の要素を分けないといけない。身近な例で説明すると「成績を上げる」は上位の要求機能で、「塾に通う」は設計解、「英語の成績が5になる」は効果である。

 

最も大きな要求機能は「対戦に勝つ」ということだ。その他はすべて副次的なものである。

 その他の副次的な要求機能は一体なんだろうか。それは「相手のライフを奪う」や「自分のライフを安全圏に保つ」にあたる。

 

 

続く

参考文献:続・失敗百選