ベンダー選定とは｜進め方3段階・9つの評価基準と失敗を避ける勘所

かつて、大きな電力会社で働いていたころ、稟議書というものを山ほど作りました。いわゆる、「お諮り文書」というものです。あのころ体で覚えたことが、一つあります。資料は、分厚いほど通る。

ペラ一枚で持っていくと「これだけ？」という顔をされる。同じ中身でも、参考資料や他社事例をぶ厚く挟んで持っていくと「よく調べたね」と言われて、すっと判子が並ぶ。中身が本当に動くかどうかとは、たぶん、あんまり関係ない。分厚さは、決裁する人を安心させるためのものなんですよね。しかも当時の筆者を含む同僚諸兄は、それをわかって、意図的に分厚ーいのをこさえていたと思います。……過去の話ですからね。

なぜこんな昔話から始めたかというと、いまエンジニアとして関わっている「AIエージェント開発」の現場で、あのときと同じ匂いをしょっちゅう嗅ぐからです。いちばん分厚くて、いちばん流暢なデモが、いちばん使われない。 それなのに私たちは、つい分厚いほう・流暢なほうに安心して、判子を押してしまう。あのころの決裁者と、たぶん同じ顔で。

（電力会社の元サラリーマンが、なぜAIエージェントの現場にいるのか——その回り道は自己紹介に書きました。書き手の素性が気になったら、どうぞ。）

「うちでもAIエージェントを作れます」――そう言い切る提案書が、いま日本中の会議室を埋め尽くしています。デモは滑らかに動く。画面の向こうでエージェントが質問にスラスラ答え、タスクをこなしていく。発注したくなる気持ちは、痛いほどわかります。でも、半年後にそのエージェントが現場で毎日使われているかと聞かれて、「はい」と即答できるプロジェクトは、正直、驚くほど少ない。

先に結論を言ってしまいます。この記事はあえて逆張りします。“AIエージェントを作れるコンサル”という言葉ほど、発注する側が警戒したほうがいいものはありません。 とはいえ、誤解しないでくださいね。「AIエージェントは使えない」という話ではないんです。むしろ逆で、ちゃんと設計すれば現場は確かに変わる。問題は技術力ではなく、もっと手前――発注から設計までの「組み立て方」にあります。

これから、ある架空の、でもどこにでもありそうなプロジェクトを一つ、最初から最後まで追いかけます。前半は「分厚い提案書を買ってしまった会社」がたどる末路。後半は「同じ会社が、地味なやり方に切り替えたら何が起きたか」。あなたの会社のいまのAIの話を、頭の片隅で重ねながら読んでもらえると、うれしいです。

ベンダー選定とは｜進め方と、評価基準の作り方

ベンダー選定とは

ベンダー選定とは、システムやサービスの開発・導入を任せる外部の会社を、複数の候補から選び出すことです。発注側が主体になって進めます。

選ぶ作業そのものより、「何をもって選ぶか」を先に決めることのほうが難しく、そして効きます。基準が無いまま提案を並べると、いちばん印象がよかったところが選ばれます。

なぜベンダー選定が重要なのか

理由は3つあります。

• 後から変えるのが難しい — 一度発注すると、途中で乗り換える費用は最初の発注額より大きくなる
• 成果の大部分が、選定の時点で決まる — その会社が持っている経験と体制を超えるものは出てこない
• 選定の過程が、そのまま社内の合意になる — 基準を作る作業は、要件を決める作業とほぼ同じ

3つ目が見落とされます。評価項目を作る過程で、社内でも意見が割れていたことが表に出ます。そこを揃えないまま発注すると、揃っていない要求がベンダーへ流れます。

ベンダーの種類

「ベンダー」は範囲の広い言葉です。何を担う会社かで呼び分けられます。

種類	担うもの
システムベンダー	システム全体の設計・開発・導入
ソフトウェアベンダー	製品としてのソフトウェアの提供
ハードウェアベンダー	機器の提供と保守
シングルベンダー	1社でまとめて引き受ける形
マルチベンダー	複数社が分担する形

シングルとマルチは、責任の所在の話です。シングルは窓口が1つで済む代わりに、その1社に依存します。マルチは得意分野ごとに選べる代わりに、不具合が出たときに「どちらの責任か」を発注側が裁く必要があります。

外部のベンダーに依頼するメリット

• 専門の会社に任せられる — 自社にない経験と技術を、その時点から使える
• 採用と育成の費用を抱えずに済む — 一時的に必要な人員を、雇用せずに確保できる
• 体制を増減しやすい — プロジェクトの山と谷に合わせて調整できる

