システム思考とSTAMP

世の中のいろいろなモノやコトを「システム」として考えることと、その道具の一つであるSTAMP/STPAについて。

「創発性」について

創発性とは

wikipedia では、次のように説明されている。

創発(そうはつ、英語:emergence)とは、部分の性質の単純な総和にとどまらない性質が、全体として現れることである。局所的な複数の相互作用が複雑に組織化することで、個別の要素の振る舞いからは予測できないような系が構成される。

「全体は、部分の総和以上である」とは、よく言われることである。例えば企業にいると、「1足す1」が「2以上」にならなければ組織としての意味がない、という話は社長などからの訓示でよく聞く。「相乗効果」という言葉も同じ文脈でよく使われる。

プロ野球の読売ジャイアンツの監督をしていた原辰徳さんは、「『読売個人軍』であってはならない」という話をよくしていた。個人の能力を単に足し合わせただけでは「チーム力」にならないという意味であろう。

 

これらの例を見ても、「創発性」とは日常生活でよく接するような、ごく普通の概念であることが分かる。

むしろ、「ごく普通の概念」というより、「あらゆることに通じる概念である」というべきであり、従って、「創発性」について理解し、常に意識しておくことは、この世界で起きる事象に対処する上で役立つといえる。

「創発性」はなぜ重要か

上に書いた例は、「システム全体としての良い性質」が創発される例であった。しかし、システムに創発される性質について「良い/悪い」と感じるのは人間の主観に過ぎないのであって、「創発性」という概念は良い/悪いの価値観は含まない。「システムの要素が相互作用すれば、要素の性質の単純な総和にとどまらない性質が全体として現れてしまう」というだけである。

例えば「台風」は、人間社会に大きな損害を与え得る「全体としての性質」を持つ。その性質を生み出す「部分(要素)」は空気分子である。密な状態から疎な状態に移行しようとする空気分子の「部分の性質」が集まると、台風という「全体としての性質」が生まれてしまう。

 

"「創発性」について”という論文(※1)には、次のようなことが記されている。

創発的理論とは、

全体に特徴的な振る舞いは,その構成要素がバラバラにあるとき,あるいはそれらが他の結合状態にあるときの,それら要素の振舞いについての最も完全な知識 most complete knowledgeが与えられたとしても,またこの全体におけるそれら要素の比率や配置についての最も完全な知識が与えられたとしても,たとえ理論上でさえ,そこからは演繹されえない。(Broad,p.59)

と主張するものである。

ここでは、「創発性」を理解する上で非常に重要なポイントが示されている。

それは、「システムを構成する要素についてどれだけ完全な知識があったとしても、そこから、システム全体の性質を演繹的に予測することは不可能である」ということである。

 

システムの構成要素を注意深く観察し、そこから、全体に起こり得る性質を思いつく/気が付くということはあり得る。しかし、「演繹されえない」ということは、全体に起こり得る全ての性質を解析的に導出することはできない、ということである。

 

これがなぜ「重要なポイント」かというと、このことを「できるはずだ」と考えている人が実は多いと思われるからである。それを感じる典型的な場面は、なんらかの「想定外の事故」が起きたとき、その原因が分析されると、「そんなことは設計段階で当然分かるはずだろう。それを怠ったのは開発者に責任がある。人災だ。」という声が上がるような場面である。

想定外の事故(すなわち、システム全体の創発性)が分かったあとで、それに繋がる要素の相互作用が分析されれば、その因果関係は明確になる。そうすると「それは当然分かるはずだ」と感じる。しかし、その逆方向の分析(要素の性質から事故を予測すること)は、必ずしも容易ではないのだ。

 

このようなことは、「事故」以外のことにもいえる。

例えば、企業が新製品の企画を考えるとき、想定顧客、競合製品、市場動向などを洗い出して分析を行うであろう。それはもちろん必要なことではある。しかし、そういった分析の積み上げのみによって必ず「売れる」製品が見極められるということはない。誰か個人の「突然のヒラメキ」のようなものが実は正しい場合もある。そのようなアイデアを「客観的な裏付けがない」「役員に説明しにくい」などといって切り捨てるとしたら、それはもったいないかもしれない。

 

「ロジカルシンキング」は必要ではあるが、それだけで「良い結果」を得られるわけではない。上記のような「ヒラメキ」を上手く導き出そうとするのが「デザイン思考」であるという見方ができる。

昨今の「説明責任」や「透明性」を重視する風潮は、「ロジカルに正しいこと」を偏重しすぎているのではないか。「創発性」に関する理解は、それを補正することに役立つと思われる。

なお、「創発性」に関する理解は、システムの「階層」、および、階層間の「コントロール」との関係についての理解も必要となる。(以下の記事を参照。)

システムの「階層」について - システム思考とSTAMP 

STAMPで考える「モノづくり・コトづくり」の本質 - システム思考とSTAMP

 

おまけ(その1)

STAMPでは、事故は創発性である、とする。つまり、システムの要素を分析しても「起こり得る事故」を演繹的に導き出すことはできない。したがって、「気づき」が必要になる。その「気づき」を上手く引き出し、その過程を記録する工夫が凝らされているのがSTAMP/STPAであるという言い方ができる。

