BtoB EC開発会社の選び方と見極め7項目

◆監修・編集責任者　小園 将隆　2026年8月28日

B2B EC-COLUMN

業務要件の再現性・見積の妥当性・契約の型 — BtoB EC開発会社を見極める3軸

BtoB EC開発会社とは、企業間取引に固有の商習慣を要件として整理し、受発注の仕組みをWeb上に構築・保守する事業者です。その見極めは、業務要件の再現性・見積工期の妥当性・契約のリスク分担という3点に集約されます。とくに見積と工期は、JUAS（一般社団法人 日本情報システム・ユーザー協会）が公表する標準工期の式で、提案書の数字をその場で検算できます^*1。

見極めの3軸と、記事で使う7つの確認項目

相見積を前にした担当者が最初につまずくのは、比較の軸が定まらないことです。以下の7項目は、業務要件から選定プロセスまでを検討順に並べたものであり、本記事のH2構成にそのまま対応します。

BtoB EC開発会社とは何か（担当範囲の定義）

ここでいう商習慣とは、取引先別の掛率、掛売と与信、金額に応じた承認フロー、ロット単位の発注などを指します。開発会社の担当範囲は、これらを要件として整理する工程から、構築後の保守までを含みます。

BtoC向けのカート機能をそのまま流用しても、こうした商習慣は再現できません。

候補となる事業者が増えるほど、実績の量だけでなく内容を確認する視点が必要になります。

「実績が豊富」を検証可能な質問に置き換える

競合の比較記事の多くは「実績豊富」「業界理解が深い」を選定基準に挙げますが、それをどう確かめるかまでは示していません。実績は件数ではなく、次の3点を尋ねることで検証可能な情報に変わります。

第一に、取引先別価格や承認フローを要件定義書のどの項目に落とし込んだかを尋ねます。第二に、基幹システムとの連携で発生した課題と対応方法を尋ねます。第三に、工期・費用の見積根拠を数式や実績値で説明できるかを尋ねます。

見極め①：取引先別価格・与信・承認フローの再現性を確認する

取引先別価格・掛率テーブル・与信・承認フローは、要件定義の初期段階で明文化しておく必要がある項目です。ここが曖昧なまま開発が進むと、後工程での仕様変更につながりやすくなります。

取引先別価格・掛率テーブル・与信・承認フローを要件定義で落とさない

BtoB取引では、取引先ごとに価格や掛率が異なることが一般的です。与信枠を超えた注文を止める仕組みや、金額に応じた承認フローも、業種によって細かく分かれます。これらを開発会社にどこまで具体的に伝えられるかが、要件定義の質を左右します。

要求仕様の変更が大きいプロジェクトでは、換算欠陥率が平均0.481となり、変更のないプロジェクトの0.192と比べて2倍以上高くなっています^*1。要件定義の段階で商習慣を具体的に伝えるほど、後工程での品質低下を避けられます。

EDI標準（流通BMS）への対応可否を確認する

基幹システムとの受発注連携を検討する場合、EDI標準への対応可否は具体的な確認軸になります。流通BMS（流通ビジネスメッセージ標準）は、発注・出荷・受領・返品・請求・支払の6業務・8種の標準メッセージで構成される仕様です^*7。2007年4月に基本形Ver1.0が公開され、消費税軽減税率に対応した基本形Ver2.0が2018年11月に公開されています^*7。

流通BMSに対応しているかどうかは、開発会社に直接尋ねれば確認できる客観的な事実です。「柔軟に対応します」という回答ではなく、対応済みの通信プロトコルやメッセージ種別を具体的に答えられるかを見ます。

基幹システム・販売管理との連携方式をどう聞くか

基幹システムや販売管理システムとの連携は、EC側の受発注データをどう同期させるかで実装方式が変わります。 連携方式（API連携・ファイル連携・EDI連携など）と、障害発生時のデータ整合性の担保方法を、提案段階で確認しておくことが実務上の備えになります。

見極め②：見積金額を実測ベンチマークで検算する

相見積の金額差に根拠があるかどうかは、業界団体が公表する実測データと照らし合わせることで確かめられます。JUASの調査は、単価と工数の関係を回帰分析で示しており、提示額を検算する基準として使えます^*1。

人月単価の目安は127万円 — JUASの回帰分析

