こんにちは。KINTOテクノロジーズ（KTC）で、ユーザーファースト推進活動の運営に関わっているる かーびー です。 KTCでは 「ユーザーファースト」 を会社の重点方針のひとつに掲げており、社内勉強会「ユーザーに寄りそわNight!」の開催もその取り組みのひとつです。 Vol.02 のレポートに続き、今回はVol.03の内容をお伝えします。 テーマは「クイックなリサーチ」。サービスに感じた「このまま進めていいのかな」という違和感を、すぐに改善案にせず、手元にある情報から一度確かめてみる進め方です。 サービスの企画や改善に関わっていると、「この動線で、必要な情報までたどり着けるのだろうか」「説明の途中で迷う人がいるのではないか」と感じる場面があります。 こうした違和感は改善を考えるきっかけになりますが、その時点では本当に問題が起きているのか、ユーザーにどんな影響があるのかまではわかりません。 生煮えのままチームに改善案をあげたとして、関係者の立場によって持っている情報や前提が異なるため、提案に至った背景から理解を取り付ける必要があります。一定の共感は得られるとしても、関係者が多いほど時間がかかるものです。 Vol.03で取り上げたのは、この違和感と改善案のあいだに、「確かめる」を一段はさむ実践でした。 第3回の寄りそわNightでは、デジタル戦略部の上田貴弘さんに登壇していただきました。オンライン相談やVoC（Voice of Customer：お客様の声）の分析、ユーザビリティテストなどを通じて、ユーザーの声や行動を捉える業務に取り組んでいます。当日は、オンライン相談やVoCから見えてきた仮説を、新入社員とのユーザビリティテストで確かめた事例が紹介されました。 新入社員に実際のサービスを使ってもらう 今回の事例の出発点は、オンライン相談やVoCを見る中で生まれた「サービスの利用途中に、いくつかのつまずきが起きているのではないか」という仮説でした。 ただ、相談や問い合わせからわかるのは、ユーザーが言葉にした困りごとが中心です。実際の画面上のどこで手が止まり、何が理解しにくかったのかまではつかめません。 そこで登壇者の上田さんが紹介したのが、新入社員に協力してもらうユーザビリティテストでした。 入社したばかりのメンバーは、業務やサービスに関する前提知識がまだ少なく、社内では当たり前になっている言葉や流れにも、初めてサービスに触れる人に近い反応を示します。社内メンバーなので確認したい内容を共有しやすく、短い準備で実施できる。実践のしやすさも、この方法が選ばれた理由の一つでした。 もちろん、新入社員がそのまま実際のお客様を代表するわけではありません。 今回は、サービスのどこにつまずきがありそうかをまず確かめるための検証です。 テストでは、実際に画面を操作してもらいながら、利用中の発話や迷い、説明を読んだあとの反応を観察していきます。説明を何度も読み返す、次に進まずに考え込む、前の画面に戻って情報を探す。 操作の様子を追うことで、どの場面で立ち止まったのか、どの説明が伝わりにくかったのか、判断するために何の情報が足りなかったのかが具体的になっていきます。 設計上は、説明を読めばそのまま次の画面へ進める想定でも、実際には同じ箇所を何度も読み返している。反対に、作る側が課題だと考えていた箇所では、ほとんど迷いが起きていない。登壇を通して繰り返し語られていたのは、この「想定」と「実際に起きていること」を分けて見ることの大切さでした。 紹介された例のひとつが、本人確認書類の画像アップロードです。最新のスマートフォンで撮ったきれいな写真が容量の上限を超え、エラーになる。設計した時点では問題のなかった仕様でも、ユーザーの利用環境が変わることで、思わぬところにつまずきが生まれます。実際の利用を見て初めてわかるつまずきは、こうした単純なところにも潜んでいます。 エラーに遭遇した人は、そのあと撮り直して先へ進めているのか。それとも、そこで利用をやめてしまっているのか。実際の行動が見えると、次に確かめたいことが具体的になります。こうして、ひとりの違和感が、チームで確かめられる問いに変わっていきます。 オンライン相談やVoCから感じていた違和感に実際の行動が重なったことで、「使いにくそう」という感覚だけでは見えていなかった部分が確認できた。そんな事例でした。 提案の前に、同じ景色を見る 確かめた結果を、チームでどう使うのか。この話題で登壇のキーワードになっていたのが「同じ景色を見る」という言葉です。 ここでいう「同じ景色」とは、全員が同じ意見になることではありません。改善案を挟んで向かい合うのではなく、ユーザーの行動や声を真ん中に置いて、隣に並んで見る。ユーザーに何が起きていたのか。どの情報から、課題かもしれないと考えたのか。何が変われば、困りごとが解消されたと言えそうなのか。立場や役割が違っていても、まずユーザーを共通の起点にして考える、という意味です。 改善案だけが先に出てくると、受け取る側は、何を解決しようとしているのか、なぜ今扱う必要があるのかを、まず確認しなければなりません。ユーザーの行動や発言、問い合わせ、ログが先に共有されていれば、改善案への賛否を決める前に、「何が起きていそうか」から話し始められます。 直したい箇所のリストは、開発の現場ではいつも長くなりがちです。 「一部の環境で画像のアップロードがエラーになることがある」という一行の報告と、目の前でユーザーが何度も写真を撮り直し、手を止めてしまう様子とでは、同じ事実でも受け取る重みが違います。 実際の行動を関係者が一緒に見ることで、ユーザーへの影響を起点に、何から手をつけるかを話せるようになります。 最初に置いた仮説が、正しいとは限りません。確かめてみると、想定とは別の場所で迷っていたり、課題だと思っていたことが実際にはそれほど影響していなかったりもします。 それでも、見ていた事実と仮説が共有されていれば、想定と違う結果が出たときに、次に何を確認するかを考えやすくなります。 事実は、提案を通すためだけの材料ではなく、チームで次の判断を下すための材料にもなります。 今回の事例を貫いていたのは、この考え方だったように思います。 参加者から寄せられた質問 イベント後のアンケートや質問フォームには、今回の内容を実践する際に迷いそうな点について、具体的な質問が寄せられました。たとえば、次のような内容です。 「売上を伸ばす」のような大きな目的から、どの粒度まで課題を小さくして調査を設計するのか アンケートで集めた声を、設問の意図や対象者を踏まえてどう読み取るのか 集めた事実を、聞き手が判断できる量にどう整理するのか また、「ユーザー中心の視点でサービス開発を進めるには、何から始めるとよいのか」「プロジェクト名など、普段使う言葉をユーザー起点に変えることにも意味があるのか」といった質問もありました。 内容を理解して終わるのではなく、自分の業務で試すとしたらどこで迷うのか。その段階まで踏み込んだ質問が多かったことが印象に残っています。ここで挙がった論点は、次回以降のテーマを考える際の材料にしていく予定です。 まず、手元にあるものを見てみる ユーザーファーストの実践というと、大がかりな調査や専門的なリサーチから始めるもののように感じるかもしれません。 今回の事例の起点は、オンライン相談やVoCなど、すでに手元にあった情報でした。そこから気になったことを、新入社員とのユーザビリティテストで確かめる。日々の業務で生まれる「このままでいいのかな」という違和感も、事実とセットにすると、チームで検討できる問いになります。 私自身、気になることがあると、つい解決策まで一気に考えてしまいます。今回の話を聞きながら、答えを出す前に、まず何が起きているのかを一度見てみることを忘れないようにしたいと思いました。 次に何かが気になったとき、まずは手元のログや問い合わせをひとつ確認してみる。今回のレポートが、そんな一歩につながればうれしいです。 関連記事 『ユーザーに寄りそわNight!』Vol.02レポート ── my route開発チームのフィールドワーク事例 KINTO Technologiesにおけるユーザーファースト推進の取り組み 定量データと定性データを行き来する ── ユーザーインタビューわいわい会

