2018-06-18

エンジニア社会主義 日本

技術系の新人向けにC言語の研修を外部講師を頼んでやっているのだけれど、ふと、これって海外の企業なら「C言語でプログラムを書ける人」とか「○○のスキルを持っている人」といった採用条件で人材を募集するんだろうなと思った。

プログラミングをほとんどやったことない人材を企業で教育してソフトウェア開発にアサインするなんてことやっているのは日本だけじゃないかと思う。

実際、LinkedIn に自分のスキルや実績を書いておくと、たまに海外の会社のリクルーターからコンタクトがくる。海外の企業はリクルータと契約していて開発に必要なスキルを持つ人材を常に探しているように見える。実際,海外の企業ではクビになる可能性も高いから転職の市場もそこそこ大きいのだろう。

日本の企業って、どうして商品開発に必要な知識やスキルがほとんどない状態の人材を採用して、自前で教育するスタイルをずっと昔から変えないのだろうと思う。たぶん,これまでは専門的なスキルを持っていない新卒生を採用して,企業内で長い時間かけてOJTで育てるという育成方法がよい結果を生んできたのだろう。

しかし,今となっては,また,特にソフトウェア技術者の採用としてはそのスタイルにはデメリットも出てきたと思う。

日本の企業の人材採用に関する歴史的な背景としては,企業側は技術者教育に金がかかりしばらくは即戦力にはならないが、ある程度年月が経つと、会社の言うことをよく聞く汎用的で一定の給料で使い倒すことのできる技術者を確保できる点でメリットがあったし,日本の新卒生は勤勉で我慢強い気質を持ち、不足している技術、スキルはある程度自前で習得できるポテンシャルはあるので使い勝手はいいのだろう。

企業内で技術者が成長する過程で、技術、スキルの差は出来てくる。でも日本では、そこに給与の差を付けることなく年功序列の給与体系で技術者を使えるので、製品開発における人件費の総額を技術的な実現可能性の難易度は無視しても,人月勘定で見積もることができる。不足する人的リソースはソフトウェア系の外部協力会社を使ってこれも人月勘定で補えばよい。でも,このやり方はそろろそ無理が出てきたように思える。

技術者サイドから見ると、日本の採用スタイルなら簡単にクビにされることはない(今の時代はどうなのかなあ)ので、安心して働けるが、その反面,技術やスキルが秀でていたとしても、その能力が平均的なサラリーの2倍とか3倍とかにはならない。古典的な日本の企業では技術的な優越がサラリーや待遇で評価されることはあまりない。(外資系とか最近のIT企業は違うのかもしれない)

この日本的採用スタイルの最大の問題は、その組織に足らない技術やスキルがあったときに、それを自前の技術者が習得するには時間と費用がかかる、あるいは、外部からその技術やスキルを持ってくるのにコストがかかるということについて組織の上位の人達がピンと来ないことではないだろうか。

足らない技術やスキルがあると、自前の技術者に「習得しろ」と命令すれば、何とかなるもしくは,足らない技術やスキルを外から「人を含めて外から買う」という概念はないのかもしれない。それは今の経営層が「自分はそうやって製品開発を成功させてきた」という成功体験があるからだろう。昔と今で、必要な技術やスキルの質や量の差を理解していない。

これだけ製品のソフトウェアが大規模、複雑化し、機器がネットワークでつながるようになると、システムを実現するのに必要な技術、スキルは多様化し、それらを全部自前で習得するのは難しい。

だから、必要に応じて技術そのものを外部からパッケージで買ったり、技術やスキルを持った人材を「買う」必要がある。でも、技術やスキルを「買う」ということに慣れていないし、そのための予算も取っていない。

その代わり一人月いくらで何人月ぶんならこの開発に使ってもいいという、人月勘定の予算の取り方はする。技術やスキルによって、必要な予算が異なるという感覚は乏しい。

その結果、製品開発を成功させるためには、不足するスキルを短期間に習得できるポテンシャルの高い人材がオーバーワークになりながら頑張るという状況に陥る。そして、優秀な人材であればあるほど、抱える仕事量が多くなり疲弊し,職場のモチベーションが下がっていく。

