Transcript 活用事例集 - IPA 独立行政法人 情報処理推進機構

Software
Engineering
Center
Information-technology Promotion Agency, Japan
『非機能要求グレード』活用事例集 第２版
2012年4月24日
独立行政法人 情報処理推進機構 (IPA)
技術本部 ソフトウェア・エンジニアリング・センター (SEC)
Copyright© 2011,2012 Information-technology Promotion Agency, Japan. All rights reserved.
Software Engineering Center
SEC
使用条件
Software Engineering
for Mo･No･Zu･Ku･Ri
1. 本資料の著作権は、独立行政法人情報処理推進機構(IPA)が保有しています。
2. 独立行政法人 情報処理推進機構は、「本資料の全部又は一部を複製、改変、公衆送信、又は翻
訳/翻案し、第三者に有償又は無償で再配布すること」を許諾します。なお、複製し再配布する場
合は、実際の契約書として使用する場合を除き、本使用条件を添付し、本使用条件に記載されて
いる条件を配布先に遵守させて下さい。改変又は翻訳/翻案し再配布する場合は、実際の契約書と
して使用する場合を除き、新しく使用条件を設定することが可能ですが、本使用条件を必ず含め
て下さい。
3. 独立行政法人 情報処理推進機構は、本資料が第三者の著作権、特許権、実用新案権等の知的財
産権に抵触しないことを一切保証するものではなく、また、本資料の内容に誤りがあった場合で
も一切責任を負いかねます。
4. 独立行政法人 情報処理推進機構は、本ページで記載された許諾内容を除き、独立行政法人 情
報処理推進機構又は第三者の著作権、特許権、実用新案権等の知的財産権に基づくいかなる権利
を許諾するものではありません。
5. 独立行政法人 情報処理推進機構は、本資料の商取引への利用、システム開発への利用、開発さ
れたシステムの使用、及び当該システムの使用不能等により生じるいかなる損害についても、な
んら責任を負うものではありません。
6. 本資料へのお問い合わせについては、独立行政法人 情報処理推進機構 ソフトウェア・エンジ
ニアリング・センターまでご連絡下さい。
7. 二次利用時に著作権を表示する場合は、次のように表記してください。
 2011年に公開した場合
Copyright © 2011 IPA, 二次著作権者名
 2012年に公開した場合
Copyright © 2011,2012 IPA, 二次著作権者名
 2013年以降に公開した場合
Copyright © 2011-公開年 IPA, 二次著作権者名
Copyright © 2011,2012 IPA, All Rights Reserved
Software Engineering Center
1
SEC
ご利用にあたって
Software Engineering
for Mo･No･Zu･Ku･Ri
当活用事例集は、「非機能要求グレード」の実際に活用して頂いて
いる企業・団体の皆様のお話やご意見を基に、活用局面に関する情報
を活用事例としてまとめたものです。活用局面をご紹介することで、
「非機能要求グレード」が単なる要件定義時の利用に留まらず、多様
な活用への可能性があることをご理解頂けると幸いです。
各事例内容は、次の項目を中心にまとめています。
 概要およびプロジェクトプロファイルとして業種、業務
 システム概要、利用工程、利用目的、利用方法など
 非機能要求グレードのレベル算出の工数
 利用効果と非機能要求に関する留意点
 活用者視点で気がついた非機能要求グレード利用の
注意点など
Copyright © 2011,2012 IPA, All Rights Reserved
Software Engineering Center
2
目










次
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
事例１．予算作成時の利用事例・・・・・・・・・・・・・・・P.6
事例２．稼働中システムの再評価・・・・・・・・・・・・・・P.8
事例３．非機能要求定義のリファレンス利用・・・・・・・・・P.11
事例４．非機能要求定義のチェックに利用 ・・・・・・・・・P.14
事例５．社内システム開発標準への適用 ・・・・・・・・・・P.16
事例６．組込システムのソフトウェアアーキテクチャ策定に利用
・・・・・・・・・・・・・・・・・・・P.20
事例７ 企業合併時の社内開発標準の統合事例・・・・・・・・P.23
事例８．要件定義書の平易性と利便性の向上・・・・・・・・・P.25
事例９．非機能要求グレード活用のコンサルティング
・・・・・・・・・・・・P.27
事例１０．運用を含めた概算見積もりの算定・・・・・・・・・P.30
Copyright © 2011,2012 IPA, All Rights Reserved
Software Engineering Center
3
目
次
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 事例１１．ユーザへのヒアリングツール（その１）
・・・・P.32
 事例１２．ユーザへのヒアリングツール（その２）
・・・・P.35
 事例１３．SIベンダにおける上流～下流一貫指標としての活用
・・・・・・・・・P.37
 事例１４．テスト工程での活用
・・・・・・・・・P.40
 事例１５．非機能要求のトレーサビリティ管理 ・・・・・・・P.42
 事例１６．システム障害の分析への活用
・・・・・・P.45
 事例１７．運用診断ビジネスのツール
・・・・・・・P.47
Copyright © 2011,2012 IPA, All Rights Reserved
Software Engineering Center
4
SEC
活用事例と適用工程との対応
予算
事
例
開発標
準策定
1
予算
作成
開発工程
概算
見積
SI
提案
要件
定義
設計
運用
テスト
障害
診断
システム
再評価
○
ユーザ
ベンダ
○
○
○
3
○
○
○
4
○
○
○
○
○
5
○
6
○
○
○
7
○
○
○
8
○
○
○
9
○
○
○
○
○
10
新
規
追
加
事
例
利用者
○
2
既
存
事
例
Software Engineering
for Mo･No･Zu･Ku･Ri
○
11
○
○
○
12
○
○
○
13
○
○
14
15
○
○
○
○
○
16
○
○
17
○
○
Copyright © 2011,2012 IPA, All Rights Reserved
○
○
Software Engineering Center
5
事例１．予算作成時の利用事例（1/2)
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 概要
製造業のA社はプロジェクト予算作成時に、非機能要求グレードのモデル
システムを使って予算を算定し、予算見積もりの精度を高めている。
 業種、業務