おまけ(その2)

ところで、「人生」も創発性だと感じられる。「自分」の周囲の環境、これまでの経験、出会った人々、それらの「要素」が相互作用して「私の人生」ができている。

「良い人生」を送りたい。しかし、どうすると「良い人生」になるのか。「要素」は、偶然もあるが自分で選択できるものもある。ただ、「要素」から分析しても答はたぶん出てこない。じゃあ、どうすればいいのだろうか。そんなことも、「創発性」の教えから、ぼんやりと考えさせられる。

 

参考文献:

※1:「創発性について」,松本俊吉, 科学基礎論研究 28巻 2号, 2001 

 

 

 

 

 

「システム思考」とは何か

「システム」とは何か では、「システム」という概念の定義を示した。

「システム思考」とは、端的に言えば、対象物を「システム」として捉えて考えることである。

「世界はシステムで動く」(※1)では、次のように記している。

あらゆるものを「システム」として考え、分析するのが「システム思考」です。

 

また、GLOBISでは「システム思考」を次のように説明している。

システム思考とは、目の前の問題や出来事を単独で考えるのではなく、それらがどのようにつながり合い、影響し合っているかに注目する思考方法です。

 

システムを構成する要素が「どのようにつながり合い、影響し合っているか」を見るには、どのように心がければ良いのだろうか?

慶應大学の白坂成功教授は、「システム思考の重要性について考える」(※2)の中で次のように述べている。

基本はすごく単純で、俯瞰的に考える、全体として捉えるということです。
私は三つの軸で俯瞰するようにしています。一つ目は空間の俯瞰です。この範囲
で見ましょうという空間俯瞰。二つ目は時間俯瞰終わりのことまでを考えて、
今どうするかを考える。三つ目は意味俯瞰です。これを目的として、このために
どのようにやっていくかという俯瞰。この三つの俯瞰を進めるのがシステム思考
だと考えています。

 

システム思考を具体例で考える

システム思考の具体的で身近な適用例としては、ルービックキューブが分かりやすいと思う。(※3)

ルービックキューブは、6つの面についてそれぞれ色を揃えていくパズルだ。26個の小さいキューブを、3本の直交する軸を中心に回転させ、色を揃えていく。あるキューブを目的の位置まで移動させようとすると、他のキューブも一緒に移動してしまう。したがって、「まず青の面を揃え、次に赤の面を揃え、・・・」という具合に順番に色を揃えていこうとしてもうまくいかない。

上で引用した「システム思考」の説明を見てみる。「目の前の問題や出来事を単独で考えるのではなく、それらがどのようにつながり合い、影響し合っているかに注目する」のである。各面を単独で考え、一つずつ順番にやっていこうとする考え方ではうまくいかない。各キューブや面が「どのようにつながり合い、影響し合っているか」を考える必要がある。

これはまさしく「システム思考」である。

 

他の例としては、例えば「旅行の計画」がある。旅行を計画するとき、何を決めるだろうか?

  • いつ行くか
  • 何日間行くか
  • 誰と行くか
  • どの地域に行くか
  • どこを回り何をするか
  • どこに泊まるか
  • 移動手段は何にするか
  • 予算はいくらにするか
  • 何を持っていくか

ざっと考えてもこれくらいのことを決めるであろう。

これらを決めていくとき、各項目について「単独で考えて一つずつ決めていく」であろうか?そんなやり方ではうまくいかないはずである。上に挙げた項目は、それぞれが相互に関連する。一つを決めると他に影響する。全体を「俯瞰的」に考えないと決まらないはずである。

「いつ行くか」「何日間行くか」「何を持っていくか」などは、時間的俯瞰が必要であり、「どこに行くか」「どこに泊まるか」「移動手段は何にするか」は空間的俯瞰が必要であり、「誰と行くか」「どこで何をするか」などは意味的俯瞰に相当すると言えそうだ。

 

システム思考が必要ない例

システム思考が必要ない例もある。

例えば、公園の雑草を取る仕事を考えてみる。

一度では全部の草取りができない場合に、上の絵のようにいくつかの区域に分割して、各区域を順番に草取りしていくことはよく行われる。

この場合、例えば左上の区域について草取りを行っているときは、他の区域のことは考えないであろう。「目の前の問題や出来事を単独で考える」ことをしているのである。つまり「システム思考」をしていない。

それでなぜ、問題ないのだろうか?

それは、区域の間に相互作用がないためである。例えば、「左上の区域の草取りをすると右下の区域に新たに草が生える」などという相互の関係は存在しない。各区域の草取りは、独立に考えることができる。

このようなタイプの問題は、「問題を分割し、分割された小問題のそれぞれについて個別に対処していく」というやり方を適用することができる。

逆に言えば、「このようなタイプの問題」以外の問題は、分割して個別に対処していくやり方は適していない。無理やりそのようなやり方を適用すれば必ず失敗する。これは、上に書いたルービックキューブや旅行計画の例を見れば明らかである。

 

「システム思考」はなぜ必要か?

