事故事例分析に基づく情報システム調達のリスク対策静岡大学齋田芽久美平林元明湯浦克彦 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