あいまいな非機能要求を“見える化”する重要性
これまで述べてきたとおり、非機能要求の明確化に関する取り組みは2008年に始まった。非機能要求グレード検討会が発足したとき、もし本当にこのプロジェクトが予定通りに進んだら日本の情報システム開発の流れは大きく変わるのでは、と期待した人も多かっただろう。しかし、その意義と重要性はまだまだ世間に認知されていない。社会基盤としての情報システムがますます存在感を増すなかで、今あらためて再確認しておく必要があるだろう。
あらためて問いたい。なぜ、非機能要求の適切な設定はそんなにも難しいのだろうか。
まず、非機能要求は機能要求と異なり、要件定義書に体系的に記述しにくいということが挙げられる。機能要求の記述の合間に、非機能要求が散在していることも多く、しかもそのレベルも非常にあいまいだ。また、散在する非機能要求間に矛盾があり、一貫性を欠いているケースもよく見かける。そしてたいていの場合、非機能記述の根拠付け、優先順位付けができていない。「何を、どの程度、実現すればよいのか」——ここで発注側と受注側の大きな認識のズレが生じるのである。
もうひとつ、根源的な問題として、発注側と受注側のコミュニケーションの不足が挙げられる。本来、情報システム開発とは一企業のWebシステムから社会的基盤を構成する重要なITインフラに至るまで、発注側と受注側がともに開発に参加し、作り上げていくスタイルが望ましい。だが、そういう関係を構築することは非常に難しく、とくに発注側の顧客企業にITリテラシが不足している場合は、“丸投げ”状態になりやすく、受注側も細部を確認しにくいという事態が起こりやすい。
だが、今や情報システムは社会基盤の中核を成す重要な構成要素のひとつである。受発注者間で共通認識がもてないまま構築されたシステムは、社会不安を誘発する大きな要因になりかねないのだ。また、先にも挙げたとおり、非機能要求はハードウェアやOS、ミドルウェアといったシステム基盤に対する要求が多いため、業務アプリケーションへの要求が多い機能要求よりも、ある意味、細部に渡るまですり合わせを行っておくべきなのだ。
あいまいな言葉で語られがちな非機能要求を見える化／定量化することで、受発注者間のコミュニケーションを円滑にし、部門のシステムから社会性の高いシステムシステムまで、要求に応じた構築事例を増やす、ひいてはそのシステムをベースに高度な社会基盤を構築し、日本企業の競争力を高める——非機能要求を普及／促進させる意義はそこにある。
次回からは、非機能要求を適切に設定していくための具体的なポイントについて解説していきたい。
Keep up with ZDNet Japan
ZDNet JapanはFacebookページ、Twitter、RSS、Newsletter（メールマガジン）でも情報を配信しています。現在閲覧中の記事は、画面下部の「Meebo Bar」を通じてソーシャルメディアで共有できます。
