2016-07-04

テスラ社死亡事故で考える Intended Use (意図する使用)


GHS(ヘルスソフトウェア推進協議会)のリスクマネジメントトレーニング講座で,Intended Use(意図する使用)が決まっていないとリスク分析はできないと教えている。

Intended Use を決める・定義するということは,製造業者が提供する製品やサービスにおいて,誰が,何を,どのように使うことを意図しているのかを明確にすることである。

日本人の技術者は特にこれが苦手だと感じる。

その理由は,多くの日本の製造業者がすでに市場にある自社製品やライバル会社の製品の機能や性能を模倣・継承して,それらに付加価値として追加することで「売れる」製品を作ることができてしまうからではないかと考えている。

だから,日本の技術者は自分が開発に携わった製品の新たに付け足した機能や性能のことはスラスラと答えることができるのに,その製品の Intended Use (意図する使用)は何かと聞いてもバシッと答えが返ってこない。

こちらが聞いているのは,付け足した付加機能のディテールではなく,基本機能や基本性能を誰のために,何のために作ったのかを答えた欲しいのだが,そういった基本機能・基本性能は,すでに前の機種で実現してしまっていて,再利用するだけなので,付け足し機能しか担当していない技術者の頭の中に残らないのだろう。

しかし,製品やサービスの基本機能や基本性能が故障したり不具合を起こしたりすると,とたんに大問題となる。だから,市場で不具合が発覚してリコールになったりしたときにはじめてそれが製品にとって重大な機能だったのだと気が付いたりする。

GHSのセミナーでは,Intended Use を説明するのにMobile MIM という iPad iPhone のアプリケーションソフトウェアを例示している。

このアプリケーションソフトウェアは,医療機器である画像診断装置のデータをクラウド上に格納し,その画像を iPad や iPhone で閲覧するソフトウェアだ。iPhone を持っている方は,アプリをダウンロードしてサンプル画像を無料で見ることができるので試してみるとよい。

このアプリは,2008年に 米国FDAに医療機器としての申請をしており,3年間に渡るFDAの交渉を経て,医療機器と認められている。

この経緯はアプリのようこその Mobile MIMのストーリーに書いてあるので,読んで見ると面白い。

そして,ユーザーガイドの配下に左記の使用目的が書いてある。

日本語では使用目的となっているが英語モードで表示させると Intended Use だ。

Intended Use には,「何の目的のソフトウェアであるか」「アプリが扱う医療画像は何から得たものか」がまず書かれている。

そして次が大事なのだが,このアプリは医療行為に関わることとして「放射線治療のプランを承認することに使用できる」と書いてある。

そしてさらに重要なのは,このアプリが医療機器である画像ワークステーションに取った代わるように設計していないことと,画像ワークステーションへのアクセスができないときにのみ使用すべきと明示している。

そういった場合であってもマンモグラフィには使用できないと明確に書いている。

ようするに Intended Use を定義した上で,でできることと,できないことをはっきりと書いているのだ。

このような書きぶりは,海外の医療機器では珍しくない。海外の医療機器ではIntended Useの中で,できることと出来ないことがはっきりと書かれている。

米国で特にそういう書きぶりになるのは,できることと出来ないことを明確にしておかないと,その製品で事故が起こったときに,製造業者側の責任分解点が曖昧になるからである。

なお,訴訟対策という意味以外でも,冒頭に書いたように Intended Use が明確になっていないとリスク分析ができない。

Mobile MIM に関して言えば,「放射線治療のプランを承認する」目的での使用は意図しているので,その目的に際して,間違った判定にならないようにリスク分析を行い対策しておく責務が製造業者側に生まれる。

おそらくそのためであろう。このアプリは自然光が強い場所では使えないように,医療用途で使用する場合には,少しだけコントラストを変えたエリアをランダムに表示させて,そこをポイントできないと先に進めないようなくふうがされている。

これは,微妙な輝度の違いを読み取れないような環境でアプリを使うと誤診につながるので,それを回避するためのリスクコントロール手段である。想像するにFDAと何回も Intended Use と想定されるリスクについて議論した末に設定したリスクコントロール手段だと思われる。