製造業、全ての業務
 システム概要
省略（個別システムではない）
 利用工程
予算作成時
 利用目的
 予算精度の向上
 ベンダが提示した価格の算出根拠の明確化
 利用方法
予算作成時にそれぞれのシステムが非機能要求グレードのどのモデルシス
テムに該当するかを算出し、それを基に複数のベンダにRFIを出して、
システム構成や予算額を把握している。
 非機能要求グレードのレベル算出の工数
１システムあたり2人日
Copyright © 2011,2012 IPA, All Rights Reserved
Software Engineering Center
6
SEC
事例１．予算作成時の利用事例（2/2)
Software Engineering
for Mo･No･Zu･Ku･Ri
 利用効果
 予算見積もりの精度が向上し、予算不足や予算余りのプロジェクトが削
減できた。
 RFIに対して複数のベンダから提出された提案に記載されている金額やシ
ステム構成に違いがあれば、その原因を分析して適正な予算を組むこと
が可能になった。
 非機能要求グレード利用時の注意
 非機能要求グレードでは、要求とその程度しか定めていないので、それ
を実現する実際のシステム基盤はベンダによって異なる。
 アプリケーションの非機能要求が対象でない。
 過剰や過少ではない、最適なシステム基盤を目標にした。
Copyright © 2011,2012 IPA, All Rights Reserved
Software Engineering Center
7
事例２．稼働中のシステムの再評価(1/3)
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 概要
稼動中のシステムに活用することで、暗黙的知に扱っていた非機能要求項
目の明確化、レベルの高低などを確認した。
 業種、業務
金融業
 利用工程、利用シーン
 利用工程：運用工程
 利用シーン：稼働中システムの再評価（リスクの把握とコスト削減）
 利用目的
社内のユーザ部門とのコミュニケーションによって非機能要求に関する暗
黙知や非機能要求のレベル感を中心とした評価を行うことで、稼働中のシ
ステムのリスク把握と非機能要求を実現するためのシステム基盤に対する
保守・運用費用の削減を図る。
Copyright © 2011,2012 IPA, All Rights Reserved
Software Engineering Center
8
事例２．稼働中のシステムの再評価(2/3)
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 利用方法
 稼働中のシステムについて、設計工程で作成した非機能要求に関する
ドキュメントを収集し、定義されている項目の網羅性や設定されている
レベルの根拠について確認した。
 非機能要求グレードの重要項目は、比較的分かりやすい言葉で定義されて
いるため、この分野に精通していないユーザ部門の担当者と情報システム
部門との認識合わせに利用した。
 利用効果
 実装時の要求レベルの課題を見つけた。今後のリスク回避のための投資
やコストダウンの検討の材料とすることができた。
 システム基盤の設計や運用ノウハウを暗黙知から形式知へ一部転換でき
た。ノウハウの形式知化が進めば、非機能要求は超上流で決めることが
できる。
 非機能要求グレード利用時の注意
 グレード表のレベルの考え方が、多元的であるので留意する必要がある。
 クラウドのようなアプリ先行で早期開発可能な状況下では、システム基盤
（インフラ）での漏れ防止が重要である。
Copyright © 2011,2012 IPA, All Rights Reserved
Software Engineering Center
9
SEC
事例２．稼働中のシステムの再評価(3/3)
Software Engineering
for Mo･No･Zu･Ku･Ri
非機能要求グレードの概要
 非機能要求グレードとは、情報システム
2009年5月公開の非機能要求グレード成果物
のシステム基盤の可用性や拡張性 などの
非機能要求を明確化し、システム構築に
おける開発ベンダとユーザ企業間の合意
形成を支援する手法である
樹系図
利用ガイド
グレード表
項目一覧
 開発ベンダ企業6社からなる非機能要求グ
レード検討会で策定し、その後IPA/SECに 非機能要求グレードの ユーザ視点で非機能 ユーザ/ベンダが合意す 項目一覧の閲覧
構成と利用法の解説書 要求を抽出するため べき非機能要求項目を 性を補完する図
移管。
の項目
網羅的にまとめたもの
実証評価の概要
 ユーザ企業の実システムへの試行適用を通して、利用効果、利用可能性、課題 を評価
■評価作業A
RFP等に記載されている非機能要求からグレード表・項目一覧
を記述
実システム
のRFP等
グレード表
項目一覧
■評価作業C
評価作業A,B結果の比較分析
グレード表（評価作業A）
RFP等の情報より
値を記載した
グレード表
同じシステムであること
差分を分析
実システムの現状
グレード表
項目一覧
Copyright © 2011 IPA, All Rights Reserved
■評価作業B
実システムの現状に係わる資料・ヒアリングからの非機能要求抽出
※RFP：Request for Proposal
Copyright © 2011,2012 IPA, All Rights Reserved
本来RFP等で確認
すべき値が入った
グレード表
グレード表（評価作業B）
Software Engineering Center 10
事例３．非機能要求定義のリファレンス利用（1/3)
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 概要
沖電気工業様では、システム基盤の設計にあたり、「非機能要求グレード」
をリファレンスとして利用し、開発品質の向上を目指した。ユーザとの合意
形成だけでなく、「グレード表」を一部拡張・調整しながら、プロジェクト
メンバ間でシステムの非機能要求に関する知識を共有する場としても利用
した。
 システム概要
人事院の人事・給与関係業務情報システム
 利用工程、利用シーン
ハードウェア調達のための要件定義工程
 利用目的
