「組込みソフトエンジニアを極める」がB5版のオンデマンド出版になります。

「リアルタイムOSから出発して組込みソフトウェアエンジニアを極める」ですが、印刷製本コストが値上がりで、今までの形式（普通の印刷）や価格では重版はできなくなり、オンデマンド出版で判型がB5になります。価格もちょっとだけ上がって税込み2200円になります。

大きさは一回り大きくなって、やや薄くなり開きやすくなったと思います。

日経BPでの初版が2006年で、その後、エスアイビー・アクセスでの初版が2011年、改訂版が2016年、オンデマンド版が2023年となります。

2006年の初版から 17年経ちもう少しで一万部ですが、まだまだ使える内容です。実際、組込みソフトウェアもネットワークにつながることが普通になって、規模も増大する一方です。とはいうもののソフトウェアプロダクトラインをちゃんと実践している企業ってまだ少ないですもんね。

この本の原稿書いていたときは、セキュリティのことなんか一ミリも考えていませんでしたが、今原稿書くなら、セキュリティについてもガッツリ解説しないとダメなんだろうなって思いますね。

そういう意味では、セキュリティについてもクリアできないと、組込みソフトエンジニアを極めたことにならないんだな。これから社会に出て行くエンジニアって、学習しなければいけないことがどんどん増えていくみたい。でも、そこをAIがサポートして補っていくんだろう。

となると、ソースコード書くところよりも、もっと上流の設計の考え方とか、ビジネスと技術をどう融合させるかといったところのが技術者の大事な役割になると思うので、まだまだこの本が役に立つ時代は続きます。この本は、技術だけでなく、ビジネスや組込みソフトウェア開発そのものにエンジニアがどう向き合うかについても書いたつもりです。

Amazon の原稿判型の在庫がなくなり次第、B5版のオンデマンド版に変わる予定です。

FDAの医療機器ソフトウェア機能の市販前申請ガイダンスが18年ぶりに改訂された

FDA 米食品医薬品局 が、医療機器を市販前申請する際の「デバイスソフトウェア機能の市販前申請の内容」（Content of Premarket Submissions for Device Software Functions）のガイダンスを 2023年6月14日に発行した。

このガイダンスは、米国で医療機器を販売する際に、ソフトウェアが含まれている場合は、このガイダンスに従って必要なドキュメントを FDA に提出しなさいという内容だ。

この文書は、2005年5月に発行された「医療機器に含まれるソフトウェアの市販前提出の内容に関するガイダンス」に代わるもので、内容はだいぶ変わっている。

とはいうものの 2021年11月にドラフトが公開されていたので、こんな感じで変わるということはアナウンスされていた。（FDAのガイダンスは ドラフト→ Final というプロセスを踏むが、ドラフト段階でもできているかどうか聞かれる）

一番の変更点は、2005年までのガイダンスでは、タイトルが「Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices」（医療機器に含まれるソフトウェアのための市販前ガイダンスの内容）だったのが、「Content of Premarket Submissions for Device Software Functions」（デバイスソフトウェア機能の市販前申請の内容）になった点だ。

これは何を意味しているかというと、2005年のガイダンスでは、「医療機器に含まれるソフトウェアに関するいろいろな説明をせよ」だったのが、2023年のガイダンスでは、医療機器に含まれるではなく、医療機器ソフトウェアの機能 がターゲットになったという点が異なる。

同じように見えるかもしれないが、2005年のガイダンスでは、医療機器に含まれるソフトウェアが審査の対象だった。2023年のガイダンスでは、医療機器に含まれるソフトウェアだけでなく、医療機器が提供する機能として、医療機器が連携するクラウド上のソフトウェアや、スマホやタブレットのブラウザやアプリケーションなども含めて「医療機器単体でできることだけでなく、ネットワークを含めたトータルのシステムでできること、しようとしていること」を説明することが求められるようになった。

