EDIシステム開発の開発期間・スケジュール・納期について

EDIシステムとは、受発注・出荷・請求といった企業間の商取引データを、電話回線やインターネット回線を介して電子的にやり取りする仕組みを指します。かつては流通業界や製造業のサプライチェーンで、JCA手順や全銀協手順といった電話回線ベースの通信プロトコルが主流でしたが、近年はインターネットEDI（IP-EDI）や経済産業省主導で策定された流通BMS（流通ビジネスメッセージ標準）への移行が進み、さらにNTT東西のINSネット（ISDN）のデジタル通信モードが段階的に終了へ向かうという業界事情も重なって、多くの企業が新規構築・刷新のタイミングを迫られています。EDIシステムは自社の中だけで完結せず、取引先企業とデータ形式・通信手順をすり合わせながら稼働させる特性を持つため、一般的な業務システムとは異なる期間の読み方が必要になります。

本記事では、EDIシステム開発の開発期間・スケジュール・納期に焦点を当て、規模別の期間の目安、要件定義から本稼働までの工程別配分、取引先との接続テスト・並行運用が期間に与える影響、レガシーEDIからの移行が期間を押し上げる背景、そして納期遅延の典型要因と対策までを、具体的な数値とともに体系的に解説します。新規にEDIシステムを構築する方はもちろん、老朽化したレガシーEDIの刷新やWeb-EDIからの脱却を検討している方にとっても、現実的なスケジュールを描くための判断軸が身に付く内容です。

本テーマに関する全体ガイドは、以下の記事をご覧ください。

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

EDIシステム開発期間の全体像

EDIシステムの開発期間は、対象となる取引先の数、カスタマイズの有無、既存の基幹システムとの連携の度合いによって大きく変動します。クラウド型のパッケージやASP（アプリケーションサービスプロバイダ）を利用し汎用機能のみで構成する小規模版であれば、総期間はおよそ1〜2か月が目安です。パッケージにカスタマイズを加える中規模版になると3〜6か月、基幹システムとの統合やフルスクラッチ開発を伴う大規模版では6か月〜1年以上を見込む必要があります。EDIシステムが他の業務システムと決定的に異なるのは、期間を左右する主因が「自社内の機能開発」ではなく「取引先を巻き込んだ接続調整」にある点で、この特性を理解しないまま一般的なシステム開発の感覚でスケジュールを引くと、後工程で大幅な遅延を招きやすくなります。

費用面でも規模によって相場が明確に分かれます。クラウド型の場合、取引先50社以下の小規模版は初期費用0〜10万円・月額費用1〜5万円、取引先50〜300社の中規模版は初期費用10〜50万円・月額費用5〜15万円、取引先300社以上の大規模版は初期費用50〜200万円・月額費用15〜30万円以上が目安です。一方、オンプレミス型やフルスクラッチ開発の場合は初期費用300万〜1,000万円以上、年間保守費用50万〜200万円という水準になり、これに加えてデータ移行費用10万〜100万円、研修費用10万〜50万円、取引先向け説明会費用5万〜20万円といった周辺コストも発生します。期間と費用はセットで検討する必要があり、どちらか一方だけを見て意思決定すると、実態と乖離した計画になりかねません。

規模別にもう少し具体的な工程配分を見ていきましょう。小規模版（クラウド型・汎用機能のみ）は、要件定義・システム選定に2週間、契約・初期設定に1週間、データ移行・テストに2週間、社内研修・取引先周知に2週間を割り当て、その後は即時に本稼働へ移行するのが標準的な流れです。中規模版（パッケージベース・追加カスタマイズあり）では、要件定義・システム選定に1か月、契約・カスタマイズ要件確定に1か月、開発・初期設定に2〜3か月、データ移行・テストに2週間、社内研修・取引先周知に1か月をかけたうえで、並行運用・本稼働開始までさらに1〜3か月を確保します。大規模版（基幹システム統合・フルスクラッチ開発）になると、要件定義・システム選定に2〜3か月、契約・仕様設計に2〜3か月、開発・カスタマイズに3〜6か月、データ移行・テストに1〜2か月、社内研修・取引先周知に1〜2か月、段階的並行稼働・本稼働開始に3か月以上を見込みます。基幹システム全体のリプレイスを伴う場合は、1〜3年規模のプロジェクトになることも珍しくありません。

