EDI担当者が退職するときの運用・保守の引き継ぎ｜小規模組織で何を棚卸しし、社内か外部かをどう決めるか

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

B2B EC-COLUMN

EDI担当者が辞めると、運用・保守の何が止まり何が困るのか

EDI担当者から退職を切り出されたものの、受発注のデータ交換のどこまでがその人の頭の中にあるのか見当がつかない。
そんな状況でも、残り期間でできることはあります。
まず、EDIの仕事を日々の監視、障害対応、取引先ごとの仕様変更と調整、システムの維持管理に分けて書き出します。
次に、担当者しか分からず、止まると影響が大きい作業から引き継ぎます。
社内で持つか外部に頼むかは、作業ごとに決めてかまいません。
外部委託の範囲、取引先への連絡、担当者名義のIDの扱いは契約や取引先ごとに違うため、一つずつ確かめながら進めます。

日々の監視と障害対応

担当者が辞めたときに何が止まるかは、EDIの仕事を作業ごとに分けると見えてきます。
EDIの運用を請け負う事業者の一つは、EDI運用担当者の業務として、仕様変更の対応、得意先との対応や調整、日々のシステム監視、障害発生時の対応、システムの維持や管理を挙げています¹。
これは1社のサービス説明であり、どのEDIにも当てはまる定義ではありません。
それでも、自社の担当者が何をしているかを書き出す出発点としては十分に使えます。

このうち、止まったときに最も早く表に出るのが日々の監視です。
監視とは、専用の画面を見張ることに限りません。
朝に受信の記録を開いて取引先からの注文データが届いているかを見る、送ったはずの出荷データにエラーが返っていないかを見る、といった確認も含まれます。
担当者がいなくなってこの確認を誰もしなくなると、受信に失敗していても社内では気づけません。
取引先から「注文を送ったのに出荷されない」と問い合わせを受けて、初めて止まっていたことが分かる、という順番になります。

障害対応は、監視以上に担当者の頭の中に寄りやすい作業です。
受信に失敗したとき、再送を頼むのか、自社側でやり直すのか、システムの保守会社に電話するのか。
その判断と連絡先は、手順書ではなく担当者の経験に残っていることがあります。
たとえば担当者が、受信件数がいつもより少ない朝には取引先の窓口へ電話を一本入れて確かめていたとします。
この習慣がどこにも書かれていなければ、後任は件数の少なさを異常と思わないまま一日を終えてしまいます。

取引先ごとの仕様変更・調整

監視と障害対応が毎日の作業なのに対し、仕様変更は不定期にやってきます。
取引先が商品コードの桁数を変える、データの項目を追加する、送受信の時刻を変える、といった連絡が来ると、自社側でもデータの変換設定を直す必要があります。
さらに、取引先と試験的にやり取りして確かめる作業も発生します。

この作業が厄介なのは、担当者が辞めた直後には何も起きず、しばらくしてから止まる点です。
取引先からの変更連絡が退職した担当者のメールアドレスに届き、誰にも読まれないまま切り替え日を迎える、ということも起こりえます。
切り替え日以降は取引先から届くデータが自社の設定と合わなくなり、受信はできても取り込みでエラーになります。

得意先との対応や調整も、同じように人に付いています。
取引先側の誰に聞けば仕様の詳細が分かるか、試験の日程をどう組んできたか、過去にどんな取り決めをしたか。
こうした関係は、システムの設定画面を見ても分かりません。

システムの維持管理

自社でEDIの通信ソフトやサーバーを持っている場合は、その維持管理も担当者の仕事に入っています。
具体的には、ソフトの更新、バックアップ、保守会社との契約や問い合わせ窓口、利用料の支払い名義などです。

ここで見落としやすいのが、期限のあるものです。
接続方式によっては、通信に使う証明書やパスワードに有効期限があり、期限前に更新の手続きが要ることがあります。
年に一度しか発生しない作業は、担当者本人も手順をよく覚えていないことがあります。
退職後に期限切れで初めて気づけば、その日から送受信が止まります。
自社のEDIで何に期限があり、誰の名義で申請しているかは、棚卸しで確かめる項目に入れておきます。