要件整理、設計の検証
 利用方法（続く）
要件定義書へのインプットとして利用し、議論の入り口として活用した。
ユーザと情報共有するために、「活用シート」の空欄にした箇所を埋めて
いく方法で、情報共有した。体系的に広く利用した。
Copyright © 2011,2012 IPA, All Rights Reserved
Software Engineering Center 11
事例３．非機能要求定義のリファレンス利用（2/3)
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 利用方法（続き）
 非機能要件定義の項目から基盤設計に反映すべき項目と運用設計に反映
すべき項目をそれぞれ分類して記載し、関係者と合意を図った。
 要件定義で決められない項目は、未定義事項として設計時に定義すること
も実施した。決まっていないことが明らかになることが重要である。
 利用効果
 知識体系としてみると、広く網羅的に漏れなく非機能項目を含むという
ことがメリットとなっている。
 ユーザより、「グレード表」を使用し最初から示してもらえるので助かる
と言われた。網羅性は安心感をもたらす。
 本システムの次期開発でも一度整理した同じ形式で合意が出来た為、効率
が良かった。
 全体のギャップを埋めることに使用したので、内容が覆えることが減った。
 公的な機関から提供されたこのような基準はユーザに説明し易い。
 トータルなコスト削減効果については把握できていない。
Copyright © 2011,2012 IPA, All Rights Reserved
Software Engineering Center 12
事例３．非機能要求定義のリファレンス利用（3/3)
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 非機能要求グレード利用時の注意
 セキュリティは官庁の統一基準※があるので、それをメインに実施
する必要があった。今後非機能要求グレードからその基準が導出できる
ことを期待。
※「政府機関の情報セキュリティ対策のための統一基準」
http://www.nisc.go.jp/active/general/kijun01.html
 システム基盤（インフラ）担当者とアプリ開発担当者が性能に関して
一緒に検討する必要がある（責任分担が難しかった）。
 性能や可用性などの導入時の基盤設計については、官庁の調達仕様で
定められているので、「非機能要求」は運用設計を主眼とした。
 初期は4、5回ほど打合せをする必要があり、その後も適宜打合せを実施
した。
Copyright © 2011,2012 IPA, All Rights Reserved
Software Engineering Center 13
事例４．非機能要求定義のチェックに利用（1/2)
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 概要
試験支援システムの開発にあたって、ユーザからの要望があり、非機能要
求グレード表にて最終的な非機能要件の調整を行った。
 システム概要
試験問題作成および試験実施システム
 利用工程、利用シーン
要件定義の最終工程
 利用目的
要件の抜け洩れの確認に活用
 利用方法
 非機能要件定義の結果に対して、重要項目を対象とした抜け洩れという
観点での確認に活用した。
 自社の項目をまずマップし、抜けている項目は、基本的に「社会的影響
が限定されているシステム」としてレベル設定を行った。
 非機能要求グレードのレベル算出の工数
ユーザとの検討を5日程度実施した。社内検討にも同程度の時間を掛けた。
Copyright © 2011,2012 IPA, All Rights Reserved
Software Engineering Center 14
事例４．非機能要求定義のチェックに利用（2/2)
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 利用効果
 漏れを極力防止できるという意味で安心して使用できる。ユーザと網羅性
について詰める際に、うまく活用できた。
 重要項目とそれ以外をわけているところが便利であった。
 公的機関が提供していることで、非機能要求の物差しとして非常に役立つ。
 非機能要求グレード利用時の注意
 非機能要件定義を後追いで実施したので、コスト面でのトレードオフが
でてしまうことがあった。
 性能はインフラとアプリで決まるため、インフラだけの設定は困難なところ
があった。
 ユーザは性能面を最も重視しており、その次が稼働率であった。
Copyright © 2011,2012 IPA, All Rights Reserved
Software Engineering Center 15
事例５．システム開発標準への適用(1/4)
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 概要
NTTデータ殿では、同社のシステム開発標準であるTERASOLUNA®の適用
判断・合意形成プロセス、実現プロセス、実現確認プロセスの各プロセス
に非機能要求グレードを活用している。また、社内で提供している各種の
ツールと連携させることで、ツールと開発標準の連携を実現している。
 業種、業務
SIer、コンサル業務
 利用工程、利用シーン
開発標準に適用し、開発標準内の超上流（コンサルティング）と上流（要件
定義プロセス）に適用
 利用目的
システム基盤の品質の確保
お客様とのコミュニケーションの円滑化
見積の精度向上
設計書など、お客様に納品するドキュメントの作成負担の軽減
※TERASOLUNAは、ネーミング、ロゴタイプ、ロゴマーク合わせて
(株)NTTデータの登録商標です。




Copyright © 2011,2012 IPA, All Rights Reserved
Software Engineering Center 16
事例５．システム開発標準への適用(2/4)
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 利用方法
 各工程でグレード表の次の箇所を活用した。
 企画段階：非機能要求グレード表に記載されている約100個の項目と





各項目に対応するメトリクス
 要件定義(システム要件の整理)：非機能要求グレード表に記載されて
いる約100個の項目と各項目に対応するメトリクス（企画段階で策定
した内容の確認・精査）
 要件定義(システムアーキテクチャ設計)：項目一覧に記載されている
個々の小項目に対応する総計236個のメトリクスとレベル
 レビュー観点/テストケース抽出：大項目、中項目に合わせ観点の分
