ソフトウェアの特性を考慮せず事故が起きた事例

【1985年～1987年に起こった放射線治療器 Therac 25（セラック25）の事故】

Therac-25は高エネルギーの透過性放射線を患者の身体の奥に照射し、周囲の組織を傷つけることなくがん細胞を破壊する装置で、巨大なアームの照射口からは、電子線とX線の二種類の放射線が照射される。

 透過性の高いX線を生成するときは、高エネルギーの電子の流れを金属製のターゲットにぶつけ、電子線生成モードのときは、金属のターゲットを自動的に移動して電子線のエネルギーレベルを下げ、直接腫瘍にビームを送る。低エネルギーの電子線はX線より透過性が低いため、皮膚の表層に近いがんの治療に使われた。Therac-25はいわゆる組込みソフトウェアで動く機器だが、1980年台の装置でソフトウェアはPDP-11（※1） というミニコンピュータを使って制御を行っていた。

※1 PDP-11 は、ディジタル・イクイップメント・コーポレーション(DEC)が1970年代から1980年代に販売した16ビットミニコンピュータシリーズ。

Therac-25 の事故では複数の医療機関で放射線治療装置が誤動作し、過大な放射線を浴びた患者に死傷者（6名）がでた。この事故はソフトウェアの不具合が原因であり、見えないソフトウェアのせいで再発防止が進まない中、ナンシー・レブソン（現マサチューセッツ工科大学教授）らの努力により事故原因が詳細に調査され、レポートが発表されており、このレポートは20年以上たった今でも、ソフトウェアエンジニアにとって深い教訓として伝えられてる。（※『セーフウェア』 翔泳社 2009 に詳細が記載されている。インターネット上ならば、こちらでも英文でレポートを読むことができる）

Therac-25 の事故は20年以上も前に起こった事例だが、ナンシー・レブソンの詳細な調査により現代にいろいろな教訓を残した。

【Therac-25 は Therac-20 の後継機だった】

普通、後継機種の場合「枯れた」ソフトウェアを再利用できるため、安全や信頼は増す。実際、ソフトウェアの大半は　Therac-20のソースが使われていた。

それなのに何故事故が起きたのか。誤解されたくないので、ここで注釈を入れておく。ソフトウェアが絡んだ事故は「○○だから××である」といったように簡単には語れない。プリウスのブレーキソフト改変に関する分析だって結構な時間と労力をかけて書いた。（しかも、本当のことは分かっていないし、ソフトウェアの問題ではないかもしれない。）だから、本当に Therac-25 による事故の原因を知り、自分達のドメインの再発防止に利用したいのなら、必ず原本を読んでいただきたい。ここでは、あえて、複雑な問題発生の原因のうちの一端のみを紹介する。努々ここで紹介したことだけで6名もの犠牲者がでるような事故に発展したのではないことを理解していただきたい。20年も前のソフトウェアエンジニアだって、そこまでいい加減ではないということを強調しておく。

さて、枯れたソフトウェア資産を再利用しているのになぜ事故が起こったのかの。そもそも Teharc-20 のソフトウェアに混入していた不具合をハードウェアの安全装置でブロックしていたが、Therac-25 でその安全装置を取ってしまったことが原因の一端となっている。（実際、この安全装置が Therac-25 にも付いていれば最悪の事故は免れたと考えられている）

Therac-6 や Therac-20 では独立した安全装置が異常エネルギーの出力をブロックしていた。

そして、Therac-25 の開発をする際に、経済性の理由（たぶんコストダウンだろう）から、このハードウェアの安全装置をソフトウェアに置き換えた。そして、それによってもともと Therac-20 に内包していた不具合が表面化してしまった。（実際にはそんな簡単な話ではないがここでは簡略化して書いている）

当然のことながら、機器の品質保証担当は「そんなことして大丈夫か？」と思っただろう。そこで、Therac-25 の製造もとである AECL は1983年3月に Therac-25 に対する安全解析を実施した。

この分析は FTA（フォールトツリー解析）で行われた。FTA と FEMA は非常に有名な安全解析の手法なので、初めてこの言葉を聞いた方は インターネットでどんなものか理解しておいて欲しい。

この安全解析の結果 AECL は次のような報告を出した。

