システム開発会社の選び方｜比較ポイントと発注前の見極め方

Webサービスやスマホアプリを手がけるシステム開発会社は、知名度や見積総額だけでは選び切れません。目的に合わない機能、発注側のレビュー不足、保守範囲の認識違いは、契約後の追加費用や遅延につながり得ます。比較を始める前に、発注側が何を実現したいのか、何を譲れないのかをそろえることが重要です。

この記事では、依頼方式の選び方から候補の絞り込み、実績・体制・見積・保守条件の比較、契約前の確認までを順に解説します。同じ基準で候補を比較し、選定理由と残るリスクを説明できる発注判断を進められるようになります。

開発会社の選定は、候補を探す前の目的・KPI・制約の整理から始まります。各段階で比較条件と確認事項をそろえることが、説明可能な発注判断につながります。

01Sectionシステム開発会社を比較する前に、目的・KPI・制約をそろえる

システム開発会社の比較は、機能の要望を並べるところから始めるものではありません。候補各社に同じ前提を伝えられる状態をつくると、提案内容と見積条件の違いを読み解きやすくなります。

この記事の対象範囲：Webサービス・スマホアプリ開発

対象となる工程は、企画、要件定義、UI/UX設計、開発、テスト、リリース、保守運用です。どの工程から任せたいかによって、比較すべき実績、体制、費用の意味が変わります。

たとえば、課題がまだ曖昧なら要件整理や検証の支援が重要です。一方で、要件と受入条件が固まっているなら、設計・開発・テストの実行力と見積の透明性が中心になります。要件定義では、事業上の要求と制約を整理し、実現方法を検討することが求められます。IPA「ユーザのための要件定義ガイド 第2版」も、利用者側が事業要求と要件定義を管理する重要性を示しています。

選定前整理シートで決める5項目

KPIと計測要件を見積・受入条件につなげる

KPIを「利用者数を増やす」のような目標だけで終わらせると、開発会社ごとに計測実装の想定が異なります。ベースライン、目標値、計測イベント、ダッシュボードの要否、評価時期、責任者を依頼条件に含めましょう。

受入時に確認する機能と、リリース後に検証する成果指標は別物です。両方を提案・見積の対象として扱うことで、開発完了後に成果の確認方法が残る事態を避けやすくなります。

02Section依頼方式は要件確度と関与可能性で選ぶ

既存サービスでMust要件を満たせるか、成果物と受入条件を固められるか、継続的な優先順位付けとレビューが可能かを順に確認して、依頼方式を選びます。

開発会社へ発注することだけが選択肢ではありません。既存のパッケージやSaaSで必須業務の大半を満たせるなら、設定・連携・運用設計を優先して比較するほうが合理的な場合があります。

まず既存サービスで必須要件を満たせるか確認する

最初に、標準機能でMust要件を満たせるサービスがあるかを確認します。その際は、機能の有無だけでなく、既存システムとの連携、データ移行、運用ルール、利用量に応じた費用、独自要件を実現するための追加開発の必要性を見ます。

既存サービスでは差別化したい業務や顧客体験を実現しにくい、または既存環境との連携が主要な難所である場合は、受託開発や継続的な開発支援を検討します。外部資源やパッケージの利用、代替案、連携要求の検討は、IPAのUISSでも要件・実現可能性の確認観点として整理されています。

受託開発・準委任型支援・パッケージ／SaaSの違い

依頼方式は、要件の確度と発注側が継続して関与できるかで選びます。まず既存サービスでMust要件を満たせるかを確認し、満たさなければ独自業務・差別化・既存環境連携の重要性を見ます。独自開発が必要な場合は、成果物と受入条件を固定できるか、固定しにくい場合は優先順位付けとレビューを継続できるかを確認します。

要件未確定なら、要件整理フェーズを先行する

要件が未確定で、発注側にも優先順位を決める担当がいない状態では、いきなり開発範囲を固定するより、要件整理を先行するほうが適切です。候補各社には、どこまでを要件整理の成果とし、次工程の見積条件をどうそろえるかを確認します。

依頼方式、開発の進め方、契約形態は同じ分類ではありません。たとえば反復的に進める案件でも、個別の契約条件は別途定めます。契約の扱いは後述する成果物、稼働、変更、報酬、責任分界で確認してください。

03Section候補探索と一次選定は、公開情報の限界を前提に進める

候補探索では、公開情報を使って「相談する価値があるか」を絞り込みます。ただし、一覧掲載や公開事例だけで、実担当体制や見積・契約条件まで確定することはできません。

公開情報で確認する5項目

候補の収集には開発サービスの一覧を利用できます。掲載情報は候補抽出に活用し、最終判断では面談、提案、契約案で追加確認する前提にしてください。

面談・提案・契約確認へ回す項目

実担当者、参画時期、稼働率、再委託範囲、見積前提、障害時の対応、知的財産や移管の条件は、公開情報だけでは確定しません。候補間で同じ質問を行い、提案書、体制図、見積書、契約案とともに記録します。

