非機能要求の提示はユーザー企業の仕事！？
ここまで見てきたとおり、事業コンセプトと非機能要求を一致させることは、発注者であるユーザー企業が主体となって行うべき作業だということができるだろう。だが実際には、「（非機能要求の詳細を）どう提示してよいかわからない」という理由から、開発ベンダーに要求の決定さえも丸投げしているケースも非常に多く存在する。ユーザー企業の期待レベルを把握できないまま作成された要件定義書に従ったシステムがどういうものになるのか、想像に難くない。
今回、某国内大手建設企業の情報システム部門の責任者の方（本稿ではA氏とさせていただく）に、非機能要求を中心とする要件定義のあり方についてお話を伺う機会を得た。数々の社内システム案件を手がけてきたA氏は、きっぱりと「超上流（※1）も含め要件定義はユーザー企業の仕事」と言い切る。
※1：IPAが定義する概念に「超上流」というプロセスがある。一般に上流と言われるプロセスのさらに上流にあたり、システム化の方向性や要件定義について「超上流から攻めるIT化の原理原則17ヶ条（PDF）」でまとめられている。
「ユーザー企業にとって重要なのは、モノ（システム）を作り上げることではなく、モノ（システム）により実現される事業（業務）を構築すること。そして単にシステムを構築するだけでなく、テスト、移行、運用など、それぞれの段階でモノを動かすためには何が必要なのか、何を準備すべきなのか、上流の段階でしっかり洗い出す必要がある」とA氏。「開発ベンダーは、ユーザー企業から提示された要求を“どう実現するか”という点にフォーカスしてほしい。また、ベンダーはシステムに求められる要求をきっちり確認すること。あいまいな点を残したまま開発工程に入ることは絶対に避けるべき」と強調する。また情報システム部門としては、システムを必要とする業務部門に対し、責任範囲を明確にする、求める非機能要求を明確にするといった姿勢を徹底している。「たとえば“前日からシステムが止まっている場合、…”などと書かれていたら、“前日というのは24時間前か、それとも前日の業務開始時間からか”といったことをはっきりさせる。またプロジェクトに入る前には必ず業務部門と情報システム部門のそれぞれの責任者を明記し、役割分担と責任を明確にしている」（A氏）
非機能要求グレードについてA氏は「システム発注の基本的なフレームワークとしてはよくまとまっていると思う。ただしこのままでは弊社では使えない。非機能要求グレードは、どちらかというと社会的影響が大きいシステムの構築を前提にしているような感がある。弊社のような建設会社は（通信事業者の携帯電話システムのような）社会の根幹を成すほどのクリティカルな情報システム基盤はないので、非機能要求グレードの3つあるモデルシステムのうち、2つしか使えないことになる」と評価する。ユーザー企業がこれを使いこなすには、ある程度のカスタマイズがどうしても必要になるとのことだ。
また、非機能要求グレードは、ユーザー企業からみると物足りないと感じるところがいくつかあるという。たとえば移行案件に伴い、新しくユーザーを教育する必要が生じたとする。だが教育やトレーニングというプロセスは非機能要求グレードには含まれておらず、開発ベンダーも「それはプロジェクト要件」という考え方だ。一方でA氏は「“モノをつつがなく動かす”ためには、たとえば教育やトレーニングは欠かせないプロセス。ユーザー企業にとっては非機能要求そのもの」と語る。
「ユーザー企業の情報システム部門は、事業コンセプトを実現するシステムを作るなら覚悟をもってあたってほしい。非機能要求をきっちりやることはその第一歩。そして一度それでうまくいったら、次回以降のプロジェクトも同じように回していく覚悟ももってほしい」とA氏。結局、ユーザー企業が本気で取り組まなければ、事業コンセプトに沿ったシステムの構築は難しいということだと言えようか。
次回は“鉄則3カ条”のその2である「要求間のトレードオフを見極める」について見ていく。その際、今回お話を伺ったA氏によるアドバイスも、ところどころ織り混ぜていきたいと思う。
Keep up with ZDNet Japan
ZDNet JapanはFacebookページ、Twitter、RSS、Newsletter（メールマガジン）でも情報を配信しています。現在閲覧中の記事は、画面下部の「Meebo Bar」を通じてソーシャルメディアで共有できます。
