前回、企業は自社のニーズをつかみきれていないために、調達がうまくいかないことがあると説明した。では、企業はどのようにすれば自社のニーズを的確につかんで、それをRFPに盛り込むことができるのだろうか。

標準的なRFPに含まれる主要な項目を以下の表に示した。RFPを提示する先がこれまでに取引実績のあるSIベンダーばかりではなく、初めて取引するSIベンダーであっても、自社が何を求めているのかということを理解できるような内容でなければならない。第三者にも説明できること、取引実績の有無で有利・不利が発生しないようにすることへの配慮が大切である。

これまでの連載において、調達には各部署から専門知識を持った人材が必要に応じて参画すべきと述べた。法務部門や総務部門は法令や社内規程に照らして保証要件や契約条件についてアドバイスしてくれるだろうし、人事・労務部門は体制作りや作業条件、再委託など要員に関する部分で参画してくれるであろう。「餅は餅屋」ということわざ通り、専門家にゆだねたほうがリスクやトラブルを回避できる可能性が高い。

では、IT部門は専門性をどこで発揮すべきかというと、言うまでもなく以下の表の「システム概要」「機能要件」「非機能要件」に関わる部分においてだ。

標準的なRFPにおける主要項目

**1.提案依頼の趣旨**
・提案の手続き(提出期限、提出方法)
・提案にかかわる質疑応答のルール
・提供する資料
・選定結果の回答について
・機密保持協定

**2.調達の目的・狙い・背景**

**3.システム概要**
・システム化の範囲
・ビジネスの要求要件
・既存システムとの関連、システム構成
・現行の運用環境、開発環境
・保守条件
・納入物件、成果物
・スケジュール

**4.機能要件**

**5.非機能要件**

**6.プロジェクト管理要件**
・責任権限と役割分担
・想定している体制
・作業場所

**7.保証要件**
・保証条件
・検収条件
・SLA

**8.契約条件**
・契約形態、支払い条件
・秘密保持契約
・瑕疵担保責任、損害賠償
・検収条件

昨今、ビジネスニーズを仕様化したものが機能要件と非機能要件と呼ばれるようになった。つまり、企業が自社のビジネスニーズをRFPに反映させる上で、機能要件と非機能要件がカギになるというわけだ。

機能要件とは、簡単に言ってしまえば「システムを利用して何をやりたいか」を説明したものであり、「業務上の付加価値に直接的に関係するもの」となる。

対する非機能要件とは、「その機能をどのような品質で利用したいか」を説明したもので、「想定される環境下においてその機能を問題なく利用し続ける」ための要件である。

例えば、「前日の商品別売上実績を翌日の9時までに見られるようにしたい」というのは機能要件に当たる。この場合、前日の商品別売上実績を翌日の9時に見ることができれば、誰に見られても構わないというわけではない。そこで、「管轄する営業部所属の社員だけに限定されなければならない」「社員が外出時に持ち歩いているノートPCでも快適に参照できなければならない」といった非機能要件が出てくる。

また、「従業員の残業時間を翌月の第1営業日までに集計したい」という機能要件については、「正社員、契約社員といったように従業員のタイプが増えても対応できるようにしておきたい」「給与システムとのインタフェースのほかに人事システムとのインタフェースも必要である」といった非機能要件が考えられる。

執筆者プロフィール

石森敦子(Atsuko Ishimori)
株式会社プライド システム・コンサルタント

『出典:システム開発ジャーナル Vol.3(2008年3月発刊)
本稿は原稿執筆時点での内容に基づいているため、現在の状況とは異なる場合があります。ご了承ください。