一般的なソフトウェア開発や評価の経験があっても、医療機器の開発に関わり始めると「これまでと同じテストで十分なのか」と迷いやすくなります。 医療機器では、単に仕様通り動作することを確認するだけでなく、ソフトウェアの誤動作が患者や医療従事者へ与える影響を考え、 安全性に関わるリスクが適切に管理されていることまで確認する視点 が欠かせません。 さらに、IEC 62304／JIS T 2304によるソフトウェアライフサイクル、ISO 14971／JIS T 14971によるリスクマネジメント、サイバーセキュリティなど、複数の要求を実際の開発・テスト活動へ結び付ける必要があります。 そのため重要なのは、規格の条文を暗記したりテストケースを大量に作ったりすることではなく、 「どの要求やリスクを、どの試験で確認したのか」を説明できる仕組み を整えることです。 そこで今回は、医療機器のソフトウェアテストで押さえておきたい考え方から具体的なテスト方法、要求・リスク・証跡のつなげ方までを実務の流れに沿って整理しました！ テスト計画の作成やレビュー、監査・承認申請に向けたプロセスの見直しに役立つ全体像を確認していきます。 import haihaiInquiryFormClient from "https://form-gw.hm-f.jp/js/haihai.inquiry_form.client.js";haihaiInquiryFormClient.create({baseURL: "https://form-gw.hm-f.jp",formUUID: "927d2c4e-f06c-45b1-bd36-0240e55ccf72",}) ▼テストの種類について詳しい内容はこちら▼ 【保存版】テストの目的別タイプ一覧 医療機器のソフトウェアテストは何が違う？安全・規格・検証の全体像をつかもう！ 医療機器のソフトウェアテストを理解するうえで、最初に押さえておきたいのが 一般的なソフトウェアテストとの目的の違い です。 もちろん、要求された機能が正しく動くか、不具合がないかを確認することは医療機器でも重要です。 ただし、それだけでは十分とはいえません。 医療機器では、ソフトウェアの誤動作や出力の誤りが患者への危害につながる可能性を考え、要求、設計、リスクコントロール、検証結果を関連付けながら安全性を確認していく必要があります。 JIS T 2304に基づくライフサイクルとリスクマネジメントを組み合わせ、単発の試験ではなく 開発プロセス全体で安全なソフトウェアを作り込む ことが基本となります。 個々のテスト技法から入るより、まず「安全性をどのような根拠で説明するのか」という全体像を理解すると、その後のテスト設計も整理しやすくなります。 「バグがない」だけでは足りない！医療機器でテストが重要になる理由 一般的なソフトウェアでも不具合は問題になりますが、医療機器ではその影響が診断や治療、患者の安全へ及ぶ可能性があります。 たとえば、測定値を誤って表示する、必要な警報が作動しない、通信異常によってデータが欠落するといった問題は、単なる使いにくさでは終わらない場合があります。 そのためテストでは、正常に動くことに加えて、 故障や誤入力、通信断、想定外操作が起きたときにも危険な状態へ進まないか を確認することが重要です。 さらに、「試験に合格した」という結果だけでなく、対象となる要求やリスク、実施条件、期待結果、実際の結果を追跡できる状態にしておく必要があります。 安全性はテスト工程だけで作るものではなく、要求定義、設計レビュー、リスクマネジメント、構成管理、問題解決などを含むライフサイクル全体で作り込むものです。 つまり、 不具合を見つけるテストから、安全性を根拠付きで確認するテストへ視点を広げること が医療機器では欠かせません。 規格は一つだけ見ればよい？テストに関係する規格の役割を整理しよう！ 医療機器ソフトウェアに関わる規格は複数ありますが、すべてを同じ目的のルールとして扱うと理解しにくくなります。 IEC 62304／JIS T 2304は、ソフトウェアの要求分析、設計、実装、検証、保守、構成管理、問題解決など、 ソフトウェアライフサイクルを管理するための軸 として考えると整理しやすくなります。 ISO 14971／JIS T 14971は、ハザードを特定し、関連するリスクを評価・コントロールして、その有効性を確認するためのリスクマネジメントの枠組みです。 ISO 14971:2019は2025年にも内容が確認され、現在も有効な版として扱われています。 このほか、ISO 13485は品質マネジメント、IEC 62366-1はユーザビリティ、IEC 81001-5-1／JIS T 81001-5-1はサイバーセキュリティといった役割があります。 特にネットワーク接続などを伴う医療機器では、サイバーセキュリティについても製品ライフサイクルを通じた対応が求められています。 大切なのは規格を別々にチェックすることではなく、 要求・リスク・設計・検証という一連の開発活動の中で関係付けること です。 ベリフィケーションとバリデーションを混同しない！それぞれの役割を押さえよう 医療機器開発では、V&V（Verification and Validation：検証と妥当性確認）という言葉がよく使われます。 ベリフィケーションは、作成した設計やソフトウェアなどが、あらかじめ定められた要求事項を満たしているかを確認する活動です。 たとえば、ソフトウェア要求仕様に「異常を検知して一定時間以内に警報を表示する」と定めている場合、その条件通りに機能するかを試験することが該当します。 一方、バリデーションでは、最終的な医療機器が 意図した使用目的や実際のユーザーニーズを満たしているか を確認します。 仕様書に書かれた内容を満たしていても、実際の医療現場で安全かつ適切に使用できなければ、製品として十分とはいえません。 そのため、医療従事者の操作、使用環境、合理的に予見できる誤使用なども含めて考える必要があります。 「仕様通りに作れているか」と「必要な医療上の目的を達成できるか」を分けて整理すると、単体・結合・システムテストと製品全体の妥当性確認を混同しにくくなります。 必要なテストを漏れなく整理！工程別・目的別に何を確認するか決めよう！ 医療機器だからといって、一般的なソフトウェアテストとはまったく異なる特殊な試験だけを行うわけではありません。 単体テスト、結合テスト、システムテストといった一般的なテストレベルを基本としながら、 安全性、リスク、規制要求、使用環境などの観点を加えていくこと がポイントです。 また、すべての機能を同じ深さで試験すればよいわけでもありません。 プログラム医療機器では、危害につながる可能性を踏まえてソフトウェア安全クラスを設定し、そのクラスに応じた対応を行う考え方があります。 製品の用途や構成、機能の重要度、リスクによって重点的に検証する部分は変わります。 テストケースの名称を揃えることよりも、 「何を保証するために、その試験を行うのか」まで明確にすること が重要です。 単体・結合・システムテスト！開発工程ごとの役割を明確にしよう 単体テストでは、関数やクラス、モジュールなど比較的小さな単位に分け、ロジックや計算処理、入力条件、例外処理などを確認します。 早い段階で問題を見つけられるため、後工程での大きな手戻りを防ぐうえでも重要です。 結合テストでは、複数のソフトウェアアイテムを組み合わせ、インターフェース、データ受け渡し、通信、処理順序などが設計通りに機能するかを確認します。 個々のモジュールが正常でも、接続部分でデータ形式やタイミングが食い違えばシステムとしては正しく動きません。 ソフトウェアシステムテストでは、統合されたソフトウェア全体が ソフトウェア要求事項を満たしているか を確認します。 ここでは、機能そのものだけでなく、安全性に関係する要求やエラー処理なども対象になります。 重要なのは、同じケースを各工程で繰り返すことではなく、それぞれのレベルで何を保証するのかを決め、リスクや安全クラスを踏まえて必要な深さを設定することです。 正常系だけでは危険！異常系・境界値・状態変化を重点的に確認しよう 通常の入力で期待通りに動作することを確認するだけでは、実際の使用環境で起こる問題を十分に見つけられません。 特に医療機器では、 異常が起きたときに危険な状態へ進まないこと が重要な確認ポイントになります。 入力値を扱う機能では、正常値だけでなく、最小値、最大値、閾値の直前と直後、不正な形式、欠損値などを確認します。 同値分割や境界値分析を利用すれば、すべての入力を試さなくても効率よく代表的な条件を選べます。 状態を持つソフトウェアでは、状態遷移テストを使い、正常な遷移だけでなく、許可されていない遷移や想定外イベントが発生した場合も確認します。 さらに、通信断、センサー異常、電源断、データ破損、処理途中の中断など、製品構成から合理的に予見できる異常状態を洗い出します。 思いつきで異常系ケースを増やすのではなく、 要求仕様とリスク分析から試験条件を導き出すこと が抜け漏れ防止につながります。 患者への影響から逆算！リスクコントロールが本当に効くか検証しよう 医療機器のテストでは、機能一覧から試験項目を作るだけでなく、 リスク分析からテストを逆算する考え方 が重要です。 ISO 14971では、ハザードを特定し、関連するリスクを評価し、必要なリスクコントロールを実施して、その有効性を確認するという流れでリスクを管理します。 たとえば、誤った値を入力すると危険な出力につながる可能性がある場合、入力範囲の制限や警告表示、処理の停止などをリスクコントロールとして実装することがあります。 テストでは、その安全機能が通常時に存在することを確認するだけでは十分ではありません。 実際に異常条件を発生させ、期待したタイミングで制御が働き、危険な状態への進展を防げるかまで確認します。 アラーム、インターロック、フェイルセーフなどについても同様です。 さらに、試験結果をリスク分析の記録へ結び付け、 どの試験がどのリスクコントロールの有効性を裏付けているか を説明できる状態にしておくことが重要です。 性能・ユーザビリティ・セキュリティも忘れない！機能以外の品質も確認しよう ソフトウェア要求を満たしていても、処理速度が遅すぎたり、操作を誤りやすかったり、外部から攻撃を受けやすかったりすれば、安全な医療機器とはいえません。 そのため、製品特性に応じて性能、ユーザビリティ、サイバーセキュリティなどの観点もテストへ組み込みます。 性能では、応答時間、処理量、連続稼働時の挙動、大量データを扱った際の変化など、医療上の使用目的へ影響する条件を確認します。 ユーザビリティでは、実際の使用者や使用環境を踏まえ、操作ミスや表示の読み違いが危険につながらないかを確認する視点が重要です。 ネットワーク接続や外部アクセスが想定される製品では、認証、権限管理、通信、脆弱性などのセキュリティ要求も対象になります。 国内では、対象となる医療機器について サイバーリスクを特定・評価・低減し、製品ライフサイクル全体でセキュリティを確保すること が求められています。 外部ライブラリやOSなどの構成要素も含め、製品の用途とリスクに応じて必要な検証を選ぶことが大切です。 修正したら終わりではない！変更影響と回帰テストまで設計しよう 不具合を修正したとき、「修正した機能が正常に動いたので完了」と判断するのは危険です。 ソフトウェアは複数のモジュールやインターフェースが関連しているため、小さな変更でも既存機能や安全機能へ思わぬ影響が広がる場合があります。 まず必要なのが、変更したコードだけを見るのではなく、依存するモジュール、データ、通信、共通部品、リスクコントロールなどへの 変更影響分析 です。 その結果をもとに、修正箇所そのものを確認する再テストと、影響を受ける可能性がある既存機能を確認する回帰テストの範囲を決めます。 また、機能追加や設計変更によって新しいハザードが生じたり、既存リスクの評価が変わったりする可能性もあります。 その場合は、テストだけでなくリスクマネジメントの記録も見直す必要があります。 医療機器ソフトウェアでは開発後の保守までライフサイクルとして捉えるため、 変更理由、影響範囲、実施した試験、その結果を追跡できる仕組み を最初から設計しておくことが重要です。 要求・リスクからテストケースへ！監査でも説明できる設計と運用にしよう！ 医療機器のソフトウェアテストの実務で難しいのは、テストケースそのものを作ることより、 「なぜこのテストが必要なのか」という根拠を残すこと です。 要求仕様、リスク分析、設計、試験仕様、試験結果が別々に管理されていると、個々の資料が正しくても全体として安全性を説明しにくくなります。 そこで重要になるのが、要求からテスト結果までを追跡できるトレーサビリティです。 さらに、不具合修正や仕様変更が起きた際にも、どの要求、リスク、試験へ影響するのかを確認できる状態が求められます。 サイバーセキュリティについても、適合性確認の実施を記録・保管し、必要に応じて説明できる体制が求められています。 文書を監査のためだけに作るのではなく、 開発チーム自身が品質判断を再現するための証拠として活用すること がポイントです。 まず要求をテスト可能にする！曖昧な仕様をそのまま試験へ持ち込まない よいテストケースを作るには、その前提となる要求がテスト可能な状態になっている必要があります。 たとえば、「すばやく表示する」「操作しやすい」「異常時は適切に警告する」といった要求では、試験を実施しても合格・不合格を客観的に判断できません。 「入力から何秒以内に表示する」「どの条件で、どの警告を出す」といった形で、 判定できる要求へ具体化すること が重要です。 入力条件、前提条件、期待される出力、性能値、エラー時の挙動などが明確であれば、試験ケースも一貫して作りやすくなります。 さらに、ソフトウェア要求だけを見るのではなく、上位のシステム要求、意図する使用、ユーザーニーズ、リスクコントロールとの関係も確認します。 要求に矛盾や抜けがある場合、テスト担当者が独自判断で補完してしまうと、後から判断根拠が分からなくなります。 テスト設計を早期から始め、 テストできない要求を上流工程へ戻すこと自体を品質活動として捉えること が大切です。 「このリスクにはこの試験」と言える！要求・リスク・テストを一本につなごう テストケースを大量に作っても、要求との対応関係が分からなければ、必要な検証を網羅できているか判断しにくくなります。 そこで、ユーザーニーズ、システム要求、ソフトウェア要求、リスクコントロール、テストケース、テスト結果を関連付けます。 要求側からテストをたどれば、 試験が用意されていない要求の発見 に役立ちます。 反対にテスト側から要求へ戻れば、「この試験は何を確認するために存在するのか」をチェックできます。 特に安全性に関わる要求では、リスク分析で設定したリスクコントロールがどの要求として実装され、どのテストによって有効性が確認されたのかを追跡できることが重要です。 こうした関係を一覧化する方法として、トレーサビリティマトリクスが利用できます。 単なる管理表にするのではなく、 「このリスクに対してこの設計を行い、この試験結果によって有効性を確認した」と説明するための地図 として使うと、レビューや変更影響分析にも役立ちます。 合否だけでは足りない！再現できるテスト仕様書と記録を残そう テスト結果に「合格」とだけ残しても、後から同じ条件で結果を再現できなければ十分な証跡とはいえません。 テスト仕様には、対象となる要求、テスト目的、前提条件、入力値、操作手順、期待結果、合否判定基準などを明確にします。 試験を実施した際には、実際の結果に加えて、使用したソフトウェアやハードウェアのバージョン、試験環境、テストデータなども記録しておくと再現性を高められます。 ログ、測定結果、画面記録など、 判定を裏付ける客観的な証拠 を残すことも重要です。 不合格が発生した場合は、問題を削除して新しい結果だけを残すのではなく、問題報告、原因調査、修正、再試験まで追跡できる形で管理します。 また、サイバーセキュリティについても適合性確認の結果や関連文書を特定し、説明できる状態が必要とされています。 資料の量を増やすことが目的ではなく、 第三者が後から見ても同じ判断にたどり着けるだけの情報を残すこと を基準にすると、過剰な文書化も避けやすくなります。 限られた工数でも品質を守る！リスクベースで優先順位を付けよう 現実の開発では、考えられるすべての入力値や状態、組み合わせをテストすることはできません。 そこで重要になるのが、 リスクに応じてテストの優先順位を変える考え方 です。 患者への危害につながる可能性が高い機能、複雑なアルゴリズムを持つ箇所、複数機能から利用される共通モジュール、過去に不具合が多かった部分などは、重点的に確認する候補になります。 変更頻度が高い領域も回帰不具合が入り込みやすいため、影響を考慮して試験を厚くします。 一方で、単純にテストケース数を増やしたり、コードカバレッジの数値だけを高めたりしても、安全性に関わる重要な条件を見逃していれば十分とはいえません。 ISO 14971では、リスクの特定・評価・コントロールと、その有効性をライフサイクルを通じて管理する枠組みが示されています。 テストレビューでも「何件実施したか」ではなく、 重要な要求とリスクを必要な深さで確認できているか を見ることで、限られた工数を有効に使いやすくなります。 自動化は目的ではない！回帰テストと証跡作成を効率化しよう テスト自動化は、医療機器ソフトウェア開発でも有効ですが、自動化率そのものを目標にすると本来の目的を見失いやすくなります。 向いているのは、毎回同じ条件で繰り返す単体テスト、既存機能の回帰テスト、大量の入力データを扱う試験などです。 変更のたびに手作業で同じ確認を行っている領域から自動化すれば、短時間で安定した結果を得やすくなります。 一方、実際の操作性を評価するユーザビリティテストや、人の観察や判断が重要となる探索的な確認など、手動で実施する価値が高い試験もあります。 重要なのは、自動と手動を競わせることではなく、 それぞれが得意な領域へ適切に配置すること です。 また、自動テストでも、対象バージョン、試験環境、入力、期待結果、実行結果を追跡できるようにします。 ツールを導入した結果、要求と試験結果の関係が見えなくなっては意味がありません。 「重要なリスクを短時間で繰り返し確認できるか」「変更時の影響をすばやく確認できるか」を基準に自動化対象を選ぶことがポイントです。 開発・品質保証・薬事で認識をそろえる！テストをチームの品質保証活動にしよう 医療機器のソフトウェアテストをテスト担当者だけの仕事にすると、要求、リスク、規制、設計の間に情報の分断が生まれやすくなります。 開発者は設計や実装を理解し、品質保証担当者はプロセスや記録を確認し、薬事担当者は承認・認証で求められる説明を意識しています。 それぞれが別々に作業するのではなく、 要求レビューやリスクレビューの早い段階から試験方法や必要な証拠を共有すること が重要です。 テスト担当者が上流工程へ参加すれば、試験できない要求や、検証方法が曖昧なリスクコントロールを早期に見つけやすくなります。 また、「誰が試験を実行するか」だけではなく、誰が要求を承認し、誰がリスク評価を確認し、誰が試験結果の妥当性を判断するのかまで役割を明確にしておく必要があります。 監査や申請の直前になって記録を集める運用ではなく、通常の開発活動そのものが証跡として残る仕組みにすると負担も減らせます。 市場で得た不具合情報や脆弱性情報も次のリスク分析や設計、テストへ戻し、 ライフサイクルを通じて品質を改善する体制 につなげることが大切です。 まとめ｜テストの数ではなく「安全を説明できる仕組み」を作ろう！ 医療機器のソフトウェアテストでは、単体テスト、結合テスト、システムテストを実施するだけでは十分ではありません。 患者や使用者への影響を考え、 どのリスクをどのような要求・設計によって低減し、それをどの試験で確認したのか を説明できる状態まで作ることが重要です。 IEC 62304／JIS T 2304によるソフトウェアライフサイクルと、ISO 14971／JIS T 14971によるリスクマネジメントを切り離さず、要求、設計、テスト、結果を一つの流れとして管理すると全体像を整理しやすくなります。 ネットワーク接続などを伴う医療機器では、サイバーセキュリティも開発時だけの確認事項ではなく、市販後を含むライフサイクル全体で管理する必要があります。 必要以上にテストケースや文書を増やすのではなく、重要な要求とリスクを特定し、そこへ重点的に検証工数を配分することも欠かせません。 まずは現在のプロジェクトについて、要求、リスクコントロール、テストケース、試験結果が互いに追跡できるかを確認すると、改善すべきポイントが見えやすくなります。 最終的に目指したいのは、「医療機器だから多くのテストを実施した」という状態ではなく、 「この試験結果があるから、この要求とリスクについて安全性を説明できる」と論理的に示せる状態 です。 QA業務効率化ならPractiTest テスト管理の効率化 についてお悩みではありませんか？そんなときはテスト資産の一元管理をすることで 工数を20%削減できる 総合テスト管理ツール「 PractiTest 」がおすすめです！ PractiTest (プラクティテスト) に関する お問い合わせ トライアルアカウントお申し込みや、製品デモの依頼、 機能についての問い合わせなどお気軽にお問い合わせください。 お問い合わせ この記事の監修 Dr.T。テストエンジニア。 PractiTestエバンジェリスト。 大学卒業後、外車純正Navi開発のテストエンジニアとしてキャリアをスタート。DTVチューナ開発会社、第三者検証会社等、数々のプロダクトの検証業務に従事。 2017年株式会社モンテカンポへ入社し、マネージメント業務の傍ら、自らもテストエンジニアとしテストコンサルやPractiTestの導入サポートなどを担当している。 記事制作： 川上サトシ （マーケター、合同会社ぎあはーと代表）

