安全で安心できるe-社会を実現するソフトウェアとシステム技術：1.システムリスクに挑む：安全で安心できるe-社会を実現するソフトウェア開発・管理技術

全文

(1)特集：安全で安心できる e- 社会を実現するソフトウェアとシステム技術. 特集 1．. システムリスクに挑む：安全で安心できる e- 社会を実現するソフトウェア開発・管理技術南山大学. 青山幹雄 [email protected]. 現代社会は情報通信システム，とりわけ，ソフトウェ. アのバグによる．このバグは，人命にかかわる装置の操. アに依存している．ソフトウェア開発・運用のリスクは. 作者に対するユーザインタフェースの不適切さに加え，. 社会全体に及ぶ可能性がある．金融，航空などの社会基. 過剰照射から患者を保護する安全装置の制御誤りが組み. 盤をなすビジネスにおける近年の相次ぐシステム障害の. 合わされた複合的問題であった．さらに，このソフトウェ. 発生は，このリスクの巨大さを広く知らしめるとともに，. アの開発は 1 人の技術者に任されて，かつ，その技術者. 予防の難しさも露呈した．さらに，コンピュータウイル. の経験や技術を社内で知る人がいなかったという管理の. スのグローバルな拡散は，リスクもグローバルな広がり. 問題もあった．. を持つことを意味する．. ■ アリアン 5 号（Ariane5）ロケット打ち上げ失敗. 本稿は，このような背景のもと，ソフトウェアシステ. 1996 年 6 月 4 日に打ち上げられた ESA（European. ムを安全性の視点から捉え，安全性の確保がソフトウェ. Space Agency）のアリアン 5 号ロケットは発射 37 秒後. ア設計の課題であることを示し，安全で安心できるソフ. に軌道を逸脱したことから，地上からの信号で自爆した．. トウェアシステムを提供するための開発・管理技術を紹. 直接の原因は，ロケットに搭載された軌道制御のための. 介する．. 慣性航法システムのソフトウェアバグによる．旧型のア. 23）. リアン 4 号から 5 号へのソフトウェアの仕様変更がプログラムに正しく盛り込まれていなかった．さらに，ソフ. 高まるソフトウェアシステムのリスク. トウェアの変更の問題とともに，ロケットのような実機で試験が困難なシステムの品質・安全性の保証の問題も. ソフトウェアシステムが被害者の死亡や巨額の損失を. あった．. もたらす事故が起きている．このような現状を，米国大. ■ 我が国における大規模システム障害の発生. 統領情報技術諮問委員会（PITAC）は，「国民が脆弱な. 我が国でも，近年，社会に広範な影響を及ぼすシステ. ソフトウェアに頼らざるを得ない状況にある」と憂慮し. ム障害が発生している．. ている. 41）. ．. みずほフィナンシャルグループの発足に伴うシステム. ソフトウェアシステムの事故や開発の破綻の事例が収集・分析されている. 13），34）. ．代表的事例を示そう．. 統合で 2002 年 4 月に約 1 カ月にわたり発生した大規模システム障害. 35）. をはじめ，大規模オンラインシステム. の障害が発生している．. 人命にかかわる安全性の破綻 ■ 放射線治療装置セラック-25 による患者死亡. 2003 年 3 月 1 日には東京航空交通管制部の飛行計 21），38）. 画情報処理システム（FDP: Flight Data Processing. 1985 ∼ 87 年に米国・カナダで設置された 11 台の放. system）のソフトウェアバグにより，羽田空港を中心. 射線治療装置セラック -25（Therac-25）のうち 6 台で患. に 203 便が欠航し 1,443 便に遅れがでた．. 者が大量被爆を浴びる事故が起きた．そのうちの 3 件で. 一方，情報セキュリティの面からは，企業などにおけ. 3 名が死亡した．直接の原因は，装置の組込みソフトウェ. る顧客情報の漏洩が相次ぎ，2004 年 1 月には Yahoo-BB. IPSJ Magazine Vol.45 No.4 Apr. 2004. 339.

