「要件定義を難しくする」とクローズアップされてきたのが“非機能要件”の存在である。非機能要件とは，性能や信頼性，拡張性，セキュリティなど，機能要件以外のもの全般を指す。これらはユーザーへのヒアリングからだけでは洗い出しにくい。漏れがあると，稼働後のトラブルの種になる。こうした事態を未然に防ぐ，非機能要件の見極め方を探る。

　旅行代理店のアールアンドシーツアーズは，今年10月末に予定しているホテル予約システムの稼働に向けて，今，開発の真っ最中だ。このシステムは，仕入れた航空券の在庫や宿泊の空室情報を管理するホストに，2次代理店からインターネット経由で送信されてくる予約データを受け渡すもの。

　開発を主導する大平雅義システム部長は，「機能要件はほぼ固まったが，性能に関する非機能要件が懸案として残っていて悩ましい」と語る。

　予約データはインターネットを介してやり取りされる。そこに含まれる顧客情報は暗号化が必須だが，SSL通信はサーバーの負荷を高くする。そこで，どの程度のレスポンスを確保すればよいのかがまだ見えていない。

　「今のところ性能は“欲求不満のない程度”としか考えていないが，顧客からクレームが入るようでは困る」（大平氏）という。あまり遅いようだとメッセージを暗号化すべきものとその必要がないものに分け，通信後にマージするなどの仕掛けを考える必要もあるかもしれない。大平氏は設計に影響を及ぼさないか心配している――。

非機能要件の漏れは後で判明する

　東京海上日動システムズで品質管理を担当していた菊島靖弘氏（現 アイネス 金融システム本部 副本部長）は，「“非機能要件”の存在が要件定義を難しくしている」と指摘する。非機能要件とは，ユーザーが望む機能要件を実現するために必要となるその他の要件の総称である。機能要件は主にユーザーへのヒアリングで洗い出すべきものだが，非機能要件は情報システム部門（またはITベンダー）側で洗い出さなければならないことが多い。

　図1は，人材紹介会社インテリジェンスが人材紹介システムの開発のために作成した要件定義書の目次である。「16．移行要件」から「20．キャパシティ要件」までが非機能要件に相当する。これらは一般に「システム要件」などと総称されることもある。

図1●機能要件と非機能要件 ユーザーにヒアリングしてもなかなか洗い出せないのが非機能要件。図はインテリジェンスが開発した人材紹介システムの要件定義書を基に作成

　このような非機能要件は，稼働後に漏れが判明するとシステム障害や新たなコスト負担をもたらしやすい。例えばERPパッケージをベースに会計システムを構築した住友林業は，要件定義時に「制度変更」への対応をあまり考慮しなかったことを反省し，システムを見直している。

　「会計制度の変更は本来パッケージのバージョンアップで対応できるはずなのだが，債権/債務モジュールは導入時にカスタマイズが多かった。バージョンアップしようとすると修正や検証の作業が膨れ上がる」（情報システム部 川大佑氏）。現行のシステムでは，制度変更に対応するのが困難になってしまうわけだ。2003年6月の稼働以来，幸いこれまで制度対応を迫られたことはなかったが，将来の運用のしやすさを見据えて債権/債務の部分を再構築する検討に入った。

　このような運用要件も非機能要件の一種と言える。後で苦労しないように，要件定義の段階で非機能要件をきちんと見極めよう。

◆何を洗い出すか？　性能や信頼性だけではない

　最近の環境の変化を考慮すると，菊島氏は「非機能要件は大きく3つに分けて整理できる」と話す。(1)狭義の非機能要件，(2)プロジェクト固有の要件，(3)既存システム・コネクティビティ要件，の3つである（図2）。(1)はユーザーが求める機能を安全にストレスなく使えるようにするための制約や条件を指し，「性能」「セキュリティ」「コンプライアンス」「特許」などが該当する。(2)は開発プロジェクト期間中に想定される環境の変化への事前対応で，「制度改正」「企業の体制変更」などがある。(3)はシステム開発により影響を受ける既存システムの修正点である。