以前は、ソフトウェアに障害が発生したときの患者への影響に応じて Level of Concern が Minor, Moderate, Major の3段階に設定され、それぞれのレベルに応じて提出するドキュメントが分かれていたが、今回は、基本ドキュメントと拡張ドキュメントの2段階になった。

拡張ドキュメントになる条件は以下になる。

医療機器のソフトウェア機能に関連する障害や欠陥が、患者、デバイスの使用者、または使用環境の他の人々に対して死亡または重大な負傷の恐れを伴う危険な状況を引き起こす可能性がある場合

下記に各ドキュメントレベルに応じて、求められる内容を示す。

Software Documentation Elements ソフトウェア ドキュメント 要素	Basic Documentation Level 基本ドキュメントレベル	Enhanced Documentation Level 拡張ドキュメントレベル
Documentation Level Evaluation ドキュメント レベル評価	A statement indicating the Documentation Level and a description of the rationale for that level. ドキュメンテーションレベルを示す声明と、そのレベルの根拠の説明。
Software Description ソフトウェア説明	Software description, including overview of significant software features, functions, analyses, inputs, outputs, and hardware platforms. ソフトウェアの説明、重要なソフトウェアの特徴、機能、分析、入力、出力、およびハードウェアプラットフォームの概要を含める。
Risk Management File リスクマネジメントファイル	Risk management plan, risk assessment demonstrating that risks have been appropriately mitigated, and risk management report. リスクマネジメント計画、リスクが適切に軽減されていることを示すリスクアセスメント、およびリスクマネジメント報告書。
Software Requirements Specification(SRS) ソフトウェア要求仕様書(SRS)	SRS documentation, describing the needs or expectations for a system or software, presented in an organized format, at the software system level or subsystem level, as appropriate, and with sufficient information to understand the traceability of the information with respect to the other software documentation elements (e.g., risk management file, software design specification, system and software architecture design chart, software testing). SRS（Software Requirements Specification）文書は、システムまたはソフトウェアのニーズや期待事項を組織的な形式で記述し、ソフトウェアシステムレベルまたはサブシステムレベルに応じて、他のソフトウェア文書要素との情報のトレース性を理解するための十分な情報を提供する（例：リスクマネジメントファイル、ソフトウェア設計仕様、システムおよびソフトウェアアーキテクチャ設計図、ソフトウェアテスト結果など）。
System and Software Architecture Design システム及びソフトウェアアーキテクチャ設計	Detailed diagrams of the modules, layers, and interfaces that comprise the device, their relationships, the data inputs/outputs and flow of data, and how users or external products (including information technology (IT) infrastructure and peripherals) interact with the system and software. デバイスを構成するモジュール、レイヤー、およびインターフェースの詳細な図解、それらの関係性、データの入力/出力とデータのフロー、およびユーザーや外部製品（情報技術（IT）インフラストラクチャや周辺機器を含む）がシステムとソフトウェアとのやり取りをする方法についての図解。
Software Design Specification (SDS) ソフトウェア設計仕様(SDS)	FDA is not recommending the SDS as part of the premarket submission. Sponsor should document this information on the design via the DHF for the device. During premarket review, FDA may request additional information, if needed, to evaluate the safety and effectiveness of the device. FDAは、市販前申請の一環としてSDS（Software Development Standards）の提出を基本ドキュメントレベルでは推奨していない。製造業者は、医療機器の設計に関するこの情報をデバイス履歴ファイル（DHF）に文書化する必要がある。市販前審査中、FDAは、必要に応じて、医療機器の安全性と有効性を評価するために追加の情報を要求することがある。	SDS documentation, including sufficient information that would allow FDA to understand the technical design details of how the software functions, how the software design completely and correctly implements all the requirements of the SRS, and how the software design traces to the SRS in terms of intended use, functionality, safety, and effectiveness. SDS（Software Development Standards）文書には、FDAがソフトウェアの機能の技術的な設計詳細、ソフトウェア設計がSRSのすべての要件を完全かつ正しく実装している方法、およびソフトウェア設計が意図された使用目的、機能、安全性、有効性に関してSRSとのトレース性を理解するために十分な情報が含まれる。
Software Development, Configuration Management, and Maintenance Practices ソフトウェア開発、構成管理(コンフィグレーションマネジメント)及び保守	A summary of the life cycle development plan and a summary of configuration management and maintenance activities; ライフサイクル開発計画の概要と、構成管理および保守活動の概要の要約。 OR 又は A Declaration of Conformity36to the FDA-recognized version of IEC 62304, including subclauses 5.1.1-5.1.3, 5.1.6-5.1.9, clause 6 (Software maintenance process), and clause 8 (Software configuration management process), among others as applicable. FDAが認識しているIEC 62304のバージョンに対する適合性宣言（Declaration of Conformity）：該当する場合には5.1.1-5.1.3、5.1.6-5.1.9の細分箇条、箇条6（ソフトウェア保守プロセス）、および箇条8（ソフトウェア構成管理プロセス）などが含まれる。	A summary of the life cycle development plan and a summary of configuration management and maintenance activities; ライフサイクル開発計画の概要と、構成管理および保守活動の概要の要約。 OR 又は A Declaration of Conformity36to the FDA-recognized version of IEC 62304, including subclauses 5.1.1-5.1.3, 5.1.6-5.1.9, clause 6 (Software maintenance process), and clause 8 (Software configuration management process), among others as applicable. FDAが認識しているIEC 62304のバージョンに対する適合性宣言（Declaration of Conformity）：該当する場合には5.1.1-5.1.3、5.1.6-5.1.9の細分箇条、箇条6（ソフトウェア保守プロセス）、および箇条8（ソフトウェア構成管理プロセス）などが含まれる。
Software Testing as Part of Verification and Validation 検証(ベリフィケーション)および妥当性確認(バリデーション)の一部としてのソフトウェアテスト	A summary description of the testing activities at the unit, integration and system levels; ユニット、統合、およびシステムレベルでのテスト活動の概要説明 AND 及び System level test protocol including expected results, observed results, pass/fail determination, and system level test report. システムレベルのテスト手順書（テストプロトコル）を含み、期待される結果、観測された結果、合格/不合格の判定、およびシステムレベルのテストレポートを含む。	Basic Documentation Level, PLUS 基本ドキュメントレベルに 加えて unit and integration level test protocols including expected results, observed results, pass/fail determination, and unit and integration level test reports. ユニットおよび統合レベルのテスト手順書（テストプロトコル）を含み、期待される結果、観測された結果、合格/不合格の判定、およびユニットおよび統合レベルのテストレポートを含む。
Software Version History ソフトウェアバージョン履歴	A history of tested software versions including the date, version number, and a brief description of all changes relative to the previously tested software version. 以前にテストされたソフトウェアバージョンの履歴を含み、日付、バージョン番号、以前にテストされたソフトウェアバージョンとの関連でのすべての変更の簡単な説明が含まれる。
Unresolved Software Anomalies 未解決のソフトウェア異常	List of remaining unresolved software anomalies with an evaluation of the impact of each unresolved software anomaly on the device’s safety and effectiveness. 未解決のソフトウェアの異常のリストと、各未解決のソフトウェアの異常がデバイスの安全性と有効性に与える影響の評価。

