EDIシステム開発の発注/外注/依頼/委託方法について

EDIシステム開発を外注する場合は、発注前の準備から始め、開発会社を選んで契約し、発注後の管理へと進みます。

• EDIシステム開発を外注すべき理由
• 発注前の準備
• 開発会社の選び方
• 契約時の注意点
• 発注後のプロジェクト管理

全銀手順やJX手順（流通BMS）などの専門的な通信プロトコルへの対応が必要で、一般的なWebシステム開発会社に発注すると技術的なリスクが高くなります。詳しくは、以下の完全ガイドをご覧ください。

▼全体ガイドの記事
・EDIシステム開発の完全ガイド

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

EDIシステム開発を外注すべき理由

外注のメリットと内製との比較

EDIシステム開発を外注する最大のメリットは、EDI固有の専門知識を持つエンジニアをすぐ確保できる点です。JX手順（流通BMS）の仕様書の読み込みと実装、AS2のSSL/TLS証明書管理・MDN応答処理、全銀TCP/IP手順の電文フォーマット実装は、経験のないエンジニアには習得に数ヶ月かかる分野です。外注すれば、こうした専門エンジニアをプロジェクトにすぐ投入できます。

外注と内製の主な違いを比べると、次のようになります。

EDIシステムは、取引先との接続テストや業界標準プロトコルへの対応という特殊性があるため、リスク低減の観点では、専門会社への外注が有利なケースが多いです。ただし、外注後の保守運用体制は長期的な計画が必要です。「開発は外注、保守は内製」という移行を視野に入れ、ナレッジ移転の計画を最初から立てておくことが推奨されます。

外注に向いているケース

EDIシステム開発の外注が特に適しているのは、次のようなケースです。大手流通・製造企業から取引継続のためのEDI対応を求められ、早急な対応が必要なケースです。現在FAX・メール・電話で行っている受発注業務を電子化して業務効率を改善したい一方、社内にシステム開発の人手がないケースも該当します。

既存のEDIシステムが老朽化し、クラウド移行や多プロトコル対応への刷新が必要な場合も該当します。VANサービスから直接EDI（AS2・SFTP等）へ移行を検討し、技術的な知見がない状況も含まれます。

一方、自社にEDI経験のあるエンジニアがいて、特定のプロトコル追加だけ専門的な支援が必要な場合は、フルアウトソースよりも、技術コンサルティング契約や一部機能の外注が適切です。外注の範囲を明確にしたうえで、コアとなるビジネスロジックは内製で持ち、EDI固有の専門技術部分だけを外注する組み合わせも有効です。

発注前の準備

要件定義と取引先との調整

EDIシステムの発注前に最も重要な準備は、取引先から必要な技術仕様の情報を集めることです。EDI接続を求める取引先（特に大手流通・製造企業）は、通常、仕様に関する資料を提供しています。

取引先から得た資料をもとに、次の4点を押さえておきます。

1. 取引先のEDI接続仕様書・通信仕様書・フォーマット仕様書の入手
2. プロトコル（JX手順・AS2・SFTP等）、帳票（発注書・出荷通知・請求書等）、フォーマット仕様（XMLタグ定義・CSVフォーマット等）、テスト環境の有無
3. 稼働開始目標日、接続テストの窓口、障害時の連絡・エスカレーション手順の調整
4. ERP・WMS・会計システムとの連携要件の洗い出し

取引先との事前すり合わせは、発注前に済ませておくのが理想的です。すり合わせておくことで、プロジェクト中の手戻りを防げます。

こうして整理した情報を発注先に伝えることが、実態に即した見積もりと提案を得るための鍵です。

さらに、社内システム（ERP・WMS・会計システム）との連携要件も、EDIシステムの設計・開発費用に大きく影響します。「EDIで受信した発注データをERP（SAP・Oracle等）に自動取り込みしたい」「ERPの出荷データをEDIで自動送信したい」といった要件が、その代表例です。

連携対象システムの担当部門や担当者にも、要件の詳細を事前に確認しておくことが欠かせません。

予算・スケジュールの設定

EDIシステムの予算は、初期開発費用、ランニングコスト（月次保守費用・クラウド費用・ライセンス費用）、取引先追加時の費用を含めたTCO（総保有コスト）で計画します。初期費用の相場は、取引先5〜10社の小規模で50万〜300万円、取引先10〜50社の中規模で300万〜1,000万円が目安です。ランニングコストは、月次5万〜30万円程度を見込んでおくのが現実的です。

スケジュールは、取引先から求められた稼働開始日から逆算して設定します。一般的なEDIシステムの開発期間は、要件定義から本番稼働まで3〜6ヶ月程度です。ただし、取引先との接続テスト期間は取引先の対応スピードに左右されるため、不確定要素が大きくなります。

特に大手流通企業との接続テストは、取引先のテスト環境の空き状況や窓口担当者のスケジュールに左右されることがあります。そのため、「接続テストフェーズに最低1ヶ月の余裕を持たせる」という計画が、現場の実態に即しています。

開発会社の選び方

EDI専門知識を持つ会社の選び方

EDI開発会社を選ぶ際は、自社が必要とするプロトコルの具体的な実績があるかを最初に確認します。「EDI開発の経験があります」という回答では足りず、「JX手順（流通BMS）での大手小売との接続実績が○件あります」のように、具体的な実績を聞く必要があります。Web-EDIのみの経験しかない会社に、直接EDI（JX手順・AS2等）の開発を頼むと、リスクが高くなります。

業界知識も選定の基準です。流通業では流通BMSの標準仕様（発注・出荷・請求の各帳票の必須項目・任意項目）、製造業ではRosettaNetやVDA（ドイツ自動車業界標準）への対応経験、金融業では全銀フォーマットの詳細知識が求められます。自社の業界でEDI実績が豊富な会社を選ぶと、設計品質と手戻りリスクの削減につながります。

