2013-12-14

エンジニアを目指す就活学生よ、自分のページを作りなさい。

12月1日に新卒採用が解禁になった。ニュースを見たりすると、学生が総合就活イベントに押し寄せているシーンが見える。

そこで思うのは「こんなの人と同じことやっていたら絶対ダメだな」ということだ。就職が厳しくなればなるほど、学生は多くのエントリーシートを出す。人気のある企業には大量のエントリーシートが届くから、スクリーニングをかけなければならない。

就活マニュアルをみんな読んでいるから、スクリーニングして振り分けることが難しい。採用側の立場に立てばいろいろなことが見えてくる。

論外なエントリー者は別にして、マニュアル読んできた学生はみんな同じなのだ。面接したってマニュアル通りの回答をするのだろう。個性を強調しろとマニュアルに書いてあれば、個性を強調するマニュアル通りの対応をするから、採用する方は「また、それか」ということになるのだろう。

ドワンゴはスクリーニングのために入社試験料 2525円を取ることにした。三幸製菓はおせんべいへの熱い思いを自由形式で発表する入社試験を始めた。

菊池良さんは世界一即戦力な男をホームページで表現し、採用を勝ち得た。

要するにエントリーシートや就職試験や面接では差が付かないのだ。簡単なことだ。他の学生と自分は何が違っていて、どれだけその組織に役に立つのかをアピールすればよい。

簡単だと言いつつ、日本の学生には最も難しい課題かもしれない。何しろ、みんなと同じようにすること、型にはまったテストで高得点を取ることを何年間も教え込まれてきたのだから、いきなり個性を表現しろとか、他との違いを強調しろと言われても難しいだろう。

【問題解決力・課題突破力をアピールする】

現在、就職活動を行っている学生は自分の個性や組織内での問題解決、課題突破力をアピールする機会がない。

就職活動が画一化してしまった現在では、採用する企業サイドは学生の資質・本質を企業が見抜くことは極めて難しい。企業は学生が未成熟な状態で、終身雇用を行うリスクを負っている。

学生が未成熟な状態で採用するリスクが避けられないのであれば、頼りにしたいのは採用時点での知識量よりも、採用後の問題解決力や障害の突破力であろう。それは、企画部門だけの要求ではなく、開発部門、生産部門においても同じである。組織内では日々解決すべき問題が山積している。それらの問題に対して評論したり、指示を待っている者と、少しずつでも問題を解決して前進できる人材では組織への貢献度及び人材の成長の度合いは雲泥の差である。


「どうせどうせ」子ちゃんと、「評論家」くんは、組織内で役に立たないし、進化のスピードが恐ろしく遅い。一方で問題解決キッズは、最初に知識がなくても着実にゴールにたどり着き、個人としての成長のスピードが速い。

企業は、採用時点で知識がなくても問題解決能力のポテンシャルの高い問題解決キッズとなりうる学生を採用すべきだと思っている。

問題解決キッズか単なる「評論家」くんかを見分けるには、問題を解決できる実力、実績を見ることだ。

それは、エントリーシートや入社試験や面接の時間内で見せるよりも、菊池良さんのように自分自身のページを作ってしまえばよいのだ。

そんなの今の時代お金を使わなくても簡単にできる。そのページをタダで広く宣伝する方法もある。ただ、そのためのマニュアルが欲しいといったら、その時点で負けだ。

自分をアピールするための工夫は自分の力でオリジナルの示し方で実現するからこそ、問題解決・課題解決の実績となる。

理系志望の学生はそんなスキルがあっても会社の中で役に立たないやと思っているかもしれないが、とんでもない。組織内で自分のやりたいことができるようになるには、組織内個人商店の店主として自分の店の商品を宣伝してアピールする能力がなければいけない。

ただ、プログラミングの能力が高ければ出世は後から付いてくると思ったら大間違いだ。特にソフトウェア技術者は成果物が見えにくいから、改善提案や自分の実績を周りの人にアピールする能力が問われる。製造業ならソフトウェアのことが分からないハードウェア出身の上司に説明しなければいけないこともある。

そういうのは苦手だと言っていると、自分がやりたい仕事さえさせてもらえないことだってある。自分は何が出来て、組織にどんな貢献をしたのかを説明できない技術者は、高い技術を持っていても、支援者が増えていかない。結果として自分のやりたいことができなくなっていく。

エンジニアを目指す就活学生よ、自分のページを作って問題解決能力・課題解決能力を示してみなさい。就活だけでなく、就職後にも必ず役に立つから。

※どうやったらいいか考えない人はダメだよ。(Wix なんかもいいかもしれない)

P.S.

ページができたら連絡ください。本ブログで紹介します。

2013-11-24

流星ひとつを読んで


自分の好きな作家 沢木耕太郎(当時31歳)が28歳のときの藤圭子にインタビューしたときの本を、今になって出版したことを聞き、思わず買って今日読んだ。

藤圭子さんへのインタビュー本と言うことだけなら買わなかったと思う。沢木耕太郎氏が書いた本ということでどうしても読みたくなった。

なぜ、1979年、今から34年も前のインタビューが今になって出版されたのかは、本を読んでみると分かる。

この本は沢木耕太郎がインタビューした内容をそのまま本にしようと試みたノンフィクションライターとしての挑戦の成果だ。だから、たぶん何も恣意的な加工をしていない。不正確な事実は修正したかもしれないが、事前に大宅文庫で綿密に情報を仕入れ整理してインタビューに臨んでいるので、インタビュアー側の資料は元々正確だっただろう。

そして、藤圭子の発言は何の加工もなくストレートに語られている。話したくないことは「話したくない」と断り、そのことも書かれている。

この本はよくある回想録のように、隠したいことを隠したり、インタビューの後に名前を匿名にしたりしていない。容易に誰だか特定できる人達のことが生々しく語られている。沢木耕太郎氏は、2013年の出版に際して書き起こした後記に、その当時これを出版していたら、藤圭子が将来芸能界に復帰するときの妨げになると思い、藤圭子本人から出版の許可を得ていたにもかかわらず、出版を断念したと書いている。

そして、藤圭子が亡くなって、宇多田ヒカルと元夫の宇多田照寛氏のコメントが発表され「精神を病み、永年奇矯な行動を繰り返したあげく投身自殺をした女性」という一行では片付けることのできないひとりの女性(沢木氏は「輝くような精神の持ち主」と書いている)の最も美しい瞬間を見られるのは、このインタビュー記事しかないと思った。

そして、28歳のときの藤圭子がどのように考え、どのような決断をしたのか。もしもこの『流星ひとつ』を読むことがあったら、宇多田ヒカルは初めての藤圭子に会うことができるかもしれないと考えた。

藤圭子は、沢木氏とのインタビューの冒頭で「インタビューなんで馬鹿ばかしいだけ」「この人には、自分のことが、もしかしたらわかってもらえるかもしれない、なんて思って真剣にしゃべろうとすると、もう記事のタイトルが決まっていて、ただあたしと会ってたってことだけが必要だったりするんだよね。あたしなんかがどんなことをしゃべっても関係ないんだ、その人には」と言っている。

それに対して、沢木耕太郎は「すぐれたインタヴュアーは、相手され知らなかったことをしゃべってもらうんですよ」「知らなかったこと、というと少し言いすぎになるかな。意識していなかったこと、と言えばいいかもしれない。普通の会話をしていても、弾みで思いもよらなかったことを口にしていることがあるじゃない、よく。でも、しゃべったあとで、そうか、自分はこんなことを考えていたのか、なんてひとりで納得したりする。そういうことなんだ、知らなかったことをしゃべらせるっていうこは、相手がしゃべろうと用意していた答え以外の答えを誘い出す。そういった質問をし、そういった答えを引き出せなければ一流のインタヴュアーとは言えないと思うな」と言った。

そして、その言葉どおり、おそらく藤圭子が自分でも気がつかなかった自分自身を沢木耕太郎のインタビューによって見事に引き出されたと思う。

スティーブ・ジョブズ の評伝も本人へのインタビューを書き起こした本だが、事実のおもしろさではなくインタビュアーが引き出したもののおもしろさでは『流星ひとつ』が一枚上を行っていると思う。

沢木耕太郎の世界の旅『深夜特急』をもう一度読み返したくなった。その旅の最後の時期に、パリのオルリー空港で、沢木耕太郎と藤圭子が出会っており、その出会いにまったく気づいていなかった藤圭子にそのこと語るくだりが、とても運命的でよかった。

1979年当時、インタビューでこれだけのものを引き出しておきながら、この本を出版することを思いとどまった沢木耕太郎と小説新潮の編集担当者に敬服する。当時この本を出版してもおそらく相当の部数が売れただろう。利益のことだけを考えれば、当時、その価値を捨てたことになる。しかし、この本を出版していれば、藤圭子が嫌気していた週刊誌やワイドショーに引き出したエピソードが断片的に取り上げられて、インタビューの内容が一人歩きしただろう。

そういったことを考えて出版を思いとどまったのなら、若干31歳、ノンフィクションライターでジャーナリストとしての沢木耕太郎がすごいと思った。世俗的な編集者ならなんとしても出版してくれと説得しただろうし、凡人ならその説得に結局は応じただろうし、そうしたら、その後のマスコミの動きが沢木耕太郎自身の人生に陰を落としたのではないかと思った。

やぱり沢木耕太郎のインタビュー本だからということでこの本を買ったのは正解だった。

P.S.

藤圭子本人は、引退のきっかけは1974年の声帯のポリープを取る手術をして声質が変わってしまったことだと言っている。「圭子の夢は夜開く」(1970年)と「面影平野」(1977年)で違いが分かるはずなのでYoutube で比較してみたが、何となくという感じではっきりとは分からない。高域での引っかかりがなくなってしまったことで自分の声質の特長が消えてしまったことが相当ショックだったらしい。

何となくわかる気がする。歌の上手い歌手はたくさんいるけど、上手いのと曲を買いたい(昔ならアルバムを買いたいだが、今はダウンロード)と思うのは違う。

何かしらの魅力があるから買うのであって、単純に歌が上手いから買うのではない。最近、テレビでこの人は歌が上手いと思い iTunes Store でサビを聞いて買うのをやめたことが二回あった。「買おう」と決断するには、今ひとつ心が動かなかったのだ。

藤圭子さんは声帯の手術をした後にすぐに変化に気がついたそうだ。冷静に自分の価値がどこにあるのか分かっていたのだなあと思った。

2013-11-16

安全を売りにするな!安全を食いものにするな!

最近、どうしてもペンを取りたいと思わせることが二つ起こった。ひとつは、マツダの安全装備の体感試乗会で起きた「CX-5」の事故で、もうひとつは2007年に起こったトヨタの急加速事故に関するトンデモ検証記事だ。

マツダの安全装備の体感試乗会で起きた「CX-5」の事故

Car Watch NEWS より】
 マツダは11月12日、埼玉県内でマツダオートザム店を展開する坂田自動車工業が開催した安全装備の体感試乗会で、11月10日に発生した人身事故についての第一報を発表した。 
 埼玉県深谷市の坂田自動車工業 駐車場内で発生した今回の事故では、「CX-5」に装備されている「スマート・シティ・ブレーキ・アシスト(SCBS)」の機能を体感するイベントのなかで参加者が運転する車両がフェンスに衝突。車内にいた参加者と販売店従業員の2人が負傷し、参加者が頚椎捻挫(軽傷)、販売店従業員が右腕骨折(重傷)となっている。 
 SCBSは近赤外線レーザーで前方の車両を検知し、ドライバーの操作に応じてブレーキをサポートするシステム。障害物の大きさや種類、周辺環境、車速、ドライバーの運転操作によって正常に作動しない場合があるとしており、マツダではSCBSの体感試乗会を開催するにあたって、上記の項目を考慮し、一定の条件を設定してその条件下で実施するよう全国の販売店に案内している。 
 今回の坂田自動車工業による体感試乗会がマツダの案内する条件に沿って実施されたか否かを確認中で、事故に至った原因や状況などについても含めて警察による調査で明らかになると考えているとのこと。一刻も早い原因究明と再発防止に向け、坂田自動車工業とともに警察の調査に全面的に協力するとしている。なお、SCBSに起因する公道での事故発生についてはこれまで報告がないとの発表だ。 
 また、今回の事故原因が判明して対応が決まるまで、安全装備の体感試乗会は自粛するとしている。
【参照終わり】

なお、この出来事に関するマツダの第一報はこちら。(PDF)

最近はやりの自動ブレーキには種類がある。
  • 赤外線式
  • ミリ波レーダー式
  • カメラ式
マツダ CX-5 に搭載されていたのは赤外線式で、時速 30km以上では作動しない仕様の模様。赤外線式の自動ブレーキはコストが安く、軽自動車に搭載されているのも赤外線式のようだ。最近盛んに自動ブレーキを搭載を強調したCMが流れている。

CX-5 の試乗会で起こった事故の原因は調査中ということだが、自分は単純に 時速 30km 以上で障害物に突っ込んでしまったのだろうと思っている。時速 30km 以上では効かないということを一瞬忘れたディーラーの販売員と血気盛んな運転手がおそるおそるではなくガーンとマットにぶち当たりにいったシーンが目に浮かぶ。

さて、下記のようにどのメーカのCMでも安全機能を売りにさんざん宣伝した後、注意表記が読むまもなく一瞬取って付けたように言い訳がましく一瞬表示され消える。

でも、どのCMもそれぞれの会社のWEBサイトで動画で見られるようになっているので、その部分だけボーズして画面キャプチャすればこのようにじっくり読むことができる。


仮に今回の事故が時速 30km 以上で走っていてブレーキを踏まずに障害物に突っ込んでいって自動ブレーキが効かなかったのなら、それは「i-ACTIVSENSE に搭載されているセンサーは、反射しにくい対象物、天候状況、速度状況、道路状況などの条件によって適切に作動しない場合がありますので、あらゆる状況での事故を回避するものではございません。これらの安全技術だけに頼った運転は行わず、安全運転を心掛けてください。」の注意書きの速度状況によって適切に動作しない場合に当たるのだと思う。

ただ、上記の注意書きの書きぶりだと、速度の条件はセンサーの性能限界のように読み取れるが、自分はそうではなくて明確に時速 30km 以上では自動ブレーキを動作させない制御をしていたのではないかと考える。

もしそうなら、時速29kmでは自動ブレーキは作動し、時速31km なら作動しない。このような Crisp な1か0かの設定が、人間のアナログ的な感覚に合わないということはよくある。

何はともあれ、ここで声を大にしていいたいのは、自動車業界は安全を売りにするなということだ。(【ISO 26262との向き合い方 (16) 安全を売りにすることの意味】参照)

なぜか。それは安全には絶対的な安全というものはなく、相対的な概念だからである。だから、安全機能に絶対大丈夫はない。だから、安全機能の提供者は上記のような Excuse(言い訳)を示す。でも言い訳を書くことでは、残留リスクは許容されないのだ。

マツダのプリクラッシュセーフティ技術の解説(これによると、プリクラッシュセーフティには3種類あって、低速で作動するスマートシティブレーキサポートとAT誤発進制御とスマートブレーキサポートで、CX-5 には中・高速で動作するミリ波レーダー式のスマートブレーキサポートは搭載されていない。そんなのユーザーはわかんないよ。)