類
社内共通用語として利用
非機能要求グレードの項目と、開発手順で定義している成果物の目次と
の対応を整理している。
現行システムのレベルと新システムのレベルを併記できるようにカスタ
マイズして、議論をしやすくした。
要件の確定状況を明記できるようにした。
要件定義の中で、二段階構成にして非機能要求を掘り下げた。要件定義
の冒頭で要件整理レベル感、その後システムアーキテクチャ検討の項目
一覧で、非機能要求の掘り下げと対応方針を策定する。
Copyright © 2011,2012 IPA, All Rights Reserved
Software Engineering Center 17
SEC
事例５．システム開発標準への適用(3/4)
Software Engineering
for Mo･No･Zu･Ku･Ri
 利用効果
 従来は納品成果物とはならない中間成果物の作成の負担が大きかった。
非機能要求グレードを導入することで、簡易に資料をまとめることが
できるようになった。
 非機能要求をまとめた後の設計で、設計項目と非機能要求との対応付け
が可能になり、設計時の要求の考慮漏れを防止する仕組みを作ることが
できた。
 従来は、ネットワークやDBなど分野によって記述範囲や粒度が異なる難
点があったが、非機能要求グレードの項目を基準とすることで開発手順
の記述範囲や粒度を揃えることができたうえ、見直しの根拠も明確にす
ることができた。
 非機能要求グレード利用時の注意
移行データ量、移行データ方式なども意識する必要がある。
 非機能要求グレードに対する要望
外字・文字コードの非機能要求が欲しい。
現時点では各社でのカスタマイズなどをIPAにフィードバックする仕
組みがあると良い。
非機能要求項目一覧の検討結果を踏まえて、概算見積もりを算出する
ガイドラインがほしい。
Copyright © 2011,2012 IPA, All Rights Reserved
Software Engineering Center 18
SEC
事例５．システム開発標準への適用(4/4)
Software Engineering
for Mo･No･Zu･Ku･Ri
旧版の
TERASOLUNAⓇ
新版の
TERASOLUNAⓇ
非機能要求
グレード
基本構想立案、システム
要件定義の成果物様式に
取り込み、タスクも見直
した。
Copyright © 2011,2012 IPA, All Rights Reserved
Software Engineering Center 19
事例６．組込システムのソフトウェアアーキテクチャ策定に
利用（1/3)
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 概要
オムロン株式会社殿では、鉄道事業者向けシステムの券売機などの端末機
器のソフトウェアアーキテクチャ策定に非機能要求グレードを活用した。
券売機などの組込みソフトウェアにも非機能要求の適用が可能であり、か
つ効果をもたらすことを示した。
 業種、業務
製造業（組込みシステム開発業務）
 システム概要
鉄道事業者向けシステム（券売機などの端末機器）
 利用工程、利用シーン
システム要件定義、アーキテクチャ設計
 利用目的
ユーザとコミュニケーションをとりながら非機能要求の重要性を確認しつ
つ設定し、かつソフトウェアアーキテクチャを策定する。
Copyright © 2011,2012 IPA, All Rights Reserved
Software Engineering Center 20
事例６．組込システムのソフトウェアアーキテクチャ策定に
利用（2/3)
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 利用方法
非機能要求グレード活用シートを基に、券売機などの端末機器にそれぞれの
モデルシステムのレベル感を適用する。非機能要求グレードの各項目に対し
て券売機のシステム特性を適用し、組込みシステムに合致しない部分は調整
した。
非機能要求グレード表を基に組込みシステム特有の項目を追加して、当該
システムに対する非機能要求を設定した。具体的には、システム環境・エコ
ロジーの大項目に、券売機などの端末機器特有の項目を追加した。
項目一覧表に明示されている他の規格との関係性を活用し、ソフトウェア
アーキテクチャの策定を実施した。
非機能要求グレードで使っている一般的な用語を、社内の組織名や製品名
といった固有名詞に置き換えることで、社内設計者の視認性を良くした。
Copyright © 2011,2012 IPA, All Rights Reserved
Software Engineering Center 21
事例６．組込システムのソフトウェアアーキテクチャ策定に
利用（3/3)
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 利用効果
技術者は、非機能要求について認識していても、表現力に乏しいことが多く
一覧表に掲載されている説明が役に立った。
非機能要求に関する社内認識の共通化に大きな効果があった。
運用・保守性で取り上げられている項目を券売機などの端末機器のソフト
ウェアに適用したことで、保守に関する要件を数値で定義でき、
運用フェーズにおいて配置すべきサポート要員数を考える指針になった。
券売機などの端末機器だけでなく、駅務システムも非機能要求グレードを
使って検討したのは、組込みシステム開発者にとって、組込み系でないPCの
非機能要求の勉強となった。
 非機能要求グレード利用時の注意
他のセキュリティ基準との整合性が十分とは言えない。
非機能要求に関しての共通認識を、社内のマネジメント層やユーザの鉄道
事業者から、更に鉄道事業者間、システムベンダ間で持つことが重要と考
えらる。
Copyright © 2011,2012 IPA, All Rights Reserved
Software Engineering Center 22
事例７．企業合併時の社内開発標準の統合事例(1/2)
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 概要
企業合併時には、システム開発標準として共通の物差しを必要とする。各社
古いものを引きずっている状況下で、非機能要求グレードに注目し、基盤系
のサービスレベルを揃えた標準策定に活用した。
 業種、業務
金融業
 利用工程、利用シーン
開発標準の策定
 利用目的
開発標準化。企業合併時に各社各様であったシステムの可視性を向上するた
めの共通の物差しとして活用。
Copyright © 2011,2012 IPA, All Rights Reserved
Software Engineering Center 23
事例７．企業合併時の社内開発標準の統合事例(2/2)
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 利用方法
標準策定に向けてグレード表をもとに、非機能要求項目の解説作成向けに
カスタマイズした上で、必須項目を選別した。
 検討主体者欄を設け、システムや営業、基盤のサービスレベルの違いを
確認した。
 モデルシステムシートの大項目を、レベル感や認識の違いを探るために