EDIの種類で自社の担当範囲はどう変わるか

ここまでの作業が、すべて自社に乗っているとは限りません。
自社がどこまでを持っているかは、EDIの種類と、すでに外部に頼んでいる範囲で変わります。

• 取引先と個別に取り決めて接続している場合：データの形式や通信方法が取引先ごとに違い、変換設定や通信ソフトの維持管理を自社で持っていることがあります。
  仕様変更の対応も取引先ごとに発生します。
• 業界などで決めた標準の形式を使っている場合：形式はそろっていても、取引先ごとの設定や接続先の管理は残ります。
• Web-EDI（取引先が用意したWeb画面にログインして注文を確認・取得する形）の場合：システムの維持管理は主に画面を提供する側が持ちますが、ログインIDの管理、毎日の確認、取得したデータの社内システムへの取り込みは自社に残ります。

複数の取引先が別々の方式を使っていると、担当者は方式ごとに違う手順を覚えています。
通信やシステムの保守をすでに外部に頼んでいる場合は、その委託先との窓口が担当者一人になっていないかも確かめる必要があります。
自社の担当範囲は、取引先の一覧と接続方式を並べて初めて分かります。
そのため、棚卸しは取引先単位で始めるのが近道です。

▼ 図の内容を文字で読む

1. 変更連絡が退職した担当者のメールアドレスに届く
2. 誰にも読まれないまま切り替え日を迎える
3. 取引先のデータが自社の設定と合わなくなる
4. 受信はできても取り込みでエラーになる

退職までに何を棚卸しし、どの情報を先に引き継ぐか

作業の棚卸し表の作り方

前の節の作業を、自社の取引先ごとに書き出していきます。
行は「A社の注文データの受信確認」「B社の仕様変更対応」のように、取引先と作業の組み合わせにします。
作業の種類だけで書くと、取引先ごとに違う手順や連絡先が一行にまとまってしまい、後任が読んでも使えません。

列には作業の中身に加えて、引き継ぎの順番を決めるための4つの見方を置きます。

• 頻度：毎日、毎週、月次、年次、不定期のどれか
• 止まったときの影響：どの受発注が止まり、社内外の誰が困るか
• 担当者以外が分かるか：手順を知っている人がいるか、書かれた手順があるか
• 取引先側の依頼や手順が必要か：再送の依頼や試験の調整など、自社だけでは完結しない作業か

このほか、作業で使う画面やファイルの場所、使うID、連絡先も同じ行に書いておくと、後でIDを付け替える作業がそのまま進められます。
書き出しは、担当者に一から思い出してもらうより、手元の記録をたどる方が漏れが減ります。
担当者の送受信メール、カレンダーの予定、通信ソフトの実行記録、保守会社への問い合わせ履歴などを一緒に見ながら、何をしていたかを拾います。
年に一度の更新のように、記録をたどらないと本人も思い出せない作業をここで拾えるかどうかが、後の分かれ目になります。

担当者しか分からないものの見分け方

4つの見方のうち、判定に迷いやすいのが「担当者以外が分かるか」です。
担当者に聞けば「手順書はあります」と返ってくることもあります。
しかし、その手順書で別の人が実際に作業できるかは別の話です。

確実に見分けるには、担当者が不在の日を想定して、別の人がその作業をやってみることです。
担当者は横で見ているだけにして、手順書とメモだけで進められるかを試します。
途中で担当者が「ここはいつも感覚で」「この場合は先方に電話して」と口をはさんだ箇所が、まだ担当者の頭の中にある部分です。

試す前でも、次のような作業は担当者しか分からない可能性が高いと見当を付けられます。

• 手順が担当者のPCやメール、個人のメモにしかない
• 取引先とのやり取りが担当者個人のアドレスで行われている
• 使うIDやパスワードが担当者の名義になっている、または担当者だけが管理している
• 頻度が低く、前回いつ誰がやったかの記録がない