セーフティ(安全)の定義
セーフティ(安全)とは,〔ISO/IEC GUIDE 51:1999〕※1 によれば,『受容できないリスクがないこと』と定義される。すなわち,セーフティ(安全)は受け入れ不可能なリスクから解放されていることであり「受容できないリスクがない」または「許容可能リスク」が達成されていることをもって「安全」と規定される。 
安全はリスクを経由して定義され,リスクはその時代,社会の情勢,環境によっても変化するため安全の尺度を一定にすることはできず,絶対的な安全を定義することはできない。そのため,製品,プロセスまたはサービスは相対的に安全であるとしか言えない。 
安全は,リスクを許容可能なレベルまで低減させることで達成される。許容可能なリスクは,使用者の利便性,目的適合性,費用対効果,並びに関連社会の慣習のように諸要因とのバランスで決定される。したがって,許容可能なリスクは常に見直す必要がある。技術及び知識の両面の開発が進み,製品,プロセスまたはサービスの使用と両立して,最小リスクを達成できるような改善が経済的に実現可能になったときは,特に見直しが必要である。 
※1 ISO/IEC Guide 51 は,規格に安全に関する規定を導入する際に参照され,機械,電気,医療,科学など幅広い分野で作成される安全規格に適用されるガイドラインである。
しかし、自動車の販売サイドは安全機能を前面に出すと他社と差別化できると考えるため、安全機能をことさら強調する。これにより、ユーザーは安全は相対的なものではなく、絶対的なものと勘違いしてしまう。※1
※1 小泉元首相が11月12日に日本記者クラブで原発ゼロの記者会見をする前、「自分は首相時代にさんざん原発は安全だと聞かされ信じていたがだまされていた」と言ったそうだ。
安全機能を過信する、または過信させることでこのような事故が起こることは予想していた。(このサイトの右上側のISO 26262 との向き合い方 の特集記事を読んで見て欲しい。)この事故は試乗会だからまだよかったが、実際の道路走行中に自動ブレーキが効かずに事故が起こったら、メーカー側はどのように対処するのか心構えができているのだろうか。

裁判では運転手の過失かどうかが問われると思うが、運転手に過失があっても事故にならないという安全機能を自動車メーカーと販売会社はCMで宣伝しているのだ。一瞬表示する言い訳は利用者との契約とは見なされないから、本当の事故が起これば自動車メーカーが安全機能をことさらアピールしているCMも不利な証拠として採用されると思っている。

最近、自動ブレーキを売りにしている自動車会社は、安全機能を売りにすることの恐ろしさが分かっていない。安全には絶対はないのだから、安全を過信するのようなイメージをユーザに植え付けることは絶対にやってはいけないのだ。(トヨタはやっていないと思う)

それを平気でやってしまうのは、事故と正面から向き合っていないからだ。または、事故と正面から向き合う品質保証部門と、販売が増えればよいと考えキャンペーンを打つ販売部門が分かれていて、会社のトップマネジメントが販売増の方にしか目がいっていないとチェックが効かずに安全を売りにするCMが世に出て行く。

そういう会社は記者会見でユーザやマスコミに頭を下げなければいけない事件が起こったときにはじめて、安全を売りにしたことを後悔し、反省する。

販売部門が計画を達成したいばかりに、売りにつながる要素を宣伝したがる気持ちも分からないではない。

しかし、安全機能は慎ましく、黙ってしっかり実装し、その評価は自ら宣伝するのではなく、お客さんから「あれがあって助かったよ」と言ってもらうものだと思っている。それが侍エンジニアというものだ。

自動車業界も今まではそうしていたじゃないかと思う。アクティブ・セーフティとしての機能、例えばABSを前面に出して宣伝していただろうか、そんなことはなかった。当たり前品質はどういったものかを日本の企業は分かっていた。

プリクラッシュ・セーフティに関しては、誰かが最初に安全を売りにしてしまい、それを横目で見ていた者達が「乗り遅れるな」と一斉にマネをしてしまったのだ。

まじめな話、自動車業界は プリクラッシュ・セーフティ・システムに対するリスク分析を早くやり、コストとのトレードオフについて、企業横断的に議論をした方がよい。

ようするにプリクラッシュ・セーフティという安全機能に対して、コストダウンを優先した結果、センサを赤外線に絞ったことで、どんなリスクが残留するのかを分析し、どういった場合にそのリスクは許容できて、どういったときの許容できないのかを検討するのだ。(議論する内容はコストダウンの要素だけでなく、さまざまな新しく経験したことのない Hazardous Situation があるだろう)

医療機器業界で長年リスク分析を行ってきた者としてアドバイスすると、コストダウンによって性能が低下した場合のリスクコントロール手段は、多くの場合表記上の対策となる。

表記上の対策とは機器のオペレータに対して注意表記をすることで、残留リスクが具現化するのを防ぐ対策の一つだ。機器へのラベリングや画面表示、取扱説明書での注意表記がそれに相当する。

ところが、自動車は取扱説明書は見ないでも使えることが通例になってしまっている。この場合、自動車を使い始めるときに契約書でガチガチの縛りをかけない限り、使用者が当たり前だと考えていること、当たり前だと認識されてもしかたがないことに関しては、自動車メーカーが保証をしなければいけなくなる。

自分は自動ブレーキが時速 30km 以下でないと作動しないという情報をどこかで見ていたような気がするが、あれだけ毎日、自動ブレーキの効果をCMで見せられるとすっかりそのことは忘れて、どんなにスピードを出していても作動するというイメージに自然とすり替わっていた。

そういったイメージを植え付けておいて、自動車を売り渡すときにユーザーに契約書、誓約書も交わしていないのだとしたら、事故が起こったときのことを考えずに突っ走っているとか考えられない。

リスク分析・設計の考え方や方法論についてはこちらを参考にして欲しい。

もういちど言う「安全は売りにするな!」「安全機能は慎ましく、黙ってしっかり実装し、効果はお客さんから評価してもらえ!」

2007年に起こったトヨタの急加速事故に関するトンデモ検証記事

次はトンデモ記事の話題。

何はともあれ、まずは、EE Times Japan の『トヨタの急加速事故は欠陥だらけのファームウェアが原因?――原告側調査の詳細』の記事を読んでみて欲しい。

自分はひさびさに安全を食いものにしているひどい記事を見た。もとの情報提供者の Barr GroupのCTO Michael Barr 氏は、とんでもないひどいヤツだ。開発者やコンサルタントとしての優れた実績を誇る他、大学教授や編集者、ブロガー、著者として活躍した経歴も持つらしいが、この記事はひどいし、安全の実現にこんな経歴は関係ないんだなと思った。そう考える理由はこれだ。
  • 安全を楯に正義面しているが安全を保証したことなどない単なる評論家だ。
  • 安全が絶対的な概念ではなく相対的な概念であることを理解していない。
  • ソフトウェア品質とシステムの安全をごっちゃにしている。
21世紀になっても Fault Avoidance のみを求める愚かさ。
高い性能が要求され、特に安全性が最重要視される場合、設計やコーディング、試験に関する評価・基準は最も重要な課題となる。欠陥が生じることは決して許されず、確実な安全性が求められる。
この記事の冒頭にこう書いてある。一見正しいように見えるが間違っている。ソフトウェアが起因の欠陥は 決定論的故障 (Systematic Failure) と呼ばれる。特にシステムをリリースした後に発見するのは難しいが、一度発見されると100%再現できることが多く、ソフトウェアの改変によってまったく出なくなるという ハードウェアの部品故障とはまったく異なる性質を持つ。

このような Systematic Failure を数百万行クラスのソフトウェアシステムでゼロにすることなど不可能であることは、現場のソフトウェアエンジニアならみな分かっているし、ハードウェアエンジニアでも組織の上位層でもゼロにしたいがなかなかそうできないことが分かっている。

「欠陥が生じることは許されない」という考え方は下記の図の、Fault Avoidance すなわち、個々の構成要素の信頼性を高めることで安全性を確保しようとする設計思想であり、Specific Optimaization すなわち個別最適の発想だ。

フォールト・アボイダンス

個々の構成要素の信頼性を高めることで安全性を確保しようとする設計(構成要素の故障やバグを認めない)

フェール・セーフ

個々の構成要素に故障やバグがあっても必ず安全側に落ち着くようにする設計(信頼性よりも安全性を優先する)

フォールト・トレランス

個々の構成要素の故障やバグがあっても別の手段(冗長性や多重化など)によって機能を維持しようとする設計(構成要素の故障やバグを前提とする)

エラー・プルーフ(フール・プルーフ)
間違った操作をしようとしても危険が発生しないようにする設計。

そしてFault Avoidance だけで、システムの安全を確保しようとする考え方はもう古く、まったく現実的ではない。Fault Avoidance の方法論のとして、Formal Method(形式手法)があるが、それは、巨大なシステムの一部に使えることはあったとしても、数百万行クラスのシステム全体になど使える訳がない。

なぜなら、ソフトウェアの最大の特徴はフレキシビリティであり、曖昧さを許容できるところであり、変更容易性であるからだ。

きっちりきっちり決めた部品を積み上げてシステムを構成できるのなら、ハードウェアの組合せで実現できるはずだ。

ソフトウェアって物語を書くようなものだと思う。一つのストーリーを伝えるのにも複数の書き味がある。分かりにくい文章もあれば、最後にどんでん返しを持ってきたりもできる。ソフトウェアのフレキシビリティは欠点かもしれないが、最大の特長でもあるのだ。

だから、構成部品の信頼性を追求し、それを積み上げていく Fault Avoidance と 個別最適だけの考え方は現代のセーフティ・クリティカルなソフトウェアシステムの安全設計では現実的ではない。

今は、個々の部品に問題があるかもしれないと仮定した上で、フェールセーフ設計やフォールトトレランス設計を考える。そうした上で、信頼性を高める必要性があるソフトウェアアイテムに対して、Fault Avoidance を目指す。(でも、絶対に誤りがないと決めつけてはいけない)

そして、相手が人間だった場合、人間が侵すミスは完全には防げないことから、ユーザーがミスを犯しにくいユーザインタフェースを設計する。

これが Total Optimization (全体最適)の考え方であり、大規模、複雑化したソフトウェアシステムにおいて安全を実現するための方法論だ。
組み込み機器向けのコンサルティングを手掛けるBarr GroupのCTO(最高技術責任者)であり、共同創設者でもあるMichael Barr氏*)は2013年10月、EDNの問い合わせに対し、今回の調査結果を明らかにした。Barr氏は同僚とともに、裁判の原告側の専門家証人として徹底的な調査を実施した結果を明らかにした。これは、セーフティクリティカルシステム開発に携わる全ての人々に対する教訓となるだろう。自動車業界や医療機器業界、航空宇宙業界などのいずれの分野においても、欠陥が生じることは決して許されない。
冗談だろう。教訓にもなにもならない。Fault Avoidance & Specific Optimization の視点で、重箱の隅を突っついているだけだ。

SAFEWARE をまじめに読めばこんな記事にはならないはずだ。
ソフトウェア
 今回の技術調査は、ECMソフトウェアに焦点を絞って行われた。
 まず、ミラーリングが常時実行されていなかったことが明らかになった。ミラーリングでは通常、重要なデータが冗長変数に書き込まれる。スタックオーバーフローが発生する可能性を考えると、非常に重大な問題だといえる。 
 トヨタは、割り当てられたスタック領域のうち41%しか使用していないと主張していたが、Barr氏の調査の結果、実際に使われているのは94%だったことが分かった。さらに、コードの内部において、MISRA-Cに違反する再帰が発見された。これは、スタックにとっては致命的な問題だ。またCPUには、スタックオーバーフローを防ぐためのメモリ保護機能も搭載されていないという。 
 さらに、RTOSのクリティカルな内部データ構造と、スロットル角度関数という2つの重要なアイテムに対して、ミラーリングが不完全だったことが明らかになった。
ここで言っているミラーリングということが、冗長設計(フォールト・トレランス)のことだとすれば、冗長設計がなされていないのは悪だといった口ぶりだが、そんなことはない。

重要なデータが何らかの要因で化けたときのことを考えて、変数を複数持ったり、3つ持って多数決を取るよいという者がいるが、実際にはそんなに簡単ではない。

フォールト・トレランスはシステムを複雑にし、テストパターンを増やしてしまう。仮に複数に格納した変数が一致しなかった場合、どれを正しいと判断するのか。テストすべきパターンは一つではない。よってサンプルテストは通ったとしても、テストパターンがすべて網羅されておらず、漏れがあった場合、非常に分かりにくいバグにつながる。

よって、対象となるリスクによっては、フォールト・トレランスではなく、高信頼性部品を使ったシンプルな設計の方が安全の確度が高まる場合がある。Total Optimization (全体最適)の中では、一部分に Fault Avoidance & Specific Optimization を採用した方がよい場合がある。

皆さんは電波時計をご存じだろう。標準時間の信号に毎日合わせ込みをすることによって、時間を正確に保つ。時間合わせを毎日行うために、水晶発信子の精度は通常の時計よりも悪い。

福島の原子力発電所の事故が起こってしばらくの間、電波時計の掛け時計の時間がずれるなあと感じていた。それは、標準電波を発信する福島のおおたかどや山標準電波送信所(40 KHz) がしばらく停止していたからだ。

電波時計は標準時刻に合わせ込むことで水晶発振子の精度を下げる(フォールト・トレランスの一種)、一般の時計は自動の合わせ込みができないので精度の高い水晶発振子を選別して採用する(フォールト・アボイダンスの一種)という違いがある。

どちらが優れているとは一概にはいえないが、標準電波が発信されてる状況なら電波時計の方が顧客満足度は高いと言えるかもしれない。しかし、標準電波が発信されるという条件は絶対ではないのだ。

安全に絶対はないから、想定したリスクに対して、どんな思想でリスクコントロールをしたのか根拠をもって説明できないといけない。電波時計の場合は、標準電波の発信が条件になる。

よって、この記事は重要なアイテムに対してミラーリングをすることが絶対条件のような書き方をしているが、それはおかしい思った。

さらに、MISRA-C (コーディング規約)への違反を次のように書いている。
Barr氏は、「トヨタのプログラムは、自動車業界で広く採用されている『MISRA-C』への対応が不十分だ。準拠していない箇所が8万個も見つかった。トヨタの内部規格には、MISRA-C規格のうち11個のルールしか適用されていなかった。しかも、ETCSのコードは、そのうち5個に準拠していなかった」と述べている。MISRA-Cとは、欧州の自動車業界団体であるMISRA(Motor Industry Software Reliability Association)が策定したC言語のためのソフトウェア設計標準規格である。1998年に発行されたMISRA-Cの初版「MISRA-C:1998」には、93個の必要要件と34個の勧告要件があるが、トヨタはこのうちの6個にしか準拠していなかったのだ。
 同氏は、「トヨタは、コードのピアレビューが不十分であるか、まったく行っていなかった可能性がある。バグ管理システムも存在しない」と指摘した。
これも現場を知らない者の評論家的発想だ。そもそも、MISRA-C はC言語の表記法の作法の一例だ。その表記法に従ったソースコードで安全が保証されるのかと言えばそうではない。

MISRA-C でのコード表記がシステム安全の条件のような書き方をしているが、それは違う。人間は機械ではない。ソフトウェアを一行一行書いているのは突き詰めれば一人のエンジニアだ。人間はそんなに簡単な生き物ではない。行為は同じでも、動機が間違っていれば効果は現れない。

コーディングルール、コーディングスタイルをそろえましょうという取り組みは、作法がよいと考える書き方をみんなで実践することで、より見やすいコードを書きましょうといったものだ。それなのに、Barr氏はMISRA-C への逸脱を悪だと決めつけ、鬼の首を取ったかのように逸脱を見つけたことを自慢している。

これを見ると、1960年代にエドガー・ダイクストラが構造化プログラミングを発表し、関数は一行80文字以下、50行以下にした方がレビューしやすいという設計の規範が、いつの間にか50行以上の関数を許してはいけないというルールに変質したことを思い出す。

トヨタは大人だから黙っていると思うが、「コードのピアレビューが不十分であるか、まったく行っていなかった可能性がある。バグ管理システムも存在しない」などど言い放って、もしそれが本当でなかったら名誉毀損で訴えられてもおかしくないと思う。(和解で決着が付いた裁判に使われた途中の証拠を使って一方的に評論するのは間違っている。アメリカ人のくせにフェアーでない。)

