システム開発のベンダー選定基準6項目｜失敗しない評価シートの作り方

—Free Download / 資料ダウンロード

失敗しないためのアプリ開発の考え方と開発パートナー選定チェックリスト

この資料でわかること

アプリ開発（スマートフォンアプリ・Web アプリ）の発注・開発を検討している企業の担当者が、開発パートナーを選ぶ際に「何を確認すべきか」「どのような観点で比較すべきか」を体系的に把握できる実践的なチェックリストを提供する。

こんな方におすすめです

• アプリ開発を検討しているが失敗したくない
• 開発パートナーの選び方が分からない
• アプリの形式選定やUI/UX設計の確認ポイントを知りたい

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

はじめに

「複数のシステム開発会社から提案をもらったけど、どうやって比較すればいいのか分からない」「価格が違いすぎて判断できない」「選んだ会社で失敗したくない」——システム開発の発注を初めて担当する方から、こうした声をよく聞きます。

ベンダー選定で最も多い失敗の原因は、「明確な評価基準を持たないまま選んでしまうこと」です。印象や価格だけで選んだ結果、開発途中でトラブルが発生したり、稼働後に保守が機能しなかったりするケースが後を絶ちません。

本記事では、システム開発会社（秋霜堂株式会社・TechBand）の立場から、発注担当者が使えるベンダー選定の評価基準6項目と、選定理由を社内で根拠として説明できるシンプルな評価チェックシートの作り方を解説します。評価シートの配点の決め方、コピーして使える比較表テンプレート、国内ベンダーと海外ベンダーを比較する際の視点まで、実務でそのまま使える形でまとめています。

初めてシステム開発を外注される方、あるいは過去の選定で後悔した経験がある方に特に役立てていただける内容です。

ベンダー選定とは？なぜ「明確な基準」が必要なのか

ベンダー選定とは、システムの開発・構築・運用を依頼する外部委託先（ベンダー）を決める意思決定プロセスを指します。単に「どの会社に頼むか」を決めるだけでなく、プロジェクトの成否に直結する重要な判断です。

なぜ明確な評価基準が必要なのでしょうか。理由は3つあります。

1. 選定を属人化させないため

「なんとなく話が合いそうだから」「担当者の印象が良かったから」という理由だけでは、組織として合理的な意思決定ができません。複数人が同じ基準で評価することで、判断の客観性を保てます。

2. 選定理由を社内で説明できるようにするため

上司や経営陣への報告・承認において「なぜこのベンダーを選んだのか」を数値と事実で説明できることが求められます。評価基準を明確にしておくことで、この説明責任を果たせます。

3. 後悔しない選定のため

ベンダー選定のミスは、プロジェクト途中での追加コスト・スケジュール遅延・品質問題として表れます。後から「あのとき確認しておけば良かった」とならないよう、事前に確認すべき項目を整理しておくことが重要です。

なお、「SIer」「システムベンダー」「受託開発会社」など発注先の種類については別記事で詳しく解説しています。参考にしてください。 （→ SIerとベンダーの違いとは？種類・特徴・発注先の選び方を発注者視点で比較）

ベンダー選定に失敗する3つのパターン

評価基準を学ぶ前に、典型的な失敗パターンを把握しておきましょう。「自分は大丈夫」と思っていても、これらのパターンにはまってしまうケースは少なくありません。

価格が安い業者を選んでしまうパターン

見積もり金額だけを比べて「一番安い会社に頼もう」と決めることはリスクがあります。

最安値の見積もりが出た理由を考えてみてください。工数の見積もりが甘い（後から追加費用が発生しやすい）、保守・サポートが別途有料、品質管理のコストを削減している、などの可能性があります。

「安い理由を確認する」姿勢が重要です。根拠のある見積もりかどうかを必ず確認してください。

担当者の印象・雰囲気で選んでしまうパターン