使った。内部調整を行い、ベンダ見積を取得した。金額を下げると
サービスレベルが変化することがわかった。
 利用効果
ストレスがなく、無駄がない。ただし人を見ながら使うことは必要。
 自分がわかる（関わる）ところをピンポイントで見るときに、整理されて
いるので便利である。
Copyright © 2011,2012 IPA, All Rights Reserved
Software Engineering Center 24
事例８．要件定義書の平易性と利便性の向上（1/2)
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 概要
東京証券取引所殿では非機能要件を文章で記載しており、必ずしもわかりや
すいとは言えなかった。表形式で非機能を表現できる非機能要求グレードを
活用することで非機能要件をわかりやすくし、非機能要件の品質向上とベン
ダとのコミュニケーションを一層円滑にする。
IPAの非機能要求グレードをそのまま流用するのではなく、粒度が不足して
いる部分には独自に拡充することでさらに有用性を強化する。
 業種、業務
金融業
 利用工程、利用シーン
①RFPの作成 ②RFPに基づいて要件定義書の作成
 利用目的
①非機能要件の品質向上
②非機能要件の作成に要する工数の削減
③ベンダとのコミュニケーションの向上
Copyright © 2011,2012 IPA, All Rights Reserved
Software Engineering Center 25
SEC
事例８．要件定義書の平易性と利便性の向上（2/2)
Software Engineering
for Mo･No･Zu･Ku･Ri
 利用方法
 非機能要求グレードでは粒度が十分ではない項目については、活用シー
トをアレンジして、必要な内容を追記している。
 １つの非機能が複数のサブシステムで構成されることもあり、その場合
には、非機能要求グレード表を社内の事情に合うように変更する。
運用については、オンラインの運用期間とバッチ方式の運用期間のよう
に社内の事情に合うようにメトリクスを追加する。
 利用効果
今後、満足感や安心感などの視点も含めて効果を確認していく。
システム切り替え時のチェックリストとしての活用や予算作成時の
チェックリストとしての活用など、当初は想定していなかった用途が
あることがわかった。
 非機能要求グレード利用時の注意
重複項目があることを事前に承知しておく必要がある。
 項目数が多いので、すべての項目をチェックするには相当の工数と
時間を要する。
Copyright © 2011,2012 IPA, All Rights Reserved
Software Engineering Center 26
事例９．非機能要求グレード活用のコンサルティング（1/3)
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 概要および利用の背景
 ユーザ企業における要件定義書の社内標準や文書雛形は、多くの場合、
文章主体で記載されており、記載内容や記載レベルがまちまちである。
このため、要件の漏れや誤り、ベンダとの要件伝達時の齟齬が発生しが
ちである。
 「非機能要求グレード」をユーザ企業が効率的に導入・活用するために
は、要件分類や用語を理解しやすくする、導入企業のシステム特性に応
じた標準的なグレード設定を行う、等のカスタマイズが必要となる。
 ＮＴＴデータ経営研究所殿では、上記の課題に対し、要件定義項目の細
分化や図表表現を取り入れた要件定義標準（標準雛型/マニュアル）の
策定支援サービスを提供している。同社では、非機能要件部分の標準作
成のベースとして「非機能要求グレード」を活用している。
 業種、業務
コンサルティング
 利用工程、利用シーン
ユーザ企業が、非機能要求グレードをベースとして社内標準となる要件定義
書のフォーマットやルールを策定する際のカスタマイズ業務支援
Copyright © 2011,2012 IPA, All Rights Reserved
Software Engineering Center 27
事例９．非機能要求グレード活用のコンサルティング（2/3)
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 利用目的
 ユーザ企業が行う非機能要件定義の品質向上／効率化
 ユーザ企業が実施する受入・検収テストのテスト項目の標準化
 利用方法
 ユーザ企業への要件定義（非機能要件部分）標準化支援におけるコンサ
ルティングツールの1つとして活用
 非機能要件部分の要件定義書の標準様式を作成する際のベースとし
て活用
 または、非機能要件定義書の網羅性を検証するために活用
 利用効果
 「非機能要求グレード」は非機能要件定義項目が網羅的に整理されてい
るため、コンサルティングツールとしては有用
 ユーザ企業が非機能要求グレードを導入・活用した際の効果については
今後検証を実施する予定
Copyright © 2011,2012 IPA, All Rights Reserved
Software Engineering Center 28
事例９．非機能要求グレード活用のコンサルティング（3/3)
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 非機能要求グレード利用時の注意
「参照すべきドキュメント種類、分量が多い点」と「（これまでと異なる）
図表形式の要件定義書の作成となる点」等から、ユーザ企業が独力で非機能
要求グレードを有効活用する事は困難であると想定される。
そのため、非機能要求グレードに関する知見や要件定義標準化に関する経験が
豊富な社外コンサルティング会社の支援を仰いだ方が品質面、作業負担両面に
おいて望ましい
Copyright © 2011,2012 IPA, All Rights Reserved
Software Engineering Center 29
事例１０．運用を含めた概算見積もりの算定（1/2)
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 概要
非機能要求グレードを活用して運用時に発生する恐れがある障害を十分に
分析することで、ユーザも納得できるような運用も含めた概算見積を
作成する。これによって、運用時の障害発生により、ユーザとベンダの
双方が予定外の費用が発生することを回避する。
 業種、業務
すべての業種
 利用工程、利用シーン
概算見積もり作成
 利用目的
ユーザが納得できる運用までを含む見積の算定
Copyright © 2011,2012 IPA, All Rights Reserved
Software Engineering Center 30
事例１０．運用を含めた概算見積もりの算定（2/2)
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 利用方法
 アプリ開発のメンバーの他にインフラ担当のメンバーも参画させ、非機能
