検証これ # ?? LT読書会ならぬ読書感想文

@tokutaka

はじめに

• おなまえ

• とくたか (@tokutaka)

• おしごと：電機メーカーでの設計チームリーダー

• モデル検査・テスト設計・オブジェクト指向設計・レビュー等の品質技術力向上と、JIRA等ツールを用いたアジャイルチーム構築

• どういうひと？

• てすとだいすき

• ふぐあいだいすき

• れびゅーだいすき

• まさかりだいすき

• この記述は引用箇所に用います。

• 凡例：引用箇所を明確にするため、下記の表記はすべて引用です。

なんのほん？

• 和書（Kindle Only）

• 医療機器ソフトウェア検証，妥当性確認，およびコンプライアンス: 医療用ソフトウェア開発では避けて通れない「バリデーション」の本質を理解し，FDA規制をクリアするために

• デビッド・ボーゲル (著), 酒匂寛 (翻訳), 坂井務 (翻訳), 酒井郁子 (翻訳)

• 原著

• Medical Device SoftwareVerificatoin, Validation, and Compilance

• David A. Vogel.

• http://www.amazon.co.jp/dp/B00KC87VKW

なぜそのほんよんだ？：酒匂さんのPRより(1/3)

• https://m.facebook.com/story.php?story_fbid=10152250691883859&id=708228858

• テーマは表題の通り「医療機器ソフトウェア検証，妥当性確認，およびコンプライアンス」に関するもので、ここで言うコンプライアンスとは特に米国FDA の規制に対するものを指しています。

• こう書くと、内容的に医療機器ソフトウェアに限定された、狭い話かと思われるかもしれませんが、実際には全てのソフトウェア開発に関わる方々に読んでいただきたい内容となっています。

なぜそのほんよんだ？：酒匂さんのPRより(2/3)

• 若干高めではありますが、妥当性確認（Validation)、（正当性）検証（Verification) に興味のある組織にとって、役に立つ内容だと思います。

• なお聞きなれない用語だと思われる方のために、

• 若干の補足を致しますと

• 妥当性確認＝正しいものを作っているのか

• 正当性検証＝正しく作っているのか

• という区分になります。この２つは似て非なる概念で、この２つの違いを理解し、それぞれの意義を理解することがとても大切です。

なぜそのほんよんだ？：酒匂さんのPRより(3/3)

• 本書が伝えようとしていることの一つは、「妥当性確認と検証を行う意義を理解し、人間の命に直接係る医療機器ソフトウェアに適用する際のアプローチを考える材料を与える、結果として規制要件に対するコンプライアンスを実現できる」というものなのである。

• 妥当性確認はコストのかかる活動だ。しかし妥当性確認を開発作業に正しく織り込んで継続的に行うことが、結果的に品質を高め市場でのリスクを回避しビジネスを成功に導くことであるということを本書は繰り返し説いている。なお妥当性確認をきちんと機能させるには、要件と実装の間をつなぐ追跡性の向上が必要不可欠だが、このことの大切さは本書の冒頭でも第一に触れている。

• 妥当性確認と検証はルーチンワークに落とし込まれるべきではない継続的な創造作業なのである。こうした「妥当性確認」「検証」そして「コンプライアンス」の意義の理解と合意形成を組織の中で行うためには一定の時間と労力が必要とされる。そして更に実際のアクティビティへと落としこむためには、本書に書かれた内容をよく理解した上でそれぞれの組織や製品に合った手法を自ら作り上げ、洗練させていかなければならない。その意味で「正しいやり方を教えて欲しい、その通りにやるから」という態度はこの作業にもっとも向かないものと言えるであろう。

• 本書の内容が（少なくともその精神が）全てのソフトウェア技術者にとって「当たり前」のものとなるように願う

要するに：私の頭の中に残ったこと

• タイトルは医療機器といってるけど、ソフトウェア開発での当たり前なので読め

• 妥当性確認＝Validation

• 正当性検証＝Verification

• 妥当性確認と検証は創造的な活動。「正しい具体的なやり方を教えてほしい、そうするから」という態度は死すべし

どんな本？:目次の引用

第一部背景

1. 医療機器ソフトウェア妥当性確認の進化と本書の必要性

2. 規制の背景

3. FDAによるソフトウェア妥当性確認規制とソフトウェアの妥当性確認が必要な理由

4. ソフトウェア妥当性確認のための組織的考慮

5. ソフトウェア（開発）ライフサイクル

6. 確認と妥当性確認：その実像と虚像

7. ソフトウェア妥当性確認に対するライフサイクルのアプローチ

8. ライフサイクル全体に及ぶアクティビティのサポート：リスク管理

9. その他の支援活動：計画、レビュー、構成管理、欠陥管理

どんな本？:目次の引用

第2部医療機器ソフトウェアの妥当性確認

10. 概念フェーズアクティビティ

11. ソフトウェア要件フェーズアクティビティ

