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年に起こったトヨタの急加速事故に関するトンデモ検証記事だ。
なお、この出来事に関するマツダの第一報はこちら。(PDF)
最近はやりの自動ブレーキには種類がある。
CX-5 の試乗会で起こった事故の原因は調査中ということだが、自分は単純に 時速 30km 以上で障害物に突っ込んでしまったのだろうと思っている。時速 30km 以上では効かないということを一瞬忘れたディーラーの販売員と血気盛んな運転手がおそるおそるではなくガーンとマットにぶち当たりにいったシーンが目に浮かぶ。
さて、下記のようにどのメーカのCMでも安全機能を売りにさんざん宣伝した後、注意表記が読むまもなく一瞬取って付けたように言い訳がましく一瞬表示され消える。
でも、どのCMもそれぞれの会社のWEBサイトで動画で見られるようになっているので、その部分だけボーズして画面キャプチャすればこのようにじっくり読むことができる。
仮に今回の事故が時速 30km 以上で走っていてブレーキを踏まずに障害物に突っ込んでいって自動ブレーキが効かなかったのなら、それは「i-ACTIVSENSE に搭載されているセンサーは、反射しにくい対象物、天候状況、速度状況、道路状況などの条件によって適切に作動しない場合がありますので、あらゆる状況での事故を回避するものではございません。これらの安全技術だけに頼った運転は行わず、安全運転を心掛けてください。」の注意書きの速度状況によって適切に動作しない場合に当たるのだと思う。
ただ、上記の注意書きの書きぶりだと、速度の条件はセンサーの性能限界のように読み取れるが、自分はそうではなくて明確に時速 30km 以上では自動ブレーキを動作させない制御をしていたのではないかと考える。
もしそうなら、時速29kmでは自動ブレーキは作動し、時速31km なら作動しない。このような Crisp な1か0かの設定が、人間のアナログ的な感覚に合わないということはよくある。
何はともあれ、ここで声を大にしていいたいのは、自動車業界は安全を売りにするなということだ。(【ISO 26262との向き合い方 (16) 安全を売りにすることの意味】参照)
なぜか。それは安全には絶対的な安全というものはなく、相対的な概念だからである。だから、安全機能に絶対大丈夫はない。だから、安全機能の提供者は上記のような Excuse(言い訳)を示す。でも言い訳を書くことでは、残留リスクは許容されないのだ。
※マツダのプリクラッシュセーフティ技術の解説(これによると、プリクラッシュセーフティには3種類あって、低速で作動するスマートシティブレーキサポートとAT誤発進制御とスマートブレーキサポートで、CX-5 には中・高速で動作するミリ波レーダー式のスマートブレーキサポートは搭載されていない。そんなのユーザーはわかんないよ。)
セーフティ(安全)の定義
それを平気でやってしまうのは、事故と正面から向き合っていないからだ。または、事故と正面から向き合う品質保証部門と、販売が増えればよいと考えキャンペーンを打つ販売部門が分かれていて、会社のトップマネジメントが販売増の方にしか目がいっていないとチェックが効かずに安全を売りにするCMが世に出て行く。
そういう会社は記者会見でユーザやマスコミに頭を下げなければいけない事件が起こったときにはじめて、安全を売りにしたことを後悔し、反省する。
販売部門が計画を達成したいばかりに、売りにつながる要素を宣伝したがる気持ちも分からないではない。
しかし、安全機能は慎ましく、黙ってしっかり実装し、その評価は自ら宣伝するのではなく、お客さんから「あれがあって助かったよ」と言ってもらうものだと思っている。それが侍エンジニアというものだ。
自動車業界も今まではそうしていたじゃないかと思う。アクティブ・セーフティとしての機能、例えばABSを前面に出して宣伝していただろうか、そんなことはなかった。当たり前品質はどういったものかを日本の企業は分かっていた。
プリクラッシュ・セーフティに関しては、誰かが最初に安全を売りにしてしまい、それを横目で見ていた者達が「乗り遅れるな」と一斉にマネをしてしまったのだ。
まじめな話、自動車業界は プリクラッシュ・セーフティ・システムに対するリスク分析を早くやり、コストとのトレードオフについて、企業横断的に議論をした方がよい。
ようするにプリクラッシュ・セーフティという安全機能に対して、コストダウンを優先した結果、センサを赤外線に絞ったことで、どんなリスクが残留するのかを分析し、どういった場合にそのリスクは許容できて、どういったときの許容できないのかを検討するのだ。(議論する内容はコストダウンの要素だけでなく、さまざまな新しく経験したことのない Hazardous Situation があるだろう)
医療機器業界で長年リスク分析を行ってきた者としてアドバイスすると、コストダウンによって性能が低下した場合のリスクコントロール手段は、多くの場合表記上の対策となる。
表記上の対策とは機器のオペレータに対して注意表記をすることで、残留リスクが具現化するのを防ぐ対策の一つだ。機器へのラベリングや画面表示、取扱説明書での注意表記がそれに相当する。
ところが、自動車は取扱説明書は見ないでも使えることが通例になってしまっている。この場合、自動車を使い始めるときに契約書でガチガチの縛りをかけない限り、使用者が当たり前だと考えていること、当たり前だと認識されてもしかたがないことに関しては、自動車メーカーが保証をしなければいけなくなる。
自分は自動ブレーキが時速 30km 以下でないと作動しないという情報をどこかで見ていたような気がするが、あれだけ毎日、自動ブレーキの効果をCMで見せられるとすっかりそのことは忘れて、どんなにスピードを出していても作動するというイメージに自然とすり替わっていた。
そういったイメージを植え付けておいて、自動車を売り渡すときにユーザーに契約書、誓約書も交わしていないのだとしたら、事故が起こったときのことを考えずに突っ走っているとか考えられない。
リスク分析・設計の考え方や方法論についてはこちらを参考にして欲しい。
もういちど言う「安全は売りにするな!」「安全機能は慎ましく、黙ってしっかり実装し、効果はお客さんから評価してもらえ!」
21世紀になっても Fault Avoidance のみを求める愚かさ。
このような Systematic Failure を数百万行クラスのソフトウェアシステムでゼロにすることなど不可能であることは、現場のソフトウェアエンジニアならみな分かっているし、ハードウェアエンジニアでも組織の上位層でもゼロにしたいがなかなかそうできないことが分かっている。
「欠陥が生じることは許されない」という考え方は下記の図の、Fault Avoidance すなわち、個々の構成要素の信頼性を高めることで安全性を確保しようとする設計思想であり、Specific Optimaization すなわち個別最適の発想だ。
フォールト・アボイダンス
個々の構成要素の信頼性を高めることで安全性を確保しようとする設計(構成要素の故障やバグを認めない)
ナンシー・レブソンの言葉
マツダの安全装備の体感試乗会で起きた「CX-5」の事故
【Car Watch NEWS より】マツダは11月12日、埼玉県内でマツダオートザム店を展開する坂田自動車工業が開催した安全装備の体感試乗会で、11月10日に発生した人身事故についての第一報を発表した。
埼玉県深谷市の坂田自動車工業 駐車場内で発生した今回の事故では、「CX-5」に装備されている「スマート・シティ・ブレーキ・アシスト(SCBS)」の機能を体感するイベントのなかで参加者が運転する車両がフェンスに衝突。車内にいた参加者と販売店従業員の2人が負傷し、参加者が頚椎捻挫(軽傷)、販売店従業員が右腕骨折(重傷)となっている。
SCBSは近赤外線レーザーで前方の車両を検知し、ドライバーの操作に応じてブレーキをサポートするシステム。障害物の大きさや種類、周辺環境、車速、ドライバーの運転操作によって正常に作動しない場合があるとしており、マツダではSCBSの体感試乗会を開催するにあたって、上記の項目を考慮し、一定の条件を設定してその条件下で実施するよう全国の販売店に案内している。
今回の坂田自動車工業による体感試乗会がマツダの案内する条件に沿って実施されたか否かを確認中で、事故に至った原因や状況などについても含めて警察による調査で明らかになると考えているとのこと。一刻も早い原因究明と再発防止に向け、坂田自動車工業とともに警察の調査に全面的に協力するとしている。なお、SCBSに起因する公道での事故発生についてはこれまで報告がないとの発表だ。
また、今回の事故原因が判明して対応が決まるまで、安全装備の体感試乗会は自粛するとしている。【参照終わり】
なお、この出来事に関するマツダの第一報はこちら。(PDF)
最近はやりの自動ブレーキには種類がある。
- 赤外線式
- ミリ波レーダー式
- カメラ式
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も不利な証拠として採用されると思っている。
最近、自動ブレーキを売りにしている自動車会社は、安全機能を売りにすることの恐ろしさが分かっていない。安全には絶対はないのだから、安全を過信するのようなイメージをユーザに植え付けることは絶対にやってはいけないのだ。(トヨタはやっていないと思う)
そういう会社は記者会見でユーザやマスコミに頭を下げなければいけない事件が起こったときにはじめて、安全を売りにしたことを後悔し、反省する。
販売部門が計画を達成したいばかりに、売りにつながる要素を宣伝したがる気持ちも分からないではない。
しかし、安全機能は慎ましく、黙ってしっかり実装し、その評価は自ら宣伝するのではなく、お客さんから「あれがあって助かったよ」と言ってもらうものだと思っている。それが侍エンジニアというものだ。
自動車業界も今まではそうしていたじゃないかと思う。アクティブ・セーフティとしての機能、例えばABSを前面に出して宣伝していただろうか、そんなことはなかった。当たり前品質はどういったものかを日本の企業は分かっていた。
プリクラッシュ・セーフティに関しては、誰かが最初に安全を売りにしてしまい、それを横目で見ていた者達が「乗り遅れるな」と一斉にマネをしてしまったのだ。
まじめな話、自動車業界は プリクラッシュ・セーフティ・システムに対するリスク分析を早くやり、コストとのトレードオフについて、企業横断的に議論をした方がよい。
ようするにプリクラッシュ・セーフティという安全機能に対して、コストダウンを優先した結果、センサを赤外線に絞ったことで、どんなリスクが残留するのかを分析し、どういった場合にそのリスクは許容できて、どういったときの許容できないのかを検討するのだ。(議論する内容はコストダウンの要素だけでなく、さまざまな新しく経験したことのない Hazardous Situation があるだろう)
医療機器業界で長年リスク分析を行ってきた者としてアドバイスすると、コストダウンによって性能が低下した場合のリスクコントロール手段は、多くの場合表記上の対策となる。
表記上の対策とは機器のオペレータに対して注意表記をすることで、残留リスクが具現化するのを防ぐ対策の一つだ。機器へのラベリングや画面表示、取扱説明書での注意表記がそれに相当する。
ところが、自動車は取扱説明書は見ないでも使えることが通例になってしまっている。この場合、自動車を使い始めるときに契約書でガチガチの縛りをかけない限り、使用者が当たり前だと考えていること、当たり前だと認識されてもしかたがないことに関しては、自動車メーカーが保証をしなければいけなくなる。
自分は自動ブレーキが時速 30km 以下でないと作動しないという情報をどこかで見ていたような気がするが、あれだけ毎日、自動ブレーキの効果をCMで見せられるとすっかりそのことは忘れて、どんなにスピードを出していても作動するというイメージに自然とすり替わっていた。
そういったイメージを植え付けておいて、自動車を売り渡すときにユーザーに契約書、誓約書も交わしていないのだとしたら、事故が起こったときのことを考えずに突っ走っているとか考えられない。
リスク分析・設計の考え方や方法論についてはこちらを参考にして欲しい。
もういちど言う「安全は売りにするな!」「安全機能は慎ましく、黙ってしっかり実装し、効果はお客さんから評価してもらえ!」
2007年に起こったトヨタの急加速事故に関するトンデモ検証記事
次はトンデモ記事の話題。
何はともあれ、まずは、EE Times Japan の『トヨタの急加速事故は欠陥だらけのファームウェアが原因?――原告側調査の詳細』の記事を読んでみて欲しい。
自分はひさびさに安全を食いものにしているひどい記事を見た。もとの情報提供者の Barr GroupのCTO Michael Barr 氏は、とんでもないひどいヤツだ。開発者やコンサルタントとしての優れた実績を誇る他、大学教授や編集者、ブロガー、著者として活躍した経歴も持つらしいが、この記事はひどいし、安全の実現にこんな経歴は関係ないんだなと思った。そう考える理由はこれだ。
- 安全を楯に正義面しているが安全を保証したことなどない単なる評論家だ。
- 安全が絶対的な概念ではなく相対的な概念であることを理解していない。
- ソフトウェア品質とシステムの安全をごっちゃにしている。
高い性能が要求され、特に安全性が最重要視される場合、設計やコーディング、試験に関する評価・基準は最も重要な課題となる。欠陥が生じることは決して許されず、確実な安全性が求められる。この記事の冒頭にこう書いてある。一見正しいように見えるが間違っている。ソフトウェアが起因の欠陥は 決定論的故障 (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 でのコード表記がシステム安全の条件のような書き方をしているが、それは違う。人間は機械ではない。ソフトウェアを一行一行書いているのは突き詰めれば一人のエンジニアだ。人間はそんなに簡単な生き物ではない。行為は同じでも、動機が間違っていれば効果は現れない。
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年、医療用加速器の使用において重大が放射線事故がなかったことで安全であると思い込んでしまった。
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,1ページのアブストラクトを書くときも必死だったが、上記のメールが来たときはうれしかった反面、9/27 までに10日間で論文を提出しないといけないというプレッシャーがキツかった。
MedSRDR 2013 Program Committee
今回はワークショップなので、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)
登録:
投稿 (Atom)