EDIシステムの開発期間を左右する最大の要因は、取引先ごとに異なるEDI仕様・通信プロトコルへの対応です。取引先は自社が採用しているJCA手順、全銀協手順、流通BMS、Web-EDI、あるいは個別開発のAPI-EDIなど、それぞれ異なる方式でつながっていることが多く、新システムに合わせて接続設定を変更するには、自社の開発作業だけでなく取引先への事前通知とテスト接続のスケジュール調整が全取引先と並行して必要になります。取引先数が多い卸売業や商社では、このEDI切り替え作業だけで2〜3か月のリードタイムを要することも珍しくありません。もう一つの大きな要因が、既存システム間で分散している取引先マスタや商品マスタのクレンジングです。「株式会社〇〇」と「（株）〇〇」の表記揺れ、重複登録、部分的な欠損データなどを整理する作業には相応の時間がかかるため、カットオーバー（本稼働切り替え）の4〜6か月前から着手しておくことが望まれます。さらに、受発注・出荷・請求・支払といった複数のメッセージ種別を扱う場合、データフォーマットの変換ロジックが複雑になり、CSV・XML・固定長といった形式が混在するとその分だけ設計・テスト工数が積み上がる点にも注意が必要です。

要件定義から本稼働までの工程別スケジュール

EDIシステム開発の期間を正しく見積もるには、プロジェクト全体を工程に分解し、それぞれにどれだけの時間が必要かを把握することが欠かせません。中規模のEDIシステム（開発期間およそ半年）を例に取ると、工程は要件定義・仕様策定、開発・初期設定、取引先接続テスト、並行運用、本稼働という流れで進みます。EDIシステムの場合はとくに要件定義段階での通信手順・データフォーマットの確定と、後半の取引先接続テストに厚く時間を配分する点が特徴で、上流の仕様確定を軽視して開発を急ぐと、終盤で取引先とのフォーマット齟齬が発覚し、全取引先を巻き込んだ手戻りに発展します。

EDIシステム開発において、要件定義と仕様策定はプロジェクト全体の成否を握る最上流工程です。半年規模のプロジェクトであれば、ここに全体の1〜2割にあたる1〜2か月を割り当てます。この工程で確定させるべきは、採用する通信手順（流通BMS、全銀協TCP/IP手順、Web-EDI、API-EDIのいずれか、または複数の併用）、やり取りするメッセージ種別（受発注、出荷、検収、請求、支払）ごとのデータ項目定義、そして取引先マスタ・商品マスタの統合ルールです。とりわけ通信手順の選定は根幹で、後工程で方式を変更すると、取引先への再調整が発生し全体スケジュールに深刻な影響を与えます。この工程を軽く見て開発に進むと、取引先へのヒアリングが後手に回り、実際に必要な項目が開発途中で次々と判明して手戻りが多発します。要件定義書と接続仕様書を成果物として明文化し、変更が発生した場合の取り扱いルールまで合意しておくことが、納期遵守の最大の予防策になります。

要件定義と仕様策定が固まったら、開発・初期設定フェーズに移ります。この工程は全体の中でも大きな比重を占め、半年規模なら2〜3か月を見込みます。開発では、通信手順に応じたコネクタの実装、データフォーマットの変換ロジック（CSV・XML・固定長の相互変換）、既存の販売管理システムや会計ソフトとのAPI・CSV連携、そしてイレギュラー業務（返品、値引き、数量一部出荷、複数拠点への分割出荷など）への対応ロジックを並行して作り込みます。ここで期間短縮の鍵になるのが、取引先ごとの個別仕様をできるだけ早い段階で洗い出し、共通化できる部分と個別対応が必要な部分を仕分けておくことです。標準機能で吸収できない商慣習が多いほど、開発・カスタマイズの工数は膨らみます。社内テストの段階では、まず自社の販売管理システムや会計ソフトとの連携が正しく動くかを確認し、この時点で不具合を潰しておくことで、次工程の取引先接続テストをスムーズに進められます。

取引先との接続テスト・並行運用が期間に与える影響

EDIシステムが一般的な業務システムの開発と最も異なるのは、自社の開発が完了しても、取引先というコントロールできない相手を巻き込んだ接続テストと並行運用を経なければ本稼働できない点にあります。取引先数が多いほど、テスト接続のスケジュール調整だけで多くの時間を要し、ここが期間を読みにくくする最大の要因になります。ここでは、取引先ごとの個別仕様への対応と接続テストのスケジューリング、そして新旧システムの並行運用とカットオーバーのタイミング設計という二つの観点から、この影響を整理します。

