システム開発を外部へ依頼するとき、

「複数の開発会社から提案をもらったが、どこを選べばよいか分からない」

「見積金額が一番安い会社を選んでも問題ないのか」

「技術力の違いをどう判断すればよいのか」

と悩むことがあります。

システム開発では、ベンダー選定がプロジェクトの成否に大きく影響します。

同じ要件で提案を依頼しても、

A社
開発費：300万円

B社
開発費：450万円

C社
開発費：600万円

のように価格が異なることがあります。

しかし、

最も安い会社
=
最も良い開発会社

とは限りません。

例えばA社の300万円には、

データ移行なし

保守なし

要件定義は発注者側

テスト範囲が限定的

という条件があり、B社の450万円には、

要件定義

データ移行

テスト

リリース支援

3か月の初期保守

まで含まれている可能性があります。

金額だけでは比較できません。

システム開発のベンダー選定では、

• 要件を理解しているか
• 類似システムの経験があるか
• 適切な提案ができるか
• 開発体制に問題がないか
• 費用の範囲が明確か
• コミュニケーションしやすいか
• 開発後も保守できるか

などを総合的に評価することが重要です。

この記事では、システム開発会社・ITベンダーを選定するときの比較項目、評価表の作り方、面談で確認したい質問、失敗しないためのポイントまで解説します。

ベンダー選定とは

ベンダー選定とは、

システム開発を依頼する企業・開発会社を比較し、プロジェクトに最も適した依頼先を決めること

です。

一般的には、

システム化を検討

↓

業務・課題整理

↓

RFP・提案依頼

↓

複数社から提案

↓

提案内容の比較

↓

面談・プレゼン

↓

ベンダー評価

↓

候補決定

↓

契約条件確認

↓

契約

という流れで進みます。

小規模なシステム開発では、正式なRFPを作らず、

業務内容

必要機能

予算

希望時期

をまとめて数社へ相談するケースもあります。

どちらの場合でも重要なのは、できるだけ同じ条件で候補会社を比較することです。

ベンダー選定で比較したい10項目

システム開発会社を比較するときは、主に次の10項目を確認します。

評価項目	確認内容
1. 要件理解	業務・課題を理解しているか
2. 提案力	要望以上の改善提案があるか
3. 開発実績	類似案件の経験があるか
4. 技術力	必要なシステムを実現できるか
5. 開発体制	PM・開発者の体制は十分か
6. 進め方	要件変更・進捗管理方法は適切か
7. 費用	金額と対象範囲は妥当か
8. スケジュール	現実的な計画になっているか
9. コミュニケーション	相談・意思疎通しやすいか
10. 保守・運用	リリース後も支援できるか

順番に解説します。

1．要件・業務への理解度

最初に確認したいのが、

自社が何に困っているのかを
本当に理解しているか

です。

例えばRFPで、

営業担当者ごとにExcelで
顧客情報を管理している。

担当者変更時に情報が引き継がれず、
営業管理者も案件状況を把握できない。

と伝えたとします。

良い提案であれば、

今回の目的は単なるExcelのWeb化ではなく、

・顧客情報の一元管理
・案件状況の可視化
・営業履歴の共有
・属人化の解消

だと理解しています。

という形で課題を整理しているでしょう。

一方、

顧客登録

顧客検索

CSV出力

という機能一覧だけを返してくる会社の場合、業務課題まで理解しているか確認が必要です。

提案書の冒頭を見る

提案書の、

背景

課題認識

目的

を見ると理解度が分かりやすくなります。

自社が伝えた内容をそのままコピーしているだけなのか、

なぜこのシステムが必要なのか

まで整理されているのかを比較します。

2．提案力

ベンダー選定では、

言ったものを作れる会社

だけでなく、

目的に合った方法を提案できる会社

を選ぶことが重要です。

例えば発注者が、

CSV出力機能が必要です

と伝えたとします。

良いベンダーであれば、

CSVは何に利用しますか？

と確認します。

すると、

毎月会計システムへ
取り込むためです。

と分かるかもしれません。

そこで、

CSVによる手作業ではなく、
API連携できないか確認しましょう。

と提案できる会社の方が、業務改善という目的に近づく可能性があります。

要望をすべて肯定する会社がよいとは限らない

例えば、

AIを入れたい

アプリも欲しい

ダッシュボードも欲しい

