要求と確認対象の境界が揃わず、範囲を説明できない
変更要求は業務のひと言単位で上がり、変更は画面項目単位で入ります。このずれを調整しないと、変更条件がテストに載らず、範囲の根拠を示せません。
医療機器分野のQMSで使うコンピュータ化システムについて、変更に伴う要求とリスクから確認範囲を定め、テスト結果と証跡を整理します。
支援実績5,000件以上













コンピュータ化システムは、ソフトウェアと手順やデータ、設定を含む運用環境の組み合わせとして扱います。不具合は要求と確認対象のずれや記録の分断として現れ、普通に動く間ほど見逃されがちです。
変更要求は業務のひと言単位で上がり、変更は画面項目単位で入ります。このずれを調整しないと、変更条件がテストに載らず、範囲の根拠を示せません。
バリデーションの必要性と程度は、利用リスクとQMSへの影響で決めます。この考慮を省くと、重要な変更が浅い確認で通り、優先順位を説明できません。
実装側のテスト結果が自社の要求やリスクと対応づかないと、責任の分界を示せません。結果がそろっていても、自社の確認範囲としては説明できません。
CSVファイルを受け渡す構成では、取り込み、変換、出力のどの段でも値が崩れます。取り込みの成否が記録に残らなければ、何が欠けたかを追えません。
申請と承認はワークフローに、操作履歴は監査証跡に残り、つながっていません。どの変更要求への対応かを示さなければ、確認済み範囲の証拠になりません。
変更後に残った不具合は、見た目では気づけないことがあります。どこまで確認したか組織として答えられなければ、影響は判断と後日の説明に届きます。
静的テスト(レビュー)は、システムを実行せずに成果物を評価する確認です。実行前に確認対象の境界を文書へ固定しないと、確認漏れの発覚時に確認済み範囲の根拠が崩れるおそれがあります。
最初に照合するのは、変更の目的と要求の裏付けです。変更理由書の目的が要求仕様書へ反映されていないかを洗い出します。この照合が、確認範囲の議論を文書の記載で進める土台です。
次は、利用リスクと確認範囲の対応です。リスク評価で高と判定された機能ほど確認を厚くする配分が、テスト計画の優先度へ反映されているかを、文書の記載をたどって確認します。
権限と承認の条件は、仕様書の記載レベルで照合します。承認の可否や状態遷移を画面遷移図と権限定義表で確かめます。権限境界が曖昧だと、承認済み記録を修正できる設計を見落とします。
システム間では、取り込み・変換・出力の仕様を突き合わせます。対象は案件で確認できた形式・項目・相手先に限り、接続先の内部処理は含めません。テストの証跡は、業務データと同じ枠にしません。
最後に、記録の残し方を手順へ合わせます。確認するのは、監査証跡と検証記録の保存先、保持期間、参照権限です。それぞれが案件で合意した手順書と一致しているかを照合します。
動的テストでは、利用リスクと影響範囲から確認範囲を選び、システムを実際に動かして変更後の挙動が要求どおりかを検証します。
変更部分の全数確認は、期間と記録の量から現実的ではありません。影響度分析でリスクの高い箇所から選び、テストケースへ反映し、選ばなかった範囲は根拠とあわせて記録に残します。
ケースへの分解には、境界値分析や状態遷移テストなどの確立した技法を使い、入力値のわかれ目や状態が動く経路が要求どおりかを検証します。境目は、仕様が曖昧なまま実装されやすい部分です。
組み合わせの確認は、単機能の中にはおさまりません。外部との接続をまたぐ論点を確かめるため、実行前に確認範囲と担当の分界を実装側と合意し、記録に何を残すかまで決めておきます。
実行後は、結果を一覧のまま置かず、要件・テストケース・結果の対応で結びます。この結びがあれば、確認した範囲と残るリスクを説明でき、レポートが合議の判断材料になります。
固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。
人日単位のアサインで固定費を抱えず、繁忙期に増減できます。
独立した検証で偏りを排し、監査に使える客観的な記録を残せます。
JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。
GENZの支援実績は5,000件以上ですが、医療機器のQMS向けに限った数ではありません。20年の第三者検証の経験を踏まえ、確認範囲の設計からテスト実施、記録まで伴走し、リリース判断の材料を揃えます。
変更の目的と要求を確かめ、確認範囲とその根拠を案にまとめます。確認しない範囲の明記は、後から問われたときの答えを用意するためです。
リスクの高い機能は動的テストを厚く、影響が限定的な箇所はレビュー中心に絞ります。JSTQB認定エンジニアが在籍し、設計と実行を担います。
結果は確認した範囲と未確認の範囲に分け、要件との対応を記録します。未確認の範囲には残存リスクと受け入れの判断材料を添えます。
実装側と提供側の確認範囲を仕分け、要求とリスクと記録の対応を一本に整理します。法令への適合は判定せず、ご担当者様の判断材料を揃えます。
変更の目的と受け入れ条件、リスクに応じた確認範囲の考え方を伺い、確かめる範囲と優先順位を整理します。
変更の目的と受け入れ条件、期日への影響を確認します。
利用リスクと影響範囲で優先順位を付け、範囲と工数を整理します。
合意した範囲を実施し、判断待ちの事項をその都度共有します。
結果と証跡、未確認の範囲を納品し、再確認の進め方を整理します。
支援実績5,000件以上
変更前のご相談では、変更の目的と受け入れ条件を伺い、リスクに応じた確認範囲のたたき台を作ります。工数は規模やリスクで変わるため、案件の情報をご共有のうえでお伝えします。