要求グレードに基づいて運用時に発生する恐れがある障害を見積時に明確
にする。
 上記の分析に基づいて障害の発生を未然に防止するための防止策を設計時
の見積に盛り込む。
 利用効果
 発注者：運用時の障害発生が減少して、障害による業務の中断が減少
運用時に発生した障害の原因解析と対策に要する費用の削減
 受注者：障害発生時の原因解析や対策に投入する工数を他の業務に
割り当てることができる。
 非機能要求グレード利用時の注意
IT業界に携わっていない発注者に非機能要求グレードで記載されている言葉
で説明しても発注者は理解できない。発注者が理解できる言葉で置き換えて
説明する必要がある。
Copyright © 2011,2012 IPA, All Rights Reserved
Software Engineering Center 31
事例１１．ユーザへのヒアリングツール（その１）（1/3)
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 概要
システム基盤に対するインフラ要件の検討は、ユーザ、インフラ担当、アプ
リ担当の３つの部門が共同ですすめる。非機能要件の検討においてユーザに
はヒアリング形式で非機能の確認と合意をとりつける。
ヒアリング用に非機能要求グレードの活用シートをカスタマイズして使う。
 業種、業務
インフラサービス
 利用工程、利用シーン
利用工程：インフラシステムの設計
利用シーン：インフラ要件についてユーザにヒアリング
 利用目的
担当者のスキルに依存せずに非機能要件の検討漏れを防止して、ユーザへの
説明と確認をとるためのツールとして活用する。
Copyright © 2011,2012 IPA, All Rights Reserved
Software Engineering Center 32
事例１１．ユーザへのヒアリングツール（その１）（2/3)
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 利用方法
 活用シートをカスタマイズすることで、ユーザを含む3者へのヒアリング
に使いやすくする。
 活用シートの大項目と中項目をそのまま利用する。項目の右側に
項目の定義内容とユーザに対するヒアリング項目の欄を追加した。
 非機能要求グレードの各項目のレベルなどの詳細設定に必要な情報
をシステム基本情報として大項目の先頭に追加した。
 ヒアリングは上から下に順番に聞くようにする。上の質問の回答を
反映して、次の質問になるようにする。このようにすることで、
遡って質問が出ないようにした。
 各項目に対するヒアリング先は、インフラ担当、アプリ担当、ユー
ザの3者の中のいずれか１つにすることで、異なる意見が出ないよう
にした。
 ヒアリングで選択肢を用意する場合には、以下のようにユーザの事
情を考慮して選択肢を用意した。
ユーザ（各利用部門のシステム担当者）は、必ずしもシステムに詳
しいとは限らない。そのような担当者にも、回答しやすくするため
に「選択肢」を準備し、専門用語を使わない選択回答案を準備する
よう心がけた。
Copyright © 2011,2012 IPA, All Rights Reserved
Software Engineering Center 33
事例１１．ユーザへのヒアリングツール（その１）（3/3)
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 利用方法（つづき）
 システムごとに作成していたインフラ要件定義書のとりまとめを実施
して、インフラ要件定義書の標準を整備した。インフラ要件定義書の
整備に際しては、無駄な要件を記載しないことと、インフラ要件定義書
を基に作成するインフラ設計書、運用設計書など各種の設計書の作成が
容易に行えるような設計インプット情報を記載するように心がけた。
 利用効果
 非機能をしっかりと決めることでコストが高くなっても、その根拠を
きちんと説明できる。
 従来は各個人で要件定義を作成していたが、作業の標準化による若手
育成のツールになりうる
 ハードウェアリソースや、運用サービスレベルなどのオーバースペック
を防ぐことも期待できる。
 非機能要求グレード利用時の注意
 項目数が多いので、ユーザとの合意形成までにかなりの工数と時間を
要する場合がある。
 IT専門用語などを、なるべくわかりやすくユーザに伝えるようにする
べきである
Copyright © 2011,2012 IPA, All Rights Reserved
Software Engineering Center 34
事例１２．ユーザへのヒアリングツール（その２）（1/2)
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 概要および利用の背景
新規かつ大規模な案件に対し、非機能要求グレードを適用している。
このようなシステムでは、非機能の各項目に設定するレベルがベンダと
ユーザとの間で一致しないケースやそもそもユーザがレベルを設定しない
ケースもある。
そこで、非機能要求グレードの活用シートを変更して、ヒアリングで得た
ユーザの要求を記録できるようにした。これによって、ユーザとベンダの
設定値との違いとレベルの設定経緯が一目でわかるようにした。
 業種、業務
大規模案件、特定案件
 利用工程、利用シーン
提案などに必要な入手情報の漏れ、提案内容の漏れ防止に活用
 利用目的
 項目のレベルが設定された経緯の明確化
 ヒアリングで得られたユーザの要求の見える化
Copyright © 2011,2012 IPA, All Rights Reserved
Software Engineering Center 35
事例１２．ユーザへのヒアリングツール（その２）（2/2)
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 利用方法
 ユーザの要求とベンダの設定値との対応を表形式で表現することで 、
一目で違いがわかるように変更した活用シートを使っている。ユーザがレ
ベルを設定していない非機能要求項目に対しては、ベンダ側の判断で適切
な要求レベルを設定している。
 非機能項目を２つに分け、それぞれに対して下記の処理をすることで
ユーザへのヒアリングの議事録とレベル設定の経緯がわかるようにする。
 ユーザが数値を設定した項目
ヒアリングで得られたユーザの数値をカスタマイズした活用シートに
記載する。
 ユーザが数値を設定しない項目
ユーザがレベルを指定しなかったことを記録し、その隣の欄にベンダ
が設定した数値を記録する。
 利用効果
定量的な効果は、今後、検証していく。
 非機能要求グレード利用時の注意