ものつくりのエンジニアにとって日本は社会主義国家のようだ。がんばっても、がんばらなくてもサラリーはあまり変わらない。日本で高度プロフェッショナル制度が広まるとさらに、日本のエンジニア社会主義がさらに加速するような気がする。

エンジニア社会主義は安心して働けるし、企業が技術者を教育してくれるのでいい面もあったが、技術が多様化して分業しなければシステムを開発しきれなくなってきた現在では、デメリットの方が大きくなってきたように思う。

簡単にクビにならない環境は確かに何者にも代えがたいメリットのように思える。でも,ビズリーチのような企業が売り上げを伸ばしているのならば,人材がプールされあちこちの企業でスキルを買って不足を補うような市場は日本でも醸成されつつあるのだろう。

もしも,一度採用した人材を使い続けるのが日本の企業のスタイルというのならば,これだけ製品開発に必要な技術が多様化した今日では,企業はその技術を習得させるための予算を通常の開発費とは別に予算計上する必要があると思う。見積りしにくいだろうが,その予算がないと結局は開発が遅延したり,失敗プロジェクトになったりする。

そして,日本の企業が技術者を雇用し続けるスタイルを貫くのならば,新しい技術を教えられる人材を確保し,その能力を評価するようにするべきだと思う。ようするに教えられる人材,特にその企業のコアコンピタンス(競合他社に真似できない核となる能力)を身につけさせることができる人材や,新しい技術を教える教育コンテンツや教えられる人材を積極的に確保し逃さないようにするべきだ。

日本の企業は,何でもOTJで伝承するのが職人としての美徳のような感覚があるようだが,システマティックにトレーニングして,できるようになったかどうかをテストして,資格を与えるといったことを組織的にやっていかないと,必要なスキルが見えず,知らぬ間に企業の技術力がほとんどなくなっていたということになりかねない。

エンジニアサイドからすれば,個人商店として自立できるくらいの技術力を身につけるようにし,組織サイドからすれば,製品開発に必要な技術やスキルを整理し,技術を身につけさせるスキームやトレーナーの人材を確保する。これをやらないと,次の世代の製品開発は立ちゆかないのではないか。

ソフトウェアプロジェクトを組織するときに○○のスキルを持った人を何人、△△のスキルを持った人を何人といった集め方をするか,○○のスキルや△△のスキルを教育するのに□□万円の予算を確保するといった形にしないと作りたい物が作れない時代になってきたのではないだろうか。

2018-04-13

ウーバーの自動運転事故について考える

2018年3月18日に米ライドシェアサービス大手のウーバー・テクノロジーズの自動運転車が、米アリゾナ州フェニックス近郊で試験運転中に起こした死亡事故のことは多くの人がすでにニュースで見たと思う。

ただ,なぜ,この事故が起こったのかという原因については,まだ十分な分析の結果が報道されていないようだ。

ただ,その中でも,Engajet の『自動運転Uberの死亡事故はLiDARの削減が原因か。高い車高も死角拡大の可能性』の記事は参考になった。

【『自動運転Uberの死亡事故はLiDARの削減が原因か。高い車高も死角拡大の可能性』より引用】

Uberの自動運転車が歩行者を検知できなかった原因について、ReuterはUberの自動運転車が搭載するLiDARの死角について報告しています。
2016年、Uberは自動運転のベース車両をセダン車のフォード・フュージョンからSUVのボルボXC90へと変更しました。このときLiDAR 7基、レーダー 7基、カメラ 20台で構成される自動運転システム用のセンサー群もLiDAR 1基、レーダー 7基、カメラ 7台へと大幅に変更されました。

自動運転車は、LiDARが発するレーザーパルスの反射、さらにレーダー、カメラによる視覚的(可視光)によって路上にある障害物を検知し、衝突を避けます。しかし、新しいUberの自動運転車は、以前のモデルが7つ搭載していたLiDARをルーフ上に1つしか搭載していません。

カーネギー・メロン大学交通センターで自動運転技術を10年以上にわたって研究してきたRaj Rajkumar氏は、現在のUberの自動運転車は、センサーの視野的に歩行者を完全に捉えられなくなっていると指摘します。

