介護ソフトのテストを任されたものの、「一般的な業務システムと同じ観点で確認してよいのだろうか」と迷うケースは少なくありません。 介護ソフトには利用者情報の管理だけでなく、アセスメント、ケアプラン、介護記録、サービス実績、各種帳票、介護報酬請求など、介護現場のさまざまな業務が集約されています。 そのため、個々の画面が仕様通りに動いていることだけを確認しても、十分なテストとはいえません。 たとえば、介護記録への入力自体は正常でも、その情報がサービス実績や帳票、請求処理へ正しく反映されなければ、現場では重大な問題につながります。 さらに介護分野では、介護報酬改定によって算定基準や通知などが変更されたり、LIFE（科学的介護情報システム）のCSV連携仕様が更新されたりするため、外部制度の変更にも継続して対応する必要があります。 2026年7月には介護情報基盤との連携に関するインタフェース仕様書第2.1版も公開されており、介護ソフトの品質保証では自社システムの画面だけでなく、外部システムとのデータの流れまで見る重要性が高まっています。 そこで今回は、 介護業界のソフトウェアテストで押さえたい考え方と具体的なテスト観点を、業務・制度・データ連携の流れで整理しました！ 介護業務を詳しく知らない状態からでも、重大な不具合につながるポイントを見つけやすくするための基本を確認していきます。 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",}) ▼テストの種類について詳しい内容はこちら▼ 【保存版】テストの目的別タイプ一覧 まずここを押さえよう！介護ソフトのテストが一般的な業務システムと違う理由 介護ソフトのテストで重要なのは、 機能そのものではなく、その機能が介護業務全体の中でどのような役割を持っているか を理解することです。 一般的なWebサービスであれば、入力、検索、更新、削除などの機能単位でテスト項目を整理しやすいケースがあります。 一方、介護ソフトでは利用者情報や介護記録が別の画面や帳票へ連携し、最終的にはサービス実績や介護報酬請求へ影響することがあります。 前工程で発生した小さなデータ不整合が、複数の処理を経たあとに請求金額の誤りとして表面化する可能性もあります。 また、介護サービスには制度上の算定条件や適用期間などが存在するため、「システムとして正しく動いているか」だけでなく、 制度上のルールに照らして正しい結果になっているか も確認しなければなりません。 すべての機能を同じ深さでテストするのではなく、請求、個人情報、介護記録、外部提出データなど、問題が発生した際の影響が大きい領域から優先順位を付ける考え方も大切です。 画面が動くだけでは不十分！介護業務の「つながり」からテストしよう 介護ソフトでは、一つの画面だけを見て正常かどうかを判断すると、機能間で発生する不具合を見逃しやすくなります。 利用者を登録したあと、アセスメントを実施し、ケアプランやサービス予定を作成し、実際のサービス提供内容を記録して実績を確定し、その情報を帳票や請求へ使用するというように、業務は連続しています。 したがって、テストケースを設計するときは、 入力した情報が次にどこへ渡り、最終的に何へ使われるのか を追いかけることが重要です。 たとえば利用者の認定情報を変更した場合、その変更が対象画面だけでなく、予定、実績、帳票、請求処理へ正しく反映されるかまで確認します。 各画面の単体テストでは問題がなくても、データを受け渡す際の変換処理や更新処理に不具合が潜んでいる場合があります。 そのため、単体テストや結合テストに加えて、 実際の介護業務を最初から最後まで再現するシナリオテスト を取り入れると、実運用で発生する不整合を発見しやすくなります。 制度を知らないままテストしない！仕様の根拠を先に確認しよう 介護ソフトの仕様には、介護報酬、各種加算、サービスコード、適用期間、帳票など、介護制度に基づいて設計されている部分が数多くあります。 そのため、画面仕様書だけを見ながら期待結果を作ってしまうと、「仕様書通りではあるものの制度上は誤っている」という問題を見逃す可能性があります。 テスト設計では、 その仕様が何を根拠に決められているのか を確認することが大切です。 介護報酬改定では算定基準や関連通知などが変更されるため、変更内容が要件やシステム仕様へ正しく落とし込まれているかも確認する必要があります。 制度知識に不安がある場合は、QA担当者だけで正常・異常を判断せず、介護業務に詳しい担当者やプロダクト担当者と期待結果を共有します。 また、テスト開始後に仕様の曖昧さへ気付くのではなく、要件定義書や設計書を事前にレビューし、矛盾や条件漏れを見つけることも品質保証の重要な工程です。 テストとは完成したプログラムだけを確認する作業ではなく、仕様そのものが正しいかを確かめる活動でもある と考えると、重大な不具合を早い段階で防ぎやすくなります。 全項目を均等に確認しない！重大事故につながる機能から優先しよう 介護ソフトには多くの機能があり、サービス種別や利用者条件、加算などを掛け合わせると、テストパターンは急激に増えていきます。 すべての組み合わせを同じ深さで確認しようとすると、テスト工数が膨らむ一方で、本当に重要な部分へ十分な時間を使えなくなる可能性があります。 そこで有効なのが、 不具合が発生したときの影響度からテストの優先順位を決める考え方 です。 たとえば請求金額が誤る、必要な介護記録が失われる、別の利用者の個人情報が表示される、外部へ誤ったデータを送信するといった問題は、業務や事業所の運営へ大きな影響を与える可能性があります。 一方、表示上の軽微なずれなどは、同じ不具合であっても優先度が異なります。 「どこにバグがありそうか」だけでなく、 「そこでバグが起きたら何が起こるか」から逆算してテスト対象を選ぶ ことが重要です。 請求、利用者情報、介護記録、権限、帳票、外部連携などを重点領域として整理し、リリース前に必ず確認する範囲をあらかじめ決めておくと、限られた期間でも品質を守りやすくなります。 重大な不具合を防ぐ！介護ソフトで重点的に確認したいテスト観点 介護ソフトのテストでは、一般的な入力チェックや画面遷移に加えて、介護業務ならではの観点をテストケースへ落とし込む必要があります。 中心になるのは、利用者情報、介護記録、ケアプラン、サービス予定・実績、介護報酬請求、帳票、権限管理、外部システムとのデータ連携です。 重要なのは、それぞれを独立した機能として確認するだけではありません。 一つのデータが複数の機能へどのように流れるかを確認すること が、介護ソフトの品質を高めるポイントになります。 また、正常なデータを入力して期待通りの結果になることだけでは、実際の現場で起きる問題を十分に再現できません。 日付の境界、入力漏れ、予定変更、修正、重複操作、通信断、複数職員による同時操作などもテストへ組み込みます。 介護現場では毎日継続してシステムが使われるため、単に機能が動くかだけでなく、 実際の運用の中で安全に使い続けられるか まで確認することが大切です。 利用者情報・介護記録・ケアプランは「登録できる」だけで終わらせない！ 利用者情報では、氏名や生年月日の登録だけでなく、認定情報、負担割合、サービス利用期間など、後続処理へ影響する項目を重点的に確認します。 必須項目が空欄の場合、入力可能な最大文字数を超えた場合、過去の日付や想定外の値を入力した場合など、正常系以外のケースも必要です。 特に重要なのが、 登録後に情報を変更した場合の影響 です。 たとえば認定情報を変更したとき、利用者画面だけが更新されても、ケアプランや実績、帳票、請求処理に古い情報が残っていれば、業務上の不整合が発生します。 介護記録についても、登録できることだけでなく、修正や削除を行った場合の履歴、関連帳票への反映、集計結果への影響を確認します。 複数の職員が同じ利用者情報を同時に開いた場合には、後から保存した内容で意図せず上書きされないかも確認が必要です。 また、利用者を取り違えて記録を登録することは重大な問題につながるため、 別利用者への誤登録を防ぎやすい画面・操作になっているか という使いやすさの観点も含めて評価します。 予定・実績・介護報酬請求は最重要！金額まで一連の流れを確認しよう 介護ソフトの中でも特に慎重にテストしたいのが、サービス予定から実績、介護報酬請求へつながる領域です。 サービスを予定通り提供したケースだけでなく、キャンセル、時間変更、回数変更、月途中での状態変更など、現場で発生しやすいパターンを用意します。 そのうえで、実績へ正しく反映され、対象となるサービスや加算が適切に判定され、最終的な請求データまで正しく作成されるかを確認します。 加算については、算定条件をすべて満たすケースだけでは不十分です。 条件を満たすケース、条件を一部だけ満たすケース、条件を満たさないケース を分けて確認すると、誤算定を発見しやすくなります。 単位数や利用者負担などの計算結果についても、画面表示が正しいだけで判断せず、最終的に生成される請求データと一致していることまで追跡します。 介護報酬は2026年度にも改定が行われ、算定基準や関連通知が変更されています。 そのため請求機能では、通常時の正しさに加えて、 制度変更後も旧条件が誤って残っていないか という回帰テストも欠かせません。 境界値と日付条件を狙おう！介護制度ならではの異常系を洗い出す システムの不具合は、通常の利用パターンよりも「条件が切り替わる瞬間」で発生しやすい傾向があります。 介護ソフトでは特に、月末と月初、年度の切り替え、制度改定日、認定期間の開始日と終了日、加算の適用開始日と終了日など、 日付の境界を意識したテスト が重要です。 たとえば4月1日から新しいルールを適用する場合、3月31日、4月1日、4月2日でそれぞれ正しい処理になるかを確認します。 回数や数量についても、0回、1回、上限値、上限を1回超えた値など、条件が変化する前後をテストします。 入力データについては、空欄、不正な文字、桁数超過、重複、存在しないコードなどを使い、異常なデータをシステムが適切に扱えるか確認します。 さらに介護業務では、すでに確定した過去月の記録や実績を修正するケースも考えられます。 その場合は、変更後の情報だけでなく、 修正によって関連する帳票や請求結果がどこまで変わるのか まで確認しておく必要があります。 帳票・権限・個人情報も忘れない！現場運用まで含めて確認しよう 介護ソフトでは入力した情報をさまざまな帳票へ出力するため、画面上の値と帳票の内容が一致しているかも重要なテストポイントです。 項目の欠落、途中で切れる文字、古い情報の表示、ページ分割によるレイアウト崩れなど、データ内容と出力形式の両方を確認します。 特に情報を修正した場合は、変更内容が対象となるすべての帳票へ反映されているかを確認することが大切です。 また、介護ソフトでは利用者の個人情報を扱うため、 職員ごとの権限管理 も重点的にテストする必要があります。 職種や役割によって、閲覧、登録、編集、削除、承認などの操作範囲が正しく制限されているかを確認します。 退職や異動によって権限を変更したあとも、以前の権限で操作できないことを確認しておくと安心です。 さらに、誰がいつどの情報を変更したのかを追跡できる操作履歴や変更履歴も、トラブル発生時の調査に役立ちます。 別利用者の情報が表示される、権限のない職員が閲覧できる、誤った帳票を出力できる といった問題は高リスクとして扱い、優先的に確認します。 スマホ・タブレット・通信断まで再現！「介護現場で使えるか」を確かめよう 介護記録などを現場で入力するシステムでは、パソコンだけでテストを完了させないことも重要です。 実際に利用されるスマートフォンやタブレットを用意し、画面サイズの違いやタッチ操作を含めて確認します。 ボタンが小さすぎないか、入力項目が多すぎないか、必要な情報へすぐ移動できるかなど、 忙しい介護現場でも迷わず操作できるか という視点が欠かせません。 機能として正しく動いていても、一件の記録に多くの操作が必要であれば、現場の負担を増やす可能性があります。 さらに、施設内すべての場所で安定した通信環境が利用できるとは限りません。 通信速度が低下した場合、一時的に接続が切れた場合、通信が復旧した場合を再現し、入力内容が失われないか確認します。 オフライン対応や同期機能がある場合は、復旧後に同じデータが二重登録されたり、古い情報で新しいデータが上書きされたりしないかもテストします。 「仕様通り動くか」と「実際の介護現場で無理なく使えるか」は別の品質 として評価することが大切です。 制度改定・外部連携に強くなろう！変更に振り回されないテスト設計の進め方 介護ソフトの品質を長期的に守るには、リリースのたびにテストケースを一から考える方法では限界があります。 介護報酬の改定や外部システムの仕様変更が発生すると、自社で直接変更した機能だけでなく、そのデータを参照する帳票や請求、連携機能まで影響を受ける可能性があります。 さらに、LIFEでは介護ソフト向けのCSV連携仕様が継続して更新されており、2026年5月にも関連仕様が更新されています。 介護情報基盤についても2026年7月に連携用インタフェース仕様書第2.1版が公開されているため、外部仕様の変更を検知し、自社への影響を確認する仕組みが重要になっています。 そこで必要になるのが、 変更影響分析、シナリオテスト、回帰テスト、自動化、業務担当者とのレビュー を組み合わせたテスト体制です。 個々の担当者の経験だけに依存せず、「変更されたらどこを見るか」をチームで再利用できる形にしておくことで、制度変更が続いても品質を安定させやすくなります。 介護報酬改定は「変更された数字」だけをテストしない！ 介護報酬改定への対応では、変更された単位数だけ確認すれば十分というわけではありません。 算定条件、加算、適用時期、関連する通知、帳票など、変更によって影響を受ける範囲を広く確認する必要があります。 2026年度の介護報酬改定でも、算定基準に関する告示や通知などが改正されています。 テスト設計では、まず制度変更の内容とシステムの機能を対応付け、 どの変更がどの画面・計算・帳票・データ出力へ影響するのか を一覧化します。 そのうえで、直接修正した機能だけでなく、そのデータを利用する後続機能までテスト対象へ広げます。 特に重要なのが、新旧ルールの切り替えです。 改定日前日、改定日当日、改定日翌日のデータを作成し、それぞれに正しいルールが適用されるかを確認します。 また、改定前から利用している利用者と改定後に登録した利用者が混在するケースなども検証すると、実運用に近い確認ができます。 「変更箇所をテストする」のではなく、「変更によって結果が変わる場所をすべて探す」 ことが制度改定テストのポイントです。 LIFE・ケアプラン・介護情報基盤は「ファイルが出た」で終わらせない！ 介護ソフトは、自社システムだけで業務が完結するとは限りません。 LIFE、ケアプランデータ連携、介護情報基盤など、外部システムとの間でデータを受け渡す場面が増えています。 LIFEではCSV連携の標準仕様が継続して更新されており、介護ソフト側でも最新仕様へ追随する必要があります。 介護情報基盤についてもAPI（Application Programming Interface：システム同士が情報をやり取りするための仕組み）やインタフェースに関する仕様が整備されています。 外部連携テストでは、「CSVファイルが出力できた」というところで終わらせず、 入力元→データ変換→ファイルやAPIへの出力→送信→外部側での取り込み まで一つの流れとして確認します。 必須項目、桁数、コード値、文字コード、データ形式、仕様バージョンなども確認対象です。 さらに、欠損データ、不正コード、重複データ、旧形式のデータを送った場合のエラー処理もテストします。 通信失敗時に適切なエラーが表示されるか、再送によってデータが重複しないかまで確認しておくと、外部連携時のトラブルを減らしやすくなります。 機能単位から卒業！「記録から請求まで」のシナリオテストを作ろう 介護ソフトのテスト品質を高めるには、機能一覧からテストケースを作るだけでなく、 実際の介護業務を一つのストーリーとして再現する方法 が有効です。 たとえば、利用者を新規登録し、認定情報を設定し、ケアプランを作成し、サービス予定を登録します。 その後、実際にサービスを提供した想定で介護記録を入力し、実績を確定させ、加算の条件を満たしているかを確認し、帳票と請求データを作成します。 この一連の処理を通すことで、一つひとつの機能テストでは気付きにくいデータ連携の不整合を発見しやすくなります。 さらに、予定通り進むケースだけでなく、途中でサービスをキャンセルする、担当職員を変更する、記録を修正する、認定情報を更新するといったイベントを加えます。 画面表示だけを見るのではなく、帳票、外部出力、請求結果などを突き合わせて整合性を確認することも重要です。 本番環境で発生した問い合わせや障害についても、同じ条件を再現するシナリオを作り、回帰テストへ追加します。 こうして 現場で実際に起きた問題をテスト資産へ変えていく ことで、同じ不具合の再発を防ぎやすくなります。 回帰テストを仕組み化！制度変更のたびにゼロから確認する状態をなくそう 新しい機能を追加したり制度改定へ対応したりした際には、修正した部分だけではなく、既存機能が壊れていないかを確認する回帰テストが必要です。 介護ソフトでは各機能がデータでつながっているため、一見関係のなさそうな変更が請求や帳票へ影響するケースも考えられます。 まず、利用者情報、介護記録、実績、請求、権限、帳票、外部連携など、 リリースごとに必ず確認する重要機能 を固定します。 さらに、過去に発生した重大障害や問い合わせの多かった機能も回帰テストへ追加します。 変更が発生した際には、「直接修正した機能」と「そのデータを参照している機能」を分けて影響範囲を整理すると、確認漏れを防ぎやすくなります。 何度も同じ手順を繰り返すテストについては、自動化も有効です。 一方で、使いやすさや複雑な介護業務の判断など、人が確認した方が適している部分まで無理に自動化する必要はありません。 自動化率を高めることではなく、重要な不具合を早く検知できる状態を作ること を目的に、自動テストと手動テストを使い分けます。 テスト担当だけで抱えない！介護業務・開発・品質保証が一緒に品質を守ろう 介護ソフトでは、テスト技術だけで品質を守ることは難しく、介護業務や制度に関する知識も欠かせません。 一方で、QA（Quality Assurance：品質保証）担当者が介護制度のすべてを一人で理解するのも現実的ではありません。 そこで、開発担当者、QA担当者、プロダクト担当者、介護業務に詳しい担当者などが、それぞれの知識を持ち寄って品質を確認する体制を作ります。 テストケースを実行する直前だけではなく、 要件や仕様を決める段階から品質確認へ参加すること が重要です。 業務担当者にシナリオをレビューしてもらうことで、システム担当者だけでは思い付かなかった現場特有のケースを発見できる場合があります。 逆に、実際には発生しない複雑な組み合わせを削り、重要なケースへテスト工数を集中させることもできます。 リリース後には、不具合件数だけでなく、問い合わせ内容や現場で困った操作なども振り返ります。 その結果を仕様書やテストケースへ戻し、次回以降も確認できる状態にします。 制度変更の履歴、判断根拠、障害事例、テスト観点をチームの共有資産として残す ことで、担当者が変わっても品質を維持しやすくなります。 まとめ｜介護業務の流れから考えれば、重大な不具合を防ぐテストができる！ 介護業界のソフトウェアテストでは、個々の画面が正常に動くことだけを確認しても十分ではありません。 利用者情報、アセスメント、ケアプラン、介護記録、サービス実績、帳票、介護報酬請求、外部連携まで、 一つのデータが介護業務の中をどのように流れていくのか を追うことが重要です。 特に請求金額の誤り、介護記録の欠損、個人情報の誤表示、外部システムへの誤ったデータ送信などは影響が大きいため、優先的に確認する必要があります。 また、正常系だけでなく、月末・月初、制度切り替え日、予定変更、過去データの修正、通信断など、実際の業務で起こり得る条件もテストへ取り入れます。 介護報酬やLIFE、介護情報基盤などの仕様は変化するため、一度テストケースを作って終わりではありません。 変更による影響範囲を整理し、重要機能を回帰テストとして残し、本番で発生した問題を新しいテストケースへ反映する仕組みが必要です。 介護業務の専門知識をQA担当者だけで抱えず、開発や業務担当者と共有しながら品質を確認することも欠かせません。 まずは 「この画面へ入力した情報が、最終的にどの帳票・請求・外部システムへつながっているのか」 を一本の業務フローとして整理するところから始めると、介護ソフト特有のテスト観点を見つけやすくなります。 QA業務効率化ならPractiTest テスト管理の効率化 についてお悩みではありませんか？そんなときはテスト資産の一元管理をすることで 工数を20%削減できる 総合テスト管理ツール「 PractiTest 」がおすすめです！ PractiTest (プラクティテスト) に関する お問い合わせ トライアルアカウントお申し込みや、製品デモの依頼、 機能についての問い合わせなどお気軽にお問い合わせください。 お問い合わせ この記事の監修 Dr.T。テストエンジニア。 PractiTestエバンジェリスト。 大学卒業後、外車純正Navi開発のテストエンジニアとしてキャリアをスタート。DTVチューナ開発会社、第三者検証会社等、数々のプロダクトの検証業務に従事。 2017年株式会社モンテカンポへ入社し、マネージメント業務の傍ら、自らもテストエンジニアとしテストコンサルやPractiTestの導入サポートなどを担当している。 記事制作： 川上サトシ （マーケター、合同会社ぎあはーと代表）

一般的なソフトウェア開発や評価の経験があっても、医療機器の開発に関わり始めると「これまでと同じテストで十分なのか」と迷いやすくなります。 医療機器では、単に仕様通り動作することを確認するだけでなく、ソフトウェアの誤動作が患者や医療従事者へ与える影響を考え、 安全性に関わるリスクが適切に管理されていることまで確認する視点 が欠かせません。 さらに、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の導入サポートなどを担当している。 記事制作： 川上サトシ （マーケター、合同会社ぎあはーと代表）