Transcript 発表資料
事故事例分析に基づく 情報システム調達のリスク対策 湯浦研究室修士2年 齋田芽久美 2015/02/17 目次 1.背景と目的 2.従来の要件定義支援方法 3.関連研究 4.研究アプローチ 5.要件定義支援環境デモ 6.考察 7.評価 8.今後の課題 1.背景と目的 要件定義の重要性 -要件定義は難しい 出典：IPA アンケート調査報告2005/6/29-7/1 SODECにおけるアンケートによる 『失敗の原因が要件定義書 にあると思われる割合について』 出典：JUAS ソフトウェア開発管理基準 に関する調査報告書(2015.2) 『工期遅延理由』 →要件定義の学習・作成を支援する 2.従来の要件定義支援方法 TRMと非機能要求グレード -TRM 経済産業省から提供されている 物品調達編と役務調達編で構成されている -非機能要求グレード IPAから提供されている 非機能要求を6つの大項目，34の中項目， 116の小項目で分類 2.従来の要件定義支援方法 TRM | 物品調達編 システムを構成してい る機能・サービスを 18のドメインに分類 機能要件，非機能要件 が記述されている 2.従来の要件定義支援方法 TRM | 役務調達編 システム ライフサイクルを ・企画 ・要件定義 ・開発 ・運用・保守 の4つに分ける 2.従来の要件定義支援方法 TRM | 役務調達編 ・概要 ・用意する資料 ・作成する資料 ・記載すべきポイント ・記載例 ・留意すべき点 2.従来の要件定義支援方法 非機能要求グレード -6大項目，34中項目，116小項目 ・可用性 ・性能・拡張性 ・運用・保守性 ・移行性 ・セキュリティ ・システム環境・エコロジー 3.関連研究 関連研究 -金融システムの成功要因を特定する 「金融事業経営における情報システム開発のリスク マネジメント観点の提案」 慶應義塾大学大学院遠藤らの研究では，金融システム開発 局面でのリスクマネジメントを取り上げている． 本研究と同じく「動かないコンピュータ」の事例に立脚し つつ，成功に不可欠な6つの要因を提言した． -RFPの品質を定量的に評価する 「非機能要件に着目したRFP評価」 奈良先端科学技術大学院齊藤らの研究では， 「保守と運用に関する55の非機能件」のみに定め， ベンダーへの提案依頼書の品質を定量的に評価する方法を 提案した． 4.研究アプローチ 研究手順 STEP1 事故事例を収集 STEP2 分類項目を作成 事故事例を分類 STEP3 事故につながりやすい要因の特定 STEP4 支援環境の提案 4.研究アプローチ STEP1 | 事故事例の収集 -社会的に問題となった事故事例が対象 日経コンピュータ『動かないコンピュータ』 (1981/10~1997/4，2001/1/1~連載中) 対象発行年月 2001/1/1~2014/9/24 全322記事(381事例) 掲載年月日，事故発生日時，システムの名称， 関連組織，概要，主な原因，復旧時間，規模， 公共・民間システムの区別 4.研究アプローチ STEP1 | 事故事例の収集 -利用できる事故事例 ①原因まで判明している事例であること 原因 テスト計画書に不 備があった． 行動 システム改修作業 時に修正漏れが あった． 結果 設計金額を計算 するシステムに 不具合． ②原因が情報システムに関連している事例であること →270件の事故事例を対象事例とする 4.研究アプローチ STEP2 | 分類項目の作成 -システム管理基準，情報セキュリティ管理基準 大項目番号 大項目名 システム管理基準 Ⅰ 情報戦略 6の大項目，38の中項目，287の小項目で構成 Ⅱ 企画業務 Ⅲ 開発業務 Ⅳ 運用業務 Ⅴ 保守業務 Ⅵ 共通業務 大項目番号 大項目名 1 セキュリティ基本方針 2 情報セキュリティのための組織 3 資産の管理 4 人的資源のセキュリティ 5 物理的及び環境的セキュリティ 6 通信及び運用管理 7 アクセス制御 8 情報システムの取得、開発及び保守 9 情報セキュリティインシデントの管理 10 事業継続管理 11 順守 情報セキュリティ管理基準 「マネジメント基準」と「管理策基準」から成り立つ 「管理策基準」 11の大項目，39の中項目，131の小項目で構成 4.研究アプローチ STEP2 | 分類項目の作成 分類項目 7の大項目，33の中項目，76の小項目 →以降この分類項目を， 要因項目とする． 対象事例270件を76の要因項目で 分類した． 4.研究アプローチ STEP3 | 事故につながりやすい要因 -頻度による分析 対象事例270件を76の要因項目で分類する． -復旧時間による分析 対象事例270件の復旧までにかかった時間を1〜6の値で 点数化し，要因ごとに平均値を取る． -公共・民間システムの区別による分析 対象事例270件を省庁や自治体が調達した公共のシステムと民間 が調達したシステムに分類する． 4.研究アプローチ STEP3 | 頻度による分析 30 7 「目的，対象業務，費用，スケ ジュール，開発体制，投資効果 などを明確にしなかった」 25 31「要求事項を網羅したテストケースを設定して いなかった」 21「性能が要求定義を満たしていなかった」 20 該 当 件 数 38「運用管理ルールを適切に定めていなかった」 39「運用管理ルールを遵守していなかった」 15 20「要求されるシステム性能を満たすために容 量・能力に関する要求事項を特定し，また将 来必要とされる容量・能力を予測していな かった」 10 24「障害対策を考慮していなかった」 75「システムに脆弱性を残していた」 5 41「事故及び障害の報告体制及び対応手順を明確 にしていなかった」 52「保守ルールを適切に定め，遵守しなかった」 0 7 31 21 38 39 20 24 75 41 52 12 16 要因番号 12「現状分析が不足していた」 16「開発を遂行するために必要な要員，予算，設 備，期間などを確保できていなかった」 4.研究アプローチ STEP3 | 復旧時間による分析 6 復 旧 時 間 75「システムに脆弱性を残していた」 5 45「入力の誤謬、不正を防ぐ対策が 講じられていなかった」 4 7 「開発計画は、目的、対象業務、費用、 スケジュール、開発体制、投資効果など を明確にしなかった」 (1 67「ウイルス検知の仕組みを用意していな かった」 〜 3 6) 31「要求事項を網羅したテストケースを設定 していなかった」 2 26「ユーザ教育の方針とそのスケジュールを 明確にしていなかった」 1 75 45 7 67 31 要因番号 26 35 55 35「本番運用を想定した負荷テストを行って いなかった」 55「保守のテスト計画を適切に定め、テスト 計画に基づいて実施しなかった」 4.研究アプローチ STEP3 | 公共民間の区別による分析 35 Ⅰ「情報戦略」 公共 30 民間 25 該 当 件 数 Ⅱ「企画業務」 Ⅲ 「開発業務」 20 Ⅳ「運用業務」 15 Ⅴ「保守業務」 10 Ⅵ「共通業務」 5 Ⅶ「セキュリティ」 0 Ⅰ Ⅱ Ⅲ Ⅳ Ⅴ 要因の大項目 Ⅵ Ⅶ 4.研究アプローチ STEP4 | 支援環境の提案 -利用対象者 要件定義について学習したい人 要件定義書を記述する人 -システム構成 ひ な 形 PC 要 件 項 目 該当する要因 参考資料 記述参考例 事故事例 要件定義支援環境 ・TRM ・非機能要求グレード ・政府システムの調達仕様書 5.要件定義支援環境デモ 6.考察 要因の考察 -STEP3で分析した復旧時間と頻度によって 4つのグループに分ける グループ① 重要度の高い事故が かなり起こりやすいグループ グループ② 重要度は高くはないが， 頻度がかなり高いグループ グループ③ 重要度は高くなく， 頻度が高いグループ グループ④ 重要度の高い事故が 起こりやすいグループ 6.考察 要因の考察 | グループ① -重要度の高い事故がかなり起こりやすいグループ 7 「開発計画段階で目的，対象業務，費用，スケジュール， 開発体制，投資効果などを明確にしなかった(29件)」 6.考察 要因の考察 | グループ② -重要度は高くないが，頻度がかなり高いグループ 38 「運用ルールを適切に定めていなかった(17件)」 6.考察 要因の考察 | グループ③ -重要度は高くないが，頻度が高いグループ 24 「障害対策を考慮していなかった(13件)」 極めて単純な装置や，故障するとは思われていなかった 装置が故障した． 41 「事故及び障害の報告体制及び対応手順を明確にして いなかった(12件)」 起こり得る事故を想定してマニュアルを作成して いなかった． 52 「保守ルールを適切に定めていなかった (11件)」 保守時に起こり得るトラブルを想定していなかった． 6.考察 要因の考察 | グループ④ -重要度の高い事故が起こりやすいグループ 12 「現状分析が不足していた (10件)」 16 「開発を遂行するために必要な要因，予算，設備，期間 などを確保できていなかった (10件)」 20 「システム性能の容量・能力に関する要求事項を特定し， また将来必要とされる容量・能力も予測する (14件)」 75 「システムに脆弱性を残していた (12件)」 7.評価 評価 -教育利用においての有用性 要件定義支援の前段階として，要件定義そのものを理解させるための 教育として利用できるのではないかと評価をいただいた． 関連する事例の一覧を見ることができ，経験のあるSEにとっても 非常に有用である． -要件項目の重要度について テスト要件，運用・保守要件の重要度が高すぎる 要件定義のフェーズに関わる要因と，テスト，運用・保守工程 に関わる要因を区別する必要がある． 8.今後の課題 課題 -評価について 学生による利用評価 専門家による改善点，活用方法の検討 -事故事例の拡充 編集者を通した記事からでは不明な点が多い 詳細がわかる事故事例の収集 -要因項目と要件項目の対応付け 各要件項目の重要度について見直しが必要