接続テストの支援範囲も、あわせて確認しておきます。納品して終わりにせず、取引先のテスト環境との疎通確認や本番接続の立ち会いまで担ってくれる会社を選ぶことが、プロジェクトを本番稼働まで確実に導くうえで大切です。「取引先と直接やり取りして接続テストを主導してもらえるか」は、事前に確認しておくことが欠かせません。

相見積もりの取り方

EDIシステムの見積もりは、最低3社から取得することを推奨します。見積もり依頼書（RFP）には、対応が必要なプロトコルと取引先数、対応帳票の種類と各帳票のサンプルデータ（可能な範囲で）、連携が必要な社内システムの一覧とAPIの有無を書きます。さらに、稼働目標日と段階的な展開の計画、概算予算の上限と優先事項、取引先側でのテスト環境の準備状況も伝えます。

相見積もりでは、取引先接続テストの支援内容と移行（旧システムからの切り替え）費用が見積もりに含まれているかを確認します。加えて、運用マニュアル作成費用と初期設定費用の有無も見ておき、同じ条件で金額を比べます。

EDI開発の見積もりには、工数積み上げ型（作業項目ごとの工数×単価）とフィックス型（成果物ベースの固定価格）があります。要件が確定していればフィックス型、仕様が変わる可能性があれば工数積み上げ型が適しています。

契約時の注意点

契約形態の選択

EDIシステム開発の契約形態は、準委任契約と請負契約の2種類が一般的です。

• 準委任契約（時間・材料型）：稼働時間に対して報酬が発生するため、要件が変わりやすい場合や、上流工程からコンサルティングを依頼したい場合に適しています。
• 請負契約（固定価格型）：成果物の納品に対して報酬が発生し、要件が明確な場合に予算の上限を決められます。

そこで、要件定義と基本設計は準委任契約で、要件が固まってからの開発とテストは請負契約で進める組み合わせが多く採用されます。この方式なら、上流での柔軟な要件調整と、開発段階の追加費用リスクの管理を両立できます。

請負契約では、スコープ変更時の費用算定方法（変更管理プロセス）を契約書に定めておくことが大切です。EDI開発では、接続テストが取引先の対応スピードに左右されて遅れやすい点に注意が必要です。「取引先都合での接続テスト遅延は追加費用対象としない」「接続テストフェーズの期間延長は○ヶ月まで追加費用なし」といった取り決めを契約書に明記しておくと、後のトラブル防止に有効です。

さらに、EDI開発特有の契約上の注意点として、取引先との接続テストが完了しない場合の扱いがあります。この扱いも、契約書に明記しておきます。

保守・運用契約の重要性

EDIシステムは本番稼働後も保守が続くため、保守・運用契約は初期開発契約と同じくらい重要です。確認すべき項目は、障害対応の優先度と対応時間（24時間365日か、営業時間内のみか）、定期的なセキュリティアップデートと脆弱性対応の有無です。

さらに、取引先から求められるフォーマット変更やプロトコル変更への対応費用、新規取引先追加時の設定費用と対応時間の目安も、取り決めておきます。EDIシステムは長期稼働を前提とするミッションクリティカルなシステムのため、開発会社の事業継続性も確認すべき点です。

5〜10年後も安定してサポートを受けられるか、開発会社が吸収合併や事業撤退になった場合のソースコードの扱いとサポート移行の手順を、契約書に明記しておくことをお勧めします。また、ソースコードの所有権と開示範囲（将来的な内製保守に備えた取得権）も、契約前に確認・合意しておくことが大切です。

発注後のプロジェクト管理

EDIシステムの開発は、要件定義から開発までを経たあと、単体テストと結合テストに進みます。その後、取引先接続テストと並行運用を経て、本番切り替えを迎えます。

発注後は、週次または隔週で定期的な進捗報告の場を設け、各フェーズの完了状況、課題、リスクを確認する体制を整えておくことが大切です。

特に取引先接続テストのフェーズは、開発会社に加えて発注側の業務担当者と取引先の三者が関わります。業務担当者はテストデータの準備や業務の観点からの確認を行い、取引先との連絡調整は開発会社と発注側で役割分担を明確にしておきます。

取引先接続テストで見つかるデータ不整合やプロトコル解釈の違いは、設計書に立ち返って修正が必要になることがあります。そのため、テスト結果の記録と修正履歴を管理する体制が欠かせません。

本番稼働後のトラブルに備え、障害対応の体制も事前に整えておくことが大切です。EDIシステムのエラーは取引先との受発注業務に直結します。このため、障害発生時の一次対応（発注会社側・取引先側・開発会社側それぞれの役割）、エスカレーション手順、取引先への連絡方針を事前に決めておくと、緊急時の混乱を最小限にできます。

まとめ

発注前の準備では、取引先から仕様書を入手し、対応プロトコル・帳票・社内システム連携要件を整理したうえでRFPを作成することが出発点です。

開発会社の選定では、自社が必要とするプロトコルの具体的な実績、業界知識、取引先接続テスト支援の範囲を確認します。そのうえで、最低3社から相見積もりを取ることを推奨します。

契約時は、準委任契約と請負契約の使い分け、取引先接続テストの遅延時の費用の扱いを明確にします。保守契約では、対応時間、フォーマット変更対応、新規取引先追加費用を確認し、ソースコードの所有権も押さえておくことが、トラブル防止の鍵です。

発注後は、自社・開発会社・取引先の三者が連携したテスト管理体制を整えます。本番稼働後の障害対応フローも事前に確立しておくことで、EDIシステムの安定稼働につながります。

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。