本文へスキップ

運用つまずき

担当者個人のアカウントで稼働する定期の処理は担当者の退職で停止する

公開
2026.11.12
更新
2026.11.12

結論

定期の処理は作成した担当者のアカウントやパソコンで稼働することがあり、手順と再開の方法も記録されないまま残ります。担当者が不在になると、停止は次に処理が稼働する日まで判明しないことがあり、社内に再開できる人がいません。

サマリ

  • 毎日または毎月に自動で稼働する処理は、作成した担当者のアカウント、パソコン、メールボックスに依存して稼働することがあり、退職の手続きでそれらを停止するか返却すると、処理も稼働できなくなる
  • 処理の一覧、手順、パスワード、失敗した後の再開の方法を担当者だけが把握していると、不在の後に処理が停止したとき、原因の調査から開始することになる
  • 処理の停止は、次に処理が稼働する予定の日か、その結果を利用する日まで判明しないことがある
  • 処理を修正できるのが担当者だけなので、担当者は休暇や退職の時期を処理の日程で調整することになりやすい

担当者に依存しやすい定期の処理と連携の処理

  • 定期の処理: 毎晩の集計、月末の締め、バックアップのように、所定の日時に自動で稼働する処理
  • 連携の処理: 受注の取り込みや会計のソフトへの転記のように、あるシステムのデータを別のシステムへ転送する処理
  • 運用の手順: 処理が失敗したときの再実行の方法、パスワードの保管場所、処理が停止したときの連絡先

定期の処理は担当者のアカウントや端末で稼働していることがある

定期の処理は、担当者が自分のアカウントやパソコンで作成し、そのまま稼働し続けていることがあります。退職の手続きでアカウントを停止し、パソコンを返却すると、それに依存した処理は稼働できなくなり、次に稼働する予定の日時に失敗します。

処理の場所 担当者に依存する理由 担当者の不在の後の処理の状態
Googleのスプレッドシートなどに設定した自動の処理(Google Apps Script) 処理を開始する設定(トリガー)を作成すると、処理は作成した人のアカウントで実行される[1] アカウントの停止や削除の後は、別のアカウントで設定し直す必要がある
Windowsのタスクスケジューラ 登録したユーザーの権限で実行され、登録時にそのユーザーのパスワードを保存する設定がある[2] パスワードを保存した設定では、パスワードの変更やアカウントの停止の後、次の実行で失敗する
担当者のパソコンのExcelのマクロや自作のツール パソコンの起動と担当者のログインを前提に稼働する パソコンの停止や返却で処理が停止し、初期化で処理そのものが消失する
担当者のメールボックスの転送や自動の振り分け 取引先からのデータの受信が個人の宛先になっている 退職の後、データが受信されないか、誰も確認しない宛先に配信される
クラウドやドメインの管理の画面 管理者のアカウントと二段階認証の端末が担当者の1人分しか無い 設定の変更や更新の手続きができず、期限の通知も個人の宛先に配信される

Google Workspaceでは、ユーザーを削除すると、別のユーザーに移管しなかったドライブのファイルやメールは削除され、復元できるのは削除から20日以内です[3]。共有ドライブに保存したファイルは組織が所有するので、ユーザーを削除しても保持されます[3:1]。

担当者のアカウント、パソコン、メールボックスのそれぞれに依存した処理が、退職の手続きで稼働できなくなることを示した図
図1 処理が担当者個人のアカウントや端末に依存すると、退職の手続きに伴う停止や返却で、複数の処理が稼働できなくなる

手順と再開の方法は担当者だけが把握している

1人で運用していると、処理を作成する人と修正する人が同じで、手順を共有する相手がいないので、記録する動機が生じにくくなります。処理が失敗したときも担当者が自分で再実行するので、記録が存在しても、確認する人は担当者だけです。