退職日までに先に引き継ぐもの

棚卸し表ができたら、止まったときの影響と、担当者以外が分かるかの2つで作業を分けます。
影響が大きく担当者しか分からない作業が、退職日までに最初に引き継ぐものです。
影響が大きくても他の人が分かる作業は、手順書と照らして抜けを埋めれば足ります。
影響が小さく担当者しか分からない作業は、メモを残してもらえば退職後に整えても間に合います。

もう一つ、頻度の低い作業の扱いに気を付けます。
毎日の確認なら、後任が数日横で見れば覚えられます。
一方、年次の更新や不定期の仕様変更は、担当者の在職中に一度も発生しないまま退職日を迎えることがあります。
その場合は実際の作業を見せてもらえないので、前回の記録、手順、申請先、期限の日付を書き残してもらうことを優先します。

この順番は、引き継ぎに使える時間が限られている前提での一つの考え方です。
担当者の残り期間が長ければ、影響の小さい作業まで実地で引き継げます。
取引先が多ければ、影響の大きい取引先から順に進めることになります。
取引先側の依頼や手順が必要な作業は取引先の都合で日程が決まるため、早めに着手しておくと退職日に間に合わせやすくなります。

▼ 図の内容を文字で読む

1. 影響が大きく、担当者しか分からない
2. 退職日までに最初に引き継ぐ
3. 影響が大きいが、他の人も分かる
4. 手順書と照らして抜けを埋める
5. 影響が小さく、担当者しか分からない

手順書化や複数人体制など、社内で備える場合どこまでできるか

手順書化の範囲

引き継ぎの順番が決まったら、それを後任一人だけでなく組織に残す方法を考えます。
まずは手順書です。
ただ、EDI全体を網羅した手順書を退職日までに作ろうとすると、肝心の優先作業の引き継ぎが後回しになります。

手順書は、棚卸し表で影響が大きいとした作業から書き始めます。
毎日の受信・送信の確認方法、エラーが出たときの最初の対応、取引先と保守会社の連絡先一覧、過去の仕様変更の履歴、の順に書くと、後任が困る場面から順に埋まります。
画面の操作は、画面の写しを貼ると短く済みます。

書きにくいのは判断の部分です。
「いつもより件数が少ない」と気づくには、いつもの件数を知っている必要があります。
取引先ごとの通常の受信件数の目安、注文の締め時刻、送信が遅れたら取引先に連絡するまでの猶予など、担当者が無意識に使っている基準を数字や時刻で書いてもらうと、判断が手順に変わります。
手順書は取引先の仕様が変わるたびに直さないと実態とずれていくため、誰が更新するかも決めておきます。

第二担当者の置き方

手順書があっても、それを読んで動ける人がいなければ使われません。
第二担当者は、主担当と同じだけEDIを知っている必要はありません。
日々の確認と、障害時の最初の連絡までを一人でできれば役割を果たせます。

誰を置くかは、EDIが止まったことにいち早く気づける位置にいる人が向いています。
たとえば受注処理をしている人なら、注文データが届かない日は自分の仕事が始まらないので、確認を日々の業務の中に組み込めます。
主担当と第二担当で日ごとに確認を交代すると、第二担当者が手順を忘れずに済みます。
取引先にも第二担当者を窓口として伝えておけば、主担当が不在の日にも連絡が届きます。

人員が少ない場合の限界

小規模企業者は、法律上の定義では常時使用する従業員の数で区切られています。
商業やサービス業（宿泊業・娯楽業を除く）では5人以下、工業や運送業などでは20人以下です²。
この基準は企業の規模を示すもので、EDIの運用に何人必要かを示すものではありません。

それでも、人数が少ないほど、EDIの第二担当者に時間を割ける人を確保しにくくなるとは考えられます。
少人数で受注・出荷・経理を分け合っている会社では、EDIを分かる人を二人保つこと自体が、誰かの仕事の一部を占めます。
どれだけ割けるかは会社ごとに違うので、規模だけを見て社内体制は無理だと決める必要はありません。