Uberの自動運転車が搭載するVelodyne製のLiDARセンサーは、その外観から1台でも360度周囲を完全に監視できるように見えます。ところが、VelodyneによるとLiDARは垂直方向の検出範囲が狭く、SUVのように車高の高いクルマのルーフ上ひとつだけでは車両周囲に約3mの死角ができてしまうとのこと。特に地面に近い高さ、たとえば歩行者の足元や自転車の車輪、小動物などの検出が難しくなります。

【引用終わり】

事故は夜起きたので,人と自転車が暗闇にいたときにはカメラでは関知することはできず,LiDAR と レーダー が障害物検知の頼りだったと思われる。ただし,Uber が自動運転のベース車両をセダンのフォード・フュージョンからSUVのボルボXC90 に変更した際に,LiDAR(英語:Light Detection and Ranging、Laser Imaging Detection and Ranging、「光検出と測距」ないし「レーザー画像検出と測距」)は7基から1基に削減されている。また,SUVの車高の高い車ではLiDARに死角があったのかもしれない。

今回のUberの自動運転車の事故の原因はソフトウェアではないかもしれないが,クリティカルなシステムに使用されているソフトウェアの安全は,このようなインシデントやアクシデントの再発を防止するスキームの中で成熟させていくべきものではないかと思う。

そう考えるときに,いつも引っ掛かるのが機能安全(きのうあんぜん、英: functional safety)ということば(概念)だ。

Wikipedia から引用すると機能安全の説明は次のようになる。

Wikipedia 機能安全 から引用】

機能安全(きのうあんぜん、英: functional safety)は「監視装置や防護装置などの付加機能によるリスク低減策」であり、安全方策(安全を確保する為の考え方)の1つである。人間、財産、環境などに危害を及ぼすリスクを、機能や装置の働きにより、許容可能なまでに低減する一つのやり方である。JIS C 0508(IEC 61508)は「被制御機器(EUC)及び被制御機器制御系の全体に関する安全のうち、電気・電子・プログラマブル電子安全関連系及び他のリスク軽減措置の正常な機能に依存する部分」と定義している。自動車の機能安全規格ISO 26262は、機能安全の対象を「電気電子(E/E)システムの機能不全のふるまい」 に限定している。→#自動車の機能安全

電気・電子・プログラマブル電子(Electrical・Electronic・Programmable Electronic)は、E/E/PE(またはE/E/PES)という略号を使用している。

機能安全は、本質安全という考え方と対比して説明される事ある。例えば踏切では、列車と道路を通行する車輌等との事故の危険がある。これを踏切に警報機や遮断機を設置して事故を防ぐのが機能安全である。これに対して,立体交差を設置することより危険を回避することが本質安全と言える。※1

安全を確保する為に交差しないというのが本質安全に基づいた考え方である。立体交差にするというのは、事故の原因が少なくなるので、機能安全の考え方を適用したものと言える。立体交差で鉄道が上か自動車道が上かで、物の落下や柵のつけ方によって事故の被害の大きさが変動することからも立体交差が本質安全ではないことが分かる。踏切に警報機や遮断機を設置するというのも、事故の可能性は無くなりはしないが、これらの機能や装置の働きにより、許容可能なまでに危険を低減できるので、機能安全の考え方を適用したものと言える。

※1 取り消し線部分は Wikipedia からの引用そのものであるが,解釈が誤っているという指摘があったので本ブログでは青字に修正した。

【引用終わり】

一方で,ISO/IEC Guide 51:1999(Safety aspects — Guidelines for their inclusion in
standards, 安全側面ーー規格への導入指針JIS Z8051)では,セーフティ(安全)を次のように説明している。
 セーフティ(安全)とは,〔ISO/IEC GUIDE 51:1999〕※1 によれば,『受容できないリスクがないこと』と定義される。すなわち,セーフティ(安全)は受け入れ不可能なリスクから解放されていることであり「受容できないリスクがない」または「許容可能リスク」が達成されていることをもって「安全」と規定される。
 安全はリスクを経由して定義され,リスクはその時代,社会の情勢,環境によっても変化するため安全の尺度を一定にすることはできず,絶対的な安全を定義することはできない。そのため,製品,プロセスまたはサービスは相対的に安全であるとしか言えない。