特に注目して欲しいのは、System and Software Architecture Design（システム及びソフトウェアアーキテクチャ設計）の部分で、「デバイスを構成するモジュール、レイヤー、およびインターフェースの詳細な図解、それらの関係性、データの入力/出力とデータのフロー、およびユーザーや外部製品（情報技術（IT）インフラストラクチャや周辺機器を含む）がシステムとソフトウェアとのやり取りをする方法についての図解。」の提出を求められることになった。

今回のガイダンスには Appendix B に このシステム及びソフトウェアアーキテクチャ設計図の例が3つ示されている。

1. ハンドヘルド診断デバイス

2. 患者と医療提供者向けのアプリケーションを備えた埋め込み式治療デバイス

3. 取得された医療画像を解析するためのクラウドベースのデバイスアルゴリズムのシステムおよびソフトウェアアーキテクチャ

これらのダイアグラムはハードウェア、ソフトウェアを含むシステム全体の静的なアーキテクチャ図で、この図は 一般的なURLの表記ではなく FDAの独自の表記法である。

凡例を付けていれば、この様式とまったく同じでなくてもよいようだが、このFDAが示す表記法で 医療機器申請をすれば審査が早く進むのだろう。

特徴的なのは、ハードウェアモジュール、ソフトウェアモジュール、OTS（市販されている既製のソフトウェア製品）を区別しており、それらの関係性をインタフェースの矢印線で示しているところだ。