営業担当者の印象が良くて契約したところ、実際の開発担当者は全く別の人だった、ということはよくあります。

ベンダーを評価するときは「担当者個人の能力・人柄」ではなく「組織としての開発能力・プロセス・管理体制」を評価することが大切です。実際に担当するエンジニアやPMとの面談を依頼することも有効です。

要件定義前にベンダーを決めてしまうパターン

「とりあえず相談してみて気に入ったらそのまま発注した」というケースも多くあります。しかし、要件定義が曖昧な状態でベンダーを決めると、認識のズレが後から表面化し、スコープの膨張（最初の見積もりより大幅にコストが増える）につながりやすくなります。

最低限の要件を文書化してからベンダー選定を始めることで、複数社の提案を同じ条件で比較できるようになります。

ベンダー選定の評価基準6項目

ここからが本記事の核心です。以下の6項目を評価軸として設定することで、ベンダーを客観的かつ根拠のある形で比較できます。

1. 開発実績・技術力

最も重要な評価軸です。「自社が依頼したいシステムに近い案件の実績があるか」を確認します。

確認すべきポイント:

• 類似業界・類似規模の開発実績の有無
• 使用技術スタック（自社が必要とする技術を持っているか）
• 実績の詳細（規模・金額・期間・担当範囲）

たとえば秋霜堂では、「動画校正システムの新規開発（300〜500万円）」「マルチプラットフォームスマホアプリ開発（200〜300万円）」「SNSマーケティング支援システム（SaaS）のMVP開発（200万円〜）」など、業種・規模・技術スタックが多様な実績があります。類似案件の実績を持つかどうかが、プロジェクト成功確率を大きく左右します。

確認すべき質問例:

• 「弊社の案件に近い開発実績を教えていただけますか？」
• 「その案件でのあなたの会社の担当範囲はどこまでですか？」

2. コスト（初期費用・ランニングコスト）

見積もり金額の大小だけでなく、「見積もりの根拠と総コスト」を確認します。

初期費用（開発費）だけでなく、以下も必ず確認してください:

• 保守・運用費（月額または年額）
• 追加開発・機能改修費（単価の目安）
• バグ対応費（無償範囲と有償範囲の境界）

システム開発費用の相場については、別記事で詳しく解説しています。 （→ システム開発の費用相場は？抑えるコツや開発会社を選ぶポイントを解説）

確認すべき質問例:

• 「この見積もりでカバーされていない費用はありますか？」
• 「仕様変更が発生した場合の追加費用はどのように算出されますか？」

3. プロジェクト管理体制

「誰が、どのように、プロジェクトを管理するか」を確認します。

確認すべきポイント:

• PMの経験・実績（類似案件の経験があるか）
• 進捗報告の頻度・手段（週次報告か、チャットツール利用か等）
• 課題管理の方法（課題発生時にどう対応するか）

週次定例ミーティングと課題管理ツールによるトレーサビリティを持つチームは、問題の早期発見と対処が機能しやすくなります。

確認すべき質問例:

• 「プロジェクトマネージャーはどなたが担当されますか？過去の経験を教えてください」
• 「進捗はどのように共有・管理されますか？」

4. コミュニケーション適合性

開発会社との長期的な協働を想定すると、コミュニケーションの「合いやすさ」は重要な選定基準です。

確認すべきポイント:

• レスポンス速度（問い合わせへの返答がどれくらいで来るか）
• 「なぜその技術・なぜその構成か」を分かりやすく説明できるか
• 発注者側の知識レベルに合わせたコミュニケーションが取れるか

初回の打ち合わせ・提案プレゼンでのやり取りを通じて、「この会社とならうまくやっていけそうか」を感じ取ることも判断材料になります。ただし、感覚だけでなく上記の客観的評価軸と組み合わせて総合判断することが大切です。

5. 保守・サポート体制

システムは開発して終わりではなく、稼働後も継続的な保守が必要です。発注前に以下を必ず確認してください。