そして,何を意図しているのかと同様に「何を意図していないのか」ことも明確に示した。これによって「製造業者が意図していないこと」をユーザーが行った場合は,誤使用となる。医療機器ドメインでは「合理的に予見可能な誤使用」は製造業者の責任でリスクコントロールをする義務があるが,Intended Use で明確に出来ないこと,意図していないことを明示している場合に,ユーザーがそれをやってしまった場合は,よっぽどのことが無い限り,製造業者の意図に反した誤った使い方となる。

日本人がこのような Intended Use を見ると,販売に悪影響がでるのではないかと思うかもしれない。しかし,組織が取扱説明書等で出来ないと書いているのに,セールスの担当者が「公式にはできないと書いてありますが,実際には多くのお客さんがこんな使い方をしていますよ」などとユーザーに耳打ちしていれば,FDAは取扱説明書上に明記された Intended Use と 医療機器の使用の実態との乖離を許さない。

さて,2016年6月30日に米テスラモーターズの「自動運転モード」作動中に初の死亡事故が起きた。(日経記事

死亡した運転手は自動運転中にポータブルDVDプレーヤーでハリーポッターのDVDを鑑賞していた可能性があるらしい。(ロイター記事

この記事の中で,下記のように書かれている。
事故車となったセダン「モデルS」の2015年モデルの運転手が道路を見ていたのかどうかという疑問は、テスラにとって重大な意味がある。同社は、オートパイロットの安全性に関して連邦当局から予備調査を受けている。  
オートパイロット搭載車は運転しなくても、車線内を走行し、スピードを維持できる。同社は1日に声明を出し、「オートパイロットは路上での最先端のドライバー支援システムだ。ただ、これにより、テスラ車が自律走行車になったり、運転車が責任を放棄できたりするわけではない」との見解を示した。  
この,「オートパイロットは路上での最先端のドライバー支援システムだ。ただ、これにより、テスラ車が自律走行車になったり、運転車が責任を放棄できたりするわけではない」というテスラモーターズの主張に思い切り突っ込みを入れたい。

テスラモーターズは オートパイロット機能による自動運転を Intended Use として意図しているのか,意図していないのかを明確にしておらず,曖昧なままにして,状況によって都合良く解釈していないかと。

ようするに,ユーザーがオートパイロットに任せきった運転をすることを想定もしくは,黙認しながら,公式には自律走行は許していないとする,2つの顔を使い分けていないかということだ。

こういうことをすると,有効なリスク分析できない。製造業者として意図していることと意図していないことが明確になっていないから,運転手がオートパイロットに運転を任せきってしまうことが,正常使用なのか,明確な誤使用なのか,それとも合理的に予見可能な誤使用なのかがはっきりしない。

自律走行を意図していないのなら,まず,「オートパイロット」で運転手が運転を任せてしまうことは禁忌・禁止として,明確に,常に意識できるようにラベリング(みえるところに表示する)必要があり,かつ,そうしてでも運転を任せきってしまうことは合理的に予見可能な誤使用としてありうると考えて,リスクコントロール手段を講じることが必要だ。

例えば,運転手の視線が前方を向いていなければ警告音を鳴らすといったリスクコントロールだ。

こういったリリスクコントロール手段にはコストがかかるから,やるやらないの判断するためには,組織として承認された Intended Use が必要になる。そこがはっきりしないと,開発の過程で組織の都合のよい解釈が成されて,リスクが残ったまま,製品が市場で使われることになる。

今一度,自動車メーカーに問いたいのは自動車メーカーは「運転手から運転を解放するため」に自動車に自動運転機能を装備しようとしているのではないのかということだ。目標は高く掲げ,社会への貢献を高らかに謳い,「やっちゃえ」と言ってユーザに期待させておきながら,事故が起きると責任は回避するという態度はいただけない。

医療機器の場合,単純化すると,製造業者が「診断」「治療」「予防」を標榜すると医療機器として規制されることになる。支援するとか,補助するとかで,誤魔化すのではなく,左記のようにビシッと線を引くことが Intended Use を定義することになる。

自動運転機能を自動車に装備する目的は「運転からの開放」なのに,事故が起こったときだけ「自動運転はあくまでも運転の補助だ」と言っていないか。上の図の例だと線が右にいったり左にいったりしていないかということだ。

「運転からの開放」か「あくまでも運転の補助かなのか」の使用目的の違いによって,リスク分析の結果や必要なリスクコントロールが変わってくる。

だからこそ,大事なのは「その機能があるかないかではなく,製造業者がどんな意図でその機能を製品に搭載したのかという意図の問題」だ。それが Intended Use を特定することだ。

そして,その機能を意図して搭載すると決めたのなら,その使用目的を想定したリスク分析を行い,リスクが受容できるまでリスクコントロール手段を講じなければいけない。

Mibile MIM の例では「放射線治療プランの承認に使用することを意図する」と決めたから,放射線治療プランを誤って承認するリスク(例えば実際には病巣があるのにないと判断して治療が遅れ病状が悪化するなど)が抽出され,リスクコントロール手段を取ることができたのだ。

Intended Use を曖昧にしていると「コントラストが確認できない状況でアプリを使わせてはいけない」というリスク分析が出てこないかったかもしれないし,コストがかかるからといわれ採用できなかったかもしれない。

自動運転に関しては,何のためにその機能を搭載するのかの Intended Use を定義しないまま,自動車業界は世の中のムードや早く実現しろというプレッシャーに押されて開発を進めていないだろうか。

一番危ないのは,サプライヤーが「その機能作れって言われたので作りました」というスタンスで部品として自動運転の機能を自動車メーカーに提供するというケースだ。

「ASIL-D として自動運転機能を仕上げましたので安心してどうぞご使用ください」というスタンスだと,Intended Use をベースにしたリスク分析やリスクコントロール手段に結び付かない。ようするに自動運転が「運転からの開放」なのか,「運転の一部肩代わり」なのか曖昧なままでは,リスク分析の結果とリスクコントロール手段が変わり,受容できないリスクが残留するいうことだ。

また,事故が起こってからリスクコントロール手段を考え直すということを繰り返していくと,付け足したリスクコントロール手段が新たなリスクを生む可能性がある。

医療機器業界は,そういった経験を繰り返した結果,機能安全(Functional Safety)とは異なる,リスクベースアプローチ(Risk Based Approach)を中心した基準を確立してきた。

自動車業界は今後,自動車運転を未来に向かって推し進めようとするならば,自動運転の Intended Use を明確に定義すべきだ。

運転支援だなどと曖昧にごまかして,事故が起こらないうちは,さんざんメリットとして宣伝に使い,いざ事故が起こったら使用者の誤使用にして責任を逃れるやり方は許されない。

これまで自動車は走る・止まる・曲がるの基本性能と付加価値となる機能の間に独立性があったが,時代が変わって,付加価値の機能と基本機能・基本性能が絡み合うようになってきたのだと思う。

医療機器の世界では,ひとつに特定しきれないさまざまな機能をもった機器があり,その使い方に絡む事故もたくさん起こっていたので,事故の再発防止のためにも Intended Use の定義とリスクマネジメントの重要性が叫ばれてきた。

自動車業界もITとの融合が本格的になってきて,Intended Use を明確にしなければ,有効なリスク分析ができず,これまでにはなかった複雑な要因の事故が多発する世界に足を踏み入れてきたのではないだろうか。

P.S.

テスラ社の事故に関して「これは運転支援システムであるから,ドライバーが運転を機械任せにしてしまったことが間違い」という識者の見解を散見するが,こういう考え方をしていると未来に発生するであろうオートパイロットの事故は減らない。オートパイロットを導入することで交通事故が減少するというメリットと天秤にかけるという考え方はあるが,それを正当化したいのなら社会的なコンセンサスを得たうえで,利用者にもリスクを理解させ,オートパイロットの使用における禁忌・禁止事項を守らせることが必要だと思う。

2016-06-04

リアルタイムOSから出発して組込みソフトエンジニアを極める【改装版】

2006年3月に出版した著書『組込みソフトエンジニアを極める』は,最初の日経BP社版が再版されず絶版となったため,エスビーアイアクセス版を2011年9月に出版した。

その後,この版が在庫切れとなり,オンデマンド印刷で少しずつ刷ろうということになったが,結局あまりコストが下がらないということで,改装版で再版することになった。

------

最初に出版してから10年経ちましたが,組込みソフトウェア開発の環境は劇的には変わっていないなあと感じています。ソフトウェアを作っているのは人間なのでそう簡単には変われないのでしょう。

表紙が少し明るい色になりました。Amazon での取り扱いも始まったので,是非ご利用ください。


2016-05-01

三菱自動車の燃費不正問題に思うこと(プレッシャーの悪影響)

三菱自動車の燃費偽装問題では、不正なデータの操作が行われた軽乗用車4車種の実際の燃費が、カタログなどに記していた公表値と大幅に異なる可能性が出ていて、5~10%ぐらいの乖離があり、大幅に異なる場合には型式指定の取消しがあるかもしれないとのことである。

eKワゴンの当初の燃費目標は2011年2月の時点で26.4km/リットルだったが、スズキが2012年9月に28.8km/リットルのワゴンRを発売すると、三菱自動車内の目標は29km/リットルに引き上げられ、ダイハツ工業が2012年の12月に売り出した「ムーヴ」の燃費が29km/リットルになるという情報が伝わると、目標は29.2km に引き上げられた。

もしも、燃費目標と根拠となるメカニズムがセットで語られていなかったのだとしたら「手段を選ばず目標を達成せよ」と命じたのと同じだと思う。直接不正を指示してはいなくても、結果的にはそうせざるを得ない所に追い込んだことになる。

三菱の軽自動車もアイドリングストップの機能は搭載していたようだが、ライバル会社はそれ以上のこと(スズキのエネチャージなど)をしているのに、新たな技術開発なくして燃費性能が上がるわけがない。

売り上げが上がらないから売れるような物を作れとか、燃費性能が負けているからそれ以上の物を作れとか、およそ技術で立脚している会社の目標とは思えないようなことを言うトップマネジメントがいるんだと思った。そんなことなら技術的背景がまったなくても言えるでしょ。

こちらの時事通信の記事によると社長は「基本的な数字を操作しているとは夢にも思わなかった。性善説に立っていた」と言い,担当部長は「何としても燃費目標を達成しろ。やり方はお前らで考えろ」と言ったそうだ。繰り返すが,技術で飯を食っている会社のマネジメント層が発する言葉とは信じられない。技術的根拠に重きを置かず,その会社のコア技術,コアコンピタンスとなる技術が何かについて知らない,知りたいと思わないなら技術に立脚した会社とは言えないと思う。

安全分析で著名なMITのナンシー・レブソン教授が、スペースシャトルコロンビアの事故をモデル化した図がこの図だ。(出典はこちら

これで注目して欲しいのは、左側の予算カットや性能に対するプレッシャーがミッション成功に対してマイナスの影響を与えているということだ。

三菱自動車の不正の件は安全への影響はなかったようだが、ユーザーの信頼を失う結果となった。技術者が伸び伸びと開発に専念できない環境、プレッシャーだけが強く、モチベーションやインセンティブがない環境が最終的には組織に損害を与えるというモデルはあると思う。

そのベースが人間の論理的でない部分から成るので、証明するのが難しいが、事故分析の分野では事故当事者にかかっていたプレッシャーを考慮に入れる例は多くある。

ダイハツ・ムーヴ “燃費チキンレース”はもうしない!』という記事もあるから、ダイハツは燃費競争がいずれ破綻することが分かっていたようだ。

この記事で注目すべきは、「もうこれ以上の燃費性能を顧客は望んでいない」というところだ。顧客は望んでいないが、ライバル会社に負けるから燃費の目標数値を上げるというところが間違いの元であり、誰のために商売しているのかを見失った時に問題は起こるということを思い知らされた。

今回のケースは顧客のためではなく自分達のために安易に燃費目標をつり上げ、結局は燃費を偽って顧客の利益に背反することをやってしまった。仮に軽自動車の競争で後塵を拝していたのだとしても、顧客のことをないがしろにする企業に明日はないと思う。多くの社員がそうではなかったとしても、ボードメンバーに顧客を気遣う気持ち(Awareness)よりも利益が先に立つ人がいると危ない。

また、三菱自動車の燃費不正の問題は、経営層が技術に立脚しないプレッシャーを社員にかけることのリスクが明白になった例であり、どの企業にもありうる教訓にしないといけないと思った。