Comments
Description
Transcript
障害事例情報共有の取組みと 事例分析により得られた教訓
ソフトウエアジャパン2015 「ICTによるイノベーションの創出 ～スマートシティからオリンピック・パラリンピックまで～」 ITフォーラム：IPA/SECセッション 異分野情報活用とイノベーション ～製品・ITサービスの安全・安心のための仕組みと人材～ 障害事例情報共有の取組みと 事例分析により得られた教訓 ～智の共有が安心・安全社会を創る～ 2015年2月3日 独立行政法人情報処理推進機構（ＩＰＡ） 技術本部 ソフトウェア高信頼化センター（ＳＥＣ） 山下 博之 [email protected] Information-technology Promotion Agency, Japan Software Reliability Enhancement Center (SEC) Copyright © 2013-2015 IPA, All Rights Reserved Software Reliability Enhancement Center 内 容 1. 背景 2. IPA/SECの取組み 「重要インフラ等システム障害対策」など 3. これまでの成果概要 ITサービス高信頼化“教訓集” システム障害事例の分析に基づく対策・教訓の共有の仕組み 4. “教訓”の例 5. 今後の取組み 業界を超えた“教訓”共有の仕組みの展開 6. まとめ Copyright © 2013-2015 IPA, All Rights Reserved Software Japan 2015 Software Reliability Enhancement Center 2 １．背景 背景 ソフトウェアは，それ自身，複雑化・大規模化し， システム間連携により，複雑化は一層進展 停止・異常動作等のリスクの増大 ∵ 市民生活や社会経済活動がＩＴシステムに大きく依存 Copyright © 2013-2015 IPA, All Rights Reserved Software Japan 2015 Software Reliability Enhancement Center 3 １．背景 ＩＴ障害を引き起こす脅威（要因） IT障害を引き起こす脅威（要因）としては，意図的要因（情報セキュリ ティ関連）と非意図的要因（システム障害関連），災害等がある． ここでの注目 <出典> NISC: 重要インフラの情報セキュ リティ対策に係る第２次行動計画 Copyright © 2013-2015 IPA, All Rights Reserved Software Japan 2015 Software Reliability Enhancement Center 4 データ例 グローバル・リスク 財政危機 大 ← 重要インフラの ITシステム障害 生物多様性 損失と 生態系崩壊 水危機 気候変動 失業・不完全雇用 受容できないリスク 異常気象 影 響 度 所得格差 サイバー攻撃 影 響 度 リスクの低減 発生確率 受容できるリスク 発生確率 → 大 Copyright © 2013-2015 IPA, All Rights Reserved Software Japan 2015 <出典> Global Risks 2014 Ninth Edition, the World Economic Forum Figure 1.1: The Global Risks Landscape 2014 Software Reliability Enhancement Center 5 データ例 情報処理システム障害の発生状況 社会に大きな影響を与えた システム障害の発生件数 2009年以降で増加傾向 件 多大な影響を与えたITサービス障害の 発生件数（報道ベース）の推移 60 50 新聞やテレビなどのメディアでは， 幾度となく以下のようなニュースが 世間を賑わせている： 40 30 ・△△でリコール、国内で数十万台 …理由は、制御プログラムに不具合が発見された 20 ためという。 10 ・○○システムで障害か、終日つながりにくく …原因は、法律改正直前の駆け込み需要と期末の 0 締め処理とが重なり、想定外の大量入力にシステ ムの性能が耐えられなかった模様。 ・□□システムで障害、午前中のサービス停止 …原因は、システムは本番装置の故障により予備 装置に自動的に切り替わるようになっていたが、 その切替えが失敗したためという。 Copyright © 2013-2015 IPA, All Rights Reserved Software Japan 2015 2007 2008 2009 2010 2011 2012 2013 2014 (出典) SEC Journal 情報システムの障害状況 類似障害の発生 Software Reliability Enhancement Center 6 １．背景 情報処理システムの信頼性向上 システムの 構築時→初期リスク（故障）回避 ソフトウェア・エンジニアリング技法の活用 はるかに長期間 システムの 運用時→様々なリスクに対応 体系的な取組みが必要 着目点は．．． Copyright © 2013-2015 IPA, All Rights Reserved Software Japan 2015 Software Reliability Enhancement Center 7 １．背景 システム運用時に想定されるリスク ＜環境変化＞ 新サービス追加 法制度改正 利用増大(量) 利用形態変化(質) 故 障 率 初期故障期 偶発故障期（安定期） 摩耗故障期 <故障率曲線の原図> "Bathtub curve" by en:User:Wyatts - U.S. Army document. Licensed under Public domain via ウィキメディア・コモンズ http://commons.wikimedia.org/wiki/File:Bathtub_curve.jpg#mediaviewer/File:Bathtub_curve.jpg Copyright © 2013-2015 IPA, All Rights Reserved Software Japan 2015 Software Reliability Enhancement Center 8 １．背景 リスクへの対応 ハードウェアは劣化する→故障 冗長構成，など ソフトウェアは劣化しない ソフトウェアは相対的に劣化する 使われる環境の変化 ビジネス方針，ニーズ 組織・人（慣れによる過信・ 油断，交代による技術/ノ ウハウ継承無し） 利用者増，技術進展，他 リスク要因 Copyright © 2013-2015 IPA, All Rights Reserved Software Japan 2015 教訓の活用 網 羅 的 な 事 前 抽 出 が 困 難 障害事例に基づく 教訓・対策の共有 失敗に学ぶ Software Reliability Enhancement Center 9 ２．IPA/SECの取組み 重要インフラ分野における高信頼化対策（IPA） ◇重要インフラ分野等のシステム障害への対策 経験を共有し、みんなの力でIT社会の安全・安心を築くしくみ 具体的には， 重要インフラ分野*等のシステム障害の事例を分析し，それにより得られた 教訓と対策を整理・体系化した上で，再発防止策を，業界を越えて横断 的に広く共有する仕組みの構築を目指す． http://www.ipa.go.jp/sec/system/index.html * 情報通信，金融，航空，鉄道，電力，ガス，政府・行政サービス，医療，水道，物流，クレジット，石油，化学 Copyright © 2013-2015 IPA, All Rights Reserved Software Japan 2015 Software Reliability Enhancement Center 10 ２．IPA/SECの取組み 情報セキュリティ 教訓共有の取組みの目指す方向 航空 現状（教訓の共有なし） 原子力 金融 障害に基づく教訓の共有による信頼性向上のしくみ 社会 社会 より高い安全・安心な 製品機器/ITサービスの提供 重要インフラ等 重要インフラ等 信 頼 性 信 頼 性 製品機器/ ITサービス (Ａ社) 障害 製品機器/ ITサービス (Ｂ社) 障害 対 策 実 施 教 訓 Ａ 信 頼 性 信 頼 性 製品機器/ ITサービス (Ｃ社) 障害 対 策 実 施 原因分析 対策検討 教 訓 Ｂ 対 策 実 施 原因分析 対策検討 教 訓 Ｃ 原因分析 対策検討 信 頼 性 製品機器/ 製品機器/ 製品機器/ ITサービス ITサービス ITサービス (Ａ社) (Ｂ社) (Ｃ社) 障害 障害 障害 対策実施 対策実施 対策実施 教訓 教訓 教訓 教 訓教 Ａ訓教 Ｂ訓 Ｃ 原因分析・対策検討 一般化・抽象化・普遍化 体系的整理 機密保持等 のルール 専門家，有識者のご協力を得て IPA/SECや業界団体等が担う共有活動 類似障害の発生 Copyright © 2013-2015 IPA, All Rights Reserved 信 頼 性 Software Japan 2015 Software Reliability Enhancement Center 11 ３．これまでの成果概要 IPAにおける事例分析，教訓の共有活動 （実績） 2014年度も継続中 2014年5月13日公開 http://www.ipa.go.jp/about/press/20140513.html ＜特徴＞ ①業界・分野を超えて活用可能な普遍化された教訓。 ②機密保持ルールの下で詳細情報の提供を受けた深い議論。 ③蓄積されたソフトウェア・エンジニアリングに関する知見の活用。 Copyright © 2013-2015 IPA, All Rights Reserved Software Japan 2015 Software Reliability Enhancement Center 12 ３．これまでの成果概要 教訓一覧（製品・制御システム） 教訓番号 1 シ ス テ ム 要 求 定 義 教訓タイトル 複雑な条件式のロジック変更を行う場合は、デシジョンテーブル等による検証が有効である ア ー キ シ テ ス ク テ チ ム ャ 設 計 ア ー ソ キ フ テ ト ク ウ チ ャェ ア 設 計 ア ー （キ ソ 変 フ テ 更 ト ク 設 ウ チ 計 ェ ャ ）設ア 計 ○ ○ ○ ○ （ コ ー デ実 ィ装 ン グ レ ビ ュ ー シ ス テ ム テ ス ト 教 育 マプ ネロ ジジ メェ ン ク ト ト 運 用 ） 条件が整理されていない状態で、トータルの条件数が100を超えるような機能、または10個以上の条 件を有する機能を修正する場合、関連する条件を全て洗い出して整理し不整合がないことを確認す 複雑な条件式のロジッ 2 る ク変更を行う場合は、デ 複数機能モジュールを統合する場合、統合前の条件数の総和と統合後の条件数を比較し差がある 3 場合は、条件の抜けがないか確認する。 シジョンテーブル等によ 変数値域が広く、組合せバリエーションが非常に多くなる場合には、値域を適切な大きさに分割した 4 上で境界値テストを実施する る検証が有効である 5 内蔵電池を使用する場合には、深放電時の起動シーケンスを考慮すること 6 フラッシュメモリを使用する場合には、書き込み寿命回数を考慮すること 7 消費電力の多い機能を追加する場合には、一時的な電圧降下による影響（リセット、フリーズ等）や 電源の種類、電池の場合は残量を考慮すること 8 想定可能な例外を形式的に漏れなく分析する 9 ○ ○ ○ ○ ○ ○ ○ ○ システムを二重化する場合は、同期すべきデータ領域を適切に設定する ○ 制御対象のハードウェアが同一でも、運用条件が変わるときは、ハードウェア仕様を再確認する 歩留りのある製品の良 10 プロセス間、スレッド間でデータを共有（引き渡し）する場合は、排他・同期処理が正しく行われている 品／不良品を検査する 11 か、あるいはデッドロックが発生していないかどうか注意する 装置では、全てが良品 歩留りのある製品の良品／不良品を検査する装置では、全てが良品あるいは、不良品との検査結果 12 は異常と判断すべきである あるいは、不良品との 既存ソフトウェアの性能改善を実施する際には、アイドリングタイムの発生、処理の同期ずれの発生 13 等と影響を確認する 検査結果は異常と判断 ・大量のデータを通信経由で扱う場合、一連の処理の流れの中にボトルネックを作りこまないように 14 すべきである 注意する ・時間帯による負荷変動について考慮する 15 納入したあと、お客様が運用するような業務システムでは、業務シーケンス中のあらゆる異常操作（リ セット、電源断、放置も含め）、への対応を考える 16 障害解析時の保守メンテ用ログ処理であっても、仕様書を作成し、影響評価を実施すること 17 判断処理は、必要条件だけでなく、制限すべき条件も漏れなく抽出する 18 ログファイルの断片化に注意する Copyright © 2013-2015 IPA, All Rights Reserved ○ ○ ○ ○ ○ 消費電力の多い機 ○ ○ ○ 能を追加する場合 ○ ○ には、一時的な電 圧降下による影響 （リセット、フリーズ 等）や電源の種類、 ○ ○ 電池の場合は残 ○ ○ 量を考慮すること ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ Software Japan 2015 Software Reliability Enhancement Center 13 ３．これまでの成果概要 教訓一覧（ITサービス） No 領域 ＩＤ 1 ガバナン ス／マネ ジメント Ｇ１ 2 Ｇ２ 3 Ｔ１ 4 Ｔ２ 5 Ｔ３ 技術 6 Ｔ４ 7 Ｔ５ 8 Ｔ６ 9 Ｔ７ 教訓概要 システム開発を情シス部門だけの仕事にせず、 各事業部門が自分のこととして捉える「態勢」をつくることが大切 発注者は要件定義に責任を持ってシステム構築にかかわるべし サービスの継続を優先するシステムにおいては、 疑わしき構成要素を積極的にシステムから切り離せ （“フェールソフト”の考え方） 蟻の目だけでなく、 システム全体を俯瞰する鳥の目で総合的な対策を行うべし！ 現場をよく知り、現場の知識を集約し、 現場の動きをシミュレートできるようにすべし！ システム全体に影響する変化点を明確にし、 その管理ルールを策定せよ！ サービスの視点で、 「変更管理」の仕組み作りと「品質管理責任」の明確化を！ テスト環境と本番環境の差異を体系的に整理し、 障害のリスク対策を練るべし バックアップ切替えが失敗する場合を考慮すべし ガバナンス/マネジメント 技術 組織連携 発注者責任 要求 設計 製造 試験 運用 ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ ○ 各教訓の説明 Copyright © 2013-2015 IPA, All Rights Reserved Software Japan 2015 Software Reliability Enhancement Center 14 ４．“教訓”の内容 各教訓の構成 [教訓ＩＤ] 教訓概要(タイトル) 問題：障害事例の内容 原因：問題を引き起こした要因の 分析結果 対策：問題の原因を取り除き再発 を防止するための方法 効果：対策の実施により見られた ／期待される効果 教訓：得られた教訓の内容説明・ 補足 あらかじめ実施 しておくべき対策 はないか？ 類似の障害は 起きないか？ 各教訓の説明 Copyright © 2013-2015 IPA, All Rights Reserved Software Japan 2015 Software Reliability Enhancement Center 15 ５．今後の取組み 教訓の共有（社会で）と活用（各組織で） 形式知 社会智 一般化・抽象化 された教訓 ★ 有識者・専門家 による機論 高 各分野で展開 抽 象 レ ベ ル 共通コンテキスト 普遍化 共有 暗黙知 事例と ★ 根本原因 対策 コンテキスト ★ 対策 ★：本質 “想像力”が重要 Copyright © 2013-2015 IPA, All Rights Reserved 対策 ★ 対策 コンテキスト コンテキスト コンテキスト Ａ分野 Ａ分野 ★ Ｂ分野 低 Ｃ分野 各組織での活用時，システマティックな取組み： 教訓と共に提供されるコンテキストと 自身のコンテキストとを比較・照合し， 適用可能な教訓について，具体的対策を検討 Software Japan 2015 Software Reliability Enhancement Center 16 ５．今後の取組み 誰が，どう使う？ 部署等／ 経営層 （事例に基づく）教訓の活用例 役割（ロール） 社長 組織に“安全文化”を醸成 担当役員 部門長 業務部門 業務推進担当 システム推進担当 組織・ 体制 の 整備 関連会社 運用 手順 の 整備 開発 手順 の 整備 部門長 情報 システム 部門 システム開発担当 システム子会社 元請けベンダ ベンダ 社内教育 アウトソーサ サブベンダ 調達 時の 指示 事項 調達 時の 確認 事項 ﾚﾋﾞｭｰ ・試験 項目 類似 事例 トラブ ル発 生時 の 原因 推定 ＜出典（縦軸）＞ SEC BOOKS 「経営者が参画する要求 品質の確保 ～ 超上流から攻めるIT化の勘どころ ～」，p.37 の 3.2（１）項、p.41 の 4.1 Copyright © 2013-2015 IPA, All Rights Reserved Software Japan 2015 Software Reliability Enhancement Center 17 ５．今後の取組み 安全文化：スイスチーズモデル(1/2) （さまざまな）穴 危険因子 事故 防護壁 •プロダクト面（空間） •プロセス面（時間） <参考例> http://rikanet2.jst.go.jp/contents/cp0300/manual/extra/ex_29.html Copyright © 2013-2015 IPA, All Rights Reserved Software Japan 2015 Software Reliability Enhancement Center 18 ５．今後の取組み 安全文化：スイスチーズモデル(2/2) プロセス／アクティビティ 設計 試験 運用 不具合/ミス の要因 システム障害 穴をふさぐ 教訓 広範囲の事例 Copyright © 2013-2015 IPA, All Rights Reserved 多様な観点 Software Japan 2015 Software Reliability Enhancement Center 19 教訓活用例 教訓の一例(1/6) 【教訓タイトル】 ★：本質 ＜抽象的な表現の例＞ システムの部分変更（に伴う新旧混在）時に（非変更部分との）整合性を確認する． ＜具体的な表現の例＞ 変化に対応して（プログラム／システム定義データ中の）定数をチェックする． 【説明】 共通コンテキスト 交換（部分変更）する構成要素（ソフトウェアを含む）は，交換前のものと互換 性があるという仕様になっていても，機能やインタフェースが一部異なっている かもしれない．特に，新機能が追加されていることがよくある．異なる技術が用 いられている場合には，設計思想そのものが異なっていることもある．また，機 能は同じでも，性能等の非機能特性が異なるケースは多い． したがって，交換する構成要素と，システムの他の部分（交換しない部分）とが 整合するかについて，様々な視点から確認する必要がある． 特に，性能差がある場合，タイマ監視等を行う処理においては，監視タイマ値の 妥当性を入念にチェックし，チューニングをやり直す必要がある．特に，新しい 構成要素の特性が性能に影響する場合を見逃してはならない． Copyright © 2013-2015 IPA, All Rights Reserved Software Japan 2015 Software Reliability Enhancement Center 20 教訓活用例 教訓の一例(2/6) 整合性の確認要 構築当初のシステム Copyright © 2013-2015 IPA, All Rights Reserved 構成要素の一部を交換 Software Japan 2015 Software Reliability Enhancement Center 21 教訓活用例 教訓の一例(3/6) 【問題（障害事例）】 (個別)コンテキスト ◆概要 2013年7月18日，ある鉄道会社にて，列車運行を管理するシステムのうち， ダイヤに基づき各駅の信号機を自動制御する「自動列車進路制御装置(PRC)」の 保守時に異常が発生．その後バックアップ系統への切替えに失敗し、装置が停止． 管轄する3路線の鉄道が2時間以上運行できなくなり，385本が運休，約11.1万 人に影響． ◆状況 午前4時，PRCの部品（今回の要因となった部品とは別のもの）の交換作業を 始めると，アラームが鳴動し動作停止． 復旧のため，機器内に２つある処理系統のうち上記部品交換を行ったのとは別 の系統（バックアップ系統）を起動させようとしたものの，起動せず． 交換対象の部品を戻して再起動する等を試みたが，PRCは復旧せず． ５時半頃に予備のPRCを使ってシステム全体の復旧に取り掛かり，６時54分 に復旧．７時半頃から順次運転を再開． <参考> 新聞等の報道記事 Copyright © 2013-2015 IPA, All Rights Reserved Software Japan 2015 Software Reliability Enhancement Center 22 教訓活用例 教訓の一例(4/6) 【（直接の）原因】 (個別)コンテキスト PRCのディスクとして，元はHDDが使用されていたが，2010年に，インタ フェース互換のあるSSDに交換された．制御OSの変更はなかった．【設計】 交換当時は，現用・待機両系停止の状態で装置を起動する試験のみを実施し， 潜在リスクを発見できなかった． 【試験】 その後，PRC内部のある故障部品を交換する必要が生じ，現用系のみを停止し て実施することとした．工場での事前確認では，同じ装置がなかったため，HDD 搭載装置での試験を行い，SSD搭載装置ではできなかった． 【運用】 このような状況で，現場での実際の交換作業において，PRCの現用系停止状態 で待機系を起動させた．装置の仕様上，初期起動時に，CPU上のOSがディスクに リセット要求を行い，その完了をタイマ監視（タイマ値=200ms）で待つ．HDD の場合には1msで完了するが，今回の装置に搭載されていたSSDでは300msが 必要であった． したがって，タイムアウトを検出したOSはディスクの異常と判断して停止要求 を行い，SSDはそれを不正コマンドとして受け付けず，外部からのコマンドを拒 否するモードに移行した． 【今回の対処】OSの監視タイマ値を200msから360msに変更． Copyright © 2013-2015 IPA, All Rights Reserved Software Japan 2015 Software Reliability Enhancement Center 23 教訓活用例 教訓の一例(5/6) 【対策（例）】 共通コンテキスト ◆コンポーネント・レベル ・ミスを起こさない：特にメンテナンス時における，ハード担当と制御ソフト担 当とのコミュニケーションの徹底（気づかせるための会議，文書の工夫等） ・ミスを逃さない ：試験時の思い込み（“互換性”への過信）排除（第三者の関 与等）．標準規格の規定事項/規定外事項の明確化 ◆システム・レベル ・ミスを起こさない：変化点を捉えた，俯瞰的かつ系統的な設計レビュー ・ミスを逃さない ：試験時における，本番環境との相違点に関するリスク評価 【教訓活用時のコンテキスト】 (1) 比較的大規模なシステムにおいて，システムの構築あるいは更改を段階的に 行う場合，版や性能等の異なる構成要素が混在することになるケース (2) 比較的長期間使用しているシステムにおいて，あるいは技術進展の激しい分 野において，一部の部品を当時の最新の（or 通常出回っている）ものと交換 するケース Copyright © 2013-2015 IPA, All Rights Reserved Software Japan 2015 Software Reliability Enhancement Center 24 教訓活用例 教訓の一例(6/6) (個別)コンテキスト 【教訓の活用（例） 】 (1) 比較的大規模なシステムにおいて，システムの構築あるいは更改を段階的に 行う場合，版や性能等の異なる構成要素が混在することになるケース 多数のサーバと端末装置から成るシステムにおいて，当初は全体を一括で構 築したものの，その後の端末の更改を，毎年一部ずつ順に行うような場合，新規 端末の性能が当初端末より高い場合には，サーバとの通信における応答待ちタイ マ値等をチューニングし直す必要があるかどうか，検討． (2) 比較的長期間使用しているシステムにおいて，あるいは技術進展の激しい分 野において，一部の部品を当時の最新の（or 通常出回っている）ものと交換 するケース 装置内のメモリを増量のために大容量チップに交換する際，大容量のために 前のものよりアクセス時間が若干長い仕様となっている場合，CPUやDMAデバイ スとのタイミングの整合性を確認． 新部品の初期設定タイミングの相違やエラーメッセージ追加の有無等，標準 規格では規定されていない実装上の事項を確認． Copyright © 2013-2015 IPA, All Rights Reserved Software Japan 2015 Software Reliability Enhancement Center 25 ５．今後の取組み 障害事例情報に基づく教訓共有の仕組みの展開イメージ 目指す社会に向けて 企業 a4 企業 a3 企業 a5 企業 a6 分野・業界Ａ内 の情報共有 企業 a2 企業 a1 企業 b2 ・・・ 分野・業界Ｂ内 の情報共有 企業 b1 分野・業界にまた がる情報共有 教訓 企業 d1 企業 d2 分野・業界Ｄ内 の情報共有 応用分野に関す る情報共有 企業 e1 企業 d3 企業 e2 企業 e3 企業 g1 ・・・ 企業 c1 企業 c2 ・・・ 分野・業界Ｃ内 の情報共有 地域団体による 情報共有 企業 h1 企業 f1 企業 f2 分野・業界Ｆ内 の情報共有 企業 f5 企業 f3 企業 f4 分野・業界Ｅ内 の情報共有 Copyright © 2013-2015 IPA, All Rights Reserved Software Japan 2015 Software Reliability Enhancement Center 26 ６．まとめ（に代えて） 共有活動への参加者の声 活動目的 ［参加者］ 他分野の事例を自身の参考とする ［社会］ 多くの分野の参考となるよう，特定分野の事例を普遍化 ・自社事例を“教訓”化するための議論の中で，“気づき”を得ることが あった． ・他分野の事例紹介では，鉄道の線路を送電線に置き換えて考えてい る． ・他分野の事例の中に参考になるところがあった． イノベーションの種 Copyright © 2013-2015 IPA, All Rights Reserved Software Japan 2015 Software Reliability Enhancement Center 27 ６．まとめ（に代えて） みなさまへの期待 1．各社内での取組み 暗黙知 障害事例情報を収集・蓄積する． 再発防止策をまとめ，共有する． 2．グループ企業や業界における取組み 形式知 社内での取組みを関係者へ拡げる． 3．社会レベルでの取組み 社内やグループ内の知見を社会全体のために役立てる． 社会智 他所からの知見を，自身のために活用する． イノベーション Copyright © 2013-2015 IPA, All Rights Reserved Software Japan 2015 Software Reliability Enhancement Center 28 ご清聴，ありがとう ございました http://www.ipa.go.jp/sec/system/index.html Copyright © 2013-2015 IPA, All Rights Reserved Software Japan 2015 Software Reliability Enhancement Center 29 Check！ Catch！ Search！ Click！ Copyright © 2013-2015 IPA, All Rights Reserved Software Japan 2015 Software Reliability Enhancement Center 30 以降，参考 Copyright © 2013-2015 IPA, All Rights Reserved Software Japan 2015 Software Reliability Enhancement Center 31 データ例 過去の情報処理システムの障害事例 ひとたびシステム障害が発生した場合， 社会に及ぼす影響範囲が拡大し，その深刻度も増大 過 去 の 事 故 事 例 （ ソ フ ト ウ ェ ア 起 因 ） 人身事故 経済事故 Therac-25による放射線過剰被爆事故（1985～87年） エアバスA320の墜落事故（1988～93年） 名古屋空港で中華航空機が着陸に失敗炎上（1994年） 携帯情報端末の発熱－実はソフトの不具合（2009年） 電子カルテシステムの不具合（2010年） 新幹線運行管理システムの障害（2008年，2011年） 銀行オンラインシステムの障害（2011年） 株式売買システムの障害（2012年） レンタルサーバーのデータ消失（2012年） Copyright © 2013-2015 IPA, All Rights Reserved Software Japan 2015 Software Reliability Enhancement Center 32 データ例 類似障害の発生状況 ◆処理量の増大・環境変化に対する対処遅れ 1. みずほ銀行の障害…2011.3.15～3.24 東日本大震災義援金の受付けが携帯電話を利用した送金サービスの口座に集中し，その処 理を行う夜間バッチの件数が上限を超えたことをきっかけに，事後対応のまずさもあり，長期間 にわたりサービス停止の事態に． 2. アフラックの障害…2013.4.4 一部の保険料金が4月から上がるのに伴い，3月末に駆込みの契約が増えたために処理量が 増大し，夜間バッチが想定の時間内に終了しなかった可能性大． 3. NTTドコモの障害…2011.8.16, 2011.12.20 スマートフォンの急激な普及により通信の質が変化すると共に量も増大し，設備の容量を超え たために，通信しにくい状況に．このことが別の障害も誘発． 4. KDDI（ａｕ）の障害…2013.4.16～18 スマートフォンによるメールの送受信等が使用できない状況が断続的に発生したが，利用の急 増に対応するための設備増強の遅れが根本原因と報道されている．(4/18 日経電子版) ◆二重化システムにおける待機系への切替え失敗 日本生命（2014.4.7），JR九州（2013.7.18），KDDI（2013.4.16），東京証券取引所 (2012.2, 2012.8)，富士通データセンター(2012.6)，住信SBIネット銀行（2011.9），気象 業務支援センター(2009.3)，NTT東日本(2008.11)，JR東日本(2008.9) Copyright © 2013-2015 IPA, All Rights Reserved Software Japan 2015 Software Reliability Enhancement Center 33 参考 「正常化の偏見」 人の性：「自分だけは大丈夫」と思う … 正常化の偏見※ → 確かに大丈夫，という確認が必要 ※ (出典)人はなぜ「自分は大丈夫」と思うのか，防災研究家の片田群馬大学教授に聞く，ITpro 2007/04/11 http://itpro.nikkeibp.co.jp/article/Interview/20070409/267753/ Copyright © 2013-2015 IPA, All Rights Reserved Software Japan 2015 Software Reliability Enhancement Center 34 参考 「他山の石」 「他山の石」の意味※ 他人の誤った言行やつまらない出来事でも それを参考にしてよく用いれば， 自分の修養の助けとなる 失敗に学ぶ → 類似障害の発生を防止できる 「対岸の火事」 ※(出典) 文化庁月報 平成23年10月号(No.517) http://www.bunka.go.jp/publish/bunkachou_geppou/2011_10/series_08/series_08.html Copyright © 2013-2015 IPA, All Rights Reserved Software Japan 2015 Software Reliability Enhancement Center 35 参考 みんなの力で全体をカバー ITサービスの機能やシステムが複雑化す ると，単一事業者のカバーする知見の範 囲は，相対的に狭くなる． 広 高信頼化 1事業者に囲われた経験と情報を幅広 く社会全体で共有し、障害対策などに 有効活用できることが重要． カ バ ー 範 囲 率 社会全体 1社のみ 狭 低 高 ITサービス機能・システム複雑度 時代の流れ Copyright © 2013-2015 IPA, All Rights Reserved Software Japan 2015 Software Reliability Enhancement Center 36 参考 「情けは人のためならず」 「情けは人のためならず」の意味※1 人に対して情けを掛けておけば， 巡り巡って自分に良い報いが返ってくる “社会間接互恵性” ※2 ある個体が利他行動(他者に親切にする行動)を行った結果、 その個体の評価が高まり、他者に行った利他行動が回り 回って別の他者から返ってくる仕組み 「ヒト」は，日常生活で困っている他人を見ると，それが自分の知らない人で あっても助けたい衝動にかられ，多くの場合何らかの親切を行う性質を持つ ※1 (出典) 文化庁月報 平成24年3月号(No.522) http://www.bunka.go.jp/publish/bunkachou_geppou/2012_03/series_08/series_08.html ※2 (出典) 大阪大学大学院人間科学研究科の実証実験成果から 2013年8月8日 http://www.osaka-u.ac.jp/ja/news/ResearchRelease/2013/08/20130808_1 Copyright © 2013-2015 IPA, All Rights Reserved Software Japan 2015 Software Reliability Enhancement Center 37 参考 相互に結びつくITサービス/製品機器 国民生活・社会経済活動 医療機器 金融系 情報処理システム 制御機器 制御機器 エネルギー系 情報処理/制御システム 他サービス/製品機器の障害は， 自サービス/製品機器にも 影響が及び得る 交通系 情報処理システム データセンター/クラウド 情報通信系 情報処理/制御システム ・あるITサービス/製品機器は，他のITサー ビス/製品機器に依存することがある． ・ITシステムの中に，製品機器を含むこと がある． 相互に依存 Copyright © 2013-2015 IPA, All Rights Reserved Software Japan 2015 Software Reliability Enhancement Center 38 参考 もう一つの効果（目的）：経験の継承 メインフレーム → 分散（Ｃ／Ｓ）システム → クラウドコンピューティング 自分は先輩と同じような間違いを犯していないか？ 後輩は自分と同じような間違いを犯しはしないか？ → 他所のシステム障害にも目を向ける Copyright © 2013-2015 IPA, All Rights Reserved Software Japan 2015 Software Reliability Enhancement Center 39 参考 アンケート例 障害事例情報を公開する企業に対して、どのように思 われますか？（回答者76名） １．障害を発生させていることから、信 頼できない 2.6% 11.8% 0.0% ２．積極的に情報公開をすることから、 公開しない企業に比べて信頼できる 2.6% ３．特に何とも思わない ４．その他 82.9% 無回答 ＜アンケート回答者（計76名）＞ ET2013（2013年11月） ソフトウェアジャパン（2014年2月） Copyright © 2013-2015 IPA, All Rights Reserved Software Japan 2015 Software Reliability Enhancement Center 40 H25年度の活動成果概要 情報処理システム高信頼化教訓集－2013年度版－ プレス発表 重要インフラを支えるシステムの障害情報や対策を分析した2種類の教訓集を公開 http://www.ipa.go.jp/about/press/20140513.html 情報処理システム高信頼化教訓集（製品・制御システム編）－2013年度版－ http://www.ipa.go.jp/sec/reports/20140513_2.html 情報処理システム高信頼化教訓集（ITサービス編）－2013年度版－ http://www.ipa.go.jp/sec/reports/20140513.html ＜特徴＞ ①複数の重要インフラ分野等（通信、銀行、証券、保険、鉄道、電力、政府・ 行政など）の有識者・専門家を中心とする委員会を設置し、多方面からの議 論に基づき、業界・分野を超えて活用可能な普遍化された教訓。 ②所定の機密保持ルール（今回、同時公開）の下で、未公開情報を含む障害事 例及びその再発防止策等に関する詳細情報の提供を受け、原因や対策につい て深く議論した内容をベースに、可能な範囲を公開。 ③委員の豊富な経験に基づく知見と、過去10年間の活動でIPA/SECに蓄積され たソフトウェア・エンジニアリングに関する検討成果に基づいて取りまとめ、 技術領域に加え、ガバナンス／マネジメント領域の教訓も整理。 Copyright © 2013-2015 IPA, All Rights Reserved Software Japan 2015 Software Reliability Enhancement Center 41 H25年度の活動成果概要 「教訓集」の構成 情報処理システム高信頼化教訓集 （ITサービス編）の本体 PART Ⅰ 教訓集（本編） PART Ⅱ 障害対策手法・事例集 PART Ⅲ 障害分析手法・事例集 付録A 障害情報の取扱いルール 障害情報を報告・記録する共通 様式と、それらの収集・公開に 際しての機密保持等のルールを まとめたもの Copyright © 2013-2015 IPA, All Rights Reserved Software Japan 2015 教訓集中の各教訓を実践するため に必要な手法を整理したもの 今回の活動の中で実施した、障 害の分析手法・事例の調査結果 をまとめたもの Software Reliability Enhancement Center 42 ４．“教訓”の内容 例：教訓の概要（１） 教訓G1：システム開発を情シス部門だけの仕事にせず、 各事業部門が自分のこととして捉える「態勢」をつくることが大切 システムトラブルの8割は、上流の要件定義局面でのコミュニケーション・ギャップから 問題が生じていることが判明 →システム開発におけるビジネスサイドの役割と責任を明確化し、コミュニケーションの 質を高める態勢「アプリケーション・オーナー制度」 •システム開発は、情シス部門に 任せきりにすべき仕事ではなく、 自分の考えた商品や施策を具体 化するために行う自分自身の仕 事であるという「オーナーシッ プ」の考え方を持たせる。 •事業部門に、要件の詳細が固ま るまで、情シス部門と対話を繰 り返す責任を持たせ、要件定義 の最終責任を負わせる。 •事業部門に、要件定義どおりに システムが出来たかどうか受入 れテストを実施する責任を負わ せる。 アプリケーション・オーナー制度：責任と役割分担（東京海上日動火災株式会社の例） Copyright © 2013-2015 IPA, All Rights Reserved Software Japan 2015 Software Reliability Enhancement Center 43 ４．“教訓”の内容 例：教訓の概要（２） 教訓G2：発注者は要件定義に責任を持ってシステム構築にかかわるべし システム開発・運用をITベンダに外部委託するケースで、開発案件の増加に伴い任せる業務 が徐々に拡大し、要件定義や受入れテスト等、発注者としての役割を果たし切れていない 1) 要件定義書の中身と受入れテストについての責任は発注者とする 2) 開発プロセス標準を見直し、上流の要件定義を押さえる（上流工程完璧主義） 改革後 改革前 ベンダー任せ 要件定義前の 見積もりで契約し 変更はなし 要件定義 発注者が責任を持ち 主体的に実施。 ベンダーには委任契約で発注 要件定義書を変更したら 仕様変更書を作成し 契約を見直し システム 設計・開発 ベンダー任せ 受入れ テスト 発注者が責任を持ち 主体的に実施。 ベンダーには委任契約で発注 要件漏れ等の上流工程に起因する 品質上の問題が著しく減少 プロジェクトの透明性が増し、組 織同士の継続的な信頼関係が向上 Copyright © 2013-2015 IPA, All Rights Reserved Software Japan 2015 改革前 改革後 企画 （プロジェクト企画書作成） 要件定義（１） RFPの作成 要件定義書の作成 企画 （プロジェクト企画書作成） ①要件定義書の記述レベル の詳細化を図り、記載内 容の網羅性チェックを徹 底する 要件定義（２） 要件確認書の作成 要件定義 RFPの作成 ※RFPの詳細化 要件定義書の作成 ※ 要件定義書の詳細化 と網羅性チェック システム・ソフトウェア 要件定義 システム・ソフトウェア 要件定義 システム・ソフトウェア 方式設計 システム・ソフトウェア 方式設計 システム・ソフトウェア 実装とテスト システム・ソフトウェア 実装とテスト 発注側担当 受入れテスト 受入れテスト ベンダ担当 ②受け入れテストのテスト ケースを上流工程で作成 ③発注者自らが、要件定義 が設計書に反映されたこ とを確認し、要件定義書 と 設計書のズレをなくす Software Reliability Enhancement Center 44 ４．“教訓”の内容 例：教訓の概要（３） 教訓T1：サービスの継続を優先するシステムにおいては、 疑わしき構成要素を積極的にシステムから切り離せ （“フェールソフト”の考え方） １）自身のヘルスチェックの場合 業務内容に基づいて、システム毎にポリシーを作 成した上で、フェールソフトの考え方を適用。 ①異常を通知 現用 ﾉｰﾄﾞA ハードウェア機器の故障、ソフトウェアの処理プ ロセスの異常等があった場合には、その部位を積 極的に停止させることでシステムから切り離す、 場合によってはその系全体を放棄するといった考 え方のもとに処理・対応する。 一方、そのような状況下で一部の部位や系をシス テムから切り離しても、システム全体としての サービスは継続できるように、フェールソフトの 考え方に基づいて設計・運用する。 というのは、機器やソフトウェアそれぞれの動作 継続を優先しすぎてしまうと、予期せぬ障害の場 合にサービスへの影響がかえって大きくなってし まう場合があり、サービスの継続を優先させるた めには、むしろ積極的に関連する部分をシステム から切り離す方が良い場合が多いからである。 Copyright © 2013-2015 IPA, All Rights Reserved Software Japan 2015 待機 ﾉｰﾄﾞB ②停止コマンドで切り離し ２）他系のヘルスチェックの場合 待機 ﾉｰﾄﾞB 現用 ﾉｰﾄﾞA ①ヘルスチェック ②停止コマンドで切り離し ３）自動停止できない場合は手動による停止で切り離し 現用 ﾉｰﾄﾞA 待機 ﾉｰﾄﾞB Software Reliability Enhancement Center 45 ４．“教訓”の内容 例：教訓の概要（４） 教訓T2：蟻の目だけでなく、 システム全体を俯瞰する鳥の目で総合的な対策を行うべし！ 制御系システムの下位にある制御装置の稼働系に故障が発生し、 自動的に待機系に切り替わるところが切り替わらず、 上位の監視端末からの指示による系切替えを実施したが、失敗。 障害が下位で起きた場合、障害を起こ した下位だけの対策を考えがちである が、蟻の目（下位）の対策だけでなく、 システム全体の視点で、鳥の目（上 位）対策を活用することでシステムの 安定稼働が保たれる。 Copyright © 2013-2015 IPA, All Rights Reserved Software Japan 2015 Software Reliability Enhancement Center 46 ４．“教訓”の内容 例：教訓の概要（５） 教訓T3：現場をよく知り、現場の知識を集約し、 現場の動きをシミュレートできるようにすべし！ 特定ケースで制御信号が正しく出力されず、列車が停止 【原因１】有識者（ベテラン社員を含む）による以下の機能確認を行っても、まだ洗い出 せていない機能が存在する。（機能要件漏れ） 【原因２】列車の動き、システムの動作などを総合的にテストできる環境、つまり、組込 みソフトウェアを持った制御システムと列車などの動作の全てのテストが行え るテスト環境ができていない。 【原因１】については、一度設計された 「機器の動き（列車の運転）」のパ ターンを知識データベースとして蓄 積し、そこに、追加登録していく。 ①A列車が折返し出発 駅 【原因２】については、制御系システム のシミュレーション・システムの開 発を行うためには、現実の制御装置 のプロセスを分かりやすく可視化し、 ②駅を出発したのに プロセスの骨子を見極めて「モデ もかかわらず制御 ル」化（モデリング）する。 信号が出続ける Copyright © 2013-2015 IPA, All Rights Reserved Software Japan 2015 ④A列車の制御信号が 出続けているため、B 列車への制御信号が 出なかった A列車 B列車 ③B列車の進路を構成 Software Reliability Enhancement Center 47 ４．“教訓”の内容 例：教訓の概要（６） 教訓T4：システム全体に影響する変化点を明確にし、 その管理ルールを策定せよ！ 表示項目数がシステムの上限値を超えたため、全画面表示が消え，オペレータが混乱 ↳システム構築当初から決まっていた上限値について、外部仕様変更に伴う見直しを未実施 原因の本質は、全体に影響する変化点（この場合、予測時間、列車運転本数）が不明確 【原因１】予測時間を4H⇒24Hに変更した際、そのよう な要件変更があったにもかかわらず、「修正箇 所数」の上限値の増加などシステム全体の機能 要件変更を未実施 【原因２】列車の本数が年々増加しており、本来ならば（ 運転本数の増加の都度）上限値を超えた際のシ ステムの挙動を見直す必要があったにもかかわ らず、未実施 ②ダイヤ 修正発生 実績ダイヤ Software Japan 2015 予測ダイヤ ①抑止入力 制御系システムの変化点の管理ルールを明確にし、その ルールを守る仕組みを構築 ・システムが監視・制御する対象と仕様の変化点を網羅 ・変化点管理のルールとそれを守る仕組みを構築 ・変化点管理で使用する管理指標を関係部門で共有し、 「変化点の見落とし」を防止 Copyright © 2013-2015 IPA, All Rights Reserved ③修正箇所が上 限値を超過 修正箇所 現在時刻 ④予測ダイヤの表示 ができなくなった Software Reliability Enhancement Center 48 ４．“教訓”の内容 例：教訓の概要（７） 教訓T5：サービスの視点で、 「変更管理」の仕組み作りと「品質管理責任」の明確化を！ 本店ホスト／サーバから請求データを端末に転送し請求書を印刷するシステムにおいて、 端末として、営業員が持ち歩くHT（ハンディ・ターミナル）を新規に導入したところ、 そのシステムから出力される請求書の金額が誤ったまま顧客に渡ってしまい、個別謝罪・ 請求書の再発行に追われた． システムへの新たな要件追加、 使用方法の変更があると、今ま で正常に稼働していたシステム が突如障害となる 変更があった時にシステム 全体のプログラムの整合性、 データの整合性、テスト仕 様の整合性を保つための変 更管理を確実に実施 システム全体の整合性を確 認する人を決め、品質管理 責任を明確にし、開発 フェーズ毎の検証を実施 Copyright © 2013-2015 IPA, All Rights Reserved 事業所サーバ 本店ホスト/サーバ 顧客 ﾃﾞｰﾀﾍﾞｰｽ ホ ス ト Ｐ Ｇ 請求予定 配 信 Ｐ Ｇ 請求予定 使用料 調整単価 Ｈ Ｔ 送 信 Ｐ Ｇ 営業HT 営業HT Ｈ Ｔ ・ Ｐ Ｇ 障害 業務部門と情シス部門 でテスト仕様作成・実施 請求書作成 情シス部門でテスト仕様作 成・実施→業務部門も参加 データ整合性 プログラム整合性 テスト仕様整合性 要件定義 設計・開発 受入れテスト サービスの視点で、「変更管理」 「品質管理責任」 Software Japan 2015 Software Reliability Enhancement Center 49 ４．“教訓”の内容 例：教訓の概要（８） 教訓T6：テスト環境と本番環境の差異を体系的に整理し、 障害のリスク対策を練る テスト環境と本番環境とに相違があり、テスト環境でうまくいったソフトウェアのリリー スであるが、本番環境で障害が発生 ①テスト環境と本番 環境の差異分析 ②テスト環境で確認 できない項目、機 能に対し、関係者 でリスク分析 ③リスク分析結果を 基に、コンティン ジェンシープラン ④本番環境のリスク をステークホルダ で共有 ⑤大きいリスクは経 営トップが判断 環境差異 分析 テスト環境 機 能 要 件 本番環境 AP ・ ・ ・ ①テスト環境と本番環境の環境差異を洗い出す テスト環境で検証できる ・異なる項目 ・異なる項目 ・異なる項目 テスト環境 Copyright © 2013-2015 IPA, All Rights Reserved ②テスト環境で検証 出来ない項目を 抜き出す。 テスト環境で検証できない 項目 テスト環境で検証できる OS ﾐﾄﾞﾙ ｳェｱ テスト環境で 検証できない ③リスク対策/コンティ ンジェンシープランを 作成（３者で検討） テスト環境で検証できる HW 非 機 能 要 件 本番環境 テスト環境で検証できない テスト環境で検証できる ・異なる項目 データ 量・質 テスト環境で検証できない テスト環境で検証できる ・異なる項目 リスク対策/コンティン ジェンシープラン 1 2 3 4 テスト環境で検証できない テスト環境で検証できる 性能 ・異なる項目 テスト環境で検証できない テスト環境で検証できる NW ・異なる項目 テスト環境で検証できない ④３者の検討結果は、経営トップ、 製品ベンダ等のステークホルダで 共有する。 ⑤大きいリスクは、経営トップが判断する。 Software Japan 2015 Software Reliability Enhancement Center 50 ４．“教訓”の内容 例：教訓の概要（９） 教訓T7：バックアップ切替えが失敗する場合を考慮すべし 冗長構成を取っているにも関わらず、バックアップ切替えが失敗しシステム障害とな るケースが多い。下図に示されるさまざまな失敗原因にあらかじめ配慮してシステムの 開発・運用を行うことにより、過去に発生した障害と類似の障害の発生を防ぐことがで きる。 (5)手動切替え失敗 (9) 切替え失敗 (7) 待機系システムの障害 （操作ミス） （保守作業ミス） （稼働系と同一原因） (4)切替え失敗 （切替えソフトウェア不具合） (2)待機系システムの障害 （構成不備） (1）稼動系システムの 障害未検知 (3)待機系システムの障害 （アプリケーション不備） 稼働系 待機系/ 分散稼働 アプリケーション OS等 ハードウェア (6)切替え後動作不安定 （性能不足） (10) ネットワークの 自動切替えに失敗 (8) 切替え後動作不安定 （データ不正） データ データ (11)電源装置の 自動切替えに失敗 電源装置 (予備) Copyright © 2013-2015 IPA, All Rights Reserved アプリケーション OS等 ハードウェア Software Japan 2015 電源装置 (現用) ネット ワーク 現用 ネット ワーク 予備 Software Reliability Enhancement Center 51 ４．“教訓”の内容 例：製品・制御システム編の教訓例（１） ※以下、直接の対策と恒久対策に続く Copyright © 2013-2015 IPA, All Rights Reserved Software Japan 2015 Software Reliability Enhancement Center 52 データ例 優れた品質保証体制の組織のプロダクトは信頼性が高い 品質保証体制の専門スタッフがいるプロジェクトの方が， そうでないプロジェクトに比べ，プロダクトの信頼性が高い 統計データ例 N=63 (37+26) 低 システマティック な取組みの効果 ← 信 頼 性 12.2 → 約2.5倍 高 4.8 優れた品質保証体制の組織 * FP発生不具合密度：ファンクションポイント（機能規模）当たりに発生する不具合（バグ）の数 出典：「ソフトウェア開発データ白書2014-2015」(IPA/SEC) Copyright © 2013-2015 IPA, All Rights Reserved Software Japan 2015 Software Reliability Enhancement Center 53 参考 「サイバーセキュリティ戦略」 出典： NISC ,「サイバーセキュリティ2013」（案）について,平成25年6月27日,P4 Copyright © 2013-2015 IPA, All Rights Reserved Software Japan 2015 Software Reliability Enhancement Center 54 参考 重要インフラの情報セキュリティ対策に係る 第３次行動計画の概要 出典： NISC ,重要インフラの情報セキュリティ対策に係る第３次行動計画の概要,平成26年10月10日,P2 Copyright © 2013-2015 IPA, All Rights Reserved Software Japan 2015 Software Reliability Enhancement Center 55 参考：セキュリティ サイバーセキュリティ情報共有活動 ［J-CSIP］ 2013年度 実施件数 Copyright © 2013-2015 IPA, All Rights Reserved Software Japan 2015 Software Reliability Enhancement Center 56 参考：航空 航空安全情報自発報告制度 [ VOICES ](1/2) 2014年度から国土交通省航空局の「航空安全プロ グラム」が開始されたことに伴い始まった安全情 報の報告制度 法令等で定められた事故やインシデント等に関す る義務的な報告制度だけでは捉えきれない多くの 情報を収集し、航空の安全向上のために活用 航空活動に直接携わっておられる方々（個人また はその所属する事業者等の組織）から，自ら経験 または視認した航空の安全上の支障を及ぼす可能 性があったと思われる事象（いわゆるヒヤリハッ ト）についての報告を収集し，業務実施者間で情 報を共有するとともに，それらの情報を分析して 必要と思われる改善を提案することにより，航空 の安全向上に寄与 そのヒヤリ！ さっきのハット！を 役立てます！ 出典： 航空安全情報自発報告制度（VOICES) について http://www.jihatsu.jp/index.html 報告者保護の観点から，航空安全当局（国土交通省航空局）や報告者の所属する組織以外 の第三者機関が運営を行う． 航空安全当局は，報告者の個人，会社名等が特定される情報の提供を制度運営者に対し求 めない，本制度に提供された情報を行政処分等の不利益処分の根拠として使用しない． Copyright © 2013-2015 IPA, All Rights Reserved Software Japan 2015 Software Reliability Enhancement Center 57 参考：航空 航空安全情報自発報告制度 [ VOICES ](2/2) 公益財団法人 航空輸送技術研究センター（ATEC）が運営 航空安全情報自発報告サイト https://asicss.cab.mlit.go.jp/voluntary/ 報告の受付け 分析担当者によるヒアリング 情報の秘匿化 分析作業とフィードバック VOICESポータルサイト にて周知，等 Copyright © 2013-2015 IPA, All Rights Reserved 出典：航空安全情報自発報告制度（VOICES) について http://www.jihatsu.jp/FAQ/index.html#pageLink02 Software Japan 2015 Software Reliability Enhancement Center 58 参考：原子力 原子力施設情報公開ライブラリー ［NUCIA］ (1/2) 原子力施設情報公開ライブラリーを意味する英語の名称 NUClear Information Archives の頭文字をとった略 称で、国内原子力発電所や原子燃料サイクル施設の運 転に関する情報を広く共有化するためのサイトです。 http://www.nucia.jp/index.html Copyright © 2013-2015 IPA, All Rights Reserved Software Japan 2015 Software Reliability Enhancement Center 59 参考：原子力 原子力施設情報公開ライブラリー ［NUCIA］(2/2) トラブル情報等 「トラブル情報」 「保全品質情報」 Copyright © 2013-2015 IPA, All Rights Reserved Software Japan 2015 Software Reliability Enhancement Center 60 参考：金融 金融ISAC (1/1) 金融機関間のサイバーセキュリティに関する情報を共有するための組織 http://www.f-isac.jp/index.html （2014年8月1日設立） 高度化するサイバー攻撃に対抗するため、フィッシング被害、不正送金被害、 APT攻撃、DDoS攻撃、脆弱性・ゼロディの脅威等のサイバーセキュリティに関 する情報を、会員である金融機関で共有し連携して対策に当たる。 すでに米国には同様の組織があり（FS-ISAC：Financial Services Information Sharing and Analysis Center）、4,600社を超える金融機関が会員となって活 動しているが、金融ISACはFS-ISACとも連携し、情報共有を促進。また、国内 の組織とも積極的に連携していく予定。 出典： 一般社団法人 金融ISACの設立について http://www.f-isac.jp/new4.html 参考： 米国のセキュリティ情報共有組織（ISAC）の状況と運用実態に関する調査 平成22年3月 株式会社 三菱総合研究所 http://www.nisc.go.jp/inquiry/pdf/fy21-isac.pdf IT-ISAC, Chemical ISAC, Communication ISAC, ES-ISAC(エネルギー), FS-ISAC(政府施設), MS-ISAC等がある．ES-ISACのみ，システム障害情報も共有． Copyright © 2013-2015 IPA, All Rights Reserved Software Japan 2015 Software Reliability Enhancement Center 61 社会智とイノベーション 知とその共有に関する進化 見える化 形式知 （知識） 暗黙知 個有 分析・体系的整理 個人が 目指すところ 現状 組織 形式知 （智恵） 企業が 目指すところ 現状 共有 社会 ソーシャル・ イノベーション 現状 当面の マイルストーン 人類が 目指すところ オ ー プ ン ・ イ ノ ベ ー シ ョ ン ＜参考文献＞ 山下: 社会の“インテリジェンス”活用推進に向けた考察, SEC journal, No.23. Copyright © 2013-2015 IPA, All Rights Reserved Software Japan 2015 Software Reliability Enhancement Center 62