システム思考の例としてルービックキューブや旅行の計画を挙げた。このようなことなら、日常生活でごく普通に行っていることである。なぜ、ことさら「システム思考」などと名付けて注目する必要があるのか。

それは、次のように考えられる。

 

上に挙げた「草取り」の問題を改めて見てみると、これは実に分かりやすい。左上の区域の草取りが終われば、「全体の25%が完了した」とハッキリと言える。「あと、その3倍の労力を費やせば全体の草取りが完了する」という見通しも確実に立つ。この性質は、「マネジメント」を行う上で非常に都合が良い。マネジメントとは、作業者を監督する立場の人が行う場合と、作業者自身が自らに対してセルフマネジメントを行う場合との双方を含む。

しかしながら、現実の問題は「ルービックキューブ」のような問題が多い。上の写真の左側のような状態を見て、これが右側写真の「ゴール」に対して何%の状態であるかなど、誰も分かりようがない。それは当然だし、誰もが分かっているはずなのだが、「数値管理」が必要とされる場面は多々ある。「企業」では費用をかけて作業を行うため、特に「数値管理」の要求は高い。

そのような場合に、ルービックキューブ」タイプの問題を、なんとかして「草取り」タイプの問題と同様に扱いたくなるのである。

 

例えば、ある社員が仕事として、ソフトウェア開発のある品質を高めるためのノウハウを考え、「ガイド」を作ったとする。その社員の上司は、その仕事の価値を金額で示してアピールしたいと考える。そこで、「ソフトウェアの売上額に対してそのガイドが貢献した割合を示せ」とその社員に要求する。それが分かれば、ガイドを適用したソフトウェアの売上額に掛け合わせれば、「評価額」が算出できるわけである。

しかし、「品質」には様々な面があり、それらが相互に関わりあってソフトウェア全体の「価値」になるものである。それが商談の成否や価格に影響し、結果的に「売上」になる。「草取り」の問題のように、

品質A+品質B+品質C+・・・=全体品質

という関係ではないのであって、敢えて数式で言うなら「掛け算」の関係である。

その社員は、上司からそんなことを訊かれても、答えようがないのである。

 

現実世界の問題の多くが「ルービックキューブ」タイプであるにも関わらず、「草取り」タイプの問題として扱おうとするケースは多いだろう。そこでは、無理なことをしているため、どうしても不幸なことが起きがちだ。

世界を正しく捉え、正しく対処し、無理・無駄・不幸をなくすためにも、「システム思考」というものを常に意識しておくことが必要なのだと言える。

 

おまけ:「エンジニアリング」の落とし穴

上のルービックキューブの写真で、左側の状態が右側の「ゴール」に対して何%の状態かは誰も分からない、と書いた。

しかし、ルービックキューブのエキスパートは存在し、どのような状態からでもゴールに達することができる。そのようなエキスパートは、「どうすればゴールに到達できるか」のノウハウを持っており、写真の左側の状態から、どのようなステップで各面を揃えられるかの筋道が見える。

このように、ある特定の種類の問題について分析を深めていけば、それを解決するノウハウが確立されることは多い。「エンジニアリング」とは、そのようにして確立されたものに相当する、と言ってよいであろう。

 

いったんそのような「エンジニアリング」ができると、それを他者に伝えることで、初心者をエキスパートに育てることが可能になる。このことは、ルービックキューブを例に考えても容易に想像がつく。

かように「エンジニアリング」は有難いものである。「エンジニアリングがあるのだから、これを活用して人材育成し、競争力を高めよう」というようなことを企業ではよく言う。

これは正しいのだが、落とし穴がある。ルービックキューブのようなパズルは、もともと、「このような手順で進めれば解決する」という筋道が見えないものである。それを何度も試行錯誤し、なんとかして編み出したものが「エキスパートのノウハウ」すなわち「エンジニアリング」である。

もともと「筋道が見えない」タイプの問題なので、少し問題にアレンジが加わると、既知のノウハウが通用しなくなることは大いにある。にも関わらず、「エンジニアリングがあるのだから…」と、エンジニアリングへの依存が強すぎると落とし穴にはまる。対象の問題の性質が少し変わった場合に「なぜ、うまくいかないんだろう?」となる。

 

もともとの問題の性質を考えれば、「確立されたノウハウ」が使えない場合が多くあるのは当然であって、「なぜなんだ。こんなはずではないのに」と狼狽える必要はない。

「エンジニアリング」は、適用する対象が変わらなければ有効である。しかし、対象の性質が変わればそうはいかない(例えば、機械学習モデルを含むソフトウェアの開発には従来のソフトウエア工学がうまくハマらないように)。テーラリングが常に可能とは限らない。エンジニアリングは、上手く使えたらラッキー、ぐらいに捉えておくのがよい。

 

 

 

「システム」とは何か(その3)

前回は、前々回の記事で整理した「システム」の定義に基づいて、身の回りにあるもの(机)をシステムとして捉えることができることを示した。今回はその続き。

身の回りのシステム(2)

およそシステムらしく見えない例として、ペットボトルを取り上げる。ペットボトルもシステムとして考えることができる。

ペットボトルは便利だ。もしもペットボトルがなかったら、飲料の運搬や保存は今頃どのようにしていただろうか?