という要望に対して、

全部できます。

と回答する会社より、

今回の目的を考えると、
AI機能は初回リリースでは不要だと思います。

まず顧客・案件管理を完成させ、
利用データが蓄積してから追加した方が
費用対効果が高いでしょう。

と説明できる会社の方が適切なケースもあります。

3．類似システムの開発実績

次に、過去の開発経験を確認します。

例えば在庫管理システムなら、

在庫管理

販売管理

入出庫管理

倉庫管理

業務システム

などの経験が参考になります。

必ずしも、

自社と完全に同じシステム

を作った経験が必要なわけではありません。

重要なのは、

似た業務

似た技術

似た規模

似た難易度

の開発経験があるかです。

実績で確認したいこと

単に、

業務システムの開発実績多数

ではなく、

どのようなシステムか

どの工程を担当したか

何人で開発したか

どのくらいの期間か

どの技術を使ったか

どのような課題を解決したか

まで確認すると判断しやすくなります。

4．技術力

技術力は重要ですが、

最新技術をたくさん知っている

ことだけが評価基準ではありません。

重要なのは、

今回のシステムに
適切な技術を選択できるか

です。

例えば社員20人向けの小規模な社内システムに、

Kubernetes

複雑なマイクロサービス

大規模分散DB

を導入しても、過剰設計になる可能性があります。

一方、

将来的に数万人が利用するサービス

なら、拡張性を考えた設計が必要です。

技術選定理由を聞く

例えば、

なぜこの技術を使うのですか？

と質問します。

回答が、

最近人気だからです

だけなら注意が必要です。

理想的には、

・開発速度
・運用負荷
・採用難易度
・将来の拡張
・クラウド費用
・保守性

などを踏まえて説明できることが望ましいでしょう。

5．開発体制

会社として実績があっても、

今回の案件を
誰が担当するのか

は別問題です。

確認したいのは、

PM

要件定義担当

設計担当

開発担当

テスト担当

などです。

営業担当者だけで判断しない

提案段階では非常に詳しい営業担当者が対応していても、

契約後は別のPM・エンジニア

になる場合があります。

可能であれば契約前に、

実際に担当予定のPM

メインエンジニア

とも話します。

特に要件定義から依頼する場合、PM・SEとの相性は重要です。

6．プロジェクトの進め方

システム開発では、途中で要件変更・追加要望が発生することがあります。

そのため、

変更が発生した場合
どう管理するのか

を確認します。

確認したい項目

進捗報告の頻度は？

定例会は？

タスクはどう管理する？

課題管理方法は？

仕様変更はどう管理する？

追加費用はどのタイミングで発生する？

成果物は何を作る？

などです。

「柔軟に対応します」だけでは判断しない

例えば、

仕様変更にも柔軟に対応します

では具体性がありません。

確認したいのは、

変更要求

↓

影響範囲確認

↓

追加工数確認

↓

発注者承認

↓

開発

のような変更管理方法です。

7．費用

もちろん費用も重要です。

ただし、

見積総額

だけで比較しないことがポイントです。

例えば、

項目	A社	B社
要件定義	含む	別料金
設計	含む	含む
開発	含む	含む
テスト	含む	含む
データ移行	含まない	含む
リリース	含む	含む
初期保守	なし	3か月

なら、

A社：
300万円

B社：
400万円

でも単純比較できません。

見積で確認したい項目

要件定義

設計

UIデザイン

開発

テスト

データ移行

インフラ構築

リリース

PM

マニュアル

研修

保守

など、どこまで含まれているか確認します。

8．スケジュール

価格が安くても、

希望リリース日に
間に合わない

なら選定できない場合があります。

しかし、

どこよりも短納期

だからよいとも限りません。

例えば他社が6か月必要としているシステムを、

2か月でできます

と提案している会社があれば、

なぜ2か月で可能なのか

を確認します。

理由が、

既存パッケージを活用する

類似システムをベースにする

十分な開発人数を配置する

なら合理的かもしれません。

一方、明確な根拠がなければリスクがあります。

9．コミュニケーション

見落とされやすいですが、非常に重要です。

システム開発では数か月から数年にわたり、

要件確認

仕様確認

課題

変更

障害

などのコミュニケーションが発生します。

そのため、

質問への回答が分かりやすい

専門用語をかみ砕いて説明できる

分からないことを分からないと言える

