2023-01-01

久しぶりの投稿

 

1年3ヶ月ぶりの投稿。ふと、Facebook で友人が近況を書き込んでいるのをみて、「あ、そういえばブログ更新してなかった」て気が付いた。

このブログを始めたきっかけは、自分の本を出版して読者との交流しながら情報発信したいと思っていたからだった。あと、組織内で思ったこと、感じたことをブログに書くことである意味ストレス解消していたのかもしれない。また、書くことで自分の考えを整理して伝えるスキルを高めたいという思いもあった。

20年以上、組込みソフトウェアの開発をしてきたが、技術者への支援の仕事を経て、今は、組込み機器からの情報をクラウドに上げて、ユーザにサービスを提供するソフトウェアの開発をマネジメントしている。在宅勤務が増えて仕事の取り組み方も変わって、仕事をしているときとしないときの、ON/OFFがはっきりするようになって、OFFのときは仕事の事を考えなくなった。

若い時は会社にいても家に帰ってきても抱えてる課題をどう解決しようかと考えていたが、今はスキルが高まってきたせいか、ONのときに課題解決の道筋が見えるようになってきたので、OFFのときは仕事のことはあまり考えないようになった。こういった状況の変化で、ブログの更新が滞っていたのかもしれない。

環境が変化したとはいえ、今になってもいろいろを思うところはある。ソフトウェアは複数のエンジニアが関わって作っていくものだし、事業も関係する人々とコミュニケーション取りながら進めて行くので、その中で何かしら感情がぶつかったりすることはある。そういうことがあると、ブログに自分の考えを書きたくなってくる。

最近思うのは、組織ってやっぱり蛸壺的になるもんだということだ。組織が大きくなるほど、エンドユーザとの接点がなくなり、自分のやっていることがユーザのためというよりは、組織のため、さらに自部門のため、さらに自分の利益のためになる。最近、他部門の技術者が「その機能、入れるのか入れないのかだけ、言ってください」という発言をしたので、「そうじゃないだろう、ユーザにとって必要かどうかを考えるんだろう」とたしなめたことがあった。上から言われたことだけやる仕事って面白くないようなって思う。自分が作ったものをユーザが喜んでくれることを糧に仕事ができれば、技術を吸収するスピードだって速くなる。

自分がそういう考えで35年以上働いてきて感じるのは、組織の中にいても自分は個人商店だという認識を持っていたのはよかったなということだ。

入社したてのころはスキルがなくて、とても独立してやっていくことはできなかったので、早く一人前になりたいと貪欲に技術を吸収しようと思っていた。ある程度、外の世界の人達と渡り合えるようになってからは、いつでも独立するぞという気持ちでいたつもりだ。

ただ、組織と自分のポリシーにオーバラップがある内は、多少イヤなことがあっても我慢しようと思った。実力さえ身につけることができれば、組織が方向性が自分の生き方と異なると思ったら、迷わずに外に出ようと考えることができた。個人商店として何とかやっていきそうという自信が付いてなければ、組織にかじり付くしかなかったけれど、いつでも個人商店としてやっていけるとなれば、組織に対してもそれ相当の発言ができる。

そして、組織の事業を支えるようなプロジェクトに関わるようになれば、顧客満足を高めることの実感を得ることができるようになる。

自分はエンドユーザにどのような価値が提供できるのかから始まり、それを実現するための技術は何か、その技術を習得するためにどうしたからいいかという順番で物事を考えるようにしている。

いろいろな技術者と話しをしていると、そういう思考ではなくて、このファンクションをどうやったら実現できるかから話しをはじめる人がいることに気が付く。

「組込みソフトエンジニアを極める」の著書では、技術的なこととともに、エンドユーザに提供する価値を実現する技術を身につけることの大切さを書いたつもりだ。

そういった思考をする訓練をしてきたことによって、さまざまな課題にぶつかったときに、組織内のセクショナリズムなど、エンドユーザ価値に関係がない、また逆行するような事柄は実にくだらないと考えることができるようになった。

35年以上ソフトウェアエンジニアとして働いてきて思うのは、やっぱりソフトウェアは人が作ってるので、人=技術者のことをよく理解しないと何事もうまくいかないということだ。

