EDIシステムのRFP/要件定義書/提案依頼書について

EDIシステムの導入・刷新を進めるとき、成否を左右するのが要件定義とRFP（提案依頼書）の質です。EDIは自社単体で完結するシステムではなく、取引先・基幹システム・通信回線という複数の関係者をまたいで動きます。そのため、要件を曖昧なまま発注すると、データマッピングの工数が想定の何倍にも膨れ上がったり、取引先ごとの差異が後から噴出したり、企業間で「どちらの責任か」を巡るトラブルに発展したりします。とくにEDIは「繋がって当たり前」と思われがちで、要件定義が軽視されやすい分野ですが、実際にはここでの詰めの甘さが、後工程で最も高くつくのです。

本記事は、EDIシステムの要件定義書・RFP（提案依頼書）に盛り込むべき要件を、企業間連携の責任分界・通信／データ変換要件・基幹連携とトランザクション設計・法令／非機能要件という観点から体系的に整理する「要件定義特化」の記事です。とくに、多くのRFPで抜け落ちがちな「片方だけ処理が進んだときの責任と復旧」「電帳法・J-SOX・通信手順の数値要件」まで踏み込んで解説します。読み終えるころには、ベンダーに渡せる要件の骨格が描けるはずです。なお、EDIシステム全体の費用相場や進め方をまだ把握していない方は、先にEDIシステムの完全ガイドから読むことをおすすめします。

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

企業間連携の責任分界点を要件化する

EDIの要件定義で最も見落とされ、しかし最も重要なのが、企業間連携の「責任分界点」を要件として明文化することです。EDIは自社と取引先という別々の企業をまたいでデータが流れるため、どこまでが自社の責任で、どこからが取引先やベンダーの責任かという境界を曖昧にしたまま進めると、トラブル時に「言った言わない」の押し付け合いになります。社内システムの要件定義とは異なる、企業間システムならではの視点がここで求められます。

まず要件化すべきは、「データがどこまで届けば自社の責任を果たしたとみなすか」という到達責任の境界です。送信したデータが相手の受信サーバーに届いた時点なのか、相手の基幹システムに正しく取り込まれた時点なのか、で責任の重さが変わります。EDIでは到達確認（受信通知）の有無と、それを取引の証跡として双方が認めるかを要件として定める必要があります。ここを定義しておかないと、「注文を送ったのに処理されていない」というトラブルで、送信側と受信側のどちらに非があるかを判断できません。

あわせて、受信したデータの正当性チェックをどちらが担うかも要件化します。たとえば必須項目の欠落や桁数違反、未登録の商品コードといった不備があった場合、送信側がデータを訂正して再送するのか、受信側が補正するのかを取り決めます。EDIシステムには、この不備を検知してエラーとして返す機能が求められますが、エラーをどう扱うかは技術ではなく業務上の責任分担の問題です。要件定義の段階で取引先と合意し、RFPに「データ不備時の責任分担と再送ルール」として明記しておくことが、後のトラブルを防ぎます。

とくに荷待ち記録のような企業間でまたがるデータでは、誰がいつ入力し、それをエビデンスとして双方が認めるかという論点が空白になりがちです。EDIで扱う受発注・出荷データでも、相手側の都合で遅延や訂正が生じたとき、その記録をどちらのシステムに、どの権限で残すかを定めておかないと、後から事実関係を確認できません。責任分界の要件は、正常時だけでなく異常時・例外時のデータの扱いまで踏み込んで定義することで、初めて実効性を持ちます。

EDIプロジェクトでは、自社の基幹システムのベンダー、EDIツールのベンダー、取引先側のシステム担当という複数の関係者が関わります。データが流れる経路のどこで障害が起きたかによって、責任を負う主体が変わるため、RFPでは「障害発生時にどのベンダーが一次対応の窓口になるか」「ベンダー間の責任境界をどこに引くか」を要件として求める必要があります。ここが曖昧だと、障害時に各社が「うちの担当範囲ではない」と主張し、復旧が遅れます。

とくに「API連携で全体最適」をうたう提案では、企業間でトランザクションが複数システムをまたぐため、障害時の切り分けが難しくなります。要件定義の段階で、各システムの境界（インターフェース）を明確に定義し、それぞれの境界でデータが正しく受け渡されたことをログで確認できる仕組みを要件に含めると、責任の切り分けが容易になります。riplaはフルスクラッチ受託の立場から、企業間連携の責任分界を契約・要件の両面で整理し、「繋げば全体最適」の理想論で終わらせない要件設計を支援しています。

通信手順・データ変換の要件を数値で定義する

EDIの要件定義で具体性が問われるのが、通信手順とデータ変換の要件です。ここを抽象的な言葉で済ませると、ベンダーが見積もりを正確に出せず、後から「想定外の変換が必要だった」と追加費用が発生します。逆に、現状の取引先構成と通信手順、データ形式を棚卸しして要件に落とし込めば、ベンダーは精度の高い提案ができ、こちらも複数社を公平に比較できます。

