『GHSがヘルスソフトウェア国際規格の解説セミナーを開催（innavi net 記事）』
このIEC 82304-1 解説セミナーの中で，「ヘルスソフトウェア製品のバリデーション」の講演があり，改めて，バリデーションって何？，バリデーションは何のためにやるのか？を考えてみた。
Validation（バリデーション）は日本語では「妥当性確認」と訳され，ISO 9000 (JIS Q 9000:2015)では次のように定義されている。
3.8.13 妥当性確認（validation）
客観的証拠（3.8.3）を提示することによって，特定の意図された用途又は適用に関する要求事項（3.6.4）が満たされていることを確認すること。
- 注記 1 妥当性確認のために必要な客観的証拠は，試験（3.11.8）の結果，又は別法による計算の実施若しくは文書（3.8.5）のレビューのような他の形の確定（3.11.1）の結果である。
- 注記 2 “妥当性確認済み”という言葉は，妥当性確認が済んでいる状態を示すために用いられる。
- 注記 3 妥当性確認のための使用条件は，実環境の場合も，模擬の場合もある。
3.8.12 検証（verification）
客観的証拠（3.8.3）を提示することによって，規定要求事項（3.6.4）が満たされていることを確認すること。
- 注記 1 検証のために必要な客観的証拠は，検査（3.11.7）の結果，又は別法による計算の実施若しくは文書（3.8.5）のレビューのような他の形の確定（3.11.1）の結果であることがある。
- 注記 2 検証のために行われる活動は，適格性プロセス（3.4.1）と呼ばれることがある。
- 注記 3 “検証済み”という言葉は，検証が済んでいる状態を示すために用いられる。
バリデーション（妥当性確認）とベリフィケーション（検証）の２つの定義を比較してみる。
| 英語 | 日本語 | 先頭 | 中間 | 末尾 |
| Validation | 妥当性確認 | 客観的証拠（3.8.3）を提示することによって | 特定の意図された用途又は適用に関する要求事項（3.6.4）が | 満たされていることを確認すること。 |
| Verification | 検証 | 客観的証拠（3.8.3）を提示することによって | 規定要求事項（3.6.4）が | 満たされていることを確認すること。 |
3.8.3 客観的証拠（objective evidence）
あるものの存在又は真実を裏付けるデータ（3.8.1）。
3.6.4 要求事項（requirement）
明示されている，通常暗黙のうちに了解されている又は義務として要求されている，ニーズ又は期待。
結果，バリデーション（妥当性確認）とベリフィケーション（検証）を比較すると，その違いは，中間の「特定の意図された用途又は適用に関する」と「規程」の部分だけだということが分かる。
これでは，Validation（妥当性確認）とVerification（検証）の違いが分からないという技術者がいても不思議ではない。
Validation（妥当性確認）とVerification（検証）の違いを 1981年に Barry W . Boehm が "Software Engineering Economics, Prentice-Hall" で次のように説明し，多くの人が引用しているのでそれを見てみよう。
| 英語 | 日本語 | 英文の説明 | 日本語の解釈 |
| Validation | 妥当性確認 | Are we building the right product? |
正しい製品（成果物）を開発しているか？ （顧客要求を満たす製品を作っているか？） |
| Verification | 検証 | Are we building the product right? |
正しく製品（成果物）を開発しているか？ （仕様通りに作っているか？） |
英語では，同じ単語で語順を変えることで上手いこと説明しているのだが，日本人にはなかなか解釈が難しいかもしれない。
バリデーションは正しい製品（成果物）を開発しているのか？（顧客要求を満たす製品を作っているのか？）と問うていて，ベリフィケーションは，正しく製品（成果物）を開発しているか？（仕様通りに作っているのか？）を問うているという解釈だ。
それでもValidation（妥当性確認）とVerification（検証）の違いがよく分からないという人は，なぜ，Validation（妥当性確認）とVerification（検証）を分けないといけないのかという視点で考えてみるとよい。
ソフトウェア製品の場合，Validation（妥当性確認）とVerification（検証）は分けて考えた方がよいのだ。なぜなら，仕様通りに開発したのに，顧客要求を満たす製品になっていないというケースがよくあるからだ。
<仕様通りに開発したのに，顧客要求を満たす製品にならない要因の例>
- 仕様書が完璧でないため，システムの使用環境やユーザーニーズをよく知らない設計者（ソフトウェアの場合プログラマー）が，不足仕様の行間を自分の判断で埋めてしまった。
- 2次，3次下請けと設計作業が分配されたため，要求仕様が伝言ゲームで誤って伝わった。
- 顧客の要求が正しく要求仕様に反映されておらず，誤りや曖昧さのある要求仕様から設計仕様が作られた。
- 顧客要求事項の範囲（上限，下限）が分析されておらず，要求事項として示されていなかったため，設計者が自分の感覚で範囲を決めてしまったが，実際は要求とずれていた。
- 設計者（プログラマー）が検証仕様を作成したため，パスするテストケースしか想定しなかった。よって検証は全部合格だが，漏れがあり妥当性確認は合格しない。
- 顧客Aの要求を満たすように作ったが，顧客Bや顧客Cはその仕様を望んでなかった。
- 設計仕様に漏れや反映されていない要求仕様があったり，要求仕様を勘違いして設計仕様を作ったりしていた。
- 汎用的に作られた市販ソフトウェア（OTS)が，当該製品の要求実現にマッチしていなかったのにその問題に気付かず置き去りにされた。
これらの例から分かるように，大規模ソフトウェア開発のように，開発作業を分業し，階層化すると，下位層に行けば行くほど，顧客要求がよく分からない状態で作業（プログラミング）を行うことになる。顧客要求が分からなくても，問題なく作業ができているなら，それはアーキテクチャ設計がよいからかもしれない。IN と OUT が明確な，汎用性の高いソフトウェアアイテムを多くして，ドメインに依存したソフトウェアアイテムを少なく，凝集されることができれば，多くの汎用性の高いソフトウェアアイテムの単体テストは容易になる。
しかし，そんなよいアーキテクチャ設計のソフトウェアシステムや，要求仕様を正確に反映している完璧な仕様書なんて滅多にないから，プログラマーが曖昧な仕様書の行間を読んでプログラムを書くことなど日常茶飯事だろう。クライアントからすると過去の製品の仕様や，製品の使用環境を知っていて，より正確に行間を読んでくれるプログラマーが「よく出来る人」という評価になる。
しかし，そんなよいアーキテクチャ設計のソフトウェアシステムや，要求仕様を正確に反映している完璧な仕様書なんて滅多にないから，プログラマーが曖昧な仕様書の行間を読んでプログラムを書くことなど日常茶飯事だろう。クライアントからすると過去の製品の仕様や，製品の使用環境を知っていて，より正確に行間を読んでくれるプログラマーが「よく出来る人」という評価になる。
人に依存した開発をやっている組織ほど，仕様書の精度が低い。仕様書の精度が低いのにいい仕事ができているのは，Validation（妥当性確認）とVerification（検証）を同時に意識しながら，作業ができる技術者がいるからだと思う。
小さいプロジェクトで，職人的開発をしているチームほど，Validation（妥当性確認）とVerification（検証）の区別が付かない，必要性を感じない場合が多い。なぜなら，Validation（妥当性確認）とVerification（検証）を区別しなくても，上記のような問題が発生しないからだ。
別な言い方をすれば，その人は，Validation（妥当性確認）で必要なことが頭に入っている状態でプログラムを作っていて，Verification（検証）しているときに，一緒にValidation（妥当性確認）もしてしまっているのだ。老練な技術者は「ここだけは抑えておこう」「ここに何かあったら大変だ」という製品の要所を把握していて，常に要所に影響がないかアンテナを張っている。その要所である「ここ」が，基本機能や基本性能を実現している部分であり，クリティカルシステムならリスクコントロール手段となり，バリデーション項目になる。
アーキテクチャの良さが要所を守っているというケースもある。基本機能や基本性能を実現しているソフトウェアアイテムと付帯機能を実現しているソフトウェアアイテムの凝集度が良く，結合度が弱いアーキテクチャが実現できている場合，付帯機能部分の追加や修正に失敗しても，基本機能や基本性能に影響を与えない，もしくは要所を触ることができないようになっていれば，要所を守ることができる。
別な言い方をすれば，その人は，Validation（妥当性確認）で必要なことが頭に入っている状態でプログラムを作っていて，Verification（検証）しているときに，一緒にValidation（妥当性確認）もしてしまっているのだ。老練な技術者は「ここだけは抑えておこう」「ここに何かあったら大変だ」という製品の要所を把握していて，常に要所に影響がないかアンテナを張っている。その要所である「ここ」が，基本機能や基本性能を実現している部分であり，クリティカルシステムならリスクコントロール手段となり，バリデーション項目になる。
アーキテクチャの良さが要所を守っているというケースもある。基本機能や基本性能を実現しているソフトウェアアイテムと付帯機能を実現しているソフトウェアアイテムの凝集度が良く，結合度が弱いアーキテクチャが実現できている場合，付帯機能部分の追加や修正に失敗しても，基本機能や基本性能に影響を与えない，もしくは要所を触ることができないようになっていれば，要所を守ることができる。
さて，「技術者は現場を知らなければダメだ！」と上司や先輩から言われたと思う。これは別な見方をすれば，「Validation（妥当性確認）できるエンジニアになれ！」ということで，Validation（妥当性確認）とVerification（検証）が同時にできる人材は，開発効率が高く，効率的にクレームが出ない製品を作れる技術者なので，「技術者は現場を知らなければダメだ！」はそういったエンジニアになれという意味なのだ。
また，顧客に対して頻繁に使い勝手を確認するような開発スタイル（アジャイルプロセス等）を取るという行為は，Validation（妥当性確認）とVerification（検証）を同時に実施して，開発効率を高めていると言える。ちなみに，クリティカルシステムで，このスタイルを推奨しない。なぜなら，ユーザーにValidation（妥当性確認）を求める方法では，通常の使用環境ではおきにくい危険状態に対するリスクコントロール手段に，ソフトウェアの修正が悪影響を与えているかどうかの確認が漏れる危険性があるからだ。クリティカルシステムでは，バリデーション項目を抽出して，テストがしにくくても１つ１つ確認する必要がある。
また，顧客に対して頻繁に使い勝手を確認するような開発スタイル（アジャイルプロセス等）を取るという行為は，Validation（妥当性確認）とVerification（検証）を同時に実施して，開発効率を高めていると言える。ちなみに，クリティカルシステムで，このスタイルを推奨しない。なぜなら，ユーザーにValidation（妥当性確認）を求める方法では，通常の使用環境ではおきにくい危険状態に対するリスクコントロール手段に，ソフトウェアの修正が悪影響を与えているかどうかの確認が漏れる危険性があるからだ。クリティカルシステムでは，バリデーション項目を抽出して，テストがしにくくても１つ１つ確認する必要がある。
Validation（妥当性確認）を行うには，当該製品分野に対する深い知識が必要でその製品の「ユーザニーズの理解」「意図する使用（Intended Use)の理解」「市場要求との整合性の判断ができるスキル」が出来る人材が必要となる。
ちなみに，製品に搭載するソフトウェアの規模はどんどん大きくなっているので，プロジェクトメンバー全員が「Validation（妥当性確認）できるエンジニア」になるのは不可能だ。
だから，Validation（妥当性確認）とVerification（検証）は分けないといけないのだ。
IEC 82304-1 では，箇条 6 ヘルスソフトウェア製品のバリデーション で，6.1 バリデーション計画， 6.2 バリデーションの実施, 6.3 バリデーション報告 が要求となっていて，計画の要求の中には，「e)バリデーションを行う要員に必要な資格要件を特定する。教育訓練が必要な場合は，バリデーションを始める前に完了しておく。」や「f)バリデーションチームの，設計チームに対する適切な独立性レベルを定める。」などの要求も含まれている。
バリデーションを行う要員の必要な資格要件というのは，特定が難しそうだが，対象となるシステムの使用者が特定の資格を持っていたり，特定のワークフローで仕事をしているような場合，バリデーション要因としてそれらの知識の必要性を判断する。
ある意味，これまで経験則やキャリアの長さで判断していた「バリデーション要員のスキル」を見える化して，漏れのないバリデーションをするルールを策定したと言えるだろう。
また，バリデーション計画を立てるためには，製品要求事項を抽出しないといけないのだが，これが出来ない人が多い。
Use requirement（製品要求事項）と Specification （仕様）の区別が付かないのだ。Use requirement（製品要求事項）は「使用の必要条件」という意味なので，それがないと製品が成り立たない，製品の基本機能，基本性能の元となる要件だ。
それが何なのか答えられない技術者が多い。その理由を考えると，日本の製品は既存製品に対する改良，改善，追加を繰り返す製品開発が多く，遙か昔に作成したUse requirements（製品要求事項）を忘れてしまった，または，最初に作ったUse requirements（製品要求事項）も実は，他社の同等製品からコピーしたものだったということなのではないだろうか。
だから，技術者は，最近追加した機能や性能，あるいは，不具合で修正した仕様には詳しいものの，製品に搭載されている基本機能や基本性能が何かをズバリ答えられない。
逆に言えば，多くの製品開発は，基本機能や基本性能はすでに枯れてしまっていて，おまけの機能を追加することで成り立っているので，Use requirements（製品要求事項）が何かを知らなくても後継製品ができてしまうということだ。
これは２つの面で問題がある。１つは，付加機能を付け足した製品しか作れないのでイノベーションが起こらない（市場を拡大できる製品が生まれない）ということと，２つ目は，付け足した機能が，基本機能や基本性能に悪影響を及ぼす危険性があるということだ。
ソフトウェアの場合，ソフトウェアの構造（アーキテクチャ）が悪いと，付け足した機能が基本機能や基本性能に悪影響を及ぼす危険性が高くなる。要するにスパゲッティのようなプログラムに機能を追加すると，さらに絡まりが強くなって，また，システムのどこが要所かを理解しないエンジニアが意図せず大事な機能や性能を実現している部分を傷を付けてしまう可能性がある。
だから，ソフトウェアの構造が悪いシステムほど，バリデーションが重要になる。Use requirements（製品要求事項）の項目を１つ１つ確認することで，その製品の必要条件が満たされているかどうか，製品の基本となる可用性や完全性が侵害されていないかを確認するからだ。
別な見方をすれば，細かい付帯機能すべてを確認できなくても，バリデーションによって製品の基本機能や基本性能には問題がないことを確認できるということだ。（将来，小さい設計変更はあっても，リコールに至るような大きな問題を押さえ込める確率が高まる）
製品やソフトウェアの規模が大きくなればなるほど，Validation（妥当性確認）とVerification（検証）は明確に区別することが重要で，かつ，これからのソフトウェア開発においては，Use requirements（製品要求事項）の抽出を含むバリデーション計画・実施・報告 が重要な要素となるということがお分かりいただけたかと思う。
P.S.
ISO 26262 では，Validation Plan の立案は明示的に要求していないように思う。(もし，間違っていたら教えて欲しい） その理由は，これまで自動車はUse requirements（製品要求事項）が「走る」「曲がる」「止まる」とように変わらない=普遍だったからではないだろうか。でも，電気自動車や自動運転ができるようになると，Use requirements（製品要求事項）が変わったり，多様化して，付け足した付加機能が基本機能を脅かしたりする危険が出てくるのではないか。自動車のソフトウェアもValidationを重視した方が良くないか。（サプライヤは Validation Plan 書けなかったりして）
P.S.
ISO 26262 では，Validation Plan の立案は明示的に要求していないように思う。(もし，間違っていたら教えて欲しい） その理由は，これまで自動車はUse requirements（製品要求事項）が「走る」「曲がる」「止まる」とように変わらない=普遍だったからではないだろうか。でも，電気自動車や自動運転ができるようになると，Use requirements（製品要求事項）が変わったり，多様化して，付け足した付加機能が基本機能を脅かしたりする危険が出てくるのではないか。自動車のソフトウェアもValidationを重視した方が良くないか。（サプライヤは Validation Plan 書けなかったりして）
0 件のコメント:
コメントを投稿