2の 「患者と医療提供者向けのアプリケーションを備えた埋め込み式治療デバイス」のアーキテクチャ図を見ると分かるのは、埋め込み式の治療デバイスが物理的な医療機器なのだが、実際には、リーダー/プログラマと通信したり、リーダー/プログラムを通して、クラウドにデータを送ったり、モバイル端末でデータを見たりするような使い方をする（＝意図する使用としている）ことである。

ようするに、現代の医療機器は、医療機器単体で使用することは少なくなってきていて、ネットワークに接続して、クラウドで機械学習したり、モバイル端末で医療機器の情報を閲覧したりすることが当たり前になってきているということだ。そのため、患者リスクは医療機器の中だけに留まらず、医療機器から外に出た情報がどのように使われるのかも含めて、リスクマネジメントしないといけなくなってきている。

だからこそ、FDAのガイダンスのタイトルが「医療機器に含まれるソフトウェアのための市販前ガイダンスの内容」から「デバイスソフトウェア機能の市販前申請の内容」に変わったのだ。

規制当局としてチェックしなければいけないのは医療機器に含まれるソフトウェアだけではなくなったので、医療機器のソフトウェア機能として、ネットワークを含めた接続機器や機能全体を審査しないといけなくなったのである。

それにともない、医療機器が出力する情報は仕様を公開するので自由に使ってくださいという考え方はNGとなっている。相互運用性（Interoperability）を医療機器製造業者が定義した上で、その安全性や有効性の妥当性を確認する必要があるということになる。

そうなると、医療機器からどんな情報が出たり入ったりしていて、どんな機器やシステムと接続しているのか、それらの機器・システムには市販のソフトウェアが使われてるのかどうかを見る必要が出てくる。だからこそ、システム及びソフトウェアアーキテクチャ設計図が必要となった。

また、システム全体の機能として安全性や有効性を確認するためには、それぞれの機能モジュールの要求仕様を確認した上で、それらの要求仕様が検証され、バリデーションされているかのトレースを取る必要がある。

そのため、システム及びソフトウェアアーキテクチャ設計図の各モジュールには、要求仕様の番号が記載されている。（例 SWReq X.Y)  また、ところどころで機能モジュールの Intended Use（意図する使用）がノートで説明されている。例えば、1のハンドヘルド診断デバイスでは、解析エンジンのノートに下記のノートが付けられている。

Analysis engine consists of software algorithms for analyzing signals acquired from patient （解析エンジンは患者から取得した信号を解析するためのソフトウェアアルゴリズムで構成されています）

システム及びソフトウェアアーキテクチャ設計図が、SRS（ソフトウェア要求仕様）でも提示を求められているのは、各モジュールの要求仕様を確認したり、トレースを取ったりしたいからである。

医療機器ソフトウェアの安全性や有効性を確認するために、規制当局がシステムアーキテクチャまで踏み込んで審査する時代になった。

システムエンジニアやソフトウェアエンジニアは、ソフトウェアを作る以前に、さまざまなモデリングができなければいけなくなってきている。今回は、システム及びソフトウェアアーキテクチャ設計図だが、サイバーセキュリティでは脅威モデリングとしてデータフローダイアグラムを信頼境界も含めて描くことが求められてる。

現代のソフトウェアエンジニアは当たり前にモデリングができることが求められるようになった。

