◆監修・編集責任者
B2B EC-COLUMN
この記事のポイント
- 退職が決まったら、受発注の流れを取引先・データ・締め時間・障害時の4欄で書き出し、空欄のある行から聞き取る。
- INSネットを使うEDIは、NTT東日本の案内では2028年12月31日に回線のサービスが終わるため、退職とは別の期限として一覧に書く。
- 例外対応と障害時の判断は本人の操作に立ち会って受け取り、後任候補が手順書だけで再現できるかで引き継ぎを確かめる。
- 見直しは取引先の状況に左右されるため、退職までは社内引き継ぎか委託で運用を続け、見直しは退職後の中期課題とする。
- 委託しても、判断者・取引先の窓口・認証情報の保管は自社に残す。
目次

退職が決まったら最初に洗い出す受発注の流れ:取引先・データ・締め時間・障害時の4欄
EDIを長年一人で回してきた担当者の退職が決まった。
取引先ごとの例外や障害時の判断は、その人の頭の中にしかない。
そんな状況でも、退職日までに変えられることはあります。
まず、止まると困る受発注の流れを、取引先・データ・締め時間・障害時対応の4欄で書き出します。
次に、手順書に残せるものと、在職中に本人の操作を見て再現しておくものを分けます。
そのうえで、残り期間と後任の有無から社内引き継ぎか保守の外部委託を選びます。
取引先との調整が要るEDIの見直しは、退職後の課題として切り分けるのが現実的です。
退職日から逆算して優先順位を付ける
退職までの期間が限られているとき、すべての処理を同じ深さで引き継ごうとすると、日常の作業を追いかけるうちに退職日が来てしまいます。
そこで最初に決めたいのは、どの受発注の流れから聞くかという順番です。
目安になるのは、その流れが止まったときに、どれだけ早く出荷や請求に響くかです。
毎日届く発注データの取り込みが止まれば、その日のうちに出荷の準備が遅れます。
一方、月に一度の請求データの送信は、止まってもすぐには気づかれないかもしれません。
ただし、頻度の低い処理ほど、退職までに実物を見られる回数は少なくなります。
その一回を逃すと、手順を確かめる機会がなくなります。
順番は影響の大きさで付けます。
そのうえで、月次や年次の処理は次に回ってくる日を先に調べ、立ち会う日程を押さえておきます。
そうすれば、優先順位が低いことが見落としにつながりにくくなります。
退職日から逆算するというのは、聞く順番を決めるだけでなく、実地で確かめる日を暦の上に置くことでもあります。
締め日や繁忙期と重なる日は本人も手が離せないため、聞き取りはその前後に入れるほうが進めやすくなります。
4欄の一覧の作り方
一覧の1行は、取引先とデータの組み合わせで、1つの受発注の流れとして作ります。
同じ取引先でも、発注データの受信と出荷データの送信では、締め時間も障害時の動き方も違います。
行を分けておくと、後で使いやすくなります。
欄は次の4つです。
・取引先:相手先の名前と、EDIで使っている取引先のコードや識別名
・データ:発注、出荷、請求など何のデータか、自社が受け取るのか送るのか
・締め時間:取引先側の締めと、自社がデータを取り込む、または送り出す時刻
・障害時:取引先の連絡先と、自社で再送や手作業への切り替えを決める人
障害時の欄に連絡先と判断者を分けて書くのは、電話をかける人と、再送してよいかを決める人が同じとは限らないからです。
これまで担当者がその両方を一人で担っていたなら、退職後はどちらの役割も空く可能性があります。
書き出してみると、空欄がいくつも出るかもしれません。
その空欄こそ、担当者の頭の中にだけある情報の場所です。
空欄を埋めること自体を目標にするより、空欄のある行を次の聞き取りの対象にするほうが、作業の意味がはっきりします。
なお、4欄は聞き取りの順番を付けるための作業枠で、これだけで項目が足りるという基準ではありません。
取引先の数や接続の仕方に応じて、欄を足して構いません。
ヒアリングを一覧に沿って進める
担当者に「知っていることを全部書いてほしい」と頼むと、本人にとって当たり前のことほど抜けます。
一覧の行を一つずつ指して、その行について問いを投げるほうが、抜けている箇所が見えやすくなります。
たとえば、次のような聞き方です。
・この取引先のデータが締め時間までに届かなかったら、最初に何を見ますか
・届いたデータの中身がおかしいとき、取引先に連絡しますか、それとも自社で直しますか
・この行の処理で、手順書に書いていない作業はありますか
・この取引先から、EDIの外で電話やメールで連絡が来ることはありますか
最後の問いは見落とされやすい部分です。
EDIの画面や処理だけを見ていると、取引先から電話で受けた修正を手で反映しているような作業は、一覧に現れません。
答えが出たら、4欄の横に例外としてメモを残し、本人の操作に立ち会って引き継ぐ対象に回します。
聞き取りの途中で判断者の欄に誰も入らない行が見つかったら、その行は管理者が退職前に担当を決める対象になります。
| 取引先 | データ | 締め時間 | 障害時 |
|---|---|---|---|
| 取引先A(例) | 発注データを受信 | 取引先の締め後に自社で取込 | 連絡先:取引先Aの窓口/判断者:自社の受注責任者 |
| 取引先A(例) | 出荷データを送信 | 出荷確定後、取引先の締め前に送信 | 連絡先:取引先Aの窓口/判断者:空欄 |
| 取引先B(例) | 請求データを送信 | 月次の締め後に送信 | 連絡先:空欄/判断者:空欄 |
EDIの種類と回線で変わる『退職後に止まるもの』と期限
固定回線(INSネット)利用の場合の確認点
前の一覧に、もう一つ欄を足します。
その流れがどの接続方式と回線で動いているかです。
退職への備えとは別の話に見えますが、回線そのものに期限があれば、引き継いだ運用がそのまま続くとは限りません。
そのため、同じ一覧で見ておく必要があります。
固定回線のうち、ISDN回線であるNTT東日本のINSネットについては、INSネット64、INSネット64・ライト、INSネット1500の3サービスが2028年12月31日にサービス提供を終了すると案内されています1。
新規販売は2024年8月31日に終了しました1。
また、データ通信に使われるディジタル通信モードは、2024年1月から地域ごとに段階的に終了しています1。
この案内はNTT東日本のものです。
NTT西日本のエリアや他社の回線を使っている場合は、自社の契約と利用エリアに照らして条件を確かめる必要があります。
担当者の退職と結び付けて確かめたいのは、次の点です。
・その回線を、EDIの送受信に実際に使っているか(契約上の名称と現在の設定の両方から確かめる)
・どの通信モードで送受信しているか
・回線の契約名義と、機器や設定を誰が用意したか
・取引先側も同じ回線方式に依存しているか
回線の設定を組んだのが退職する担当者本人なら、現在の構成を説明できる人がいなくなる前に聞いておく価値があります。
回線の切り替えを検討するときも、いまの構成が分かっていることが出発点になるからです。
回線を変える話は、取引先との接続方法を変える話につながりやすく、後で扱うEDIの見直しの判断にも関わります。
インターネット系・Web-EDIの場合の確認点
インターネットを使うEDIでは、回線の期限とは別に、人に結び付いた設定が退職後の停止につながらないかを見ます。
Web-EDIは、取引先が用意したWeb画面に自社がログインして、受発注データを確認・入力する形です。
取引先ごとに画面と操作が違う場合、その数だけ手順とログイン情報があることになります。
確かめたいのは次の点です。
・ログインのアカウントが担当者個人の名義になっていないか
・パスワードや電子証明書の保管場所と、証明書の有効期限
・エラーや受信の通知が、担当者個人のメールアドレスに届く設定になっていないか
・送受信を自動で行うソフトや設定が、担当者の端末だけに入っていないか
特に注意したいのが通知の宛先です。
退職手続きで個人のメールアカウントが止められた時点で、通知は誰にも届かなくなります。
障害が起きていても気づく人がいなければ、発見が遅れた分だけ影響が広がります。
通知を共有のアドレスへ切り替える作業は退職日より前に終え、切り替え後に通知が届くことを一度確かめておきます。
証明書の有効期限は、退職後しばらくしてから更新の時期が来ることもあります。
更新の手順を知る人がいないまま期限を迎えないよう、期限の日付を一覧に書き、更新を担う人を決めておきます。
この管理者の決め方は、退職後の体制とあわせて最後の節で扱います。
▼ 図の内容を文字で読む
- 影響の大きさで順番を付ける:止まったときに出荷や請求へ早く響く流れから聞く
- 次に回ってくる日を調べる:月次や年次の処理は次の実施日を先に確かめる
- 立ち会う日程を押さえる:退職までに実物を見られる回数が少ない処理を優先する
- 締め日や繁忙期の前後に入れる:本人の手が離せない日を避けて聞き取りを置く
手順書に残せる情報と、在職中に実地で引き継ぐ情報の切り分け
文書化に向く情報
ここまでの一覧で、何がどこで動いているかの見取り図ができました。
次は、その一つ一つを、手順書として残すものと、本人の操作を見て受け取るものに分けます。
文書化に向くのは、誰がやっても同じ手順になる情報です。
・毎日・毎月の定期作業の手順と、実行するタイミング
・取引先と社内の連絡先
・サーバー、ソフト、回線などの構成と、それぞれの契約先
・画面操作の手順
・データの変換ルールや設定ファイルが置かれている場所
これらは書き方さえ揃えれば、本人がいなくても読み手が追えます。
画面の写しを添え、操作の前後で何が変わるかを書いておくと、読み手が途中で迷ったときに、自分がどこまで進んだかを確かめられます。
変換ルールそのものを書き写す必要はなく、どこにあり、変更したときに何に影響するかが分かれば足りる場合もあります。
実地で引き継ぐ情報
一方で、手順書だけでは足りない情報があります。
聞き取りで例外とメモした取引先ごとの個別対応と、障害時の判断です。
たとえば、ある取引先のデータが届かなかったとき、担当者は経験から「この取引先は締め前に一度だけ再送してくる」と知っていて、慌てずに待つかもしれません。
別の取引先なら、すぐに電話をかけるかもしれません。
この違いは、手順書に「届かない場合は確認する」と書いただけでは伝わりません。
再送してよいかどうかの判断も同じです。
同じデータを二度取り込めば二重の受注になるおそれがあり、取り込まなければ出荷が遅れます。
担当者はどちらを避けるべきかを、取引先や時間帯から判断しているはずです。
しかし本人にとっては当たり前のことなので、言葉にされていないかもしれません。
こうした情報は、本人が実際に操作する場面に立ち会い、その場で「なぜいまそうしたのか」を聞くことで初めて取り出せます。
本人の在職中にしかできない作業なので、文書化できる部分より先に日程を確保しておきたいところです。
手順書の清書は退職後でも進められますが、判断の理由を聞ける相手は退職日までしかいません。
後任候補に再現してもらう確かめ方
文書化したものと実地で受け取ったものが本当に引き継げたかは、後任候補が自分の手で再現できるかどうかで確かめられます。
手順書を書いた本人が読み返しても、抜けには気づきにくいからです。
進め方の一例です。
1. 本人が普段どおりに操作し、後任候補は横で見て理由を聞く
2. 後任候補が本人の前で同じ操作をする
3. 別の日に、後任候補が手順書だけを見て一人で操作する
4. 詰まった箇所と、本人に聞いて解決したことを手順書に書き足す
5. 書き足した手順書で、後任候補がもう一度操作する
3つ目の段階で詰まった箇所が、手順書に残っていなかった情報です。
詰まりがなくなるまで繰り返すと、手順書は「書いた人が読める文書」から「読む人が使える文書」に変わっていきます。
後任がいない場合は、代わりに対応する社内の人か、委託を検討している先の担当者に、この再現を担ってもらうことになります。
誰が再現できたかを一覧の行ごとに記録しておくと、退職日の時点で、どの流れが引き継げていて、どの流れが本人頼みのまま残っているかが分かります。
その残り方が、次に考える選択肢の材料になります。
▼ 図の内容を文字で読む
- 2024年1月から:ディジタル通信モードが地域ごとに段階的に終了
- 2024年8月31日:INSネット64・64ライト・1500の新規販売終了
- 2028年12月31日:INSネット64・64ライト・1500のサービス提供終了
残り期間と後任の有無で選ぶ:社内引き継ぎ・外部委託・EDIの見直し
3案を同じ軸で比べる
再現の結果を見ると、残り期間のうちに社内で引き継ぎきれるかどうかの見通しが立ちます。
ここで選ぶのは、社内引き継ぎ、保守の外部委託、EDIの見直しの3つです。
見直しには、標準的な方式への移行や、接続方式・回線の変更を含めて考えます。
表の中で判断が分かれやすいのは、後任はいるが兼務で手が回らない場合です。
知識は社内に残したいが、日常の監視や定期作業まで任せきれない。
それなら、判断と取引先対応は社内に置き、決まった作業を委託する組み合わせも考えられます。
3案はどれか一つを選ぶものではなく、受発注の流れごとに違う案を当てることもできます。
ここで4欄の一覧が役に立ちます。
止まったときの影響が大きく例外の多い流れは社内で持ち、手順が決まっている流れは委託に回す、という分け方を行単位で考えられます。
見直しに取引先調整が要る理由
担当者の退職を機に、個別仕様のEDIをやめて方式を整理したいと考えることもあるでしょう。
ただ、中小企業庁のミラサポplusは、EDIは1社だけが導入しても効果を得られず、取引先企業の状況や環境を考慮して導入の要否を判断する必要があると説明しています2。
この説明はEDIの導入判断についてのものですが、見直しにも同じ構造が当てはまります。
自社側で方式や接続を変えれば、取引先側の設定や受け取り方にも変更が及びます。
相手が変更に応じるか、いつ応じられるかは、自社だけでは決められません。
費用の面では、受注側の企業が中小企業共通EDI標準に対応したプロバイダーや業務アプリケーションを使う場合は、大きな費用はかからないとされています2。
中小企業共通EDI標準は、取引先ごとの個別仕様ではなく、共通の取り決めに沿ってデータをやり取りするための標準です。
ただし、この記述は標準に対応する場合の話で、具体的な金額は示されていません。
いま使っている業界ごとのEDIや個別仕様のEDIから移行する費用を示すものではなく、取引先が移行に応じる保証もありません。
短期と中期の分け方
ここからは、ここまでの事実を組み合わせた提案です。
見直しは取引先との調整が前提になるため、退職日までに終えにくい場合があります。
一方、INSネットで動いているEDIには、担当者の退職とは別に、2028年12月31日という回線の期限があります1。
この2つを合わせると、次の分け方が現実的です。
退職までの短期は、社内引き継ぎか委託で今の運用を止めずに続ける。
見直しは退職後の中期課題とし、取引先との調整から始める。
この分け方では、退職する担当者の知識が中期の見直しにも使われます。
現在の構成、取引先ごとの例外、回線の設定といった情報は、見直しの範囲を決めるときの出発点になるからです。
退職までに一覧と手順書を整えておくことは、短期の運用のためだけでなく、後で見直しを検討する人のための記録にもなります。
INSネットを使っていない場合でも、取引先から方式の変更を求められることはありえます。
その依頼を誰が受けて判断するかは、退職後の体制の一部として決めておきます。
委託を選ぶ場合に渡す情報
委託する、あるいは一部を委託すると決めたら、委託先に何を渡すかを整えます。
委託先が作業の範囲を見積もるには、自社のEDIで何が動いているかが分かる材料が要ります。
渡す情報は、ここまでに作ったものがそのまま使えます。
・4欄の一覧(取引先、データ、締め時間、障害時)
・接続方式と回線の欄、契約先と契約名義
・手順書と、再現のときに詰まった箇所の記録
・例外としてメモした取引先ごとの個別対応
・取引先に委託の予定を伝えたかどうか
見積もりの段階で一覧を渡しておくと、委託先ごとに前提を揃えて比べやすくなります。
逆に、一覧がないまま委託先の質問に答える形で情報を出していくと、聞かれなかった流れが委託の範囲から漏れるおそれがあります。
認証情報やパスワードそのものは、契約を結び、受け渡しの方法を決めてから渡すものです。
見積もり段階の材料とは分けておきます。
委託範囲と責任分界
委託で決めておくことの中心は、責任分界です。
責任分界とは、どこまでを委託先が担い、どこからを自社が担うかの線引きを指します。
EDIの運用には、日常の作業と、取引先との関係にかかわる判断が混ざっています。
作業ごとに線を引くと抜けが見えます。
表の右側の自社に残すものは、委託しても空けられない役割です。
特に取引先への連絡と仕様変更の受け付けは、取引の当事者が自社である以上、技術的な作業を委託先に任せても、受けるかどうかの判断は自社に残ります。
ここで挙げた確認項目は、退職への備えとして編集部が整理したもので、委託契約に必ず含まれる項目の一覧ではありません。
障害時の対応時間と費用の決まり方
委託先の対応時間は、4欄の締め時間と並べて確かめます。
取引先の締めが早朝や夕方にあり、その時間帯に障害が起こりうるなら、委託先がその時間に受け付けているかが重要になります。
受付時間外に起きた障害を誰が見るのかを決めておかないと、委託していても止まったままの時間が生まれます。
費用については、金額より先に、何によって決まるかを確かめます。
・毎月決まった額か、作業や障害対応ごとに発生するか
・取引先の追加や仕様変更への対応が含まれるか、別に見積もるか
・障害時の時間外対応が別の扱いになるか
・契約前の調査や、引き継ぎ期間の作業が別になるか
条件の切り方は委託先によって違うため、一社の金額を相場とみなさないようにします。
同じ一覧を渡したうえで決まり方を並べると、比べやすくなります。
対応時間や費用が妥当かどうかは、自社の締め時間や取引先の数に照らして判断します。
| 案 | 残り期間 | 後任の有無 | 取引先との調整 | 自社に残る役割 |
|---|---|---|---|---|
| 社内引き継ぎ | 後任が再現まで進められる期間がある | 後任または候補がいる | 現行の方式を続けるなら窓口の変更を伝える程度 | 運用の知識・作業・判断のすべて |
| 保守の外部委託 | 委託先に渡す一覧と手順書を整える期間がある | いない、または兼務で手が足りない | 委託後の連絡窓口を伝える | 判断者・取引先窓口・認証情報の保管 |
| EDIの見直し | 取引先との調整が前提で退職までに終えにくい場合がある | 問わない(見直し後の運用を担う人は必要) | 取引先の状況に左右される | 新しい方式での運用と取引先との調整 |
| 作業 | 委託先に任せる範囲の例 | 自社に残すもの |
|---|---|---|
| 日常の送受信の監視 | 送受信結果の確認と異常の通知 | 通知を受ける社内の担当者 |
| 障害時の一次切り分け | 原因の調査と復旧作業 | 再送や手作業への切り替えの判断 |
| 取引先への連絡 | 技術的な状況の整理 | 取引先への連絡と説明 |
| 仕様変更への対応 | 設定や変換ルールの変更作業 | 変更を受けるかどうかの判断と窓口 |
| 認証情報・証明書 | 作業に必要な範囲での利用 | 保管と更新の責任 |
▼ 図の内容を文字で読む
- 本人が操作:後任候補が横で見て理由を聞く
- 本人の前で再現:後任候補が同じ操作をする
- 手順書だけで再現:別の日に後任候補が一人で操作する
- 詰まった箇所を追記:本人に聞いて解決したことを手順書に書き足す
- もう一度操作:書き足した手順書で後任候補が再び操作する
退職後の最初の障害と取引先からの変更依頼に備える体制
一次対応者と連絡経路
退職後に最初の障害が起きたとき、誰が気づき、誰が取引先に連絡し、誰が再送や手作業への切り替えを決めるのか。
これまで担当者一人が担っていた流れを、退職前に人の名前で書き出します。
一次対応者は、障害に最初に気づいて状況を確かめる人です。
委託している場合は委託先が担うこともありますが、委託先から連絡を受ける社内の人も決めておきます。
判断者は、再送するか、取引先に手作業での対応を頼むかを決める人で、一覧の障害時の欄に書いた人と揃えます。
取引先からの仕様変更の依頼も、同じ経路で考えます。
依頼がこれまで担当者個人に届いていたなら、退職前に取引先へ新しい窓口を伝え、届く先を切り替えます。
窓口になるのは、技術的な作業を誰がするかとは別に、変更を受けるかどうかを決められる自社の人です。
退職した担当者に、退職後も問い合わせられるようにしたいと考えることもあるでしょう。
それが可能かどうかは、雇用条件や本人との合意によります。
頼むのであれば、どの範囲の質問に、いつまで、どの方法で応じてもらうかを、退職前に本人と話し合って書面に残しておくと、互いに迷いません。
ただし、退職者への問い合わせを前提に体制を組むと、本人と連絡が取れなくなったときに止まってしまいます。
あくまで補助として考えます。
認証情報・証明書の管理者
EDIの接続に使うパスワード、ログインのアカウント、電子証明書は、所在が分からなくなると送受信そのものができなくなる情報です。
誰が保管し、誰が更新するかを、退職前に決めます。
外部に委託する場合も、保管の責任者は自社側に置きます。
委託先には作業に必要な範囲で使ってもらい、元の情報と更新の記録は自社が持つ形にしておきます。
そうすれば、委託先を変えるときや契約を見直すときにも、接続を自社の手で続けられます。
担当者個人の名義で作られたアカウントは、退職前に共有の名義か後任の名義へ切り替えます。
切り替えたあとに実際にログインできるか、証明書の期限と更新手順がどこに書かれているかも、本人がいるうちに確かめておきます。
想定障害での動作確認
体制を書き出したら、本人が在職している間に一度、障害を想定して動いてみます。
たとえば、ある取引先の発注データが締め時間までに届かないという想定を置きます。
一次対応者が一覧と手順書だけを頼りに、状況の確認、判断者への連絡、取引先への問い合わせまでを進めます。
このとき、退職する担当者には手を出さず、横で見てもらいます。
一次対応者が迷った箇所や、本人なら別の動きをした箇所が、まだ引き継げていない部分です。
机上で体制図を確かめるだけでは、連絡先が古い、手順書の画面が今の画面と違う、といった食い違いは見えてきません。
この確認で障害がなくなるわけではありません。
それでも、退職後に初めて障害に向き合う人が、一度は同じ流れを体験した状態にできます。
答え合わせをしてくれる本人がいるのは退職日までなので、残り期間が短いほど、この確認を早めに日程へ入れておく意味があります。
▼ 図の内容を文字で読む
- 退職までの短期
- 社内引き継ぎか委託で今の運用を止めずに続ける
- 退職後の中期
- 見直しは取引先との調整から始める
- 一覧と手順書が見直しの出発点になる
- 回線の期限
- INSネットは2028年12月31日にサービス提供終了
4欄の一覧や再現の結果が手元にあっても、どの流れを社内に残し、どこを委託や見直しの対象にするかは、EDIの構成と取引先との関係を合わせて見ないと決めにくいためです。
書き出した一覧をもとに、退職までに社内で引き継ぐ範囲、委託に回す範囲、退職後に見直しを検討する範囲の切り分けを確かめられます。無料相談で要件を整理する
要点の整理
| 軸 | 基準 |
|---|---|
| 最初に作るもの | 取引先・データ・締め時間・障害時の4欄の一覧。空欄の行から聞き取る |
| 回線の確認 | INSネットを使う場合は2028年末の終了(NTT東日本の案内)を一覧に書く |
| 引き継げたかの判断 | 後任候補が手順書だけで再現できたか |
| 選択肢の分け方 | 退職までは社内引き継ぎか委託、見直しは取引先調整を前提に退職後の中期で |
| 委託しても自社に残す役割 | 判断者、取引先の窓口、認証情報の保管と更新 |
▼ 図の内容を文字で読む
- 委託先に任せる範囲の例
- 送受信結果の確認と異常の通知
- 原因の調査と復旧作業
- 設定や変換ルールの変更作業
- 自社に残す判断と窓口
- 再送や手作業への切り替えの判断
- 取引先への連絡と説明
- 変更を受けるかどうかの判断と窓口
- 認証情報・証明書
- 委託先は作業に必要な範囲で利用
- 自社が保管と更新の責任を持つ
▼ 図の内容を文字で読む
- 障害に気づく:通知や締め時間の確認で一次対応者が気づく
- 状況を確かめる:一覧と手順書で該当する流れを特定する
- 判断者が決める:再送、待機、手作業への切り替えを決める
- 取引先へ連絡:障害時の欄の連絡先に状況を伝える
- 記録と追記:起きたことと対応を手順書に書き足す
委託範囲や責任分界、障害時の動き方は、自社の締め時間や取引先の数に照らして決める必要があり、退職日までの限られた期間で一から整理するのは負担が大きいためです。 退職前に決めておく体制と、委託先に渡す情報に過不足がないかを確かめられます。
よくある質問
担当者が退職を申し出てから退職日までが1か月しかない場合、何を最優先で聞き取るべきですか。
止まると当日中に出荷や請求に響く流れについて、4欄の一覧のうち障害時の判断と、取引先ごとの例外対応を先に聞き取ります。
あわせて、認証情報や証明書の所在、担当者個人の名義になっているアカウントや通知先も確かめます。
月次の処理は退職までに回ってくる日を調べて、立ち会う日程を押さえます。
手順書の清書は退職後でも進められますが、判断の理由は本人がいるうちにしか聞けません。
手順書は誰が読んで検証すれば、引き継ぎができたと言えますか。
書いた本人ではなく、実際にその手順書を使う人が検証します。
後任候補、後任がいなければ代わりに対応する社内の人や委託先候補が、別の日に手順書だけで操作できたかで判断します。
詰まった箇所を書き足し、もう一度手順書だけで操作できれば、その流れは引き継げたと記録できます。
退職した担当者に、退職後も問い合わせることはできますか。事前に何を取り決めておけばよいですか。
可能かどうかは、雇用条件や本人との合意によります。
頼む場合は、応じてもらう質問の範囲、期間、連絡の方法を退職前に話し合い、書面に残しておきます。
ただし、問い合わせできることを前提に体制を組むと、連絡が取れなくなったときに止まるため、補助として位置づけます。
固定回線(ISDN)のEDIを使っている場合、担当者の退職とは別に何を確認すべきですか。
NTT東日本の案内では、INSネット64、INSネット64・ライト、INSネット1500は2028年12月31日にサービス提供を終了し、ディジタル通信モードは2024年1月から地域ごとに段階的に終了しています1。
NTT西日本のエリアや他社の回線の場合は、自社の契約と利用エリアで条件を確かめます。
その回線を実際にEDIで使っているか、どの通信モードで送受信しているか、設定を誰が組んだかを、担当者の在職中に聞いておきます。
外部委託する場合、認証情報や証明書の管理は誰が持つべきですか。
保管と更新の責任者は自社側に置くのが安全です。
委託先には作業に必要な範囲で使ってもらい、元の情報と更新の記録は自社が持ちます。
そうしておくと、委託先を変えるときや契約を見直すときにも、接続を自社の手で続けられます。
取引先から、退職を機に仕様変更を求められた場合、誰が窓口になりますか。
変更を受けるかどうかを決められる自社の人が窓口になります。
設定の変更作業を委託先に任せていても、取引の当事者は自社なので、判断は自社に残ります。
依頼がこれまで担当者個人に届いていたなら、退職前に取引先へ新しい窓口を伝えておきます。
- 1 出典:NTT東日本「INSネット(ディジタル通信モード等)サービス終了のご案内」(2026年確認)
- 2 出典:中小企業庁(ミラサポplus)「企業間のデータ連携で、受発注の業務コストを削減する!」(2020年公開・2026年更新)
画像の出典元
- Two coworkers engaged in discussion while using a laptop in a modern office setting./Photo by Gustavo Fring on Pexels