「非機能要求グレード」に対するパブリックコメント実施結果

2010年2月吉日
「非機能要求グレード」に対するパブリックコメント実施結果について
システム基盤の発注者要求を見える化する
非機能要求グレード検討会
非機能要求グレード検討会では、「非機能要求グレード」を実際の多種多様なプロジェクトで利用
できるようにするために、検討会のWebサイトにて「非機能要求グレード」に関するパブリックコメントを
2009年5月26日から2009年6月30日まで募集しました。
この報告書は、いただきましたご意見を「非機能要求グレード」にどのように反映するのか、改善内
容を報告するものです。なお勝手ではございますが、「非機能要求グレード」の各構成品の細部に
関するご指摘・ご意見は、各構成品への反映と完成をもって報告にかえさせていただきます。また、
誤字・脱字などのご指摘・ご意見も、同様に「非機能要求グレード」への反映結果をもって報告にか
えさせていただきますので、よろしくお願いします。
パブリックコメントにご協力をいただき厚くお礼を申し上げます。
【実施期間、ご意見の総数等】
内　容
項　目
１）実施目的
「非機能要求グレード」を実際の多種多様なプロジェクトで利用できるよう
にするために、「非機能要求グレード」に関するパブリックコメントを募集。
2009年5月26日から2009年6月30日まで
非機能要求グレード検討会ホームページに掲載
「非機能要求グレード（2009年5月版）」
・「非機能要求グレード」利用ガイド(以下、利用ガイド)
４）ご意見の対象
・システム基盤の非機能要求に関するグレード表(以下、グレード表)
・システム基盤の非機能要求に関する項目一覧(以下、項目一覧)
・システム基盤の非機能要求に関する樹系図(以下、樹系図)
・回答者数
30 回答者
５）回答者数/コメント数
・コメント数
391 件（類似意見、ご賛同意見を含む）
・利用ガイドに対するご意見
155 件
・グレード表に関するご意見
72 件
６）コメントの内訳
・項目一覧に対するご意見
123 件
・樹系図に対するご意見
41 件
２）実施期間
３）実施方法
【ご賛同意見】
次のようなご賛同意見をいただきました。
ご賛同意見（抜粋）
全体的には以前のもの（2008年9月版）と比べてたいへん分かりやすくなった。大幅に改善された
と思います
商談の途中で、必ず非機能要件に関する問い合わせがあります。これまであまり系統だてて検
討できる手段をもっていなかったので、今後はこのツールを活用して、あいまいさを残さないよう
にしたいと思いました。
全体としてよくまとまっていると思います。
主要成果物(グレード表・項目一覧)が表形式であるので，用語集の存在はありがたい。
この試み自体は、ある程度、コーチング的発想であり、ついでに自分らもおいしいという意味で、
Win-Winモデルを追及しようとしている意味で支持できる。
断片的な知識としては知っていることも多かったが、このように体系化されているものを通して読
むことで、整理された知識になると感じた。
Copyright ©2010 システム基盤の発注者要求を見える化する非機能要求グレード検討会
1
「非機能要求グレード」に対するパブリックコメント実施結果ご報告
【目　次】
１．アンケート集計結果のご報告
２．ご意見と「非機能要求グレード」への反映について
２．１主な改善点について
２．２ご意見と「非機能要求グレード」への反映方針・考え方
付録．パブリックコメントリスト
Copyright ©2010 システム基盤の発注者要求を見える化する非機能要求グレード検討会
2
１．アンケート集計結果のご報告
「非機能要求グレード」は、利用ガイドと、グレード表、項目一覧、樹系図の三つのツールで構成されます。
パブリックコメントは、「非機能要求グレード」に対するアンケート及び個別コメントの二つの様式で実施しまし
た。本章は、アンケート様式にご回答いただいた内容を報告するものです。
アンケート様式は、ご回答者の立場を選択いただく内容、「非機能要求グレード」の解りやすさを評価いただ
く内容、そして、非機能要求グレードを自社で活用される場合の活用のレベルに関する内容で構成されてい
ます。アンケートはA～Eの五段階評価でおこない、アンケート集計結果は表1.1のとおりです。
表1.1　アンケート集計結果
No
分類
質問項目
合計
C D
A
B
1 ご回答の立場立場
6
20
4
2
利用ガイド
1
14
8
4
3
グレード表
1
16
7
3
「非機能要求
グレード」に対
4
項目一覧
する評価
17
6
4
5
樹系図
6
13
8
6
「非機能要求グレード」全体
14
11
2
7
システム開発への適用
6
11
6
3
社内標準化への活用
5
6
12
3
8
9
活用のレベル
活用される場合
11
19
備　考
E
Ａ　：　ユーザ　（発注者）の立場
Ｂ　：　ベンダ　（受注者）の立場
Ｃ　：　ユーザ・ベンダ以外
Ａ　：　大変解りやすかった
Ｂ　：　解りやすかった
Ｃ　：　どちらかといえば解りやすかった
Ｄ　：　解りにくかった
Ｅ　：　解らなかった
Ａ　：　強くそう思う
Ｂ　：　そう思う
Ｃ　：　どちらかといえばそう思う
Ｄ　：　そう思わない
Ｅ　：　まったくそう思わない
複数回答
Ａ　：　社会的影響が極めて大きいシステム
Ｂ　：　社会的影響が限定されるシステム
Ｃ　：　社会的影響が殆ど無いシステム
12
図1.1は、評価傾向を概観するために、表1.1　No2～8について、A=5点、B=4点、C=3点、D=2点、E=1点とし
て点数で積算した結果をグラフ化したものです。
表1.1の集計結果及び図1.1から、「非機能要求グレード」に対する評価では、「非機能要求グレード」の各
ツールについて、概ね解りやすいとの評価をいただきました。ただし、樹系図については、他の評価に比べて
低い状況でした。
また、活用に関する回答では、システム開発に適用する意向は高く、社内標準化に活用される意向も高い状
況と推測できます。
利用ガイド
100
80
社内標準化への活用
グレード表
60
40
20
0
システム開発への適用
非機能要求グレード全体
項目一覧
樹系図
図1.1　アンケート集計結果を点数で積算したグラフ
3
Copyright ©2010 システム基盤の発注者要求を見える化する非機能要求グレード検討会
２．　ご意見と「非機能要求グレード」への反映について
いただきましたご意見を「非機能要求グレード」にどのように反映するのか、改善内容を報告しま
す。2.1節において、多数のご意見を踏まえて「非機能要求グレード」に反映する主な改善点を報告
し、2.2節において、いただきましたご意見について「非機能要求グレード」への反映方針や考え方を
個別に報告します。
２．１主な改善点について
１）利用ガイド
■利用ガイドを［利用編］と［解説編］に分冊化し、再構成
「非機能要求グレード」を利用する場合に、従来の利用ガイドでは利用に関する記述になかなか
たどり着かないというご意見がありました。一方、検討経緯や「非機能要求グレード」の各ツール
の説明が不足しているというご意見がありました。このようなご意見を総合的に検討して、利用ガ
イドを［利用編］と［解説編］に分冊化し、再構成することにいたします。
利用ガイド［利用編］：「非機能要求グレード」を利用者の視点から、利用方法を記載します。
利用ガイド［解説編］：「非機能要求グレード」を策定した背景やツールの詳細を解説します。
分冊化することで、目的別に利用可能になります。
■いろいろな利用例を追加し、内容を改善
「非機能要求グレード」を様々に利用したいというご要望/期待が寄せられました。これ等のご意
見を踏まえて、利用ガイド［利用編］の基本的な利用例においては内容を充実させより具体的に
いたします。また、いろいろな利用例においては事例を追加するなど大幅に見直しをいたしま
す。見直しにあたっては、経済産業省の「非機能要求グレード評価委員会」において実施された
「非機能要求グレード」の有効性評価結果も反映し、より充実した内容に改善いたします。
■利用ガイド［解説編］では「非機能要求グレード」の仕様や策定の背景などを充実
「非機能要求グレード」の目的はシステム基盤の非機能要求を見える化することにありますが、そ
の目的趣旨の説明が不足しているというご意見がありました。このようなご意見を踏まえて、「非機
能要求グレード」の目的、狙い、システム基盤とはそもそも何か、非機能要求に関してどのような
問題が生じ、どのような解決を図っているのか等について、これまでの検討経緯・背景等を整理
し、利用ガイド［解説編］に解説をいたします。
２）グレード表
■モデルシステムシートをグレード表に新設
モデルシステムを具体的にイメージできるように工夫して欲しいというご要望が多く寄せられまし
た。そこで、今まで利用ガイドに記載していたモデルシステムを、グレード表にモデルシステム
シートとして新設いたします。さらに、モデルシステムシートでは非機能要求の特徴を１６に絞り、
各モデルシステムごとに比較できるようにして一覧性を向上させます。
■グレード表と項目一覧を一体化したスプレッドシートを提供
グレード表と項目一覧を一体化したシートにする提案が多く寄せられました。また、グレード表と
項目一覧をもっと自由に使えるように使用条件を見直して欲しいとのご意見もいただきました。こ
れらのご意見を踏まえて、グレード表と項目一覧を一体化したスプレッドシートを提供いたしま
す。このスプレッドシートによって、実際の活用場面ではグレード表から項目一覧にシームレスに
展開できますので、より効率的に非機能要求を確認していくことができます。また、自由にご利用
いただけるように使用条件を見直しいたします。
■重要項目の意味を解説
グレード表は項目一覧から重要項目を抽出して作成していますが、この重要項目の意味が不明
確というご意見が多く寄せられました。重要項目は、項目一覧の中から、コストや品質に影響を与
える度合が大きい項目を、ユーザ視点とベンダ視点の両面から評価し選定しています。ご意見を
踏まえて、重要項目を選定した経緯などを勘案して利用ガイドに説明を補足いたします。
また、グレード表の各項目の意味を示す凡例を新設します。
Copyright ©2010 システム基盤の発注者要求を見える化する非機能要求グレード検討会
4
３）項目一覧
■ご意見をもとにメトリクス（指標）を再精査し、汎用性を向上
メトリクスに関しては、さまざまな方から、項目の過不足や、レベルの違和感、記述の分かりやすさ
など、数多くのご意見をいただきました。これらのご意見を踏まえて、メトリクスを一つ一つ精査
し、場合によっては追加や削除を行います。より多くのプロジェクトでご利用いただけるツールを
目指し、汎用性を向上させます。
■重複項目を示す列を新設
大項目間で重複する項目があり、重複項目の存在と意味が解りにくいというご意見が寄せられま
した。ご意見を踏まえて、項目一覧に重複項目の列を新設し、重複項目かどうかを識別可能にし
ます。
また、「非機能要求グレード」では、大項目毎に検討対象者や検討順が異なることを想定し、それ
ぞれの大項目の観点で項目を選択しているため、重複をそのまま残すことにしています。これ
は、無理にどちらかの大項目に集約することで、検討漏れとなることを防ぐためです。この趣旨を
利用ガイド［解説編］に記載いたします。
また、項目一覧の各項目の意味を示す凡例を新設します。
■運用コストへの影響列を再精査し精度向上
運用コストへの影響は、開発コストをかけることで運用コストを下げられる可能性のあるメトリクスを
○で示し、運用コストへの影響欄に○がついているメトリクスは、要求のレベル値と運用コストがト
レードオフの関係である可能性があることを示しています。しかし、運用コストへの影響の定義が
明確ではないというご意見がありました。ご意見を踏まえて、利用ガイド［解説編］において運用コ
ストへの影響の解説を見直すと共に、項目一覧の運用コストへの影響を精査いたします。
４）樹系図
■様式を精査し、閲覧性をさらに向上
樹系図について、印刷したときに文字が小さく見づらいというご意見が多く寄せられました。ご意
見を踏まえて次の改善を行います。
・様式をＡ３横に統一します。
・記述枠を変更して、印刷時の大きさを確保します。
■樹系図からグレード表、項目一覧の逆引きが可能
樹系図からグレード表、項目一覧に導けるように関係づけるというご意見が多く寄せられまし
た。ご意見を踏まえて次の改善を行います。
・樹系図のメトリクスに項番を付します。
・樹系図では重要項目を網掛け表示にして、グレード表との関係を示します。
・樹系図に凡例を新設します。
Copyright ©2010 システム基盤の発注者要求を見える化する非機能要求グレード検討会
5
２．２ご意見と「非機能要求グレード」への反映方針・考え方
たくさんのご意見をありがとうございました。いただきましたご意見と「非機能要求グレード」への反
映方針・考え方につきましては、付録．パブリックコメントリストを参照してください。
なお、以下のご意見につきましては「非機能要求グレード」への反映と完成をもって報告にかえさ
せていただき、パブリックコメントリストには記載しておりません。
・誤字・脱字などのご指摘・ご意見
・「非機能要求グレード」の各々の個別・細部に関するご指摘・ご意見
・類似のご意見
以上
Copyright ©2010 システム基盤の発注者要求を見える化する非機能要求グレード検討会
6
付録．　パブリックコメントリスト
番号
1
2
3
4
5
6
7
ご意見の
対象
利用ガイド
利用ガイド
利用ガイド
利用ガイド
利用ガイド
利用ガイド
利用ガイド
指摘
ページ
全体
全体
全般
全体
ご意見の内容
｢非機能要求グレード」への反映方針・考え方
とても良いツールですので、普及のため、「使用条件」をGPL程度の「オープン・ドご意見を踏まえて、最終公開物は、PDFファイルでの公開と、「グレード
キュメント」として、もっと、自由に使えるよう希望します。
表」と「項目一覧」を容易に利用いただけるように一体化した表をスプ
レッドシート形式で公開いたします。
また、スプレッドシートは、ご自由に利用いただけるよう使用条件を見
直しいたします。
ユーザーが提示/選択しやすく、ベンダーが理解しやすい非機能要求グレードの
レベルが設定できれば双方にとってメリットがあることは理解できます。ただ、非機
能要求グレードが対象にしているユーザーは、IT部門なのか、利用部門なのか、
カテゴリーにより明確になっていないように見えます。
(1) 利用部門とIT部門の間でビジネスパフォーマンスやビジネスリスクに対する非
機能要求のサービスレベルを取り決めする基準
(2) IT部門とベンダーの間で非機能要求のサービスレベルに対するシステム基盤
の要求仕様を取り決めする基準
(1)でグレードのレベルを選択し、次に(2)でシステム基盤の要求仕様を選択するガ
イドとしてまとめるとわかりやすいと思います。
ご意見を踏まえて、非機能要求グレードの対象ユーザにつきまして
は、利用ガイドの最初にどのような立場の利用者を対象にしているの
かを明確にします。
また、ユーザ内の部署等と非機能要求グレードの関係につきまして
は、利用ガイド[利用編]に記述いたします。
顧客のシステム基盤に対する非機能要件を引き出して効果的に定義するというフ
レームワークに違和感があります。顧客の要求は、APにはこういう要求、システム
基盤にはこういう要求、・・・という階層構造を構成しているという仮説に基づいてい
ると思われますが、顧客はシステムに対する要求があるのみではないでしょうか?
顧客からすれば、要求が確実に実現されればよいのであり、それがAPで実現され
ようと基盤で実現されようとそれはどうでもよいことではないでしょうか?顧客要求は
一つなので、それを無理矢理(?)APへの要求、システム基盤への要求、・・・に分
けで引き出すのではなく、1体の要求として引き出した後に要件定義→論理設計
において、どの階層で実現するかを全体最適の観点で決めていくと考えます。し
たがって単独での(に見える)システム基盤に対する要求の定義は違和感が強くあ
ります。
したがって課題はシステムに対する顧客要求をどう引き出して定義するか、それを
開発側がどのように各構成要素に割り当てるか、割り当てたときに必要な顧客要
求はどのように導出するか、ではないでしょうか。
また今回の構想は顧客がシステムの稼働率99.999%を求めている場合、これを
APとシステム基盤にそれぞれ割り振るという発想になるように見えます。しかしそ
の場合は、達成できる稼働率は99.999%の二乗になってしまいますから、顧客要
求は実現できないことになります。
ご意見を踏まえて、検討会の狙いが適切に伝わるように非機能要求グ
レードのスコープの記述を見直しいたします。
非機能要求グレードでは、非機能要求のうち、主に、システム基盤で
実現される要求をスコープとしています。システム基盤に注目している
理由としては、業務アプリケーションで実現される要求に偏ってしまっ
て不足しがちなシステム基盤に対する要求の確認・合意を促すことが
必要であると考えているためです。
非機能要求のグレードと開発取引の際の契約価格／工期（または単位機能辺りご意見につきましては、非機能要求グレードは合意形成のために提供
取引金額）の関係付けに対するガイドラインまたは、事例枠組みが必要でしょう。されるツールとしての位置づけであり、契約に関しては今後の検討課
こうしたものは容易ではないですが、これなくして適用と言っても契約に関わる問題といたします。
題として扱うことは難しいと考えます。是非、この観点での検討をお願いしたい。
単なる思い付きですが、こうした問題の合意形成は論理的にできそうな気はしま
せんが、例えば受発注者多数に対するこうした複合的な問題に対する認知度を
工夫したアンケート等で収集し（コンジョイント分析等の手法）、合意形成の一助と
することも面白いように思います。
非機能要件のグレード決定は、実際には対象システムの開発投資に関わる発注
者組織の経営課題or投資の狙い等、システム要求事項の前段階での方針決定
やビジョン設定に強く依存すると思います。つまり要件によっては、（機能要件と同
じく）費用、納期とのトレードオフが発生せざるを得ない性格です。この点を考慮
し、要求事項の背景に存する必然性または可塑性を明らかにする必要があると考
えます。この関係性をも視野に入れた検討を是非お願いしたいと考えます。
ご意見を踏まえて、以下の利用方法を利用ガイド[利用編]に記述いた
します。機能要求／非機能要求にかかわらず、要求内容によっては費
用、納期とのトレードオフが発生します。このようなトレードオフについ
て、非機能要求グレードでは、各要求項目に対して選定したレベルを
「プラス/マイナス」して調整する方法を提供しています。提示されたレ
ベルに対する見積が予算に合わなかった場合にレベルを変更して再
見積もりするというサイクルをまわす利用方法です。この方法では、当
初の要求を変更した場合、システム基盤にどのような影響が出るのかと
いうのを確認しながら調整できるというメリットもあります。
なお、運用コストとのトレードオフの関係については、項目一覧の「運
用コストへの影響」列に示しています。
・適用（想定）システムのカテゴリ定義が必要：想定しているシステムは、エンター
プライズシステムと思いますが、組込み系も含めているとなると使用環境（温度、湿
度。。）や安全性、信頼性などを考慮しなければならないことと、社会的影響度に
生命への影響を考えなければなりません。今回はエンタープライズの範囲だとの
前提条件を追記する必要があると思います。
・信頼性に関して：エンタープライズ情報システムとしても、社会的影響度を与える
システムの場合は性能要件だけでなく故障（システム障害）発生頻度や検出難度
も要件として必要なのではないかと思います。
・しかしながら全体としてよくまとまっていると思います。
ご意見を踏まえて、非機能要求グレードが想定している情報システム
については、利用ガイドに記述すると共に、モデルシステムをより理解
しやすくなるようにいたします。
非機能要求グレードでは、主に企業の業務システム等の情報システム
を対象としております。
なお、信頼性については、大項目「可用性」の中で定義しております。
全体
全般
全般
非機能を精査する上で、正しいシステム構成、安定稼動の机上確認、適正投資ご意見を踏まえて、利用ガイド[利用編]の「いろいろな利用例」の内容
（モノ）による適正コストの評価などに結び付けるためにも参考になると思います
を見直して、利用者の考え方でいろいろな使い方が出来るように表現
が、そのようなニュアンスが伝わってきません。
を改善いたします。
ガイドの内容は、利用者の考え方でいろいろな使い方が出来るようなニュアンスを
出してもよろしいかと思います。
（ガイドは利用する側の責任で使うのです）
Copyright ©2010 システム基盤の発注者要求を見える化する非機能要求グレード検討会
付録 - 1/8
番号
8
9
10
11
12
13
ご意見の
対象
利用ガイド
利用ガイド
利用ガイド
利用ガイド
指摘
ページ
ご意見の内容
｢非機能要求グレード」への反映方針・考え方
非機能グレード検討会およびこの成果の目的はシステム基盤の非機能要求を見
える化することと思います。このことは検討会HPや成果をよく見るとそれを読みと
れますが、初見の人には、下記のような狙いをもっと前面に出して、強調されたほ
うが意図が伝わると思いました。
システム基盤とはそもそも何か
↓
システム基盤の非機能要求に関して、どのような問題が生じているのか
↓
これに対しどのような解決を図っているのか
ご意見を踏まえて、非機能要求グレードの背景や目的に関しまして
は、以下の3点を、より解りやすくするように利用ガイド［解説編］に記述
いたします。
・システム基盤の定義
・非機能要求の問題
・問題への解決法
全体
非機能要求グレードで扱われている要求項目は開発時に必要な非機能要求、あ
るいは、運用時に必要な非機能要求のどちらか。初期段階での要求検討にのみ
使うものであるならその旨明確にしておくことが必要と思う。開発時に必要な非機
能要求としても試験や検収に扱う場合は違うし、SLA要件など運用で考えるものも
異なる。
ご意見を踏まえて、システム開発の開発プロセスと非機能要求グレード
の関係を利用ガイド[利用編]で説明するようにいたします。
非機能要求グレードは、基本的に要件定義までの段階で利用されるこ
とを想定しています。ただし、運用時に必要な非機能要求についても
システム基盤に影響を与えるものについては、要件定義の段階で検討
することが必要ですので、非機能要求グレードに含めています。
全体
ISO/IEC 9126に記載されているようなメトリクスの評価式は、なぜグレード表に掲
載されていないのか。メトリクスの内容を決めても、後で確認ができなければいけ
ないため、評価式を明確にすることは重要だと思っている。
ご意見につきまして、非機能要求グレードのメトリクスは非機能要求内
容の合意を目的に抽出した段階であり、メトリクスを「受入試験」や「検
収」時にどのような評価式で確認するかについては、今後の検討課題
といたします。
全体
非機能要求に関する全体像のうち、グレード検討会は最初のステップとしてここに
取り組んでいる、という位置づけがぱっと分かる絵があると良い。
いろいろ課題はあるが、今回はまずここに取り組んでいて、そこについては一歩前
進した、というニュアンスが分かる説明が欲しい。
ご意見を踏まえて、非機能要求グレードのねらいとスコープの記述を
見直しいたします。
なお、「非機能要求グレード検討会のは最初のステップとしてここに取
り組んでいる、という位置づけがぱっと分かる絵」については、文章で
記述することで代替いたします。
全般
非機能の6大項目の定義や、具体的な例(表1.6.2.1、2.4.にある概要程度)が前半ご意見を踏まえて、利用ガイドをより活用しやすくする為に、利用ガイド
にまとまって整理されている方が資料全体がわかりやすくなるのではないか。
を「利用編」と「解説編」の二つに分冊化いたします。利用ガイド［利用
編］では非機能要求グレードの利用方法について説明し、利用ガイド
利用ガイド欲を言えば、成果物を利用した検討のイメージ(図1.1.1または図2.1.1に相当)や［解説編］では非機能要求グレードの背景と各ツールの詳細を説明い
利用ガイド
全体の構成非機能の概要(前述)といったプロジェクト全体で共有する概要的な資料と、実担たします。
当者レベルが必要とする詳細その他を期した資料と分かれていると、使いやすく
なるのではないか。
利用ガイド
全体
システム基盤の、と限定していることの説明がもう少し必要だと思う。
ご意見を踏まえて、利用ガイド[解説編]において、非機能要求グレード
非機能要求」ということばが前面に出すぎており、「システム基盤の」という限定詞のスコープは主にシステム基盤で実現される非機能要求であることを
が隠れてしまっているところが少し気になります。
記述いたします。
利用者が混乱する可能性がありますので、その部分だけ、もう少し強調していただ
いた方がよいと思います。
誰が、どの部分を使うのか、を、この時点で明確にして欲しい。
⇒最初に全体像と利用イメージを掴みたいから。
14
15
16
17
18
利用ガイド
利用ガイド
利用ガイド
利用ガイド
利用ガイド
1
ご意見を踏まえて、最初に全体像と利用イメージを掴めるよう利用ガイ
ドの構成を見直しいたします。具体的には、利用ガイドを[利用編]と[解
説編]の二つに分冊化し、[利用編]の構成を工夫します。
1
何故グレード（Grade）という言葉を使用したのでしょうか。Gradeは明らかに等級、ご意見を踏まえて、「グレード」のコンセプトについて、「グレード」とは何
階級を指す言葉であり、グレード１はグレード３より劣ると読み取れてしまいます。を指しているのか利用ガイド[解説編]の「FAQ」に説明を記述いたしま
別な表現が望ましいと感じられます。
す。
6
1.6.2　スコープ内の項目について
ご意見を踏まえて、非機能要求グレードにおける６大項目選定の経緯
非機能要求を「可用性」「性能・拡張性」「運用・保守性」「移行性」「セキュリティ」を利用ガイド[解説編]の「FAQ」に記述いたします。
「環境・エコロジー」の　６分類に整理しているが。このように分類にした背景、
網羅性評価についての記述が欲しい。システム基盤に対する発注者の要求を「見
える化」することを目的に選んだ、FAQのA1に６社の集約、整理した結果等と書い
てあるが、客観性のある説明が欲しい。
例えば、品質外部特性（機能性、信頼性､使用性､効率性､保守性､移植性）、
RASIS（信頼性、可用性、保守性、保全性、セキュリティ）、その他の標準が定義し
ている分類を集約するとこうなり、基盤に影響する要素としてこの６つになる、という
説明が欲しい。
7
1.6.3にて、検討のスコープ外としている項目がありますが、クライアントサイドの基ご意見につきましては、非機能要求グレードが主にシステム基盤で実
盤を選定する際に、ユーザビリティについて検討すると思います。
現される要求をスコープとしており、ユーザビリティは基本的には、業
務アプリケーションとの関連が深く、ユーザに意識されやすい要求と考
えていますので、非機能要求グレードのスコープ外としています。
8
2章は「成果物の説明」が書かれているのは確かだが、「非機能要求グレード評価ご意見を踏まえて、タイトルを見直します。
Kit（？←成果物のまとまりをさす名前）の利用法」とした方が、わかりやすい
なお、「非機能要求グレード」を成果物の総称としていますので、その
定義を利用ガイドの[利用編][解説編]の序文に記述いたします。
Copyright ©2010 システム基盤の発注者要求を見える化する非機能要求グレード検討会
付録 - 2/8
番号
19
ご意見の
対象
利用ガイド
指摘
ページ
8
ご意見の内容
｢非機能要求グレード」への反映方針・考え方
図2.1.1について、成果物を全部閲覧した結果、私のイメージと違っていました。
私がイメージしたのは下記のようでした。
一番重要な基準として、根底にある成果物は「項目一覧」
利用時の参照として、その項目を見やすくした目次が「樹形図」、項目一覧の検討
の指標サンプルが「グレード表」
利用時の手順として、上記成果物を利用する際の手順書が「利用ガイド」
ご意見を踏まえて、利用ガイド［利用編］の「基本的な利用例」におきま
して、非機能要求グレードの基本的利用が、「モデルシステム」→「グ
レード表」→「項目一覧」の流れであることを明確に説明いたします。ま
た、「いろいろな利用例」についても内容を見直しいたします。
ですので、私が初心者で利用するなら、「利用ガイド」を読んで、「項目一覧」を利
用します。そして、たまに検討時の参考として「グレード表」を見ることになります。
20
21
22
23
24
25
26
27
利用ガイド
利用ガイド
利用ガイド
利用ガイド
利用ガイド
利用ガイド
利用ガイド
利用ガイド
上成果物の作りを示すのであれば、2.3.3の「項目一覧」の説明の後に、モデルシご意見を踏まえて、利用ガイド[解説編]におきましては利用ガイド［利
ステム部分が付加された2.3.2の「グレード表」の説明をした方が理解し易いかと思用編］の「基本的な利用例」と同様に「モデルシステム」→「グレード表」
→「項目一覧」の流れに合わせて説明いたします。
p.16～p.18 います。
9
9
13
13
13
14
18
2.1.1　グレード表
・システムの処理規模に関するグレードがない
APプログラムサイズ、クライアントPC数、外部接続するシステム数およびデータ
量といったシステムの処理規模を表す要素によってシステム基盤のグレードが変
化しうると思いますが、それを評価する項目が無いように見えます。環境・エコの
中に「システム利用者人数」「クライアント数」など近いものが有るが、グレードのレ
ベルが不十分だと思います。
ご意見を踏まえて、メトリクスのレベルを見直しいたします。
なお、非機能要求グレードではシステム基盤全体に対する非機能要
求に関して「システム環境」や「業務処理量」で確認するようにしていま
す。
「ユーザが具体的な非機能要求をすぐに提示できるようにする」がテーマとしてい
るが、全体を通して、最後はユーザが決めるものだ、というトーンが感じられる。ベ
ンダーがもっと積極的に決めていいのではないか。これはp29、モデルケースを決
めるプロセスでも言える。ヒューリスティックにどのモデルから始めればいいかはベ
ンダーが判断できるのではないか。
ご意見を踏まえて、利用ガイド［利用編］におきまして、ユーザ/ベンダ
の関係をより具体的に説明するようにいたします。なお、グレード表/項
目一覧はプロジェクトによってユーザ/ベンダどちらが主体的で使うの
か異なることがあるため、非機能要求グレードではユーザ/ベンダどち
らが主体的に使うべきかは定義しておりません。
モデルシステムがイメージしづらい。一般企業におけるシステムでの例がいくつかご意見を踏まえて、「モデルシステム」を表にして一覧化する等の見直
あると分かりやすい。
しと、理解しやすくなるように工夫いたします。ただ、一般企業における
システムの例は、「社会的影響が限定されるシステム」のバリエーション
として案件毎のご対応をお願いいたします。
社会的影響の文言がありますが、漸くP13にて理解をすることになります。
社会的影響 = 社会インフラ（金融、医療、交通機関など）の印象を受ける方が多
いと思われますので、
社会経済の影響、社会的経済影響などのニュアンスの方がよろしいかと思いま
す。
もしくは、P13の説明を P1-2に挟み込んでは如何でしょうか。
ご意見を踏まえて、モデルシステムの名称に関する説明を見直し、利
用ガイドに記述いたします。
また、すぐにモデルシステムの説明を参照できるよう、モデルシステム
の説明を記述したシートを、グレード表に組み込みます。
「重要インフラ情報システム信頼性研究会」の報告書に記載されているように、シ
ステムプロファイリングは4つ存在する。しかしグレード表のモデルシステムには
「人命への影響、甚大な経済損失が予想される」システムについての記述が無
い。検討会としての「人命への影響、甚大な経済損失が予想される」システムの位
置づけはどうなっているのか。
「人命への影響、甚大な経済損失が予想されるシステム」は「社会的影
響が極めて大きいシステム」の中に含まれるという位置づけで考えてお
ります。その趣旨の説明を、モデルシステムシート、および利用ガイド
[解説編]のモデルシステム説明部分に追加いたします。
「(E)ｾｷｭﾘﾃｨ」で「外部への接続有り。」となっていますが、「表2.3.1.3 社会的影響
が限定されるシステムの非機能要求」では「外部への接続無し」となっています。
「表2.3.1.2 社会的影響が殆ど無いシステムの非機能要求」の「(E)ｾｷｭﾘﾃｨ」で「外
部への接続なし」の誤りではないでしょうか。
ご意見を踏まえて、「社会的影響が殆ど無いシステムの非機能要求」
は、外部への接続があることを想定したモデルシステムとなっておりま
すので、モデルシステムの説明と該当部分の表現を見直しし、より分か
りやすくなるように改善いたします。
重要項目について。品質やコストへのインパクトの違いで分けられるのではなく、ご意見を踏まえて、「重要項目」について、重要項目を選定した経緯な
ユーザとベンダーの間でコンセンサスを得ることが必要な項目か、他の項目が明どを勘案して利用ガイド[解説編]に説明を補足するようにいたします。
らかになっていれば、ベンダー側で単独で判断できる項目化か、の違いではないただ、非機能要求グレードは、ユーザ/ベンダ双方で合意が必要なシ
か。つまり後者はユーザ関与が必要ない。（正確には、過剰スペックでないかのステム基盤に関わる非機能要求を抽出していますので、基本的には双
チェックは必要なので、確認だけでよい、という項目）。ネーミングも解釈が広く、誤方が合意することを前提にしています。
解を与えやすい。
非機能要件検討のプロセス
非機能要件を指標の単位で検討するのではなくて、重要でレベルの高い項目ほ
ど詳細まで検討する、といったブレークダウン式アプローチの方が検討しやすい
のではないか。
28
29
利用ガイド
利用ガイド
26
32
たとえば6大項目での重要度(レベルや検討の優先度や深堀具合)をまず顧客と
検討する。
次に重要度の高い項目の中項目について重要度の検討を行う。重要なものにつ
いては、さらに小項目、指標の検討を行う、といったような進め方である。
3.3　いろいろな利用例
社会的影響が大きいシステムの企業においては、非機能要求のグレートについて
の要求レベル感があらかじめあると思われるが、一方で、「社会的影響が殆ど無い
システム」の企業の場合には、非機能要求のグレードを検討するに当たって、当
該グレートを採用する場合のコスト見合いで、グレードを決定するプロセスが想定
される。こうしたことから、見積もりプロセスも考慮した要求レベルの確認例もあると
わかりやすいと思われる。
なお、当該事項は「4.3　ＦＡＱ」に掲載することも代替案として考えられる。
Copyright ©2010 システム基盤の発注者要求を見える化する非機能要求グレード検討会
付録 - 3/8
ご意見を踏まえて、利用ガイド［利用編］の「基本的な利用例」や「いろ
いろな利用例」を見直しいたします。ただ、非機能要求グレードは、「モ
デルシステムの選定」→「グレード表による重要項目の確認」→「項目
一覧による詳細の決定」、という基本的な利用方法を想定しています
が、「いろいろな利用例」に示しますように使い方の制限はしておりませ
ん。
ご意見を踏まえて、利用ガイド［利用編］の「基本的な利用例」におきま
して、非機能要求を決めて見積り、予算内に収まらない場合には、要
求内容を見直して再見積もりする流れを繰り返すことがあることを補足
いたします。
番号
30
31
32
33
34
35
36
37
ご意見の
対象
利用ガイド
グレード表
利用ガイド
利用ガイド
利用ガイド
利用ガイド
利用ガイド
利用ガイド
指摘
ページ
20-25
48-57
全体
36
ご意見の内容
｢非機能要求グレード」への反映方針・考え方
例えば、20ページにおいて「耐障害性」は「耐故障性(fault tolerance)」であり、故ご意見を踏まえて、用語の使用につきましては誤解をあたえる部分が
障(faults)と障害(failures)の概念と用語の定義が日本語と英語とで一対一対応しないように見直しいたします。なお、用語は「非機能要求グレード」の利
ない。高信頼情報システム基盤(Dependable and Secure Computing)の非機能要用者がわかりやすい一般的な用語を用いています。
求グレードのメトリクス（指標）を設計するための概念と用語の定義は次の国際標
準に行うべきである。
「非機能要求グレード利用ガイド」の発注者側想定読者をどう考えるか、によるが、ご意見を踏まえて、分かりにくい専門用語は用語を見直すなど、表現
非機能要求に関する知識があまり無い発注者側担当者を想定すると、用語集のを修正いたします。
用意など工夫されているが、専門用語の使用を回避したほうがさらにわかりやす
いと考える。
表3.4.1　No.2　モデルシステムに該当しない案件で利用する場合には，新たなモご意見を踏まえて、モデルシステムに該当しない案件で利用する場合
デルとしてグレード表を策定して利用，とあります．つまり，グレード表は今後拡張は、各組織でグレード表をカスタマイズして利用することを利用ガイド
するという予定があるということなのでしょうか？それとも，各組織でグレード表をカ [利用編]に記述いたします。
スタマイズして利用する，ということでしょうか？後者の場合では，カスタマイズの
方法などを具体的に示していただけると助かります．
37
4.1 非機能要求に関するほか活動との関係について
IPA/SECの「発注者ビューガイドライン」についても追加されてはいかがでしょう
か。（あまり関連性はないかもしれませんが）
37
他基準や他ガイドとの関係について言及することは重要なことだと思います．しかご意見を踏まえて、非機能要求に関する他の活動との関係を示した図
し，図4.1.1の図が何を示しているのかわかりにくいと感じました．理解を深めるたにつきましては、再整理するようにいたします。ただ、現在の図の上下
めにも，長方形の大きさの意味等，図の凡例を示していただけると助かります．
関係は、特に意味はございません。
37～38
P37の図4.1.1に、非機能要求グレードとJUAS-UVCⅡ、JEITAのSLAガイドラインご意見では、非機能要求グレードとJUAS-UVCⅡ、JEITAのSLAガイド
との関係が示してあるが、項目単位で差異がわかるような表があるとよいと思われラインとの関係を項目単位で差異がわかるような表をご要望されている
ます。
かと思います。ご意見につきましては、今後の検討課題といたします。
40
ISO/IEC9126との対応表を見ていて感じたのですが、例えば「変更性」と「習得
ご意見を踏まえ、大項目間で留意すべき関連については、利用ガイド
性」は、複雑なユーザカストマイザブル要件を実装した場合、逆に習得性や運用 [解説編]の大項目ごとの説明の部分で記述いたします。
性を制約してしまう場合があると思います。６つのドメインカテゴリ間での相関関係
の検討も視野に入れねばならない場合があるのではないでしょうか？
樹系図の使い方
上にコメントした大→中→小項目をブレークダウンするときに、樹系図が使えると
検討しやすいと感じる。
コメントの補具体的なイメージはないが、樹系図も検討のワークシートやチェックシートになっ
足
ていると便利。
ご意見につきましては、利用ガイド中に記述することで理解に混乱を
招く可能性があるため、記載しないことにいたします。なお、ご指摘の
「発注者ビューガイドライン」については、ほぼ同じ枠組みの母体で検
討されています。
ご意見を踏まえて、利用ガイド[解説編]に「樹系図」の利用方法につい
ての説明を記述いたします。
38
グレード表
全体
グレード表と項目一覧は、一体としていいのでは？見せ方を工夫すれば、それがご意見を踏まえて、「グレード表」と「項目一覧」を一体化した表を作成
初期段階で決定すべき重要項目(すなわちグレード表にあげる項目)か、後々決しスプレッドシート形式で提供いたします。
定していく詳細項目かは判別できるので。
39
グレード表
全体
空欄には、－(ハイフン)などを入れて、「規定、記載、なし」を明確化した方が分かご意見を踏まえて、試作し確認しましたが、結果として、見やすさの観
りやすいです。
点から、空欄のままといたします。
40
グレード表
全体
非機能要求を品質要求と制約に分離して捉えて、システムを利用(運用・保守・・）
する場面・状況でどのような制約があるか、その場面・状況でどの品質特性にどの
程度のサービスレベルが要求されているか、２つの軸で非機能要求の困難さのレ
ベルを表現すると解りやすくなると思います。制約は、現在の技術では解決困難
な物理的制約(距離による伝搬遅延など)とシステムの発注者や社会が規定してい
る方針制約に分離して表現すると、ベンダーが提供する解決策の技術的実現性
とコスト的実行可能性の評価との関連がわかりやすくなります。
ご意見を踏まえて、項目の並びを再検討するなど見直しする際の留意
事項にいたします。なお、非機能要求グレードでは、非機能要求を
ユーザ/ベンダ双方で漏れなく合意すると言うことを重視し、かつ、合
意すべき非機能要求を検討すべき単位でまとめる方式を継続し、現在
の６大分類に纏めることにいたします。また、レベルにつきましても非機
能要求を実現する難易度を開発コストという観点から表現する方式と
いたします。
システムのモデルによってどの程度かを理解するような記載の仕方は非常に良いご意見を踏まえて、利用ガイド[利用編]の「いろいろな利用例」に非機
能要求グレードのカスタマイズについて記述いたしますので実システ
と思います。
「選択時の条件」欄にて＋、－の選択例があるのも決める際の判断材料になりとてムの要求に合うようにカスタマイズをして利用をお願いいたします。
も有効だと思います。
41
グレード表
全体
欲を言えば、社会的影響以外の他の軸でのモデルもあると嬉しいです。
（B2B、B2C、長期利用、短期利用、運用予算の制限、運用人員の制限、特定数
のアクセス、不特定多数のアクセス、QCDのどれを重視するかなど）
Copyright ©2010 システム基盤の発注者要求を見える化する非機能要求グレード検討会
付録 - 4/8
番号
42
43
44
ご意見の
対象
グレード表
グレード表
グレード表
指摘
ページ
全体
全体
全体
ご意見の内容
｢非機能要求グレード」への反映方針・考え方
全般
｢社会的影響度・・・・・・システム｣モデルとメトリクスのレベルとの重みの関係が不
明確。
システムの利用形態（社内、事業用、公共利用等）や評価者によて重みの捕らえ
方が異なるのではないか。
また、グレード表であるなら、重みに対する何らかの考え方を示すべきではない
か。
ご意見を踏まえて、「グレード表」に「モデルシステムシート」を追加し、
モデルシステムを解りやすく改善いたします。また、「グレード」のコンセ
プトについて、「グレード」とは何を指しているのか利用ガイド[解説編]
の「FAQ」に説明を追加いたします。ただ、実際に利用される場合に
は、モデルシステムで得られたベース値を利用形態によって「プラス/
マイナス」の上下に調整をしていただく必要があります。このことは、利
用ガイド［利用編］で説明を補足いたします。
項番は示されていますが，連続性がないため，行番号等を付与するなど工夫いたご意見を踏まえて、「グレード表」と「項目一覧」は容易に利用いただけ
だけると利用しやすいと思います．
るように一体化した表をスプレッドシート形式で公開いたします。「グ
レード表」と「項目一覧」を一体化したスプレッドシートで連続性がとれ
るように改善いたします。
レベルはなぜ左詰で記述されているのか。直感的な指摘ではあるが、普通なレベご意見につきまして、非機能要求グレードでは各モデルシステムでレ
ルはレベル3、一番高いレベルはレベル5などにバラして配置してほしい。グレードベルに差が出ないメトリクスも存在するため、レベルに特別な意味を持
表のモデルシステムは、一番左に「社会的影響が殆ど無いシステム」、一番右にたせることは見送りとさせていただきます。
は「社会的影響が極めて大きいシステム」が配置されているのに、その値を見ると
レベルが5になったり、3になったり場合によっては1があったりと感覚的に読むこと
が困難である。
思いつきのアイデアだが、せっかくモデルシステムを定義しているので、モデルシ
ステムのように一番左は「社会的影響が殆どない」レベル、真ん中は「社会的影響
が限定される」レベル、一番右は「社会的影響が極めて大きい」レベルとすること
はできないか。
45
46
47
48
グレード表
グレード表
グレード表
グレード表
全体
全体
全体
全般
非機能要求項目は、せいぜい25から30個程度の項目をピックアップして開発初期非機能要求グレードは、非機能要求をユーザ/ベンダ双方で漏れなく
から運用まで管理して使うことが多い。
合意することを重視して要求項目をリストにしています。
多くの項目があっても、結局使うのはそのぐらいの項目数になるかと思う。非機能また、非機能要求グレードは段階的詳細化の検討方法に従った利用
要求グレードはそのような使い方ができるようになっていて欲しい。
を想定しています。
ご意見を踏まえて、段階的詳細化を容易にするためにモデルシステム
の特徴を表わす非機能要求を絞るとともに、モデルシステムシートを新
設して一覧性を高めるように見直しいたします。
利用ガイド[利用編]の基本的な利用例や共通的なインフラ基盤が存在
する場合の利用例などを参考にご利用をお願いいたします。
項目一覧表から重要項目を105個選択したとありますが，選択の根拠がよくわかり
ませんでしたので，明示いただきたいと思います．
重要項目として，「セキュリティリスク管理」が選択されていない点が気になりまし
た．追加をお願いしたいと思います．
ご意見を踏まえて、利用ガイド[解説編]に「重要項目」の検討経緯を勘
案して「重要項目」の定義、選定根拠を明示するようにいたします。
その上で、上記の基準に照らして、「セキュリティリスク管理」が「重要項
目」として含まれるかについても追加検討いたします。
グレードは一意に決めるべき場合とそうでない場合（例えば、最低限ｘｘｘは達成、
しかしできれば△△△まで実現できると良いなど）があると思います。発注者から
見た場合は、そのように目標設定を一定の幅を持って要件出しを進めるのが自然
なアプローチのように思います。一方受注者にとっても、一意に決定したグレード
集合は非常に強い枷になり、設計の自由度や代替案検討の幅を狭めかねないよ
うに思います。これは、利用ガイドに対するコメントかも知れませんが、こうした一定
の自由度を維持できる枠組みにして利用したいと思います。
ご意見につきましては、利用ガイドを見直す際の参考といたします。な
お、非機能要求グレードを使って検討された結果を契約上でどのよう
に表現するのかにつては個別具体的案件で検討する必要がありま
す。
各項目は「重要項目」か否かの分類がされていますが、それとは別に、「①利用者
視点（エンドユーザに近い立場）で定義されるもの」と「②設計・実装として検討す
るもの」という区分けもできるように思います。
この区分けは樹系図から読み取れるかと思ったのですが、必ずしもそうではありま
せんでした。
検討は、①→②の順番で進むので、①と②が明確に分離して定義されているとわ
かりやすいです。
また、各②の項目に関連する①の項目が明示されると、よりわかりやすいと思いま
す（n:nの関係になる）。
更にその関連付けの中で、①のレベルと②のレベルの関連についても説明が加
われば、検討の助けになります。
（①のレベルが5の場合②は4～5が該当、①のレベルが4の場合②は3～4が該
当、というような関連があると思われる）
全ての項目で上記ができるものとは思いませんが、できるものもあるのではないか
と思います。
ご意見を踏まえて、利用ガイド［利用編］のいろいろな利用例の内容を
見直しいたします。
また、樹系図につきましては、改良を行い、利用ガイドで解説を補足い
たします。
なお、ご意見にあります「非機能要求項目を利用者視点や設計・構築
者視点等で分析して重要項目以外にも分類する」ことにつきましては
将来の検討課題といたします。
尚、樹系図には上記の観点を期待するので、現在のままだと、中途半端に感じま
す（おそらく利用しない）。
49
グレード表
－
50
グレード表
B.3.1.1
「運用コストへの影響」の定義がもうひとつはっきりしない。「開発コストをかければご意見を踏まえて、「運用コストへの影響」について利用ガイド［解説
運用コストを下げられる可能性」であれば、もっと多くの項目が該当するのではな編］で解説を補足すると共に、「グレード表」、「項目一覧」の精査をい
いか？
たします。
⇒再度項目毎の精査が必要
CPU余裕率というのは、やはり違和感がある。CPU利用率とした方がよい。メモリもご意見を踏まえて、「利用率」を使用いたします。
同じ。
Copyright ©2010 システム基盤の発注者要求を見える化する非機能要求グレード検討会
付録 - 5/8
番号
51
52
ご意見の
対象
項目一覧
項目一覧
指摘
ページ
全般
全体
（例えば，
C.5.4.1）
ご意見の内容
｢非機能要求グレード」への反映方針・考え方
項目一覧には、「非機能要求」ではなく、それを実現するための「手段」的要素が
強いもの、それらを検討するための前提となる「基礎事項」などが混在しておりわ
かりづらい。カテゴリーを分けたほうが良いのではないかと思います。
・基礎事項：業務処理量、業務増大度、機材設置環境条件など
・手段的要素が強いもの：システム監視継続性、耐障害性（ここではいきなり非冗
長、コールドスタンバイ、といった方式論が出てくるが、本来の耐障害性は1台の
サーバーで障害が発生した際に、どれくらいの時間待てるか、という可用性の非
機能要件から導くものと思います）、運用・保守性の項目など
ご意見を踏まえて、項目の並びを再検討するなど見直しする際の留意
事項にいたします。なお、非機能要求グレードでは、非機能要求を
ユーザ/ベンダ双方で漏れなく合意すると言うことを重視し、かつ、合
意すべき非機能要求を検討すべき単位でまとめる方式を継続して、現
在の６大分類にいたします。
定量化できないものについてもレベルを設定する必要があるのかどうか疑問を持
ちました．例えば，運用・保守体制の「役割分担」については，選択肢の提示があ
るとありがたいのですが，「全てユーザが実施」がレベル0で，「一部ユーザが実
施」がレベル1，「全てベンダが実施」がレベル2という設定になっており，違和感が
あります．場合によっては，ユーザとベンダと共同で役割分担することで「全てベ
ンダが実施」するよりも，難易度が高くなるケースもあるのではないでしょうか？
ご指摘のような具体的な数値でレベルが表現されていないメトリクスで
あっても、ユーザ/ベンダ双方で合意することが重要であると判断した
場合はメトリクスとして定義しております。また、レベルの高低が逆転す
る可能性があるメトリクスが存在していることについては、ご意見を踏ま
えて、利用ガイド[解説編]や備考などに補足説明をするようにいたしま
す。
システムのグレードとレベルの値が一致している方が分かりやすい。
53
54
55
56
項目一覧
項目一覧
項目一覧
項目一覧
全項目
レベル値
全般
全般
全体
ご意見につきましては、非機能要求グレードでは各モデルシステムで
レベルに差が出ないメトリクスも存在するため、レベルに特別な意味を
たとえば社会的影響が極めて大きいシステムではレベルが全て4とか5とかになる持たせることは見送りとさせていただきます。
方が
分かりやすいのではないかと感じる。
グレード表にて、３類型（社会的影響度による分類）の実現レベルが定義されてい
ますが、重要項目以外についても定義できないでしょうか。
尚、全項目について「社会的影響度の３類型」で実現レベルを定義できるものとも
思いません。
出来ない項目については無理に定義しなくてもいいと思います。
例えば、「移行データ量」は、「社会的影響度」と何ら関係なく、実際の移行データ
量を定義する以外、意味がないと思います。
それでも、何らかのレベルを仮にでも定義しておかないと使いづらい、という側面
があるのであれば、３類型一律「2」を設定し、全て同じ「+」「-」のコメントをつけて
おいたほうがよいのではないかと思いました。
ご意見を踏まえて、「グレード表」と「項目一覧」を一体化した表をスプ
レッドシート形式で提供いたします。なお、重要項目以外のベース値
につきましては個別具体的案件で変動することが多いために各案件で
カスタマイズして定義していただくことを想定しております。「グレード
表」と「項目一覧」を一体化した表を利用して、重要項目のレベルを決
定後、あるいは決定する過程において、レベル値を選定してください。
各項目の内容は、各々は理解しやすいと思います。（中級者の経験があれば問ご意見を踏まえて、レベルの数値に理由付けなどの説明を追加するこ
題ないと思います）
とを検討いたします。
ただ、理解しにくいのは 1倍、1.2倍、1.5倍など係数の幅が持つ意味が理解でき
ません。
この差の考え方が簡単にコメントあれば、直感の回答でなくなりユーザ/ベンダの
認識差も詰まると思います。
「小項目」について「メトリクス」が詳細にいくつか定義されているものと、ざっくりと
定義されているものがある。
そのためか、「レベル」も詳細なのとざっくりなものがある。
（定量的な例を用いた「レベル」、通常気にしないような細かな「メトリクス」、「レベ
ル」が2択しかない、など。）
ご意見を踏まえて、メトリクスやレベルの記載粒度を同じぐらいすること
を意識し、粒度精査を実施いたします。
「メトリクス」「レベル」の記載粒度を同じぐらいにして欲しい。
各レベルにおける、コストへの相対的インパクト度（例えば、レベル0を1とした場合ご意見につきましては、検討会でレベル感につきまして検討いたしまし
の各レベルの比較間の目安）があると、レベル感の検討の参考になる。
たが、結論に至らず、今後の検討課題といたします。
57
58
59
60
項目一覧
項目一覧
項目一覧
項目一覧
全般
－
全体
全体
メトリクスの各項目について、項目の定義がほしい。例えば下記No３(A.1.1.1)のよご意見を踏まえ、意味が明確でないメトリクスの定義については備考で
うな場合、あいまいになってしまう。
補足いたします。
利用ガイドに「概要」や「留意事項」があるが、もう一つ個別の項目説明になってい
ない。
⇒小項目説明か備考欄に、メトリクスの定義を明記するようルール化し、徹底す
る。
No3 コメント
「可用性」の「運用スケジュール」で、「運用時間（特定日）」と「運用時間（通常）」と
の区別が良くわからない。
レベル定義は「土日は運用しない」「日曜の夜間のみ運用しない」などの定義とな
るのでは？
⇒説明が不足しているので追加して欲しい
可能であれば各項目を決めておかなければならない理由があると嬉しいです。
（特に「重要項目」になっている項目については、決めておくべき理由があるから
重要項目になっていると思います。）
それら理由があると、「これを決めておかないと後からこういったリスクが発現する」
と分かっている担当者は、漏れなく聞く動機付けになり、リスク発生、手戻りの防止
につながると思います。
ご意見は、重要項目の選択理由が個別には記載されていないことに
起因していると理解しました。ご意見を踏まえ、利用ガイド[解説編]に
重要項目の検討経緯を勘案して重要項目の定義、選定根拠を明示す
るようにします。
⑨ プロセス管理的なこと、もしくは、要件を導出するための手続き的なことは除去
したほうがよい。例えば、運用・保守体制での「定期報告会」や「運用管理方針」、
もしくは、セキュリティリスク分析や対策等
理由：「システム基盤に関わる部分」をスコープとする記載されている（ガイド：Ｐ５）
ため。
ご意見を踏まえて、利用ガイド[解説編]の「非機能要求グレードのス
コープ」の箇所の説明を見直します。なお、システム基盤に関してユー
ザ/ベンダで合意が必要と考えられる要求については、手続き的だと
思われる要求についても非機能要求グレードに記述しております。
Copyright ©2010 システム基盤の発注者要求を見える化する非機能要求グレード検討会
付録 - 6/8
番号
61
62
ご意見の
対象
項目一覧
項目一覧
指摘
ページ
可用性
ご意見の内容
｢非機能要求グレード」への反映方針・考え方
小項目・可用性/業務継続性と小項目・耐障害性/サーバ等は業務継続性のレベ
ルに合わせて、サーバのレベルが決まると考えられるので、項目を並列の関係で
はなく、階層化をして頂きたいと思います。それにより検討の順序性や項目間の
関連性が、より明確に認識できるものと思います。
ご意見は、項目の階層化による検討の順序性や項目間の関連性を明
確するということと理解致しました。ご意見を踏まえ、基本的には「樹系
図」で階層化や順序性を表現するようにしておりますので、ご意見の趣
旨を踏まえて、「樹系図」を改善いたします。
「可用性」と「運用・保守性」の分類にやや一貫性を欠く項目があるように見受けらご意見は、大項目間に重複した項目が存在することに起因するご意見
れる。
と理解致しました。ご意見を踏まえて、大項目間に重複するメトリクスが
存在する場合には、重複を識別できるようにすると共に、重複した相手
おおよそ項目一覧では「可用性」のところでは障害に対する許容水準を決めておメトリクス、理由などの説明を追加いたします。
り、「運用・保守性」は正常・障害かかわらずシステム運用のサービスレベルを決め
可用性と運
ている。
用
この分類に従うとすると「可用性」にある運用スケジュールや監視継続性は「運用・
保守性」の項目にある方がしっくり来る。
63
項目一覧
A3
付帯設備（小項目）のレベルを上げるべきではないか。災害時だけでなく、停電対ご意見を踏まえて、災害対策の付帯設備に加え平時の付帯設備（停
策、接地条件等の条件は、平時のときでも必要である。
電対策、接地条件等の条件）に関する小項目を、システム環境に追加
いたします。
通常時の業務量
ご意見を踏まえ、レベルの設定が可能か検討いたします。
登録ユーザ数、同時アクセス数など数値なしはレベル１になっているが、今決まっ
ていなくても要件定義で決める必要があり、決まっていないことがレベル１は違和
感あり。
WEBシステムで不特定多数がユーザならレベル５とか。Ｍａｘは会員数でその数が
判っている場合はレベル３とか・・・
64
項目一覧
B.1.1.1
65
項目一覧
B.3
中項目　リソース拡張性
小項目に列挙するリソースにネットワーク (LAN および WAN) を追加したい。
B4
性能品質保証の性能テストの内容は、運用・保守性の項目としても取り上げるべきご意見の性能テストつきましては、性能・拡張性の要求としています
である。
が、一方、運用・保守性では、監視のレベルとして性能監視を含めて
います。従いまして、ご意見の性能テストを運用・保守性に含めること
は見送りとさせていただきます。
66
項目一覧
ご意見を踏まえて、中項目のリソース拡張性にネットワークの項目を追
加することを検討いたします。
「レベル２」欄の保守運用マニュアルは、通常運用の一部ではないでしょうか。
そう考えると「レベル１」欄のみでいい気がします。
67
68
69
70
71
72
73
項目一覧
項目一覧
項目一覧
項目一覧
樹系図
樹系図
樹系図
C.4.3.1
ご意見につきまして、運用マニュアルは業務運用に必要となるシステム
に対する操作をガイドするものであり、保守マニュアルは業務運用とは
直接関係しないシステムのメンテナンス作業に関する操作等をガイド
また、通常運用と保守運用を分けるのであれば、障害時の報告手順はどちらに含するものと考えています。ご意見の障害時の報告手順に関しては、運
まれるのでしょうか。
用マニュアルに記載するものと考えています。
移行作業の分担とリハーサルは重要項目と考えます。「重要項目」欄にチェックをご意見につきましては、2008年度に実施した「非機能要求グレード
してはどうでしょうか。
ユーザビュー検討委員会」において、「重要かもしれないが早々に決
められるものではない」というユーザ多数意見により、重要項目から外
す結論にいたりました。この結果を鑑み、本ご意見の対応については
D.5.1.1～
見送りといたします。経済産業省より公開中の『「非機能要求グレード
D.5.2.4
ユーザビュー検討委員会」報告書』　付録４の参照をお願いいたしま
す。
E.5.2.2
物理的な対策によるユーザ操作制限度のメトリクス（指標）として、次の項目を追加ご意見につきまして、想定する利用シーンを考えた場合、記述が詳細
すべきである。
すぎるため、現在の記述レベルとし、見送りとさせていただきます。
・重要な情報設備の、他の区画との明確な区別
・入退室記録の保存期間
・監視カメラの稼働時間
・監視映像保存期間
・警備員の常駐時間
防火に対する指標が必要ではないか
ご意見につきましては、「項目一覧」では、防火、防水ともに大項目「可
用性」内の中項目「災害対策」としてとしてまとめています。
「樹系図」ではなく「樹形図」とするのが一般的表記と思います。あえて「樹系図」と
表記する理由／こだわりを記述していただく方が読者／利用者に分かり易いと思
います。
＜参考＞Googleでのヒット件数
樹系図：29600件
樹形図：162000件
ご意見につきまして、「樹系図」は、「中項目」、「小項目」、「メトリクス」
の系統図で、検討順を表現したという趣旨で樹系図の用語を使用して
おります。
利用ガイド[解説編]の「FAQ」に説明を記述いたします。
縦か横かどちらかに様式を統一した方が見やすい
(慣れやすい)
ご意見を踏まえて、「樹系図」はA3横書きで統一いたします。
非機能要求の品質特性(Quality Attribute)や計測指標の分類と非機能要求を実
現する手段の分類が一つ樹系図に混在しており、CMU/SEIのATAMで用いられ
る"Quality Atrribure Characterizations(Stimuli-Architectural DecisionsResponses)" を応用した樹系図と解釈しましたが、表記法の凡例がないため読者
が正しく意味を解釈できない恐れがあります。
ご意見を踏まえて、「樹系図」において、樹系図の大項目、中項目、小
項目、メトリクス図形の凡例や活用方法などを記載したページを追加い
たします。
あわせて、利用ガイドにおきましても、凡例や樹系図自体の活用方法
について解説を追加いたします。
F4
全体
全体
全体
Copyright ©2010 システム基盤の発注者要求を見える化する非機能要求グレード検討会
付録 - 7/8
番号
ご意見の
対象
指摘
ページ
74
樹系図
全体
75
樹系図
全体
ご意見の内容
｢非機能要求グレード」への反映方針・考え方
項番を付記した方が、樹系図からグレード表、項目一覧へ導きやすい
76
77
78
79
樹系図
樹系図
樹系図
樹系図
全体
全体
重要項目か否か(グレード表の対象項目か否か)が一目でわかるよう、対象項目をご意見を踏まえて、重要項目には色づけをして、グレード表の対象項
色づけするなど識別がほしい
目かどうかが識別できるようにいたします。
一部の大項目表において、吹き出しの対象としている分類項目が項目一覧になく
統一感がない(混乱する)
※運用・保守性の「運用要件」「管理要件」、移行性の吹き出しのボックス、セキュ
リティの「セキュリティ管理」「セキュリティ機能」＋吹き出しのボックス、環境・エコロ
ジーの「環境条件(制約条件)」「設置容易性」
ご意見を踏まえて、「樹系図」の表現につきましては、凡例にない記述
はしないようにいたします。具体的には以下のように変更いたします。
・項目一覧にない分類項目名は使用しない
・空白のボックスは使用しない
「利用ガイド」に記載されている通り、閲覧性は高くなると思います。
が、実際に利用する際には、この項目から結局「項目一覧」を見なければ、どれを
検討するのか、また、決めるべき内容が分からないので、あまり活用はされないか
と思います。
ご意見を踏まえて、「樹系図」のメトリクスを表すボックスには、項番を記
述して、逆引きができるように改善します。また、重要項目には網掛け
をして、グレード表の対象項目かどうかが一目で識別できるようにいた
します。
「利用ガイド」に記載されているもう一つの目的である検討順ですが、「項目一覧」
にて上から順に並んでいる方が実施し易いかと思います。
非機能要件を定義する全体の手順は，樹形図の記述順，つまり，可用性→性能・
拡張性→保守運用性→移行性→セキュリティ→環境エコロジー
ということになるのでしょうか？大分類間の手順を示していただけるとわかりやすい
作業順番とと思います．
留意点の補
足
－
ご意見を踏まえて、「樹系図」のメトリクスを表すボックスには、項番を記
述するようにいたします。
ご意見につきましては、6大項目間における検討順序は、情報システム
が何を優先させているのかにも関係した内容になりますので、情報シ
ステムの優先順位が変わるとそれに伴って変化する性質をもっていま
す。従って、非機能要求グレードでは、大項目間の検討順序の規定は
していません。また、大項目間での検討順は、個別具体的案件の性質
によって決められたとしても、それぞれの要求項目を一旦決めた後に
整合性が取れているか、再度、確認のループを回すことが必要になり
ます。
項目一覧の閲覧性を高めるための位置付けとあるが、「調整が進んでいく順序」ご意見につきまして、分類構造としたのが項目一覧であり、検討順序を
で並べると構造的に樹系図で表すべきでない項目から成り立っているように見え例示したものが樹系図という考え方で整理しております。
る。単純に分類構造で示した方がわかりやすいのではないか。
可用性のツリーが、グレード表とマッピングしづらく、わかりにくい。「こうマッピングご意見を踏まえて、樹系図の凡例の記載とメトリクスには項番を追加い
されてますよ」という注釈があるとよい。
たします。
80
81
樹系図
樹系図
可用性
移行計画で、トラブル対処と一括りにするのではなく、例えば、切り戻しのタイミンご意見につきまして、切り戻しは、D.5.3.1のトラブル対処で取り決め
グやポイントなどがあるとよい。
て、D.1.1.1移行期間で期間をスケジュール化することで考えておりま
運用・保守性
す。
Copyright ©2010 システム基盤の発注者要求を見える化する非機能要求グレード検討会
付録 - 8/8

Download Report