【『セーフウェア』 Appendix A.2 より引用】

1. ハードウェアエミュレータ上と遠隔治療装置の照射野条件の下で大規模な試験を行うことにより、プログラミングエラーは減少していた。未解決のソフトウェアエラーは分析には含まない。
   
2. 
   ソフトウェアは長期使用、疲労、あるいは再生産プロセスが原因で品質が低下することはない。
   
3. 
   コンピュータの実行エラーは、ハードウェアコンポーネントの欠陥や、α粒子や電磁ノイズによって引き起こされる「ソフト」（ランダム）エラーが原因である。
   

このレポートは複雑なソフトウェアを作ったことがない人が書いたのだろう。解説すると、1は、「ハード・ソフト込みのシステム（ハードウェアはエミュレータ）でさんざんいろいろな試験を行ったのでバグはほとんど潰した」ということだ。ハードウェアはエミュレータを使っているので異常状態、故障状態も再現できているので心配ないという主張だ。

残念ながらTherac-25 の事故から20年以上たった現在でも、ほとんどの機器がこの方法でシステムの安全を確認している。そして、そこにソフトウェアが絡んでおり、ソフトウェアの規模が大きく、複雑であればあるほど、そのやり方では漏れが生じる。

ちなみに、1で「未解決のソフトウェアエラーは分析には含まない。」は正直な申告だと思う。日本人ならこの一文は削除して報告しただろう。なぜなら、未解決のソフトウェアエラーが既存のシステムに影響を与えないという根拠は何もないからだ。そして、この安全解析報告の作成から実際の製品のリリースまでの間にソフトウェアが改変されたらその改変がデグレードを誘発しない保証はない。

2の「ソフトウェアは長期使用、疲労、あるいは再生産プロセスが原因で品質が低下することはない。」はハード屋さんがソフトウェアをどう見ているか端的に表している。ようするにハードウェアでは部品の故障や生産時のさまざまな問題があり、品質保証の活動とはこれらの問題をいかに押さえ込むかが我々の仕事なのだ、その点ソフトウェアは何回コピーしても品質が劣化しない、すばらしい、品質は完璧だと考えているのだろう。今となってはソフトウェアの不具合で商品をリコールすることは日常茶飯事になっているから、QA担当もそうは思っていないだろうが、多くのQAはソフトウェアは分からない、自分では品質を保証できないから誰かお墨付きをくれ！と考えているような気がする。

3は笑ってしまうが、ソフトウェアの実行エラーは放射線などでメモリーのデータ化けなどが原因であり、バグは1で潰しているから、ハードウェアや外部環境の影響からプログラムやデータを守れば大丈夫だと言っているのだ。

実際この安全分析の FTA には障害を発生させる原因コンポーネントとして、「コンピュータの故障」も含まれている。そして、「コンピュータが誤ったエネルギーを選択する」が発生する確率は 10のマイナス11乗で、「コンピュータが誤ったモードを選択する」が発生する確率は4×10のマイナス9乗となっている。

この発生確率は後にナンシー・レブソンらの分析によって何の根拠もないと結論づけられたが、その当時はおそらく　PDP-11 がハードウェア部品として故障する確率を示したのだろうと予想される。

このことから安全解析実施者はソフトウェアやソフトウェアの不具合についてほとんど知識がなくブラックボックスとして分析をしていることが分かる。

ソフトウェアの恐いところは、どんなに難しいオペレーションでなければ発生しない不具合でも、その通りに操作すると100%確実のその不具合は発生するということだ。その結果、Therac-25の場合は約3年間の間に 6名の犠牲者を出してしまった。

現在、トヨタのリコール問題でアメリカが騒いでいるのは、犠牲者が増えることをできるだけ抑えるための手順、プロセスを組織が定めて、それを確実に実施しなさい、また、その手続きの間に隠蔽や怠慢などがあったら絶対に許さない、責任はトップにあると言っているのだと思う。

事故が発生したときのオペレーションはその通りなのだが、ソフトウェアが絡んでいるときは困ってしまう。原因が簡単にはわからないし、事故の発生確率をはじき出すのが難しいからだ。だから、ソフウェアがらみのときは、事故の重大性だけでランクを判定する。例えば

※仮にソフトが関係していたと仮定して

