システム開発会社の選び方｜発注側が見るべき比較の観点と契約前の確認事項

システム開発会社の選び方で最初に固めるべきは、価格の比較ではなく「自社が実現したい業務を、どの観点で・誰にどう伝えるか」という発注側の準備です。

比較の観点を決めないまま複数社に声をかけると、各社の提案の前提がそろわず金額だけで判断してしまい、稼働後の保守フェーズで想定外の追加費用や対応の遅さに困るケースが少なくありません。本記事では発注側の立場から、選定前に固めておくこと、タイプ別の得意領域、比較・評価の観点、提案依頼と見積もり取得の進め方、契約前の確認事項を実務の流れに沿って整理します。開発工程そのものの流れは、別記事「システム開発工程の基礎知識」で解説しています。

システム開発会社を選ぶ前に発注側が固めること

システム開発会社を選ぶ前に発注側が固めておくべきことは、実現したい業務の優先順位と、予算・時期の前提条件の2点です。この2つが曖昧なまま複数社に声をかけると、各社の提案の前提がそろわず、比較そのものが成立しません。

実現したい業務と優先順位

最初に固めるのは、システムで解決したい業務課題と、そのなかで譲れない要件の優先順位です。「在庫管理を効率化したい」のような目的レベルの言葉だけでは、開発会社ごとに解釈が分かれ、提案内容も見積もりも比較できない状態になります。業務フローのどこにボトルネックがあり、どの工程を自動化・可視化したいのかを、現場担当者へのヒアリングを通じて具体的に言語化しておくことが出発点になります。

要件には「必須」「あれば望ましい」の2段階で優先順位をつけておくと、提案会社ごとの実現方法の違いを比較しやすくなります。すべてを必須要件にしてしまうと見積もりが高止まりしやすく、本当に譲れない要件がどれかも見えにくくなります。

予算と時期の前提条件

予算と稼働開始時期の前提条件は、比較を始める前に社内で合意しておく必要があります。予算に幅を持たせる場合も上限額を明示したうえで各社に提示すると、実現可能な範囲に絞った提案を引き出しやすくなります。稼働開始時期についても、決算期や繁忙期など業務側の都合から逆算した希望時期を先に示すことで、開発会社側が体制を組めるかどうかを早い段階で判断できます。

予算・時期のどちらか一方でも未確定のまま提案依頼を進めると、後工程で「思っていたより費用がかかる」「稼働開始に間に合わない」という認識のずれが生じやすくなります。費用の相場感をあらかじめ把握しておきたい場合は、別記事「システム開発費用の相場と見積もりの考え方」も参考になります。

システム開発会社のタイプと得意領域の違い

システム開発会社は、受託開発・SES・パッケージ導入・ラボ型の4タイプに大きく分かれ、それぞれ契約の考え方と得意領域が異なります。

受託開発・SES・パッケージ導入・ラボ型の違い

4タイプの違いを整理すると、次のようになります。

「独自性の高い業務をゼロから作りたいのか」「既存の仕組みに技術者を組み込みたいのか」「標準的な業務を早く導入したいのか」という発注の性質によって、適したタイプは変わります。

規模と体制による向き不向き

開発会社の規模・体制と、自社プロジェクトの規模が合っているかも判断軸になります。組織階層の多い開発会社は複雑な案件では体制の厚みが強みになる一方、小規模な改修案件では意思決定に時間がかかり割高になりやすい傾向があります。反対に少人数体制の開発会社は小回りが利く一方、担当者の離脱や繁忙期に体制が薄くなるリスクを抱えています。

自社プロジェクトの規模・複雑さに対し、開発会社側がどの程度の人数・階層で対応する想定なのかを提案段階で確認しておくと、比較・評価の観点を設計しやすくなります。

比較・評価の観点をどう設計するか

比較・評価の観点は、体制と要員の質、実績の近さ、見積もりの根拠、保守体制の4点を軸に設計すると、価格だけに引っ張られない判断がしやすくなります。

体制と要員の質・実績の近さ・見積もりの根拠・保守体制

体制と要員の質では、提案書に記載された担当者の経験と、プロジェクトへの稼働の関与度を確認します。実績の近さでは、自社と業種・規模・システムの性質が近い実績があるかを見ます。異業種の実績しかない場合、業務知識の習得に想定以上の時間がかかることがあります。

見積もりの根拠では、金額の内訳が工程別・役割別に分解され、前提条件（対象範囲・想定工数・除外事項）が明記されているかを確認します。保守体制では、問い合わせ対応の窓口・対応時間帯・障害発生時の初動までの目安時間が提案に含まれているかを見ておくと、稼働後のトラブルを未然に防ぎやすくなります。

提案内容の比較表の作り方