担当者の不在の後に処理が停止すると、社内の他の人は停止した処理の特定から調査します。

  1. 停止した処理の特定
  2. その処理の場所と、実行しているアカウントの特定
  3. 接続に必要なパスワードと権限の探索
  4. 停止した期間の受注や会計のデータの再取り込み

処理の一覧があれば、1と2の特定は容易になります。

不在の後に処理が停止したときの調査を、処理の特定、場所とアカウントの特定、パスワードと権限の探索、データの再取り込みの順で示し、前の2つが処理の一覧で容易になることを示した図
図2 処理の一覧で容易になるのは前半の2つで、パスワードの探索とデータの再取り込みは一覧があっても必要

一覧が無い状態で最も特定しにくいのは、個人のアカウントで設定された処理です。例えば、Google Apps Scriptのトリガーは、設定したアカウント以外からは参照できません[1:1]。そのため、他の人が自分のアカウントの画面で確認しても、処理の存在そのものが判明しないことがあります。年に1回の集計やドメインの更新の通知のように稼働の間隔が長い処理ほど、引き継ぎの期間中に一度も稼働せず、存在が判明しないまま残ります。

処理の停止は次の稼働日か結果の利用日まで判明しないことがある

処理が稼働できなくなる日と、停止が判明する日は一致しないことがあります。失敗の通知が担当者だけに配信されていると、通知を確認する人がいないので、業務の部署が結果を利用するまで停止は判明しません。退職の日にアカウントを停止する場合、月次の処理は退職の後の最初の月末まで稼働しないので、停止が判明するのは引き継ぎの期間の終了の後です。

退職の日、アカウントの停止、次の月末の処理の日、業務の部署からの連絡を時間の軸の上に配置し、停止と判明の間に空白の期間があることを示した図
図3 退職の日にアカウントを停止し、月末が引き継ぎの期間の後に来る場合。停止は、月末の処理の結果を業務の部署が利用するまで判明しない

在籍中の担当者は、月末の処理の失敗を自分で修正します。手順を担当者だけが把握していると、不在の後は社内に修正できる人がいません。

処理の運用を担当者1人に依存している兆候

担当者が1人の体制は、中堅・中小企業では珍しくありません。ノークリサーチの2025年の調査では、年商500億円未満の企業の24.5%で、情報システムの担当の人員が1名でした[4]。

次の項目に該当するほど、担当者の不在で処理が停止しやすくなります。どの項目も単独では問題とは限りません。右の列の条件を満たさない項目に複数該当する場合に注意が必要です。

担当者が1人だけで運用している兆候を、記録、権限と通知、不在の影響の3つに分類した図
図4 兆候は、記録、権限と通知、不在の影響の3種類に分かれる
兆候 該当しても問題が軽微な場合
毎晩や月末に稼働する処理の一覧が無い 処理の数が少なく、業務の部署が日程と結果を把握していて、再実行の手順も担当者以外が把握している
担当者の休暇中は、システムに関する問い合わせへの回答が休暇明けまで保留になる 保留になるのが問い合わせへの回答だけで、処理は組織のアカウントで稼働している
クラウドやドメインの管理者のアカウントが担当者の1つだけ 別の管理者のアカウントを社内の別の人が保管していて、二段階認証も本人以外が通過できる
担当者が月末や締めの日を避けて休暇を取得している 締めの作業そのものが手作業で、処理の停止とは無関係
処理の失敗の通知が担当者個人のメールにしか配信されない 通知が共有の宛先にも配信され、通知の受信者が再実行できる
運用を委託していて、委託先の担当が毎回同じ1人で、処理の一覧を自社が受領していない 委託先の複数人が処理を把握していて、一覧の写しを自社も保有している

アイアットOECが2026年5月に実施した調査では、社内で1人で情報システムを担当する330人のうち、37.3%が自分の不在で一部のシステムが停止すると回答しました[5]。完全に停止すると回答した人は17.3%です[5:1]。この数値は担当者自身の見立てで、本人が把握していない処理は含みません。

担当者の不在を放置した場合の危険

