Zenn
👋

ひとり情シスが退職するときにやったこと（主にGWS、Slack）

2024/11/15に公開
Slack
退職
情シス
gws
tech

背景

そういうことになりました。

思想

一人なので権限をもろもろ握っています。
自分の退職後にカオスになることを避けるため、上司の許可をもらって次のようにしました。

  • 自分用のユーザー（ユーザーB）をもう一つ作る。ユーザーBの権限は通常社員と同じとする
  • 引き継ぎが終わったら、元の自分のユーザー（ユーザーA）の退職処理をする
  • 退職日までユーザーBで過ごす

費用は1セットぶん発生しますが、自分の後片付けを自分でできるのでおすすめです。
自分で墓を掘るタイプの生前葬です。

GWS

GAS

GASファイル自体は共有ドライブに置いてあり、オーナー譲渡の問題は発生しませんでしたが、GASの実行権限やトリガーは自ユーザーに紐づいている状態でした。
最初から特権管理者でやっておけばよかった…

トリガー
GASのトリガー一覧（ https://script.google.com/home/triggers ）を開きます。
ここに出てきているトリガーのうち今後も使いたいものは特権管理者で作り直し、自分のトリガーからは消しました。
（このあたりはGWSユーザーを消すときのオーナー譲渡でよしなにしてくれそうな気もするのですが、念のため）

権限
GAS実行時の権限が自分に紐づいたままだとユーザー削除後に何が起きるか分からなかったので、あらかじめ外しておきました。
Googleアカウントのデータとプライバシー（ https://myaccount.google.com/data-and-privacy ）を開き、「サードパーティ製のアプリとサービス」に遷移します。
アクセス許可したGASもここに出てくるので、クリックして「（名前） との接続をすべて削除しますか？」をクリック、削除しました。
その後、該当のGASを特権管理者ユーザーで開くと実行許可のダイアログが出てくるので許可しておきます。
これで大丈夫なはず。

Gmail

  • 登録していたメルマガ、勝手に送られてくる営業メール類を解除
  • スプレッドシートの更新通知など、自分で設定していた通知系を止める
  • 転送設定を止め、必要なら引き継ぎ先のGmailで設定しなおす（Gmailの「設定」>「フィルタとブロック中のアドレス」を「転送」で検索すれば探せます）

GWSのGood/Badまとめ

  • Good
    • もともと、社員個人のユーザーとは別に特権管理者ユーザーが作ってあった
    • 情シス社員のユーザーは特権管理者にせず、管理者ロールを割り当ててあった
    • 情シス宛のメールは個人アドレスではなく情シスグループアドレスで受けていた
    • GASをドライブ上の１フォルダにまとめてあった
  • Bad
    • 共有ドライブへの移行が終わっておらず、マイドライブ運用も続いていた
    • GASのトリガーと実行権限が個人ユーザーについていた

Slack

自分はプライマリオーナーでした。
Slackアプリもいくつか作っていたので、それらをお片付けしていきます。

プライマリオーナー譲渡

手順は公式ヘルプにある通りです。
譲渡の時はパスワードが必要になりますが、SSOでログインしているとパスワードがありません。
その場合はパスワードリセットしてから譲渡する流れになります。

自分が作ったSlackアプリにコラボレーターを追加

Your Apps（ https://api.slack.com/apps ） を開くと自分が作ったアプリ一覧が出てくるので、ひとつずつクリック → Collaboratorsから引き継ぎ先を追加していきます。
ついでに自分をLeaveさせておくと、Your Appsに出てくるものが減るので分かりやすいです。
（これを実行するタイミングが早すぎると、Leaveした後に問い合わせが来て泣くことに…）

自分が作ったSlackワークフローにコラボレーターを追加

ワークフロービルダーを開き、 Managed by you に出てくるワークフローにコラボレーターを追加していきます。
一覧からそのままコラボレーター設定画面を開く導線がなくてつらかった…
Slackワークフロー内で外部サービス連携している場合、連携部分も対応が必要です。
自分はスプレッドシート連携していたので、引き継ぎ先の人に連携しなおしてもらいました。連携しなおすと設定内容が消えるのもつらかった…

更に、Slackワークフローを以前から使っている人はLegacy workflow managementも見ておくとよいです。移行前のワークフローがあるとそちらにだけ出てきて、ワークフロービルダーでは確認できません。罠です。

プライベートチャンネル

引き継ぎ先の人を入れていきます。

アプリ

アプリをインストールしたSlackユーザーを消すと、アプリが無効化されます。
これを防ぐには個人に割り当てない管理者ユーザーからインストールするしかないんだろうか？
既にインストールしてしまっていたので、ユーザーを消してアプリが無効化されたあとに必要なものだけ戻しました。
このとき要らないアプリの整理もできるので、いいっちゃいいのか（？）

SlackのGood/Badまとめ

Good

  • なんだろう…ない？

Bad

  • 個人に割り当てない管理者ユーザーを作っていなかった（費用をケチっていた）
  • 自分が作ったアプリやSlackワークフローがそこそこあった

GWSとかSlack以前に…

SaaSがどうとかそんな些末な話じゃない！ひとり情シスが辞めるのは大変なんだぞ！
というお話もあるかと思います。

後任がいない

「後任が見つかるまでいてほしい」と引き留められるケースもあるのかなと想像します。
いまのご時世、情シスを採ろうとしてすぐ採ることは難しそうです。待っていると永遠に待つことになりかねませんし、急いでアンマッチな人材を採るのも双方不幸になります。
そのような引き留めを受けた場合、情シス代行サービスとかシェアード社員とかいったものを提案する選択肢もあるのではないでしょうか。

自分はそのつもりでいましたが、幸い後任社員が決まりました。

引き継ぎが難しい

年次作業もあるので、完璧な引き継ぎをしようとしたら最低1年かかります。
そうでなくても経験やスキルが千差万別な情シスのこと、さくっと引き継ぎが終わるケースは少ないのではと推察します。

これは退職時にやることではなく日頃からやることですが「手順を書き残しておく」に尽きると思います。
自分は記憶が苦手なので何でも書き残す癖があり、たとえ覚えている業務でも手順に沿って実施していました。書いた手順を使い続けることでメンテナンスができ、たとえばSaaSの仕様が変わったときなどにも追従できるからです。
そのおかげで引き継ぎが異様にスムーズでした。
何を聞かれても「詳しい手順はこのドキュメントに書いてあります。ざっくり言うとこういうことです」で済んでしまいました。足りないものがあればその場で手順をガッと書きました。
とにかく「手順に書いてある、その手順は実績がある」という状態にしてしまえばお互いに安心です。

他の方法として、「退職後も業務委託として情シスを続ける」も選択肢になりそうです。
しかし「引き継ぎが不十分だから業務委託に」という流れ（実際はそうでなくてもそう見えかねない流れ）になると、よくない感情を残しそうだなと思いました。
自分は幸いスッと辞めることができました。

これから転職する情シスのお役に立てば幸いです！

Discussion