STAMP/STPAの誤解しやすいところ

STAMP/STPAについて、初めて聞く人に説明するとき、UCAを識別する際に用いる４つのガイドワードのところで「なるほど」「面白い」という反応をされることが多いように思う。確かに分かりやすく、面白い部分ではあるが、ガイドワードの部分だけにあまり目を奪われると、STAMPの本質を見逃す恐れがあるのではないかと思う。STAMPを誤解する落とし穴になり得るとさえ言えそうな気がする。

「大きいものは分割して扱うのがよい」という常識

対象が大きい場合、小分割して対応するのは賢いやり方である、というのは、常識として定着していると思われる。

例えば、公園の草むしりをする場合、ブロックに分割し、各ブロックの草むしりを順番に行っていくやり方や、各ブロックに作業者を割り当てるやり方をよく行う。各ブロックの作業は独立に行われ、全ブロックの作業が完了すれば、公園全体の草むしりが完了する。

このように、「大きいものを分割して扱う」やり方がうまく行くケースは多い。

しかし、そのやり方ではうまく行かない場合もある。複雑なシステムを扱う場合は注意が必要となる。

複雑性とランダム性によるシステムのクラス分け

"Engineering a Safer World" (Nancy Leveson著) では、システム理論の説明の箇所で、「ランダム性の度合い」と「複雑性の度合い」の観点で、システムを３つのクラスに分ける考え方を示している。

organized simplicity：ランダム性も、複雑性も、いずれも低いクラス
unorganized complexity：ランダム性が高いクラス
organized complexity：複雑性が高いが、ランダム性は高くないクラス

このうち、1.は、「大きなものを分割して対応するやり方」（分割統治法）が使えるクラスである。各要素の振舞いにランダム性がなく、要素間の相互作用が十分に単純な場合である。草むしりの例でいえば、あるブロックの雑草を取る行為と別のブロックの雑草を取る行為の間には相互作用がないので、各ブロックの作業を独立して行っていけば問題なく全体の作業が完了する。

2.は、統計的な手法が使えるクラスである。各要素の振舞いのランダム性が十分に高いので、要素数が膨大で複雑であったとしても、全体を統計的なやり方で扱っても問題ない。統計熱力学はその一例になる。

3.は、それらのどちらの手法も適さないクラスである。要素間の相互作用が単純ではないので、「独立して扱っても問題ないように分割すること」が難しい。（草むしりの例でいえば、あるブロックの雑草を取ると別のブロックに雑草が生える、といった複雑な法則がある場合とか(?)。）また、要素の振舞いに十分なランダム性がないため、統計的な手法も適用できない。

そして、システム理論は、3.のクラスのシステムを扱うために必要である、とされている。

システム理論・システム思考の特徴

システム理論は、対象物に対し、それを構成する部分の一つ一つの挙動の寄せ集めで全体を説明できるという考え方（要素還元論）では限界があるとの立場に立つ。全体を要素に分割し、要素を個別に見るのではなく、全体を同時に見ることに重点を置く。（システムダイナミクスは、この考え方（システム理論）に基づいて考え出された方法論の一つである。）

システム思考は、システム理論に基づく実践的な応用と捉えることができるが、例えば000064383.pdf (ipa.go.jp)では「システム思考とは、システムを全体俯瞰的に捉えることである」と説明されている。

システム理論に基づくSTAMP/STPAでは、したがって、システムを要素に分割して個々に見ていくのではなく、「全体を俯瞰的に見る」ことが重要である。

しかしながら、UCAの識別では、「コントロールアクションを一つずつ取り上げ、それに４つのガイドワードを順番に当てはめて識別していく」というやり方をする。

これは、やるべきことが明確で分かりやすいし、組合せ数が有限なので順番にやっていけばいつか終わるという安心感もある。

しかし、このやり方は、「大きいものを部分に分割して個別に考えていく」という、システム理論と真逆のやり方に見える。UCAは、STAMP/STPAの特徴的な概念として目立つだけに、UCAを識別する部分をもって「STAMP/STPAって、そういうことなのか」と、誤解してしまう恐れがあるのではないかと思う。

STAMP/STPAの真の趣旨は、「制御構造図をもとに、システムの要素間のコントロールの関係性を全体俯瞰的に見る」ことである。初期のSTAMPでは、４つのガイドワードは存在しなかったとのことである。

重要なのは、STAMP/STPAの最後のステップ、ハザードを引き起こすシナリオを考える部分である。このステップでは、システム全体を俯瞰的に見て、要素間の相互作用によって生じる創発性を考える。

UCAは、それを考える「きっかけ」とか「取っ掛かり」として捉えるべきである。制御構造図をじっと眺めて闇雲に考えるのでは、網羅性が分からなくなるし、複数人で議論しながら考える場合に着眼点が違っていると会話がしずらい。そういった問題に対処するためにUCAという概念が考えられたのではないかと思う。