複数社の提案を横並びで比較する際は、評価軸を列に、比較対象の会社を行に置いた表を作ると、各社の強み・弱みが視覚的に把握しやすくなります。架空の例として、体制・実績・見積根拠・保守体制の4項目でA社・B社・C社を比較すると、次のような整理になります。

金額だけを見るとB社が有利に見えるケースでも、見積根拠や保守体制の欄が空欄であれば、追加のヒアリングで前提条件を確認する必要があります。比較表は提案内容が更新されるたびに更新し、判断の根拠を残しておくことが説明責任にもつながります。

提案依頼と見積もり取得の進め方

提案依頼と見積もり取得を効果的に進めるには、提案依頼書に書くべき項目を過不足なく整理し、見積もりの前提条件を各社にそろえて提示することが要点になります。

提案依頼書に書くべき項目

提案依頼書（RFP）には、少なくとも次の項目を記載しておくと、各社の提案の前提がそろいやすくなります。

• プロジェクトの背景・目的と、解決したい業務課題
• 機能要件（必須・あれば望ましいの優先順位付き）
• 非機能要件（可用性・性能・セキュリティなど、機能面以外で満たすべき水準）
• 予算の上限と、稼働開始を希望する時期
• 提案書に記載してほしい項目（体制・実績・見積根拠・保守体制など）と提出期限
• 評価基準と、選定スケジュール

このうち見落とされやすいのが非機能要件です。IPA（独立行政法人情報処理推進機構）は、要件定義の場でユーザーと開発者の認識の相違を防ぐことを目的に、非機能要求の項目を体系的に整理した「非機能要求グレード」を公開しており、可用性やセキュリティといった項目を過不足なく洗い出すための参考として活用できます（出典：IPA「非機能要求グレード」）。機能要件だけを提示すると、稼働後の性能やセキュリティ水準について各社の想定にばらつきが生じやすくなります。

見積もりの前提条件をそろえる

見積もりの前提条件をそろえるとは、対象範囲・想定工数・除外事項・保守費用の有無といった条件を、各社に同じ形式で提示・回答してもらうことです。前提条件がそろっていないと、一見安く見える見積もりが実は対象範囲を狭めているだけ、というケースを見抜けなくなります。見積もり方法そのものの精度を上げたい場合は、別記事「システム開発の見積もり方法と精度を上げるポイント」も参考になります。

質問と回答のやり取りは口頭で済ませず、書面（メールや共有ドキュメント）に残しておくと「言った・言わない」の食い違いを防げます。要件定義書の記載項目を事前に整理しておくと、提案依頼の段階から各社への伝達の精度が高まります。要件定義書のフォーマットは、別記事「要件定義書のフォーマット・書き方完全解説」で紹介しています。

契約前に確認しておく事項

契約前に確認しておく事項は、請負と準委任という契約形態の違いに基づく責任範囲と、成果物の定義・検収条件の2点です。個別の契約条項の是非は法的判断を伴うため、最終的な締結前には専門家への相談を前提としてください。

請負と準委任の違いを踏まえた責任範囲

請負契約は成果物の完成を約束する契約で、完成責任は開発会社側にあります。一方、準委任契約は業務の遂行そのものに報酬が発生し、成果物の完成義務は負いません。要件定義のように着手時点で最終的な成果物の形が想定できない工程は、性質上、準委任契約になじみやすいとされています（出典：BUSINESS LAWYERS「システム開発契約は請負と準委任どちらを使う？要件定義を準委任とするのはなぜ？」）。

実務では、要件定義・基本設計は準委任、詳細設計以降の製造・テストは請負という組み合わせが多く見られます。どちらを採用するかで、仕様変更が発生した際の責任の所在や追加費用の扱いが変わります。

成果物の定義と検収条件

検収とは、納品されたシステムが仕様どおりに動作するかを発注側が確認する工程であり、単なる品質判定ではなく、支払い義務と契約不適合責任の起算点を同時に確定させる行為です。合否の具体的な基準は、検収の段階ではなく要件定義の段階であらかじめ明示しておく必要があります（出典：発注ラウンジ「システム開発の検収とは？起こりやすいトラブルや作業時の注意点」）。

民法改正により、従来の「納品完了から一定期間」という瑕疵担保責任は、「不具合発覚から一定期間」を基準とする契約不適合責任に変わっています。この期間や範囲は契約で調整できるため、検収完了後に不具合が見つかった場合の対応をどう定めているかを事前に確認しておくことが望ましいです。個別の契約条文の解釈は、法務担当者や弁護士への確認を前提としてください。

選定でつまずきやすいポイント

「コンサルタントの歩み」編集部が2025年以降にヒアリングしたベンダー選定支援の案件を整理したところ、選定でつまずくケースの多くは価格やスケジュールそのものよりも、比較の前提をそろえきれていないことに起因していました。代表的なつまずきは、価格だけで選んで保守で困るケースと、要件が固まらないまま発注してしまうケースの2つです。