「組込みソフトエンジニアを極める」や「リコールを起こさないソフトウェアのつくり方」で、欧米と日本の技術者の考え方の違いについてしつこいくらい書いたのは、そこを理解しなければ開発はうまくいかないと直感していたし、実際、欧米で培われたプロセスアプローチはそのまま適用したのでは日本ではうまくいかないと実感したからだ。

ソフトウェアの面白さって、人と密接に関係しているところかもしれないと、今更ながら感じる。

2021-09-10

2021年11月1日にヘルスソフトウェア向けリスクマネジメント・トレーニング講座(オンライン)を開催します

GHS 一般社団法人ヘルスソフトウェア推進協議会は、2021年11月1日にヘルスソフトウェア向けリスクマネジメント・トレーニング講座(オンライン)を開催します。

本リスクマネジメント・トレーニング講座は、GHS 開発ガイドラインの Level-1 の要求を実践するために必要な知識、技術を習得するための講座です。一般社団法人 ヘルスソフトウェア推進協議会(GHS)は、これまで、9回に渡りトレーニング講座を開催し、のべ200名以上の参加者が ヘルスソフトウェアのリスクマネジメントに関するスキルを修了しています。

本講座は、分かり易い資料、少人数に分かれたグループワーク・グループディスカッション、経験豊富な講師やモデレータによる丁寧な指導が特長の参加者の満足度が高いセミナです。

リスクマネジメント・トレーニング講座(オンラインセミナ)プログラム

10:00~10:05 開講挨拶(トレーニング講座開講の挨拶とスケジュール確認,連絡)
10:05~10:15 テスト 受講者事前知識調査
10:15~11:00 講義1 安全(セーフティ)の考え方
11:00~11:10 アイスブレイク(Zoomのブレイクアウトルームを使ってみる)
11:10~12:00 演習1 Intended Use(意図する使用)の定義と安全面とセキュリティの特質を明確化
12:00~12:45 昼食休憩
12:45~16:25 ※途中休憩あり
                演習2 演習1 Intended Use(意図する使用)の発表
演習3 仮想ヘルスソフトウェアアプリのリスク分析演習
演習4 リスク分析結果発表(各グループ)とディスカッション
解説  分析例の解説
16:25~16:40 GHS リスクマネジメント様式集(3種)と記入例とヘルスソフトウェアのサイバーセキュリティ要求について
16:40~16:50 質疑応答
16:50~17:00 アンケート記入・提出

詳しくは、こちらをご覧下さい。

演習では仮想のヘルスソフトウェア(健康アプリ)を題材にして、危害にいたる可能性のある一連の事象、危険状態、具体的な危害をリストアップし、それらが発生する確率(可能性)と重大度を分析して対策を考えます。

個人ワークの結果を持ち寄り、他社の参加者とグループディスカッションを行うことにより、自分では気が付かなかった視点があることに気付き、演習を経験することで、持ち帰って自社製品でもリスク分析できるようになることを目指します。

※コンサルティング関係の方の参加はお断りしています。

2021-08-31

IEC 62304 準拠と謳っている RTOS が医療機器規制当局から注意喚起を受ける

富士ソフトが扱う blackberry QNX リアルタイムOS に 脆弱性が見つかり、米国FDA, 日本の厚労省が 医療機関や医療機器製造業者に対して注意喚起を行っている。

厚労省通知 2021年8月23日 『医療機器のオペレーティングシステムに係る脆弱性への対応について(注意喚起)

本件については下記の記事の解説が分かり易い。

【ZD Net Japan 『米政府機関、ブラックベリー製品の脆弱性で注意喚起』より引用】