安全は,リスクを許容可能なレベルまで低減させることで達成される。許容可能なリスクは,使用者の利便性,目的適合性,費用対効果,並びに関連社会の慣習のように諸要因とのバランスで決定される。したがって,許容可能なリスクは常に見直す必要がある。技術及び知識の両面の開発が進み,製品,プロセスまたはサービスの使用と両立して,最小リスクを達成できるような改善が経済的に実現可能になったときは,特に見直しが必要である。
※この説明文は ISO/IEC Guide 51の2014年の改訂でなくなってしまったのだが,安全(セーフティ)を説明するための文章として優れていると思い,今でも引用している。

この説明を分かりやすく4つにまとめると次のようになる。

セーフティ(安全)とは
  1. セーフティ(安全)とは「受容できないリスクがないこと」である。
  2. 絶対的な安全を定義することはできない。安全は相対的な概念である。
  3. リスクが許容可能かどうかは「使用者の利便性」「目的適合性」「費用対効果」など諸要因のバランスで決定される。
  4. 世の中の技術開発が進んだら、リスクの許容可能性の見直しが必要である。
安全は相対的な概念であり,リスクが許容可能かどうかは諸要因のバランスで決定される。この部分が非常に重要だ。

Uber の自動運転システムの事故の場合,LiDAR 7基、レーダー 7基、カメラ 20台 の自動運転車を LiDAR 1基、レーダー 7基、カメラ 7台 の自動運転車に変更したことで,リスクの要因が変わったのかもしれない。この変更が経済的な要因を優先させたのだとすれば,それがトリガーとなって事故が起こったのかもしれない。

セーフティ(安全)は,意図する使用(Intended Use)を定義し,その使用環境から想定されるリスクを分析し,リスクを低減するための対策を立案し,検証し,妥当性を確認する

しかし,安全は相対的で諸要因のバランスで成り立っているので,システムの変更は相対的な安全を崩してしまう危険性がある。ソフトウェアの場合であれば,ソフトウェアのちょっとした変更が安全を実現しているリスクコントロール手段に影響を与え,安全アーキテクチャを崩してしまうかもしれない。

ソフトウェアのよる安全監視や安全装置が意図した動きをしないかどうかの確認は,異常状態を作り出さないと分からないこともあるだろう。だから,クリティカルシステムに対してアジャイルなソフトウェア開発,ソフトウェア変更を行う際には,安全アーキテクチャが崩れていないことを常に確認する必要がある。

さて,仮にUber の自動運転システムの事故がLiDAR を7基から1基に減らしたことにより,死角ができたのだとしたら,どのようにすれば事故は防げるだろうか。

それは,日中,夜間の環境条件で,障害物を感知する範囲を特定し,自動車の上限スピードで障害物を感知してから,障害物との衝突を回避するまでの時間を割り出し,それを実現するためのハード,ソフトの要件を定義する。障害物が止まっているとは限らないので,さまざまな条件を考慮しないといけない。

このように「障害物を検知し,自動で衝突を回避する」という要求に対して,ハード,ソフトの条件を出し,設計仕様に落とし,検証とバリデーションを行い,それらがトレースできているかどうか確認する,これを要求ごとに行っていく。

インシデントやアクシデントが発生した場合は,この流れのどこに問題があったのかを分析し,それをフィードバックする。これを積み重ねていくことで,相対的な安全を確保していく。

このようなシステム全体のリスクマネジメントのアプローチにより,システムに責任を持つ者がリスク低減のために必要な要件を定めて,リスクがコントロールされていることを確認し続けていれば,ハードウェアやソフトウェアの変更により,知らぬ間にリスクが許容できなくなっていること(ソフトウェアの場合ならデグレード)が起こっていないことを保証することができる。

しかし,機能安全(きのうあんぜん、英: functional safety)が「監視装置や防護装置などの付加機能によるリスク低減策」であり、安全方策(安全を確保する為の考え方)の1つであり,機能安全が個々のユニットの安全機能を積み重ねるボトムアップアプローチであるのなら,個々の部品単位で安全機能を搭載したものをアセンブリしたときに,システム全体が安全かどうかは分わかるだろうか。

