ワークフローサンプル: 第549話：情報解禁こそ自動的に！

人事情報の発表方法

「人事異動の情報（配置変更や地位変更）を社内に公表する」という業務はフクザツです。

昇格・降格・採用・退職・休職・部署異動・関係会社出向…と、さまざまなパターンがあり、また個別の事情もそれぞれに異なります。

人事担当者の気持ちとしては、たとえば「信任の厚いベテラン社員が晴れて定年退職される」というケースなら何か月も前から周知しておきたくなるかも知れません。しかし一方で「競合他社に転職する」というケースなら秘密にしておきたいと思うかも知れません。また「家族介護のために休職する」といったケースでも、同僚や関係者に対して（守秘義務違反に配慮し）積極的に事前連絡しようとする人もいれば、黙っていたいと考える人もいるでしょう。

基本的には『既定の解禁ルール』にのっとって、粛々と「人事部内秘の情報」を「社内公知の情報」に切り替えるべきなのでしょう。（人事通達）

業務上の課題

公表方法として「社内掲示」という手法がとられている会社は少なくありません。

しかし、紙に印刷して「掲示板」や「壁」に張り出すという手法では、外出が多い人、長期休暇中の人、あるいはリモートワーカーにとっては見る機会が非常に少ないものになってしまいます。他方、人事部門としても「決められたタイミングで掲示作業を行う」や「決められたタイミングで掲示を終了させる」といった業務は、意外と大きな負担となります。

また「朝礼での口頭発表」という手法がとられている会社もあります。

しかし、これもまた長期休暇中の人やリモートワーカーは、朝礼出席者と同じだけの情報量を得ることは難しいと言わざるを得ません。さらに、口頭であるが故に「異動の日付」や「異動部署」などが正確に伝わらないリスクもあります。

[人事異動情報の公表]

業務の自動化

この業務プロセス定義は、金曜日の朝6時に「翌週日付で予定されている人事異動情報」が自動公表される仕組みです。

すなわち、たとえば8月25日(金)の朝には「8月27日(日)から9月2日(土)に予定されている人事イベント」が抽出され、社内メーリングリストに投稿されます。

2017-08-28 (--:--): 佐藤太郎（退職：最終出勤日）
2017-08-31 (16:00): 鈴木次郎、定年退職式
2017-09-01 (--:--): 高橋三郎（製品開発部→営業部）
2017-09-01 (--:--): 田中四郎（営業部→営業部長）

具体的には、（業務プロセス図を見れば一目瞭然ではありますが）、金曜日の朝6時になればプロセスが自動的に起動し（タイマー開始イベント）、『Request to Calendar』という自動工程に到達します。そして、その自動工程にて Google Calendar API への自動リクエストが行われ、「2日後から8日後」の情報（つまり「次週日曜日から次週土曜日」の情報）が自動的に抽出されます。さらにその後、下流の「メール送信イベント」にて社内通知されます。

もちろん、対象の Google Calendar は「役員および人事部門に限る」といったアクセス制限をかけておきます。そうすることで、人事担当者は、まだ社内公表できない遠い未来の『異動予定』であっても、異動日が決定した際に逐次「異動の予定」を書き込む事が可能となります。

これらの設定によって、「社内へ公開する作業」が自動化され、ミスやモレがない公表業務が実現されます。（メール公表があった上で全社朝礼にて「退職の挨拶」などの時間をとるのも良いでしょう）

個別公表と一括公表

ところで、この業務プロセス定義は「１件１件の辞令を審査・内定・発令する流れ」とは少しオモムキが異なります

つまり、関係者との調整や本人への打診などの手続きがワークフロー化されているなら、その内定決定後に「タイマー中間イベント」をおくなどして、自動的に「公表」されるワークフロー設計にしがちです。（そして期末には大量のメールが…）

しかしもし、その「公表する」という工程を切り離し

Google Calendar へ書き込んで終了
Google Calendar からの抽出で開始

という特殊な分割を行えば、「複数案件の公表」が一括して行われる仕組みを実現できます。

一般に、業務プロセス定義に流れる複数の案件をマージ（集約）する方法は簡単ではありません。しかし、そのマージ（集約）がカレンダー情報に基づくものなのであれば、あえて Google Calendar という中間データベースを使うことによって、よりスムーズな業務が設計できる可能性があります。

＜モデリング動画８倍速＞