確認すべきポイント:

• 保守契約の有無と内容（月額費用・対応範囲）
• バグ対応時の無償範囲と有償範囲
• 緊急時（システム障害等）の対応時間・対応体制
• 担当エンジニアが退職した場合の引き継ぎ体制

システム開発の「契約不適合責任（旧：瑕疵担保責任）」は、原則として不具合を知った日から1年以内に請求する必要があります。この期間を超えた後のサポートは別途保守契約が必要になるため、契約前に明確にしておきましょう。

確認すべき質問例:

• 「保守契約の内容と費用を教えていただけますか？」
• 「本番稼働後に重大なバグが発生した場合、どのような対応をしていただけますか？」

6. 会社の安定性・継続性

プロジェクトが長期に渡る場合、ベンダー側の会社が安定して継続していることが重要です。

確認すべきポイント:

• 設立年数・社員数・売上規模の目安（財務的安定性）
• 直近の採用動向（急激な縮小がないか）
• 過去のプロジェクト放棄・途中撤退の事例がないか

特にスタートアップや小規模な会社に依頼する場合、プロジェクト途中での事業縮小・廃業リスクについても念頭に置いておきましょう。

この6項目はBaaSベンダーやAI開発会社の選定にも応用できる

ここまでの6項目は「システム開発会社」を想定した評価軸ですが、考え方自体はより幅広い選定に応用できます。たとえばBaaS（Backend as a Service）ベンダーを選ぶ場合は「開発実績・技術力」を「自社のユースケースに近い導入実績」に、「保守・サポート体制」を「障害時のSLA・サポート窓口の対応時間」に読み替えると評価しやすくなります。

AI開発会社を選ぶ際も同様です。初回ミーティングでは「類似ドメインでのAI開発・チューニング実績」「学習データの取り扱い方針」「運用開始後のモデル精度劣化への対応方針」を6項目の枠組みに当てはめて質問すると、抜け漏れなく確認できます。開発ツールやプラットフォームの選定でも、コスト・サポート体制・拡張性という軸は共通して使えるため、自社が今どのような対象を選定しようとしているかに応じて項目名を読み替えてご活用ください。

—Free Download / 資料ダウンロード

失敗しないためのアプリ開発の考え方と開発パートナー選定チェックリスト

この資料でわかること

アプリ開発（スマートフォンアプリ・Web アプリ）の発注・開発を検討している企業の担当者が、開発パートナーを選ぶ際に「何を確認すべきか」「どのような観点で比較すべきか」を体系的に把握できる実践的なチェックリストを提供する。

こんな方におすすめです

• アプリ開発を検討しているが失敗したくない
• 開発パートナーの選び方が分からない
• アプリの形式選定やUI/UX設計の確認ポイントを知りたい

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。

ベンダー選定プロセス（RFI→RFP→評価の3ステップ）

評価基準が明確になったら、以下の3ステップでベンダーを選定します。

ステップ1: 情報収集（RFI）

RFI（Request for Information: 情報提供依頼書）とは、候補ベンダーに自社の会社情報・開発実績・技術スタック・費用感の目安などを書いて提出してもらう書類です。

3〜5社に送付し、回答内容を比較することで候補を2〜3社に絞り込みます。RFIは詳細な要件書がなくても作成できます。まず「どのような規模・性質のシステムを開発したいか」という概要レベルで作成して構いません。

RFIで確認すべき項目の例:

• 会社概要（設立年数・社員数・資本金・開発拠点の所在地）
• 類似規模・類似業界の開発実績（件数・概要・担当範囲）
• 保有技術スタック・得意な開発領域
• 体制の目安（PM・エンジニアの人数構成、外部委託の有無）
• 概算費用感（レンジで可）と見積もり提示までの期間
• 保守・サポート体制の概要

これらの回答内容を前述の評価基準6項目に沿って整理しておくと、RFI段階で明らかに要件に合わない候補を早期に除外でき、RFP以降の検討工数を絞り込めます。

