安全性解析手法STAMP/STPAセミナーの感想

先日、安全性解析手法STAMP/STPAセミナーに行ってきた。
ラフな感想をメモ書き。

【感想】
安全性解析手法STAMP/STPAセミナー＠大阪（ソフトウェア高信頼化 SECセミナー ）-SEA関西

安全性解析手法STAMP/STPAセミナー＠大阪

「はじめてのSTAMP/STPA（実践編）～システム思考に基づく新しい安全性解析手法～」の公開：IPA 独立行政法人 情報処理推進機構

一般社団法人JASPARと相互協力協定を締結<br />自動車産業における「STAMP/STPA」の普及促進で、さらなる安全性の向上を加速：IPA 独立行政法人 情報処理推進機構

【1】最近のIT業界だけでなく、メーカーでも、IOTやAI、ビッグデータがバズワードになっている。
家電製品は既にソフトウェア化されてしまって価格破壊と鮮度劣化が激しいけれど、ついに自動車にもEVの波が押し寄せてきたように、メーカーが製造するあらゆる工業製品もソフトウェア化が迫ってきている。

しかし、従来のメーカーの品質管理手法は、そういうソフトウェア化の環境変化に対応しきれていないと考えている。
メーカーの品質管理手法は、統計的品質管理を主体とした、量産品の品質管理技法だと思う。
つまり、品質が保証された製品を大量生産するために、品質のばらつきを管理図などのQC技法で潰し、歩溜まりを上げて、経験曲線効果を活用して、コスト低減と品質向上を目指す。
この手法が以前まで、日本の製造業は品質で世界一だ、という評価をもたらしてきた。

しかし、製造業における、大量の資金投入による投資と生産設備の最新化、大規模化、という規模の経済の考え方は、ソフトウェア開発では全くと言っていいほど通用しない。
ソフトウェア開発は徹頭徹尾、労働集約的な産業だと僕は思う。

たとえば、人月の法則で言われるように、大量の開発メンバーが加わるほど、システム開発は遅れる。
他に、コンウェイの法則のように、大人数の組織は、その複雑な組織構造がソフトウェア設計にも反映されて、ソフトウェア構造がより複雑化され、ソフトウェアはエントロピー増大にさらされる。

そこで、アジャイル開発、そしてスクラムでは、規模の経済をベースにした製造業の開発スタイルではなく、サーバーントリーダーシップや自己組織化の理念の元で、小規模な開発チームで状況変化に素早く対応できる仕組みを提唱してきた。
よって、ソフトウェア開発をビジネスの主体とするならば、たとえメーカーであろうとも、アジャイル開発の導入は避けては通れないはずだ、と僕は思っている。

【2】でも、ソフトウェア開発の仕組みを製造業にそのまま取り入れたとしても、上手く行かない部分がある。
それが、安全性という品質特性だろう。
特に、フェールセーフという安全性の品質だろうと僕は思う。

たとえば、鉄道の踏切、交差点の信号、レンジやドラム缶式洗濯機などでは、人が事故に合わないように、安全が保持できる方向へ切り替わる仕組みが考えられ、昔からその機能が提供されてきた。
しかし、ソフトウェアが製品に組み込まれると、ちょっとしたバグが人命の危機にさらされるリスクが増大する。
そして、ソフトウェア開発者なら誰でも知っているだろうが、全ての潜在バグを潰すことは事実上不可能だ。
つまり、ソフトウェアが組み込まれた製品は、安全性に関して、何らかの不安が残る場合がある。

そういう課題は以前からずっと認識されてきたようで、たとえば、自動車の電子制御系に関する機能安全規格はISO 26262として最近公開された。
ついに自動車でもISOとして安全性という品質が業界標準で決まったために、組込ソフトウェアにおける安全性の研究は現在ホットな状況なのだろう、と思う。

IPAでも、この分野の研究が重要と認識しているようで、セーフウェアの本の著者であるナンシーさんとも共同して、安全性解析手法STAMP/STPAという手法を作り、日本のメーカーに広げようとしているようだ。

今回は、そんなセミナーに行ってきた。

【3】正直な感想を言うと、僕は門外漢なので、安全性解析手法STAMP/STPAがどこまで有効なのか、分からない。
でも、こういう安全性解析手法がどんな考え方をしているのか、というイメージは持つことができた。

一言で言えば、部品単体レベルの品質向上を目指すのではなく、もっと抽象的なレベルを上げて、製品とそれに関わるステークホルダーの関係に注目する観点で、安全性を議論しようとしている。
下記の絵が分かりやすい。

