Embed Size (px)
DESCRIPTION
とある勉強会でのLT資料 http://connpass.com/event/6354/
Citation preview
検証これ LT読書会ならぬ読書感想文
tokutaka
はじめに
bull おなまえ
bull とくたか (tokutaka)
bull おしごと電機メーカーでの設計チームリーダー
bull モデル検査テスト設計オブジェクト指向設計レビュー等の品質技術力向上とJIRA等ツールを用いたアジャイルチーム構築
bull どういうひと
bull てすとだいすき
bull ふぐあいだいすき
bull れびゅーだいすき
bull まさかりだいすき
bull この記述は引用箇所に用います
bull 凡例引用箇所を明確にするため下記の表記はすべて引用です
なんのほん
bull 和書（Kindle Only）
bull 医療機器ソフトウェア検証妥当性確認およびコンプライアンス 医療用ソフトウェア開発では避けて通れない「バリデーション」の本質を理解しFDA規制をクリアするために
bull デビッドボーゲル (著) 酒匂寛 (翻訳) 坂井務 (翻訳) 酒井郁子 (翻訳)
bull 原著
bull Medical Device SoftwareVerificatoin Validation and Compilance
bull David A Vogel
なぜそのほんよんだ酒匂さんのPRより(13)
bull httpsmfacebookcomstoryphpstory_fbid=10152250691883859ampid=708228858
bull テーマは表題の通り「医療機器ソフトウェア検証妥当性確認およびコンプライアンス」に関するものでここで言うコンプライアンスとは特に米国FDA の規制に対するものを指しています
bull こう書くと内容的に医療機器ソフトウェアに限定された狭い話かと思われるかもしれませんが実際には全てのソフトウェア開発に関わる方々に読んでいただきたい内容となっています
なぜそのほんよんだ酒匂さんのPRより(23)
bull 若干高めではありますが妥当性確認（Validation)（正当性）検証（Verification) に興味のある組織にとって役に立つ内容だと思います
bull なお聞きなれない用語だと思われる方のために
bull 若干の補足を致しますと
bull 妥当性確認＝正しいものを作っているのか
bull 正当性検証＝正しく作っているのか
bull という区分になりますこの２つは似て非なる概念でこの２つの違いを理解しそれぞれの意義を理解することがとても大切です
なぜそのほんよんだ酒匂さんのPRより(33)
bull 本書が伝えようとしていることの一つは「妥当性確認と検証を行う意義を理解し人間の命に直接係る医療機器ソフトウェアに適用する際のアプローチを考える材料を与える結果として規制要件に対するコンプライアンスを実現できる」というものなのである
bull 妥当性確認はコストのかかる活動だしかし妥当性確認を開発作業に正しく織り込んで継続的に行うことが結果的に品質を高め市場でのリスクを回避しビジネスを成功に導くことであるということを本書は繰り返し説いているなお妥当性確認をきちんと機能させるには要件と実装の間をつなぐ追跡性の向上が必要不可欠だがこのことの大切さは本書の冒頭でも第一に触れている
bull 妥当性確認と検証はルーチンワークに落とし込まれるべきではない継続的な創造作業なのであるこうした「妥当性確認」「検証」そして「コンプライアンス」の意義の理解と合意形成を組織の中で行うためには一定の時間と労力が必要とされるそして更に実際のアクティビティへと落としこむためには本書に書かれた内容をよく理解した上でそれぞれの組織や製品に合った手法を自ら作り上げ洗練させていかなければならないその意味で「正しいやり方を教えて欲しいその通りにやるから」という態度はこの作業にもっとも向かないものと言えるであろう
bull 本書の内容が（少なくともその精神が）全てのソフトウェア技術者にとって「当たり前」のものとなるように願う
要するに私の頭の中に残ったこと
bull タイトルは医療機器といってるけどソフトウェア開発での当たり前なので読め
bull 妥当性確認＝Validation
bull 正当性検証＝Verification
bull 妥当性確認と検証は創造的な活動「正しい具体的なやり方を教えてほしいそうするから」という態度は死すべし
どんな本目次の引用
第一部背景
1 医療機器ソフトウェア妥当性確認の進化と本書の必要性
2 規制の背景
3 FDAによるソフトウェア妥当性確認規制とソフトウェアの妥当性確認が必要な理由
4 ソフトウェア妥当性確認のための組織的考慮
5 ソフトウェア（開発）ライフサイクル
6 確認と妥当性確認その実像と虚像
7 ソフトウェア妥当性確認に対するライフサイクルのアプローチ
8 ライフサイクル全体に及ぶアクティビティのサポートリスク管理
9 その他の支援活動計画レビュー構成管理欠陥管理
どんな本目次の引用
第2部医療機器ソフトウェアの妥当性確認
10 概念フェーズアクティビティ
11 ソフトウェア要件フェーズアクティビティ
12 設計および実装フェーズアクティビティ
13 テストフェーズアクティビティ
14 保守フェーズ妥当性確認アクティビティ
第3部非機器ソフトウェアの妥当性確認
15 自動化プロセスソフトウェアの妥当性確認背景
16 非機器ソフトウェアの妥当性確認を計画する
17 意図した使用と意図した使用を実現する要件
18 非機器ソフトウェアのリスク管理と構成管理ライフサイクル全体に及ぶアクティビティ
19 妥当性確認をサポートする非機器テストアクティビティ
20 非機器ソフトウェアの保守および廃棄
非医療機器のこと
読書感想のまとめ
bull 全章にわたって非常にすばらしい 一部をピックアップします
bull 3章 FDAが妥当性確認要求するときの状況としてのTherac25の惨事と原因サマリーとソフトウェアエンジニアリングの実践の関係
bull 6章 そもそも検証と妥当性確認とテストの関係とは
bull 8章リスク分類や発生確率を埋める時点で難しい残存リスクの受容をどう考えれば
bull 13章テストの心理学
bull 19章 テストする理由としない理由
bull ちなみに原著のほうが英語かつ若干高いので和書のほうがお勧めです
第3章 FDAによるソフトウェア妥当性確認規制と必要な理由
bull Therac25事件httpenwikipediaorgwikiTherac-25
bull この事故までFDAは対処した経験がほとんどなかったとのこと
bull Nancy Levesonによる要因報告を以下引用します
bull 要因は全体的に身につまされますソフトウェアに対する過信
ソフトウェアは機器のハザード分析で考慮されずハードウェアの不具合が第一に考慮されソフトウェア障害が発生した場合の適切なバックアップメカニズムがないまま安全機能の多くがソフトウェアに実装された
信頼性と安全性の混同
防衛的設計の欠如
無頓着
非現実的なリスク査定
事故報告に対する不適切な調査やフォローアップ
ソフトウェアの再利用
安全なユーザインターフェース対使いやすいユーザインターフェース
第3章 FDAによるソフトウェア妥当性確認規制と必要な理由
根本的原因除去の失敗
「ソフトウェア障害モード中にキーボードでPを押すと（中略）放射線照射が起こる可能性があったそういう「Proceed」が5回あるとシステムがシャットダウンされるこれに対するメーカの対応は「Proceed」の回数を減らすというものでシャットダウンが5回ではなく3回で始まるようになった結果幹部を攻撃する過剰照射の量は抑えられたが不具合の根本的原因はそのままだった
このエラー状態につながる一連のイベントには画面でデータを編集するためカーソルをポイントする際のオペレータによる上向き矢印の使用がふくまれていたメーカであるAtomic Energy Of Canada Limited(AECL)社の対応はTheracシステムのユー
ザに書簡を送り「キーを取り外しスイッチの接点を電気テープや他の絶縁物質で開放位置に固定すること」を要請することだった
bull 暫定対策やパッチワークを恒常化することの危険性
bull 対応を進める本人たちは迅速に顧客のための活動をしようとしているのですが
第3章 FDAによるソフトウェア妥当性確認規制と必要な理由
bull 不適切なソフトウェアエンジニアリングが要因としてあげられている
今日の先進テクノロジとテクニックへさらに25年の経験をもってしてもその要因リストで業界が完全に除去できたいうことができるものは事実上皆無なのである
不適切なソフトウェアエンジニアリングの実践
bull ソフトウェア要件と設計の文書化が後づけでなされた
bull ソフトウェアの設計と開発を制御する品質システムが整備されていなかった
bull ソフトウェア設計が過度に複雑だったと思われる
bull システムレベルのソフトウェアテストしか実行されなかったユニットレベルや統合レベルのテストとは明らかでないすべてのソフトウェア変更に関する回帰テストの計画が全然ない
bull ソフトウェアのユーザインターフェースがユーザにわかりにくいエラーメッセージが不可解
６検証と妥当性確認その実像と虚像
bull あるあるだけどその人たちに「わかってないな」と説教してもあまり伝わらない
bull テストすればよいレビューすればよいとタスクのみを認識する人を改宗することが難しい
業界には明らかに混乱や誤った情報がある当社には医療機器メーカが新しく開発した機器の仕上げ段階でその「妥当性確認」をーできれば1週間以内で－お願いしたいという契約の電話を毎週のように受けている
検証と妥当性確認の内容に関してよくある誤解からはじめよう図６１にそういう根拠のない社会通念をいくつか挙げる最初にもっともよくある誤解は製品に欠陥がないと保証するために製品開発プロセス最後で行う大量のテストを妥当性確認とするものであるこれは２つの理由で誤っているこれから見ていくように妥当性確認はソフトウェアの設計段階で欠陥を入りこませないことと入り込んでしまった欠陥を検出修正すること両方を等しく重視する
６検証と妥当性確認その実像と虚像
妥当性確認
検証
テスト
図６２ 「妥当性確認」対「検証」対「テスト」
bull これで明日からうまく説明できそうです
図６３ ソフトウェア妥当性確認の傘
妥当性確認におけるアクティビティをわかりやすく列挙されています詳しくは原著をお買い求めください
8 2 リスク管理
bull 自分の勘違いがまさに記述されていたリスク管理していればいいのではという勝手な思い込み妥当性確認アクティビティの一部なんだよな
リスク管理は妥当性確認アクティビティとみなされるリスクを特定し重大なリスクに対する制御を設計しそうした制御の有効性を検証する体系的なリスク管理プロセスはソフトウェアやシステムの信用を強化する妥当性確認の目標はソフトウェアの信用を構築することだからリスク管理が妥当性確認アクティビティあるように見えるのだ
812 リスク管理アクティビティ
bull ここでは紙面を割いてハザード分析および確率をどのようにするかが長文で記述されているソフトウェア不具合を起こしやすくする要因の列挙があり参考になった
814 リスク制御
bull ここでは具体例とともにどのようにリスクを軽減または受容するかが記述されている１例としてオッカムのかみそりの適用
bull 実際に自分の開発の中で実践している考え方と近くある意味自信を持てたがそれをどのように教育していくべきかという点で問題がありそうだと感じた なお完全なリスク像を十分に理解できたという確信は私もほしい
今度はその受容不可リスクに対する制御を設計する（または既存のものを特定する）番だ
他人によって自分の病気の母親がそのリスクにさらされたくない（すなわちもっとも単純な直感的評価であるが）なら全体的リスクは受容不可である－このことは他の定量的または定性的分析が結論付ける内容とは関係ない
リスク管理は反復的だからライフサイクル全体で行う必要があるリスク管理プロセスの方法とツールを多くしようすることが名案であることは確かだしかしいろいろな方法で生成された情報をどうまとめ有意義な全体的残存リスク査定を可能にするレビューに備えるかを考えなければならないやはり（中略）情報を1箇所に集めない限り完全なリスク像を十分に理解できたという確信を与えない
13 テストフェーズアクティビティ
bull ISTQBのFoundation Level程度に具体例とともに書かれていてすばらしい
bull テストチームと開発チームとの連携の例はシンプルかつ理解しやすい
135テストの心理学
テスト中のよくない態度を醸成するものとしてテストチームからのソフトウェアに対する一方的批判があるその埋め合わせには開発者をテスト設計のレビュアとして使用することが考えられるこれで少なくとも以下の3つが実現する
1開発者はテスト設計テスタはソフトウェアを批評するように批判の流れのバランスをとる（中略）
2開発者によるテスト設計のレビューはテスト範囲を著しく向上させる (中略）
3テスト設計のレビューはソフトウェア設計に関してと開発者がソフトウェアを機能させるために何が必要だったかの理解を向
上させる結果につながることが多い（中略）こういう情報を活用するテスタはソフトウェアで障害を起こしそうな部分に作業を集中させるそれは本書で述べてきたリスクベースの妥当性確認とテストを構成する要素の1つである
19 妥当性確認をサポートする非機器テストアクティビティ
bull 普段自分が使っているIDEやコンパイラに対するテストするしないを明確に切り分けなかった自分に気がつくことができました
bull ただしFDA規制ガイダンスは規制として有効なのか疑わしいのかとも思いました意識づけるだけなのかあまり理解しきれていません
191テストする理由しない理由
ソフトウェアテストに関する章のはじめ方としては妙かもしれないが多くの場合大量の非機器ソフトウェアテストは妥当性確認投資に効果をあげる最良の方法でない可能性がある
197要約
保守的な妥当性確認計画者はテストの計画を立てて規制問題を満たさなければならないが会社が労力に対して得る利益を最大にするため十分に計画を練ったリスクベーステストは大量である必要がないそれでも機器メーカにとって重要な欠陥の発見で生産的にすることができ安全性または規制に関する障害の発見で有効なこともある
最後に
bull 引用している情報は本全体のごくごくわずかでしかありません
bull 規制がどれだけ重量級かという説明ではなくなにのための規制なのかそしてそれをやるときにどのような困難があってどうメリットがあるかという説明になっています
bull 要件やトレーサビリティといった欠陥混入時に多大な影響をあたえるアクティビティへの対応や保守での考え方などぜひ読むべきです
bull 本書は開発ライフサイクルにも言及されていますアジャイルな人たちにもお勧めです
bull まだまだ自分自身理解しきれていないためもう一度全部読み返します
はじめに
bull おなまえ
bull とくたか (tokutaka)
bull おしごと電機メーカーでの設計チームリーダー
bull モデル検査テスト設計オブジェクト指向設計レビュー等の品質技術力向上とJIRA等ツールを用いたアジャイルチーム構築
bull どういうひと
bull てすとだいすき
bull ふぐあいだいすき
bull れびゅーだいすき
bull まさかりだいすき
bull この記述は引用箇所に用います
bull 凡例引用箇所を明確にするため下記の表記はすべて引用です
なんのほん
bull 和書（Kindle Only）
bull 医療機器ソフトウェア検証妥当性確認およびコンプライアンス 医療用ソフトウェア開発では避けて通れない「バリデーション」の本質を理解しFDA規制をクリアするために
bull デビッドボーゲル (著) 酒匂寛 (翻訳) 坂井務 (翻訳) 酒井郁子 (翻訳)
bull 原著
bull Medical Device SoftwareVerificatoin Validation and Compilance
bull David A Vogel
なぜそのほんよんだ酒匂さんのPRより(13)
bull httpsmfacebookcomstoryphpstory_fbid=10152250691883859ampid=708228858
bull テーマは表題の通り「医療機器ソフトウェア検証妥当性確認およびコンプライアンス」に関するものでここで言うコンプライアンスとは特に米国FDA の規制に対するものを指しています
bull こう書くと内容的に医療機器ソフトウェアに限定された狭い話かと思われるかもしれませんが実際には全てのソフトウェア開発に関わる方々に読んでいただきたい内容となっています
なぜそのほんよんだ酒匂さんのPRより(23)
bull 若干高めではありますが妥当性確認（Validation)（正当性）検証（Verification) に興味のある組織にとって役に立つ内容だと思います
bull なお聞きなれない用語だと思われる方のために
bull 若干の補足を致しますと
bull 妥当性確認＝正しいものを作っているのか
bull 正当性検証＝正しく作っているのか
bull という区分になりますこの２つは似て非なる概念でこの２つの違いを理解しそれぞれの意義を理解することがとても大切です
なぜそのほんよんだ酒匂さんのPRより(33)
bull 本書が伝えようとしていることの一つは「妥当性確認と検証を行う意義を理解し人間の命に直接係る医療機器ソフトウェアに適用する際のアプローチを考える材料を与える結果として規制要件に対するコンプライアンスを実現できる」というものなのである
bull 妥当性確認はコストのかかる活動だしかし妥当性確認を開発作業に正しく織り込んで継続的に行うことが結果的に品質を高め市場でのリスクを回避しビジネスを成功に導くことであるということを本書は繰り返し説いているなお妥当性確認をきちんと機能させるには要件と実装の間をつなぐ追跡性の向上が必要不可欠だがこのことの大切さは本書の冒頭でも第一に触れている
bull 妥当性確認と検証はルーチンワークに落とし込まれるべきではない継続的な創造作業なのであるこうした「妥当性確認」「検証」そして「コンプライアンス」の意義の理解と合意形成を組織の中で行うためには一定の時間と労力が必要とされるそして更に実際のアクティビティへと落としこむためには本書に書かれた内容をよく理解した上でそれぞれの組織や製品に合った手法を自ら作り上げ洗練させていかなければならないその意味で「正しいやり方を教えて欲しいその通りにやるから」という態度はこの作業にもっとも向かないものと言えるであろう
bull 本書の内容が（少なくともその精神が）全てのソフトウェア技術者にとって「当たり前」のものとなるように願う
要するに私の頭の中に残ったこと
bull タイトルは医療機器といってるけどソフトウェア開発での当たり前なので読め
bull 妥当性確認＝Validation
bull 正当性検証＝Verification
bull 妥当性確認と検証は創造的な活動「正しい具体的なやり方を教えてほしいそうするから」という態度は死すべし
どんな本目次の引用
第一部背景
1 医療機器ソフトウェア妥当性確認の進化と本書の必要性
2 規制の背景
3 FDAによるソフトウェア妥当性確認規制とソフトウェアの妥当性確認が必要な理由
4 ソフトウェア妥当性確認のための組織的考慮
5 ソフトウェア（開発）ライフサイクル
6 確認と妥当性確認その実像と虚像
7 ソフトウェア妥当性確認に対するライフサイクルのアプローチ
8 ライフサイクル全体に及ぶアクティビティのサポートリスク管理
9 その他の支援活動計画レビュー構成管理欠陥管理
どんな本目次の引用
第2部医療機器ソフトウェアの妥当性確認
10 概念フェーズアクティビティ
11 ソフトウェア要件フェーズアクティビティ
12 設計および実装フェーズアクティビティ
13 テストフェーズアクティビティ
14 保守フェーズ妥当性確認アクティビティ
第3部非機器ソフトウェアの妥当性確認
15 自動化プロセスソフトウェアの妥当性確認背景
16 非機器ソフトウェアの妥当性確認を計画する
17 意図した使用と意図した使用を実現する要件
18 非機器ソフトウェアのリスク管理と構成管理ライフサイクル全体に及ぶアクティビティ
19 妥当性確認をサポートする非機器テストアクティビティ
20 非機器ソフトウェアの保守および廃棄
非医療機器のこと
読書感想のまとめ
bull 全章にわたって非常にすばらしい 一部をピックアップします
bull 3章 FDAが妥当性確認要求するときの状況としてのTherac25の惨事と原因サマリーとソフトウェアエンジニアリングの実践の関係
bull 6章 そもそも検証と妥当性確認とテストの関係とは
bull 8章リスク分類や発生確率を埋める時点で難しい残存リスクの受容をどう考えれば
bull 13章テストの心理学
bull 19章 テストする理由としない理由
bull ちなみに原著のほうが英語かつ若干高いので和書のほうがお勧めです
第3章 FDAによるソフトウェア妥当性確認規制と必要な理由
bull Therac25事件httpenwikipediaorgwikiTherac-25
bull この事故までFDAは対処した経験がほとんどなかったとのこと
bull Nancy Levesonによる要因報告を以下引用します
bull 要因は全体的に身につまされますソフトウェアに対する過信
ソフトウェアは機器のハザード分析で考慮されずハードウェアの不具合が第一に考慮されソフトウェア障害が発生した場合の適切なバックアップメカニズムがないまま安全機能の多くがソフトウェアに実装された
信頼性と安全性の混同
防衛的設計の欠如
無頓着
非現実的なリスク査定
事故報告に対する不適切な調査やフォローアップ
ソフトウェアの再利用
安全なユーザインターフェース対使いやすいユーザインターフェース
第3章 FDAによるソフトウェア妥当性確認規制と必要な理由
根本的原因除去の失敗
「ソフトウェア障害モード中にキーボードでPを押すと（中略）放射線照射が起こる可能性があったそういう「Proceed」が5回あるとシステムがシャットダウンされるこれに対するメーカの対応は「Proceed」の回数を減らすというものでシャットダウンが5回ではなく3回で始まるようになった結果幹部を攻撃する過剰照射の量は抑えられたが不具合の根本的原因はそのままだった
このエラー状態につながる一連のイベントには画面でデータを編集するためカーソルをポイントする際のオペレータによる上向き矢印の使用がふくまれていたメーカであるAtomic Energy Of Canada Limited(AECL)社の対応はTheracシステムのユー
ザに書簡を送り「キーを取り外しスイッチの接点を電気テープや他の絶縁物質で開放位置に固定すること」を要請することだった
bull 暫定対策やパッチワークを恒常化することの危険性
bull 対応を進める本人たちは迅速に顧客のための活動をしようとしているのですが
第3章 FDAによるソフトウェア妥当性確認規制と必要な理由
bull 不適切なソフトウェアエンジニアリングが要因としてあげられている
今日の先進テクノロジとテクニックへさらに25年の経験をもってしてもその要因リストで業界が完全に除去できたいうことができるものは事実上皆無なのである
不適切なソフトウェアエンジニアリングの実践
bull ソフトウェア要件と設計の文書化が後づけでなされた
bull ソフトウェアの設計と開発を制御する品質システムが整備されていなかった
bull ソフトウェア設計が過度に複雑だったと思われる
bull システムレベルのソフトウェアテストしか実行されなかったユニットレベルや統合レベルのテストとは明らかでないすべてのソフトウェア変更に関する回帰テストの計画が全然ない
bull ソフトウェアのユーザインターフェースがユーザにわかりにくいエラーメッセージが不可解
６検証と妥当性確認その実像と虚像
bull あるあるだけどその人たちに「わかってないな」と説教してもあまり伝わらない
bull テストすればよいレビューすればよいとタスクのみを認識する人を改宗することが難しい
業界には明らかに混乱や誤った情報がある当社には医療機器メーカが新しく開発した機器の仕上げ段階でその「妥当性確認」をーできれば1週間以内で－お願いしたいという契約の電話を毎週のように受けている
検証と妥当性確認の内容に関してよくある誤解からはじめよう図６１にそういう根拠のない社会通念をいくつか挙げる最初にもっともよくある誤解は製品に欠陥がないと保証するために製品開発プロセス最後で行う大量のテストを妥当性確認とするものであるこれは２つの理由で誤っているこれから見ていくように妥当性確認はソフトウェアの設計段階で欠陥を入りこませないことと入り込んでしまった欠陥を検出修正すること両方を等しく重視する
６検証と妥当性確認その実像と虚像
妥当性確認
検証
テスト
図６２ 「妥当性確認」対「検証」対「テスト」
bull これで明日からうまく説明できそうです
図６３ ソフトウェア妥当性確認の傘
妥当性確認におけるアクティビティをわかりやすく列挙されています詳しくは原著をお買い求めください
8 2 リスク管理
bull 自分の勘違いがまさに記述されていたリスク管理していればいいのではという勝手な思い込み妥当性確認アクティビティの一部なんだよな
リスク管理は妥当性確認アクティビティとみなされるリスクを特定し重大なリスクに対する制御を設計しそうした制御の有効性を検証する体系的なリスク管理プロセスはソフトウェアやシステムの信用を強化する妥当性確認の目標はソフトウェアの信用を構築することだからリスク管理が妥当性確認アクティビティあるように見えるのだ
812 リスク管理アクティビティ
bull ここでは紙面を割いてハザード分析および確率をどのようにするかが長文で記述されているソフトウェア不具合を起こしやすくする要因の列挙があり参考になった
814 リスク制御
bull ここでは具体例とともにどのようにリスクを軽減または受容するかが記述されている１例としてオッカムのかみそりの適用
bull 実際に自分の開発の中で実践している考え方と近くある意味自信を持てたがそれをどのように教育していくべきかという点で問題がありそうだと感じた なお完全なリスク像を十分に理解できたという確信は私もほしい
今度はその受容不可リスクに対する制御を設計する（または既存のものを特定する）番だ
他人によって自分の病気の母親がそのリスクにさらされたくない（すなわちもっとも単純な直感的評価であるが）なら全体的リスクは受容不可である－このことは他の定量的または定性的分析が結論付ける内容とは関係ない
リスク管理は反復的だからライフサイクル全体で行う必要があるリスク管理プロセスの方法とツールを多くしようすることが名案であることは確かだしかしいろいろな方法で生成された情報をどうまとめ有意義な全体的残存リスク査定を可能にするレビューに備えるかを考えなければならないやはり（中略）情報を1箇所に集めない限り完全なリスク像を十分に理解できたという確信を与えない
13 テストフェーズアクティビティ
bull ISTQBのFoundation Level程度に具体例とともに書かれていてすばらしい
bull テストチームと開発チームとの連携の例はシンプルかつ理解しやすい
135テストの心理学
テスト中のよくない態度を醸成するものとしてテストチームからのソフトウェアに対する一方的批判があるその埋め合わせには開発者をテスト設計のレビュアとして使用することが考えられるこれで少なくとも以下の3つが実現する
1開発者はテスト設計テスタはソフトウェアを批評するように批判の流れのバランスをとる（中略）
2開発者によるテスト設計のレビューはテスト範囲を著しく向上させる (中略）
3テスト設計のレビューはソフトウェア設計に関してと開発者がソフトウェアを機能させるために何が必要だったかの理解を向
上させる結果につながることが多い（中略）こういう情報を活用するテスタはソフトウェアで障害を起こしそうな部分に作業を集中させるそれは本書で述べてきたリスクベースの妥当性確認とテストを構成する要素の1つである
19 妥当性確認をサポートする非機器テストアクティビティ
bull 普段自分が使っているIDEやコンパイラに対するテストするしないを明確に切り分けなかった自分に気がつくことができました
bull ただしFDA規制ガイダンスは規制として有効なのか疑わしいのかとも思いました意識づけるだけなのかあまり理解しきれていません
191テストする理由しない理由
ソフトウェアテストに関する章のはじめ方としては妙かもしれないが多くの場合大量の非機器ソフトウェアテストは妥当性確認投資に効果をあげる最良の方法でない可能性がある
197要約
保守的な妥当性確認計画者はテストの計画を立てて規制問題を満たさなければならないが会社が労力に対して得る利益を最大にするため十分に計画を練ったリスクベーステストは大量である必要がないそれでも機器メーカにとって重要な欠陥の発見で生産的にすることができ安全性または規制に関する障害の発見で有効なこともある
最後に
bull 引用している情報は本全体のごくごくわずかでしかありません
bull 規制がどれだけ重量級かという説明ではなくなにのための規制なのかそしてそれをやるときにどのような困難があってどうメリットがあるかという説明になっています
bull 要件やトレーサビリティといった欠陥混入時に多大な影響をあたえるアクティビティへの対応や保守での考え方などぜひ読むべきです
bull 本書は開発ライフサイクルにも言及されていますアジャイルな人たちにもお勧めです
bull まだまだ自分自身理解しきれていないためもう一度全部読み返します
なんのほん
bull 和書（Kindle Only）
bull 医療機器ソフトウェア検証妥当性確認およびコンプライアンス 医療用ソフトウェア開発では避けて通れない「バリデーション」の本質を理解しFDA規制をクリアするために
bull デビッドボーゲル (著) 酒匂寛 (翻訳) 坂井務 (翻訳) 酒井郁子 (翻訳)
bull 原著
bull Medical Device SoftwareVerificatoin Validation and Compilance
bull David A Vogel
なぜそのほんよんだ酒匂さんのPRより(13)
bull httpsmfacebookcomstoryphpstory_fbid=10152250691883859ampid=708228858
bull テーマは表題の通り「医療機器ソフトウェア検証妥当性確認およびコンプライアンス」に関するものでここで言うコンプライアンスとは特に米国FDA の規制に対するものを指しています
bull こう書くと内容的に医療機器ソフトウェアに限定された狭い話かと思われるかもしれませんが実際には全てのソフトウェア開発に関わる方々に読んでいただきたい内容となっています
なぜそのほんよんだ酒匂さんのPRより(23)
bull 若干高めではありますが妥当性確認（Validation)（正当性）検証（Verification) に興味のある組織にとって役に立つ内容だと思います
bull なお聞きなれない用語だと思われる方のために
bull 若干の補足を致しますと
bull 妥当性確認＝正しいものを作っているのか
bull 正当性検証＝正しく作っているのか
bull という区分になりますこの２つは似て非なる概念でこの２つの違いを理解しそれぞれの意義を理解することがとても大切です
なぜそのほんよんだ酒匂さんのPRより(33)
bull 本書が伝えようとしていることの一つは「妥当性確認と検証を行う意義を理解し人間の命に直接係る医療機器ソフトウェアに適用する際のアプローチを考える材料を与える結果として規制要件に対するコンプライアンスを実現できる」というものなのである
bull 妥当性確認はコストのかかる活動だしかし妥当性確認を開発作業に正しく織り込んで継続的に行うことが結果的に品質を高め市場でのリスクを回避しビジネスを成功に導くことであるということを本書は繰り返し説いているなお妥当性確認をきちんと機能させるには要件と実装の間をつなぐ追跡性の向上が必要不可欠だがこのことの大切さは本書の冒頭でも第一に触れている
bull 妥当性確認と検証はルーチンワークに落とし込まれるべきではない継続的な創造作業なのであるこうした「妥当性確認」「検証」そして「コンプライアンス」の意義の理解と合意形成を組織の中で行うためには一定の時間と労力が必要とされるそして更に実際のアクティビティへと落としこむためには本書に書かれた内容をよく理解した上でそれぞれの組織や製品に合った手法を自ら作り上げ洗練させていかなければならないその意味で「正しいやり方を教えて欲しいその通りにやるから」という態度はこの作業にもっとも向かないものと言えるであろう
bull 本書の内容が（少なくともその精神が）全てのソフトウェア技術者にとって「当たり前」のものとなるように願う
要するに私の頭の中に残ったこと
bull タイトルは医療機器といってるけどソフトウェア開発での当たり前なので読め
bull 妥当性確認＝Validation
bull 正当性検証＝Verification
bull 妥当性確認と検証は創造的な活動「正しい具体的なやり方を教えてほしいそうするから」という態度は死すべし
どんな本目次の引用
第一部背景
1 医療機器ソフトウェア妥当性確認の進化と本書の必要性
2 規制の背景
3 FDAによるソフトウェア妥当性確認規制とソフトウェアの妥当性確認が必要な理由
4 ソフトウェア妥当性確認のための組織的考慮
5 ソフトウェア（開発）ライフサイクル
6 確認と妥当性確認その実像と虚像
7 ソフトウェア妥当性確認に対するライフサイクルのアプローチ
8 ライフサイクル全体に及ぶアクティビティのサポートリスク管理
9 その他の支援活動計画レビュー構成管理欠陥管理
どんな本目次の引用
第2部医療機器ソフトウェアの妥当性確認
10 概念フェーズアクティビティ
11 ソフトウェア要件フェーズアクティビティ
12 設計および実装フェーズアクティビティ
13 テストフェーズアクティビティ
14 保守フェーズ妥当性確認アクティビティ
第3部非機器ソフトウェアの妥当性確認
15 自動化プロセスソフトウェアの妥当性確認背景
16 非機器ソフトウェアの妥当性確認を計画する
17 意図した使用と意図した使用を実現する要件
18 非機器ソフトウェアのリスク管理と構成管理ライフサイクル全体に及ぶアクティビティ
19 妥当性確認をサポートする非機器テストアクティビティ
20 非機器ソフトウェアの保守および廃棄
非医療機器のこと
読書感想のまとめ
bull 全章にわたって非常にすばらしい 一部をピックアップします
bull 3章 FDAが妥当性確認要求するときの状況としてのTherac25の惨事と原因サマリーとソフトウェアエンジニアリングの実践の関係
bull 6章 そもそも検証と妥当性確認とテストの関係とは
bull 8章リスク分類や発生確率を埋める時点で難しい残存リスクの受容をどう考えれば
bull 13章テストの心理学
bull 19章 テストする理由としない理由
bull ちなみに原著のほうが英語かつ若干高いので和書のほうがお勧めです
第3章 FDAによるソフトウェア妥当性確認規制と必要な理由
bull Therac25事件httpenwikipediaorgwikiTherac-25
bull この事故までFDAは対処した経験がほとんどなかったとのこと
bull Nancy Levesonによる要因報告を以下引用します
bull 要因は全体的に身につまされますソフトウェアに対する過信
ソフトウェアは機器のハザード分析で考慮されずハードウェアの不具合が第一に考慮されソフトウェア障害が発生した場合の適切なバックアップメカニズムがないまま安全機能の多くがソフトウェアに実装された
信頼性と安全性の混同
防衛的設計の欠如
無頓着
非現実的なリスク査定
事故報告に対する不適切な調査やフォローアップ
ソフトウェアの再利用
安全なユーザインターフェース対使いやすいユーザインターフェース
第3章 FDAによるソフトウェア妥当性確認規制と必要な理由
根本的原因除去の失敗
「ソフトウェア障害モード中にキーボードでPを押すと（中略）放射線照射が起こる可能性があったそういう「Proceed」が5回あるとシステムがシャットダウンされるこれに対するメーカの対応は「Proceed」の回数を減らすというものでシャットダウンが5回ではなく3回で始まるようになった結果幹部を攻撃する過剰照射の量は抑えられたが不具合の根本的原因はそのままだった
このエラー状態につながる一連のイベントには画面でデータを編集するためカーソルをポイントする際のオペレータによる上向き矢印の使用がふくまれていたメーカであるAtomic Energy Of Canada Limited(AECL)社の対応はTheracシステムのユー
ザに書簡を送り「キーを取り外しスイッチの接点を電気テープや他の絶縁物質で開放位置に固定すること」を要請することだった
bull 暫定対策やパッチワークを恒常化することの危険性
bull 対応を進める本人たちは迅速に顧客のための活動をしようとしているのですが
第3章 FDAによるソフトウェア妥当性確認規制と必要な理由
bull 不適切なソフトウェアエンジニアリングが要因としてあげられている
今日の先進テクノロジとテクニックへさらに25年の経験をもってしてもその要因リストで業界が完全に除去できたいうことができるものは事実上皆無なのである
不適切なソフトウェアエンジニアリングの実践
bull ソフトウェア要件と設計の文書化が後づけでなされた
bull ソフトウェアの設計と開発を制御する品質システムが整備されていなかった
bull ソフトウェア設計が過度に複雑だったと思われる
bull システムレベルのソフトウェアテストしか実行されなかったユニットレベルや統合レベルのテストとは明らかでないすべてのソフトウェア変更に関する回帰テストの計画が全然ない
bull ソフトウェアのユーザインターフェースがユーザにわかりにくいエラーメッセージが不可解
６検証と妥当性確認その実像と虚像
bull あるあるだけどその人たちに「わかってないな」と説教してもあまり伝わらない
bull テストすればよいレビューすればよいとタスクのみを認識する人を改宗することが難しい
業界には明らかに混乱や誤った情報がある当社には医療機器メーカが新しく開発した機器の仕上げ段階でその「妥当性確認」をーできれば1週間以内で－お願いしたいという契約の電話を毎週のように受けている
検証と妥当性確認の内容に関してよくある誤解からはじめよう図６１にそういう根拠のない社会通念をいくつか挙げる最初にもっともよくある誤解は製品に欠陥がないと保証するために製品開発プロセス最後で行う大量のテストを妥当性確認とするものであるこれは２つの理由で誤っているこれから見ていくように妥当性確認はソフトウェアの設計段階で欠陥を入りこませないことと入り込んでしまった欠陥を検出修正すること両方を等しく重視する
６検証と妥当性確認その実像と虚像
妥当性確認
検証
テスト
図６２ 「妥当性確認」対「検証」対「テスト」
bull これで明日からうまく説明できそうです
図６３ ソフトウェア妥当性確認の傘
妥当性確認におけるアクティビティをわかりやすく列挙されています詳しくは原著をお買い求めください
8 2 リスク管理
bull 自分の勘違いがまさに記述されていたリスク管理していればいいのではという勝手な思い込み妥当性確認アクティビティの一部なんだよな
リスク管理は妥当性確認アクティビティとみなされるリスクを特定し重大なリスクに対する制御を設計しそうした制御の有効性を検証する体系的なリスク管理プロセスはソフトウェアやシステムの信用を強化する妥当性確認の目標はソフトウェアの信用を構築することだからリスク管理が妥当性確認アクティビティあるように見えるのだ
812 リスク管理アクティビティ
bull ここでは紙面を割いてハザード分析および確率をどのようにするかが長文で記述されているソフトウェア不具合を起こしやすくする要因の列挙があり参考になった
814 リスク制御
bull ここでは具体例とともにどのようにリスクを軽減または受容するかが記述されている１例としてオッカムのかみそりの適用
bull 実際に自分の開発の中で実践している考え方と近くある意味自信を持てたがそれをどのように教育していくべきかという点で問題がありそうだと感じた なお完全なリスク像を十分に理解できたという確信は私もほしい
今度はその受容不可リスクに対する制御を設計する（または既存のものを特定する）番だ
他人によって自分の病気の母親がそのリスクにさらされたくない（すなわちもっとも単純な直感的評価であるが）なら全体的リスクは受容不可である－このことは他の定量的または定性的分析が結論付ける内容とは関係ない
リスク管理は反復的だからライフサイクル全体で行う必要があるリスク管理プロセスの方法とツールを多くしようすることが名案であることは確かだしかしいろいろな方法で生成された情報をどうまとめ有意義な全体的残存リスク査定を可能にするレビューに備えるかを考えなければならないやはり（中略）情報を1箇所に集めない限り完全なリスク像を十分に理解できたという確信を与えない
13 テストフェーズアクティビティ
bull ISTQBのFoundation Level程度に具体例とともに書かれていてすばらしい
bull テストチームと開発チームとの連携の例はシンプルかつ理解しやすい
135テストの心理学
テスト中のよくない態度を醸成するものとしてテストチームからのソフトウェアに対する一方的批判があるその埋め合わせには開発者をテスト設計のレビュアとして使用することが考えられるこれで少なくとも以下の3つが実現する
1開発者はテスト設計テスタはソフトウェアを批評するように批判の流れのバランスをとる（中略）
2開発者によるテスト設計のレビューはテスト範囲を著しく向上させる (中略）
3テスト設計のレビューはソフトウェア設計に関してと開発者がソフトウェアを機能させるために何が必要だったかの理解を向
上させる結果につながることが多い（中略）こういう情報を活用するテスタはソフトウェアで障害を起こしそうな部分に作業を集中させるそれは本書で述べてきたリスクベースの妥当性確認とテストを構成する要素の1つである
19 妥当性確認をサポートする非機器テストアクティビティ
bull 普段自分が使っているIDEやコンパイラに対するテストするしないを明確に切り分けなかった自分に気がつくことができました
bull ただしFDA規制ガイダンスは規制として有効なのか疑わしいのかとも思いました意識づけるだけなのかあまり理解しきれていません
191テストする理由しない理由
ソフトウェアテストに関する章のはじめ方としては妙かもしれないが多くの場合大量の非機器ソフトウェアテストは妥当性確認投資に効果をあげる最良の方法でない可能性がある
197要約
保守的な妥当性確認計画者はテストの計画を立てて規制問題を満たさなければならないが会社が労力に対して得る利益を最大にするため十分に計画を練ったリスクベーステストは大量である必要がないそれでも機器メーカにとって重要な欠陥の発見で生産的にすることができ安全性または規制に関する障害の発見で有効なこともある
最後に
bull 引用している情報は本全体のごくごくわずかでしかありません
bull 規制がどれだけ重量級かという説明ではなくなにのための規制なのかそしてそれをやるときにどのような困難があってどうメリットがあるかという説明になっています
bull 要件やトレーサビリティといった欠陥混入時に多大な影響をあたえるアクティビティへの対応や保守での考え方などぜひ読むべきです
bull 本書は開発ライフサイクルにも言及されていますアジャイルな人たちにもお勧めです
bull まだまだ自分自身理解しきれていないためもう一度全部読み返します
なぜそのほんよんだ酒匂さんのPRより(13)
bull httpsmfacebookcomstoryphpstory_fbid=10152250691883859ampid=708228858
bull テーマは表題の通り「医療機器ソフトウェア検証妥当性確認およびコンプライアンス」に関するものでここで言うコンプライアンスとは特に米国FDA の規制に対するものを指しています
bull こう書くと内容的に医療機器ソフトウェアに限定された狭い話かと思われるかもしれませんが実際には全てのソフトウェア開発に関わる方々に読んでいただきたい内容となっています
なぜそのほんよんだ酒匂さんのPRより(23)
bull 若干高めではありますが妥当性確認（Validation)（正当性）検証（Verification) に興味のある組織にとって役に立つ内容だと思います
bull なお聞きなれない用語だと思われる方のために
bull 若干の補足を致しますと
bull 妥当性確認＝正しいものを作っているのか
bull 正当性検証＝正しく作っているのか
bull という区分になりますこの２つは似て非なる概念でこの２つの違いを理解しそれぞれの意義を理解することがとても大切です
なぜそのほんよんだ酒匂さんのPRより(33)
bull 本書が伝えようとしていることの一つは「妥当性確認と検証を行う意義を理解し人間の命に直接係る医療機器ソフトウェアに適用する際のアプローチを考える材料を与える結果として規制要件に対するコンプライアンスを実現できる」というものなのである
bull 妥当性確認はコストのかかる活動だしかし妥当性確認を開発作業に正しく織り込んで継続的に行うことが結果的に品質を高め市場でのリスクを回避しビジネスを成功に導くことであるということを本書は繰り返し説いているなお妥当性確認をきちんと機能させるには要件と実装の間をつなぐ追跡性の向上が必要不可欠だがこのことの大切さは本書の冒頭でも第一に触れている
bull 妥当性確認と検証はルーチンワークに落とし込まれるべきではない継続的な創造作業なのであるこうした「妥当性確認」「検証」そして「コンプライアンス」の意義の理解と合意形成を組織の中で行うためには一定の時間と労力が必要とされるそして更に実際のアクティビティへと落としこむためには本書に書かれた内容をよく理解した上でそれぞれの組織や製品に合った手法を自ら作り上げ洗練させていかなければならないその意味で「正しいやり方を教えて欲しいその通りにやるから」という態度はこの作業にもっとも向かないものと言えるであろう
bull 本書の内容が（少なくともその精神が）全てのソフトウェア技術者にとって「当たり前」のものとなるように願う
要するに私の頭の中に残ったこと
bull タイトルは医療機器といってるけどソフトウェア開発での当たり前なので読め
bull 妥当性確認＝Validation
bull 正当性検証＝Verification
bull 妥当性確認と検証は創造的な活動「正しい具体的なやり方を教えてほしいそうするから」という態度は死すべし
どんな本目次の引用
第一部背景
1 医療機器ソフトウェア妥当性確認の進化と本書の必要性
2 規制の背景
3 FDAによるソフトウェア妥当性確認規制とソフトウェアの妥当性確認が必要な理由
4 ソフトウェア妥当性確認のための組織的考慮
5 ソフトウェア（開発）ライフサイクル
6 確認と妥当性確認その実像と虚像
7 ソフトウェア妥当性確認に対するライフサイクルのアプローチ
8 ライフサイクル全体に及ぶアクティビティのサポートリスク管理
9 その他の支援活動計画レビュー構成管理欠陥管理
どんな本目次の引用
第2部医療機器ソフトウェアの妥当性確認
10 概念フェーズアクティビティ
11 ソフトウェア要件フェーズアクティビティ
12 設計および実装フェーズアクティビティ
13 テストフェーズアクティビティ
14 保守フェーズ妥当性確認アクティビティ
第3部非機器ソフトウェアの妥当性確認
15 自動化プロセスソフトウェアの妥当性確認背景
16 非機器ソフトウェアの妥当性確認を計画する
17 意図した使用と意図した使用を実現する要件
18 非機器ソフトウェアのリスク管理と構成管理ライフサイクル全体に及ぶアクティビティ
19 妥当性確認をサポートする非機器テストアクティビティ
20 非機器ソフトウェアの保守および廃棄
非医療機器のこと
読書感想のまとめ
bull 全章にわたって非常にすばらしい 一部をピックアップします
bull 3章 FDAが妥当性確認要求するときの状況としてのTherac25の惨事と原因サマリーとソフトウェアエンジニアリングの実践の関係
bull 6章 そもそも検証と妥当性確認とテストの関係とは
bull 8章リスク分類や発生確率を埋める時点で難しい残存リスクの受容をどう考えれば
bull 13章テストの心理学
bull 19章 テストする理由としない理由
bull ちなみに原著のほうが英語かつ若干高いので和書のほうがお勧めです
第3章 FDAによるソフトウェア妥当性確認規制と必要な理由
bull Therac25事件httpenwikipediaorgwikiTherac-25
bull この事故までFDAは対処した経験がほとんどなかったとのこと
bull Nancy Levesonによる要因報告を以下引用します
bull 要因は全体的に身につまされますソフトウェアに対する過信
ソフトウェアは機器のハザード分析で考慮されずハードウェアの不具合が第一に考慮されソフトウェア障害が発生した場合の適切なバックアップメカニズムがないまま安全機能の多くがソフトウェアに実装された
信頼性と安全性の混同
防衛的設計の欠如
無頓着
非現実的なリスク査定
事故報告に対する不適切な調査やフォローアップ
ソフトウェアの再利用
安全なユーザインターフェース対使いやすいユーザインターフェース
第3章 FDAによるソフトウェア妥当性確認規制と必要な理由
根本的原因除去の失敗
「ソフトウェア障害モード中にキーボードでPを押すと（中略）放射線照射が起こる可能性があったそういう「Proceed」が5回あるとシステムがシャットダウンされるこれに対するメーカの対応は「Proceed」の回数を減らすというものでシャットダウンが5回ではなく3回で始まるようになった結果幹部を攻撃する過剰照射の量は抑えられたが不具合の根本的原因はそのままだった
このエラー状態につながる一連のイベントには画面でデータを編集するためカーソルをポイントする際のオペレータによる上向き矢印の使用がふくまれていたメーカであるAtomic Energy Of Canada Limited(AECL)社の対応はTheracシステムのユー
ザに書簡を送り「キーを取り外しスイッチの接点を電気テープや他の絶縁物質で開放位置に固定すること」を要請することだった
bull 暫定対策やパッチワークを恒常化することの危険性
bull 対応を進める本人たちは迅速に顧客のための活動をしようとしているのですが
第3章 FDAによるソフトウェア妥当性確認規制と必要な理由
bull 不適切なソフトウェアエンジニアリングが要因としてあげられている
今日の先進テクノロジとテクニックへさらに25年の経験をもってしてもその要因リストで業界が完全に除去できたいうことができるものは事実上皆無なのである
不適切なソフトウェアエンジニアリングの実践
bull ソフトウェア要件と設計の文書化が後づけでなされた
bull ソフトウェアの設計と開発を制御する品質システムが整備されていなかった
bull ソフトウェア設計が過度に複雑だったと思われる
bull システムレベルのソフトウェアテストしか実行されなかったユニットレベルや統合レベルのテストとは明らかでないすべてのソフトウェア変更に関する回帰テストの計画が全然ない
bull ソフトウェアのユーザインターフェースがユーザにわかりにくいエラーメッセージが不可解
６検証と妥当性確認その実像と虚像
bull あるあるだけどその人たちに「わかってないな」と説教してもあまり伝わらない
bull テストすればよいレビューすればよいとタスクのみを認識する人を改宗することが難しい
業界には明らかに混乱や誤った情報がある当社には医療機器メーカが新しく開発した機器の仕上げ段階でその「妥当性確認」をーできれば1週間以内で－お願いしたいという契約の電話を毎週のように受けている
検証と妥当性確認の内容に関してよくある誤解からはじめよう図６１にそういう根拠のない社会通念をいくつか挙げる最初にもっともよくある誤解は製品に欠陥がないと保証するために製品開発プロセス最後で行う大量のテストを妥当性確認とするものであるこれは２つの理由で誤っているこれから見ていくように妥当性確認はソフトウェアの設計段階で欠陥を入りこませないことと入り込んでしまった欠陥を検出修正すること両方を等しく重視する
６検証と妥当性確認その実像と虚像
妥当性確認
検証
テスト
図６２ 「妥当性確認」対「検証」対「テスト」
bull これで明日からうまく説明できそうです
図６３ ソフトウェア妥当性確認の傘
妥当性確認におけるアクティビティをわかりやすく列挙されています詳しくは原著をお買い求めください
8 2 リスク管理
bull 自分の勘違いがまさに記述されていたリスク管理していればいいのではという勝手な思い込み妥当性確認アクティビティの一部なんだよな
リスク管理は妥当性確認アクティビティとみなされるリスクを特定し重大なリスクに対する制御を設計しそうした制御の有効性を検証する体系的なリスク管理プロセスはソフトウェアやシステムの信用を強化する妥当性確認の目標はソフトウェアの信用を構築することだからリスク管理が妥当性確認アクティビティあるように見えるのだ
812 リスク管理アクティビティ
bull ここでは紙面を割いてハザード分析および確率をどのようにするかが長文で記述されているソフトウェア不具合を起こしやすくする要因の列挙があり参考になった
814 リスク制御
bull ここでは具体例とともにどのようにリスクを軽減または受容するかが記述されている１例としてオッカムのかみそりの適用
bull 実際に自分の開発の中で実践している考え方と近くある意味自信を持てたがそれをどのように教育していくべきかという点で問題がありそうだと感じた なお完全なリスク像を十分に理解できたという確信は私もほしい
今度はその受容不可リスクに対する制御を設計する（または既存のものを特定する）番だ
他人によって自分の病気の母親がそのリスクにさらされたくない（すなわちもっとも単純な直感的評価であるが）なら全体的リスクは受容不可である－このことは他の定量的または定性的分析が結論付ける内容とは関係ない
リスク管理は反復的だからライフサイクル全体で行う必要があるリスク管理プロセスの方法とツールを多くしようすることが名案であることは確かだしかしいろいろな方法で生成された情報をどうまとめ有意義な全体的残存リスク査定を可能にするレビューに備えるかを考えなければならないやはり（中略）情報を1箇所に集めない限り完全なリスク像を十分に理解できたという確信を与えない
13 テストフェーズアクティビティ
bull ISTQBのFoundation Level程度に具体例とともに書かれていてすばらしい
bull テストチームと開発チームとの連携の例はシンプルかつ理解しやすい
135テストの心理学
テスト中のよくない態度を醸成するものとしてテストチームからのソフトウェアに対する一方的批判があるその埋め合わせには開発者をテスト設計のレビュアとして使用することが考えられるこれで少なくとも以下の3つが実現する
1開発者はテスト設計テスタはソフトウェアを批評するように批判の流れのバランスをとる（中略）
2開発者によるテスト設計のレビューはテスト範囲を著しく向上させる (中略）
3テスト設計のレビューはソフトウェア設計に関してと開発者がソフトウェアを機能させるために何が必要だったかの理解を向
上させる結果につながることが多い（中略）こういう情報を活用するテスタはソフトウェアで障害を起こしそうな部分に作業を集中させるそれは本書で述べてきたリスクベースの妥当性確認とテストを構成する要素の1つである
19 妥当性確認をサポートする非機器テストアクティビティ
bull 普段自分が使っているIDEやコンパイラに対するテストするしないを明確に切り分けなかった自分に気がつくことができました
bull ただしFDA規制ガイダンスは規制として有効なのか疑わしいのかとも思いました意識づけるだけなのかあまり理解しきれていません
191テストする理由しない理由
ソフトウェアテストに関する章のはじめ方としては妙かもしれないが多くの場合大量の非機器ソフトウェアテストは妥当性確認投資に効果をあげる最良の方法でない可能性がある
197要約
保守的な妥当性確認計画者はテストの計画を立てて規制問題を満たさなければならないが会社が労力に対して得る利益を最大にするため十分に計画を練ったリスクベーステストは大量である必要がないそれでも機器メーカにとって重要な欠陥の発見で生産的にすることができ安全性または規制に関する障害の発見で有効なこともある
最後に
bull 引用している情報は本全体のごくごくわずかでしかありません
bull 規制がどれだけ重量級かという説明ではなくなにのための規制なのかそしてそれをやるときにどのような困難があってどうメリットがあるかという説明になっています
bull 要件やトレーサビリティといった欠陥混入時に多大な影響をあたえるアクティビティへの対応や保守での考え方などぜひ読むべきです
bull 本書は開発ライフサイクルにも言及されていますアジャイルな人たちにもお勧めです
bull まだまだ自分自身理解しきれていないためもう一度全部読み返します
なぜそのほんよんだ酒匂さんのPRより(23)
bull 若干高めではありますが妥当性確認（Validation)（正当性）検証（Verification) に興味のある組織にとって役に立つ内容だと思います
bull なお聞きなれない用語だと思われる方のために
bull 若干の補足を致しますと
bull 妥当性確認＝正しいものを作っているのか
bull 正当性検証＝正しく作っているのか
bull という区分になりますこの２つは似て非なる概念でこの２つの違いを理解しそれぞれの意義を理解することがとても大切です
なぜそのほんよんだ酒匂さんのPRより(33)
bull 本書が伝えようとしていることの一つは「妥当性確認と検証を行う意義を理解し人間の命に直接係る医療機器ソフトウェアに適用する際のアプローチを考える材料を与える結果として規制要件に対するコンプライアンスを実現できる」というものなのである
bull 妥当性確認はコストのかかる活動だしかし妥当性確認を開発作業に正しく織り込んで継続的に行うことが結果的に品質を高め市場でのリスクを回避しビジネスを成功に導くことであるということを本書は繰り返し説いているなお妥当性確認をきちんと機能させるには要件と実装の間をつなぐ追跡性の向上が必要不可欠だがこのことの大切さは本書の冒頭でも第一に触れている
bull 妥当性確認と検証はルーチンワークに落とし込まれるべきではない継続的な創造作業なのであるこうした「妥当性確認」「検証」そして「コンプライアンス」の意義の理解と合意形成を組織の中で行うためには一定の時間と労力が必要とされるそして更に実際のアクティビティへと落としこむためには本書に書かれた内容をよく理解した上でそれぞれの組織や製品に合った手法を自ら作り上げ洗練させていかなければならないその意味で「正しいやり方を教えて欲しいその通りにやるから」という態度はこの作業にもっとも向かないものと言えるであろう
bull 本書の内容が（少なくともその精神が）全てのソフトウェア技術者にとって「当たり前」のものとなるように願う
要するに私の頭の中に残ったこと
bull タイトルは医療機器といってるけどソフトウェア開発での当たり前なので読め
bull 妥当性確認＝Validation
bull 正当性検証＝Verification
bull 妥当性確認と検証は創造的な活動「正しい具体的なやり方を教えてほしいそうするから」という態度は死すべし
どんな本目次の引用
第一部背景
1 医療機器ソフトウェア妥当性確認の進化と本書の必要性
2 規制の背景
3 FDAによるソフトウェア妥当性確認規制とソフトウェアの妥当性確認が必要な理由
4 ソフトウェア妥当性確認のための組織的考慮
5 ソフトウェア（開発）ライフサイクル
6 確認と妥当性確認その実像と虚像
7 ソフトウェア妥当性確認に対するライフサイクルのアプローチ
8 ライフサイクル全体に及ぶアクティビティのサポートリスク管理
9 その他の支援活動計画レビュー構成管理欠陥管理
どんな本目次の引用
第2部医療機器ソフトウェアの妥当性確認
10 概念フェーズアクティビティ
11 ソフトウェア要件フェーズアクティビティ
12 設計および実装フェーズアクティビティ
13 テストフェーズアクティビティ
14 保守フェーズ妥当性確認アクティビティ
第3部非機器ソフトウェアの妥当性確認
15 自動化プロセスソフトウェアの妥当性確認背景
16 非機器ソフトウェアの妥当性確認を計画する
17 意図した使用と意図した使用を実現する要件
18 非機器ソフトウェアのリスク管理と構成管理ライフサイクル全体に及ぶアクティビティ
19 妥当性確認をサポートする非機器テストアクティビティ
20 非機器ソフトウェアの保守および廃棄
非医療機器のこと
読書感想のまとめ
bull 全章にわたって非常にすばらしい 一部をピックアップします
bull 3章 FDAが妥当性確認要求するときの状況としてのTherac25の惨事と原因サマリーとソフトウェアエンジニアリングの実践の関係
bull 6章 そもそも検証と妥当性確認とテストの関係とは
bull 8章リスク分類や発生確率を埋める時点で難しい残存リスクの受容をどう考えれば
bull 13章テストの心理学
bull 19章 テストする理由としない理由
bull ちなみに原著のほうが英語かつ若干高いので和書のほうがお勧めです
第3章 FDAによるソフトウェア妥当性確認規制と必要な理由
bull Therac25事件httpenwikipediaorgwikiTherac-25
bull この事故までFDAは対処した経験がほとんどなかったとのこと
bull Nancy Levesonによる要因報告を以下引用します
bull 要因は全体的に身につまされますソフトウェアに対する過信
ソフトウェアは機器のハザード分析で考慮されずハードウェアの不具合が第一に考慮されソフトウェア障害が発生した場合の適切なバックアップメカニズムがないまま安全機能の多くがソフトウェアに実装された
信頼性と安全性の混同
防衛的設計の欠如
無頓着
非現実的なリスク査定
事故報告に対する不適切な調査やフォローアップ
ソフトウェアの再利用
安全なユーザインターフェース対使いやすいユーザインターフェース
第3章 FDAによるソフトウェア妥当性確認規制と必要な理由
根本的原因除去の失敗
「ソフトウェア障害モード中にキーボードでPを押すと（中略）放射線照射が起こる可能性があったそういう「Proceed」が5回あるとシステムがシャットダウンされるこれに対するメーカの対応は「Proceed」の回数を減らすというものでシャットダウンが5回ではなく3回で始まるようになった結果幹部を攻撃する過剰照射の量は抑えられたが不具合の根本的原因はそのままだった
このエラー状態につながる一連のイベントには画面でデータを編集するためカーソルをポイントする際のオペレータによる上向き矢印の使用がふくまれていたメーカであるAtomic Energy Of Canada Limited(AECL)社の対応はTheracシステムのユー
ザに書簡を送り「キーを取り外しスイッチの接点を電気テープや他の絶縁物質で開放位置に固定すること」を要請することだった
bull 暫定対策やパッチワークを恒常化することの危険性
bull 対応を進める本人たちは迅速に顧客のための活動をしようとしているのですが
第3章 FDAによるソフトウェア妥当性確認規制と必要な理由
bull 不適切なソフトウェアエンジニアリングが要因としてあげられている
今日の先進テクノロジとテクニックへさらに25年の経験をもってしてもその要因リストで業界が完全に除去できたいうことができるものは事実上皆無なのである
不適切なソフトウェアエンジニアリングの実践
bull ソフトウェア要件と設計の文書化が後づけでなされた
bull ソフトウェアの設計と開発を制御する品質システムが整備されていなかった
bull ソフトウェア設計が過度に複雑だったと思われる
bull システムレベルのソフトウェアテストしか実行されなかったユニットレベルや統合レベルのテストとは明らかでないすべてのソフトウェア変更に関する回帰テストの計画が全然ない
bull ソフトウェアのユーザインターフェースがユーザにわかりにくいエラーメッセージが不可解
６検証と妥当性確認その実像と虚像
bull あるあるだけどその人たちに「わかってないな」と説教してもあまり伝わらない
bull テストすればよいレビューすればよいとタスクのみを認識する人を改宗することが難しい
業界には明らかに混乱や誤った情報がある当社には医療機器メーカが新しく開発した機器の仕上げ段階でその「妥当性確認」をーできれば1週間以内で－お願いしたいという契約の電話を毎週のように受けている
検証と妥当性確認の内容に関してよくある誤解からはじめよう図６１にそういう根拠のない社会通念をいくつか挙げる最初にもっともよくある誤解は製品に欠陥がないと保証するために製品開発プロセス最後で行う大量のテストを妥当性確認とするものであるこれは２つの理由で誤っているこれから見ていくように妥当性確認はソフトウェアの設計段階で欠陥を入りこませないことと入り込んでしまった欠陥を検出修正すること両方を等しく重視する
６検証と妥当性確認その実像と虚像
妥当性確認
検証
テスト
図６２ 「妥当性確認」対「検証」対「テスト」
bull これで明日からうまく説明できそうです
図６３ ソフトウェア妥当性確認の傘
妥当性確認におけるアクティビティをわかりやすく列挙されています詳しくは原著をお買い求めください
8 2 リスク管理
bull 自分の勘違いがまさに記述されていたリスク管理していればいいのではという勝手な思い込み妥当性確認アクティビティの一部なんだよな
リスク管理は妥当性確認アクティビティとみなされるリスクを特定し重大なリスクに対する制御を設計しそうした制御の有効性を検証する体系的なリスク管理プロセスはソフトウェアやシステムの信用を強化する妥当性確認の目標はソフトウェアの信用を構築することだからリスク管理が妥当性確認アクティビティあるように見えるのだ
812 リスク管理アクティビティ
bull ここでは紙面を割いてハザード分析および確率をどのようにするかが長文で記述されているソフトウェア不具合を起こしやすくする要因の列挙があり参考になった
814 リスク制御
bull ここでは具体例とともにどのようにリスクを軽減または受容するかが記述されている１例としてオッカムのかみそりの適用
bull 実際に自分の開発の中で実践している考え方と近くある意味自信を持てたがそれをどのように教育していくべきかという点で問題がありそうだと感じた なお完全なリスク像を十分に理解できたという確信は私もほしい
今度はその受容不可リスクに対する制御を設計する（または既存のものを特定する）番だ
他人によって自分の病気の母親がそのリスクにさらされたくない（すなわちもっとも単純な直感的評価であるが）なら全体的リスクは受容不可である－このことは他の定量的または定性的分析が結論付ける内容とは関係ない
リスク管理は反復的だからライフサイクル全体で行う必要があるリスク管理プロセスの方法とツールを多くしようすることが名案であることは確かだしかしいろいろな方法で生成された情報をどうまとめ有意義な全体的残存リスク査定を可能にするレビューに備えるかを考えなければならないやはり（中略）情報を1箇所に集めない限り完全なリスク像を十分に理解できたという確信を与えない
13 テストフェーズアクティビティ
bull ISTQBのFoundation Level程度に具体例とともに書かれていてすばらしい
bull テストチームと開発チームとの連携の例はシンプルかつ理解しやすい
135テストの心理学
テスト中のよくない態度を醸成するものとしてテストチームからのソフトウェアに対する一方的批判があるその埋め合わせには開発者をテスト設計のレビュアとして使用することが考えられるこれで少なくとも以下の3つが実現する
1開発者はテスト設計テスタはソフトウェアを批評するように批判の流れのバランスをとる（中略）
2開発者によるテスト設計のレビューはテスト範囲を著しく向上させる (中略）
3テスト設計のレビューはソフトウェア設計に関してと開発者がソフトウェアを機能させるために何が必要だったかの理解を向
上させる結果につながることが多い（中略）こういう情報を活用するテスタはソフトウェアで障害を起こしそうな部分に作業を集中させるそれは本書で述べてきたリスクベースの妥当性確認とテストを構成する要素の1つである
19 妥当性確認をサポートする非機器テストアクティビティ
bull 普段自分が使っているIDEやコンパイラに対するテストするしないを明確に切り分けなかった自分に気がつくことができました
bull ただしFDA規制ガイダンスは規制として有効なのか疑わしいのかとも思いました意識づけるだけなのかあまり理解しきれていません
191テストする理由しない理由
ソフトウェアテストに関する章のはじめ方としては妙かもしれないが多くの場合大量の非機器ソフトウェアテストは妥当性確認投資に効果をあげる最良の方法でない可能性がある
197要約
保守的な妥当性確認計画者はテストの計画を立てて規制問題を満たさなければならないが会社が労力に対して得る利益を最大にするため十分に計画を練ったリスクベーステストは大量である必要がないそれでも機器メーカにとって重要な欠陥の発見で生産的にすることができ安全性または規制に関する障害の発見で有効なこともある
最後に
bull 引用している情報は本全体のごくごくわずかでしかありません
bull 規制がどれだけ重量級かという説明ではなくなにのための規制なのかそしてそれをやるときにどのような困難があってどうメリットがあるかという説明になっています
bull 要件やトレーサビリティといった欠陥混入時に多大な影響をあたえるアクティビティへの対応や保守での考え方などぜひ読むべきです
bull 本書は開発ライフサイクルにも言及されていますアジャイルな人たちにもお勧めです
bull まだまだ自分自身理解しきれていないためもう一度全部読み返します
なぜそのほんよんだ酒匂さんのPRより(33)
bull 本書が伝えようとしていることの一つは「妥当性確認と検証を行う意義を理解し人間の命に直接係る医療機器ソフトウェアに適用する際のアプローチを考える材料を与える結果として規制要件に対するコンプライアンスを実現できる」というものなのである
bull 妥当性確認はコストのかかる活動だしかし妥当性確認を開発作業に正しく織り込んで継続的に行うことが結果的に品質を高め市場でのリスクを回避しビジネスを成功に導くことであるということを本書は繰り返し説いているなお妥当性確認をきちんと機能させるには要件と実装の間をつなぐ追跡性の向上が必要不可欠だがこのことの大切さは本書の冒頭でも第一に触れている
bull 妥当性確認と検証はルーチンワークに落とし込まれるべきではない継続的な創造作業なのであるこうした「妥当性確認」「検証」そして「コンプライアンス」の意義の理解と合意形成を組織の中で行うためには一定の時間と労力が必要とされるそして更に実際のアクティビティへと落としこむためには本書に書かれた内容をよく理解した上でそれぞれの組織や製品に合った手法を自ら作り上げ洗練させていかなければならないその意味で「正しいやり方を教えて欲しいその通りにやるから」という態度はこの作業にもっとも向かないものと言えるであろう
bull 本書の内容が（少なくともその精神が）全てのソフトウェア技術者にとって「当たり前」のものとなるように願う
要するに私の頭の中に残ったこと
bull タイトルは医療機器といってるけどソフトウェア開発での当たり前なので読め
bull 妥当性確認＝Validation
bull 正当性検証＝Verification
bull 妥当性確認と検証は創造的な活動「正しい具体的なやり方を教えてほしいそうするから」という態度は死すべし
どんな本目次の引用
第一部背景
1 医療機器ソフトウェア妥当性確認の進化と本書の必要性
2 規制の背景
3 FDAによるソフトウェア妥当性確認規制とソフトウェアの妥当性確認が必要な理由
4 ソフトウェア妥当性確認のための組織的考慮
5 ソフトウェア（開発）ライフサイクル
6 確認と妥当性確認その実像と虚像
7 ソフトウェア妥当性確認に対するライフサイクルのアプローチ
8 ライフサイクル全体に及ぶアクティビティのサポートリスク管理
9 その他の支援活動計画レビュー構成管理欠陥管理
どんな本目次の引用
第2部医療機器ソフトウェアの妥当性確認
10 概念フェーズアクティビティ
11 ソフトウェア要件フェーズアクティビティ
12 設計および実装フェーズアクティビティ
13 テストフェーズアクティビティ
14 保守フェーズ妥当性確認アクティビティ
第3部非機器ソフトウェアの妥当性確認
15 自動化プロセスソフトウェアの妥当性確認背景
16 非機器ソフトウェアの妥当性確認を計画する
17 意図した使用と意図した使用を実現する要件
18 非機器ソフトウェアのリスク管理と構成管理ライフサイクル全体に及ぶアクティビティ
19 妥当性確認をサポートする非機器テストアクティビティ
20 非機器ソフトウェアの保守および廃棄
非医療機器のこと
読書感想のまとめ
bull 全章にわたって非常にすばらしい 一部をピックアップします
bull 3章 FDAが妥当性確認要求するときの状況としてのTherac25の惨事と原因サマリーとソフトウェアエンジニアリングの実践の関係
bull 6章 そもそも検証と妥当性確認とテストの関係とは
bull 8章リスク分類や発生確率を埋める時点で難しい残存リスクの受容をどう考えれば
bull 13章テストの心理学
bull 19章 テストする理由としない理由
bull ちなみに原著のほうが英語かつ若干高いので和書のほうがお勧めです
第3章 FDAによるソフトウェア妥当性確認規制と必要な理由
bull Therac25事件httpenwikipediaorgwikiTherac-25
bull この事故までFDAは対処した経験がほとんどなかったとのこと
bull Nancy Levesonによる要因報告を以下引用します
bull 要因は全体的に身につまされますソフトウェアに対する過信
ソフトウェアは機器のハザード分析で考慮されずハードウェアの不具合が第一に考慮されソフトウェア障害が発生した場合の適切なバックアップメカニズムがないまま安全機能の多くがソフトウェアに実装された
信頼性と安全性の混同
防衛的設計の欠如
無頓着
非現実的なリスク査定
事故報告に対する不適切な調査やフォローアップ
ソフトウェアの再利用
安全なユーザインターフェース対使いやすいユーザインターフェース
第3章 FDAによるソフトウェア妥当性確認規制と必要な理由
根本的原因除去の失敗
「ソフトウェア障害モード中にキーボードでPを押すと（中略）放射線照射が起こる可能性があったそういう「Proceed」が5回あるとシステムがシャットダウンされるこれに対するメーカの対応は「Proceed」の回数を減らすというものでシャットダウンが5回ではなく3回で始まるようになった結果幹部を攻撃する過剰照射の量は抑えられたが不具合の根本的原因はそのままだった
このエラー状態につながる一連のイベントには画面でデータを編集するためカーソルをポイントする際のオペレータによる上向き矢印の使用がふくまれていたメーカであるAtomic Energy Of Canada Limited(AECL)社の対応はTheracシステムのユー
ザに書簡を送り「キーを取り外しスイッチの接点を電気テープや他の絶縁物質で開放位置に固定すること」を要請することだった
bull 暫定対策やパッチワークを恒常化することの危険性
bull 対応を進める本人たちは迅速に顧客のための活動をしようとしているのですが
第3章 FDAによるソフトウェア妥当性確認規制と必要な理由
bull 不適切なソフトウェアエンジニアリングが要因としてあげられている
今日の先進テクノロジとテクニックへさらに25年の経験をもってしてもその要因リストで業界が完全に除去できたいうことができるものは事実上皆無なのである
不適切なソフトウェアエンジニアリングの実践
bull ソフトウェア要件と設計の文書化が後づけでなされた
bull ソフトウェアの設計と開発を制御する品質システムが整備されていなかった
bull ソフトウェア設計が過度に複雑だったと思われる
bull システムレベルのソフトウェアテストしか実行されなかったユニットレベルや統合レベルのテストとは明らかでないすべてのソフトウェア変更に関する回帰テストの計画が全然ない
bull ソフトウェアのユーザインターフェースがユーザにわかりにくいエラーメッセージが不可解
６検証と妥当性確認その実像と虚像
bull あるあるだけどその人たちに「わかってないな」と説教してもあまり伝わらない
bull テストすればよいレビューすればよいとタスクのみを認識する人を改宗することが難しい
業界には明らかに混乱や誤った情報がある当社には医療機器メーカが新しく開発した機器の仕上げ段階でその「妥当性確認」をーできれば1週間以内で－お願いしたいという契約の電話を毎週のように受けている
検証と妥当性確認の内容に関してよくある誤解からはじめよう図６１にそういう根拠のない社会通念をいくつか挙げる最初にもっともよくある誤解は製品に欠陥がないと保証するために製品開発プロセス最後で行う大量のテストを妥当性確認とするものであるこれは２つの理由で誤っているこれから見ていくように妥当性確認はソフトウェアの設計段階で欠陥を入りこませないことと入り込んでしまった欠陥を検出修正すること両方を等しく重視する
６検証と妥当性確認その実像と虚像
妥当性確認
検証
テスト
図６２ 「妥当性確認」対「検証」対「テスト」
bull これで明日からうまく説明できそうです
図６３ ソフトウェア妥当性確認の傘
妥当性確認におけるアクティビティをわかりやすく列挙されています詳しくは原著をお買い求めください
8 2 リスク管理
bull 自分の勘違いがまさに記述されていたリスク管理していればいいのではという勝手な思い込み妥当性確認アクティビティの一部なんだよな
リスク管理は妥当性確認アクティビティとみなされるリスクを特定し重大なリスクに対する制御を設計しそうした制御の有効性を検証する体系的なリスク管理プロセスはソフトウェアやシステムの信用を強化する妥当性確認の目標はソフトウェアの信用を構築することだからリスク管理が妥当性確認アクティビティあるように見えるのだ
812 リスク管理アクティビティ
bull ここでは紙面を割いてハザード分析および確率をどのようにするかが長文で記述されているソフトウェア不具合を起こしやすくする要因の列挙があり参考になった
814 リスク制御
bull ここでは具体例とともにどのようにリスクを軽減または受容するかが記述されている１例としてオッカムのかみそりの適用
bull 実際に自分の開発の中で実践している考え方と近くある意味自信を持てたがそれをどのように教育していくべきかという点で問題がありそうだと感じた なお完全なリスク像を十分に理解できたという確信は私もほしい
今度はその受容不可リスクに対する制御を設計する（または既存のものを特定する）番だ
他人によって自分の病気の母親がそのリスクにさらされたくない（すなわちもっとも単純な直感的評価であるが）なら全体的リスクは受容不可である－このことは他の定量的または定性的分析が結論付ける内容とは関係ない
リスク管理は反復的だからライフサイクル全体で行う必要があるリスク管理プロセスの方法とツールを多くしようすることが名案であることは確かだしかしいろいろな方法で生成された情報をどうまとめ有意義な全体的残存リスク査定を可能にするレビューに備えるかを考えなければならないやはり（中略）情報を1箇所に集めない限り完全なリスク像を十分に理解できたという確信を与えない
13 テストフェーズアクティビティ
bull ISTQBのFoundation Level程度に具体例とともに書かれていてすばらしい
bull テストチームと開発チームとの連携の例はシンプルかつ理解しやすい
135テストの心理学
テスト中のよくない態度を醸成するものとしてテストチームからのソフトウェアに対する一方的批判があるその埋め合わせには開発者をテスト設計のレビュアとして使用することが考えられるこれで少なくとも以下の3つが実現する
1開発者はテスト設計テスタはソフトウェアを批評するように批判の流れのバランスをとる（中略）
2開発者によるテスト設計のレビューはテスト範囲を著しく向上させる (中略）
3テスト設計のレビューはソフトウェア設計に関してと開発者がソフトウェアを機能させるために何が必要だったかの理解を向
上させる結果につながることが多い（中略）こういう情報を活用するテスタはソフトウェアで障害を起こしそうな部分に作業を集中させるそれは本書で述べてきたリスクベースの妥当性確認とテストを構成する要素の1つである
19 妥当性確認をサポートする非機器テストアクティビティ
bull 普段自分が使っているIDEやコンパイラに対するテストするしないを明確に切り分けなかった自分に気がつくことができました
bull ただしFDA規制ガイダンスは規制として有効なのか疑わしいのかとも思いました意識づけるだけなのかあまり理解しきれていません
191テストする理由しない理由
ソフトウェアテストに関する章のはじめ方としては妙かもしれないが多くの場合大量の非機器ソフトウェアテストは妥当性確認投資に効果をあげる最良の方法でない可能性がある
197要約
保守的な妥当性確認計画者はテストの計画を立てて規制問題を満たさなければならないが会社が労力に対して得る利益を最大にするため十分に計画を練ったリスクベーステストは大量である必要がないそれでも機器メーカにとって重要な欠陥の発見で生産的にすることができ安全性または規制に関する障害の発見で有効なこともある
最後に
bull 引用している情報は本全体のごくごくわずかでしかありません
bull 規制がどれだけ重量級かという説明ではなくなにのための規制なのかそしてそれをやるときにどのような困難があってどうメリットがあるかという説明になっています
bull 要件やトレーサビリティといった欠陥混入時に多大な影響をあたえるアクティビティへの対応や保守での考え方などぜひ読むべきです
bull 本書は開発ライフサイクルにも言及されていますアジャイルな人たちにもお勧めです
bull まだまだ自分自身理解しきれていないためもう一度全部読み返します
要するに私の頭の中に残ったこと
bull タイトルは医療機器といってるけどソフトウェア開発での当たり前なので読め
bull 妥当性確認＝Validation
bull 正当性検証＝Verification
bull 妥当性確認と検証は創造的な活動「正しい具体的なやり方を教えてほしいそうするから」という態度は死すべし
どんな本目次の引用
第一部背景
1 医療機器ソフトウェア妥当性確認の進化と本書の必要性
2 規制の背景
3 FDAによるソフトウェア妥当性確認規制とソフトウェアの妥当性確認が必要な理由
4 ソフトウェア妥当性確認のための組織的考慮
5 ソフトウェア（開発）ライフサイクル
6 確認と妥当性確認その実像と虚像
7 ソフトウェア妥当性確認に対するライフサイクルのアプローチ
8 ライフサイクル全体に及ぶアクティビティのサポートリスク管理
9 その他の支援活動計画レビュー構成管理欠陥管理
どんな本目次の引用
第2部医療機器ソフトウェアの妥当性確認
10 概念フェーズアクティビティ
11 ソフトウェア要件フェーズアクティビティ
12 設計および実装フェーズアクティビティ
13 テストフェーズアクティビティ
14 保守フェーズ妥当性確認アクティビティ
第3部非機器ソフトウェアの妥当性確認
15 自動化プロセスソフトウェアの妥当性確認背景
16 非機器ソフトウェアの妥当性確認を計画する
17 意図した使用と意図した使用を実現する要件
18 非機器ソフトウェアのリスク管理と構成管理ライフサイクル全体に及ぶアクティビティ
19 妥当性確認をサポートする非機器テストアクティビティ
20 非機器ソフトウェアの保守および廃棄
非医療機器のこと
読書感想のまとめ
bull 全章にわたって非常にすばらしい 一部をピックアップします
bull 3章 FDAが妥当性確認要求するときの状況としてのTherac25の惨事と原因サマリーとソフトウェアエンジニアリングの実践の関係
bull 6章 そもそも検証と妥当性確認とテストの関係とは
bull 8章リスク分類や発生確率を埋める時点で難しい残存リスクの受容をどう考えれば
bull 13章テストの心理学
bull 19章 テストする理由としない理由
bull ちなみに原著のほうが英語かつ若干高いので和書のほうがお勧めです
第3章 FDAによるソフトウェア妥当性確認規制と必要な理由
bull Therac25事件httpenwikipediaorgwikiTherac-25
bull この事故までFDAは対処した経験がほとんどなかったとのこと
bull Nancy Levesonによる要因報告を以下引用します
bull 要因は全体的に身につまされますソフトウェアに対する過信
ソフトウェアは機器のハザード分析で考慮されずハードウェアの不具合が第一に考慮されソフトウェア障害が発生した場合の適切なバックアップメカニズムがないまま安全機能の多くがソフトウェアに実装された
信頼性と安全性の混同
防衛的設計の欠如
無頓着
非現実的なリスク査定
事故報告に対する不適切な調査やフォローアップ
ソフトウェアの再利用
安全なユーザインターフェース対使いやすいユーザインターフェース
第3章 FDAによるソフトウェア妥当性確認規制と必要な理由
根本的原因除去の失敗
「ソフトウェア障害モード中にキーボードでPを押すと（中略）放射線照射が起こる可能性があったそういう「Proceed」が5回あるとシステムがシャットダウンされるこれに対するメーカの対応は「Proceed」の回数を減らすというものでシャットダウンが5回ではなく3回で始まるようになった結果幹部を攻撃する過剰照射の量は抑えられたが不具合の根本的原因はそのままだった
このエラー状態につながる一連のイベントには画面でデータを編集するためカーソルをポイントする際のオペレータによる上向き矢印の使用がふくまれていたメーカであるAtomic Energy Of Canada Limited(AECL)社の対応はTheracシステムのユー
ザに書簡を送り「キーを取り外しスイッチの接点を電気テープや他の絶縁物質で開放位置に固定すること」を要請することだった
bull 暫定対策やパッチワークを恒常化することの危険性
bull 対応を進める本人たちは迅速に顧客のための活動をしようとしているのですが
第3章 FDAによるソフトウェア妥当性確認規制と必要な理由
bull 不適切なソフトウェアエンジニアリングが要因としてあげられている
今日の先進テクノロジとテクニックへさらに25年の経験をもってしてもその要因リストで業界が完全に除去できたいうことができるものは事実上皆無なのである
不適切なソフトウェアエンジニアリングの実践
bull ソフトウェア要件と設計の文書化が後づけでなされた
bull ソフトウェアの設計と開発を制御する品質システムが整備されていなかった
bull ソフトウェア設計が過度に複雑だったと思われる
bull システムレベルのソフトウェアテストしか実行されなかったユニットレベルや統合レベルのテストとは明らかでないすべてのソフトウェア変更に関する回帰テストの計画が全然ない
bull ソフトウェアのユーザインターフェースがユーザにわかりにくいエラーメッセージが不可解
６検証と妥当性確認その実像と虚像
bull あるあるだけどその人たちに「わかってないな」と説教してもあまり伝わらない
bull テストすればよいレビューすればよいとタスクのみを認識する人を改宗することが難しい
業界には明らかに混乱や誤った情報がある当社には医療機器メーカが新しく開発した機器の仕上げ段階でその「妥当性確認」をーできれば1週間以内で－お願いしたいという契約の電話を毎週のように受けている
検証と妥当性確認の内容に関してよくある誤解からはじめよう図６１にそういう根拠のない社会通念をいくつか挙げる最初にもっともよくある誤解は製品に欠陥がないと保証するために製品開発プロセス最後で行う大量のテストを妥当性確認とするものであるこれは２つの理由で誤っているこれから見ていくように妥当性確認はソフトウェアの設計段階で欠陥を入りこませないことと入り込んでしまった欠陥を検出修正すること両方を等しく重視する
６検証と妥当性確認その実像と虚像
妥当性確認
検証
テスト
図６２ 「妥当性確認」対「検証」対「テスト」
bull これで明日からうまく説明できそうです
図６３ ソフトウェア妥当性確認の傘
妥当性確認におけるアクティビティをわかりやすく列挙されています詳しくは原著をお買い求めください
8 2 リスク管理
bull 自分の勘違いがまさに記述されていたリスク管理していればいいのではという勝手な思い込み妥当性確認アクティビティの一部なんだよな
リスク管理は妥当性確認アクティビティとみなされるリスクを特定し重大なリスクに対する制御を設計しそうした制御の有効性を検証する体系的なリスク管理プロセスはソフトウェアやシステムの信用を強化する妥当性確認の目標はソフトウェアの信用を構築することだからリスク管理が妥当性確認アクティビティあるように見えるのだ
812 リスク管理アクティビティ
bull ここでは紙面を割いてハザード分析および確率をどのようにするかが長文で記述されているソフトウェア不具合を起こしやすくする要因の列挙があり参考になった
814 リスク制御
bull ここでは具体例とともにどのようにリスクを軽減または受容するかが記述されている１例としてオッカムのかみそりの適用
bull 実際に自分の開発の中で実践している考え方と近くある意味自信を持てたがそれをどのように教育していくべきかという点で問題がありそうだと感じた なお完全なリスク像を十分に理解できたという確信は私もほしい
今度はその受容不可リスクに対する制御を設計する（または既存のものを特定する）番だ
他人によって自分の病気の母親がそのリスクにさらされたくない（すなわちもっとも単純な直感的評価であるが）なら全体的リスクは受容不可である－このことは他の定量的または定性的分析が結論付ける内容とは関係ない
リスク管理は反復的だからライフサイクル全体で行う必要があるリスク管理プロセスの方法とツールを多くしようすることが名案であることは確かだしかしいろいろな方法で生成された情報をどうまとめ有意義な全体的残存リスク査定を可能にするレビューに備えるかを考えなければならないやはり（中略）情報を1箇所に集めない限り完全なリスク像を十分に理解できたという確信を与えない
13 テストフェーズアクティビティ
bull ISTQBのFoundation Level程度に具体例とともに書かれていてすばらしい
bull テストチームと開発チームとの連携の例はシンプルかつ理解しやすい
135テストの心理学
テスト中のよくない態度を醸成するものとしてテストチームからのソフトウェアに対する一方的批判があるその埋め合わせには開発者をテスト設計のレビュアとして使用することが考えられるこれで少なくとも以下の3つが実現する
1開発者はテスト設計テスタはソフトウェアを批評するように批判の流れのバランスをとる（中略）
2開発者によるテスト設計のレビューはテスト範囲を著しく向上させる (中略）
3テスト設計のレビューはソフトウェア設計に関してと開発者がソフトウェアを機能させるために何が必要だったかの理解を向
上させる結果につながることが多い（中略）こういう情報を活用するテスタはソフトウェアで障害を起こしそうな部分に作業を集中させるそれは本書で述べてきたリスクベースの妥当性確認とテストを構成する要素の1つである
19 妥当性確認をサポートする非機器テストアクティビティ
bull 普段自分が使っているIDEやコンパイラに対するテストするしないを明確に切り分けなかった自分に気がつくことができました
bull ただしFDA規制ガイダンスは規制として有効なのか疑わしいのかとも思いました意識づけるだけなのかあまり理解しきれていません
191テストする理由しない理由
ソフトウェアテストに関する章のはじめ方としては妙かもしれないが多くの場合大量の非機器ソフトウェアテストは妥当性確認投資に効果をあげる最良の方法でない可能性がある
197要約
保守的な妥当性確認計画者はテストの計画を立てて規制問題を満たさなければならないが会社が労力に対して得る利益を最大にするため十分に計画を練ったリスクベーステストは大量である必要がないそれでも機器メーカにとって重要な欠陥の発見で生産的にすることができ安全性または規制に関する障害の発見で有効なこともある
最後に
bull 引用している情報は本全体のごくごくわずかでしかありません
bull 規制がどれだけ重量級かという説明ではなくなにのための規制なのかそしてそれをやるときにどのような困難があってどうメリットがあるかという説明になっています
bull 要件やトレーサビリティといった欠陥混入時に多大な影響をあたえるアクティビティへの対応や保守での考え方などぜひ読むべきです
bull 本書は開発ライフサイクルにも言及されていますアジャイルな人たちにもお勧めです
bull まだまだ自分自身理解しきれていないためもう一度全部読み返します
どんな本目次の引用
第一部背景
1 医療機器ソフトウェア妥当性確認の進化と本書の必要性
2 規制の背景
3 FDAによるソフトウェア妥当性確認規制とソフトウェアの妥当性確認が必要な理由
4 ソフトウェア妥当性確認のための組織的考慮
5 ソフトウェア（開発）ライフサイクル
6 確認と妥当性確認その実像と虚像
7 ソフトウェア妥当性確認に対するライフサイクルのアプローチ
8 ライフサイクル全体に及ぶアクティビティのサポートリスク管理
9 その他の支援活動計画レビュー構成管理欠陥管理
どんな本目次の引用
第2部医療機器ソフトウェアの妥当性確認
10 概念フェーズアクティビティ
11 ソフトウェア要件フェーズアクティビティ
12 設計および実装フェーズアクティビティ
13 テストフェーズアクティビティ
14 保守フェーズ妥当性確認アクティビティ
第3部非機器ソフトウェアの妥当性確認
15 自動化プロセスソフトウェアの妥当性確認背景
16 非機器ソフトウェアの妥当性確認を計画する
17 意図した使用と意図した使用を実現する要件
18 非機器ソフトウェアのリスク管理と構成管理ライフサイクル全体に及ぶアクティビティ
19 妥当性確認をサポートする非機器テストアクティビティ
20 非機器ソフトウェアの保守および廃棄
非医療機器のこと
読書感想のまとめ
bull 全章にわたって非常にすばらしい 一部をピックアップします
bull 3章 FDAが妥当性確認要求するときの状況としてのTherac25の惨事と原因サマリーとソフトウェアエンジニアリングの実践の関係
bull 6章 そもそも検証と妥当性確認とテストの関係とは
bull 8章リスク分類や発生確率を埋める時点で難しい残存リスクの受容をどう考えれば
bull 13章テストの心理学
bull 19章 テストする理由としない理由
bull ちなみに原著のほうが英語かつ若干高いので和書のほうがお勧めです
第3章 FDAによるソフトウェア妥当性確認規制と必要な理由
bull Therac25事件httpenwikipediaorgwikiTherac-25
bull この事故までFDAは対処した経験がほとんどなかったとのこと
bull Nancy Levesonによる要因報告を以下引用します
bull 要因は全体的に身につまされますソフトウェアに対する過信
ソフトウェアは機器のハザード分析で考慮されずハードウェアの不具合が第一に考慮されソフトウェア障害が発生した場合の適切なバックアップメカニズムがないまま安全機能の多くがソフトウェアに実装された
信頼性と安全性の混同
防衛的設計の欠如
無頓着
非現実的なリスク査定
事故報告に対する不適切な調査やフォローアップ
ソフトウェアの再利用
安全なユーザインターフェース対使いやすいユーザインターフェース
第3章 FDAによるソフトウェア妥当性確認規制と必要な理由
根本的原因除去の失敗
「ソフトウェア障害モード中にキーボードでPを押すと（中略）放射線照射が起こる可能性があったそういう「Proceed」が5回あるとシステムがシャットダウンされるこれに対するメーカの対応は「Proceed」の回数を減らすというものでシャットダウンが5回ではなく3回で始まるようになった結果幹部を攻撃する過剰照射の量は抑えられたが不具合の根本的原因はそのままだった
このエラー状態につながる一連のイベントには画面でデータを編集するためカーソルをポイントする際のオペレータによる上向き矢印の使用がふくまれていたメーカであるAtomic Energy Of Canada Limited(AECL)社の対応はTheracシステムのユー
ザに書簡を送り「キーを取り外しスイッチの接点を電気テープや他の絶縁物質で開放位置に固定すること」を要請することだった
bull 暫定対策やパッチワークを恒常化することの危険性
bull 対応を進める本人たちは迅速に顧客のための活動をしようとしているのですが
第3章 FDAによるソフトウェア妥当性確認規制と必要な理由
bull 不適切なソフトウェアエンジニアリングが要因としてあげられている
今日の先進テクノロジとテクニックへさらに25年の経験をもってしてもその要因リストで業界が完全に除去できたいうことができるものは事実上皆無なのである
不適切なソフトウェアエンジニアリングの実践
bull ソフトウェア要件と設計の文書化が後づけでなされた
bull ソフトウェアの設計と開発を制御する品質システムが整備されていなかった
bull ソフトウェア設計が過度に複雑だったと思われる
bull システムレベルのソフトウェアテストしか実行されなかったユニットレベルや統合レベルのテストとは明らかでないすべてのソフトウェア変更に関する回帰テストの計画が全然ない
bull ソフトウェアのユーザインターフェースがユーザにわかりにくいエラーメッセージが不可解
６検証と妥当性確認その実像と虚像
bull あるあるだけどその人たちに「わかってないな」と説教してもあまり伝わらない
bull テストすればよいレビューすればよいとタスクのみを認識する人を改宗することが難しい
業界には明らかに混乱や誤った情報がある当社には医療機器メーカが新しく開発した機器の仕上げ段階でその「妥当性確認」をーできれば1週間以内で－お願いしたいという契約の電話を毎週のように受けている
検証と妥当性確認の内容に関してよくある誤解からはじめよう図６１にそういう根拠のない社会通念をいくつか挙げる最初にもっともよくある誤解は製品に欠陥がないと保証するために製品開発プロセス最後で行う大量のテストを妥当性確認とするものであるこれは２つの理由で誤っているこれから見ていくように妥当性確認はソフトウェアの設計段階で欠陥を入りこませないことと入り込んでしまった欠陥を検出修正すること両方を等しく重視する
６検証と妥当性確認その実像と虚像
妥当性確認
検証
テスト
図６２ 「妥当性確認」対「検証」対「テスト」
bull これで明日からうまく説明できそうです
図６３ ソフトウェア妥当性確認の傘
妥当性確認におけるアクティビティをわかりやすく列挙されています詳しくは原著をお買い求めください
8 2 リスク管理
bull 自分の勘違いがまさに記述されていたリスク管理していればいいのではという勝手な思い込み妥当性確認アクティビティの一部なんだよな
リスク管理は妥当性確認アクティビティとみなされるリスクを特定し重大なリスクに対する制御を設計しそうした制御の有効性を検証する体系的なリスク管理プロセスはソフトウェアやシステムの信用を強化する妥当性確認の目標はソフトウェアの信用を構築することだからリスク管理が妥当性確認アクティビティあるように見えるのだ
812 リスク管理アクティビティ
bull ここでは紙面を割いてハザード分析および確率をどのようにするかが長文で記述されているソフトウェア不具合を起こしやすくする要因の列挙があり参考になった
814 リスク制御
bull ここでは具体例とともにどのようにリスクを軽減または受容するかが記述されている１例としてオッカムのかみそりの適用
bull 実際に自分の開発の中で実践している考え方と近くある意味自信を持てたがそれをどのように教育していくべきかという点で問題がありそうだと感じた なお完全なリスク像を十分に理解できたという確信は私もほしい
今度はその受容不可リスクに対する制御を設計する（または既存のものを特定する）番だ
他人によって自分の病気の母親がそのリスクにさらされたくない（すなわちもっとも単純な直感的評価であるが）なら全体的リスクは受容不可である－このことは他の定量的または定性的分析が結論付ける内容とは関係ない
リスク管理は反復的だからライフサイクル全体で行う必要があるリスク管理プロセスの方法とツールを多くしようすることが名案であることは確かだしかしいろいろな方法で生成された情報をどうまとめ有意義な全体的残存リスク査定を可能にするレビューに備えるかを考えなければならないやはり（中略）情報を1箇所に集めない限り完全なリスク像を十分に理解できたという確信を与えない
13 テストフェーズアクティビティ
bull ISTQBのFoundation Level程度に具体例とともに書かれていてすばらしい
bull テストチームと開発チームとの連携の例はシンプルかつ理解しやすい
135テストの心理学
テスト中のよくない態度を醸成するものとしてテストチームからのソフトウェアに対する一方的批判があるその埋め合わせには開発者をテスト設計のレビュアとして使用することが考えられるこれで少なくとも以下の3つが実現する
1開発者はテスト設計テスタはソフトウェアを批評するように批判の流れのバランスをとる（中略）
2開発者によるテスト設計のレビューはテスト範囲を著しく向上させる (中略）
3テスト設計のレビューはソフトウェア設計に関してと開発者がソフトウェアを機能させるために何が必要だったかの理解を向
上させる結果につながることが多い（中略）こういう情報を活用するテスタはソフトウェアで障害を起こしそうな部分に作業を集中させるそれは本書で述べてきたリスクベースの妥当性確認とテストを構成する要素の1つである
19 妥当性確認をサポートする非機器テストアクティビティ
bull 普段自分が使っているIDEやコンパイラに対するテストするしないを明確に切り分けなかった自分に気がつくことができました
bull ただしFDA規制ガイダンスは規制として有効なのか疑わしいのかとも思いました意識づけるだけなのかあまり理解しきれていません
191テストする理由しない理由
ソフトウェアテストに関する章のはじめ方としては妙かもしれないが多くの場合大量の非機器ソフトウェアテストは妥当性確認投資に効果をあげる最良の方法でない可能性がある
197要約
保守的な妥当性確認計画者はテストの計画を立てて規制問題を満たさなければならないが会社が労力に対して得る利益を最大にするため十分に計画を練ったリスクベーステストは大量である必要がないそれでも機器メーカにとって重要な欠陥の発見で生産的にすることができ安全性または規制に関する障害の発見で有効なこともある
最後に
bull 引用している情報は本全体のごくごくわずかでしかありません
bull 規制がどれだけ重量級かという説明ではなくなにのための規制なのかそしてそれをやるときにどのような困難があってどうメリットがあるかという説明になっています
bull 要件やトレーサビリティといった欠陥混入時に多大な影響をあたえるアクティビティへの対応や保守での考え方などぜひ読むべきです
bull 本書は開発ライフサイクルにも言及されていますアジャイルな人たちにもお勧めです
bull まだまだ自分自身理解しきれていないためもう一度全部読み返します
どんな本目次の引用
第2部医療機器ソフトウェアの妥当性確認
10 概念フェーズアクティビティ
11 ソフトウェア要件フェーズアクティビティ
12 設計および実装フェーズアクティビティ
13 テストフェーズアクティビティ
14 保守フェーズ妥当性確認アクティビティ
第3部非機器ソフトウェアの妥当性確認
15 自動化プロセスソフトウェアの妥当性確認背景
16 非機器ソフトウェアの妥当性確認を計画する
17 意図した使用と意図した使用を実現する要件
18 非機器ソフトウェアのリスク管理と構成管理ライフサイクル全体に及ぶアクティビティ
19 妥当性確認をサポートする非機器テストアクティビティ
20 非機器ソフトウェアの保守および廃棄
非医療機器のこと
読書感想のまとめ
bull 全章にわたって非常にすばらしい 一部をピックアップします
bull 3章 FDAが妥当性確認要求するときの状況としてのTherac25の惨事と原因サマリーとソフトウェアエンジニアリングの実践の関係
bull 6章 そもそも検証と妥当性確認とテストの関係とは
bull 8章リスク分類や発生確率を埋める時点で難しい残存リスクの受容をどう考えれば
bull 13章テストの心理学
bull 19章 テストする理由としない理由
bull ちなみに原著のほうが英語かつ若干高いので和書のほうがお勧めです
第3章 FDAによるソフトウェア妥当性確認規制と必要な理由
bull Therac25事件httpenwikipediaorgwikiTherac-25
bull この事故までFDAは対処した経験がほとんどなかったとのこと
bull Nancy Levesonによる要因報告を以下引用します
bull 要因は全体的に身につまされますソフトウェアに対する過信
ソフトウェアは機器のハザード分析で考慮されずハードウェアの不具合が第一に考慮されソフトウェア障害が発生した場合の適切なバックアップメカニズムがないまま安全機能の多くがソフトウェアに実装された
信頼性と安全性の混同
防衛的設計の欠如
無頓着
非現実的なリスク査定
事故報告に対する不適切な調査やフォローアップ
ソフトウェアの再利用
安全なユーザインターフェース対使いやすいユーザインターフェース
第3章 FDAによるソフトウェア妥当性確認規制と必要な理由
根本的原因除去の失敗
「ソフトウェア障害モード中にキーボードでPを押すと（中略）放射線照射が起こる可能性があったそういう「Proceed」が5回あるとシステムがシャットダウンされるこれに対するメーカの対応は「Proceed」の回数を減らすというものでシャットダウンが5回ではなく3回で始まるようになった結果幹部を攻撃する過剰照射の量は抑えられたが不具合の根本的原因はそのままだった
このエラー状態につながる一連のイベントには画面でデータを編集するためカーソルをポイントする際のオペレータによる上向き矢印の使用がふくまれていたメーカであるAtomic Energy Of Canada Limited(AECL)社の対応はTheracシステムのユー
ザに書簡を送り「キーを取り外しスイッチの接点を電気テープや他の絶縁物質で開放位置に固定すること」を要請することだった
bull 暫定対策やパッチワークを恒常化することの危険性
bull 対応を進める本人たちは迅速に顧客のための活動をしようとしているのですが
第3章 FDAによるソフトウェア妥当性確認規制と必要な理由
bull 不適切なソフトウェアエンジニアリングが要因としてあげられている
今日の先進テクノロジとテクニックへさらに25年の経験をもってしてもその要因リストで業界が完全に除去できたいうことができるものは事実上皆無なのである
不適切なソフトウェアエンジニアリングの実践
bull ソフトウェア要件と設計の文書化が後づけでなされた
bull ソフトウェアの設計と開発を制御する品質システムが整備されていなかった
bull ソフトウェア設計が過度に複雑だったと思われる
bull システムレベルのソフトウェアテストしか実行されなかったユニットレベルや統合レベルのテストとは明らかでないすべてのソフトウェア変更に関する回帰テストの計画が全然ない
bull ソフトウェアのユーザインターフェースがユーザにわかりにくいエラーメッセージが不可解
６検証と妥当性確認その実像と虚像
bull あるあるだけどその人たちに「わかってないな」と説教してもあまり伝わらない
bull テストすればよいレビューすればよいとタスクのみを認識する人を改宗することが難しい
業界には明らかに混乱や誤った情報がある当社には医療機器メーカが新しく開発した機器の仕上げ段階でその「妥当性確認」をーできれば1週間以内で－お願いしたいという契約の電話を毎週のように受けている
検証と妥当性確認の内容に関してよくある誤解からはじめよう図６１にそういう根拠のない社会通念をいくつか挙げる最初にもっともよくある誤解は製品に欠陥がないと保証するために製品開発プロセス最後で行う大量のテストを妥当性確認とするものであるこれは２つの理由で誤っているこれから見ていくように妥当性確認はソフトウェアの設計段階で欠陥を入りこませないことと入り込んでしまった欠陥を検出修正すること両方を等しく重視する
６検証と妥当性確認その実像と虚像
妥当性確認
検証
テスト
図６２ 「妥当性確認」対「検証」対「テスト」
bull これで明日からうまく説明できそうです
図６３ ソフトウェア妥当性確認の傘
妥当性確認におけるアクティビティをわかりやすく列挙されています詳しくは原著をお買い求めください
8 2 リスク管理
bull 自分の勘違いがまさに記述されていたリスク管理していればいいのではという勝手な思い込み妥当性確認アクティビティの一部なんだよな
リスク管理は妥当性確認アクティビティとみなされるリスクを特定し重大なリスクに対する制御を設計しそうした制御の有効性を検証する体系的なリスク管理プロセスはソフトウェアやシステムの信用を強化する妥当性確認の目標はソフトウェアの信用を構築することだからリスク管理が妥当性確認アクティビティあるように見えるのだ
812 リスク管理アクティビティ
bull ここでは紙面を割いてハザード分析および確率をどのようにするかが長文で記述されているソフトウェア不具合を起こしやすくする要因の列挙があり参考になった
814 リスク制御
bull ここでは具体例とともにどのようにリスクを軽減または受容するかが記述されている１例としてオッカムのかみそりの適用
bull 実際に自分の開発の中で実践している考え方と近くある意味自信を持てたがそれをどのように教育していくべきかという点で問題がありそうだと感じた なお完全なリスク像を十分に理解できたという確信は私もほしい
今度はその受容不可リスクに対する制御を設計する（または既存のものを特定する）番だ
他人によって自分の病気の母親がそのリスクにさらされたくない（すなわちもっとも単純な直感的評価であるが）なら全体的リスクは受容不可である－このことは他の定量的または定性的分析が結論付ける内容とは関係ない
リスク管理は反復的だからライフサイクル全体で行う必要があるリスク管理プロセスの方法とツールを多くしようすることが名案であることは確かだしかしいろいろな方法で生成された情報をどうまとめ有意義な全体的残存リスク査定を可能にするレビューに備えるかを考えなければならないやはり（中略）情報を1箇所に集めない限り完全なリスク像を十分に理解できたという確信を与えない
13 テストフェーズアクティビティ
bull ISTQBのFoundation Level程度に具体例とともに書かれていてすばらしい
bull テストチームと開発チームとの連携の例はシンプルかつ理解しやすい
135テストの心理学
テスト中のよくない態度を醸成するものとしてテストチームからのソフトウェアに対する一方的批判があるその埋め合わせには開発者をテスト設計のレビュアとして使用することが考えられるこれで少なくとも以下の3つが実現する
1開発者はテスト設計テスタはソフトウェアを批評するように批判の流れのバランスをとる（中略）
2開発者によるテスト設計のレビューはテスト範囲を著しく向上させる (中略）
3テスト設計のレビューはソフトウェア設計に関してと開発者がソフトウェアを機能させるために何が必要だったかの理解を向
上させる結果につながることが多い（中略）こういう情報を活用するテスタはソフトウェアで障害を起こしそうな部分に作業を集中させるそれは本書で述べてきたリスクベースの妥当性確認とテストを構成する要素の1つである
19 妥当性確認をサポートする非機器テストアクティビティ
bull 普段自分が使っているIDEやコンパイラに対するテストするしないを明確に切り分けなかった自分に気がつくことができました
bull ただしFDA規制ガイダンスは規制として有効なのか疑わしいのかとも思いました意識づけるだけなのかあまり理解しきれていません
191テストする理由しない理由
ソフトウェアテストに関する章のはじめ方としては妙かもしれないが多くの場合大量の非機器ソフトウェアテストは妥当性確認投資に効果をあげる最良の方法でない可能性がある
197要約
保守的な妥当性確認計画者はテストの計画を立てて規制問題を満たさなければならないが会社が労力に対して得る利益を最大にするため十分に計画を練ったリスクベーステストは大量である必要がないそれでも機器メーカにとって重要な欠陥の発見で生産的にすることができ安全性または規制に関する障害の発見で有効なこともある
最後に
bull 引用している情報は本全体のごくごくわずかでしかありません
bull 規制がどれだけ重量級かという説明ではなくなにのための規制なのかそしてそれをやるときにどのような困難があってどうメリットがあるかという説明になっています
bull 要件やトレーサビリティといった欠陥混入時に多大な影響をあたえるアクティビティへの対応や保守での考え方などぜひ読むべきです
bull 本書は開発ライフサイクルにも言及されていますアジャイルな人たちにもお勧めです
bull まだまだ自分自身理解しきれていないためもう一度全部読み返します
読書感想のまとめ
bull 全章にわたって非常にすばらしい 一部をピックアップします
bull 3章 FDAが妥当性確認要求するときの状況としてのTherac25の惨事と原因サマリーとソフトウェアエンジニアリングの実践の関係
bull 6章 そもそも検証と妥当性確認とテストの関係とは
bull 8章リスク分類や発生確率を埋める時点で難しい残存リスクの受容をどう考えれば
bull 13章テストの心理学
bull 19章 テストする理由としない理由
bull ちなみに原著のほうが英語かつ若干高いので和書のほうがお勧めです
第3章 FDAによるソフトウェア妥当性確認規制と必要な理由
bull Therac25事件httpenwikipediaorgwikiTherac-25
bull この事故までFDAは対処した経験がほとんどなかったとのこと
bull Nancy Levesonによる要因報告を以下引用します
bull 要因は全体的に身につまされますソフトウェアに対する過信
ソフトウェアは機器のハザード分析で考慮されずハードウェアの不具合が第一に考慮されソフトウェア障害が発生した場合の適切なバックアップメカニズムがないまま安全機能の多くがソフトウェアに実装された
信頼性と安全性の混同
防衛的設計の欠如
無頓着
非現実的なリスク査定
事故報告に対する不適切な調査やフォローアップ
ソフトウェアの再利用
安全なユーザインターフェース対使いやすいユーザインターフェース
第3章 FDAによるソフトウェア妥当性確認規制と必要な理由
根本的原因除去の失敗
「ソフトウェア障害モード中にキーボードでPを押すと（中略）放射線照射が起こる可能性があったそういう「Proceed」が5回あるとシステムがシャットダウンされるこれに対するメーカの対応は「Proceed」の回数を減らすというものでシャットダウンが5回ではなく3回で始まるようになった結果幹部を攻撃する過剰照射の量は抑えられたが不具合の根本的原因はそのままだった
このエラー状態につながる一連のイベントには画面でデータを編集するためカーソルをポイントする際のオペレータによる上向き矢印の使用がふくまれていたメーカであるAtomic Energy Of Canada Limited(AECL)社の対応はTheracシステムのユー
ザに書簡を送り「キーを取り外しスイッチの接点を電気テープや他の絶縁物質で開放位置に固定すること」を要請することだった
bull 暫定対策やパッチワークを恒常化することの危険性
bull 対応を進める本人たちは迅速に顧客のための活動をしようとしているのですが
第3章 FDAによるソフトウェア妥当性確認規制と必要な理由
bull 不適切なソフトウェアエンジニアリングが要因としてあげられている
今日の先進テクノロジとテクニックへさらに25年の経験をもってしてもその要因リストで業界が完全に除去できたいうことができるものは事実上皆無なのである
不適切なソフトウェアエンジニアリングの実践
bull ソフトウェア要件と設計の文書化が後づけでなされた
bull ソフトウェアの設計と開発を制御する品質システムが整備されていなかった
bull ソフトウェア設計が過度に複雑だったと思われる
bull システムレベルのソフトウェアテストしか実行されなかったユニットレベルや統合レベルのテストとは明らかでないすべてのソフトウェア変更に関する回帰テストの計画が全然ない
bull ソフトウェアのユーザインターフェースがユーザにわかりにくいエラーメッセージが不可解
６検証と妥当性確認その実像と虚像
bull あるあるだけどその人たちに「わかってないな」と説教してもあまり伝わらない
bull テストすればよいレビューすればよいとタスクのみを認識する人を改宗することが難しい
業界には明らかに混乱や誤った情報がある当社には医療機器メーカが新しく開発した機器の仕上げ段階でその「妥当性確認」をーできれば1週間以内で－お願いしたいという契約の電話を毎週のように受けている
検証と妥当性確認の内容に関してよくある誤解からはじめよう図６１にそういう根拠のない社会通念をいくつか挙げる最初にもっともよくある誤解は製品に欠陥がないと保証するために製品開発プロセス最後で行う大量のテストを妥当性確認とするものであるこれは２つの理由で誤っているこれから見ていくように妥当性確認はソフトウェアの設計段階で欠陥を入りこませないことと入り込んでしまった欠陥を検出修正すること両方を等しく重視する
６検証と妥当性確認その実像と虚像
妥当性確認
検証
テスト
図６２ 「妥当性確認」対「検証」対「テスト」
bull これで明日からうまく説明できそうです
図６３ ソフトウェア妥当性確認の傘
妥当性確認におけるアクティビティをわかりやすく列挙されています詳しくは原著をお買い求めください
8 2 リスク管理
bull 自分の勘違いがまさに記述されていたリスク管理していればいいのではという勝手な思い込み妥当性確認アクティビティの一部なんだよな
リスク管理は妥当性確認アクティビティとみなされるリスクを特定し重大なリスクに対する制御を設計しそうした制御の有効性を検証する体系的なリスク管理プロセスはソフトウェアやシステムの信用を強化する妥当性確認の目標はソフトウェアの信用を構築することだからリスク管理が妥当性確認アクティビティあるように見えるのだ
812 リスク管理アクティビティ
bull ここでは紙面を割いてハザード分析および確率をどのようにするかが長文で記述されているソフトウェア不具合を起こしやすくする要因の列挙があり参考になった
814 リスク制御
bull ここでは具体例とともにどのようにリスクを軽減または受容するかが記述されている１例としてオッカムのかみそりの適用
bull 実際に自分の開発の中で実践している考え方と近くある意味自信を持てたがそれをどのように教育していくべきかという点で問題がありそうだと感じた なお完全なリスク像を十分に理解できたという確信は私もほしい
今度はその受容不可リスクに対する制御を設計する（または既存のものを特定する）番だ
他人によって自分の病気の母親がそのリスクにさらされたくない（すなわちもっとも単純な直感的評価であるが）なら全体的リスクは受容不可である－このことは他の定量的または定性的分析が結論付ける内容とは関係ない
リスク管理は反復的だからライフサイクル全体で行う必要があるリスク管理プロセスの方法とツールを多くしようすることが名案であることは確かだしかしいろいろな方法で生成された情報をどうまとめ有意義な全体的残存リスク査定を可能にするレビューに備えるかを考えなければならないやはり（中略）情報を1箇所に集めない限り完全なリスク像を十分に理解できたという確信を与えない
13 テストフェーズアクティビティ
bull ISTQBのFoundation Level程度に具体例とともに書かれていてすばらしい
bull テストチームと開発チームとの連携の例はシンプルかつ理解しやすい
135テストの心理学
テスト中のよくない態度を醸成するものとしてテストチームからのソフトウェアに対する一方的批判があるその埋め合わせには開発者をテスト設計のレビュアとして使用することが考えられるこれで少なくとも以下の3つが実現する
1開発者はテスト設計テスタはソフトウェアを批評するように批判の流れのバランスをとる（中略）
2開発者によるテスト設計のレビューはテスト範囲を著しく向上させる (中略）
3テスト設計のレビューはソフトウェア設計に関してと開発者がソフトウェアを機能させるために何が必要だったかの理解を向
上させる結果につながることが多い（中略）こういう情報を活用するテスタはソフトウェアで障害を起こしそうな部分に作業を集中させるそれは本書で述べてきたリスクベースの妥当性確認とテストを構成する要素の1つである
19 妥当性確認をサポートする非機器テストアクティビティ
bull 普段自分が使っているIDEやコンパイラに対するテストするしないを明確に切り分けなかった自分に気がつくことができました
bull ただしFDA規制ガイダンスは規制として有効なのか疑わしいのかとも思いました意識づけるだけなのかあまり理解しきれていません
191テストする理由しない理由
ソフトウェアテストに関する章のはじめ方としては妙かもしれないが多くの場合大量の非機器ソフトウェアテストは妥当性確認投資に効果をあげる最良の方法でない可能性がある
197要約
保守的な妥当性確認計画者はテストの計画を立てて規制問題を満たさなければならないが会社が労力に対して得る利益を最大にするため十分に計画を練ったリスクベーステストは大量である必要がないそれでも機器メーカにとって重要な欠陥の発見で生産的にすることができ安全性または規制に関する障害の発見で有効なこともある
最後に
bull 引用している情報は本全体のごくごくわずかでしかありません
bull 規制がどれだけ重量級かという説明ではなくなにのための規制なのかそしてそれをやるときにどのような困難があってどうメリットがあるかという説明になっています
bull 要件やトレーサビリティといった欠陥混入時に多大な影響をあたえるアクティビティへの対応や保守での考え方などぜひ読むべきです
bull 本書は開発ライフサイクルにも言及されていますアジャイルな人たちにもお勧めです
bull まだまだ自分自身理解しきれていないためもう一度全部読み返します
第3章 FDAによるソフトウェア妥当性確認規制と必要な理由
bull Therac25事件httpenwikipediaorgwikiTherac-25
bull この事故までFDAは対処した経験がほとんどなかったとのこと
bull Nancy Levesonによる要因報告を以下引用します
bull 要因は全体的に身につまされますソフトウェアに対する過信
ソフトウェアは機器のハザード分析で考慮されずハードウェアの不具合が第一に考慮されソフトウェア障害が発生した場合の適切なバックアップメカニズムがないまま安全機能の多くがソフトウェアに実装された
信頼性と安全性の混同
防衛的設計の欠如
無頓着
非現実的なリスク査定
事故報告に対する不適切な調査やフォローアップ
ソフトウェアの再利用
安全なユーザインターフェース対使いやすいユーザインターフェース
第3章 FDAによるソフトウェア妥当性確認規制と必要な理由
根本的原因除去の失敗
「ソフトウェア障害モード中にキーボードでPを押すと（中略）放射線照射が起こる可能性があったそういう「Proceed」が5回あるとシステムがシャットダウンされるこれに対するメーカの対応は「Proceed」の回数を減らすというものでシャットダウンが5回ではなく3回で始まるようになった結果幹部を攻撃する過剰照射の量は抑えられたが不具合の根本的原因はそのままだった
このエラー状態につながる一連のイベントには画面でデータを編集するためカーソルをポイントする際のオペレータによる上向き矢印の使用がふくまれていたメーカであるAtomic Energy Of Canada Limited(AECL)社の対応はTheracシステムのユー
ザに書簡を送り「キーを取り外しスイッチの接点を電気テープや他の絶縁物質で開放位置に固定すること」を要請することだった
bull 暫定対策やパッチワークを恒常化することの危険性
bull 対応を進める本人たちは迅速に顧客のための活動をしようとしているのですが
第3章 FDAによるソフトウェア妥当性確認規制と必要な理由
bull 不適切なソフトウェアエンジニアリングが要因としてあげられている
今日の先進テクノロジとテクニックへさらに25年の経験をもってしてもその要因リストで業界が完全に除去できたいうことができるものは事実上皆無なのである
不適切なソフトウェアエンジニアリングの実践
bull ソフトウェア要件と設計の文書化が後づけでなされた
bull ソフトウェアの設計と開発を制御する品質システムが整備されていなかった
bull ソフトウェア設計が過度に複雑だったと思われる
bull システムレベルのソフトウェアテストしか実行されなかったユニットレベルや統合レベルのテストとは明らかでないすべてのソフトウェア変更に関する回帰テストの計画が全然ない
bull ソフトウェアのユーザインターフェースがユーザにわかりにくいエラーメッセージが不可解
６検証と妥当性確認その実像と虚像
bull あるあるだけどその人たちに「わかってないな」と説教してもあまり伝わらない
bull テストすればよいレビューすればよいとタスクのみを認識する人を改宗することが難しい
業界には明らかに混乱や誤った情報がある当社には医療機器メーカが新しく開発した機器の仕上げ段階でその「妥当性確認」をーできれば1週間以内で－お願いしたいという契約の電話を毎週のように受けている
検証と妥当性確認の内容に関してよくある誤解からはじめよう図６１にそういう根拠のない社会通念をいくつか挙げる最初にもっともよくある誤解は製品に欠陥がないと保証するために製品開発プロセス最後で行う大量のテストを妥当性確認とするものであるこれは２つの理由で誤っているこれから見ていくように妥当性確認はソフトウェアの設計段階で欠陥を入りこませないことと入り込んでしまった欠陥を検出修正すること両方を等しく重視する
６検証と妥当性確認その実像と虚像
妥当性確認
検証
テスト
図６２ 「妥当性確認」対「検証」対「テスト」
bull これで明日からうまく説明できそうです
図６３ ソフトウェア妥当性確認の傘
妥当性確認におけるアクティビティをわかりやすく列挙されています詳しくは原著をお買い求めください
8 2 リスク管理
bull 自分の勘違いがまさに記述されていたリスク管理していればいいのではという勝手な思い込み妥当性確認アクティビティの一部なんだよな
リスク管理は妥当性確認アクティビティとみなされるリスクを特定し重大なリスクに対する制御を設計しそうした制御の有効性を検証する体系的なリスク管理プロセスはソフトウェアやシステムの信用を強化する妥当性確認の目標はソフトウェアの信用を構築することだからリスク管理が妥当性確認アクティビティあるように見えるのだ
812 リスク管理アクティビティ
bull ここでは紙面を割いてハザード分析および確率をどのようにするかが長文で記述されているソフトウェア不具合を起こしやすくする要因の列挙があり参考になった
814 リスク制御
bull ここでは具体例とともにどのようにリスクを軽減または受容するかが記述されている１例としてオッカムのかみそりの適用
bull 実際に自分の開発の中で実践している考え方と近くある意味自信を持てたがそれをどのように教育していくべきかという点で問題がありそうだと感じた なお完全なリスク像を十分に理解できたという確信は私もほしい
今度はその受容不可リスクに対する制御を設計する（または既存のものを特定する）番だ
他人によって自分の病気の母親がそのリスクにさらされたくない（すなわちもっとも単純な直感的評価であるが）なら全体的リスクは受容不可である－このことは他の定量的または定性的分析が結論付ける内容とは関係ない
リスク管理は反復的だからライフサイクル全体で行う必要があるリスク管理プロセスの方法とツールを多くしようすることが名案であることは確かだしかしいろいろな方法で生成された情報をどうまとめ有意義な全体的残存リスク査定を可能にするレビューに備えるかを考えなければならないやはり（中略）情報を1箇所に集めない限り完全なリスク像を十分に理解できたという確信を与えない
13 テストフェーズアクティビティ
bull ISTQBのFoundation Level程度に具体例とともに書かれていてすばらしい
bull テストチームと開発チームとの連携の例はシンプルかつ理解しやすい
135テストの心理学
テスト中のよくない態度を醸成するものとしてテストチームからのソフトウェアに対する一方的批判があるその埋め合わせには開発者をテスト設計のレビュアとして使用することが考えられるこれで少なくとも以下の3つが実現する
1開発者はテスト設計テスタはソフトウェアを批評するように批判の流れのバランスをとる（中略）
2開発者によるテスト設計のレビューはテスト範囲を著しく向上させる (中略）
3テスト設計のレビューはソフトウェア設計に関してと開発者がソフトウェアを機能させるために何が必要だったかの理解を向
上させる結果につながることが多い（中略）こういう情報を活用するテスタはソフトウェアで障害を起こしそうな部分に作業を集中させるそれは本書で述べてきたリスクベースの妥当性確認とテストを構成する要素の1つである
19 妥当性確認をサポートする非機器テストアクティビティ
bull 普段自分が使っているIDEやコンパイラに対するテストするしないを明確に切り分けなかった自分に気がつくことができました
bull ただしFDA規制ガイダンスは規制として有効なのか疑わしいのかとも思いました意識づけるだけなのかあまり理解しきれていません
191テストする理由しない理由
ソフトウェアテストに関する章のはじめ方としては妙かもしれないが多くの場合大量の非機器ソフトウェアテストは妥当性確認投資に効果をあげる最良の方法でない可能性がある
197要約
保守的な妥当性確認計画者はテストの計画を立てて規制問題を満たさなければならないが会社が労力に対して得る利益を最大にするため十分に計画を練ったリスクベーステストは大量である必要がないそれでも機器メーカにとって重要な欠陥の発見で生産的にすることができ安全性または規制に関する障害の発見で有効なこともある
最後に
bull 引用している情報は本全体のごくごくわずかでしかありません
bull 規制がどれだけ重量級かという説明ではなくなにのための規制なのかそしてそれをやるときにどのような困難があってどうメリットがあるかという説明になっています
bull 要件やトレーサビリティといった欠陥混入時に多大な影響をあたえるアクティビティへの対応や保守での考え方などぜひ読むべきです
bull 本書は開発ライフサイクルにも言及されていますアジャイルな人たちにもお勧めです
bull まだまだ自分自身理解しきれていないためもう一度全部読み返します
第3章 FDAによるソフトウェア妥当性確認規制と必要な理由
根本的原因除去の失敗
「ソフトウェア障害モード中にキーボードでPを押すと（中略）放射線照射が起こる可能性があったそういう「Proceed」が5回あるとシステムがシャットダウンされるこれに対するメーカの対応は「Proceed」の回数を減らすというものでシャットダウンが5回ではなく3回で始まるようになった結果幹部を攻撃する過剰照射の量は抑えられたが不具合の根本的原因はそのままだった
このエラー状態につながる一連のイベントには画面でデータを編集するためカーソルをポイントする際のオペレータによる上向き矢印の使用がふくまれていたメーカであるAtomic Energy Of Canada Limited(AECL)社の対応はTheracシステムのユー
ザに書簡を送り「キーを取り外しスイッチの接点を電気テープや他の絶縁物質で開放位置に固定すること」を要請することだった
bull 暫定対策やパッチワークを恒常化することの危険性
bull 対応を進める本人たちは迅速に顧客のための活動をしようとしているのですが
第3章 FDAによるソフトウェア妥当性確認規制と必要な理由
bull 不適切なソフトウェアエンジニアリングが要因としてあげられている
今日の先進テクノロジとテクニックへさらに25年の経験をもってしてもその要因リストで業界が完全に除去できたいうことができるものは事実上皆無なのである
不適切なソフトウェアエンジニアリングの実践
bull ソフトウェア要件と設計の文書化が後づけでなされた
bull ソフトウェアの設計と開発を制御する品質システムが整備されていなかった
bull ソフトウェア設計が過度に複雑だったと思われる
bull システムレベルのソフトウェアテストしか実行されなかったユニットレベルや統合レベルのテストとは明らかでないすべてのソフトウェア変更に関する回帰テストの計画が全然ない
bull ソフトウェアのユーザインターフェースがユーザにわかりにくいエラーメッセージが不可解
６検証と妥当性確認その実像と虚像
bull あるあるだけどその人たちに「わかってないな」と説教してもあまり伝わらない
bull テストすればよいレビューすればよいとタスクのみを認識する人を改宗することが難しい
業界には明らかに混乱や誤った情報がある当社には医療機器メーカが新しく開発した機器の仕上げ段階でその「妥当性確認」をーできれば1週間以内で－お願いしたいという契約の電話を毎週のように受けている
検証と妥当性確認の内容に関してよくある誤解からはじめよう図６１にそういう根拠のない社会通念をいくつか挙げる最初にもっともよくある誤解は製品に欠陥がないと保証するために製品開発プロセス最後で行う大量のテストを妥当性確認とするものであるこれは２つの理由で誤っているこれから見ていくように妥当性確認はソフトウェアの設計段階で欠陥を入りこませないことと入り込んでしまった欠陥を検出修正すること両方を等しく重視する
６検証と妥当性確認その実像と虚像
妥当性確認
検証
テスト
図６２ 「妥当性確認」対「検証」対「テスト」
bull これで明日からうまく説明できそうです
図６３ ソフトウェア妥当性確認の傘
妥当性確認におけるアクティビティをわかりやすく列挙されています詳しくは原著をお買い求めください
8 2 リスク管理
bull 自分の勘違いがまさに記述されていたリスク管理していればいいのではという勝手な思い込み妥当性確認アクティビティの一部なんだよな
リスク管理は妥当性確認アクティビティとみなされるリスクを特定し重大なリスクに対する制御を設計しそうした制御の有効性を検証する体系的なリスク管理プロセスはソフトウェアやシステムの信用を強化する妥当性確認の目標はソフトウェアの信用を構築することだからリスク管理が妥当性確認アクティビティあるように見えるのだ
812 リスク管理アクティビティ
bull ここでは紙面を割いてハザード分析および確率をどのようにするかが長文で記述されているソフトウェア不具合を起こしやすくする要因の列挙があり参考になった
814 リスク制御
bull ここでは具体例とともにどのようにリスクを軽減または受容するかが記述されている１例としてオッカムのかみそりの適用
bull 実際に自分の開発の中で実践している考え方と近くある意味自信を持てたがそれをどのように教育していくべきかという点で問題がありそうだと感じた なお完全なリスク像を十分に理解できたという確信は私もほしい
今度はその受容不可リスクに対する制御を設計する（または既存のものを特定する）番だ
他人によって自分の病気の母親がそのリスクにさらされたくない（すなわちもっとも単純な直感的評価であるが）なら全体的リスクは受容不可である－このことは他の定量的または定性的分析が結論付ける内容とは関係ない
リスク管理は反復的だからライフサイクル全体で行う必要があるリスク管理プロセスの方法とツールを多くしようすることが名案であることは確かだしかしいろいろな方法で生成された情報をどうまとめ有意義な全体的残存リスク査定を可能にするレビューに備えるかを考えなければならないやはり（中略）情報を1箇所に集めない限り完全なリスク像を十分に理解できたという確信を与えない
13 テストフェーズアクティビティ
bull ISTQBのFoundation Level程度に具体例とともに書かれていてすばらしい
bull テストチームと開発チームとの連携の例はシンプルかつ理解しやすい
135テストの心理学
テスト中のよくない態度を醸成するものとしてテストチームからのソフトウェアに対する一方的批判があるその埋め合わせには開発者をテスト設計のレビュアとして使用することが考えられるこれで少なくとも以下の3つが実現する
1開発者はテスト設計テスタはソフトウェアを批評するように批判の流れのバランスをとる（中略）
2開発者によるテスト設計のレビューはテスト範囲を著しく向上させる (中略）
3テスト設計のレビューはソフトウェア設計に関してと開発者がソフトウェアを機能させるために何が必要だったかの理解を向
上させる結果につながることが多い（中略）こういう情報を活用するテスタはソフトウェアで障害を起こしそうな部分に作業を集中させるそれは本書で述べてきたリスクベースの妥当性確認とテストを構成する要素の1つである
19 妥当性確認をサポートする非機器テストアクティビティ
bull 普段自分が使っているIDEやコンパイラに対するテストするしないを明確に切り分けなかった自分に気がつくことができました
bull ただしFDA規制ガイダンスは規制として有効なのか疑わしいのかとも思いました意識づけるだけなのかあまり理解しきれていません
191テストする理由しない理由
ソフトウェアテストに関する章のはじめ方としては妙かもしれないが多くの場合大量の非機器ソフトウェアテストは妥当性確認投資に効果をあげる最良の方法でない可能性がある
197要約
保守的な妥当性確認計画者はテストの計画を立てて規制問題を満たさなければならないが会社が労力に対して得る利益を最大にするため十分に計画を練ったリスクベーステストは大量である必要がないそれでも機器メーカにとって重要な欠陥の発見で生産的にすることができ安全性または規制に関する障害の発見で有効なこともある
最後に
bull 引用している情報は本全体のごくごくわずかでしかありません
bull 規制がどれだけ重量級かという説明ではなくなにのための規制なのかそしてそれをやるときにどのような困難があってどうメリットがあるかという説明になっています
bull 要件やトレーサビリティといった欠陥混入時に多大な影響をあたえるアクティビティへの対応や保守での考え方などぜひ読むべきです
bull 本書は開発ライフサイクルにも言及されていますアジャイルな人たちにもお勧めです
bull まだまだ自分自身理解しきれていないためもう一度全部読み返します
第3章 FDAによるソフトウェア妥当性確認規制と必要な理由
bull 不適切なソフトウェアエンジニアリングが要因としてあげられている
今日の先進テクノロジとテクニックへさらに25年の経験をもってしてもその要因リストで業界が完全に除去できたいうことができるものは事実上皆無なのである
不適切なソフトウェアエンジニアリングの実践
bull ソフトウェア要件と設計の文書化が後づけでなされた
bull ソフトウェアの設計と開発を制御する品質システムが整備されていなかった
bull ソフトウェア設計が過度に複雑だったと思われる
bull システムレベルのソフトウェアテストしか実行されなかったユニットレベルや統合レベルのテストとは明らかでないすべてのソフトウェア変更に関する回帰テストの計画が全然ない
bull ソフトウェアのユーザインターフェースがユーザにわかりにくいエラーメッセージが不可解
６検証と妥当性確認その実像と虚像
bull あるあるだけどその人たちに「わかってないな」と説教してもあまり伝わらない
bull テストすればよいレビューすればよいとタスクのみを認識する人を改宗することが難しい
業界には明らかに混乱や誤った情報がある当社には医療機器メーカが新しく開発した機器の仕上げ段階でその「妥当性確認」をーできれば1週間以内で－お願いしたいという契約の電話を毎週のように受けている
検証と妥当性確認の内容に関してよくある誤解からはじめよう図６１にそういう根拠のない社会通念をいくつか挙げる最初にもっともよくある誤解は製品に欠陥がないと保証するために製品開発プロセス最後で行う大量のテストを妥当性確認とするものであるこれは２つの理由で誤っているこれから見ていくように妥当性確認はソフトウェアの設計段階で欠陥を入りこませないことと入り込んでしまった欠陥を検出修正すること両方を等しく重視する
６検証と妥当性確認その実像と虚像
妥当性確認
検証
テスト
図６２ 「妥当性確認」対「検証」対「テスト」
bull これで明日からうまく説明できそうです
図６３ ソフトウェア妥当性確認の傘
妥当性確認におけるアクティビティをわかりやすく列挙されています詳しくは原著をお買い求めください
8 2 リスク管理
bull 自分の勘違いがまさに記述されていたリスク管理していればいいのではという勝手な思い込み妥当性確認アクティビティの一部なんだよな
リスク管理は妥当性確認アクティビティとみなされるリスクを特定し重大なリスクに対する制御を設計しそうした制御の有効性を検証する体系的なリスク管理プロセスはソフトウェアやシステムの信用を強化する妥当性確認の目標はソフトウェアの信用を構築することだからリスク管理が妥当性確認アクティビティあるように見えるのだ
812 リスク管理アクティビティ
bull ここでは紙面を割いてハザード分析および確率をどのようにするかが長文で記述されているソフトウェア不具合を起こしやすくする要因の列挙があり参考になった
814 リスク制御
bull ここでは具体例とともにどのようにリスクを軽減または受容するかが記述されている１例としてオッカムのかみそりの適用
bull 実際に自分の開発の中で実践している考え方と近くある意味自信を持てたがそれをどのように教育していくべきかという点で問題がありそうだと感じた なお完全なリスク像を十分に理解できたという確信は私もほしい
今度はその受容不可リスクに対する制御を設計する（または既存のものを特定する）番だ
他人によって自分の病気の母親がそのリスクにさらされたくない（すなわちもっとも単純な直感的評価であるが）なら全体的リスクは受容不可である－このことは他の定量的または定性的分析が結論付ける内容とは関係ない
リスク管理は反復的だからライフサイクル全体で行う必要があるリスク管理プロセスの方法とツールを多くしようすることが名案であることは確かだしかしいろいろな方法で生成された情報をどうまとめ有意義な全体的残存リスク査定を可能にするレビューに備えるかを考えなければならないやはり（中略）情報を1箇所に集めない限り完全なリスク像を十分に理解できたという確信を与えない
13 テストフェーズアクティビティ
bull ISTQBのFoundation Level程度に具体例とともに書かれていてすばらしい
bull テストチームと開発チームとの連携の例はシンプルかつ理解しやすい
135テストの心理学
テスト中のよくない態度を醸成するものとしてテストチームからのソフトウェアに対する一方的批判があるその埋め合わせには開発者をテスト設計のレビュアとして使用することが考えられるこれで少なくとも以下の3つが実現する
1開発者はテスト設計テスタはソフトウェアを批評するように批判の流れのバランスをとる（中略）
2開発者によるテスト設計のレビューはテスト範囲を著しく向上させる (中略）
3テスト設計のレビューはソフトウェア設計に関してと開発者がソフトウェアを機能させるために何が必要だったかの理解を向
上させる結果につながることが多い（中略）こういう情報を活用するテスタはソフトウェアで障害を起こしそうな部分に作業を集中させるそれは本書で述べてきたリスクベースの妥当性確認とテストを構成する要素の1つである
19 妥当性確認をサポートする非機器テストアクティビティ
bull 普段自分が使っているIDEやコンパイラに対するテストするしないを明確に切り分けなかった自分に気がつくことができました
bull ただしFDA規制ガイダンスは規制として有効なのか疑わしいのかとも思いました意識づけるだけなのかあまり理解しきれていません
191テストする理由しない理由
ソフトウェアテストに関する章のはじめ方としては妙かもしれないが多くの場合大量の非機器ソフトウェアテストは妥当性確認投資に効果をあげる最良の方法でない可能性がある
197要約
保守的な妥当性確認計画者はテストの計画を立てて規制問題を満たさなければならないが会社が労力に対して得る利益を最大にするため十分に計画を練ったリスクベーステストは大量である必要がないそれでも機器メーカにとって重要な欠陥の発見で生産的にすることができ安全性または規制に関する障害の発見で有効なこともある
最後に
bull 引用している情報は本全体のごくごくわずかでしかありません
bull 規制がどれだけ重量級かという説明ではなくなにのための規制なのかそしてそれをやるときにどのような困難があってどうメリットがあるかという説明になっています
bull 要件やトレーサビリティといった欠陥混入時に多大な影響をあたえるアクティビティへの対応や保守での考え方などぜひ読むべきです
bull 本書は開発ライフサイクルにも言及されていますアジャイルな人たちにもお勧めです
bull まだまだ自分自身理解しきれていないためもう一度全部読み返します
６検証と妥当性確認その実像と虚像
bull あるあるだけどその人たちに「わかってないな」と説教してもあまり伝わらない
bull テストすればよいレビューすればよいとタスクのみを認識する人を改宗することが難しい
業界には明らかに混乱や誤った情報がある当社には医療機器メーカが新しく開発した機器の仕上げ段階でその「妥当性確認」をーできれば1週間以内で－お願いしたいという契約の電話を毎週のように受けている
検証と妥当性確認の内容に関してよくある誤解からはじめよう図６１にそういう根拠のない社会通念をいくつか挙げる最初にもっともよくある誤解は製品に欠陥がないと保証するために製品開発プロセス最後で行う大量のテストを妥当性確認とするものであるこれは２つの理由で誤っているこれから見ていくように妥当性確認はソフトウェアの設計段階で欠陥を入りこませないことと入り込んでしまった欠陥を検出修正すること両方を等しく重視する
６検証と妥当性確認その実像と虚像
妥当性確認
検証
テスト
図６２ 「妥当性確認」対「検証」対「テスト」
bull これで明日からうまく説明できそうです
図６３ ソフトウェア妥当性確認の傘
妥当性確認におけるアクティビティをわかりやすく列挙されています詳しくは原著をお買い求めください
8 2 リスク管理
bull 自分の勘違いがまさに記述されていたリスク管理していればいいのではという勝手な思い込み妥当性確認アクティビティの一部なんだよな
リスク管理は妥当性確認アクティビティとみなされるリスクを特定し重大なリスクに対する制御を設計しそうした制御の有効性を検証する体系的なリスク管理プロセスはソフトウェアやシステムの信用を強化する妥当性確認の目標はソフトウェアの信用を構築することだからリスク管理が妥当性確認アクティビティあるように見えるのだ
812 リスク管理アクティビティ
bull ここでは紙面を割いてハザード分析および確率をどのようにするかが長文で記述されているソフトウェア不具合を起こしやすくする要因の列挙があり参考になった
814 リスク制御
bull ここでは具体例とともにどのようにリスクを軽減または受容するかが記述されている１例としてオッカムのかみそりの適用
bull 実際に自分の開発の中で実践している考え方と近くある意味自信を持てたがそれをどのように教育していくべきかという点で問題がありそうだと感じた なお完全なリスク像を十分に理解できたという確信は私もほしい
今度はその受容不可リスクに対する制御を設計する（または既存のものを特定する）番だ
他人によって自分の病気の母親がそのリスクにさらされたくない（すなわちもっとも単純な直感的評価であるが）なら全体的リスクは受容不可である－このことは他の定量的または定性的分析が結論付ける内容とは関係ない
リスク管理は反復的だからライフサイクル全体で行う必要があるリスク管理プロセスの方法とツールを多くしようすることが名案であることは確かだしかしいろいろな方法で生成された情報をどうまとめ有意義な全体的残存リスク査定を可能にするレビューに備えるかを考えなければならないやはり（中略）情報を1箇所に集めない限り完全なリスク像を十分に理解できたという確信を与えない
13 テストフェーズアクティビティ
bull ISTQBのFoundation Level程度に具体例とともに書かれていてすばらしい
bull テストチームと開発チームとの連携の例はシンプルかつ理解しやすい
135テストの心理学
テスト中のよくない態度を醸成するものとしてテストチームからのソフトウェアに対する一方的批判があるその埋め合わせには開発者をテスト設計のレビュアとして使用することが考えられるこれで少なくとも以下の3つが実現する
1開発者はテスト設計テスタはソフトウェアを批評するように批判の流れのバランスをとる（中略）
2開発者によるテスト設計のレビューはテスト範囲を著しく向上させる (中略）
3テスト設計のレビューはソフトウェア設計に関してと開発者がソフトウェアを機能させるために何が必要だったかの理解を向
上させる結果につながることが多い（中略）こういう情報を活用するテスタはソフトウェアで障害を起こしそうな部分に作業を集中させるそれは本書で述べてきたリスクベースの妥当性確認とテストを構成する要素の1つである
19 妥当性確認をサポートする非機器テストアクティビティ
bull 普段自分が使っているIDEやコンパイラに対するテストするしないを明確に切り分けなかった自分に気がつくことができました
bull ただしFDA規制ガイダンスは規制として有効なのか疑わしいのかとも思いました意識づけるだけなのかあまり理解しきれていません
191テストする理由しない理由
ソフトウェアテストに関する章のはじめ方としては妙かもしれないが多くの場合大量の非機器ソフトウェアテストは妥当性確認投資に効果をあげる最良の方法でない可能性がある
197要約
保守的な妥当性確認計画者はテストの計画を立てて規制問題を満たさなければならないが会社が労力に対して得る利益を最大にするため十分に計画を練ったリスクベーステストは大量である必要がないそれでも機器メーカにとって重要な欠陥の発見で生産的にすることができ安全性または規制に関する障害の発見で有効なこともある
最後に
bull 引用している情報は本全体のごくごくわずかでしかありません
bull 規制がどれだけ重量級かという説明ではなくなにのための規制なのかそしてそれをやるときにどのような困難があってどうメリットがあるかという説明になっています
bull 要件やトレーサビリティといった欠陥混入時に多大な影響をあたえるアクティビティへの対応や保守での考え方などぜひ読むべきです
bull 本書は開発ライフサイクルにも言及されていますアジャイルな人たちにもお勧めです
bull まだまだ自分自身理解しきれていないためもう一度全部読み返します
６検証と妥当性確認その実像と虚像
妥当性確認
検証
テスト
図６２ 「妥当性確認」対「検証」対「テスト」
bull これで明日からうまく説明できそうです
図６３ ソフトウェア妥当性確認の傘
妥当性確認におけるアクティビティをわかりやすく列挙されています詳しくは原著をお買い求めください
8 2 リスク管理
bull 自分の勘違いがまさに記述されていたリスク管理していればいいのではという勝手な思い込み妥当性確認アクティビティの一部なんだよな
リスク管理は妥当性確認アクティビティとみなされるリスクを特定し重大なリスクに対する制御を設計しそうした制御の有効性を検証する体系的なリスク管理プロセスはソフトウェアやシステムの信用を強化する妥当性確認の目標はソフトウェアの信用を構築することだからリスク管理が妥当性確認アクティビティあるように見えるのだ
812 リスク管理アクティビティ
bull ここでは紙面を割いてハザード分析および確率をどのようにするかが長文で記述されているソフトウェア不具合を起こしやすくする要因の列挙があり参考になった
814 リスク制御
bull ここでは具体例とともにどのようにリスクを軽減または受容するかが記述されている１例としてオッカムのかみそりの適用
bull 実際に自分の開発の中で実践している考え方と近くある意味自信を持てたがそれをどのように教育していくべきかという点で問題がありそうだと感じた なお完全なリスク像を十分に理解できたという確信は私もほしい
今度はその受容不可リスクに対する制御を設計する（または既存のものを特定する）番だ
他人によって自分の病気の母親がそのリスクにさらされたくない（すなわちもっとも単純な直感的評価であるが）なら全体的リスクは受容不可である－このことは他の定量的または定性的分析が結論付ける内容とは関係ない
リスク管理は反復的だからライフサイクル全体で行う必要があるリスク管理プロセスの方法とツールを多くしようすることが名案であることは確かだしかしいろいろな方法で生成された情報をどうまとめ有意義な全体的残存リスク査定を可能にするレビューに備えるかを考えなければならないやはり（中略）情報を1箇所に集めない限り完全なリスク像を十分に理解できたという確信を与えない
13 テストフェーズアクティビティ
bull ISTQBのFoundation Level程度に具体例とともに書かれていてすばらしい
bull テストチームと開発チームとの連携の例はシンプルかつ理解しやすい
135テストの心理学
テスト中のよくない態度を醸成するものとしてテストチームからのソフトウェアに対する一方的批判があるその埋め合わせには開発者をテスト設計のレビュアとして使用することが考えられるこれで少なくとも以下の3つが実現する
1開発者はテスト設計テスタはソフトウェアを批評するように批判の流れのバランスをとる（中略）
2開発者によるテスト設計のレビューはテスト範囲を著しく向上させる (中略）
3テスト設計のレビューはソフトウェア設計に関してと開発者がソフトウェアを機能させるために何が必要だったかの理解を向
上させる結果につながることが多い（中略）こういう情報を活用するテスタはソフトウェアで障害を起こしそうな部分に作業を集中させるそれは本書で述べてきたリスクベースの妥当性確認とテストを構成する要素の1つである
19 妥当性確認をサポートする非機器テストアクティビティ
bull 普段自分が使っているIDEやコンパイラに対するテストするしないを明確に切り分けなかった自分に気がつくことができました
bull ただしFDA規制ガイダンスは規制として有効なのか疑わしいのかとも思いました意識づけるだけなのかあまり理解しきれていません
191テストする理由しない理由
ソフトウェアテストに関する章のはじめ方としては妙かもしれないが多くの場合大量の非機器ソフトウェアテストは妥当性確認投資に効果をあげる最良の方法でない可能性がある
197要約
保守的な妥当性確認計画者はテストの計画を立てて規制問題を満たさなければならないが会社が労力に対して得る利益を最大にするため十分に計画を練ったリスクベーステストは大量である必要がないそれでも機器メーカにとって重要な欠陥の発見で生産的にすることができ安全性または規制に関する障害の発見で有効なこともある
最後に
bull 引用している情報は本全体のごくごくわずかでしかありません
bull 規制がどれだけ重量級かという説明ではなくなにのための規制なのかそしてそれをやるときにどのような困難があってどうメリットがあるかという説明になっています
bull 要件やトレーサビリティといった欠陥混入時に多大な影響をあたえるアクティビティへの対応や保守での考え方などぜひ読むべきです
bull 本書は開発ライフサイクルにも言及されていますアジャイルな人たちにもお勧めです
bull まだまだ自分自身理解しきれていないためもう一度全部読み返します
8 2 リスク管理
bull 自分の勘違いがまさに記述されていたリスク管理していればいいのではという勝手な思い込み妥当性確認アクティビティの一部なんだよな
リスク管理は妥当性確認アクティビティとみなされるリスクを特定し重大なリスクに対する制御を設計しそうした制御の有効性を検証する体系的なリスク管理プロセスはソフトウェアやシステムの信用を強化する妥当性確認の目標はソフトウェアの信用を構築することだからリスク管理が妥当性確認アクティビティあるように見えるのだ
812 リスク管理アクティビティ
bull ここでは紙面を割いてハザード分析および確率をどのようにするかが長文で記述されているソフトウェア不具合を起こしやすくする要因の列挙があり参考になった
814 リスク制御
bull ここでは具体例とともにどのようにリスクを軽減または受容するかが記述されている１例としてオッカムのかみそりの適用
bull 実際に自分の開発の中で実践している考え方と近くある意味自信を持てたがそれをどのように教育していくべきかという点で問題がありそうだと感じた なお完全なリスク像を十分に理解できたという確信は私もほしい
今度はその受容不可リスクに対する制御を設計する（または既存のものを特定する）番だ
他人によって自分の病気の母親がそのリスクにさらされたくない（すなわちもっとも単純な直感的評価であるが）なら全体的リスクは受容不可である－このことは他の定量的または定性的分析が結論付ける内容とは関係ない
リスク管理は反復的だからライフサイクル全体で行う必要があるリスク管理プロセスの方法とツールを多くしようすることが名案であることは確かだしかしいろいろな方法で生成された情報をどうまとめ有意義な全体的残存リスク査定を可能にするレビューに備えるかを考えなければならないやはり（中略）情報を1箇所に集めない限り完全なリスク像を十分に理解できたという確信を与えない
13 テストフェーズアクティビティ
bull ISTQBのFoundation Level程度に具体例とともに書かれていてすばらしい
bull テストチームと開発チームとの連携の例はシンプルかつ理解しやすい
135テストの心理学
テスト中のよくない態度を醸成するものとしてテストチームからのソフトウェアに対する一方的批判があるその埋め合わせには開発者をテスト設計のレビュアとして使用することが考えられるこれで少なくとも以下の3つが実現する
1開発者はテスト設計テスタはソフトウェアを批評するように批判の流れのバランスをとる（中略）
2開発者によるテスト設計のレビューはテスト範囲を著しく向上させる (中略）
3テスト設計のレビューはソフトウェア設計に関してと開発者がソフトウェアを機能させるために何が必要だったかの理解を向
上させる結果につながることが多い（中略）こういう情報を活用するテスタはソフトウェアで障害を起こしそうな部分に作業を集中させるそれは本書で述べてきたリスクベースの妥当性確認とテストを構成する要素の1つである
19 妥当性確認をサポートする非機器テストアクティビティ
bull 普段自分が使っているIDEやコンパイラに対するテストするしないを明確に切り分けなかった自分に気がつくことができました
bull ただしFDA規制ガイダンスは規制として有効なのか疑わしいのかとも思いました意識づけるだけなのかあまり理解しきれていません
191テストする理由しない理由
ソフトウェアテストに関する章のはじめ方としては妙かもしれないが多くの場合大量の非機器ソフトウェアテストは妥当性確認投資に効果をあげる最良の方法でない可能性がある
197要約
保守的な妥当性確認計画者はテストの計画を立てて規制問題を満たさなければならないが会社が労力に対して得る利益を最大にするため十分に計画を練ったリスクベーステストは大量である必要がないそれでも機器メーカにとって重要な欠陥の発見で生産的にすることができ安全性または規制に関する障害の発見で有効なこともある
最後に
bull 引用している情報は本全体のごくごくわずかでしかありません
bull 規制がどれだけ重量級かという説明ではなくなにのための規制なのかそしてそれをやるときにどのような困難があってどうメリットがあるかという説明になっています
bull 要件やトレーサビリティといった欠陥混入時に多大な影響をあたえるアクティビティへの対応や保守での考え方などぜひ読むべきです
bull 本書は開発ライフサイクルにも言及されていますアジャイルな人たちにもお勧めです
bull まだまだ自分自身理解しきれていないためもう一度全部読み返します
812 リスク管理アクティビティ
bull ここでは紙面を割いてハザード分析および確率をどのようにするかが長文で記述されているソフトウェア不具合を起こしやすくする要因の列挙があり参考になった
814 リスク制御
bull ここでは具体例とともにどのようにリスクを軽減または受容するかが記述されている１例としてオッカムのかみそりの適用
bull 実際に自分の開発の中で実践している考え方と近くある意味自信を持てたがそれをどのように教育していくべきかという点で問題がありそうだと感じた なお完全なリスク像を十分に理解できたという確信は私もほしい
今度はその受容不可リスクに対する制御を設計する（または既存のものを特定する）番だ
他人によって自分の病気の母親がそのリスクにさらされたくない（すなわちもっとも単純な直感的評価であるが）なら全体的リスクは受容不可である－このことは他の定量的または定性的分析が結論付ける内容とは関係ない
リスク管理は反復的だからライフサイクル全体で行う必要があるリスク管理プロセスの方法とツールを多くしようすることが名案であることは確かだしかしいろいろな方法で生成された情報をどうまとめ有意義な全体的残存リスク査定を可能にするレビューに備えるかを考えなければならないやはり（中略）情報を1箇所に集めない限り完全なリスク像を十分に理解できたという確信を与えない
13 テストフェーズアクティビティ
bull ISTQBのFoundation Level程度に具体例とともに書かれていてすばらしい
bull テストチームと開発チームとの連携の例はシンプルかつ理解しやすい
135テストの心理学
テスト中のよくない態度を醸成するものとしてテストチームからのソフトウェアに対する一方的批判があるその埋め合わせには開発者をテスト設計のレビュアとして使用することが考えられるこれで少なくとも以下の3つが実現する
1開発者はテスト設計テスタはソフトウェアを批評するように批判の流れのバランスをとる（中略）
2開発者によるテスト設計のレビューはテスト範囲を著しく向上させる (中略）
3テスト設計のレビューはソフトウェア設計に関してと開発者がソフトウェアを機能させるために何が必要だったかの理解を向
上させる結果につながることが多い（中略）こういう情報を活用するテスタはソフトウェアで障害を起こしそうな部分に作業を集中させるそれは本書で述べてきたリスクベースの妥当性確認とテストを構成する要素の1つである
19 妥当性確認をサポートする非機器テストアクティビティ
bull 普段自分が使っているIDEやコンパイラに対するテストするしないを明確に切り分けなかった自分に気がつくことができました
bull ただしFDA規制ガイダンスは規制として有効なのか疑わしいのかとも思いました意識づけるだけなのかあまり理解しきれていません
191テストする理由しない理由
ソフトウェアテストに関する章のはじめ方としては妙かもしれないが多くの場合大量の非機器ソフトウェアテストは妥当性確認投資に効果をあげる最良の方法でない可能性がある
197要約
保守的な妥当性確認計画者はテストの計画を立てて規制問題を満たさなければならないが会社が労力に対して得る利益を最大にするため十分に計画を練ったリスクベーステストは大量である必要がないそれでも機器メーカにとって重要な欠陥の発見で生産的にすることができ安全性または規制に関する障害の発見で有効なこともある
最後に
bull 引用している情報は本全体のごくごくわずかでしかありません
bull 規制がどれだけ重量級かという説明ではなくなにのための規制なのかそしてそれをやるときにどのような困難があってどうメリットがあるかという説明になっています
bull 要件やトレーサビリティといった欠陥混入時に多大な影響をあたえるアクティビティへの対応や保守での考え方などぜひ読むべきです
bull 本書は開発ライフサイクルにも言及されていますアジャイルな人たちにもお勧めです
bull まだまだ自分自身理解しきれていないためもう一度全部読み返します
814 リスク制御
bull ここでは具体例とともにどのようにリスクを軽減または受容するかが記述されている１例としてオッカムのかみそりの適用
bull 実際に自分の開発の中で実践している考え方と近くある意味自信を持てたがそれをどのように教育していくべきかという点で問題がありそうだと感じた なお完全なリスク像を十分に理解できたという確信は私もほしい
今度はその受容不可リスクに対する制御を設計する（または既存のものを特定する）番だ
他人によって自分の病気の母親がそのリスクにさらされたくない（すなわちもっとも単純な直感的評価であるが）なら全体的リスクは受容不可である－このことは他の定量的または定性的分析が結論付ける内容とは関係ない
リスク管理は反復的だからライフサイクル全体で行う必要があるリスク管理プロセスの方法とツールを多くしようすることが名案であることは確かだしかしいろいろな方法で生成された情報をどうまとめ有意義な全体的残存リスク査定を可能にするレビューに備えるかを考えなければならないやはり（中略）情報を1箇所に集めない限り完全なリスク像を十分に理解できたという確信を与えない
13 テストフェーズアクティビティ
bull ISTQBのFoundation Level程度に具体例とともに書かれていてすばらしい
bull テストチームと開発チームとの連携の例はシンプルかつ理解しやすい
135テストの心理学
テスト中のよくない態度を醸成するものとしてテストチームからのソフトウェアに対する一方的批判があるその埋め合わせには開発者をテスト設計のレビュアとして使用することが考えられるこれで少なくとも以下の3つが実現する
1開発者はテスト設計テスタはソフトウェアを批評するように批判の流れのバランスをとる（中略）
2開発者によるテスト設計のレビューはテスト範囲を著しく向上させる (中略）
3テスト設計のレビューはソフトウェア設計に関してと開発者がソフトウェアを機能させるために何が必要だったかの理解を向
上させる結果につながることが多い（中略）こういう情報を活用するテスタはソフトウェアで障害を起こしそうな部分に作業を集中させるそれは本書で述べてきたリスクベースの妥当性確認とテストを構成する要素の1つである
19 妥当性確認をサポートする非機器テストアクティビティ
bull 普段自分が使っているIDEやコンパイラに対するテストするしないを明確に切り分けなかった自分に気がつくことができました
bull ただしFDA規制ガイダンスは規制として有効なのか疑わしいのかとも思いました意識づけるだけなのかあまり理解しきれていません
191テストする理由しない理由
ソフトウェアテストに関する章のはじめ方としては妙かもしれないが多くの場合大量の非機器ソフトウェアテストは妥当性確認投資に効果をあげる最良の方法でない可能性がある
197要約
保守的な妥当性確認計画者はテストの計画を立てて規制問題を満たさなければならないが会社が労力に対して得る利益を最大にするため十分に計画を練ったリスクベーステストは大量である必要がないそれでも機器メーカにとって重要な欠陥の発見で生産的にすることができ安全性または規制に関する障害の発見で有効なこともある
最後に
bull 引用している情報は本全体のごくごくわずかでしかありません
bull 規制がどれだけ重量級かという説明ではなくなにのための規制なのかそしてそれをやるときにどのような困難があってどうメリットがあるかという説明になっています
bull 要件やトレーサビリティといった欠陥混入時に多大な影響をあたえるアクティビティへの対応や保守での考え方などぜひ読むべきです
bull 本書は開発ライフサイクルにも言及されていますアジャイルな人たちにもお勧めです
bull まだまだ自分自身理解しきれていないためもう一度全部読み返します
13 テストフェーズアクティビティ
bull ISTQBのFoundation Level程度に具体例とともに書かれていてすばらしい
bull テストチームと開発チームとの連携の例はシンプルかつ理解しやすい
135テストの心理学
テスト中のよくない態度を醸成するものとしてテストチームからのソフトウェアに対する一方的批判があるその埋め合わせには開発者をテスト設計のレビュアとして使用することが考えられるこれで少なくとも以下の3つが実現する
1開発者はテスト設計テスタはソフトウェアを批評するように批判の流れのバランスをとる（中略）
2開発者によるテスト設計のレビューはテスト範囲を著しく向上させる (中略）
3テスト設計のレビューはソフトウェア設計に関してと開発者がソフトウェアを機能させるために何が必要だったかの理解を向
上させる結果につながることが多い（中略）こういう情報を活用するテスタはソフトウェアで障害を起こしそうな部分に作業を集中させるそれは本書で述べてきたリスクベースの妥当性確認とテストを構成する要素の1つである
19 妥当性確認をサポートする非機器テストアクティビティ
bull 普段自分が使っているIDEやコンパイラに対するテストするしないを明確に切り分けなかった自分に気がつくことができました
bull ただしFDA規制ガイダンスは規制として有効なのか疑わしいのかとも思いました意識づけるだけなのかあまり理解しきれていません
191テストする理由しない理由
ソフトウェアテストに関する章のはじめ方としては妙かもしれないが多くの場合大量の非機器ソフトウェアテストは妥当性確認投資に効果をあげる最良の方法でない可能性がある
197要約
保守的な妥当性確認計画者はテストの計画を立てて規制問題を満たさなければならないが会社が労力に対して得る利益を最大にするため十分に計画を練ったリスクベーステストは大量である必要がないそれでも機器メーカにとって重要な欠陥の発見で生産的にすることができ安全性または規制に関する障害の発見で有効なこともある
最後に
bull 引用している情報は本全体のごくごくわずかでしかありません
bull 規制がどれだけ重量級かという説明ではなくなにのための規制なのかそしてそれをやるときにどのような困難があってどうメリットがあるかという説明になっています
bull 要件やトレーサビリティといった欠陥混入時に多大な影響をあたえるアクティビティへの対応や保守での考え方などぜひ読むべきです
bull 本書は開発ライフサイクルにも言及されていますアジャイルな人たちにもお勧めです
bull まだまだ自分自身理解しきれていないためもう一度全部読み返します
19 妥当性確認をサポートする非機器テストアクティビティ
bull 普段自分が使っているIDEやコンパイラに対するテストするしないを明確に切り分けなかった自分に気がつくことができました
bull ただしFDA規制ガイダンスは規制として有効なのか疑わしいのかとも思いました意識づけるだけなのかあまり理解しきれていません
191テストする理由しない理由
ソフトウェアテストに関する章のはじめ方としては妙かもしれないが多くの場合大量の非機器ソフトウェアテストは妥当性確認投資に効果をあげる最良の方法でない可能性がある
197要約
保守的な妥当性確認計画者はテストの計画を立てて規制問題を満たさなければならないが会社が労力に対して得る利益を最大にするため十分に計画を練ったリスクベーステストは大量である必要がないそれでも機器メーカにとって重要な欠陥の発見で生産的にすることができ安全性または規制に関する障害の発見で有効なこともある
最後に
bull 引用している情報は本全体のごくごくわずかでしかありません
bull 規制がどれだけ重量級かという説明ではなくなにのための規制なのかそしてそれをやるときにどのような困難があってどうメリットがあるかという説明になっています
bull 要件やトレーサビリティといった欠陥混入時に多大な影響をあたえるアクティビティへの対応や保守での考え方などぜひ読むべきです
bull 本書は開発ライフサイクルにも言及されていますアジャイルな人たちにもお勧めです
bull まだまだ自分自身理解しきれていないためもう一度全部読み返します
最後に
bull 引用している情報は本全体のごくごくわずかでしかありません
bull 規制がどれだけ重量級かという説明ではなくなにのための規制なのかそしてそれをやるときにどのような困難があってどうメリットがあるかという説明になっています
bull 要件やトレーサビリティといった欠陥混入時に多大な影響をあたえるアクティビティへの対応や保守での考え方などぜひ読むべきです
bull 本書は開発ライフサイクルにも言及されていますアジャイルな人たちにもお勧めです
bull まだまだ自分自身理解しきれていないためもう一度全部読み返します
