要約

  • DocuSignでユーザーを閉じると、新規送信とアカウントへのアクセスは止まる。閉鎖前に送ったエンベロープは、受信者が引き続き完了できる。
  • 所有権の移転は確認後に処理待ちとなる。最初に表示される直近3カ月の一覧と、移転の申請だけでは、業務の引き継ぎを確認できない。
  • 個別共有で権限を細かく選べても、どの担当者が、どのアカウントで仕事を続けるかは企業が決める必要がある。

採用の返事を待っている人にとって、担当者の退職日は会社の内部事情だ。仮に、採用担当者がオファーの文書を送った後に退職し、候補者が翌日署名したとする。候補者は採用手続きを進めている。会社側では、その文書を送った人のアカウントがすでに閉じられているかもしれない。

この例は仮定だが、二つの状態が両立することはDocuSignの公式手順に書かれている。閉じられたユーザーは新しいエンベロープを送信できず、自分のアカウントや完了済み文書にもアクセスできない。一方、閉鎖前に送信したエンベロープは受信者が完了できる。エンベロープとは、署名する文書とその処理をまとめた単位だ。

送信者がいなくなるたびに手続きを止めれば、候補者や顧客が企業の人事異動に付き合わされる。この連続性には価値がある。ただし、社外の人が先へ進めるなら、社内にも続きを受け持つ人が要る。退職処理の完了印は、その人の代わりにはならない。

文書を残す仕事と、続きを受け持つ仕事

DocuSignはユーザーを閉じる前に、エンベロープの所有権を移すか、完了済みの文書をダウンロードするよう勧めている。ここには異なる作業が並んでいる。保存用のファイルを確保することと、まだ動いている案件を引き受けることだ。

後任に共有フォルダーを渡せば、すでに終わった文書は見つけやすくなる。だが、署名待ちの案件について、誰が進捗を見て、誰が次の処理をするのかは別に決めなければならない。電子化すると紙の山は減る。担当者不在の山まで自動で減るわけではない。

共同作業には共有アクセスが用意されている。管理者は権限、開始日と終了日、有効な状態を管理でき、設定の変更は監査ログに残る。公式説明上の共有は同一アカウント内のユーザー同士で行い、ユーザーからグループへの共有とは区別される。

閉じられたユーザーのエンベロープを扱う場合、説明は自分か別の有効なユーザーに移転してからアクセスする手順を案内している。休暇中の代理として見られたことと、退職後の仕事を正式に引き受けたことを、同じ証拠で済ませるのは無理がある。

「移転する」と「移転した」の間

所有権の移転では、エンベロープとテンプレートをそれぞれ選ぶ。最初の一覧には直近3カ月の対象が表示され、日付範囲や送信者、テンプレート所有者などで絞り込みを変えられる。3カ月は最初の表示範囲であって、保管期限でも、古い仕事が消えた印でもない。

この初期設定を、退職者が残した全件の一覧だと思い込むと、引き継ぎ対象が画面の都合で小さくなる。ソフトウェアが古い文書を隠して処分したのではなく、利用する側が最初の検索結果で業務範囲を決めてしまう。

対象を選んで移転を確認した後にも処理がある。公式手順では、依頼はキューに入り、一括操作のログに記録される。処理完了後に対象が新しい所有者側へ移る。ボタンを押した担当者の作業と、システム側の作業は、同時に終わるとは限らない。

後任が引き受けるべき一覧と、実際に移った対象を照合する時間は、ここから生まれる。ユーザー数だけを数える購入見積もりには載りにくい時間だ。毎回管理者を呼び、見つからない文書を探し、処理待ちの理由を確認するなら、その手間も製品を使う原価になる。

大きな鍵を渡せば済む時代でもない

DocuSignの2026年9月のリリースノートには、API経由で一つのエンベロープを共有する機能が記載されている。閲覧・ダウンロード、修正や再送などの操作、さらに下書きの送信まで、許可する範囲を分けられる。同一アカウント内が対象で、記載された提供範囲からPersonalプランは除かれている。

後任にメールボックス全体を開放するしかない、という説明では現在の選択肢を捉えられない。完了ファイルの保管だけを担当する人と、進行中の案件を処理する人では、必要な権限が異なる。仕事の分担を具体的にすれば、渡す権限も具体的になる。

ただし、操作が許されることと、その仕事を自分が担当すると理解していることは別だ。候補者からの問い合わせを誰が受け、署名が進まなければ誰が確認するのか。企業は権限の設定と一緒に、責任の行き先も決める必要がある。

同じリリースノートでは、Shared AccessのREST呼び出しでユーザーIDとアカウントIDを合わせて確認する変更も説明されている。複数アカウントに所属していても、文書が属するアカウントの文脈を外して自由に扱える仕組みではない。対象はREST v2とv2.1であり、ウェブやモバイルアプリの変更として一括りにはできない。

部署を統合して窓口を一つにするときにも、この境界は残る。組織図で担当者を置き換えるだけでは、後任が作業するアカウントまで自動で整わない。

席は空いても、受け皿は空けない

ユーザー閉鎖の説明には、署名グループからその人をすべて外す独立した選択肢もある。外さなければ、グループ宛て通知を引き続き受け取ることがある。アクセスの終了、通知先の変更、既存案件の進行はそれぞれ扱うべきものだ。一つの閉鎖ステータスで全部が終わったと判断するには、製品の動きが細かすぎる。

UCLが公開する電子署名サービスの説明は、引き継ぎを送信時点から考える一例になる。同大学の共有メールボックスには直接ログインできず、送信チームをグループにまとめ、送信前に共有メールボックスのユーザーへ移すルールを設定し、そのエンベロープをチームに共有する方法が示されている。人の入れ替わりより長く使える受け皿を用意する考え方だ。

DocuSignのAPI資料は、移転ルールを作れるのは管理者で、アカウントにはTransfer Custodyが有効になっている必要があるとしている。公開された運用例を参考にするときも、自社の利用条件と必要な設定は費用に含めて考えることになる。

公開資料には引き継ぎ漏れの発生率や損失額がなく、規模を知るには退職者、移転完了記録、担当者のいない未完了案件を照合する必要がある。まず確かめるべき動作はもっと単純だ。前任者を退出させたあと、後任者が仕事を進められること。契約書には、退職届を一緒に出してくれる親切心はない。

出典