ペットボトルの「全体としての性質」を考えてみる。

液体や気体を漏らさない気密性を有し、簡単に破損や変形をしない強度と剛性を有する。これらの性質のおかげで、私たちの生活はずいぶん助けられている。

このような「システム全体の性質」は、どのような「要素」と「要素同士の相互作用」によって創発されているのだろうか?

ペットボトルは、PET(ポリエチレンテレフタレート)という高分子でできている。

PETは細長い鎖状の形状をしており、きれいに並んで結晶化しやすいことから、気密性や強度などの性質が生まれるとのことである。

ペットボトルをシステムとして捉えたとき、ポリエチレンテレフタレートという要素が相互に分子間力で結び付く作用によって、「気密性」「強度」「剛性」といった全体の性質が創発されている、ということができる。

このようなものが、自然にできるはずはない。誰かが、このような性質を意図して「システム設計」したのである。

身の回りのシステム(3)

もう少し「モノとモノが組み合わされてできている」ことが見える例として、洗面台を取り上げる。

洗面台の全体としての性質(私たちがどのような恩恵を受けているか)を考えてみると、「必要な時に、必要なだけの量の水を提供してくれる」ということと、「排出された水を余すことなく排水管に流してくれる」ということが言えるだろう。

これらの性質は、洗面台のどのような「要素」と、それらの「相互作用」が創発しているのだろうか。

洗面台を見れば明らかなとおり、「蛇口」、「センサー」、「洗面ボウル」で構成されている。センサーと蛇口は、必要な時にのみ蛇口から水が排出されるようにする関係がある。蛇口と洗面ボウルは、蛇口から排出された水を全て洗面ボウルが受け止めるように位置する関係がある。

これらの要素と相互関係により、「必要な時に、必要なだけの量の水を提供し、排出された水を全て排水管に流す」という有難い性質が創発されている、といえる。

もしも洗面台というものが発明されていなかったら、毎朝どのようにして顔を洗っていたのだろうか、と考えると、その有難みが再認識される。

身の回りのシステム(4)

ビジネスモデルのような「仕組み」も「システム」として捉えることができる。

例えば、ウーバーイーツは、「家にいながらにして、外の飲食店の料理を楽しむことができる」という性質を創発するシステムである、ということができる。他にも、配達員という新しい雇用を生み出し、飲食店に対しては店内の客席数以上の注文を受けることができるという新たな性質を生み出している。

これらの性質を創発する「要素」は、飲食店、配達員、注文者である。注文者が飲食店と配達員に注文を出し、それに応じて飲食店が料理を提供し、配達員がそれを受け取り、注文者に届ける、という三者の「相互関係」でウーバーイーツは成り立っている。

この三者は、ウーバーイーツが登場する以前は特に相互関係はなかった。ウーバーイーツは、これらの三者の相互関係を「設計」することにより「システムづくり」をしたのだ、という言い方ができる。

 

「システム」とは何か(その2)

前回の記事では、「システム」の概念について次のように整理した。

 

システムとは、相互に作用する要素の複合体である。

その相互作用によって、「部分の総和以上」であるシステム全体としての性質が創発される。

 

「システム」をこのように捉えると、身の回りのあらゆるものを「システム」として見ることができる。

身の回りのシステム(1)

例えば、どこでも見かける「机」について考えてみる。

机が「システム」ならば、その「全体としての性質」は何であろうか?

それは、机が何故存在するのか、私たちは何故机を使うのか、何が有難いのか、を考えてみれば良い。突き詰めて考えてみれば、「ある程度までの重量のものを天板の上に置くと、置いたままの状態を保ってくれる」ということが言えるのではないか。

PCを置いたり、書類を置いたり、腕を置いたりして作業する。そういうときに、机は「置いたままの状態を保つ」という役割を果たしてくれる。そのおかげで私たちは作業ができる。

PCを置いた瞬間に「ぐにゃっ」と沈んで行ってしまったら有難くないのだ。机は、常に私たちの期待に応え、置いたままの状態を保つというミッションを淡々と果たしてくれる。

では、その「全体としての性質」を生み出している「要素」と、それらの「相互作用」は何であろうか?

一見すれば、「天板」と、4本の「脚」から構成されていると言える。

では、それらのどのような「相互作用」が「ものを置いた状態のまま保つ」という性質を創発しているのだろうか。

まず、「4本の脚は、天板の四隅に位置する」という相互の関係性があるといえる。4本の脚が天板の中央にあったら机のミッションは果たせない。

次に、「4本の脚は、天板と垂直に接する」という関係性があるといえる。さらに、「4本の脚と天板とは、垂直の関係が維持されるような強度で結合される」という関係性があるといえる。

これらの関係性がないと、例えばPCにかかる重力によって天板と脚との結合が解け、PCが床に落ちてしまうことになりかねない。

 

以上は、「机」というものに関するごく常識的なことである。しかし、人類が初めて机を作ったとき、最初からこのような形が考えられたのだろうか。おそらく、いくらかの試行錯誤があり、その結果このような「要素」と「相互作用」が発見されたのだろうと思われる。

 

「システムをつくる」とは、そういうものなのだろうと思う。

