« うどん | トップページ | アンバランス »

2007年8月 1日 (水)

System Dynamics(その8)

20070731_1sdloop 以前テレビのある番組でコメンテイターが「最近は技術が発達しているからシミュレーションで事前に何でもわかっちゃうんじゃないの?なのにロケットとか、飛行機とか、車とか(ちゃんと使っているのに設計が元と思われる)事故が何度も起こるのはおかしいよねぇ。」と述べていて、びっくりした覚えがある。

説明するまでもなく、実世界ありのままをシミュレーションするのは不可能なので、特定のケースにフィットするように単純化したモデルを計算に用いるわけで当然使える状況に制限があるし、誤差も必ずある。優れたモデルは数多くの実験データを集めて、多くのケースに小さい誤差でフィットするように工夫してあるわけだ。

なので、システムダイナミクスのシミュレーションモデルを組んで、それが定量的にどれほど現実とフィットするかを実データ無しに議論しても始まらない。定性的な傾向を判断するためならともかく、数字をはっきりさせたければ実際に類似のシステムを運用するなり、実験するなり、現象を観測するなり、なんなりしてデータを集めて自分が作ったモデルに反映させる必要がある。そうやって初めて未知のケースを予測するシミュレーションができるわけだ。

端的に言うと、論理が正しいかどうかを判断するにはそれをサポートするだけの根拠が必要なわけで、その根拠がどれだけ自分が対象とするケースで有効かつ信頼性があるかを吟味する必要がある。

ある程度の経験があるエンジニアの人には読んでもらうのが申し訳ないくらい当たり前の事を書いてしまったけれど、System Dynamicsはエンジニアでない人にも、算数の知識さえあれば(微分積分の定義だけでも知っていればかなり楽になるが)使いこなせるし、意図せずとも古典制御で出来ることは全て出来てしまう。
なので、下手をすると上の図の赤い線で描かれている部分にのみ注目された結果、残りがおろそかにされてしまっているにもかかわらず「使えない!」という判断をされるのは心苦しいので敢えて紹介した。

 

さて、かなり前置きが長くなったけれど実際にモデルを組むときに大事なことをは何だろうか。
もちろん自分が挙動を知りたいパラメータを中心にして、何が影響するかをどんどん膨らませていくのだけれど、ある程度数が増えてきたときに僕が考えることはいくつかある。
第一には、どこにどういうループがあるかと言うこと。ループが全く見つけ出せない場合はどこかに抜けや漏れがあると考えて良い。なぜなら全ての要素が右から左に影響を伝えていっておしまい、というシステムはあり得ないからだ。もしそういうモデルができあがった場合はビア・ゲームのように周りが見えていないと考えた方が良いだろう。"Causal loop Diagram"と名前が付いているだけのことはあるのだ。
もちろん定数で定義される要素や、今週の平均気温のように自分が影響を与えられない要素があることも確かだけれど、たいていの場合はある要素が取った変化に対して他の要素が反応し、それがさらに元の要素へと影響を与えるループができあがる。そしてこのループこそがシステムのダイナミクスを理解する鍵になると考えている。モデルが無数の線でごちゃごちゃになってしまったときは是非ともこのループとインプットもしくはアウトプットのない浮いた要素に注目して考え直して欲しい。

そしてもう一つ大事なのは、論理に飛躍が無いかどうかだ。これは少しテクニックを知っておく必要もあるけれども、いわゆる「なぜなぜ分析」とか「5W」を知っている人には問題なく行えると思う。
20070731_2teibo どういう事かというと、以前紹介したミシシッピ川の堤防の高さ競争の例を思い出して欲しい。「自分の堤防を増築する」のは「他人の堤防が高い」から、というのは一見理にかなっているように見えるけれども直接関連づけてしまっては問題がある。
何故なら「他人の堤防が高い」事によってまず始めに影響を受けるのは「自分が満足できる堤防の高さ」である。そして「自分の堤防の高さ」と「自分が満足できる堤防の高さ」を比べて初めて「自分の堤防を増築する」からだ(自分が洪水被害を被るリスク、増築コストや期間、効果など、自分の考えを入れてもらえば良い、唯一の正解は無い)。始めよりもずっと高さ競争のダイナミクスが明確に表せていることが解ってもらえるだろうか。

その他、要素の単位に気をつけるだとか、要素名には動詞でなく名詞を使うとか細かい点はいくつかあるけれども、習うより慣れよである。

最後に、どうやったら重要な要素が漏れなく見つけ出せて、要素間の関連付けが綺麗に出来て、ループの影響が予想できるかについて。
実はそんな上手い方法はハッキリ言って無い。一番の方法は冗談ではなくそのシステムのことをよく知っている人に話しを聞くなり自分の作ったモデルを元に相談することである。いろんな立場の人と話が出来ればもちろんその方が望ましい。オブジェクト指向言語のように優れたパターンはテクニックとしてあるとしても、システムのアーキテクチャーを理解して綺麗にモデル化するには、経験とセンスが問われる事は悲しいかな事実なのだ。

 

System DynamicsのようなSEの手法は、実世界で培った経験があってこそだ。
もちろん属人的に埋もれている経験を他の人にも共有できる形で表すこと(暗黙知から形式知へ)、時には自分もどういう考え方をしていたのかを整理できるのがSEの力であり魅力である。

« うどん | トップページ | アンバランス »

コメント

コメントを書く

(ウェブ上には掲載しません)

トラックバック

この記事のトラックバックURL:
http://app.f.cocolog-nifty.com/t/trackback/176692/7376322

この記事へのトラックバック一覧です: System Dynamics(その8):

« うどん | トップページ | アンバランス »