2015年03月10日

Pages: 1 2 3

それから、先ほど加藤さん、「うまくやれたか、やれなかったか」という話をされましたけれども、過去を見て、うまくやれたか、やれなかったかというのは、ある程度定量的に評価することができます。被害がどれくらいあったかとか、それをどれくらいリカバーできたかということを、過去を見て言うことはできます。しかし、今のシステムが未来に向かってどの程度レジリエントかどうかということは別の問題なんですね。というのは、たまたまうまくいった話と、たまたま一生懸命やったのに運が悪いことが重なってだめに成ってしまったこと、というのがあるわけですね。

【加藤】だから、そこで「想定外」という言葉が出てくるんですね。

【丸山】そうですね。でも、その時に大事なのは、レジリエンスを考える上で、時間軸において、過去の特定の例がレジリエントであったかどうかという議論をするのと、このシステムが将来に向かって過去のシステムよりレジリエントかどうか議論するというのは、全く別の話であるということを理解しないといけないということです。同じシナリオが来たらレジリエントになるのを保障するというのは、システム全体がレジリエントになるということとあまり関係がないと言えます。全く同じシナリオは二度と起きないですよね。

【加藤】そうですよね、それが自然災害を相手にするということですよね。

【丸山】それでも自然災害は例えば台風など、ある程度似たパターンで来るので予測もできますし繰り返しもあるのですが、パンデミックとか、テロとか、そういうものが来た時に住宅を高いところに建ててることがその対策になるかというと、あまりなりそうにないですよね。

【加藤】今のお話うかがっていて思ったのが、例えば自然災害、例えばパンデミック、例えばテロ、という時に、今、丸山さんが考えておられるのは、それぞれに対してそれぞれのシステムを考えていくというお話なのでしょうか。それとももっと抽象化してどんな外因が来ても対応する、というような考え方なのでしょうか。

【丸山】最終的には何が来ても大丈夫なようにしたい、とは思うのですが、そういうことは多分難しいと思うんです。けれども少なくともそういう分類をしておくことは大事で、それぞれの脅威の種類に応じて、それぞれ違う戦略があるわけです。それを分類して整理しておきましょうということが大事です。そしてかつ、1つの時間軸を見てレジリエントであったかという議論とともに、将来についてはどう考えるか。過去のパフォーマンスに基づいてレジリエンスを考えることを、パフォーマンス・レジリエンスと呼んでいます。そして将来に向かってのレジリエンスをシステムの能力と考えるということを、コンピテンシー・レジリエンスと呼んでいます。パフォーマンス・レジリエンスとコンピテンシー・レジリエンスを分けて考えましょう、というのも大事なポイントだと思います。

【加藤】そうしますと、いわゆる世の中的に言うシステムの設計というのは、要件定義があって、仕様書を書いて、開発をして、実装をするというような段取りを踏むと思うのですが、今みたいなレジリエントなシステムを設計するにあたって、そのプロセスみたいなものというのはどういう風になっていくのでしょうか。

【丸山】良いポイントですね。少なくともレジリエンスを考えるようなシステムについて言えば、いわゆるウォーターフォール型の設計というのはあまりうまく働かないのだろうと思います。システムを設計してカットオーバーする間に、とっくに環境って変わってますよね。カットオーバーした途端にまた環境もどんどん変わりますよね。もしIT的なアナロジーで言うのであればデブオプス（DevOps）をずっとやっている。デブオプスという言葉はご存じですか？デベロップメントとオペレーションが常に不可分になってるという考え方で、GoogleとかAmazonってそうじゃないですか。毎日毎日新しい機能が追加されて古い機能が削られてということが起きているわけで、それはこの日がカットオーバーで、その日から同じ仕様でずっと走るというシステムでは全くないですよね。ですからデブオプスではウォーターフォール的なことはやりません。

それと同じようなことがレジリエンスを考えるようなシステム、社会の運営とか、会社の運営とか、あるいはコンピューターシステムの運用でも良いですけれども、デブオプスのような考え方が適用されると思います。それを「レジリエンス・サイクル」と考えています。

レジリエンス・サイクル

まず、こういうシステムを作ろうという、システムの設計フェイズがあります。そこでできることというのは色々あるわけですよね。例えばシステムを二重化しておきましょうというのは、設計フェイズの判断によって少しレジリエンスに貢献することができるわけですよね。

それから、普通の運用フェイズにできることというのも色々あるわけです。訓練しましょうとか、あるいはそのシステムがきちんと動いているか監査しましょう、とかです。そういうことは通常運用時にできることです。

それから、何か大きな災害が起きる前に予測できることというのがあります。早期警戒フェイズと言っていますが、典型的には大きな台風は大体72時間前にはいつ上陸するかということが相当正確にわかるわけです。そうすると事前に対策が取れます。パンデミックもそうですよね。国内で起きたら難しいですが、他で流行っているという情報があれば準備をすることができます。エボラや鳥インフルエンザというようなパンデミックは、早期警戒フェイズで防げているところもあるわけです。

それから次に検出フェイズというのがあります。典型的になものは、今回の東日本大震災の時に新幹線が全部止まりましたよね。それはディテクションがきちんと働いていたからで、検出と対策の間が2〜3分しかないだろうけれど、その間に対策がとれるタイプにおいては、このフェイズでの施策がすごく効くんですね。

その後で起きてしまった後は緊急対応のフェイズ。初動でどれくらい人が助かるかというのがあるわけです。最初の72時間くらいですね、自然災害の場合には。

それからその後で回復のフェイズがあります。システムが壊れたところを直すフェイズ。

その後、それと並行してかも知れませんがイノベーションというフェイズがあるわけです。元に戻るということ考えずに、これを機会としてもっと良いものにしようという動きが多くの場合現れています。1945年東京が焼け野原になって、今はもっと良い都市になっているわけですよね。
またそれから、最初の設計、プランとかデザインのフェイズに戻ってくるサイクルになっているという風に考えています。

Pages: 1 2 3