何かの公式に当てはめていくとシステムを設計できる、というような類のものではなくて、所望の性質が創発されるように「要素」と「相互作用」を設計するのは、発見的なプロセスになるのだろう。

発見的とはいっても、「手あたり次第」、「やみくもに」ということではない。経験がものをいう。経験から学習した人は、上手にシステム設計ができる。

それならばと、経験に基づいて、「標準則/方法論」を定めようとする。それはもちろん無意味なことではなく、多くの益をもたらしてきたといえる。(「エンジニアリング」が有益であることは疑う余地がない。)しかし、そのアプローチで「いつか、完璧な方法論を手に入れられるはずだ」という考えがあるとすれば、それは幻想だろうと思う(*1)。

その「本質的な限界」は、作るシステムが多様化・複雑化するにつれて表面化してくる。比較的シンプルなシステムの設計では「なんとかなっていた」ものが、そうはいかなくなってくる。それが「想定外のシステム事故」になる。

そういうことなので、「想定外のシステム事故」が起きたとき、担当者を責めるのは筋違いである。「やるべきことをやらなかった」「怠けていた」のではなく、もともと、難しいことをやっていたのだ、という認識を持つべきであろう。

企業等の組織を含め、世の中の議論などを見ていると、「完璧な方法論があるはずだ」という幻想が根底にあるのではないだろうかと、勘繰らざるを得ないような場面に遭遇する(*2)。仮に対象のシステムを固定すれば、その分野における「完璧な方法論」は確立可能かもしれない。しかし、「これまでなかった新しいシステム」が日々求められる現代においては、それは非現実的である。

「システム」の概念を正しく認識することは、幸せな社会をつくるための「第一歩」として重要なのであろうと思う。

 

※「身の回りのシステム(2)」も書く予定だったが、途中で話がそれて長くなったので、次回に。

 

*1:この世界のあらゆる現象を説明・予測可能な理論科学がいつか完成し、それに基づいた「失敗しないシステム作り」の汎用的な方法論がいつの日か完成するはずだ、という考えがあるとすれば、という意味。「幻想だろう」というのは、そのような完全な方法論はあり得ず、「システム作り」は常に、後付けでしか説明しようのない「気づき」や「ひらめき」などを必要とするものだろうという意味。十分な「気づき」が得られないまま作られたシステムは、想定外の障害を起こす可能性を含んでいる。そして、十分な気づきが得られたかどうかは証明しようがない。

 

*2:例えばある企業では、社員は年度末までにどのような成果を達成するかを宣言し、それに向けた四半期毎のマイルストーンを設定することが求められる。その達成具合によってボーナスの額が決められる。この制度が公平なものとされているならば、「ベストを尽くせば成果を達成できるはず」という考えが根底にあることを示唆する。つまり「正解(成果を達成できるやり方)」が存在し、それに到達できるかどうかで評価するという考え方である。入学試験に似ている。あるいは逆に、「ベストを尽くせば達成できる」類の成果を宣言するのであれば、そのようなタイプの「成果」を集めたところでそれは「単なる部分の総和」であって、組織としての有機的な連動による会社全体のパフォーマンスにはつながらないだろう。いずれにしても、「システム」という概念の理解なく考えられた制度と思われてならない。組織の運営とシステム理論 にも書いたように、企業全体の目標を各部門や各社員に分割することは、非常に難しい問題であり、決して容易い話ではないのだ。

 

「システム」とは何か(その3)に続く

 

「システム」とは何か

「システム」という概念を初めて体系的に整理したといわれる「一般システム理論」(※1)では、著者のフォン・ベルタランフィは次のように記している。

システムとは、相互に作用する要素の複合体と規定できる。

相互作用とは、要素pが関係Rにおいて存在すること、したがってRの中での一つの要素pのふるまいが別の関係R'の中でのふるまいと異なることを意味する。

この著書は、「システム」の概念が、様々な学術分野での知見に当てはまることを示すことに主眼が置かれていると思われる。(「一般システム理論」というタイトルにもそれが表れていると考えられる。)説明に数式が多用されており、厳密性は高いが、「システム」について自然言語で分かりやすく記された箇所を見つけることに多少難儀する。

もう一つ、次のような記述もある。

「全体は部分の総和以上のものだ」などというが、その意味は要するに、構成的特性は、ばらばらにされた部分の性質からは説明できないということである。

システムの創発性が還元不可能であることを言っていると理解できる。

 

一方、M・デーヴィドソンが著した「ベルタランフィ:一般システム論入門」(※2)は、ベルタランフィの功績をまとめたものであるが、タイトルにあるとおり、一般システム理論に関する入門書的な位置づけとなっており読み物として読みやすい。

次のような記述がある。

ベルタランフィは、システムにおける構成要素は相互に連関するという事実を重視して、「相互連関する諸要素の複合体」と定義してきた。

例えば、腕時計は機能しているときはシステムだが、ひとたび分解されてしまうと単なる部品の山と化してシステムではなくなる。

 

また、次のような記述もある。

芸術作品のようなシステムは単なる集積ではなく、パターンである。音楽作品で言えば、単なる音の総計ではなくその組み合わせである。

