自動車の安全水準からプログラミングに関するヒントを得る

どうも、株式会社プラハCEO兼エンジニアの松原です。

ASILと呼ばれる自動車の安全水準に関する規格がプログラミングにも活かせると常々考えているため、こちらの記事にまとめてみました。普段の意思決定のお役に立てていただけたら幸いです。

(自動車に関する仕事をしていたのは早くも10年近く前なので、もしASILに関する認識が間違っていたらご指摘ください!)

TL;DR

開発に関する意思決定をする時は以下3つの基準で考えてみる

• 重大度
• 曝露可能性
• 制御可能性

ASILとの出会い

僕は新卒で自動車の部品を開発する会社に入社しました。

気づいたらバイクに乗ってサーキットを走り回るテストライダーになり、命がけで毎日働くうちにメンタルをやられて退職したのですが、バイクでウィリーができるようになる以外にも様々な学びが得られました。その一つがASILです。

ASILとは何か

自動車部品の安全性に関する規格「ISO26262」に登場する考え方です。

自動車は人命に関わるため品質は妥協できません。一方で自動車は数万点の部品が組み上げる非常に複雑な製品なので、すべての部品に同じ時間をかけて品質を保証していこうとすると、とてもコストが見合いません。

コストをかけてでも検査を厳重に行うべき部品と、そうでない部品をレベル分けして考慮していくためのフレームワークがASILです。

例えば次のような車があったとします。

• ワイパーがよく壊れる車
• ブレーキがよく壊れる車

絶対に後者の方がヤバい車だと感覚的には理解できるのですが「ワイパーよりブレーキの方が大事な（壊れたらまずい）部品だよね」と誰もが納得しやすいよう、以下3つの基準に照らし合わせて考えるのがASILの根本的なアイデアです：

• その部品が壊れたらどれだけ重大なハザードが生じるのか
• ドライバーが上記のハザードに直面する確率
• その部品が壊れたときドライバーがどこまで状況に対応できるのか

ASILでは各基準ごとにA~Dでリスクを評価します。Dが最も危険、Aが最も安全です。

ASILに則って考えてみる

まずワイパーについて考えてみます。（webエンジニアに向けた説明のため大幅に簡略化しているため自動車エンジニアが見たら「おいおいそんなシンプルじゃないぜ」と思われるかもしれませんが、そこは目を瞑っていただけると幸いです...! 🙇‍♂️）

• ワイパーが壊れたらどれだけ重大なリスクが生じるのか　→ ちょっと雨天で運転しづらくなる程度なので低く見積もれる
• ワイパーが壊れたときドライバーが深刻な状況に直面する可能性 → 雨天時のみ影響を受けるので低く見積もれる
• ワイパーが壊れたときドライバーがどこまで状況に対応できるか → ワイパーが視界の邪魔になっている場合は車を止めて手でワイパーをどけられるので低く見積もる

では今度はブレーキについて考えてみます。

• ブレーキが壊れたらどれだけ重大なリスクが生じるのか　→ 高速走行時に発生した場合は深刻な人命に関わるハザードに直面する
• ブレーキが壊れたときドライバーが深刻な状況に直面する可能性 → 車を運転する時間のうち何割を高速走行するのか考慮する。あるいは低速走行であっても市街地であれば深刻な状況に陥ることもある
• ブレーキが壊れたときドライバーがどこまで状況に対応できるか → 低速走行であればサイドブレーキで回避できる可能性はあるが、高速走行の場合は回避する術がないため非常に深刻

こんなふうに共通の基準を使って比較してみると部品毎のリスク・アセスメントが捗るのが、なんとなく実感いただけたのではないでしょうか。

余談ですが「ブレーキブースターが故障したらドライバーには何もできない説」という水曜日のダウンタウンみたいな検証のために、何の前情報もなくテストサーキットを自動車で運転させられ、突然目の前に人型の模型が飛び出してくると同時に電子制御でブレーキブースターを停止される、という試験を課されたことがあります。

試験担当者としては「ブレーキブースターが壊れたらやっぱり人間は何もできないよね」という方向に持っていきたかったらしいのですが、模型が飛び出てくると同時にブレーキペダルをへし折るぐらいの力で踏み込んだら問題なく止まれてしまったので「一般的な反射神経と脚力ではないためノーカウント」と異常値として扱われ、それ以降の検証に呼ばれなくなりました。

ASILをWEB開発に応用できないか

このASILの考え方は自動車の部品に限らずWEB開発にも応用できる概念ではないでしょうか？

例えばデータベース設計の際に「このテーブルを分割すべきだろうか」と悩んだら、こんな風に考えを整理できそうです:

• テーブルを分割しなかった時にどれだけ重大なリスクが生じるのか → 仕様変更に対応する工数が増えるだけなら大したリスクではないが、売り上げに直結する既存ユースケースが実現できなくなるのは重大なリスク
• テーブルを分割しなかったときに深刻な状況に直面する可能性 → とはいえ上記のユースケースはサービス全体の利用者の0.5%しか通っていないのでリスクは少し少なめに見積もっても構わない
• テーブルを分割しなかったために問題が起きた際、開発者がどこまで対応できるか → 本来必要なデータが失われてバックアップもリテンション期間を過ぎた場合は開発者にできることはない。バッチ経由で他のテーブルから導出できるのであればリスクは少なめに見積もれる

ついつい解決策を考える際「こういう問題が起きたらどうしよう...」とワーストケースを考えがちですが、問題が引き起こすリスクの重大さの他にも「それが深刻な影響を及ぼす確率」「発生したとして復旧の容易さ」も併せて考えないとリスクを過大評価してしまう気がするのです。

「そのリスクがどれだけ重大か」「どれだけ頻繁に起こり得るか」などは当人の経験や感性に大きく左右されるので、これはASILが本来の文脈(自動車部品の評価)でも抱えている問題なのですが、僕は判断に悩んだときこの基準を採用すると意外とすんなり結論が出ることが多かったので、もしよければ試してみてください

まとめ

意思決定をする時は以下3つの基準で考えてみる

• 重大度（各案がどれだけ深刻な事態を招く可能性があるか）
• 曝露可能性（その深刻な事態はどんな確率で起こり得るのか）
• 制御可能性（その深刻な事態が起きたとき、エンジニアにできることはあるのか）