再委託がある場合は、担当工程、アクセス権、元請の品質責任、連絡窓口、再委託先変更時の扱いを確認しましょう。個人データを扱う委託では、契約内容、取扱状況、再委託先を含む管理も必要です。詳細は個人情報保護委員会のガイドラインを確認してください。

RFPを使うべき場面と使わない場面

複数候補に対して、目的、対象範囲、制約、回答依頼事項、評価基準を共通提示できる状態なら、RFPは比較の公平性を高めます。一方、課題やMust要件が未整理なら、RFPを急ぐよりも要件整理の支援範囲を相談するほうが比較しやすくなります。

RFPに含める内容や、提案依頼へ進む判断はRFP（提案依頼書）の解説で確認できます。候補によって前提情報を変えず、質問への回答を全候補に共有する運用も重要です。

04Section実績・技術・提案は「案件の難所」で見極める

類似業界の実績件数や、特定技術の利用経験だけでは、自社案件を任せられるかは判断できません。比較すべきなのは、今回の課題と制約に近い難所を、どの範囲まで担当し、どのように解いたかです。

実績は課題・担当範囲・制約・結果で比べる

候補各社には、対象利用者、解決した課題、連携先、性能や可用性の要求、セキュリティ上の制約、運用・改善の担当範囲を聞きます。そのうえで、自社案件との共通点と相違点を分けて記録します。

公開できない案件については、顧客名や機密情報を求める必要はありません。匿名化したうえで、課題、制約、担当工程、対応方法、検証方法、適用できなかった条件を説明できるかを確認します。

技術選定は保守性と代替案まで確認する

技術提案では、「何を採用するか」だけでなく、「なぜ他の選択肢を採らないのか」を聞きます。既存システムとの整合、保守できる人材の確保、性能・セキュリティ、将来の連携や拡張、特定事業者への依存を避ける設計、文書化の方針まで説明できると、提案の再現性を評価しやすくなります。

提案内容は完成形の機能一覧だけでなく、不確定事項、前提、技術的なリスク、検証方法を明示しているかも確認します。不確実性を早い段階で見える化する候補は、変更管理やリスク共有でも協働しやすい可能性があります。

公開できない実績と再委託範囲の聞き方

非公開案件や再委託の有無は、公開事例の見た目から推測しないことが重要です。「誰が実装したか」だけでなく、設計レビュー、コードレビュー、テスト、障害対応を誰が担い、元請がどのように品質を管理するかを確認します。

回答が抽象的な場合は、提案書の体制図、役割分担、品質計画、変更・障害時の連絡経路に具体化してもらいましょう。

05Section実担当チームと進め方を確認する

提案担当者との会話が円滑でも、実際のチームが確保され、発注側の意思決定と品質管理が回るとは限りません。契約前には、実担当体制とプロジェクト運営を確認します。

実担当者・QA・再委託の責任分界を確認する

プロジェクト責任者、設計責任者、開発リーダー、QA責任者について、役割、参画時期、稼働想定、兼務、交代時の引継ぎ、代替要員を確認します。

定例会の参加者、意思決定者、回答期限を決め、課題・仕様変更・障害の起票から完了確認までの経路をそろえます。再委託がある場合は、データや環境へのアクセス権を含め、元請の管理責任を確認してください。

段階型と反復型で変わる発注側の役割

段階型では、工程の節目で要件、設計、受入条件を承認し、変更の影響を判断します。要件が未確定のまま開始したり、変更承認者が不明だったりすると、遅延や認識ずれが起きやすくなります。

反復型では、短い単位で成果を確認しながら、発注側が優先順位と受入判断を継続します。レビューや意思決定を担う担当者が不在だと、開発チームが待機したり、価値の低い作業を進めたりするおそれがあります。IPAのアジャイル開発外部委託モデル契約も、発注者・受注者の役割、権限、チームの進め方を事前に明確化し、合意する考え方を示しています。

進め方と契約形態は別軸で確認する

段階型・反復型という進め方と、請負・準委任という契約形態は別軸です。「反復型だから準委任」「段階型だから請負」とは限りません。

請負では、成果物、仕様、受入条件、検収、変更時の再見積・納期変更を具体化します。準委任では、担当役割、稼働時間・期間、実施タスク、報告方法、優先順位、精算条件や上限を確認します。いずれも、知的財産、秘密保持、再委託、終了・移管を契約条件として確認してください。経済産業省の取引トラブル事例集は、成果物の特定や作業内容、責任分界を確認する際の参考になります。個別契約の最終判断は、自社の法務・調達部門または専門家に確認しましょう。

06Section見積もりは総額ではなく比較可能性で見る

初期予算と期間の仮説は、機能名だけから作ると誤差が大きくなります。対象プラットフォーム、Must要件、連携、非機能要件、工程、保守、発注側の準備物をそろえ、同じ依頼条件で概算を取得することが比較の出発点です。

費用は5層に分けて比較する