人間もまた、数ガロンの水分と、様々な量の脂肪、炭素、鉛、リン、鉄、石灰、マグネシウム、硫黄等の集合体以上の存在であり、身体各部の組織化によって成立している。組織化が崩れれば死ぬ。

芸術作品を「システム」と捉えているところが面白い。言われてみれば、音楽作品は単なる音の集まりではなく、その繋がり具合が「メロディー」になるわけであり、それが心地よさ、楽しさ、悲しさといった「曲全体としての性質」を創発しているわけだ。

人間の身体も、複雑な「システム」である。「生命」の不思議さを感じるし、その構成要素の関係性がちょっと崩れただけで健康を喪失することを考えると、本当に絶妙な「相互連関」のおかげで毎日生きていられるのだと実感する。自然と感謝の気持ちが湧いてくる。

 

また、芸術に関係する話としては次のような記述もある。

システムにおいては、1+1=2プラスα、の関係が成り立つ。システムにおいて、その本質は各部の相互連関であって、各部の物質そのものではない。
例えば、ロダンの「考える人」は大理石でできていても、青銅製でも粘土でも、この彫像の持つもの思わしげな本質は変わらない。
同様に、「ハムレット」の役を誰に変えてみても、出来上がりは似通ったものになる。それはこの戯曲の本質が、配役などの各要素にあるのではなく、その相互連関形式にあるためだ。

このあたりは、ベルタランフィの著書にもあった「全体は部分の総和以上のものである」を具体例で示している。

 

また、「ものづくり」に関わる話も出てくる。

「システム全体は各部の総計よりも大である」という考えは、取り立てて謎めいたものではない。
石器時代に生きた人類の祖先は、…(中略)…防御と狩猟のために彼らが頼りにしていたのは直接手に持つ道具、つまり、成形した単純な石器だ。
時代が進むにつれて、二つ以上の部品を組み合わせて道具を作る能力を身につけるようになる。研磨した石器を棒の先に縛りつけ、最初の斧を完成させた。こうしてできた複合道具は、各部が独立して与える打撃より大きな打撃を可能にした。

この「最初の斧」が、ものづくりの原点である。

石を尖らせてモノを切ったり皮をなめすのに使ったりする、すなわち「道具を使う」という発想に至ったことも画期的だが、さらに、「尖った石と木の枝を組み合わせる」というアイディアが生まれたことは、人類史における重要な事象だと思える。

この「最初の斧」が人類が初めて作った「システム」であり、今日行われているあらゆる「ものづくり」は、これと本質的に変わらないものだろう。

 

このように考えると、「この世に存在するものは全て『システム』なのではないか」と思えてくるが、「世界はシステムで動く」(※3)には、次のようなことが記されている。

システムではないものはあるのでしょうか?ええ、あります。特に相互のつながりや機能を持たない、何かの寄せ集めがそうです。たまたま路上にまき散らされた砂は、システムではありません。砂を足しても取り除いても、変わらずただ路上に砂があるだけです。

たまたま路上にまき散らされた砂はシステムではないが、意図的に撒いた砂はシステムと呼べる場合もあるように思う。例えば、枯山水は要するに「砂」や「石」だが、全体としての「美しさ」がある。これは、「音楽」と同様であり、砂や石の相互連関が意味をもたらしていると考えれば、「システム」に該当するだろう。

ただ、「ランダムにまき散らされた砂や石」であっても、見方によってその全体像に「美しさ」などの価値や意味を見出せる場合もありそうに思える。

ということは、「システム」であるかどうかは、それを見る主体が存在し、その主体の主観に依存するということだと言えるのではないだろうか。

考えてみれば「太陽系」というシステムも、それによって地球上の気象現象がもたらされていることなどの「意味」を見出しているのは人間であり、宇宙(という主体があるとするなら)にとっては特に意味を成さないのかもしれない。

(そもそも、太陽の周りを惑星が回っているという現象も、人間の五感や脳がそう関知しているだけであって、『実際』がどうであるかはわからない。)

 

「システム」とは何か(その2)に続く

 

引用元:

  • ※1:「一般システム理論」,フォン・ベルタランフィ, 長野敬・太田邦昌 共訳, みすず書房, 1973
  • ※2:「ベルタランフィ:一般システム論入門」,M・デーヴィドソン, 鞠子 英雄 ・酒井 孝正 共訳, 海鳴社, 2000
  • ※3:「世界はシステムで動く」,ドネラ・H・メドウズ, 枝廣淳子 訳, 小田理一郎 監修, 英治出版, 2015

STAMP/STPAの「なぜ」と「コツ」(その4)

STAMP/STPAの4番目のステップは、ハザードシナリオの識別です。

3番目のステップで、UCAの識別を行いました。

4番目のステップで行うハザードシナリオの識別とは、「なぜ、(ステップ3で識別した)UCAが起きるのか?」を説明するシナリオを識別することです。

UCAとは、コントロールアクションが想定通りに働かず、そのためにハザードが発生するシナリオでした。つまり、コントロールアクションからハザードまでの因果関係のシナリオを特定したものだと言えます。

