前回，ISO26262におけるセーフティケースの特殊な位置づけについて書いてみました．安全性の確保を考える上で，アプローチの違い（プロセス的な定義をするかゴール指向で定義するか）は，きわめて重要です．つい最近（8月1日）に，ISO26262 Part 10の正式版が発行されたので，この正式版にあるセーフティケースを例にとり考えてみたいと思います．
ちなみに，Part 10 はISO26262のガイドラインとしての位置づけです．それ以外は，昨年の11月に正式発行ですから，8ヶ月ほど遅れて発行されたことになります．全体の構成はかなり変わっているのですが，セーフティケースの記述に関してはドラフト（DIS版）からあまり変わっていません（5.3 「セーフティケースを理解する」）．記述量は減っていて，約2頁ほどの記述です．これまでは，セーフティケースの一般的な説明となっていたのが，規格中の文章ということで，整合性をとるための変更が主たる目的でしょうか．ずいぶんすっきりとした文章に変わったのですが，その分，無味乾燥化しています．もちろん，私の主観です．ただ，私のそして誰かの主観は大事で，それがなくては，あるいはそれを知ることなしに，理解はできないだろうと思います．
***
ここではドラフト版との違いを見ることにします．
(1) セーフティケースの説明図
単純なところでは，セーフティケースを示す図の要素の名称が変わっています（図6）．以前は，Kellyさんの学位論文にあるものをそのまま使っていたのですが，今回，ISO26262の用語に合わせて変えています．引用図を説明なしに改変するのもどうかと思うのですが，それ以前に，単独でセーフティケースの説明にこの図を使用することはあまり見通しが良くないのではと思っています．
(2) セーフティケースの全体での位置づけ
セーフティケースをISO26262の主流のプロセス的定義の中に取り込む努力の一つとして，「セーフティケースの初期のバージョンは，安全計画の一部に含まれる」という記述があります（5.3.2 注記）．これは新たに追加された部分で，より積極的にセーフティケースについて記述しているということだと思います．ただ，もう一歩だと思うのは，セーフティケースは，安全計画とは原則区別されているので（Part2 6.5.1と6.5.3），単なる参照だけで良かったかもしれません．もちろん，この注記で大事なのは，漸次的に（incremental）セーフティケースは作られるという部分になります．それぞれのライフサイクルの段階で，証拠と共に作成されるというのが，一番重要な部分で，それぞれが（中間バージョンなどではない）完成されたものとなります．
(3) 確認レビュー(*)
最後に，新たに追加された部分が，最後から2つ目のパラグラフです．パラグラフといっても一行しかありませんが，「セーフティケースは，ISO26262-2:2011,6.4.7で規定されている確認レビュー（confirmation review）を前提としている」．ここでの確認レビューというのは，「必要な独立性レベルを持つレビューアによって，成果物が，ISO26262へ適合していることを確認することと」なっています（Part1 1.18）．また，独立の程度は別途規定されています．さて，この確認がどうして必要になるのでしょうか．次では，この点を中心に考えてみます．
(*) confirmation review に関する合意のとれた訳語はないと思います．ここでは，単に確認レビューとしておきます
***
究極的に，安全というのは信じ・納得することでしかありません．（包丁の例を持ち出すまでもなく）あるシステムが文脈を無視したところで安全といえるはずはありません．それは，システムとは社会の中に埋め込まれた存在として考えれば，とうぜんのことです．だとすると，ソフトウェアはよくハードウェアと違って確率的に扱えないという例外的な扱いをしますが，それは逆で，確率的に扱えるものの方が，この世においては希少なのだろうと思います．
セーフティケースは，安全ゴールと証拠関係における一つの視点を提供します．そこには，立証というかたちで，作成者の主観が投影されています．それはあくまで主観に過ぎないということです．立場が変われば，立証は成立しなくなります．従って，この主観を確認するということが必要になります．
セーフティケースの意味は，それが正しい安全ゴールと証拠との関係を示していることにあるのではありません．立証を通じて，どうしてその関係でよいと考えたのかという主観を明示することのみにあります．その論理の道筋がなければ，だれも良否を判定できないのです．あくまで判断の材料を提示しているに過ぎず，それ自身が安全を示しているわけではありません．
***
このことは，多くのプロセス的なアプローチに通じてもいえます．何かのタスクに対してレビューをしましょうという定義は，何もいっていないに等しいのです．如何なるレビューを実行することで，タスクの成果物を保証するということが如何に可能かを説明しない限り，そのプロセスの良否を評価することはできないということになります．
ちなみに，26262のドラフト版は，セーフティケースのもつ主観性を強調しています．それが正式版ではなくなっています．これによって，文章自体はすっきりとしました．しかし，ISO26262で主となっているプロセス的なアプローチと，セーフティケースの距離は遠ざかったかもしれません．
(nil)