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

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

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

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

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

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

  • 季節型インフルエンザ、風疹、水疱瘡などの感染症に、自身が感染したかもしれない (0/1/2/3)
  • 季節型インフルエンザ、風疹、水疱瘡などの感染症に、同居家族が感染したかもしれない (0/1/2/3)
    • 0: 感染の可能性はほぼ無い
    • 1: 症状が出始めた気がする
    • 2: 症状が強く出始めたと思う
    • 3: 感染症の検査で陽性がでた

[出退勤報告フロー]

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

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

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

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

[稟議フロー]
上司を評価する「無記名投票」をしたい!

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

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


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

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

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

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

[上司評価の投票(無記名投票)]

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

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

そして「Excel ファイル」での社員マスター管理は、すでに限界だ。。。
  • 基本情報(社員マスタ-):社員番号、メールアドレス、通称氏名、入社年月日
  • 詳細情報(法定管理項目):戸籍氏名、生年月日、性別、最終学歴、職歴、緊急連絡先、退職年月日、など

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

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

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

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

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


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

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

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

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

[SLA申請対応フロー]