そして、4番目のステップで行う「なぜ、UCAが起きるのか」は、その上位の因果関係のシナリオを特定するものだ、と位置付けることができます。

したがって、この2つの因果関係を特定するシナリオと合わせることによって、「このシステムにおいて、なぜ、ハザードが起きるのか」を説明するシナリオを識別できることになります。

 

結局のところ、STAMP/STPAを行う目的は、「このシステムにおいて、ハザードが起きるシナリオ」をなるべく多く、偏りなく見つけたい、ということです。ですから、このステップ4がまさに「本丸」であり、その目的のど真ん中に対応するステップになります。ここまでのステップは、このステップ4をやりやすくするための準備、お膳立てなのだ、という整理の仕方で良いと思います。

 

「ステップ4がやりやすくなっている」とはどういうことかというのは、ステップ3までがない場合を想像してみると分かりやすいです。

もしもUCAの特定をせずに「ハザードシナリオの識別」を行おうとすれば、対象システムを目の前にして、どこに着目してどのように考えていったらよいか、途方に暮れてしまうでしょう。

STAMP/STPAのステップ4は、「ステップ3で識別したUCAを1つずつ取り上げ、そのUCAが起きるシナリオを考える」という「手順」が示されているおかげで、途方に暮れることなく、脳の働きを集中させて考えることができるのです。

ステップ4のコツ

「ハザードシナリオの識別」には、STAMP/STPAとして特に工夫や支援はありません。「なぜ、このUCAが起きるのか?」について、あらゆる可能性を考えます。これは、脳の縛りを解き、開放して、想像力を最大限に活用する作業になります。

「あらゆる可能性を考える」。これが、「想定外の事故シナリオ」を防ぐために重要になるのです。分析者の想像力が試されるステップになります。

 

ただし、「想像力」というのは、過去の経験や知識が源になるのだろうと思われます。ステップ4の分析には、対象システムの運用に関する経験や知識を持つ人が関わることが必須であると言えます。

 

具体例

前回に行ったUCAの識別例のうち、

「商品の配達がまだされていないにも関わらず、配達員が配達ステータスを『配達完了』と更新するためにハザードH2が発生する」

というUCAを取り上げて、ハザードシナリオを考えてみます。

 

配達業務の経験がある人であれば、様々な状況が想像されることであろうと思われます。一方、配達業務の経験がなくても、配達を「受け取る」立場になることは、多くの人が経験するでしょう。その経験から、想像力を働かせてみます。

 

シナリオ1:同じ住所に同時に2つの配達物があった。しかし住人が留守であったために宅配ボックスに入れることにし、2つとも「配達完了」とステータス更新した。しかし、宅配ボックスに入れる直前で1つは生ものであることに気づき、持ち帰ることとした。その際「配達完了」のステータスを戻すことを忘れた。

シナリオ2:マンションへの配達物で、「置き配」の指定があったため、荷物を部屋の玄関前に置き、「配達完了」のステータスに更新した。しかし、違う部屋番号の玄関前に置いてしまった。宛先が手書きされている紙の文字が擦れていて読みにくかった。

 

2つ考えてみましたが、「宅配」の経験が豊富な人であればもっと多くのバリエーションを考えつくのではないでしょうか。

 

ハザードシナリオを識別したら、それに対する「対策」を考えることが必要です。

上の例のシナリオ1であれば、配達員がステータスを戻すことを「忘れた」のが原因です。シナリオ2は、配達員の「誤認」が原因です。いずれも、ステータスの更新作業を配達員が行うのではなく、自動化できれば事故を防げそうです。

例えば、個々の配達物に、位置を検出できるセンサーを付け、「配達先に正しく配置された」ことが確認されたら、ステータスを「配達完了」にする、という仕組みが実現できれば、上記の2つのシナリオによる事故は防げるでしょう。

 

STAMP/STPAの作業としては、識別した全てのハザードシナリオについて「対策」を検討し、その現実性や効果等の考察を含めて記録しておくことが必要です。

万一事故が起きた場合、「このような対策を考えていたが、技術的難易度やコストの観点で対応を見送った」といった説明が可能になります。それは、事故後に改善策が推進されることも役立ちます。

 

「事故が絶対に起きないことを保証する」ことは残念ながら無理ですが、ベストエフォートを尽くすことと、それを第三者に示すことは可能です。

そのための有効な手段として、STAMP/STPAは位置づけられるのです。

 

STAMP/STPAの「なぜ」と「コツ」(その3)

前回に続き、STAMP/STPAの3番目のステップです。

このステップでは、非安全なコントロールアクション(UCA:Unsafe Control Action)の識別を行います。

UCAの識別は、STAMP/STPAの手順の中でもっともアルゴリズミックな作業になります。ここで「アルゴリズミック」という表現は、「手順的」あるいは「機械的」といった意味で使っており、客観性が高く、属人性が低いという意味を意図しています。STAMP/STPAは、このUCAという概念を用いることにより、「想定外の事故シナリオを見つけ出す」という難しい課題に対して、ある程度の客観性と網羅性をもたらすことに成功していると言えます。

 

UCAの識別のコツを示す前に、「UCAの識別は、なぜ必要なのか?」を考えてみます。