なぜそう考えるかというと,ユニットの安全機能は,システム全体の安全から来た要求とは限らないと思うからだ。自動車部品の安全機能として,異常監視や冗長性の機能をよく見受けるが,それらの安全機能は例えば,障害物を検知して自動ブレーキをかけるという要求に対する直接的なリスクコントロール手段になっていない。別な言い方とすると,インシデントの再発防止のための取り組みではないということだ。意図する使用(Intended Use)から展開されていない安全機能は,どんなリスクにも効果があると考えて設計されていると思うが,そんな魔法の杖は存在しないし,ハードウェアやソフトウェアを組み合わせて作った複雑なシステムにおいては,特に有効でないケースも出てくる。

自動車の安全について,自動車メーカーがリスクを分析し,その観点から,サプライヤーに要求を突きつけるのは分かる。しかし,サプライヤーが機能安全への適合を自動車会社に上申して,その自動車が安全であると主張するのは,どうしても納得がいかない。

Uber の自動運転の事故は,ハードウェアとソフトウェアを組合せたシステムとしての事故として,原因分析する必要があるのではないか。

個々の部品の不良が原因となるというシチュエーションは1960年代のゼロディフェクトの考え方であり,個々の部品の信頼性を高めてシステムの安全を担保するという考え方は,21世紀の大規模複雑化したシステムでは成り立たない。

システムの複雑化による複合要因での事故は非常に多くなった。従って今回のような事故の再発防止は,システムを統合してユーザーに提供する自動車会社が旗を振って,根本原因を調査し,再発防止策を継承していく必要がある。

事故が起こるたびに,犯人捜しをしてサプライヤーの責任を追及しても,事故の再発防止にはつながらない。現代の事故は,そういった部品単位で起こるのではなく,複合要因で発生することの方が多いからだ。

複合要因で発生する事故に対しては,システムとしてトップダウンアプローチで,リスクコントロールを行う必要がある。その時の旗振りは 顧客に対してシステムの安全を保証する者でなければならない。それは,自動車の場合サプライヤーではなく,自動車メーカーだと思うのだ。

「安全を機能(ファンクション)で確保できると考えていると,複合要因の事故はなくならないぞ」と言いたい。

P.S.

その後、米運輸安全委員会(NTSB)が、配車アプリ大手ウーバー(Uber)の自動運転車に女性歩行者がはねられ死亡した事故に関し、衝突の6秒前に車が歩行者を検知したものの、自動緊急ブレーキ(AEB)が作動しなかったことを2018年5月24日初期調査報告書で発表した。

自動運転システムは歩行者を検知した後、衝突の1.3秒前に緊急ブレーキが必要だと判定したが、事前にウーバーの技術者らがAEBシステムが作動しないよう設定していたとも指摘している。AEBを無効にした理由は「車体に不規則な挙動が生じる可能性を下げるため」とのこと。

ようするに機器やシステムの不具合というよりは、ヒューマンエラーだったということらしい。ただし、こういったヒューマンエラーも考慮してリスクマネジメントをしなければ事故はなくならない。

バリデーション(妥当性の確認)は、ヒューマンエラーを含めた使用環境を想定して行わなければならない。部品レベルの安全対策では、システムのエラーのすべてを防止することはできない。

2018-03-18

2020年の医療機器ソフトウェアに求められる要件の予想

前回のブログ記事『ソフトウェア製品の認証は可能か?』で,医療機器では「基礎安全,基本機能,基本性能」「リスクマネジメント」「ソフトウェアライフサイクル」「ユーザビリティ」の4つについて正当性を示すことが規制当局から求められると書いた。

適合が求められる規格でこのことを表すとこの図のようになる。

専用のハードウェアにソフトウェアを搭載する医療機器の場合は,製品安全規格として IEC 60601-1 と,ソフトウェアライフサイクルプロセス規格として IEC 62304 が求められる。汎用のITプラットフォーム上で動作する医療機器ソフトウェアの場合は,製品安全規格として,IEC 82304-1と ソフトウェアライフサイクルプロセス規格 の IEC 62304 が求められる。(IEC 82304-1 は規制要件になるかどうかはまだ決まっていない)

IEC 82304-1 は 2018年3月1日に JIS T 82304-1 として日本語で参照できるようになった。この規格の目次は次のようになっている。

