はじめに
本記事では、数千万円以上の大規模システム調達の成功に向けて、RFP準備、RFP発出の工程において意識すべきポイントを全般的に考察する。全般的な考察の中でも、特にRFP準備工程における要件の決定が重要な要素と考えているため、重点的に考察をしている。
本記事が、数千万以上の大規模システムの調達をご検討されている方の一助となれば幸いである。
1.RFPの概要
RFPとは、"Request for Proposal"の略で、日本語に訳すと「提案依頼書」である。
システム調達を検討している発注者が、専門的な知識や技術を持ったシステム開発事業者（主にSIerやシステムベンダー）に対してRFPを発出すると、システム調達に関する提案を受け取ることができる。
RFPでは、発注者が求める提案内容や要件を明確に定義し、システム開発事業者に提示することで、発注者の実情に即した最適なシステム提案を受け取ることが可能であり、通常RFI (Request For Information: 情報提供依頼書）の後に作成するのが一般的である。
(1)RFPを作成する目的
システム調達は、コンペ形式か随意形式どちらかの方法で実施されるが、特にコンペ形式においては、競争性の確保（ベンダーロックインの回避など）が求められる。
そのため、RFPを作成する事によって「発注者の要件を正確かつ具体的にシステム開発事業者に伝えること」が可能となる。RFPは可能な限り具体的な内容で作成することで、システム調達の競争性の確保（ベンダーロックインの回避など）に繋がる。
一方、抽象的な内容のRFPを作成し、システム調達を実施すると、システム開発事業者独自の解釈により、発注者の要件とかけ離れた提案（必須要件を満たせていないなど）をされる可能性が高く、現行システムを担当するシステム開発事業者に優位なコンペとなり、競争性の確保（ベンダーロックインの回避など）が難しくなる。
以上のことから、特に数千万円以上の大規模システムを調達する際は具体的な内容のRFPを作成する事が望ましい。
(2)具体的なRFPと抽象的なRFPのメリット、デメリット
数千万円以上の大規模システム調達を実施する際、具体的な内容のRFPを作成する事が望ましい。
一方、人的リソースが不足しているといったなどの事由により、抽象的な内容のRFPでシステム調達を実施するケースも存在する。
そこで、具体的なRFPと抽象的なRFPのメリット、デメリットを整理し、それぞれの場合の良し悪しを把握する。
図1：抽象的なRFPのメリット、デメリット
図2：具体的なRFPのメリット、デメリット
(3)RFPの記載事項
RFPを作成する場合の記載事項を以下に整理する。
RFPには、一般的に以下のような内容が含まれる。
図3：RFPの記載事項
2.RFP準備工程で意識すべきポイント考察
RFPを準備するにあたっての工程は、下記の4つに分類できる。
「要件の決定」
「RFP作成」
「評価基準の作成」
「RFP発出対象の事業者選定」
それぞれの工程について意識すべきポイントを考察する。
図4：RFP準備にあたっての工程イメージ
(1)要件の決定
発注者は、システム調達にあたって実現したい要件を網羅的にRFIに盛り込み、技術的に実現可能かをシステム開発事業者へ情報提供依頼を実施する事で、発注者の実現したい要件への技術的な実現可否が明確になる。
発注者は情報提供依頼の結果を踏まえて、実現したい要件の絞り込みをし、RFPに盛り込むべき要件を決定する事が求められる。要件の決定には様々な部門が関わってくるため、各部門のシステム調達の考え方に配慮しながら、慎重に検討を進める事が重要である。
調達部門は、主に予算内でシステム調達をしたいと考える傾向がある。ユーザー部門は、主に現場業務の高度化や効率化のためのシステム調達をしたいと考える傾向がある。システム部門は、主に安定的なサービス提供が可能なシステム調達をしたいと考える傾向がある。
図5：各部門のシステム調達に関する考え方
例えば、調達部門の考え方を優先する場合、予算を限りなく抑えたいという事で、いわゆる「安かろう悪かろう」の調達となってしまう可能性がある。このように、各部門でシステム調達に関する考え方が異なるため、要件の決定にあたっては全部門横断的に進めていくことが望ましい。
全部門横断的に要件を決定するポイントとしては、大きく下記の3点が考えられる。
「技術的な実現可否の検討」
「費用対効果の検討」
「スケジュール遵守」
「技術的な実現可否の検討」とは、技術的に実現可能な要件なのかを確認する事である。
例えば、新規提案事業者は技術的に実現可能としている一方、現行システムを担っている提案事業者は技術的に実現不可としているといったケースがあるため、相対評価的に検討する事も求められる。
「費用対効果の検討」とは、技術的に実現可能な要件であっても、要件を実現する際の費用対効果が悪いなど等といったケースがあるため、それらの取捨選択を検討する事である。
「スケジュール遵守」とは、技術的に実現可能かつ費用対効果が高い要件であっても、スケジュールの遵守が難しくなるケースがあるため、それらの取捨選択を検討する事である。
上記3つのポイントを活用しながら、要件の決定を進めるイメージを提示する。法改正対応などのように、そもそも対応が必須の要件については、3つのポイントを考慮せず要件に盛り込む（費用対効果が悪くても実施等）。業務追加、変更のような要望については、3つのポイントを考慮しながら要件に盛り込む。
例えば、帳票の見直し（統合やレイアウト変更など）のような要望があった場合、まずは「技術的な実現可否の検討」を考慮する。技術的な実現が可能となれば、「費用対効果の検討」を考慮する。例えば、帳票の見直しは、数百万円の開発費用が発生する場合、帳票の見直しを実施した際の効果が数百万円の開発費用を上回るのかが検討ポイントとなる。
帳票の見直しによって、年間の帳票の消費量を減少させることができ、システム更改後の運用・保守期間の数年間の削減費用として数千万円が見込めるといった場合であれば、数百万円の開発費用を上回る効果と判断できる。最後に「スケジュール遵守」の確認をする。
これら3つのポイントを考慮しながら、全部門に対して要件の決定を促すことで、予算内での調達、業務の高度化や効率化、安定的なサービス提供などを満たしたシステム調達の実現に近づくと考えている。
(2)RFPの作成
「1. (3) RFPの記載事項」を参考にしながら、システムで何を実現したいのかを網羅的かつ具体的に示すことが重要である。
システム規模が大きくなるほど、適切な調達業務が求められる。
デジタル庁が公開している「デジタル・ガバメント推進標準ガイドライン」[1]や「デジタル・ガバメント推進標準ガイドライン考察書」[2]、「デジタル・ガバメント推進標準ガイドライン実践ガイドブック」[3]には、システム調達の手続きや手順、具体的な作業内容などが記載されているため、大規模なシステム調達のRFPを作成する場合の参考にできる。
(3)評価基準の作成
RFP発出後、発注者はシステム開発事業者から提案書を受領し、提案書の内容を評価し受注者を決定するため、RFP準備工程では評価基準を作成する（公共調達の場合は必須）。評価基準は、調達方式によって変わってくる。
調達方式は下図の通りである。
図6：調達方式
本記事は、数千万円以上の大規模システムの調達を実施するという前提であるため、「一般競争入札」の「総合評価落札方式」を考察対象とする（「最低価格落札方式」の場合、いわゆる「安かろう悪かろう」に繋がる懸念があるため）。「総合評価落札方式」には、「加算方式」と「除算方式」が存在するが、過剰な低入札価格を防ぐ意味で「加算方式」を採用する事が一般的である。
「総合評価落札方式」の「加算方式」は、価格評価点と技術評価点の合計が最も高い事業者を落札者とする方式である。以上を踏まえて、「一般競争入札」「総合評価落札方式」「加算方式」の評価基準を作成するという前提とする。
上記前提の評価基準としては、価格評価点と技術評価点の2つに分けられるため、それらを作成する際に意識すべきポイントを考察する。
価格評価点は、「入札価格に対する得点配分×(１－入札価格／予定価格)」で算出されるため、とりわけ予定価格をどのように検討するかがポイントとなる。
予定価格を算出する方法は、「原価計算方式」と「市場価格方式」の2点である。
「原価計算方式」は、仕様書や設計書などをベースに作業項目や人員を割り出し、それらを積み増して算出する方法である。
主に公共工事や製造業などに活用される方法であり、システム調達の場面においては活用が難しい。
「市場価格方式」は、過去に同様または類似の契約金額や見積書を参考に算出する方法である。
主に物品購入などに活用される方法であるため、システム調達の場面においての活用が見込めるため、具体的な算出方法を考察する。過去に本システム調達と同程度規模のシステム調達を実施したことがある場合は、過去の契約金額や見積書をベースにし、システム調達の方針に沿って、ベースから加算するのか、減算するのかを決定する。
システム調達方針として、新規施策の実現に伴う新たな要件が複数存在する場合は、現行システムからの変更点という位置づけで加算を考慮する事が望ましい。
一方、システム調達方針として現行システムの資産を流用したマイグレーション要素が強い場合は、マイグレーションによる開発工数の削減効果という位置づけで減算を考慮する事が望ましい。
また上記に加え、IT業界の人材不足による単価の上昇や物価為替の影響などの社会情勢も考慮すると、より精緻な予定価格の算出に繋がると考えている。
過去に本システム調達と同程度規模のシステム調達を実施したことが無い場合は、システム開発事業者から受領した情報提供書の見積書を参考に予定価格を算出する方法が、精緻な予定価格の算出に繋がると考えている。
技術評価点は「性能等の得点」で算出されるため、とりわけ何を評価項目とするのか、評価項目の配点をどうするのかの2点が検討ポイントである。まず、評価項目を検討する上では「デジタル・ガバメント推進標準ガイドライン」に即した評価項目にするか、システム調達方針を主とした評価項目にするかといった2つの考え方がある。
「デジタル・ガバメント推進標準ガイドライン」には、以下のような評価事項を設定する事が記載されている。
- 制度、業務及び情報システムに対する理解度
- 要件定義の理解度
- 任意で提案を求める事項に対する充足度
- プロジェクトの計画能力
- プロジェクトの管理能力
- 設計・開発などに関する技術的能力
- 設計・開発など等の実績
- 組織的対応力
評価事項に沿って、評価項目を整理するのが1つ目の考え方である。
例えば、②要件定義の理解度という事項に、「機能要件への対応内容」という評価項目を設定し、「機能要件一覧への対応が示されていること」といった評価観点を設定する。
システム調達方針を主とした評価項目の例としては、「売上拡大」という評価項目を設定し、「新規施策に柔軟に対応できる拡張性が示されていること」といった評価観点を設定する。
次に、評価項目の配点を検討するにあたっては、システム調達する際は何らかの方針（新規施策を実現したい、障害を少なくしたいなど）があると思われるため、評価項目でもその方針に沿って、重視したい項目の配点を高めに設定し、他の評価項目との差別化を図る事が適切な評価に繋がると考えている。
各部門とすり合わせしながら進める事で、納得度の高い評価項目となり、システム調達に際しての疑義が発生しにくいと考えている。
(4)RFP発出対象の事業者選定
RFIを発出している場合、情報提供に応じたシステム開発事業者に対して、RFPを発出する事が一般的である。
3.RFP発出工程で意識すべきポイント考察
RFPを発出するにあたっての工程は、下記の4つに分類できる。
「RFP説明会」
「事業者からの質疑応答」
「事業者への質疑応答」
「提案書の評価」
それぞれの工程について意識すべきポイントを考察する。
図7：RFP発出にあたっての工程イメージ
(1)RFP説明会
RFP説明会とは、RFP発出対象の事業者に対して、RFPの配布や説明を実施する会である。RFP説明会は、RFI説明会に比べて、より具体的な内容（要件や評価基準など）が定まっているため、その点を中心に説明をする事がポイントである。
(2) 事業者からの質疑応答
発注者は、RFP発出後、RFPに関して事業者からの質疑を受付・回答をする。
要件に関する質問や技術的な質問が事業者から提示される可能性があるため、必要に応じて調達部門以外の部門（ユーザー部門、システム部門など）を巻き込むことがポイントである。
各部門を巻き込み回答を作成する事で、回答内容が精緻となり、認識齟齬が発生しにくくなるからである。
(3)事業者への質疑応答
発注者は主に提案の評価に関する事をシステム開発事業者に質疑する事となる。
価格評価点を算出し評価採点する際、システム開発事業者から提示された価格の妥当性が不明瞭などといったケースがあるため、提示価格となった理由を質問するようなやり取りをする事がポイントである。
技術評価点の評価項目を評価採点する際、システム開発事業者から提示された提案書に評価項目に該当する提案内容の記載漏れや抽象的な内容で実現性を確認できないなどのケースがあるため、提案内容の追記や具体的内容の提示を促すようなやり取りをする事がポイントである。
また、書面での質疑応答の他に、システム開発事業者からのプレゼンテーションの機会を設けたり、書面でのやり取りでは伝わりづらい質疑に関しては個別対面でヒアリングを実施するなど、柔軟な対応で事業者への質疑応答を実施する事で、相互理解が進みやすくなる。
(4)提案書の評価
発注者は、システム開発事業者から提示された提案書について、価格評価点、技術評価点の観点から評価採点を実施し、受注者を決定する。
価格評価点は、「1. (3) 評価基準の作成」で記載した通り、提示された提案価格を価格評価点を算出する式に当てはめれば、評価採点としては完了する。
技術評価点は、「1. (3) 評価基準の作成」で記載した通り、複数の評価項目の評価採点を実施する。評価項目は、提案内容の実現性と有効性の観点で評価採点する方法がある。
実現性では、提案内容を実施する際の実現性を具体的に想起出来ることを指す。
例えば、現行のシステムとは異なるOSが提案されている場合、当該提案事業者は多くの導入実績を有しており、OSに関する知見があり、確実な導入や迅速なトラブル対応が可能であると推察できるため、現行システムとは異なるOSであっても実現性が認められるなどのように、評価採点を実施する。
有効性では、提案内容の実現性が認められたものに関して、定量的または定性的な効果が見込めるかを確認する。例えば、現行システムと異なるOSは業界標準（デファクトスタンダード）であり、現行システムのOSと比べて、拡張性が向上するため有効性が認められるなどのように評価採点を実施する。
4.次回のシステム調達における改善点の整理
これまでシステム調達成功に向けてRFP工程で意識すべきポイントを考察してきた。
最後にこれまでのシステム調達の活動において、露見した問題や課題を次回のシステム調達における改善点として整理する上でのポイントを考察したい。
次回のシステム調達における改善点の整理方法としては、発注者側の観点とシステム開発事業者側の観点の2つに分けることができる。
発注者側の観点とは、システム調達活動で露見した問題や課題を棚卸しし、その対応策などを整理する事である。例えば、提案事業者数が想定より少なかった、調達スケジュールがタイトで業務量が大幅に増加したなど、発注者内部の問題や課題を棚卸しするイメージである。
システム開発事業者側の観点とは、RFIやRFPを受け取った事業者から見た際の問題や課題提起を棚卸しし、その対応策などを整理する事である。
例えば、RFIやRFPなどの提供資料で理解が難しい箇所があった、要件が厳格であったなど、落札者や不落となった事業者に対して、ヒアリングまたはアンケートを通じて問題や課題を棚卸しするイメージである。
まとめ
数千万円以上の大規模システム調達を成功させるために、RFP準備工程、RFP発出工程で意識すべきポイントを考察した。
システム調達案件の内容によって直面する問題や課題は異なり、システム調達業務の進め方も多様であると考えているが、本記事の内容が少しでも参考になり、システム調達業務が一歩でも前に進めることができれば幸いである。
[1] デジタル庁「デジタル・ガバメント推進標準ガイドライン」
https://www.digital.go.jp/resources/standard_guidelines/
[2] デジタル庁「デジタル・ガバメント推進標準ガイドライン考察書」
https://www.digital.go.jp/resources/standard_guidelines/
[3] デジタル庁「デジタル・ガバメント推進標準ガイドライン実践ガイドブック」