設定したレベルが後になってユーザと揉めることがないように、非機能要求
グレードの項目にシステムなどに特化した項目追加が必要である。
Copyright © 2011,2012 IPA, All Rights Reserved
Software Engineering Center 36
事例１３． SIベンダにおける上流～下流一貫指標
としての活用 （1/3)
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 概要
富士通殿では、システム開発の標準プロセス体系「SDEM」の各工程で非機能
要求グレードの全項目を取り入れ、社会的影響が極めて大きいシステムにお
ける要件トレーサビリティを確保するとともに、社会的影響が限定されるシ
ステム以下については主要非機能要求項目に基づくシステム基盤実装ソリュ
ーションのパターン化を図っている。
 業種、業務
SIer、コンサルティング
 利用工程、利用シーン
 社会的影響が極めて大きいシステム
業務要求に基づく非機能要求の網羅性確保
 非機能要求の設計～構築～テストでのトレーサビリティ確保
 社会的影響が限定されるシステム、社会的影響が殆ど無いシステム
 主要な非機能要求に基づくアーキテクチャのパターン化
 既存システム基盤（パブリッククラウド等）活用時の評価

 利用目的
様々なシステムで求められる非機能要求の共通尺度として活用している。
Copyright © 2011,2012 IPA, All Rights Reserved
Software Engineering Center 37
事例１３． SIベンダにおける上流～下流一貫指標
としての活用 （2/3)
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 利用方法
 社会的影響が極めて大きいシステム
非機能要求はシステム基盤だけで実現できるものではないため、
業務要件の延長に非機能要求を位置付け、非機能要求グレードの項
目を網羅した段階的合意形成プロセスを要件定義手法「Tri-Shaping
」の中で標準化している。
 詳細化された項目は、設計項目～テスト項目との関係マトリックス
によりトレーサビリティを確保している。
 社会的影響が限定されるシステム、社会的影響が殆ど無いシステム
 非機能要求グレードでは、実装アーキテクチャはSIerの創意工夫に
委ねられており、技術の進歩にも依存する。「TRIOLEシステム構成
モデル」では、可用性の複合要件3段階(松/竹/梅)と、性能・拡張性
4段階(特大/大/中/小)を選択することで、非機能要求グレードの
「可用性」「性能・拡張性」「運用・保守性」小項目の標準レベル
が決まると共に実装アーキテクチャの標準パターンを導出できる。
 可用性と性能・拡張性の主要項目から、独自に12種類のモデルシス
テムを開発し、各々の実装アーキテクチャと運用性を「TRIOLEシス
テム構成モデル」としてパターン化している。

Copyright © 2011,2012 IPA, All Rights Reserved
Software Engineering Center 38
事例１３． SIベンダにおける上流～下流一貫指標
としての活用 （3/3)
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 利用効果
 社会的影響が極めて大きいシステム
従来は「システム化企画」「要件定義」「設計仕様」「構築仕様」
「テスト仕様」におけるトレーサビリティの実現が難しかった。非
機能要求グレードを標準指標とすることで、システム基盤領域につ
いては一貫したトレーサビリティを確保でき、ドキュメント品質と
システム品質の第三者検証も可能になった。
 社会的影響が限定されるシステム、社会的影響が殆ど無いシステム
 従来は3段階のモデルシステムからのテーラリング、あるいは重要項
目からの段階的詳細化が必要であり、非機能要求グレードの活用は
負荷が高かった。「可用性3段階」×「性能・拡張性4段階」からの
選択方式とし、実装アーキテクチャと対応付けたことで、お客様が
値頃感と運用体制をイメージできる様になった。

 非機能要求グレード利用時の注意
 外部接続、操作性、移植性等のアプリケーション依存性の高い項目は、
別に考慮する必要がある。レベル0/1しかない項目は要求内容の具体化
が必要である。
 業務担当者、アプリケーション開発担当者、運用担当者も意識すべきで
ある。
Copyright © 2011,2012 IPA, All Rights Reserved
Software Engineering Center 39
事例１４．テスト工程での活用 （1/2)
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 概要、導入の背景
過去事例で、提案、計画段階で要求を明確化し、それに基づいてソフトウエ
ア開発を進めていたにもかかわらず、テスト工程で性能問題が発生すること
があった。そこで、この防止と改善を図ることを目的に、性能に関するユー
ザ要件を明らかにし、ユーザ要件がソフトウエア設計に織り込まれているこ
とをテスト段階で検証するために、非機能要求グレードを導入した。
 業種、業務
レスポンスタイムなど性能が問題になる業務
 利用工程、利用シーン
非機能要求グレードをベースにした評価項目の選定
 利用目的
合意されたユーザ要件がソフトウエア設計に反映されていることの検証
Copyright © 2011,2012 IPA, All Rights Reserved
Software Engineering Center 40
事例１４．テスト工程での活用 （2/2)
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 利用方法
テスト工程の中の設計検証への活用
過去の経験と知見を踏まえて、ユーザとのSLAに性能に関する項目を
追加
 レスポンスタイムがどの程度であればユーザは満足するかなどを
評価した。
性能評価のために２つのテンプレートを使用
 非機能要求グレード活用テンプレート
 性能確認項目設計テンプレート

 利用効果
設計したシステムの性能をテスト工程で確実に検証できるため、合意された
ユーザ要件が的確にソフトウエア設計に反映されていることの検証ができる。
Copyright © 2011,2012 IPA, All Rights Reserved
Software Engineering Center 41
事例１５．非機能要求のトレーサビリティ管理（1/3）
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 概要
2007年頃から非機能要求グレード相当を実システムに適用している。設計フ
ェーズからチェックリストを活用してチェックすることで、要件の漏れや方
式の検討漏れを防止している。プロジェクトごとに取り組みやトレーサビリ
ティの実施方法は異なるが、非機能要求グレードはすべてのプロジェクトに
適用することを目指している。
 業種、業務
