非機能要求はいちゃもん？

非機能要求って？

ここで機能要求とは対象システムの機能に関する要求のことです。つまり普段言っているところの要求です。普通の機能やサービスのことです。動詞句の「〇〇〇する」の〇〇〇に該当するものが機能です。

非機能要求はこの機能要求以外の諸々の要求を指します。普通の要求以外の要求なので、聞き手から見れば、いちゃもんのように聞こえる場合も少しだけ、いえ、多くあります。

非機能要求は「魅力的品質」を保証するための要求でしたが、今は「当たり前品質」のように考えているユーザが多いです。まさにいちゃもんです。

非機能要求には、たとえば「可用性」があります。可用性とはつまり、それが使えるかどうかということです。まさにこれは、いちゃもんです。言われた通りの機能を作っているのにも関わらず、それが使い物になるかどうかでいちゃもんを言ってくるのです。怖いです。

非機能要求のいろいろ（非機能要求グレード）

非機能要求は機能要求以外なので、いろいろとあります。それこそユーザの数だけあります。ユーザはいちゃもんをいう生き物ですから（個人の感想です）。

IPAの「非機能要求グレード」に、非機能要求の分類が紹介されています。この非機能要求グレードでは６個のカテゴリとして、(1) 可用性、(2) 性能・拡張性、(3) 運用・保守性、(4) 移行性、(5) セキュリティ、(6) システム環境・エコロジーがあります。そしてこのカテゴリに対して、239個のメトリクス（評価基準）が紹介されています。

非機能要求グレードを少し紹介すると、これは富士通などの6社で制定し、その後IPAに移管されています。非機能要求グレードでは、モデルシステムシート、グレード表、項目一覧、樹形図などがありますので、要求分析でお困りの方はぜひご覧ください（以上、宣伝終わり）。

(1)の可用性は使えるかどうかでしたが、(2) の性能・拡張性は名前の通りで、性能や拡張面でユーザが納得するかどうかです。性能は既に非機能）（魅力的品質）と言うより、機能（当たり前品質）の一部になっているような、うるさい要求になっています。

(3) の運用・保守性は、ものを作って終わりという話（要求）ではなく、運用こそがシステムの価値という考えの下、重要な品質になっています。それゆえ、これも厳しい要求になっています。ここではDevOpsで対応するというのはお互いの幸福、win-winになるでしょう。

(4) の移行性は、最近ではシステム移行よりもデータ移行が重要になってきています。データが他のシステムに移行できるようにデータ設計とその運用はもはや、当たり前になっています。ということでこれも厳しい要求です。

(5) のセキュリティは、これこそが最近の要求の最大のものです。この要求を満たさないとお金が出ません。一番厳しい要求です。・・・逆に言えば、金になる要求です。

(6) のシステム環境・エコロジーはこれから強くなる要求です。SDGsなどが企業方針になる時代なので、また生成AIでは大量の電気を使い、大量のCO2を排出しますので、世間の目は厳しいものになっていくでしょう。

非機能要求を軽視する悲劇

これまで非機能要求を軽視すると大変な目に会います。今は昔、品質が欠陥がないこととしていた1970年代とは違い、機能要求中心だった1980年代とは違い、非機能要求が注目され、重要視されるようになってきた1980年代から1990年代、そして21世紀になると非機能要求に関する物語が語られるようになってきました。

非機能要求を真面目にしないと、非機能に関する検討漏れが出てきて、仕様に曖昧さが残り、ユーザとの齟齬が生じ、解決弛緩性への見通しが不明になります。時間も必要になり、解決方法も不明の闇の世界になります。

ゆめゆめ、非機能要求を軽視せずに、コストを掛けて、非機能要求を実現します。

ステークホルダ問題

非機能要求において、最大の問題は非機能要求を出すステークホルダに関する問題があります。これは非機能だけでなく機能要求でも同じことが言える問題です。

この問題は相反するステークホルダが複数人いるときに起こります。機能要求では比較的相反することはないのですが、非機能要求では相反することになりがちです。

この理由は非機能要求が精神的な、感覚的な要求が含まれていて、定量的に数字で表現しにくいということから起こります。IPAの非機能要求グレードではなるべく定量化するようにしていますが、それでも定性的な要求になりがちです。

この問題を解決するには高度な政治的納涼力、統治能力、管理能力が必要です。これこそが非機能スキルです。

今日の一言「非機能はステークホルダを狙え」以上です。