リスクを事前に説明する

回答が極端に遅くない

ことも重要です。

初回打ち合わせ自体が評価材料になる

例えば、

こちらの話を聞かず
自社サービスの説明ばかりする

会社と、

現在の業務はどうなっていますか？

この機能が必要なのはなぜですか？

この作業は本当にシステム化が必要ですか？

と質問する会社では、要件定義の進め方にも違いが出る可能性があります。

10．運用・保守

システムはリリースして終わりではありません。

例えば、

障害

ブラウザ更新

OS更新

ライブラリ更新

外部API変更

セキュリティ対応

追加機能

などがあります。

そのため、開発後についても確認します。

確認したい内容

保守契約は可能か？

月額はいくらか？

何が保守範囲か？

障害受付時間は？

緊急対応は？

軽微な修正は含まれる？

追加開発は可能か？

長期利用する業務システムなら、保守体制も重要な評価項目です。

【コピペ用】ベンダー選定評価表

複数社を比較する場合は、評価表を作ると判断しやすくなります。

例えば100点満点で評価します。

評価項目	配点
要件・業務理解	20
提案内容	15
類似実績	10
技術力	10
開発体制	10
プロジェクト管理	10
費用	10
スケジュール	5
コミュニケーション	5
運用・保守	5
合計	100

例えば3社を評価すると、

評価項目	A社	B社	C社
要件理解	18	15	12
提案	14	12	10
実績	8	10	7
技術	8	9	8
体制	8	8	7
管理	8	7	6
費用	7	5	10
スケジュール	4	5	4
コミュニケーション	5	4	3
保守	4	5	3
合計	84	80	70

この例では、

C社
=
最も安い

としても、総合評価ではA社になる可能性があります。

評価項目には重み付けする

すべて同じ点数にする必要はありません。

例えば、

複雑な業務システム

なら、

要件理解

提案力

PM能力

を重視します。

一方、

仕様が完全に決まっている
単純な開発

なら、

費用

納期

技術力

の比率を上げてもよいでしょう。

重要なのは、

提案書を見てから
都合よく評価基準を変えない

ことです。

可能であればRFPを配布する前に評価基準を決めます。

ベンダーへ面談で確認したい質問

提案書だけでなく面談・プレゼンで確認します。

要件理解

今回のシステム開発で
最も重要な課題は何だと考えていますか？

相手が今回の目的を理解しているか確認できます。

提案

当社が提示した要求の中で、
不要だと思うものはありますか？

単なる御用聞きではなく、提案できる会社か確認できます。

技術

なぜ今回この技術構成を
選んだのでしょうか？

技術選定理由を確認します。

リスク

今回のプロジェクトで
最も大きいリスクは何だと考えていますか？

重要な質問です。

経験のある会社ほど、

データ移行

業務ルールの未確定

外部API

納期

など、具体的なリスクを提示できる傾向があります。

体制

契約後、実際に担当するPMは
どなたですか？

営業担当だけでなく実際の担当者を確認します。

要件変更

開発途中で仕様変更が発生した場合、
どのように進めますか？

変更管理方法を確認します。

障害

リリース後に重大障害が発生した場合、
どのような体制で対応しますか？

保守体制を確認できます。

ベンダー選定の流れ

一般的には次の流れで進めます。

STEP1｜システム化の目的を整理する

まず、

なぜシステムを作るのか

を整理します。

STEP2｜要件を整理する

少なくとも、

背景

目的

対象業務

利用者

主要機能

非機能要件

予算

納期

を整理します。

STEP3｜候補ベンダーを探す

例えば、

検索

紹介

開発会社比較サービス

クラウドソーシング

過去取引先

などから候補を探します。

最初は5〜10社程度を確認し、実績・会社規模・技術領域などから3〜5社程度へ絞る方法があります。

STEP4｜同じ条件で提案を依頼する

複数社へ同じRFP・要件資料を渡します。

STEP5｜質問へ回答する

各社から質問があれば回答します。

比較の公平性を重視する場合は、重要な追加情報を各社で共有します。

STEP6｜提案書・見積を確認する

評価表を使い、

提案

費用

実績

体制

技術

スケジュール

を比較します。

STEP7｜面談・プレゼンを実施する

書面だけで判断せず、

PM

責任者

エンジニア

などと話します。

STEP8｜上位候補を絞る