社内で持ちにくいのは、不定期で技術的な作業です。
日々の確認は手順に落とせても、取引先の仕様変更に合わせた変換設定の修正や試験は、発生する回数が多くない一方で、来たときには専門的な作業が要ります。
社内の人数でこの作業を誰が担うのかが決まらないとき、外部委託が選択肢に上がります。

運用・保守を外部委託する場合、何を任せられ何が自社に残るか

任せられる作業の例

EDIの運用・保守を外部に任せるとき、どこまで任せられるかは事業者と契約ごとに違います。
一つの例として、EDIの運用を請け負うあるサービスは、提供範囲に、規約や仕様の変更への対応、得意先との対応や調整、24時間365日の監視、障害発生時の対応、ハードウェアとソフトウェアの保守、定期的なSLA報告会を挙げています¹。
SLAとは、委託先が守るサービスの水準を取り決めたものです。

この例から、社内に残しにくいとした仕様変更の対応も、日々の監視も、委託の対象になりうることが分かります。
ただしこれは1社の公開ページの説明で、どの事業者でも同じ範囲を請け負うわけではありません。
料金や契約の条件もこのページからは分からないため、相場の目安にはなりません。
委託先を比べるときは、価格より先に、自社の棚卸し表のどの行が委託範囲に入るかを照らし合わせる方が、抜けを見つけやすくなります。

契約前に確認する項目

委託を検討するときに確かめたいのは、棚卸し表の各行が委託後に誰の担当になるかです。
委託範囲の説明は「監視」「仕様変更対応」のように作業の種類で書かれていることがあり、自社の取引先ごと・方式ごとの作業にそのまま当てはまるかは、説明だけでは判断しにくいためです。

• 自社の取引先と接続方式のすべてが対象に入るか。
  Web-EDIの画面確認のように、対象かどうかが分かりにくい作業はないか
• 仕様変更の対応がどこまでか。
  取引先との日程調整や試験まで含むのか、設定の修正だけか
• 障害時に誰から誰へ、どの時間帯に連絡が来るか。
  自社が判断を求められるのはどんな場面か
• 委託開始時に、自社が渡す情報と権限は何か
• 定期報告に何が含まれ、自社の誰が受け取るか
• 契約を終えるときに、設定や手順、記録がどう返されるか

最後の項目は、委託を始める時点では後回しにしやすいものです。
しかし、担当者の頭の中を委託先へ移したあとで、今度は委託先にしか分からない状態になれば、属人化の相手が変わっただけになります。

委託を始めるには、委託先に現状を伝える作業そのものも必要です。
担当者が在職しているうちに、棚卸し表と手順書をもとに委託先へ説明してもらえるかどうかで、立ち上がりの手間が変わります。
退職日までの残り期間が短い場合は、委託の契約より先に、この説明に使える時間を確保できるかを見ておきます。

自社に残る判断・権限

先の例のページには、委託した側の会社に何の役割が残るかは書かれておらず、契約条件も載っていません。
ここから先は、契約ごとに確かめる前提での整理です。
委託しても自社に残しておくべきと考えられるのは、次のような判断と権限です。

• 取引条件の判断：取引先から新しい形式や締め時刻の変更を求められたとき、受けるかどうかを決めるのは取引の当事者である自社です
• アクセス権限の管理：委託先に渡すIDや権限の範囲と、委託終了時の回収
• 委託先の監督：報告を読み、委託範囲どおりに動いているかを確かめる人
• 受発注の内容の確認：届いた注文が業務上正しいかは、データの送受信とは別に自社が見ます

つまり、外部に任せてもEDIを分かる人がゼロでよいわけではありません。
担当者一人が持っていた仕事のうち、技術的な作業は外へ、取引と権限の判断は社内へ、と分かれるイメージです。
社内に残る人は、通信の設定を直せなくてもかまいません。
ただ、報告を読み、委託先と取引先の間で何が起きているかを把握できる程度の理解は必要です。