外部のベンダーに依頼するデメリット

• ノウハウが社内に残りにくい — 作った経緯や判断の理由が、外部にだけ蓄積する
• 情報が社外に出る — 業務の内容、データ、取引先の情報を渡すことになる
• 変更のたびに費用と時間がかかる — 社内なら口頭で済むことが、見積もりと承認を伴う

1つ目への現実的な備えは、「決めたこと」を発注側が書いて残すことです。作り方は外に出しても、なぜそう決めたかの記録まで外に出すと、次の発注でまた同じ説明から始まります。

選定の進め方1｜事前調査とRFI

候補になりそうな会社を洗い出し、RFI（情報提供依頼書）で、各社にできること・実績・体制の情報を集めます。

この段階では提案を求めません。求めるのは、比較できる形の情報です。いきなり提案を求めると、各社が別々の前提で作ってくるため、並べても比べられません。

選定の進め方2｜候補を絞り、RFPを出す

集めた情報で候補を絞り、RFP（提案依頼書）を作って提出を依頼します。同時に、社内で選定基準を決めます。

依頼するのは3社前後が実務的です。多いほど比較の手間が増え、同じ条件で依頼することのほうが社数より効きます。

選定の進め方3｜提案を評価して決める

提出された提案書を評価項目に沿って採点し、必要ならプレゼンテーションと質疑を経て、最終的に1社を決めます。

提案を受け取ってから評価項目を作らないでください。結果を見てから基準を作れば、選びたいところが選ばれる基準ができあがります。

評価基準は、目的と要件から逆算する

評価項目は、一般的な雛形をそのまま使うのではなく、この案件で何を実現したいかから引き出します。

作るときの作法は2つです。採点できる粒度まで割ることと、重視する成果に合わせて配点を変えること。「技術力」のような大きな項目は、そのままでは採点者ごとに解釈が割れます。

評価項目1｜事業の継続性と安定性

システムは作って終わりではありません。保守の期間、その会社が存続しているかを見ます。財務状況、設立からの年数、主要な取引先の顔ぶれが材料になります。

評価項目2｜得意分野と技術力

会社ごとに強い領域が違います。「できます」と「やったことがあります」は別です。

確かめるなら、今回と同じ技術・同じ規模・同じ業種で、いつ、何をやったかを具体的に聞いてください。

評価項目3｜過去の実績

実績の一覧は、社名の多さではなく今回に近いものが含まれているかで見ます。

あわせて、担当した人がいまも在籍しているかを聞いてください。会社の実績と、実際に入る人の経験は別のものです。

評価項目4｜要件の網羅性と実現度

こちらが出した要件に、提案が全部答えているか。答えていない項目があるとき、それが「できない」なのか「読み落とし」なのか「対象外と判断した」なのかを確かめます。

3つ目がいちばん重要です。意図的に外している項目には、たいてい理由があります。その理由が、こちらの気づいていない制約を教えてくれることがあります。

評価項目5｜費用の妥当性

総額ではなく、内訳で見ます。工程ごとの工数と人員構成、含まれる作業と対象外の作業、保守にかかる継続費用。

安いことは、それ自体では評価点になりません。何が入っていないから安いのかが説明できて、その分を自社で引き受けられるなら評価点になります。

評価項目6｜納期の妥当性

希望どおりの納期が並んだときこそ、その前提（発注側が何をいつまでに用意するか）が書かれているかを見ます。

前提の書かれていない納期は、守られる約束ではありません。

評価項目7｜開発と保守の体制

誰が入るのか、何人か、その人たちは他の案件と兼務か。稼働後の保守は誰が担当し、連絡はどの窓口に、何時から何時まで通じるのか。

評価項目8｜セキュリティ体制

データをどこに置くか、誰がアクセスできるか、再委託があるか、事故が起きたときの連絡と責任の範囲。

再委託の有無は必ず確認してください。契約した相手と、実際に作業する会社が違うことがあります。

評価項目9｜提案とプレゼンテーション

提案書の内容と、説明の場での受け答えを評価します。

ここは、評価がいちばん歪みやすい項目です。資料の分量、図の作り込み、話し方のうまさは、実際に作られるものの質とは別の軸です。

だから、この項目には配点の上限を先に決めておくことをお勧めします。（この記事の後半は、ここの話です）

配点の決め方と、評価のぶれを減らす工夫

項目を並べたら、次に配点を決めます。