一般社団法人JASPARと相互協力協定を締結<br />自動車産業における「STAMP/STPA」の普及促進で、さらなる安全性の向上を加速：IPA 独立行政法人 情報処理推進機構

一般に、メーカーの品質管理の考え方では、下請け業者から仕入れた部品の品質を徹底的に管理し、それら高品質な部品を組み立てて、最終製品の品質を維持しようとする。
しかし、製品が複雑な構造になると、部品単体の品質が良くても、それら部品の関係や依存性で品質が悪くなる時がある。
その話は、部分の合計は全体と一致しない、むしろ全体よりも大きくなる、という集合論の話を連想させる。
バナッハ＝タルスキーのパラドックスだったかな。

バナッハ＝タルスキーのパラドックス - Wikipedia

ソフトウェアが混じってくれば、なおさら、プログラム単体ではなくシステム全体として機能させた場合の方が品質に大きく関わってくる。
つまり、部品レベルではなく、製品全体、製品とそれに関わるユーザとの相互作用を考慮した「システム」のような考え方が必要になってくる。

【4】この考え方にはいくつか特徴があると僕は思う。

【4-1】一つは、製品のI/Fがユースケースになること。
たとえば、電気自動車を考えた場合、ユーザは電気自動車に何を期待するのか、という観点から、電気自動車に必要な機能を考えていくことができる。
この考え方のメリットは、ユーザの価値や便益を起点に機能を考えるので、ユーザに優しい製品になる可能性が高いことだろうと思う。
つまり、ソフトウェア開発の企画や要件定義の手法を取り入れているように思う。

すると、製品とユーザの接点は、製品のI/F機能、またはユースケースと考えることができる。
なぜなら、ユーザが製品を使う利用シーンを考えるようになり、それを表現しようとすると、ユースケースの概念が自然に現れてくるからだ。

また、ユースケースの概念が現れてくると、「SysML」本のコンテキスト図のように、製品に関係するステークホルダー全てがアクターとして現れ、その中心に製品が配置されるような図が作られることになる。
つまり、この考え方では、アクターを漏れなく抽出すること、アクターと製品に関わるI/Fとなるユースケースを自由な発想でどれだけ考えられるか、という観点が重要になってくるだろう、と思う。

そして、そのコンテキスト図を元に、安全性の観点を組み込んで製品の機能を付けていくことになるはず。

ただし、アクターやユースケースが漏れると、その後の工程で検出することは不可能なので、自由な発想を補強するようなプラクティスが必要になってくるのではないか。

【4-2】もう一つは、製品のハード設計がなくても議論できること。

一般に、ハード屋さんはどうしても実際のモノの設計図から考えたがる。
しかし、企画段階ではモノがないので、イメージにしくい。

だが、製品にはこんな機能があるとユーザにとっていいよね、という観点で、製品のI/Fを洗い出していくことができるし、それらI/Fを整理することで、製品のおぼろげなイメージが出てくる。
たぶん、iPodやiPhoneのような製品も、プロトタイプ製品はあったとしても、ユーザの利用シーンから色々考えて作られたのではないだろうか。

すると、製品のハード設計図がない状態で製品の機能を作り出し、安全性の品質の議論ができるようになる。

なお、SysMLのメリットは、ハード設計図がなくても、ソフトウェア層の観点で抽象的なレベルで要件や機能をイメージできること、という話を聞いたことがあったが、たぶん、その内容とほぼ似たことなのだろう。

実際、IPAの方の講演でも、抽象的なレベルで考えることでより広く安全性を考えることができる。
部品レベルのような粒度の細かい観点で考えると、安全性を考慮すべき観点が漏れやすいから、あえて、抽象度をあげて幅広く議論するのだ、という話があったから。

【5】上記の内容は素人の考えなので、どこまで正しいのか分からない。
でも、安全性の品質に関する議論を、箱と矢印の図で行おうとする方向性を見ると、ハード設計図のレベルではなく、SysMLのようなソフトウェアのレイヤーで抽象的なレベルで設計しようとしているように思える。

この手法がどこまで通用するのか、僕は分からない。
でも、ソフトウェア開発がハード設計でも重要になってくるならば、具体的なモノがない状態で機能を設計する必要性は出てくるだろう。
すると、ソフトウェア設計のように、要件や仕様を決めていく技法やプロセスが必要になってくる。
それら技法は、たぶん今までのハードのやり方は通用しないだろう、と思う。

そして、アジャイル開発を取り入れた場合の品質保証は、どのような観点に考慮すれば効果的なのか？
そういう課題も考えてみたい。

【追記】
STAMPについての分かりやすい記事が紹介されている。

STAMP/STPAとは何か (4/4) - MONOist（モノイスト）