非機能要件とは？機能要件との違いや非機能要件の設計手法まで解説
初めて担当する上流工程。
上司からいきなり「非機能要件を設計して欲しい」と指示されたら、あなたは真っ先に何を思いますか？
「機能じゃない（機能に非らずな）要件なんてあるのか？」
正直、こんな疑問が思い浮かぶのではないでしょうか？
非機能要件とは、システムを構築するに当たり、性能面やセキュリティ面等において実現するべき要件であり、顧客が潜在的に持っている「隠れた要件」のことです。
機能要件と違い、顧客が明確に意識している要件ではないため、設計するためには、地道で根気のいるヒアリングが必要不可欠です。
その代わり、非機能要件が実現されれば、顧客満足度もシステムの完成度も一気にアップし、更には、非機能要件設計をやりきったあなたに対する上司の評価もアップするという、大事でお得な要件なのです。
ここでは、非機能要件を初めて設計する人に向けて、その概要についての説明と、非機能要件を顧客から引き出すために大事ないくつかのポイントについて、お話しようと思います。
目次
１．「機能ではない」要件とは一体何か？
非機能要件とは、文字通り「機能以外」の要件を指します。ここで言う「機能」とは、顧客が持つ「要望」とほぼ同義と考えてよいでしょう。
「今までメールで申請していた社内手続きをWEBシステム化したい。」
これが顧客要望であり、大雑把な機能要件です。
それに対して、「画面が表示されるまでの待ち時間は3秒以内」や「障害復旧時は、障害発生時点とすべて同じ状態に戻して欲しい。」、「全社員が一斉にアクセスしても、システムがダウンしないようにして欲しい。」等、性能面を始めとするシステムの安心・安全を実現するために必要な要件が「非機能要件」なのです。
機能要件を「表向きの要件」と表現するのであれば、非機能要件は「裏向きな要件」と言えるでしょう。
２．顧客要望は大きくふたつに分類できる
ITエンジニアの大切な仕事は、顧客要望を実現することです。前章にも書きましたが、顧客要望には、「表向きの要件」と「裏向きな要件」が存在します。この章では、ふたつの要件の違いについて、もう少し深堀りして説明していきます。
２-１．顧客の表向きの要件（機能要件）
「今までメールで申請していた社内手続きをWEBシステム化したい。」
前章で、上記のような顧客要望が「機能要件」であると説明しました。
顧客がそこそこ大きい規模の企業の場合、顧客要望書や提案依頼書(RFP)等により、ある程度まとまった形での要望を提示して頂ける場合もありますが、顧客が中小企業の場合は、こちらから顧客にヒアリングして、顧客要望を実現できる形にまとめる必要があります。
そして、ヒアリングした結果、顧客側から出てくる要望は、以下のような事柄が多いのではないかと思います。
- スマホやPCから社内手続きの申請ができるようにしたい。
- 申請があったら、担当者にメールで通知したい。
- 申請内容は、社員別にデータベースに登録して検索できるようにしたい。
- 申請が今どこまで進んでいるか、進捗状況を確認できるような画面が欲しい。
- 申請承認したら、申請者に自動的にメール通知したい。
- etc…
お気づきかと思いますが、これはすべて目に見える機能についての顧客要望です。そして、性能面やセキュリティ面についての要望を自発的に口にする顧客は、なかなかいないものです。
もちろん上記のような顧客要望も、基本設計、詳細設計を行う上では、とても重要な情報です。しかし、この裏に隠れて、システムを安心、安全に稼働するために、更に重要な情報を明らかにする必要があります。
それが、次に説明する「非機能要件」です。
２-２．顧客の裏向きの要件（非機能要件）
２-２-１．「非機能要件」とは？
「非機能要件」とは、前章でも説明したように、顧客の目に見える要件の裏に隠れた「機能要件以外の要件」のことです。
例えば、高機能で画面UIも優れた社内手続きの申請システムを開発したとしても、画面が表示されるまでの時間が遅かったり、システムの運用時間が極端に短かったりすると、当然顧客満足度は低くなるでしょう。
反対に、画面表示の時間も早く、使い勝手のよい運用条件を定義することができれば、顧客満足度のアップに繋がります。
「非機能要件」とは、システムが安心、安全に稼働するためには「あって当然」「普通に動いて当然」と、顧客が無意識のうちに思っている、言ってみれば、システム上の「縁の下の力持ち」的な要件であり、システムに必要不可欠な「質」の部分を支える要件なのです。
それでは、「非機能要件」とは、具体的にどのような項目を指すのでしょうか。
２-２-２．「非機能要件」の設計項目
「非機能要件」の設計項目としては、「ISO/IEC 9126(JIS X 0126)」や「FURPS+」といった世界的にも有名なものもありますが、本稿では、「IPA（独立行政法人情報処理推進機構）」が提唱する「非機能要件の６大項目」をベースとして、非機能要件設計を説明したいと思います。
「IPA（独立行政法人情報処理推進機構）」を、聞き覚えがない団体だなと思う人もいるかもしれません。ですが、「情報処理技術者試験」の運営を行っている団体と言えば、「あぁ！」と納得されるのではないでしょうか。（「IPA（独立行政法人情報処理推進機構）」は、以降「IPA」と表記します。）
IPAの「非機能要件の６大項目」をベースとして設計を行う理由は、簡単です。顧客に対して説得力があるからです。日本の情報システムに携わる人間で、「情報処理技術者試験」を知らない人はほぼいないでしょう。その試験を運営する団体が提唱する非機能要件項目に従って設計します、という設計方針は、顧客への説得力や納得感を高めます。
IPAでは、非機能要件設計のために「非機能要求グレード」というツール群を公開しています。その中で定義されている「非機能要求グレードの６大項目」は、下表の通りです。
非機能要件設計は、この６つのカテゴリに分けられた項目に従って、構築するシステムの身の丈に合った要件を定義する必要があります。
「身の丈に合った」と申し上げたのは、上の６つのカテゴリで定義された非機能要件をすべて盛り込むと、大抵予算と合わなくなってしまうためです。
どこまでの範囲の非機能要件を、自分たちが構築するシステムに含めるのか判断しなければならないという点が、非機能要件設計を難しいと思わせている要因の一つではないかと思います。
そこで必要となってくるのが、非機能要件を設計するための「指標」や「評価基準」であり、IPAが公開している「非機能要求グレード2018」のツール群なのです。
だって、こんな微細な項目、ゼロから全部考えるの嫌でしょう？(笑)
参考URL
- 非機能要求グレード2018 (IPA)：非機能要求グレードの解説とツール群のダウンロードページ
- ｢経営に活かすIT投資の最適化」読本（IPA）：非機能要件をストーリー仕立てでわかりやすく
３．「非機能要件」の指標（ＲＡＳＩＳ）と評価基準（ＳＬＡ/ＳＬＯ）
「非機能要件」とは何かがわかってきたところで、いよいよ「非機能要件」の設計についてのお話です。
前章では「非機能要求グレードの６大項目」を表で示しましたが、具体的にどのような項目をどのくらいの指標値で表したらよいのか、まだ迷うところが多々あると思います。
本章では、「非機能要件」設計大事な指標となる「ＲＡＳＩＳ」と、「非機能要件」設計の評価基準である、「ＳＬＡ」「ＳＬＯ」について説明します。
これから「非機能要件」設計を行うに当たり、考慮すべき指標や評価基準についての理解を深めていきましょう。
３-１．「ＲＡＳＩＳ」
「ＲＡＳＩＳ」とは、非機能要件に特化した指標ではなく、コンピュータシステムのサービス全般に関する指標基準のひとつで、以下の５項目の頭文字を取って表現されるものです。指標値を計算により表すことができる、先頭の３項目のみ取って「ＲＡＳ」と表現する場合もあります。
日本語項目を見て、前章で挙げた「非機能要求グレードの６大項目」と重複するものが多いことに、気がついた方もいると思います。
「非機能要求グレードの６大項目」も「ＲＡＳＩＳ」も、システムの機能部分が問題なく動作するか否かを判断するために必要な基盤要素、という点では共通するからです。
どちらも非機能要件を設計する上では考慮するべき性能指標であり、大事な設計要素なのです。
３-２．「ＳＬＡ」
「ＳＬＡ」とは「Service Level Agreement」の頭文字を取ったもので、「サービスレベル契約」のことです。「サービスレベル契約」は、サービスを提供する事業者と契約者の間で交わされる契約であり、事業者が提供するサービスの内容や性能基準を、どの程度のレベルまで保証するかについて、明文化したものです。
「契約」と付くからには、もちろん守るべき約束事であり、違反すればペナルティが課せられる場合もあります。ペナルティの条件や内容についても、両者合意の上「ＳＬＡ」に記載されます。
「ＳＬＡ」として記載される内容の一例を、以下にいくつか挙げてみます。
- 可用性とアップタイム（サービス提供時間の内、実際にユーザーがサービスを利用できる時間の割合）
- 様々なレベルの問題に対するヘルプデスクの回答までの時間
- アプリケーションの応答時間
- ネットワーク設計の変更についてユーザーに事前通知を行うタイミング
- 稼動統計情報（ユーザーに定期的に情報開示を行う）
- 性能のベンチマーク値（実際に測定した性能値と定期的に比較を行う）
サービスを提供する事業者は、「ＳＬＡ」を策定することによって、顧客の期待を明示的に管理できると共に、サービス障害や性能低下に関する免責事項についても明示することができます。
一方、契約者としての顧客も、サービス障害発生時の損害賠償等について、契約として明示化できるというメリットがあります。
３-３．「ＳＬＯ」
「ＳＬＡ」に対応して、「ＳＬＯ」という用語があります。
「ＳＬＯ」とは「Service Level Objects」の頭文字を取ったもので、「サービスレベル項目(目標)」のことです。
「サービスレベル項目(目標)」は、「ＳＬＡ」で顧客と合意した契約内容に対して、それを達成するための具体的な評価基準や指標値や目標を示します。
例えば、前項で「ＳＬＡ」の一例として挙げた「様々なレベルの問題に対するヘルプデスクの回答までの時間」に対する「ＳＬＯ」は、「電話着信から回答までの時間3分以内の達成率80%以上」等です。
もちろん上記はあくまでも一例であり、「ＳＬＡ」に対する「ＳＬＯ」は、それぞれのシステムに適した目標値を設定する必要があります。
「非機能要件」設計は、これら「ＳＬＡ」「ＳＬＯ」を達成するためには、どのような性能を維持、運用していけば良いのかを定義する、とても大事な作業なのです。「非機能要件」で取り決めた基準が「ＳＬＡ」「ＳＬＯ」の目標達成に至らなければ、「契約違反」としてペナルティになってしまうかもしれないのですから。
４．「非機能要件」の設計手法
「非機能要件」を設計するに当たり、IPAの「非機能要求グレード2018」のツール群を使用することについては、2章でご説明した通りです。その設計手法について、ここでは簡単に手順の流れだけを記載します。
まずは、設計手順の流れをしっかり把握してください。
(1) 設計対象のシステムが、以下の３つのモデルシステムの中のどれに該当するかを選択し、システムの方向性や規模、特徴を確認します。
- 社会的影響がほとんどないシステム
- 社会的影響が限定されるシステム
- 社会的影響が極めて大きいシステム
(2) (1)で選択したモデルシステムを元に、コストや品質に関する重要項目、92項目を定めたグレード表を用いて、推奨される要求レベルの値（0 – 5）を確認し、システムの規模や予算、顧客要望に合わせて推奨値を調整します。
それによって、システムに必要なコストや品質についての基本方針が明確になります。
(3) 重要項目以外についても、項目一覧から非機能要求項目のレベルを選択し、推奨値を確認、調整します。
そして、最後に最も重要なことは、(1)～(3)で定義したすべての非機能要件項目について、
顧客と調整し、合意を得ることです。
なお、詳細な手順については、「非機能要求グレード 2018」の「利用ガイド[利用編]」に詳しい説明がありますので、そちらをご確認ください。（以下の「◆参考URL」を参照）
参照URL
- 非機能要求グレード2018 (IPA)：非機能要求グレードの利用手順とツール群のダウンロードページ
５．顧客から「非機能要件」を引き出すための４つのポイント
本章では、顧客から「非機能要件」という隠れた要求を引き出すためのポイントについて、４つご紹介します。
「非機能要件」設計を行う際の、大事な心構えとして覚えておいてくださいね。
５-１．「非機能要件」の提案はこちらから。顧客主体で「非機能要件」は出てこない。
最初にはっきり申し上げておきますが、「非機能要件」は顧客から出てくるのを待つのではなく、サービス提供者である、こちら側から提案する必要があります。顧客側から自発的に「非機能要件」を提示してくることは、ほぼ100%ないと思ってください。
顧客側の担当者がシステムに詳しい人の場合は、要件定義の段階から「非機能要件」について言及して来る場合もありますが、そんなラッキーは滅多にありません。
2章でも説明したように、「非機能要件」とは、顧客が普段意識していない「縁の下」に隠れている「基盤上の機能」なのです。
システムの専門家であるこちら側から、「非機能要件」とはこういうことを決める必要があります、と提案することによって、「非機能要件」に対する顧客側の意識もグンと表面化し、システム提供側と顧客側の認識齟齬を防ぐことができます。
５-２．「非機能要件」は図に描いた方が伝わりやすい
「非機能要件」の提案資料や設計書を作成する場合には、図表多めを心がけましょう。
ITエンジニアには、顧客説明の際に難しい専門用語を使いたがる、という不思議な傾向があります。「非機能要件」は、システム基盤寄りの機能なので、ただでさえ難しい用語が頻出します。
難しい用語を連ねてグダグダと説明するよりは、ポンチ絵1つで図示化した方が、顧客にははるかに伝わりやすく、また図示化することによって認識齟齬もありません。そして何より、説明する側も図に対する補足説明だけで済むので、難しいことをくどくど説明しないで済みます。
以下に、負荷分散装置の冗長化について、説明文だけの場合と図示化した場合の例を挙げてみます。どちらが顧客により理解されやすいのか、一目瞭然なのがご理解いただけると思います。
✦説明文だけの場合
✦図示化した場合
５-３．提案は松・竹・梅のメリデメ表を提示しよう
「非機能要件」を検討する際に、いくつかある提案の中からひとつを決定する必要がある場合は、「松」「竹」「梅」の３案に対するメリット、・デメリットを記載した表を顧客に提示して、その中からひとつを顧客に選択してもらうようにしましょう。
３案のメリット・デメリットについて、一目で確認できる表のことを「メリデメ表(メリット・デメリット表の略)」と呼びます。（顧客によっては、別の呼び方をすることもあります。）
「松」「竹」「梅」の並び順については、オススメ順、予算がかかる順等があり、特に「こうあるべき」と決められたものはありません。ただ、傾向として人は特上の「松」よりも、真ん中の「竹」を選択することが多いようです。
こちら側のイチ推しをあえて「松」ではなく「竹」に持ってくるという戦略も有りかと思います。そして、デメリットについては、各案隠すことなく明確に提示するようにしましょう。
デメリットを「レアケースだから」「起こるはずがないから」と隠しておいたことによって、後々隠していたデメリットが発覚し、致命的な問題に発展することもあるのです。
５-４．決定権はあくまで顧客側にあることを忘れない
そして、最後に重要なことは、「非機能要件」に対する決定権は、あくまで顧客側にある、ということを忘れないことです。
メリデメ表を作成していると、「これは「竹」を選択するしかないな」と確信する場合もありますが、そこで「竹しかありません」とゴリ押しする提案は、スマートではありません。
何故なら、あなたがこのシステムの決定権を握っているわけでもなく、開発予算を管理しているわけでもないからです。それでも、「竹」を選択しないと絶対的にマズいという場合には、決してゴリ押しするのではなく、顧客が「竹」を選択するようにうまく誘導しましょう。
そこが、コミュニケーション力の高いITエンジニアの「腕の見せ所」です。
たとえ口での説明が上手くないとしても、メリデメ表のうしろに、推奨案とその根拠について、熱量高めな説明文で語ってみる、という手もあります。コミュニケーション力とは、決して「口で上手く語る」だけの能力ではないはずです。
関連記事
６．まとめ
「機能要件」も「非機能要件」も、顧客が実現したい要件であることに、何ら変わりはありません。
そして、「機能要件」よりも顧客の意識に上りにくい「非機能要件」を設計することは、確かに一筋縄にはいかず、手間も多くかかる作業です。ですが、「非機能要件」をしっかり設計することができれば、以下のようなメリットもあるのです。
- システムとしての堅牢性も信頼度も上がるため、顧客からの信頼度も上がる。
- 「非機能要件」設計という難しい要件設計をやりきった、あなたに対する上司からの評価も急上昇。
「機能要件」の設計に比べて、裏向きで地味な設計ですが、顧客の隠れた要望をヒアリングによって引き出し、それを機能として現実のものにできるということは、「顧客要望を実現する」というITエンジニアの仕事の醍醐味ではないでしょうか。
かなり「Ｍっ気」要素が強めな醍醐味ですけど（笑）
コメント