Webシステムや業務システムのテスト経験があっても、電子カルテでは「一般的なテストと何が違うのか」「どこまで確認すれば十分なのか」と迷いやすいものです。 電子カルテでは、単に画面や機能が仕様どおり動けばよいわけではありません。 患者情報の取り違え、診療記録の不整合、処方や検査結果の誤表示、外部システムとの連携不良などは、診療業務そのものへ影響する可能性があります。 そのため、 不具合が起きた場合に医療現場へどのような影響が生じるか を考えながらテストを設計することが重要です。 また、現在の電子カルテは電子処方箋管理サービスや電子カルテ情報共有サービスなど外部サービスとの接続も広がっており、システム単体だけで品質を考えることが難しくなっています。 そこで今回は、電子カルテのソフトウェアテストで押さえたいテストの種類から特有の観点、テストケースの作り方、優先順位の付け方まで実務の流れに沿ってまとめました！ 「何を・なぜ・どこまで確認するのか」を整理し、テスト計画やレビューで根拠を説明できる状態を目指しましょう。 import haihaiInquiryFormClient from "https://form-gw.hm-f.jp/js/haihai.inquiry_form.client.js";haihaiInquiryFormClient.create({baseURL: "https://form-gw.hm-f.jp",formUUID: "927d2c4e-f06c-45b1-bd36-0240e55ccf72",}) ▼テストの種類について詳しい内容はこちら▼ 【保存版】テストの目的別タイプ一覧 電子カルテのソフトウェアテストは何が違う？まず全体像をつかもう！ 電子カルテのソフトウェアテストを考える際は、最初から細かなテスト項目を作成するのではなく、 品質を守る対象がどこまで広がっているか を把握することが大切です。 患者情報や診療記録など電子カルテ内部の機能だけでなく、医療機関内の各システムや外部サービスとの接続、利用者が集中した場合の性能、障害発生時の継続利用なども確認対象になります。 実際の標準型電子カルテの開発でも、単体・結合・総合という工程別テストだけでなく、シナリオ、ユーザビリティ、負荷、脆弱性、受入れなど幅広いテストが組み込まれています。 まずは「どの工程で、どの品質リスクを確認するのか」を整理してから、具体的なテストケースへ落とし込むことが重要です。 電子カルテでは「機能が動く」だけでは品質を守れない！ 一般的な業務システムでも仕様どおりの動作は重要ですが、電子カルテではさらに 誤った情報が診療判断や業務へ影響しないこと まで考えて確認する必要があります。 たとえば患者検索が正常に動作していても、同姓同名の患者を見分けにくい表示になっていれば、実際の運用では患者を取り違えるリスクが残ります。 処方登録の処理が成功していても、患者・薬剤・用量・日時などが正しく保持されていなければ、機能として十分とはいえません。 さらに、医師が診療記録を入力し、検査や処方を指示し、その結果を別の職種が確認するといった一連の流れが成立するかも確認します。 「仕様に合っているか」と「医療現場で安全に使えるか」を両方見ること が、電子カルテのテストで欠かせない視点です。 単体・結合・総合・受入テストの役割を整理しよう！ 電子カルテでも、開発工程に応じて単体テスト、結合テスト、総合テスト、受入テストを使い分けます。 単体テストでは入力チェックや登録・更新処理など個々の機能を確認し、結合テストでは患者情報、診療記録、オーダー、検査結果などが機能間で正しく受け渡されるかを確認します。 総合テストになると、本番に近い構成で診療シナリオや外部システム連携、性能、障害時の動作など、システム全体の品質を確認する範囲が中心です。 受入テストでは、実際に利用する医療機関側の視点から、想定した業務を問題なく行えるかを確認します。 標準型電子カルテの開発でも、テスト体制、環境、スケジュール、シナリオ、評価方法、合否判定基準を含む全体テスト計画が求められています。 各工程で何を保証するのかを分けること が、重複と抜け漏れを防ぐポイントです。 機能テストだけでは足りない！押さえるべきテスト種類を整理しよう！ 電子カルテでは、患者登録や診療記録、処方、検査などが仕様どおり動くかを見る機能テストが基本になります。 一方で、それだけでは実際の利用環境で発生する問題を十分に見つけられません。 受付から診察、検査、処方などの流れを確認する シナリオテスト 、他システムとの情報交換を見る連携テスト、大量アクセスやデータ量を想定する性能・負荷テストも必要です。 さらに、認証や権限、脆弱性などを見るセキュリティテスト、障害時のバックアップ・復旧確認、仕様変更後に既存機能が壊れていないかを見る回帰テストも重要になります。 標準型電子カルテの開発では、シナリオテスト、ユーザビリティテスト、アクセシビリティテスト、回帰テスト、負荷テスト、脆弱性診断、受入テストなども実施対象に含まれています。 機能・業務・連携・非機能の4方向からテスト種類を整理する と全体像をつかみやすくなります。 重大な不具合を見逃さない！電子カルテ特有のテスト観点を押さえよう！ 電子カルテ特有のテスト観点を洗い出す際は、画面や機能の一覧を順番に確認するだけでは十分ではありません。 重要なのは、 どの不具合が患者や診療業務へ大きな影響を与えるか から逆算することです。 患者情報、診療記録、処方、検査結果、利用者権限、外部システム連携などは、特に重点的に確認したい領域になります。 また、平常時だけでなく、通信断やシステム障害、データ量の増加など、実運用で起こり得る条件を加えて考える必要があります。 電子カルテの標準仕様でも、可用性やデータ保管、バックアップ、セキュリティなどが重要な非機能要件として扱われています。 ここからは、テストケースへ具体的に反映したい代表的な観点を整理します。 患者情報の取り違えを防ぐテストを最優先にしよう！ 電子カルテで特に慎重に確認したいのが、 表示・入力している情報が正しい患者に紐づいているか という点です。 通常の患者検索だけでなく、同姓同名、似た氏名、同一生年月日など、取り違えが起こりやすい条件を用意して確認します。 複数患者のカルテを連続して開くケースでは、前に閲覧していた患者の情報や入力内容が別患者の画面へ残らないことも重要です。 患者基本情報を変更した場合には、診療記録や関連機能、連携先システムとの間で古い情報と新しい情報が混在しないかも確認します。 さらに、患者情報の訂正や統合など日常的な登録処理から外れるケースでは、過去データとの対応関係が崩れないことも確認対象です。 正常な操作だけでなく、途中キャンセル、画面切り替え、複数画面の利用、通信断などを組み合わせる と、実運用に近いリスクを拾いやすくなります。 診療記録・処方・検査は「業務の流れ」で確認しよう！ 診療記録、処方、検査をテストする場合は、それぞれを独立した機能として見るだけでなく、 前後の業務と正しくつながっているか を確認します。 診療記録では、入力、保存、追記、訂正、履歴確認までを通して、情報が矛盾なく保持されているかを見ることが重要です。 処方や各種オーダーでは、患者、薬剤、用量、日時など必要な情報が正しく登録され、変更や中止を行った場合にも最新状態が適切に反映されるか確認します。 検査では、依頼を登録して終わりではなく、検査側で処理され、結果が電子カルテへ戻り、正しい患者の画面へ表示されるまでを一連のシナリオとして捉えます。 また、医師だけでなく、看護師、検査部門、医事担当者など複数の利用者をまたぐ流れも確認します。 一つひとつの機能が正常でも、業務全体では成立しないケースがある ため、職種やシステムをまたいだ確認が欠かせません。 外部システムとの連携は「送れたか」だけで終わらせない！ 現在の電子カルテでは、レセプトコンピュータ、検査システム、画像関連システム、電子処方箋管理サービス、電子カルテ情報共有サービスなど、複数のシステム・サービスとの連携が発生します。 そのため連携テストでは、通信が成功したことだけでなく、 送信した情報が相手側で正しく解釈され、業務で利用できる状態になっているか まで確認することが重要です。 患者識別情報、コード、日時、単位、ステータスなどが送信元と受信先で一致しているかを確認します。 対象システムによっては、HL7（Health Level Seven）、FHIR（Fast Healthcare Interoperability Resources）、DICOM（Digital Imaging and Communications in Medicine）などの医療情報標準も関係します。 電子カルテ情報共有サービスでもFHIRを用いた情報連携の技術仕様が整備されています。 通信失敗、タイムアウト、再送、重複送信、順序の入れ替わりなども加え、 連携異常がデータ欠落や二重登録につながらないか を確認することが大切です。 権限・セキュリティは「見えてはいけない情報」から考えよう！ 電子カルテでは多くの診療情報を扱うため、セキュリティテストでは「必要な利用者が使えるか」だけでなく、 権限のない利用者から情報を守れているか を見ることが重要です。 医師、看護師、医事担当者、システム管理者など役割ごとに権限を整理し、閲覧・登録・変更・削除できる範囲が想定どおりになっているか確認します。 画面上でメニューを隠しているだけではなく、直接的な画面遷移や不正なリクエストでも権限を超えた操作ができないことまで検証する必要があります。 ログイン、ログアウト、セッション切れ、認証失敗などの異常系も確認対象です。 また、重要な情報へのアクセスや変更を追跡できるよう、必要な操作履歴が正しく記録されることも確認します。 電子カルテの標準仕様では、セキュリティ要件に加えて脆弱性診断やペネトレーションテストも検討対象となっています。 アプリの機能テストと専門的なセキュリティ検証を分けて計画すること が重要です。 障害・性能・バックアップは「診療を止めない」視点で確認しよう！ 電子カルテは日々の診療業務で継続して利用されるため、正常時の機能確認だけでなく、 負荷や障害が発生したときにどの程度業務を維持できるか も重要な品質項目です。 利用者が集中した場合に、患者検索やカルテ表示、オーダー入力など主要操作の応答時間が大きく悪化しないか確認します。 性能テストでは、少量のテストデータだけでなく、本番運用で想定される患者数や診療記録の蓄積量を考慮することも重要です。 サーバー、ネットワーク、外部サービスなどに障害が発生した場合には、利用可能な機能と利用できなくなる機能を確認します。 バックアップについても「取得に成功した」で終わらせず、実際にリストアして必要なデータを復元できるかまで確認します。 標準仕様では可用性、バックアップ、セキュリティなどが非機能要件として扱われ、標準型電子カルテの設計でもシステムバックアップやデータバックアップ、障害時の縮退・継続運転が検討対象になっています。 障害発生後に二重登録や未送信データが残っていないかまで確認すること がポイントです。 抜け漏れを減らす！電子カルテのテスト設計を実務に落とし込もう！ テスト観点を理解していても、そのままでは実際のテストケースにはなりません。 電子カルテのテスト設計では、 要件・業務・リスクを結び付けて具体的な確認条件へ変換する作業 が重要になります。 まず要件定義書や設計書からシステムの機能を把握し、それぞれを利用する職種や業務の流れを整理します。 次に、「この機能で問題が起きた場合に何が困るのか」を考え、リスクの大きい部分から観点を広げていきます。 そのうえで、正常系、異常系、境界値、状態遷移、権限差、連携異常などをテストケースへ具体化します。 テスト工数が限られる場合には、全機能を同じ密度で確認するのではなく、重要度に応じて確認の深さを変えることも必要です。 いきなりテストケースを書かず、要件と業務フローを整理しよう！ テスト設計を始める際、設計書の機能一覧からすぐに操作手順を書き始めると、 機能間や職種間のつながりにあるリスクを見落としやすくなります。 まずは「誰が、どのタイミングで、何のために使う機能なのか」を整理します。 たとえば受付、診察、検査、処方、会計という流れを可視化すると、患者情報やオーダー情報がどこで生成され、どのシステムへ渡されるのかが把握しやすくなります。 そのうえで、正常系だけでなく、入力値の境界、処理途中での中断、ステータス変更、利用者権限の違いなどへ観点を広げます。 仕様書を読んでも期待結果が判断できない箇所は、単なるテスト担当者の疑問として処理せず、仕様上の曖昧さとして早い段階で確認することが重要です。 テスト設計を「完成した仕様を確認する工程」ではなく、仕様の抜けや矛盾を見つける品質活動として扱う ことで、後工程での手戻りも減らしやすくなります。 「リスク×機能×業務」でテスト観点を洗い出そう！ 電子カルテのテスト観点を効率よく洗い出すには、機能一覧だけでなく、 起こしてはいけない問題から逆算する方法 が有効です。 まず、患者取り違え、処方情報の誤り、検査結果の誤表示、診療業務の停止、情報漏えいなど、影響の大きい事象を整理します。 次に、それぞれの事象につながる可能性がある機能、データ、利用者、外部システムを紐づけます。 同じ発生可能性でも、患者や診療への影響が大きい問題ほど優先順位を高くします。 高リスクの機能では正常系だけでなく、異常系、境界値、権限差、通信障害など複数の条件を組み合わせて確認します。 一方、低リスクの機能まで同じ密度でテストすると、工数が増える一方で重要部分へ十分な時間を割けなくなる可能性があります。 「この不具合が起きたら何が困るか」を説明できる状態にしてからケース数を決める と、テストの優先順位にも根拠を持たせやすくなります。 実際の診療を想定したシナリオへ落とし込もう！ シナリオテストでは、一画面の入力やボタン操作を確認するのではなく、 実際の診療業務が最初から最後まで成立するか を確認します。 たとえば、患者受付、診察、オーダー登録、検査実施、結果確認、処方という一連の流れを一つのシナリオとして設計します。 新患と再来、外来と入院など業務条件が異なる場合は、重要なパターンを分けて用意します。 さらに、処方内容を途中で変更する、検査を中止する、患者情報を訂正するなど、現場で起こり得る分岐を追加すると実践的なテストになります。 複数の職種や端末、外部システムをまたぐ場面では、前工程の処理結果が後工程へ正しく伝わっているかも確認します。 標準型電子カルテの開発でもシナリオテストや利用者による受入テストが明確に位置付けられています。 期待結果は「エラーが出ない」とするのではなく、 画面表示、登録データ、連携データ、ステータスまで具体化する ことが大切です。 時間が足りないときこそ、テストの優先順位を明確にしよう！ 実務ではテスト期間や要員が限られているため、すべての機能を同じ深さで確認することは現実的ではありません。 そこで、 患者への影響、業務への影響、利用頻度、変更量、過去の障害実績 などを使って優先順位を決めます。 患者情報、診療記録、処方、検査、重要な外部連携など、問題発生時の影響が大きい領域にはテスト工数を厚く配分します。 仕様変更が入った場合は、変更した機能だけを見るのではなく、同じデータを利用している画面や後続処理、外部連携まで影響範囲を追うことが重要です。 繰り返し確認する回帰テストでは自動化を活用し、人による判断が必要な診療シナリオやユーザビリティ確認へ時間を振り分ける方法もあります。 標準型電子カルテの開発でも、反復して実施するテストは原則として自動化する方針が示されています。 また、不具合件数だけで品質を判断せず、重大な未解決不具合、重要シナリオの結果、残存リスクなどを踏まえて テスト開始前に終了条件と合否基準を決めること が重要です。 テスト結果を次の品質改善につなげよう！ テストで見つかった不具合は、修正して再テストが通れば終わりとするのではなく、 なぜ発生し、なぜそれまで見つからなかったのか まで振り返ることで次の品質改善につながります。 原因を要件漏れ、仕様の曖昧さ、設計ミス、実装ミス、テスト観点不足などに分類すると、同じ種類の問題を予防しやすくなります。 一つの画面で見つかった不具合でも、共通部品や同じロジックを利用している別機能へ横展開して確認することが重要です。 また、レビューで繰り返し指摘される観点はチェックリストやテスト設計ガイドへ蓄積すると、担当者による品質のばらつきを抑えやすくなります。 仕様変更やバージョンアップ時には、既存のテストケースも見直し、現在の業務や仕様と合わなくなったケースを更新します。 電子カルテでは医療業務とソフトウェア品質の両方の知識が求められるため、必要に応じて医療機関の実務担当者や品質保証の専門担当者をレビューへ加えることも有効です。 テスト結果を次の設計やテスト計画へ戻す仕組みを作ること が、長期的な品質向上につながります。 まとめ｜電子カルテのテストは「医療現場のリスク」から逆算しよう！ 電子カルテのソフトウェアテストでは、一般的な機能確認に加えて、患者情報、診療業務、外部システム連携、セキュリティ、性能、障害復旧など幅広い観点が必要です。 重要なのは、テストケースの数を増やすことではありません。 「どの不具合を本番環境へ出してはいけないのか」を明確にし、そのリスクから必要な確認内容を逆算すること が重要です。 要件と診療業務の流れを整理し、患者安全や業務への影響と各機能を結び付ければ、電子カルテ案件の経験が浅い場合でもテスト観点を体系的に洗い出しやすくなります。 限られた工数の中では、患者情報、診療記録、処方・検査、重要な外部連携など影響度の高い部分へ重点的にテストを配分することも欠かせません。 また、電子カルテ情報共有サービスなど外部とのデータ連携が広がる中では、電子カルテ単体の正常動作だけでなく、複数システムをまたいだ品質保証の重要性もさらに高まっています。 まずは担当システムについて、 「重大な問題につながるリスク」「主要な診療シナリオ」「外部システムとの連携」 の3点を整理し、現在のテスト計画に不足がないか確認するところから始めましょう。 QA業務効率化ならPractiTest テスト管理の効率化 についてお悩みではありませんか？そんなときはテスト資産の一元管理をすることで 工数を20%削減できる 総合テスト管理ツール「 PractiTest 」がおすすめです！ PractiTest (プラクティテスト) に関する お問い合わせ トライアルアカウントお申し込みや、製品デモの依頼、 機能についての問い合わせなどお気軽にお問い合わせください。 お問い合わせ この記事の監修 Dr.T。テストエンジニア。 PractiTestエバンジェリスト。 大学卒業後、外車純正Navi開発のテストエンジニアとしてキャリアをスタート。DTVチューナ開発会社、第三者検証会社等、数々のプロダクトの検証業務に従事。 2017年株式会社モンテカンポへ入社し、マネージメント業務の傍ら、自らもテストエンジニアとしテストコンサルやPractiTestの導入サポートなどを担当している。 記事制作： 川上サトシ （マーケター、合同会社ぎあはーと代表）