官公庁
 利用工程、利用シーン
官公庁の大規模案件の上流工程、設計工程、テスト工程
 利用目的
 上流工程での設計漏れの検出とフィードバックによる品質確保
 テスト工程での確認漏れの防止による品質確保
 非機能の要件定義漏れの検出による品質確保
Copyright © 2011,2012 IPA, All Rights Reserved
Software Engineering Center 42
事例１５．非機能要求のトレーサビリティ管理（2/3）
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 利用方法
 システム設計の最上位である非機能要求から非機能要件、非機能要件の
実現方式と具体化のステップにおいて、各項目にタグをつけて１つ１つ
チェックしていく。
 たとえば、非機能要求が50個、非機能要件が100個、非機能要件の実現方式
が100個ある場合には、以下のステップで進める。
①それぞれの項目にタグをつける。
②50個の非機能要求を縦軸、100個の非機能要件を横軸にとって、50行
100列のチェック行列を作成する。
③行列の各要素についてチェックする。
④続いて、100個の非機能要件を縦軸、100個の非機能要件の実現方式を
横軸にとって、100行100列の行列を作成する。
⑤行列の各要素についてチェックする。
補足説明
【要求と要件の違いについて】
要求：～したいこと。（例：画面で氏名を入力したい。）
要件：～でなければならないこと。（例：画面には氏名入力フィールドが配置されていること。）
（機能／非機能共に同じ。要求を要件化することでシステムで実現すべき範囲を明確化する。）
Copyright © 2011,2012 IPA, All Rights Reserved
Software Engineering Center 43
事例１５．非機能要求のトレーサビリティ管理（3/3）
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 利用効果
上流工程での検討の抜けや漏れが検出できるようになった。
運用面での障害の発生件数が減少した。
初期費用が増大するが、長期運用中で発生する障害対策費を考慮すると、
受注者のコスト削減につながる。一方で、発注者にとっても、障害対策に
投入する工数の削減につながる。
 非機能要求グレード利用時の注意
長期運用で発生する障害対策で負担する費用を考えると、システム設計時に
多少の費用をかけてでも，運用面での非機能を十分に検討しておくべきで
ある。
非機能については、発注者も気付かない重要な要件が明確に表現されてない
ことがある。このため、発注者にも非機能要求グレードを活用してもらう
ことで、発注者と受注者との間でお互いに非機能要求をチェックできる
ようになると良い。
Copyright © 2011,2012 IPA, All Rights Reserved
Software Engineering Center 44
事例１６．システム障害の分析への活用（1/2)
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 概要
新規かつ大規模案件には、品質保証部がPMO（Project Management Officer）
と連携して、見積もり審査、方針審査など、すべてのステージでチェック
する。導入したシステムで障害が発生した場合には、非機能要求グレード
を使用してチェックする。
 業種、業務
新規かつ大規模な案件
 利用工程、利用シーン
導入したシステムで障害が発生した場合のチェック
 利用目的
 新規、大規模システムでの品質の一層の向上
 導入したシステムで障害が発生した場合の原因究明と対策の迅速化
Copyright © 2011,2012 IPA, All Rights Reserved
Software Engineering Center 45
SEC
事例１６．システム障害の分析への活用（2/2)
Software Engineering
for Mo･No･Zu･Ku･Ri
 利用方法
IPAの非機能要求グレードをA3用紙１枚程度にまとめる。
プロジェクトの規模と内容を見て、PMOと品質保証部がチェックする。
非機能要求グレードがシステム設計やテスト項目の設定にどのように
反映しているのかをチェックする。
 利用効果
直接の効果を知ることは難しい。
 非機能要求グレード利用時の注意
項目数が多いためすべての案件に非機能要求グレードを適用するのでは
なく、内部で設定した判定基準を満たした案件にのみ非機能要求グレー
ドを適用する。
Copyright © 2011,2012 IPA, All Rights Reserved
Software Engineering Center 46
事例１７．運用診断ビジネスのツール（1/2)
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 概要、利用の背景
ユーザは非機能を軽視しがちであり、非機能要求という言葉自体が浸透して
いない。IPAの非機能要求グレードをシステム運用要件に関するチェックツ
ールとして使用することで、ユーザとの揉め事を減らす。
 業種、業務
システムサービスのアウトソーシング
 利用工程、利用シーン
 利用工程：運用フェーズ
 利用シーン：ユーザが使用しているシステムの運用診断・運用見直し
 利用目的
提案活動の１つとして、ユーザが現在使用中のシステムの運用状況を実際に
視察し、診断および改善提案を実施する際のチェックツール
Copyright © 2011,2012 IPA, All Rights Reserved
Software Engineering Center 47
事例１７．運用診断ビジネスのツール（2/2)
SEC
Software Engineering
for Mo･No･Zu･Ku･Ri
 利用方法
 非機能要求グレードを指標として、ユーザが使用中のシステムの運用に
おける問題点および課題を明確化する。
 ユーザが使用中のシステムを非機能要求グレードで１つ１つチェック
することで、ユーザのニーズを的確に引き出す。
 利用効果
ベンダ独自のツールではなく、IPAという信頼性がある機関から公開されて
いる非機能要求グレードを指標とすることにより、ユーザへの説明が容易
になり、ユーザも理解しやすくなったことでユーザとの揉め事が減少し、
合意が得やすくなった。
 非機能要求グレード利用時の注意
ユーザが所属する業界によっては、業界独自の運用要件項目とレベルが設定
されている場合がある。その場合には、業界で設定されている項目とレベ
ルに従う。
Copyright © 2011,2012 IPA, All Rights Reserved
Software Engineering Center 48