▼ 図の内容を文字で読む

1. 委託の対象になりうる作業（1社の説明の例）
2. 規約や仕様の変更への対応
3. 得意先との対応や調整
4. 監視と障害発生時の対応
5. 自社に残ると考えられる判断と権限

社内で持つか外部に頼むか、自社の状況でどう選ぶか

4つの選択肢の比較

ここまでの話を、作業ごとに当てる選択肢として並べ直します。
選択肢は、後任一人への社内引き継ぎ、手順書化と複数人化、運用・保守の外部委託、仕組みの見直しの4つです。
仕組みの見直しとは、取引先ごとにばらばらの接続方式を整理する、使っていない接続をやめる、といった方法で、担当者に依存する作業そのものを減らす選択です。

表のうち判断が分かれるのは、主なリスクの列です。
社内引き継ぎは最も手早い一方、後任がまた一人で抱えれば、次の退職で同じ状況に戻ります。
外部委託は技術的な作業を外へ出せますが、委託範囲の外にある作業が誰の担当でもなくなる危険があります。
それを防ぐのが、前の節で述べた棚卸し表と委託範囲の照合です。
仕組みの見直しは根本的な対策ですが、取引先との調整が要るため、退職日までの短い期間で済ませるものではありません。

併用の考え方

4つの選択肢は一つだけを選ぶものではなく、棚卸し表の行ごとに当てはめてかまいません。
たとえば、次のように割り振ることができます。

• 毎日の受信確認：手順書にして、受注担当と交代で確認する
• 障害時の復旧と仕様変更の対応：外部委託に出す
• 取引先との条件の取り決め：社内の責任者が持つ
• 取引先ごとにばらばらな接続方式：退職後に時間をかけて見直す

このように分けると、社内の人に求める知識の量が減り、外部に出す範囲もはっきりします。
反対に、すべてを外部委託にまとめようとすると、取引条件の判断まで委託先任せになりかねません。
すべてを社内に残そうとすると、人数の少ない組織では負担が一人に戻ります。

仕組みの見直しは、退職前後の混乱が落ち着いてから取りかかる方が無理がありません。
担当者の引き継ぎと接続方式の変更を同時に進めると、旧方式と新方式の両方を理解している人が誰もいない期間ができてしまうためです。

状況別の判断条件

どの割り振りが合うかは、担当者の残り期間、社内の人員、EDIの種類、取引先との関係で変わります。
いくつかの状況を想定して、判断の分かれ方を見てみます。

担当者の残り期間が短く、後任の候補もいない場合は、引き継げる量に限りがあります。
棚卸し表の作成と、影響が大きく担当者しか分からない作業の引き継ぎに時間を集中し、退職後の一次対応を誰がするかを先に決めます。
外部委託を考える場合も、契約の検討と並行して、担当者から委託先へ現状を説明してもらう時間を確保できるかが鍵になります。

取引先の大半がWeb-EDIで、自社でサーバーや通信ソフトを持っていない場合は、自社の作業が毎日の確認、データの取り込み、IDの管理に寄ります。
手順に落としやすい作業が中心なので、手順書化と複数人化で対応できる余地が大きくなります。

自社で通信ソフトやサーバーを持ち、取引先ごとに個別の接続をしている場合は、仕様変更や障害の対応に技術的な作業が残ります。
社内に技術の分かる人を二人保てないなら、その部分は外部委託の検討対象になります。

取引先との関係も判断材料に入ります。
主要な取引先の担当者と長く付き合いがあり、調整を顔の見える関係で進めてきた場合は、その窓口を委託先へ移すことを取引先がどう受け止めるかを確かめておきたいところです。
取引先とのやり取りは社内に残し、技術的な作業だけを外部に出す、という分け方もできます。

退職後の空白期間と取引先への連絡で先に決めておくこと

退職後の一次対応者

どの選択肢を選んでも、退職日の翌日から体制が完成しているとは限りません。
後任が育つまで、あるいは委託先が立ち上がるまでの間にも、注文データは毎日届きます。
この空白期間に誰が毎日の確認をし、異常があったときに最初に誰が動くかを、退職日より前に決めておきます。