(2) 人年 300. 200 バッチ処理. 100. オンライン処理. 150. 技術ギャップを埋める開発能力向上が必要. ある公共システムの例 1970. 1980. その他 27%. ？. 100. 50 1960. Web + 分散オブジェクト，トランザクション処理， SQL，セキュリティ. C/S + GUI CICS SQL. ［IBM の調査 (1996)］. 1990. その他の設計誤り 26%. 入力値チェック誤り 27%. 配列などの境界チェック誤り 20%. 2000. 図 -1 ソフトウェア開発リスクの増大. の 470 万人の顧客情報の漏洩事件に至っている．. 図 -2 市販ソフトウェアのセキュリティ障害の原因. ア開発が最大規模であった．現在では，100 万行のソフトウェア開発は珍しくない．. 超巨大システム開発の破綻. 図 -1 は，IBM によるグローバルなサーベイに基づき，. システム運用における障害に加えて，開発の破綻やそ. 公共システムを例として，類似のソフトウェア開発に必. れに伴う損失の規模も増大している．. 要な労力の変化を示す. 米国政府は 80 年代から 90 年代にかけて巨大ソフト. の増大と開発技術の進化，高度化とともに，必要な労力. ウェアシステム開発の破綻を経験し，会計検査院（GAO）. も増大している．あわせて，開発リスク，すなわち，必. が 1995 年にまとめた報告書（GAO/HR-95-1）では「12. 要とする技術水準，技術リスクも高まっている．この開. 年間で 2,000 億ドル（20 兆円以上）を費やしてほとん. 発リスクの増大を克服する開発力が求められている．. ど得るものがなかった」と批判した．この中で最大の. ■ 組込みソフトウェアにおける要求の難しさ. 破綻事例は，1981 年から 10 年の期間と 25 億ドルの予. Lutz は人工衛星 Voyager と Galileo の制御コンピュー. 算で始まった，連邦航空局（FAA）の航空管制システ. タソフトウェア（各 18K 行と 22K 行）の結合試験とシ. ムの再開発プロジェクト AAS（Advanced Automation. ステム試験で発見されたバグ 387 件の中でシステムの障. 7）. 25）. ．ソフトウェア開発への要求. System）である．計画はたびたび延期された．多数. 害に至るバグ 209 件の原因を分析した. のソフトウェア工学研究者も動員した査察が行われた結. 因は，要求の誤り（各 62% と 70%）であった．これは，. 果，全面見直しとなった．GAO が 1999 年に発行した. 組込みソフトウェアで，かつ，高い安全性を必要とする. 報告書（GAO/T-RCED/AIMD-99-137）では，2004 年. ソフトウェアの開発における要求分析の困難さと重要性. までに総額 410 億ドルを費やす見込みとなった．当初の. を指摘している．. 予定に比べ 10 年遅れ，かつ，20 倍の費用を要する最大. ■ ソフトウェア製品のセキュリティ問題の 3/4 は初歩. 規模の破綻となった．要求仕様の絶えざる追加変更，す. 26）. ．最も多い原. 的なプログラミング誤りによる. べての機能を一挙に開発するビッグバン開発プロセス，. パデュー大学の CERIAS（Center for Education and. アーキテクチャ設計の問題とアーキテクトの不在，プロ. Research in Information Assurance and Security）が収. ジェクト管理の問題など，大規模開発の典型的問題が山. 集した主要な 100 種類のソフトウェア製品のバグの中. 積みであった．このような大規模システム開発の破綻は，. で 2000 年 1 月から 2003 年 9 月の間に発生した主なバグ. 米国政府が 90 年代半ばに立法措置を含む情報システム. 2,255 件の原因分析の結果を図 -2 に示す．この分析から，. の調達制度の全面見直しの契機となった．. CERIAS を創設したセキュリティ研究者 Spafford はソフトウェア障害の「約 3/4 が既知の初歩的なプログラ. 破綻の原因はソフトウェアの開発と管理にある. ミングの誤りによる」と指摘している. 45）. ．この誤りは，. 1988 年の Morris Internet Worm の原因として知られて. ■ ソフトウェアシステム開発リスクの増大. いた．業界が過去の失敗から学んでいないこと，さらに. 大規模ソフトウェアシステム開発の破綻の背景にはソ. は，現在の企業や政府の多くのソフトウェアにこの問題. フトウェアシステムの規模，複雑度，広がりの絶えざる. が内在していることも彼は指摘している．. 増大がある．「ソフトウェア危機」が喧伝された，1970. Littlewood らもソフトウェアシステムの多くの問題. 年前後は，メガステップ，すなわち 100 万行のソフトウェ. の原因が既知の設計問題にあることを指摘している. 340. 45 巻 4 号情報処理 2004 年 4 月. 24）. ．.

(3) 特集：安全で安心できる e- 社会を実現するソフトウェアとシステム技術. カテゴリと名称. 内容. I：致命的（Catastrophic）. 致死，システムの喪失，$100 万以上の損害，違法で重大な環境破壊. II：危機的（Critical）. 身体的機能不全，3 名以上の傷害や疾病，$20 万以上 $100 万未満の損害，違法で修復不可能な環境破壊. III：限界的（Marginal）. 1 名の傷害や 1 日以上の業務ができなくなる疾病， $1 万以上 $20 万未満の損害，違法でなく修復可能な環境破壊. IV：無視し得る（Negligible）. 業務不可には至らない傷害や疾病の可能性，$2,000 以上 $1 万未満の損害，違法ではない最小の環境破壊. レベルと名称. システムの障害発生確率. A：頻発（Frequent）. 頻繁に発生. B：起こり得る（Probable）. 耐用期間中に数回発 10-1 > X > 生 10-2. 頻繁に発生. C：稀に発生（Occasional）. 耐用期間中に時には 10-2 > X > 発生 10-3. 耐用期間中に数回発生. D：起こりそう耐用期間中にはあり 10-3 > X > にないそうにないが起こり 10-6 （Remote）得る. 耐用期間中に起こりそうにないが，起こり得る. E：起こらない（Improbable）. 表 -1 MIL-STD-882D の損害分類. 特定要素の障害発生確率 X > 10-1. 起こらないとみなせ 10-6 > X る. 絶えず経験. 起こりそうにないが可能性はある. 表 -2 MIL-STD-882D の障害発生確率の分類. また，Wood はユーザにおけるシステム障害の原因の 50% 以上が既知のバグであることを示している. 53）. ．. ■ 不十分な検証・試験. Requirements）となり，その後の多くの安全性基準の. 米国の NIST（National Institute of Standards Tech-. 元となった．最新版は，2000 年に発行された MIL-STD-. nology）が 2002 年にまとめた試算では，ソフトウェア. 882D である. の低品質によって米国経済は年間約 600 億ドル（7.2 兆. ■ 安全性のモデル. 円），すなわち GDP の 0.6% の損失をこうむっていると. 安全性とリスクは表裏一体の関係にある．リスクとは. いう. 36）. ．これを我が国の 2002 年度の GDP に換算する. と 3 兆円の損失に相当する．. 48）. ．. 「何らかの問題が起こる可能性」である．一般に，次の式（1）で定義される．リスク＝障害による損失の大きさ×障害発生確率（1）. ソフトウェアシステムの安全性とリスクに関する諸概念. ここで，障害（failure）とは，システムの停止，機能不全，処理性能の低下などを意味する．障害や誤り（error）. システムの安全性とリスクの基本概念. の原因を故障（fault）と呼ぶ．傷害発生確率の逆数は. ソフトウェア品質の一般的な分類は ISO/IEC-9126. 障害が発生しない期間の期待値である．障害によって修. “Software Engineering - Product Quality”（JIS X0129. 理をしないことを仮定するシステムでは，システムの寿. 「ソフトウェア製品の品質」）として標準化されている．. 命となる．. さらに，ソフトウェアの信頼性や安全性を具体的に考え. ■ 安全性の基準. るために，下記に示す，踏み込んださまざまな概念が提. MIL-STD-882D では，システムの安全性を損害. 唱されている．. （mishap）の大きさと発生確率で，それぞれ，表 -1. ■ 安全性と信頼性. と表 -2 に示すように段階的かつ具体的に定義してい. まず，安全性と信頼性は異なる概念であり，場合によっ. る. ては，相反する要求であることに留意しよう．. 元の表として設計目標を定めることができる．. 48）. ．設計者は，この 2 つの尺度を組み合わせて，2 次. システムの信頼性（reliability）とは，システムが機能を提供し続ける確度である．システムの実行結果は問. システムの安全性の諸定義. わない．. システムの安全性に関する定義が，異なる視点や研究. 一方，システムの安全性（safety）は実行結果に関す. のアプローチから提案されている. る概念であり，人や財産，環境などに害をもたらさない. ■ セフティクリティカルとミッションクリティカル. ことである．安全性のためには信頼性を制限する必要も. セフティクリティカル（Safety-Critical）とは，故障. あり得る．. が人命の損失，大規模環境破壊，巨額の経済的損失など. システムの安全性に関する最初の体系化は米国空軍が. の致命的な結果をもたらす可能性があるシステムであ. 1966 年に発行した MIL-S-38130A（システム安全性仕. る．航空機の飛行制御や列車の運行制御などの交通運輸. 様：System Safety Specification）といわれている．こ. システム，医療機器，などがある．. れが，1969 年に MIL-STD-882（System Safety Program. 一方，オンライントランザクション処理システムや通. 42），46），51）. ．. IPSJ Magazine Vol.45 No.4 Apr. 2004. 341.

