リスクの生じやすさと，リスクの結果生じる事態の起こりやすさを，混同すべきではない． (p.94)
リスクを安全性に限定すると，冒頭のことばは，次のように言い換えることができる．
ハザードの生じる確率と，危害が生じる確率を，混同すべきではない．
ここはちょっと注意が必要である．前回見たようにリスクの定義は危害の発生確率と，危害によって生じた場合の重傷度から計算できるものである．原書での議論は，コトバの使い分けからすると，前者をハザードとするのが適当である．
これは，重要な点である．ハザードが顕現したからといって，システムとしてだめになるとは限らない．更に，システムとしてだめになったからといって，危害があるわけではない．即ち，信頼性がないからといって，そのことだけで，安全性がないとはいえないのと同じである．
一般に，危険源と訳されるハザードについて，ISO 26262 の定義を見てみる．
potential source of harm (1.56) caused by malfunctioning behaviour (1.73) of the item (1.69)
NOTE This definition is restricted to the scope of ISO 26262; a more general definition is potential source of harm.
危害の潜在的な源．アイテムの機能不全によるふるまいによって引き起こされる．
注記：この定義は，ISO 26262 の範囲に限る．一般に潜在的な危険源はより広い範囲である．
ちなみに機能不全によるふるまいとは，「故障や設計意図に反したふるまい」を指している．
ISO 26262 が含まない危険源は，規格の最初のスコープ項にある．
It does not address hazards related to electric shock, fire, smoke, heat, radiation, toxicity, flammability, reactivity, corrosion, release of energy and similar hazards
電気ショック，火災，煙，熱，放射線，毒物，可燃性，化学反応，腐食，エネルギー放出，その他の類似のハザードは含まない．
さて，話を戻す．危険源があって，危害が生じる．この間には何があるのだろう．
例えば，ハーネスを止めているブラケットが折れる．それによってハーネスが振動し，摩耗により断線する．リアランプの一つが点灯しなくなる．夜間後方を走行している車は，二輪者だと思い，側方を通過しようとして衝突する．ここで，故障車のドライバおよび後続車ドライバに危害が生じる可能性が生じる（但し，規格が対象としているのは，前者のみである）．
ブラケットが折れる，から始めると，スコープ外となるが，それでも危険源が表に現れることが，直ちに危害につながっているわけではない．走行中ハンドルにロックが掛かれば，すぐに危害につながる可能性が高い．しかし，全てが危害に直結しているというわけではない．
重要なのは，（ドライバーに）危害が生じないことである．一般のリスク度は，危険源の発生確率とそれが生じたときの影響の大きさの積となる．ASILの計算では，ドライバが対処できるか，もその計算に含む．容易に避けられるならば，危害が生じることが少ない．そのため，更に，ドライバの回避可能性も加味する．
回避可能性を含むのが正しいかは，議論だと思う．しかし，レベル2やレベル3の自動運転の回避可能性とは一体? と考えてしまわないでもない．概念的に正しいことと，それを実際に適用することの難しさは別である．
少なくとも，現状，ASIL計算に人間系が含まれている以上，適切なドライバモデルが必要になる．いかなるドライバのユーザタイプを，我々は用意すれば良いのだろう．
（この項，更につづく）
（nil）
多くのソフトウェアプロジェクトの失敗は，理想化しすぎたシステムを，考えがちであることに起因している．(p.93)
冒頭にあるように，プロジェクトの初期段階では，みんなが夢を描く．それは，大事なことには違いない．夢がなければ，誰もそのプロジェクトを進めるようとする意欲を持たない．しかし，どこかで冷静にリスクを見よう，それによって要求も適切なものにしよう，というのがリスク分析の目的である．
リスクとは
リスクは，このブログのタイトルにもしているので，ISO 26262 の定義も用いながら，しばらくは詳しく見ることにする（26262は，どうしてこんなに魅力的なのだろう！）．ちなみに，KAOS原書では，リスクの種別（3.2.1）は1頁に満たない．
以下は，ISO 26262 の定義である（これは規格の世界では，一般的な定義である）．
combination of the probability of occurrence of harm (1.56) and the severity (1.120) of that harm (1.99)
（リスクとは，危害の発生確率と危害の重大さの組み合わせである）
この規格が着目しているのは，安全性なので，危害（既に人体に悪影響が生じている）となる．プロジェクトの話ならば，「リスクとは，プロジェクト失敗の発生確率とプロジェクト失敗における重大さの組み合わせである」となる．また，組み合わせというのは，それぞれ（危害の発生確率，危害の重大さ）が数値化（通常は，0から１の範囲）されたとすれば，その積として表現される．事象は，普通複数あり，全体しては，その和となる．
残存リスク 規格によっては残留！リスクというコトバもある[/re]（residual risk）というコトバもあり，その定義は，次のようになる．
risk (1.99) remaining after the deployment of safety measures (1.110) (1.97)
（安全機構を付加した後に残るリスク）
全てのリスクを除外することはできないというのが，ポイントの一つである．いつ小惑星が地球に衝突するかもしれない．そんなマレなことは考えなくても，宇宙線は降り注いでおり，いつビット反転しても不思議はない．
さて，良く話題になるASILの定義は次の通りである．
one of four levels to specify the item’s (1.69) or element’s (1.32) necessary requirements of ISO 26262 and safety measures (1.110) to apply for avoiding an unreasonable residual risk (1.97), with D representing the most stringent and A the least stringent level
（4つのレベルのうちの一つ．レベルに従い，アイテムないしはエレメントのISO26262に必要な要求を特定し，非合理な残存リスクを避けるための安全機構を特定する．Dが最も強く，Aが最も弱い）
ちょっと混乱を招く定義ではと思う．前段には，「アイテム」というコトバがある．このアイテムは，規格では，特殊な使い方をしており興味深い．ずいぶん前に，その一端について書いている．ASIL付与の目的は，残存リスクを避けるということである．残存リスクについては，この一つ前の定義である．
さて，ややこしいが，順番に考える．
最初にアイテム定義をする．ハザード分析とリスク評定を行ったあとに，アイテムにASILを付加する．先に，アイテム・エレメントとなっているのは，アイテムがシステム，それからその構成要素としてのエレメントに展開される時に，最初にアイテムに対して与えたASILも紐付いていくからである．要求（実際には安全要求）や安全機構も同様で，紐付いていく．
そうすると，中心となるASIL定義は，「アイテムに対して，リスクを計算し，システムが達成すべき十全性を段階的に表現したもの」ということに尽きる．エレメントも安全要求も安全機構も（最初は）関係ない．
特に，3-7.4.1.2に注目すべき．
The item without internal safety mechanisms shall be evaluated during the hazard analysis and risk assessment, i.e. safety mechanisms intended to be implemented or that have already been implemented in predecessor items shall not be considered in the hazard analysis and risk assessment.
ハザード分析およびリスク評定中，内部的な安全機構なしに，アイテムを評価すること．即ち，組み込もうと考えている安全機構や，既にアイテムに組み込まれている安全機構（アイテム改変の場合）は，ハザード分析およびリスク評定中は，考慮しない．
これが，ISO 26262 の画期的かつ，理想を求めた「美しい」姿である．
メタに考えると，冒頭のように，理想を求めることによるリスクも想定できるのだが，それはさておこう．
（この項つづく）
(nil)
特定の解決策に飛びつく代わりに，普通は他の代替策がないか，探した方が良い．（p.92）
ここでは，幾つかの衝突の解決策を提示している．最初は，これまでの要求抽出技術を使用する．特に，インタビューやグループセッションが効果的としている．インタビューでは，要求の理由を直接問うことができる．グループセッションは，そもそも利害関係者が集まって調整する場所である．ちょっと同語反復的だが，その場は，衝突の解決の場でもあり，もちろん有効である．
上記の他に，衝突解決のための利用できる幾つかの考え方が，ここでの主題である．この方法は，演算子を用いて，要求を操作するという，おもしろいいい方になっている．要求に，演算子を加えて「操作」することで，衝突のない要求に変更するということである（今回の説明は，バイアスが少しあるかもしれない．私自身の方法とラップしている部分があり，偏った説明になっているかもしれない）．
境界条件を避ける
以前の図書館システムの例で，2週間以内に返してもらわないと困る，という図書館スタッフの要求と，必要なだけ借りたいという借り手側の要求があった．「2週間」が，ここでの境界である．この境界条件をなくすというのが，ここでの「操作」である．
この「操作」は，次の場合に，有効な解決策となる．必要とする人が図書館に来た時に，貸し出し中で読めないのは困るというのが，スタッフが2週間とする理由だとする（そもそも2週間でも不適切かもしれない．しかし，折衷として期限を切ったとする）．いま，境界条件を消したので，誰でも好きなだけ借りることができるようになる．多数の「あの本はないのか？」で，スタッフは攻められることになるかもしれない．
ここで，あきらめないで，更に思考実験を続ける．
どの本が，どれくらい必要とされるかの傾向を見る．貸出が重なる可能性がある本については，同一本を複数用意することとする．そのうち，かつ，一定数は，貸し出ししないこととする（実際に多くの図書館はそうしているに違いない）．
これで，上記の問題は解決し，かつ境界条件をどうするかで，悩む必要もなくなる．もっとも，スタッフの期限を切る理由が，別の場所にあれば，別の解決策が必要である．例えば，無期限にすると，誰も返却しなくなるからという理由．要求のもとになる理由を知ることは，いつでも重要である．
衝突している要求文を保持する
ここでの操作としては，要求に対して，新たな内容を付け加える．前述の例であれば，2週間という期限は残す．但し，「待っている人がいなければ，返却した直後に，再度同じ本を借りることができる」という但し書きを加える．図書館に来た人は，最大2週間待たないといけないかもしれない．しかし，もし期限を設定する理由が，「無制限にすると返却されない」ということならば，最大待つ期間は分かり，かつ，借り手の必要なだけ借りるも（新たな読み手が現れない限り）満足する．
衝突している要求文を緩和する
次のような但し書きをつける．「もし，2週間を超えて保持する許可を明示的に得たならば，必要な期間借りることができる」．これは，前述の但し書きと似ている．
操作としては，衝突している文の合成と見なすことができる．
優先度が低い要求を取り下げる
これは，もっとも単純である．優先度が，要求文に付加されていれば，そこで足きりするという操作になる．ただ，利害関係者で優先度が異なるときに，どうやって，適切な優先度を付加するのかという，別の問題を生む．
衝突の原因あるいは対象を特殊化する
これは，要求文に含まれる対象（主語であったり，目的語）を操作する．要求：「ユーザは，本の貸し出し状況を知ることができること」と要求：「学生は，どのユーザが本を借りているかが知ることができないこと」は，衝突する．これは，最初の要求の主語である「ユーザ」を「スタッフユーザ」に特殊化することで，たちどころに解決してしまう．
今回のように，問題解決のときに，書かれている文に対して，操作するというのはきわめて有効な手段である．解決策について，ただ思い悩むより，遙かに生産的である．また，単に解決策だけではなく，課題を見つけるときにも使用できる
今回メインの例は，図書館システムであった．読む本は，必ず買うようになってから，図書館には行かなくなった．しかし，よく利用していた時代を思い出すと，少し心が痛む．
(nil)