システム構築のイロハの「イ」と呼べるのが、システムに対する「要求」である。要求は大きく「機能要求」と「非機能要求」がある。

 機能要求は、業務要求と言い換えられ、エンドユーザーがシステムを利用して業務を行う上で必要な要求を指す。例えば顧客情報システムであれば、顧客名や住所などを登録できること、それらが検索できる機能を持つことなどが機能要求である。

 非機能要求は、機能要求以外にシステムに対して必要な性能などを指す。非機能要求は、技術系(技術要求)と運用系(運用要求)に分類できる。

 技術系の非機能要求で代表的なのは、レスポンスタイムなどのパフォーマンスだ。いくら業務上必要な機能を満たしていても、クリックして画面が切り替わるまで1分もかかっていてはエンドユーザーが仕事にならない。ネットワークに関する要求、障害対策、セキュリティ対策などもある。運用系の非機能要求としては、システムの利用時間の設定や、保守に関する要求などが主なものである。

 この非機能要求は、以前からシステムに対する重要な要求であったが、昨今のクラウドを利用したシステム開発では、特にコスト算出に影響する事柄として適切な洗い出しが求められている。ところが、実際のプロジェクトでは二つの理由で、非機能要求が軽視されてしまうケースが少なくない。

 一つめの理由は、RFP(提案依頼書)作成や要件定義の作業は、機能要求の洗い出しから行うためだ。どのような機能を実装するかによって、必要な性能が変わってくるので、非機能要求を後に回すことになる。

 非機能要求を後にやる理由をそこまで明確に意識せず、「普通はそうだから」と疑問を持たずにやってしまうケースも多い。スケジュールが押してくると、なおさら洗い出しや整理といった作業を端折ることになる。

 もう一つの理由は、誰が非機能要求を決めるのかがはっきりしないことだ。本来であれば、情報システム部門が機能要求をきちんと理解した上で、非機能要求を仕切るべきである。しかし、特に技術が日進月歩であるため、情報システム部門がそれをすべてキャッチアップするのは困難になってきている。技術系の情報は、ベンダーのほうが持っているので、そこはむしろ頼ってよいのではないか。

 ただし、運用系の要求に影響する事象については、発注者側がきちんと洗い出しをして、備えるべきである。例えば玩具関連のECサイトであれば、クリスマスの時期に通常の20倍以上のアクセスがある、といった運用上の課題についてデータを用いてベンダーに示すことが必要だ。もちろん正確な洗い出しができればそれに越したことはない。だが、多少間違っていてもクラウドなどのサービスの利用においては、比較的簡単に調整が利く。

 大事なのは、発注者が非機能要求を一度きちんと取りまとめ、それをベンダーと協議することだ。それをせずに「丸投げ」すると、運用開始の段階で想定のコストを大幅に超えるトラブルが発生しかねない。仮説レベルであっても構わないので、発注者は運用イメージを想定すべきである。