米サイバーセキュリティ・インフラセキュリティ庁(CISA)は、BlackBerryの製品に存在する「BadAlloc」の脆弱性に関するセキュリティアラートを発表した。BadAllocは、2021年の初めにMicrosoftの研究者が発表した脆弱性だ。

 また米国時間8月17日、BlackBerryは同社の「QNX Real Time Operating System(RTOS)」がBadAllocの脆弱性の影響を受ける可能性がある問題についてのアドバイザリーを発表した。QNX RTOSは医療機器や自動車、工場などで使用されており、国際宇宙ステーションでも使われている。同社は最近、QNX RTOSがおよそ2億台の自動車で使われていると明らかにしたばかりだ。

 CISAは、QNX RTOSは一部のIoT機器やOT/ICSシステムで使用されており、これらのシステムを保護するための対策が急務だと付け加えた。BlackBerryは影響を受ける製品の完全なリストを公開している。

 CISAのアラートでは、「リモートの攻撃者にCVE-2021-22156を悪用されると、対象デバイスがサービス妨害状態に陥ったり、任意のコードが実行されたりする可能性がある。BlackBerryのQNX RTOSは幅広い製品で使用されており、この製品が侵害されると、悪意を持った攻撃者に極めて重要度が高いシステムの制御を奪われる可能性があり、国家的に重要な機能のリスクが高まる」と述べている。

 「CISAは、現時点ではこの脆弱性が積極的に悪用されている事例を把握していない。CISAは、重要インフラ企業や、影響を受けるQNXベースのシステムを開発、保守、サポート、使用しているその他の組織に対して、影響を受ける製品にできる限り早くパッチを適用することを強く推奨する」

 CISAによれば、一部のRTOSのソフトウェアをアップデートするには、機器を取り外すか、敷地外の施設に持ち込んで、メモリーを物理的に交換する必要があるという。

 BlackBerryのアドバイザリーには、同社がこの脆弱性を修正するためにリリースした多数のアップデートの情報が掲載されている。Microsoftは4月に、BadAllocは25件のCVEにまたがる問題であり、消費者向け製品から医療用IoTや産業用IoTまでさまざま分野に影響を与える可能性があると述べている。

 米国の政治専門ニュースメディアであるPoliticoは8月17日、4月にBadAllocの脆弱性に関する情報が開示されて以降、BlackBerryと米国の政府関係者との間で交わされてきた舞台裏での議論について報じた。

 記事では、BlackBerryは同社の製品がBadAllocの影響を受けることを否定し、米政府がこの問題に関してアラートを公表することに抵抗したとされている。

 また、CISAの担当者が、QNXシステムに関するセキュリティアラートについて、影響を受ける業界や国防総省などと事前に連携を取っていたことや、外国の政府関係者にもこの脆弱性について説明する予定であることも報じられている。

 BlackBerryは6月に、QNXはAptiv、BMW、Bosch、Ford、GM、本田技研工業、Mercedes-Benz、トヨタ自動車、Volkswagenが製造する多数の自動車に採用されていると発表している。

【引用終わり】

サイバーセキュリティに関する脆弱性は市販後に見つかることがあり、それ自体はあってもまったく不思議ではないので、この脆弱性が見つかったからといって QNXの品質が悪いとは思わない。

どの製品にもありうるので、ここは粛々とパッチを当てたり、QNXの外側の環境で緩和策を取ることが重要と考える。

今回の記事で取り上げたのは、blackberry QNX について、日本の販売元の富士ソフトが QNXは IEC 62304(医療機器ソフトウェア - ソフトウェアライフサイクルプロセス)のソフトウェア安全性クラスC に準拠証明書付きで出荷されると宣伝しており、これが IEC 62304 のリスクベースアプローチの考え方から逸脱していて、単に商品を売るために 規格を利用しているに過ぎないことを示したかったからだ。

QNX OS for Medical 概要・特長 】より引用

医療機器の複雑さが日増しに増加する昨今、規制の監視が益々厳しくなって来ています。根源が知られており事前認証されたコンポーネントを選択することで、認証プロセスが相当楽になります。QNX OS for Medical(医療用QNX OS)は、独立サードパーティにより「医療機器ソフトウェア - ソフトウェア ライフサイクル プロセス」の標準規格であるIEC 62304準拠であると評価されています。この製品はARMとx86プロセッサーでサポートされています。

医療用QNX® OSは、医療機器メーカー用のQNXソフトウェア システムズソリューションの主要素です。これは、市場投入前の認証業務に必要な時間と手間を低減することで医療関係のお客様が厳しい規制要件を満たすお手伝いをするためにデザインされています。医療用QNX OSは、QNXの標準オペレーティングシステムにより100% API互換で、お客様が最大限にソフトウェアを再使用し、それぞれ異なる認証要件を持つ複数製品用の共通プラットフォームを構築できるようになります。この製品は独立サードパーティ評価によるIEC 62304クラスC準拠証明書付きで出荷されます。

