[トヨタ]フェイルセーフは難しい

最近のエントリは質が・・

フェイルセイフ（ある女子大教授のつぶやき）
http://iiaoki.jugem.jp/?eid=3459

近年改善が見られるものの、日本の自動車、電機産業におけるソフトウェアの立場というのは総じて低い。
どの企業の経営者もソフトウェアの重要性について語るものの、いかんせん社内に占める技術者の割合は圧倒的にメカトロニクスや電気系が多いし、また平均年齢もソフトウェア関係者の方が低いため、社内の論理としてはどうしてもソフトウェアの地位は高まらない。

マイクロソフトのビルゲイツは、ソニーに対してこういった。
(ソニーは脅威にあらずという意味で)
「ソニーはソフトウェアが作れない。」と。
それは、ソニーのソフトウェアエンジニアの能力が低いということではなく、ソニーという会社としてのソフト開発力は低いという意味であった。

また、少し前であるが、私はトヨタのソフトウェア担当役員の話を聞く機会があったので、少しこの件について感想を述べたいと思う。
トヨタも例外ではなく、ソフトウェアの立場が低かったようで、近年組織的な改変によって改善が行われてきたようである。
やはり、自動車技術の花形と言われたエンジンなどを長年やってきた人からすれば、「ソフトウェアなんて付加価値でしょ？」という認識しかなく、ソフトウェアが商品やサービスの価値を決めるという発想が希薄なのである。

これまで日本輸出製造業が世界に誇ってきたのはハードウェアの力であり、ソフトウェアの力ではなかった。
その視点に立てば、「ソフトウェアなんて付加価値でしょ？」と思うのも当然かもしれない。
「商品」をつくる「事業部」からすれば、ソフトウェアも「部品」の一つなのであり、「部品」のくせに「商品」の価値を決するかごとき論理は、彼らにとってみれば暴論なのである。

※
実はそれだけではなくて、新しい技術への心理的抵抗がある。
人間は「わからないこと」について寛容ではない。
知らないことを認められる人は、それほど多くなく、たいていは「よくわからない＝嫌い」と情緒的判断を下してしまうのだ。
これは、ヒトが生きていくために備えた機能でもある。
人間は知らないことについて合理的に判断できない。
しかし、生きていくためには、その時々の環境に応じて判断しなければならない。
知らない食べ物、未開の土地、未知な他民族、などなどだ。
滅亡リスクを考慮にいれると、漸進的にしか行動様式を変えることはできない。
新しいものについては、少しずつ、恐れながら取り入れていくということだ。

まぁ、なんにせよ日本企業でソフトウェアの重要性が認知されてきたのは、ほんと最近のことであり、ソフトウェアに対する認識が広がるのはこれからなのである。
これは外部要因による強制的構造変化になるだろう。
幕末の黒船は、今は新興国である。

で、トヨタのフェイルセイフがどうなっているのかだ。
詳細を知っているわけではないが、思うところを述べてみる。

まず、ソフトウェアについて知っている人なら誰もが認めることであるが、「不具合ゼロは有り得ない」である。
どんなに優秀なエンジニアと、十分な資金とスケジュールを確保したとしても、不具合はゼロにはできない。
いや、これはソフトウェアに限ったことではないが、人間が作ったものに完璧など存在しない。
※
もちろん、ソフトウェアにも品質があって、不具合の質と量の違いは出てくる。
単に不具合が存在するといっても、致命的な不具合と些細な不具合との差はある。

当然、トヨタがつくる車に搭載されているソフトウェアにも不具合が多数入り込む。
これは、誰もが認める事実である。
だが、重要なことは「最終的に車の走行に影響がないこと」であり、不具合の有無ではない。
なので、ソフトウェアを開発するにあたっての方針としては、「不具合も想定して、最終的に走行に支障が出ないこと」であるはずだ。

例えば、これは単純すぎる例だが、
「ブレーキ制御システムに不具合がみられる場合は強制的に油圧ブレーキを効かせる。」とか。
しかし、
「Aというエラーが起きたら安全策としてA-Aという方向に倒す。」
「そうすると他のデバイスとの状況矛盾が起きるので、そちらも初期化する。」
などとやっているとその初期化処理に不具合が発生したりする。
そう、不具合処理が不具合に起こる可能性も想定しなければならない。

また、
「Aというエラーが起きたら安全策としてA-Aという方向に倒す。」
「しかし、A-Aが動かない場合はどうするのか。」
という問題も想定されるわけである。

つまり、
「じゃA-Aが動かない場合はA-Bでいきましょう。」
「でも、A-Bも動かない場合は？」
などという無限ループにはまるのである。

さらにいえば、
「AとBというエラーは想定していたが、まさかCエラーが起きるとは・・」
という話も往々にしてあるわけあ。


ソフトウェアを設計する際には「何を問題として想定するか。」ということが非常に重要となるが、これは結局「どこまでを問題として想定するか。」という問題に置き換わる。

実はこれ、当Blogで繰り返し述べている「科学」についてのお話全く同じである。
カール・ポパーの「反証できなきゃ科学じゃない。」、転じて「科学的理論はどこかに必ず反証可能性がある＝完全理論は存在しない」なのである。

不具合が存在しないシステムは存在しない。
だから、システムを開発するためには、どこまでの不具合を想定するかという設計が重要である。
システムの品質の良し悪しは、その設計段階で決まるといってよく、その設計段階で失敗するとどれだけ完璧に近いプログラムコードを記述できても不具合は発生する。

ゆえに、ソフトウェア開発は知的産業なのであって、誰にでもできるわけではない。
本当に優秀なソフトウェア設計者は数が少なく、シリコンバレーなどいけば給料も高いのである。
優秀なプログラマーが優秀な設計者とはならないのである。

話がそれてしまった。
トヨタでも同様に、考えられる不具合を想定して、その場合の処理が定められている。
なので、基本的に"考えられる"不具合に対して最低限の対応はできているのである。
特に、車の場合は、どんな不具合でも、つまり想定仕切れていない不具合に対しても、システムがどう転んでも安全方向に倒すように設計してある。

たまに、その対応の仕方が、一般消費者とズレていることもある。
技術者からよく聞くのが「それは不具合ではありません、(設計通りの)仕様です。」
技術者からしてみれば、「それがいいと思ってやったのに」という思いもあるだろうが、何がいいかを決めるのは技術者だけではないので言い訳にしかならないのだろう。

最も危険なのは「想定仕切れない不具合」の、さらに想定漏れなのだが、もう話が長くなってきたのでおわり・・。