システム基盤における上流工程での 非機能要求合意を目指して 2015年1月14日 独立行政法人情報処理推進機構（IPA）技術本部 ソフトウェア高信頼化センター（SEC) 連携委員 富士通株式会社 柏木 雅之 Copyright © 2010-2015 IPA, All Rights Reserved Software Reliability Enhancement Center 目次 1. 非機能要求の重要性と課題 2. 非機能要求グレードのコンセプトと構成 3. 非機能要求グレードを利用した非機能要求の合意 プロセス（ケーススタディ） 4. 非機能要求グレードの開発と評価 5. 非機能要求グレードの活用事例 6. ご参考：非機能要求グレードのアンケート調査 付録：FAQ Copyright © 2010-2015 IPA, All Rights Reserved Software Reliability Enhancement Center 1 1 非機能要求の重要性と課題 Copyright © 2010-2015 IPA, All Rights Reserved Software Reliability Enhancement Center 2 １-１ 情報システムの社会基盤化と高度化 情報システムはビジネス・社会活動を支える基盤であり、 ビジネス・社会活動の発展に伴い要求も高度化 一般 消費者 情 報 シ ス テ ム の 利 用 者 社外利用/企業間接続 利活用の高度化 社外企業 （利用範囲の拡大） ビジネスニーズへの迅速な 対応要請の高まり。 情報システムのリスクが ビジネスリスクに直結！ （非機能要求項目への 対応の必要性） 全社員PC/社内システム 社内全員 社会活動・ビジネスと情報システムが直結 （情報システムの社会基盤化と高度化） 数千台～ コンピュータセンタ 数百台～数千台 基幹業務 バックオフィス 数万・数十万台 担当者 技術的な高度化（複雑なシステム要素の連携） 数台～数百台 ITと業務の関係 参考：情報サービス白書2009 P.143 技術変化 Copyright © 2010-2015 IPA, All Rights Reserved Software Reliability Enhancement Center 3 1-2 情報システムの障害件数の推移 （報道ベース） 2005 2006 2007 2008 10 10 2009 2011 1～2件/月 4.5件/月 8 7 月 別 件 数 2010 7 6 6 6 6 5 4 4 4 4 4 3.1件/月 3 5 4 4 4 3 2 3 1.8件/月 3 1.3件/月 1.4件/月 2 2 2 2 2 2 2 2 3 2 2 3 2 2 2 2 2 Copyright © 2010-2015 IPA, All Rights Reserved 1 1 Software Reliability Enhancement Center 2011.5 2011.3 0 2011.1 0 0 2010.11 2010.1 2009.11 2009.9 2009.7 2009.5 2009.3 2008.11 0 1 2010.9 1 2010.7 1 1 2010.5 1 0 2008.9 2008.7 2008.5 2008.3 2008.1 2007.11 2007.9 2007.7 2007.5 1 1 2010.3 1 0 2007.3 0 0 2006.11 0 0 0 0 0 0 0 1 2009.1 1 2007.1 1 2006.9 2006.1 0 0 2005.11 2005.9 0 2005.7 0 1 2006.7 1 2006.5 1 2006.3 1 1 年 月 4 １-３ システム障害の要因とは（１/２） 要件定義など上流工程の改善が品質向上に効果的 レビュー活動 進捗管理 2% 構成管理 （変更管理） プロジェクト間 又は組織間の調整 1% 外注管理 4% 3% 6% 要件定義 33% プロジェクト計画 14% 開発体制 16% 21% 品質に悪い影響を 与える要因は？ 要員の技術力とその維持/ トレーニング 出典：情報サービス産業協会（JISA) 「情報サービス産業における受託ソフトウェア開発実態アンケート調査」 2005より Copyright © 2010-2015 IPA, All Rights Reserved Software Reliability Enhancement Center 5 １ー３ システム障害の要因とは（２／２） 要件定義など上流工程の改善が品質向上に効果的 5年間に要件定義の問題が改善されていない 41.7% テス トが不十分 36.7% 要件定義が不十分 シス テム開発の質が悪い 31.7% エンドユーザへの教育が不十分 31.7% シス テムの設計が不正確 31.7% 21.7% 社内の開発体制に問題 18.3% 計画が現実の利用形態に沿わず 16.7% シス テムの企画が不十分 15.0% ベンダの選択に問題 2003年 11.7% その他 0% 2008年 10% 20% 30% 40% 「日経コンピューター 2008年12月1日号」の「第2回プロジェクト実態調査」を元に作成 Copyright © 2010-2015 IPA, All Rights Reserved Software Reliability Enhancement Center 6 【ご参考】 非機能要求関連の各種活動 企画 要件定義 開発 運用・保守 非機能要求仕様定義ガイドライン（ＵＶＣ Ⅱ） JUAS 非機能要求に関して、各フェーズで実施すべきことと、 検収フェーズでの評価指標を提示 各フェーズのユーザとベンダ間の役割分担も提示 民間向けITシステムのSLAガイドライン JEITA 運用時のサービスの要求レベル を定義し合意することでサービス 運用の品質を高める考え方提示 REBOK JISA 要件定義の知識体系。 非機能要求も含む 非機能要求グレード IPA/SEC 要求の定義段階での非機能要求のグレード（要求 レベル）を開発に入る前にユーザとベンダ間で 確認し合意する手段を提示。 システム基盤構築の判断（難度や費用）に直結 Copyright © 2010-2015 IPA, All Rights Reserved 非機能要求記述ガイド アーキテクチャ設計を実施するために 非機能要求を正確に記述する方法を提示 Software Reliability Enhancement Center 7 １－４ システムに対する機能要求と非機能要求 本日の話はシステム基盤の「非機能要求」に関するコミュニケーション 非機能要求 グレードでの分類 要件定義成果物からみた要求の分類※ 品質要求 非機能 要求 技術要求 その他要求 可用性 運用・操作要求 移行要求 付帯作業 その他 機能 要求 性能・拡張性 運用・保守性 移行性 機能要求（プロセス） セキュリティ 機能要求（データ） システム環境・ エコロジー 機能要求（インタ－フェース） ※参考：SEC BOOKS 「経営者が参画する要求品質の確保～超上流から攻めるIT化の勘どころ～」 （オーム社刊） Copyright © 2010-2015 IPA, All Rights Reserved Software Reliability Enhancement Center 8 1-4 システムに対する機能要求と非機能要求 機能要求はシステム化したい「業務」だが非機能要求は様々で曖昧 機 能 要 求 非 機 能 要 求 この業務を システム化したい 対象業務は全てor特定？ 「極力」で許容される時間は EUC 製造 １分、１０分、or１時間？ 障害が発生しても サービスは極力止め ないでほしい データの暗号化の範囲は？ 暗号化の鍵管理方法は？ 不正アクセスの追跡範囲は？ 事務室内で 運用したい Copyright © 2010-2015 IPA, All Rights Reserved サービス時間帯は ２４Ｈ、９～２１時、 会計 物流 or ９～１７時？ 対象ユーザ数はどのくらい？ 分析 販売 セキュリティ認証の程度は？ いつでも、誰でも どこでも使える ようにしてほしい 情報漏洩、 ウィルス混入は 防止してほしい どこでもの範囲は？ 建屋内、 同一県内、 国内 or 海外？ 情報は確実に 保全してほしい Software Reliability Enhancement Center 9 １-５ 非機能要求の実現要素 非機能要求の多くは「システム基盤」にて実現 機 能 要 求 業務アプリ 非 機 能 要 求 EUC 分かり易い操作、 容易な業務変更、 ｱﾌﾟﾘｹｰｼｮﾝ性能 システム運用・ 調達の仕組み、 体制による実現 (運用設計にて検討) Copyright © 2010-2015 IPA, All Rights Reserved 製造 物流 会計 販売 分析 システム基盤 制御/運用アプリケーションによる実現 ＯＳ、ミドルウェアによる実現 ＨＷ／ＮＷ機器による実現 Software Reliability Enhancement Center 10 １-６ 非機能要求に関する課題 お客様（発注者）とベンダの間で認識のギャップがある お客様（発注者） 開発ベンダ（受注者） 技術的でイメージできない わかりやすく説明できない 業務にあった要求が示せない 業務ごとに最適解が異なる ベンダから提案してほしい 期待レベルが把握できない どう提示してよい かわからない Copyright © 2010-2015 IPA, All Rights Reserved 何を提案してよい かわからない Software Reliability Enhancement Center 11 １-７ 非機能要求の課題 非機能要求のギャップがシステム開発・運用のリスクとなる ベンダ （受注者） ユーザ （発注者） 結果 具体化が進んでいない上流工程で決めきることは困難 発注者・受注者で共通認識を持てない、合意できない リスク 誘発 システム開発（プロジェクト運営）の成 否へ影響 [基盤の変更、下流で問題発覚] Copyright © 2010-2015 IPA, All Rights Reserved システム運用上のリスク拡大 [想定外、あるいは、 極限状態での利用運用] Software Reliability Enhancement Center 12 １-８ 要件定義書における非機能要求の課題 多くの要件定義成果物において非機能要件記述が体系的に記 述されておらず、そもそもどのような項目を記述すべきかが 理解されていない 機能要求が中心の要求定義成果物の中に散在する 実現すべき程度（レベル）があいまい。 散在する非機能要求間に矛盾がある 非機能要求が網羅的でない 非機能要求の分類に一貫性を欠く 非機能記述の根拠付けおよび優先順位付けができない 例：出張申請機能は、勤怠管理と旅費精算を行うための機能で、 … （中略） … 本人または指定された代行者が申請し、利用者に ストレスを感じさせない応答を実現すること。 何をどの程度に決めるのかが難しい Copyright © 2010-2015 IPA, All Rights Reserved Software Reliability Enhancement Center 13 【参考】非機能要求定義の状況(4/24公開) ●非機能要求の参考にする基準（図2.4.1） ①「社内にある」は17%に過ぎず、「社内の類似案件を参考にする」団体が58%と多い ②参考にする基準が「ない」との回答は17%（ユーザ１で28%、ベンダ１で16%）もある ③社外の基準 •JISの品質特性、Boehmの品質特性 ※ユーザ１：非機能要求グレードを知らない •JUASの非機能要求ガイド ユーザ２：非機能要求グレードを知っている •経産省とIPAで策定したTRM*1 ベンダ１：非機能要求グレードを知らない •顧客側の持つ基準に基づく ベンダ２：非機能要求グレードを知っている •非機能要求グレード（IPA） ●非機能要求設定項目数（図2.4.2） •「100項目以上」は7%、「50～100項目」が17%、「50項目未満」が59% •ベンダ２の設定項目数は他に比べ多い 100% 90% 80% 17% 28% 25% 18% 5% 8% 70% 16% その他 50% 48% 68% 64% 30% 20% 10% 21% 21% 17% 20% 11% 0% 全体 ユーザ１ ユーザ２ ベンダ１ 18% 社外のものを参考にする 50% 社内の類似案件を参考にする 40% 社内にある 30% 10% 0% ベンダ２ 図2.4.1参考にする基準 45% 50% その他 設定していない 59% 58% 67% 18% 50項目未満 50～100項目 100項目以上 50% 20% 25% 26% 60% ない 40% 4% 90% 70% 4% 58% 2% 80% 60% 50% 100% 36% 12% 7% 8% 全体 ユーザ１ 16% ユーザ２ ベンダ１ ベンダ２ 図2.4.2非機能要求設定項目数 *1 TRM(Technical Reference Model)は技術参照モデルで調達に必要な技術情報をまとめたもの http://www.ipa.go.jp/osc/trm/index.html Copyright © 2010-2015 IPA, All Rights Reserved Software Reliability Enhancement Center 14 【参考】目標復旧時間(RTO)と対策の不整合 出所：アンケート調査の結果を基に作成 Copyright © 2010-2015 IPA, All Rights Reserved Software Reliability Enhancement Center 15 ２ 非機能要求グレードのコンセプトと構成 Copyright © 2010-2015 IPA, All Rights Reserved Software Reliability Enhancement Center 16 2-1 非機能要求グレードの構成 非機能要求グレードは次の３つの図表（③④⑤）と２つのガイド（①②）から構成 される。 さらに、自由にカスタマイズできるスプレッドシート（⑥）を用意している。 ①利用ガイド（解説編） ②利用ガイド（利用編） 非機能要求グレードを作成した 背景やツールの詳細等を解説し たもの 非機能要求グレードの具体的な 利用方法について解説したもの ③グレード表 ④項目一覧 ３つのモデルシステムと重要な 非機能要求項目に対する要求レ ベルを示した一覧表 非機能要求項目をユーザ／ベンダ 間で漏れなく共通に認識できるよ う体系化した一覧表 ⑤樹系図 ⑥活用シート グレード表、項目一覧の閲覧 性を向上させ、要求項目の検 討順を可視化した図 グレード表と項目一覧の内容をま とめた一覧表。スプレッドシート 形式で使用可能。 Copyright © 2010-2015 IPA, All Rights Reserved Software Reliability Enhancement Center 17 ２－２ 非機能要求項目の体系化 システム基盤に関する非機能要求を大きく６項目に分類 大項目 要求例 確認結果に基づき、実施する対策例 可用性 運用スケジュール （稼働時間・停止予定など） 障害、災害時における稼動目標 機器の冗長化やバックアップセンターの設置 復旧・回復方法及び体制の確立 性能・ 拡張性 業務量および今後の増加見積り システム化対象業務の特性 （ピーク時、通常時、縮退時など） 性能目標値を意識したサイジング 将来へ向けた機器・ネットワークなどのサイズと 配置 ＝ ｷｬﾊﾟｼﾃｨ･ﾌﾟﾗﾝﾆﾝｸﾞ 運用・ 保守性 運用中に求められるシステム 稼動レベル 問題発生時の対応レベル 監視手段およびバックアップ方式の確立 問題発生時の役割分担、体制、訓練、 マニュアルの整備 移行性 新ｼｽﾃﾑへの移行期間および移行方法 移行対象資産の種類および移行量 移行スケジュール立案、移行ツール開発 移行体制の確立、移行リハーサルの実施 利用制限 不正アクセスの防止 アクセス制限、データの秘匿 不正の追跡、監視、検知 耐震／免震、重量／空間、温度／湿度、 騒音など、システム環境に関する事項 CO2排出量や消費エネルギーなど、エコロジー に関する事項 規格や電気設備に合った機器の選別 環境負荷を低減させる構成 ｾｷｭﾘﾃｨ ｼｽﾃﾑ環境・ ｴｺﾛｼﾞｰ Copyright © 2010-2015 IPA, All Rights Reserved Software Reliability Enhancement Center 18 ２-２ 非機能要求項目の体系化 非機能要求を６つの大項目に分類し、さらに具体的な項目に細分化 小項目を定量的に 表現するための指標 非機能要求を体系的に 整理したときの最も広い分類 大項目 検討すべき単位で 小項目をまとめた分類 中項目 小項目 小項目 小項目 中項目 … Copyright © 2010-2015 IPA, All Rights Reserved （システムの開発コストや 品質に影響を与える度合い の大きいメトリクスを 重要項目とする。） メトリクス メトリクス メトリクス メトリクス ユーザと開発ベンダの間で合意される 非機能要求を示す項目の分類 Software Reliability Enhancement Center 19 ２－２ 非機能要求項目の体系化 大・中項目の全体像 非機能要求項目 可用性 性能・拡張性 運用保守性 移行性 セキュリティ 継続性 業務処理量 通常運用 移行時期 耐障害性 性能目標値 保守運用 移行方式 災害対策 リソース拡張性 障害時運用 回復性 性能品質保証 運用環境 中項目 中項目 中項目 中項目 移行対象 （機器） 前提条件・ 制約条件 システム制約／ 前提条件 セキュリティ リスク分析 システム特性 適合規格 セキュリティ診断 サポート体制 移行対象 （データ） その他 運用管理方針 移行計画 多 メトリクスに 重要項目を 含む割合 少 合計236のメトリクス（指標） Copyright © 2010-2015 IPA, All Rights Reserved システム環境・ｴｺﾛｼﾞｰ セキュリティ リスク管理 アクセス・ 利用制限 機材設置 環境条件 環境 マネジメント データの秘匿 不正追跡・監視 ネットワーク対策 マルウェア対策 Ｗｅｂ対策 Software Reliability Enhancement Center 20 【ご参考】ソフトウェア品質基準(ISO/IEC 25000:2005)との関係 システム基盤の非機能要求を対象としている非機能要求グレードとソフトウェ アの品質を対象にしているISO/IEC 9126-1:2001(今のISO/IEC 25000:2005)と は一概に比較できないが、用語は可能な範囲でこの規格を参考にした。 ＩＳＯ／ＩＥＣ 9126-1:2001 特性 副特性 機能性 合目的性 信頼性 使用性 非機能要求項目 （大項目） × 正確性 相互運用性 セキュリティ 機能性標準適合性 × × セキュリティ セキュリティ、 システム環境・エコロジー 成熟性 障害許容性 回復性 可用性 可用性 可用性、 運用・保守性 システム環境・エコロジー × 運用・保守性 運用・保守性 × システム環境・エコロジー 信頼性標準適合性 理解性 習得性 運用性 魅力性 使用性標準適合性 Copyright © 2010-2015 IPA, All Rights Reserved ＩＳＯ／ＩＥＣ 9126-1:2001 特性 副特性 効率性 時間効率性 非機能要求項目 （大項目） 性能・拡張性 資源効率性 効率性標準適合性 性能・拡張性 性能・拡張性、 システム環境・エコロジー 保守性 解析性 変更性 安定性 試験性 保守性標準適合性 移植性 環境適用性 設置性 共存性 置換性 移植性標準適合性 運用・保守性 × × × 運用・保守性、 システム環境・エコロジー 移行性 システム環境・エコロジー 移行性 移行性 システム環境・エコロジー Software Reliability Enhancement Center 21 ２－３ 要求レベルによる要求項目の共通認識 メトリクス毎に実現上必要となるコストや実装上のアーキテクチャの 難易度が 大きく変わるポイントで『レベル』を設定。 レベル０からレベル５までの最大６段階で設定。レベル値が大きいほ ど実現難易度は高くなり、一般に開発コストは増加。 レベルで示す値はユーザ／ベンダ間で合意形成を図る出発点とし、 最終的に具体的な数値として合意することを想定。 レベルの差は、アーキテクチャの違い ユーザ レベルの例 大項目 可用性 中項目 小項目 継続性 業務継続性 （可能性を保証 するにあたり、 要求される 業務の範囲と その条件） メトリクス 非機能要求を提示しやすい レベル ０ １ ２ ３ ４ ５ 対象業務範囲 内部向け バッチ系 業務 内部向け 内部向け オンライン系 全業務 業務 外部向け バッチ系 業務 外部向け オンライン 系業務 全ての 業務 サービス 切替時間 ２４時間 以上 ２４時間 未満 ２時間 未満 ６０分 未満 １０分 未満 ６０秒 未満 業務継続の 要求度 障害時の 業務停止 を許容 する。 単一障害 時は業務停 止を許容せ ずに処理を 継続させる 二重障害時 でもサービス 切替時間の 規定内で業 務継続 Copyright © 2010-2015 IPA, All Rights Reserved ベンダ 非機能要求を確認しやすい Software Reliability Enhancement Center 22 ２-４ モデルシステムとグレードによる推奨値の提供 利用目的、規模、障害時に社会に与える影響が異なることにより実現水準 に有意な差がある３つの「モデルシステム」を定義。 モデルシステム毎に「重要項目」の選択レベルと選択時の条件を「グレード 」と定義。 「グレード」は、非機能要求項目を決定する目安として有効。 モデル 社会的影響が殆ど無いシ システム ステム 名 社会的影響が限定されるシ ステム 社会的影響が極めて 大きいシステム システム 企業の特定部門が比較的限ら 企業活動の基盤となるシステム 国民生活・社会経済活動の基 の概要 れた範囲で利用しているシステ で、その機能が低下又は利用不 盤となるシステムで、その機能 ムで、機能が低下または利用 可能な状態に陥った場合、当該 不可な状態になった場合、利 企業活動に多大の影響を及ぼす 用部門では大きな影響がある と共に取引先や顧客等の外部利 が、その他には影響しないもの。用者にも影響を及ぼすもの。 が低下又は利用不可能な状 態に陥った場合、国民生活・ 社会経済活動に多大な影響 を与えるもの。 ここでは、ごく小規模のイン ターネット公開システムを想定 している。 ここでは、不特定多数の人が 利用するインフラシステムを想 定している。 Copyright © 2010-2015 IPA, All Rights Reserved ここでは、企業内のネットワーク に限定した基幹システムを想定 している。 Software Reliability Enhancement Center 23 【ご参考】 モデルシステム名 モデルシステム名は「重要インフラ情報システム信頼性研究会報告※」から引用 注：「Type Ⅳ：人命に影響、甚大な経済損失」はType Ⅲに含めて検討 ※ http://sec.ipa.go.jp/reports/20090409.html Copyright © 2010-2015 IPA, All Rights Reserved Software Reliability Enhancement Center 24 ２－５（１） 利用ガイド 用途別に２種類の利用ガイドを整備 利用ガイド(解説編)目次 1. はじめに 1.1 非機能要求グレード策定の背景とねらい 1.2 非機能要求の問題と非機能要求グレードの 解決方法 1.3 非機能要求グレードのスコープ 1.4 非機能要求グレードの概要 2. 非機能要求グレードの詳細説明 2.1 非機能要求グレードの詳細説明 2.2 各大項目の概要と留意事項 利用ガイド(利用編)目次 1.非機能要求グレードの概要 2.開発プロセスと 非機能要求グレードの利用の関係 3.基本的な利用例 4.いろいろな利用例 5.留意事項 3. FAQ 4. 用語集 5. 付録 5.1 非機能要求に関する他活動との関係について 5.2 他活動との関係について Copyright © 2010-2015 IPA, All Rights Reserved Software Reliability Enhancement Center 25 ２－５（２） 項目一覧 システム基盤に関わる非機能要求項目と要求レベルを一覧化 した表 開発契約までに確認が 要求レベルにより具体的な ユーザ／ベンダが合意すべき非機能要求を網羅 必要な要求項目 選択肢を提示 要求項目 要求レベル 低 備考（補足説明） 高 重複項目 重要項目 他の大項目に同じ項目 があるかどうかの識別 QCDに大きな影響が 当該項目を定量的に表現す ある項目（グレード表 るための指標 対象項目） Copyright © 2010-2015 IPA, All Rights Reserved メトリクス（指標） 運用コストへの影響 要求される要求ﾚﾍﾞﾙに 要するｺｽﾄと運用ｺｽﾄとの間にﾄﾚｰﾄﾞ ｵﾌがある項目を示す Software Reliability Enhancement Center 26 ２-５（３） 樹系図 非機能要求項目の大項目単位に中項目以下の検討順序を 可視化したもの 前 重要な非機能要求項目 検討順序 後 後 Copyright © 2010-2015 IPA, All Rights Reserved Software Reliability Enhancement Center 27 ２-５（４） グレード表：モデルシステムシート モデルシステムシート ３つのモデルシステムにおいて、特徴を表す非機能要求を整理したもの モデルシステムの定義 Copyright © 2010-2015 IPA, All Rights Reserved Software Reliability Enhancement Center 28 【ご参考】 モデルシステムの非機能要求 モデルシステムを定義するにあたり、個々のモデルシステムに対する 非機能要求を典型的な１６の特徴で定義した。 モデル システム 可用 性 性能 ・ 拡張 性 社会的影響が殆ど無い システム 社会的影響が限定される システム 社会的影響が極めて大きい システム 稼動率 ９９％ （年間許容停止時間 数日） ９９．９９％ （年間許容停止時間 約１時間） ９９．９９９％ （年間許容停止時間 約数分） 目標復旧 水準 週次のバックアップからの復旧 １営業日以内の復旧 数時間で障害発生時点に復旧 大規模 災害 システム再構築による復旧 １週間以内の業務復旧 ＤＲサイトで業務継続 性能 目標 大まかな性能目標 （他の要求より重視しない） 性能面でのサービスレベルを規定 性能面でのサービスレベルを 規定 拡張性 拡張性は考慮しない 拡張計画が決められている 拡張計画が決められている 業務時間のみサービス提供 夜間バッチ終了後、業務開始 まで若干の停止時間あり 常時サービス提供が前提 （２４Ｈ／３６５日稼動） 手動で必要データのみ 日次に自動でシステム全体 運用サイトと同期したバックアップサイトを 構成 機器の死活監視 業務機能を監視 障害の予兆監視 ： ： ： 運用・ 運用時間 保守 性 バック アップ 運用監視 非機能要求 の特徴 Copyright © 2010-2015 IPA, All Rights Reserved モデルシステムの定義 Software Reliability Enhancement Center 29 ２－５（４） グレード表：グレード表（続く） グレード表 ユーザの視点で非機能要求を抽出 重要な 非機能要求項目 要求レベル Copyright © 2010-2015 IPA, All Rights Reserved グレードの定義 Software Reliability Enhancement Center 30 ２－５（４） グレード表：グレード表（続き） グレードの定義 選択レベル： 個々のメトリクスに対して、該当する モデルシステムを想定して選択したレ ベル。ベース値と呼ぶ。 Copyright © 2010-2015 IPA, All Rights Reserved 選択時の条件： ベース値を選択したときの条件。 さらに、ベース値を調整する際の 条件を[＋][－]で示した。 Software Reliability Enhancement Center 31 ２ｰ５（５） 活用シート（グレード表と項目一覧との関係） ① グレード表： 02_hikinou_grade_201002.pdf 大 中 項 項 目 目 項番 A.1.1.1 可 用 性 小項目 レベル 重 複 項 目 小項目説明 継 運用スケジュール 続 性 システムの稼働時間や 停止運用に関する情報。 メトリクス (指標) 0 運用時間（通常） 1 規定無し 2 定時内 （9時～17 時） 3 夜間のみ 停止 （9時～21 時） 4 社会的影響が殆ど無いシ ス テ ム 運用コ ス トへ の影 響 5 1時間程度 若干の停 の停止有り 止有り （9時～翌 （9時～翌 朝8時） 朝8時55 分） 24時間無 停止 選択レベル 2 【メトリクス】 運用時間は、オンライン/バッチを含みシステムが稼動している時間帯を指す。 ① 運用時間（特定日） 規定無し 定時内 （9時～17 時） 夜間のみ 停止 （9時～21 時） 1時間程度 若干の停 の停止有り 止有り （9時～翌 （9時～翌 朝8時） 朝8時55 分） 24時間無 停止 【重複項目】 C.1.1.2。運用時間は、システムの可用性の実現レベルを表す項目であるとともに、運用・保守性に関 する開発コストや運用コストを検討する上でも必要となる項目であるため、可用性と運用・保守性の両 方に含まれている。 計画停止の有無 ○ 0 規定無し 2 計画停止 計画停止 計画停止 有り（運用 有り（運用 無し スケジュー スケジュー ルの変更 ルの変更 可） 不可） 【重複項目】 C.2.1.1。計画停止の有無は、システムの可用性の実現レベルを表す項目であるとともに、運用・保守 性に関する開発コストや運用コストを検討する上でも必要となる項目であるため、可用性と運用・保守 性の両方に含まれている。 通常と異なる運用時間となる特定日は存 在しない。 [+] 休日にバックアップ運用を行うなど、通 常とは異なる運用時間となる特定日が存 在する場合 0 ○ 計画停止 事前の合意があれば、停止は可能。 有り（運用 スケジュー [+] 運用時間外での停止だけで対応可能 ルの変更 な場合 可） 【運用コストへの影響】 計画停止が”有り”の場合、事前のバックアップや、システム構成に応じた手順準備など、運用時のコ ストがかさむ。 ② 社会的影響が極めて 大きいシ ス テ ム 選択レベル 選択時の条件 若干の停 止有り （9時～翌 朝8時55 分） 24時間無停止での運用は必要ないが、極 力システムの稼働は継続させる。 5 選択時の条件 24時間無 システムを停止できる時間帯が存在しな 停止 い。 [-] 夜間のアクセスは認めないなど、長時 間運用を停止する場合 [+] 24時間無停止で運用する場合 [-] 1日のスケジュールで定期的に運用を 停止する時間帯が存在する場合 1 夜間のみ 週末はバックアップ運用のみのため、夜間 停止 は停止する。 （9時～21 時） [-] 週末運用するバックアップやバッチ処 理などが存在せず、土休日は運用を停止 する場合 [+] 休日出勤する社員の業務に必要なた め、土休日も運用する場合 5 計画停止 24時間無停止での運用は必要ない。停止 有り（運用 可能な時間が存在し、計画的な停止は可 スケジュー 能。 ルの変更 不可） [-] 運用スケジュールとしては停止可能な 時間帯は存在しないが、事前の調整で停 止が可能な場合 [+] 24時間無停止が要求される場合 2 24時間無 システムを停止できる時間帯が存在しな 停止 い。 [-] 定期的に運用を停止する日が存在する 場合 計画停止 システムを停止できる時間帯が存在しな 無し い。 [-] 運用スケジュールとして停止可能な時 間帯が存在し、計画停止の必要性がある 場合 … ＋ 選択レベル 4 【メトリクス】 特定日とは、休日/祝祭日や月末月初など通常の運用スケジュールとは異なるスケジュールを定義し ている日のことを指す。特定日が複数存在する場合は、それぞれにおいてレベル値を整合する必要が ある（例：「月～金はレベル2だが、土日はレベル0」、「通常はレベル5だが、毎月1日にリブートをする ためその日はレベル3」など）。 また、「ユーザの休日」だけでなく、「ベンダの休日」についても特定日として認識し、運用保守体制等 を整合すること。 ○ A.1.1.3 選択時の条件 夜間のみ 夜間に実施する業務はなく、システムを停 停止 止可能。 （9時～21 時） [-] 運用時間をもっと限って業務を稼働さ せる場合 [+] 24時間無停止やリブート処理等の短時 間の停止のみを考える場合 【レベル】 ()内の時間は各レベルの一例を示したもので、レベル選定の条件とはしていない。「規定なし」は、固 定のサービス時間が存在しないことを示し、基本的にシステムは停止していて、必要に応じてユーザ がシステムを起動するようなケースを想定している（例：障害発生に備えた予備システム、開発・検証 用システム等）。「定時内」や「夜間のみ」は、一般的な業務形態を想定したもので、業務が稼動する 時間帯が異なるシステムにおいては、時間帯をスライドさせるなどの読替えが必要である。「停止あ り」とは、システムを停止しなければならない時間帯ではなく、システムを停止できる可能性のある時 間帯を指す。「24時間無停止」は、オンライン業務が稼動していない時間にバッチを稼動させる必要が あり、システムを停止することができないようなケースも含まれる。 ○ A.1.1.2 社会的影響が限定されるシ ス テ ム 備考 【重複項目】 C.1.1.1。運用時間は、システムの可用性の実現レベルを表す項目であるとともに、運用・保守性に関 する開発コストや運用コストを検討する上でも必要となる項目であるため、可用性と運用・保守性の両 方に含まれている。 ② 項目一覧：03_hikinou_list_201002.pdf 項番 大項目 中項目 A.1.1.1 可用性 継続性 小項目 運用スケジュール 重 複 項 目 小項目説明 重 要 項 目 システムの稼働時間や停止運用に関する情報。 レベル メトリクス (指標) 0 1 運用時間（通常） 規定無し 2 3 4 運用 コスト への 影響 5 定時内 夜間のみ停 1時間程度の 若干の停止 24時間無停 （9時～17時） 止 停止有り 有り 止 （9時～21時） （9時～翌朝8 （9時～翌朝8 時） 時55分） 備考 【重複項目】 C.1.1.1。運用時間は、システムの可用性の実現レベルを表す項目であるとともに、運用・保守性に関する開発コスト や運用コストを検討する上でも必要となる項目であるため、可用性と運用・保守性の両方に含まれている。 【メトリクス】 運用時間は、オンライン/バッチを含みシステムが稼動している時間帯を指す。 【レベル】 ()内の時間は各レベルの一例を示したもので、レベル選定の条件とはしていない。「規定無し」は、固定のサービス 時間が存在しないことを示し、基本的にシステムは停止していて、必要に応じてユーザがシステムを起動するような ケースを想定している（例：障害発生に備えた予備システム、開発・検証用システム等）。「定時内」や「夜間のみ停 止」は、一般的な業務形態を想定したもので、業務が稼動する時間帯が異なるシステムにおいては、時間帯をスラ イドさせるなどの読替えが必要である。「停止有り」とは、システムを停止しなければならない時間帯ではなく、シス テムを停止できる可能性のある時間帯を指す。「24時間無停止」は、オンライン業務が稼動していない時間にバッチ を稼動させる必要があり、システムを停止することができないようなケースも含まれる。 ○ ○ ○ ○ ○ 計画停止の有無 計画停止有り 計画停止有り 計画停止無し （運用スケ （運用スケ ジュールの変 ジュールの変 ○ 更可） 更不可） A.1.1.2 運用時間（特定 日） A.1.1.3 規定無し 定時内 夜間のみ停 1時間程度の 若干の停止 24時間無停 （9時～17時） 止 停止有り 有り 止 （9時～21時） （9時～翌朝8 （9時～翌朝8 時） 時55分） 【重複項目】 C.1.1.2。運用時間は、システムの可用性の実現レベルを表す項目であるとともに、運用・保守性に関する開発コスト や運用コストを検討する上でも必要となる項目であるため、可用性と運用・保守性の両方に含まれている。 【メトリクス】 特定日とは、休日/祝祭日や月末月初など通常の運用スケジュールとは異なるスケジュールを定義している日のこ とを指す。特定日が複数存在する場合は、それぞれにおいてレベル値を整合する必要がある（例：「月～金はレベ ル2だが、土日はレベル0」、「通常はレベル5だが、毎月1日にリブートをするためその日はレベル3」など）。 また、「ユーザの休日」だけでなく、「ベンダの休日」についても特定日として認識し、運用保守体制等を整合するこ と。 【重複項目】 C.2.1.1。計画停止の有無は、システムの可用性の実現レベルを表す項目であるとともに、運用・保守性に関する開 発コストや運用コストを検討する上でも必要となる項目であるため、可用性と運用・保守性の両方に含まれている。 ○ 【運用コストへの影響】 計画停止が”有り”の場合、事前のバックアップや、システム構成に応じた手順準備など、運用時のコストがかさむ。 … … ＝ ③ スプレッドシート：05_hikinou_sheet.xls 項番 C.1.1.1 大 中 項 項 目 目 運 用 ・ 保 守 性 小項目 通 運用時間 常 運 用 小項目説明 重 重 複 要 項 項 目 目 システム運用を行う時間。利用者やシステム 管理者に対してサービスを提供するために、 システムを稼動させ、オンライン処理やバッチ 処理を実行している時間帯のこと。 レベル メトリクス (指標) 0 運用時間（通 規定無し 常） 1 定時内 （9時～17 時） 2 3 夜間のみ 停止 （9時～21 時） 1時間程度 の停止有 り （9時～翌 朝8時） 4 若干の停 止有り （9時～翌 朝8時55 分） 5 24時間無 停止 ③ 運用時間（特 規定無し 定日） バックアップ システムが利用するデータのバックアップに関 する項目。 選択レベル 2 選択時の条件 選択レベル 夜間のみ 夜間に実施する業務はなく、システ 停止 ムを停止可能。 （9時～21 時） [-] 運用時間をもっと限って業務を 稼働させる場合 [+] 24時間無停止やリブート処理等 の短時間の停止のみを考える場合 4 規定無し 通常と異なる運用時間となる特定 日は存在しない。 2 若干の停 止有り （9時～翌 朝8時55 分） 選択時の条件 24時間無停止での運用は必要ない が、極力システムの稼働は継続さ せる。 社会的影響が極めて大きいシステム 選択レベル 5 選択時の条件 24時間無 システムを停止できる時間帯が存 停止 在しない。 [-] 1日のスケジュールで定期的に 運用を停止する時間帯が存在する 場合 [-] 夜間のアクセスは認めないな ど、長時間運用を停止する場合 [+] 24時間無停止で運用する場合 【レベル】 （）内の時間は各レベルの一例を示したもので、レベル選定の条件とはしていない。規定無しは、固 定のサービス時間が存在しないことを示し、基本的にシステムは停止していて、必要に応じてユー ザがシステムを起動するようなケースを想定している（例：障害発生に備えた予備システム、開発・ 検証用システム等）。定時内や夜間のみ停止は、一般的な業務形態を想定したもので、業務が稼動 する時間帯が異なるシステムにおいては、時間帯をスライドさせるなどの読替えが必要である。停 止有りとは、システムを停止しなければならない時間帯ではなく、システムを停止できる可能性のあ る時間帯を指す。24時間無停止は、オンライン業務が稼動していない時間にバッチを稼動させる必 要があり、システムを停止することができないようなケースも含まれる。 定時内 （9時～17 時） 夜間のみ 停止 （9時～21 時） 1時間程度 若干の停 の停止有 止有り り （9時～翌 （9時～翌 朝8時55 朝8時） 分） ○ ○ C.1.2.1 社会的影響が限定されるシステム 備考 【重複項目】 A.1.1.1。運用時間（通常）は、システムの可用性の実現レベルを表す項目でもあるため、重複項目と なっている。 【メトリクス】 運用時間は、オンライン/バッチを含みシステムが稼動している時間帯を指す。 ○ ○ C.1.1.2 社会的影響が殆ど無いシステム 運用コ ストへ の影 響 データ復旧範 復旧不要 囲 一部の必 システム 要なデータ 内の全 のみ復旧 データを復 旧 24時間無 停止 【重複項目】 A.1.1.2。運用時間（特定日）は、システムの可用性の実現レベルを表す項目でもあるため、重複項 目となっている。 0 [+] 休日にバックアップ運用を行う など、通常とは異なる運用時間とな る特定日が存在する場合 【メトリクス】 特定日とは、休日/祝祭日や月末月初など通常の運用スケジュールとは異なるスケジュールを定義 している日のことを指す。特定日が複数存在する場合は、それぞれにおいてレベル値を整合する必 要がある（例：「月～金はレベル2だが、土日はレベル0」、「通常はレベル5だが、毎月1日にリブート をするためその日はレベル3」など）。 また、ユーザの休日だけでなく、ベンダの休日についても特定日として認識し、運用保守体制等を 整合すること。 夜間のみ 週末はバックアップ運用のみのた 停止 め、夜間は停止する。 （9時～21 時） [-] 週末運用するバックアップや バッチ処理などが存在せず、土休 日は運用を停止する場合 [+] 休日出勤する社員の業務に必 要なため、土休日も運用する場合 5 24時間無 システムを停止できる時間帯が存 停止 在しない。 外部デー 全データを復旧するためのバック タは利用 アップ方式を検討しなければならな できない いことを想定。 2 外部デー 全データを復旧するためのバック タは利用 アップ方式を検討しなければならな できない いことを想定。 3 データの 内部統制対応の要件に基づき、 長期保存 データの履歴を保存する必要があ （アーカイ る。 ブ） [-] バックアップはデータ損失から の回復に対する用途にのみ使用す る場合 [-] 定期的に運用を停止する日が 存在する場合 【重複項目】 A.2.6.2。可用性ではデータをどこまで保全するかという観点で、運用ではデータをどこまで復旧させ るかという観点で本項目が必要となり、重複項目としている。 【メトリクス】 システムを障害から復旧するためには、データバックアップ以外に、OSやアプリケーションの設定 ファイル等を保管するシステムバックアップも必要となることが考えられる。システムバックアップの 取得方法や保管方法についても、同時に検討すべきである。 ○ C.1.2.2 外部データの 全データ 一部の 利用可否 の復旧に データ復 利用できる 旧に利用 できる 外部デー タは利用 できない ○ C.1.2.3 項目一覧と同一の情報 （236項目分： 「項目」 「レベル」「備考」など） 【レベル1】 一部の必要なデータとは、業務継続性の要求を満たすために必要となるようなデータを想定してい る。 【メトリクス】 外部データとは、当該システムの範囲外に存在するシステムの保有するデータを指す（開発対象の システムと連携する既存システムなど）。外部データによりシステムのデータが復旧可能な場合、シ ステムにおいてバックアップ設計を行う必要性が減るため、検討の優先度やレベルを下げて考える ことができる。 1 一部の 他システムから必要なデータを修 データ復 復することができるため、バックアッ 旧に利用 プによってシステムの全データを復 できる 旧しなくてもよいことを想定。 2 [-] 外部に同じデータを持つシステ ムが存在するため、本システムに 障害が発生した際には、そちらから データを持ってきてシステムを復旧 できるような場合 [-] 外部に同じデータを持つシステ ムが存在するため、バックアップを 取得しなくても本システムの全デー タを復旧できるような場合 バックアップ 利用範囲 バックアッ 障害発生 プを取得し 時のデー ない タ損失防 止 ユーザエ データの ラーからの 長期保存 回復 （アーカイ ブ） 【レベル2】 ユーザエラーからの回復の場合、システムとしては正常に完了してしまった処理を元に戻さなけれ ばならないため、複数世代のバックアップの管理や時間指定回復（Point in Time Recovery）等の機 能が必要となる場合が考えられる。 ○ 1 障害発生 障害発生時に決められた復旧時点 時のデー （RPO）へデータを回復できれば良 タ損失防 い。 止 [-] 障害時に発生したデータ損失を 復旧する必要がない場合 [+] 復旧時点（RPO）が固定ではな く、障害の内容に応じて時間指定で 復旧する必要がある場合 2 ユーザエ 管理者の作業ミスなどによって発 ラーから 生したデータ損失についても回復で の回復 きることを保証したい。 [-] 管理者の作業ミスによる復旧は 管理者が作業前に個別にデータ保 全作業を実施することで担保するこ ととし、バックアップによる回復は必 要としない場合 [+] データ損失からの回復だけでな く、過去データの保存用途に用いる 場合 [-] 外部に同じデータを持つシステ ムが存在するため、本システムに 障害が発生した際には、そちらから データを持ってきてシステムを復旧 できるような場合 グレード表で追加されてい る情報 （92項目分： モデルシステ ムのレベル値） … Copyright © 2010-2015 IPA, All Rights Reserved Software Reliability Enhancement Center 32 章扉 ３ 非機能要求グレードを利用した非機能要求 の合意プロセス（ケーススタディ） Copyright © 2010-2015 IPA, All Rights Reserved Software Reliability Enhancement Center 33 ３-１ 非機能要求グレード利用方法 お客様と段階的に詳細化しながら非機能要求を確認する手法 段階① 「モデルｼｽﾃﾑの選定」：開発するシステムに最も近いモデルシステムを１つ選択 モデルシステムシートを使用し開発システムに最も近いモデルシステムを選択 モデルシステムシート （グレード表） 社会的影響が 殆どないシステム 社会的影響が 限定されるシステム 選択 社会的影響が 極めて大きいシステム 段階② 「重要項目のレベル決定」：樹系図で全体を俯瞰し、グレード表でレベル値を決定 「社会的影響が限定されるシステム」における「目標復旧時間（RTO）」の例 調整前 調整後 レベル2 12時間以内に復旧 レベル3 6時間以内に復旧 調整 要求により、レベルを調整 グレード表・樹系図 段階③ 「重要項目以外のレベル決定」：項目一覧で非機能要求項目の要求レベルを決定 「可用性」の重要項目以外の非機能要求項目を検討する例 項目一覧・樹系図 中項目 小項目 メトリクス（指標） 耐障害性 サーバ 冗長化（機器） 災害対策 システム 復旧方針 ・ ・ ・ ・ ・ ・ Copyright © 2010-2015 IPA, All Rights Reserved ・ ・ ・ 低 レベル0 非冗長構成 レベル1 特定のサーバで 選択 冗長化 レベル2 すべてのサーバ 高 で冗長化 Software Reliability Enhancement Center 34 ケーススタディ 想定システムイメージ 小売店から本部への「商品発注」、「商品受注」、「在庫管理」 システムを対象 在庫管理 小売店A 本部 商品発注 商品受注 ・・・ 小売店Z 商品発注 Copyright © 2010-2015 IPA, All Rights Reserved プ ロ フ ァ イ ル 業態：ホームセンター 店舗：県内20店舗 システム概要： 本部で一括納入・管理している商品の発 注～在庫管理までを自動化するシステム。 システムが利用不可能な状態に陥った場合、 企業活動に多大の影響を及ぼす。 Software Reliability Enhancement Center 35 ケーススタディ 段階①：モデルシステムを参考に方向性確認 お客様要求を「段階的詳細化」しながら確認するためのツール「群」 方向性の確認 コストに大きな影響がある 要求項目を決定 開発開始までに必要な 要求項目を決定 段階① モデルシステム シート （グレード表） グレード表・樹系図 項目一覧・樹系図 イメージレベル 重要項目 詳細項目 １６項目 ９２項目 ２３６項目 Copyright © 2010-2015 IPA, All Rights Reserved Software Reliability Enhancement Center 36 ケーススタディ 段階①-1 モデルシステムの選択 システムのプロファイルから最も近いモデルシステムを選択 社会的影響が ほとんど無いシステム 社会的影響が 限定されるシステム 社会的影響が 極めて大きいシステム 企業活動の基盤となるシステ ムで、その機能が低下又は利 用不可能な状態に陥った場 合、当該企業活動に多大の 影響を及ぼすと共に取引先や 顧客等の外部利用者にも影 響を及ぼすもの。 ここでは、企業内のネットワー クに限定した基幹システムを 想定している。 国民生活・社会経済活動の 基盤となるシステムで、その 機能が低下又は利用不可能 な状態に陥った場合、国民生 活・社会経済活動に多大な 影響を与えるもの。 ここでは、不特定多数の人が 利用するインフラシステムを 想定している。 モデルシ ステム名 企業の特定部門が比較 的限られた範囲で利用し ているシステムで、機能が 低下または利用不可な状 モデルシ 態になった場合、利用部 ステムの 門では大きな影響がある 概要 が、その他には影響しな いもの。 ここでは、ごく小規模のイ ンターネット公開システム を想定している。 システム基盤の発注者要求を見える化する非機能要求グレード検討会公開資料「非機能要求グレード」利用ガイドより引用 Copyright © 2010-2015 IPA, All Rights Reserved Software Reliability Enhancement Center 37 ケーススタディ 段階①-2 モデルシステムとの差を確認 選択したモデルシステムと開発するシステムの差を確認する お客様（発注者） モデルシステム定義 稼働率99.99% システムダウンは避けたい （年間停止許容時間 1時間未満） 障害時は6時間以内に復旧 被災時は1週間以内で復旧 発注の95%以上を3秒以内 ・ ・ ・ 比較 1営業日以内での復旧 被災時は1週間以内で復旧 性能面のサービスレベル規定 ・ ・ ・ 「社会的影響が限定されるシステム」が一番近い Copyright © 2010-2015 IPA, All Rights Reserved Software Reliability Enhancement Center 38 ケーススタディ 「社会的影響が限定されるシステム」 の構成イメージ 拠点内LAN VPN 正センタ バック エンド バックアップセンタ WEB WEB /AP /AP サーバ サーバ WEB WEB WEB /AP /AP /AP サーバ サーバ サーバ コールドスタンバイ自動切換 DB サーバ 予備 サーバ ストレージ Copyright © 2010-2015 IPA, All Rights Reserved 保管 DB サーバ 予備 サーバ 開発環境 Software Reliability Enhancement Center 39 ケーススタディ 段階②：重要項目のレベル決定 グレード表を用いてコスト等に影響がある重要な要求項目を決定 方向性の確認 コストに大きな影響があ る要求項目を決定 開発開始までに必要な 要求項目を決定 段階 ② モデルシステムシート （グレード表） グレード表・樹系図 項目一覧・樹系図 イメージレベル 重要項目 詳細項目 １６項目 ９２項目 ２３６項目 Copyright © 2010-2015 IPA, All Rights Reserved Software Reliability Enhancement Center 40 ケーススタディ 段階②-1 重要項目の調整前 「重要項目」の要求レベルの設定例を用いて、より「早期に」 「重要」な非機能要求項目（抜粋） 要求レベルの設定例 判断 重要項目例 メトリクス(指標) レベル 業務継続性 ｻｰﾋﾞｽ切替時間 3 60分未満 目標復旧水準 RTO(目標復旧時間) 2 12時間以内 稼働率 稼働率 4 99.99% 大規模災害時 ｼｽﾃﾑ再開目標 3 1週間以内 業務処理量 同時ｱｸｾｽ数 1 上限が決まっている ﾊﾞｯﾁ処理件数 0 件数が決まっている 業務量増大度 ｵﾝﾗｲﾝ件数増大率 1 1.2倍 ｵﾝﾗｲﾝﾚｽﾎﾟﾝｽ 通常時ﾚｽﾎﾟﾝｽ順守率 3 90% 運用時間 運用時間(通常) 4 若干の停止有り 内部統制対応 対応実施有無 1 既存の社内規定での対応実施 移行ｽｹｼﾞｭｰﾙ ｼｽﾃﾑ停止可能日時 4 夜間など ｾｷｭﾘﾃｨﾘｽｸ分析 ﾘｽｸ分析範囲 1 重要資産 地域的広がり 地域的広がり 0 拠点内 Copyright © 2010-2015 IPA, All Rights Reserved 選択時の条件 （１）重要項目 毎に、該当モデ ルにおける標準 レベルを選択し た条件を示す。 （２）レベルを 調整する際の条 件を示す。 Software Reliability Enhancement Center 41 ケーススタディ 段階②-2 重要項目の調整後 「重要項目」の要求レベルの設定例を用いて、より「早期に」 「重要」な非機能要求項目（抜粋） 要求レベルの設定例 判断 レベルアップ 重要項目例 メトリクス(指標) レベル 復旧時間：6時間以内 選択時の条件 業務継続性 ｻｰﾋﾞｽ切替時間 3 60分未満 目標復旧水準 RTO(目標復旧時間) 2 12時間以内 稼働率 稼働率 4 99.99% 大規模災害時 ｼｽﾃﾑ再開目標 3 業務処理量 同時ｱｸｾｽ数 1 ﾊﾞｯﾁ処理件数 0 業務量増大度 ｵﾝﾗｲﾝ件数増大率 1 1.2倍 ｵﾝﾗｲﾝﾚｽﾎﾟﾝｽ 通常時ﾚｽﾎﾟﾝｽ順守率 3 90% 運用時間 運用時間(通常) 4 内部統制対応 対応実施有無 1 移行ｽｹｼﾞｭｰﾙ ｼｽﾃﾑ停止可能日時 4 ｾｷｭﾘﾃｨﾘｽｸ分析 ﾘｽｸ分析範囲 1 （２）レベルを 若干の停止有り 調整する際の条 既存の社内規定での対応実施 件を示す。 レベルダウン 夜間など 重要資産夜間停止：夜間要員不要 地域的広がり 地域的広がり 0 拠点内 Copyright © 2010-2015 IPA, All Rights Reserved 仮決め （１）重要項目 稼働率：後日最終決定 毎に、該当モデ 1週間以内 ルにおける標準 上限が決まっている レベルアップレベルを選択し 件数が決まっている 順守率：95%以上 た条件を示す。 Software Reliability Enhancement Center 42 ケーススタディ 段階③：重要項目以外のレベル決定 システム基盤構築のためのお客様要求を「段階的詳細化」 しながら確定 方向性の確認 コストに大きな影響が ある要求項目を決定 モデルシステムシート （グレード表） 開発開始までに必要 な要求項目を決定 段階 グレード表・ 項目一覧・樹系図 ③ 樹系図 イメージレベル 重要項目 詳細項目 １６項目 ９２項目 ２３６項目 Copyright © 2010-2015 IPA, All Rights Reserved Software Reliability Enhancement Center 43 ケーススタディ 段階③-1 「非機能要求項目一覧」の 要求レベルを活用 具体的な選択肢を提示することで「誤解なく」要求を確認 小項目 サーバ メトリクス （指標） 0 冗長化（機器） 非冗長構成 アーキテクチャ A レベル 1 B 保守/リカバリ待ち WEB/APサーバは入力を 分散させる方式にしよう 障害発生時のサービス中断 時間は60分目標 2 特定サーバを冗長化 A 冗 長 B DBサーバを二重化 全サーバ冗長化 A 冗 長 B 冗 長 全てのサーバを二重化 DBサーバを冗長化して自動切換、 再立ち上げ中は利用できない お客様が直接利用しないので 切替後に実施すれば問題ない 最適なのは「レベル1」だ!! Copyright © 2010-2015 IPA, All Rights Reserved Software Reliability Enhancement Center 44 ケーススタディ 段階③-2 「非機能要求項目一覧」の 網羅性を活用 チェックリストとして利用することで要求を「漏れ」がないよう確認 ・・・ 要件定義書 確認 仕様書 非機能要求項目一覧 記載漏れなどはないか？ 要求間に矛盾はないか？ 要求の確認漏れはないか？ 要求に誤りはないか？ 未決定な項目は合意済か？ 仕様は要求を満たしているか？ 開発フェーズを開始しよう!! Copyright © 2010-2015 IPA, All Rights Reserved Software Reliability Enhancement Center 45 ３-２ まとめ：「非機能要求グレード」のメリット 非機能要求を「早期に」判断できる 最初は「モデルシステム」でイメージレベルから確認 「グレード表」で重要な項目に絞ってから検討 １から決めるのではなく、推奨された要求値を「調整」 非機能要求を「誤解なく」提示・確認できる 要求レベルで「具体的な選択肢」を提示 「十分に」「しっかりと」のようなあいまいな表現ではなく、 「レベル3で」と具体的に確認 非機能要求を「漏らさずに」確認できる 網羅的な要求項目の一覧をチェックリストとして活用 樹系図による全体を俯瞰することで「矛盾」がないかチェッ ク Copyright © 2010-2015 IPA, All Rights Reserved Software Reliability Enhancement Center 46 ４ 非機能要求グレードの開発と評価 Copyright © 2010-2015 IPA, All Rights Reserved Software Reliability Enhancement Center 47 ４-２ 「非機能要求グレード検討会」が作成 「非機能要求の見える化」という課題に共感したベンダ６社で構成 システム基盤の発注者要求を見える化する 正式名称 非機能要求グレード検討会（略称： 非機能 要求グレード検討会） IPA 独立行政法人 情報処理推進機構 へ移管 ㈱ＮＴＴデータ、富士通㈱、日本電気㈱、 ㈱日立製作所、 参加企業 三菱電機インフォメーションシステムズ㈱ 、 沖電気工業㈱ 活動時期 2008年4月～2010年3月（解散） 情報システムを開発する際には、受発注者 の双方が要求を正確に認識することに多大 な労力を使っている。中でも「非機能要求」 と呼ばれる要求はその認識共有が難しい、 かつ、その手段が確立していない。 設立趣旨 そこで本検討会は非機能要求の選択肢を 提示しメニュー化する「非機能要求グレード」 を策定し開発ベンダのみならず、発注者企 業を含む業界全体へ広くその利用を働きか ける。 Copyright © 2010-2015 IPA, All Rights Reserved http://sec.ipa.go.jp/reports/20100416.html Software Reliability Enhancement Center 48 ４-３ 非機能要求グレードの検討経緯 お客様（ユーザ企業）に活用頂けるようご意見を取り入れながら「非 機能要求グレード」を開発／改訂した。 2008年度 上期 2008年9月29日 非機能要求項目一覧 公開 2009年度 下期 上期 2009年5月26日 非機能要求グレード 評価版公開 お客様 机上評価 お客様による評価 Copyright © 2010-2015 IPA, All Rights Reserved 下期 2010年2月25日 非機能要求項目 実現レベル 評価結果 体系化 設定 反映 お客様 ヒアリング 2010年度以降 非機能要求グレード 完成版公開 評価結果 反映 実システム による評価 IPA/SEC での活動 (2010年度 は普及活動) パブリック コメント募集 Software Reliability Enhancement Center 49 ４-４ ユーザ評価：パブリックコメント パブリックコメントを通じて幅広い方々の意見を取 り入れ、広く利用出来る成果とした。 実施方法 非機能要求グレード公式Webサイトでの募集（及びプレスリリース等での依頼） アンケート調査及び自由記入形式によるコメントを収集 評価対象 2009年5月公開版 非機能要求グレード一式 実施期間 2009年5月26日から2009年6月30日まで 回答数 回答数 30回答、コメント数 391件 評価結果・ ご意見など アンケートの結果、非機能要求グレードの各ツールについて概ね「わかりやすい」 「すぐにシステム開発へ適用する」という意見が得られた。 項目について解説が不足しているなど、改善のためのｺﾒﾝﾄを多数得られた。 検討会が目標としていた経済産業省が実施した「情報システムの信頼性向上に 関するガイドライン第２版」に対するパブリックコメントの結果である「10社から80 件程度」より多くのコメントが得られた。 パブリックコメント結果報告書が公式Webサイトにて公開 http://www.nttdata.com/jp/ja/nfr-grade/public.html Copyright © 2010-2015 IPA, All Rights Reserved Software Reliability Enhancement Center 50 ４-４ ユーザ評価：実践的評価 お客様（ユーザ企業）２社のシステムを利用して、 「非機能要求グレード」の実践的評価を実施した。 評価実施者 非機能要求グレード評価委員会 委員会 参加者 ユーザ企業2社※、検討会参加ベンダ企業6社 ※ 東京海上日動火災保険、東京ガス（ティージー情報ネットワーク） 実施内容 システムの企画・要件定義工程において、有効に使えるツールであることを確認 ユーザ企業で実際に稼働するシステムを題材に適用評価を実施 稼働中のシステム（コンタクト履歴データベースシステム、 TESﾒﾝﾃﾅﾝｽ業務支援システ ム）に対し、要求時点と稼働時点の非機能要求明確化と比較 実施期間 2009年8月～10月 （計2回の委員会、20回のタスクフォースを開催） 評価結果・ ご意見など 利用ガイドで示した使い方、モデルシステムの例示、レベルの妥当性・十分性、 独自モデ ルの設定しやすさなど個別の構成ツールに対して有効と評価。 ユーザ企業内にデータセンタなどの共通インフラ基盤や独自のランク付けが存在したため、 それを利用して段階的に非機能要求を確認する活用例の案を得ることができた。 活動報告書が経済産業省より公開中 http://www.meti.go.jp/policy/it_policy/softseibi/index.html#04 Copyright © 2010-2015 IPA, All Rights Reserved Software Reliability Enhancement Center 51 ４-５ ユーザ評価まとめ 評価を通じて非機能要求グレードの実用性を検証 評価施策 変更点 具体例 項目やレベルの解説を追加 利用方法や内容に 関する解説の拡充 運用中システムを 対象とした評価 ドキュメントを目的に応じて分割 列の追加・定義の明確化 要求を決めづらい表現の見直し 非機能要求グレードの 項目・レベルを総見直し 項目やレベルの追加・統廃合 モデルシステムの調整 パブリックコメント の実施 スプレッドシート形式での提供 利用形態の改善 モデルシステムシートの提供 カスタマイズができるよう 使用条件を緩和 Copyright © 2010-2015 IPA, All Rights Reserved Software Reliability Enhancement Center 52 ４-６ 非機能要求グレードの今後 非機能要求グレードは2010年3月末にＩＰＡ／ＳＥＣへ移管し、 2010年度以降ＩＰＡ／ＳＥＣの活動として普及活動、改善活動を実施 検討会参加各社は成果を社内のＳＩ活動の中で活用 各社 ＩＰＡ／ＳＥＣへ移管 SI活動の中で活用 各社社内標準 など 各社社内標準 など 各社社内標準 など Copyright © 2010-2015 IPA, All Rights Reserved Software Reliability Enhancement Center 53 章扉 ５ 非機能要求グレードの活用事例 ⇒個々の事例は、活用事例集を参照ください。 Copyright © 2010-2015 IPA, All Rights Reserved Software Reliability Enhancement Center 54 ５-１ 非機能要求グレードの基本的な活用シーン 活用シートを適宜加工することでさまざまなワークシートとして 活用できる。 （１）要件定義書やＲＦＰに添付 上記資料の非機能要求はまとめて書かれていない。 このため、付録などに非機能要求を添付して抜け・ もれチェックに使う。また、まとめることで矛盾や 優先順位の検討が容易になる。 （２）非機能要求ヒアリング用シート 要件定義を行う場合、業務担当者や運用担当者に 非機能要求を確認する際に使う （３）非機能要件チェックシート 第三者が非機能要求グレードを使わずに作成した 要件定義のチェックを行う時に使う （４）既存のシステム診断シート 既存のシステムの非機能要求が正しく設定されて いるかを診断し、ITリスクや過剰なシステムを把握 Copyright © 2010-2015 IPA, All Rights Reserved Software Reliability Enhancement Center 55 ５－２ 共通インフラ基盤や社内グレードとしての活用例 社内に共通インフラ基盤や社内グレードが存在する場合には、非機能要求いくつ かのグループに体系化することで、非機能要求グレードを効果的に活用できる。 グ ル ー プ ③ グ ル ー プ ② グ ル ー プ ① 性能･拡張性（ユーザ数、同時アクセス数） 移行性（移行方式） システム環境・エコ（システム特性） 個別調整項目： 構築するシステムに応じてレベルが異なる項目 etc. 社内ランクＡ 社内ランクＢ 可用性=超高 セキュリティ=高 社会的に影響がある 社内グレード別に、 項目のレベルを定 義したセットを作っ ておく 毎回個別にレベルを 検討・調整して決め る 可用性=高 セキュリティ=中 全社的業務に影響がある 社内ランクＣ 可用性=低 セキュリティ=低 社内ローカルシステム 社内グレード：各社独自のシステム分類定義によってレベルが分かれる項目 システム共通基盤・設備・社内規程 可用性 （ネットワーク機器、災害対策） 運用性 （運用管理方針） セキュリティ （セキュリティ前提条件） 環境・エコ （データセンタの仕様） etc. 共通基盤： 共通インフラ基盤・社内規則等あらかじめ レベルが決まっている項目 項目一覧を用いて 設定値を決めておく ※経済産業省 「非機能要求グレード評価委員会報告書」を元に作成 Copyright © 2010-2015 IPA, All Rights Reserved Software Reliability Enhancement Center 56 ５－３ 活用事例と適用工程との対応 事 例 開発標 準策定 1 予算 予算 作成 概算 見積 SI 提案 開発工程 要件 定義 設計 運用 テスト 障害 診断 ○ ユーザ ベンダ ○ ○ ○ 3 ○ ○ ○ 4 ○ ○ ○ ○ ○ 5 ○ 6 新 規 追 加 事 例 システム 再評価 ○ 2 既 存 事 例 利用者 ○ ○ ○ 7 ○ ○ ○ 8 ○ ○ ○ 9 ○ ○ ○ ○ ○ 10 ○ 11 ○ ○ ○ 12 ○ ○ ○ 13 ○ ○ 14 ○ 15 ○ 16 ○ ○ ○ ○ ○ 17 ○ ○ ○ ○ 活用事例集第2版 http://www.ipa.go.jp/files/000004624.ppt Copyright © 2010-2015 IPA, All Rights Reserved Software Reliability Enhancement Center 57 ５-４ クラウドサービスと非機能要求グレード（1/2) クラウドサービスは、作るから選択への転換 オンプレ ミス IaaS PaaS SaaS 機能要求 業務アプリ ケーション (業務フロー、データ項目等) 非機能要求 （可用性、性能・拡張性、運用保守性、 移行性、セキュリティ、 システム環境・エコロジー、 ユーザビリティ等） グ レ非 実行基盤 ー機 ド能 ハード、OS、 の 要 ミドルウェア 対求 象 ：利用者が決めることができない ：利用者が決めることができる（自分で作る） Copyright © 2010-2015 IPA, All Rights Reserved Software Reliability Enhancement Center 58 ５-４ クラウドサービスと非機能要求グレード（2/2) 次のステップでクラウドサービスを検討： 1. 利用者の要求を明確にする（機能、非機能とも） 2. クラウドサービスの機能・SLA(=非機能要件)を評価する。 ⇒クラウドサービスの情報開示が必要 3. 双方の要件のすり合わせ⇒「割り切りも必要」 クラウドの利便性の裏にある、ITリスクの把握をする 要件を満たさない場合、ビジネス側でITリスクの担保や受容 Ex. クラウドサービスが何らかの理由で使えない場合に備え、人手の作業で業務を代行するなど の対策を講じておく。 非機能要求 検証、リスクの担保・受容 ＳＬＡ クラウド サービス 利用者 Copyright © 2010-2015 IPA, All Rights Reserved クラウドサービス Software Reliability Enhancement Center 59 章扉 ６ ご参考：非機能要求グレードのアンケート調査 Copyright © 2010-2015 IPA, All Rights Reserved Software Reliability Enhancement Center 60 6-1 アンケート調査概要(1/2) ■アンケート方法 ●アンケート先 •ユーザ企業、ベンダ企業 •大企業、中堅企業（企業：資本金10億円以上／未満） •官公庁・自治体(自治体：人口30万以上／未満) •首都圏の企業・団体、地方の企業・団体 •教育研修機関：「非機能要求グレード」は要件定義の一部であり、この要件定義の研修を実施して いる教育研修機関は重要 ●アンケート方式 多肢選択肢と記述式の併用 ●回答カテゴリの設定 •ユーザ１：非機能要求や「非機能要求グレード」を知らないユーザ •ユーザ２：「非機能要求グレード」を知っているユーザ（活用、未活用） •ベンダ１：非機能要求や「非機能要求グレード」を知らないベンダ •ベンダ２： 「非機能要求グレード」を知っているベンダ（活用、未活用） •教育研修機関：要件定義の研修を実施している機関 ●アンケート内容（回答カテゴリ別の設問） ユーザ１、ユーザ２、ベンダ１、ベンダ２ 非機能要求グレードの認知度、非機能要求項目の考慮性、非機能要求の決定プロセス、非機能要 求の課題 教育研修機関 非機能要求グレードの認知度、要件定義研修について Copyright © 2010-2015 IPA, All Rights Reserved Software Reliability Enhancement Center 61 6-1 アンケート調査概要(2/2) ●アンケート回答先のプロフィール •ユーザ29団体、ベンダ30団体、教育研修機関8団体、計67団体 •大企業、中堅、官公庁・自治体、首都圏だけでなく地方の団体も回答 40 回答団体数 35 ユーザ１：ユーザ側で非機能要求 あるいは非機能要求グレード知ら ず 8 ユーザ２：ユーザ側で非機能要求 グレードを認識、または活用 25 11 ベンダ１：ベンダ側で非機能要求 あるいは非機能要求グレード知ら ず 30 15 回 答 団 体 数 ベンダ２：ベンダ側で非機能要求 グレードを認識、または活用 4 19 3 5 25 教育 20 15 15 10 ユーザ 20 5 教育：教育研修機関 ベンダ 9 0 大企業 図2.1.1回答状況 図2.1.2団体・組織規模 50 45 60 4 50 40 横軸は団体・組織の種別、縦軸の内訳は回答者の立場 図2.1.1は回答者の立場での回答数 35 回 答 団 体 数 30 29 教育 ベンダ 20 ユーザ 15 5 15 4 3 1 1 官公庁・自治体 教育研修機関 その他 0 民間企業 回 答 団 体 数 30 教育 28 ベンダ ユーザ 20 10 10 8 40 25 10 中堅 19 2 10 図2.1.3団体・組織の種別 Copyright © 2010-2015 IPA, All Rights Reserved 0 首都圏 地方 図2.1.4回答者地域 Software Reliability Enhancement Center 62 6-2 「非機能要求グレード」について(1/2) ●「非機能要求グレード」認知状況（図2.2.1） ユーザ側は4団体で14%の認知度、ベンダ側は11団体で37%の認知度 合計で15団体、25%の認知度 ●「非機能要求グレード」活用状況（図2.2.2） ユーザ側は活用団体なし ベンダ側は「活用中」3団体10%の活用度、「ごく一部活用」を含めると5団体17%の活用度 60 60 50 50 40 回 答 団 体 数 2 その他 全く活用していない 40 44 知らない 30 知っている 19 20 回 答 団 30 体 数 20 52 1 11 4 0 全体 ユーザ 図2.2.1認知状況 だいたい活用 28 10 15 活用していたが今は活用していな い ごく一部で活用 24 25 10 1 0 ベンダ 活用中 2 3 全体 2 3 ユーザ ベンダ 図2.2.2活用状況 ●未活用の理由 •利用ノウハウが足りない •デファクトスタンダード化していない •時間的な猶予の関係で類似（非機能要求定義）の既存資産を流用活用することが多い •社内標準への取り込み作業中 •これから活用しようと考えている Copyright © 2010-2015 IPA, All Rights Reserved Software Reliability Enhancement Center 63 6-2 「非機能要求グレード」について(2/2) ●「非機能要求グレード」について 「非機能要求グレード」を認知している15団体のアンケート結果 ①モデル数は適切（図2.2.3） ②項目数は「適量」と「多い」が拮抗（図2.2.4） ③ドキュメントは分かりやすい（図2.2.5） ④今後の活用団体はベンダが主（図2.2.6） ⇒「非機能要求グレード」は問題なし ⇒普及促進策：認知度を上げ活用事例の提示が重要（ベンダ側は今後の活用が期待できる） 100% 90% 100% 7% 7% 9% 80% 70% 70% 60% 60% その他 40% 100% 87% モデルが少なすぎる 82% 適切 25% 47% 20% 10% 10% 適量 90% 36% 25% 7% 0% 全体 ベンダ２ ベンダ２ 10 7% 7% 9% 9 9% 8 70% 7 4 その他 60% 全く分からなかった 73% 100% 64% あまり分からなかった 40% 分かった 30% 良く分かった 回 答 団 体 数 6 その他 5 1 4 ある 3 2 18% 13% 0% ない 3 5 20% 10% ユーザ２ 図2.2.4非機能要求項目数 80% 50% 多すぎる 40% 図2.2.3モデル数 100% 少ない 多い 20% ユーザ２ 少なすぎる 50% 40% 30% 0% その他 55% 50% 30% 全体 9% 90% 80% 50% 7% 9% 4 1 1 0 全体 ユーザ２ ベンダ２ 図2.2.5ドキュメントの分り易さ Copyright © 2010-2015 IPA, All Rights Reserved 全体 ユーザ２ ベンダ２ 図2.2.6今後の活用予定 Software Reliability Enhancement Center 64 6-3 非機能要求考慮状況(1/3) ●非機能要求の考慮状況（ユーザ29団体、ベンダ30団体） • 大項目：可用性、性能・拡張性、運用・保守性、移行性、セキュリティ、システム環境・エコロジー（2.3項の図では環 境と略） • 各大項目ごとに、「考慮：考慮していますか」、「レベル：レベルについて考慮していますか」、 「コミット：受発注者でコミット（合意）していますか」の3点をアンケート •選択肢「する」に5点、「時々する」に3点、「あまりしない」に1点を配点 ●特徴（図2.3.1） •システム環境・エコロジーと移行性が他に比べ低い •得点傾向：考慮（概念段階）＞レベル（詳細段階）＞コミット（合意段階） ●ユーザとベンダ比較（図2.3.2） 得点傾向：官公庁＞ベンダ＞ユーザ民間 ⇒普及促進策：ユーザ民間の非機能要求の考慮を高める必要がある 考慮 レベル ユーザ官公庁 コミット 可用性 5 環境コミット 環境レベル 4 環境 3 性能・拡張性 可用性考慮 5 4 3 環境考慮 ベンダ 可用性レベル 可用性コミット 性能・拡張性考慮 2 2 1 セキュリティコミット 1 ユーザ民間 性能・拡張性レベル 0 0 セキュリティレベル セキュリティ 運用・保守性 性能・拡張性コミット セキュリティ考慮 運用・保守性考慮 移行性コミット 運用・保守性レベル 移行性レベル 移行性 図2.3.1非機能要求考慮状況 Copyright © 2010-2015 IPA, All Rights Reserved 運用・保守性コミット 移行性考慮 図2.3.2非機能要求 ユーザ、ベンダ比較 Software Reliability Enhancement Center 65 6-3 非機能要求考慮状況(2/3) ●大企業と中堅の非機能要求考慮状況（図2.3.3） 得点傾向：大企業が高いものの顕著な差はない ●首都圏と地方企業の非機能要求考慮状況（図2.3.4） 得点傾向：首都圏が高いものの顕著な差はない 大企業 環境コミット 環境レベル 可用性考慮 5 4 首都圏 中堅 可用性コミット 3 環境考慮 環境コミット 可用性レベル 性能・拡張性考慮 環境レベル 性能・拡張性レベル セキュリティコミット 性能・拡張性コミット セキュリティレベル 1 可用性コミット 性能・拡張性考慮 性能・拡張性レベル 0 0 セキュリティレベル セキュリティ考慮 運用・保守性考慮 運用・保守性レベル 移行性レベル 可用性レベル 2 1 移行性コミット 4 3 環境考慮 2 セキュリティコミット 可用性考慮 5 地方 運用・保守性コミット 移行性考慮 図2.3.3大企業と中堅企業の非機能要求考慮状況 Copyright © 2010-2015 IPA, All Rights Reserved 性能・拡張性コミット セキュリティ考慮 運用・保守性考慮 移行性コミット 運用・保守性レベル 移行性レベル 運用・保守性コミット 移行性考慮 図2.3.4首都圏と地方の企業の非機能要求考慮状況 Software Reliability Enhancement Center 66 6-3 非機能要求考慮状況(3/3) ●情報システムのユーザ数による非機能要求考慮状況（図2.3.5） •得点傾向：ユーザ数が多いほど得点が高い •ユーザ数1万以上のシステムは各項目とも考慮性が高い ●情報システムの種別による非機能要求考慮状況（図2.3.6） •得点傾向：社会インフラ＞社外システム＞社内システム •社会インフラのシステムも各項目とも考慮性が高い ユーザ数1000未満 環境コミット 環境レベル ユーザ数1000以上1万未満 可用性考慮 5 4 社会インフラ 可用性レベル 環境コミット 可用性コミット 3 環境考慮 ユーザ数1万以上 性能・拡張性考慮 環境レベル 環境考慮 性能・拡張性レベル 1 セキュリティコミット 0 可用性レベル 可用性コミット 性能・拡張性考慮 性能・拡張性レベル 0 セキュリティレベル 性能・拡張性コミット セキュリティ考慮 運用・保守性考慮 運用・保守性レベル 移行性レベル 4 社内システム 2 1 移行性コミット 可用性考慮 5 3 2 セキュリティコミット 社外システム 運用・保守性コミット 移行性考慮 図2.3.5情報システムのユーザ数による非機能要求考慮状況 Copyright © 2010-2015 IPA, All Rights Reserved セキュリティレベル 性能・拡張性コミット セキュリティ考慮 運用・保守性考慮 移行性コミット 運用・保守性レベル 移行性レベル 運用・保守性コミット 移行性考慮 図2.3.6情報システムの種別による非機能要求考慮状況 Software Reliability Enhancement Center 67 6-4 非機能要求決定プロセス(1/3) ●非機能要求の参考にする基準（図2.4.1） ①「社内にある」は17%に過ぎす、「社内の類似案件を参考にする」団体が58%と多い ②参考にする基準が「ない」との回答はユーザ１で28%、ベンダ１で16%もある ③社外の基準 •JISの品質特性、Boehmの品質特性 •JUASの非機能要求ガイド •経産省とIPAで策定したTRM*1 •顧客側の持つ基準に基づく •非機能要求グレード（IPA） ●非機能要求設定項目数（図2.4.2） •「100項目以上」は7%、「50～100項目」が17%、「50項目未満」が59% •ベンダ２の設定項目数は他に比べ多い 100% 90% 80% 17% 28% 25% 18% 5% 8% 70% 16% その他 50% 48% 68% 64% 30% 20% 10% 21% 21% 17% 20% 11% 0% 全体 ユーザ１ ユーザ２ ベンダ１ 18% 社外のものを参考にする 50% 社内の類似案件を参考にする 40% 社内にある 30% 10% 0% ベンダ２ 図2.4.1参考にする基準 45% 50% その他 設定していない 59% 58% 67% 18% 50項目未満 50～100項目 100項目以上 50% 20% 25% 26% 60% ない 40% 4% 90% 70% 4% 58% 2% 80% 60% 50% 100% 36% 12% 7% 8% 全体 ユーザ１ 16% ユーザ２ ベンダ１ ベンダ２ 図2.4.2非機能要求設定項目数 *1 TRM(Technical Reference Model)は技術参照モデルで調達に必要な技術情報をまとめたもの http://www.ipa.go.jp/osc/trm/index.html Copyright © 2010-2015 IPA, All Rights Reserved Software Reliability Enhancement Center 68 6-4 非機能要求決定プロセス(2/3) ●非機能要求合意先 • ユーザ側の合意先（図2.4.3）は「CIOあるいは情報システム部門の責任者」、「業務部門」、「運用部門」が大半 •ベンダ側の合意先（図2.4.4）はベンダ内（図中黒線）よりユーザ側（図中赤点線）が圧倒的に多い ⇒受注者のベンダはユーザとの合意に重きをおいている ⇒ユーザ・ベンダ間の非機能要求に対する合意は重要 90 70 60 50 回 答 団 体 数 3 16 その他 70 2 運用部門 13 40 業務部門 17 30 20 6 80 14 企画部門 5 CIOあるいは情報システム部門の 責任者 10 18 17 0 2 2 1 3 3 1 1 全体 ユーザ１ ユーザ２ 経営層 図2.4.3非機能要求合意先（ユーザ側） Copyright © 2010-2015 IPA, All Rights Reserved 60 回 答 団 体 数 2 5 8 30 15 15 14 20 10 ベンダの品質管理部門 9 50 40 その他 ベンダのAPL開発部門 1 3 6 5 9 11 ベンダ１ ベンダ２ 10 0 全体 ユーザの運用部門 1 2 2 4 6 5 6 8 8 19 ベンダのPMO ユーザの業務部門 ユーザの企画部門 ユーザのCIOあるいは情報システム部門の責 任者 ユーザの経営層 図2.4.4非機能要求合意先（ベンダ側） Software Reliability Enhancement Center 69 6-4 非機能要求決定プロセス(3/3) ●非機能要求合意期間（図2.4.5） ベンダ２の合意期間はユーザ側やベンダ１に比べ長期間。これは非機能要求の重要性を認知のためか ●SLA締結状況（図2.4.6） ユーザ１の締結状況は良くないがベンダ側の締結状況も意外と悪い ⇒SLA締結で非機能要求のコストや品質に関して納得感が高まるので締結の促進化が望まれる 100% 100% 90% 80% 16% 9% 13% 25% 14% 10% 21% 13% 80% 70% 60% 90% 21% 21% その他 25% 5% 50% 73% 40% 30% 52% 42% 50% 50% 13% 17% 13% 5% 25% 10% 11% 9% 4% 全体 ユーザ１ 18% 60% ２週間程度 50% 1～3か月 40% 3か月以上 30% 28% ベンダ１ 図2.4.5非機能要求合意期間 Copyright © 2010-2015 IPA, All Rights Reserved ベンダ２ 21% 27% 21% その他 42% 10% 18% 33% 時々交わす 50% 16% 14% 全体 16% 4% ユーザ１ ユーザ２ 全く交わさない あまり交わさない 75% 0% ユーザ２ 9% 70% 20% 20% 0% ２週間未満 9% ベンダ１ 36% 必ず交わす 9% ベンダ２ 図2.4.6SLA締結状況 Software Reliability Enhancement Center 70 6-5 非機能要求の課題(1/3) ●非機能要求の設計時トラブル（図2.5.1） 59団体中、設計時のトラブル経験は38団体。ユーザ側は社内システム（図中赤点線）が多いが、ベンダ側は社会イ ンフラや社外システム（図中黒線）でのトラブルとなっている ●納入時の非機能要求出来具合（図2.5.2） 全体では「合意通り」、「だいたい合意通り」の比率は55%。高い比率とは言えない。特にベンダ２では低い。 ⇒非機能要求について受発注者間でよく合意する必要がある 40 100% 1 35 90% 4 その他 80% 社内支援システム 70% 30 25 15 回 答 20 社 数 15 5% 5% 25% 32% その他 26% 36% 73% 25% 60% 3 3 2 1 1 3 2 1 1 3 1 1 全体 ユーザ１ ユーザ２ ベンダ１ ベンダ２ 6 4 40% 社外の特定ユーザ向けシステム 30% 社会インフラシステム 20% 47% 53% 56% だいたい合意通り 50% 6 9 社外の不特定ユーザ向けシステ ム 図2.5.1非機能要求設計時のトラブル Copyright © 2010-2015 IPA, All Rights Reserved 合意した通りになっていないことが 多い 合意した通りになっていないことが 時々ある 50% 10 0 4% 社内基幹システム 9 5 5% 3% 合意通り 18% 10% 0% 8% 8% 全体 ユーザ１ ユーザ２ 11% 9% ベンダ１ ベンダ２ 図2.5.2納入時の非機能要求出来具合 Software Reliability Enhancement Center 71 6-5 非機能要求の課題(2/3) ●非機能要求の予算（図2.5.3） 予算の確保は全体で「大変」、「大変なことが多い」は79%に達していて十分に確保できていない。その中でベンダ２ では36%で確保できているとの回答。これは非機能要求を良く理解しているベンダ２が予算確保に積極的に働きかけ ているものと思われる。 ●予算と非機能要求のトレードオフ（図2.5.4） 「予算を増額する」は12%しかなく、「非機能要求のレベルを下げる」が43%に達している。 ●予算について回答者の見解 コスト優先で非機能要求はトレードオフされる 非機能要求を考慮するとコスト増になり価格競争に勝てない ユーザ企業の予算担当は非機能要求の必要性・重要性を理解できない ⇒非機能要求のレベルを下げることは、リスクの増大になることの認識が必要 ⇒システム基盤である非機能要求の重要性を訴求し予算の確保が必須 100% 90% 5% 15% 80% 16% 100% 5% 8% 25% 9% 90% 16% 17% 11% 25% 36% 80% 50% 70% 70% 55% 60% 50% その他 大変 64% 大変なことが多い 63% 68% 40% 75% 30% 27% 20% 10% 14% 0% 2% 全体 8% ユーザ１ ユーザ２ ベンダ１ 9% ベンダ２ 図2.5.3非機能要求の予算 Copyright © 2010-2015 IPA, All Rights Reserved 13% その他 42% 60% 受注者あるいは発注者にお願い する 50% 容易なことが多い 40% 容易 30% 42% 43% 非機能要求レベルを下げる 25% 55% 予算を増額する 42% 20% 10% 16% 28% 12% 21% 25% 0% 全体 ユーザ１ ユーザ２ 5% 9% ベンダ１ ベンダ２ 図2.5.4予算と非機能要求のトレードオフ Software Reliability Enhancement Center 72 6-5 非機能要求の課題(3/3) ●非機能要求の合意（図2.5.5） 受発注者間で非機能要求を合意することは「大変」、「大変なことが多い」が68%。特にベンダ１は79%、ベンダ２は 73% ベンダ側の苦労 •ユーザ側の非機能要求の考慮が低い •予算が十分に確保されていない •非機能要求と予算のトレードオフの実施 ●非機能要求の研修機会（図2.5.6） ユーザ、ベンダとも研修機会が不十分との回答 100% 2% 5% 4% 100% 5% 18% 90% 90% 19% 21% 80% 80% 50% 50% 70% 60% 9% 16% 63% 70% 60% 55% 50% 大変 大変なことが多い 40% その他 その他 74% 25% 30% 60% 50% 容易なことが多い 40% 容易 30% 64% 68% 72% 全くない あまりない 68% だいたいある 十分にある 50% 20% 25% 25% 10% 0% 20% 32% 5% 4% 全体 ユーザ１ 27% 16% 5% ユーザ２ ベンダ１ 10% 27% 14% 12% 全体 ユーザ１ 11% 0% ベンダ２ 図2.5.5非機能要求の合意 Copyright © 2010-2015 IPA, All Rights Reserved ユーザ２ ベンダ１ ベンダ２ 図2.5.6非機能要求の研修機会 Software Reliability Enhancement Center 73 ご静聴ありがとうございました Copyright © 2010-2015 IPA, All Rights Reserved Software Reliability Enhancement Center 74 付録 ＦＡＱ（１／３） ①要件をまとめるにあたり、最も苦労した点は？ 検討当初 ベンダー６社が使う「用語」が違っていた。また、同じ用語でも意味が 異なっている場合もあった。⇒用語集の作成 項目の数が多く、精査を重ねた点（最終的に236項目） 検討中盤 利用者の視点にするため、次の手段などで意見を取り込んだ。 社内及び、ユーザ企業ヒアリング 経済産業省のユーザビュー検討委員会 パブリックコメント 経済産業省のグレード評価委員会 特にパブリックコメントは、想定を遙かに超える391件が寄せられた。 検討終盤 利用ガイドなど、利用者の観点から２分冊にしたため、執筆量が増え、 作業が逼迫した。 Copyright © 2010-2015 IPA, All Rights Reserved Software Reliability Enhancement Center 75 付録 ＦＡＱ（２／３） ②ユーザ企業（特に経営層）との意識合わせ 次のスライドに示すような図で、「ユーザ/ベンダの部署と役割」を利用 ガイド（利用編）は説明。 とは言っても非機能要求をユーザが決めるのは大変。 非機能要求グレードは、モデルシステムを使い、コストに大きな影響 を与える重要な項目からから順番に決める手法を提供。 システムの重要度とそれに見合うコストのかけ方の合意を得ることを 目標にして、利用者と開発者の意識合わせをする手段を非機能要求 グレードは提供。 経営層へは、投資コストや事業リスクでの訴求が重要。 非機能要求のような技術用語では訴求は困難。 ⇒IPA／SECで経営層向けの小冊子 「経営に活かすIT投資の最適化」 を作成。 Copyright © 2010-2015 IPA, All Rights Reserved Software Reliability Enhancement Center 76 参考 要件定義の担当部署と役割 部署等／役割（ロール） 要件の定義内容 社長 経営層 担当役員 部門長 業務推進担当 業務部門 システム推進担当 事業要件 定義 業務要件 定義 関連会社 部門長 情報システム 部門 運用部門 の参画も 必要 システム 要件定義 システム開発担当 システム子会社 元請けベンダ ベンダ アウトソーサ 非機能要求 を含む サブベンダ SEC BOOK 「経営者が参画する要求品質の確保 第2版」から引用 Copyright © 2010-2015 IPA, All Rights Reserved Software Reliability Enhancement Center 77 付録 ＦＡＱ（３／３） ③調達品（ハード、ソフト、サービス）の考え方 非機能要求グレードは、システム全体の非機能要求を決める手法。 個々の実装技術や製品は競争領域として検討対象外。システムの 非機能要求をどのようなアーキテクチャ（技術・製品）で実現するか は、システム基盤の設計者（アーキテクト）やSIベンダーの腕の見せ 所。 ⇒システムアーキテクチャに基づき、調達品が決定される。 政府のガイドラインやIPAのTRM(技術リファレンスモデル)などで徐 々の非機能を盛り込み中。 同じ分野の機能が同等なソフトウェアやハードウェアでも、サポート がどこまで受けられるかによって、一部の非機能要件を満たせるか どうか、そのレベルを左右する可能性が出る。特に運用保守性の大 項目に影響がでる可能性もあるので慎重に判断すべき。 ex. OSSは基本的にサポートなし。商用製品もサポート期間は 一般には５年程度。 クラウドサービスのSLAは、非機能要求項目。ただ、ベンダの情報 公開が不十分。 Copyright © 2010-2015 IPA, All Rights Reserved Software Reliability Enhancement Center 78
© Copyright 2024 ExpyDoc