12. 設計および実装フェーズアクティビティ

13. テストフェーズアクティビティ

14. 保守フェーズ妥当性確認アクティビティ

第3部非機器ソフトウェアの妥当性確認

15. 自動化プロセスソフトウェアの妥当性確認：背景

16. 非機器ソフトウェアの妥当性確認を計画する

17. 意図した使用と意図した使用を実現する要件

18. 非機器ソフトウェアのリスク管理と構成管理：ライフサイクル全体に及ぶアクティビティ

19. 妥当性確認をサポートする非機器テストアクティビティ

20. 非機器ソフトウェアの保守および廃棄

非医療機器のこと

読書感想のまとめ

• 全章にわたって非常にすばらしい： 一部をピックアップします

• 3章： FDAが妥当性確認要求するときの状況としてのTherac25の惨事と、原因サマリーと、ソフトウェアエンジニアリングの実践の関係

• 6章： そもそも検証と妥当性確認とテストの関係とは？

• 8章：リスク分類や発生確率を埋める時点で難しい。残存リスクの受容をどう考えれば？

• 13章：テストの心理学：

• 19章： テストする理由としない理由

• ちなみに原著のほうが英語かつ若干高いので和書のほうがお勧めです。

第3章： FDAによるソフトウェア妥当性確認規制と必要な理由

• Therac25事件：http://en.wikipedia.org/wiki/Therac-25

• この事故まで、FDAは対処した経験がほとんどなかったとのこと。

• Nancy Levesonによる要因報告を以下引用します。

• 要因は全体的に身につまされます。ソフトウェアに対する過信

ソフトウェアは機器のハザード分析で考慮されず、ハードウェアの不具合が第一に考慮され、ソフトウェア障害が発生した場合の適切なバックアップメカニズムがないまま、安全機能の多くがソフトウェアに実装された

信頼性と安全性の混同

防衛的設計の欠如

無頓着

非現実的なリスク査定

事故報告に対する不適切な調査やフォローアップ

ソフトウェアの再利用。

安全なユーザインターフェース対使いやすいユーザインターフェース

第3章： FDAによるソフトウェア妥当性確認規制と必要な理由

根本的原因除去の失敗

「ソフトウェア障害モード中にキーボードでPを押すと、（中略）放射線照射が起こる可能性があった。そういう「Proceed」が5回あると、システムがシャットダウンされる。これに対するメーカの対応は、「Proceed」の回数を減らすというもので、シャットダウンが5回ではなく3回で始まるようになった結果、幹部を攻撃する過剰照射の量は抑えられたが不具合の根本的原因はそのままだった。

このエラー状態につながる一連のイベントには、画面でデータを編集するためカーソルをポイントする際のオペレータによる上向き矢印の使用がふくまれていた。メーカであるAtomic Energy Of Canada Limited(AECL)社の対応は、Theracシステムのユー

ザに書簡を送り、「キーを取り外し、スイッチの接点を電気テープや他の絶縁物質で開放位置に固定すること」を要請することだった。

• 暫定対策やパッチワークを恒常化することの危険性。

• 対応を進める本人たちは迅速に顧客のための活動をしようとしているのですが。

第3章： FDAによるソフトウェア妥当性確認規制と必要な理由

• 不適切なソフトウェアエンジニアリングが要因としてあげられている！

今日の先進テクノロジとテクニックへさらに25年の経験をもってしても、その要因リストで業界が完全に除去できたいうことができるものは、事実上皆無なのである

不適切なソフトウェアエンジニアリングの実践

• ソフトウェア要件と設計の文書化が後づけでなされた

• ソフトウェアの設計と開発を制御する品質システムが整備されていなかった

• ソフトウェア設計が過度に複雑だったと思われる

• システムレベルのソフトウェアテストしか実行されなかった。ユニットレベルや統合レベルのテストとは明らかでない。すべてのソフトウェア変更に関する回帰テストの計画が全然ない

• ソフトウェアのユーザインターフェースがユーザにわかりにくい。エラーメッセージが不可解。

６．検証と妥当性確認：その実像と虚像

• あるあるだけど、その人たちに「わかってないな！」と説教してもあまり伝わらない

• テストすればよい、レビューすればよいと、タスクのみを認識する人を改宗することが難しい

業界には明らかに混乱や誤った情報がある。当社には、医療機器メーカが新しく開発した機器の仕上げ段階で、その「妥当性確認」をーできれば1週間以内で！－お願いしたいという契約の電話を毎週のように受けている。

検証と妥当性確認の内容に関してよくある誤解からはじめよう。図６．１にそういう根拠のない社会通念をいくつか挙げる。最初に、もっともよくある誤解は製品に欠陥がないと保証するために製品開発プロセス最後で行う大量のテストを妥当性確認とするものである。これは２つの理由で誤っている。これから見ていくように、妥当性確認は、ソフトウェアの設計段階で欠陥を入りこませないことと、入り込んでしまった欠陥を検出修正すること両方を等しく重視する。