通信手順の要件は、自社の取引先がどの手順を使っているかの棚卸しから始まります。流通業界標準のJX手順、金融標準の全銀TCP/IP手順、国際的なAS2やebMS、従来型の全銀手順など、取引先ごとに採用手順が異なります。RFPには「対応が必須な通信手順の一覧」と「各手順を使う取引先の社数・取引量」を記載し、INSネット終了で移行が必要な取引先がどれだけあるかも明記します。これにより、ベンダーは必要な手順対応の範囲を正確に把握できます。

あわせて、Web-EDIで対応する取引先と、システム間EDIで対応する取引先の区分も要件化します。IT対応が難しい中小取引先はWeb-EDIの画面入力、システムを持つ大手取引先はシステム間連携、というように手段を使い分けるのが一般的です。さらに、FAXや電話の注文が残る取引先について、それをAI-OCRなどでデータ化して統合する要件を盛り込むかどうかも、この段階で判断します。取引先構成の棚卸しを丁寧に行うほど、要件の精度と見積もりの正確さが上がります。

EDI構築で最も工数を要するデータマッピングは、要件定義の精度が費用に直結します。RFPには、取引先のデータ形式と自社基幹のデータ形式の差を、文字コード（EBCDIC・Shift_JIS・UTF-8など）、日付や金額の桁数・表記、項目の並び順といった具体レベルで書き出します。とくに商品コードの変換テーブルが何件規模になるか、取引先ごとに別々のマッピングが何パターン必要かを示すと、ベンダーはマッピング工数を正確に見積もれます。ここを「適宜対応」とだけ書くと、見積もりが甘くなり後で揉めます。

要件としては、変換ルールを画面上でノンプログラミングに定義・保守できることを求めるか、それともプログラム実装でよいかも明記します。取引先の追加・変更が頻繁な企業ほど、現場で変換定義を保守できる機能を要件に含めるべきです。また、未登録の商品コードや想定外のデータ形式が来たときにエラー検知できることも、マッピング要件の一部として書き込みます。データ変換の要件を数値と具体例で固めることが、追加費用の膨張を防ぐ最大の防波堤になります。

基幹連携とトランザクション要件を設計する

EDIと基幹システムを連携させて自動化を進めるなら、トランザクション（処理の一貫性）に関する要件を設計段階で固めることが不可欠です。EDI側でデータ受信が成功しても、基幹側への取り込みで失敗すると、データが片方だけ処理された不整合状態が生まれます。この「片肺飛行」をどう検知し、どう復旧するかを要件化しないと、運用開始後に原因不明の受注漏れや二重計上が発生します。

トランザクション要件の核心は、不整合の検知とリカバリの定義です。「EDI受信成功・基幹取り込み失敗」のような中途半端な状態を自動で検知し、その注文がどの段階で止まっているかを可視化する要件を盛り込みます。さらに、失敗したデータを安全に再取り込みする仕組み、あるいは処理全体を取り消すロールバックの仕組みを、どちらの方式で実現するかを要件として定めます。これがないと、運用担当者が手作業でデータを突き合わせる消耗戦になります。

とくに受発注のデータは、二重に取り込まれると過剰出荷や過剰請求につながり、企業間の信頼を損ないます。再送時に同じデータが重複しないよう、一意キーで重複を排除する冪等性（同じ処理を何度実行しても結果が変わらない性質）の要件も検討します。J-SOXの観点では、こうした処理の証跡（いつ・誰が・どのデータをリカバリしたか）をログに残す要件も求められます。トランザクション要件は技術的に見えますが、企業間取引の正確性を担保する業務要件そのものです。

基幹連携の方式も要件化します。リアルタイムにAPIで連携するのか、一定間隔でファイル（CSV・固定長）をやり取りするバッチ連携にするのかで、システムの作りと費用が変わります。受注のように即時性が重要なデータはリアルタイム、夜間にまとめて処理してよいデータはバッチ、というように、データの性質に応じて方式を要件で指定します。すべてをリアルタイムにすると費用が膨らむため、業務上の必要性に照らした切り分けが要件定義の腕の見せ所です。

あわせて、連携の対象となる基幹システムの仕様（製品名・バージョン・連携用インターフェースの有無）を要件に明記します。既存の基幹がAPIを公開していない場合、ファイル連携や中間テーブルを介する設計が必要になり、その分の工数を見込む必要があります。基幹側の制約を要件定義で洗い出さずに進めると、開発後半で「連携できない」という致命的な手戻りが起きます。連携方式の要件は、EDI単体ではなく基幹システムとセットで設計することが原則です。

