破壊をデザインする、という発想

ついつい壊れないようにしようと考えてしまうものだけれど、もしかするとデザインするべきなのは「破壊」なのかもしれない。

すべての箇所を合理的に作り、つまり全体として最適な強さのバランスにデザインすることは、必ずしも正しくない。むしろ、通常はわざとバランスを崩し、弱い部分を設定しておくものだ。
　いろいろなレベルのものがある。少々方向性が違うが、たとえば、ヒューズは大電流が流れた場合に、その弱い部分で断線するようになっている。

http://blog.mf-davinci.com/mori_log/archives/2008/01/post_1664.php

これは僕が学生の時に研究室の教授から教わった考え方だ。
その先生は「破壊制御設計」と呼んでいた。
疲労破壊をご存知だろうか。大きな事故の裏にはこの疲労破壊が絡んでいるケースが多い。例えば日航機の墜落事故、比較的最近の事例でいえばジェットコースターの事故などがそうだ。疲労破壊というのは、微小な亀裂が徐々に進展していくことで破壊に至る現象を指すのだが、イヤラシイことにその亀裂はごく微小であり人の目には見分けが付かないのである。さて、この破壊にどう立ち向かうか。
疲労破壊には次の２つの重要な特徴がある。

• ひとたび亀裂が入れば、その亀裂が進展していく速度は比較的正確に予測が可能
• 最初に亀裂が入るタイミングは全く予測できない

そこで、次のような策がとられる。
構造材にあらかじめ切り欠き（キズ）をわざと付けておくのだ。こうすればそこに応力集中するから、亀裂は確実にそのキズの位置から発生するはずである。定期点検の際に集中的にその部位を検査すれば亀裂の発生を見逃すことがなく、亀裂の進展具合も管理することが可能なので、適切なタイミングで部品交換などの策を講じることが可能になるというわけだ。
まさに破壊という現象を「制御可能」にする設計と言える。

同様の考え方を、「ザ・ゴール」でも読んだ記憶がある。読んだのはずいぶん前だし、TOCに詳しいわけではないので記憶違いがあるかもしれないけれど・・・。

ザ・ゴール ― 企業の究極の目的とは何か

本書では、記憶が確かならば、工場の生産性を管理するのに「ボトルネック」を重視していた。管理するためにはボトルネックが「必要」なのだ。各工程の生産性を均一にしてしまうとどこを管理すればよいか分からなくなってしまうが、ボトルネックがあればその一点を集中的に監視することで全体の生産性を管理することが出来る、というカラクリだ。
これもあえて弱い箇所を作っておくことで全体を制御可能にしようという考え方だと思う。

研究室の教授はこう言っていた。
「医学を考えてみよう。医学が目指すべきは不老不死ではない。死なないようにしようという発想はナンセンスである。人は必ず死ぬ、という前提の下に、すべての人が天寿を全うできるようにするのが医学だ。」
「構造物の設計も同じだ。形あるものは必ず壊れる。絶対に壊れないようにしよう、という発想はナンセンスなのだ。壊れることは前提として、そのライフサイクルを管理可能にすることが大切なのだ。」

どうだろう、これらはとても面白い考え方ではないだろうか。
僕はとても面白い、と思う。

さて、僕はプログラマだ。この考え方は、僕の仕事にも応用できないものだろうか。

例えば、開発は大抵計画通りには行かない。たぶん、何が何でも計画通りにやれるようにしよう、という発想はナンセンスなのだ。そうではなく、「計画というのは必ず崩れる」という前提に立ったとき、僕たちは計画をどのようにデザインすべきなのか。
計画の「壊れ方」をデザインするという発想はどうだろうか。
つまり、あえて計画に弱い箇所を仕込んでおく。ここから計画が壊れるはず、という箇所を用意しておく。そして、そこを集中的に監視することで計画からのズレを管理できる、かもしれない。

例えば、ソフトウェアの設計はどうだろうか。まったくバグがないソフトウェアを開発しようというのはナンセンスだろう。バグは必ずある、という前提に立ったとき、どんなデザイン戦略が考えられるのか。

・・・妄想って、楽しい。