非機能要件の定義

はじめに

本連載も、今回で最終回となります。これまでは機能設計書を中心に解説してきましたが、最終回は非機能要件について解説します。非機能要件という言葉を聞いたことはあるかも知れませんが、カバー範囲が広いためどのようなことなのか説明するのがちょっと難しかったりします。でも、実は機能要件に引けを取らないほど重要なので、最後にきっちりお伝えしていきます。

非機能要件(non-functional requirement)とは

非機能要件(NFR)とは、ソフトウェア設計のうち機能面以外の要件すべてを指します。“機能以外”のためその含むところが大きく、それゆえきちんと定義されずにシステム開発されているケースも多いです。そして、それが原因で完成したシステムが使い物にならないこともままあります。

パフォーマンスが悪くて作業効率が悪化した、セキュリティに欠陥があり情報漏洩した、デザインが悪くて売れない、使い勝手が悪くユーザーから不満が出ている、システムが不安定で時々落ちる、拡張性がなくて我慢して使っている、などの問題はどれも非機能要件が満たされていないためです。機能要件だけでは満足なシステムにならず、非機能要件という品質属性が備わって始めてシステムは機能するのです。

非機能要件で定義する項目

「機能以外はすべて非機能要件」になるので、非機能要件で定義する項目は多岐にわたります。そのため、何を定義すれば良いかが不明瞭で、きちんと定義せずにシステムを作ってしまい、稼働してから大きなトラブルになりやすい。そのあたりが非機能要件の難しいところです。

定義を明確にしようという試みもなされています。もう10年以上も前になりますが、一般社団法人日本情報システム・ユーザー協会(JUAS)が2年間かけて230項目の非機能要件を整理し、その成果を「非機能要求仕様ガイドライン 2008」として出版しました。このガイドラインでは非機能要件を図1の左の10項目にまとめ、それぞれについてどのような内容を定義、検証するか書かれています。

図1：非機能要件で定義する項目

続いて、独立行政法人情報処理推進機構(IPA)が、国内SI事業者6社の協力の元2010年に「非機能要求グレード」をまとめています。こちらは2018年に更新されており、IPAのホームページよりダウンロードできます。

非機能要求グレードでは、非機能要件を図1中央の6つの大項目にカテゴリー分けしています。各項目でどのような要件を定義するのかは、ダウンロード資料「01_利用ガイド解説編.pdf」の表3.1.2.1を読めばイメージしやすいでしょう。これを表1に引用します。

表1：非機能要求グレードの6大項目
【出典】非機能要求グレード2018 利用ガイド [解説編] 表1.3.2.1 (p.7) より

非機能要件チェックリスト

非機能要件は、すべて明確に定義しなければならないものでもありません。システムによっては項目が該当しないものもありますし、「暗黙の了解」「常識の範囲」といった“阿吽の呼吸”で要件を記述しなくても合格レベルのシステムが出来上がることもあるでしょう。しかし、大事な非機能要件が漏れていたために、システムが完成してから大きな問題として発覚することも少なくありません。そのような漏れを起こさないためには、非機能要件チェックリストが役に立ちます。チェックリストを作成しておき、システムの企画段階で確認することで、大事な要件を定義し忘れるようなミスが防げるのです。

チェックリストは、IPAの大項目に沿ったものでも良いのですが、ここでは表2のように少し細かなメッシュでチェックリストを作ってみました。各項目にどのような内容を記載するかイメージしやすいように、チェック項目やチェック要素(ファクター)のほかにeコマース(オンラインショッピング)サイトの記入例を入れています。実際は、もっと具体的で詳細な内容を記載するため表に収まるような分量ではありませんが、みなさんがシステムの非機能要件を定義する際に参考にしてください(個人的好みでいくつかの項目はカタカナにしています)。

表2：非機能要件チェックリストのサンプル

非機能要件の記述ポイント

表2に示す非機能要件について少し説明しましょう。

(1)アベイラビリティ(可用性)

どの程度のアベイラビリティが要求されるかを定義します。もちろん、どんなシステムでも可用性が高いほど良いわけですが、要求が高ければコストも高くなります。そのためシステムの委託者側が必要レベルを伝えることは大切です。例えば、一般企業の基幹業務であれば、システムダウンしてもバックアップから戻せれば良いと割り切れるでしょう。一方、この例のようにeコマースサイトの場合は、24時間364時間稼働が原則です。完全冗長化構成でメンテナンス時も停止しないことを求め、さらに災害発生時にもダウンタイムを最小にしたいならその旨を記載する必要があります。

(2)パフォーマンスとスケーラビリティ(拡張性)

本番稼働してみたが、遅くて実用に耐えられず大クレームになった。eコマースサイトだけでなく、こうしたことは日常茶飯事です。東京オリンピックのチケット申込みサイトも当初重くて不満の声が殺到しましたが、このようなトラブルが発生するのは非機能要件をきちんと定義していなかったり、本番前のテストが不十分だったりするからです。

また、稼働当初は問題なかったのに、稼働後3か月くらいでシステムが遅くなってユーザーの使い勝手を著しく低下させることもよくあります。開発サイドからすると「そんなに増加するとは聞いてなかった」というわけですが、最初からデータ量やユーザー数がどれくらい増加するか示していれば責任は開発側に移ります。そのため、開発側もきちんとスケーラビリティを考えてプラットフォームやシステム構成を企画・設計するので、こうしたトラブルが起こりにくくなるのです。

なお、今回用意したチェックリストでは確認・検証方法という欄を設けています。非機能要件は、ともすると言いっぱなし、聞きっぱなしで済ましてしまい、本番稼働後にトラブルが発覚するケースが非常に多いのが特徴です。それを防止するためには、どのようなツールやテストによって要件が満たされていることを担保するか、という点まで定義するのが効果的なのです。