・アクセルペダルが戻らない→重大

・低速でブレーキが抜ける感覚がある→軽微

・アクセルが急加速する→重大

といった具合だ。（ソフトウェアが原因だった場合は発生する確率は考慮できない）
国際安全規格のリスク(risk)の定義は危害(harm)の発生確率×危害の重大(severity)である。しかし、ソフトウェアに起因するリスクにおいては発生確率はハードウェアの部品故障率のようなものにはできない。原因が分かってしまうと直せるなら直せと言われてしまう。

今後、ソフトウェアをブラックボックスにしかとらえられないハードウェア出身の組織上位層や品質保証担当が、自組織や協力会社が作ったソフトウェアの安全性や信頼性について第三者に安全性や信頼性についてお墨付きを付けてもらおうという動きが増えることが目に見えているが、ここではっきり言っておくがその考え方では絶対に安全は確保できない。

なぜなら、大規模複雑化したソフトウェアの各サブシステムの統合時のわずかな検証漏れ、設計コンセプトの考え方の違いなど、設計者達のヒューマンエラーに起因した問題は、設計サイドの技術者がアーキテクチャを可視化して、自分達で問題点を見つけないと見つからない可能性が高いからである。

アメリカ人に責められたらサムライになれ

20年以上前アメリカ人の監査官とソフトウェア品質についてやり合ったことがある。自分の作ったソフトウェアに対していろいろ質問され、こんな性格だから自信持ってキッチリ答えたつもりだった。

だけど、判定はクロだった。そのときはなぜダメなのかまったく理解できなかったが、後から彼らが求めていることについて調べていくうちにだんだん分かってきた。

【判定クロの理由】

• エンジニア個人の成果はその個人に由来するものであって、組織的な安全性や信頼性を担保するものではない。検証結果があるだけではダメで、検証の範囲、合否判定基準を明確化し、漏れなく実施するという組織的ルールが存在し、それが実行されていることが求められる。
• アメリカ人はあらかじめルールを公開している。そのルールを事前に読んでいない、知らなかったは許されない。フェアーに対してアンフェアーな対応は絶対に許されない。
• 責任あるものの承認行為が必要である。責任あるものはその責務を全うするための資格を持ちトレーニングを受けている必要がある。

自分は20年前の若かりし頃、エンジニア個人としての自信を打ち砕かれる出来事があってから、猛然とアメリカ人が求めていることを学習し理解することに務めた。そして、学習すればするほどアメリカ人の考え方と日本人のエンジニアの考え方に大きなギャップがあることを痛感した。

だから、それ以後ずーっと、アメリカ人と日本人の違い、欧米で体系化された方法論が日本で形骸化する理由について考えてきた。

アメリカ人はフェアーとアンフェアーに非常にこだわる。特に瑕疵（欠陥）があることを知っていたのに隠していたりすることは絶対に許さない。そして、それを見つけたとき末端の作業者ではなく必ず責任者を非難し罰する。

だから、疑いをもたれたら自分達の正当性を責任者が自信を持って説明しなければいけない。日本人はなかなかこれをとっさにはできない。常日頃、責任と権限について考え、アンフェアーを許さないスタンス、言動と行動をとっている必要がある。

曖昧でどっちつかずの対応をしている日本のエンジニアはアメリカ人に責められると徹底的に守勢に回ってしまう。そしてびくびく、おどおどしだし、いろいろな質問に対してグレーなことを指摘されると YES / NO を答えずに言い訳をし始める。そんなシーンをこれまで何度見てきたことか。

品質問題に関してアメリカ人に対峙するときのポイントはつぎの5点だ。

1. アメリカにおけるルールをおさらいし頭にたたき込んでおく。
2. そのルールに逸脱しているのかしていないのかという視点だけで物事を考えるようにする。
3. 質問の意味が曖昧だったり、個人の主観に見えたときは臆せずにどのルールに基づいた質問であるかを聞く。
4. ルールに反していないのなら自信を持ってその正当性を主張する。
5. グレーだと思ったら白の要素の根拠を説明し、言い訳はしない。

好き嫌いは別にして、こういう訓練をしているとだんだん日本人の問題点が見えてくるのと同時に、自分自身に武士の魂が宿ってくるような気がするから不思議だ。

