MSCについて — 私がこの仕事をする理由

医療機器のソフトウェア規格は、事故の再発防止から生まれた知恵です

1985年から1987年にかけて、北米で Therac-25 という放射線治療器が6件の重大事故を起こしました。ソフトウェアの並行処理の不具合等により、通常の100倍以上の線量が患者に照射され、複数の方が亡くなりました。

被害者の何件かは、当初「放射線治療の通常副作用」と誤診されました。ソフトウェアが原因で人が危害を被るという発想自体が、当時はまだ広く共有されていなかったのです。

IEC 62304（医療機器ソフトウェアライフサイクルプロセス）、ISO 14971（リスクマネジメント）、IEC 62366（ユーザビリティエンジニアリング）——これらの国際規格は、こうした事故を繰り返さないために生まれました。IEC 62304にはソフトウェア工学のさまざまなプラクティスが取り入れられています。

私は、規格を「守らなければならないルール」とは考えていません。医療機器のソフトウェア規格は、過去に発生した事故の再発防止の知恵です。その知恵を正しく使いこなすことが、患者の安全を守ることにつながる。それが MSC の支援の出発点です。


39年間、医療機器のソフトウェアを作ってきました

1987年に日本光電工業に入社して以来、除細動器、生体情報モニタ、DXシステムなど、クリティカルデバイスのソフトウェア開発や技術者支援に39年間従事してきました。

仕様立案、アーキテクチャ設計、プロセス管理、安全性・信頼性の検証、保守、そしてソフトウェア技術者の教育——組込みシステム開発に関する幅広い領域を、メーカーの内側で経験してきました。

2006年から2025年まで JEITA（電子情報技術産業協会）ヘルスケアインダストリ部会 医療用ソフトウェア専門委員会に幹事として関わり、IEC 62304 の実践ガイドブック策定にも携わりました。また、日本光電在籍中に医療機器規制となったサイバーセキュリティ対応についても尽力を尽くしました。


雛形を渡しても、エンジニアは育ちません

医療機器ソフトウェアの規制対応で、よくある相談があります。「IEC 62304 の規格書を読んだが、具体的に何をどこまでやればいいかわからない」。

この問いに対して、雛形やテンプレートを渡すことはできます。形式的にはそれで規格に適合できるかもしれない。しかし、エンジニア自身が規格の意図を理解していなければ、次に新しい問題が起きたとき、また同じ壁にぶつかります。

Therac-25 の事故後、AECL（カナダ原子力公社）は問題のあった制御変数の値を固定値に変更する修正を行いました。しかし、それは根本原因を解消するものではありませんでした。一つの不具合をパッチで塞いでも、設計思想そのものが変わらなければ、別の場所で同じ種類の問題が再発します。

私がブログで2012年に「テンプレートで乗り切る功罪」という記事を書いたのも、同じ問題意識からです。形だけ直しても、本質は変わらない。

MSC は、規格の答えを教えるのではなく、エンジニアが自分で考え、判断できるようになることを目指します。具体的な開発現場の課題からスタートして、規格の本質的な意図を理解してもらう。著書のタイトルにもある「具体から抽象へ」というアプローチを、コンサルティングでもトレーニングでも一貫して実践しています。


リスクに応じて濃淡をつける誠実さ

日本光電時代、社内のソフトウェアレビューでは、一つのポリシーを貫いてきました。人工呼吸器のような命に直結する機器には徹底的に厳しく。リスクの小さい機器には適切な水準で。

これは ISO 14971 の本質そのものです。リスクマネジメントとは、すべてを一律に厳しくすることではありません。製品がもたらすリスクの大きさに応じて、対策の深さと幅を誠実に判断すること。米国 FDA も同じ思想で米国の国民を守っています。規制当局が IEC 62304 や ISO 14971 を規制要件としているのは、これらの規格が医療機器の安全に本質的に必要だからです。

一方で、長年工業会の国内委員会に参加する中で、IEC 61508（機能安全）を医療機器業界にも適用せよという圧力が度々かかるのを見てきました。その背景には、55億ドル規模の認証ビジネス市場があります。私はその都度、医療機器の安全は ISO 14971 のリスクマネジメントが基盤であり、認証ビジネスのために規格を使うべきではないと主張してきました。

規格は人の命を守るためにある。ビジネスのためにあるのではない。


組込みソフトウェアアーキテクトとして


私は組込みソフトウェアアーキテクトを自負しています。長い組込みソフトエンジニアとして経験の集大成が著書『組込みソフトエンジニアを極める』です。


2006年初版ですが、改定・増販を繰り返して出荷数が1万部に到達しました。日本の製造業、特に組込みソフトウェアのアーキテクトは正当に評価されていないと感じます。アーキテクトは製品のソフトウェアの構造を考える開発のキーマンです。


ソフトウェアアーキテクトは製品のソフトウェア構造を知り尽くしているため、何でもできる便利屋として扱われ、日本の終身雇用制の弊害かもしれませんが、その人がいなくなったら製品の開発が立ちゆかなくなるという認識を持ってもらえていません。エンジニアも簡単に転職ができるようになった現在ではソフトウェアアーキテクトの引き抜きは製品開発の致命的な危機となりかねません。


MSCはソフトウェアアーキテクトを支援し、育成したいと考えています。


ハードウェアやネットワークによる他機器との連携、コアアセットとのなるその商品の価値が凝集されているソフトウェアアイテムやリスクコントロールアイテムの分離と独立性の確保が、ソフトウェア製品群の効率的な開発を可能にします。


ソフトウェアの部品化、共通化を口にする技術者、プロジェクトマネージャを何人も見てきましたが、実現できたケースはほとんど見たことがありません。ソフトウェアの再利用、ソフトウェアプロダクトラインの実現には技術とマネージメントが必要です。


MSCでは、製品のソフトウェアアーキテクチャを可視化し、商品群としての価値を最大限に高めるための支援を行いたいと考えています。


MSC を始めた理由

2025年3月、日本光電を定年退職して、同年6月に Medical Software Consulting を始めました。

大きく稼ぐためではありません。39年間蓄積した知見を医療機器業界に還元し、エンジニアを育てたいと思ったからです。

ISO/IEC の国際エキスパートたちは、もちろん自国の利益を優先して主張します。しかし根底には「医療に貢献したい、医療機器で人の命を救いたい」という気持ちがある。そのために必要な規格を、何年もかけて作っている。私も同じ思いでこの仕事をしています。

年に2〜3件、面白い仕事を密度高くやる。一つひとつの課題に丁寧に向き合い、依頼されたこと以上の価値を返す。それが MSC の働き方です。


著書・実績


こんな方に来てほしい


Medical Software Consulting 代表　酒井 由夫