(3)メンテナンス性(保守性)と運用性

Webサイトや社内システムで「システムメンテナンスのため、明日の3時から6時までサイトを止めます」というようなアナウンスをよく目にします。メンテナンスである程度のダウンタイムを認めても良いシステムならば、コスト削減のために割り切るのは当然です。ただし、その場合でも、どの程度までメンテナンスのための停止を許容できるかを非機能要件に記載した方が間違いはないです。一方、メンテナンスの際でもシステムを連続運転させて欲しい場合は、その旨を非機能要件に明記し、ホットスタンバイなどの仕組みを用意することになります。

運用に関しては自動と手動を含めてさらに要件が幅広いです。例えばeコマースサイトの場合、サイトが止まるような障害が発生すると、販売機会損失になるだけでなくサイトの信頼も落としてしまいます(有名サイトならニュースになったりもします)。

異常発生アラートが拾えるのなら、エラーメッセージでスマホのアラームを鳴らすなどの対策も取りやすいのですが、メモリを使い切ったような場合は異常メッセージを出すことなく静かに固まっているだけで気づかないこともあります。それを防止するため、定期的にサーバーなどの死活監視をする仕組みを入れて欲しいなら、非機能要件に「死活監視」と書いておく必要があります。

(4)ユーザビリティ

パフォーマンスやスケーラビリティは数値で表しやすいですが、ユーザビリティはユーザー(人間)の感覚的なものなので要件として定義しにくいです。そのためユーザビリティはドキュメントに明記されないことが多いのですが、一方で現代のシステムはユーザビリティがとても重要視されています。

行政サービス系のシステムで恐ろしいほどユーザビリティが悪いものが多いのは、なぜでしょうか。それは発注者がユーザビリティに知見も関心もないまま大手SIerに丸投げしているからでしょう。請け負った側にもプロとしての自覚が足りないように思います。ユーザーに年配者が多いというペルソナ(想定ユーザー)も考えず、動けば良いと言わんばかりの使いにくいものを開発して検収さえ通れば任務終了です。その結果、泣きを見るのが一般ユーザーという図式になるのです。

一方、eコマースサイトにとってユーザビリティは死活問題です。ユーザーが不満を抱くようなサイトは客足がめっきり落ちますし、ユーザーを迷子にしてしまったら機会損失につながります。そのため、eコマースサイトの発注者はいろいろな競合サイトのUIを調べ、受託者もこれまでに蓄えた経験をぶつけて、双方の協力の元でユーザビリティの良いサイトが完成するのです。

牽制の意味も含めて、非機能要件としてユーザビリティを記載しておくことは重要です。例えばペルソナとして「20～30代のスマホで購入する女性が多い」と書けば、パソコンよりもスマホでの購入を第一に考えてくれることが期待できます。そして、スマホでは全角と半角を間違い易いので、電話番号やメールアドレスが全角で入力されてもエラーとせず黙って半角変換して通すような処理を入れてくれるわけです。

また、これはまだ世の中にスタンダードなものがないのですが、ユーザビリティの基準のようなものを作っておき、その水準をクリアすることを非機能要件とするのも効果的です。実は当社でも「ユーザビリティガイド」を作成していて、プロンプト(ガイドやラベル、書式など)やアイコン、インテリセンス、パンくずリストなど現代のシステムに合ったユーザビリティに関してまとめてあります。当社の場合は、請負側としての責任でこれらの資料を作成・運用していますが、このようなものを委託者側がユーザビリティを意識し、用意しておく必要があると思います。

(5)効果目標

情報システムに投資すると判断したからには、当然ながら投資に見合う効果を期待しています。しかし、思うような効果が得られなかったとしても、通常、それは委託者側の問題で開発側に責任を持たすことはできません。

そのため、委託者がシステムの目的までは記載したとしても、期待する効果を数値で明確に示すことはあまりありません。しかし、開発側に責任を持ってもらえないとしても、期待する効果を書いて共有することは無駄ではありません。定量的が望ましいですが、難しければ定性的でも良いです。例えば、上記の行政サービスの開発を委託する際に、期待される効果として「高齢者でも迷わずに利用でき、多くの人がお役所に行かずに済むようになる」と書いてあったとしましょう。エンジニアは基本的に善良でまじめなので、それだけで劣悪なユーザビリティはだいぶ減るのではないかと思います。

(6)技術・環境要件と規制要件

プラットフォームや採用する技術などは、通常、きちんと書かれています。稼働後のメンテナンス要員の関係で開発言語やRDBMSまで指定するかはケースバイケースでしょうが、クラウドかオンプレミスか、利用したいツールやシステム、既存システムとの関連性などは重要なポイントなので要件として書かれるのが普通です。

一方で、法律などの規制要件は記述されていないことが多いように思います。例えば、eコマースに関わる法律として「特定商取引に関する法律」と「個人方法保護法」があります。eコマースサイトを請け負うことのできるベンダであれば、さすがにこれらを記載しなくても大丈夫だと思いますが、何が起こるか分からないので、それでも非機能要件として提示しておくことに越したことはありません。

おわりに

本連載では、これまで機能仕様書の書き方や標準化をテーマに解説をしてきましたが、もう1つ大事なことを忘れていたことに気づいて、最終回で非機能要件について取り上げました。非機能要件は、機能要件と比べて定義や事例、テンプレート化などが遅れているので、麻里ちゃんではないですが誰かが積極的に取りまとめて進化させてくれると良いなぁと思っています。

さて、本連載も今回で終了です。長い間、お付き合いありがとうございました。日本のIT業界の進化と発展、そして自分自身のために頑張っていきましょう！