非機能要件は，ユーザーの要求からは出てきにくい。エスエムジーの小森裕介氏（オブジェクトフレームワークディヴィジョン テクニカルコンサルタント）は「経験上，非機能要件の中でも，許容できるダウンタイムや操作性などはユーザーから比較的出てきやすい。しかし，信頼性や性能は意識的にヒアリングしないとあまり出てこない。拡張性に関してはほとんど出てこない」と指摘する。そのため情報システム部門側で主導的に洗い出す。ここからは事例を基にそのプロセスを見ていこう。

◆どう洗い出すか？　ひな型を使い漏れ防止

要件をテンプレート化しておく

　非機能要件は機能要件と異なり，項目レベルで業種や業務による違いが少ない。「性能」「保守性」「拡張性」「セキュリティ」など，どのシステムでも同じような項目が並ぶ。そこでエスエムジーは要件定義のテンプレートを用意し，非機能要件として洗い出すべき項目を列挙した。SEはその項目を埋めればよい形にしてある。

　図5は，実際のテンプレートと，それに基づき作成したATC日本旅遊のための要件定義書の抜粋である。テンプレートには，「ハードウエア，ソフトウエアともに二重化構成の形態とし，通常は稼働系・待機系のホットスタンバイ運用を行い…」など，書き方のサンプルが載っている。SEは案件ごとにカスタマイズして「HDDの障害には3台のHDDによるRAID5構成を導入する…」などと記載すればよい。

図5●エスエムジーが用意している非機能要件のテンプレートとATC日本旅遊の宿泊予約システムにおける記入例
図5●エスエムジーが用意している非機能要件のテンプレートとATC日本旅遊の宿泊予約システムにおける記入例
 非機能要件の項目をテンプレート化しておくと漏れを防げる
 [画像のクリックで拡大表示]

　テンプレートの項目は，細分化しておくほど実際の案件を手掛けるときの作業が楽になる。電通国際情報サービスには，Webシステムを対象にセキュリティ要件の漏れを無くすことを目的としたセキュリティ・レビュー・ボード（SRB）という品質管理のグループがある。ここで，受注する案件のセキュリティ要件を確認するための「SRBチェックシート」を用意している。チェックシートには，「重要情報を格納する変数が共有される場合，排他制御が適切に行われているか」といったレベルまでブレークダウンして書かれている。

　プロジェクト担当者は項目ごとに「○」「×」「該当無し」「未定」「質問の意味が分からない」を記入することで漏れを無くす。項目にはそれぞれ重要度が設定されており，「特に必須項目については○になるよう設計するのが原則。×になるなら，少なくともリスクを認識した上で対策を考えておく必要がある」（事業推進本部 開発技術センター 技術第3グループ 統括マネージャー 田中靖紀氏）。

　チェックシートには，難易レベルの異なる3種類が用意されている。最も簡易なレベル1は，プロジェクト・マネージャがセルフチェックすればよい。レベル2～3はSRBのメンバーによるチェックが必要となる。どのレベルのチェックシートを使うかはデータの重要度など案件により判断する。

項目を埋めるプロセスを決める

　テンプレートの各項目を埋める作業は，機能要件と同じくヒアリングが基本である。ただし，機能要件がユーザーの要求を正しく引き出すことを主とするのに対し，非機能要件は情報システム部門側またはベンダー側からユーザーに提案し，それを承認してもらうというプロセスが主となる。また，性能やセキュリティの制約から機能要件の修正を求めるものがあれば，その代替案を提示する。

　図6左は，人材紹介会社インテリジェンスのユーザー部門に対して日本IBMが障害対策要件に関するヒアリングを実施した際の議事録である。

図6●インテリジェンスが人材紹介システムの開発時に実施したミーティングから要件定義につながる流れ
図6●インテリジェンスが人材紹介システムの開発時に実施したミーティングから要件定義につながる流れ
 ミーティングで具体的な内容を洗い出す
 [画像のクリックで拡大表示]

　要件定義のディスカッションにはインテリジェンス側と日本IBM側から数人ずつが参加し，週3回のペースで15回程度開催された。1回のディスカッションは約3時間である。ディスカッションは日本IBM側が提起した課題について主に話し合う。

　インテリジェンス側の承認を得て文書化したものが，図6右の要件定義書である。議事録と正対するような形でまとめられているのが分かる。

　ヒアリングの方法にも工夫がある。エスエムジーの小森氏は「“どの程度の性能が必要か”と聞いてもユーザーは普通答えられない。Webシステムなら何人くらいが使うか，監視システムなら装置の数が何台くらいになるか，というように具体的に聞いていく」という。また，操作性であれば「どんな人が使うかを聞く。パソコンのリテラシーの低そうな人がユーザーなら，プルダウンはなるべく使用しない，などと判断する」（小森氏）という。

　清水建設では，機能要件を洗い出した段階で集中検討会という場を設けて，非機能要件の漏れを埋める活動を行っている。集中検討会に参加するのは，各ステークホルダーの代表。ここでは，設計するに当たり欠けている情報や懸案となっている事項をベンダーがあらかじめピックアップしておき，まとめて合意形成を図るのである。懸案事項には機能要件も含まれているが，性能やキャパシティ，セキュリティなど非機能要件全般が検討されることが多いという。

いつも同じ内容の要件はルール化

　非機能要件の種類によっては，結果としてどの案件でも同じような内容で埋まることがある。このような非機能要件は，テンプレート化するよりも設計ルール（標準）として定義してしまうほうがよい。

　日本コムシスは，すべての社内システムに共通する設計/運用ルールを設定している。例えば，全アプリケーションで画面の構成や表示の順番を統一することで，操作性に関する非機能要件が満たされるようにしている。

　図7は同社の施工システムの画面だ。ルールには，画面を上下の2つに分けることや，各画面内のボタンの配置，プルダウンの表示の順番などがルールとして定義されている。「営業や人事，財務など，どの部門のシステムもルック＆フィールを変えていない。同じルールを適用しているからだ」（藤本氏）。

図7●日本コムシスが取り組んでいる操作性の標準化の具体例
図7●日本コムシスが取り組んでいる操作性の標準化の具体例
 [画像のクリックで拡大表示]

　日本コムシスの社内システムは，営業，人事，施工，財務，グループウエアなどがあり，情報システム部門にそれぞれ担当者が数人ずついる。運用ルールは各システムの担当者の中から人を出して構成する共通化プロジェクトなどの場で決められる。

　システムごとに要件が共通なら，このルールを開発のフレームワークに組み込んでしまうことも可能だ。電通国際情報サービスは，前述のSRBチェックシートに記載したセキュリティ要件を，自社開発のフレームワーク「DFORCE!)」へ組み込む作業を進めている。URL直接指定のページ・アクセス，クロスサイト・スクリプティング，パスワード再表示，SQLインジェクションなどはフレームワークで対策済みとなっている。