ワークフローサンプル: 2016/02

※この記事には「改善編」があります

旦那が「水疱瘡」にかかった！
子供が「インフル」にかかった !!

誰だって「職場に感染症が蔓延！」といったリスクは、ゼロに近づけてもらいたい。会社には「適切な感染症対策」を取ってもらいたい。

一言で「感染症」と言っても様々だ。感染力が極めて強い「エボラ出血熱」のような「感染症法」が定める『1類感染症』に該当するような大病(!!!)もあれば、、、「水疱瘡」や「季節性インフルエンザ」など『5類感染症』に分類され、それぞれの組織に対策が委ねられる感染症もある。（さすがに『１類』は国家権力が対策するハズ）

以下のワークフローは「第465話：勤怠管理もクラウド型ワークフローで」の『出退勤報告フロー』をアレンジしたものだ。

何ということはない。日ごろ入力している「出退勤の報告フォーム」の下に、「感染症の兆候アンケート(任意)」という入力フォームが追加されている。

季節型インフルエンザ、風疹、水疱瘡などの感染症に、自身が感染したかもしれない（0/1/2/3）
季節型インフルエンザ、風疹、水疱瘡などの感染症に、同居家族が感染したかもしれない（0/1/2/3）

0: 感染の可能性はほぼ無い
1: 症状が出始めた気がする
2: 症状が強く出始めたと思う
3: 感染症の検査で陽性がでた

[出退勤報告フロー]

部長自身が「稟議書」を書く。。。

そもそも決裁権者なのだから、稟議する（決裁権者に判断を乞う）という行為自体が要らないハズだ。それが部予算内での判断なら、なおさらだ。しかし、そうであってとしても「稟議書を作成すべし」としている会社は少なくない。つまり、「組織として形成された意思は文書として記録に残す」という視点にたつとともに、監査対応の効率化を想定している。

ただ、、、ワークフローシステムにおいて、「自分で申請して、自分で決裁する」というのは、たしかにメンドウな話だ。

以下のワークフローは、2016年版の基本業務に収録されている「第462話：稟議書を回す」をアレンジしたものだ。「部長ロール」を持つユーザは『2.決裁する』を通らないフローで、稟議書を提出できるようになっている。

[稟議フロー]

上司を評価する「無記名投票」をしたい！

なるほど、オンラインで、簡単に「上司評価」の機会が持てるなら、ソレはソレで便利そうだ。「年次」とは言わず、「四半期おき」や「月次」などで実施すれば、上司自身が日常業務を振り返るための良い機会になる、、、ような気がする？　（「内閣支持率」の調査みたいなものか？）。

しかし、ワークフローシステムとは、そもそも「いつ誰がどんな入力をしたか」を記録する道具だ。普通に考えれば「無記名」とは相性が悪い。

このワークフローは、チームメンバーによる「上司評価フロー（無記名投票）」が定義されている。

具体的には、スケジュールされた日時になると［1.上司評価を記入する］というマイタスクが、メンバー全員に割り当てられる仕組みだ。メンバーは、（手を震わせながら？）、たとえば、[1]信任する、[2]どちらでもない、[3]信任しない、を選んで申請する。

秀逸なのは、入力した「上司評価データ」が自動的に「外部ファイル」に追記され、そして申請データとしては自動的に消去される点だ。つまり［データ閲覧権限］があるユーザでも「誰がどのような投票をしたのか」は確認できない。さらにご丁寧なことに、この例では「外部ファイル」の中身を追記都度にシャッフルする機能まで整っている。つまり、通信ログでも盗聴解析しない限り、投票内容は保護される仕組みになっている。（投票したかどうか？、いつ投票したか？、については保護対象外としている）

もっとも、、、「投票総数が１人だった！」とか、「投票者全員が信任しないを選択した！！」とか、そういう場合にあっては「誰がどのような投票をしたのかを隠蔽する」が実現できない。。。（怖）

[上司評価の投票（無記名投票）]

『社員マスター』をセットしたい！

ただ、人事部のシゴトは「在職者」だけを管理すれば良いという訳ではない。「出向した人」や「退職した人」の情報も管理しなければならない。しかし、業務システム等で使われる「在職者の一覧」（社員マスター）も、きっちりメンテナンスしたい。

そして「Excel ファイル」での社員マスター管理は、すでに限界だ。。。

基本情報（社員マスタ－）：社員番号、メールアドレス、通称氏名、入社年月日
詳細情報（法定管理項目）：戸籍氏名、生年月日、性別、最終学歴、職歴、緊急連絡先、退職年月日、など

以下は「氏名・住所・電話番号等の新規申請もしくは変更申請」を処理する業務フローだ。

入社時だけでなく、氏名が変わった時、住所が変わった時、電話番号が変わった時に、逐次申請してもらう必要がある。秀逸な点は、必要に応じてワークフロー基盤の『社員マスター』を自動更新できる機能だ。そして自動更新される『社員マスター』は、たとえば「ワークフロー基盤にログインアカウントを持たない社員に通知メールが送られる仕組み」などを作る際に活用される

[社員個人情報の申請受付]

SLA （えすえるえー）、、、
Service Level Agreement （サービスレベルアグリーメント）、、、

クラウドサービス事業者や通信サービス事業者が自らの「サービス品質」を宣言し、実際のサービスが基準を下回った際には返金等が行われるという仕組みだ。この「クラウドファースト」な時代（？）、ＩＴ業界の方でなくても見聞きしたことがあるかも知れない。

以下のワークフローは、サービス事業者が「返金等」を行う業務プロセスだ。

一般の方には馴染みのない話だが、実はこの SLA という制度、、、多くの場合は「ユーザ側からの申請」を受けてから返金等のフローが始められる。まぁ「クレームを受けてから返金する制度」みたいな感じにも聞こえるが、、、現実はそうなっている。

（「鉄道輸送サービス」において、延着などの際に特急料金の払い戻しをする仕組みと同じ、とも言える。。。）

もっとも、、、どんなソフトウェアにも必ずバグが含まれている。世界中でセキュアと信じられている仕様にも、必ず弱点がある。それでいて、ユーザ側の利用スタイルも千差万別だ。ハマってしまう人もいれば、ハマらない人も出てくる。そんな状況下において「返金等を行う」のだから、仕方がない方式なのかもしれない。

[SLA申請対応フロー]