JIS T 82304-1 目次

  1. 目的及び適用範囲
  2. 引用規格
  3. 用語及び定義
  4. ヘルスソフトウェア製品の要求事項
  5. ヘルスソフトウェア-ソフトウェアライフサイクルプロセス
  6. ヘルスソフトウェア製品のバリデーション
  7. ヘルスソフトウェア製品の識別情報と附属文書
  8. ヘルスソフトウェア製品の市販後活動

箇条5 は IEC 62304 を参照しているので,IEC 82304-1 がソフトウェアライフサイクルプロセスの要求として IEC 62304 を呼んでいる形になっている。

ようするに,ライフサイクルプロセスの要求に加えて,製品の要求事項を明確にした上で,バリデーションの計画,実施,報告を行い,製品の識別情報や附属文書への記載内容を指定し,さらに,市販後の活動も行うことでヘルスソフトウェア製品の安全を実現しようとしている。

なお,IEC 82304-1 は規制対象と規制対象外の両方のヘルスソフトウェアを対象としているのに対し,現在の IEC 62304 Ed.1.1は規制対象の医療機器ソフトウェアのみがスコープとなっている。そこで,IEC 62304 は Ed.2 において,IEC 82304-1 と同様に,規制対象と規制対象外のヘルスソフトウェアにスコープを拡大しようとしている。

どちらの規格も製品安全やリスク低減を目的としているのだが,今や規制対象のヘルスソフトウェアだけでなく,規制に至らないヘルスソフトウェアに対しても必要な要件があるという考え方だ。

IEC 62304 Ed.2 は現在検討中であり,2000年までには策定されると予想される。そこで,2020年時点でのヘルスソフトウェアの規格体系を予想してみると次のようになる。

IEC 82304-1 は ヘルスソフトウェアのソフトウェアライフサイクルプロセス規格である IEC 62304 Ed.2 を箇条5で呼んでいる。IEC 62304 が Ed.2 になると一般要求事項として 品質マネジメント,リスクマネジメント,ユーザビリティを要求するようになると予想される。

品質マネジメントは規制対象の医療機器の場合は,ISO 13485(ISO 13485 は ISO 9001の医療機器版で文書化要求などが強化されている) を 規制対象外の場合は,ISO 9001でもよしとし,リスクマネジメントは ISO 14971 を,ユーザビリティは IEC 62366-1 で適合を示してもよいという方向性が検討されている。

ちなみに,ユーザビリティは 使いやすさを目的にしたユーザビリティではなく,ヘルスソフトウェア製品の使用に伴うリスクを特定しコントロールすつためにユーザビリティエンジニアリングを要求している。また,セキュリティに関してもヘルスソフトウェアの安全に影響する脅威を特定,評価し,対策することを求めている。

医療機器ソフトウェアについては 2020年に向けて「バリデーションを含む製品安全」「ソフトウェアライフサイクル」「品質マネジメント」「リスクマネジメント」「安全のためのユーザビリティ」「安全のためのセキュリティ」を求めることで,医療機器ソフトウェアの製品安全を確立しようとしている。

このブログで繰り返し主張しているように,ソフトウェアのプロセス要求だけで,ソフトウェアの製品安全を示すことは出来ず,いろいろな確度から安全について証明していく必要があるということだ。

セキュリティはソフトウェア製品がネットワークで他のソフトウェアとつながるようになって,また,ユーザビリティはユーザインタフェースがリッチになるに従って,使い方を間違うことで危害に至ることが増えてきたことが背景にある。

また,バリデーションやリスクマネジメントが重要視されてきたのは,システムを構成する個々のソフトウェア部品の信頼性を高めることでは,システム全体の安全性や信頼性を確保できないほど,ソフトウェアは大規模・複雑化していることを示している。

「バリデーションを含む製品安全」「ソフトウェアライフサイクル」「品質マネジメント」「リスクマネジメント」「安全のためのユーザビリティ」「安全のためのセキュリティ」ひとつひとつが規格に適合しているしていないということに着目するのではなく,そのシステムに対してどの要求がどのように安全に寄与しているのかをよく考えて,全体として安全を確かなものにするにはどこを強く抑えると効果的かを考えることが求められるようになる。

規格適合は過程であって目的ではない。このことを忘れてはいけない。