【引用おわり】

このブログサイトでも幾度となく、IEC 62304 が自動車ドメイン等で幅をきかせている機能安全規格ではなく、医療機器のインシデントに対して、医療機器のソフトウェア開発プロセスをリスクベースアプローチでの再発防止を目的として策定されたものであることを説明してきた。

機能安全規格では、製品に使用している部品の開発プロセスが機能安全規格が定めるプロセスどおりに作られているかどうかを認証することを推奨しているが、IEC 62304 はあくまでも医療機器の開発プロセスをリスクベースアプローチで開発することを求めていて、部品単位での規格適合など求めていない。

※機能安全という名前が良くない。安全(Safety)は機能(Function)ではない。機能的安全というのもおかしい。安全機能は手段でしかなく、本質を示していない。機能安全という言葉自体が安全の本質を目指していないと感じる。

そもそも、製品全体の構成要素の信頼性を高めることで安全性を確保しようとする設計は個別最適の発想(フォールト・アボイダンス)であり、ソフトウェアの規模が増大し、複雑化した現代では、まったくもって古い考え方である。1960年代の主流だった発想だ。

今では、左図の緑枠にあるように、製品の安全は「フェールセーフ」「フォールトトレランス」「エラー・プルーフ」といった、個々の構成要素に故障がバグがあっても安全側に倒れるようにしたり、冗長性を持たせたり、操作者は必ずミスをするという前提で設計するといった全体最適の発想を行うことが求められている。これが IEC 62304 で求められているリスクベースアプローチ(患者危害に至る危険状態が起こる要因を分析して、重大な危害が起こらないような対策を行う手法)だ。

だから、RTOSのような汎用部品が何の機器に組み込まれて、どのような機能や性能を実現するために使われるかが分からない状態で、安全性を評価することはできない。

例えば、列車で事故が発生したら速やかに列車を止めることが求められるが、飛行機で事故が発生したら、近くの空港まで飛行機を飛ばし続けなければらならない。同じ移動手段でも前者は止める、後者は動き続けることが求められる。

使用目的(意図する使用 = Intended Use)が定まらないと、リスク分析ができないと教えている。なぜなら、同じ材質、同じ形状をしていても何に使うのかによって、危険状態に至る可能性や発生する危害は変わるからである。

この図にあるように、細い木の棒は、アイスキャンディの棒かもしれないが、医師が口の中を診る際の舌圧子かもしれない。

後者の場合は、医療機器となり滅菌や一つ一つの包装が求められる。

同じ材質、同じ形状でも、意図する使用(Intended Use)によっては、リスクが変わるのだ。

よって、汎用製品である リアルタイムOS について、規格の認証が取れているから安全性が高いと主張しているのは、間違っているし、意味がない。

下記の誤った記事を見て欲しい。IEC 62304 を機能安全規格と同じように扱っている。さらに、IEC 62304 のソフトウェア安全クラスは、機器の意図する使用によってリスク分析を行いその評価によってクラスが変わるはずなのに、なにに使われるのか分からない段階で、ソフトウェア安全クラスC であると言っている。一番高いクラスにしておけばいいでしょという考えならば、それはリスクベースアプローチの本質をまったく理解していないことになる。ようするに、IEC 62304 の規格趣旨が理解できていない証拠である。

【MONOist  組込み開発ニュース『工業、自動車、医療機器の機能安全認証を取得した最新版RTOSを提供開始』】より引用

BlackBerryは2020年11月9日、機能安全認証を取得したリアルタイムOSの最新版「QNX OS for Safety 2.2」の提供を開始した。自動車や組み込みソフトウェア開発などにおいて、認証取得作業を軽減し、迅速なシステム開発を可能とする。

最新版のQNX OS for Safety 2.2は、「QNX Neutrino RTOS」をベースとする。第三者認証機関のテュフ ラインランドから、「IEC 61508 SIL3」(工業)、「ISO 26262 ASIL D」(自動車)、「IEC 62304 Class C」(医療機器)の機能安全認証を取得している。

 さらに、「ISO 26262」「IEC 61508 TCL3/T3」の要件に準拠したC/C++ツールチェーンも採用している。これにより、QNXの機能安全性製品に安全認証取得済みのC++ランタイムライブラリが含まれることとなった。

 同社は、最新版のQNX OSを利用することで、開発期間を短縮しながら安全性や信頼性の高いシステムを開発し、開発費用の削減が可能になるとしている。