• 重視する成果に合わせて配点する — 全項目を同じ点数にすると、優先順位が消える
• 4段階など、段階を決めて採点する — 10段階にすると、採点者ごとの尺度の差が出る
• 各段階が何を指すかを、言葉で定義する — 「4＝今回と同じ規模の実績が複数ある」のように書く
• 採点者を複数にし、点が割れた項目だけを話し合う

3つ目をやるかどうかで、評価表の意味が変わります。定義の無い4段階は、印象を数字に置き換えているだけになります。

RFPを出す前に、評価基準を社内で合意する

基準は、提案を受け取る前に確定させてください。関係する部署（事業側・情報システム・法務・購買）で、項目と配点に合意を取っておきます。

この順番にしておくと、選定の結果を説明するときに、「後から基準を作ったのでは」という疑いが立ちません。

失格条件と、追加確認で済む条件を分ける

評価には、点数で比べる項目と、満たしていなければその時点で対象外になる項目があります。

後者は先に分けて明示しておきます。取引の条件、必須の認証、対応できない地域や時間帯など。分けておかないと、失格に相当する欠落が「減点」として吸収されてしまいます。

比較表と、選んだ理由を残す

残すのは点数だけではありません。

• 点数とコメントをセットで記録する — 数字だけでは、後から理由を再現できない
• 同点だったときの優先順位を、先に決めておく
• 選ばなかった理由も、説明できる範囲で残す
• 選定時の評価項目を、発注後の管理項目へ引き継ぐ

4つ目が、選定を実務に繋げます。体制やセキュリティを評価して選んだなら、そのとおりに運用されているかを、稼働後も同じ項目で見ていきます。

ベンダー選定でよくある失敗

報じられている失敗例と、実務で挙がるものを整理すると、次の5つに集約されます。

• 要件が固まらないまま選定を始めた — 比べる軸が無いので、印象で決まる
• 費用の安さだけで決めた — 含まれていなかった作業が、後から追加費用になる
• 提案書とデモの出来で決めた — 見せるための作り込みと、動かし続ける力は別
• 実績の社名だけを見た — 今回に近い案件か、担当者が残っているかを確かめていない
• 選定の記録を残さなかった — 担当が変わると、なぜその会社なのかを誰も説明できなくなる

3つ目が、いちばん自覚しにくい失敗です。評価表を作り、配点も決めていたのに、それでも起きます。

発注を決めたあとに残る仕事

選定は終わりではなく、始まりです。

• 契約形態（請負か準委任か）と、仕様変更の扱いを決める
• 発注側が用意するもの（データ、担当者の時間、承認の段取り）を確定させる
• 進捗を確認する頻度と、動くものを見せてもらう間隔を決める
• 評価項目を管理項目に引き継ぎ、稼働後も同じ軸で見る

2つ目を決めていない発注は、ベンダーをどれだけ丁寧に選んでも遅れます。止まる原因が、発注側の中にあるためです。

ここまでが、ベンダー選定の教科書どおりの整理です。RFIで情報を集め、RFPを出し、項目を割って配点し、複数人で採点し、記録を残す。この形にしておけば、選定は説明できるものになります。

ここからは、その評価表を埋めていたときに、実際には何を見て決めていたかの話です。項目も配点も用意したうえで、それでも「提案とプレゼンテーション」の欄が効いてしまう場面があります。

分厚い提案書を買ってしまった会社の話

たとえば、こんなプロジェクトがあったとします。

中堅の機械メーカー。カスタマーサポート部門が、問い合わせ対応に追われています。そこへAIコンサルがやってきて、「問い合わせ対応AIエージェント」を提案する。デモは見事でした。チャット欄に「納期はいつですか」と打つと、エージェントが流暢に、丁寧に答える。役員たちは「おお」とどよめいて、その場でGOサインが出ました。

提案書は100ページありました。最新モデルの構成図、市場規模、競合事例、ロードマップ。プリントアウトすると、ちょっとした卒業論文……いや、電話帳くらいの厚みです。ずっしり。一見、すごーくしっかりして見える。

——ここで、さっきの稟議の話を思い出してください。この100ページに役員が感じた安心は、たぶん「中身が動く確信」ではなくて、「これだけ調べてあるなら大丈夫だろう」という、あの分厚さへの安心です。筆者が電力会社で味わっていた、あの感覚そのまんま。怖いのは、その安心が、本番では一円の役にも立たないことなんですよね。

さて、半年後。鳴り物入りで導入されたエージェントは——現場の、誰にも、使われていませんでした。マル無視です。

