【12thWOCS2最優秀賞受賞テーマ】 D-Caseを用いたレビューを 見える化する方法の導入事例 IoT時代のセーフティとセキュリティ 2015.03.30, IPA/SEC （株）デンソークリエイト小林展英 D-Case導入の目的 1 / 35 開発現場が抱える問題 •  上位者の経験が成果物に上手く反映できていない –  担当者は成果物の妥当性を論理的に説明できず、上位者は明確な判断基準に基づいた指摘ができていないため、もぐら叩き的なレビューになってしまう経験基づく成果物担当者（作成側）不一致経験上位者（依頼側）レビュー・確認する基づく確認記録問題の解決方針 2 / 35 •  上位者と担当者が同じ経験に基づいて仕事に取り組む環境を整えることで問題解消を図る成果物が満たすべき基準経験（常識・考え方など）基準を満たすように成果物を作成成果物確認記録成果物が基準を満足することを確認成果物が基準を満足することができなければ成果物を改訂上位者の経験を担当者と正しく共有できる方法が必要経験を正しく共有する方法 3 / 35 •  双方の経験（常識、語彙等）が揃えば相手と正しく情報を共有できるはず依頼側・開発側ともに理解していること（世の中の常識）開発側の背景（組織の常識）依頼側の背景（組織の常識）受け取る情報の前提（議論毎の常識）受け取る情報伝える情報の前提（議論毎の常識）文書伝える情報考え方考え方語彙語彙担当者上位者経験を見える化して相手と共有する手段としてD-Caseを導入 D-Caseの紹介：基本的な描き方 •  •  4 / 35 相手と合意形成できている前提に基づき上位の主張を下位の主張に分解最下位の主張の妥当性を証拠に基づいて説明することで主張全体が特性基準を満足できていることを説明する特性基準前提成果物の構成成果物が特性基準を満足している成果物の構成に従って説明する成果物の構成要素が特性基準を満たしている主張説明成果物の構成要素間の関係が特性基準を満たしている証拠構成要素が特性基準を満たす証拠構成要素間の関係が特性基準を満たす証拠 D-Caseの適用方法 •  •  5 / 35 相手と合意形成できている前提に基づき上位の主張を下位の主張に分解最下位の主張の妥当性を証拠に基づいて説明することで主張全体が特性基準を満足できていることを説明する特性基準前提成果物の構成成果物が特性基準を満足している成果物の構成に従って説明する主張確認記録説明経験成果物の構成要素が特性基準を満たしている成果物の構成要素間の関係が特性基準を満たしている証拠構成要素が特性基準を満たす証拠成果物構成要素間の関係が特性基準を満たす証拠 D-Caseを用いたレビューの方法手順1：前提となる文書を揃える知らない知っている新規に用意する相手・相手と合意形成できている文書を揃える・不足する場合は右記の４状態を念頭に ③文書化 ④一緒にして理解を文書化する得る ②教えて ①合意形成もらってできている文書化知っている知らない自分手順4：D-Caseで説明する・"構造に関する文書"に基づいて説明したいことを手頃な大きさに分解して説明する・説明の妥当性は、"条件に関する文書"を成果物が満足していることで納得を得る・上記流れで相手の納得を得られなければ手順１から再チャレンジ！ 6 / 35 手順2：説明の構造を設計する・手順１で揃えた文書を前提として説明の構造を設計する前提構造に関する文書前提条件に関する文書 "説明したいこと" ゴールは妥当である前提に従って説明する構造の構成要素は妥当である戦略・・・手順3：成果物を証拠に紐づける・説明の妥当性を最終的に支える証拠として条件を満足できる成果物を紐付ける条件に関する文書構造の構成要素は妥当である条件を満足できる成果物設計品質レビューでの活用事例 7 / 35 ＜インタフェース仕様＞ ret = ConvMsec(unsigned short sec, unsigned long *msec); ＜変換規則＞・secを1000倍した値を*msecに格納し、E_OKを戻り値とする。・secが255より大きい場合は*msecに255000を格納し、 E_OVERを戻り値とする。＜設計品質レビューの報告内容＞確認事項テスト項目数は十分であるか？：仕様を満足することが確認されているか？妥当性証拠判断 OK テスト仕様書： OK ：テスト報告書妥当性判断の根拠既存処理をコードレビューで押さえ、追加処理の境界値に関するテスト項目を抽出。：テスト仕様書の該当項目がすべて合格している設計品質レビューでの活用事例 8 / 35 テスト項目数は十分であるか？：仕様を満足することが確認されているか？： OK ：テスト報告書 sec＞255 ⑦ ⑥ ※ 妥当性判断の根拠既存処理をコードレビューで押さえ、追加処理の境界値に関するテスト項目を抽出。：テスト仕様書の該当項目がすべて合格しているそれ以外妥当性証拠判断 OK テスト仕様書 ret = E_OK; ① sec = MAX; ② ＜設計品質レビューの報告内容＞確認事項＜処理の流れ＞ tmp = sec×1000;③ sec==MAX ⑧ ⑨ ret = E_OVER ④ それ以外＜インタフェース仕様＞ ret = ConvMsec(unsigned short sec, unsigned long *msec); ＜変換規則＞・secを1000倍した値を*msecに格納し、E_OKを戻り値とする。・secが255より大きい場合は*msecに255000を格納し、 E_OVERを戻り値とする。 *msec = tmp; ⑤ ※MAX=255 手順1：前提となる文書を揃える相手知らない知っている手順１：前提となる文書を揃える・相手と合意形成できている文書を揃える・不足する場合は右記の４状態を念頭に新規に用意する ③文書化 ④一緒にして理解を文書化する得る ②教えて ①合意形成もらってできている文書化知っている知らない自分手順4：D-Caseで説明する・"構造に関する文書"に基づいて説明したいことを手頃な大きさに分解して説明する・説明の妥当性は、"条件に関する文書"を成果物が満足していることで納得を得る・上記流れで相手の納得を得られなければ手順１から再チャレンジ！手順2：説明の構造を設計する・手順１で揃えた文書を前提として説明の "説明したいこと" 構造を設計するゴール前提構造に関する文書前提条件に関する文書は妥当である前提に従って説明する構造の構成要素は妥当である戦略・・・手順3：成果物を証拠に紐づける・説明の妥当性を最終的に支える証拠として条件を満足できる成果物を紐付ける条件に関する文書 9 / 35 構造の構成要素は妥当である条件を満足できる成果物 •  「保証対象の構造」に従って上位者の考える合格基準を明文化保証対象既存処理追加処理関係品質保証対象合格基準既存処理（C1）前回リリース時とコードの差分がない追加処理（C2）入力の境界値を網羅したテスト項目を実施既存処理と追加（C3）対象のパス毎に正常系のテスト項目を処理の関係１項目以上実施手順1：前提となる文書を揃える相手知らない知っている手順２：説明の構造を設計する・相手と合意形成できている文書を揃える・不足する場合は右記の４状態を念頭に新規に用意する ③文書化 ④一緒にして理解を文書化する得る ②教えて ①合意形成もらってできている文書化知っている知らない自分手順4：D-Caseで説明する・"構造に関する文書"に基づいて説明したいことを手頃な大きさに分解して説明する・説明の妥当性は、"条件に関する文書"を成果物が満足していることで納得を得る・上記流れで相手の納得を得られなければ手順１から再チャレンジ！手順2：説明の構造を設計する・手順１で揃えた文書を前提として説明の "説明したいこと" 構造を設計するゴール前提構造に関する文書前提条件に関する文書は妥当である前提に従って説明する構造の構成要素は妥当である戦略・・・手順3：成果物を証拠に紐づける・説明の妥当性を最終的に支える証拠として条件を満足できる成果物を紐付ける条件に関する文書 10 / 35 構造の構成要素は妥当である条件を満足できる成果物 •  上位者の考える合格基準を前提として説明の構造を見える化手順1：前提となる文書を揃える相手知らない知っている手順３：成果物を証拠に紐付ける・相手と合意形成できている文書を揃える・不足する場合は右記の４状態を念頭に新規に用意する ③文書化 ④一緒にして理解を文書化する得る ②教えて ①合意形成もらってできている文書化知っている知らない自分手順4：D-Caseで説明する・"構造に関する文書"に基づいて説明したいことを手頃な大きさに分解して説明する・説明の妥当性は、"条件に関する文書"を成果物が満足していることで納得を得る・上記流れで相手の納得を得られなければ手順１から再チャレンジ！手順2：説明の構造を設計する・手順１で揃えた文書を前提として説明の "説明したいこと" 構造を設計するゴール前提構造に関する文書前提条件に関する文書は妥当である前提に従って説明する構造の構成要素は妥当である戦略・・・手順3：成果物を証拠に紐づける・説明の妥当性を最終的に支える証拠として条件を満足できる成果物を紐付ける条件に関する文書構造の構成要素は妥当である条件を満足できる成果物 11 / 35 手順1：前提となる文書を揃える相手知らない知っている手順３：成果物を証拠に紐付ける・相手と合意形成できている文書を揃える・不足する場合は右記の４状態を念頭に新規に用意する ③文書化 ④一緒にして理解を文書化する得る ②教えて ①合意形成もらってできている文書化知っている知らない自分手順4：D-Caseで説明する・"構造に関する文書"に基づいて説明したいことを手頃な大きさに分解して説明する・説明の妥当性は、"条件に関する文書"を成果物が満足していることで納得を得る・上記流れで相手の納得を得られなければ手順１から再チャレンジ！手順2：説明の構造を設計する・手順１で揃えた文書を前提として説明の "説明したいこと" 構造を設計するゴール前提構造に関する文書前提条件に関する文書は妥当である前提に従って説明する構造の構成要素は妥当である戦略・・・手順3：成果物を証拠に紐づける・説明の妥当性を最終的に支える証拠として条件を満足できる成果物を紐付ける条件に関する文書 12 / 35 構造の構成要素は妥当である条件を満足できる成果物手順４：D-Caseで説明（その１）手順４：D-Caseで説明（その２）手順1：前提となる文書を揃える相手知らない知っている ③文書化 ④一緒にして理解を文書化する得る ②教えて ①合意形成もらってできている文書化知っている知らない自分手順4：D-Caseで説明する・"構造に関する文書"に基づいて説明したいことを手頃な大きさに分解して説明する・説明の妥当性は、"条件に関する文書"を成果物が満足していることで納得を得る・上記流れで相手の納得を得られなければ手順１から再チャレンジ！前提構造に関する文書前提条件に関する文書は妥当である前提に従って説明する構造の構成要素は妥当である戦略・・・手順3：成果物を証拠に紐づける・説明の妥当性を最終的に支える証拠として条件を満足できる成果物を紐付ける条件に関する文書 13 / 35 構造の構成要素は妥当である条件を満足できる成果物＜ConvMsec実装＞ ret = E_OK; ① sec＞255 ⑦ ⑥ ※ sec = MAX; ② それ以外 •  上位者の合格基準（C1,2）を満足しており問題無し手順2：説明の構造を設計する・手順１で揃えた文書を前提として説明の "説明したいこと" 構造を設計するゴール tmp = sec×1000;③ sec==MAX ⑧ ⑨ ret = E_OVER ④ それ以外手順４：D-Caseで説明（その１）・相手と合意形成できている文書を揃える・不足する場合は右記の４状態を念頭に新規に用意する *msec = tmp; ⑤ ※MAX=255 手順1：前提となる文書を揃える相手知らない知っている ③文書化 ④一緒にして理解を文書化する得る ②教えて ①合意形成もらってできている文書化知っている知らない自分手順4：D-Caseで説明する・"構造に関する文書"に基づいて説明したいことを手頃な大きさに分解して説明する・説明の妥当性は、"条件に関する文書"を成果物が満足していることで納得を得る・上記流れで相手の納得を得られなければ手順１から再チャレンジ！ sec=255時に E_OVERが返る前提構造に関する文書前提条件に関する文書は妥当である前提に従って説明する構造の構成要素は妥当である戦略・・・手順3：成果物を証拠に紐づける・説明の妥当性を最終的に支える証拠として条件を満足できる成果物を紐付ける条件に関する文書 14 / 35 構造の構成要素は妥当である条件を満足できる成果物＜ConvMsec実装＞ ret = E_OK; ① sec＞255 ⑦ ⑥ ※ sec = MAX; ② それ以外 •  上位者の合格基準（C3）未達の証拠（Sn4, 5, 6）を検出 •  Sn5, 6は合格基準を満たすため追加テストを実施 ⇒ Sn5の追加テスト時に不具合発見！手順2：説明の構造を設計する・手順１で揃えた文書を前提として説明の "説明したいこと" 構造を設計するゴール tmp = sec×1000;③ sec==MAX ⑧ ⑨ ret = E_OVER ④ それ以外手順４：D-Caseで説明（その２）・相手と合意形成できている文書を揃える・不足する場合は右記の４状態を念頭に新規に用意する *msec = tmp; ⑤ ※MAX=255 上位者 - 担当者の理解のズレが発生した原因 ret = E_OK; ① 既存処理をコードレビューで押さえ、追加処理の境界値に関するテスト項目を抽出。既存処理 sec＞255 ⑦ ⑥ ※ sec = MAX; ② ret = E_OK; ① ⑨ ret = E_OVER ④ ※ sec = MAX; ② *msec = tmp; ⑤ sec==MAX ⑧ 追加処理ないため既存処理と理解していた赤点線枠の理解のズレが発生追加処理担当者は⑦⑨の処理が空で追加が sec==MAX ⑧ ⑦ ⑥ tmp = sec×1000;③ それ以外 tmp = sec×1000;③ sec＞255 それ以外か？ OK 既存処理妥当性判断の根拠追加処理目数は十分である判断＜担当者の理解＞それ以外テスト項妥当性追加処理確認事項＜上位者の理解＞ ⑨ ret = E_OVER ④ それ以外＜設計品質レビューの報告内容＞ 15 / 35 *msec = tmp; ⑤ ※MAX=255 D-Caseで構造化した説明内容を確認することで不具合の流出につながる理解のズレに気づくことができた ※MAX=255 D-Caseから得られる勘所（その１） 16 / 35 •  複数のゴールが一つの証拠に集約している場合、複数の視点が一箇所に混在した文書になっている場合が多い（文書品質が低い可能性がある）《メモリ管理機能外部仕様書》 2. 機能仕様 2.1. 初期化メモリ管理機能はECUの初期化要求時に不揮発メモリを初期化する。要求時に指定された開始アドレスからデータ長までの範囲を初期化対象とする。また、初期化時に指定された値を不揮発メモリの初期値とする。データ長の値域は0〜100までとし、それ以外の値が設定された場合にはエラーを返す。初期値に使用できる値域は0〜 255とする。値域外の値を渡された場合のエラーはE_INVALIDを戻り値として返す。関数の詳細はx.x節参照。 2.2. 不揮発メモリ書込み： 2.3. 不揮発メモリ読み出し： D-Caseから得られる勘所（その２） •  戦略にレビュー対象の構造や属性を示した前提が関連付けられていない場合、分解されたゴールが網羅的でない場合が多い（納得感が薄い） 17 / 35 D-Caseから得られる勘所（その２） 18 / 35 •  戦略にレビュー対象の構造や属性を示した前提が関連付けられていない場合、分解されたゴールが網羅的でない場合が多い（納得感が薄い）プロセス関連プロダクト関連：機能要件プロダクト関連：非機能要件 D-Caseから得られる勘所（その３） 19 / 35 •  ゴールに証拠の判断基準となる前提が関連付けられていない場合、証拠のレビュー基準がレビューアの感覚の場合が多い（客観的な根拠がない）インタフェースが文書化されていることは分かるが… インタフェースの妥当性を判断した根拠が明文化されているプロジェクトで活用しているレビュー基準の整備状況も見える化できる安全分析プロセスでの活用事例 20 / 35 今回採用した安全分析プロセス手順1：ハザード分析手順2：故障モード抽出・HAZOPを用いて機能の正常動作からの逸脱をハザードとして抽出・FTAの末端ノードはガイドワードを用いて故障モードとして抽出・システムが提供する機能の特性に応じてHAZOPのガイドワードを決定手順4：D-Caseで説明する・以下の3点をD-Caseで見える化する - 故障モードの抽出結果 - 故障モードに対する対策 - システムに対する対策の組込み状況・ハザードをFTAのトップゴールに設定・システム構成に基づいてハザードを分解手順3：故障モードの対策定義・故障モードを装置単体で回避できる場合、装置毎のスコープで対策を定義・複数の装置に跨がった対策が必要な場合、装置間共通の方針を定めた上で対策を定義安全分析における重要なポイント •  安全分析の結果を第三者が納得して確認できる必要がある安全分析プロセスの適用対象：ヘッドライト制御システム 21 / 35 提供機能 ID. 機能 1. ユーザのライトスイッチ操作に応じてヘッドライトを点灯 2. ユーザのライトスイッチ操作に応じてヘッドライトを消灯システム構成ライトスイッチ IGスイッチ HW_LS HW_IG ボデー制御 CAN ECU ：ワイヤハーネス：CAN通信線 HW_HLR ヘッドライト制御ECU HW_HLL ：センサ/アクチュエータ：ECU 右ヘッドライト左ヘッドライト安全分析プロセスの適用対象：ヘッドライト制御システム 22 / 35 ECUソフトウェア構成ヘッドライト制御ECU AUTOSAR RTE COM-Stack IO-Stack CAN HW_LS HW_HLR HW_HLL RTOS アプリケーション層 AUTOSAR基盤層 Head Light Control SW-C アプリケーション実行層車載ソフト共通機能提供層今回試行の前提 •  安全分析の簡略化事項 –  FMEAを組み合わせた故障モード起点の分析を省略 –  故障モードを回避する対策定義時の重要性分析などを省略 •  説明対象の省略事項 –  システムを構成する装置のハードウェア詳細 –  中核を担うヘッドライト制御ECU以外のソフトウェア構成 –  ECUに搭載されるソフトウェア部品の詳細 D-Caseの有効性評価に焦点を置いているため上記を前提とした 23 / 35 手順１：ハザード分析結果手順1：ハザード分析手順2：故障モード抽出手順4：D-Caseで説明する手順3：故障モードの対策定義・システムが提供する機能の特性に応じてHAZOPのガイドワードを決定・HAZOPを用いて機能の正常動作からの逸脱をハザードとして抽出・以下の3点をD-Caseで見える化する - 故障モードの抽出結果 - 故障モードに対する対策 - システムに対する対策の組込み状況ガイドワード採用方針・ハザードをFTAのトップゴールに設定・システム構成に基づいてハザードを分解・FTAの末端ノードはガイドワードを用いて故障モードとして抽出 24 / 35 ・故障モードを装置単体で回避できる場合、装置毎のスコープで対策を定義・複数の装置に跨がった対策が必要な場合、装置間共通の方針を定めた上で対策を定義 •  ヘッドライトが持つ点灯、消灯という値に着目して以下のガイドワードを採用 –  無し、異なる、過多、過少ハザード分析結果 ID. ガイドワードハザード 1. 無し 2. 異なる 3. 過多ヘッドライトの光量が多い 4. 過少ヘッドライトの光量不足ヘッドライトの完全な喪失ユーザ操作に対するヘッドライトの点灯、消灯が逆転手順２：故障モード分析結果手順1：ハザード分析手順2：故障モード抽出手順4：D-Caseで説明する手順3：故障モードの対策定義・システムが提供する機能の特性に応じてHAZOPのガイドワードを決定・HAZOPを用いて機能の正常動作からの逸脱をハザードとして抽出・以下の3点をD-Caseで見える化する - 故障モードの抽出結果 - 故障モードに対する対策 - システムに対する対策の組込み状況装置種別装置 H/W本体＋入出力起こり得る故障・ハザードをFTAのトップゴールに設定・システム構成に基づいてハザードを分解・FTAの末端ノードはガイドワードを用いて故障モードとして抽出・故障モードを装置単体で回避できる場合、装置毎のスコープで対策を定義・複数の装置に跨がった対策が必要な場合、装置間共通の方針を定めた上で対策を定義 25 / 35 手順３：故障モードの対策定義結果手順1：ハザード分析手順2：故障モード抽出手順4：D-Caseで説明する手順3：故障モードの対策定義・システムが提供する機能の特性に応じてHAZOPのガイドワードを決定・HAZOPを用いて機能の正常動作からの逸脱をハザードとして抽出・以下の3点をD-Caseで見える化する - 故障モードの抽出結果 - 故障モードに対する対策 - システムに対する対策の組込み状況安全対策方針・ハザードをFTAのトップゴールに設定・システム構成に基づいてハザードを分解・FTAの末端ノードはガイドワードを用いて故障モードとして抽出 26 / 35 ・故障モードを装置単体で回避できる場合、装置毎のスコープで対策を定義・複数の装置に跨がった対策が必要な場合、装置間共通の方針を定めた上で対策を定義（方針１）走行中における突然のヘッドライト喪失を回避するため、ヘッドライト制御に関する故障検出時には点灯する側で制御する。（方針２）通信に関する途絶・誤り検出時には受信側で方針１に基づいて制御する。安全対策定義 ID. 構成要素故障モード対策 1. ボデー制御ECU 2. IGスイッチ値のワイヤハーネス断線 H/W回路で断線時のIGスイッチ値をオンとするノイズ印加によるIGスイッチ値の逆転 IO-StackでIGスイッチ値のチャタリングを防止する 3. CAN通信線断線ヘッドライト制御ECU側で対応する 4. CAN送信メッセージの値化け COM-Stackで誤り検出符号を付与する：： 7. ヘッドライト制御 8. ECU ：：：： CAN通信線断線 COM-Stackで通信途絶時のIGスイッチ値をオンとする CAN受信メッセージの値化け COM-Stackで誤り検出時のIGスイッチ値をオンとする：：：：手順４：D-Caseを用いた説明手順1：ハザード分析手順2：故障モード抽出手順4：D-Caseで説明する手順3：故障モードの対策定義・システムが提供する機能の特性に応じてHAZOPのガイドワードを決定・HAZOPを用いて機能の正常動作からの逸脱をハザードとして抽出・以下の3点をD-Caseで見える化する - 故障モードの抽出結果 - 故障モードに対する対策 - システムに対する対策の組込み状況・ハザードをFTAのトップゴールに設定・システム構成に基づいてハザードを分解・FTAの末端ノードはガイドワードを用いて故障モードとして抽出 27 / 35 ・故障モードを装置単体で回避できる場合、装置毎のスコープで対策を定義・複数の装置に跨がった対策が必要な場合、装置間共通の方針を定めた上で対策を定義第三者の納得には数多くの情報を適切に構造化して説明できる必要がある第三者が納得するために必要なこと 28 / 35 分析工程の構成要素組込み状況要求工程n 基準A 中間成果工程n+1 最終成果基準B 以下の2点は納得する上で知っておきたい必要条件となるはず •  どのような過程で、どのような判断基準に基づき分析されたか？ •  要求を満足する対策は最終成果に漏れなく組込まれているのか？【D-Caseの有効性】安全分析の全体俯瞰（1/2） 29 / 35 【D-Caseの有効性】安全分析の全体俯瞰（2/2） 30 / 35 【D-Caseの有効性】判断基準の見える化 31 / 35 【D-Caseの有効性】安全対策方針の記述品質の見える化説明のスコープに合わせて具体化されている 32 / 35 【D-Caseの有効性】対策の組込み状況の確認導出した対策組込み状況の確認記録 33 / 35 各種分析手法とD-Caseの役割分担 34 / 35 分析 HAZOP FTA/FMEA 外部内部トレーサビリティ, テスト報告書等 D-Case 凡例確認：仕事の流れ：結果の総括 D-Caseの役割 •  安全分析の過程、結果のつながりを全体俯瞰する •  安全分析に用いた判断基準（ガイドワード、方針等）を見える化する •  故障モードの対策がシステムに組み込まれていることを見える化するまとめ 35 / 35 （現場が抱える問題）上位者の経験が成果物に上手く反映できていない •  前提ノードで見える化された上位者の経験に基づいて成果物の品質を確認できるようになった •  構造化された図表現の特性から表形式では見落としがちな不備（横並び要素の不揃い感等）を検出できるようになった •  成果物の品質推測に活用できる勘所が導出できた今後取り組んでいきたいこと •  新たな技術の導入に対する抵抗感を上回る価値を示したい –  成果物の不備に自分で気づけるようになった –  顧客への成果報告の成功率が高くなった、等々 D-Caseの有効性を開発現場で体感できる経験の場作りにぜひご協力下さい