例えば、

5社
↓
3社
↓
2社

へ絞ります。

STEP9｜条件を詳細確認する

最終候補について、

見積範囲

成果物

保守

契約

追加費用

開発体制

を確認します。

STEP10｜契約する

条件に合意したら契約・要件定義へ進みます。

開発会社の規模は大きい方がよい？

必ずしもそうではありません。

大手ベンダー

メリット：

大規模案件への対応

体制を組みやすい

管理プロセスが整っている

長期保守を依頼しやすい

一方、

費用が高くなりやすい

意思決定に時間がかかる

実際の開発が再委託になる

場合があります。

中小開発会社

メリット：

柔軟に対応しやすい

意思決定が早い

費用を抑えやすい

一方、会社によって技術力・管理力の差があります。

フリーランス・小規模チーム

メリット：

費用を抑えやすい

担当者と直接話せる

柔軟性が高い

一方、

大規模開発

24時間保守

複数人での長期運用

などには向かない場合があります。

重要なのは、

会社の大きさ

ではなく、

今回のプロジェクト規模に
適した体制か

です。

技術スタックだけで選ばない

例えば、

Reactが使える会社

Pythonが使える会社

だけで選定するのはおすすめできません。

システム開発では、

業務理解

要件定義

DB設計

セキュリティ

テスト

運用

プロジェクト管理

なども必要です。

特に業務システムでは、

コードを書ける

だけではなく、

複雑な業務を
システム要件へ整理できる

能力が重要です。

安すぎる見積にも注意する

例えば3社の見積が、

A社：
450万円

B社：
500万円

C社：
120万円

だった場合、

C社が圧倒的に安いから決定

とする前に理由を確認します。

例えば、

要件定義が含まれていない

テストが限定的

データ移行なし

PM費用なし

保守なし

一部機能を見積から除外

などかもしれません。

逆に、

既存システムを再利用できる

ノーコード・SaaSを活用する

など合理的な理由で安い可能性もあります。

重要なのは、

なぜこの金額なのか

を説明してもらうことです。

ベンダーロックインにも注意する

システム開発では、

開発会社を変更できない

状態になる場合があります。

例えば、

ソースコードを渡してもらえない

独自技術で他社が保守できない

アカウントをベンダーが所有

クラウド契約をベンダー名義で管理

などです。

契約前に、

ソースコードの扱い

Gitリポジトリ

クラウドアカウント

ドメイン

DB

ドキュメント

の管理主体を確認します。

長期運用するシステムほど重要です。

再委託の有無も確認する

営業会社と実際の開発会社が異なる場合があります。

再委託自体が問題というわけではありません。

ただし、

誰が設計するか

誰が開発するか

誰がPMするか

誰が障害対応するか

は確認しておきます。

特に、

営業会社
↓
一次受け
↓
二次受け
↓
開発者

と階層が深い場合、情報伝達・費用・対応速度に影響する可能性があります。

契約前に確認したいチェックリスト

最終候補が決まったら、次を確認します。

【開発範囲】

□ 何が見積に含まれているか

□ 何が対象外か

□ データ移行は含むか

□ インフラ構築は含むか

□ リリース作業は含むか


【費用】

□ 見積内訳

□ 追加費用が発生する条件

□ 月額費用

□ クラウド費用

□ 外部サービス費用


【体制】

□ PMは誰か

□ 開発人数

□ 実際の開発会社

□ 再委託有無


【成果物】

□ ソースコード

□ 設計書

□ テスト結果

□ 操作マニュアル

□ Gitリポジトリ


【保守】

□ 保守費

□ 保守範囲

□ 対応時間

□ 障害対応

□ 追加開発


【権利・アカウント】

□ ソースコードの権利

□ クラウドアカウント

□ ドメイン

□ DB

□ 各種APIアカウント

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

失敗1｜最安値だけで選ぶ

見積範囲が違えば単純比較できません。

失敗2｜提案書の見栄えで判断する

きれいな資料と開発力は別です。

失敗3｜会社実績だけを見る

会社に実績があっても、今回の担当チームに同じ経験があるとは限りません。

失敗4｜営業担当者だけと話す

実際のPM・開発担当者も確認します。

失敗5｜技術力だけで決める

業務システムでは要件整理・PM・運用能力も重要です。

失敗6｜保守を確認しない

