【徹底解説】非機能要件とは何かについて完全に理解する

こちらの記事では、非機能要件について解説します。非機能要件を知ることで、システムアーキテクトとしてのスキルを身につけましょう。

要件とは

非機能要件の解説前に、まずは要件とは何かについて解説します。

ITシステム開発における要件とは、実際に実現する事です。要件は、要求を基に定義します。

次に、ITシステム開発における要求とは、システムの買い手・利用者の「こういうことがしたい」という希望です。

ITシステム開発では様々な制約があります。金銭的な制約もあれば、納期の制約もあります。出てきた要求を全て実現できれば良いですが、制約によってはそれが無理なケースも多いです。

そのため要求を洗い出したら、そのあとは制約を踏まえて「実際に実現する事」を決める＝要件を決める必要があります。

要求・要件は、ビジネスレベル・業務レベル・システムレベルに分かれてそれぞれ定義されます。

ビジネスレベルでは、事業としての要求・要件を定義します。例えば売上や投資利益率を改善する等です。ビジネス要求を定義したら、制約を踏まえてビジネス要件を定義します。

業務レベルでは、ユーザーの行動レベルでの要求・要件を定義します。これは上記で定めたビジネス要件を達成するための要求・要件でなければなりません。例えば、売上の停滞理由は営業の客先訪問率の低さにあるが、営業は事務業務のとある箇所に時間を取られすぎて客先訪問に集中できないためその業務を効率化する等です。業務要求を定義したら、制約を踏まえて業務要件を定義します。

システムレベルでは、システムとして何をするかの要求・要件を定義します。これは上記で定めた業務要件を達成するための要求・要件でなければなりません。例えば、業務のとある箇所を改善するためにシステムでこういう機能を実現する等です。システム要求を定義したら、制約を踏まえてシステム要件を定義します。

非機能要件は、システム要件の一種です。

また、ここから先は単に「要求」「要件」と書いた場合、それぞれ「システム要求」「システム要件」を意味します。

非機能要件とは

要件は、機能要件と非機能要件に分かれます（要求もまた、機能要求と非機能要求に分けられます）。

機能要件とは、機能の要件です。今回解説する非機能要件とは、機能以外の要件です。

機能とは、ユーザーが実際に操作するものです。具体的に言えば、画面やCUI等のクライアントから実行可能な入出力操作です。

例えば「ユーザーは商品を注文できる」「ユーザーはディレクトリ移動を実行できる」等です。これらはユーザーの行為をサポートするため開発のコアな部分ですが、システムの要件としてはこれらを実現するだけでは不十分です。システムはそれ以外にも業務に耐えうる速度やセキュリティ等を備えなければなりませんが、これらが非機能要件に当たります。機能要件と非機能要件の違いは、「機能か、機能以外か」です。

非機能要件の実現方法

非機能要件の多くは、システムのインフラによって実現されます。

注意して欲しいのは、「多くは」であって「全て」ではないという点です。アプリケーションレベルで担保する非機能要件もあります。例えばセキュリティという非機能要件のためのサニタイズという処理がありますが、これはソースコードによって実現されます。

インフラエンジニアにとっての非機能要件

インフラはITシステムが動く大前提であると同時に、非機能要件の実現手段でもあります。

そのためインフラエンジニアは、最終的には個々のインフラ技術への習熟のみならず、非機能要件の実現のためにインフラ技術を設計できるようになる事が求められます。

学習初期段階から非機能要件を理解することで、何のためにインフラを設計するのかを押さえることができます。

非機能要求の一覧

前述した通り、要件は要求を基に定義されます。そのため非機能要求の全体像がわかれば、非機能要件の全体像もわかります。

非機能要求を一覧化してくれている資料として、IPA（Information-technology Promotion Agency, Japanの略。日本のソフトウェア分野における競争力の総合的な強化を図る独立行政法人）の非機能要求グレードがあります。（参照先：システム構築の上流工程強化（非機能要求グレード））

非機能要求グレードに準拠すれば非機能要求には大別6種類あり、これらは非機能要求グレードでは大項目と呼ばれます。これらは更に中項目、小項目、メトリクス（小項目の達成指標）とブレイクダウンされ詳細に定義されます。

この記事では大項目にスコープを絞って解説することで、まず全体像をつかむことを目指します。

可用性

可用性とは、システムが安定的に稼働し続けられる能力です。

システムはトラブルによりダウンするケースがありますが、それが頻発するとユーザーは困ります。そのため可用性という指標を設け、それを保証する必要があります。

可用性についてはEnvaderに別途解説記事があるため、詳細はそちらをご参照ください。（参照先：【わかりやすく解説】可用性とは？）

性能・拡張性

まずは性能と拡張性を各自解説します。

性能とは、サービス提供におけるリソース利用の効率性です。簡単に言えば、ITシステムのスピードです。