なぜか。デモで使われた質問は「よくある質問」ばかりだったんです。でも現場に来る本物の問い合わせは、例外だらけ。「先月の注文番号◯◯の件で、特殊梱包をお願いしていたはずなんですが」「前回クレームを入れた分の代替品、いつ届きますか」。こういう、過去の経緯と社内の事情がからんだ問い合わせに、エージェントは自信満々に間違える。

ここが、致命傷でした。自信満々に間違えるAIは、現場にとって、いないより厄介なんです。 担当者は結局すべてをダブルチェックするはめになる。「これなら自分でやったほうが早い」。そう気づいた瞬間に、エージェントは静かに見捨てられます。100ページのどこにも、「誰の」「どの業務の」「どの瞬間を」楽にするのか、具体的には書かれていなかった。書いてあったのは、立派な構想だけでした。

なぜ「動くデモ」は「使われる業務」にならないのか

デモと本番運用のあいだには、川どころか、谷があります。多くのプロジェクトは、この谷で落ちる。理由はわりと単純で、デモは「動くこと」を証明するために作られ、本番は「使われ続けること」を求められるから。求められているものが、最初から違うんですよね。

谷を生む原因は、だいたい次の3つに集約されます。

• 技術先行：最新モデルを使うこと自体が目的になって、「誰のどの仕事が楽になるのか」が後回しになる
• UX不在：エージェントの賢さばかりが語られて、人がそれをどう呼び出し、どう信頼し、どう直すのかが設計されていない
• 業務接続の欠落：既存の業務フロー・権限・データ・例外処理につながっておらず、現場の“最後の一歩”で詰まる

とくに見落とされがちなのが、2つ目です。

これ、実は仕事とは関係ないところで腹落ちした感覚がありまして。少し脱線させてください。筆者はスノボ好きと釣り好きが高じて長野に移住したクチで、スキマ時間にはリンゴやブドウを育てる果樹農家のお手伝いをしたりしながら暮らしています。あるとき、農園主さん（70代です）と「いやあ、人手が足りなくて」という話をしていて、短時間だけ働き手を集められる求人アプリ――最近よくある、空いた数時間にスポットで人を呼べるやつ――の存在が話題に出ました。便利そうじゃないですか。実際、よくできたアプリなんです。

でも、農園主さんには使えませんでした。スマホの細かい操作がそもそもつらい。応募者とのチャットのやりとり、本人確認、当日のドタキャンへの対応……一つひとつが、彼の手と段取りに馴染まない。そして果樹農家は全国的に高齢化が進んでいるので、これは彼ひとりの話じゃないんです。業界まるごとで、「便利なはずの道具」が現場に届いていない。

賢さとか、機能の多さの問題じゃないんですよね。「その人の手と、目と、段取りで、その場で本当に使えるか」のほうが、ずっと手前に立ちはだかる。

AIエージェントも、まったく同じです。現場の担当者の「手と目と段取り」に合っていなければ、どれだけ賢くても、誰も触らないボタンになる。世にあふれる「AIエージェント コンサル」の提案の多くは、この“現場の手”を一度も見ないまま、設計図だけを描いている。だから、流暢なのに使われないんです。 件のアプリは農家の方専用のアプリではなく、広い業種に対応できる設計だったと思います。しかし、「農業」がそのアプリの使い勝手のせいで図らずもこぼれ落ちていたのは明白でした。

さて、文句はこのへんにしておきましょう。大事なのは「で、どうするの」ですよね。ここから先は、さっきのメーカーが、もし最初から地味なやり方を選んでいたら何が起きたか、という話をします。

同じプロジェクトを、地味なやり方でやり直す

巻き戻しましょう。同じメーカー、同じ「問い合わせが多すぎる」という悩み。ただし今度は、モデルの話から始めません。順番に見ていきます。

ステップ0：モデルの話を、いったん全部やめる

最初にやるのは、どのモデルを使うかでも、アーキテクチャ図を描くことでもありません。「現場の一日」を、ただ観察することです。

筆者がAIエージェントの案件で最初にやるのは、たいていカスタマーサポートの席のうしろに座って、一日ぼーっと眺めることです。誰が、どのタイミングで、どんな問い合わせに、何分かけて、どこで手が止まっているのか。地味です。でも、これをやらずに作るのは、行ったこともない畑のために道具を選ぶようなもの。たいてい、的を外します。

ステップ1：いちばん効く「一点」だけを選ぶ