JUAS「ソフトウェア・メトリクス調査2025」は、開発総費用と実績工数の関係を式で示しています。式は「開発総費用＝127.14×実績工数」で、決定係数（自由度調整済みR²）は0.92です（n=195/221）^*1。JUASの報告書は、この回帰係数をもとに人月単価の目安を127万円としています^*1。

ただし母集団は単価50万〜400万円のプロジェクトに限定されています。極端に単価の低い案件や高額な大規模案件は、この範囲の外にあります。

開発方式で単価は変わる（スクラッチ・パッケージ・SaaS）

同じ調査は、開発方式ごとの加重平均単価も示しています。スクラッチ開発の全体平均は96万円（n=99）、パッケージ利用開発は144万円（n=39）、SaaS利用開発は144万円（n=15）です^*1。SaaS利用開発はサンプル数が少ないため、JUAS自身が「参考情報」と注記しています^*1。

提示された金額を自社の数字で確かめるには、無料相談で要件を整理するのが近道です。工数の見積根拠を第三者と一緒に確認すれば、金額差の理由が把握しやすくなります。

ベンダー提示価格の値上げ局面をどう読むか

JUAS「企業IT動向調査報告書2026」によれば、IT予算が増加する理由の第2位は「円安・人件費高騰・ベンダー提供価格の値上げなどによる影響」です^*2。この理由を挙げた企業の割合は、2025年度計画で46.6%（n=502）、2026年度予測で45.6%（n=474）です^*2。発注側の多くがベンダー提供価格の上昇を予算増の要因として見込んでいる局面であり、その前提のうえで提示額の妥当性を検討する必要があります。

見極め③：標準工期の式（3.23×立方根）で提示工期を検算する

提示された工期が現実的かどうかも、業界団体の実測データを使って概算できます。工期が短すぎる提案は、要件定義や結合テストの工数を圧縮している可能性を疑う材料になります。

標準工期＝3.23×投入工数の立方根

JUASの調査は、標準的な工期を「標準工期＝3.23×投入工数（人月）の立方根」という式で示しており、決定係数は0.90です（n=232/258）^*1。この式を使うと、投入工数125人月のプロジェクトでは標準工期は約16.15か月と算出できます^*1。

実績工期は標準工期の1.08倍 — 1割の余裕を見込む

実際に完了したプロジェクトの工期は、標準工期の1.08倍になる傾向があります（n=232/258）^*1。JUASの報告書も、標準工期から1割程度の余裕を持って計画を立案することが望ましいと述べています^*1。提示工期がこの水準を大きく下回る場合は、根拠を確認する価値があります。

小規模ほど遅れる — プロジェクト規模別の超過割合

標準工期を超過した割合は、分析対象232件のうち全体で49%です^*1。規模別に見ると、50人月未満のプロジェクトでは56%が標準工期を超過し、500人月以上の大規模プロジェクトでは29%にとどまります^*1。小規模案件ほど工期見積の余裕が少なく、遅延が発生しやすい傾向が読み取れます。

工期配分の目安は「要件定義20：設計〜結合テスト50：総合テスト30」

工期の内訳は、要件定義：設計〜結合テスト：総合テストの比率で20：50：30が目安です（工期対象データ251件・分析対象211件）^*1。工数の内訳は15：60：25です^*1。提示された工程表がこの比率から大きく外れている場合、特定の工程を圧縮していないかを確認します。

見極め④：換算欠陥率0.05を品質目標として握る

品質は工期・費用と比べて数値化しにくい項目ですが、JUASの調査は「換算欠陥率」という指標で品質水準を定量化しています。契約前に目標値を握っておくことで、完成後の手戻りを減らせます。

品質目標は換算欠陥率0.05で握る

換算欠陥率は、欠陥の重度に応じて重み付けした欠陥数を全体工数で割った指標です。JUASの調査では平均0.25、中央値0.05となっており（n=187）、報告書は換算欠陥率の目標を0.05とするのが妥当だと記載しています^*1。契約段階でこの数値を目標値として明記できるかどうかを確認します。

品質目標を提示したプロジェクトは欠陥率が低い

品質目標の提示有無別に見ると、提示ありのプロジェクトの換算欠陥率は0.2、提示なしは0.23です（n=184）^*1。差は大きくありませんが、目標を明示すること自体が品質管理の姿勢を示す材料になります。

