RFIに記述すべき内容とは | システム導入検討のエッセンス(2)

RFIに記述すべき内容とは | システム導入検討のエッセンス(2)

イントロダクション

前回はRFI・RFPとはそもそも何なのか、何故必要なのかという話をしました。
今回から実際に記載すべき内容についてお話しします。
まずは順番的にRFIからになります。

尚、前回の最後にも告知しましたが、当ブログではRFIの雛形やフォーマットの提供は想定していません。
あくまでRFI・RFPの理解を深めるための解説になりますのでご了承ください。

スポンサーリンク

RFIに記載すべきこと

まず記載するのは自社の状況

RFIに記載するのは主に「自社の状況」と「依頼したい事項」です。

「自社の状況」は、自分たちがどのような企業・団体であり、何をしていて、何に困っているかを伝えるためのものです。
具体的に挙げると以下のような項目になります。

自社の会社概要

何を主な事業としていて、どれくらの規模(売上、社員数、事業所数等)の会社かを簡単に紹介します。最低限、会社のホームページで紹介している情報は必要です。

ベンダーは事業内容や規模によってある程度適合する製品は絞ることができます。
同業種で同じくらいの事業規模の会社に導入実績がある製品を紹介してもらえるかもしれません。

価格が高いから機能や性能が良いのではなく、「自社に適合して、運用しやすいもの」を調達できるよう、どうしても伝えるべき特記事項があれば記載しておきましょう。

新たな製品・サービスを調達したいと思っている理由、背景

「〇〇を導入したい」ではなく、「ここが困ってる」を記載します。
提供してもらいたいのは、製品自体よりも、その製品を活用したソリューションになります。
解決してほしい事象を明確にして、ベンダーに説明できるような資料にまとめましょう。

システム選定の過程・計画

今回の調達について、どうやって選定しようとしているか、いつ迄に決定しようとしているか、いつから稼働させたいと思っているかの計画を示します。

対象の規模が大きくなれば、ちょっと興味があっただけ程度ではベンダーから得られる情報もその程度になる可能性があります。
社内でもある導入計画についてネゴが取れており、予算化の目途も立っていて、「本当に買いますよ」と手を挙げれば、ベンダーは真剣に情報を提供してくれます。要は売り込みに来ます。

「ちゃんと発注する計画も立てていますよ」をお知らせするのと共に、ベンダー側は「その時期は他の案件と被ってて人を集めるのが難しい」とか、「もっと早くできる」「もっと時間がかかる」という判断ができるようになります。

現行業務(システム)の概要

今困っていることについての業務内容の説明です。
今何ができていて、何ができていなくて、何に困っているかがわかるように纏めましょう。
詳細な仕様や運用は省きますが、これだけは必ず必要というものがあれば特記事項にしておきましょう。

現行業務でパッケージシステムを利用していれば、その名前も伝えたほうが良いです。
パッケージ名である程度機能はわかるので、ベンダー側も自社製品との差を理解した上で情報が提供できます。

ベンダーに依頼したい事項

会社概要の提示

「自社の会社概要」の裏返しです。

調達規模が大きくなれば、それだけ開発体制も大きくなります。
大手企業が必ずいいわけではないけど、大型プロジェクトを単独で任せるには売上規模や社員数で見ると不安、という会社にはやはり頼みづらいです。

例えば予算5,000万円で新システムを調達しようとしているとします。
手を挙げたのが売上1億/年のベンダーでした。
全社員でプロジェクトに取り組んで年間の会社の売り上げの半分という規模感です。
どれだけ周到な計画を立てても、一度予定が狂えばリカバリが難しそうです。

そんな無茶な仕事の受け方は普通ありえませんが、念のため「安心して任せられる体制がとれる会社か」を確認するようにしましょう。

提案しようとしてる製品やサービスの内容

「困っていることをどうやって解決しようとしているか」の大まかな概要をお知らせしてもらいます。

こちらから提示した要件やスケジュールについて、「できる」「できない」の二分で回答されることはあまりありません。代替手段や運用提案、調達スコープ自体の縮小等、ベンダーが取りえる手段で実現の方法を提示してきます。

あまりに各社が回避してくるような要件は、実施できるけど費用がかさんだり、そもそも実現が難しかったりすることが考えられます。
この後のRFP時にその要件をどう定義しておくべきか考えるようにしましょう。

導入事例

同種の業務や同規模の企業への製品・サービスの導入実績を問い合わせます。
顧客企業名は出してもらえない場合もありますが、件数と規模感、導入時期等を回答してもらいます。

前述の会社概要と同様で、導入経験の無い会社の初プロジェクトで生贄にされるのはできれば避けたいです。

RFIの記述で気を付けるべきこと

伝え方は「こういうことが困っています」「こんな感じのものが欲しい」

記載すべき内容はここまでとし、ここからは気を付けるべき内容です。

RFIは「これじゃなきゃダメ!」とこだわりを持って臨んでしまうと、知っている技術・サービスの範囲を超えた提案がもらいにくくなります。

場合によって絶対条件になる項目もあるかもしれませんが、よほどでなければ「こちらがイメージしているのはこんな感じ」くらいにしておいたほうがいいでしょう。

例えば自社側が「個人情報を大量に取り扱う業務なので、インターネットに接続できない環境で利用したい!」と考えていたとします。
なのでRFIでいきなり「クローズドなLAN環境での運用を想定」と書いてしまうと、他のセキュリティ対策について提案を受けられないかもしれません。
「個人情報の取り扱いがあるので、インターネットに接続しないネットワークでの運用に相当するセキュリティ確保が必要である。」としておいたほうが良いと考えます。

スポンサーリンク

中締め

RFIの前に、業務整理は絶対必要

RFIを書くにしろ書かないにしろ、新たなシステム=新たな仕組みを導入するにあたっては、現行業務の整理は絶対に必要です。
今どうなっているかがわからないのに仕組みを変えれば大きな弊害を産みかねません。

現行業務を漏れなく実現する、という意味ではなく、どれがどれに置き換わるのか、置き換わることの効果と影響はどの程度なのかを把握しておかなければ、現場を説得することもできません。

依頼されるベンダーとしても、何が変わるのかわからない提案は効果も訴求しずらいし、受注した後から見えていなかった要件が明らかになるリスクもあり、かなり手は出しづらいでしょう。

当たり前と言えば当たり前ですが、まずは現状をきちんと把握しましょう。
把握しなければいけない現状とは、現場レベルの声だけではありません。
ここで把握すべきことが、RFIやRFPで記載されるべき項目に繋がります。
RFIはわりとざっくりした内容だったのに対して、RFPは詳細な要件が必要になります。

次回はPFIで押さえておくべき要件を元に、把握しておくべき現行業務の観点についてお話していきたいと思います。


RFI・RFP/プロジェクト管理関連の記事を纏めています。

PJ管理カテゴリの最新記事