(4) 信システム，企業の基幹業務システムなどでは，故障に障害耐力. よって致命的な結果には至らないが，ミッション，すなわちある目的や仕事の達成が求められる．このようなと呼ぶ．セフティクリティカルとミッションクリティカルを障害率で単純に比較することはできないが，一般に，10. -6. 完全機能維持. 部分的機能維持. 処理停止障害部分隔離. 機能提供への迅速な復帰. FailOperational. FailActive. Fail-Safe. HighAvailability. Dependability/Survivability. 9）. の障害率が両者を区別する目安である． ■ 耐故障性：フォールトトレランスとフェイルセーフ. 処理中断. 処理継続. システムをミッションクリティカル（Mission-Critical）. 32）. High-Assurance/High-Integrity. 図 -3 に示すように，システムの構成要素の故障への耐力として定義する．フォールトトレランス（Fault-. 図 -3 障害耐力に基づく分類. Tolerance）とは故障の発生にもかかわらずシステムは何らかの機能を提供しつづけることである．一方，ファイ -9. ルセーフ（Fail-Safe）は，結果に関する概念であり，故. ムの障害率は，米国連邦航空局（FAA）が 10 以下で. 障が起きても結果の安全性を保証するものである．. あることを定めている．. ■ デペンダビリティとサバイバビリティデペンダビリティ（Dependability）は，フォールトトレランスの一種の概念として，Lapie が 80 年代初め. 安全なシステムを開発するソフトウェア工学の枠組み. に提唱した．フォールトトレランスが故障への対応を. システム障害の多くの原因がソフトウェア開発にある. 重視していることに対し，ある水準のサービスを提供し. ことから，安全性や品質保証など，さまざまな取り組み. つづけることを重視し，信頼性，可用性（availability），. が行われてきた. 安全性，セキュリティを含む広い概念である. 28）， 33）. ．ヨー. 20），22），46）. ．しかし，リスクの増大に応. じた体系的・組織的な取り組みがされているとは言い難 8）. ロッパを中心に研究開発が行われてきた．. い．安全性を保証し，高いリスクを克服するソフトウェ. デペンダビリティと類似の概念にサバイバビリティ. ア工学の研究・開発と実践を推進する必要がある. （Survivability）がある. 12），18）. ．システムの故障や外. 2）. 学. Services）と呼ぶ重要なサービスを一定の品質（Essential. ら，技術の融合が望まれる. Properties）で維持できる特性である. ．90 年代後半. ．. また，情報セキュリティを対象とするセキュリティ工. 部からの攻撃などが起きても主要サービス（Essential 30）. 28）. とソフトウェア工学は相補的な関係にあることか 44）. ．. ここでは，安全性の実現の視点から開発技術と管理技. から米国国防総省を中心に研究開発が行われている．. 術を紹介する．さらに，失敗の経験をフィードバックす. ■ ハイアシュアランス. る仕組みを述べる．. ハイアシュアランス（High-Assurance）はシステム開発の視点から分類した概念である. 29）. ．開発の不完全. 開発技術. 性を前提に，形式的手法などを用いて，システムの安全. 安全なシステムを実現するためには，次の 2 つのアプ. 性の確度を実証的に高めるアプローチである．類似の概. ローチがある．. 念にハイインテグリティ（High-Integrity）がある. 52）. ．. 1）高い安全性の作り込み：組込みソフトウェアなどの変更できないソフトウェアでは，それ自体が高い安全. システムの安全性の基準いくつかのシステムや領域では，安全性や信頼性の基準が定められている. 33）. ．. たとえば，ミッションクリティカルである電話交換システムでは，20 年間連続稼働して停止時間が 1 時間未満，. 性を達成することが求められる． 2）一定の故障の発生を許容し，故障に耐える頑健な設計とする．大規模システムなどでは，冗長構成などによって故障を局所化したり，自己修復を可能とする．開発技術を開発プロセスに沿って概観しよう． 11），51）. すなわち，5.7*10 であることが，ATT や NTT の技術. ■ ハザード分析. 基準で定められている．さらに，障害からの平均復旧時. ハザード（Hazard）とはシステムの故障や障害を引. 間（MTTR: Mean Time To Repair）も定められている．. き起こす可能性のある状態やシナリオである．システム. セフティクリティカルである航空機の飛行制御システ. はハザードの数だけリスクがある．まず，ハザードを特. -6. 342. 45 巻 4 号情報処理 2004 年 4 月.

