第44回　ひ・・・非機能に　基盤もアプリも　要注意

　性能や可用性といった要素を非機能要件と呼ぶ。要素間のトレードオフが多く、決めにくいが、システム基盤だけでなくアプリケーションまで配慮して、バランスの取れた形にまとめ上げるのはITアーキテクトの腕の見せ所でもある。

　システム開発では利用者が「実現したいこと」を要求（Requests/needs/wants）と呼ぶ。要求を実現するために「実装しなければならないこと」を要件（Requirement）と呼び、要件は業務運営に必要な機能要件と、非機能要件に二分される。

　そもそも要求はコストや期間、利用する製品や開発言語といった諸々の制約を含んでいる。この制約を前提に、プロジェクトマネジャーはQCD（品質、コスト、納期）の視点で、ITアーキテクトはシステム構造の視点でそれぞれ責任を持つ。もちろんシステム構造の善し悪しはQCDに影響を与える。

　機能要件定義が不十分だったために、開発が中断したり手戻りが多発して納期が遅れるといったトラブルはよく聞く。だが、使われないシステムが出来上がるのは非機能要件定義やその検証が不十分な場合が多い。

　また「機能要件はアプリケーションで実装して非機能要件はインフラで実装する」「非機能要件は決めるのが難しい」「非機能要件とは『ソフトウエアの出来ばえを評価する品質特性モデル』である」ともよく耳にする。これは勘違いといえる。どこが勘違いなのかを考えながらぜひ読んでほしい。

非機能要求グレードを活用

　事務系システムは、人間だけでやっていた仕事をシステムと人間で分担して効率を高めるために構築する。事務規程や業務フロー、伝票や台帳などを基にシステムに必要な機能を洗い出していくため、一般的に機能要件は分かりやすい。伝票はシステムの画面や帳票に、台帳はデータベース、事務規程は業務ロジック、業務フローは画面遷移に近い概念であり、業務機能として「何を」システムで実現するかが明確だからだろう。