受託開発ベンダーを比較するときの観点｜固定価格と準委任・スコープの扱い方

システム開発を外部のベンダーへ委託する際、多くの担当者が頭を悩ませるのが「どのベンダーが自社にとって最適か」という比較軸です。単に「見積金額が安い」「実績が豊富」という表面的な指標だけで選定すると、開発途中の要件変更による追加費用の発生や、納品物のクオリティ不足といったトラブルを招きかねません。

本記事では、IT実務者の視点から、受託開発ベンダーを比較検討する際に不可欠な「契約形態（固定価格・準委任）の特性」と、トラブルの火種になりやすい「スコープの扱い方」について、公式サイト等の一次情報に基づき詳細に解説します。

受託開発における2つの主要な契約形態

ベンダー比較の前提として、まずは「請負契約（一括請負・固定価格）」と「準委任契約」の違いを正しく理解する必要があります。これらは民法上の性質が異なり、リスクの所在が変わります。

1. 請負契約（一括請負・固定価格）

請負契約は、ベンダーが「システムの完成」を約束し、その対価として報酬を支払う形態です。一般的に「ウォーターフォール型開発」で採用されます。

• 成果物責任： ベンダーは完成物に対して責任を負う。
• 契約不適合責任（旧：瑕疵担保責任）： 納品後に不具合（バグ）が見つかった場合、一定期間内であれば無償改修を請求できる。
• 価格： 原則として固定（フィックス）。

2. 準委任契約（タイム＆マテリアル）

準委任契約は、ベンダーが「善良な管理者の注意（善管注意義務）」をもって業務を遂行することを約束する形態です。主に「アジャイル型開発」や「要件定義フェーズ」で採用されます。

• 成果物責任： 完成の義務はない。稼働した時間や提供した専門性に対して対価を支払う。
• 柔軟性： スコープが確定していない状態でも着手でき、途中の仕様変更にも柔軟に対応可能。
• 価格： 「人月単価 × 稼働時間」による変動、または月額固定。

特に、社内DXを推進するために既存ツールとの連携を模索する場合、初期段階では準委任、仕様確定後に請負へ切り替えるといったフェーズ分けが推奨されます。例えば、Excelと紙の限界を突破する「Google Workspace × AppSheet」業務DX完全ガイドで紹介されているような内製化支援に近いプロジェクトでは、柔軟な準委任契約の方が適しているケースが多いです。

ベンダー比較のための契約形態・特性一覧表

以下の表は、一般的な受託開発における契約形態の比較です。ベンダーから提示された提案がどちらに該当するか、リスクとリターンのバランスを確認してください。

スコープの扱い方でベンダーの「誠実さ」を見極める

ベンダー比較において、見積金額以上に重要なのが「スコープ（開発範囲）をどのように定義しているか」です。以下の3つの観点で提案書をチェックしてください。

1. 境界線の明確化

「ログイン機能」という一言でも、ベンダーによって範囲が異なります。

• メールアドレス認証のみか、SNS連携（OAuth）を含むのか。
• パスワードリセット機能や、多要素認証（MFA）は含まれるのか。

これらが「別料金」なのか「基本構成内」なのかを明文化していないベンダーは、後のトラブルリスクが高まります。

2. 非機能要件の記載

「動けば良い」というベンダーと、セキュリティや負荷耐性を考慮するベンダーでは、初期コストに大きな差が出ます。

• セキュリティ： OWASP Top 10などの脆弱性診断基準に準拠しているか。
• 保守性： 納品後のソースコードの所有権、ドキュメント（設計書・API仕様書）の納品有無。

例えば、広告データの最適化など、高度なデータ連携を伴う開発では、広告×AIの真価を引き出すデータアーキテクチャのような、将来的な拡張性を担保したスコープ設定が求められます。

3. 変更管理（チェンジリクエスト）のプロセス

開発が進む中で必ず発生するのが「やっぱりこうしたい」という要望です。この際、

• 「それはスコープ外です」と拒絶するだけか。
• 「バックログに入れて優先順位を調整しましょう」と代替案を出すか。

後者のプロセスが標準化されているベンダーは、準委任契約でのパートナーシップに向いています。

ベンダー比較時にチェックすべき実務的ポイント

エンジニアのアサイン体制と透明性

多くのベンダーは、営業担当とエンジニアが別です。比較時には「実際にコードを書くリードエンジニアと面談できるか」を確認してください。また、オフショア（海外開発）を利用している場合、コミュニケーションのオーバーヘッドや品質管理体制を具体的にヒアリングする必要があります。

既存システムとの統合知見

現代のシステム開発は、ゼロから作るよりも「既存のSaaSやデータベースとどう繋ぐか」が鍵となります。例えば、会計周りのDXを検討している場合、バクラク vs freee支出管理の比較に見られるような、各ツールの仕様の違いやAPI制限を熟知しているベンダーかどうかが、開発後の運用効率に直結します。

失敗しないための発注手順ステップ

1. RFP（提案依頼書）の作成： 背景、目標、必須機能、予算、納期、非機能要件をドキュメント化する。
2. NDA締結とヒアリング： 候補2〜3社に詳細な要件を伝え、逆提案を受ける。
3. 見積書・提案書の精査： 「一括請負」か「準委任」かを確認し、スコープ外（除外事項）を明確にする。
4. 契約書の法務チェック： 契約不適合責任の期間、損害賠償の限度額、知的所有権の帰属を確認。
5. 開発環境のセットアップ： GitHubやSlack等のアクセス権限、セキュリティポリシーの共有。

実務上の注意点：
準委任契約において、委託元（あなた）がベンダーのエンジニアに対して直接「明日の朝9時にこの作業を終わらせておいて」といった具体的な指揮命令を行うと、法的に「偽装請負」とみなされるリスクがあります。指示は必ずベンダー側の責任者（PM）を通じて行うよう徹底してください。

まとめ：自社に最適なパートナーを見極めるために

受託開発ベンダーの比較は、単なる「見積比較」ではありません。
要件が固まっており、リスクを固定したいなら「請負契約」を。
市場の反応を見ながら柔軟に開発を進めたいなら「準委任契約」を。
それぞれの特性を理解した上で、スコープの境界線を曖昧にしないベンダーを選ぶことが、プロジェクト成功への最短距離です。

自社の課題が「既存業務の自動化」にあるのか、「新規の顧客体験創出」にあるのかによって、選ぶべきベンダーのカラーは異なります。本記事の比較基準を参考に、長期的な技術パートナーとなり得る1社を見極めてください。