(5) 特集：安全で安心できる e- 社会を実現するソフトウェアとシステム技術. 対象システム. 分析方法. 適用プロセス概念設計. システムの潜在ハザードとその影響を把握. 故障木解析（FTA）. アーキテクチャ. トップダウン分析：システムのトップ事象から原因となる基本事象へ分解. 事象木解析（ETA）. オペレーション. ある事象の発生からその対応に沿った事象の生起プロセス（影響範囲）を分析. 設計. ボトムアップ解析：要素（コンポーネント）の障害がシステム全体に及ぼす影響の分析. チェックリスト法. 全ライフサイクル. What-if 法. 作業安全分析（JSA）. オペレーション. 操作ごとのハザードの抽出. チェックリスト法. 全ライフサイクル. What-if 法. チェックリスト法. 全ライフサイクル. What-if 法：安全に対する企業文化（Safety Culture）. 故障モード影響解析（FMEA/FMECA）人組織. 内容. 予備ハザード分析（PHA）. 表 -3 ハザード分析の方法. 定する．これをハザード分析（Hazard Analysis）と呼ぶ．主なハザード分析の方法を表 -3 に示し，その中の故障. λ. コンピュータウイルスの感染. λ=λ1×λ2 =(λ11+・・)(λ21+λ22). 木解析（FTA: Fault Tee Analysis）の例を図 -4 に示す． λ1. ソフトウェアシステムのハザード分析の事例として，. ウイルスの受信防護不可. AND. ワクチンの効果無効. Lutz らはチェックリスト法を航空機のコクピットの仕様に適用し，有効性を示した. λ2 OR. 27）. ．さらに，ソフトウェ. ア故障木解析（SFTA: Software FTA）とソフトウェア故障モード影響解析（SFMEA: Software Fault Mode and. サーバのフィルタリングもれ. Effects Analysis）を組み合わせる方法も提案している．. λ11. ■ 業務やシステムの安全性を保証する要求工学要求分析において，機能的要求だけでは要求の全体像. ワクチンソフトウェアインストールもれ λ21. パターンファイル更新もれ λ22. 図 -4 故障木解析（FTA）の例. は捉えられない．そのため，安全性や信頼性などの非機能的要求（NFR: Non-Functional Requirements）の分析方法が 90 年代から研究されている．最近は，セキュリ. 疵が安全性の問題点となる．ビジネスプロセス分析では，. ティや安全性などの要求が重視されている．. 従事する人を含む情報の流れや処理の分析を通して安全. 航空機の飛行制御システムや航空管制システム，ある. 性やセキュリティの要求を明らかにする必要がある．. いは，鉄道，自動車などの人が介在するセフティクリティ. ■ 安全なシステムとソフトウェアアーキテクチャの設計. カルシステムでは，システムを操作する人も含めて安全. a）アーキテクチャ設計がシステムの特性を決定する. 性の要求を分析する必要がある．このため，ユーザがシ. アーキテクチャはシステムとソフトウェアの骨格と振. ステムを利用するシナリオに基づく分析方法が提案され. 舞いを決めることから，安全性などの非機能的特性を決. ている．. 定する主因である．換言すれば，同一の機能を実現する. 一方，要求のセキュリティを分析する方法として，悪. アーキテクチャは複数あり，その違いは非機能的特性に. 意のユーザなどのリスクをオブジェクト指向分析の標準. ある．. 表記法である UML のユースケースで表現する方法が提. アーキテクチャには，ハードウェアを含むシステム. 案されている．これらは，ミスユースケース（Misuse. アーキテクチャとソフトウェアアーキテクチャがある．. 1）. Cases）. 30）. やアビューズケース（Abuse Case）. と呼. 2）. セフティクリティカルシステム，ミッションクリティカ. ばれる．. ルシステムの要求目標を達成するためには，システム. 顧客やユーザなど，要求の利害関係者（stakeholder）. アーキテクチャ，ハードウェアアーキテクチャ，ソフト. の利害が一致しないことが開発の主要なリスクとなり得. ウェアアーキテクチャを統合した設計が必要である. る．そのため，利害関係者を明らかにし，分析する方法. 企業情報システムでは，ビジネスの構造をビジネス. としてステークホルダ分析（Stakeholder Analysis）が. アーキテクチャと呼ぶ．また，ドメイン（対象アプリ. ある．. ケーションの領域）ごとのソフトウェアアーキテクチャ. 一方，企業情報システムでは，ビジネスプロセスの瑕. をドメイン指向ソフトウェアアーキテクチャ（Domain-. IPSJ Magazine Vol.45 No.4 Apr. 2004. 32）. ．. 343.

