2015/03/12 事故事例分析に基づく 情報システム調達のリスク対策 静岡大学 齋田芽久美 平林元明 湯浦克彦

目次 1. 背景と目的 2. 従来の要件定義支援方法 3. 研究アプローチ 4. 要件定義支援環境のデモ 5. 評価 6. 今後の展望

1. 背景と目的 要件定義の重要性 - 要件定義は難しい 出典： JUAS ソフトウェア開発管理基準 に関する調査報告書 (2015.2) 『工期遅延理由』 出典： IPA アンケート調査報告 2005/6/29-7/1 SODEC におけるアンケートによる 『失敗の原因が要件定義書 にあると思われる割合について』 → 要件定義の学習・作成を支援する 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

よりわかりやすい支援環境の作成 - 各要件項目の重要性 - 各要件項目ごとに参考となる資料の提示 関連する情報システム開発の失敗事例を示す 関連する失敗要因を示す 従来の支援方法として提供されている TRM や非機能要求グレードの参考となる箇所を示す 3. 研究アプローチ 9

研究手順 事故事例を収集 分類項目を作成 事故事例を分類 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 の小項目で構成 情報セキュリティ管理基準 「マネジメント基準」と「管理策基準」から成り立つ 「管理策基準」 11 の大項目， 39 の中項目， 131 の小項目で構成 13

3. 研究アプローチ STEP2 | 分類項目の作成 分類項目 7 の大項目， 33 の中項目， 76 の小項目 → 以降この分類項目を， 要因項目 とする． 対象事例 270 件を 76 の要因項目で 分類した． 14

3. 研究アプローチ STEP3 | 事故につながりやすい要因 - 頻度による分析 - 復旧時間による分析 対象事例 270 件を 76 の要因項目で分類する． 対象事例 270 件の復旧までにかかった時間を 1 〜 6 の値で 点数化し，要因ごとに平均値を取る． 15

3. 研究アプローチ STEP3 | 頻度による分析 7 「目的，対象業務，費用，スケ ジュール，開発体制，投資効果 などを明確にしなかった」 31 「要求事項を網羅したテストケースを設定して いなかった」 21 「性能が要求定義を満たしていなかった」 38 「運用管理ルールを適切に定めていなかった」 39 「運用管理ルールを遵守していなかった」 20 「要求されるシステム性能を満たすために容 量・能力に関する要求事項を特定し，また将 来必要とされる容量・能力を予測していな かった」 24 「障害対策を考慮していなかった」 75 「システムに脆弱性を残していた」 41 「事故及び障害の報告体制及び対応手順を明確 にしていなかった」 52 「保守ルールを適切に定め，遵守しなかった」 12 「現状分析が不足していた」 16 「開発を遂行するために必要な要員，予算，設 備，期間などを確保できていなかった」 16

3. 研究アプローチ STEP3 | 復旧時間による分析 75 「システムに脆弱性を残していた」 45 「入力の誤謬、不正を防ぐ対策が 講じられていなかった」 7 「開発計画は、目的、対象業務、費用、 スケジュール、開発体制、投資効果など を明確にしなかった」 67 「ウイルス検知の仕組みを用意していな かった」 31 「要求事項を網羅したテストケースを設定 していなかった」 26 「ユーザ教育の方針とそのスケジュールを 明確にしていなかった」 35 「本番運用を想定した負荷テストを行って いなかった」 55 「保守のテスト計画を適切に定め、テスト 計画に基づいて実施しなかった」 17

3. 研究アプローチ STEP4 | 支援環境の提案 - 利用対象者 要件定義について学習したい人 要件定義書を記述する人 - システム構成 18

4. 要件定義支援環境のデモ 19

5. 評価 評価 - 実務利用について 20 【有効な点】 各要件項目ごとに要件定義支援環境を参照しながら記述していくことがで きる． 【課題】 重要度については一部高すぎると感じられるものがあったり， 要件定義段階ではトラブルを防ぐことが難しい項目もある ・ TRM 検討ワーキンググループに参加している実務経験豊富な企業の方々 ・元 IT 企業の社員教育講師の方 ・金融情報システム開発の成功要因について研究している専門家

5. 評価 評価 - 教育利用について 【有効な点】 要件定義支援の前段階として，要件定義そのものを理解させるための 教育として利用できる． 関連する事例の一覧を見ることができ，経験のある SE にとっても 非常に有用である． 【課題】 実際に大学院の講義内で利用してもらい，学習者から評価を取る 必要がある． 20 ・ TRM 検討ワーキンググループに参加している実務経験豊富な企業の方々 ・元 IT 企業の社員教育講師の方 ・金融情報システム開発の成功要因について研究している専門家

6. 今後の展望 今後の展望 - 要件項目の重要度の見直し - 事故事例の拡充 - 事故要因の普遍性 事故要因とされているものが普遍的なものなのか， 技術の進歩によって解決できるものなのかを判別する必要がある． 編集者を通した記事からでは不明な点が多い 記載されている主な事故要因の正確性 裁判所の判例や金融庁の業務改善命令を参考にしてはどうか 21 テスト要件，運用・保守要件の重要度が高すぎる 要件定義のフェーズに関わる要因と，テスト，運用・保守工程 に関わる要因を区別する必要がある．