観察すると、見えてきます。問い合わせの中身は、実はわりときれいに分かれている。「配送状況の確認」みたいに、答えが定型的で量が多いものと、「クレームの経緯がからむ相談」みたいに、判断が要るけど量は少ないもの。

ここで、欲張らないことです。全部に答えるエージェントではなく、「配送状況の一次回答」という一点だけを狙う。あれもこれもできる賢い相棒、を最初から目指すほど、皮肉なことに、何にも使われないものが出来上がります。狭く始めるほど、確実に役に立てる。

ステップ2：人間が「どこで手綱を握るか」を設計する

ここがいちばん大事で、いちばん飛ばされる工程です。

「AIが自動で返信する」ではなく、「AIが下書きを作って、担当者がワンクリックで承認して送る」にします。AIは一次回答の文面を用意するところまで。送信ボタンを押すのは人間。担当者から見れば、ゼロから書く手間が消えて、確認と微修正だけになります。

そして、AIが「これは自信がない」と判断した問い合わせ（例外、クレーム、過去の経緯つき）は、自動で人間にエスカレーションする。自信満々に間違えさせない。 「わからないときは、わからないと言って人に渡す」。これを設計に組み込むだけで、現場の信頼はまるで変わります。さっきの“いないより厄介なAI”が、ここで“ちゃんと頼れる下働き”に変わるんです。

ステップ3：既存の仕組みに、無理なくつなぐ

配送状況を答えるには、配送管理システムの中を見にいく必要があります。だから、そこに接続する。どの担当者がどこまで見ていい権限なのか、例外のときは誰に渡すのか。地味な工程です。でも、この「つなぎ込み」をやらないと、エージェントは社内の現実から切り離された“賢いおもちゃ”のままで終わります。

ステップ4：狭く出して、「効いた」を一つ作ってから広げる

3週間後。「配送状況の一次回答」だけをやる、ものすごく地味なエージェントが動き始めます。派手さはありません。役員に見せても「え、これだけ？」と言われるかもしれない。昔の筆者の感覚でいえば、稟議には通しにくい“薄さ”です。

でも現場では、一次回答のほとんどをAIが下書きするようになって、担当者の手が目に見えて空いた。毎日、使われている。 ここで初めて、「次はこの問い合わせ種別も」と横に広げていきます。一点で「効いた」を作ってから広げる。これが、現場で生き残るエージェントの育て方です。

ビフォーアフター ― 何が変わったのか

同じプロジェクトの、ビフォーとアフターを並べてみます。

ビフォー：100ページの分厚い提案書。最新モデルを謳う流暢なデモ。役員は感動、現場は半年後に誰も使っていない。残ったのは、立派な構想と、見捨てられたエージェント。

アフター：提案書はA4で数枚。「対象業務（配送の一次回答）」「人間の介入点（承認とエスカレーション）」「接続先（配送システム）」「成功の測り方（担当者の処理時間）」しか書いていない。代わりに、地味だけど毎日使われるエージェントが、ちゃんと動いている。

電話帳並みだった分厚い資料は数枚に縮んで、その代わりに、現場で本当に動くものが残りました。インクの無駄遣いが減って、仕事も減った。

差を生んだのは、モデルの性能ではありません。体験設計（どう使われるか）と、業務接続（どこに組み込まれるか）です。同じ基盤モデルを使っても、片方は「賢いけど使われないデモ」になり、もう片方は「地味だけど毎日使われる業務の一部」になる。分かれ道は、次の問いに最初から答えているかどうか、なんですよね。

• 誰の、どの業務の、どの瞬間を肩代わりするのか
• 人はどこで介入して、どこで承認して、どこで訂正するのか
• 間違えたとき、現場はどう気づいて、どうリカバリーできるのか
• 既存のツール・権限・データに、どう無理なくつなぐのか

これは「モデルを選ぶ」問題ではなくて、「体験と業務を設計する」問題です。だからAIエージェント開発は、モデルの議論から始めてはいけない。使う人の現実から始めるべきなんです。

発注する人へ ― 提案書の厚さの代わりに、何を見るか

最後に、これから「AIエージェントを作れます」という提案を受ける人へ。AIエージェント コンサルを名乗る相手を見極めるとき、見てほしいのは、デモの流暢さでも、提案書の厚さでもありません。たった一点です。

「うちの、誰の、どの仕事の、どの瞬間を楽にするんですか？」 と、聞いてみてください。ここに、具体的に・現場の言葉で答えられる相手は、たぶん信用できます。逆に、最新モデルの名前と市場規模の話に戻っていってしまう相手は……あの分厚い稟議書を、もう一度あなたに渡そうとしているのかもしれません。