今回の FDA が要求する システム及びソフトウェアアーキテクチャ設計図 は、UML モデリングツール EnterpriseArchitect で描くことができる。

↓アドインの説明

System and Software Architecture Diagramの作成

EA 16.1 にこのアドインを取り込んで描いた図を示す。

すり合わせ的に作ってきたソフトウェアシステムは、こんなに綺麗に機能=モジュールになっていないかもしれないが、AIなど多様な機能を取り入れたシステムを実現するには、機能分割されたモジュールを組み合わせた設計にしていく必要がある。

すり合わせ一本でここまでソフトウェアを開発してきた技術者には、モデリングできるように今回のようなシステムアーキテクチャを描く練習するとともに、是非「リアルタイムOSから出発して 組込みソフトエンジニアを極める」を読んで、どうやって時間分割のハードルを越えて、さらに機能分割のハードルを越えるのかを学んで欲しい。

医療機器のサイバーセキュリティ規制強化へ

2023年3月31日付けで、厚労省から医療機器のサイバーセキュリティ規制強化に関するいくつかの通知が発出された。

どんな通知なのかを説明したいと思う。

1.  医療機器の基本要件基準第12条第３項の適用について（令和５年３月31日薬生機審発0331第８号）(PDF,155KB) 
2. 医療機器のサイバーセキュリティ導入に関する手引書の改訂について（令和５年３月31日薬生機審発0331第11号・薬生安発0331第４号）(PDF,1435KB) 
3. 医療機関における医療機器のサイバーセキュリティ確保のための手引書について（令和５年３月31日医政参発0331第１号・薬生機審発0331第16号・薬生安発0331第８号）(PDF,971KB)

「医療機器の基本要件基準第12条第３項の適用について」の医療機器の基本要件基準とは何か

PMDAに詳しい説明資料があるのでこれを参照して欲しい。

簡単にいうと、薬機法（法律）で医療機器は認証基準への適合が必要となっていて、基本要件基準第41条にて、厚生労働大臣は必要な基準を設けることができるとある。医療機器の基本要件基準は厚労省からの告示によって示されている。

医療機器の基本要件基準の第12条は、「プログラムを用いた医療機器の対する配慮」で、今回 第12条の 3項にサイバーセキュリティ要求が追加された。

実は第12条2項は 2017年5月に追加されたJIS T 2304(医療機器ソフトウェア―ソフトウェアライフサイクルプロセス)への適合を求めた追加だった。

第12条3項は、2023年3月9日に追加の告示が発出されている。今回 出た通知は、第12条3項の施行に関する通知となる。

医療機器の基本要件基準第12条第３項

３．プログラムを用いた医療機器のうち、他の機器及びネットワーク等と接続して使用する医療機器又は外部から不正アクセス及び攻撃アクセス等が想定される医療機器については、当該医療機器における動作環境及びネットワークの使用環境等を踏まえて適切な要件を特定し、当該医療機器の機能の支障が生じる又は安全性の懸念が生じるサイバーセキュリティに係る危険性を特定及び評価するとともに、当該危険性が低減する管理が行われていなければならない。また、当該医療機器は、当該医療機器のライフサイクルの全てにおいて、サイバーセキュリティを確保するための計画に基づいて設計及び製造されていなければならない。

これが追加された第12条3項の内容になる。この3項の説明が冒頭の3/31付けの通知1 に書かれている。その内容を紹介する。

趣旨

基本要件基準は、医療機器が具備すべき品質、有効性及び安全性に係る基本的な要件を規定したものであり、医療機器に対しリスクマネジメントの適用によってリスクを許容可能な範囲まで低減することが要求されている。