(6) なシステムにはさまざまな構造が考えられるが，代表ビジネスアーキテクチャ. コンピューティングがある．. データアーキテクチャ. データアーキテクチャ. 現在では，インターネットやさまざまな市販製品（COTS: Commercial-Off-The Shelf）のハードウェアや. アプリケーションアーキテクチャ. アプリケーションアーキテクチャ. ソフトウェアを組み合わせた脆弱な基盤の上でシステ. テクノロジーアーキテクチャ. ムを構築することが前提となっている．集中的な制御. 目標 (Target/To-Be). テクノロジーアーキテクチャ. 現状 (Baseline/As-IS). 例として IBM の提唱するオートノミック（Autonomic）. ビジネスアーキテクチャ. アーキテクチャモデル. 標準. も困難である．安全性の確保は困難な問題である．システムの状態を知り，故障の発見と対応を行うために，. 移行プロセス. ハードウェアからソフトウェアへ至る各階層とコンポーネントごとに，組込み自己診断機構 BITE（Built-In Test. 図 -5 EA のフレームワーク. Equipment）やチェック機構による誤り検出が組み込まれている． Specific Software Architecture）と呼ぶ．. ■ 安全なプログラムの設計・プログラミング技術. アーキテクチャの設計には対象アプリケーションドメ. a）新たなモジュール化の方法とプログラミング言語. インの知識，さまざまなアーキテクチャの特性，利用す. 安全性や品質，セキュリティなどの非機能的特性はシ. るフレームワークの理解，さまざまな要素技術の理解な. ステム全体にわたる横断的特性であることから，従来の. ど総合的な設計力が求められる．ゼロから設計すること. 機能やオブジェクトを単位とする設計・プログラミング. は困難である．そのため，アーキテクチャの設計技術を. 技術だけでは扱うことが困難である．このような特性を. 整理・体系化する必要がある．. 設計・実装する方法としては，次の 2 つが考えられる．. 1 つの体系的なアプローチとして，モデル駆動アーキテクチャ（MDA: Model-Driven Architecture）がある. 31）. ．. また，図 -5 に示す EA（Enterprise Architecture）が. 1）プログラムとは独立した制御機構の導入：たとえば，ポリシー制御としてプログラムとは別の機構を導入する方法である．. ．開発技術をビジネス，データ，アプリケーショ. 2）アスペクト指向プログラミング（AOP: Aspect-. ン，テクノロジーの 4 階層で整理し，それぞれ，現状か. Oriented Programming）：AOP はアスペクトと呼ぶ. ら目標へ移行する移行プロセスと利用できる標準を体系. システムの特性ごとにモジュール化を可能とする多次. 化している．米国では，1996 年の IT マネジメント再構. 元のモジュール化の機構である. 築法（IT Management Reform Act）により政府調達で. プログラミング言語の代表例は Java 言語を拡張した. EA の利用を義務付けている．我が国の政府でも，導入. AspectJ である．C 言語を用いた多くのシステムでも. が進められている．. セキュリティを保証する必要があることから，セキュ. b）安全性を実現するアーキテクチャの要素技術. リティをアスペクトとして扱うための C 言語を拡張し. システムのリスクを軽減し，安全性を保証するために. たアスペクト指向プログラミング言語も提案されてい. は，リスク管理の機構をシステムの機構として組み込む. る. ある. 16）. 31）. ．アスペクト指向. 49）. ．今後の研究・開発が期待される．. 必要がある．. b）設計におけるリスク分散. リスクを分散するアーキテクチャとしては，ハード. ソフトウェアの設計においても，ハードウェア設計で. ウェアとソフトウェアの冗長構成（redundancy）がある．. 開発された安全性を高める機構を応用して，ソフトウェ. ハードウェアと組み合わせた二重化などの技術は，大規. アの安全性を高めることができる．ロックイン，インター. 模システムで長年実用化されてきた．また，異種冗長構. ロック，ウォッチドッグタイマ，などがある．故障の発. 成として，ハードウェアでは異なるプロセッサを用いる. 生する踏み切り制御システムで，そのままではフェイル. 方法がある．ソフトウェアでは，異なるアルゴリズム，. セーフでない設計を，インターロックを付加して，フェ. プログラミング言語，開発チームで実装する N- バージョ. イルセーフにできる設計例が示されている. ンプログラミングがある．. 特に，安全性を要求されるソフトウェアシステムでは，. 一方，要素の故障を前提として，故障しても何らかの. 多様な例外に対応する必要があることから，その制御は. 修復を行うシステムを自己修復（Self-Healing），ROC. 複雑になる．. （Recovery-Oriented Computing）と呼ぶ. 344. 45 巻 4 号情報処理 2004 年 4 月. 37）. ．このよう. 3），22）. ．.