【引用おわり】

一方で、富士ソフトは、IEC 62304 を医療機器のソフトウェア開発に適用する際に、支援を行うサービスも行っており、そのサービスを紹介したページでは、IEC 62304 の趣旨を正しく理解しているように見える。【対象ページ

なぜ、このような矛盾が生じるのか。理由は簡単だ。QNX が IEC 62304 に準拠したと宣伝に使っている部門と、IEC 62304 をコンサルテーションしますといっている部門が異なっており、前者は IEC 62304 の中身を読んでおらず(または読んでいても理解しておらず)規格適合したと表明すれば、他のRTOSと差別化ができ、規格の趣旨をよく理解できていないユーザから購入してもらえると考えているからだ。

そして、規格の内容や趣旨を熟知している 第三者認証機関が 機能安全ではない IEC 62304 を汎用ソフトウェア製品に対して適合証明してしまうのか、これも商売になるからだ。(規格適合を証明するには相当な費用がかかる)

規格を熟知した認証機関が誤った使い方をしていることを知っていながら、規格適合証明を出しているのだから、こっちの方が罪が重いと思う。

このブログで必要に問題のあるソフトウェア製品について批判する記事を書くのは、これらの認証がエンドユーザの安全を目指して実施されているのではなく、単に商品を売りたいために認証を取っていると思うからだ。

ここで冒頭の blackberry QNX リアルタイムOS に 脆弱性が見つかり、米国FDA, 日本の厚労省が 医療機関や医療機器製造業者に対して注意喚起を行っているという件に話しを戻す。

blackberry QNX リアルタイムOS は 第三者認証機関のテュフ ラインランドから、「IEC
61508 SIL3」(工業)、「ISO 26262 ASIL D」(自動車)、「IEC 62304 Class C」(医療機器)の機能安全認証を取得している(IEC 62304は機能安全規格ではないので、この記述は誤り)と、富士ソフトはWEBサイトで、規格の認証を取得していて、他の製品より安全ですよと主張している。

揚げ足を取るつもりはないが、今回の脆弱性の発見で脆弱性を突かれると リアルタイムOSを使っている製品が悪用され、患者危害に至る可能性があるためパッチを当てる必要があることが分かった。

QNX は「信頼性が高いとされていた」ため、医療機器にも多く使用されていたので、米国や日本の規制当局が冒頭の注意喚起を出したわけだ。

QNXは自動車にも多く使われているようなので、自動車業界でも対応が求められているだろう。

ただ、QNXが対象システムのどこに、何に使われているのかによって、リスクの大きさは異なる。だから、製品ごとにリスク分析を行うことが重要なのであって、部品の製品開発のプロセスが規格に適合していることを主張するのはおかしいし、医療機器の場合、規格趣旨から特に間違っている。

この図を再掲するが、個別最適で安全設計をする時代ではないのだ。全体最適の発想で、意図する使用を明確にして、その上でリスクを分析し、危害の重大度を考慮し、重大な危害に至るケースを優先して、対策を立てていることが、患者や利用者の被害を効率てきに低減することにつながる。

このリスクベースアプローチの考え方を理解せずに、規格適合を主張し、商品を売ろうとする者は、場合によっては、エンドユーザのリスクを高めてしまっている可能性さえある。

汎用ソフトウェア部品を利用する開発者は、ソフトウェア部品の開発プロセスの認証を気にするのではなく、そのソフトウェアがどのような検証を行ったのか、テストの網羅性やテストケースの設計はどうだったのかを精査するべきだ。

規格ビジネスの悪は、規格が求める内容を理解しないユーザにお墨付きをちらつかせて商品を売ろうとする側面を増長させる点にある。

単純な商品販売における競争のための手段ならまあ、無駄ではないし、それもありかと思うが、そこにユーザの健康や安全がかかっているとすれば、それは間違いだと言わなければかえって危ないと思っている。

セキュリティ上の脆弱性は市販後に見つかったら、粛々を対応することでよい。

だた、これを期に、汎用ソフトウェア製品の規格適合証明が製品の安全性で担保するのは間違いであるということを再認識して欲しい。