派手なデモを作ること自体は、正直、それほど難しくないんです。難しいのは、半年後も現場で静かに使われ続けるものを残すこと。逆張りに聞こえるなら、それは業界がいかに“デモ”と“分厚さ”に最適化されてきたか、の裏返しでもあります。

「作れます」ではなく「使われ続けます」と言えるかどうか。発注先を選ぶ基準は、そこに置いていいと思います。あの日の筆者が、薄い資料でも胸を張れていたら、たぶんもっといい仕事ができたはずなので。

---

この記事は、ARCHECOが運営するメディア「AI・新規事業戦略大学」でお届けしました。ARCHECOは、UI/UXデザインとプロダクト開発を強みに、お客さまと並走しながら「使われるもの」をつくっているチームです。ご相談・お問い合わせはこちらからどうぞ。

ベンダー選定のよくある質問

ベンダー選定とは何ですか？

システムやサービスの開発・導入を任せる外部の会社を、複数の候補から選び出すことです。発注側が主体になって進めます。選ぶ作業そのものより、何をもって選ぶかを先に決めることのほうが難しく、そして効きます。基準が無いまま提案を並べると、いちばん印象がよかったところが選ばれます。

ベンダー選定は、どのような手順で進めますか？

3段階です。事前調査（候補を洗い出し、RFI＝情報提供依頼書で比較できる形の情報を集める。この段階では提案を求めません）、選定準備（候補を絞り、RFP＝提案依頼書を出す。同時に社内で選定基準を決める）、評価・選定（提案書を評価項目に沿って採点し、必要ならプレゼンテーションと質疑を経て1社を決める）。依頼するのは3社前後が実務的で、社数より同じ条件で依頼することのほうが効きます。

ベンダー選定の評価基準には、何を入れればよいですか？

9項目が基本です。事業の継続性と安定性、得意分野と技術力、過去の実績、要件の網羅性と実現度、費用の妥当性、納期の妥当性、開発と保守の体制、セキュリティ体制、提案とプレゼンテーション。一般的な雛形をそのまま使うのではなく、この案件で何を実現したいかから逆算し、採点できる粒度まで割ってください。技術力のような大きな項目は、そのままでは採点者ごとに解釈が割れます。

評価の配点は、どう決めればよいですか？

重視する成果に合わせて配点を変えます。全項目を同じ点数にすると優先順位が消えます。採点は4段階など段階を決めて行い（10段階にすると採点者ごとの尺度の差が出ます）、各段階が何を指すかを言葉で定義してください。たとえば4は「今回と同じ規模の実績が複数ある」のように書きます。定義の無い4段階は、印象を数字に置き換えているだけになります。

評価基準は、いつ決めればよいですか？

RFPを出す前です。提案を受け取ってから評価項目を作ると、結果を見てから基準を作ることになり、選びたいところが選ばれる基準ができあがります。関係する部署（事業側・情報システム・法務・購買）で項目と配点に合意を取っておくと、選定結果を説明するときに、後から基準を作ったのではという疑いが立ちません。

ベンダー選定でよくある失敗は何ですか？

5つです。要件が固まらないまま選定を始めた（比べる軸が無いので印象で決まる）、費用の安さだけで決めた、提案書とデモの出来で決めた、実績の社名だけを見た（今回に近い案件か、担当者が残っているかを確かめていない）、選定の記録を残さなかった。3つ目がいちばん自覚しにくく、評価表を作り配点も決めていたのに起きます。

シングルベンダーとマルチベンダーは、どう選べばよいですか？

責任の所在の話として考えてください。シングルベンダーは1社でまとめて引き受けるため窓口が1つで済みますが、その1社に依存します。マルチベンダーは得意分野ごとに選べる代わりに、不具合が出たときにどちらの責任かを発注側が裁く必要があります。裁ける体制が社内に無いなら、シングルのほうが実務は回ります。

ベンダーを決めたあとには、何をすればよいですか？

4つです。契約形態（請負か準委任か）と仕様変更の扱いを決める、発注側が用意するもの（データ・担当者の時間・承認の段取り）を確定させる、進捗を確認する頻度と動くものを見せてもらう間隔を決める、選定時の評価項目を発注後の管理項目へ引き継ぐ。2つ目を決めていない発注は、ベンダーをどれだけ丁寧に選んでも遅れます。止まる原因が発注側の中にあるためです。