フェーズ別の工期を管理しているプロジェクトほど工期を守りやすい

フェーズ別の工期を記載していたプロジェクトの割合は、標準工期以下で完了したグループで84%、超過したグループで77%です（n=232）^*1。工程ごとの進捗を管理しているかどうかは、提案書の記載粒度からある程度読み取れます。

見極め⑤：契約の型とリスク分担を確認する

見積・工期の検算に加えて、契約でリスクの所在がどう分担されているかも確認が必要です。IPAが公表するモデル契約書は、契約交渉の土台として使える公的な文書です。

IPA「情報システム・モデル取引・契約書（第二版）」を土台に交渉する

IPA（独立行政法人 情報処理推進機構）は、ユーザー企業とベンダー企業の間で使う契約のひな形を公表しています。名称は「情報システム・モデル取引・契約書（第二版）」です^*3。開発会社が独自の契約書式のみを提示する場合、IPAのひな形と比較してリスク分担の記載に不足がないかを確認する材料になります。

多段階契約 — 要件定義と開発を分けて発注する意味

IPAのモデル契約は、要件定義・外部設計・開発・運用といった工程ごとに契約を分ける多段階契約を想定しています^*3。工程を分けて発注すると、要件定義の成果物を確認したうえで開発フェーズの契約可否を判断できます。要件が固まる前に一括で発注するより、後戻りのリスクを抑えやすくなります。

アジャイル開発なら「アジャイル開発版」モデル契約を確認する

ウォーターフォール型ではなく、アジャイル型で開発を進める場合もあります。その際はIPAが別途公表している「情報システム・モデル取引・契約書（アジャイル開発版）」が参考になります^*4。反復的な開発サイクルを前提とした契約条項が用意されており、通常の第二版とは想定する進め方が異なります。

見極め⑥：2026年1月施行の取適法で発注側が負う義務

2026年1月1日に、下請代金支払遅延等防止法を改正した中小受託取引適正化法（取適法）が施行されました。発注側の義務が変わった可能性があるため、契約実務に関わる担当者は内容を確認しておく必要があります。なお、個別の該当性は所管官庁の資料で確認することが前提です^*6。

何が変わったか（令和7年法律第41号）

改正法の名称は「下請代金支払遅延等防止法及び下請中小企業振興法の一部を改正する法律」（令和7年法律第41号）です^*5。令和7年5月16日に成立し、同月23日に公布されました^*5。施行期日は令和8年1月1日で、この日以降に行う製造委託等について適用されます^*5。

自社が「委託事業者」に当たるか

プログラム作成委託の類型では、資本金3億円超の事業者、または常時使用する従業員300人超の事業者が「委託事業者」に区分される可能性があります^*5。従業員基準は、資本金基準が適用されない場合に用いられる基準です^*5。自社がこの基準に該当するかどうかは、資本金・従業員数を確認したうえで個別に判断する必要があります。

発注時に明示すべき事項（第4条）

委託事業者に当たる場合、発注内容等の明示義務（第4条）が生じます^*5。明示すべき事項は、受託事業者の給付の内容・製造委託等代金の額・支払期日及び支払方法その他の事項で、書面又は電磁的方法により直ちに明示します^*5。

電磁的方法で明示した場合でも、受託事業者から書面交付を求められたときは遅滞なく交付する義務があります^*5。発注時の書面フォーマットにこれらの項目が含まれているかを、契約前に確認しておくとよいでしょう。

見極め⑦：4ステップの選定プロセスと逆質問リストで比較する

ここまでの6項目を個別に確認する場だけでなく、選定プロセス自体を段階的に設計することも見極めの一部です。RFP作成から契約まで4段階に分けると、各段階で確認すべき事項が整理しやすくなります。

RFP作成→提案依頼→提案評価→契約の4ステップ

選定プロセスは、RFP（提案依頼書）の作成、複数社への提案依頼、提案内容の評価、契約締結という4つの段階に分けて進めます。各段階で立ち止まって確認することで、比較の軸がぶれにくくなります。

提案時にぶつける逆質問リスト