(7) 特集：安全で安心できる e- 社会を実現するソフトウェアとシステム技術. c）型とプログラミング言語の頑健性ソフトウェアの安全性の基礎は，プログラムの安全性である. 実世界（問題）. 47）. ．Spafford が指摘したようにプログラミング. 言語の選択は基礎的で重要な要因である. 実世界（問題）. 実装ソフトウェア. 人手. 人手. 人手. 45）. ．Java や C#. かし，実際には，組込みソフトウェアなど多くのソフトウェアが C 言語で実装されている．Pournelle は「もしコンパイル時に強い型チェックと範囲チェックを行って. 解析実行. 試験実行. 解析ソフトウェア. 実装ソフトウェア. 静的解析の方法. 試験の方法. いれば，WindowsXP のバッファオーバーフローを利用した問題は防げるのではないか」と指摘している. 試験仕様の記述. モデルと解析すべき性質の記述. などの強い型付けの言語を利用することが望まれる．し. 図 -6 ソフトウェアの静的解析と試験. 40）. ．. d）形式的手法ハイアシュアランスシステムなどの高い安全性や信頼性を実現するために，形式手法（Formal Methods）の適用が研究されている．交通運輸システムへの適用が試みられている. 52）. が，まだ，広く普及するには至ってい. 理にも高い能力が求められている．このため，PMI （Project Management Institute）. の PMBOK（Project. Management Body of Knowledge）の導入など，プロジェクト管理の強化が現場で進められている．さらに，. ない．今後の研究が待たれる．. プロジェクト管理を組織的に支援する PMO（Project. ■ 解析・試験技術. Management Office）制度が導入されている．. ソフトウェアの正しさを確認する方法には，図 -6 に. 一方，システムや開発プロジェクトのリスクの増大に. 示すように，モデル検査（Model Checking）などの静. 伴い，リスク管理の重要性が認識されている. 的解析（Static Analysis）とプログラムを実行する試. スクはベンダの開発リスクにとどまらず，ユーザにおけ. 10），51）. ．リ. ．それぞれ，長所と短所がある．近年，モ. る運用リスクもある．さらに，開発リスクは，一般にベ. デル検査などの応用が進んでいる．たとえば，Jha と. ンダが担う傾向にあるが，開発が破綻すればユーザも損. Wing は，銀行間のネットワークにモデル検査を適用し. 失をこうむる．ソフトウェア開発における問題の主因が. 験がある. 54）. てサバイバビリティの検証を行った. 17）. ．. 要求仕様にあることから，要求分析と上流工程からのリ. 特に，安全性などの非機能的特性はシステム全体にわ. スク管理が重要である．. たる横断的特性であるので，人手による検証が困難であ. リスク管理へのトップマネジメントの関与と全社の組. る．一方，モデル検査では，人手によるモデル化が必要. 織的取組みが不可欠となっている．これを全社的リスク. であり，かつ，状態爆発による計算時間の増大とバラン. 管理（ERM: Enterprise Risk Management）. スをとった適切なモデル化が必要となるという課題も. リスクは損失という負の面が強調されがちであるが，リ. ある．. スクと機会とは相対的な概念であることから，ERM で. 14）. と呼ぶ，. はリスクと機会の統合した評価も提案されている．. 開発管理. ■ 人材育成. ■ 開発プロセス：インクリメンタルプロセスによるリ. 高いリスクを克服し，必要な技術を活用できる高度なソフトウェア技術者の育成が急務である．システムやソ. スク低減 Boehm が 1986 年に提唱したスパイラルプロセスはリ. フトウェアのアーキテクチャを設計できるシステムアー. スク駆動開発と呼ばれ，開発リスクに応じた技術の利用. キテクトやソフトウェアアーキテクト，あるいは，プロ. を提案した．しかし，プロセスの形状のみが注目され，. ジェクトマネジャの育成が求められる．. その意味は広く理解されなかった．. また，大学などの学生や企業の技術者がソフトウェア. 90 年代になって，オブジェクト指向技術のもたらし. システムの安全性の重要性を認識する必要もある. たモジュール性の向上がインクリメンタルプロセスの利. ユーザにおいても，システムの戦略的立案や開発・運. 用を促した．インクリメンタルプロセスは，開発を小さ. 用に権限と責任を持つ CIO（Chief Information Officer）. な単位に分割し，段階的に開発することにより，開発リ. の制度化と育成が必要である．. 5）. ☆1. ．. 6）. スクを軽減する． ■ プロジェクト管理とリスク管理開発技術のリスクの増大とともにプロジェクト管. ☆1. 本稿の内容の一部は学部 2 年生の必修科目である「技術倫理」の教材として利用している．. IPSJ Magazine Vol.45 No.4 Apr. 2004. 345.

(8) 失敗から学ぶために. も考慮する必要があろう．. これまで，我が国では大規模システム障害に対して開. ユーザにおいても，ソフトウェアシステムの運用リ. 発企業内では情報の蓄積や分析がされてきたが，それを. スク管理が組織的に取り組まれるようになった．たとえ. 活用して産業界全体へフィードバックする仕組みが欠け. ば，コンピュータシステムの運用が業務と直結する金融. ていた．損害をこうむった社会への説明も十分にされて. では，オペレーショナルリスクの主要な要素としてシス. いるとは言い難い．システムの社会的責任がきわめて重. テムリスクを位置づけている. いことから，問題を分析し，知見を共有し，フィードバッ. れた「金融検査マニュアル」には「システムリスク管理. クする仕組みが必要である．現状では「解剖なき医学」. 態勢の確認検査用チェックリスト」が示され，金融庁に. である. 43）. ．. よる検査対象となっている. 14），43）. ．1999 年に導入さ. 19）. ．. 米国では，前述したいくつかの巨大システム開発の破綻に対し，会計検査院などが主導して専門化による分析が行われた．その結果，90 年代後半に政府調達制度. ユーザとベンダがともに進化・発展するために. が改革された．失敗を活かすためには，米国のような. ソフトウェアシステムは，ユーザ，すなわち，社会や. システム障害の分析を行い，フィードバックする仕組. 企業，個人の活動をコンピュータで擬似し，代替するこ. みが必要である．他の工学分野の先人に学ぶ必要があ. とから，ユーザとベンダは表裏一体の関係にある．今後，. る. 15），39）. ．1 つのアプローチは，システムのユーザとベ. 業務システムに加え，組込み／ユビキタスシステムの急. ンダから独立した専門家による第三者機関の設置であ. 速な進化と社会への浸透が予想されることから，ソフト. る．交通運輸における事故調査委員会がモデルとなるだ. ウェアシステムのリスクは一層高まるだろう．ソフト. ろう．. ウェアシステムのリスクはベンダとユーザの共通の課題. また，我が国のソフトウェア産業は，長年，受託開発. であることを認識し，協調して取り組む必要がある．. が中心である．ソフトウェアベンダの収益は稼働工数（人. 社会のソフトウェアシステムの安全性への関心が高. 月）で決まることから，技術力（生産性）の向上が逆に. まっていることは，ベンダにとっても，より高品質で安. 収益の低下を招くことになる．現場におけるソフトウェ. 全なシステムの開発を促す．品質や安全性が差別化の鍵. アシステムの開発技術の向上が進まないという背景に. となる．逆に，事故や障害はビジネスの存亡にかかわる. は，我が国のソフトウェア産業のビジネス慣行と構造の. 可能性があることは，他の分野で今日経験していること. 問題がある．. である．私たちの責務は重い．. 4）. ソフトウェアシステムの安全性に関する研究開発の課. 安心できるシステムへ「安全」が技術的課題であるのに対し，「安心」は心理. 題は多い．ソフトウェアシステムにかかわる研究者，技術者，経営者が本稿で述べた課題に挑戦することを期待する．. 的，社会的課題である．人々が安心できるためには，社会制度の整備とその適切な運営や情報の公開，説明責任の遂行，教育や広報などの活動が必要である． ■ 安全性の標準化と基準電話交換システムや航空管制システムなど，これまで社会基盤を担うシステムでは，信頼性などの基準が定められている．しかし，インターネットや COTS を利用したシステムなどの新しい基盤では脆弱性が高まるリスクがあるにもかかわらず，基準が定められていない．安心できる基盤として，ソフトウェアシステムの信頼性や安全性の共通基準（Common Criteria）を定め，保証する必要がある． ■ 安全性の検査と保証・認定制度安全性の観点から，ソフトウェア保証（Software 50）. Certification）. 346. やソフトウェア技術者の認定制度など. 45 巻 4 号情報処理 2004 年 4 月. 参考文献 1）Alexander, I.: Misuse Cases: Use Cases with Hostile Internet, IEEE Software, Vol.20, No.1, pp.58-66（Jan./Feb. 2003）． 2）Anderson, R.: Security Engineering: A Guide to Building Dependable Distributed Systems, John Wiley & Sons（2001）,［トップスタジオ（訳）, 情報セキュリティ技術大全 , 日経 BP 社（2002）］． 3）青山幹雄ほか : ペトリネットの理論と実践 , 朝倉書店（1995）． 4）青山幹雄 : コンピュータが消える日 : インターネット時代のソフトウェア , 情報処理 , Vol.41, No.5, pp.523-527（May 2000）． 5）青山幹雄 : ソフトウェア技術者のグローバルスタンダード化 , 情報処理 , Vol.39, No.11, pp.1144-1147（Nov. 1998）． 6）青山幹雄 , 中谷多哉子（編著）: オブジェクト指向に強くなる , 技術評論社（2003）． 7）青山幹雄 : 情報技術と航空の共進化 : グローバルな航空 IT ネットワークの形成 , 情報処理 , Vol.44, No.12, pp.1253-1259（Dec. 2003）． 8）Committee on Information Technology Research in a Competitive World: Making IT Better: Expanding Information Technology Research to Meet Society's Needs, The National Academies Press（2000）． 9）Cooling, J.: Software Engineering for Real-Time Systems, Addison Wesley（2003）． 10）DeMarco, T. and Lister, T.: Waltzing with Bears, Dorset House（2003）, ［伊豆原弓（訳）: 熊とワルツを , 日経 BP 社（2003）］． 11）Dunn, W. R.: Designing Safety-Critical Computer Systems, IEEE Computer, Vol.36, No.11, pp.40-46（Nov. 2003）． 12）Ellison, R. J.: Survivability: Protecting Your Critical Systems, IEEE.