連携のタイミングや頻度も要件に落とし込みます。受注データを即時に取り込むのか、一定間隔でまとめて処理するのか、夜間バッチで一括処理するのかによって、現場の運用も変わります。さらに、連携が失敗したときに誰がどう気づくか、再実行はどの権限で行うかといった運用要件も、この段階で定めておくと稼働後の混乱を防げます。連携の要件は、正常時の流れだけでなく、頻度・タイミング・異常時の運用までを一体で設計することが、安定稼働の前提になります。

法令・非機能・移行の要件を漏らさない

機能要件を固めたら、見落とされがちな法令要件・非機能要件・移行要件をRFPに盛り込みます。これらは「動くシステム」を「安心して長く使えるシステム」にするための要件であり、後付けすると大きなコストがかかるため、最初の要件定義で押さえておくべき領域です。EDIは取引データという機微な情報を扱う以上、法令と非機能の要件は軽視できません。

EDIで扱う注文書・請求書などの取引データは、電子帳簿保存法やインボイス制度の対象になり得ます。RFPには、取引データを法令の要件に沿って保存・検索できること、適格請求書に必要な項目を満たせることを要件として明記します。これらを後付けすると、新規構築時に織り込む場合の2〜3倍のコストがかかると言われ、実際にサポート費を年100万円節約したものの、稼働半年後のインボイス改正対応で別会社に500万円を追加発注した事例もあります。法令対応は最初の要件に含めるのが最も安上がりです。

購買・調達のEDIでは、J-SOX（内部統制）への対応も要件になります。誰がデータを承認し、誰が送信したかの証跡をログに残す、承認権限と実行権限を分離する、といった統制要件を盛り込みます。これらは監査対応の前提であり、上場企業やその取引先では必須です。法令要件は業種・規模によって適用範囲が変わるため、自社に関係する法令を洗い出し、それぞれをEDIの要件にどう反映するかを整理することが、RFP作成の重要なステップです。

INSネット終了に伴うレガシーEDIからの移行では、移行要件をRFPに明記することが欠かせません。既存の取引先をどの順序で新EDIに移すか、移行期間中に旧EDIと新EDIをどう並行運用するか、データの移行範囲はどこまでか、を要件として定めます。取引先を巻き込む移行は一斉切り替えがリスクを伴うため、段階移行の計画を要件に含め、ベンダーに移行支援の体制を求めることが現実的です。

あわせて、稼働後の拡張に関する要件も忘れずに盛り込みます。取引先の追加、新しい通信手順への対応、マッピングの追加といった日常的な変更を、どの程度の費用と期間で行えるかをRFPで確認します。とくに追加開発の人月単価が後から1.5倍に跳ね上がる契約の罠があるため、単価テーブルを事前に取り決める要件を含めることが、長期コストを抑える鍵です。これらの要件を網羅したRFPを作るには、自社の取引実態と法令、将来計画を整理する必要があります。riplaはフルスクラッチ受託の立場から、企業間連携の責任分界を含むEDI要件の整理と、追加費用が膨らまない契約・要件設計を支援しています。

EDIは取引データという機微な情報を企業間でやり取りするため、セキュリティの非機能要件をRFPに明記することが欠かせません。通信経路の暗号化、アクセス権限の制御、データの改ざん検知、不正アクセスへの対策といった要件を定めます。とくにWeb-EDIでは取引先がインターネット経由でアクセスするため、認証の強度やログイン履歴の記録といった要件が重要になります。セキュリティを後付けすると大きな改修が必要になるため、最初の要件で押さえておくべき領域です。

あわせて、可用性と性能の要件も数値で定めます。受発注は止まると取引そのものが滞るため、システムの稼働率や障害時の復旧目標時間を要件として示します。月末の請求処理など取引が集中する時間帯に、想定件数を処理しきれる性能があるかも要件化します。たとえば「ピーク時に1時間あたり何件のデータを処理できること」といった具体的な数値を盛り込めば、ベンダーは必要な性能を見積もれます。非機能要件は目に見えにくい分、要件定義で明示しないと「動くが遅い」「止まると復旧に時間がかかる」システムになりがちです。数値で定義することが、安心して長く使えるEDIの条件になります。

まとめ

EDIシステムの要件定義・RFPでは、企業間連携の責任分界点、通信手順・データ変換の具体要件、基幹連携とトランザクション設計、そして電帳法・J-SOX・移行・追加単価といった法令／非機能要件を漏れなく押さえることが重要です。とくに「データがどこまで届けば責任を果たしたか」「片方だけ処理が進んだときの検知と復旧」「ベンダー間の責任境界」という、企業間システムならではの論点は、多くのRFPで抜け落ちがちでありながら、トラブル時に最も高くつく部分です。要件定義の段階でこれらを取引先と合意しておくことが、後の追加費用と企業間トラブルを防ぎます。

要件定義は、機能を並べるだけでは完結しません。自社の取引先構成・通信手順・データ形式・法令要件・将来計画という実態を棚卸しし、企業間の責任分界まで言語化することが、精度の高いRFPの条件です。riplaはフルスクラッチ受託とAI駆動開発を組み合わせ、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を創業。