リリース後に保守先がなくなる可能性があります。

失敗7｜対象外を確認しない

安い見積に必要な作業が含まれていない場合があります。

失敗8｜評価基準を後から決める

提案を見てから基準を決めると、担当者の好みに左右されやすくなります。

ベンダー選定で最も重要なのは自社の目的に合う会社か

例えば、

有名企業との実績多数

エンジニア500名

最新技術を採用

という会社でも、

予算200万円の
小規模業務システム

には合わない可能性があります。

一方、社員数の少ない開発会社でも、

中小企業の業務システム

要件定義

Excel業務のWeb化

小規模開発

を得意としているなら、今回のプロジェクトに合う可能性があります。

つまり、

一番すごい会社

ではなく、

今回のプロジェクトに
一番合う会社

を探します。

ベンダー選定に関するよくある質問

ベンダーは何社くらい比較すればよいですか？

案件規模によりますが、最終的な提案比較は3〜5社程度にすると比較しやすいでしょう。

候補調査段階では、さらに多くの会社を確認しても構いません。

一番安い会社を選ばない方がよいですか？

安いこと自体に問題はありません。

重要なのは、

なぜ安いのか

を確認することです。

必要な開発範囲を満たし、合理的な理由で安ければ有力候補になります。

開発実績はどの程度重視すべきですか？

重要ですが、完全に同じシステムの実績が必須とは限りません。

類似する業務・技術・規模・難易度の経験を確認します。

ベンダー評価表は必要ですか？

複数社を比較するなら作成をおすすめします。

担当者の感覚だけでなく、

要件理解

提案

技術

費用

体制

保守

などを同じ基準で比較できます。

技術に詳しくない場合、どう選べばよいですか？

技術名そのものより、

なぜその構成なのか

他にどんな選択肢があるのか

費用・保守・拡張性にどう影響するのか

を説明してもらいます。

専門用語を分かりやすく説明できるかも評価材料になります。

ベンダー選定前にRFPは必要ですか？

必須ではありません。

ただし複数社を比較する場合は、

背景

目的

対象範囲

主要要件

予算

希望時期

提案してほしい内容

を揃えた資料を渡した方が比較しやすくなります。

hiro-dev-labの要件整理・システム開発支援

hiro-dev-labでは、Webシステム・業務システムについて、開発だけでなく要件整理から対応しています。

例えば、

• 現状業務のヒアリング
• 業務フロー整理
• 業務課題の洗い出し
• システム化範囲の整理
• 業務要件・機能要件整理
• 非機能要件整理
• RFP作成に必要な要件整理
• 技術構成の検討
• データ・権限設計
• 外部システム・API連携
• Java・Python・TypeScriptによるWebシステム開発
• リリース後の保守・機能追加

などを検討できます。

例えば、

Excel業務を
システム化したい

↓

何を作ればよいか
まだ整理できていない

という段階であれば、

現状業務をヒアリング

↓

課題を整理

↓

システム化する範囲を整理

↓

必要な要件を定義

↓

技術・費用・スケジュールを検討

↓

設計・開発

という形で進められます。

ベンダー選定は「会社選び」ではなく「プロジェクトを一緒に進める相手選び」

システム開発は、完成済みの商品を購入するのとは異なります。

開発途中には、

追加要望

仕様変更

技術課題

データ問題

スケジュール調整

などが発生する可能性があります。

そのためベンダー選定では、

価格

技術

実績

だけではなく、

課題を理解してくれるか

リスクを正直に説明するか

相談しながら進められるか

変更へ適切に対応できるか

長期的に保守できるか

まで確認することが重要です。

ベンダー選定では、

1．システム化の目的を整理する

2．要件を整理する

3．複数社へ同じ条件で提案を依頼する

4．評価基準を事前に作る

5．要件理解・提案・技術・費用を比較する

6．実際のPM・担当者と面談する

7．見積範囲・対象外を確認する

8．保守・運用まで確認する

9．契約条件を確認する

10．総合評価で選定する

という流れで進めると、金額だけに左右されず、自社に合った開発会社を選びやすくなります。

「複数の開発会社から見積を受けているが比較方法が分からない」

「システム開発会社を探している」

「要件がまだ整理できていない」

「要件定義から設計・開発まで相談したい」

といった段階からでも、システム化の検討を進めることができます。

要件定義・業務システム開発について相談する