ワークフローサンプル: 第545話：Google Group 連携で、ラクラクML管理(3)

Google Group 登録者のメンテナンス

前回記事および前々回記事では、『Google Group』のメンバー追加やメンバー削除が自動的に実行される業務プロセス定義を紹介しました。

Google Group を「社内の情報共有ツール」として活用している会社であれば、この自動追加や自動削除といった機能は、「適時更新を保証する仕組み」として非常に有効と言えるでしょう。

求められる信頼性要件の高さ

しかし、この様な仕組みを導入してもなお、「正しいメンバーを維持すること」は容易ではありません。

たとえば、急ぎの依頼を受けて「間違った Group にメンバー追加」（システム管理画面）してしまうケースもあるでしょう。あるいは、ユーザ自身が「退会処理」（ユーザ設定画面や unsubscribe メール）をしてしまうケースもあるかもしれません。その様なケースは、「届くべきでないヒトに情報が届いてしまう状態」あるいは「届くべきヒトに情報が届かないという状態」になってしまいます。

「えっ？　そんな通達、あったっけ？？」

何か月もメーリングリストの情報を受け取らずに仕事をしていた、、、なんかヘンだと思った、、、、といった悲劇は、（非常に恐ろしい事ではありますが）、いつか必ず発生してしまうものです。

[MLメンバー確認]

リスク軽減策

この業務プロセスは Google Group のメンバーリストを自動取得し、当該 Google Group に自動投稿する仕組みです。

たとえば「営業3課ML」のメンバーは、毎月1日の朝7時、「営業3課の全員のメールアドレスが本文にかかれたメール」を受信することになります。たとえば「ISMS取得プロジェクト」のメンバーは、毎月1日の朝7時、「ISMS取得プロジェクトの関係者全員のメールアドレスが本文にかかれたメール」を受信することになります。

確かにこの仕組みを導入しても、受信していないヒト自身は「受信していない事」に気づくことはできません。しかし、受信しているヒトが「受信すべきヒトが受信していない事」に気づくことはできるでしょう。そして副次的に、「そう言えば、こんなヒトも受信しているんだった」と再認識する機会にもなります。

つまり「取締役会用のメーリングリスト」や「社外協力者も参加するメーリングリスト」など、情報公開範囲に常に注意すべき Google Group での運用が推奨されると言えます。（もちろん社外協力者がメンバーに含まれている場合には、その社外協力者にも購読者全員のアドレスが開示される仕組みになっています）

※言うまでもありませんが、各メールアドレスを Group 内で共有しないルールとなっている Google Group は想定外です。（e.g. 「全取引先」）

無人工程の活用

ここでは［ML数取得］［ML選択］［MLメンバー取得］という3つの無人工程（追加された『サービス工程』）が利用されています。

［ML数取得］では『監視対象メーリングリスト』（複数行文字列）の行数が自動カウントされ、ループする回数がセットされます。［ML選択］と［MLメンバー取得］ではN行目に書かれた Google Group について、その購読者が API リクエストされます。（ワークフローシステムのサーバサイド処理として『Admin SDK Directory API v1』への OAuth2 リクエストが自動送信されます）

そして、直後にあるメール通知イベントによって Google Group の「購読者リスト」が自動投稿される流れとなります。

なお、メール通知先を情報システム部に固定し、情報システム部が責任をもってメンバーメンテナンスを行うという業務プロセスも検討の価値があると言えるでしょう。

[MLメンバー確認：「1.監視対象を確認」画面]