「 IPA非機能要求グレード」を基に、非機能要求の効果的な検討と管理のプロセスを解説！
非機能要求/要件の適切な決定と管理は、ITシステムの調達過程において、システム発注者（以下「発注者」という。）側が直面する最も重要かつ複雑な課題の一つです。特に公共性の高いシステムであれば、国民生活に直接影響を及ぼすため、開発や運用には高い信頼性と安全性が求められますし、災害等が起こった時であっても事業の継続性が求められます。 しかし、非機能要求/要件は抽象的で、定量化が難しいことや、プロジェクトの初期段階で適切に考慮することが難しいという課題があります。
そこで、本記事では、非機能を定義する際に参考となるガイドラインの中から、情報処理推進機構（以下「IPA」という。）が提供する「非機能要求グレード」を基に、非機能要求の効果的な検討と管理のプロセスを紹介していきます。
目次
１．非機能要求/要件の基礎知識
1-1. 非機能要求と非機能要件
まず、「非機能要求」と「非機能要件」という表現の違いについて解説します。 非機能要件は発注者側、事業者等側の双方の協力によって決定されていくものですが、前提として発注者側の業務担当部門や情報システム部門で検討した非機能要求が明確になっている必要があります。２つの違いについては、以下のように表現ができます。
- 非機能要求
・重要項目に絞って要求を詳細に決める
・要求レベルには幅があることがある（製品仕様やコストを踏まえて決めるべく、詳細決定は先送りする） - 非機能要件
・事業者等からの提案や情報提供を受けながら、コストや実現難易度も踏まえて要件として具体化する
※詳しくは、こちらをご参照ください。
本記事は、発注者側で非機能要求を検討するプロセスについて紹介しています。
1-2. 非機能要件の重要性
まず、非機能要件には、大きく以下の２つの要件があります。
- システム要件
システムやサービスがどのように動作するかを定義するもの - 委託要件
外部の会社に実施してもらいたい業務を委託する内容を指しているもの
システム要件は、システムの機能要件とは異なり、可用性、性能/拡張性、運用/保守性、移行性、セキュリティなどの品質特性を規定します。
委託要件は、特定のタスクや業務が外部委託される際の品質やパフォーマンスの基準を設定する際に重要になります。政府が提供するデジタル・ガバメント推進標準ガイドラインでは、特に公共セクターのIT調達における委託要件を網羅しています。
こうした非機能要件が適切に管理されないと、パフォーマンスの低下、セキュリティリスクの増大、さらにはプロジェクト全体の失敗につながる可能性があります。そのため、非機能要件はIT調達プロジェクトにおける成功の鍵を握る重要な要素といえます。発注者は、非機能要件が重要な要素であることを意識して、その前提にあたる非機能要求をプロジェクトに合わせて適切に検討し、管理することが求められます。
本記事は、非機能要求検討のための方法の一つである、IPAの非機能要求グレードを基にしていますが、非機能要求グレードは、上記２つの要件のうち、システム要件の部分を具体化するためのツールとなります。
次章以降では、この非機能要求グレードの活用方法について、詳しく紹介していきます。
２． IPA非機能要求グレードの概要
2-1. IPAと非機能要求グレードの概要
IPAは、情報技術に関する研究、開発、普及活動を行う日本の独立行政法人です。IPAは、ITプロジェクトにおける非機能要求の特定と管理を支援するためのガイドライン「非機能要求グレード」を提供しています。
非機能要求グレードのフレームワークにより、プロジェクトの目的やニーズに基づいて、各非機能要求項目に対する要求レベルを設定することができます。
出典：独立行政法人情報処理推進機構(2018年4月)「非機能要求グレード2018利用ガイド[解説編]」 P11 図1.4.2.1 非機能要求グレードの概要と全体イメージ
2-2. 非機能要求グレードのメリットと活用
まず、非機能要求グレードを活用することによる主なメリットについて紹介します。
- 要求の明確化
プロジェクトの目的やニーズに合わせた非機能要求の検討により、プロジェクトの進行がスムーズになり、最終的に高い品質のシステムの実現につながります。 - コミュニケーションの向上
発注者と事業者等との間で非機能要求レベルに関する共通の理解を築くことができます。それにより、その後の要件定義における漏れや誤解を防ぎ、プロジェクトのリスクを低減することにつながります。 - リスクの低減
非機能要求レベルの事前の特定と明確化により、プロジェクト途中での要件変更や誤解によるリスクを最小限に抑えることができます。また、要求に基づく適切な技術選定により、システムの品質と信頼性向上につながります。
続いて、非機能要求グレードを効果的に活用するためのプロセスについて紹介します。
- プロジェクトの目的・目標の確認
プロジェクトの目的や達成したい目標を明確にします。 - 定義すべき非機能要求項目の絞込み
非機能要求グレードのフレームワークにある多数の非機能要求項目の中から、そのプロジェクトにおいて重視する必要がある非機能要求項目を絞込みます。 - 要求レベルの設定
絞り込んだ各非機能要求項目に対して、達成すべきレベルを設定します。 - 文書化と共有
検討した各非機能要求項目のレベルを文書化し、プロジェクト関係者と共有します。
発注者はIPAの非機能要求グレードのフレームワークを活用することで、プロジェクトの目的・目標に合致した高い品質と信頼性のシステムの実現を目指すことができるようになります。
それでは次に、非機能要求検討プロセスの詳細について紹介します。
３．発注者による非機能要求検討のプロセス詳細
非機能要求を特定する際は、プロジェクトの目的・目標、利用者のニーズ、社会的影響、予算などを総合的に考慮し、それに基づいて定義すべき非機能要求項目を絞り込み、優先順位を決定したうえで、要求レベルを設定することが必要です。非機能については、技術的な要素もあり、発注者だけで決めることは難しいため、事業者側と共同で決めていく場合もあるかもしれません。ただし、要求段階では基本的に発注者側だけで非機能要求項目の絞込みから要求レベルの設定までを行うことになります。
また、非機能要求の特定プロセスでは「冗長化などの可用性の向上とコスト増大」「セキュリティの強化とユーザの利便性低下」のようなトレードオフが発生することがあることに留意し、レベル設定を行う必要があります。
3-1. 定義すべき非機能要求項目の絞込みの方法
まず、定義すべき非機能要求項目の絞込みのための最初のステップとして発注者側が行う主な内容を以下に示します。
- ニーズの分析
プロジェクトの目的や目標、ニーズを詳細に分析し、それに対応する非機能要求項目を洗い出します。 - 初期情報収集
RFIの実施や事業者等とコミュニケーションをとることで、製品やサービスに求める要件や調達条件などを決定するために必要な情報を収集します。
続いて、集めた情報等から定義すべき非機能要求項目の検討を行います。「非機能要求グレード」にある非機能要求項目の中から絞り込む形で検討を行うと、定義すべき非機能要求項目の検討を進めやすくなります。
3-2. 優先順位付けの方法
定義すべき非機能要求項目の絞込みを行ったら、続いて優先順位付けを行います。優先順位付けを行う理由は、非機能要求を全て同時に満たすことは現実的ではないため、最も重要な要求項目から順に対処する戦略を立てる必要があるためです。
非機能要求項目を評価し優先順位を付けるには、各非機能要求項目のプロジェクト目標に対する重要度、システム全体に及ぼす影響度、および技術的な制約や予算といった観点での実現可能性を分析します。
3-3. 要求レベルの設定
優先順位付けを行ったら、続いて要求レベルの設定を行います。要求レベルの設定では、プロジェクトの目標・目的、技術的制約、予算などを考慮しながら、優先順位の高い要求項目から順に、必要なレベルの設定を行います。
要求レベルはプロジェクトの目標・目的が達成されるために不可欠な指標で、定期的な見直しの基準として機能します。そのため、ガイドラインのレベルをそのまま適用するだけでなく、プロジェクトに即した達成可能なレベルを設定することが重要です。
3-4. IPAの非機能要求グレードの具体的な利用方法
ではIPAの非機能要求グレードを活用した定義すべき非機能要求項目の特定と優先順位付け及び要求レベルの設定はどうなるのかについて紹介します。「IPAの非機能要求グレードの利用方法」では、下図の手順を紹介しています。
出典：独立行政法人情報処理推進機構(2023年8月時点)「システム構築の上流工程強化（非機能要求グレード）紹介ページ」 ，https://www.ipa.go.jp/sec/softwareengineering/std/ent03-b.html
①モデルシステムの選定
プロジェクトに最も近いモデルシステムを、プロジェクトの規模や業種、システムの種類などに基づいて「社会的影響がほとんど無いシステム」「社会的影響が限定されるシステム」「社会的影響が極めて大きいシステム」から選択します。選択したモデルシステムはプロジェクトの非機能要求の基準となります。
例えば、災害情報を配信するシステムであれば、予期せぬ災害時に確実に動く必要があり、住民への情報提供という重要性を考慮すると「社会的影響が極めて大きいシステム」となります。
出典：独立行政法人情報処理推進機構(2018年4月)「非機能要求グレード2018利用ガイド[解説編]」 P14 図2.1.1.1 モデルシステムの定義
②重要項目のレベル設定
選定したモデルシステムに基づき、プロジェクトの目的やビジネスニーズに最も影響を与える重要な非機能要求項目を特定し、それらの要求レベルを設定します。
例えば、災害情報を配信するシステムであれば、稼働時間などの可用性、災害時にも情報配信できるような耐障害性や個人情報保護のセキュリティを重要項目として特定します。特定した項目に対して、システムの目的と重要性に応じた適切な要求レベルを、グレード表を参考に設定します。この際、最高レベルの要求を一律に適用するのではなく、各項目の具体的な状況とプロジェクトの要件を考慮して、必要なレベルを決定します。これにより、システムが災害時においても効率的かる信頼性高く機能するようにします。
③重要項目以外のレベル設定
重要項目のレベル設定が完了したら、残りの非機能要求項目についてもレベル設定を行います。
例えば、災害情報を配信するシステムであれば、住民の操作性を意識したユーザビリティ、大量アクセスを想定した高い処理能力などの性能や、今後のサービス拡張へ対応できるような拡張性を特定します。これら特定した項目は、プロジェクトの予算やスケジュール、技術的な制約を考慮しつつ、適切なレベルを設定します。
出典：独立行政法人情報処理推進機構(2018年4月)「非機能要求グレード2018利用ガイド[解説編]」 P16 図2.1.1.3 グレード表の例（全体）
具体的な例をあげてみましたが、非機能要求グレードでは200以上の指標があり、その全てを詳細に検討するのは非常に手間がかかります。また、指標の中には、複数の大項目に該当しているものもあります。そのため、プロジェクトにおいてどの項目が重要であるのかを考え、詳細に検討する必要がある項目を絞り込む使い方が現実的となります。
さらに、非機能要求グレードのグレード表と項目一覧は、発注者の環境や対象となるシステムによっては検討不要となる項目も出てくることが想定されます。その場合には検討しない理由を文書化しておく等、管理を適切に行う必要があります。
以上のような非機能要求の特定プロセスは、プロジェクトの目標達成に向けて行う重要なタスクです。適切な要求項目の特定とレベルの設定を行うことで、求めているシステムの実現が可能となります。
４．非機能要求の文書化の重要性
非機能要求検討の最後のプロセスとして、非機能要求の文書化があります。 第３章までで行った、定義すべき非機能要求項目の絞込みや優先順位付け、IPAのグレードを用いた場合であれば決定したレベルの結果を含めることが重要です。 その文書化においてIPAの活用シートを利用することが有効になります。
文書化を行うことで、この後の非機能要件を決定するステップにおける事業者等との明確なコミュニケーションを確保し、プロジェクトの進行における誤解を防ぐことが可能となります。 また、達成基準や検証方法を明記し、開発フェーズとテストフェーズの両方で非機能要件が適切に管理されるようにすることも可能となり、発注者と事業者等の双方で認識のずれが起きないようにすることに有効となります。
まとめ
IT調達プロジェクトにおいて、非機能要求の効果的な決定と文書化は、その後の非機能要件を決定することだけでなく、プロジェクトの成功に大きく寄与することがお分かり頂けたでしょうか。
本記事ではIPAの非機能要求グレードを基にした紹介を行いましたが、その他にも非機能要求に関するガイドラインがありますので、こうしたガイドラインを活用し、非機能要求の決定、その後の事業者側と協力しながらの非機能要件の検討を適切に行い、システムの品質向上を目指してください。
IT調達ナビの運営会社である株式会社グローバル・パートナーズ・テクノロジー（GPTech）は、システム導入における、「システム発注側」の支援に特化したコンサルティングファームです。
システム導入・刷新に向けて、進め方や体制等でお困りの場合は、ぜひ一度弊社までご相談ください。
この記事の編集者
銭場 啓太
大学卒業後、東京都特別区職員として13年勤務。ケースワーカー、徴税吏員を歴任後、滞納管理システム担当を2年、情報システム部門に５年従事。業務システム運用の他、グループウェアの刷新、自治体システム標準化やガバメントクラウド移行を担当する。業務の中で、発注者側の強化の必要性を感じ、発注者を支援していきたいという思いから（株）グローバル・パートナーズ・テクノロジーに中途入社。主に公共部門の業務支援に従事しつつ、IT調達ナビでシステム発注に役立つ記事を展開するメディア運営業務にも携わる。
