IPAのベンダー選定評価表に発注側が足すべき3項目——引き継ぎ・要員・追加単価

IPAの雛形で何がカバーされているか

IPAが公開するベンダー選定の評価雛形は、情報システム調達の実務に沿って設計されており、機能要件・非機能要件・会社概要・導入実績など、評価の骨格を整えるうえで有用なツールです。フォーマットが整っているため、選定担当者が「これで足りる」と感じるのは自然なことでしょう。

ただし、この雛形が想定しているのは主に「どのベンダーを選ぶか」という初期選定の場面です。発注側にとって重要な「選んだ後」の関係が、ほとんど評価されない構造になっています。評価の軸をどこに置くかという上流の設計についてはベンダー選定の基準は比較表より先に決まるで整理していますが、本稿では評価表そのものの補完に絞って扱います。

発注側が追記すべき3つの項目

以下の3点は、IPA雛形をそのまま使う場合に抜けやすく、かつ発注側のリスクが高い項目です。

1. 保守・運用の引き継ぎ体制　システムリリース後にベンダーが変わることは珍しくありません。契約終了や途中解約の際に、ソースコード・設計書・環境情報がどのような形で引き渡されるかを、選定時点で明確にしておく必要があります。

- ドキュメントの整備水準と納品形式 - 次のベンダーへの移行支援期間・内容 - 知的財産権の帰属（発注側に戻るか否か）

1. 担当要員の交代と通知義務　プロジェクトのキーマンが途中で変わると、品質とスケジュールの両面に影響します。選定段階で確認しておくことで、契約後のトラブルを減らせます。

- 主担当者・PMの交代時の事前通知義務（最低期間） - 代替要員のスキル要件と発注側の承認プロセス - チーム構成の固定度合い（外注比率の開示）

1. 追加開発の単価と見積り条件　初期開発の費用は提案書で比較できますが、機能追加や仕様変更の費用は選定後に初めて提示されることが多い項目です。評価段階で確認しないと、後から割高な単価を受け入れるか、ベンダーを替えるかという二択に追い込まれます。

- 追加開発の時間単価・工数見積りの根拠 - 機能追加・設計変更の見積り提出期限 - 単価の有効期間（何年間保証されるか）

「引き継ぎできる」と「引き継ぎしやすい」は別物です。3点とも提案書への記載を求める形で問わなければ、比較の土俵が揃いません。

AI導入の見積書で確認する5つの観点でも触れているように、費用の「理由」を選定前に聞き出す習慣が、長期的なコスト管理につながります。同じ姿勢は、ベンダー選定の評価設計にも当てはまります。

評価表を実効性あるものにするために

追記した項目は、評価表に加えるだけでは機能しません。RFP（提案依頼書）に記載要件として組み込み、各ベンダーへ事前に周知することで初めて比較が成立します。事前周知なしでは、ベンダーごとに回答粒度が異なり、評価の公平性が保てません。

また、未回答・回答不備の項目を評価基準に明記しておくと、提案書の質そのものが上がります。「確認したかったが提案書に書かれていなかった」という事態を、選定前に防ぐことができます。

IPAの雛形は使えないのではありません。標準的な調達向けに設計されたツールとして正しく位置づけ、自社の目的と契約後のリスクに応じて補完することが、実際の調達業務に即した使い方です。

ベンダー選定の設計や発注整理でお困りの場合は、DX伴走支援「しぼる」からご相談ください。