ステップ2: 提案依頼（RFP）

RFP（Request for Proposal: 提案依頼書）とは、具体的なシステム要件・スケジュール・予算の上限などを記載した上で、候補ベンダーに提案書を提出してもらう書類です。

RFP作成のポイント:

• 目的と背景（なぜシステムが必要か）
• 主要機能・要件（最低限盛り込みたいこと）
• 予算の上限（目安でも記載することで見積もりの精度が上がる）
• スケジュールの希望（いつまでに稼働させたいか）

「要件がまだ曖昧でRFPを書けない」という方は、まず箇条書きレベルで作成し、提案プレゼン時にベンダーと一緒に詳細化する方法が現実的です。

ステップ3: 評価・決定

提案書の内容とプレゼンを総合的に評価し、最終的なベンダーを決定します。

評価は必ず複数人で行い、各自が独立して採点した後に合議する形が望ましいです。「なぜこの点数を付けたか」のコメントを記録しておくことで、選定理由の根拠として使えます。

実践！シンプルなベンダー評価チェックシートの使い方

複数のベンダーを客観的に比較するために、以下のような評価チェックシートを作成します。

評価チェックシートのフォーマット例:

スコアリングは1〜5点の5段階や「○△×」3段階など、複雑にならない方法で行います。評価基準の「配点」は自社のプロジェクト特性に合わせて調整してください。

ポイント:

• 合計点だけでなく、「特に重要な評価項目で低評価のベンダーを除外する」という判断も合わせて行う
• 評価コメント（「なぜこの点数か」）を各自が記録し、合議の材料とする
• 評価シートは選定後も保管し、経営判断の根拠資料として活用する

配点（重みづけ）はどう決める？自社のリスク特性から逆算する

上記の表はあくまで標準的な配点例です。「配点をどう決めればいいか分からない」という声が多いため、決め方の手順を示します。

1. プロジェクトのリスクが最も高い領域を1つ選ぶ（例: 新規性の高い技術を使う開発なら「開発実績・技術力」、長期保守が前提の基幹システムなら「保守・サポート体制」）
2. 選んだ項目の配点を30〜40点に引き上げ、他の項目から差分を減らして調整する
3. 配点を決めた理由を一言メモしておく（後で「なぜこの配点にしたか」を説明する際の根拠になる）

配点の根拠を自社の主観だけに頼りたくない場合は、IPA（情報処理推進機構）が公開している非機能要求グレードや共通フレームなど、公的機関がまとめた評価観点を参考にする方法もあります。これらは可用性・性能・セキュリティ・保守性といった観点を体系的に整理しているため、社内評価項目の抜け漏れチェックや、配点根拠の補強資料として活用できます。

比較表テンプレート（自社用にコピーして使う）

候補ベンダーが多い場合や、初回のRFI段階で簡易比較したい場合は、以下のようなシンプルな比較表から始めても構いません。

この簡易比較表で候補を絞り込んだ後、前述の配点付き評価チェックシートで最終候補を精査する、という2段階の使い方をおすすめします。

国内ベンダーと海外ベンダーの比較ポイント

選定候補には、国内ベンダーだけでなく海外ベンダー（オフショア開発会社等）が含まれることもあります。国内・海外いずれが良いという単純な優劣ではなく、以下の観点で自社のプロジェクトに合うかを判断してください。

海外ベンダーを候補に含める場合は、評価基準6項目の「コミュニケーション適合性」と「保守・サポート体制」の確認をより厚めに行うことをおすすめします。特に緊急時の対応時間帯（自社の営業時間内に一次対応が受けられるか）は、契約前に必ず確認してください。

選定後に確認すべき契約・SLAのポイント

ベンダーを選んだ後、契約締結前に以下を必ず確認してください。

ソースコード・著作権の帰属先