見積は初期開発費だけでなく、外部サービス、保守、追加改修、移管・終了まで分けて確認します。各層の範囲・前提・除外項目を対応付けてから比較することが重要です。

初期開発の総額だけでは、継続利用まで含めた費用を比較できません。費用の発生条件と見積範囲を、次の5層に分けて候補間で確認します。

同一条件の概算依頼で初期予算・期間仮説をつくる

概算依頼では、対象範囲、工程、非機能、前提、除外、変更、保守、移管を同じ列で確認します。総額だけでは、工程省略、外部費用の除外、発注側作業の想定差を見分けられません。

比較列を埋められない回答は、補足や再見積を依頼します。補足後も工程、前提、除外を対応付けられない場合は比較保留とします。具体的な見積書の読み方は、システム開発の見積もり比較に関する解説も参照してください。

公開メトリクスは見積差を質問する補助線にとどめる

JUASのソフトウェア・メトリクス調査2025は、過去プロジェクトの実績工数、開発総費用、工期の関係を整理した資料です。工程と費用範囲を対応付けたうえで、候補間の差が体制、連携、非機能、リスク対応、保守範囲のどこから生じるかを質問する補助線にします。

候補社の見積は将来に向けた計画値であり、JUASの数値は過去の実績値です。現在相場、個別見積の妥当性、確定納期の判定には用いず、費用層と契約条件を分けて確認してください。

07Section保守・セキュリティ・移管の要求水準を先に決める

保守契約があることと、自社に必要な対応が含まれることは同義ではありません。停止時の影響と扱う情報の重要度から要求水準を決め、候補比較と契約条件に反映します。

停止影響と情報重要度からRTO・RPOを考える

RTOは目標復旧時間、RPOは許容できるデータ損失の時点を示す考え方です。停止すると何が止まるか、顧客・業務への影響、代替手段、夜間・休日の影響を整理して決めます。

RTO・RPO、可用性、運用監視、復旧手順は、IPAの非機能要求グレードを補助資料として検討できます。ただし、これは民間案件へ一律の水準を求めるものではなく、自社の停止影響に見合う確認観点を選ぶための資料です。

保守・セキュリティ条件へ変換する

保守・セキュリティ条件は、停止影響と扱う情報の重要度から決めます。復旧目標、連絡体制、再委託先の管理、運用条件を順に具体化し、見積・契約へ反映します。

個人データを扱う場合は、認証表示や公開方針の有無だけで判断せず、委託するデータ、アクセス権、ログ、インシデント連絡、再委託先の管理、取扱状況を確認する方法まで具体化します。

移管できる状態を契約前に確認する

開発会社の変更や内製化の可能性があるなら、リリース後ではなく契約前に移管対象と更新責任を決めます。コードだけを引き渡しても、アカウントや構成情報、復旧手順がなければ運用を継続できない場合があります。

08Section評価・決裁・契約までの進め方

ベンダー選定は、準備、候補探索・一次選定、相談またはRFP、提案・見積・面談評価、交渉・決裁、契約・開始条件確認の順で進めます。所要期間は候補数、要件確度、社内の法務・調達・セキュリティ審査によって変わるため、一律の日数ではなく、各工程の完了条件で管理します。

5段階評価と必須ゲートを分ける

評価点は1〜5点で付け、2点・4点も使います。加重点は「配点 × 評価点 ÷ 5」で計算します。必須条件の未達や重大リスクは、合計点では打ち消せません。

必須ゲートは、見積の範囲・前提・除外を比較できること、実担当責任者と緊急時の連絡経路を確認できること、変更・検収・知的財産・個人データ・再委託・保守・移管の確認先が明確であることです。未達なら、合計点が高くても保留または除外とします。

評価者間のばらつきを根拠資料で調整する

評価者は、提案書、面談記録、見積書、契約案の該当箇所を根拠として個別採点し、評価差が2点以上ある項目や加重点への影響が大きい項目を確認します。

すり合わせでは印象論ではなく、資料のどの記述を評価根拠とするかを確認します。デジタル庁の標準ガイドライン解説書は、要件充足度に加え、実施体制、要員計画、プロジェクト管理能力を確認する考え方を示しています。民間案件へ一律適用するのではなく、評価観点を補う資料として活用してください。

選定理由・残リスク・契約前確認を記録する

決裁資料には、最高点の候補だけでなく、選定理由、次点との差、残るリスク、解消条件を残します。重大リスクは合計点とは別に、影響、根拠、対応責任者、確認期限、判定を記録します。

契約前には、変更手続、検収、知的財産、個人データ、再委託、保守、解除・移管について、見積・提案時の前提と契約案に差がないかを確認します。法的な解釈や条項の最終判断は、自社の法務・調達部門または専門家に委ねてください。

システム開発の依頼先を探す

目的、Must要件、依頼範囲、保守・移管条件を整理したうえで、対応できるシステム開発会社を比較できます。

Webアプリ・SaaS開発4593社掲載

システム開発会社を比較する