PR

非機能要件の定義

2020年7月14日(火)
梅田 弘之(うめだ ひろゆき)

はじめに

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

非機能要件(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コマースサイトを請け負うことのできるベンダであれば、さすがにこれらを記載しなくても大丈夫だと思いますが、何が起こるか分からないので、それでも非機能要件として提示しておくことに越したことはありません。

<<麻里ちゃんの設計奮闘記>>非機能要件は誰が定義するの?
  • 麻里こうやって表2を見ると、非機能要件って、RFP(提案依頼書)に断片的に書いてある程度しか見たことがないわ。
  • 先輩:ちょっと軽視されているのかなぁ。これが悪いとユーザーニーズを満たさなくなるのに、きちんと定義されていないことが多いいんだ。
  • 麻里機能さえ正しく動けばバグじゃないっていう風潮があるから?
  • 先輩:うん、その古くさい考え方がまだ根強く残っているかも。でも、これ、まずは発注者が意識改革しないとね。機能要件ばかりで、必要な非機能要件をきちんと定義していないことが多いからね。
  • 麻里請負側は、要件があいまいだと都合の良い方に解釈しがちですものね。
  • 先輩:まあ、それもあるけど、請負側では判断が付かないってこともあるよ。非機能要件には正解があるわけでなく、ユーザーの要求品質の程度で決まるってところも難しいところかな。
  • 麻里ユーザーの要求品質の程度?
  • 先輩:ふふ、久しぶりにオウム返しの反応がきたな(にやにや)。非機能要件は贅沢を言えばきりがない。だから、これはここまでで妥協できる、これはここまでは必要、というように最低限必要な水準をきちんと示す責任があるんだ。
  • 麻里なるほど。示さなかった要件は、(こちらの)常識以下になる可能性もあるってことか…。そのリスクを分かっていたら、必要な要件は漏れなく定義しようと思いますね。
  • 先輩:そう。だから漏れがないようにチェックリストを使って、あらかじめ委託サイドの内部で要件を決めておく作業が大事になる。できれば要件定義に入る前のRFP提示段階でやれると良い。要件定義に入ってからだと予算オーバーとなってしまうかも知れないからね。
  • 麻里本来は、請負側も提案時に非機能要件を一通り確認すべきなのだけど、機能ばかり質問・確認して非機能の方はおろそかになっているかも…。
  • 先輩:業界のバックアップも期待したいかな。JUASは発注者側の立場だから、いち早く「非機能要求仕様ガイドライン 2008」を作って公開してくれたけど、その後の改訂版は出ていない。IPAは8年ぶりに更新して「非機能要求グレード 2018」を誰でも参照できるように出してくれたから、これをより現場で使えるようにして欲しいね。
  • 麻里ユーザビリティなんかも基準を作ると良いかも。ユーザビリティの良さを5段階にして、最低レベル3以上というのを発注の条件にする。それだけで、行政サービスの使い勝手も大幅に増すと思うわ。
  • 先輩:お、それ良いアイデアだね。
  • 麻里当社のユーザビリティエンジニアに基準作ってもらおうかしら…。
  • 先輩:あれ、自分がやるってことじゃないんだぁ。

おわりに

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

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

著者
梅田 弘之(うめだ ひろゆき)
株式会社システムインテグレータ

東芝、SCSKを経て1995年に株式会社システムインテグレータを設立し、現在、代表取締役社長。2006年東証マザーズ、2014年東証第一部上場。

前職で日本最初のERP「ProActive」を作った後に独立し、日本初のECパッケージ「SI Web Shopping」や開発支援ツール「SI Object Browser」を開発・リリース。日本初のWebベースのERP「GRANDIT」をコンソーシアム方式で開発し、統合型プロジェクト管理システム「SI Object Browser PM」、アプリケーション設計のCADツール「SI Object Browser Designer」など、独創的なアイデアの製品を次々とリリース。最近は、AIを利用したサービスに取り組んでいる。

主な著書に「Oracle8入門」シリーズや「SQL Server7.0徹底入門」、「実践SQL」などのRDBMS系、「グラス片手にデータベース設計入門」シリーズや「パッケージから学ぶ4大分野の業務知識」などの業務知識系、「実践!プロジェクト管理入門」シリーズ、「統合型プロジェクト管理のススメ」などのプロジェクト管理系、最近ではThink ITの連載をまとめた「これからのSIerの話をしよう」「エンジニアなら知っておきたいAIのキホン」を刊行。

「日本のITの近代化」と「日本のITを世界に」の2つのテーマをライフワークに掲げている。

連載バックナンバー

Think IT会員サービス無料登録受付中

Think ITでは、より付加価値の高いコンテンツを会員サービスとして提供しています。会員登録を済ませてThink ITのWebサイトにログインすることでさまざまな限定特典を入手できるようになります。

Think IT会員サービスの概要とメリットをチェック

他にもこの記事が読まれています