システムのソースコードや設計書の著作権が発注者（自社）に帰属するかを確認します。ベンダー側に著作権が残る契約になっていると、将来的にベンダーを変更したい場合に制約が生じます。契約書に「成果物の著作権は発注者に帰属する」という条文が含まれているか確認してください。

契約不適合責任の範囲と期間

システムに問題が見つかった場合の対応義務（旧：瑕疵担保責任）について、いつまでが無償対応の範囲かを確認します。「不具合を知ってから1年間」が法律上の原則ですが、契約書で変更することも可能です。

変更管理プロセスの明示

開発途中での仕様変更が発生した場合、どのような手順で承認し、追加費用をどう算出するかを事前に定めておきます。変更管理の詳細については別記事を参考にしてください。 （→ 変更管理・仕様変更プロセスとは？システム開発で使える5つのステップと変更要求書の書き方）

ベンダーロックインを防ぐためのチェックリスト

ベンダーロックインとは、特定の開発会社やプラットフォームへの依存が深まり、他のベンダーへの移行が困難になる状態です。選定時点から以下を確認することで、ロックインのリスクを減らせます。

確認チェックリスト:

• ソースコードは自社に帰属する（著作権の確認）
• 使用技術はオープンスタンダードまたは広く使われているフレームワークか
• ドキュメント（設計書・仕様書）の整備方針が明確か
• コードの可読性・保守性に関するポリシーがあるか
• 担当エンジニアが退職・異動した場合の引き継ぎ体制はあるか
• 保守フェーズで別のベンダーに引き継ぐことは可能か

ベンダーロックインは選定後に気づいても手遅れになることが多いため、候補ベンダーへの質問として事前に確認することをおすすめします。

まとめ：ベンダー選定は「選定理由を説明できる状態」を目指す

本記事で解説したベンダー選定の評価基準6項目を振り返ります。

1. 開発実績・技術力（最重要）
2. コスト（初期費用・ランニングコスト）
3. プロジェクト管理体制
4. コミュニケーション適合性
5. 保守・サポート体制
6. 会社の安定性・継続性

これらを評価チェックシートに落とし込み、配点を自社のリスク特性に合わせて調整したうえで複数人で合議することで、「なぜこのベンダーを選んだか」を根拠を持って説明できるようになります。国内・海外どちらのベンダーを検討する場合でも、この6項目とRFI→RFP→評価という3ステップの流れは共通して使えるフレームワークです。

ベンダー選定は一度失敗すると、プロジェクトの立て直しに大きなコストがかかります。この記事で紹介したフレームワークを活用し、後悔のない選定を行っていただければと思います。

秋霜堂株式会社では、「構想段階からの伴走型開発」「少人数精鋭体制」「稼働後の継続保守」を強みとして、中小企業向けのシステム開発支援を行っています。ベンダー選定の相談から対応しておりますので、お気軽にお問い合わせください。

選定後の生産性指標管理については、以下の記事も参考にしてください。 （→ 開発生産性とは？企業が押さえるべき4大指標と開発会社選定の実践ステップ解説）

—Free Download / 資料ダウンロード

失敗しないためのアプリ開発の考え方と開発パートナー選定チェックリスト

この資料でわかること

アプリ開発（スマートフォンアプリ・Web アプリ）の発注・開発を検討している企業の担当者が、開発パートナーを選ぶ際に「何を確認すべきか」「どのような観点で比較すべきか」を体系的に把握できる実践的なチェックリストを提供する。

こんな方におすすめです

• アプリ開発を検討しているが失敗したくない
• 開発パートナーの選び方が分からない
• アプリの形式選定やUI/UX設計の確認ポイントを知りたい

詳しく見る

フォームから無料ダウンロード

お名前必須

会社名必須

メールアドレス必須

電話番号任意

ご質問・ご要望任意

プライバシーポリシーに同意の上、送信します。

ダウンロードする

入力いただいたメールアドレスにPDFをお送りします。