システムを開発する際、大きく二つの作り方に分けることができます。
それは「アウトソーシング（外注）」と「インソーシング（内製）」です。
それぞれの開発手法にはメリット・デメリットありますが、今回はアウトソーシング時の外注先のベンダー選定の流れとコツを解説します！
システム開発時のベンダー選定の工程
まずはベンダー選定がシステム開発工程のどこの位置にいるか確認しましょう！
下の図の通りですが、開発をお願いする会社を選定しないと開発が始まらないので、システムの企画を行い、予算を取ったら、「ベンダー選定」を行います。
STEP1：RFP作成
ベンダー選定を行うためには発注側で作って欲しいシステムの詳細情報を整理して、一つのドキュメントにまとめる必要があります。
それを「提案依頼書」という形でベンダーへ配布します。
この提案依頼書がRFP（Request For Proposal）と呼ばれるもので、中身には以下のような情報を記載します。
RFPには「背景、目的、業務フロー、機能要件、非機能要件」など、ベンダーが提案するために必要な情報が記載されている
システムの規模が大きくなればなるほど、RFPの量は多くなり、添付資料として、「機能一覧」や「業務フロー図」、「ネットワーク構成図」などの付随情報も多くなりますね。
SETP2：提案依頼（RFP）説明会
続いて完成したRFPを提案したいベンダーへ配布しますが、RFPだけを配布するのではなく、RFP内の重要なポイントやサマリを解説するとより精度の高い提案がベンダーから出てきます。
そのために、「提案依頼（RFP）説明会」というものを開催することも多いですね。
また、その場でQ＆Aを実施することで、早期にベンダーの疑問点を解消することもできます。
提案依頼するベンダーの数は？
「この提案依頼説明に何社呼ぶの？」って疑問に思う方もいらっしゃると思います。
ずばり「案件やタイミングで変わります！」って元も子もない言い方ですが、本当に決まりはないのです。
私の経験上、3社から8社くらいですが、ネットワーク構築とかだと、結構多めにお声がけしますし、営業関係でお付き合いがあるベンダーさんにもお声がけしたりすることがありますね。
提案依頼する社が多ければ、それだけ提案の数が集まるので、良い提案が出てくる可能性が高くなります。
その反面、提案の数だけ後述すうQ&Aや評価をしなければならないので、それだけ労力がかかります。
と言うことで、提案依頼のベンダー数は案件毎に吟味する必要がありますね。
提案依頼説明会のやり方は？
昔は提案依頼説明会のために大きな会議室を借りて、1社あたり3名まで参加とか決めて、リアルで説明会を実施したりしてました。
その際に紙でRFP本体や添付資料を人数分印刷したりするので、その準備も大変でした。
現在はオンラインで説明会を開催しちゃうことも多く、会議室の準備や印刷が不要になって大分省力化できていると思います。
ただ、私は複数のベンダーさんを一同に集めて、説明会をやる緊張感が好きでした（笑）
STEP3：Q&A
RFP配布後から提案の締め切りまではある程度の期間があります。短くても1か月くらいはあると思います。
RFPがどんなに詳細かつ高クオリティで要件が記載されていても、疑問が生まれる、追加の情報が欲しくなる、ことはあると思います。
そんな時はベンダーから提案依頼側へ質問することができます。
質問は一つ一つではなく、ある程度まとめて質問しますが、提案依頼側は丁寧に一つずつ回答します。
下の図のように質問に対しての回答が追加情報になっている場合などは、質問してきたベンダー以外のベンダーにも追加情報として提供します。
これにより、全ての提案ベンダーに対して提示内容に不平等が無いようにしています。
STEP4：提案説明会＆評価
RFP配布から一定期間後に提案の締め切りがやってきます。
大体締切日に「提案書＆見積書」が依頼元に届きます。
場合によっては「締切日を伸ばしてほしい」とお願いされることもありますが、その場合、了承することもありますが、そこはマイナスポイントになってしまいます。（締切守れないベンダーは今後のプロジェクトでのスケジュール遅延の可能性高いですもんね）
提案書が提出されたら、「提案説明会」を実施します。
私なりの提案説明会を行う理由は以下の3点があります。
長い時間と工数をかけて提案書や見積を作成して頂いているので、提案説明会でその思いを発注依頼側にぶつけてもらいます。
提案説明会のポイント
- ベンダー側のプロジェクトマネージャやプロジェクトリーダーの印象を直接確認する
- QAでのやり取りでベンダーが柔軟な対応ができるかを確認する
- プロジェクトへの熱意（意気込み）を確認する
そして、全てのベンダーの提案説明会を実施し、評価・比較を行います。
評価にはいろいろなやり方があると思いますが、評価シートを作成し、それぞれポイントなる項目で点数をつけて、その合計点で優劣を付けたりします。
また、システム部門だけでなく、システムを使う業務部門の担当者の感想も聞いたりして、そこもポイントに換算します。
また、金額は安い方が良いのですが、「安かろう悪かろう」もあるので、見積り内容をきちんと確認して、見積り漏れが無いかのチェックは重要ですね。
ベンダー数が多かったり、内容面で競っている場合は、二次評価でより詳細な比較を行うこともあります。
見積金額も含めて、最終的にどのベンダーを選定するか関係者で決定します！
ただ、まだ発注までには道のりがあります。（汗）
SETE5：社内承認
さあ、内部で提案評価がまとまって、発注したいベンダーが決まったら、社内承認です。
会社によってルールは色々あると思いますが、基本的には社内の正式な手続きを取るため、ユーザー部門やシステム部門の責任者に評価内容を報告し、承認を得ます。
責任者側はスケジュールや体制、金額などにリスクが無いかを確認し、必要に応じて追加の確認を担当者へ依頼したりしますね。
分かりやすくシンプル且つ漏れのない報告資料を作ったりする必要があるので、意外とこのプロセスが大変だったりします。。。
社内承認が下りたら発注！と思いきや、このタイミングではベンダーへ発注書を出さず、「第一交渉権を付与」ということを行うこともあります。
SETE6：第一交渉権付与
「第一交渉権付与」、言葉でなんとなく分かるかと思いますが、提案依頼ベンダーの中から発注を前提に最終的な詳細を詰めるためための権利をベンダー側に与える、というものです。
「優先交渉権」という言葉を使ったりもしますね。
第一交渉権を付与したのち、双方の契約内容や諸条件、要望の再確認などを行います。
発注までもう少し！
SETEP7：発注・契約
第一交渉権付与し、双方で契約内容が合意できたら、いよいよ発注です。
発注書を渡したり、契約書を締結することで完了します。
発注はプロジェクト丸っと発注したり、要件定義、設計、開発など工程ごとに発注することがありますね。
これでやっとこベンダー選定完了です！（パチパチ）
発注が完了した瞬間は発注側、受注側の双方に達成感がありますが、これから本格的にプロジェクトが始まるので、早速プロジェクト準備フェーズに入りますね。（長い道のりですね）
まとめ
今回はシステム開発におけるベンダー選定のプロセスとコツに関して解説してきました。
ベンダー選定のまとめ
- ベンダー選定はシステム開発の最初の山場である
- RFP作成に情熱を注ぐことで良い提案が出てくる可能性が高くなる
- お声がけするベンダーの数は案件や状況応じて決める
- 提案評価は評価軸をしっかり決めて、公平に評価を行う
- 発注までは評価、社内承認、第一交渉権付与などのプロセスがある
私も発注側として、幾度となくベンダー選定を実施していきましたが、RFP作成から発注までは長い道のりでした。
ただ、このプロセスを丁寧且つ確実に行うことで、この後のプロジェクトをトラブルなく円滑に進めることができましたので、ここは力の入れ所だと思ってます！
選定したベンダーさんはもちろんのこと、落選してしまったベンダーさんにも感謝ですね。
以上です！