豊田社長にはアメリカ議会の公聴会でサムライとして堂々と質問に答えてもらいたい。

※『サムライエンジニア再び』も参照されたし。

P.S.

現在、ソフトウェアの安全と信頼を実現する方法について書いた本を執筆していて、最終段階の校正をしている。3月の終わりの方には書店に並ぶようなスケジュールとなっている。それまでこのブログサイトで少しずつ本のコンセプトや内容の一端を紹介していこうと思う。

もちろん、このブログで主張していること、解説していることも随所に取り入れているので、ブログの読者の方々の期待を裏切らない内容となっていると思っている。

『組込みソフトエンジニアを極める』第4章「品質の壁を越える」にも結構書いているんですけどね。

“品質の壁” は、組込みソフトに求められる安全性や信頼性をクリアするために越えなければならない目標です。組込み製品は人の生活に密着しており、組込みソフトは組込み製品をコントロールする頭脳となっているため、そこに不具合があるとユーザーに迷惑がかかるだけでなく、企業全体の信用も失墜してしまいます。企業にとっては製品回収の費用が利益を圧迫しているという現状もあります。組込みソフトエンジニアは、ソフトウェアの品質向上についての理論を理解し、プロジェクトや組織としてその理論を実践することで、製品の安全性や信頼性を確保します。組込みソフトを取り巻く世界は、グローバル化しつつあります。世界全体に広がった市場で、日本の組込み製品、日本の組込みソフトは品質が高いというブランドイメージを守り続けなければ、私たち組込みソフトエンジニアの足下も揺らいでいくでしょう。


『組込みソフトエンジニアを極める外伝』より

プリウスブレーキ制御ソフト改変についての考察 （訂正）

プリウスのブレーキ制御に関しては次々に新しい事実が分かるので過去の考察を訂正していかないといけない。

【いろいろな事実を総合して分かったこと（訂正を含む）】

• この問題はたぶんソフトウェアのデグレード（変更によって今まで動いていたところが動かなくなるミス）ではない。
• この問題は複雑化していたブレーキシステムの軽量化、低コスト化により、ブレーキシステムのハード・ソフトが変わった際に Validation（妥当性確認）の 漏れが生じたことからきている。
• 漏れがあったからといってトヨタやアドヴィックスがV&V(Validation & Verification)を十分に行っていなかった訳ではなく普通の企業に比べればよっぽど念入りにやっていた。（と予想する。）
• 軽量化やコストダウンの検討は悪ではなくエンジニアがトライすべきことだから、その流れは間違っていない。（だからデグレードではない。もとに戻してしまうと重量が重くなり、コストアップしてしまう。それは商品の価値を下げ、結果的に顧客満足度も下げてしまう）
• 結果的にソフトウェアの改変で問題を解決しようとしたがソフトウェア技術者のミスともいいきれない。（Validation のステージにおいてすべてのシチュエーションを想定して確認することは不可能）
• この問題は設計の工程で見つけられた可能性は低く、ユーザークレーム→原因分析→是正→水平展開という CAPA（Corrective Action & Preventive Action：是正処置及び予防措置）で改善する種別のものである。
• 結果的に今回の問題は受容可能なリスクと判断される。（実質的な安全性の確保とユーザーの気持ち悪さ、不安とは異なる）
• 上記のことから、今回の問題はエンジニアの過失はとは言い難い。

【Tech-On! 記事『汎用部品の活用で回生協調機能を低コスト化』を読み解く】

Tech-On! 記事『汎用部品の活用で回生協調機能を低コスト化』の記事を落ち着いてじっくり繰り返し読んでみた。日経Automotive Technology はすごい。どうして、トヨタのエンジニアでもないのにここまで詳しくブレーキシステムのメカニズムが分かってしまうのだろうと思う。

この記事をエンジニアではない一般の読者が読んでもよく分からないと思うので解説しながら内容を理解したいと思う。（途中、Tech-On!の記事をところどころで参照している）

【とんでもなく複雑化しているハイブリッド車のブレーキシステム】

プリウスは燃費を向上させるために、制動時に車両の運動エネルギーを回収する機能を備えた「回生協調ブレーキ」システムを搭載している。