６．検証と妥当性確認：その実像と虚像

妥当性確認

検証

テスト

図６．２ 「妥当性確認」対「検証」対「テスト」

• これで明日からうまく説明できそうです

図６．３ ソフトウェア妥当性確認の傘

妥当性確認におけるアクティビティをわかりやすく列挙されています。詳しくは原著をお買い求めください

8. 2 リスク管理

• 自分の勘違いがまさに記述されていた。リスク管理していればいいのではという勝手な思い込み。妥当性確認アクティビティの一部なんだよな。

リスク管理は、妥当性確認アクティビティとみなされる。リスクを特定し、重大なリスクに対する制御を設計し、そうした制御の有効性を検証する体系的なリスク管理プロセスは、ソフトウェアやシステムの信用を強化する。妥当性確認の目標はソフトウェアの信用を構築することだから、リスク管理が妥当性確認アクティビティあるように見えるのだ。

8.12 リスク管理アクティビティ

• ここでは、紙面を割いて、ハザード分析および確率をどのようにするかが長文で記述されている。ソフトウェア不具合を起こしやすくする要因の列挙があり、参考になった。

8.14 リスク制御

• ここでは具体例とともに、どのようにリスクを軽減または受容するかが記述されている。１例として、オッカムのかみそりの適用。

• 実際に自分の開発の中で実践している考え方と近く、ある意味自信を持てたが、それをどのように教育していくべきか？という点で問題がありそうだと感じた。 なお、完全なリスク像を十分に理解できたという確信は私もほしい。

今度は、その受容不可リスクに対する制御を設計する（または既存のものを特定する）番だ。

他人によって自分の病気の母親がそのリスクにさらされたくない（すなわち、もっとも単純な直感的評価であるが）なら、全体的リスクは受容不可である。－このことは他の定量的または定性的分析が結論付ける内容とは関係ない。

リスク管理は反復的だから、ライフサイクル全体で行う必要がある。リスク管理プロセスの方法とツールを多くしようすることが名案であることは確かだ。しかし、いろいろな方法で生成された情報をどうまとめ、有意義な全体的残存リスク査定を可能にするレビューに備えるかを考えなければならない。やはり、（中略）情報を1箇所に集めない限り、完全なリスク像を十分に理解できたという確信を与えない。

13 テストフェーズアクティビティ

• ISTQBのFoundation Level程度に具体例とともに書かれていてすばらしい。

• テストチームと開発チームとの連携の例はシンプルかつ理解しやすい。

13.5テストの心理学

テスト中のよくない態度を醸成するものとして、テストチームからのソフトウェアに対する一方的批判がある。その埋め合わせには、開発者をテスト設計のレビュアとして使用することが考えられる。これで少なくとも以下の3つが実現する。

1.開発者はテスト設計、テスタはソフトウェアを批評するように、批判の流れのバランスをとる。（中略）

2.開発者によるテスト設計のレビューは、テスト範囲を著しく向上させる。 (中略）

3.テスト設計のレビューは、ソフトウェア設計に関してと、開発者がソフトウェアを機能させるために何が必要だったかの理解を向

上させる結果につながることが多い。（中略）こういう情報を活用するテスタは、ソフトウェアで障害を起こしそうな部分に作業を集中させる。それは本書で述べてきたリスクベースの妥当性確認とテストを構成する要素の1つである。

19 妥当性確認をサポートする非機器テストアクティビティ

• 普段自分が使っているIDEやコンパイラに対する、テストする・しないを明確に切り分けなかった自分に気がつくことができました。

• ただし、FDA規制ガイダンスは、規制として有効なのか疑わしいのかとも思いました。意識づけるだけなのか？あまり理解しきれていません。

19.1テストする理由・しない理由

ソフトウェアテストに関する章のはじめ方としては妙かもしれないが、多くの場合、大量の非機器ソフトウェアテストは妥当性確認投資に効果をあげる最良の方法でない可能性がある。

19.7要約

保守的な妥当性確認計画者は、テストの計画を立てて、規制問題を満たさなければならないが、会社が労力に対して得る利益を最大にするため、十分に計画を練ったリスクベーステストは、大量である必要がない。それでも、機器メーカにとって重要な欠陥の発見で生産的にすることができ、安全性または規制に関する障害の発見で有効なこともある。

最後に

• 引用している情報は本全体のごくごくわずかでしかありません。

• 規制がどれだけ重量級かという説明ではなく、なにのための規制なのか、そしてそれをやるときにどのような困難があって、どうメリットがあるか、という説明になっています。

• 要件やトレーサビリティといった欠陥混入時に多大な影響をあたえるアクティビティへの対応や、保守での考え方など、ぜひ読むべきです。

• 本書は開発ライフサイクルにも言及されています。アジャイルな人たちにもお勧めです。

• まだまだ自分自身理解しきれていないため、もう一度全部読み返します。