コーディング規約はプロジェクトの内部で設計の規範をリーダーのリーダーシップの下で実践していった時のソフトウェア品質に効果を及ぼす。業界標準だからという説得力の薄いルールでコーディング規約の縛りをかけても効果はそれほど高くない。(ISO 26262との向き合い方 (22) テンプレートで乗り切る功罪2
NASA(米航空宇宙局)は、Barr Groupよりも前にトヨタ車の調査を行い、ETCSに実装された5つのフェイルセーフモードについて報告している。トヨタのフェイルセーフモードは、3つの「リンプホームモード(非常時の動作モード)」と、RPM(1分間当たりの回転数)制限、エンジンの停止で構成されている。だが、これらのフェイルセーフモードはすべて、同一タスクで処理されている。そのタスクが停止したり、故障したりした場合はどうなるのだろうか?
この部分もしかり。フェイルセーフの機能はどのように分離するかどうかの有効性は、リスクコントロールを行った後の残留リスクの評価によって判断する。

この記事では残留リスクがあるということだけをにおわせておいて、残留リスクが許容できない根拠が書かれていない。あえて読み取るとすれば、NASAが指摘しているから?か。NASAが言っていることはすべて正しいのか、一基何十億円もするシステムのフェールセーフと一台数百万円のシステムのフェールセーフを比べてもいいのか。

人の命はお金には換算できないって。そう、その通り。だから、リスクは何かを想定し、リスクコントロールを実施しても許容できないのなら、そんな商品は売ってはいけないのだ。

安全を確保するということは、多くの場合コストも含めてギリギリのところで、せめぎ合ってリスクヘッジしているのだ。重箱の隅をつつくだけのお気楽な奴らとは、立場が違う。彼らは重箱の隅を突っついて、それが出来ていないと「危ないですよ」とクライアントを煽り立て、それを指導することで儲けるが、仮にその指導の結果、事故が起こっても何の保証もせず、「こっちの方法論もやっていなかったですよ」といけシャーシャーと言う。

機器の製造業者は安全という責任を背負って日々の活動をしている。だから、そういう活動をしているにも関わらず、事故が起こってしまったときのショックは大きいし、自責の念も強い。

だから、正義面して重箱の隅をつついて、白馬の騎士を気取っているヤツを見ると本当にむかつく。
安全システムを扱っている人なら誰でも、何としても単一障害点(SPOF:Single Point of Failure)を回避すべきだと認識しているだろう。だが今回のケースでは、2個のCPUに車両状態情報を供給するA-Dコンバータが、SPOFになっていた。
前述のように、フォールト・トレランスが常にフェール・セーフに有効とは限らない。高信頼性部品を使い、構造をシンプルにすることで全体のリスクを低減することだってある。

最後に、この記事の結論の一つ一つに突っ込みをいれていこう。

結論

 ソフトウェアの欠陥が明らかになった今回の問題から、われわれは何を学べるだろうか。
  • 全てはエンジニアリングの文化から始まる。品質を実現するには、適切な相互評価、文書化されたルールの実施、コード品質のツールや基準の使用などに取り組む文化が必要となる。
安全の実現には文化が必要という主張なら同意する。しかし、安全と品質を混同しているのなら、それは間違い。安全は絶対的な概念ではなく、ルールやツール、基準を絶対的な存在と位置づけたら、そっちの方がよっぽど危険だ。
  • 複雑なシステムでは、ハードウェアやソフトウェアによって引き起こされる可能性のある故障のシナリオを、全てテストするのは不可能だ。欠陥のないコードを作成するには、考えられるあらゆる最善策を施し、使えるツールは全て利用するくらいの心構えで設計しなくてはならない。
前半は同意。しかし、欠陥のないコードを作成するにはあらゆることをしろというのは不同意。使えるツールはすべて利用しろだって。バカを言うな。どんなツールがどんな効果があるのか、ツール自体の Validation(妥当性確認)が必要だといったことが分かって言っているのか。ツールの導入とコストと効果のバランスを考えないで導入できると思っているのか。言ってることが正しくても、それを言う心根がまっすぐではないのがかんに障る。欠陥のないコードを目指すことはよいが、それでも残ることを想定してシステム全体としてリスクが許容できることと目指す。
  • 適切なところにはモデルベース設計を用いる
モデルベース設計は、モデルをコードに変換する部分の人的関与を減らすリスコントロールだ。でもモデル変換の部分を作ったり、変更したりするのは人間だからその部分に不具合が絶対にないとは言えない。モデルベース設計だから安全と考えるのは間違い。
  • 異なるエンジニアリングチームで、徹底的にシステムをテストする必要がある。自分で設計したものを、自らテストするという間違いを犯してはならない(トヨタがどのようにテストを行ったのかは、特に説明されていない)。
欧米の人は必ずそう言い、NASAはV&Vは独立しているべきと言い、IV&V(IはIndependent)が重要という。でも、そのソフトウェアの要求仕様やアーキテクチャを一番よく知っているのは、そのソフトウェアを作成したソフトウェアエンジニアだ。単純に性善説、性悪説ということではなく、ユーザーの使用環境やソフトウェアシステムのアーキテクチャよく考慮した効果的なテストを設計できるのは、そのソフトウェアを設計したソフトウェアエンジニアではないか。そのソフトウェアシステムのことをよく知らないエンジニアリングチームが闇雲にテストして、分かりにくい不具合を見つけ出すことができるとは到底思わない。NASAが IV&V を盛んに言うのも、自分ではソフトウェアは作ってないからではないかといつも疑っている。自分で作っていないから、アーキテクチャを考慮したテストができないので、独立したチームでテストした方が効果が高いといっているのでは?
  • 基本となるハードウェアは、ファームウェアと連携して信頼性を実現する必要がある。例えば、SPOFは回避しなければならない。タスクを完全に分離し、保護するために、ロックステップCPU、EDACメモリ、適切なウォッチドッグ、MMU(メモリ管理ユニット)といった技術で、信頼性を向上しなければならない。さらに、故障モードを決定し、設計の改善に結び付けるために、FMEA(Failure Mode Effect Analysis:故障モード影響解析)を徹底的に実施する必要がある。
信頼性と安全性は異なる。信頼性をいくら高めても安全を保証することはできない。信頼性を追求すれば際限がない。ユーザーに対して、何らかの安全を保証するのなら、製造業者はどこかに線を引かないといけない。その線の要因の中に企業間競争やコスト、リリース期限の要素は必ず含まれる。

それらのさまざまな要因を考えて線を引き商品をリリースし、フィールドで何かあったときに走り回るのが、機器の製造業者の責務だ。

そんなに苦しいのなら、やめればいいのにと思うかもしれない。しかし、その苦しい責務以上に、製品を通した社会への貢献を感じ、ユーザーから感謝の気持ちを受け取る喜びを感じることができる。だからこの仕事を続けている。

6月7月に行った SESSAME のソフトウェア安全分析・設計セミナで、自動車業界の方達と接し、自動車のサプライヤとOEMの関係を少し実感したので、そんな単純ではないなということが分かったが、もう少し安全と信頼の違い、リスク分析とリスクコントロールの設計について、業界全体として理解を深めて欲しいと思った。

今回のブログのタイトルをもう一度叫んで終わりにしようと思う。

「安全を売り物にするな!安全を食いものにするな!」


P.S.

ソフトウェア安全分析・設計セミナ Part 1 の最後で紹介している、放射線治療器 Therac-25 の事故分析の結果、ナンシー・レブソン教授が出した結論をここに紹介する。なんだ、上記の結論を似ているじゃないかと思うかもしれないが、それは違う、上記は裁判で勝訴することを目的とした論証の結論であり、下記は事故に向き合い事故の再発防止を目的とした教訓だと思っている。実際に、FDAは Therac-25 の事故の後、この研究結果を医療機器ソフトウェアのガイダンスに盛り込んで、実践させ、それによって事故が減ってきているかどうかをウォッチし続けている。前者の結論は責任のない評論家の結論。後者の結論は、どうしたら事故を再発させないか真剣に考えた研究者の結論だと思っている。

ナンシー・レブソンが解く 事故の原因因子

ソフトウェアへの過信
・ソフトウェアは故障しないし、故障できないという意識があった。

信頼性と安全性の混同
・Therac-25 は過剰照射が起きるまで何万時間も可動しており、誤動作はしなかった。
・信頼性が高かったためにAECLは自分達のソフトウェアは安全であると思い込んでいた。

防御的設計の欠如
・技術者は最悪の場合に備えて、内部で何が起こっているのかを調査しうる仕組みを組み込むべき。

根本原因の排除の失敗
・ソフトウェアの不具合が分かりにくいからといって、根本原因を追及せずに見込みで判断してはいけない。
・ソフトウェアに欠陥が見つかるたびに個々にそれらを解決しても機器の安全性の問題を解決することにはならなかった。

自己満足
・過去10年、20年、医療用加速器の使用において重大が放射線事故がなかったことで安全であると思い込んでしまった。

非現実的なリスクアセスメント
・確率論的リスクアセスメントが機器への過信を生み、リスクアセスメントの結果自体を過度に信頼することになった。(ソフトウェアの特性を排除していた。Systematic Failure) 

不十分な原因調査、あるいは事故報告書の不十分な追跡調査
・セーフティクリティカルなシステムを構築しているすべての企業は、監査証跡と、事故を招くかもしれない問題の兆しが見つかった時に適用されるインシデント分析手順を備えるべきである。

ソフトウェアの再利用
・レガシーソフトウェアや COTS(商用ソフトウェア)の使用が安全性を増加させるだろうと単純に思い込んでいた。
・ソフトウェアモジュールの再利用は移行した新たなシステムにおける安全性を保証するものではない。

安全なユーザインタフェース対使いやすいユーザインタフェース
・機器をできるだけ使いやすくすることは安全目標と相容れないこともあり得る。(Usability)

ユーザー及び政府の監督と規格
・Therac-25の事故があってから、FDAは報告システムの改善を始め、ソフトウェアを含めるように手順や指針を拡大し始めた。
・ユーザーからの情報や働きかけも機器の問題を解決するには重要だった。


ソフトウェアエンジニアリングの不十分な実施

原文 
訳文 
Software specifications and documentation should not be an afterthought.  ソフトウェア仕様と文書類は後知恵の産物となるべきではない。(最後に揃っていればいいやはダメ)
Rigorous software quality assurance practices and standards should be established. ソフトウェア品質保証に関する厳正な実施とその基準が確立されるべきである。
Designs should be kept simple and dangerous coding practices avoided. 設計は単純にしておくべきであり、危険なコーディングを行うことは避けるべきである。
Ways to detect errors and get information about them, such as software audit trails, should be designed into the software from the beginning. ソフトウェア監査証跡のように、エラーを検出し、そのエラーに関する情報を取得する方法を、最初からソフトウェアに組み込んで設計するべきである。
The software should be subjected to extensive testing and formal analysis at the module and software level; system testing alone is not adequate. Regression testing should be performed on all software changes. ソフトウェアは、詳細なテストとモジュールレベルやソフトウェアレベルでの形式的分析を受けるべきである。システムテストだけでは不十分である。ソフトウェアのあらゆる変更に対して回帰テストを行うべきである。
Computer displays and the presentation of information to the operators, such as error messages, along with user manuals and other documentation need to be carefully designed. エラーメッセージなど、コンピュータディスプレイとオペレータへの情報の提示は、ユーザーマニュアルや他の文書とともに設計に十分な配慮が必要である。

    ナンシー・レブソンの言葉
    • どんなに慎重に作ってもソフトウェアは満足できるほどに完璧にはならないため、ソフトウェアがどんな動きをしたときでも、人命に危険が及ばないようにシステムを設計する必要がある。ソフトウェアの信頼性をできるだけ高めるのは悪いことではないが、それでソフトウェアが安全になるわけではない。プログラマは要求を満たすようにコードを書くが、要求が正しいとは限らない。事故のほとんどは、プログラミングのエラーではなく、要求が間違っていたり、不完全であったりしたために起きている
    • われわれの目標は、だれもがこの経験を生かせるようにすることであり、装置のメーカーや他の人を批判することではない。間違いは、このメーカーにだけ起きたのではなく、残念ながら、安全が最優先されるべきその他のシステムにも、きわめて日常的に起きている。
    • いくつかの出来事が複雑に絡み合って起きた事故が、一つの原因にされることが多すぎる。ほとんどの事故は、システム事故、つまり、さまざまな構成部分や機能が複雑に作用しあって起きるものだ。事故の原因を一つに特定することは、大きな間違いだ。

    2013-11-10

    ISSRE 2013 旅日記(Pasadena でプレゼンするまでの道のり)

    9月、10月、11月(今日まで)とブログの投稿を休んでいたのには理由がある。それは 11月7日 の US の Pasadena(カリフォルニア州)で行われた IEEE のシンポジウム ISSRE (International Symposium on Software Reliability Engineering) 2013 のワークショップ MedSRDR に採用された論文について英語でプレゼンする準備をしていたからだ。

    背景は 2011年に広島で開催された ISSRE 2011 に 3名(慶応の白坂先生と電通大の西先生と私)の医療機器をテーマにした論文(Feature Analysis of Estimated Causes of Failures in Medical Device Software and Proposal of Effective Measures) が Industrial Paper で採用されたこともあり、今回、 ISSRE ではじめて医療機器の信頼性やリスクマネジメントについて議論するワークショップ(The 1st Workshop on Software Reliability/Dependability/Risk Management in Medical Devices)が開催されるということで、これに同じ3名で議論していたネタを投稿したのだ。

    自分はこの手の国際シンポジウムへの論文投稿というものがどれくらい難しいのかよく知らないのだが、出せば必ず通るといったようなものではないらしく、採用されたら「パチパチ」ものらしい。

    ISSRE 2011のときは、1枚のアブストラクトと発表用のスライドだったが、今回はアブストラクトと、6ページの論文と、約20ページのスライドを作成した。

    テーマがもろに医療機器とリスクマネジメントだっただけに、原稿草案は自分の分担だった。TOIEC 600点いかないくらいの実力で、これだけの英文原稿を書き、かつ、30分の英語のプレゼンをしなければいけない(ISSRE 2011 では白坂先生がプレゼンをした)ことのプレッシャーはとてつもなく大きい。

    アブストラクトの提出期限が 8月末 で、採用の可否が9月中旬で、ワークショップが11月初旬という日程だった。

    そして、9/17 に運命のメールが来る。(論文タイトルは後に少し変更)
    Dear Author(s),
    We are pleased to inform you that your submission titled “An improved FTA with safety class principle for assessment of risk for software-intensive medical devices” has been accepted to present in MedSRDR 2013.
    Please prepare your presentation  by addressing attached reviewers’ comments. The maximum 20 pages presentation should be submitted by 9/27/2013.
    We are looking forward to hearing your presentation at the conference. If you are
    not the author presenting your paper, please forward this message to your co-
    author who is doing the presentation.
    Sincerely,
    MedSRDR 2013 Program Committee
    1ページのアブストラクトを書くときも必死だったが、上記のメールが来たときはうれしかった反面、9/27 までに10日間で論文を提出しないといけないというプレッシャーがキツかった。

    今回はワークショップなので、20ページのスライド作成でもよかったのだが、どうしても IEEE の論文形式で提出しかたった(その方が断然かっこいい)ので、頑張って論文形式で書こうと思っていた。この場合、MAX 6ページの論文をまず提出し、シンポジウム当日までにプレゼン用のスライドを作ることになる。

    アブストラクトと発表用のスライドの英文は、Skype で英会話を学習している Rarejob の Tuter 達にチェックしてもらった。これは本当に助かった。

    しかし、6ページの論文の方は、提出まで10日しかなかったため、インターネット辞書と格闘しながらほとんど自力で書いた。今、改めて読み返してみると英語として修正した方がよいと思われる文言が何箇所かあったと思うけどもう遅い。

    9/27 までに 6ページの論文を提出してから、また試練がまっていた。前回、3人の日程の関係で、11/7 のワークショップのプレゼンに行けるのは自分しかいなかったのだ。

    毎週末の Skype での英会話レッスンでも毎回どきどきしているのに、英語でプレゼンして質問を受けるなど考えただけでもクラクラしそうだった。

    結果的にはなんとか乗りきったのだが、そこに至るまでの苦労と精神的なプレッシャーは正直大変だった。良い経験ではあった。でも、この期間のことについてはあまり思い出したくない気分だ。

    こんな数ヶ月間を過ごしていたので、ブログを更新するどころの話ではかった。毎週末、英語と格闘だった。(9月、10月と3連休があったことは助かった)

    ということで、前置きが長かったが、今回のブログは旅日記としてみた。

    11月6日(水)

    行き帰りの飛行機は評判がよいと聞いていたシンガポール航空にした。出発は日本時間の18:50。飛行時間は約10時間で、到着するとロサンゼルスは 11/6 の11:50 となる。(時差-17時間)

    今回のシンポジウムの会場は ロサンゼルスのダウンタウンの北側に位置するパサデナ(Pasadena)という都市で、アメリカンフットボールの大学リーグのローズボウルの開催地で高級住宅街とのこと。治安はいいらしい。

    空港はロサンゼルス空港(LAX)で、一番心配だったのが、空港からシンポジウム開催場所のWestin ホテルまでの移動手段だ。日本のように鉄道が主流ではないようで、バスかタクシーかと言ったところだが、タクシーは悪い噂を聞くことがある。

    そこで、いろいろとインターネットで調べてみたら、乗り合いのシャトルバス(要するにバンに乗客が同乗する)があることが判明。早速、インターネットで行きも帰りも予約した。運転手へのチップはWEBサイト上で0か15%か20%を選択できるようになっている。こういうのが慣れない。

    予約した SuperShuttle のバン。実際こんな車だった。

    片道$34で安いんだか高いんだかよく分からないが、ちゃんと飛行機の時間とリンクして予約できたので安心した。

    飛行機も今やインターネットで予約する時代。すでに予約してあった番号でインターネットで調べてみると、座席の変更や食事の指定ができる。食事はダイエット食や宗教上の指定などかなりの選択肢がある。後で分かったのだが、ちょっとした変更をしてもよい人はここで食事を指定しておくと、食事のサービスのときに真っ先に配ってくれるのでよい。

    今回はエアバスA380 で座席は3+4+3 なので、4の端の通路側G列を指定。帰り便は最初の予約時は窓際しか取れなかったが、インターネットで変更ができ帰りの便もG列が取れた。結果的にこれはよかった。D列とG列は通路側でも席を立ってあげるのは一人で済むが、C列とH列は対象が二人になる。11時間も飛行機に乗っていることを考えるとD列とG列がよいことが分かった。

    出発当日は、新宿から成田エクスプレスで空港まで移動。成田エクスプレスのホームは新宿駅の一番端の方にあって、意外にたどり着くのに時間がかかる。

    成田空港に来たのは2006年以来。今回、6日に出て9日に帰ってくるので、トータル4日間。飛行機の中に22時間いて、泊まりは2日。機内に持ち込めるギリギリの大きさのスーツケースとショルダーバック一つで何とか荷物を積み込めた。

    搭乗まで1時間以上あったので、シャワールームを使ってみる。30分で1000円。これから拘束が長いということで一応さっぱりはしたが、ちょっと狭い。もう少し、広いといい。

    小型のスーツケースをごろごろと転がして搭乗口まで行くと、若者の集団30人以上がどうも同じ便に乗り合わせるようだ。話しぶりからするとどこかの専門学校の生徒達のようだ。ロサンゼルスまで何しに行くのだろう。

    搭乗してみるとラッキーなことに隣のF列の席が空席だった。

    シンガポール航空だけにドリンクサービスでシンガポールスリングを注文できる。かなり甘いカクテルだけどもほろ酔いにはちょうどいい。

    11時間は本当に長いけれど、エンターテインメントのコンピュータシステムの進化にはだいぶ助けられた。

    なにしろ映画は30本以上エントリされている。かなり新しい映画もあって、行き帰りで5本くらいは見た。ウルヴァリン samurai は日本が舞台なのに設定がめちゃくちゃだとは聞いていたが、本当にめちゃくちゃだった。

    剣道の試合でバック転したりするし、軍隊の兵士が切腹したりする。よって半分うとうとしながら見る。これは映画館で見なくてよかった。

    その後、映画館で二回も見たパシフィック・リムをもう一回見る。やっぱりロボットの動きがかっこいい。

    iPhone は機内では使えないものの、座席にUSBの口が付いていて充電はできる。ホテルのベッドサイドにも充電用のUSBの口があった。最近のニーズに合っている。

    今回の旅で一番持って行ってよかったと思ったのはスリッパ。相当昔にキャセイパシフィック航空の飛行機に乗ったときは、スリッパが配られていたが、今はないだろうと思い、かかとのあるスリッパを東急ハンズで購入し持参。これはよかった。飛行機の中はもちろんのころ、ホテルの中でもずっと履いていた。

    旅行用の折りたたみ式のスリッパでなくぺたんと平たくなるかかと付きのスリッパ。これはちょっとかさばるが持っていって正解。

    長い空の旅が終わるとそこはロサンゼルス国際航空、先週、空港のTSA職員が男に射殺されたばかり。先週はこの事件のために、飛行機の発着がかなり乱れたらしい。

    とりあえず何事もなく、SuperShuttle の乗り合いバンの停留所で予約番号を告げる。係の人は専用の端末を持っていて、予約番号を入力すると何もかも分かったようで、ここで待つように言われる。

    待っている間も、いろいろな行き先のバンが来ては客を乗せて去って行った。その場で代金を払っている人もいた。

    しばらく待っていると Pasadena 行きのバンが来たので、相乗りで出発。飛行機もバンも冷房を効かせすぎ。LAは今の時期、昼間は25度を超えるのだが、それでも建物や乗り物の中が寒い。

    飛行機の中は毛布が配られるが、それでも寒かった。ウルトラライトダウンのベストを持って行ったのは正解だったが、ジャケットでもよかったくらいだ。

    バンに乗ってだいたい30~40分くらいでホテルに到着。高速道路は片側4車線。でも道はがたがたしており、スピードは時速80キロくらいだった。それ以上出すと車がバウンドしそうな感じ。

    The Westin Pasadena はたぶん高級ホテルなのだろう。今回のシンポジウムはこのホテルの2階を一週間貸し切りで行われた。シンポジウムの特別価格で泊まれたようで、一泊約150ドルだった。普通にインターネットで調べると一泊230ドルと出る。ホテルの価格はいい加減だ。

    ホテルに着いたのが14:00くらいだったので、15:30 からのセッションを聞くことができる。明日のプレゼン発表会場と同じ会場のセッションを聞くことにする。

    ロサンゼルスの 15:00 は日本の 8:00。飛行機の中で熟睡できていないし、時差があるので本当に辛い。でも、会場は見ておきたいので、なんとか15:30~17:00 のセッションを眠気を我慢して聞いてみる。

    会場は小さい会議室。エプソンのプロジェクターが置いてあって、椅子はせいぜい30個くらいならんでいる程度。「こんな小さい部屋なんだ」と思う反面、これくらいの大きさの部屋ならまあ緊張しないで済むと思う。

    Session 72: Test Generation and Coverage という自分自身にはあまり興味がないセッションを聴講。やっぱり、聞いていて詳細が分からない。質疑応答の様子を聞いて「ゾッと」する。そんなの答えられないよ。何言っているのか正確に分からない。

    スケジュール表を見ると、18:00 より Banquest & Awards Ceremony とある。どうもこのシンポジウムは昼食や夕食が出る日があるらしい。(昼食は期間中用意されていたようだ)

    だから、何しろ参加費が高い。今回は発表者でも約900ドルを払った。IEEEの会員だと少し割り引かれるが、こんなに高いと会社に出してもらうとしても参加は難しい。一週間参加している人達は、宿泊費や移動の費用もあるのだから、相当な出費だろう。

    限られた人達がだけが参加できる場なのだろうか。そう考えると日本で開かれる費用の安いシンポジウムはとても良心的だと思う。

    さて、18:00 のBanquest に顔を出してみるとドリンクチケットが配られていて、料理が用意されていた。まったく知り合いがいないので、日本人と思わしき人達に声をかけて聞いてみると、みなResearcher(研究者)のようだ。

    ドリンクチケットでワインをもらうものの、話をできる人がいない。みんな談笑しているときに孤独を感じる。眠いしワインも酔いあって、早々と退散して、部屋に戻る。

    よく見えないかもしれないが、ホテルの部屋から見える am/pm 。アメリカのコンビニはガソリンスタンドに併設されてることが多いらしく、この店もそう。

    この am/pm にはお世話になった。水もここならホテルの売店の1/2 で買える。

    ただ、USのコンビニは日本のように品数豊富とは言えない。日本のコンビニは本当にすごい。何でもある。

    日本のコンピニにはないもの、それはホットドッグのコーナーでパンを買っていろいろトッピングしてお金を払うシステムのようだった。

    ワインで頭がクラクラしながら、明日のプレゼンの練習を一回だけする。

    もう日本で何十回と練習してきたから、かなり覚えているが、まだ不安は残る。飛行機の中で練習しようと思っていたが、結局一回もしなかった。

    時差のこともあり、熱いシャワーを浴びて寝ることにする。環境の変化に弱いので熟睡はできない。何時間か寝ては起きるの繰り返し。ちなみに、テレビはスポーツを見ているときが一番落ち着く。なぜなら喋っていることを理解しようとしなくても、流れが分かるから。

    メジャーリーグのワールドシリーズが終わってしまっていたのが残念だった。このときやっていれば、盛り上がれたのに。

    11月7日(木)

    発表当日。自分の出番は午前中 11:00~12:30 のセッションの3番目。9:00 からの全員参加のミーティングはとりあえずパス。これに出ていれば、もしかしたら集合写真に写っていたかもしれない。

    まあ、いいや。

    いろいろ訳あって、日本から持って行ったカップラーメンをこれも日本から持って行った湯沸かし器でお湯を沸かして食べる。

    箸を忘れたが、マドラーが日本あってこれが箸代わり。

    スターバックスのコーヒーメーカーはあったが、湯沸かし器はさすがになかった。

    先日、大阪の出張したときは、ビジネスホテルに湯沸かしポットがあったので、日本のホテルは細かいところに気が回っていると思った。

    ちなみに、Westin でもひげそりも、歯ブラシもなかった。これも持って行ってよかった。なお、Westin には Make  a Green Choice というのがあって、その札を部屋の外にぶら下げておけば、タオルの交換などをしないというシステムだ。

    タオルやその他の備品はたっぷり用意してあって、2泊くらいなら、補充してもらわなくても問題ない。部屋も散らかし放題だったので、このシステムはありがたかった。

    本番前に一度だけ通しで練習しておく。

    30分前に 会場に行くと Yuan Wei さんがプロジェクタと会議システムの準備をしていた。この人は、MedSRDRのプログラム委員でもあり、何回かメールでやりとりした中国系のソフトウェアエンジニアの人だ。

    Wei さんの会社では植え込み式の除細動器を作っているそうで、そちらは何を作っているのか聞かれた。どうも午前中の最初のセッションの発表者がこちらに来られなかったそうで、インターネットの会議システムを使ってプレゼンをするらしい。

    Wei さんのPCがプロジェクタへの出力がグレー表示になってしまい。困っていた。結局2番目の発表者は、PCを持ってきておらず、自分のPCにUSBからファイルを移して、貸してあげることになった。

    そして、本番、自分の番。結局多くの台詞をスライドに埋め込んで、Power Point のアニメーションを駆使したこともあって、約25分のプレゼンテーションはつつがなく終了。

    会社でリハーサルを企画してくれて、アメリカ人の社員に批評してもらったこともあり、プレゼン自体はたぶん普通に聞いてもらえたと思う。喋ることを全部暗記することができず、スライドの言葉を読むようになってしまったのはプレゼンテーションとしては残念だったが、スライドだけを後から見てもらう意味ではよかったかもしれない。

    日本語のプレゼンテーションならこんなに練習することはなかっただろう。英語だから何十回と練習した。オリンピックの最終プレゼンの佐藤さんのプレゼンも見た。刺激になった。

    佐藤さんのプレゼンは何十万人も見たと思うが、こちらは約15人だった。でもまあ、いいや。異国の地で英語のプレゼンできたのだから。

    質問は、「どうやったら効果が確認できるのか」とか「ISO 26262 の ASIL を参考にしたと言うが、クラスが下げられたのはどうして分かるのか」といった内容だったと思うが、キチンと言っていることが伝わらなかったかもしれない。だって、質問に対する答えは練習できなかったから。

    その分、コーディネータの Wei さんがフォローしてくれて、参加者の人達でひとしきり議論が展開されていた。その中に入れなかったのが残念。

    終わった後、日本語で話しかけてく手くれたアメリカ人の方がいて、なぜか必至で英語で答えようとしていた。何はともあれ、終わって良かった。

    部屋に戻ると、いろいろな人に報告のメールを書き、しばし休む。

    午後のセッションに参加する気力がなく、眠気と戦いながら、商業地区の Old Pasadena に徒歩で行ってみる。

    City ホールとメトロ(地上にあるのにメトロ)の駅。ホテルの中は震えるほと冷房が効いているのだが、外に出ると昼間は暑い。たぶん28度くらいはあって、日向では日差しが痛いくらい。

    1時間ほど歩いてはみるものの、ちょっとしたお土産が買えるのようところではないことが分かる。別に観光地ではないので、当たり前と言えば当たり前。

    レストランはたくさんあった。ただ、この日はシンポジウムでランチボックスを配っていたので、それを get して食べてしまった。

    量が多いので、半分残して夕飯もそれで済ませてしまったくらいだ。

    とぼとぼと帰ってきて、結局、夜までTVを見ていた。
    じっくり観察していたのは日本とのコマーシャルの違いだ。

    アメリカのコマーシャルは個別の食べ物のCMがほとんど流れない。マクドナルドとケンタッキーのCMは何度かみたが、日本のようにひとつひとつの食品のCMではない。

    目立つのは医療保険のCMかもしれない。日本で流れるようながん保険ではなく、民間の健康保険のCMが結構な頻度で流れる。こういうのにすでに入っている人達がオバマケアの政策に反対するのだと思った。

    ようするに国民皆保険ではないから、資産の余裕のある人がより優遇された民間保険に入るのだ。逆に所得の低い人で健康保険に入れない人がいる。これらの人達を救うためにオバマケアの政策が進められている。日本にいるときは、反対する理由がよく分からなかったが、CMを見ていると、なんとなく反対する人達の言い分が見えてくる。

    The Westin Pasadena の玄関前


    11月8日(金)

    帰国する日。飛行機は 14:15 発だが、迎えのシャトルバスは 10:00 ~ 10:15 までに来るという。3時間は見た方がよいとインターネットにも出ていたので、逆算するとそれくらい前に出発しないといけないのだろう。

    たまたま、同じバンに日本人の方達と乗り合わせ、話をしたら、自分のプレゼンを聞いてくれた人だと分かる。昨日のうちに知り合いになっていればよかった。

    2人のうち、一人は同じシンガポール航空の SQ11便だった。

    ロサンゼルス国際空港
    ロサンゼルス空港に着くと、噂に聞くセキュリティチェックがあった。上着も脱いで靴も脱いでスキャンもしたが、そんなには時間はかからなかった。

    なのでたっぷり2時間も時間が空く。残念ながら気の利いたお土産も豊富にあるわけでもない。ディズニーランドに行くときに降りる空港だから、ディズニーのお土産もたくさんあるのかと思ったら、まったくそんなこともない。

    有るのは、免税の酒や高級ブランドショップばかり。そして、帰りも専門学校の生徒をおぼわしき集団と一緒になる。ディズニーランドに行ってきたのかそういう袋を持っている。

    空港は広いが成田や羽田のようにそこにいて楽しいという要素には欠けているような気がする。本当に空港の機能だけしかないという感じ。

    帰りの11時間。長かった。

    成田に着くと、日本時間では午後7時。ここから家に着くまでまた3時間。

    たった、30分のプレゼンテーションのために、ここまで苦労するものかとも思ったが、そこに至るまでの過程や努力が大事だったのだろう。

    この経験は決して無駄にしてなならず、今後に活かしていかなれけばいけない。また、Researcher も大変だなと思った。現場を分かっていないとか、実際に役にたつ研究をしろといった批判をするのではなく、彼らと協調して何ができるのかを考え、実行することが重要だとも感じた。

    結局、世の中に何をを主張するとき、論文という形式を通して伝える必要がある。本を書くのも方法の一つだが、論文も手段の一つだ。

    手段が目的になるのはよくないと思うが、あるルールにしたがって世に知らしめることで技術を前進させることが可能なのも事実だ。

    ちなみに、ソフトウェア系の論文が力を持つのは、中身のよさだけではないと思う。医学の論文では効果があればとたんに有名になるが、ソフトウェア系の論文は使われなければ効果も広まらないので、世論を形成する必要がある。

    そのためには、人脈も必要なのだと思った。ロサンゼルスから日本に戻った学生さん達は何か得るものがあったかなあ。

    日本の環境でできることももっとあるように思うし、何よりもコミュニケーションが容易にできるのはよい。海外でもそう言えるようになるにはもっと努力しなくては。

    Workshop のサマリ: MedSRDR Session 87の No.3

    ISSRE 2011の論文(Slide Share)
    ISSRE 2013 MedSRDR で発表したスライド(Slide Share)


    2013-10-06

    最近考えていること

    ここ数ヶ月間、ブログへの投稿が減っている。9月は一件も投稿できなかった。理由は忙しさよりも環境の変化によるところが大きい。

    2003年にSESSAMEで活動をするようになってから、本職の仕事とプライベートな立場でのコミュニティの活動を切り替えながらこなしてきた。

    本職の仕事でモチベーションが下がったときは、コミュニティの活動に打ち込み、コミュニティで得た知識や人脈を本職の仕事に活かしたりして、両輪がうまく回っていた。

    ブログは本職のノウハウに関係することはストレートに書けないので、一般化して書いたり、自分の業務ドメインとは違う自動車ドメインのことを書いたりしている。

    そうこうしているうちに、最近になって工業会の仕事をするようになり、組織内での活動と組織外での活動の区別が付きにくくなってきた。

    工業会の仕事というのは、自組織のためだけの活動ではなく、業界全体の利益、社会貢献のための活動であり、これまでやってきたコミュニティの活動とよく似ている。

    したがって、スイッチのオンとオフの切れ目がはっきりしなくなってきたのだ。工業会の仕事をしていると、なんだか以前やっていたコミュニティの活動をしているような感覚になる。

    だから、気持ちを切り替えるタイミングがはっきりしなくなり、工業会の活動を通じて社会貢献できているからいいかと思ってしまう。

    ブログの目的は自分の中の頭の整理と、日本の組込みソフトウェアエンジニアのためにできることが有ればと思って書いているのだが「日本の・・・」って言っていていいのだろうかという気にもなってきた。

    ここ数年で国際規格が出来上がってくる過程もわかり、自分もそれらの規格の検討に関わるようになると、問題は日本の中だけに留まっていないことも分かってきた。

    もしかして、自分ができることは日本の中だけに閉じていないかもしれないという想いもある。

    そんなこんなで、今は自分自身を充電している時期なので、どうか気長に新しい記事の投稿をお待ちいただきたい。

    2013-08-31

    2013年8月の読者の関心事

    下記の表はこのブログサイトの8月のアクセスページを滞在時間で1位から50位まで並べ替えたものだ。

    不思議なことに8月は忙しくて一回もブログを書かなかったにも関わらず、お盆休みを除き、ウィークデーは毎日200件くらいのアクセスがある。そして新規読者が半数を超えている。

    そして、下記の通り、時間をかけて読まれているは特集記事「ISO 26262との向き合い方」だ。

    自分が興味をなくしたテーマにも関わらず世の中では記事を読みたい人がいるらしい。また、Google アラームで ISO 26262 のキーワードがヒットしなくなってきた。

    約3ヶ月前くらいから ISO 26262 に関するニュースが流れなくなってきた。ついにキーワードによるブームが去ったのか。

    これは勝手な想像だが、やっと当事者達はキーワードに踊らされていたことに気がついてきて、本当は何をするべきか考えるフェーズに入ってきたのではないだろうか。

    それはいい傾向だ。そもそも機能安全で安全を追求できるのかについて、自分達の環境で自分達が作っている製品で考えてみるステージに移ってきたのだろう。

    今、自分のドメインのことで頭がいっぱいなので自動車のことを考えている余裕がないが、困っていることがあって取り上げて欲しい話題があればこのサイトの右上の Message Leaf からメッセージを送って欲しい。

    といっても、半分以上の読者が 検索エンジンで目的のページを直接開けているようなので、このメッセージは伝わっていないか。


    1 ページ タイトル 平均ページ
    滞在時間(分)
    2 ISO 26262との向き合い方 (8) リスク分析しないでいいの? 29.72
    3 ISO 26262との向き合い方 (10) ISO 26262 をテンプレートで乗り切る功罪 29.43
    4 ISO 26262との向き合い方 (1) 最初に読んで欲しいこと 28.88
    5 ISO 26262との向き合い方 (3) 規格認証とスコープについて 28.57
    6 ソフトウェア資産の価値を可視化すべし 28.08
    7 ユーザー要求の多様化とペルソナ法 27.90
    8 ISO 26262との向き合い方 (17) 安全機能の複雑性を分析する 27.00
    9 ISO 26262との向き合い方 (21) 安全について理解を深める 26.62
    10 ISO 26262との向き合い方 (1) 最初に読んで欲しいこと 25.33
    11 ISO 26262との向き合い方 (6) 機能安全のマネジメント2 25.27
    12 ISO 26262との向き合い方 (8) リスク分析しないでいいの? 25.22
    13 MATLABのビジネスから見る知的生産性とは 25.00
    14 ISO 26262との向き合い方 (24) ソフトウェア安全分析・設計2 24.78
    15 ISO 26262との向き合い方 (14) FTAとFMEAの歴史 24.10
    16 ISO 26262との向き合い方 (24) ソフトウェア安全分析・設計2 23.93
    17 ISO 26262との向き合い方 (18) ツール認証って何だ? 23.55
    18 ISO 26262との向き合い方 (21) 安全について理解を深める 23.35
    19 100%の安全が確保できないからルンバを作らない? 23.23
    20 ISO 26262との向き合い方 (22) テンプレートで乗り切る功罪2 22.58
    21 ISO 26262との向き合い方 (5) 機能安全のマネジメント1 22.37
    22 ISO 26262との向き合い方 (11) ASILの分解は本当に可能か 22.16
    23 ISO 26262との向き合い方 (21) 安全について理解を深める 22.12
    24 ISO 26262との向き合い方 (17) 安全機能の複雑性を分析する 22.05
    25 ISO 26262との向き合い方 (3) 規格認証とスコープについて 21.68
    26 プリウスブレーキ制御ソフト改変についての考察(再考) 21.55
    27 ISO 26262との向き合い方 (13) 機能安全の歴史的背景1 21.50
    28 トヨタのソフト戦略 21.20
    29 ISO 26262との向き合い方 (4) 用語の定義からのトピックス 21.02
    30 ISO 26262との向き合い方 (12) 対訳版を読み始めて思うことあれこれ 20.88
    31 ISO 26262との向き合い方 (15) FTAを描いてみる1 19.95
    32 ソフトウェア系の国際規格はどのように使うのか? (ISO 26262 が正式発行される) 19.63
    33 ISO 26262との向き合い方 (1) 最初に読んで欲しいこと 19.28
    34 ソフトウェア系の国際規格はどのように使うのか? (ISO 26262 が正式発行される) 19.00
    35 ISO 26262との向き合い方 (18) ツール認証って何だ? 18.95
    36 NHKのドラマ「メイドインジャパン」を見て2 18.82
    37 ISO 26262との向き合い方 (15) FTAを描いてみる1 18.80
    38 ISO 26262との向き合い方 (11) ASILの分解は本当に可能か 18.41
    39 ISO 26262との向き合い方 (21) 安全について理解を深める 18.35
    40 ISO 26262との向き合い方 (5) 機能安全のマネジメント1 18.12
    41 ISO 26262との向き合い方 (18) ツール認証って何だ? 17.63
    42 Embedded Software Manufactory 17.23
    43 ソフトウェア系の国際規格はどのように使うのか? (ISO 26262 が正式発行される) 16.92
    44 ISO 26262との向き合い方 (20) 品質と安全の違い 16.83
    45 西洋の真似をするだけというのはそろそろやめよう 16.70
    46 ISO 26262との向き合い方 (13) 機能安全の歴史的背景1 16.50
    47 ISO 26262との向き合い方 (1) 最初に読んで欲しいこと 16.27
    48 ISO 26262との向き合い方 (6) 機能安全のマネジメント2 16.18
    49 ISO 26262との向き合い方 (5) 機能安全のマネジメント1 15.83
    50 ISO 26262との向き合い方 (5) 機能安全のマネジメント1 15.53

    2013-07-28

    冒険の旅をやりきるにはEP(Experience Point)の積み上げが必要

    仕事で問題を解決すると自分の経験値が上がったと実感することがある。

    ロールプレイングゲームの E とか EP (Experience Point) というヤツだ。経験値が設定値まで達すると主人公のレベルが一つ上がる。

    ロールプレイングゲーム(左は初代ドラゴンクエストの画面)と現実の世界が違うのは、現実の世界では経験値が見えないということだ。

    自分はセミナを開催したときは、「メールで送っていただいた質問には必ず返信します。」とアナウンスすることにしている。会場での質問に答えるのも自分自身の訓練になるが、メールで相手が満足するまで、納得するまでやりとりすると達成感があるとともに、自分自身の経験値が上がった実感を持てる。

    自分のエンジニア人生を振り返ると、いろいろなことを勉強するのに必至だった20代、成果が上がってきた30代、そして、40代になって問題解決能力が高まってきた感じがする。

    問題解決能力が高まってくると、いろいろな問題を解決することがだんだんおもしろくなってくる。難しい問題であればあるほどモチベーションが上がるのが自分でも分かる。

    あるラジオ番組のパーソナリティが、日本人のボランティアは指示を待つ人が多いが、ボランティアの先進国であるアメリカのボランティアは助けが必要なところに乗り込んでいき、そこで求められていることを探して自ら仕事を作ると言っていた。

    この話は『採用基準』に書かれていた、リーダーだけがリーダシップを発揮するという狭いリーダーシップの概念ではなく、プロジェクトの誰もがリーダーシップを発揮してよいという本来のリーダーシップのあり方にも通じると思った。

    問題解決能力が高まると、どうすれば解決の道が拓けるかの道筋が見えてくるので、提案すべきことが浮かんでくる。メンバーの多くにそのようなひらめきが浮かべば、それを議論して何を採用すべきかを決めればよい。

    日本の会議ではみんな黙っていることがあまりにも多い。解決策が思い浮かんでそれやりたいと思ったら、どんどんリーダーシップを発揮して、問題を解決してしまえばよい。自分が名目上のリーダーや責任者じゃなくてもいいのだ。

    それを実践すると自分の経験値がどんどん上がっていくことが実感できる。外から見ると自らやらなくてもよい仕事を背負ったように見えるのだろうが、本人はものすごくモチベーション高く、取り組めている。自ら選択した問題に集中することができ、解決できれば実績になる。

    それを繰り返してくると不思議と、他の人でもできる仕事が寄ってこなくなる。すると、結果的に難しいが自分がやりたい仕事だけに集中することができる環境ができてくる。

    ただ、一つだけ問題があって、ロールプレイングゲームでは常に画面に表示されている HP(Health Point)やEP(Experience Point)は現実の世界では表示されてはいないということだ。

    そうなると、溜まった経験値を何らかの形でアピールする必要が出てくる。いろいろ方法はあるだろうが、直属の上司にだけアピールするのはあまり得策ではないと思う。もちろん、組織内の機密情報は明かせないが、どんな経験値が積み上がったのかを一般的なことばで自分のプロフィールに追加して何からの形で表示するのは表現の自由が保障されている国でやってもよいだろう。

    エンジニアのEP(Experience Point)って、とても重要だと思う。他人の批評だけしていても EP はまったく上がらない。現実の世界では、問題を解決してこそEP が上がるのだ。

    そう考えると、人生観すら変わる可能性がある。嫌々日々の仕事を片付けるのではなく、どんな仕事も自分の経験値を高めることにつながると感じられるようになり、経験値が積み上がってきてレベルアップすると、よりやりたい仕事が選べるようになり、モチベーション高く、さらに難しい問題に挑戦できる道が拓ける。結果的にサラリーが上がるか、もしくはその実績を評価できる別の組織から声がかかるかもしれない。

    傍目で見ていると EP がなかなか上がらない人がいる。そういう人はEP の上がり方をもう少し意識してみたらどうだろうかと思う。EP を効果的に上げるにはどうしたらよいか必至に考えると、何を学習すればよいのかが見えてくる。RPG の世界では EP を上げるには敵を倒すのだが、現実の世界では、リアルな問題を解決できるとぐっと EP を上げることができる。そのためには、どんな知識が必要で、どんな経験がいるかをよく考えるようになる。

    そういう感覚を持っていると、世の中にある洪水のような情報の中で、自分の EP を上げるのに役立つ情報と、役に立たない情報の切り分けができるようになってくる。

    情報を右から左に流したり、評論しているだけでは EP は上がらない。冒険の旅をやりきるには必ずレベルアップが必要で、レベルアップするには EP を積み重ねることが必要だということを意識しないといけない。

    2013-06-27

    ISO 26262との向き合い方 (27) 最終回:何に向き合いますか?

    2011年12月1日から1年半、27回に渡り続けてきた特集記事「ISO 26262との向き合い方」をいったん終了にすることに決めた。

    書きたいネタはまだまだあるのだが、6/7 に開催した SESSAME のソフトウェア安全分析・設計セミナの参加された自動車ドメインの方達と接して、ハタと気がついたのだ。

    薄々気がついていたのだが、自動車業界は業界構造がサプライヤが部品を作りメーカ(OEM)がアセンブリするというスタイルが出来上がっている。

    だから、ソフトウェア安全分析・設計セミナで訴えている「現代の大規模・複雑化したシステムでは Fault Avoidance(個々の構成要素の信頼性を高めることで安全を確保しようとする設計)は無理で、Fail Safe, Fault Tolerance, Error Proof(Fool Proof) の設計を目指しましょう」という主張が肩すかしにあう。

    サプライヤは自分達が供給している部品やその部品を制御するソフトウェアにしか関心がなく、完成品の安全について切々と語ってもぼんやりとしか受け取ってもらえないということに気がついた。

    だから、メーカから ISO 26262 の規格に適合せよと言われて、そこで要求されているいろいろなことをクリアできるようになりたいという欲求はあっても、「エンドユーザの安全について考えよう」という問いかけには反応が薄い。

    コンサルタントも含めてセミナで訴える最終製品の安全の実現よりも、リスク分析の手法を習得することに興味が集中しているらしい。

    そして、ISO 26262 という規格の構造自体が 自動車業界の構造を意識したものであり、サプライヤが供給する部品に Fault Avoidance(個々の構成要素の信頼性を高めることで安全を確保しようとする設計) を求める規格であることが分かった。

    ISO 26262 も上流工程(ISO 26262-1,2,3 機能安全の管理、コンセプトフェーズ、システムレベルでの製品開発)でシステム全体のリスクアセスメントをすることになっているが、これは絵に描いた餅で後から取って付けた要求に見えてきた。

    メーカとサプライヤが一緒になって、コンセプトフェーズやシステムレベルでの製品開発について、頭を付き合わせてディスカッションしている構図がまったく想像できない。

    雰囲気的には、メーカはサプライヤの規格適合を命令するだけ、サプライヤはISO 26262に適合せよと言われてやるだけのように見える。間をつなぐはずのソフトウェア系コンサルタントはハードウェアによるリスクコントロール手段には興味がなく自分達の守備の範囲外だという顔をしているように見える。

    唯一、ECUのプラットフォームを担当する会社のエンジニアはセミナの内容にビビッときたようだが、自動車のシステム全体を見渡せるようなポジションにはいないようだ。

    そんなことを考えていたら、下記のようなニュースが飛び込んできた。

    【中日新聞2013年6月27日記事より引用「衝突軽減装置、誤作動の恐れ トヨタ、2万台リコール」】
    トヨタ自動車は26日、前の車にぶつかりそうになると自動ブレーキがかかる衝突軽減装置に誤作動の恐れがあるとして、昨年末に発売した新型「クラウン」約1万9千台と、5月に発売した新型「レクサスIS」約1000台のリコール(無料の回収・修理)を国土交通省に届け出た。衝突軽減装置のリコールは国内2例目で、トヨタ車では初めて。
     この装置は車体から前方に電波を飛ばし、跳ね返った電波を受信して障害物の距離を測る。近づきすぎると警報音が鳴り、自動的にブレーキがかかる仕組みだ。
     国交省によると、4月以降、リコールの対象車の所有者から「突然ブレーキがかかった」などの情報が6件あった。うち5月下旬、東京の首都高速道路で、渋滞で徐行中のクラウンに急ブレーキがかかり、後続車に追突された。運転手にけがはなかった。 
     トヨタは、クラウンとISを全面改良した際、隣車線からの割り込みにも対応できるよう、障害物検知の感度を上げた。東京の追突事故では、先行車に当たって乱反射した電波が、並走のタンクローリーにも反射。電波が横から来たため「割り込み」と誤って認識して急ブレーキがかかったという。 
     リコールでは、障害物検知のソフトを修正する。衝突軽減装置は、各メーカーがここ10年ほど開発にしのぎを削り、量産効果で価格も下がってきたことで搭載車が増えている。トヨタによると、販売台数のうち新型クラウンでは4割、新型ISでは6割が搭載車という。 
     国交省によると、搭載車のIS約800台が北米や欧州に輸出されており、リコールが必要かどうかトヨタが調べている。
     衝突軽減装置をめぐっては今月4日、三菱自動車もスポーツタイプ多目的車(SUV)「アウトランダー」で、トンネルの壁を前の車と誤認して自動ブレーキがかかる不具合が判明し、リコールを届け出た。
    【引用終わり】

    ソフトウェア安全分析・設計セミナでは、車の基本機能である「走る」「止まる」「曲がる」がアーキテクチャ的に独立している時には、問題が起こりにくいが、今後市場要求が多様化して「走る」「止まる」「曲がる」の機能が相互に干渉してくると、これまで予想もしなかったような原因の分かりにくい不具合が増えてくるということをレクチャーしている。

    安全をインテリジェントにするということの裏側には、思いもよらない副作用も付いてくる。その複雑性に伴うリスクの怖さが自動車ドメインの技術者にはピンときていない。

    プリクラッシュ・セーフティシステムは「走る」「止まる」がソフトウェア的に結合し、緊急操舵回避支援システムでは「走る」「止まる」「曲がる」が結合する。

    上記の誤動作は「止まる」の機能の中に閉じた問題だが、各機能が結合した状態で発生する不具合はこんなに簡単には原因がつかめないかもしれない。しかし、時代はそういった複雑な安全機能・安全性能を求めている。

    トヨタ自動車は自動車メーカの中では唯一プリクラッシュ・ブレーキシステムをCMで大々的に宣伝せず、あのろくでもない読み切る前に消える免責事項の表示もしていない。おそらく、プリクラッシュ・セーフティシステムに不具合が絶対に起こらないこともないとは思っていないし、仮に起こったとしてもCMで免責を表示しているからといってユーザに責任を押しつけることなどできないから、そうしないのだろう。

    そして、実際問題が起こったらソフトウェアを修正して粛々とリコールをする。それが正しい自動車メーカとして立ち振る舞いだと思う。

    CMで免責を表示している他の自動車会社は事故が起きたときに、免責出しているので不具合があっても許してくれと言うのだろうか。そんな言い訳は通用しないのだから、一刻も早くCMの免責表示を取るべきだと思う。

    さて、ISO 26262 はこのような複雑化した自動車ソフトウェアシステムの不具合の再発防止に役立たなければ、まったく意味がないと思っている。

    だから、ISO 26262 を推進している担当者やコンサルタントは、上記のような不具合は ISO 26262 を使ってどうやって防止するのか現場のエンジニアに説明して欲しい。

    自分は自動車業界の産業構造と、自動車業界の産業構造を意識した規格である ISO 26262 は、このような問題には有効には働かない(どこかに方法は埋め込まれているのだろうが、上手くマネジメントされる気がしない)と感じている。

    数年後、自動車への安全要求が多様化した後、分かりにくい不具合が増えてくる。そして、電気自動車の割合が増えて、聞いたことがないメーカの車が出てくると、分かりにくい不具合が一気に増えて社会問題になるだろう。

    そうなって初めて、自動車業界は現在の産業構造のままでは問題を解決できない、サプライヤにISO 26262 の適合を押しつけただけでは、安全を確保できないことに気が付くようになる。

    そうなるには、あと数年以上はかかると見た。そして、自動車メーカもサプライヤもそういった痛い目に遭わなければ、真剣にリスク分析やリスクコントロール設計を学ぼうと思わないと悟った。

    だから、ISO 26262との向き合い方の特集記事はいったん今回で終わりにすることに決めた。

    時代が再び自分の知識や経験を求めるようになったら、また書き始めようと思う。

    長い間、特集記事「ISO 26262との向き合い方」におつきあいいただきありがとうございました。

    ※ブログ「組込みソフトウェア工房」は続きますので、記事のリクエストは引き続き募集します。単発で ISO 26262 の記事を書くことはあります。

    P.S.

    2013年7月1日に『トヨタの部品共通化、海外メガサプライヤーに好機到来』という記事が掲載された。部品が共通化し中小のサプライヤが淘汰されメガサプライヤーに集約されるとう内容だ。どっちにしても、自動車業界はサプライヤの供給部品を組み合わせて使うサプライチェーンの仕組みは変わらないらしい。安全の考え方も Fault Avoidance をやめるつもりはないようだ。安全機能が複雑化したときのことは考えているのだろうか。

    2013-06-01

    電子出版された著書2冊

    技術評論社から出版されているリアル書籍『リコールを起こさないソフトウェアのつくり方』の電子書籍版がリリースされた。

    センセーショナルなタイトルだが、中身は至ってまじめな内容で、なぜ、ソフトウェア品質を高める必要があるのか、ソフトウェア品質を高めるためにはどんな取り組みが必要であるかを地道に解説している。

    また、後半では、6/7, 7/19 のSESSAME のソフトウェア安全分析・設計セミナの内容にも通じる ソフトウェアの潜在的な価値を高めるためのアーキテクチャについて解説し、具体的にどうすれば実現できるのかを説明した。

    価格はリアル書籍と同じ値段で、PDF形式で提供されるので、電子書籍の方が読みやすい、また、タブレット端末で本を読み慣れている方にはお勧めだ。

    【こんな方におすすめ】

    • ソフトウェア開発の初級者の方
    • 新人でこれから目指すべき道筋が見えていない方
    • ハードウェアエンジニアで「なぜ,ソフトウェアは問題を起こすのか」を常々疑問に思っている方
    • ソフトウェアプロジェクトマネージメントの技術を学んでいて,どうして自分のプロジェクトでうまくいかないのか悩んでいる方
    • 組織内でソフトウェア品質問題に頭を抱えている方


    次に紹介するのは、CQ出版さんから電子出版された『クリティカル・システムに使う市販ソフトウェアの検証方法』だ。

    これは、Tech Village で書いたコラムの記事を精査してPDFにしたもので、90ページ525円となっている。

    商用のソフトウェア(OTSソフトウェア)をどうやって検証すればよいのか、またどういった検証記録を作ればいいのかを具体例とともに示したもので、リーズナブルな価格設定なので気軽に購入していただきたい。

    【解説】 ソフトウェアに対する安全対策の要求は,航空宇宙産業や軍事産業に始まり,医療機器,自動車など,今や多くの電子機器へと広がっている.これらのセーフティ・クリティカル・システムの開発においては,製品が要求される安全レベルを満たしていることを証明するため,システムの検証結果の提出や,適合証明が求められるようになってきている.そのような中で,システムに組み込むOS やプロトコル・スタック,ファイル・システムなどに市販ソフトウェアやオープン・ソース・ソフトウェアが含まれる場合,これらがシステムに危険を及ぼさないことをどのように確認すればよいのだろうか? 本書では,市販ソフトウェアの使用に際して求められるリスク分析や検証作業,市販ソフトウェアの検証記録の作り方について解説する.

    どちらの電子書籍もみなさんの商品の価値を高めることに貢献できることを願っている。

    2013-05-17

    ISO 26262との向き合い方 (26) 技術倫理について考えよう

    今週、無償のある規格適合セミナに参加した。(自動車系ではない) 規格認証会社が主催する営業目的のセミナーなので、技術的な知見を得ることはあまり期待していなかったが、いろいろな意味で考えさせられる内容だった。

    そしてセミナから帰ってきて、自分が感じたことをどう伝えたらよいかずっと考えていて、一番しっくりくるのが技術倫理だなと思った。

    さて、この記事の読者の皆さんには、この後の記事を読む前に、是非 JST 科学技術振興機構 の下記のコースを眺めてみて欲しい。

    安全安心社会のための技術倫理コース(90分)

    時間がない方は、これだけでも見て欲しい。

    科学技術の倫理(学習時間12分)

    【科学技術の倫理の学習目標】
    現代社会は高度な科学技術に支えられている。科学技術は、人々を災害から守り暮らしを快適にする一方で、それ自身が災いとなって人々の安全を脅かし不安にさせることがある。科学技術のマイナス面を抑制するために、科学技術の専門家すなわち技術者は、高い専門能力と倫理性が求められる。
    このレッスンでは、(1)科学技術の専門家になぜ倫理が必要なのか? (2)科学技術が社会に受け入れられるために何が必要なのか? について考察する。
    JST 科学技術振興機構は これ以外にもさまざまな技術系の e-Learning 教材を提供しており、無償で閲覧できる。効果確認テストも付いている。(無償なのは元は税金で作ったからだろう。使わないのはもったいない)

    なぜ、技術倫理かというと、それは、国際規格への適合を技術倫理の面から見るととどうなるか、このブログの読者に考えて欲しいからだ。

    規格認証会社は規格に適合しているかどうかを実際に対象品を試験をしたり、対象企業を監査することを生業としている。テストの判定基準が明確である電気的安全性の試験の場合、公正なテストを行えばその試験証明は他でも使える。(参照:CBスキーム

    しかし、ISO 90001 やソフトウェア系のプロセス規格の適合のチェックはテストではなく、監査という形で実施するしかなく、ある程度監査官の主観も入るので常に同じ結果になるとは限らない。

    というよりも、エビデンスはあるのが前提で、監査官の問いに対して、答えられれば合格、答えられなければ不合格となるような種別の適合チェックだ。

    よって、監査官の問いの意味が理解できない場合は不合格になる確率が極めて高く、監査官の質問の意味が分かっていて、自分達がやったことに結びつけることができれば合格となる確率が高い。

    その際、規格要求そのものズバリではなくても、当たらずとも遠からずの結果をエビデンスとして説得できれば合格にできる。(この感覚が分からなければ、相当高い授業料を払う羽目になる)

    別な言い方をすると、規格要求と同等のことができていると論破することができれば、それでも合格となるということだ。ディベート力が高い方が監査には絶対に有利であり、何も言い返せない技術者はどんどん不適合を指摘されてしまう。

    よって、同じエビデンスでも欧米人が監査を受けると不適合が少なく、日本人が受けると不適合が多い。ディベートの訓練を受けていないからだ。欧米企業の場合、USの規制当局に対してこれをやり、エビデンスがなくても黒を白と無理に主張したりするので、監査官が不信を抱き、かえってひどい不適合を食らって裁判になったりする。だからといって、何も主張できない日本の企業も情けない。

    正直、こういう監査(内部監査、外部監査)をやっていると監査している方も、されている方も何のために監査をやっているのが分からなくなり監査が不毛に思えてくる。ディベートをしている自分に虚無を感じるのだ。

    規格適合会社の営業プレゼンより、具体例を挙げよう。

    ある規格に「・・・要求されるプロセス、活動及びタスクをアセスメントすることによって判定する。」という要求事項があり、備考に次のように書いてある。

    備考1 このアセスメントは、外部監査で行ってもよいし、内部監査で行ってもよい。

    これを文面通り解釈すると、わざわざ外部認証機関に監査してもらわなくても、自分達でやればいいんだとホッとするところだと思うが、規格適合会社の営業担当の説明はそうではなかった。

    「規格にある Note(備考)は要求ではありません。備考に書かれていることはあくまでも参考情報ですから鵜呑みにしないように。」 ようするに、規格は本文で内部監査でもよいと言い切っている訳ではない(=暗に外部監査を受けなさい)と強調したのだ。

    これには正直唖然とした。国際規格のことをよく分かっていて、修羅場をくぐり抜けてきた経験があれば、まったく逆に捉えることができる。

    「外部監査でなければいけないという要求はどこにも書いていない。備考にも内部監査でよいと書いてあり、我々は内部監査で実施している。何か文句あるか。」 実際には「何か文句あるか」の部分は口には出さないが、「何か文句あるか」といった態度を示すことはある程度必要で「こいつはよく分かっている。できるな、いい加減なことは言えない。」と相手に認識させることが監査では重要になってくる。

    規格要求を十分に理解できておらず、正直者で弱腰の日本人の技術者は監査に慣れていないと、サンドバッグのように打たれまくり、ボロボロになる。

    そして、最悪なのは外部監査でいったんは技術者とともに打たれたQA担当が、外部監査が終わった後に技術者を打つ方に回る場合だ。規格要求を学習していくにつれ、「こんなことも、あんなことも知らないのか」と技術者を見下すようになり、自分達が組織内部で取り締まる側になっていく。規格適合会社の営業的な言い回し、考え方がフィルターを通さずに組織内のQA担当に伝染する最悪の例だ。

    「備考1 このアセスメントは、外部監査で行ってもよいし、内部監査で行ってもよい。」は、解釈する者によって、「内部監査で行ってもよいとは言い切っていない」とも主張できるし、「外部監査でなければいけないとはどこにも書いていない」とも判断できる。

    普通に読めば後者の意味だと思うが、規格適合の外部監査を勧めたい営業担当に言わせると前者にもなり得るということだ。規格要求の理解が足りず、監査慣れしていない者は、こういった営業トークのちょっとした言い回しが頭の中にすり込まれ、サブリミナル効果のように潜在意識に残り、結果として不安に駆られ、外部監査を申し込むことになる。

    数は少ないが、技術倫理感を持った監査官やコンサルタントもいる。そういう開発プロジェクト側と一緒に安全の実現を目指してくれる人や会社をパートナーとして探さなければいけない。

    ソフトウェア工学や過去の知見を使った製品安全の実現が目的のはずなのに、規格解釈論に終始するのは、本当にばかばかしいと思う。

    言っちゃ悪いが、この規格適合会社の説明は、監査を通じて安全なソフトウェアの実現のために互いに協力しましょうという姿勢は微塵も感じられなかった。

    説明する方も説明を聞く方も、規格に適合することが目的となっている。これは本当に不幸なことだ。技術者にとって不幸であるばかりでなく、エンドユーザーにとっても不幸なことだと思う。

    そこで、今回の記事のテーマである技術倫理が出てくる。JST の科学技術の倫理の一説を見て欲しい。
    ここで、なぜ技術者に倫理が必要なのか、2つのモデルを用いて説明しましよう。  
    まず、ひとつめは社会契約モデルです。これは、専門家と公衆とが契約関係にあると考え、専門家は高い専門能力を有することで、報酬と地位が与えられますが、これと同時に公衆に対する倫理的責任を負うという考え方です。 
    医師や弁護士などのプロフェッションと呼ばれる専門職業は、このモデルに該当します。技術者も完全ではありませんが、このモデルに類似するものと考えられます。

    ふたつめは、相互依存モデルです。科学技術が高度化・細分化した社会では、仕事の分業化が進み、人々は相互に依存し合って生活しています。 
    科学技術に支えられる現代社会において、技術者が公衆の安全を最優先にすることで、公衆も技術者を「信頼」し、安心して依存し合える社会を築くことができるのです。 
    ここで示した「社会契約モデル」と「相互依存モデル」のどちらの考え方でも、技術者には高い倫理性が求められているのです。 
    プロフェッションと呼ばれる専門家は、高い専門能力を持つことで報酬と地位が与えられる。専門家はその報酬と地位を得ると同時に公衆に対する倫理的責任を負う。

    技術者が公衆の安全を最優先にすることで公衆も技術者を信頼し、安心して依存し合える社会を築くことができる。

    これが科学倫理、技術倫理の考え方だ。(Ethics of Science and Technology)

    規格認証会社の監査官はその規格を熟知しているわけだから、プロフェッションであり、公衆に対する倫理的責任を負っているはずだ。

    技術倫理から考えると、監査では国際規格の適合が安全を実現することに寄与しているどうかを最終的な判断基準にするべきであり、その専門性を使って公共の利益よりも、自社の利益を優先させてはならないと思う。

    「規格の要求はこう解釈できる。あなたたちは要求に適合できていません。」ではなく「安全を実現するために規格はこれを要求している。安全を実現するために、この要求を満たしてください。」という態度を取るべきだ。そうすれば、ディベートも実のあるものになるだろう。

    ソフトウェアは見えにくいだけに、技術倫理をしっかり持たないと専門性が公共の利益(今回の場合はエンドユーザーの安全)よりも、組織の利益が優先される事態に陥りやすいと思う。

    ソフトウェアの場合は真っ黒でも、真っ白でもなくグレーゾーンが広いことも技術倫理が揺らぐ要因になっている。明らかな黒ではないが、「本当にエンドユーザーの安全を優先しているのか?」と首をかしげたくなるような発言や行動が多い。

    日本人は技術倫理の教育などしなくても自然と身についているものだと思っていた。武士道の精神が育まれる環境がもともとあると思っていた。

    ところが特にソフトウェアの世界で欧米のテクノロジーが導入されるようになって、技術倫理はちゃんと教育しないといけないのではないかと思うようになってきた。

    技術倫理教育は誰がやればよいのだろうか。規格適合会社にやれというのは無理だから、企業の中かアカデミアか、コンサルサントがやらなければいけないのだろう。自分や自組織の利益を公共の利益よりも優先する者は、残念ながらどこにでもいるので、最後は自分で判断するしかない。

    あなたは自分が持っている専門性に対する技術倫理(公衆に対する倫理的責任)について考えたことがあるだろうか。

    今日、安倍首相が成長戦略について語っている場面で「日本の高い技術」というフレーズを連発していた。「日本の高い技術」とは何か、「日本が欧米よりも優れているのはどこか」についてあたりを付けた上での発言なのかどうかが怪しいと思った。

    気のせいかもしれないが、日本の技術的優位性について研究している研究者って本当に少ない気がする。欧米発想を鵜呑みにして形骸化させないためには、技術倫理をしっかり持って何をすべきかを考えながら、成長戦略とは何かを考える必要がある。

    2013-05-11

    プラットフォームの共通化が加速させるソフトウェア起因のリスク

    MONOist  に 『制御系システムのマルチコア化に対応、TOPPERSがAUTOSAR準拠の車載RTOSを公開へ』という記事が掲載された。

    欧州の車載ソフトウェア標準規格であるAUTOSARに準拠したリアルタイムOS(RTOS)「TOPPERS/ATK2」のマルチコアプロセッサ対応版が、2013年6月からTOPPERSプロジェクトを通じて一般公開されるという話だ。

    そして、「TOPPERS/ATK2」を開発したATK2コンソーシアムでは、RTOS仕様の策定とそれに基づくATK2の開発に加えて、ATK2向け検証スイートの開発、要求タグを付与することで仕様のトレーサビリティを確保できる設計書の作成や、AUTOSAR仕様をベースとした通信ミドルウェアおよびRTE(Run-Time Environment)ジェネレータの開発も行っているという。

    ソフトウェアに要求タグを付けて、要求からプログラムソースをトレースできるようにするというアイディは、かつてNASAのベテランソフトウェアエンジニアが行っていたテクニックであったと広島市立大学の大場充先生が言っていた。

    それは非常のよいアイディアだと思う。要求に変更があったときに、そのタグを頼りにどの部分のプログラムを直せばよいのかが分かる。

    また、「TOPPERS/ATK2」はAUTOSARの仕様に準拠したRTOSのテストスイートであるAKTSP(Automotive Kernel Test Suite Package)が用意されており、テストパターンに仕様の要求タグをつけて、実施するテストを選択できるようになっていると言う。

    このように RTOS のようなソフトウェアシステムの心臓部に使われる OTS(Off The Shelf)ソフトウェアのテスト環境がRTOSのDistributor から供給されることは利用者側からも歓迎されることだ。

    自分も Tech Village で『クリティカル・システムに使う市販ソフトウェアの検証方法』という記事を書いているので是非参考にして欲しい。

    ところで、AUTOSAR の名前は知っていたが、詳しいことは分かっていなかったので、MONOist の記事『AUTOSARで変わる車載ソフトウエア開発』をじっくり読んでみた。2009年の記事なので今ではここに書いてある内容よりももっと進んでいるのだろう。

    【『AUTOSARで変わる車載ソフトウエア開発』より引用】
    自動車の電子化の進み具合は、いくつかの指標で表現することができる。その指標の1つとして用いられるのが、搭載されるECU(電子制御ユニット)の数である。
    ECUの搭載が始まった1980年代初頭は2~3個程度だったが、現在は100個以上ものECUを搭載する高級車も存在する。基本的に、それらのECUは、ある1つの自動車システムを制御するために最適化されたハードウエアと車載ソフトウエアから構成されている。各ECUは、ほかのシステムを制御できるような汎用的な作りにはなっていない。例えば、エンジンの燃焼タイミングを制御するエンジンECUは、ステアリングやメーターなどほかのシステムの制御を行うことはできない。
    【引用終わり】

    ようするに、専用のECUを汎用のベースプラットフォーム+アプリケーションソフトウェアという組合せに変えて行こうという取り組みだ。

    ザイリンクスがARMベースのワンチップマイコンとFPGAを合体させて、1個のチップで何でも自分達の好きな形に SoC を作り替えることができる Zynq-7000 All Programmable SoC を提供している。AUTOSARの取り組みにはぴったりのプラットフォームだと言えるだろう。

    ただ、この流れが進んだときに浮かび上がるリスクが自分には見える。

    ハードウェアが汎用化され、外からはよく見えないソフトウェアが自動車の価値の多くを担うようになったときの落とし穴だ。

    プロセッサの処理能力はどんどん上がり、ハードウェアで処理させたい機能はFPGAのIPにやらせればよいという選択ができるようになってきた。

    そうなるとソフトウェアの複雑度と規模はますます上がり、安全に関するリスクの高いソフトウェアモジュールとそうでもないソフトウェアモジュールが混在することが当たり前になってくる。

    機能ごとにECUが分かれていた時には、物理的にモジュールの分離ができていたが、今度はソフトウェアの世界でのモジュール分離が重要になってくる。

    それ故に『AUTOSARで変わる車載ソフトウエア開発』の記事の中でも、アーキテクチャベース開発の重要性が書かれており、この流れ自体は望ましい。

    しかし、『AUTOSARで変わる車載ソフトウエア開発』の記事の中にも触れられていないのは、自動車への要求の多様化がもたらすソフトウェアの安全性へのインパクトと、そのリスクを防ぐために必要なリスク分析や安全のためのアーキテクチャについてである。

    AUTOSAR のようなプラットフォームの汎用化に伴い、アプリケーションソフトウェアの分離の重要性が増し、かつ、さらなる自動車ソフトウェアへの要求が多様化することによる Systematic Failure のリスクとその対策のことについてもっとよく考えた方がよいと思うのだ。

    そのためには、ISO 26262 に象徴されるようなプロセスアプローチを前面に押し出すのではなく、アーキテクチャベース開発の前段階における 要求分析、リスク分析、リスクアセスメント、リスク対策にフォーカスしなければならない。(プロセスアプローチの重要性は変わらない)

    ソフトウェア安全分析・設計セミナには、多数の自動車系サプライヤの皆さんに参加申込みしていただいているのだが、なぜが自動車OEM(メーカ)さんからの参加が少ない。自動車のエンドユーザーのリスクと直接向き合わなければいけない自動車OEM(メーカ)さんからも是非参加してもらい、要求の多様化に伴うソフトウェアリスクのインパクトについて一緒に考えて欲しい。

    ちなみに、7/19の回では、自動車以外のドメインの方々の参加も増えてきている。(ほんとにいろいろだ)

    セミナでは、放射線治療器 Therac-25 の事故モデル、体温計モデル、エレベータモデル、電気メスモデル、暖房システムモデル、緊急操舵回避支援システムなどの具体例を使って、できる限り何をしなければいけないか、どんなスキルを身につけなければいけないのかを実感できるケーススタディをするつもりだ。

    2012年のSESSAME Workshop 「次世代組み込みエンジニア活性化計画」~これからの10年を考える~の時だったと思う。「セーフティ・クリティカルな製品を開発する技術者は、安全の責任を負う必要がある。」という発言をしたところ、「人の命に関わる製品の仕事には絶対就きたくありません。」と会場にいた学生さんが言った。

    そのとき、この人は人の命に貢献する製品を作ることができたときの喜びを想像できないのかもしれない、もったいないなと思った。

    安全・安心を担保しながら人の役に立つ物を作って喜んでもらえたとき、技術者としてやってきて良かったと思う。

    超えなければならないハードルも高いが、達成できたときの喜びも大きいのだ。脇道から行くのではなく、がっつり正面から組み合って結果を出す感じかなあ。








    2013-04-27

    ISO 26262との向き合い方 (25) B787バッテリ故障FTAモデル

    現在、SESSAMEで主催するソフトウェア安全分析・設計セミナ(第1回 6/7, 第2回 7/19)の講義スライドを作っている。

    この特集記事を書いているせいか、第1回目のセミナの応募者の半分以上が自動車ドメインの方になっている。

    第1回目のセミナは募集開始から10日間で定員に達してしまったため、第2回を 7/19 に行うことになった。

    第2回は自動車ドメイン以外の方にも是非多くきて欲しいと思っているので、最近ニュースになっているボーイング787のバッテリ故障について FTAを使ってケーススタディをしてみようと思う。(このケーススタディはソフトウェア安全分析・設計セミナで詳しく解説する)

    B787のトラブルのうち 1/8 と 1/16 のぶんがリチウムイオンバッテリの発熱・発煙事故だった。

    日付
    (日本時間)
    会社 トラブル
    01月08日 JAL 米・ボストンのローガン国際空港で、駐機中の日航機の機体内部から出火
    01月09日 JAL 同空港で、地上走行中の日航機の主翼から燃料漏れ
    01月09日 ANA 羽田発山口宇部行きの全日空機でブレーキに不具合
    01月11日 ANA 羽田発松山行きの全日空機で操縦席窓にひびが入るトラブル
    01月11日 ANA 宮崎空港で離陸前点検中の全日空機の左エンジンからオイル漏れ
    01月13日 JAL 成田空港で、米国ボストンの空港で燃料漏れを起こした機体が、整備作業中に燃料漏れ
    01月16日 ANA 山口宇部発羽田行きの全日空機で飛行中、操縦室内で異臭がしたため高松空港に緊急着陸。乗客129人と乗員8人が脱出用シューターで避難、乗客5人が軽傷


    ニュースソースによるとボーイング社はリチウムイオン電池の故障確率を1000万時間に1度としていたが、実際には5200時間以下で事故が発生した。

    FTAでは部品の故障確率を計算して総合的にトップ事象が発生する確率を計算できるが、個々の基本事象の発生確率の根拠が不確かな場合、トップ事象の確率がいい加減になるという典型的な例だ。

    歴史的にもFTAによって、事故事象の発生確率が意図的に低いように見せるために、基本事象の発生確率を低く設定した例はある。また、ソフトウェアが起因する不具合の場合、不具合の発現は統計的な確率を持たないため、FTAでもこのことを考慮する必要がある。(詳しくはソフトウェア安全分析・設計セミナで解説する)

    リチウムイオンバッテリが熱暴走し発熱・発煙したことは事実だが、結局その原因はまだ分かっていない。そこで、ボーイング社は80の可能性について対策を施すことで、FAAに B787 の飛行許可を申請し受理された。

    ニュースでは熱暴走の本当の原因が分からないままで、運行を許可してよいのかというコメントが必ず付く。その通りなのだが、実際、セーフティ・クリティカルな製品を製造し市場に出している中で、再現しない不具合に対処しなければならないことはある。

    そのような場合は、今回ボーイング社が行ったように、想定されるすべてのリスクを洗い出してその対策を施す。これが、リスクアセスメント(リスクの特定、リスク分析及びリスク評価)とリスクコントロールであり、ソフトウェア安全分析・設計セミナのメインテーマだ。

    ボーイング社が80の対策を行ったということは、逆に言えば、対策を行う前は新たに想定した故障が具現化するとバッテリが熱暴走を起こし発火・発煙を起こすということだ。

    これを FTA で表すと左記のようになる。実際はそう単純ではないが、何らかのハードウェアの故障及びソフトウェアの不具合が発生するとそれが OR 接続でトップ事象に結びく。

    何か一つクリティカルな故障が起こるとそれが重大事故に繋がることを FTA は表している。

    一般の人は、なぜ前もって対策をしなかったのかと思うだろうが、このような トップ事象に至る基本事象は無限に存在するのだ。

    だから、ボーイング社が事故が起こった後に行った追加対策は80もあった。ただ、それで全てではない。リスクは無限に存在するので対策も無限に存在する。

    そういった場合、仮にトップ事象の発現を押さえる包括的な対策があれば、それをシステムに追加することが安全面では非常に有効だ。(エレベータで安全用のブレーキを追加するなど)

    これを FTA 表すと左のようになる。熱暴走故障の発現は包括的な安全装置で押さえられており、安全装置が故障しない限りトップ事象には至らない。

    トップ事象は熱暴走の故障と安全装置故障が AND で起こらないと発生しないので、非常に低い確率に抑えることができる。

    ただし、これは安全装置をハードウェアで用意した場合であって、ソフトウェアが絡んでいると必ずしも確率を言えないので注意が必要だ。

    では、包括的な安全対策がない場合はどうするのか。それは、この図のように、ひとつひとつのハードウェア故障の発生確率を下げる対策を取る(Fault Avoidance)か、ハードウェア故障が発生したことを検出して、故障の発生を認知したら、オペレータに知らせそのための対策をオペレータが取る。

    実際今回の80の対策のうち、バッテリの状態をB787の運行中も地上で監視できるようにしたそうだ。

    バッテリ状態に異常があることが分かったら、パイロットに緊急着陸の指示を出す。

    これを FTA で表すと左記のようになる。ハードウェア故障1の発生確率を下げ、かつ、故障検出装置を付けることで故障検出装置が故障しない限り、ハードウェア故障1のトップ事象への影響を下げることができることが分かる。

    そして、最後に問題として残るのがソフトウェアの不具合がトップ事象に与える影響だ。

    ハードウェアによる包括的な安全装置が使えない場合、個々のハードウェアの対策をしても、ソフトウェアの不具合がトップ事象に直接作用してしまう場合がある。

    ソフトウェアの不具合の発生確率は統計的な性質を持たないため、高いとも低いとも言い切れない。

    これが Systematic Failure の特徴だ。このように包括的な Fail Safe 対策が取れない場合、Fault  Avoidance  対策かFault Tolerance 対策で対処するしかない。

    そこがソフトウェア対策の難しいところだ。実際、B787のバッテリ制御ソフトウェアに対しても、今回対策を行ったと報じられている。どんな対策か詳細は伝えられていないが、おそらくソフトウェアの信頼性検証を再度行ったか(Fault  Avoidance対策)、冗長設計(Fault Tolerance対策)を施したのだろう。

    なお、FMEA(ハザード分析)をするとこんな感じになる。


    ソフトウェア安全分析・設計セミナでは上記のことを含めた安全実現の手順について下記を紹介している。
    1. Intended Use (意図した使用目的)を定義する
    2. リスク分析を実施する。(ユーザビリティを考慮する)
    3. リスクを評価する。(FMEA:ハザード分析、FTA)
    4. リスクコントロール手段を考える。(ハード or ソフト or 表記)
    5. ハードウェアによるリスクコントロールを優先する。
    6. ソフトウェアによるセーフティアーキテクチャを可視化する。
    7. 安全に貢献するソフトウェアアイテムを特定する。
    8. それらのソフトウェアアイテムの信頼性を高める。
    9. セーフティアーキテクチャを維持する。
    10. フィールドで発生した問題をトリガにして1から繰り返す。
    セミナでは、今回説明したB787バッテリ事故モデル以外にも、放射線治療器 Therac-25 の事故モデル、体温計モデル、エレベータモデル、電気メスモデル、緊急操舵回避支援システムモデルについて解説する。

    7/19 の回にはまだ空きがあるので、是非セミナを聞きにきて欲しい。



    2013-04-20

    ISO 26262との向き合い方 (24) ソフトウェア安全分析・設計2

    SESSAMEで6月7日に開催するソフトウェア安全分析・設計セミナの資料を作っているところだ。

    4月17日に募集要項を公開してから2日間で事務局宛に11名の応募があったようだ。(定員は30名なので参加を検討されている方は早めに申し込んで欲しい)

    東京近郊以外の遠方から申し込んでいただいた方も半分くらいおられるので、その方達の期待に添う内容にしたいと思っている。

    セミナで使うスライドはまだまだこれから作成、ブラッシュアップしていくので、参加を希望されている方達の業務ドメインを眺めながらそれぞれの実務でイメージが湧くような事例を多く紹介しようと思っている。

    なお、このブログで ISO 26262 の特集記事を書いていることもあって、現在のところ自動車系のドメインの方の申し込みが多い。(自動車ドメインに特化した内容ではないので、他のドメインの方も来て欲しい)

    この記事では、『ソフトウェア安全分析・設計セミナ』が、他の ISO 26262 に代表される機能安全のセミナとどこが違うのかを説明したいと思う。

    プロセスアプローチの話をするつもりはない

    このセミナでソフトウェア開発のプロセスアプローチの説明をくどくどとするつもりはさらさらない。そこが他のセミナとの違いだ。 ISO 26262 に代表される機能安全のセミナは、必ずソフトウェア開発プロセスの話から入り、ソフトウェア開発プロセスの重要性を説き、ソフトウェア開発プロセスのマネジメントの話をし、場合によっては、プロセス管理に有効とされるツールが紹介され、コンサルテーションを勧められる。

    ISO 26262 だけでなく、ISO 9001 以下、ほとんどの品質要求がプロセスアプローチをベースにしているのでしようがないが、自分はこの流れに対して常に違和感を感じてきたエンジニアの一人だ。

    プロセスアプローチを否定するつもりはまったくないが、特に日本のプロジェクトの場合、そこから入ると本質を見失うような気がしてならない。

    自動車ドメインの方達はもしかすると自分が考えるこの違和感に慣れていないのではないかと思っている。特に自動車ドメインではハードウェアエンジニアの人や、ハード・ソフト込みでコンポーネントに対する責務を負っている人達、品質保証部門の方達が今後の方向性が分からなくなっているような気がする。

    自動車業界では、昔からソフトウェアの開発に対してプロセスアプローチが求められてきた訳ではない。今回 ISO 26262 が国際規格になって初めて、ソフトウェア開発にプロセスアプローチが求められた。それまでハード屋さんは、ソフト屋さんにソフトウェア開発に関するすべてを委任してきた。ところが、ISO 26262ができて、ソフトウェア開発にプロセス要求が求められていることに気がついた。

    そこで、ソフト屋さんに「これらの要求は当然これまでもやってきていて、できているんだよな」と尋ねる。ところが、その回答の歯切れが悪い。「当然、できています」という答えが返ってこないのだ。

    そこで、ハード屋さんやQA担当は、「だから、ソフトウェアで問題が起こるんだ」「国際規格にも適合できないような作り方をしているから問題を起こすんだ」とはや合点する。

    自動車ドメインのソフト屋さんを代弁して言う。「そうじゃないからね」。

    日本の自動車産業の組込みソフトウェアの品質は海外のソフトウェアの品質より格段に高かったし、今でもその品質を高く保っている。

    そして、それが達成できている理由は、下記の図にあるように文化の違いともの作りのアーキテクチャの違いから来ている。

    欧米のもの作りでは「ルール/責任」を重視し「システム/ツール」を使いこなすのが得意だが、「品質を心配する意識」が低い。一方、日本のもの作りでは、「ルール/責任」は重要視せず、「システム/ツール」を使いこなすのが下手だが、「品質を心配する意識」がものすごく強い。それも、マネージャクラスの意識だけが強いのではなく、プロジェクトメンバー全員の意識が高い。

    そして、システムのアーキテクチャがコンポーネントの組合せではなく、すり合わせたような作り方をする。

    サンプルは少ないかもしれないが、日本のソフトウェアに起因する不具合が修正されるスピードは欧米のそれに比べて格段に早い気がする。


    ようするに、不具合が見つかってからアップデートのプログラムがリリースされるまでが早い。問題が放置される時間が短いので、長い目で見れば顧客満足度は高い。

    海外の開発品で不具合の現象がはっきり出ているのに、なんだかんだ理由を付けて改善のためのアクションを起こさないという例を数多く見てきた。

    責任の所在があっちだ、こっちだと言っているうちの時間だけがどんどん経過していくというケースもたくさんある。

    それに比べると日本のソフトウェアプロジェクトでは問題が起こったという情報が伝わってきた時点から、猛然と原因を調べ始める。これは「品質を心配する意識」が強く、恥の文化があるからだと思う。

    逆の言い方をすると、欧米の文化では、「品質を心配する意識」が弱く、恥の文化がないから、ソフトウェア開発プロセスをがっちり管理しないと、品質が上がらないのだ。

    ソフトウェア品質系の国際規格で問題解決プロセス(Software problem resolution process)がやたら強く要求されていて、何でだろうと考えていた。

    問題解決プロセスの例 (Software problem resolution process)
    1. 問題報告の作成
    2. 問題の調査
    3. 関係者への通知
    4. 変更管理プロセスの使用
    5. 記録の保持
    6. 問題の傾向分析
    7. ソフトウェア問題解決の検証
    8. 試験文書の内容への要求
    それは、問題解決プロセスを定義して問題が起こったときにそのプロセスを回さないと、人が動かないからそうするのだと気がついた。問題の重大度にもよるが、日本のプロジェクトではいちいち問題解決プロセスを回さなくても、問題がものすごいスピードで解決されてしまうことが多いと感じる。

    すべてのケースでそのやり方がよいとは思わないが、通り一遍の問題解決プロセスの適用はかえって顧客満足度を下げる結果になると思う。

    だから、プロセスアプローチ至上主義のような説明は本セミナではしない。

    自動車ドメインの例で説明するとこうなる

    だからといって、自動車ドメインのソフトウェア開発のあり方がいままでのままで何も変えなくてもよいとは考えていない。そう考える理由を一つの例で説明しよう。

    自動車のアーキテクチャの基本は「走る」「曲がる」「止まる」の3要素だ。

    そして、それらの三つの基本要素はハードウェア的にもソフトウェア的にも独立していた。

    それは設計としては美しい。それぞれの機能・性能要素の関連が疎でり、独立性が高い状態で維持できていれば、システム全体としての複雑性を回避できるし、何か問題が起こったときでも、どこに不具合の原因があるのかがすぐに分かる。

    さらに、コンポーネントごとにサプライヤを分離できるため、設計上だけでなく問題が発生したときの責任も明確になる。

    自動車業界におけるメーカーとサプライヤの関係ともマッチする。

    完成度の高いコンポーネントを組み合わせることで製品全体の信頼性が高まる。

    このようなアーキテクチャはセーフティの観点から見るとフォールドアボイダンス(Fault Avoidance) と言う。

    しかし、現代の自動車のシステムはこんなに単純な構造ではない。

    高凝集、疎結合のコンポーネントの組合せではなくなってきている。前述したすり合わせのソフトウェア構造が有効なのは、基本機能・基本性能のコンポーネントの中の話だ。「走る」の機能・性能を司るコンポーネントの内部である程度のすり合わせがあるのは総合的にプラスに働くことがある。(競争力の高いコア資産の形成に有利)

    ところが、最新の衝突回避システムを導入すると、衝突リスク分析判定ECUを介して「止まる」と「曲がる」の基本機能コンポーネントの結合度は強くなる。

    ハイブリッド車では「走る」と「止まる」はすでにエネルギーの回収をすることで結合しているので、今後、自動車のシステムアーキテクチャはどんどん複雑になって結合を強めていく可能性がある。

    その結果、コンポーネントごとに明確だった責務が「走る」「曲がる」「止まる」にまたがってくる。

    このことは不具合が起こったときの対処や、そもそも安全を考慮した設計ができているかどうかの確認の所在が、サプライヤをまたがる可能性が出てきたということだ。

    この状況はこれまでの強みだった日本の良さを消しかねない。自動車のシステムアーキテクチャの変化が、日本的なもの作りのやり方のアドバンテージを低下させようとしている。

    そうなると、欧米的なプロセスアプローチを取り入れないと安全が確保できないかもしれない。

    リスクマネジメントとセーフティアーキテクチャの重要性

    ただ、自分は日本のもの作りにおいて、今後も世界の優位に立つための必要なのはリスクマネジメント(リスクアセスメント+リスクコントロール)とセーフティアーキテクチャ設計だと考えている。

    そこを押さえた上で、プロセスアプローチを取り入れていけばよい。

    こういった話を織り交ぜながら、セーフティの考え方と具体的な実践手法を6月7日のセミナでレクチャーしたいと思っている。

    今回の記事では自動車ドメインでの例を取り上げたが、参加者の業務ドメインを見ながらどのドメインにも通じるような話をしたいと思う。

    P.S.

    自動車業界でも医療機器業界でもUSでは規制をクリアするために必要な知識・スキルをを身につけるセミナはだいたい3日間で$1500~$2000くらいかかる。(1日あたり $500 以上) これに宿泊代や飛行機代がかかるから、結果としてものすごい金額になる。(例えば、こんな感じ大学のセミナだってそれぐらいかかる。)

    2013-04-14

    ISO 26262との向き合い方 (23) ソフトウェア安全分析・設計セミナ

    ISO 26262 が2011年に発行されてから時間が経過し、今になって自動車の設計開発の現場で混乱が起こり始めたような気がする。

    ソフトウェアの開発経験のないハードウェアエンジニアにもISO 26262の存在がクローズアップされるようになり、ソフトウェアエンジニア達に規格適合できているの問いただすような視線を送るようになってきた。

    ISO 26262 は基本的にプロセスアプローチだから、規格が要求するプロセス通りにもの作りをし、エビデンスとなるドキュメントが作成していないと規格に適合していると認めてはもらえない。

    規格適合について監査したり、自分達でアセスメントをしたりすると、いろいろと漏れが出てくる。そうすると、ソフトウェアのことを分からない人達は「なんだ、ダメじゃないか」「どうして、国際規格の要求ができていないんだ」「怠慢だ」とソフト屋さんを責める。

    電気的安全性のように試験で白黒がはっきりするような規格なら、不合格のままで出荷されることなどないから、ハード屋さんや品質保証担当は、ソフトウェアの規格が満たされないまま商品が世界に出荷されていることが我慢ならないのだろう。

    しかし、そこがソフトウェアの評価の難しいところだ。ソフトウェアはハードウェア部品のように確率論的な故障のしかたをしない。だから、ソフトウェアの信頼性を高めるためにはソフトウェアの開発プロセスを管理するしかないというのが定説になっている。

    しかし、ソフトウェアの信頼性を高めたからと言って、システムが安全かと言えばそうではない。このことを上記のような感情を抱くハードウェアエンジニアや品質保証担当は分かっていない。

    分かっていないにもかかわらず、ソフトウェアの開発プロセスの管理ばかりに注力を注いでいると、規格の目的とは対照的に商品の安全性が脅かされる危険さえある。

    そういう背景もあって、所属しているコミュニティの SESSAMEで 2013年6月7日(金)にソフトウェア安全分析・設計セミナ(1日)を開催することになった。

    6月7日のセミナは、ソフトウェアプロセスアプローチとはまったく別の切り口から安全設計を考えるセミナだ。


    セミナのプログラム案はこのようになっている。

    22nd Open SESSAME Seminar プログラム(案)
    10:00~10:30 クリティカルソフトウェアを取り巻く環境
    10:30~11:30 安全(セーフティ)の考え方

    ・安全(セーフティ)の定義
    ・リスクアセスメント,リスク低減
    ・リスクマネジメントの反復プロセス
    ・ソフトウェア起因の障害のリスク評価
    12:30~13:30 リスク分析手法1(FMEA)

    ・FMEAの歴史、ハザード分析
    ・ソフトウェア視点のFMEA
    13:40~14:40 リスク分析手法2(FTA)

    ・FTAの歴史
    ・ソフトウェア視点のFTA
    14:50~16:10 リスクコントロール手法

    ・フェールセーフ
    ・エラープルーフ(フールプルーフ)
    ・フォールト・アボイダンス
    ・フォールト・トレランス
    ・ソフトウェアコンポーネントの分離
    ・事例検討
    16:10~16:30 リスクコントロールの維持
    16:30~17:00 質疑応答

    プログラムを見てもらえば分かるように、リスク分析とリスクコントロールの方法に注力を注いだ構成になっている。FMEAやFTAは古くからあるリスク分析手法で、教科書も日科技連から出ていて、セミナも定期的に行われている。ただ、改めて教科書となっている本を眺めていると、事例が古いのと、ソフトウェアのことが考慮されていない。

    これらの教科書が書かれた時代から、すでに40年近く経過している。時の流れとともに、商品はソフトウェアへの依存度が高くなり、その構造自体もかなり変わってきた。

    例えば、これはFMEA/FTAの教科書に載っているガス暖房システムのブロック図だ。昔のシステムはハードウェアコンポーネントが独立したブロックになっていて、ブロック図の四角と実際のコンポーネントが一致していた。

    だから、FMEAを実施する前に作成する信頼性ブロック図の各ブロックはそれぞれ独立性が高かった。別な言い方をするとブロックで書かれたコンポーネントの凝集度は高く、他のコンポーネントとの結合度は低い設計になっていたということだ。

    しかし、システムの制御の大半をソフトウェアが担うことになって、信頼性ブロック図で書かれたコンポーネントと現実のハードウェア、ソフトウェアのコンポーネントは一致しなくなった。

    また、ソフトウェアコンポーネント同士は密接に結合するようになり、どことどこがくっついているのか、どこがどこに影響を与えるのかどんどん見えにくくなってきている。

    システム構造の変化が激しく起こったため、FMEAやFTAなどのリスク分析の手法も時代に合わせて使い方を変える必要がでてきた。6/7のセミナでそれを解説したいと思う。

    また、これだけソフトウェアの規模が拡大し、複雑化した今日において、システムを構成するすべてのソフトウェア部品の信頼性を高めようとするアプローチは効果が薄く、苦労する割には得るものが小さい。

    安全設計の方法(日経ものづくり 2010年8月号 の特集記事『ソフトが揺さぶる製品安全』参考)
    現在のソフトウェアシステムのセーフティを実現するための考え方は全体最適の発想が必要である。それを表したのがこの図である。

    フォールト・アボイダンスは個別最適の発想であり、大規模ソフトウェアシステムの安全性はそのやり方では確保できない。

    全体最適の手法としてフェール・セーフ、フォールト・トレランス、エラー・プルーフといった考え方をシステムの設計者は常に考慮しなければいけない。

    また、ソフトウェアによってシステムは格段にユーザーインタフェースが向上した。UIが向上した一方で、オペレーションが複雑になり、ユーザーが誤った使い方をすることでリスクを生むようになった。このため、ソフトウェア搭載機器の危険を避けるためのユーザビリティエンジニアリングは重要性が増している。

    セミナでは、これらのリスクコントロール手段についても解説をしたいと思っている。正式なアナウンスは SESSAME のホームページでの掲載を待っていただきたいが、興味のある方は自動車ドメインの技術者だけでなく、さまざまな産業のソフトウェアエンジニア、ハードウェアエンジニア、品質保証担当に参加して欲しいと思っている。