システムの開発をベンダーに発注する際に、RFPを作成し、作成したRFPを元に開発ベンダーから提案をもらい、発注先を決定する、というプロセスを踏みます。すべてのシステム開発案件で必ず作らなければいけない、というものではありませんが、大規模な開発案件であれば、ベンダーの選定ミスはそのままプロジェクトの失敗につながりますので、RFPは必ず作成するようにします。
RFPの作成
RFP(Request for Proposal)とはシステム開発ベンダーに対して、どういったシステムを開発してほしいかの要件をドキュメント化した、提案依頼書のことです。RFPを作成せずにシステムを発注するケースもよくありますが、この場合、要件が正しくシステム開発ベンダーに伝わらないため、ベンダーによってバラバラな提案をしてくることがよくあります。今まで付き合いのあったベンダーとそうでないベンダーとでは、業務やシステムの理解度も違います。公平に各社から提案してもらい、正しくベンダーの選定を行うために、現状の業務内容やシステム機能、これから実現したい内容をもれなく資料化します。似たような言葉にRFIというものがありますが、これはRFPを作成する前に、システム開発ベンダーに提供可能なサービスの情報を依頼するドキュメントになります。
RFPの構成要素
RFPの構成要素は以下のような内容になります。 1. 概要
会社の紹介や、システム化の概要として、今回のシステム化の背景と実現したい内容、解決すべき課題を明確化します。 2. 現状分析
提案を依頼するベンダーは必ずしも現状の業務やシステムを完全に理解しているとは限りませんので、現状の業務フローと現システムの機能、非機能を整理します。すでに業務フローが存在していたり、過去のシステムの機能一覧などの資料があればその内容を入れます。 3. 提案依頼内容
次のシステムで実現したい内容を業務要件、機能要件、非機能要件の観点でまとめます。この内容がシステムの核になる部分なので、実現したい内容をもれのないように明記します。また、安定性・拡張性・可用性といった非機能要件やセキュリティの要件や運用・保守の要件も入れるようにします。 4. 提案手続き
RFPを提出した後、ベンダーからの提案書の提出期限を明記します。あまり短すぎるとそこであきらめる開発ベンダーも出てきますので、ベンダーが少し頑張れば提案書を作成できる期間にします。プロジェクトの規模にもよりますが、RFPの提出後2週間~1か月が妥当だと思います。 RFPの作成におけるポイントは、要件をもれなく洗い出すことと、要件の記述内容に曖昧さを残さないことです。細かな仕様については曖昧さが残っていても構いませんが、ベンダーによって解釈が異なるような曖昧な表現は避けるようにします。
会社の紹介や、システム化の概要として、今回のシステム化の背景と実現したい内容、解決すべき課題を明確化します。 2. 現状分析
提案を依頼するベンダーは必ずしも現状の業務やシステムを完全に理解しているとは限りませんので、現状の業務フローと現システムの機能、非機能を整理します。すでに業務フローが存在していたり、過去のシステムの機能一覧などの資料があればその内容を入れます。 3. 提案依頼内容
次のシステムで実現したい内容を業務要件、機能要件、非機能要件の観点でまとめます。この内容がシステムの核になる部分なので、実現したい内容をもれのないように明記します。また、安定性・拡張性・可用性といった非機能要件やセキュリティの要件や運用・保守の要件も入れるようにします。 4. 提案手続き
RFPを提出した後、ベンダーからの提案書の提出期限を明記します。あまり短すぎるとそこであきらめる開発ベンダーも出てきますので、ベンダーが少し頑張れば提案書を作成できる期間にします。プロジェクトの規模にもよりますが、RFPの提出後2週間~1か月が妥当だと思います。 RFPの作成におけるポイントは、要件をもれなく洗い出すことと、要件の記述内容に曖昧さを残さないことです。細かな仕様については曖昧さが残っていても構いませんが、ベンダーによって解釈が異なるような曖昧な表現は避けるようにします。
システム開発ベンダーの選定
RFPを作成したら、提案に参加してくれそうな開発ベンダーにRFPを提出します。あまり多すぎても評価に時間がかかりますし、少なすぎると比較にならないため、3社~5社が妥当だと思います。ベンダー各社から出てきた提案について、以下の観点で評価を行います。 ① ビジネス理解度
ビジネスを十分に理解しているか、業界の動向を十分に理解しているかを評価します。 ② 要件充足度
RFPで提示している機能を満たしているか、場合によってはカスタマイズ等を行い、業務や機能の実現ができるかを評価します。また、機能要件だけではなく、非機能要件として、求める安定性・拡張性・可用性を有しているか、信頼に値する万全なセキュリティ対応・監視体制を整備しているか、求める運用・保守要件が想定内の費用・工数で実現できるかを評価します。 ③ 新規性
他社製品にはない、魅力的な独自性をもった機能があるか、導入・利用方法等で斬新な方法論や事例を有しているかを評価します。 ④ 実現性
導入に向け詳細なシステム移行計画を検討しているか、システムの変更に伴う業務の変更対応を詳細に検討しているか等を評価します。 ⑤ 信頼性
取引にあたり、会社規模、財務健全性が担保されているか、国内外の導入実績を豊富に有しているかを評価します。 ⑥ コスト
予定した費用内に収まっているか、利用拡大などを想定した際の将来的なコストの妥当性があるかを評価します。 ⑦ 提案姿勢
プレゼン時に責任者(役員クラス)同席の元、提案にコミットメントしているか、本案件に対する意気込み・熱意があるかを評価します。 これらの観点でそれぞれ点数をつけ、中でも重要度が高いと思われる項目については、ウエイトを見直し、複数人でそれぞれ評価を行うことで最終的に評価の高いベンダーを選定するようにします。
ビジネスを十分に理解しているか、業界の動向を十分に理解しているかを評価します。 ② 要件充足度
RFPで提示している機能を満たしているか、場合によってはカスタマイズ等を行い、業務や機能の実現ができるかを評価します。また、機能要件だけではなく、非機能要件として、求める安定性・拡張性・可用性を有しているか、信頼に値する万全なセキュリティ対応・監視体制を整備しているか、求める運用・保守要件が想定内の費用・工数で実現できるかを評価します。 ③ 新規性
他社製品にはない、魅力的な独自性をもった機能があるか、導入・利用方法等で斬新な方法論や事例を有しているかを評価します。 ④ 実現性
導入に向け詳細なシステム移行計画を検討しているか、システムの変更に伴う業務の変更対応を詳細に検討しているか等を評価します。 ⑤ 信頼性
取引にあたり、会社規模、財務健全性が担保されているか、国内外の導入実績を豊富に有しているかを評価します。 ⑥ コスト
予定した費用内に収まっているか、利用拡大などを想定した際の将来的なコストの妥当性があるかを評価します。 ⑦ 提案姿勢
プレゼン時に責任者(役員クラス)同席の元、提案にコミットメントしているか、本案件に対する意気込み・熱意があるかを評価します。 これらの観点でそれぞれ点数をつけ、中でも重要度が高いと思われる項目については、ウエイトを見直し、複数人でそれぞれ評価を行うことで最終的に評価の高いベンダーを選定するようにします。
システム開発をベンダーに発注する際に、付き合いの長いベンダーに発注することが多いと思いますが、最終的にそのベンダーを選定するにしても、複数のベンダーと比較したうえで決定したほうがいいでしょう。1社とだけ話をしているとコストの妥当性も判断できませんし、付き合いも長くなるとベンダー側から見てもどうせ発注してくれるだろう、という甘えの感情は出てくるものです。大規模なシステムの開発であればあるほど、失敗は許されませんので、RFPをきちんと作成し、真剣にプロジェクトに向き合ってくれるベンダーを選定します。次回はまとめとして、ベンダー選定後の内製化における役割について説明します。 (つづく)
岡村 克久(Katsuhisa Okamura)
1993年(株)オービックにてSEとしてシステム開発に従事。2000年(株)イーショッピング・ブックスに入社しECサイト開発に携わる。2008年(株)セブンアンドアンドワイ システム開発部部長就任。2015年(株)セブンアンドアイネットメディア執行役員就任。オムニチャネル戦略の開発PMを務める。2017年同社を退社。2017年デジタルシフトウェーブ入社。同社取締役に就任。
■上記の著者へのDX相談・講演等の依頼は、こちらから
株式会社デジタルシフトウェーブ
https://www.digitalshiftwave.co.jp/
株式会社デジタルシフトウェーブ
https://www.digitalshiftwave.co.jp/