(9) 特集：安全で安心できる e- 社会を実現するソフトウェアとシステム技術. Internet Computing, Vol.3, No.6（Nov./Dec. 1999）, http://www.cert. org/archive/html/protect-critical-systems.html 13） Ewusi-Mensah, K.: Software Development Failures, MIT Press （2003）． 14）原誠一 : オペレーショナルリスク管理入門 , 日本経済新聞社（2004）． 15）畑村洋太郎 : 失敗学のすすめ , 講談社（2000）． 16）IBM ビジネスコンサルティングサービス IT 戦略グループ : エンタープライズ・アーキテクチャ , 日経 BP 社（2003）． 17）Jha, S. and Wing, J. M.: Survivability Analysis of Networked Systems, Proc. ICSE 2001, ACM Press, pp.307-317（May 2001）． 18）Jones, A.: The Challenge of Building Survivable InformationIntensive Systems, IEEE Computer, Vol.33, No.8, pp.39-43（Aug. 2000）． 19）金融庁 : 金融検査マニュアル（1999）, http://www.fsa.go.jp/ manual/manual.html 20）Knight, J.（ed.）: Special Issue on Safety-Critical Systems, IEEE Software, Vol.11, No.1, pp.16-67（Jan. 1994）． 21）Leveson, N. and Turner, C. S.: An Investigation of the Therac-25 Accidents, IEEE Computer, Vol.26, No.7, pp.16-41（1993）． 22）Leveson, N. G.: Safeware, Addison Wesley（1995）． 23）Lions, J. L.: ARIANE 5 Flight 501 Failure Report by the Inquiry Board （1996）, http://ravel.esrin.esa.it/docs/esa-x-1819eng.pdf 24）Littlewood, B. and Strigini, L.: Software Reliability and Dependability: A Roadmap, Proc. of ICSE 2000: The Future of Software Engineering, ACM Press, pp.175-188（2000）． 25）Lloyd, P. T. L. and Galambos, G. M.: Technical Reference Architectures, IBM Systems Journal, Vol.38, No.1, pp.51-75（1999）． 26）Lutz, R. R.: Analyzing Software Requirements Error in Safety-Critical Embedded Systems, Proc. IEEE RE '93, IEEE CS Press, pp.126-133 （1993）． 27）Lutz, R. R. et al.: Safety Analysis of Requirements for a Product Family, Proc. IEEE ICRE '98, IEEE CS Press, pp.24-33（1998）． 28）Lutz, R. R.: Software Engineering for Safety: A Roadmap. Proc. ICSE 2000: The Future of Software Engineering, ACM Press, pp.215-224 （2000）． 29）McLean, J. and Heitmeyer, C.: High-Assurance Computing Systems: A Research Agenda, America in the Age of Information（1995）, http://chacs.nrl.navy.mil/publications/CHACS/1995/ 1995mclean-NSTCCIC.pdf 30）Mead, N. R.: Requirements Engineering for Survivable Systems, CMU/SEI-2003-TN-013（2003）． 31）三ツ井欽一（編）: モデリングとツールを駆使したこれからのソフトウェア開発技法−モデル駆動開発手法を中心として− , 情報処理 , Vol.45, No.1, pp.1-33（Jan. 2004）． 32）南谷崇 : フォールトトレラントコンピュータ , オーム社（1991）． 33）夏目武 : ソフトウェアのディペンダビリティ（信頼性）と規格化の動向 , 電子情報通信学会誌 , Vol.87, No.3, pp.215-219（Mar. 2004）． 34）Neumann, P. G.: Computer Related Risks, ACM Press Series, Addison Wesley（1995）,［滝沢徹ほか（訳）: あぶないコンピュータ , ピアソンエデュケーション（1999）］, http://catless.ncl.ac.uk/Risks/ 35）日経コンピュータ（編）: システム障害はなぜ起きたか−みずほの教訓 , 日経 BP 社（2002）．. 36）NIST: The Economic Impacts of Inadequate Infrastructure for Software Testing（2002）． 37）Patterson, D. et al.: Recovery Oriented Computing（ROC）: Motivation, Definition, Techniques, and Case Studies, Technical Report, UCB/CSD-02-1175（2002）, http://swig.stanford.edu/public/ projects/roc/ 38）Peterson, I.: Fatal Defect: Chasing Killer Computer Bugs, Vintage Books（1996）,［伊豆原弓（訳）: 殺人バグを追え , 日経 BP 社（1997）］． 39）Petroski, H.: Design Paradigms: Case Histories of Error and Judgment, Cambridge University Press（1994）,［中島秀人ほか（訳）: 橋はなぜ落ちたのか : 設計の失敗学 , 朝日新聞社（2001）］． 40）Pournelle, J. E.: The Security Problems Plaguing a Flashback to the Language Wars, BYTE.com（Nov. 2003）,［Longhorn と言語論争 , 日経バイト , pp.128-133（Jan. 2004）］． 41）President's Information Technology Advisory Committee: Information Technology Research: Inventing in Our Future（1999）, http://www.ccic.gov/pitac/report/ 42）Rushby, J.: Critical System Properties: Survey and Taxonomy, Reliability Engineering and System Safety, Vol.43, No.2, pp.189-214 （1994）, http://www.csl.sri.com/papers/csl-93-1/ 43）先端リスク研究会（編）: システムリスクに挑む ,（社）金融財政事情研究会（2003）． 44）Spafford, E. H.: Relating Software Engineering and Information Security, Keynote at ICSE 03（May. 2003）, http://www.icse-conferences.org/2003/events/spafford-keynote.pdf 45）Spafford, E. H.: Exploiting Common Criteria: Can it Ensure that the Federal Government Gets Needed Security（Sep. 2003）, http:// reform.house.gov/UploadedFiles/spaf.pdf 46） Storey, N.: Safety-Critical Computer Systems, Addison Wesley （1996）． 47）Szyperski, C. and Gough, J.: The Role of Programming Languages in the Life-Cycle of Safe Systems, Proc. of STQ（Int'l Conf. on Safety through Quality）'95, http://www.research.microsoft.com/users/ cszypers/pub/（1995）． 48）US DoD: Standard Practice for System Safety, MIL-STD-882D（2000）． 49）Viega, J. et al.: Applying Aspect-Oriented Programming to Security, Cutter IT Journal, Vol.14, No.2, pp.31-39（Feb. 2001）． 50）Voas, J.（ed.）: Software Certification, IEEE Software, Vol.16, No.4, pp.22-54（Jul./Aug. 1999）． 51）Wang, J. X. and Roush, M. L.: What Every Engineer Should Know about Risk Engineering and Management, Marcel Dekker（2000）,［日本技術士会（訳）: リスク分析工学 , 丸善（2003）］． 52）Winter, V. L. et al.（eds.）: High-Integrity Software, Kluwer Academic（2001）． 53）Wood, A. P.: Software Reliability from the Customer View, IEEE Computer, Vol.36, No.8, pp.37-42（Aug. 2003）． 54）Young, M.: Symbiosis of Static Analysis and Software Testing, Keynote at SEHAS 2003（May 2003）, http:// www.sei.cmu.edu/ community/sehas-workshop/young/ （平成 16 年 3 月 16 日受付）. 幽霊電話私が企業で電話交換機のソフトウェアの開発に従事していた時の体験である．ある顧客でシステム障害が起き，問題が解決した後，運用監視のため毎日交代で客先に詰めることになった．朝，客先に出向くと会社への窓口担当の人から，電話に関するクレームがきているので対処して欲しいと言われた．ある職場で，毎日正午になると電話が鳴るが，受話器を取っても誰も出ないので，気味が悪いということであった．電話交換機が障害を起こしたことは各職場に通知されていたので，まだ異常があるのではないかということである．その職場に案内してもらった．4 つのスチール製の事務机が向き合う中央に少し高まった電話台があり，その上に電話機が載っている．見ると，電話台の傍に小さな目覚まし時計がある．私は，これではないかと思った．その持ち主に「目覚まし時計を設定していませんか」と尋ねたが，「そんなことはない」と強く否定された．そこで，正午前にまた来ることとなった．さて正午である．ジリジリと音がした．やはり目覚まし時計の音である．その目覚まし時計を持ち上げ，電話から離した．皆，すぐ，納得した．仕事で電話機を毎日のように操作していると，ベルの音は聞き違えない．目覚ましの音とはかなり違う．しかし，まず，「電話交換機がおかしい」という不信感があって，似たようなジリジリという音がすると，やはり電話機がおかしいと思ってしまったようだ．この場合は物理的な現象で納得していただくのは簡単だった．しかし，ソフトウェアのバグが原因で障害を起こして，不信感で一杯の顧客に説明を納得してもらうのは難しい．その頃，ある人の発案で，部門内の失敗談集を作った．その冊子の書名は「ないしょ話」．. IPSJ Magazine Vol.45 No.4 Apr. 2004. 347.

(10)