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年を考える~の時だったと思う。「セーフティ・クリティカルな製品を開発する技術者は、安全の責任を負う必要がある。」という発言をしたところ、「人の命に関わる製品の仕事には絶対就きたくありません。」と会場にいた学生さんが言った。

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

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

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