ガソリンエンジンの車ではブレーキによって削減された運動エネルギーは全部熱エネルギーに変わる。プリウスは制動時の運動エネルギーでモーターを回し発電し発電した電気エネルギーをバッテリに蓄えることでエネルギーを回収している。

自転車のライトを光らせるときにこぎ手は負荷を感じるだろう。運動エネルギーの一部でモーターを回しそれを光に変えているからだ。でも坂道にさしかかると漕がなくてもモーターはまわりライトは光る。プリウスはいわばこのときのエネルギーをバッテリに蓄え燃費向上に使っているのだ。

回生協調ブレーキの基本的な作動原理は次の通りだ。まず、ドライバーがアクセルペダルから足を離した段階で、ドライバーに違和感がない程度に、軽い回生ブレーキをかけ、運動エネルギを回収する。次に、ドライバーがブレーキペダルを踏むと、ペダルを踏む速度と、ペダルの踏み込み量から、ドライバーが要求する制動力がどの程度かを判断する。この制動力の範囲内で、最大限の回生ブレーキをかける。そのうえで、回生ブレーキでは足りない分を油圧ブレーキで補う。

Tech-On! の記事には図が載っているのでそれも見ていただくとして、この部分を読んだだけでもとてつもなく複雑で繊細な制御をハード・ソフトでやっているのがわかる。以前読んだ記事ではプリウスは回生ブレーキと油圧ブレーキを切り替えていると書いてあったがそれは間違いで、回生ブレーキでエネルギーを最大限回収しておいて、それだけではドライバーが想定する制動力には足らないのでその不足ぶんを油圧の制動力で補っているのだ。

回生（モーターによる制動力）はリニアではない。ハイブリッドではない車のブレーキペダルを踏んぶんだけリニアに制動する感覚を再現するためには、リアルタイムかつセンシングとアクチュエータのフィードバックのハード・ソフトが必要になる。

この時点で安全アーキテクチャの基本であるシンプルデザインと安全をつかさどる機能・性能のアイソレーションは崩れかけている。しかし、これはしょうがないのだ。ユーザーニーズは多様化し、多様化したニーズを実現するためにシステムは複雑にならざるを得ない。

しかし、複雑にも程度はあって、ソフトウェアの場合指数関数的にぐちゃぐちゃにすることが簡単にできるので、ユーザー要求を満たすための最低限の複雑さにとどめておく必要がある。

そういう努力をおそらくアドヴィックスやトヨタはしており、たぶん、他の業界よりも進んだ取り組みをしていると予想する。それでもこぼれ落ちる問題は発生するのだ。

【なぜ、先代プリウスでは発生せず、新型プリウスでは問題が起こったか】

Tech-On! の記事によると、先代プリウスは回生協調ブレーキの機能を専用設計のシステムにより実現していた。これに対して新型プリウスでは、汎用的な横滑り防止装置（ESC）と部品の共通化を進めたらしい。

ちなみに、この取り組み自体はシンプルデザインと安全機能・安全性能のアイソレーションとは逆行しているから、ユーザーに対する価値（主にコストダウン）の向上を目指した取り組みであったとはいえ危険な領域に一歩踏み出しているといえる。（『セーフウェア』で解説されている放射線治療器セラック25の事故がセラック20のコストダウンがきっかけになって起こったのに状況はよく似ている）

トヨタは部品の共通化を進めた結果、ブレーキシステムの重量を29%も減らし、低コスト化も実現した。これは想像だが、メカとエレキのコストダウンを実現して、結果としてソフトウェアの負担（複雑性、規模）が増えることがある。コストダウンを達成して、めでたしめでたしの裏にソフトウェアの問題によるリスクの高まりが見落とされていることがあるので、ハードウェア出身の組織の上位層の方達はその点をよく認識しておいて欲しい。部品のコストダウンで一見成功したに見えた利益アップはソフトのリコールで一気になくなりマイナスになる可能性もあるということだ。（だからコストダウンをやめた方がいいのではなく、そういうリスクがあることを認識した上で慎重にソフトのV&Vを行う必要がある）

【新型ブレーキシステムの構成】

新型ブレーキシステムは次の部品から構成されている。