取引先ごとに異なるEDI仕様・通信プロトコルへの対応は、自社内だけで完結しない性質上、事前通知とテスト接続のスケジュール調整を全取引先と並行して進める必要があります。主要な取引先から優先的に接続テストを行い、問題が見つかれば早期に修正できるようにする段階的なアプローチが有効ですが、取引先数が多い卸売業や商社では、この切り替え作業だけで2〜3か月のリードタイムが必要になることも珍しくありません。接続テストでは、実際にデータを送受信して正しくフォーマット変換されるか、エラー時の再送処理が機能するか、取引先側のシステムとタイミングよく同期できるかを確認します。取引先側の担当者や情報システム部門のスケジュールにも左右されるため、自社の都合だけで日程を組めない点が、EDIシステム特有の難しさです。連絡窓口を一本化し、進捗状況を可視化する仕組みを用意しておくことで、多数の取引先とのやり取りが錯綜する事態を防げます。

取引先との接続テストが完了した後も、いきなり新システムへ全面移行するのではなく、一定期間は新旧システムを並行して稼働させる「並行運用」を挟むのが安全な進め方です。中規模のプロジェクトでは1〜3か月、大規模なプロジェクトでは3か月以上の並行運用期間を確保するのが一般的で、この期間中に受発注データの件数照合や、イレギュラー処理（返品・値引き・一部出荷など）が新システムで正しく処理できるかを実運用のなかで検証します。カットオーバー（本稼働への切り替え）のタイミングは、全取引先が新方式への対応を完了できているかどうかに強く依存するため、対応が遅れている取引先が一社でも残っていると、全体のカットオーバー時期をずらさざるを得ないケースもあります。段階的にグループ分けした取引先を順次カットオーバーしていく方式も選択肢の一つですが、その場合は新旧両方式を並行してサポートする期間が長引くため、運用負荷とコストのバランスを見ながら計画することが求められます。

レガシーEDIからの移行が期間を押し上げる背景

近年、EDIシステムの新規構築・刷新案件が増えている背景には、業界特有の構造的な事情があります。長年使われてきたJCA手順や全銀協手順といったレガシーEDIは、電話回線やISDN回線を前提とした仕組みであり、通信基盤そのものの世代交代という大きな流れの影響を受けています。この移行圧力を理解しておくことは、なぜ今EDIシステムの刷新が期間・予算をかけてでも避けられない経営課題になっているのかを把握するうえで欠かせません。

いわゆる「EDIの2024年問題」として業界内で広く知られているのが、NTT東西が提供してきたINSネット（ISDN）のデジタル通信モードのサービス終了に伴い、電話回線経由で動いてきたレガシーEDI（JCA手順など）がそのままでは使えなくなるという課題です。これにより、多くの企業がインターネットEDI（IP-EDI）や流通BMSへの移行を、システムの寿命とは関係なく計画しなければならない状況に置かれています。移行にあたっては、単に通信経路をインターネット回線に切り替えるだけでなく、通信プロトコルやデータフォーマットも合わせて刷新するケースが多く、取引先全社との調整が必要になるため、通常のシステム更改よりも長いリードタイムを見込んでおく必要があります。加えて、標準化されていないWeb-EDI（取引先ごとに異なるブラウザ発注画面へログインしてデータを入力する方式）が乱立している業界構造も、受注側企業の運用負荷を高め、統合的なEDI基盤への移行ニーズを後押ししています。

JCA手順や全銀協手順から流通BMSやAPIベースのインターネットEDIへ移行する際は、単なる通信方式の変更にとどまらず、データフォーマットの構造そのものが変わることが多く、変換ロジックの再設計が必要になります。流通BMSはXML形式を採用し、受発注や出荷、請求といったメッセージ種別ごとに標準化された項目定義を持つため、旧来の固定長データをそのままでは流用できません。この変換ロジックの再構築には、既存の業務ルールをどこまで新フォーマットに落とし込めるかの検証が伴い、想定以上に工数がかかるケースが少なくありません。また、取引先の中には移行対応が遅れている企業や、そもそも流通BMSに対応していない中小企業も存在するため、旧方式と新方式の両方をサポートするハイブリッド運用期間を一定期間設けざるを得ないことも、期間が延びる一因になります。移行を検討する際は、自社の対応スケジュールだけでなく、主要取引先の移行状況を早期にヒアリングし、全体のロードマップに反映させておくことが重要です。

