ソフトウェア系の国際規格はどのように使うのか(2)？ (ISO 26262 が正式発行される）

前回に引き続き、ソフトウェア系の国際規格（ISO 26262）がどのように使われるのかを解説したいと思う。

自分は自動車ドメインの仕事はしていない。しかし、ソフトウェア系の国際規格には長いことつきあっているので、おそらくこの見解は当たっていると思う。もしも、自動車業界の方で間違っているところに気がついた方は是非お知らせ願いたい。このブログ上で訂正したい。

まず最初に読者に認識して欲しいのは国際規格はそれだけでは法的な拘束力はないという点だ。国際規格と聞くと国際法のように守らないと罰則がある、当局に捕まるというイメージを持っている人が大勢いるようだがそうではない。

国際規格は各国の規制当局が規制に使うと宣言したときに初めて法的拘束力が生じる。日本のトヨタ自動車が ISO 9001 を取得していないという事実は有名だが、だからといって誰からも咎められることはない。トヨタは ISO 9001 に適合てきなくても自分たちのやり方で品質をマネジメントできているからいいのだ。

他の国際規格も全く同じだ。自信がある組織は国際規格を使わない選択肢も取れる。しかし、多くの場合は国際規格に乗っかった方が楽であり、みんなと同じであるとアピールしやすい。さて、では自動車の電子制御系に関する安全規格 ISO 26262 が2011年11月15日に正式発行されたがこれはどうだろうか。

EUとUS（アメリカ）と日本、中国、その他一般海外で分けて考えてみよう。

まず、EU。ISO規格を最も重要視するのがヨーロッパの国々で特にドイツがその度合いが強い。ドイツを筆頭にEUの国々は ISO 規格の策定に積極的に参画するし、策定された暁にはそれらに適合することに精を出す。自分たちでルールを決めてルールを守ろうとする。

そしてドイツには有力な二つの規格認証機関がある。これらの認証機関は世界展開しており、主要各国に拠点を持っている。規格認証機関は規格の策定にも関わり、規格が発行されると、その規格を認証することで利益を得る。規格認証ビジネスは結構儲かる。規格の適合を監査し、適合できていないことが分かると、その規格が何を求めているのかを説明し、適合できるように指導する。監査するときも指導するときも費用が発生するから、厳しく監査してダメだしすればするほど、やるべきことが増えてたくさん指導を受けなければいけない。

ドイツの規格認証機関は特に厳しく規格適合を求める傾向があり、結果として厳しく監査して欲しい対象企業からの信頼が高い。

そういう傾向があるため、ドイツのメーカーは規格適合に積極的であり、ドイツの自動車会社が日本のサプライヤーに対して ISO 26262 への適合を求めるシチュエーションは大いにあり得る。しかし、これは法的な要求ではないことを頭に入れておいて欲しい。ただ、クライアントが規格に適合せよと言ってきたのであれば、サプライヤーはイヤとはなかなかいえない。なぜなら、「イヤなら規格適合している他の会社から調達するか君たちとはサヨナラ」と言われてしまうからだ。

ただし、冷静に考えて欲しいのは、例えばイタリヤやイギリスの自動車メーカーがドイツほど強くISO 26262 への適合を求めるだろうかということである。自分の予想では EU の中でも声高に言ってくるのはドイツの会社だけだと思う。それでなくても、今 EU は大変な状況なのに、規格適合のために莫大な費用をかけたいとは思わないはず。まして、法的な要求でもなんでもない規格への適合に今人と金をかけようと考えるヨーロッパのメーカーとサプライヤがどれだけいるかと思う。

つぎにアメリカの考え方だ。アメリカは国際規格をそれほど重視しない傾向がある。代わりに自分たちで作ったルールが一番だと考え、アメリカ国民の安全を守るために自分たちが決めたルールを守らせる。このルールにはばっちり法的拘束力をもたせる。時にTBT協定違反だと批判されることがあるが、そんなことは気にもせず、我が道を行く。

よって、アメリカの自動車会社がサプライヤに対して ISO 26262 の適合を直ちに要求するとは思えない。アメリカ人はフェアーを重んじるので、アメリカ国内のサプライヤに求めず、国外のサプライヤだけに求めるということはしない。

ただし、アメリカは訴訟社会であるため、事故が起きた時に、自動車に搭載されたソフトウェアの安全性について説明せよと言ってくる可能性はある。そのとき、ISO 26262 に適合してソフトウェアを作っていると主張するのは説得力があるだろう。

つぎに日本。日本は ISO 規格をそのまま規制に使うことはない。まず、日本工業規格 JIS にする。要するに日本語にする。これには結構時間がかかり、2～3年はざらにかかる。通常は工業会が持ち回りで翻訳をし、何回か見直しをかけたあとパブリックコメントを募り JIS 規格として登録される。

ただ、JISになったからといってそれが規制になるわけではない。車ドメインのことは詳しくないが、自動車に関する許認可の権限を持っているのは国土交通省だろう。国土交通省が法律に基づいて自動車に搭載されているソフトウェアの安全性を審査できるかと言えば、できる訳がない。それをやるには法律を改正する必要がある。また、国土交通省が自動車のソフトウェアの安全性を審査できる訳がない。そんなことができる人材も組織もない。何十年も前から取り組んでいるドイツだって難しいと思われるのに、これまでまったく取り組んでいなかった日本でソフトウェアの審査はできないし、仮にやり始めたらとんでもない指摘が飛んでくる可能性がある。例えばソフトウェアに関する知識がまったくない審査官が「このソフトウェアはコードレビューはしているのかね」などと、よく意味も分からず聞いてくるかもしれない。

また、現在自動車のソフトウェアで社会的な問題が頻発しているか。そんな話はないし、日本の自動車は世界一品質が高いと言われている。取り締まりを強化しないと国民の安全が確保できない状況ではない。

よって、日本では ISO 26262 は法的規制になるとは到底思えない。

次は中国。中国は予測がしにくい国だ。どの分野においても国際的なレベルに達したいと考えているため、国際規格への取り組みの意気込みは日本よりは遙かに強い。しかし、国際規格が求めるレベルにすぐに達することができるかどうかという問題もある。よって、周りの国々の様子を見ながら遅れを取らないようにしようとするだろう。おそらく政府として ISO 26262 の要求についての勉強はしていると思うし、中国語への翻訳も始めているかもしれない。ただ、だからといって規格を規制にするかどうかはわからない。中国国内のメーカーがまだ対応できないと見たらすぐには規制用件にはしないかもしれない。

最後に一般海外は、各国の動向を見てみんなが規制するようになったら同調するだろうと予測する。

【誰が何のために ISO 26262 を使うのか？】

これまで解説したように、現時点で ISO 26262 の適合の積極的なのはドイツであり、ドイツの自動車メーカーが日本のサプライヤに対して ISO 26262 の適合を要求する可能性は高い。また、日本の自動車会社が日本のサプライヤに安心材料として ISO 26262 への適合を求める可能性もあるかもしれない。

ただし、ドイツと日本の場合では事情が異なる。ドイツは歴史的に国際規格への適合をチェックするための規格認証機関を持っている。彼らは規格の内容もよく理解しており、監査テクニックも持っている。個人レベル、会社レベルの規格適合コンサルタントもうようよいる。規格適合に関するビジネスモデルができている。

ところが、日本には日本オリジナルの規格認証機関はあまりない。特に、ソフトウェアを監査できる認証機関は存在しない。しかし、ドイツを始めEUでは規格適合ビジネスの市場はあるので、日本でもそのビジネスモデルに乗っかりたいと思う会社はたくさんいる。

でもソフトウェアの監査の経験は皆無に等しいだろうから、最初のうちは規格適合について尋ねている方も答えている方も何を言っているのかわからないという状況が続くだろう。

したがって、ここ数年はドイツを始めヨーロッパの自動車会社が ISO 26262 への適合を日本のサプライヤに対して求めるだろうが、規格への適合を監査できそうなのはヨーロッパ系の規格監査経験の長い規格認証機関に頼むことになる。

そして、ソフトウェアの監査ができる人材は希少なため、本質的な突っ込みを入れることはほとんどできず、結果的に規格適合はチェックシートを埋めるという形式的なものになると予測する。

そこで、サプライヤの皆さんに聞きたい。「誰のために、何のために ISO 26262 に適合するの？」「誰のために、何のために ISO 26262 に適合したいの？」と。

この質問に対して、「クライアントから求められているから」と答えるのならは、それは形式的なことのために人、物、金を投入するのだと考えた方がよい。

「自分たちが作ったソフトウェアが安全で信頼できることを証明するための手段として ISO 26262 を使う」と答えるのならば、その組織は投資が無駄にならないかもしれないし、この不景気な時代に規格ビジネスで金儲けしたいと集まってきて有象無象の輩をかき分けて真の支援者を探し出せるかもしれない。

前者でお金を捨てたくないのならば、まず、規格要求を腰を据えて読むことだ。そして、規格認証機関には規格要求の疑問点を尋ねる。要求の中身を一回も見ないで、規格認証機関やコンサルタントに頼ってはいけない。それは思うつぼで湯水のように形式のためにお金を使うことになる。

そして、技術誌の編集の方たちにお願いしたいのは、ISO 26262 の策定委員に対してのインタビュー記事を多く載せて欲しい、できれば座談会をしたり、それぞれに記事を寄稿してもらって欲しいということだ。国際規格はそれを読んだだけでは、規格の本当の意図が分からないことが多い。そしてそれが分からないと、規格認証機関やコンサルタントが自分たちのビジネスに有利になるように規格を解釈してクライアントに伝える。そうなるとサプライヤは形式に金を使い、本質的な安全にはなかなか近づかないという不幸が訪れる確率が高くなる。

繰り返すが、今一度考えて欲しいのは、誰が何のために国際規格を使うのかという点だ。

※本件に関するコメントを募集していますのでよろしくお願いします。

「それは仕様です」とは絶対に言ってはいけない

浜岡原発の停止に際して、中部電では「（対策が済む）２年後に本当に再開できるのか確証がほしい」（中部電幹部）と、政府に何らかの保証を求めるべきだとの意見が出ているという。

これを聞いて「ああ、やっぱりそういう考え方をする人はいるのだな」と思った。こういう発言をする人はリスクマネジメントの本質が分かっていない。

リスクに対する保証というと生命保険や損害保険などの金銭的保障がすぐに思う浮かぶが、多くの人の命が関わっている場合、話しはそう簡単ではない。

人の命に関わるようなハザードの発現を、防げるのに防ぐための対策を取っておらず、金銭的な保障で備えるという選択肢はない。

よって想定したリスクに対して、リスクを分析しリスクコントロール手段を講じる必要がある。そのときにリスクコントロール手段によって100%リスクを回避できれば、それに超したことはないが、ほとんどの場合は100%のリスク回避などできないため、リスクコントロール手段によってリスクが受容できるレベルまで軽減されているかどうかを確かめる必要がある。

そこに保証という概念はない。リスクコントロール手段を講じる当事者ではない者は誰も保証などはできない。世の中にはそれが分かっていない人が大勢いる。

例えば、契約書や取扱説明書に禁忌・禁止事項を記載して、それをよく読まずに実行してしまったらそれはユーザーの責任だという人がいる。それは正しいが、現代のリスクマネジメントの考え方からすると正しくない一面もある。

社会通念上ユーザーがやってしまっても不思議ではないことに対して、契約書や取扱説明書に禁忌・禁止事項が記載してあったとしても、事故が起これば機器の製造業者やサービス提供者は社会的責任を求められる。

刑事裁判では勝訴しても、民事裁判では負ける、もしくは裁判には勝っても社会的な制裁を受けて、会社は潰れる。そんな事件は世の中でしょっちゅう起こっている。

さて、リスクコントロール手段によって事故の発生を誰も保証してくれないのならば、どうやってGO か STOP かを判断するのか。

それは一にも二にもリスクコントロール手段にの有効性の根拠による。GO か STOP かを判断した結果ではない、根拠が大事なのだ。

よく、クリティカルデバイスのリスクマネジメントに関する判断で最終的な結果を求めてくるエンジニアがいる、というか、ほとんどがそうなのだが、そういうときは最終判断の案と共に判断の根拠を必ず伝えるようにしている。自分がエンジニアに聞きたいのは、結果を受け入れるかどうかよりも、その根拠に同意するのかしないのかだ。

何も考えずに、結果だけを受けているのだけは絶対やめてくれと常に言っている。大事なのはリスクが軽減できると考える根拠だ。もちろん、客観的な証拠、統計的なデータに裏付けられた根拠に基づいた判断がベストだが、ソフトウェアの場合は障害の特徴がランダムではなくシステマティックでることが多いため、客観的な根拠だけではなく、エンジニアの自信の大きさで判断をすることも少なくない。

冒頭の中部電の「（対策が済む）２年後に本当に再開できるのか確証がほしい」（中部電幹部）と、政府に何らかの保証を求めるべきだという意見は、その観点から考えると保証だけを求めていて、「リスクコントロール手段に対して自分達はまったく自信がありません」と言っているのと同じだ。

本来ならば、「これこれのリスクコントロール手段と根拠となるデータを用意したので、これで判断して欲しい」と言うのは正しい。

リスクが受容できるかどうかは、どんなリスクを想定し、どんなリスクコントロール手段を用意し、どんな根拠によるのかを説明しないといけないのだ。

そして、それは誰も保証はしてくれない。ユーザーが納得するかどうかは機器やサービスを提供する側がどれだけ客観的なデータを使って、自信を持って説明できるかどうかにかかっている。

そのことが分かっていないエンジニアやマネージャが多いと感じる。ある講演で自分は「レビューの席で技術者が“それは仕様です”という台詞を発すると心底むかつく」と言った。

実際そのとおりで、「それは仕様です」という言葉は「私はまったく何も考えていません」と言っているのと同じであり、自分はそういう発言をする者はなぜそうなっているかという根拠を説明できない最低のエンジニアだと思っている。

リスクマネジメントでもまったく同じであり、誰かに保証して欲しいという発言は、自分はリスクコントロールに関して何も考えていませんというと言っているのと同じだから、絶対に言ってはいけないNGワードなのだ。

ソフトウェア品質を高く保つには哲学が必要

前回の記事『商品リスクを低減するには哲学的思考が必要』に関して、もう一回同じようなことを書いた文章がありますので、ご一読ください。

誰がどこに書いた文章かはご想像にお任せします。

------
明治大学理工学部に向殿政男先生という方がいます。

著書のひとつ『安全設計の基本概念』

向殿 政男
1965年明治大学工学部電気工学科卒業。1967年明治大学大学院工学研究科電気工学専攻修士課程修了。1970年明治大学大学院工学研究科電気工学専攻博士課程修了。明治大学工学部電気工学科専任講師。1973年明治大学工学部電気工学科助教授。1978年明治大学工学部電子通信工学科教授。2005年経済産業大臣表彰受賞(工業標準化功労者)。2006年厚生労働大臣表彰受賞(功労賞)。明治大学理工学部情報科学科教授。明治大学理工学部学部長。明治大学大学院理工学研究科委員長。ISO/TC 199国内審議委員会委員(元主査)。安全技術応用研究会会長。機械の包括的な安全基準に関する指針の改正のための検討委員会委員長。次世代ロボット安全性確保ガイドライン検討委員会委員長ほか(本データはこの書籍が刊行された当時に掲載されていたものです)

その、向殿先生が、日経ものづくり 8月号 で日本のものづくりの歴史的背景を次のように語っています。

【日経ものづくり 8月号 特集 ソフトが揺さぶる製品安全より引用】

信頼性一本やりでは厳しい

明治大学理工学部情報科学課教授の向殿政男氏によれば、そもそも日本の企業は、信頼性を高めることで安全を確保しようとする傾向が強いという。しかし、前述の流れに従えば、そうした考え方は特に修正を迫られることになりそうだ。

「信頼性を高めることで安全を確保する」とは、製品を構成している個々の要素の信頼性をひたすら高めることによって、異常事態が発生する可能性をゼロに近づけようとする考え方である。構成要素に故障がバグがあることは前提としないので、これは「フォールト・アボイダンス」と呼ぶ考え方だといえる。

日本の企業はこれまで、この考え方で実績を積み上げてきた。「日本製品は壊れにくい」という評価は、まさにこのフォールト・アボイダンスを追求してきたたまものといえる。もともと日本の製造業は、欧米で確立された製品の改良設計で成長してきたという経緯がある。製品全体のアーキテクチャが所与の中、改良設計という形で信頼性を高めることに力を注いできたのは、ある意味必然だった。

さらに向殿氏は、信頼性は定量的・純技術的な概念であり、技術者にとって扱いやすい指標だったことも、日本の企業がフォールト・アボイダンスに傾倒した理由に挙げる。「安全を定義するには、社会が許容するリスクとは何かといったことも考えなければならないので、どうしても哲学的な判断が必要になる。それに比べると、信頼性は技術者にとってとっつきやすい概念だった」（同氏）。

だが、ソフトの役割が増すにつれ、フォールト・アボイダンスだけで安全を確保するのは厳しくなってきた。前述の通り、ソフト自体の信頼性を高めるのが困難な上、ソフトやハードといった構成要素同士の関係も複雑になっていることから、構成要素の故障やミスを認めない前提そのものに無理が生じているのだ。

そもそも信頼性（壊れにくいこと）と安全は全く異なる概念である。だが、前述のような経緯から、信頼性を高めることと安全を確保することがほとんど同じ意味になってしまっていたのである。

【引用終わり】

この「今後の安全設計には全体最適の発想が必要であり、安全を定義するには社会が許容するリスクとは何かを組織が考えなければならず、そのためには哲学的判断がいる」、というところに強く共感します。

ようするに、ユーザーリスクとその対策は考えれば考えるほど際限がないので、コストや開発時間とのトレードオフでどこまでやるかを決断しなければならず、その決断をするためには安全や品質に対する哲学が必要だということです。

安全や信頼を実現している「当たり前品質」は、カタログやスペックシートには現れないため、長い間商品を使ってもらったときにお客様から伝わってくる「品質がいいね」という感想や、クレームの少なさなどでしか表面に現れてきません。

クリティカルデバイスではそこが命でもあるので、技術者は当たり前に出来ていることの重要性や、リスクを軽減する対策の大切さは言われなくても分かっていました。

それが、近年、リスク分析の結果や取扱説明書を見ていると、表記上の対策で禁忌・禁止事項として書いておけば、設計上の対策はいいやという技術者が増えてきたようにも感じています。そうなってきた理由のひとつは商品が実際に使われる現場の現実を知らない技術者が増えてきたからでもあります。

これだけ複雑化してしまった製品ソフトウェアに対して、安全に対して哲学を持ってどこまでやるかを決断しなければならなくなっているのです。逆に言うと製品の品質や安全に対して無知であったり、哲学（ポリシー）がない技術者が作る商品、ソフトウェアは危険であると言えます。

そして、技術者に哲学（ポリシー）があっても、組織の上位層に安全や品質に対する哲学がなく、商品のリリースの時期だけを何とかしろと言い、技術者の哲学（ポリシー）がポキッと折れてしまったり、考えてもどうにもならず辛いので考えないようにしている人はいると思っています。

簡単に言えば次のような質問に間髪入れずにはっきり答えられる技術者が少なくなってきていると思うのです。

・自分の商品の品質に自信があるか？
・自信の根拠は何か？

これらを聞くと怒り出す技術者はまだましで、しれっと「自分の守備範囲ではないんで」などと言う人が出てきたらもうおしまい。

そういう人たちで構成された組織において、製品の信頼や安全はプロセスや組織的システムのみで確保しなければならず、そのためには責任と権限が明確な組織的階層構造と徹底的な設計管理が必要です。

そうでない、プロセスやシステムだけで日々の仕事をやっているんじゃない組織において、もし、安全や信頼について自信をもって答えられる技術者、管理者が少なくなっているのだとすると、機器やサービスの安全や品質に対する哲学が個人個人に対しても、プロジェクト、部門にも必要です。

安全や信頼に関する哲学が、すでに組織の中に醸成されているのなら、職制で指揮命令するだけで高品質を維持できるかもしれませんが、安全や信頼に関する哲学が醸成されていない、廃れてしまったのなら意識改革から始めなければ高品質は達成できないと考えます。

これはロジックではなく、哲学やポリシーの問題です。なぜなら、当たり前品質という見えない品質を実現するために、どこまでやるかは常に自分との戦いであり、他人から言われた通りにするだけなら、納期のプレッシャーに負けて、品質は低い方向に傾くからです。

「開発が遅れているかどうか」を聞くのもいいですが、それと同じかそれ以上の熱意、頻度で「自分の商品の品質に自信があるか？」と問う人が増えないと高品質を維持していくのはムリだと思います。

以上

商品リスクを低減するには哲学的思考が必要

日経ものづくり 2010年8月号 の特集記事『ソフトが揺さぶる製品安全』の中で明治大学理工学部情報科学科教授の向殿政男氏が次のように語っている。

日本の企業はこれまで、この考え方で実績を積み上げてきた。「日本製品は壊れにくい」という評価は、まさにこのフォールト・アボイダンスを追求してきたたまものといえる。もともと日本の製造業は、欧米で確立された製品の改良設計で成長してきたという経緯がある。製品全体のアーキテクチャが所与の中、改良設計という形で信頼性を高めることに力を注いできたのは、ある意味必然だった。

さらに向殿氏は、信頼性は定量的・純技術的な概念であり、技術者にとって扱いやすい指標だったことも、日本の企業がフォールト・アボイダンスに傾倒した理由に挙げる。「安全を定義するには、社会が許容するリスクとは何かといったことも考えなければならないので、どうしても哲学的な判断が必要になる。それに比べると、信頼性は技術者にとってとっつきやすい概念だった」

この、「哲学的」というキーワードを見て「なるほど」と思った。もしかすると、これまでなぜソフトウェア開発やソフトウェア品質がなかなかよくならないのか、それはソフトウェア開発には哲学的な判断が必要なのに、それをしない、できない人が増えているからだと思った。

なぜ、ソフトウェアと哲学が関係するのか。安全を定義するには、社会が許容するリスクとは何かを考えそこに線を引かなければならない。商品やサービスの周りにはリスクが無限に存在する。

悪意を持った行為を含む Abnormal Use を除いても、誤使用(Use Error), うっかりミス(Slip), 過失(Lapse), 誤り(Mistake) は必ず起こる。

それらのリスクに対してどこまで企業は対処すべきか。リスクの基となるハザードは危害に発展しなければ表面化しない。だからこそ、作る側と使う側で認識のギャップが生まれる。

正しい使用と異常な使用の間にはグレーゾーン（メーカーが考える正しさ、異常さと、ユーザーが考える正しさ、異常さのギャップ）が存在する。

このグレーゾーンをメーカーが都合のよい解釈で広げていくと、ハザードが危害になる危険性が高まる。メーカーは製造物責任を回避するために大量の警告や注意を取扱説明書に記載することよって、責任を回避できると思いがちだが、世の中はそう甘くはない。

ユーザーが取扱説明書を読まずに禁忌事項を実施した場合は、事故の発生はユーザー側に責任があるから、メーカーは製造物責任を問われることはない。しかし、社会通念上、多くの人の認識と合わないような要求を製品の利用者に強いている場合、適正なラベリングを行っていなければ、製造業者は社会的責任を追求される。

ようするににニュースになるような事故が起こると表記上の対策で刑事責任は逃れられても、設計上の対策=リスクコントロール手段を実装していなけば世間が許してくれず信用ががた落ちになり、企業の対応によっては市場から No を突きつけられるということだ。

そうなると、企業はユーザーの安全のためにグレーゾーンのどこに線を引くのか決断しなければならない。これはそんなに簡単なことではない。数式で計算できるようなものでもない。

その組織やそのプロジェクト、その技術者のポリシーに寄るところが大きい。組織的なポリシーが確立されていれば、商品間、サービス間でのばらつきは少ない。プロジェクトや技術者個人に依存していてば、そのプロジェクトやその技術者が関わった製品のみグレーゾーンのユーザー部分が小さいことになる。

リスクを起こさない仕組み=リスクコントロール手段を実装するにはコストがかかる。ソフトウェアで実施する場合、材料費はかからないが分析や実装の時間を要する。ソフトウェアは常に納期を迫れれているから、納期とのトレードオフでリスクコントロール手段は省略される危険性があり、ソフトは見えにくいので省略してもその事実を確認しにくいという特徴がある。

障害の発生確率が低ければ「どうせ、そんなこと起こらないよ」という気持ちになり、対策を実装しない技術者がいても不思議ではない。そして、障害の発生確率が高くても、納期が迫っていると「どうせ、そんなこと起こらないよ」と考えたい悪魔の気持ちが大きくなっていく。

悪魔の気持ちを抑えるのが、エンジニアの倫理観であり、組織の品質保証の仕組みである。エンジニアの倫理観は、哲学的な思考で鍛えられると自分は思っている。何も考えていなければ、エンジニアの倫理観は醸成されない。1か0ではない物事に対して、何が正しいのか、何を持って正しいと考えるのかについて深く掘り下げていくことで、哲学的な思考能力は高まると思う。

そうなると、前述のグレーゾーンをユーザーのリスクを最小限にするためにかかる工数（行為）と納期やコストとのトレードオフをする際に、なぜ自分または自分たちはその選択をしたのか自信を持って言えるようになる。

それが言えないのなら、その人は組織の言われた通りにものづくりをしているだけなのであって、グレーゾーンはメーカーの都合のよい解釈になっている可能性が高い。

その危険を組織で抑えるか、エンジニアのコンプライアンス教育で抑えるのか、それとも両方かを選択するのは自由だが、技術者がやりたいようにものづくりする方がいいものができると考えているプロジェクトほど、エンジニアの哲学的思考能力は高くないと安全で信頼できる商品は作れない。

自分自身はマイケル・サンデル先生の『これからの「正義」の話をしよう――いまを生き延びるための哲学』と読んで、哲学的思考能力を高めようとしている。

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

プリウスのブレーキ制御のソフト改変についての状況が徐々にわかってきた。

エンジニアはエンジニアらしく現象を客観的にロジカルに考えて、憶測の部分は憶測として断りを入れながら語っていきたい。

まず、問題を分析する前に、ABS（アンチロック・ブレーキ・システム）についておさらいしておく。

Wikipedia によれば、ABSの構造はこうだ。

1. ブレーキペダルを踏むことによって、油圧発生装置 (2) から油圧配管 (5) を通じて油圧がブレーキキャリパ (4) に伝えられ、ブレーキバッドがブレーキディスクに押し付けられて制動力が生じる。
2. 制御装置 (1)は回転センサ (3) により車輪の回転をモニターしており、他の車輪が回転しているのにこの車輪だけ回転していないことを検出するとブレーキがロックしたものと判断し、油圧発生装置 (2) から発する油圧を下げる。
3. 油圧が下がると制動力が弱くなるのでブレーキロックから復帰する。
4. ブレーキロックから復帰すると車輪の回転が生じるので制御装置 (1) は回転センサ (3) によりブレーキロックではないと判断し、油圧発生装置 (2) から発する油圧を上げ制動力を強くする。

制御装置 (1) は、この一連の操作を数ミリ秒という短時間で行うため、運転者がポンピングブレーキを行うよりも高精度な制御が可能となる。

この説明が難しいと思ったかたは、ABSが非常に分かりやすく解説されているページも見つけたのでこちらもどうぞ。

ハイブリッドではない車で油圧ブレーキ+ABSの組み合わせであれば、この説明の機能が正しく動作していており、技術も枯れているから問題はない。

つぎに今回のプリウスの問題について、正確と思われる技術的な情報を見てみよう。

以下は2010年2月5日現在の最新の情報を正確に表していると思われる記事（中日新聞）である。元ネタはトヨタの品質保証担当役員 横山裕行常務 の記者会見である。

【中日新聞：『トヨタ、ブレーキ欠陥を否定　プリウス苦情で会見』より引用】

プリウスはガソリン車と同じ「油圧ブレーキ」と、ハイブリッド車特有の「回生ブレーキ」を併用。走行状態に合わせ、自動的に車自体が最善の組み合わせを選ぶ仕組みだ。
ただ、凍結など滑りやすい路面で車体をコントロールするアンチロック・ブレーキ・システム（ＡＢＳ）が作動すると、回生ブレーキとの併用から油圧ブレーキ単独への切り替えに、時間差が生じるという。

【引用終わり】

もう一つ、朝日新聞より追加情報

【朝日新聞：『トヨタ、新型プリウス全車を無償改修へ　欠陥は認めず』より引用】

多くは、滑りやすい路面を低速で走行中、１秒前後、ブレーキが利かなくなるというもので、トヨタの調査では、車輪がロックしてハンドル操作が不能にならないようにするアンチロック・ブレーキ・システム（ＡＢＳ）の制御ソフトの問題という。

【引用終わり】

これ以外の NHKのニュース等も総合すると次のようなときに起こる現象のようだ。

回生ブレーキが効いているとき（減速中）にブレーキを踏んで油圧ブレーキに切り替えわろうとする際、たまたま路面が滑りやすい状態であるとABSを効かせる（切り替わる）のに約1秒かかる。

ここからは憶測が入る。

この問題では「回生ブレーキ」と「油圧ブレーキ」と「ABS」の3つの機能の微妙なバランスが絡み合っている。そもそも「油圧ブレーキ」単独のシステムは非常にシンプルで正しく動いていることもテストしやすい。

つぎに、「油圧ブレーキ」+「ABS」の組み合わせは冒頭のABSの仕組みを見てもらえればわかるように結構複雑であり、ソフトウェアの制御が入ってくるが、ガソリン車においてすでに枯れた技術となっている。

ハイブリッド車における「回生ブレーキ」と「油圧ブレーキ」の切り替えはさらに難しいソフトウェアの制御になっていると予想される。しかし、それが難しいのはトヨタだってホンダだって分かっていて、徹底的にテストしていたと思う。一節によると、トヨタは新しい技術の検証には5年以上かけているらしい。

だから「回生ブレーキ」と「油圧ブレーキ」の切り替えは正常に動いていて、例えば坂道で減速中に回生ブレーキが効いている状態で、運転者がブレーキを踏むとタイムラグなく油圧ブレーキに切り替わるのだろう。

同様に、「油圧ブレーキ」＋「ABS」の組み合わせもガソリン車で培った長年の技術の蓄積があるため枯れており問題はなかったのだと思う。

しかし、今回の状況は「回生ブレーキ」と「油圧ブレーキ」と「ABS」という3つの要素の境界領域の問題であり、レアなケースのように思える。ソフトウェアの機能のテストを考えるときに、一つのシステムのテストが100項目だったとする。2つの機能を組み合わせるとテストケースは1万になる。3つの機能を組み合わせるとテストケースは100万だ。100のテストはちょっと頑張れば検証可能。1万のテストはシステマティックにやならいと漏れが発生する。100万のテストはどんなに頑張っても漏れや抜けが出る。

もう一つの憶測は、「回生ブレーキ」チームと「油圧ブレーキ」チームと「ABS」チームが別々だった場合、それぞれのサブシステムの完成度は高くても、各サブシステムを組み合わせたときに想定される問題の追求には他のチームへの遠慮があるため徹底的に突っ込めない、突っ込みがあまくなる可能性だ。他のチームにケチをつける、すでに枯れていると思われるシステムをバラバラにする、疑いを持って検証のし直しを迫るのは勇気がいる。そこに遠慮があるとテストに漏れがでる可能性もある。

「回生ブレーキ」から「油圧ブレーキ」もしくは「回生ブレーキ」から「ABS」への切り替えに1秒かかるというのはあきらかに遅い。当初エンジニアが意図していた性能要求からは外れていると思う。

結果的に回生ブレーキが効いている減速中にしか、1秒の切り替えディレイが発生しないのであれば、ユーザーリスクは小さいのかもしれないが、100Km/h 以上の高速走行中に減速して回生ブレーキ中に滑りやすいところに入って思いっきりブレーキを踏んで油圧ブレーキが効くのに1秒かかったら、制動距離に変化はないとは言えないだろう。

Wikipediaによると、そもそも、ABSには下記のような注意点があるようだから、さらに問題の現象は複雑になる。

凍結路面（凍結状況によって左右される・ミラーバーンでは制動距離が延びる場合がある）や砂利道などの非舗装路面などではABSを解除した状態の方が制動距離が短くなる傾向が強い。理由の一つに、ABS作動時は一時的にせよタイヤが空転するからである。
凍結道路において乾燥路面と混在状態の時は、制動距離がABS非作動時の倍以上になることがあるので、低速走行時（時速40 km以下）においてはABSが自動的に解除される機構が必要である。

また、ABSはタイヤがロックしているかどうかを関知するセンサは最近は4輪独立しているらしいので、その点もソフトウェアを複雑化させているのかもしれない。

複雑化したシステムの境界領域の問題は、これからますます増えてくる。だからこそ、安全アーキテクチャを実践するにはシンプルな構造を目指すのが不可欠なのだが、だからといって機能を削ることは許されないのが現実だ。

ハイブリッド車において、回生ブレーキをあきらめればブレーキシステムはガソリン車と同じ構造になり枯れた再利用資産を使える。しかし、燃費向上のためには回生ブレーキも使わないといけない。安全のためにエコを捨てることは社会やユーザーが許してくれない。だからこそ、トップダウンの安全アーキテクチャ解析が必要になってくる。

ところで、ソフトウェアが絡んだリコールの問題、大企業で社会が注目しているリコールの処理の難しさは、一度改修を行ったら、同じ問題で二度三度とリコールを繰り返すことはできないということだ。そんなことをしたら信用ががた落ちになるだけでなく、マスコミから一斉に叩かれる。

だから、今トヨタと関連会社の一部のエンジニアは、この問題の検証と、これ以外にも問題がないかどうかここ数日間、徹夜で働いているに違いない。

安全や信頼は、表面に見えているところ以外にも幅広くケアしておかないと保証できないという事実をエンドユーザーやマスコミは知らない。

マスコミや評論家は何か問題が起こったときにはみんなで大騒ぎするが、同じような別な問題はないか、違うシチュエーションでは発生しないのかといった、隠れている部分を洗い出す力はない。

クリティカルデバイスに携わるエンジニアは見えないところの問題も改善する道筋をつけていかなければ、潜在的な価値（当たり前品質）を高くキープし続けることができないのだ。

サブシステムの完成度を高めても、単純にサブシステムを結合したのでは安全は保証されないということをこのブログで言い続けている。もしかしたら、今回のブレーキ問題はその例のひとつなのかもしれない。

P.S.

その後日経ものつくりにこんな記事が載っていた。

新型プリウスはABSが動作してから油圧ブレーキが作動するまでの時間が従来型に比べて若干長く，このことがドライバーに「ブレーキが利きにくい」と感じさせていたというのが同社の見解だ。同社に寄せられたブレーキが利きにくいという現象は，基本的にABS動作時にだけ起きるものだという。また，そうした現象が起きたとしても，フットブレーキを十分に踏み込めば問題なく停止できると横山氏は説明する。
改善策としてABS動作後に油圧ブレーキが動作するまでの時間を短くした。

• 若干が1秒だとしたら長い。人間が我慢できるレスポンスの限界はだいたい500ms。
• たぶん、回生ブレーキ動作中でない場合は反応が早い
• ABSはロックしないための機能だから、ABSの動作と油圧ブレーキの作動は同じ事を意味しているはず。正確に言うと、回生ブレーキがかかっているときにABSが動作するまで1秒かかっていたので、その時間を短くした？
• ソフト修正前と後では制動距離が異なるのではないだろうか？ ソフトの修正で制動距離が短くなっているのなら・・・

さらに、こちらの記事（一番参考になる）によると、ブレーキの踏み加減によってABSの効かせ方を調節している可能性がある。結果的には、単純な単機能の油圧のディスクブレーキの時代から比べたら遙かに複雑なソフトウェア制御の時代に変わっており、安全アーキテクチャ分析をしないと安全は確保できないところまで来ているということだろう。MISRA-SA （MISRA Safety Analysis）の出番かもしれない。

プリウスの場合は低速でブレーキを踏むと回生ブレーキのみで制動する。（この時油圧ブレーキは作動していない）
その状態でABSが作動するような状態になると、回生ブレーキを切って油圧ブレーキに切り換えABSを作動させるんだが、この切り替えに1秒程度かかる。すなわちその1秒間は何のブレーキも効いていない状態になる。

という記事も発見。回生ブレーキが作動する低速というのがどれくらいのスピードまでかが問題。回生ブレーキになる最大のスピードでの1秒間でどれくらい制動距離が伸び、ABSが働くのに時間がかかることで車の姿勢が崩れないのか否か。

日本の技術者が目指すべきはスマートな職人気質

ここ数年、ソフトウェアの開発効率はどうすれば高まるのか、ソフトウェア品質はどうすれば維持できるかかを考え続けてきた。

しかし、教科書や文献に載っている方法論をそのままやってみてうまくいくような気がしない。雑感として次のようなことを感じる。

• 方法論は昔に提唱されたものの方が効果が高く、新しければ新しいほどハードルが高いような気がする。（問題の根は共通で人間はそれほど成長していない）
• 日本の組込みソフトウェアシステムの品質は高度な技術で維持されているように思えない。
• 方法論をツールに隠蔽して解決しようとして失敗するプロジェクトが山ほどある。
  

とはいうもののいろいろな文献や講演を聴いたときに「これは使える」と思うこともある。後で冷静に「使える」「使えない」を考えたとき、「商品化までたどり着いて、かつ、実際に効果があった」のか「実施したが商品の価値に貢献するところまで確認していない」の違いではないかと思った。

今回の話しは、第7回 クリティカルソフトウェアワークショップ(WOCS2009）の講演を聴いて、「これは使えそうだ」と感じたことと、なぜ、日本では教科書に書かれたことがすんなりと導入できないのかの理由について考えたことだ。

まずは、冒頭の図を見て欲しい。ソフトウェア職人気質とソフトウェア工学を対比させた図で、「ルール/責任」「システム/ツール」「顧客や品質に対する意識」という「USとJapanの文化の違いと商品品質との関係」の記事で引用したGD3 コンサルティング代表/JMAC GD3 センター長 の吉村達彦氏の視点を組み合わせている。

自分の中では日本の多くの組込みソフトウェアプロジェクトの現状はこの図で言い表せるのではないかと考えている。この図で言いたいのは次のようなことである。

• ソフトウェア工学の教科書にはソフトウェア技術者の職人気質が品質に与える影響が書かれているものが少ない。（逆に書かれているのは『ソフトウェア職人気質』や『ピープルウェア』など）
• 日本で古くから提唱されている品質向上施策は職人気質的だ。（TQMなど）
• 「ルール/責任」「システム/ツール」「顧客や品質に対する意識」は日米でかなり異なる
• 日本的ソフトウェアプロジェクトには何か特殊性がある
• 日本のプロジェクトに欧米のアプローチをそのまま取り入れようとするとうまくいかないことが多い
• 日本のプロジェクトは表面的には欧米のアプローチを取り入れるポーズはとるが実際には役に立たないと考えていることが多い
• 日本では「ソフトウェア職人気質」と「ソフトウェア工学」どちらかに偏ったままでは未来はない
• それぞれのよいところを見極めながらバランスよく取り入れることが大事

「ルール/責任」「システム/ツール」「顧客や品質に対する意識」の比較の詳細は、「USとJapanの文化の違いと商品品質との関係」の記事を参照してもらうとして、ここではJAXA（宇宙航空研究開発機構）とIPA（情報処理推進機構）が共催した 第7回 クリティカルソフトウェアワークショップ(WOCS2009)の講演でこれならうまくいくのではと感じたことを書こうと思う。

まずは、MITのナンシー・レブソン教授が言った「安全性と信頼性は区別して考える必要がある」と言ったことについて。

WOCS2009では、ソフトウェアのシステム安全のオーソリティであるMITのナンシー・レブソン教授が来日(二度目)し、2時間40分のチュートリアルを講演した。ナンシー・レブソン教授はいつものように安全性と信頼性は異なる、区別する必要があると話し、信頼性を高めたソフトウェア部品を組み合わせてもシステムとして安全にはならないことを説明した。なぜかという理由は複数ある。

【信頼性の高いソフトウェア部品を組み合わせたシステムは安全とは言えない】

• ソフトウェア部品の信頼性を100%にするだけのテストができない。
• 仮に信頼性を100%にしても、ソフトウェア部品は簡単に変更できてしまう。
• 部品が完全でも部品の組み合わせかた使い方で事故は起こる。（デッドロックなどが典型的な例）

だから、「ソフトウェア部品の信頼性を高める」とシステム安全は必ずしもイコールではないのだ。ナンシー・レブソン教授はこれまで数々のソフトウェアが起因する事故を調査することにより、このことを確信した。だから、安全性と信頼性は区別して考える必要があると言っている。実際に起こった事故から再発防止策を考えることは次回役に立つ可能性が高い。

自分は、クリティカルソフトウェアの開発に長く関わっていたし、そのドメインにおける事故や事故を起こした原因について常にアンテナの感度を高くしていたので、安全性と信頼性を同一視すると危ないということは直感的に分かっていた。

ところが、世の中ではソフトウェアの信頼性を高めることが、ソフトウェアシステムの品質を高めるために有効であるという考え方が流行っているように感じる。例えば、ソフトウェア部品が機能安全(IEC61508)の認証を得るとシステムが安全になるという考え方や、形式手法（フォーマルメソッド）のような数学的に漏れのないことを証明したソフトウェアを目指すことで品質が高まるというアプローチだ。

自分は形式手法がこれだけ話題になっているのは、情報処理系のアカデミアが論文にするのに格好のテーマだからではないかと予想している。ソフトウェア工学は自然科学ではないから、主張が正しいことを証明することがとても難しい。ソフトウェアは技術者の日々の積み重ねであるため、そもそもソフトウェアを作っている技術者の特性によって、ソフトウェアの品質も左右されてしまうのだ。そして、人間の脳は必ずしもコンピュータのようにロジカルではないため、いつも一定の動きをするとは限らない。

そうなると、ある方法論を提唱したとしてもそれが常に同じような効果を現すわけではない。だから、情報処理系の論文で、何%バグが減ったとか、開発効率が向上したとかいった記述を見つけたとしても、自分の組織で同じ数値をたたき出せるかどうかはわからない。

ところが、形式手法（フォーマルメソッド）は正しいことが数学的に証明できるから、論文のテーマとしてはうってつけだ。形式手法（フォーマルメソッド）は安全性と信頼性が同じではないということを分かっている技術者、組織が適用すれば効果的に働くが、信頼性を高めることでシステムの安全性を確保できると考えてしまったらかなり危ない。形式手法（フォーマルメソッド）はFelicaの開発に有用だったという実績が有名だが、どんな開発のどのようなシーンに適用するとよいのかを考える＝実績から有効な範囲を予測し、自分の開発に投影してみることができないと失敗すると思う。

さて、WOCS2009の2日目の講演で、三菱電機の白坂成功氏と、JAXAの片平真史氏と、ナンシー・レブソン教授の話は、非常に欧米的でかつシステマティックでスマートな感じがした。ナンシー・レブソン教授はアメリカ人で白坂氏と片平氏のミッションはロケットや宇宙開発がテーマでその技術や施策はNASAの影響を強く受けているから当たり前ではある。一方、プログラムの最後に企画されたパネルディスカッションで発言された自動車系のソフトウェア技術者の方々のお話は非常に職人気質な感じがした。

この感覚は、冒頭の「ソフトウェア職人気質」と「ソフトウェア工学」の比較に合致している。三菱電機の白坂成功氏と、JAXAの片平真史氏の話しは、基本的にはソフトウェア工学的なアプローチでソフトウェアの安全設計を実現しようとしていて、欧米で培われたアプローチの弱点と思われる「顧客や品質の対する意識」が低い点をカバーするアクティビティとして第三者による独立検証と妥当性確認が行われたいたように思う。三菱電機の白坂成功氏は日本で開発したソフトウェアシステムの設計情報、アーキテクチャを第三者のレビュー（IV&V）によって徹底的に見直すアプローチを説明していた。JAXAの片平真史氏はソフトウェアシステムの安全設計のベースには安全文化が必要と語っていた。また、ナンシー・レブソン教授は安全性と信頼性の区別の他には、「ソフトウェアの定量的な計測だけでなく、システムを全体から定性的に分析することが安全設計には必要」と言っていた。この3方の話しに共感する感じがしたのはそれぞれ実経験、実績に基づく話しだったからかもしれない。

一方、パネルディスカッションで日本の自動車の開発ですでに確固たる品質の実績を上げてきた人たちは何を語ったかといれば、ハイブリッド車という新たなテーマに対しても「顧客満足、品質向上を高めたいと思う意識と、その意識から生まれる方法を醸成させる」というアプローチで品質を維持している内容だったと思う。これは宇宙開発での方法論の後に聞いてしまうとあまりスマートな話しには聞こえない。でも、今後はどうかわからないが少なくともこれまでは、この日本の職人気質から生まれた安全ソフトウェア設計に関するアーキテクチャとエンジニアの粘り、がんばりが日本のソフトウェアシステムの品質を維持してきたのだと思う。

だからこそ、今一度冒頭に掲げた「ソフトウェア職人気質」と「ソフトウェア工学」の比較をよく見て、自分の組織、自分のプロジェクトがどちらかに偏りすぎていないかどうかをチェックして欲しいのだ。

ソフトウェア技術者はソフトウェアをアウトプットする機械じゃない、生身の人間で必ずしもロジカルな思考をするとは限らない。それに気がついていた一部の人たちは、ソフトウェア工学をベースにしながらも、予想できない人間の思考や行動からくるズレを補正するために、プロセスを繰り返すことで軌道修正したり、改善のプロセスを導入することを思いついた。アジャイルやXPなども、人間の不確定な部分からくる品質の低下を防ぐアプローチではないかと思う。

だから、日本で安全ソフトウェアを実現させるためには、人間の特性や日本人の特性・集団心理等をよく理解した上でソフトウェア工学を導入する必要がある。

日本のソフトウェアエンジニアが目指すのはやはり『スマートな職人気質』なのだと思う。（スマートといっているのは職人のいい仕事の裏付けがソフトウェア工学で説明できるということ。単なる職人気質はスマートではない。）

今後、この比較文化論的考察は今後も続け、何かしらのタイミングで公開していきたい。

　

国際標準との向き合い方

ソフトウェアの世界でも国際標準への対応が求められる機会が今後増えてくると考えられる。ISO 9001などが最もポピュラーだが、各業務ドメインにおいてもソフトウェアを意識した個別の規格がでてきた。日本のエンジニア特にソフトウェアエンジニアは国際基準・国際規格との付き合い方が下手だ。

それは、おそらくソフトウェアエンジニアが自分たちの日々の取り組みを外部にさらす機会がほとんどなかったからだと推測される。今回はソフトウェアエンジニアが国際標準とどのように向き合っていけばよいのかを考えてみる。

【国際標準との向き合い方】

国際標準の策定に対して、日本のエンジニアは自分たちとは縁遠いもの、天から振ってくるものだと考えがちだが、実際にはそうではない。国際標準は各国の代表が意見を出し合って議論し、投票によって内容を決定する。もちろん日本も代表として標準の策定に参画しているので、意見を主張することができる。ただし、日本人は議論の際に押しが弱く、欧州のように多数派を構成する能力に長けていないため、国際標準を自分たちの考え方に引き寄せることが難しいようだ。その結果、国際標準の多くは欧米が中心となって作られることが多く、責任を権限が明確な組織において構成メンバの役割をベースに「誰が何を」すべきかに焦点が当てられることになる。

ところが、責任や権限が明確でなくても、いざというとき、エンジニア同士が権限の範囲を超えて協力しあうことで問題を解決していく日本の環境では、このような考え方で体系化された方法論がうまく機能しない場合もある。しかし、鉄道、航空機、自動車、医療機器、航空宇宙など、組込み製品にソフトウェアを搭載して世界に商品を展開している日本の組織では、世界の標準や規格が日本人に合わないと愚痴をこぼしているだけでは、グローバルマーケットで生きていくことはできない。

多数派を占める欧米中心に決まった標準であったとしても、世界に商品を供給していくのなら世界のルールににしたがって自分たちの商品の安全性や信頼性を示すことも必要なのだ。海外の企業と渡り合っていくのなら日本人もルールの策定に積極的に関わり、自分たちの主張を標準に反映させるように働きかけていくことが大事である。

国際標準を「自分たちには縁遠いもの」「天から振ってきたもの」「実質的には役に立たないもの」と考え、国際基準の縛りから逃れる抜け道を探すのではなく、基準が作られた背景や策定に関わった人々の考え方をポジティブに捉えて、どうしたら自分たちの中に取り入れることができるかどうかを考えることが重要である。

【安全性や信頼性を説明する責任】

グローバルなマーケットで商品をリリースし社会的な責任を負っていく組織は、ユーザーに対して商品を実質的に安全で信頼して使ってもらえるようにするのと同時に、商品が安全で信頼できることについて根拠を持って説明できるようにすることがが求められる。開発プロジェクトは、組織内の品質保証担当や外部監査機関、組込みソフトウェアを発注したクライアントなどにソフトウェアの安全性や信頼性を説明する。クリティカルデバイスのソフトウェアの世界では、定期的な内部監査、外部監査が行われ、監査の際に十分な説明ができないと是正を求められたり、最悪の場合商品の出荷を停止させられたりすることもある。

近年、組込みソフトの規模が増大し、複雑化が進んだことによって、組込み商品そのものの安全性や信頼性を示すだけでは事故を防止することが難しくなり、商品に搭載するソフトウェアの安全性や信頼性についても説明責任を果たす義務が生じるようになってきた。この傾向は、航空宇宙、鉄道、プラント、医療機器のようなクリティカルなソフトウェアでかつ、資格を持ったオペレータが商品を扱う業種で検討が進んできたが、今後は自動車など資格を持ったオペレータではない、一般ユーザーが使用するような機器に搭載するソフトウェアに対しても、安全性や信頼性の証明が求められるようになってくることが予想される。

【説明責任が果たせない製品は世界に受け入れられないし実際に危ない】

日本の特に昔気質のエンジニアは、「商品が実質的に安全で信頼性が高ければその根拠をわざわざ示す必要はない」、「自分たちには安全で信頼できる商品を作り上げる自信がある」、「その開発工程や工程内の活動はわざわざ他人に披露するようなものではない」と考える人が少なからずいるように見受けらる。実際に安全で信頼性の高い商品をアウトプットし続けることができていれば、その主張も分からないではないが、大規模、複雑化したソフトウェアシステムにおいて安全や信頼を確保し続けることが難しくなった今日では、仮に日本製品のリコールの数が他国の製品に比べて圧倒的に少なかったとしても「最終製品の品質が高ければ、開発の工程や安全や信頼の根拠を見せる必要がない」という主張は国際的には「逃げ」や「隠蔽」ととらえられてしまう。

日本人が作っているから安全であるという主張は組込みソフトウェアの規模が小さかった時代には通じたかもしれないが、ソースコードの行数が数十万行から数百万行になってくる、また、オフショア開発で海外にソフトウェアの制作を依頼するようになった現在では説得力がない。商品に組み込んだソフトウェアが安全で信頼できるかどうかは、国際的な標準で説明できりようにしておくことが必要となる。仮に日本のエンジニアが独自の方法で製品に搭載するソフトウェアの品質を確保しており、国際標準が示す方法と相違点があったとしても、その根拠を説明することが必要なのだ。

【国際標準をポジティブにとらえる】

このとき、ソフトウェアの安全性や信頼性を国際標準に沿って説明するための労力を、育った環境の違う人たちへの余計な作業だとネガティブに考えてはいけない。ソフトウェアに起因するリコールが増えてきたことによって、日本のユーザーだけではなく世界のユーザーが製品に搭載されているソフトウェアが安全で信頼できることの説明責任を求めるようになってきたのだと認識しなければならない。国際標準に対するネガティブな気持ちをポジティブに切り替えるには、まず、世界のユーザーが何を考え、何を要求していることを知って、国際標準が目指していることと、国際標準がに記された内容のうち自分対に役立つところを見いだそうと前向きに考えることが必要となる。

その考え方ができれば、現状の自分たちのソフトウェア開発において、国際標準のどの部分を取り入れると有効なのか、どうすれば世界に対する説明責任を果たすことができるのかが見えてくるはずである。また、国際標準の有効性は何かを追っていくとクリティカルデバイスのソフトウェアエンジニアでなくても、ソフトウェアの安全や信頼で先行する業界の世界標準を知り、それらの良いところを自分のドメイン、自分の製品に取り入れることができるようになる。それができれば、自分たちの製品においてリコールを起こさないソフトウェアを作るためにプラスに働くだろう。
　

安全ソフトウェアの設計

組込みZine に　安全ソフトウェアの設計～第三回 安全アーキテクチャの可視化～　を書きましたのでご参照ください。

【安全ソフトウェアの設計の記事の裏話】

この記事の中で紹介しているエレベータの安全ソフトウェアの話は、 『第６回クリティカルソフトウェアワークショップ』で始めて紹介した話で、このときソフトウェアの安全研究のオーソリティであるMITのナンシー・レブソン教授から、「ソフトウェアシステムに独立した安全装置を付けるという方法は誰でも考えつくやり方であり稚拙な方策だ。」とばっさり切られた。

そのとき、昔々の蛇腹とびらのエレベータではとびらをきちんと閉めないと電源が流れないシンプルなインターロック構造で安全を確保しているという例が紹介された。

ナンシー・レブソン教授が言いたかったのは、安全アーキテクチャを明確化すること、ソフトウェアにこだわるのではなく、システム全体でどう安全を確保するのか、いかにシンプルなアーキテクチャで安全を実現するのかを技術者は知恵を結集して考える必要があるということだ。

エレベータの安全機能をモデリングで可視化する話は、それに通じているので決して背反しないと思うが、口が悪いことで知られているナンシー・レブソン教授は、「ソフトウェアシステムの複雑性が生み出す危険性に目を背けて、安易な方法で安全を確保しようとすると痛い目にあうよ」と言いたかったのだと思う。

数々のソフトウェアが絡んだ事故を根気強く調査した人だからこそ言える教訓だと感じる。そう思ったので、この記事ではナンシー・レブソン教授のサジェスチョンをできるだけ反映させたつもりである。
　

組込みソフトウェア開発における安全文化

5月27日のIPAX2008で「組込みソフトウェア開発における安全文化」というテーマのパネルディスカッションを聞いてきた。

パネルディスカッション
「組込みソフトウェア開発における安全文化」
コーディネータ：
　　浅見 直樹　（日経BP社　執行役員　日経エレクトロニクス発行人）
パネリスト：
　　永島 晃　（横河電機　エグゼクティブ フェロー）
　　上田 政博　（アイシン・コムクルーズ　代表取締役社長）
　　吉岡 律夫　（日本システム安全研究所 所長）
　　山本 修一郎　（NTTデータ　技術開発本部　システム科学研究所　フェロー）

このパネルディスカッションで使われた資料は公開されていないので断片的ではあるが書き取ったメモをたよりにパネルディスカッションででてきたいくつかのキーワードを紹介したいと思う。

【安全を実現するには3Eが必要】

3Eとは、次の3つ。

1. Experience（経験）
2. Education（教育）
3. Enthusiasm（熱中、熱意、情熱、こだわり）

経験と教育は当然だが、安全の実現に Enthusiasm（直訳だと熱中、熱意、情熱だが、ここではこだわりという意味だろうとのこと）が必要だというのは「確かにその通りだ」と思った。

経験や教育を受けてもなんだかんだいって、面倒くさいとか、期限・納期の圧力などでくじけそうになったときに最後の支えとなるのが「安全へのこだわり」だ。

【発注者、開発者、運用者、利用者間の価値観の違いが不具合や欠陥を生む】

完璧な仕様を作成すれば価値観の違いなど関係ない、不具合や欠陥を限りなくゼロにすることができるという考え方が形式手法なんではないかと思うが、実際にはそうは簡単にはいかない。

今、SESSAMEで初級ソフトウェア技術者に同じ仕様でC言語の関数を作らせるといかにバラバラで危なっかしいプログラムができるのかを実験する教育コンテンツを作っている。実際、やってみると同じ仕様なのにプログラムの中身は千差万別、用意したテストケースはちゃんと通るが、変数を初期化していないとか、関数の出口が一つでないといった、設計の規範が浸透していない実例がごろごろ出てくる。

要するに仕様を完全にすることは難しいし、完全だと思っても、発注者、開発者、運用者、利用者の間で伝言ゲームをしていると勘違いや思いこみが発生する。それらの勘違いや思いこみを大きな不具合、欠陥に発展させないためには、あらかじめ関係者全体で価値観を一致させる必要があるのだ。

また、発注者、開発者、運用者、利用者はそれぞれの領域に責任と権限で線を引くのではなく、責任をオーバーラップさせてオーバーラップした部分をマネージメントすることが大事だという話もあった。

【技術者は嘘を言わない、問題点を隠さない、予見できる問題点を無視しない】

安全文化を考えるときにこの3点は絶対に忘れてはいけない。3EのEnthusiasm（こだわり）にも通じるが、納期のプレッシャーに負けて、嘘を言ったり、問題点を隠したり、予見出来る問題を「見なかったことにする」ようなことがあってはいけない。（『組込みソフト開発悪循環の構図』も参照されたし）

これらが蔓延してきた組織は安全文化の確立に逆行しているので特に注意が必要だ。

【ソフト技術者は方法論に興味があり、市場や商品には興味がない】

ソフト技術者はソフトウェア開発の方法論には興味があり、次の開発では前回よりもよりよい方法をトライしようと考えるが、商品がどのように使われるのか、どのような機能や性能が市場から求められているのかには興味がないという話だ。

組込みソフトの世界ではたぶんその傾向は少ないと思うが、価値観の共有にも通じるので安全文化の確立のためには市場や商品にも興味を持ってもらわないと困る。

【組込み製品に求められる品質の多様化と安全確保は背反することがあるか？】

これはパネルディスカッションの最後の方でコーディネータの浅見さんがパネリストに質問していたことだ。各人の解答は忘れてしまったが自分ならこう答える。

組込み製品に求められる機能や性能はインテリジェンスが増してきており、単機能では実現するこが難しくなっている。しかし、安全の確保は潜在的な価値を高める重要な要素であり、難しくても商品価値を高めるために必要だ。ユーザーは潜在的価値の低い商品にはその価値に見合った対価は払わない。品質の定義が顧客満足を満たすことであるならば、潜在的な価値を高めること、すなわち安全確保は品質の向上の一部であるから背反しない。

実際、車を買うときにエンジン性能やインテリア、エクステリアをまっさきに考えるけれども、サイドエアバッグ付きかどうか、ABSはついているかなどの安全機能を付けるかつけないかは単なる付け足しの悩みではなく真剣な選択だ。

パネルディスカッションのメモを見直してみると、総じて、やっぱり組込みソフトで安全を確保するには、その商品開発に関わるソフトウェアエンジニア全体で価値観の違いを埋める努力をしないといけないということなのだと思った。
　

トヨタのソフト戦略

ソフトウェア品質シンポジウムの基調講演でトヨタ自動車常務役員の重松崇氏の話を聞いた。トヨタの重松氏はESECなどの組込み系、ソフトウェア系のイベントでよく講演しているのを見掛ける。

もともと重松氏はソフトウェア技術者としてのたたき上げではなく、根っからの車屋から車載ソフトウェアを任されたという経歴を持つ。では、なぜバリバリのソフトウェア技術者ではない重松氏が組込みソフトウェア系、品質系のイベントに呼ばれるのか？　それはもちろんトヨタ自動車が日本だけでなく世界的に高い業績を上げている企業であり、トヨタ式と呼ばれるハードウェアの生産方式と同じように、ソフトウェアの開発にもトヨタ式と呼ばれるものが存在し、それを真似すれば高品質のソフトウェアをアウトプットできるだろうと多くの人が期待しているからだ。

さて、重松氏は90分の講演時間のうち、半分以上を使って現在と未来の自動車に求められること（エネルギー効率のよいモビリティの追求と安全の確保）を語った。さすがだと思う。つい最近、JR のSuicaのプロジェクトを牽引した椎橋氏の話を聞いたが、椎橋氏も講演のほとんどの時間、鉄道を利用するお客さんの利便性を向上するために自分がやってきたことをとうとうと語っていた。

ようするに組込みは業務ドメインを知り尽くし、顧客要求（トヨタの場合は顧客というより地球や人類のことを考えているとのこと）を高める意志と戦略を持った者が、ソフトウェア開発のどこに力を入れればよいのかわかるということだ。（これはビジネス系のソフトも同じか）

でも、なぜ重松氏は車に特化したソフトウェア開発戦略をわざわざあっちこっちでレクチャーするのだろうか。その情報の公開はトヨタにとってどんなメリットがあるのか？　

これは予想だが、トヨタはトヨタのソフトウェア戦略を公の場でしゃべることで、トヨタ社内やサプライヤのソフトウェアエンジニアに対して自分達の考え方を浸透させたいのだと思う。トップの方針を末端まで届けたいという意志があるに違いない。それに重松氏がしゃべった内容は、すぐに日経エレクトロニクスなどに取り上げられちまたの話題となる。なぜなら、冒頭で書いたように日経エレの読者はトヨタ式のソフトウェア開発方式がすべての業務ドメインに使えるだとうと期待しているからだ。

でも、特に組込みソフトの世界ではすべてのドメインに共通して有効な解法はない。なぜなら、業務ドメインや組織によって、市場要求や得意な技術、リアルタイム性などの性能要件、メモリ、CPUパフォーマンスなどの制約条件、組織成熟度、エンジニアのスキルがバラバラだからだ。でも、ツールベンダーやプラットフォーム提供者は、必ず自分たちのソリューションがすべて組込み開発に有効であるかのように宣伝するので気をつけた方がいい。こういうのにコロッとやられてしまう鴨ネギタイプのエンジニアやマネージャは組織の中に必ずひとりやふたりはいるものだ。

さて、重松氏は自動車に搭載する約60のECU群を今後4群に減らしていくと言っていた。自動車におけるECUのプラットフォームを共通化し、ソフトウェアの連携によって多様な要求（交通インフラから上がってくる情報を使って危険回避するような要求）に対応していくそうだ。

この施策の最大のリスクは、エネルギー効率のよいモビリティの追求と安全の確保のうち「安全の確保」の方が危うくなる可能性があるという点だ。

ECUが物理的に分かれ責務分割されている状態では、各ECUが起こす不具合、バグの責任は明確で、ECU別に責務の重さやソフトウェア品質の検証のハードルの高さを変えることができた。でもECUの数が少なくなってしまうと、責務の分割や安全の重要性はソフトウェアの中を見ないと分からなくなる。アーキテクチャを可視化して、システムの安全を確保するための安全アーキテクチャが確立されていることをソフトウェアの範疇で証明しなければいけない。安全クラスの低いアプリケーションソフトがメモリリークを繰り返して、重要なソフトに影響を与えないことを証明しなければいけない。ソフトウェアは人間が作っているモノなので絶対大丈夫とは言い切れないし、誰かがちょこっとなおした1行の変更がシステムに大打撃を与える可能性も否定できない。

ECUの数を極力少なくするのなら、ソフトウェアの安全設計、安全アーキテクチャが絶対に必要だと思う。大規模・複雑化したクリティカルデバイスにおいては、安全アーキテクチャは今後重要なテーマになっていくだろう。また、プラットフォームの共通化のメリットがデメリットを上まわる自信がないといけない。組込みソフトはいろいろなトレードオフのバランスの上で顧客満足を確保しているのだ。

さて、重松氏はモデル駆動開発についてサラッと問題点を口にしたが、自分は大事なその一言を聞き逃さなかった。それは「戦略なきプラットフォームの共通化は失敗（プラットフォームベンダにいいようにやられる）する」ということばだ。

プラットフォームの共通化・モデル駆動開発ということばに踊らされて、商品の価値を高めることができるという確信がないままに、共通プラットフォームを採用してしまうと後々商品開発の基盤をプラットフォーム提供者に握られてしまうことに気がつく。重松氏はこの例として、ヨーロッパの共通規格団体 AUTOSAR が Windows を車載ソフトの共通プラットフォームとして採用する提案をしてきたので、日本の共通化団体の JasPar で使えない部分があることを証明してAUTOSARに進言したという例で語っていた。

重松氏の話を聞いていてトヨタは自前で自動車のソフトウェア全部を作り上げるつもりはないように聞こえた。サプライヤからのソフトウェア供給は今後も続くという考えのようだ。そうなると、クライアントとなる自動車メーカは難しくなっていくソフトウェアの理論についてどんどんうとくなり、サプライヤ側は自動車を取り巻く環境の詳細を把握しきれなくなる。トヨタの重松氏やJRの椎橋氏のように車や鉄道のことを知り尽くし、ソフトウェアの品質がどうあるべきかがわかる技術者がだんだんいなくなって顧客要求をよく理解しないソフトウェア技術者が作ったプログラムを自分たちの商品に実装せざるを得なくなってくると思う。

これはかなり危ない。車や鉄道の特性やリスクを知らない、意識しない技術者が作ったソフトウェアは間違いなく危ない。その機器が使われる場面においてどんな危険やリスクがあるのか知らないツールメーカのツールやプラットフォームも危ない。どうしてもそれらを使うのなら、それらが危なくないことを証明する責任は採用した側にある。それだけは忘れてはいけない。

P.S.

「トヨタはソフトウェアでもトヨタ式を提唱していくつもりなのか？」という会場からの質問（電通大のにしさんより）に対して、重松氏は「生産方式には自信があるが、ソフトウェアについてはむしろ外部の知恵（例えばソフトウェア工学で培われたプロセスアプローチなど）を取り入れていきたいというようなことを語っていた。トヨタ式ソフトウェア開発は参考にするべきもので、生産方式のように安易に真似してはいけないということだ。

Blogger のコメントは読みにくいので本文の方に入れてしまいました。

自動車エンジニアさん さんは書きました...

先日、コメントを書かせて頂きました『自動車エンジニア』です。

また、コメントさせて頂きます。

-----------------------------------
プラットフォームの共通化・モデル駆動開発ということばに踊らされて、商品の価値を高めることができるという確信がないままに、共通プラットフォームを採用してしまうと後々商品開発の基盤をプラットフォーム提供者に握られてしまうことに気がつく。
----------------------------------

確かにそのとおりだと思います。
自動車業界でいうと、モデルベース開発がMATLABという１つのツールに依存しすぎると、ツールベンダーに主導権を握られるリスク当然はあります。

実際そうなりつつありますが...
MathWorksがマイクロソフト状態にならないように、MAAB、J-MAABなんかでも、MathWorksにソフト改良への要求などを（強気に?）行って、かなり牽制しようとしてますが...


デンソーなんかは、ツールベンダーに依存しなくてよいような方向を志向しているのかどうかわかりませんが、最近はプラットフォーム環境を内製化しようとしてしいる感じは、各公演等から感じられます。
トヨタでも同じようなことは考えられているかもしれません。




----------------------------------
重松氏の話を聞いていてトヨタは自前で自動車のソフトウェア全部を作り上げるつもりはないように聞こえた。サプライヤからのソフトウェア供給は今後も続くという考えのようだ。
----------------------------------

参考までに、トヨタは自前で組み込み用のＯＳの開発を行っているようです
あくまで、メディアの情報です。

【トヨタ、「クルマＯＳ」独自開発】

【50人体制の開発組織・トヨタ正発表】

【経済産業省、車載標準OSを開発へ--トヨタや日産らが参加】


トヨタも現状は、サプライヤーにソフトの供給を依存しているかもしれませんが、もしかしたら、将来的に自前でいくことも考えているのかしれませんね。

ただ、本当の戦略？？です


-----------------------------------
これはかなり危ない。車や鉄道の特性やリスクを知らない、意識しない技術者が作ったソフトウェアは間違いなく危ない。その機器が使われる場面においてどんな危険やリスクがあるのか知らないツールメーカのツールやプラットフォームも危ない。
----------------------------------

自動車業界にいる者として、真摯にご指摘を受け止めなければなならないと思います。
現状、車メーカー側には組み込みのエキスパートは少ないように感じます。
いくつかの車メーカーはグループ内にＥＣＵメーカーをもっていて、組み込みは子会社のＥＣＵメーカーに任せて、車メーカーはシステムのアルゴリズム開発に注力するという方向かもしれませんが、それが、大問題の原因になるとのご指摘かと思います。

車メーカー：組み込みの素人、制御アルゴリズムや車両の特性には詳しく、ロジック開発のみやる
⇒どんどん、組み込みに疎くなる。
⇒【組み込み技術】と【制御ロジック/制御対象特性】の両方を把握するエンジニアがいなくなる。
システム/組み込み開発で全体を把握でる人がいなくなり、部分分のみの知識/経験しかない人だけになると絶望的になる。

さらに、自動車の特性に関する知識に疎いツールベンダーが、人命を預かって走る車において、ＥＣＵの組み込みの根幹を握るようにると、さらに怖いというご指摘かと思います。
（間違っていたらご容赦ください）

車メーカー側は組み込み技術の向上（組み込みエンジニアの育成も含めて）を真剣に考えていかなければいけなかと思います。
最後は車メーカーが全ての責任をとらなければいけませんので、組み込みＥＣＵの責任も最後は車メーカーが持たなければなりません。


私も、組み込みに関する知識不足を痛感しています。
最近、組み込み関連の本を何冊か購入して勉強していますが...

『組込みソフトエンジニアを極める』も今、読ませて頂いております！

ＥＣＵメーカーの組み込みエンジニアとも情報交換及び、今後のシステム/組み込み開発のやり方を議論する場なども定期的にもっていたりします。

----------------------------------
こういうのにコロッとやられてしまう鴨ネギタイプのエンジニアやマネージャは組織の中に必ずひとりやふたりはいるものだ。
----------------------------------
私もそんな１人ですね（笑）
ベンダーの営業トーク（いいことしか言わない）によくコロッといったりします（笑）

9月 08, 2007

sakai さんは書きました...

自動車エンジニアさん、コメントありがとうございます。

自動車エンジニアさんは本当に自動車のソフトウェア開発にお詳しいですね。

自動車のソフトウェア安全については、ISO 26262 の策定が進んでいると思いますが、ソフトウェアの安全性を分析する考え方として MISRA-SA というのもあります。

どっちにしても、ソフトウェアの安全性は電気的安全性のようにはっきりと白黒つけることは難しいので、エンジニアがどれだけ客観的な根拠・証拠をもってシステムの安全性や信頼性を証明できるかどうかにかかっていると思います。

自動車ソフトウェアの安全性は、これまでソフトウェアエンジニアがユーザーの要求や機器のメカニズムを熟知しており、どんな風に使われるのか、どんな風に ハードソフトが動くのか知っていてソフトウェアを作っているということで担保されていた部分が大きかったと思いますが、これからは誰がどんなソフトウェア を作り込んでしまうか分からないという前提で、ソフトウェアの安全性や信頼性が確保されていることを客観的に示していかないといけないと思います。

モデルベース開発は安全を客観的に示すための有力な方策の一つだと思いますが、モデル変換のソフトウェアを作っているエンジニアが特に車のメカニズムを意識していない場合、意図しない洩れや抜けにより変なコードが埋め込まれてしまう可能性はあると思います。

ただ、「理系白書から考えるソフトウェア工学」で書いたように、モデルベース開発が自然科学を相手にしているうちは正しく変換できているという信頼性をVerification（検証）することは難しくないと思います。

しかし、自然科学以外のすり合わせ的ソフトウェアアーキテクチャをモデル駆動開発に取り込んでいった場合は、信頼性の証明やシステム全体のValidation（妥当性確認）は難しくなってくると予想します。

組織内部の Closed のすり合わせ的アーキテクチャ・アルゴリズムの安全性や信頼性は、そのハード・ソフトが使われる場面や要求を実現するメカニズムを熟知しているソフトウェ アエンジニアの「慎重さ」「そのソフトウェアが安全を担っているという使命感」のようなものが確保していたのが本当のところでしょう。（要求通りに作られ ているかどうかを検証するのは Verification です）

これからは、その安全アーキテクチャ、安全ソフトウェアをカプセル化して、他の安全クラスの低いソフトウェアから隔離し、影響を受けにくいソフトウェアの構造を作っていかないといけないと思います。

これは ECUが物理的に分かれていることで責任分担され証明しやすかった状態に比べると、自信を持って「安全です」と言えるところまで持っていくのに時間も手間やソフトウェア的工夫もいるだろうと予想しています。

自分は自動車ドメインのエンジニアではありませんが、このブログでもその方策について考えていきたいと思います。

9月 08, 2007

組込み機器におけるギャランティとベストエフォート

2007年5月20日付けの毎日新聞朝刊に「時代の風」というコラムがあり、東大の坂村健先生の写真が載っていた。

坂村先生の写真は ESECとかETのパンフレットやWEBサイトではよく見掛けるが、新聞のコラムで見たのは初めてだった。

コラムのタイトルは『デジタル・デバイドと自己責任』で、坂村先生は自宅のインターネットがうまくつながらなくなり、その復旧でえらく手間取ったという先生の知人のエピソードを通して、インターネットの世界におけるベストエフォート（最大努力）型とギャランティー（性能保証）型との違いについて解説している。

このコラムを読んだときに頭に思い浮かんだのは、『組込みソフトエンジニアを極める』で書いたリアルタイム要求とスループット要求のことだ。

リアルタイムシステムにおけるリアルタイム要求にはハードリアルタイムとソフトリアルタイムがあって、ハードリアルタイムは応答時間を保証しているのでギャランティー型と言える。それに対して、単位時間あたりの処理能力が高いことが要求となっている場合はスループット要求となり、応答時間という観点から見るとそれはベストエフォート型となる。

リアルタイムOSは応答時間を保証（ギャランティ）することができ、昔のUNIXやWindowsなど、CPUの処理時間を各スレッドに均等にしか割り振れないOSの場合は応答時間で考えればベストエフォートだ。

ベストエフォートだから、CPUの性能が非常に高かったり、平行に動いているスレッドの数が少ない場合は全く問題ない応答をするのだが、Windowを10も20も開いていくと徐々にレスポンスが悪くなる。これがベストエフォートのベストエフォートたるゆえんだ。

リアルタイムOSを使っても、パフォーマンスが100%を超えることはあるが、優先度の高いタスクに対するCPU時間を保証することはできる。これがギャランティ型のギャランティ型たるゆえんだ。

さて、坂村先生はこのコラムの中で専門のリアルタイムOSのことについては一言も触れておらず、インターネットがつながらない原因をたらい回しに合いながら突き止めても「ルーターの相性が悪いようです」と言われてしまうのは、インターネットはユーザーの責任の上に成り立っているベストエフォート型のシステムであり、今の世の中どんどんベストエフォート型のシステムが増えていて、身を任せていればいいというシステムはほとんど存在しないからだと書いている。

【デジタル・デバイドと自己責任より引用】

　インターネットはその「自由化」のもっとも進んだものだ。あるサイト中のデータを見るまでには実はたくさんの関係者がいて、それぞれが独立している。だから「インターネットの責任者を呼べ」と言っても、誰なのか分からない。
　しかし、だからこそ会社や国の枠を超えられる。たとえアフリカとでも、簡単にしかも無料でメールのやりとりができるのはそのおかげだ。

　：

　鉄道と道路、電話とインターネット・・・これらの違いを考えればわかるように、自由度を求めれば求めるほどシステムはベストエフォート型になる。そういう時代の情報システムでは、技術設計と同程度かそれ以上に制度設計が重視される。技術ではカバーできない部分は制度でカバーする。こうした発想が必要なのだ。

【引用終わり】

ギャランティ型とベストエフォート型のたとえとして、坂村先生は鉄道と道路、電話とインターネットを対比させた。でも、ここでは組込み機器における、ギャランティ型とベストエフォート型について考えてみたい。

そもそも、組込み機器のユーザーは製品に対してメーカーが機能や性能をギャラインティするものだと考えていると思う。インターネットのように、自由度が求められることによってベストエフォートに変化し、ユーザーが自分自身で責任を負担しなければいけないと考えるようになるのだろうか？

インターネットだってギャランティしてくれる誰かがいれば、その対価を払うユーザーはいる。組込み機器は機能や性能をギャランティしてくれるからこそ、ちょっと高くても買ってくれるお客さんがいるのだと思う。

もしも、組込み機器に自由度が求められたとしても、それは組込み機器全体がベストエフォート型にするのではなく、ギャランティの部分とベストエフォートの部分を切り分けることで解決しなければいけないのだと思う。

これを勘違いして、組込み機器は自由度が求められるようになったのだから、ベストエフォート型にすればよいと考えるとユーザーからそっぽを向かれる危険性が高い。

ハードディスク内蔵のDVDレコーダで立ち上がり時間が長くなったのは、メーカーが組込み機器をベストエフォート型にしてしまった典型的な例のように思える。

ちょっと観点が変わるが Linux などのオープンソースソフトウェアを組込み機器に採用した際に、オープンソースソフトウェアの信頼性をギャランティするのはLinuxを供給するベンダーではなく採用した組織側であるということを忘れている人がいるように思う。

Linux を供給するベンダーと問題があったときには速やかに原因の究明やサポートをする契約を結ぶことはできるが、オープンソースソフトウェアそのものの信頼性をギャランティしてくれるベンダーはほとんどいない。オープンソースの自由度がもともとベストエフォートに流れるようになっているからそうなるのだが、日本人は対価を払って買ったものは、その製品の機能や性能が当然ギャランティされているものだと思い込んでいるから勘違いするのだと思う。ベストエフォート型の商品や、ユーザーが一部自己責任をともなう商品などが（説明書にそう書いてあったとしても）実際には存在するなどと考えていないのだ。

メーカーも自己責任の部分は販売するときに声を大にして言わない、説明書の隅に小さく書く。でも、ベストエフォートの部分でユーザークレームが発見され社会問題にまで発展してしまうと、結局はメーカーがやり玉に上げられる。メーカーも「ベストエフォートですから、責任はユーザーにあるのですよ」とは主張しない。日本人特有の責任と権限を明確にせず、問題は発生したときに考えればいいやという曖昧な対応の結果だ。

自由度の高いインターネットのシステムを使っているユーザーでも坂村先生が言うように、システムがギャランティ型ではなくベストエフォート型になっているので、自己責任は発生しており、その分システムを安価に使えていると認識してくれるようには思えない。

日本のメーカーは商品の購入時にユーザーの自己責任は前面に出したがらないし、多くのユーザーはトラブルが発生して自己責任の部分が明確になっても「そんなことは聞いていない」と反論せず、泣き寝入りしてしまうので、わざわざマイナスイメージを最初に言う必要がないのだ。

しかし、組込み機器の中でも、特に安全性や信頼性が求められる機能や性能については、メーカーはそれらの機能や性能について保証しなければいけないということを忘れてはいけないと思う。

そこを自由度の高さを実現するためにベストエフォートでよいのだと考えた組織は、市場の中で競争優位を保つことはできなし、ユーザーは文句を言わずにそのメーカーの商品を買わなくなり、そのメーカーは知らず知らずに市場でのシェアを落としていくように思う。

組込みソフトウェアの安全設計

先週、電気回路設計から学ぶ組込みソフト設計という記事を書いた。しかし、たった一週間で考え方を転換しなければいけなくなった。

なぜなら、今週宇宙航空研究開発機構(JAXA) が開催したクリティカルソフトウェアワークショップ(WOCS2006)の中で、マサチューセッツ工科大学のナンシー・レブソン教授の講演を聴いたからだ。

MITのナンシー・レブソン教授は、左の SAFEWARE という本を最近出版した。（日本語版の予定はまだない）

ナンシー・レブソン教授は日本ではほとんど知られていないと思うが、ソフトウェアの安全設計の分野では非常に有名な方で、1980年代から今日に至るまで、アメリカでソフトウェアで安全性の関する大きな事故があると呼び出され調査をし論文やレポートを出してきた。書かれた論文はすでに100を越えている。スペースシャトルコロンビア号の事故など航空宇宙関係のソフトウェアがらみの事故調査やミサイル防衛システムの安全設計に関する研究などもしている。

ナンシー・レブソン教授は口が悪いことでも有名で、自分の経験上でソフトウェア安全のためにマイナスの要因があると感じたときには、はっきりと NO を突きつける。

WOCS2006のパネルディスカッションで、シンドラーのエレベータの安全対策についてパネリストたちがディスカッションしていたとき、ナンシー・レブソン教授は、「自分はエレベータの安全対策について研究したことはまだないが、独立した安全装置の設置は、もっとも安直な対策であり愚かな選択だ」と切って捨てた。（国土交通省主催の事故検討委員会では独立した安全装置の設置を義務づける方向に動いているらしい）

ナンシー・レブソン教授は独立した安全装置の設置対策が本来正しく動くべき基本機能の不具合を見えなくしてしまう危険性を指摘していた。威圧感があり、きっぱりと NO というので曖昧だった部分について再考すべき点が浮き彫りになってくる。

さて、なぜ先週「電気回路設計から学ぶ組込みソフト設計」の記事の中で、組込みソフトの設計も電気回路設計から学ぶべきことがあるといったことを、今週方向転換しなければいけなくなったのかを述べたい。

それは、付け足しのように書いた「組込みソフトはこのような融通の利かない決まり切った使い方しかできないハードウェア部品同士の隙間を埋めるための存在であるとも言える」という記述は実は組込みソフトのメリットでもありデメリットでもあり、この問題を避けて通ることはできないから、電気回路設計の方法をそのまま持ってくることはできない、電気回路の設計方法を持ってくると失敗する可能性が高いと気づいたからである。ソフトウェア部品の信頼性を高めて組み合わせるとシステムの信頼性が高まるという考え方は機能安全(IEC61508）の考え方に近く、ナンシー・レブソン教授はIEC61508を「役に立たない」と言っていた。

電気回路設計から学ぶ組込みソフト設計の記事で参考にすべきと書いた「ソフトウェアを部品化して完成度を高めつなぎ合わせる」という考え方は、ハードウェアの設計をベースに考えられており、ハードウェア設計を長年やってきた人が最初に考えうる発想である。

ナンシー・レブソン教授の話を聞いていて「そこには落とし穴があり」25年の歳月の間、エンジニアはこの落とし穴に落ちることで事故を起こしてきたと言っているように感じたのだ。

「組込みソフトはこのような融通の利かない決まり切った使い方しかできないハードウェア部品同士の隙間を埋めるための存在であるとも言える」ということは組込みソフトウェアが生まれたときからこれまで変わっておらず、ソフトウェア部品が増えてきて、それらの部品を利用することが多くなってきたことは事実だが、今後も組込みソフトウェアのすり合わせ的な要素は決してなくらなないと感じる。

そうすると、ソフトウェアを部品化して、完成度の高い部品を組み合わせてシステム全体の安全性や信頼性を高めるという考え方は、こと組込み機器の安全という視点で考えたとき非常に危ないような気がしてきた。

そもそも完成度の高いソフトウェア部品を作るのは時間もコストもかかるし、ソフトウェアは変更しやすいだけに5年も10年もソースコードに手を入れないで使い続けることはほとんどないだろう。もともとソフトウェアは必要に応じて姿形を自由自在に変えることができることが特長であるのなら、完全に固定してしまおうと考えること自体にムリがあるように思える。

だからといって部品化の努力は無駄だとは言わない。再利用可能な資産としてソフトウェアのモジュールを特定し、インターフェースを明確にし、信頼性を上げておくことは、システムの安全性を高めることに必ず貢献する。しかし、システムの安全性はあくまでも、システム全体の安全設計、安全アーキテクチャを考えた上で成り立つのであって、システム全体の安全設計、安全アーキテクチャが十分に考えられていない状態で信頼性が高い思われる部品をつなぎ合わせたのでは、結果的に安全にはならない。コア資産として特定したソフトウェアモジュールはインターフェースは変えないでおいて、中身をブラックボックスにせず常によりよく進化できるようにしておけばよいのだ。

【クリティカルソフトウェアの設計指針】

1. ユーザー要求や安全要求を考えソフトウェアシステムのアーキテクチャを設計する
2. ソフトウェアのサブシステムの信頼性を高める努力をする
3. 最初に考えた設計思想が崩れていないことを開発ライフサイクル全体に渡ってチェックする
   

このクリティカルソフトウェアの設計指針で大事なのは順番で、2が1より先に来てはいけない。先週の電気回路設計から学ぶ組込みソフト設計の記事では2が強調され、1が置いていかれてしまう危険性があると思ったので今週違う見方を書いた。

WOCS2006でJAXAの片平さんがクリティカルデバイスのソフトウェアを設計する日本のソフトウェアエンジニアにとってとても参考になる講演をされた。（講演資料はしばらくすると JAXAのWEBサイトからダウンロードできるようになる）

最後に片平さんに向けて発信したメールの内容を添付する。

【安全文化について。酒井発信のメールより引用】

さて、WOCS2006の片平さんのスライドで、次の考え方は直感的に「正しい」と思いました。

－ソフトウェア安全確保のための重要な要素－

　　　□　　　　Design & Verification
　　□□□　　　Methodologies & Techniques
　□□□□□　　Rules/Regulations
□□□□□□□　Safety Culture

※Rules/Regulations:Rules/Regulations for Safety Critical System development

安全文化がベースにあるべきだというのは“直感的に”正しいと感じます。しかし、Safety Culture という表現は非常に曖昧で具体的に何をすればよいのか分かりにくいとも感じます。

たとえば、協力会社にソフトウェア開発を委託したり、多人数でソフトウェアを開発するときに何をすべきかということです。

私たちは経験的に協力会社にソフトウェア開発を委託するとき持ち帰り仕事を嫌います。持ち帰られると、開発品がどんな用途で使われ、どんなユーザーリスクがある製品が知らない者がプログラムを書くことがあるからです。（実際にこれは危険だという感覚だけあります）

また、派遣も含むプロジェクトメンバーで新しい人が入ってきたら最初の段階で必ず実施するのは、この製品が用途で使われ、どんなユーザーリスクがあるか、そしてその人が作るソフトウェアのパートは、どの部分なのかということを完全に理解するまでレクチャーするということです。これも直感的にそれがソフトウェアの安全性を確保するのに一番近道だろうと考えるからだと感じます。これは、上の積み木でいえばまさしくSafety Culture を新しい技術者に伝えたということになります。

Design & Verification や Methodologies & Techniques やRules/Regulations にほころびがあっても Safety Culture が伝わっていれば、穴は小さくなるだろうという経験的な直感からそうしています。

でも、これには限界があり、ソフトウェアの開発規模が大きくなってきたら開発者全員に安全文化を行き渡らせるのはむずかしくなります。（特にオフショア開発などの場合）

開発者が何十人にもなると「今日の昼ご飯は何だろう？」などポケッーと考えながらプログラムを書く者も出てくるでしょう。

実際、これが一番危ないと感じるので、素性がよく分からない人には製品のソフトウェアは作らせず、検査用のソフトウェアや実験用のソフトウェアを作らせます。でも、こんなやり方は小さいプロジェクトだからできるのであり、大きなプロジェクトでは難しいと思います。

実際、サプライヤーに対して納品対象のソフトウェアに静的な解析をかけ、一定の成績が出ない場合は検収を挙げないという方策をとっている会社もあると聞きます。

これだけ聞くと、Safety Culture の伝達なしでも、Design & Verification や Methodologies & Techniques や Rules/Regulations でソフトウェアの安全性（この場合信頼性か？）は確保できるように思いますが本当にそうでしょうか？

安全文化を伝えることができない場合は、システム全体のアーキテクチャを安全設計にし、そこで押さえる、そうすれば、グレーボックスのモジュールがあっても、システムの構造でリスクを抑えることができるという考え方が正しいのではないでしょうか。

Safety Culture は人間の曖昧さをポジティブに考えたときの施策で、Design & Verification や Methodologies & Techniques や Rules/Regulations は人間の曖昧さをネガティブに考えたときの施策のように感じます。

人間の曖昧さをポジティブに考えるというのは非常に日本的であり、うまくいけば効果は高いという感覚があります。しかし、対策も曖昧になりがちであるというのも事実です。でも、それぞれのドメインによって違いはあるにしても、安全設計のアーキテクチャというものが存在するのなら、これまではエンジニアの頭の中だけに存在していたアーキテクチャを表に出し継承することができれば安全設計を構築できるようになると思います。

エレベータの独立したソフトウェア安全装置を設定するというモデルは、そのような安全設計アーキテクチャの一つであり、エレベータシステムというドメインでは有効性はあるように思います。Prof. Nancy Leveson は「自分は、エレベータシステムについて調査したことはないけれども、独立した安全装置の設定はもっとも安直な考え方だ」と言っていました。

この「エレベータシステムについて調査したことはないけれども」というところが重要であり、この言葉の裏には、安全対策・安全設計はそれぞれのドメインで異なるということも言えるのだと思います。

だから独立した安全装置のような、どのシステムにも効きそうな対策は安直だという論理につながりますが、実際ドメインによっては独立した安全装置が有効な場合もあるのではないかと感じました。

Safety Culture の重要性を主張するには、Safety Culture の定義と、Safety Culture を伝達するためには何をすればよいのかについて明確にしておかなければいけないと思います。

結果的には曖昧な話になりそうですが、Safety Culture がなければ、安全につながるアーキテクチャを設計することはできない。それぞれのドメインに最適化した安全設計、安全アーキテクチャが確立することが、システムを安全に導くことに有効であるという論理に結びつけることができればいいと思います。

日本のエンジニアは安全文化からドメインに最適化した安全設計、安全アーキテクチャを作り出す能力が高いのではないかと感じます。

裏返すと、その特性をよく考えずに、Design & Verification や Methodologies & Techniques や Rules/Regulations だけに着目すると、安全文化が置き去りにされ逆に安全性が損なわれる可能性がある。

また、Safety Culture の伝達が効くのは日本人の国民性に起因する何かがありからで、海外でシステムの安全を確立する際に Design & Verification や Methodologies & Techniques や Rules/Regulations に力が入るのは日本人の国民性に起因する何かの存在（職人魂、クラフトマンシップ？）を勘定にいれないからではないでしょうか。そう考えると、自分の経験的な直感に近づきます。

【引用終わり】

製品開発に長いこと従事して切磋琢磨している日本の組込みソフトエンジニアは、欧米人に上手く説明できなくても「この製品の信頼性や安全性は高いんだ」という自信がある。

これは根拠のない自信ではない。ちゃんと根拠はあり、その根拠はすでに製品のソフトウェアシステムに実装されている。だから、製品の信頼性や安全性が高いという根拠であるソフトウェアシステムのアーキテクチャを示すことができればシステムの安全性や信頼性について説明できるはずなのだ。

これからの日本の組込みソフトエンジニアはソフトウェアシステムの設計において、どんなアーキテクチャを考え、そのアーキテクチャが製品の信頼性や安全性にどのように効いているのかを説明できるようにならなければいけない。

みんないい製品を作る技術を持っているのに、それがどんなしくみでできているのか説明できないだけなのだ。

また、そのいい製品を作る“しくみ”（アーキテクチャ）はユーザーニーズや装置に求められる安全性、ハードウェアデバイスやソフトウェア開発環境など、製品や製品群の隅々を知り尽くした技術者が設計できるのであり、ソフトウェアシステムの規模の大きくなった現在では、優秀なアーキテクトが考えた設計思想・アーキテクチャを継承するということも考えていかないと開発が追いつかないというところまで来ている。

------ その後 -------

この後、JAXAの片平さんから上記のメールに対する返信をいただいた。私信なので一部これは多くの人に伝えた方がよいという部分だけ紹介しようと思う。（自分はアーキテクトなのでアーキテクチャに目がいきがちだが、安全はアーキテクチャだけで作り上げるものではないということが分かる。）

【片平さんからの返信から】

　　：
　　：

システムレベル（トップダウン）の安全の考慮が重要であるという考えは、 「もぐらたたき」にならないようにするために重要と思います。 ここは日本のこれまで不得意とする部分かなという印象を持っています。

安全文化を伝えることができない場合は、システム全体のアーキテクチャを安全
設計にしそこで押さえる、そうすれば、グレーボックスのモジュールがあって
も、システムの構造でリスクを抑えることができるという考え方でよいのではな
いでしょうか。

システムレベル（ユーザに利用シナリオを含む）で対処すべき安全対策もありますし、 装置の詳細な設計、コード上の対策が必要で、アーキテクチャだけで押さえ込む ことはむずかしいと感じています。

－安全文化の定義について－

1)　開発側の安全文化
　　・ルール（安全審査）や安全要求などに裏づけられるエンジニアの基本思考
　　・経営者の安全確立のための意識（具体的には組織体制、資金、コミットメント）
　　・現場の文化構築（教育、経験により構築できるもの）

2)　社会的な文化
　　・利用者側の意識（安全に対する理解、犠牲の許容）
　　・過剰なプレッシャーの排除
　　・安全上Noと言ったときの理解

日本人の得意とするところだとも思いますが、上記に記述した安全文化に関して、 安全に対する理解、風土といったものが、日本にあるかというとかなり 疑問があります。 日本人がドメインに最適化した安全設計、安全アーキテクチャをつくりだす能力が 高いというのは同感です。安全設計、安全アーキテクチャの確立は、 Design & Verification のレベルの話で、Methodologies & Techniques やRules/Regulations をそれを下支えするものと信じてます。

安全文化に関しては、おそらく、日本と欧米とでは効かせ方が異なる、と思ってます。 欧米はルールを決めてギシギシやらないと安全文化が崩壊しやすい。それに対し、 日本では理解が高まり、根付けば、うまくいく可能性がある。と思います。

【引用終わり】

「 欧米はルールを決めてギシギシやらないと安全文化が崩壊しやすい。それに対し、日本では理解が高まり、根付けば、うまくいく可能性がある」というところで読者のみなさんはうなずいているのではないかと想像する。

　

シンドラーのエレベータ事故（つづき）

日経ものづくり 2006年10月号に シンドラーのエレベータの検証記事が掲載された。2006年6月，東京都港区のマンションで起きたエレベータでの事故の原因はまだ分かっていないが、日経ものづくりの記事ではエレベータの構造や安全装置のしくみなど、かなり深いところまで掘り下げておりいろいろと勉強になった。

【特集 －事故は語る－「シンドラーの波紋」 記事の内訳】

Part 1 総論
相次ぐ事故に共通する課題
再発防止に三つの視点

Part2 安全装置の裏側
トビラが閉じずに動くカゴ
想定外の事態で表れた弱点

Part3 軽視された保守
自覚のなさが高めるリスク
業者間の責任分担を明確に

Part4 生かせぬ教訓
埋もれてしまう不具合情報
分析と公開が予防のカギ

【引用おわり】

自分が興味があるのは、エレベータの構造とハードウェアデバイス、そしてエレベータの詳細な要求仕様である。これらが分かればエレベータの制御ソフトウェアをどのように作ればいいかだいたい分かる。

組込み機器はユーザーとして使う立場に立てば、その機器の表に出ている制御仕様はだいたい分かる。ソフトウェアの価値である顕在的価値と潜在的価値のうち、顕在的価値の部分は、外に見えているところからその中身を予測できる。

しかし、組込み機器の潜在的価値を構成している「使いやすさ」や「安全性」「保守性」などの部分は、外側からではよく分からない。よく分からないのだが、「使いやすさ」「安全性」「保守性」に使われているハードウェアデバイスがシステムとどのように結合しているのかが分かると、ソフトウェアがどんな制御をしているのかもある程度想像できる。

今回、日経ものづくりの記事で再確認したのは、安全装置に関しては「かご側のトビラ確認スイッチ」「乗り場側のトビラ確認スイッチ」「モータ」「電磁ブレーキ」の関係がベースにあるということだ。

戸開走行しないための安全機能は、かご側のトビラと乗り場側のトビラが両方とも閉じているときのみ、電磁ブレーキを解除し、モータを回転させてよいということだ。

2006年6月の事故では、かご側のトビラと乗り場側のトビラが両方開いてるにも関わらず、電磁ブレーキが効かずにモータが回転してしまった。電磁ブレーキの摩耗の疑いがあるようだが、電磁ブレーキが摩耗していたとしても、それとは別に、トビラの開閉のセンシングを誤り、モータを積極的に回転させなければ事故は起こらないことから、どう考えても運転制御プログラムが怪しい。

そう考えていたら、ソフトウェアの不具合を誘発しそうな要因があることが今回の記事でわかった。それは、戸開走行の例外処理だ。

【戸開走行する例外処理も－「シンドラーの波紋」より引用－】

実は、安全制御装置にはトビラが開いた状態でも電源を投入するようにバイパスが設置されているときがある。それが、再床合わせ装置を持つエレベータの場合だ。

再床合わせとは、ロープの伸びなどによってカゴの床面と乗り場側トビラの床面に発生した段差を調整すること。乗り場の床とカゴの床に段差があった場合に、つまづいたりして危険だからだ。主に、ロープが長い高層エレベータや積載容量が大きいエレベータで採用される。

【引用おわり】

要するに、トビラが開いたときでも再床合わせゾーンの範囲内であれば電磁ブレーキを解除し、エレベータをゆっくりと走行させる。この際には、一種の戸開走行となる。ただし、この例外仕様の安全対策として、再床合わせゾーンを越えてドアゾーンを外れると安全装置がモータへの通電を遮断し、エレベータを制止する。

この再床合わせの戸開走行のソフトウェアは危険を伴う例外的な処理であり、他のソフトウェアに比べて、より慎重により正確に作り込まなければならない。

ここで組込みソフトエンジニアとして思うのは、安全面から考えたときのこの例外処理が他の処理より重要度が高いということを示すのは以外に難しいということだ。

安全装置がハードウェアデバイスとして、メインCPUの制御から独立している場合、その機能や役割は外から見えやすい。メインCPUとのインターフェースも明確であり、安全装置単体としてのテストもしやすい。しかし、安全をつかさどる制御ソフトウェアがその他のソフトウェアと一緒になってしまっていると、その重要性の高いソフトウェアをマーキングして「ここが装置の安全性を確保するためのソフトウェアですよ」と強調したくても、外からその重要性を分からせる方法がないのだ。

結局、ソースリストを追いかけることでしか問題があるのかないのか分からないということになりがちだ。

たとえば仮に、モータを制御する関数の中身が以下のようになっていたとしよう。

void driveMotor（ 命令 ）
{

　　/* モータを止める処理 */
　　if ( 命令 == STOP) {
　　　　モータを止める;
　　　　電磁ブレーキON；
　　}

　　/* モータを正転させる処理 */
　　else if ( 命令 == UP ) {
　　　　status = getCageStates();
　　　　if ( status != open ) {
　　　　　　電磁ブレーキを解除;
　　　　　　モータを正転させる;
　　　　}
　　}

　　/* モータを逆転させる処理 */
　　else if ( 命令 == DOWN ) {
　　　　status = getCageStates();
　　　　if ( status != open ) {
　　　　　　電磁ブレーキを解除;
　　　　　　モータを逆転させる;
　　　　}
　　}
}

ようするに、モータを正転、逆転させるという処理に入ってから、ドアが開いていないかどうかをチェックしている。安全のための同じ処理が複数点在してしまっている。

一方、安全確認のソフトウェアはモータ処理とは独立させて監視させたり、モータ制御の関数を呼ぶ前にチェックをし、そのチェックがOKにならなければモータを制御させないという作り方もできる。

問題なのは、ソフトウェアの場合、目的を達成するための方法（プログラムの作り方）はいくつもあり、どのようなプログラミングをしているのかは、外からはよく見えないということだ。

上記のプログラミング構造に、戸開走行の例外処理を追加し、 "SLOWUP" や "SLOWDOWN" などの制御を追加し、付け足し付け足しでシステムを完成させたとしたらどうだろう。

関数の複雑性は増し、テストから漏れるパスが生まれる可能性も出てくる。

試行錯誤でソフトウェアシステムを作り上げる怖さはここにある。外見では同じように動くソフトウェアであっても、潜在的価値の低いソフトウェアはある。ソフトウェアエンジニアがそうしたいと思っていなくても、試行錯誤でソフトウェアを作り上げることで、なかなか到達しにくい部分に爆弾を作り込んでしまうことはあるのだ。

この危険は排除するために、メインCPU（制御プログラム）とは独立した、安全機能の装置を設ける方法はある。しかし、このような独立した安全装置は確実にコストアップにつながるので経済性を優先させようとした場合、取り除いてメインプログラムの中に入れればいいという判断になりやすい。

そうすると、安全機能は外から見えなくなり、キチンと機能しているかどうかわかりにくくなる。

日経ものづくりの記事では、制御装置のプログラムミスの可能性を示唆しているものの、どのようなミスの可能性があったかについては言及していない。国土交通省のエレベータワーキングチームでは、安全装置の独立化と安全制御プログラムに関しては第3者の専門家によって認証・確認する体制を構築することを提言しているらしいが、第3者の専門家による認証・確認というのはたぶん機能しないと思う。

なぜなら、第3者の専門家が安全性に関してお墨付きを与えるということはおそらくできないからだ。安全機能のためのソフトウェアの独立性や完全性は、同じCPUで動いている他のソフトウェアの影響を絶対に受けないという保証ができないだけに、どんなときでもキチンと動くということを証明するのは難しい。スレッド（タスク）を動的に生成しているシステムでメモリリークなどの影響を受けないことを保証することは非常に難しい。

不確定要素がある中で、第3者が安全性を保証することはできない。安全性の検証や妥当性確認は装置を組み上げてユーザーに提供するメーカが行うしかない。完成された部品をシステムに組み込む場合は、それがハードウェアであってもソフトウェアであってもその部品が仕様どおりに動くかどうかを検証することはできても、システムに組み込んだ後の安全性を保証することはできない。

実は、日経ものづくりの記事を読んだ後に感じたのは、「これだけ詳細な内容を記者はよく調べたなあ」という感想と「これだけ詳細な記事の中でソフトウェアについてはほとんど突っ込まれていない」という印象だ。

日経ものづくりは生産や機械設計といった話題が得意分野の雑誌だけに、ソフトウェアにメスを入れろということ自体ムリなのかもしれないが、分かったのはやっぱりソフトウェアは見えにくいということなのだ。探偵のようにエレベータを調べまくった記者もソフトウェアの中身までには切り込むことができない。この見えない世界の中で何が行われているのかは、ソフトウェアエンジニアしか知らない。

だから、ソフトウェアエンジニアが口を閉ざしてしまうと、ソースリストから問題の原因を探るしかない。事故が起こりやすいソフトウェアであればあるほど、構造が複雑であり問題を起こすカラクリを解きほぐすことが難しい。

安全をコントロールするソフトウェアの独立性を高め、その機能や性能の検証が容易になるようにしておかなければいけない。

そして、ソフトウェアモジュールを動かすベースである、オペレーティングシステムの検証は十分に行い、リスクがないことを確認しておく必要がある。

組込みソフトウェアの安全性を高めるための技術はある。それはなんだろうと思った方は『組込みソフトエンジニアを極める』の第4章－品質の壁を越える－を読んでいただければと思う。

以前書いた「シンドラーの事故を再発防止するためにエンジニアは何をすべきか」の記事も参照されたし。

バッテリーは大きなエネルギーを内在している

ソニーエナジー・デバイス製のリチウムイオンバッテリの回収が話題になっている。回収の規模は200億円、バッテリの数は590万個にも上るそうだ。

2006年6月に大阪で開催された Dell laptop explodes at Japanese conference で、会議中に突如 Dell 製のノート・パソコンが発火、炎上したとのこと。

この事故が今回の回収につながった。パソコン関係のリコールというと、「メーカから交換の連絡を待っていればいいかな」という軽い気持ちで受け止めていたが、写真のように発火する可能性があるとなると、対象機種のユーザーなら、さすがに心穏やかにはしていられないだろう。

海外の航空会社では飛行機の中ではノートパソコンはバッテリでの使用を禁じており、バッテリなしのAC電源で使用できない場合はノートパソコンは使えないようにしているところもあるらしい。

なぜ、バッテリが燃えるのかについて、日経エレクトロニクス 2006年9月11日号の「視点焦点」の記事に書いてあった。その内容をもとになぜバッテリが発火するのかについて考えてみたい。

まず、電池がなぜ電気を貯めておけるのかについて考えてみよう。

銅と亜鉛を電解液となる希硫酸や食塩水などに入れると、銅は原子がほとんど溶けず反対に亜鉛は原子が溶け出して電子が出る。そして、銅と亜鉛をつなぐと銅から亜鉛に電気が流れる。これがボルタの電池の基本だ。

要するに正極と負極を二つに分け、この二つの極の間を電荷を付帯したイオンが移動することで電流が流れる。リチウムイオン電池の場合はLi+イオンが正極と負極の間を行き来する。

バッテリが蓄えられる電力が大きければ大きいほど正極に蓄えられるLi+イオンが多いということになる。ノートパソコンが低消費電力になったとはいえ、6時間も8時間も連続で使用できるようになったということは、リチウムイオン電池やニッケル水素電池の蓄電量は非常に大きいということだ。

だから、リチウムイオン電池やニッケル水素電池の正極と負極を電気的な負荷なしに短絡させたりするととんでもないことになる。爆発するかもしれない。

だから、このような大容量のバッテリではショートしたときのための不可逆的なヒューズや発生したガスを逃がすための安全弁が用意されている。

ではこのような安全装置が施されているにもかかわらずバッテリが燃えてしまうのはなぜか。

【バッテリが発火するメカニズム】

1. 電池セルの製造工程で微少な金属粉がセルに混入する。
2. 金属粉が正極部に付着する。
3. 充放電を繰り返す。
4. 正極に付着した金属粉が金属イオンを放出する。
5. 金属イオンが樹枝状に析出し、正極と負極を隔てているセパレータを破り両極を短絡する。
6. 短絡による電流漏洩でセル内部の温度が上昇する。
7. 200℃ほどで正極材料の結晶が崩壊して酸素放出し、さらに熱を発する。（熱暴走）
8. セルの内圧が一気に高まり可燃物である電解液が気化して安全弁から放出され発火に至る。

このような内部短絡にはセル外部に搭載したヒューズや温度管理用のサーミスタは何も意味をなさない。内部が短絡しているから、ヒューズで電流の流れを切っても内部の短絡から電流は流れてしまうのだ。

したがって、製造工程での金属片の混入はもっとも注意を払わなければいけないらしい。金属片の混入の可能性としては、製造ラインを循環する空気の洗浄が不十分であるということも考えられるそうだ。

ただ、金属粉が原因で短絡しても、150℃前後でセパレータが溶解してLiイオンが通過する穴がふさがり、科学反応が止まる仕組みになっているので、金属粉の混入だけが原因ではなく、いくつかの製造工程上のミスが重なったのではないかと予想されている。

リチウムイオン電池やニッケル水素電池は取り扱いに注意しなければいけないということは、ずいぶん前から知っていた。かつてリチウムイオン電池を使った製品のバッテリ充電のソフトウェアの状態遷移について分析したことがあるからだ。

リチウムイオン電池やニッケル水素電池の取扱説明書にはおびただしい数の警告文が書かれている。バッテリを火の中に投入したり、五寸釘で打ち抜いたりしては絶対にいけない。

今回のリチウムイオン電池の事故でよく考えなければいけないのは、大きなエネルギーを持つデバイスはどんなに安全装置を施しても危険が近くにあるということだ。

組込み機器メーカーやデバイスメーカーは危険が表面にでないように幾重にも安全装置を施すので、ユーザー側はそんなリスクをまったく感じることなく機器を日常的に使用している。だからこそ、日常的ではない何かがあったときに危ないのだ。

身の回りにある機器が危ないか危なくないかは人を傷つけるほどのエネルギーを制御するものかどうかで判断できる。

たとえば、車、電車などはもちろんだが、エレベータや自動ドアだって大きなエネルギーを制御する。車や電車がなく、徒歩で目的地まで行ったらどれだけエネルギーを消費するかわかる。エレベータを使わず8階まで階段で上がったら、どれだけの位置エネルギーをエレベータが肩代わりしてくれているのかがわかる。バッテリは一見たいしたエネルギーを持っていそうにもないが、ノートパソコンを連続で8時間動かすエネルギーを一気に放出するような場合は傷害を起こしうる。

逆に言えば、単4電池2本くらいで動いている電子機器は人を傷つけるほどのエネルギーをもともと持っていないので、どんな故障の仕方をしても安全性は高いと言える。

AC電源は大きな電流を取り出すことができるので、AC電源から電流を取り出す電子機器の電源の安全性は非常に高いものが要求されている。

組込みソフトはハードウェアデバイスをコントロールすることができるため、設計の仕方によっては巨大なエネルギーの制御を誤り人を傷つけるような事故を起こしかねない。

組込みソフトエンジニアは、自分が関わっている組込み機器が扱うエネルギーの大きさに注意を払い、取り扱うエネルギーが大きければ大きいほど、慎重にソフトウェアを設計し、ハードウェアデバイスを制御し、検証や妥当性確認を納得がいくまで実施しなければならない。

今回のバッテリ事故は、ソフトウェアが絡んだ事故ではないが、AC電源につながれていない機器でも大きなエネルギー源を抱えていて危険と隣り合わせにあることがわかったと思う。

世の中がネットワークでどんどんつながれていくと、大きなエネルギーを制御するソフトウェアと、たいしたエネルギーも制御しないソフトウェアが通信するようになり、何かの間違いで大きなエネルギーを制御するソフトウェアの中に眠っていたバグを呼び覚まし、大きな事故を起こすような事態が起こるかもしれない。

ユビキタスの時代になると、組込みソフトエンジニアは自分のプロダクトだけでなく、自分のプロダクトが通信によって流す情報にも責任を持つ必要がでてくる。

高密度のバッテリ開発など世の中が便利になればなるほど、そのような利便性とは対照的に組込み機器を取り巻く環境の危険度は増し、逆に安全に対する要求は高くなるのだ。バッテリの事故は対岸の火事ではない。

組込みソフトの安全性

今　、組込みソフトを搭載した組込み機器は世の中にあふれている。携帯電話、FAX、エアコン、TV、リモコン、ミニコンポ、プリンタ、エレベータ、自動車、信号機、自動ドア、電子レジスタ、医療機器、鉄道、飛行機などなど。

そして、組込みソフトが原因となって社会問題に発展するような事故も少なからず起きている。

今回は、組込みソフトの安全性について、『組込みソフトエンジニアを極める』のプロローグの一節から考えてみたい。

【『組込みソフトエンジニアを極める』－プロローグ－より引用】

組込みソフトエンジニアがハードルや壁を乗り越えゴールに到達するまでには、高いモチベーション（動機付け）が必要です。では、組込みソフトエンジニアは試練を乗り越えて技術を高めるためのモチベーションをどこに求めればよいのでしょうか。

ひとつは、常に追いつめられながらギリギリの状態で仕事に取り組まなければならない悪循環から抜けだし、開発効率を高め余裕を持ってクリエイティブな気持ちで仕事に臨めるようになるため、そして、もう一つは魅力的な製品を開発し、ユーザーに信頼を持って快適に使ってもらい次回も自分たちの製品を選んでもらえる自信が持てるようになるため、この２つ理想が試練を乗り越えるためのモチベーションの源泉になります。

組込みソフトウェアは単に組込み機器の中で動くソフトウェアという意味ではありません。組込み機器は、さまざまな形状の外観を持ち、さまざまなユーザーインターフェースで人々の生活の中に入り込み、生活の表舞台に、あるいは、生活を支える裏方として役に立っています。組込みソフトウェアは、その心臓部であり、コントローラです。そして、組込みソフトエンジニアには自分たちが作ったソフトウェアが組込み製品の中で重要な役割を果たしているという喜びと満足感があります。

しかし、その喜びや満足感の後ろには大きな責任もあります。組込み機器が私たちの人間の身近にあって役に立っているということは、一歩間違えば組込み機器は人間を傷づける凶器にもなりかねないということです。特に組込みソフトウェアは中部の構造が見えにくいにも関わらず、設計の自由度が高いため、設計者の意図に反して社会的な問題を起こしてしまうことも残念ながらあります。

私たちは、ものつくりの喜びを感じながらも、自らの技術を磨き、組込み機器を使ってもらうエンドユーザーの満足を満たしつつ、安全で信頼性の高い組込みソフトウェアを世に送り出す義務を背負っています。

組込みソフトエンジニアは、目的を達成するための技術を磨き極めることで、仲間と創造の喜びを分かち合うことができ、便利なだけでなく安心して使える魅力的な組込み機器を世に送り出すことが可能となり、社会と組織への責任を果たすことができるのです。

日本の組込みソフトエンジニアを取り巻く環境を振り返ると、組込みソフトプロジェクトでは、技術者のぎりぎりのがんばりで増加した要求や計画された製品のリリース期限をこなしているという現状があります。場合によっては、プロジェクトに新しい人を投入することで解決しようとする組織もあるでしょう。

しかし、安直な増員はかえって技術者の負担を増加させることになり悪循環からなかなか抜け出すことはできません。組込みソフトエンジニアは技術を磨き極めることでのみ、悪循環を脱し、好循環の世界に突き抜けることができるのです。好循環の世界に入ることができれば、高い品質の組込みソフトウェアを効率よく開発することが可能となり、今リリースしている製品よりももっと顧客満足を高めることのできる商品を作り出すことができます。効率化によってできた余裕でオリジナリティの高いアイディアを考え、新しいキーデバイスの導入をハードウェア技術者と検討することも可能になります。

組込みソフトエンジニアを極める目的は、ものつくりの喜びを分かち合い、生活を豊かにし安心して使える商品を世に送り出し、商品をより競争力の高いものに引き上げ競合他社に打ち勝つことにあるのです。そこに至るまでの道のりは長く、途中にはハードルや壁が横たわっています。私たち組込みソフトエンジニアは、到達すべきゴールから目を離すことなく技術を極めることでハードルと壁を乗り越え、悪循環から好循環への境界を突破できるのです。

【引用終わり】

組込みソフトエンジニアは組込み機器を世に送りだし、自分が作った機器が社会の中で役立っているという喜びや満足感を得ることができる、しかし、その喜びや満足感の後ろには大きな責任もあると書いた。

組込み機器が私たちの人間の身近にあって役に立っているということは、一歩間違えば組込み機器は人間を 傷づける凶器にもなりかねない。

組込みソフトはハードウェアを制御することができるが、ハードウェアが扱うエネルギーの大きさを考慮せずに設計することもできてしまう。

CPUに接続されているポートを ON/OFF するだけで、巨大なクレーンのアームを動かしたり、エレベータを昇降させることができる。

組込み機器に搭載するソフトウェアの規模が小さいときは、組込みソフトエンジニアはプログラムを書きながら組込み機器の動きを想像することができた。しかし、ソフトウェアの規模が10万行を越えて100万行クラスになってくると、今作っているソフトウェアモジュールがシステム全体の中でどのような役割を担っているのか、どのような優先度で動いているのか分からなくなったりすることがある。

特に、システムの一部をオフショアに出したりすると、一部の機能を任されたプログラマ達は、システムがどのようなエネルギーを扱うのか分からないまま、現在ある情報だけでソフトウェアを作ることになる。

規模の大きいソフトウェアの信頼性を高め安全性を高める方法はあるが、唯一の解決策、ゴールドスタンダードはない。

ソフトウェア開発のプロセスを定義し、プロセスのインプットとアウトプットを Verification（検証）し、不整合なないことを確認する。また、設計の努力によって不具合の作り込みを減らし、テストやレビューなどによって、不具合を摘出する。そして、作り上げた組込みソフトウェアと組み込み機器がユーザーニーズに合致しているかどうかを Validation（妥当性確認）する。

また、想定されるリスクを防止、軽減するためにどんな対策をすればよいか考え、その対策を確実に実施したことを確認し、過去に起こした不具合の再発を防止するための対策を追加し、他の機器で起こった問題が自分たちの機器にも起こりえないかどうかを分析する。

不具合の発生件数をトレースしたり、継続的な技術者教育を行うことも大事だ。

いろいろなアクティビティはあるのだが、ひとつ言えることは、自分たちがリリースする機器が社会の中で安全に働いて欲しいという強い思いと、安全な作品をリリースしているという自覚と、裏付けのある自信がなければダメだ。

組込みソフトウェアの規模が小さいときは、製品の開発に関わるソフトウェアエンジニアのすべてが自分の作ったソフトウェアにそのような自覚を持っていた。

しかし、規模の大きくなってしまった現在では、組込み機器を組込みソフトを安全で信頼できるものにしたいという自覚を持った技術者がシステム全体の安全性や信頼性の実現を確認していかなければいけない。

組込みソフトの安全性の確保、妥当性の確認には終わりはないのだが、組込み製品が抱えるリスクの大きさによって、その努力はより慎重により深く実施されなければいけない。

組込みソフトエンジニアのモチベーションの源泉である “自分が作ったものがユーザー個人や社会に役立っているという喜び” が、その思いとは裏腹に人を傷つけ、社会問題を起こさないようにためには、自分たちが作るソフトウェアの安全性や信頼性を高めるための設計技術・検証技術を獲得し実践するしかないのである。

シンドラーの事故を再発防止するためにエンジニアは何をすべきか

シンドラー社のエレベータで痛ましい事故が起きた。この事故との関係は今のところ否定されているが、シンドラー社のエレベータの不自然な挙動の原因の一つがエレベータ制御ソフトウェアの構成管理の失敗であることがわかった。

【毎日新聞2006年6月17日朝刊より引用】

問題があったのは同社が国内で1991年から1993年までに製造したもので、この間、同一の制御プログラムを搭載した49基を出荷したが、扉が開いたまま「かご」が昇降する欠陥が一部で起きていることが1993年に分かった。

欠陥は、扉が閉まった瞬間から0.25秒以内に「開」ボタンを押した場合、扉が開いた状態でかごが昇降を始める。モーターに作動指令の電気信号を誤って伝えるプログラムミスで、1993年中に49基すべてを正常なプログラムへ交換した。

ところが、同社は49基のうち東京都八王子市、豊島区、名古屋市、静岡県沼津市にある計6基で、その後に行った別の修理の際にミスのあるプログラムを誤って再設定。49基とは別に、千葉県浦安市と神奈川県相模原市の計3基は、1993年にプログラムミスのまま誤って出荷した。

【引用終わり】

SESSAMEの中級技術者向けセミナーでソフトウェア構成管理の講義（SESSAME e-Learning Series 構成管理Ⅱに収録）を担当したとき、構成管理に失敗するとどのような事故が起こりうるのか、また、不具合が発生したときに構成管理の情報はどのように使うのかについて解説した。

ソフトウェア構成管理について最近感じるのは「ソフトウェア構成管理ができている」ということと「構成管理ツールを使っている」ことがイコールだととらえられることだ。

構成管理Ⅱの講義スライドを作るときも、『組込みソフトエンジニアを極める』の原稿を書くときも、特に気をつけたのが「その施策はなんのために行っているのか」を説明するということだ。

ソフトウェアシステムは日々の技術者の活動を積み重ねた成果物である。そして、生来、過ちを犯しやすい人間はうっかり大事なファイルを上書きしてしまったり、安易にコピー＆ペーストして一部修正し忘れたりする。

過ちを犯しやすい人間の活動が積み重ねられた成果物であるソフトウェアは、規模が大きくなってくるとどれとどれを組み合わせれば不具合の修正が確認された正しいシステムになるのかよく分からなくなってくる。

また、いろいろなバージョンのソフトウェアが存在すると、今回のシンドラー社のエレベータ制御ソフトのように間違ったバージョンのソフトウェアを製品にインストールしてしまう問題が発生する。（最新のバージョンをリリースしたつもりが、もとの問題があるバージョンにしてしまうことをデグレードという）

不具合の特定と修正および修正の確認がなされたソフトウェアソースのバージョンの関連を管理された状態にし、ユーザーや営業サイドからの不具合の問い合わせにスムーズに回答したり、問題を解決するためのバージョンを速やかにリリースできるようにしておくことがソフトウェア構成管理を行う最大の目的である。

安全な装置を世に送り出すためには、過ちを犯しやすい人間－リスクマネージメント－構成管理　この3つをセットで考えないといけない。

シンドラー社のエレベータの制御ソフトのケースでは、扉が閉まった瞬間から0.25秒以内に「開」ボタンを押した場合、扉が開いた状態でかごが昇降を始め、モーターに作動指令の電気信号を誤って伝えるプログラムミスがあったという。

どんなエレベータでも、各階のドアが閉まっている状態でなければかごは昇降をしないようなプログラム設計をするはずだ。設計者が意図しない状況が発生したということは、扉が閉まった瞬間から0.25秒以内に「開」ボタンを押したという行為が、実際のドアやかごの動作の状態と、制御盤内で認識し管理している状態との間に不整合を発生させたと考えられる。

エレベータの制御だけでなく、何かの動作をしたことである状態からある状態へ遷移する際、わずかな時間がかかることはある。リアルな環境で状態遷移が起こっているこのわずかな期間に、別な操作をしたことによって、コンピュータが認識するシステムの状態とリアルシステムの状態に不整合が起こることはある。このような魔の瞬間に状態遷移の不整合は起こりやすい。

状態遷移の不整合が起こる魔の瞬間をなくすには、コンピュータ内での状態遷移が完了したと判断する際に、実際のシステムの状態を確認するか、もしくは、状態遷移中という状態を作って状態が完全に切り替わってから次の状態に移るようにする。このとき、システムの状態を確認するセンサーが用意されている場合は、センサーの入力を確認することになる。センサーが用意されていないと、コンピュータは暗闇の中で頭の中の地図を頼りに歩いているようなことになり、ひとつ判断を誤ると自分がどこにいるのかわからなくなる。

したがって、安全確認のためのハードウェア（たとえばセンサーなど）をコストダウンのための省いてしまうと、システムとしての安全性は低くなる。『組込みソフトエンジニアを極める』では、システムの安全性に関する商品価値ことをカタログスペックに書かれる顕在的価値（Real Value）に対して、安全性や信頼性を確保し、使いやすさ、安心感を保証するという意味で潜在的価値（Potential Value）と呼んでいる。

顕在的な価値だけを意識し、潜在的な価値のことを考慮せずにコストダウンをしようとすると、結果として事故が起こる確率が高まる。

安全性を高める取り組みとしては、リスク分析を行いリスクをできるだけ小さくするようなハードウェア、ソフトウェアを配置する方法がある。また、故障が発生したときに安全側に倒れるような設計を行うことをフェールセーフ設計を行うという。

エレベータにおける最大のリスクは「各階のドアまたはかごのドアが開いたまま昇降してしまう」ということだ。このリスクが起きる原因を考え、その障害・危害（ハーム）が起こらないような対策を積み重ねることが商品の潜在的価値を高めることにつながる。

リスクをできるだけ低くするためにはFMEA（潜在的故障モード影響解析：Failure　Mode　and　Effects　Analysis）が有効となる。この FMEAを使ったリスク分析については『組込みソフトエンジニアを極める』の第4章－品質の壁を越える－で解説した。

リスク分析を行う際のポイントは2つある。ひとつめは潜在的な価値を高めるために準備したハードウェアやソフトウェアが正しく動かないという一次故障が起こった場合のことを考えておくこと。ふたつめは、せっかく用意した安全装置の検出精度の問題があり危険がないのにアラームを鳴らすという「オオカミ少年」状態が発生し、本当の危険と間違いアラームとの差異がわからなくなるような事態を避けるということだ。

そして、フィールドで問題が発生した際には、二度と同じ不具合が発生しないように、リスク分析とその対策を追加し、対策が実施されたソフトウェアのバージョンを管理し、確実にそのバージョンをリリースするシステムを作り上げることが組込み機器メーカーに求められている。

組込み機器や組込みソフトを作り上げる組織は、商品の顕在的な価値だけでなく、潜在的な価値を高めるには、どのような取り組みをしなければいけないのか常に考えている必要がある。

また、組込みソフトエンジニアは自分たちが作り上げた組込み機器を安心して使ってもらうためには、日々どんな活動をしなければいけないか考えなければならない。