　STAMP/STPAの提唱者であるレブソン氏は、STAMPを「ハザード分析説明のためのモデル（Explanatory model）」と呼んでいる。対象システムにおいて、アクシデントに至るハザード要因がどこに隠れていて、どういう条件でそれが表面化し、どういうアクシデントになるかを説明するためのモデルであるとしている。

　では、実際にどのような手順でSTAMP/STPAを実施するのか。詳細は次回で取り上げるが、ここでは手順の概略だけ紹介しよう。大まかな流れは以下の4つに大別される。最後の対策検討はSTAMP/STPAの手順には含まれないが、システム開発において安全分析する場合には必須の手順となる（図4）。

Step0：アクシデント、ハザード、安全制約の識別とコントロールストラクチャーの構築

　最初の準備段階「Step0（準備1）」として、分析対象となるシステムのアクシデント、ハザードを定義する。

　「ハザードを定義する」ことは、「どこが危険なのかに目星を付ける」ことだ。その上で、ハザードを制御するための、システム上の安全制約を識別する。アクシデント、ハザード、安全制約を識別することによって、この後の分析範囲を明確にする。

　次に「Step0（準備2）」では、分析対象となるシステムで安全制約の実現に関係するコンポーネントや、コンポーネント間の相互作用を洗い出す。ここで言う「コンポーネント」や「コンポーネント間の相互作用」がピンと来ない読者は、前述のロケットの例を思い出してほしい。

　ロケットの場合、コンポーネントはサブシステムやエンジン機器、個々の組織などを指す。もともと個別に組み立てられていたモノを相互につなぎ合わせ、コンポーネント間の相互作用を分析する。この場合の相互作用は、安全を維持するために行われるコントロールアクション（Control Action：制御行動）や、フィードバックデータを指す。

図5　STAMPにおける相互作用のモデル（コントロールストラクチャーの基本要素）

　こうしてコンポーネントと相互作用を洗い出したら、コントロールストラクチャー（Control Structure：制御構造）として整理する。コントロールストラクチャーとは、安全を維持するための制御構造であり、コンポーネントとコントロールアクション、フィードバックの関係を現す。コントロールストラクチャーを構築することによって、分析対象を明確にする。

　実は、この「分析範囲を明確にする」ことが、STAMP/STPAのキモと言っても過言ではない。なぜなら、「風が吹けば桶屋がもうかる」的に範囲を広げようと思えば、どんなアクシデントも発生し得ることになり、安全分析の範囲は際限がなくなるからだ。

　一言で「アクシデント」と言っても、人命損失、経済損失、信用失墜、ミッション失敗などさまざまだ。Step0（準備1）で明確にするのは、「どういうアクシデントに関して分析するのか」である。

　当然のことながら、安全分析を行うときには、何のため（分析範囲）に何を（分析対象）分析するのかという目的を明確にする。それがStep0である。