• 油圧ブースタ
• ブレーキアクチュエータ
• ストロークエミュレータ
• ECU（Electric Control Unit)ようするに頭脳の部分でここにソフトが入っている。

従来のブレーキシステムのと違い

従来のプリウスに搭載していた回生協調ブレーキは「ECB (Electronically Controlled Brake System)2 」と呼ばれているそうで、ブレーキペダルを踏む力が、通常走行時は直接各車輪には伝わらない「ブレーキ・バイ・ワイヤ」となっている。

※ECB2 というくらいだから ECB1 もあったのだろう。回生協調ブレーキとしてECB1→ECB2 と改善しながらハード・ソフトを枯れさせていったが、新型ブレーキシステムではコストダウンのために大幅に変更した。（一般的にそういうところに問題:Anomaly は潜んでいる）

先代プリウスではブレーキペダルからの油圧配管は、ブレーキ配管からは遮断されている。ドライバーが要求する制動力は、ブレーキペダルを踏む速度と、ペダルの角度をセンサによってセンシングしてコンピュータ制御＋モーター駆動の油圧ポンプで制動する。

このとき発生した油圧は、各輪に装備したリニア・ソレノイド・バルブによって制御し、必要な制動力を生み出している。

※このリニア・ソレノイド・バルブが高価で大きい部品らしく、新型プリウスではこの部品をデューティ型ソレノイドに変えてコストダウンをはかった。

【従来ブレーキシステムの欠点】

リニア・ソレノイド・バルブは内部のスプールバルブを高い精度で位置決めすることで、精密に油圧を制御できるとう特徴を持っている。ようするに高価だが性能のよい部品ということ。

これに対して、デューティ型ソレノイドは基本的にはオンとオフしかできないが、オン時間とオフ時間の比率を変えることで油圧を制御できる。その精度はリニアソレノイドほどではない。

※ここは今回の問題が発生した原因の中核となる部分だ。デューティ型ソレノイドはリニアソレノイドのように滑らかに制御できない。オンとオフを繰り返すことで制御するので振動が発生する。この振動を抑えるために変えた制御方法が今回の問題を生んだ。（たぶん）

リニアソレノイドは各輪にリニアソレノイドと圧力センサを備えることで、各輪のブレーキ油圧を独立して制御することができるので、ハイブリッドでない車種にも採用されている。そんな高価で高性能な部品を先代プリウスでは使っていた。ホンダのインサイトに価格対向するために新型プリウスでは高価な部品を使わないで要求されている機能や性能を実現する必要があり、結果的にこぼれ落ちた滴があった？のかもしれない。

【新型プリウスのブレーキシステム】

新型プリウスではシステム全体の油圧を決定する部分だけにリニアソレノイドを使い、この油圧を検知するセンサも一箇所だけ、そして、各輪には安価なデューティ型ソレノイドを使っている。

なお、もうひとつ新型プリウスでは低コストの取り組みをしている。従来型のブレーキ・バイ・ワイヤのシステムでは、電源が落ちるとポンプを駆動するモータが動かず、制動力を発生できないため、バックアップ電源としてのキャパシタ（一時的な蓄電池）が装備されていた。新型プリウスではブレーキシステムのくふうでキャパシタをなくしコストダウンを実現した。（くわしくは Tech-On!の記事を参照のこと）

この設計の変更により、新型プリウスはブレーキ・バイ・ワイヤとドライバの踏み力を直接各輪に伝える切り替えが可能になった。（と予想している）　そして、このメカニズムの変更を利用して、リニアソレノイドからデューティ型ソレノイドにコストダウンしたことによって低速で発生する振動ノイズを減らす制御を採用した。そこに落とし穴があったのではないだろうか。

前回の記事で、リコールによる改変で先代プリウスの性能にもどった→デグレードしたと書いたが、ブレーキシステム自体大幅に変わっているので、先代プリウスの性能にもどった訳ではない。

デューティ型ソレノイドを使っているぶん、ABS作動時に発生すると言われるノイズや振動は先代プリウスではなかった問題なのだろう。それが今回のソフトウェアの改変で復活したと思われる。そのノイズや振動は許容できるかどうかといえば、リスクとしては許容できるレベルであり、快適性とう点から考えると今後の検討課題になると思われる。（一度は低減する方向性を出している）