前回の記事にも書いたように、STAMPの基本的な哲学は「コントロールが想定通り機能すれば(それによる創発性である)安全性は保たれるが、想定を外れた場合にアクシデントが起きる」というものです。ステップ2で、安全性(※1)を保つ役割を担うコントロールアクションを識別しました。UCAの識別は、これらのコントロールアクションが想定通り機能せずに非安全(※1)な状態になるパターンを洗い出すことに相当します。次のステップ4では、これらのパターンが実際に起きるシナリオを検討することにより、「事故シナリオ」を見つけ出します。その検討対象となるパターンを洗い出しておくために、ステップ3でUCAの識別が必要となるわけです。

 

UCAを識別するコツ

STPA HANDBOOKでは、「UCAは5つの部分から構成される」として、そのことが次のような具体例を使って示されています。(< > で示すものがUCAの構成要素です。)

これは、飛行機のブレーキシステムに対するUCAの例で、"BACU Autobrake"はコントロールするコンポーネント、"Brake command"がコントロールアクションで、「通常の離陸が行われるときにBrake commandがprovideされないために[H-4.3]のハザードになる、という意味のUCAを表しています。

上記のUCAの構成要素を、日本語として自然な文となるように順番を入れ替えると、次のようになりそうです。

UCAの識別のコツはシンプルで、この「ひな型」を使って、5つの要素を当てはめていけばよいのです。

具体的には、次のような手順で行うのが良いと思います。

  1. ステップ1で識別したハザードを1つ取り上げる
  2. ステップ2で作成したコントロールストラクチャーモデルから、コントロールアクションを1つ取り上げる。(これによって「コントローラ」も特定される。)
  3. 4つのガイドワードから、1つ取り上げる。

ここまでの手順は、ほぼ機械的にできます。冒頭に示したUCAの例で、1~3までを行った状態を書いてみると、

「BACU Autobrakeが、ブレーキコマンドを与えることにより、[H4-3]のハザードになる。」

となります。1~3までを行った段階では、意味の通じない文が出来上がることが多いと思います。そこで、最後に、

  1. 論理的に意味が通じる文となるような<状況>を考える。

という作業を行います。以上により、上に示した例のようなUCAが一つ出来上がります。

この1~4の作業を、全てのハザード、全てのコントロールアクション、全てのガイドワードの組合せについて行うことで、STAMP/STPAのステップ3である「UCAの識別」ができます。

 

具体例

前々回の記事と前回の記事で示した「ハザードの識別」と「コントロールストラクチャーのモデル化」の例を用いて、UCAの識別を行ってみます。

一例として、ハザードH1を取り上げ、コントロールアクションとして「配達先の住所(商品に貼付)」を取り上げた場合を考えます。ガイドワードの"Not providing causes hazard(適用せずにハザードとなる)" を適用してみると、

「配達管理機能が、配達先の住所を商品に貼付しないことで、H1のハザードとなる」

となります。

次に、この文が妥当な意味を持つような「状況」を考えてみます。

例えば、「配達員が、配達対象の商品をトラックに積もうとしている状況」で、その商品に「配達先の住所が貼付されていない」状態だと、正しい住所に商品が配達されることはほぼあり得ないでしょう。つまり、H1のハザードが発生します。

そこで、その「状況」を加え、

「商品が出荷される状況で、配達管理機能が、配達先の住所を商品に貼付しないために、ハザードH1が発生する。」

というUCAができあがります。

 

もう一つ、別の例として、ハザードH2を取り上げ、「配達ステータス更新」というコントロールアクションを取り上げた場合を考えてみます。ガイドワードの "Providing causes hazard(適用してハザードとなる)”を適用してみると、

「配達員が、配達ステータス更新を行うために、H2のハザードとなる。」

となります。この文が妥当な意味を持つような「状況」を考えてみると、例えば、配達がまだ完了していないにも関わらず、配達員が「配達完了」のステータス更新を行ってしまうと、H2のハザードとなります。そこで、その「状況」を加え、

「商品の配達がまだされていないにも関わらず、配達員が、配達ステータスを『配達完了』と更新するために、ハザードH2が発生する。」

というUCAが出来上がります。

 

このようにして、全てのハザード、コントロールアクション、ガイドワードの組合せについて検討した結果の一例が以下の表です(※2, ※3)

 

 

脚注:

※1:ここでいう「安全」や「非安全」とは、ステップ1で識別したハザードが発生しない/発生する状態のことを指します。STAMP/STPAにおける「安全」は、ステップ1で識別するハザードによって定義づけられることになります。

※2:ガイドワードは、「STPA/HANDBOOK」に示されている英語表記を用いました。日本語表記では、原文の"provide"の意味を上手く表現できないおそれがあるためです。

※3:"Stopped too soon, Applied too long"のガイドワードを適用した場合は、UCAとして該当するものがないため、「該当なし」と記しています。このように記すことで、単なる記入漏れではなく、検討した結果であることを示すことができます。このガイドワードは、コントロールアクションの適用開始から終了までの時間に関するものであり、適用時間の長さが意味を持たないようなコントロールアクションでは、UCAの該当がない場合が多くなります。