Copyright© 2017 Information-technology Promotion Agency, Japan. All rights reserved.
SECセミナー＠大阪
2017年3月18日
独立行政法人情報処理推進機構（ＩＰＡ）
技術本部 ソフトウェア高信頼化センター（ＳＥＣ）
松田 充弘
組込みシステム障害の未然防止教訓集と
ノウハウ知識化の紹介
2017年3月18日（土）SECセミナー＠大阪
成功と失敗に学ぶシステム開発
～先進的な取り組みの実践例と過去の教訓～
2
Software Reliability Enhancement Center
Copyright© 2017 Information-technology Promotion Agency, Japan. All rights reserved.
目次
教訓集
設計知識の整理手法ガイド
社会基盤を支えている
ITシステムやIoT機器の信頼性を高めて、
社会経済活動の安定を図ることは、サービス提供企業やメーカーの
責任であり、企業間の垣根を越えて取り組んでゆく必要があります。
IPA/SECでは、2013年度から、重要インフラシステムを中心とし
て、障害事例を収集し、そこから学んだ障害未然防止の対策を製品
ドメインやサービスドメインに依存しない形の「教訓」として広め
てきました。その教訓は「情報処理システム高信頼化教訓集」に編
纂し公開しています。
IPA/SECの委員会活動の中で「教訓集」を編纂している中で、
教訓を具体的な対策に落として伝えるには、豊富な経験によって設
計知識が頭の中に蓄積されているベテラン技術者でなければできな
いことに気付きました。そこで、ベテラン技術者の頭の中に整理さ
れている設計知識を障害事例から抽出して整理する手法を委員会活
動に中で検討してきました。
3
Software Reliability Enhancement Center
Copyright© 2017 Information-technology Promotion Agency, Japan. All rights reserved.
教訓集
背景・概要
教訓集紹介
活用ガイド
教訓化ガイド
4
Software Reliability Enhancement Center
Copyright© 2017 Information-technology Promotion Agency, Japan. All rights reserved.
<出典> 片岡正次郎，鶴田舞，小路泰広：重要インフラ間の相互依存構造のモデル化と地震被害波及シミュ
レーション，国総研資料 第 510 号，国土技術政策総合研究所（国総研），平成21年2月．
http://www.nilim.go.jp/lab/bcg/siryou/tnn/tnn0510.htm
相互依存の事例
（災害時）
背景
インフラシステム間の相互依存
インフラシステ
ムは相互に依存
し，システム間
のネットワーク
連携による
複雑
化
が一層進展
5
Software Reliability Enhancement Center
Copyright© 2017 Information-technology Promotion Agency, Japan. All rights reserved.
△Therac-25による放射線過剰被爆事故（1985～87年）
△エアバスA320の墜落事故（1988～93年）
△名古屋空港で中華航空機が着陸に失敗炎上（1994年）
□首都圏自動改札機トラブル 4,378台に障害発生（
2007
年）
□首都圏窓口処理機トラブル101台に障害発生（
2007
年）
□緑色公衆電話故障
3,207台が機能停止（
2007
年）
△携帯情報端末の発熱－実はソフトの不具合（2009年）
△トルコ航空が着陸前に墜落（2009年）
△日中国浙江省温州市で高速鉄道追突事故（2011年）
△人身事故
□経済事故
過
去
の
事
故
事
例
（
ソ
フ
ト
ウ
ェ
ア
起
因
）
背景
過去の情報処理システムの障害事例
ひとたびシステム障害が発生した場合，
社会に及ぼす影響範囲が拡大し，その深刻度も増大
6
Software Reliability Enhancement Center
Copyright© 2017 Information-technology Promotion Agency, Japan. All rights reserved.
概要
IPA活動
障害事例 共有分析 教訓化
IPA WEBにて公開中
製品・制御システム高信頼化部会
重要インフラITサービス高信頼化部会
提供
教訓化
障害事例
情報処理システム高信頼化教訓集
（ITサービス編／製品・制御システム編）
【参画企業等】 トヨタ自動車（株）、日産自動車（株） 日本電気（株）、 （株）日立製作所 三菱電機（株）、横河電機（株） 富士電機（株）、矢崎総業（株） アイシン精機（株） 日本電気通信システム（株） （株）日立産業制御ソリューションズ 三菱電機メカトロニクスソフトウェア（株） （株）富士通コンピュータテクノロジーズ オムロンソーシアルソリューションズ（株） アイシン・コムクルーズ（株） パイオニアシステムテクノロジー（株） 北陸先端科学技術大学院大学 九州大学、岡山県立大学 （一社）組込みシステム技術協会 （一社）電子情報技術産業協会 【参画企業等】 （株）三菱東京UFJ銀行 日本生命保険相互会社 東京海上日動火災保険（株） （株）日本取引所グループ 東京電力（株） 東日本旅客鉄道（株） KDDI（株） （株）情報システム総研 （株）オリジネィション 日本大学 内閣官房情報通信技術総合戦略室 （一社）日本情報システム・ユーザー協会製品・制御
システム編
ITサービス編
障害事例
7
Software Reliability Enhancement Center
Copyright© 2017 Information-technology Promotion Agency, Japan. All rights reserved.
8
Software Reliability Enhancement Center
Copyright© 2017 Information-technology Promotion Agency, Japan. All rights reserved.
教訓集紹介
情報処理システム高信頼化教訓集
（製品・制御システム編） 2015年度版
2016年3月31日
IPA・ソフトウェア高信頼化セン
ターWEBに公開中。
PART Ⅰ 教訓集（本編）
PART Ⅱ 障害対策手法・事例集
PART Ⅲ 障害分析手法・事例集
PART Ⅳ 障害分析手法事例解説書
9
Software Reliability Enhancement Center
Copyright© 2017 Information-technology Promotion Agency, Japan. All rights reserved.
教訓番号 教訓タイトル 1 複雑な条件式のロジック変更を行う場合は、デシジョンテーブル等による検証が有効である ○ ○ 2 条件が整理されていない状態で、トータルの条件数が100を超えるような機能、または10個以上の条 件を有する機能を修正する場合、関連する条件を全て洗い出して整理し不整合がないことを確認す る ○ ○ 3 複数機能モジュールを統合する場合、統合前の条件数の総和と統合後の条件数を比較し差がある場合は、条件の抜けがないか確認する。 ○ ○ 4 変数値域が広く、組合せバリエーションが非常に多くなる場合には、値域を適切な大きさに分割した上で境界値テストを実施する ○ 5 内蔵電池を使用する場合には、深放電時の起動シーケンスを考慮すること ○ ○ ○ ○ ○ 6 フラッシュメモリを使用する場合には、書き込み寿命回数を考慮すること ○ ○ ○ ○ 7 消費電力の多い機能を追加する場合には、一時的な電圧降下による影響（リセット、フリーズ等）や電源の種類、電池の場合は残量を考慮すること ○ 8 想定可能な例外を形式的に漏れなく分析する ○ ○ 9 システムを二重化する場合は、同期すべきデータ領域を適切に設定する ○ 10 制御対象のハードウェアが同一でも、運用条件が変わるときは、ハードウェア仕様を再確認する ○ ○ ○ ○ 11 プロセス間、スレッド間でデータを共有（引き渡し）する場合は、排他・同期処理が正しく行われているか、あるいはデッドロックが発生していないかどうか注意する ○ ○ ○ 12 歩留りのある製品の良品／不良品を検査する装置では、全てが良品あるいは、不良品との検査結果は異常と判断すべきである ○ ○ 13 既存ソフトウェアの性能改善を実施する際には、アイドリングタイムの発生、処理の同期ずれの発生等と影響を確認する ○ ○ ○ ○ ○ 14 ・大量のデータを通信経由で扱う場合、一連の処理の流れの中にボトルネックを作りこまないように 注意する ・時間帯による負荷変動について考慮する ○ ○ ○ ○ 15 納入したあと、お客様が運用するような業務システムでは、業務シーケンス中のあらゆる異常操作（リセット、電源断、放置も含め）、への対応を考える ○ ○ 16 障害解析時の保守メンテ用ログ処理であっても、仕様書を作成し、影響評価を実施すること ○ 17 判断処理は、必要条件だけでなく、制限すべき条件も漏れなく抽出する ○ 18 ログファイルの断片化に注意する ○ シ ス テ ム テ ス ト 教 育 プ ロ ジ ェ ク ト マ ネ ジ メ ン ト 運 用 シ ス テ ム 要 求 定 義 シ ス テ ム ア ー キ テ ク チ ャ 設 計 ソ フ ト ウ ェ ア ア ー キ テ ク チ ャ 設 計 ソ フ ト ウ ェ ア ア ー キ テ ク チ ャ 設 計 （ 変 更 設 計 ） 実 装 （ コ ー デ ィ ン グ ） レ ビ ュ ー
201５年度版（35件）
教訓一覧（製品・制御システム）
10
Software Reliability Enhancement Center
Copyright© 2017 Information-technology Promotion Agency, Japan. All rights reserved.
教訓一覧（製品・制御システム）
教訓番 号 教訓タイトル 1 複雑な条件式のロジック変更を行う場合は、デシジョンテーブル 等による検証が有効である ○ ○ 2 条件が整理されていない状態で、トータルの条件数が100を超え るような機能、または10個以上の条件を有する機能を修正する場 合、関連する条件を全て洗い出して整理し不整合がないことを確 認する ○ ○ 3 複数機能モジュールを統合する場合、統合前の条件数の総和と 統合後の条件数を比較し差がある場合は、条件の抜けがないか 確認する。 ○ ○ 4 変数値域が広く、組合せバリエーションが非常に多くなる場合に は、値域を適切な大きさに分割した上で境界値テストを実施する ○ 5 内蔵電池を使用する場合には、深放電時の起動シーケンスを考 慮すること ○ ○ ○ ○ ○ 6 フラッシュメモリを使用する場合には、書き込み寿命回数を考慮すること ○ ○ ○ ○ 7 消費電力の多い機能を追加する場合には、一時的な電圧降下に よる影響（リセット、フリーズ等）や電源の種類、電池の場合は残 量を考慮すること ○ 8 想定可能な例外を形式的に漏れなく分析する ○ ○ 9 システムを二重化する場合は、同期すべきデータ領域を適切に 設定する ○ 10 制御対象のハードウェアが同一でも、運用条件が変わるときは、 ハードウェア仕様を再確認する ○ ○ ○ ○ 11 プロセス間、スレッド間でデータを共有（引き渡し）する場合は、排 他・同期処理が正しく行われているか、あるいはデッドロックが発 生していないかどうか注意する ○ ○ ○ 12 歩留りのある製品の良品／不良品を検査する装置では、全てが 良品あるいは、不良品との検査結果は異常と判断すべきである ○ ○ 13 既存ソフトウェアの性能改善を実施する際には、アイドリングタイ ムの発生、処理の同期ずれの発生等と影響を確認する ○ ○ ○ ○ ○ 14 ・大量のデータを通信経由で扱う場合、一連の処理の流れの中 にボトルネックを作りこまないように注意する ・時間帯による負荷変動について考慮する ○ ○ ○ ○ 15 納入したあと、お客様が運用するような業務システムでは、業務 シーケンス中のあらゆる異常操作（リセット、電源断、放置も含 め）、への対応を考える ○ ○ 16 障害解析時の保守メンテ用ログ処理であっても、仕様書を作成 し、影響評価を実施すること ○ 17 判断処理は、必要条件だけでなく、制限すべき条件も漏れなく抽出する ○ 18 ログファイルの断片化に注意する ○ 19 人による変更作業ではミスが起きることを前提に、ツール活用などで不具合の作り込みや流出の防止に心がける ○ ○ ○ 20 信頼性向上施策を採る場合は、故障発生確率と影響の定量評価を行い、対策は確実に実装する ○ ○ ○ ○ 21 高い信頼性対策が求められるシステムでは重大な影響を及ぼす事象の想定と復旧手順を十分に検討する ○ ○ 22 処理時間がクリティカルなシステムではツールを活用し、変数や その取りうる状態数とそれぞれの状況における動作処理に最大 バラツキを意識し余裕を把握し設計する。 ○ ○ ○ ○ ○ 23 開発を伴わない保守案件でも，システム構成変更が発生する場 合は，手順等作業内容の妥当性を確認できるようなプロセスを経 る ○ ○ ○ ○ 24 物理量（時間、重量など）を扱う場合は単位、桁数を確認する。 ○ ○ ○ 25 顧客が要求していることの目的と背景に遡って、その意図を確認することが、要求仕様のあいまいさ排除に役立つ ○ ○ 26 遠隔地等物理的に離れた装置をネットワーク接続して稼働させる システムでは、故障などの状態検知やメンテナンスも容易ではな いため、システム的視点での状態把握を行う。 ○ ○ ○ 27 マルチベンダーシステムでは仕様に外れた想定外事象が発生することを前提とした自己防衛策を採る。 ○ ○ ○ 28 データベース等COTS製品のバージョン、動作仕様の相違等の情 報が関係者にタイムリーに参照できるようにする ○ ○ ○ ○ シ ス テ ム テ ス ト 教 育 プ ロ ジ ェ ク ト マ ネ ジ メ ン ト 運 用 シ ス テ ム 要 求 定 義 シ ス テ ム ア ー キ テ ク チ ャ 設 計 ソ フ ト ウ ェ ア ア ー キ テ ク チ ャ 設 計 ソ フ ト ウ ェ ア ア ー キ テ ク チ ャ 設 計 （ 変 更 設 計 ） 実 装 （ コ ー デ ィ ン グ ） レ ビ ュ ー 教訓番 号 教訓タイトル 1 複雑な条件式のロジック変更を行う場合は、デシジョンテーブル 等による検証が有効である ○ ○ 2 条件が整理されていない状態で、トータルの条件数が100を超え るような機能、または10個以上の条件を有する機能を修正する場 合、関連する条件を全て洗い出して整理し不整合がないことを確 認する ○ ○ 3 複数機能モジュールを統合する場合、統合前の条件数の総和と 統合後の条件数を比較し差がある場合は、条件の抜けがないか 確認する。 ○ ○ 4 変数値域が広く、組合せバリエーションが非常に多くなる場合に は、値域を適切な大きさに分割した上で境界値テストを実施する ○ 5 内蔵電池を使用する場合には、深放電時の起動シーケンスを考 慮すること ○ ○ ○ ○ ○ 6 フラッシュメモリを使用する場合には、書き込み寿命回数を考慮すること ○ ○ ○ ○ 7 消費電力の多い機能を追加する場合には、一時的な電圧降下に よる影響（リセット、フリーズ等）や電源の種類、電池の場合は残 量を考慮すること ○ 8 想定可能な例外を形式的に漏れなく分析する ○ ○ 9 システムを二重化する場合は、同期すべきデータ領域を適切に 設定する ○ 10 制御対象のハードウェアが同一でも、運用条件が変わるときは、ハードウェア仕様を再確認する ○ ○ ○ ○ 11 プロセス間、スレッド間でデータを共有（引き渡し）する場合は、排 他・同期処理が正しく行われているか、あるいはデッドロックが発 生していないかどうか注意する ○ ○ ○ 12 歩留りのある製品の良品／不良品を検査する装置では、全てが 良品あるいは、不良品との検査結果は異常と判断すべきである ○ ○ 13 既存ソフトウェアの性能改善を実施する際には、アイドリングタイ ムの発生、処理の同期ずれの発生等と影響を確認する ○ ○ ○ ○ ○ 14 ・大量のデータを通信経由で扱う場合、一連の処理の流れの中 にボトルネックを作りこまないように注意する ・時間帯による負荷変動について考慮する ○ ○ ○ ○ 15 納入したあと、お客様が運用するような業務システムでは、業務 シーケンス中のあらゆる異常操作（リセット、電源断、放置も含 め）、への対応を考える ○ ○ 16 障害解析時の保守メンテ用ログ処理であっても、仕様書を作成 し、影響評価を実施すること ○ 17 判断処理は、必要条件だけでなく、制限すべき条件も漏れなく抽出する ○ 18 ログファイルの断片化に注意する ○ 19 人による変更作業ではミスが起きることを前提に、ツール活用などで不具合の作り込みや流出の防止に心がける ○ ○ ○ 20 信頼性向上施策を採る場合は、故障発生確率と影響の定量評価を行い、対策は確実に実装する ○ ○ ○ ○ 21 高い信頼性対策が求められるシステムでは重大な影響を及ぼす事象の想定と復旧手順を十分に検討する ○ ○ 22 処理時間がクリティカルなシステムではツールを活用し、変数や その取りうる状態数とそれぞれの状況における動作処理に最大 バラツキを意識し余裕を把握し設計する。 ○ ○ ○ ○ ○ 23 開発を伴わない保守案件でも，システム構成変更が発生する場 合は，手順等作業内容の妥当性を確認できるようなプロセスを経 る ○ ○ ○ ○ 24 物理量（時間、重量など）を扱う場合は単位、桁数を確認する。 ○ ○ ○ 25 顧客が要求していることの目的と背景に遡って、その意図を確認することが、要求仕様のあいまいさ排除に役立つ ○ ○ 26 遠隔地等物理的に離れた装置をネットワーク接続して稼働させる システムでは、故障などの状態検知やメンテナンスも容易ではな いため、システム的視点での状態把握を行う。 ○ ○ ○ 27 マルチベンダーシステムでは仕様に外れた想定外事象が発生することを前提とした自己防衛策を採る。 ○ ○ ○ 28 データベース等COTS製品のバージョン、動作仕様の相違等の情 報が関係者にタイムリーに参照できるようにする ○ ○ ○ ○ シ ス テ ム テ ス ト 教 育 プ ロ ジ ェ ク ト マ ネ ジ メ ン ト 運 用 シ ス テ ム 要 求 定 義 シ ス テ ム ア ー キ テ ク チ ャ 設 計 ソ フ ト ウ ェ ア ア ー キ テ ク チ ャ 設 計 ソ フ ト ウ ェ ア ア ー キ テ ク チ ャ 設 計 （ 変 更 設 計 ） 実 装 （ コ ー デ ィ ン グ ） レ ビ ュ ー11
Software Reliability Enhancement Center
Copyright© 2017 Information-technology Promotion Agency, Japan. All rights reserved.
教訓番号
教訓タイトル
1
複雑な条件式のロジック変更を行う場合は、デシジョンテーブル等による検証が有効である
○
○
2
条件が整理されていない状態で、トータルの条件数が100を超えるような機能、または10個以上の条
件を有する機能を修正する場合、関連する条件を全て洗い出して整理し不整合がないことを確認す
る
○
○
3
複数機能モジュールを統合する場合、統合前の条件数の総和と統合後の条件数を比較し差がある
場合は、条件の抜けがないか確認する。
○
○
4
変数値域が広く、組合せバリエーションが非常に多くなる場合には、値域を適切な大きさに分割した
上で境界値テストを実施する
○
5
内蔵電池を使用する場合には、深放電時の起動シーケンスを考慮すること
○
○
○
○
○
6
フラッシュメモリを使用する場合には、書き込み寿命回数を考慮すること
○
○
○
○
7
消費電力の多い機能を追加する場合には、一時的な電圧降下による影響（リセット、フリーズ等）や
電源の種類、電池の場合は残量を考慮すること
○
8
想定可能な例外を形式的に漏れなく分析する
○
○
9
システムを二重化する場合は、同期すべきデータ領域を適切に設定する
○
10
制御対象のハードウェアが同一でも、運用条件が変わるときは、ハードウェア仕様を再確認する
○
○
○
○
11
プロセス間、スレッド間でデータを共有（引き渡し）する場合は、排他・同期処理が正しく行われている
か、あるいはデッドロックが発生していないかどうか注意する
○
○
○
12
歩留りのある製品の良品／不良品を検査する装置では、全てが良品あるいは、不良品との検査結果
は異常と判断すべきである
○
○
13
既存ソフトウェアの性能改善を実施する際には、アイドリングタイムの発生、処理の同期ずれの発生
等と影響を確認する
○
○
○
○
○
14
・大量のデータを通信経由で扱う場合、一連の処理の流れの中にボトルネックを作りこまないように
注意する
・時間帯による負荷変動について考慮する
○
○
○
○
15
納入したあと、お客様が運用するような業務システムでは、業務シーケンス中のあらゆる異常操作（リ
セット、電源断、放置も含め）、への対応を考える
○
○
16
障害解析時の保守メンテ用ログ処理であっても、仕様書を作成し、影響評価を実施すること
○
17
判断処理は、必要条件だけでなく、制限すべき条件も漏れなく抽出する
○
18
ログファイルの断片化に注意する
○
シ
ス
テ
ム
テ
ス
ト
教
育
プ
ロ
ジ
ェ
ク
ト
マ
ネ
ジ
メ
ン
ト
運
用
シ
ス
テ
ム
要
求
定
義
シ
ス
テ
ム
ア
ー
キ
テ
ク
チ
ャ
設
計
ソ
フ
ト
ウ
ェ
ア
ア
ー
キ
テ
ク
チ
ャ
設
計
ソ
フ
ト
ウ
ェ
ア
ア
ー
キ
テ
ク
チ
ャ
設
計
（
変
更
設
計
）
実
装
（
コ
ー
デ
ィ
ン
グ
）
レ
ビ
ュ
ー
教訓を適用させる工程
教訓一覧（製品・制御システム）
12
Software Reliability Enhancement Center
Copyright© 2017 Information-technology Promotion Agency, Japan. All rights reserved.
教訓番号
教訓タイトル
1
複雑な条件式のロジック変更を行う場合は、デシジョンテーブル等による検証が有効である
○
○
2
条件が整理されていない状態で、トータルの条件数が100を超えるような機能、または10個以上の条
件を有する機能を修正する場合、関連する条件を全て洗い出して整理し不整合がないことを確認す
る
○
○
3
複数機能モジュールを統合する場合、統合前の条件数の総和と統合後の条件数を比較し差がある
場合は、条件の抜けがないか確認する。
○
○
4
変数値域が広く、組合せバリエーションが非常に多くなる場合には、値域を適切な大きさに分割した
上で境界値テストを実施する
○
5
内蔵電池を使用する場合には、深放電時の起動シーケンスを考慮すること
○
○
○
○
○
6
フラッシュメモリを使用する場合には、書き込み寿命回数を考慮すること
○
○
○
○
7
消費電力の多い機能を追加する場合には、一時的な電圧降下による影響（リセット、フリーズ等）や
電源の種類、電池の場合は残量を考慮すること
○
8
想定可能な例外を形式的に漏れなく分析する
○
○
9
システムを二重化する場合は、同期すべきデータ領域を適切に設定する
○
10
制御対象のハードウェアが同一でも、運用条件が変わるときは、ハードウェア仕様を再確認する
○
○
○
○
11
プロセス間、スレッド間でデータを共有（引き渡し）する場合は、排他・同期処理が正しく行われている
か、あるいはデッドロックが発生していないかどうか注意する
○
○
○
12
歩留りのある製品の良品／不良品を検査する装置では、全てが良品あるいは、不良品との検査結果
は異常と判断すべきである
○
○
13
既存ソフトウェアの性能改善を実施する際には、アイドリングタイムの発生、処理の同期ずれの発生
等と影響を確認する
○
○
○
○
○
14
・大量のデータを通信経由で扱う場合、一連の処理の流れの中にボトルネックを作りこまないように
注意する
・時間帯による負荷変動について考慮する
○
○
○
○
15
納入したあと、お客様が運用するような業務システムでは、業務シーケンス中のあらゆる異常操作（リ
セット、電源断、放置も含め）、への対応を考える
○
○
16
障害解析時の保守メンテ用ログ処理であっても、仕様書を作成し、影響評価を実施すること
○
17
判断処理は、必要条件だけでなく、制限すべき条件も漏れなく抽出する
○
18
ログファイルの断片化に注意する
○
シ
ス
テ
ム
テ
ス
ト
教
育
プ
ロ
ジ
ェ
ク
ト
マ
ネ
ジ
メ
ン
ト
運
用
シ
ス
テ
ム
要
求
定
義
シ
ス
テ
ム
ア
ー
キ
テ
ク
チ
ャ
設
計
ソ
フ
ト
ウ
ェ
ア
ア
ー
キ
テ
ク
チ
ャ
設
計
ソ
フ
ト
ウ
ェ
ア
ア
ー
キ
テ
ク
チ
ャ
設
計
（
変
更
設
計
）
実
装
（
コ
ー
デ
ィ
ン
グ
）
レ
ビ
ュ
ー
教訓一覧（製品・制御システム）
教訓番号
教訓タイトル
1
複雑な条件式のロジック変更を行う場合は、デシジョンテーブル等による検証が有効である
○
○
2
条件が整理されていない状態で、トータルの条件数が100を超えるような機能、または10個以上の条
件を有する機能を修正する場合、関連する条件を全て洗い出して整理し不整合がないことを確認す
る
○
○
3
複数機能モジュールを統合する場合、統合前の条件数の総和と統合後の条件数を比較し差がある
場合は、条件の抜けがないか確認する。
○
○
4
変数値域が広く、組合せバリエーションが非常に多くなる場合には、値域を適切な大きさに分割した
上で境界値テストを実施する
○
5
内蔵電池を使用する場合には、深放電時の起動シーケンスを考慮すること
○
○
○
○
○
6
フラッシュメモリを使用する場合には、書き込み寿命回数を考慮すること
○
○
○
○
7
消費電力の多い機能を追加する場合には、一時的な電圧降下による影響（リセット、フリーズ等）や
電源の種類、電池の場合は残量を考慮すること
○
8
想定可能な例外を形式的に漏れなく分析する
○
○
9
システムを二重化する場合は、同期すべきデータ領域を適切に設定する
○
10
制御対象のハードウェアが同一でも、運用条件が変わるときは、ハードウェア仕様を再確認する
○
○
○
○
11
プロセス間、スレッド間でデータを共有（引き渡し）する場合は、排他・同期処理が正しく行われている
か、あるいはデッドロックが発生していないかどうか注意する
○
○
○
12
歩留りのある製品の良品／不良品を検査する装置では、全てが良品あるいは、不良品との検査結果
は異常と判断すべきである
○
○
13
既存ソフトウェアの性能改善を実施する際には、アイドリングタイムの発生、処理の同期ずれの発生
等と影響を確認する
○
○
○
○
○
14
・大量のデータを通信経由で扱う場合、一連の処理の流れの中にボトルネックを作りこまないように
注意する
・時間帯による負荷変動について考慮する
○
○
○
○
15
納入したあと、お客様が運用するような業務システムでは、業務シーケンス中のあらゆる異常操作（リ
セット、電源断、放置も含め）、への対応を考える
○
○
16
障害解析時の保守メンテ用ログ処理であっても、仕様書を作成し、影響評価を実施すること
○
17
判断処理は、必要条件だけでなく、制限すべき条件も漏れなく抽出する
○
18
ログファイルの断片化に注意する
○
シ
ス
テ
ム
テ
ス
ト
教
育
プ
ロ
ジ
ェ
ク
ト
マ
ネ
ジ
メ
ン
ト
運
用
シ
ス
テ
ム
要
求
定
義
シ
ス
テ
ム
ア
ー
キ
テ
ク
チ
ャ
設
計
ソ
フ
ト
ウ
ェ
ア
ア
ー
キ
テ
ク
チ
ャ
設
計
ソ
フ
ト
ウ
ェ
ア
ア
ー
キ
テ
ク
チ
ャ
設
計
（
変
更
設
計
）
実
装
（
コ
ー
デ
ィ
ン
グ
）
レ
ビ
ュ
ー
13
Software Reliability Enhancement Center
Copyright© 2017 Information-technology Promotion Agency, Japan. All rights reserved.
未然防止知識事例（その１） 教訓１２
歩留りのある製品の良品／不良品を検査する装置では、全てが良品
あるいは、不良品との検査結果は異常と判断すべきである
教訓
・半導体がスペック通りの機能・性能を満た
しているかを検査する装置。
・半導体の検査は複数のテストで構成され、
その全てのテストが良の場合は検査結果が
良品となる。一方で、あるテストで不良に
なった場合は不良品と判断され、検査時間
の効率化のため、通常その後のテストは行
わない。
・検査機能をマスクできるモードがある。
製品の特長
14
Software Reliability Enhancement Center
Copyright© 2017 Information-technology Promotion Agency, Japan. All rights reserved.
未然防止知識事例（その１）
内部の事象
①調査担当者が調査のため、不良にならないようにマスク設定した。
⇒調査終了後は、マスク解除しなければならないが、調査担当者がマスク設定を解除しな
い状態で放置。
②そのまま量産を開始。⇒検査は全て良品となった。
観察できる現象
半導体の検査では、一定の割合で不良品が発生するが、検査した全てが良品となっ
た。しかし、その後の検査の工程で通常より多くの不良品が検出された。
検査結果：
不良個数=0
15
Software Reliability Enhancement Center
Copyright© 2017 Information-technology Promotion Agency, Japan. All rights reserved.
未然防止知識事例（その１）
対処
全て不良品の場合と同様に、全て良品の場合も異常を通知す
るよう修正した。
原因
・全て良品となった場合には、異常の可能性があるとみなして
いなかった。
・全て不良品の場合は直感的に検査が異常であるとわかるが、
全て良品の場合にも検査が異常であると考えが及ばなかった。
未然防止の対策
①良／不良の条件に関わる仕様を明確にする。
②検査装置の検証項目に加え、できるだけ検証を自動化
する。
検査結果：
不良個数=0
異常
16
Software Reliability Enhancement Center
Copyright© 2017 Information-technology Promotion Agency, Japan. All rights reserved.
未然防止知識事例（その２） 教訓１５
お客様が運用する業務システムでは、業務シーケンス中のあら
ゆる異常操作（リセット、電源断、放置も含め）、への対応を考え
る
教訓
店舗用窓口対応業務装置で、日次の業務処理に必要な
データを受信したり、当日行った処理の集計データを所定
の時間にセンターサーバに送信したりするバッチ処理が自
動的に実行されることになっている。
製品の特長
観察できる現象
①ある日、窓口対応員が当該装置の電源をOFFにして帰宅。
②翌朝窓口対応業務を行おうとしたところ、業務システムが正常に立ち上がらず。
⇒ 店舗業務運営ができない状態が発生。
17
Software Reliability Enhancement Center
Copyright© 2017 Information-technology Promotion Agency, Japan. All rights reserved.
未然防止知識事例（その２）
内部の事象
業務処理集計データの送信状態が未完了状態であったため、装置システムが正
常に起動しない。
対処
センターサーバとの送受信処理中に強制終了された場合の再送、再開時処理を実
装する。
原因
昨日の業務処理集計データをセンターサーバに送信中にバッチ処理を強制された
ためデータ送信処理が未完了状態になったことが直接原因であることがわかった。
本来、送受信中に強制終了されたとしても、次回再開した際に送信未終了分を再送
する等のリカバリ処理が実施されるべきであったが、そうした事態が想定されておら
ず、リカバリ機能が未実装だった。
18
Software Reliability Enhancement Center
Copyright© 2017 Information-technology Promotion Agency, Japan. All rights reserved.
未然防止知識事例（その２）
未然防止の対策
要件定義
19
Software Reliability Enhancement Center
Copyright© 2017 Information-technology Promotion Agency, Japan. All rights reserved.
活用ガイド
目的
教訓集を実際の開発プロセスや社内教育など開発現場におい
てどのように活用することができるか、その具体的な活用法を
解説したものである。
構成
２章 教訓集の構成と特徴
３章 組織学習のための基礎
４章 基本的な活用方法
５章 企業内での活動事例
現場で役立つ教訓活用のための実践ガイドブック
20
Software Reliability Enhancement Center
Copyright© 2017 Information-technology Promotion Agency, Japan. All rights reserved.
教訓化ガイド
目的
実際の開発現場において再発防止策からどのように未然防止の
教訓を導出してゆけばよいか、組織活動としていかに定着させて
ゆけばよいかを実践する際のガイドとして作成したものである。
構成
２章 教訓化ための概念モデル
３章 教訓活用に向けた組織活動とプロセス
４章 実践的アプローチ
５章 未然防止に向けた企業内事例
障害未然防止のための教訓化ガイドブック
21
Software Reliability Enhancement Center
Copyright© 2017 Information-technology Promotion Agency, Japan. All rights reserved.
設計知識の整理手法ガイド
背景と目的
設計知識の整理手順（概要）
設計知識のデータベース化
設計知識の活用シーン
設計知識として伝えたい事
設計知識の文脈と構造
設計知識抽出のポイント
設計知識の再利用モデル
22
Software Reliability Enhancement Center
Copyright© 2017 Information-technology Promotion Agency, Japan. All rights reserved.
背景と目的（１）
過去トラブル情報 蓄積倉庫
書
架
#3
書
架
#2
書
架
#1
2005年度
ソフトウェア
障害情報
【実態】
過去トラデータが蓄積される
一方、活用されていない。
過去トラDB
システムトラブル、ソフトウェアトラブル
再発防止・未然防止のために
[A社]
23
Software Reliability Enhancement Center
Copyright© 2017 Information-technology Promotion Agency, Japan. All rights reserved.
知識は
経験者個人の頭の中にあるもので、
伝承させるために
整理して形にする
ことが必要。
背景と目的（２）
2005年度
ソフトウェア
障害情報
再発・未然防止知識
【実態】
症状・原因・対処が具体的に記録
されているが、知識として整理さ
れていない。
過去トラDB
症状
・
原因
・
対処
24
Software Reliability Enhancement Center
Copyright© 2017 Information-technology Promotion Agency, Japan. All rights reserved.
分類タグ
設計知識の整理手順（概要）
キーワード
③一般化
④
抽出
分類情報
設計知識
過去トラDB
障害記録
①抽出
設計
知識
②構造化
①「過去トラDB」の障害情報記録から設計知識を抽出する
②抽出した設計知識を構造化する
③さらに設計知識を一般化表現に変換する
④設計知識の再利用を促すための分類タグを抽出する
25
Software Reliability Enhancement Center
Copyright© 2017 Information-technology Promotion Agency, Japan. All rights reserved.
障害を未然に防止
する設計知識DB
分類
タグ
過去トラDB
障害情報記録 #1
・症状
・原因
・対処
障害情報記録 #2
・症状
・原因
・対処
分類
タグ
分類
タグ
参照
参照
●
●
●
●
●
●
一般化・構造化
設 計 知 識
設 計 知 識
設 計 知 識
設計知識のデータベース化
障害を未然に防止するための設計知識DB
26
Software Reliability Enhancement Center
Copyright© 2017 Information-technology Promotion Agency, Japan. All rights reserved.
設計知識の活用シーン（１）
障害未然防止のための
設計知識DB
設計
設計レ
ビュー
テストケー
ス作成
障害対策
プロジェク
ト計画
各フェーズの共通知識として利用
ソフトウェア開発の様々なフェーズの共通知識として利用
27
Software Reliability Enhancement Center
Copyright© 2017 Information-technology Promotion Agency, Japan. All rights reserved.
設計知識の活用シーン（２）
家電ソフト
ウェア開発
技術者
通信機器ソ
フトウェア
開発技術者
車載機器ソ
フトウェア
開発技術者
医療・ヘル
ス機器ソフ
トウェア開
発技術者
障害未然防止のための
設計知識DB
○○ソフト
ウェア開発
技術者
製品ドメイン共通に利用
製品ドメインに依存しない共通の設計知識として利用
28
Software Reliability Enhancement Center
Copyright© 2017 Information-technology Promotion Agency, Japan. All rights reserved.
設計知識として伝えたい事（１）
障害を引き起こした直
接原因を突き止める
対処内容
対処内容を検討する
対処する
プログラムコード
（○○機能・□□処理）
対処箇所
障害発生
直接原因への対処
29
Software Reliability Enhancement Center
Copyright© 2017 Information-technology Promotion Agency, Japan. All rights reserved.
プログラムコード
（○○機能・□□処理）
考慮が漏れた
設計視点・観点
実行開始
終了
発生契機
問題を引き起こす
トリガー
障害発生
①
②
③
設計知識として伝えたい事（２）
① 問題を引き起こす可能性の
ある事象に関して、考慮が必
要な設計視点・観点が漏れ
たままプログラムコードを作
成し実装する。
② 障害を引き起こすトリガー
がかかる。
③ 障害が発生する。
考慮漏れに起因する障害発生のシナリオ
30
Software Reliability Enhancement Center
Copyright© 2017 Information-technology Promotion Agency, Japan. All rights reserved.
設計知識の文脈と構造（１）
設計知識の文脈：
「○○○の機能や処理を考えるときに、
▽▽▽の考慮が漏れていると、
△△△が起こった契機で◇◇◇◇の障害が発生する。
その障害の発生を防ぐためには□□□□の処理を作り込んでおく。」
設計知識の知識要素を文脈にする
31
Software Reliability Enhancement Center
Copyright© 2017 Information-technology Promotion Agency, Japan. All rights reserved.
設計知識をパターン化して頭の中に整理し易くする
知識要素(1)～(4)は、不具合を混入させて障害が発生するシナリオの構成要素を表す。
知識要素(5)は、(1)～(4)の要素を文章に組み立てた「何が」、「どうして」、「どうなる」を表す。
知識要素(6)は対策を表す。※(5)と(6)は文章で簡潔に説明する。
設計知識の文脈と構造（２）
設計知識を構造化する
32
Software Reliability Enhancement Center
Copyright© 2017 Information-technology Promotion Agency, Japan. All rights reserved.
設計知識 抽出のポイント
「過去トラDB」の障害情報記録から「考慮不足」、「考慮漏れ」、「知
識不足」に起因する事例を探し出す。
ただし、たいていの障害情報記録は、障害を引き起こしたプログ
ラムコードの事実とそれをどのように修正したのかの内容が淡々と
記載されただけで、何故そのようなプログラムコードになってしまっ
たかの背景（なぜ対応しなかったか、なぜ間違ったのか等）が記載
されていない。
一般に技術者は、自責を感じる原因でも仕様書不備等の問題とし
て障害情報に記録する場合があるため、背景に「考慮不足」、「考
慮漏れ」、「知識不足」の要因が含まれていても、それを判断するこ
とが難しい
過去トラDBから設計知識を抽出できるか？
33
Software Reliability Enhancement Center
Copyright© 2017 Information-technology Promotion Agency, Japan. All rights reserved.
（１）考慮漏れ要因の調査
障害情報記録の状況（症状）、直接原因、対処から障害発生シナリオ「何が」「どうして」「どう
なった」の文脈を捉える。
捉えた文脈の「どうして」の背景要因に設計時の考慮漏れ、考慮不足、知識不足は無かったかど
うかを、次のガイドに従って調べる。
【ガイド１】
経験を積んだベテラン技術者であれば、その障害を未然に防止できたかどうか考え
てみる。ベテラン技術者は仕様書等に明示されていなくても、経験によって必要な
対策を施すことができる。
設計知識の抽出方法
設計知識 抽出のポイント
34
Software Reliability Enhancement Center
Copyright© 2017 Information-technology Promotion Agency, Japan. All rights reserved.
設計知識 抽出のポイント
(3)【発生契機】(例) ノイズ
(2)【考慮漏れし易い設計視点・観点】(例)
想定していない例外割り込み発生時の
考慮漏れ
(4)【発生し得るトラブル内容】(例)
機能実行中に例外割り込みが発生する
ことでシステム異常・停止等の障害を引
き起こす
(5)【発生メカニズム】（例）
割り込み要求端子にノイズが入力する
と、不定な値を使用して割り込み処理が
起動される場合ある。その際、割り込み
処理プログラムに、不正な割り込みを想
定したコーディングがなされていなけれ
ば、システム障害が発生する。
(6)【対策】（例）
割り込み処理起動時に正常割り込みで
あるかを判断し、不正な割り込みであれ
ば何もせずに割り込みプログラムを終
了させる。
(1)【トラブルを引き起こす機能・処理】(例)
割り込み処理
(1)
障害を引き
起こす
機能・処理
(2)
考慮漏れし
易い設計
視点・観点
(3)
発生契機
(4)
発生し得る
障害内容
(5)
発生メカニ
ズム
(6)
対策
（例）抽出した設計知識
35
Software Reliability Enhancement Center
Copyright© 2017 Information-technology Promotion Agency, Japan. All rights reserved.
設計知識の再利用モデル
設 計 知 識
36
Software Reliability Enhancement Center
Copyright© 2017 Information-technology Promotion Agency, Japan. All rights reserved.