価格だけで選んで保守で困る

提案金額の安さだけを基準に決めてしまうと、保守フェーズで問い合わせ対応の遅さや、仕様変更のたびの想定外の追加費用に気づくケースがあります。見積もりの内訳や保守体制の記載が薄い提案は、稼働後のコストが見えていないだけの可能性があるため、比較・評価の観点で整理した保守体制の項目を確認しておく必要があります。

要件が固まらないまま発注する

要件が固まらないまま「とりあえず相談してみる」形で発注を進めると、開発会社側も前提が定まらないまま見積もりを出さざるを得ず、要件が追加されるたびに追加費用と工期延長が発生しやすくなります。要件の優先順位を「必須」「あれば望ましい」で整理しておくことは、この対策としても有効です。要件の言語化に難しさを感じる場合は、外部のコンサルタント・PMOの支援を検討する余地があります。

コンサルタント・PMOが選定を支援するときの役割

コンサルタント・PMOが選定を支援するときの役割は、発注側の要件を言語化する役割と、比較・評価の客観性を担保する役割の2つに大別されます。社内に選定の専任担当を置きにくい場合、外部人材の支援を検討する価値があります。

発注側の要件を言語化する

現場の要望は「使いやすくしたい」「もっと早くしたい」といった感覚的な言葉で語られることが多く、そのままでは提案依頼書に落とし込めません。コンサルタント・PMOは現場へのヒアリングを重ね、業務フロー上の課題を整理し、機能要件・非機能要件として言語化する役割を担います。社内の担当者だけで進めるよりも、複数部門の利害を客観的な立場で調整しやすいことが強みです。

評価の客観性を担保する進め方

比較・評価の客観性を担保するには、あらかじめ定めた評価軸に沿って各社の提案を採点し、特定の担当者の主観や過去の付き合いだけで選定が決まらないようにする進め方が有効です。コンサルタント・PMOが評価表の設計と採点の進行を担うことで、社内の利害関係から距離を置いた判断がしやすくなります。

このような選定支援を外部のPMO・コンサルタントに依頼する場合、業務遂行そのものを担う準委任契約の形をとることが一般的です（出典：ドメイン知識ベース「業務委託契約の形態（準委任が主流）」）。費用感の目安として、PMO・プロジェクトマネジメント支援を担うフリーランス人材の月額単価はおおむね80〜150万円程度が標準的なレンジとされ、サポート中心であれば60〜90万円程度、評価設計まで主導する戦略・リード的な関わり方であれば130万円以上になることもあります（出典：ドメイン知識ベース「PMOフリーランスの月額単価相場と役割別レンジ」）。プロジェクトマネジメントの考え方は、別記事「プロジェクト管理とは何か？手法と実践のポイントを整理」でも解説しています。社内にPMO経験者がおらず外部人材を探す場合は、「フリーコンサル向けエージェント おすすめ比較ランキング」も参考になります。

よくある質問

相見積もりは何社くらいに依頼するのが目安ですか

比較の質を保ちながら現実的に進められる目安として、3社前後に依頼するケースが多く見られます。1〜2社では比較の材料が不足しやすく、5社を超えると各社への説明・質問対応の負荷が大きくなり比較検討自体に時間がかかりすぎる傾向があります。

提案依頼から契約までの期間はどの程度を見ておくべきですか

要件がある程度固まっている前提で、提案依頼書の準備から提案受領、比較・評価、契約条件の確認までを含めると、1〜2カ月程度を見込んでおくと無理のない進め方になります。要件が固まっていない場合は、言語化に要する期間を別途見込む必要があります。

請負契約なら発注側の確認作業は少なくて済みますか

請負契約であっても、発注側の確認作業が不要になるわけではありません。成果物の完成責任は開発会社側にありますが、検収の合否基準を要件定義の段階で明示し、進行中の仕様確認に発注側として関与しなければ、完成した成果物が業務要件と食い違うリスクは残ります。契約形態にかかわらず、発注側の関与は選定後も継続して必要になります。

出典・参考情報

1. IPA（独立行政法人情報処理推進機構）「非機能要求グレード」（2026-09-13参照）
2. BUSINESS LAWYERS「システム開発契約は請負と準委任どちらを使う？要件定義を準委任とするのはなぜ？」（2026-09-13参照）
3. 発注ラウンジ「システム開発の検収とは？起こりやすいトラブルや作業時の注意点」（2026-09-13参照）

本記事は2026年9月時点の情報に基づきます。契約・法令に関する記述は一般的な考え方の整理であり、個別の契約内容の是非については専門家にご確認ください。最終更新日: 2026年9月13日