コラム

前回のコラムでは「日本本社と海外拠点の想い」と題して、経営計画の重要性、それを実現するための情報システム化に向けたアプローチについて説明し、更に情報システムの実現性を担保する設計書としてRFP（提案依頼書）を作成するということをご紹介しました。このRFPは、企業の要望を事業要件、業務要件、システム要件、非機能要件として定義し、システムベンダーに提出してシステム提案を依頼する文書になります。

では、実際に作成するには何をすれば良いでしょうか。 多くの企業はRFPを初めて作る、もしくは過去に1、2回作成したことがあるという状況で、「どのように作ったらよいか？」という疑問形から始まるケースがほとんどだと思います。 書店には「RFPの作り方」と題した書籍がたくさんあります。サンプルフォーマットを用意し、その形に合わせて作成すれば、簡単にRFPが出来上がるというものです。それで果たしてうまく行くでしょうか。 それ以前に出来ることならRFPを作らずに済ませたいという企業もあるのではないでしょうか。いつも付き合いのあるシステムベンダーに依頼すれば、細かい要件をひとつひとつ文書に落とさなくても、少し説明すればこちらの要望を理解して、更にRFPのような文書を作成してくれるため、作業を省略してしまうケースも見られます。

今回のコラムでは、これらのRFPの疑問に対して、「なぜ」「だれが」「どのように」の3つの視点から説明していきます。

なぜRFPを作成するべきなのか？

情報システムを構築するにあたり、必ず要件というものを洗い出します。 例えば、海外拠点であれば、輸出、輸入をしているので通貨を複数管理したい、通関書類は英文なので言語は英語を使いたい等のリクエストが出てきます。
要件が少なく、口頭で話が伝えられるぐらいの情報システム化であれば、わざわざ文書として作成するまでもありませんが、今回のように経営計画を実現するための情報システム化は、当然要件も多くなり、関係する人たちが多くなるため、認識違いを避ける意味でも情報システム化の設計書となるRFPが必要となるわけです。

前回のコラムでもご説明しましたが、この設計書は自社の経営計画を実現するために情報システムという共通言語（仕組み）に落とし込むためのバイブルになります。 情報システム化のプロジェクトが始まり、仮に途中で立ち止まることがあっても「計画」や「RFP」に立ち返ることにより、自分たちが進む「方向性」を再確認することが可能となります。

では、RFPを作らなかった場合、費用面からはどのようなことがいえるでしょうか。

上記の表は①要求仕様は網羅されているRFPと④網羅されていないRFPで設計・製作・テストにおいて費用が当初よりどのくらい変化したかの調査結果です。
この2つを見比べると、設計において30％、テストにおいて10％の費用が増加したということが見て取れます。費用が増加するということは、工数やかかる時間の増加はもちろんですが、それに掛かる自社人員関与時間等にも影響するということになります。

ちなみに②③はRFPが存在するものの何らかの不備があるもので、こちらに関しても、設計、テストにおいて費用の増加が見受けられます。

例えば、部門別や商品別等のセグメント別に数字を分析したいというリクエストがあった場合、RFPを作成する際に、セグメント別に実績の把握がしたいという現場からの要件のみをRFP に記載し、本来経営者からリクエストがあるはずのセグメント別の実績、セグメント別予算比較、将来予測といった要件が漏れてしまうケースがあります。そのため、企業全体の要件が網羅されず、手戻りが発生しまい、上記のような費用増加を招くことになります。

このように手戻りの発生や後だしジャンケン的な追加リクエストが発生しないようにRFPは「作った方が良い」のではなく「作らなくてはならない」重要な文書といえます。

誰がRFPを作成するべきなのか？

次に、誰がRFPを作成すべきなのでしょうか？
ここにRFPの作成者と満足度を調査した結果があります。

プロジェクトの規模を問わず、RFPを「すべて委託先」で作成した場合よりも「ほとんど自社で作成」した場合の方が満足度は高くなっています。
「ベースは自社、細部は委託先」で作成したというパターンもあります。業務要件のベース、すなわち顕在化している要件の洗出しは自社で行うが、自社でなかなか決めきれない業務要件の細部を委託先に任せてしまうということで、「500人月以上」に特に顕著ですが、「すべて委託先」に任せてしまうパターンとあまり変わりのない傾向だということがわかります。

RFP作成を普段から付き合いのある委託先に依頼すると、依頼はし易いのですが、どうしても委託先のソリューションの範疇に留まるRFPとなり、自社の想いが表れにくい傾向にあります。
RFPに書くべき内容を知っているのは当たり前のことですが、委託先ではなく、情報システムを検討している自分たちです。自社が主導権を握ってRFPを作成するということは、想いをそのドキュメントの中に盛り込むことになり、その結果、満足できる情報システム構築が実現できるのです。

どのようにRFPを作成するべきなのか？

先の調査結果でも明らかな通り、自社でRFPを作成することが望ましいということをご説明しましたが、実際どのようにRFPを作成していけば良いでしょうか？

単に書籍を参考にして形式的に自社で作成していけば良いというものでもありません。 RFPとは提案を依頼する道具になるので、良い提案を受けるために十分な情報を持たせなければなりません。
もう少し具体的に書くと、システムベンダーから良い提案を受けるためには、自社の要件を正確に誤り無く伝えることができ、更にシステムベンダーがスケジュール・コスト・スコープを含めて精度の高い提案をするための材料を過不足なく伝える必要があります。

この過不足の判断が非常に難しいところです。
余計な情報が多く要件が曖昧になってしまった、重要な情報が不足していた、要件としては記載しているが重要度の区別をしていなかった等、過不足をいかに無くせるかが重要になってきます。
過不足あるRFPは、要件が曖昧になりがちで、システムベンダーは「きっとこうだろう」という仮説に基づき提案をしてきます。

自社内で判断が付かない場合は、外部の専門家、例えばコンサルティング会社やシステムベンダーにレビューしてもらうという方法が効果的です。
これにより、ユーザー企業側の目線とシステムベンダー側の目線を併せ持つ良いRFPとすることが出来ます。ただし、RFPのレビュー依頼先は、RFPを発行する先とは明確に区別しておく必要があります。理由は言うまでも無く、RFPの大きな目的である、広く公平に提案を受けるという点が損なわれてしまうからです。システムベンダーにレビューしてもらう際には、RFP発行先以外にレビューを依頼することが必須です。また、ある程度の費用が発生するということは認識する必要があります。

では、実際に過不足なく、自社の想いを詰め込んだRFPを作成するためにはどんな項目が必要になるか、を見ていきます。

RFPの構成は以下の要素から成り立っています。

これらの要素をRFPの目次としてまとめたものが、下記のサンプルフォーマットになります。

RFPの構成詳細は、次回以降のコラムで海外拠点導入の要件を含めて解説をしていきます。

今回はRFPを「なぜ」「誰が」「どのように」という視点から見てきました。
最後にまとめると、

「なぜ」
情報システム化の設計書として、後々、プロジェクト遅延や予算オーバーに陥らずに経営計画を具現化するため。

「誰が」
自社が主体性を持って想いを詰め込むことで、結果的に満足度の高い情報システムができる。

「どのように」
PRFの情報が曖昧にならないよう過不足なく、多くのシステムベンダーが理解しやすいRFPを作成する。場合によっては外部支援を仰ぎ、自社の想いを正確に記載することが重要。
これらがRFP作成の勘所となります。

次回は、RFPをまとめるにあたり必要な要件定義の進め方をご紹介します。

第3回コラム『スムーズな要件定義方法』に続く