提案を受ける際は、開発会社からの説明を聞くだけでなく、以下のような逆質問を用意しておくと判断材料が増えます。取引先別価格の設定方法、流通BMSなど連携方式の対応実績、見積工数の算出根拠、フェーズ別の工期管理方法、契約書における多段階契約の可否です。

これらの質問に具体的な数字や手順で答えられるかどうかは、提案書の完成度だけでは分からない実務対応力を測る材料になります。

相見積の比較シートの作り方

相見積を比較する際は、金額の総額だけでなく、人月単価・想定工数・工期・品質目標の4項目を横に並べたシートを作ると、差の理由が把握しやすくなります。 各項目にJUASの実測値を並記しておけば、突出した数字がどちらの方向にずれているかも一目で分かります。

この作業を内製で行うには、業界団体の統計データを読み解く知識と、契約実務・法令の基礎知識の両方が必要です。要件定義の確認、見積の検算、契約書の照合を並行して進めるには、相応の工数がかかります。専門パートナーに相談すれば、検算の視点を共有したうえで提案内容を精査できるため、自社だけで進めるより見落としを減らせます。

まとめ：BtoB EC開発会社を見極める3つの判断軸

本稿では、BtoB EC開発会社の見極め方を7項目に整理しました。要点を3つに集約すると次の通りです。第一に、取引先別価格・与信・承認フローといった業務要件を再現できるかを確認します。第二に、JUASの実測値を基準に見積と工期を検算し、提示額に無理がないかを確かめます。第三に、IPAのモデル契約書と取適法の明示義務を踏まえ、契約でリスクの所在が明確になっているかを見ます。この3点を提案評価の基準に据えておけば、相見積を比較する際にも判断がぶれにくくなります。

---

ご不明な点はお問い合わせフォームからもご連絡いただけます。

よくある質問

BtoB EC開発会社の人月単価の目安はいくらですか。

JUASの2025年調査によれば、人月単価の目安は127万円です^*1。ただしスクラッチ開発は96万円、パッケージ・SaaS利用開発は144万円と、開発方式によって水準が異なります^*1。

提示された工期が短すぎるかどうかは、どう判断すればよいですか。

JUASの回帰式「標準工期＝3.23×投入工数の立方根」で概算し、提示工期がこれを大きく下回る場合は根拠を確認します^*1。実績工期は標準工期の1.08倍が目安であり、1割程度の余裕を見込んでおくと計画が崩れにくくなります^*1。

要件定義だけを別の会社に依頼してもよいですか。

IPAのモデル取引・契約書は要件定義と開発を分けて発注する多段階契約を想定しており、別会社への依頼自体は妨げられません^*3。要件定義の成果物を後工程の開発会社が引き継げる形式で作成することが前提になります。

開発を委託する際、発注書面には何を書けばよいですか。

中小受託取引適正化法の対象になる場合、給付の内容・代金の額・支払期日・支払方法などを書面または電磁的方法で直ちに明示する義務があります^*5。自社が対象事業者に当たるかは、資本金や従業員数の基準に照らして個別に確認する必要があります^*5。

BtoB特有の機能に対応しているかは、どう確認すればよいですか。

取引先別の掛率・与信管理・承認フローに加え、流通BMSなどのEDI標準への対応可否を尋ねるのが具体的な確認方法です^*7。流通BMSは発注・出荷・受領・返品・請求・支払の6業務・8種の標準メッセージで構成されています^*7。

1. *1　出典：一般社団法人 日本情報システム・ユーザー協会（JUAS）「ソフトウェア・メトリクス調査2025【ガイドブック】2025年版」（2025年4月）
2. *2　出典：一般社団法人 日本情報システム・ユーザー協会（JUAS）「企業IT動向調査報告書2026」（2026年4月）
3. *3　出典：独立行政法人 情報処理推進機構（IPA）「情報システム・モデル取引・契約書（第二版）」（2020年12月22日）
4. *4　出典：独立行政法人 情報処理推進機構（IPA）「情報システム・モデル取引・契約書（アジャイル開発版）」（2020年3月31日）
5. *5　出典：公正取引委員会・中小企業庁「中小受託取引適正化法テキスト」（令和7年11月）
6. *6　出典：公正取引委員会「中小受託取引適正化法（特設ページ）」
7. *7　出典：一般財団法人 流通システム開発センター（GS1 Japan）「流通ビジネスメッセージ標準（流通BMS）」