GWS/GASの引き継ぎ 退職におけるGoogleAppsScriptの扱い 特にインストーラブルトリガーについて
長々と色々書いたが、要は、インストーラブルトリガーの設置者が誰なのか、それに注意しようね、ということだ。
まえがき
GASのうち、特にインストーラブルトリガーを設定したものについては、その設置者が退職する前に引き継ぎが必要だ。引き継ぎしないまま退職するとどうなるかは怖くて検証していない。
フォルダの権限を変えるようにトリガーの権限も変えられると良いのだが、どうもそれは出来ないようである。
そのため、手動でトリガーを引き直すか、トリガーのためのGASコードを書いて走らせるなどして対応が必要になる。
そもそも、トリガー設置については管理用アカウントで管理しておけばよかったな、とも思うが、既に個人アカウントでトリガーを設置しているものが数件あったので、件数も少ないし、引き継ぎのために説明も必要だったので、そのトリガーを今回は手動で引き直した。
要した時間は、説明込みで5件のトリガー設定し直しでおおよそ1時間程度。（掛かる時間は後任者のGASへの理解にもよる）
私の環境は少人数、非IT企業、私自身のスキルも高くないため、もっとスマートなやり方があるとい思いつつ、今後のため、自分のためにこのnoteにメモしておく。
抜け漏れ、間違っている点、もっとこうした方がいいなど、ぜひコメントいただけますと幸いです。
前提として必要な知識
GASの書き方や基本構文などは割愛する。
引き継ぎにあたって、トリガーと権限について、今一度確認しておく必要がある。
トリガーについて
GASにおいて、トリガーは2種ある。
シンプルトリガーとインストーラブルトリガーだ。
インストーラブルトリガは常に設置したアカウントで実行される（意識していようがいまいが）。
インストーラブルトリガー使用時の注意点
・インストーラブルトリガーによる実行は、常にトリガーを設置したアカウントによる実行となる
・インストーラブルトリガーは他のユーザからはどのアカウントで設置したかが把握できない
リファレンス
Simple Triggers
https://developers.google.com/apps-script/guides/triggers?hl=en
Installable Triggers
https://developers.google.com/apps-script/guides/triggers/installable?hl=en
GAS本
愛すべき変態つじけ氏のブログが詳しい。
https://tgg.jugani-japan.com/tsujike/2021/05/gas-form3/#toc10
そういえば自分のnoteでもちょろっと書いていた。
https://note.com/0375/n/n578c0d96771d
ちょっと脇に逸れるが、どうにかしてオーナーを特定できないのか？
権限について
スクリプトオーナー
基本的に業務ファイルは共有ドライブ下に置いているのであれば、スクリプトのオーナも共有ドライブになるので、あまり問題にはならないはず。
トリガーのオーナー
インストーラブルトリガーの場合、設置した人がオーナーになる。
このあたりは下記の図解説明のURLが詳しい。
参考までにいくつかのURLを以下に記す。
https://for-dummies.net/gas-noobs/hints-for-excution-settings-and-sharing-settings-for-gas/
※クラシックエディタ
https://auto-worker.com/blog/?p=620
GWS管理者ヘルプ
https://support.google.com/a/answer/60781?hl=ja
トリガーを設定し直す（実際の具体的な作業）
私の環境の場合、基本的に、スプレッドシートやスクリプトは共有ドライブで作成しているので、オーナーは共有ドライブになる。殆どスプレッドシートのコンテナバインドスクリプトだな。
なので、トリガーを後任者に設定してもらえば大過ないと認識している。
手作業で設定し直す
私は今回こちらの手法を取った。
対象が10件以下で、かつ、後任者のGAS知識はコピぺ利用で自分でコードを書くことはしていないというレベル感です。
具体的には、カスタムのslackbot（アプリ）を通じて、フォームに回答があったらslackに通知したり、一定期間に対応していない案件についてリマインドをslackに通知したりするようなものについて、後任に説明しつつトリガーを引き直してもらうといった対応を取った。
説明込みで、5件ほどのトリガー引き直しに1時間程度掛かった。
トリガーの引き直し自体はそんなに難しいことではないが、コードがどういった仕組みになっていて、どのコードをトリガーにしているか、ドキュメントのコメントを見ながら、時には書き加えながら、引き継ぎを行なった。
ドキュメンテーションコメントまじ大事。
https://tonari-it.com/gas-documentation-comment/
https://front-works.co.jp/blog/gas-use-documentation-comments/
コードで設定し直す
（勝手に）お世話になっているnepiaさんのnoteや、私の師匠であるetauさんのgithubを参照してください。以下にURLを記します。
nepiaさんのnote
https://note.com/nepia_infinity/n/nc6af7cd86a1d
etauさんのgithub
https://github.com/etau/gas-classes/blob/0e83f75e28d112eaad7d9a1e187705fb819f30c1/class_trigger.gs
今後のために
・個人業務から複数人体制に移行したタイミングでトリガー設定ルールや管理を設ける
・管理アカウント必要？
うーん、やっぱり、権限を集約させた管理用アカウント（個人と紐づいていないアカウント）を作ってそれで管理が安全かなあ......。
共有アカウントは色々とアレが…
参考
https://for-dummies.net/gas-noobs/hints-for-excution-settings-and-sharing-settings-for-gas/
例えばこういったメール送信ツールの承認なんかは各操作者がすればいいのであって、それを管理する必要はない。しかし、業務全体に関わってくるようなものについては、属人化を排して管理アカウントにまとめておくほうがよさそう。
でもなー、引き継ぎのタイミングで棚卸しするというのも、それはそれでよいだろうし。
GASでクリティカルな仕事の仕組みにしてしまうのもそれはそれでどうなのかというのもある。
「コンテナのスプレッドシートにトリガー設定画面のキャプチャを貼っていて、そこでも誰が設定しているのか記録」というのも、なるほど、やっておくといいな。
GWS（GoogleWorkSpace）全般の引き継ぎについて
それだけで長々と書けそうなので今回は割愛。
参考として管理者ヘルプとか下記URLとか。https://media.rakumo.com/2019_06_04_1429/
各ユーザのマイドライブの扱いに注意。
プランによってはユーザのアーカイブという手もある。
雑文 ドキュメンテーションコメントは大事
以下、自分の整理のためにごにょごにょ書いた雑文。
↓退職関係の設定slack編はこちら
退職にあたって、これまで職場内で書いたGASのうち、特にトリガーを設定したものについて引き継ぎが必要になった。
職場内では、私以外は基本的にGASはコピペ利用という状態である。私もコピペ利用するけど...…。
基本的な制御構文などの勉強会をしたかったが、それは実施できぬまま退職日を迎えることになりそう。
そんなわけで、GASコードをあまり書いていない人にもどうにかして引き継ぐ必要があった。
具体的には、カスタムのslackbot（アプリ）を通じて、フォームに回答があったらslackに通知したり、一定期間に対応していない案件についてリマインドをslackに通知したりするようなものについて、後任に説明しつつトリガーを引き直してもらうといった対応を取った。
説明込みで、5件ほどのトリガー引き直しに1時間程度掛かった。
トリガーの引き直し自体はそんなに難しいことではないが、コードがどういった仕組みになっていて、どのコードをトリガーにしているか、ドキュメントのコメントを見ながら、時には書き加えながら、引き継ぎを行なった。
ドキュメンテーションコメントまじ大事。
https://tonari-it.com/gas-documentation-comment/
https://front-works.co.jp/blog/gas-use-documentation-comments/
#GAS
#引き継ぎ
#退職
#GoogleAppsScript
#インストーラブルトリガー
#GWS
#GoogleWorkSpace
いいなと思ったら応援しよう！