サイバーセキュリティ対策については、「医療機器におけるサイバーセキュリティの確保について」（平成27年４月28日付け薬食機参発0428第１号及び薬食安発0428第１号）、「医療機器のサイバーセキュリティの確保に関するガイダンスについて」（平成30年７月24日付け薬生機審発0724第１号及び薬生安発0724第１号）等において必要な対応を行うよう求めてきたところであるが、今般、令和２年３月に国際医療機器規制当局フォーラム（IMDRF）において、「医療機器サイバーセキュリティの原則及び実践に関するガイダンス」が取りまとめられたことに伴い、IMDRF N47文書（Essential Principles of Safety and Performance of Medical Devices and IVD Medical Devices）及びN60文書（Principles and Practices for Medical Device Cybersecurity）を踏まえ、プログラムを用いた医療機器に対しサイバーセキュリティを確保するための設計及び製造、ライフサイクル活動として、①製品の全ライフサイクルにわたって医療機器サイバーセキュリティを確保する計画を備えること、②サイバーリスクを低減する設計及び製造を行うこと、③適切な動作環境に必要となるハードウェア、ネットワーク及びITセキュリティ対策の最低限の要件を設定すること、の３つの観点を基本要件基準に盛り込むこととし、基本要件基準第12条に第３項を追加する改正を行ったものである。

要約すると、

IMDRF N47文書、N60文書をベースにしている。

1. 製品の全ライフサイクルにわたって医療機器サイバーセキュリティを確保する計画を備えること
2. サイバーリスクを低減する設計及び製造を行うこと
3. 適切な動作環境に必要となるハードウェア、ネットワーク及びITセキュリティ対策の最低限の要件を設定すること

の3つの観点を基本要件基準に盛り込んだということになる。

IMDRF は 各国の規制当局の集まりで、ここで決まったことを各国の医療機器規制当局が自国の規制に適用することになっている。

IMDRFの成果として有名なのが、MDSAP（医療機器単一審査プログラム）で、各国とも ISO 13485 （ISO 9001 の医療機器版）を医療機器製造販売業者に求めているが、国によって微妙に異なる部分を各国統一部分＋差分という形にして、1回審査をパスすれば、それぞれの国で審査し直さなくてもよいというプログラムを作った。これによって、米国の非常に厳しい査察を定期的に受ける必要がなくなった。（全体としては米国の審査基準に近づいたので米国以外の審査としてはハードルが上がったと言える）

IMDRF はN60文書として医療機器の対するサイバーセキュリティのガイダンスを発行していて、冒頭の2の文書が、IMDRF N60文書の日本適用版という位置づけになっている。

冒頭１の施行通知の解説を続ける。

(1) 「プログラムを用いた医療機器のうち、他の機器及びネットワーク等と接続して使用する医療機器」とは、他の機器（医療機器、IoT機器、周辺機器、外部記録媒体（USB、SD、HDD、CD、DVD等）、電子カルテ、PC（外部からの持ち込みPC含む））、ネットワーク（院内システム、院外システム、グローバル）等に接続して電磁的情報のやり取りをする医療機器である。

ここは対象となる医療機器の説明をしてる。

・他の機器にネットワーク等に接続して電磁的情報をやり取りする医療機器が対象。

（２）「外部からの不正アクセス及び攻撃アクセス等」は、脆弱性を攻撃対象とする等の設計者が通常使用において想定していない手法等を用いた悪意を持った不正アクセスや、意図的に過剰な負荷を与えたる攻撃（DoS攻撃(Denial Service Atttack)、DDoS攻撃(Distributed Denial of Service Attack)等）、マルウェア（悪意のあるソフトウェア）の感染を意図する攻撃によるアクセス等を想定している。昨今のサイバー攻撃についてはその攻撃形式が多様化・高度化しており、今後はこれらの攻撃手法の他にも対応することも必要となり得る。

ここは、外部からの不正アクセス及び攻撃アクセスの説明。

（３）「動作環境及びネットワークの使用環境等を踏まえて適切な要件を特定し」とは、医療機関、在宅、救急、植込み型機器等の動作環境並びに接続するネットワーク種別やオペレーティングシステム及び各種ライブラリ等のプラットフォームといった使用環境を特定し、その使用環境に適した運用体制等を含めた医療機器の意図する使用に適切な要件を設定することである。