一次対応者は、復旧まで自分でできなくてもかまいません。
受信の有無を確かめ、異常に気づいたら保守会社、委託先、取引先のどこへ連絡するかが分かっていれば、止まっている時間を短くできます。
そのためには、連絡先の一覧と、異常と判断する目安が一次対応者の手元にある必要があり、ここで先に作った手順書が使われます。

退職後の担当者に問い合わせてよいかどうかは本人との取り決め次第で、当てにできるとは限りません。
退職日までに、一次対応者が異常時の連絡を一度練習しておくと、空白期間に迷う場面が減ります。

取引先への窓口変更の連絡

取引先に担当者の変更を伝える必要があるか、どんな手続きが要るかは、取引先との契約や接続の取り決めによって違います。
決まった届け出の様式を求める取引先もあれば、メールの連絡で足りる取引先もありえるので、取引先ごとに確かめます。

手続きの要否とは別に、実務では連絡先の切り替えが問題になります。
取引先からの仕様変更の案内や障害の連絡が退職した担当者個人のメールアドレスに届き続けると、先に見たように誰にも読まれないまま期限を迎えます。
担当者個人ではなく部署の共有アドレスを窓口にする、退職後もしばらくは担当者のアドレスに届いたメールを後任へ回す、といった手当てを考えておきます。

連絡の時期は、担当者が在職しているうちに、後任や委託先と並べて伝えられるのが理想です。
担当者本人から紹介されれば、取引先も新しい窓口に連絡しやすくなり、進行中の仕様変更があればその場で引き継げます。
外部委託に切り替える場合は、取引先とのやり取りのうち何を委託先が受けるのかも合わせて伝えます。

担当者名義のアカウントと認証情報の付け替え

最後に、担当者の名義になっているIDや認証情報を整理します。
棚卸し表に書いたIDを一覧にすると、Web-EDIのログインID、通信ソフトや社内サーバーの管理者ID、保守会社や委託先の問い合わせ窓口の登録、証明書を使う方式なら申請者の名義など、思ったより多くの箇所に担当者の名前が残っていることがあります。

それぞれについて、誰に付け替えるかと、担当者のIDをいつ無効にするかを決めます。
このとき順番に注意が要ります。
付け替えより先に担当者のIDを止めると、その日から送受信や画面の確認ができなくなります。
反対に無効化を後回しにすると、退職した人のIDで社外から入れる状態が続きます。
付け替えた先のIDで実際に確認作業ができることを確かめてから担当者のIDを止める、という順に進めると、この両方を避けやすくなります。

名義の変更にどんな手続きが要るかは、取引先が提供するWeb-EDIの規約、利用しているEDIサービス、証明書の発行元ごとに異なります。
担当者個人の名義のままでは付け替えができず、新たな申請が必要になる場合もあります。
期限のある証明書などは、退職日から逆算して早めに手続きの流れを確かめておきます。
パスワードを担当者だけが知っている場合も、退職前に組織として管理する場所へ移しておきます。

▼ 図の内容を文字で読む

1. 担当者名義のIDを一覧にし、誰に付け替えるかを決める
2. 付け替えより先に止めると、その日から送受信や画面の確認ができなくなる
3. 付け替えた先のIDで実際に確認作業ができるかを確かめる
4. 担当者のIDを無効にする
5. 後回しにすると、退職した人のIDで社外から入れる状態が続く

棚卸し表で作業を分けても、どの行を外部に任せられるか、自社の接続方式で何が技術的に残るかは、社内だけでは判断しにくいことがあります。

相談では、書き出した作業のうちどれを外に出せそうか、契約前に何を決めておくべきかを、自社の取引先と接続方式に沿って確かめられます。無料相談で要件を整理する

選択肢ごとに、退職日までと退職後にやること

4つの選択肢それぞれについて、退職日までに済ませることと退職後に続けることを分けて並べた。

