レベルというのは，何か競争心を刺激するのか，好む人が多いように思います．レベルを達成しました！どうだ．
レベルというのは，分かりやすい道具なのですが，特定の文脈の中で，細部をきりはがしたものですから，それを目的化するとおかしくなります．つまり，十分に注意して，目的と手段の転倒を避けなければならないということは，良くおわかりのことと思います．
さて，ISO/FDIS 26262 には，ASILと呼ばれるレベルがあります．AからDのレベル分けがなされています．IEC 61508でいうSIL1がASIL Aに，SIL3がASIL Dにほぼ対応しているしているという云い方をされます（中間の数が異なりますが，ここではたいした問題ではありません）．ここでは，次の理由付けがなされます．乗用車においては，プラントの事故のように多くの人が傷つくということは考えにくい．それでSIL4に相当するASILは想定されていないと．
さて，今回は，ASILとはいったい何かということをその名前から考えたいと思います．Aは，Automobileの略ですから乗用車ということで済ませてしまいます（車としても良いのですが，26262は3.5トン以下の乗用車をスコープとしていますので，乗用車として先ずは問題ないだろうと思います）．問題は，SIL（Safety Integrity Level）です．こちらは，すでに幾つかの訳語があります．手元の本や類似の日本語規格などを見ると，安全度，安全度水準，安全整合性水準等々があります．
ところで，物象化の相での云い方になりますが，ASIL D は安全度が「高い」と書かれたりします．ASILの場合は，リスク発現時に人間が被る重傷度（Severity），遭遇度（Exposure），回避制御の困難さ（Controllability）で定まり，これらが全て高い時に，ASIL Dが与えられます．つまり，ASIL D というのは十全なる対処が必要とされるシナリオに対応したレベルということになります．いま，このASILを安全度とすると，ASIL D のような厳しい状況は，先の日本語訳を使うと「安全度が高い」という変換になります．このままでは，意味不明なのは，おわかりになるかと思います．身長が高いといえば，それは文字通りなのですが，安全度が高いといっても，それは，大変安全であるということではなくて，安全になるように設計・製造しなさいということを主張しているのです．安全度は逆の意味を与えています．
せっかくですから，もう少しこだわってみます．もともとの英語は，Safety Integrity Level ですから，「安全度」と訳したのでは，”Integrity” が残念なことにムシされてしまっています．「安全度水準」は数は増えているのですが，どうもLevelを丁寧に二度訳しているだけで，”Integrity” はやはりムシされているように思います．「安全整合性水準」は，この例のなかで，唯一 Integrity に取り組んだ訳語になっています．しかし，どうも整合性というのは，ここではピンときません（その訳語が適切な場合もあると思いますが）．
OEDにおいて，Integrity は，次のような明快な意味を与えられています．
The condition of having no part or element taken away or wanting; undivided or unbroken state; material wholeness, completeness, entirety.
即ち，端的には，欠落がないということです．ということでASILに対する私の（長い）訳語案は次になります．
乗用車の安全に関する完全度
私の日本語の語彙が少ないせいで長いのですが，少なくとも安全度とするより正確だろうと思います．ちなみに，フランス語だと以下になります（Part-9の規格のタイトルページから）．”les niveaux d’intégrité de sécurité automobile“．個人的には，先の日本語との相性は良いように思います．
***
さて，結局の所，レベルというのは道具に過ぎないというのは良いと思います．ASILを定めるというのも，分析段階（26262で，3-7）ですから，それは開始点に過ぎません．システム（アイテム）が置かれている位置に対して単に色分けをしてみます位の意味しかないだろうと思います．一方で，61508は少し違っていて，SILのレベルに従った故障率が定まっています．本来設計によって定まる故障率が開始点で決められているということになります．これはALARP原則を前提としているからで，そうではない26262が異なった対応となっているのは（整合性は良いのか，或いはALARP原則については同様に主張しているのではないか，ということをとりあえず等閑に伏すと），少なくともソフトウェアの視点からは適切に思います．
SILの設定は，必ずしも安全確保において必然というわけではありません．道具にすぎないのですから．英軍の規格である 00-56 （Safety Management Requirements for Defence Systems）の現在の版（Issue 4）では，かつて存在したSILは，いまは含まれていません．
（nil）
ALARPという原則があります．安全性に関する用語で，As Low As Reasonably Practical の略になります．リスクを実際的なレベルに低くする．もちろん，それは合理的に説明できるものでなくてはならない（reasonは，OEDによると古いフランス語から来ています，今でも，フランス語で「正しい」というのは，avoir reason で，正しいためには，そうである理屈を持たないといけない．正しいというのは俺は信じているという精神ではなく道理があるということだ，というのは，必ずしも同値ではなく，一つの考え方ということになるかと思います）．ALARPは，良く安全性に関する議論や教科書にでてきますし，IEC61508でも，それなりのページを使って説明しています．しかし，これはISO(/FDIS) 26262のような（乗用車を対象とする）規格だと，相性が悪いことになります．
簡単には，次のようになります．リスクの上限下限を，様々な条件（社会的な許容限度，技術的限度）から定める．リスクの下限は，BSO（Basic Safety Object）と呼ばれる目標値で，これ以下であれば，まあよしとする．リスク上限は，BSL（Basic Safety Level）と呼ばれる許容限度になります．ALARPというのは原則自身やモデルの説明にも使いますが，このBSOとBSLの間を指しています．この間で，できるだけリスクが低くなるように合理的に努力するということとなります．BSO以下はムシしてよいし，BSL以上は，相手に出来ないので，エンジニアリングとしては扱わないということになります．例えば，原発で破壊的な事故が発生し被曝するというリスクに対して，それに対処できないのであれば（BSLを超えるならば），そのBSL以上のリスク度を持つ場所には，人を居住させないようにするといった対処をとるということになります．これはエンジニアリングを超えています．かくのごとく，ALARPはもともと原発や化学プラントのような施設と社会との関わりのなかで考えられてきました．一方で，ISO(/FDIS) 26262が対象とするような乗用車ドメインでは，対象が限定的になります．ある車の障害が，一次的に社会に影響を及ぼすわけでありません．
別の相性の悪さもあります．例えば，ソフトウェアのばあいは，系統的故障となると云われますが，意地悪く云えば，確率的に計算できない故障カテゴリということです．従って，合理的に目標値（BSO）を定めることができません．更には，ソフトウェアに限らなくても，その使われる環境の多様さ，ユーザが訓練されたオペレータではなく一般人であることもまた，目標値の設定を難しくします．
IEC61508に対してC規格であるISO(/FDIS) 26262が，このALARPの扱いに関して，余りに収まりがわるいということは横に置くとして，ここでは別の原則についても考えてみることにします．
GALEと呼ばれる原則があります．Globally At Least Equivalent の略です．フランスにおける安全性の原則で，こちらはGAME（Globalement Au Moins Équivalent）或いは，GAMAB（Globalement Au Moins Aussi Bon）がオリジナルになります．比較対象は，既存のシステムになります．既存のシステムを改良したときに，安全性は良くならなければならない．少なくとも同等でなくてはいけないということになります．
常に自動車を一から設計することはきわめて稀ですから，実務的には，GALEの方が心が落ち着きます．しかし，何をして同等とするかについては，問題は残ったままとなります．
（nil）
昨年パリのChamps-Élyséesで見かけた究極のエコカー?
先週の土日に観音崎で開かれたSEA-SPINの世話人会での議論から，考えたことを少し書いてみます．SEA-SPINというのは，ソフトウェアのプロセスについて関心ある人の集まりです．さて，プロセスの話をしていて，ふと横をみるとプロダクトが伴走してることが多いと感じます．典型的には，「プロセスが良いとプロダクトは良くなるのか?」といった類の質問として現れていると思います．しかし，この問いそのもは間違っているだろうと思います．
ソフトウェアにおいて，プロセスを考えるというのは，一般のものつくりにおけるプロセスとは分けて考えないといけないだろうと思います．ものつくりにおけるプロセスというのは，偏差の制御ですから，その制御を行うための手順を如何に定めるかという点にあります．一方で，ソフトウェアは一品生産ですから，そもそも基準値を引くことが困難であったり，通常は不可能ということになります．もちろん，むりやり基準を作ることもできます．例えば，コード1行を一つのものと考えると，一時間に何個生産できるという基準値を作ることができます．しかし，それが無意味であることは，プログラムを書いている人なら良く分かるだろうと思います．
かくのごとく，ソフトウェアを作るということは，一般の製造とは異なる行為であるにも関わらず，多くのソフトウェアのプロセスの議論は，成功した製造業での流儀を用いようとしています．その帰結はあきらかなように，私には思えます．我々に必要なのは，安易な敷衍ではなく，いくばくかの「合理性」だろうと思います．
***
その例を少し考えてみます．通常のプロセスの意味で，プロセスの規定を担保するのは人間になります．それは，例えば，ソフトウェアの設計品質を，プロセスで規定しようとすると，最終的にはレビューを必要とし，誰もそのレビューが妥当であることを機械的に評価することはできません．通常のプロセスの意味では袋小路に入ります．レビューが妥当かどうかをレビューするといった具合に．大事なのは，レビューをすることではなくて，ある文脈のなかで，そのレビューが妥当であることを合理的に説明できるときに限られます．そうして，初めて，円環を閉じることができます．
プロダクトについては次が参考になります．Lazzaratoさんの無形労働の議論は，ソフトウェアの作るものは有形物としてではなく，社会に働きかける無形のものとして捉えるべき，としています．そこでは，ソフトウェアが単にbit列だから見えないということではなくて，一種の完成系としては存在し得ないということを示しています．
以上の議論から，（製造メタファに由来する）プロセスの議論もプロダクトとしてのソフトウェアの議論も，そもそもがソフトウェア（作り）の本質から遠いところにあるということが分かります．
***
いま，必要なのは単純なプロセス／プロダクトのdichotomyではないだろうと思います．実践的には，よりインスタンスとしてのプロセスに寄り添うことですし，メタには，「合理的なプロセス思考」というものが必要なのだろうと思います．後者に関して云えば，よく成功事例（best practice）の名のもとにインスタンスの共通項を探そうとしますが，それはそこに共通項があるという前提に立てるときにのみ成功します．ソフトウェアプロセスに関しては，多くの場合は，単なる物語の集合としてしか存在できず，物語としては面白くても，それが有益である保証は全くありません．「合理的なプロセス思考」というのは，共通項を探すと云うことではなくて，あるプロセスの構成要素の意味を合理的に考えると云うことです．また，そうすることでのみ，プロセスの議論に意味があるのだろうと思います．
***
さて，今回のタイトルは，（学生時代に私も講義を受けた）廣松渉さんの著作「もの・こと・ことば」から持ってきました．この単行本の帯は，「物的世界像から事的世界観へ！」となっています．このテーゼは廣松さんの著作のあちこちで使われています（その他の本のサブタイトルにも）．今回の内容に即して云うと，物象化的錯視状態にあるものとしてのプロセスを解放する！ということになるでしょうか．
(nil)