処理の一覧と手順を担当者だけが把握している状態から4つの危険が生じることを示した図
図5 処理の一覧と手順を担当者だけが把握していると、担当者の在籍中も退職の後も危険が生じる

締めの日以降に処理の停止が判明する

締めの日に利用する処理の停止は、当日かその後に判明することがあります。例えば、月末の請求のデータの作成、給与の計算のための勤怠の集計、受注のデータの取り込みです。停止した期間のデータは後から再取り込みが必要で、それまで業務の部署は手作業で数字を確認することになります。

処理の失敗時に処理を再開できる人がいない

担当者の退職の後は、サーバーの停止やクラウドのサービスの仕様の変更で処理が失敗したときも、原因を調査できる人が社内にいません。処理の一覧が無いと、外部の会社に依頼した調査も所在の特定から開始し、再開までの期間が長期化しやすくなります。

担当者が休暇や退職の時期を自由に決定できない

担当者は、不在の間に処理が失敗しても修正できる人がいないことを把握しています。そのため、休暇を締めの日の後に設定し、退職の時期を引き継ぎの完了の時期で調整することがあります。引き継ぎの完了の条件が未定だと、その時期も確定しません。

退職者のアカウントを停止しにくい

担当者のアカウントを停止すると、そのアカウントで稼働する処理も停止するので、退職の後もアカウントを存続させる判断をすることがあります。中小企業基盤整備機構のサイトの記事で、中小企業支援アドバイザーは、退職者のアカウントの確実な停止を最低限の経営リスク対策としています[6]。処理のために個人のアカウントをそのまま存続させると、この対策と両立しません。

担当者が1人でも処理が停止しにくい場合

担当者が1人でも、次の3つを全て満たしていれば、不在で処理が停止する危険は軽微になります。1つだけでは不十分です。例えば、組織のアカウントで稼働する処理も、接続先のパスワードを担当者だけが把握している状態では停止します。

  • 処理を組織のアカウントやシステム用のアカウントで稼働させ、接続先のパスワードを共有ドライブなどの組織の保管場所で管理している
  • 処理の失敗の通知が、担当者以外の宛先にも配信されている
  • 担当者以外に、処理の一覧と再実行の手順を把握している人がいる。委託している場合は、一覧の写しを自社も保有している
3つの条件を順に確認し、満たさない条件ごとに存在する危険を示した分岐の図
図6 欠けた条件に応じて、停止、判明の遅れ、再開できない状態の危険が残る

判断の基準は、処理が個人に依存していないかと、停止したときに担当者以外が停止を把握して再開できるかです。担当者が2人の体制で、それぞれが自分のアカウントで処理を設定し、手順を共有していない場合も、どちらの退職でも同じ停止が発生します。

脚注
  1. Google「Installable Triggers」Apps Script ↩︎ ↩︎

  2. Microsoft「Security Contexts for Tasks」Microsoft Learn ↩︎

  3. Google「組織からユーザーを削除する」Google Workspace 管理者ヘルプ ↩︎ ↩︎

  4. ノークリサーチ「『ひとり情シス』は増えているのか?減っているのか?IT管理/運用の現場で起きている変化」2025年10月14日。2025年5月の調査、年商500億円未満の中堅・中小企業735社の回答 ↩︎

  5. アイアットOEC「ひとり情シスの半数以上が、自身が不在となった場合『会社のシステムが停止し、業務に支障が出る』と回答!」PR TIMES。2026年5月29日〜31日のインターネット調査、会社で1人で情報システムを担当する会社員330人(20〜50代、モニター調査) ↩︎ ↩︎

  6. 中小企業基盤整備機構「中小企業は『ひとり情シス問題』にどう向き合うべきか」2026年5月18日。中小企業支援アドバイザー 村上知也氏の記事 ↩︎

関連するサービス

お問い合わせ・ご相談

システム開発、データ活用、プロダクトづくりのことならお気軽にご相談ください。要件が固まる前の整理や、お見積もりだけのご依頼も承ります。