拡張性とは、リソース増強の容易性です。リソースとは、具体的に言えばハードウェアです。システム構築後しばらくすると、ユーザー数や保持データ量が増加することで、当初のリソースでは目標の性能を達成できなくなることがあります。後々この問題を解決するためには、あらかじめリソースを増強しやすくしておく必要があります。

非機能要求グレードにおける性能・拡張性は、字面に存在する上記の2概念を主軸としながらも、これらに影響を与える前提条件・予備条件が含まれる概念です。

これらが実用に耐えないものであれば、toCシステムであればユーザーの離脱を招くでしょうし、toBの業務システムであれば期限までに業務が終了しない可能性が出てしまいます。

運用・保守性

まずは運用と保守性を各自解説します。

運用とは、システムが日々問題なく動くようにすることです。つまりトラブルの監視・予防です。

保守とは、システムに問題が起きた時に対応することです。つまりトラブルの解決です。

非機能要求グレードにおける運用・保守性は、字面に存在する上記の2概念をどう行っていくかを主軸としながらも、それを容易にする運用環境やサポート体制や管理方針が含まれる概念です。

システムはリリース後も想定外の事象がほぼ必ず起きるものであるため、この要求・要件を定めておかなければ安定してサービスを提供することが難しくなります。

移行性

移行性は、現行システム資産の新システムへの移行方針です。

現行システム＝現在使用しているシステムを新たなシステムへ置き換えるには、様々なことを決めておく必要があります。移行対象はもちろん、実行時期や方式等です。

移行は検討すべきことが多く、なおかつ各システムにより具体的にやらなければならないことがかなり違うため、入念に検討しなければ新システムを想定通り稼働させることは難しくなります。

セキュリティ

セキュリティとは、構築対象システムの安全性です。

安全性保障のためにやらなければならないことは多岐に渡り、リスク分析や診断に始まり、アクセス制限やデータの秘匿や不正追跡・監視等を行うことになります。

適切なセキュリティ対策が講じられていない場合、システムの破壊や情報の流出等が生じて社会的・経済的損失が発生し得ます。

システム環境・エコロジー

まずはシステム環境とエコロジーを各自解説します。

システム環境とは、実務的な制約条件です。システムに関する法令や、利用者数や拠点数、ハードウェアの制約事項等です。

エコロジーとは、自然・労働環境についての制約条件です。例えば自然環境の制約とはCO2排出量やエネルギー消費効率等で、労働環境であれば機器の発する騒音です。

これらの対応に失敗していると、国の規制に対応できず稼動が法的に許容されなかったり、近隣労働者の騒音被害に発展し得ます。

専門家の責務としての暗黙の要件

契約の仕方にもよりますが、システム開発プロジェクトのゴールは、要件定義で定めた要件を達成することです。それゆえお客様が発注したシステムを外部の人間＝受注者が開発する場合は、受注者の責務の一つは開発したシステムが要件を達成できているか否かにあります。逆に言えば、要件としてないものは受注者は対応しなくともよいのが基本です。要件はお客様が出す注文内容である以上はお客様が基本的に責任を持つということです。

しかし、一定レベルの要件については、仮にそれが要件定義段階で要件として挙がっていなくとも受注者は専門家としての暗黙の責務として対応しておく必要があり得ます。

SQLインジェクションというシステム攻撃手法があります。画面等のインターフェイスにSQL文を入力して利用することで、画面を介して任意のSQL文を実行しDBのデータの取得や改ざんを行う手法です。このSQLインジェクション対策は、セキュリティという非機能要件への対応ということになるでしょうが、これが要件とされておらず対策されていなかったために攻撃を受けたケースにおいて、受注者側の責任とする判決が下されたことがあります。この裁判についてはセキュリティ専門家として著名な徳丸氏のブログ記事で詳細に論じられています。

https://blog.tokumaru.org/2015/01/sql.html

どこまでが専門家としての暗黙の責務であるのかというのは明確な線引きがないのが現状だと思われますが、上記判決の根拠として、経産省・IPAが当該脆弱性についての警告を発していたことを採用しているのが一つの基準点となると思われます。専門家であるならばこれらの公的な情報はチェックし対策していることは当然という見解でしょう。

この事件はセキュリティに限られた話であり、セキュリティ問題による損害は他の要件よりも深刻なものになる可能性が高いため、他の要件についても同じように過失が認められるとは一概には言えません。しかし、お客様は基本的にはシステムのプロではない以上、機能要件はもちろん、目に見えない部分である非機能要件についてはなおさら受注者がシステムの専門家としてリードしていかなくては実現されないことの方が多くなってしまいがちです。

専門家として、非機能要求・要件の全体像を押さえ、お客様に提案し、システムの総合的な品質を保証できることを目指しましょう。