納期遅延の典型要因と対策

どれだけ綿密に計画しても、EDIシステム開発における納期遅延のリスクをゼロにすることはできません。重要なのは、遅延の典型要因を事前に把握し、対策を契約や進捗管理の仕組みに組み込んでおくことです。EDIシステムに特有の遅延要因は、マスタデータのクレンジング不足と、現場のイレギュラー業務の洗い出し不足という二つに集約されます。

EDIシステムの納期遅延で筆頭に挙がるのが、取引先マスタや商品マスタのクレンジング不足です。既存システムに散在していたマスタデータには、社名の表記揺れ（「株式会社」と「（株）」の混在など）、同一取引先の重複登録、商品コードの体系不一致といった問題が必ずと言っていいほど存在し、これをそのまま新システムに移行すると、受発注データの照合ができない、請求金額が合わないといった深刻なトラブルを招きます。対策は、要件定義の段階でマスタデータの棚卸しに着手し、カットオーバーの4〜6か月前から整備を進めておくことです。データクレンジングは一度で終わらせようとせず、テスト移行を複数回繰り返しながら、移行前後の件数と内容の差分を検証することが鉄則です。この作業を後回しにすると、開発が完了しているのにマスタが整わずカットオーバーできない、という本末転倒な事態に陥ります。

もう一つの遅延要因が、現場に根付いたイレギュラー業務の洗い出し不足です。数量一部出荷、返品、値引き、複数拠点への分割出荷、得意先ごとの個別取引条件など、システム仕様書には明文化されていない「職人芸」的な現場ルールは、要件定義の段階で漏れなく洗い出しておかないと、開発の終盤や取引先接続テストの段階になって次々と表面化します。こうした後出しの要件は、当初のスコープを超える追加開発を招き、スコープクリープ（開発範囲の無秩序な拡大）として納期を圧迫します。対策は、要件定義の段階で現場担当者へのヒアリングを徹底し、システムで対応する範囲と手作業運用に残す範囲の線引きを明確にすることです。また、仕様変更が発生した場合は、影響範囲の調査・工数見積もり・承認という変更管理プロセスを踏むルールを最初に合意しておくことで、口頭での「ちょっとした追加」の積み重ねによる予算・納期超過を防げます。見積もり段階で全体工数の10〜20%程度をバッファとして確保しておくことも、想定外の事態に備える現実的な対策です。

まとめ

本記事では、EDIシステム開発の開発期間・スケジュール・納期について、規模別の期間目安、工程別の配分、取引先接続テストと並行運用の影響、レガシーEDI移行という業界背景、そして納期遅延の典型要因と対策までを体系的に解説しました。開発期間の目安は、クラウド型の小規模版で1〜2か月、パッケージ+カスタマイズの中規模版で3〜6か月、基幹統合・フルスクラッチの大規模版で6か月〜1年以上であり、費用はクラウド型で初期0〜200万円・月額1〜30万円以上、オンプレミス・フルスクラッチで初期300万〜1,000万円以上・年間保守50万〜200万円が一つの目安です。EDIシステムの期間を決めるのは自社内の開発工数だけでなく、取引先を巻き込んだ接続調整であり、取引先数の多い企業ほどこの調整に2〜3か月を要する点、そしてISDN回線終了に伴うレガシーEDIからインターネットEDI・流通BMSへの移行が業界全体で急務になっている点を理解しておくことが、現実的なスケジュールを描く前提になります。遅延の典型要因はマスタデータクレンジングの遅れとイレギュラー業務の洗い出し不足であり、いずれも上流でのデータ棚卸しと要件定義の徹底、10〜20%のバッファ設定が対策の柱です。まずは自社が抱える取引先の数と接続方式、そして現場のイレギュラー業務を整理したうえで、複数の開発会社にEDI連携の実績を確認しながら見積もりを取ることから始めることをお勧めします。

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

株式会社riplaでは、IT事業会社出身のプロフェッショナルが「Impact-Driven型支援」を通じて、プロダクトやシステムの納品・提供を目的とせず、お客様と同じ目線で、事業成果の達成をゴールとして、高品質なDX/開発支援をいたします。

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

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

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

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

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。IT事業会社出身のプロフェッショナルが集う株式会社riplaにおいて、「Impact-Driven型支援」を掲げ、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の実現に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。