使用環境の特定について説明と、医療機器の意図する使用と使用環境の要件を設定すること。

（４）「当該医療機器の機能に支障が生じる又は安全性の懸念が生じるサイバーセキュリティに係る危険性を特定及び評価するとともに、当該危険性が低減する管理」とは、他のリスクと同様に、サイバーセキュリティに係るリスクに対しても、適切にリスクマネジメントを行い、例えば、JIS T 81001-5-1に示されている通り、サイバーセキュリティの脆弱性を特定し、その悪用によって生じる脅威や悪影響に伴うリスクを評価し、適切にリスクをコントロールすることである。

サイバーセキュリティのリスクを評価する。悪用によって生じる脅威や悪影響に伴うリスクを評価し、リスクをコントロールする。

（５）「ライフサイクルの全てにおいて、サイバーセキュリティを確保するための計画に基づいて設計及び製造」とは、全ライフサイクルにわたってサイバーセキュリティを確保するため、設計・製造工程における取組だけでなく、医療機関との連携、脆弱性対策（市販後のアップデート等を含む）に係る計画等も踏まえ、それが達成できるように、また、問題点や脆弱性が見つかった場合に対応できるように設計・製造を行うことである。

 設計・製造工程における取り組みだけでなく、脆弱性対策、医療機関への報告、連携を計画し、達成する。

JIS T 81001-5-1 とは IEC 81001-5-1 の JIS版で、「ヘルスソフトウェア及びヘルスITシステムの安全，有効性及びセキュリティ－第５－１部」というタイトルの規格だ。

IEC 81001-5-1は、IEC 62443-4-1 の要求事項を IEC 62304 のプロセスに当てはめた形の規格 であり、すでに産業用の制御システムのセキュリティ規格として存在していた IEC 62443-4-1 を医療機器のライフサイクルプロセスに置き換えた規格だ。

実は、この規格をJIS化するにあたっては、通常は2～3年かかる作業を約1年という短い期間で実現している。これは、厚労省が 医療機器の基本要件基準 のサイバーセキュリティ要求の適合と示すために、この規格を使おうと考えていたからだ。

冒頭１の通知では、「例えば、JIS T 81001-5-1に示されている・・・」というように、JIS T 81001-5-1 以外の規格を使ってもいいよというニュアンスで説明しているが、実際のところは「JIS化したんだから、JIS T 81001-5-1 に適合しろよ」といった本音がにじみでている。

IEC 81001-5-1 のような国際規格を日本が世界に先駆けて医療機器規制に使うというのは非常に珍しいことで、これまではEUが規制に取り入れてから、日本も追随するというパターンだった。

サイバーセキュリティに関しては日本の特に医療分野、医療機器分野では対応が遅れているとされていたため、今回は厚労省が世界に先駆けて、医療機器への規制を強化したといえる。

冒頭の通知３は、医療機関向けのサイバーセキュリティに関するガイダンスになる。

サイバーセキュリティは、医療機器製造業者だけでも医療機関だけでも達成することはできない、両者と規制当局は医療情報システムの提供者などが協力してはじめて達成できる。

よって、各者の情報開示や、レガシーシステムに対する補完的対策などが重要になってくるため、医療機器製造者向けのガイダンスと医療機関向けのガイダンスの両方が発出されている。

また、現行のシステムが医療機関においてどのようなネットワークにつながっているのか、また、どのようなセキュリティ対策（＝信頼境界があるのか）、どのような脅威が想定されるのかを分析すること（＝脅威分析）が必要であり、医療機器製造販売業者は、今度、脅威分析図、システム構成図を医療機関に示すことが必須になってくる。

このとき使うのが脅威モデリング（データフローダイアグラムを使うのが一般的）だ。

今後、このブログの中で脅威モデリングの説明をしていきたいと考えている。

プログラム医療機器を開発しようとしてる方は、まず3月31日付けで発出された3つの通知をよく読んで内容を理解することをお勧めする。

久しぶりの投稿

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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