Transcript 発表資料 - 静岡大学
事故事例分析に基づく 情報システム調達のリスク対策 静岡大学 齋田芽久美 平林元明 湯浦克彦 2015/03/12 目次 1.背景と目的 2.従来の要件定義支援方法 3.研究アプローチ 4.要件定義支援環境のデモ 5.評価 6.今後の展望 1.背景と目的 要件定義の重要性 -要件定義は難しい 出典：IPA アンケート調査報告2005/6/29-7/1 SODECにおけるアンケートによる 『失敗の原因が要件定義書 にあると思われる割合について』 出典：JUAS ソフトウェア開発管理基準 に関する調査報告書(2015.2) 『工期遅延理由』 →要件定義の学習・作成を支援する 3 2.従来の要件定義支援方法 TRMと非機能要求グレード -TRM 経済産業省から提供されている 物品調達編と役務調達編で構成されている -非機能要求グレード IPAから提供されている 非機能要求を6つの大項目，34の中項目， 116の小項目で分類 4 2.従来の要件定義支援方法 TRM | 物品調達編 システムを構成してい る機能・サービスを 18のドメインに分類 機能要件，非機能要件 が記述されている 5 2.従来の要件定義支援方法 TRM | 役務調達編 システム ライフサイクルを ・企画 ・要件定義 ・開発 ・運用・保守 の4つに分ける 6 2.従来の要件定義支援方法 TRM | 役務調達編 ・概要 ・用意する資料 ・作成する資料 ・記載すべきポイント ・記載例 ・留意すべき点 7 2.従来の要件定義支援方法 非機能要求グレード -6大項目，34中項目，116小項目 ・可用性 ・性能・拡張性 ・運用・保守性 ・移行性 ・セキュリティ ・システム環境・エコロジー 8 3.研究アプローチ よりわかりやすい支援環境の作成 -各要件項目の重要性 関連する情報システム開発の失敗事例を示す 関連する失敗要因を示す -各要件項目ごとに参考となる資料の提示 従来の支援方法として提供されているTRM や非機能要求グレードの参考となる箇所を示す 9 3.研究アプローチ 研究手順 STEP1 事故事例を収集 STEP2 分類項目を作成 事故事例を分類 STEP3 事故につながりやすい要因の特定 STEP4 支援環境の提案 10 3.研究アプローチ STEP1 | 事故事例の収集 -社会的に問題となった事故事例が対象 日経コンピュータ『動かないコンピュータ』 (1981/10~1997/4，2001/1/1~連載中) 対象発行年月 2001/1/1~2014/9/24 全322記事(381事例) 掲載年月日，事故発生日時，システムの名称， 関連組織，概要，主な原因，復旧時間，規模， 公共・民間システムの区別 11 3.研究アプローチ STEP1 | 事故事例の収集 -利用できる事故事例 ①原因まで判明している事例であること 原因 テスト計画書に不 備があった． 行動 システム改修作業 時に修正漏れが あった． 結果 設計金額を計算 するシステムに 不具合． ②原因が情報システムに関連している事例であること →270件の事故事例を対象事例とする 12 3.研究アプローチ STEP2 | 分類項目の作成 -システム管理基準，情報セキュリティ管理基準 大項目番号 大項目名 システム管理基準 Ⅰ 情報戦略 6の大項目，38の中項目，287の小項目で構成 Ⅱ 企画業務 Ⅲ 開発業務 Ⅳ 運用業務 Ⅴ 保守業務 Ⅵ 共通業務 大項目番号 大項目名 1 セキュリティ基本方針 2 情報セキュリティのための組織 3 資産の管理 4 人的資源のセキュリティ 5 物理的及び環境的セキュリティ 6 通信及び運用管理 7 アクセス制御 8 情報システムの取得、開発及び保守 9 情報セキュリティインシデントの管理 10 事業継続管理 11 順守 情報セキュリティ管理基準 「マネジメント基準」と「管理策基準」から成り立つ 「管理策基準」 11の大項目，39の中項目，131の小項目で構成 13 3.研究アプローチ STEP2 | 分類項目の作成 分類項目 7の大項目，33の中項目，76の小項目 →以降この分類項目を， 要因項目とする． 対象事例270件を76の要因項目で 分類した． 14 3.研究アプローチ STEP3 | 事故につながりやすい要因 -頻度による分析 対象事例270件を76の要因項目で分類する． -復旧時間による分析 対象事例270件の復旧までにかかった時間を1〜6の値で 点数化し，要因ごとに平均値を取る． 15 3.研究アプローチ 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「開発を遂行するために必要な要員，予算，設 備，期間などを確保できていなかった」 16 3.研究アプローチ 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「保守のテスト計画を適切に定め、テスト 計画に基づいて実施しなかった」 17 3.研究アプローチ STEP4 | 支援環境の提案 -利用対象者 要件定義について学習したい人 要件定義書を記述する人 -システム構成 ひ な 形 PC 要 件 項 目 該当する要因 参考資料 記述参考例 ・TRM ・非機能要求グレード ・政府システムの調達仕様書 事故事例 要件定義支援環境 18 4.要件定義支援環境のデモ 19 5.評価 評価 ・TRM検討ワーキンググループに参加している実務経験豊富な企業の方々 ・元IT企業の社員教育講師の方 ・金融情報システム開発の成功要因について研究している専門家 -実務利用について 【有効な点】 各要件項目ごとに要件定義支援環境を参照しながら記述していくことがで きる． 【課題】 重要度については一部高すぎると感じられるものがあったり， 要件定義段階ではトラブルを防ぐことが難しい項目もある 20 5.評価 評価 ・TRM検討ワーキンググループに参加している実務経験豊富な企業の方々 ・元IT企業の社員教育講師の方 ・金融情報システム開発の成功要因について研究している専門家 -教育利用について 【有効な点】 要件定義支援の前段階として，要件定義そのものを理解させるための 教育として利用できる． 関連する事例の一覧を見ることができ，経験のあるSEにとっても 非常に有用である． 【課題】 実際に大学院の講義内で利用してもらい，学習者から評価を取る 必要がある． 20 6.今後の展望 今後の展望 -要件項目の重要度の見直し テスト要件，運用・保守要件の重要度が高すぎる 要件定義のフェーズに関わる要因と，テスト，運用・保守工程 に関わる要因を区別する必要がある． -事故事例の拡充 編集者を通した記事からでは不明な点が多い 記載されている主な事故要因の正確性 裁判所の判例や金融庁の業務改善命令を参考にしてはどうか -事故要因の普遍性 事故要因とされているものが普遍的なものなのか， 技術の進歩によって解決できるものなのかを判別する必要がある． 21