第473話：今月の成果ポイントは５点！（毎月人事評価）

会社組織にとって「人事評価」は避けて通れない。

しかし「人事評価プロセス」（人事考課プロセス）は会社によって様々だ。たとえば、

• アウトプットに重きを置くのか？
• スキルに重きを置くのか？

などの『評価軸』は、各社それぞれのアイデンティティに関わる問題だ。つまり「他社の例」はほとんど参考にならない。

• [自己成果] 社内ルールに従って、十分な質と量のアウトプットを出している
• [組織効率] より良い社内ルールを提案し、社内ルールの改善に貢献している
• [自己能力] 情報技術や社会システムに関する最新知識を、常に吸収している
• [他者貢献] 情報技術や社会システムに関する最新知識を、社内発信している

更に言えば

• 絶対評価にする
• 相対評価にする
• 一次評価は絶対評価で、二次評価は相対評価にする

といった『基本的な考え方』も企業によってそれぞれ違うだろう。また『評価の実施頻度や報酬反映の仕組み』においても、会社規模や事業内容によって大きく異なる。

• 一年ごとに実施
• 三か月ごとに実施
• 一か月ごとに実施

以下のワークフローは、毎月人事評価を行う例だ。社員は毎月、それぞれの評価軸に対して０～５点の自己評価（相対評価）を行う。それを受けて、部長や役員も同じように、全員分の評価（相対評価）を行う。

[人事評価プロセス]

第472話：業務システムでインフルの兆候をつかむ？

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

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

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

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

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

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

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

[出退勤報告フロー]

第471話：オレの申請に「決裁」は要らぬ！ （by 部長）

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

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

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

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

[稟議フロー]

第470話：チームリーダーの評価を「無記名投票」で！

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

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

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


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

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

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

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

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

第469話：住所変更届（社員マスターの自動更新付）

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

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

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

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

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

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

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

第468話：SLA のサービスクレジットを発行する

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

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


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

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

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

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

[SLA申請対応フロー]

第467話：自動生成 PDF の「証明書発行日」を和暦表示する

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

「日付は、和暦で！」

日本において「年の表記」は複雑だ。つまり、行政や学校では「2016年」とは言わない。あくまでも今年は「平成28年」なのだ。『住民票』であれ『戸籍謄本』であれ、ハタマタ『卒業証書』であれ、、、少しでも重みある書類には「和暦」が記入される。


しかし、現実、、、「ことしは平成28年！」と即答できる日本人は少ない。。。
とは言え、この「数十年に一度、元年（１年）にリセットするという仕組み」は、もう1400年以上も続いている。時の政府の一存で止めてしまえるものでもないのだ。。。（そして、現在の天皇が亡くなった日には、また新しい『元号』が発表されるハズだ）

以下のワークフローは『在職証明書』の発行フローだ。

上流工程で在職者の「氏名」や「生年月日」が入力され、フロー途中の［自動工程］で証明書 PDF が自動生成される仕組みとなっている。特筆すべきは「生年月日」や「証明書発行日」などの日付データが自動的に和暦に変換される点だ。たとえば『卒業証明書』や『保護者だより』のなどの発行フロー等にも転用できるだろう。

[証明書発行フロー]