• 社内引き継ぎ：退職日までに、後任が影響の大きい作業を担当者の前で一度実行する／退職後は、後任が一人で抱えないよう手順を残し続ける

• 手順書化と複数人化：退職日までに、優先作業の手順と判断の目安を書く／退職後は、仕様変更のたびに手順書を直し、確認を交代で続ける

• 運用・保守の外部委託：退職日までに、担当者から委託先へ現状を説明する時間を取る／退職後は、報告を読み、権限の管理と取引条件の判断を社内で持つ

• 仕組みの見直し：退職日までは手を付けず、接続方式の一覧を残す／退職後に、取引先と調整しながら担当者に依存する作業を減らす

退職日を境に、担当者に聞きながら進める作業から、自社か委託先が自分たちで回す作業へ切り替わります。

要点の整理

棚卸しの単位	監視、障害対応、仕様変更と調整、維持管理を、取引先ごとの行に分けて書く
先に引き継ぐもの	止まったときの影響が大きく、担当者しか分からない作業
見落としやすいもの	頻度が低く期限のある作業、担当者名義のIDや証明書
社内か外部か	作業ごとに選ぶ。外部委託では委託範囲と自社に残る役割を契約で確かめる
退職日前に決めること	退職後の一次対応者、取引先への窓口変更、IDの付け替えと無効化の順番

退職日が決まると、空白期間の一次対応、取引先への連絡、担当者名義のIDの付け替えを短い期間で決める必要があります。 相談では、退職後に誰が何を担うかの割り振りと、付け替えや連絡をどの順番で進めるかを整理できます。

よくある質問

EDI担当者が退職を申し出たら、最初の1週間で何をすればよいですか。

まず棚卸し表に着手し、取引先ごとの作業と、使っているIDや連絡先の一覧を担当者と一緒に書き出します。
そのうえで、止まると影響が大きく担当者しか分からない作業を見つけ、引き継ぎの日程に入れます。
退職後に誰が毎日の確認と一次対応をするかも、仮でよいので早めに決めておくと、その後の判断がしやすくなります。

Web-EDIでも担当者の退職で困ることはありますか。

あります。
Web-EDIではシステムの維持管理は主に画面を提供する側が持ちますが、ログインIDの管理、毎日の注文の確認、取得したデータの社内システムへの取り込みは自社に残ります。
取引先ごとに画面や手順が違えば、それを覚えているのが担当者だけということもあるため、棚卸しの対象に入れます。

取引先に担当者変更をいつ、どう伝えればよいですか。

届け出の要否や様式は取引先との契約や接続の取り決めで違うため、取引先ごとに確かめます。
伝える時期は、担当者が在職しているうちに後任や委託先と並べて紹介できるのが理想です。
あわせて、担当者個人のアドレスではなく部署の共有アドレスを窓口にしておくと、仕様変更の案内が読まれないまま期限を迎える事態を防ぎやすくなります。

EDIの運用・保守を外部に委託しても、自社に残る業務は何ですか。

委託先の公開説明には委託元に残る役割が書かれていないことがあるため、契約で確かめる必要があります。
そのうえで自社に残しておくべきと考えられるのは、取引条件の判断、委託先に渡すIDや権限の管理、報告を読んで委託先を監督すること、届いた注文の内容の確認です。

担当者名義のIDや証明書は、退職時にどう扱えばよいですか。

担当者の名義が残っている箇所を一覧にし、それぞれの付け替え先と無効化の時期を決めます。
付け替え先のIDで作業できることを確かめてから担当者のIDを止める順にすると、送受信が止まる事態と、退職者のIDが使える状態が続く事態の両方を避けやすくなります。
名義変更の手続きはサービスの規約や証明書の発行元ごとに違うため、期限のあるものから早めに確かめます。

1. 1　出典：フューチャーアーティザン株式会社（MARKLINES掲載ページ）「EDI BPOサービス「EDI Express」」（2026）
2. 2　出典：独立行政法人中小企業基盤整備機構「中小企業・小規模企業者の定義」（2026）