【従来ブレーキシステムから新型ブレーキシステムへの変更点】

• 従来ブレーキシステムではレクサスHS250h や SAI などにも搭載されているリニア・ソレノイド・バルブを使っていた。
• 従来ブレーキシステムではドライバーとブレーキが直接つながっていないブレーキ・バイ・ワイヤのシステムだった。
• そのため従来ブレーキシステムでは電源が落ちたときのバックアップとしてキャパシタが載っていた。
• 新型プリウスでは、リニア・ソレノイドの使用を減らし、デューティ型ソレノイドを採用し、さまざまな変更を行った結果 29%の軽量化、コストダウンに成功した。（キャパシタもなくなった）
• 変更を行ったことで、低速でのABS始動時にデューティ型ソレノイドによるノイズ・振動がブレーキペダルを通じてドライバに伝わるようになった。
• その問題を解決するシステム制御に今回の問題があった。（どちらも許容できるリスク）

【商品の価値を高めるためにコストダウンは必要】

コストダウンによるシステムの変更。それもメカもエレキも大幅に変えるとなると、ソフトウェアエンジニアはそれは危ないからやめましょうとはいえないし、変更をやらないという選択肢はない。やらなければ他社に勝てない。

だから、コストダウンの取り組みはメカもエレキもソフトも協力して実現しなければならず、かつ、安全性・信頼性も確保しなければいけない。

たぶん、今回の問題は受容できるリスクの範疇であったと思われる。低速でABSが働くときにしか起こらない。制動距離は70cm 伸びるが本当にドライバが危ないと感じればブレーキペダルを強く踏み込むので制動距離は縮まる。

こう理解すると、これまでのトヨタの記者会見では発表内容は逐一納得できる。ただ、コストダウンが目的によるブレーキシステムの設計変更が問題の発生を誘発したとは絶対に言いたくないだろう。そんなことを言おうものなら『コストダウンにより不具合混入』などという超短絡的な見出しだけが一人歩きする。

【安全を脅かす落とし穴はどこに存在するか】

• システムやソフトウェアの大規模化、複雑化に潜む
• コストダウンでメカ・エレキを省略する行為の中に潜む
• ソフトウェアが見えないというところに潜む
• ソフトウェアが見えないことを認識しないで問題を単純化するところに潜む

冒頭に書いたことを繰り返すと、今回の問題は結果的にソフトウェアを修正したが、ソフトウェアだけの問題ではなく、ブレーキシステムのメカ・エレキ・ソフトを変更した際の Validation （妥当性確認）に漏れがあったということだ。

そして、その漏れは受容できるリスクの範囲ではあったが、ユーザーの気持ち悪さと不安を取り除くためにリコールにした。

トヨタが反論しない理由は、説明しても一般の人が簡単に理解できるような内容ではないことと、説明すればするほど技術的な背景を理解できない者が「トヨタはいい訳をしている」と批判するからだろう。

この問題を通じて再認識したのは、一つの問題や事故の後ろには非常に複雑でテクニカルな内容と組織判断が含まれているということだ。今回の問題は事故ではないが、仮に複雑なシステムで事故が起こった場合、その深層に一般のジャーナリズムが切り込んで解明することはおそらく不可能だということだ。日経BPの記者だって、ソフトの中に問題があれば分析のしようがない。

そう考えると、日本も複雑なシステムの事故を客観的に調査する機関があるべきだと思う。航空機や鉄道にはあると聞いたことがあるが、専門分野のエキスパートが客観的に問題を調査できるようでないとまずいだろう。

P.S.

やっぱり、コストを含む市場要求と顕在的価値、潜在的価値（安全・信頼）とのバランス、トレードオフ及び、成果物の V&V(Validation & Verification）がこれからの複雑化するソフトウェア搭載システムの課題だと思う。

Tech-On!を見ていたら『Ford社、ハイブリッド車の回生ブレーキのソフトウエアを書き換え』という記事があった。これってプリウスのソフト改変とまったく同じに見える。同じブレーキシステムをトヨタやアドヴィックスが提供していたならともかく、そうでないのだとしたらプリウスをバラバラに分解してデッドコピーしたのでは？と思わせる。なんで、こっちはリコールじゃないんだろうか。