図2●東京海上日動システムズが考える非機能要件 [画像のクリックで拡大表示]

　では，どのような理由でどのような非機能要件を，各現場担当者が洗い出したのか。あるいは事後的に気付いたのか。事例からピックアップして具体的に見ていこう。

【性能/キャパシティ】　具体的な数値として明示する

　「気にしていたのはサーバーのキャパシティだ。1999年に導入した旧システムは，2000年には既に個人旅行ブームを背景に容量不足の兆しが見えていた。2004年にはデータ量があまりに多くなり，レスポンスが極端に悪化する状態になっていた」。

　個人旅行予約システム（FITシステム）を刷新したATC日本旅遊の岡本裕氏（総務部 部長）はこう語る。FITシステムは海外からの個人旅行の注文を管理するもの。旧システムではディスク容量が慢性的に不足していて，古い不要なデータを手動で削除して容量を確保することもあった。

　FITシステムの再構築に当たって様々な要求が出ていたが，再構築の1次開発では，OSやミドルウエアのバージョンアップを含むキャパシティ増強を優先した。機能要件については，備考欄の文字数の制限撤廃や請求書のPDFファイル化など，簡単な修正で済むものだけを実装することにした。システム間連携によるデータの自動取り込みや，ホテルの宿泊在庫管理といった大掛かりな開発はすべて2次開発以降に回した。

　要件定義書には，性能に関して「登録処理が52秒以内に終了すること」などを盛り込んだ。かなり緩い要件に見えるが，これは予算の制約があったためである。「予算の範囲内で購入できるハードウエアでどの程度の処理性能が実現できるかを計算し，そこから逆算したものをユーザーに承認してもらうことにした」（開発を担当したエスエムジーの勝本秀之氏）。データ量が現状の2倍に増えると仮定しても，レスポンス・タイムは旧システムと比べて60％以上短縮できると試算した。

　2次開発で予定している宿泊などの在庫管理システムも，FITシステムと同じサーバー上に開発する予定だ。「サーバーの性能やキャパシティはそこまで考慮した上で設定した」（岡本氏）という。

【セキュリティ】　機能要件に波及することも

　非機能要件は，サーバーのサイジングやパラメータの設定変更といった比較的単純な作業にとどまらず，機能要件の見直しまで迫ることもある。清水建設の案件管理システムではセキュリティ要件が加わることで，一部の入力作業に特別な業務フローを追加する必要が出てきた。

　案件管理システムは，国内外の建設案件について，立地や仕様，担当者などの情報を一元的に管理するもの。各拠点のマネージャが，担当する案件に関する情報をリモートからログインして入力する。

　国内の案件は問題なく管理できたのだが，海外の現地法人が持つ案件をどう管理するかで問題が起きた。このシステムのユーザーは本社からの出向社員となるため，まず彼らにヒアリングした。すると，「発注企業担当者の連絡先など細かい項目は，現地採用の社員でなければ入力できないとのことだった。現地採用の社員にも新たにログインIDを与え，専用の画面を作れば済むと最初は考えた。しかし，調べてみると本社のセキュリティ・ポリシーで現地採用の社員に本社ネットワークへのログインIDを与えてはいけないことになっていた」（情報システム部 野田伊佐夫氏）。

　結局，現地採用の社員がログインせずにDBを更新できるよう，通常の業務フローとは別の業務フローを海外現地法人向けに用意した（図3）。

図3●清水建設が直面したセキュリティ要件の課題 国内外の建設案件の仕様を入力するシステムに「セキュリティ要件」が加わることで，特別な仕掛けが必要になった

　「このようなケースでは，エンドユーザーなど特定のステークホルダーに要件を深く聞いていくだけでは要件が漏れてしまう。システムに関連する様々な立場の人にヒアリングしたり，ルールを調べたりする必要がある」と野田氏は話す。