第581話：新入社員は勤怠報告でワークフローに慣れよう！

春、桜の季節、新生活の季節です。

今日から新年度、多くの会社で入社式が行われます。新入社員が配属されると、上司や先輩社員、あるいは人事担当者が会社生活のアレコレをレクチャーすることになります。その中にはきっと「勤務報告の仕方」も含まれているハズですね。

「働き方改革」や「裁量労働制」が話題となることが多い昨今、労働時間を適正に記録し、把握できるようにすることは非常に重要です（勤怠管理）。古くは紙への記入やタイムカードへの打刻にはじまり、ICカードでの打刻、専用の勤怠報告システムなどなど、様々な方法で出勤・退勤時刻の記録、報告が行われていますが、汎用なワークフローシステムを利用するのもひとつの方法です。

「出退勤報告フロー（勤怠報告フロー）」は、基本業務パックで紹介した「稟議フロー」「物品購入依頼フロー（調達購買フロー）」「立替金精算フロー」と合わせて、『ワークフローの４大アプリ』と呼ばれることもあります。クラウド型ワークフローを利用して、勤怠管理を行うことで、次のようなメリットがあります。

• テレワーク／リモートワークや外出の多いスタッフも、作業場所や外出先から記録できる
• 毎日の処理により、新しいメンバーもワークフローの操作に慣れることができる
• 組織に合わせて、継続的に、使いやすく改善できる（働き方改革にもつながる）

[出退勤報告フロー]

第552話：働き方改革は「アイデア募集」が大事

業務：カイゼンを社内募集

日本政府は本気で『働き方改革』をさせたいようだ。

たしかにウチの社内にも「誰も見ない書類の作成」や「非効率なヤリトリ」がある。「◇◇業務に〇〇クラウドの導入」とか「IoT活用」とか、、、具体的な「改善アイデア」を、もっと積極的に吸い上げる方法を考えたい。たとえば「中途社員」や「派遣社員さん」が給湯室や飲み会の席でグチってるだけ…なんて、ほんとモッタイナイ。

とは言え、、、社長が「業務プロセスを改善して生産性を高めよう！」と朝礼で叫んだくらいでは、具体的な「改善提案」は上がってこないだろうな。。。


そうだ。まずは、いわゆる「目安箱」のイメージで、『内部監査室』に「アイデア投稿」を受け付けてもらおう。

そして良いアイデアについて「現場ヒアリング工程」や「社長報告工程」に進める、、、そんなワークフローを運用してもらうのだ。（業務改善アイデア受付プロセス）

課題：社内なら誰でも投稿できるフォーム

しかし、ワークフロー基盤への「ログインID」は、全員が持っている訳ではない。

もしアイデア投稿に「ログインID」が必須なら、派遣社員さんやアルバイトさんが投稿できなくなる。（現場の非効率は、きっとアルバイトさんや派遣社員さんに押し付けられてるんだろうに。。。）


ん？、よく考えれば、ある程度の「匿名性」も担保したい。

たとえば「部長の不正リスクを下げる改善アイデア」といった大胆なアイデア投稿も推奨したいものだ。

う～む、「インターネットに完全オープンなWebフォーム」でアンケート募集する、というのも一手なのだろうが、やはりチョット気持ち悪い。。。（URLがサラされたり。。。ゼンゼン関係ない人が提案してきたり。。。）

[業務改善アイデア受付プロセス]

第524話：サーバサイド JavaScript による業務の自動化

プログラミング知識の活用

「スクリプト工程」とは、業務プロセス内にある「自動工程」の一種です。

たとえば、

• 上流工程で入力された『出勤時刻』と『帰宅時刻』を参照して、
• 自動的に『勤務時間』（ {帰宅時刻} - {出勤時刻} ）を算出する

といった「プログラム処理」を自動的に実行させるための工程です。

逆に言えば、その様なスクリプト工程を日報フローに組み込めばすれば、社員に『勤務時間』を記入してもらう必要が無くなります。

何が出来るのか？

ワークフロー基盤側で行われる自動処理は、いわゆる『サーバサイド処理』です。

つまり、業務プロセスを流れてきた案件が「スクリプト工程」に到達すれば、自動的にデータが参照され、また書き換えられます。全ての処理は人間の関知しないところで実行されます。

そこにセットされるプログラムコードは

• 「業務データの参照」に始まり、
• 「様々な演算処理」を経て、
• 「業務データの書き換え」で終わる

といった構成になるでしょう。

どの様な「演算」が可能なのか？

たとえばクラウド型ワークフロー製品である『Questetra BPM Suite』の場合、「サーバサイド JavaScript (ECMA Script) をセットできる」(※)という仕様となっています。そして、以下のような演算が可能です。

• 基本的な数値データ演算（四則演算、平方根、指数、四捨五入、乱数…）
• 基本的な文字列データ操作（結合、分割、整形、抜き出し、置換、検索…）
• 基本的な日時データ操作（加算、減算、経過計算、曜日判定、和暦変換…）
• JSON データの生成や解析
• XML データの生成や解析
• HTTPリクエストの送信（データGET、データPOST、OAuth2通信、Basic認証…）
• SMTPリクエストの送信（メール送信、添付ファイル生成、文字コード変換…）

※ Rhino エンジンで処理できる Java メソッドや Questetra 拡張メソッドも利用できます［R2300］
※ 詳細情報はコチラやコチラ

[出退勤報告フロー-時分表示]

第523話：クラウドを用いた労働時間の適正な把握

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

長時間労働の是正

日本政府では今、「働き過ぎによる健康被害」が活発に議論されています。

この議論の盛り上がりは、大手広告代理店での「新入社員過労自殺」（2015年）がキッカケと言っても過言ではありません。そして、向こう１・２年の内には『どの様な雇用契約下であったとしても月平均の残業は最大60時間まで』といった新しいルールが追加されると予想されています。

労働時間が慢性的に月220時間を超えている企業や官公庁では、「業務プロセスの抜本的な見直し」や「みなし労働時間制の適用検討」など、様々な対応が必要となってくると言えます。

参考）日本の労働基準法

• 1週間について40時間を超えて労働させてはならない
• 1日について8時間を超えて労働させてはならない

暗黙の指示による学習も労働時間

確かに、純粋な心で「学習や経験のためにもっと働きたい！」（会社に居たい！）と考えるヒトが居るのも事実です。

しかしながら今日では『業務に必要な学習』も労働時間と定義されてしまいます。『自己啓発』や『私的情報収集』という報告をさせることで労働時間を少なく見せかけるケースが後を絶たなかった現実を考えれば、これは「仕方のないガイドライン」と言えるかも知れません。

※ 労働時間の適正な把握のために使用者が講ずべき措置に関するガイドライン（厚生労働省：2017-01-20）

労働時間についてのチーム内での共通認識

労働時間とはそもそも『客観的に見て使用者の指揮命令下に置かれていると評価される時間』と定義されます。

しかし上述の様な状況をふまえて、「具体的に労働時間をどの様に計測すべきか」について、改めて各社各部署における共通認識を議論しておくことは、とても有効です。

たとえば、自宅での「資料作成」だけでなく「技術動向の学習」なども労働時間として計測されるべきでしょう。しかし一方で、最新のセキュリティ動向を確認することが求められるサーバ管理者が「ネット情報の確認」や「メルマガの購読」までも労働時間に加算して行けば、起きている時間全てが労働時間にもなりかねません。

[出退勤報告フロー]

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

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

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

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


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

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

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

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

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

プロセス分割で、データ閲覧権限を制御しやすく！

内部監査室や社外取締役が、最大4人の社員に対してアンケート調査を行う。
普通に考えれば、

1. 上流に「調査をセットする工程」を作り、
2. 下流には、４つに分流させた上で４つの「回答工程」を作る、

ことになる。もちろん、各自が記入する回答欄は別々に作り互いに見えないようにすることで、他の人の意見に惑わされることなく回答できるようにする。。。

この業務フローについては、すでに過去３週に渡ってアレコレ考察してきた。

• 2015-05-18: 真の進捗率は、プロジェクト関係者に聞くしかない！
• 2015-05-25: スクリプト工程、ご利用は計画的に！ （平均値の自動算出）
• 2015-06-01: 締切時刻が来れば、その処理が「スキップ」される工程

しかしこれらのワークフロー、、、回答内容こそ見えないものの、「他の調査対象は誰か？」は分かってしまう。それぞれの社員が独立して回答すべきケースにおいて…、あるいは調査を行っていること自体を隠蔽（いんぺい）したいケースにおいては、使いづらい。

※ 調査を４回に分けて行えば良い、ともいう話もあるが、色々メンドウ。。。

以下は、アンケート回答工程を別の業務プロセスとして分離することで、「他の回答者」を隠蔽している。

[進捗報告プロセス(親プロセス)]

[進捗報告プロセス(子プロセス)]

締切時刻が来れば、その処理が「スキップ」される工程

「業務プロセス管理」などと説明されると、少し分かりにくい、、、
むしろ、「ルーティーン・プラットフォーム」と説明された方がシックリ来る、、、

という人は少なくない（一般従業員の視点）。説明方法はさておき、、、クラウド上の『マイタスク』(ToDo)を見れば、いま自分が為すべき事がわかるというのは本当に有り難い。「いつでも」や「どこからでも」のキーワードは、リモートワークの視点でも重要だろう。

しかし、その時、「締切時刻を過ぎてしまったタスク(ToDo)」が、大量に残っているとテンションが下がる。

以下は、そのような事態が発生しないようにデザインされたルーティーン（業務プロセス）だ。「調査に対して回答する」というタスク(ToDo)は、『回答締切時刻』になれば自動的に消滅する。

[進捗報告プロセス-締切設定]

スクリプト工程、ご利用は計画的に！ （平均値の自動算出）

最大４人に対して、「プロジェクト進捗度」（0-100）を回答してもらう。

毎週あちこちの調査をおこなう内部監査室にしてみれば、「進捗度の平均値」くらい自動算出されてればイイのに、、、と思ってしまう。

以下のワークフローには、報告者（１～４人）の入力が全員完了した時点で、自動的に「平均値」が算出される仕組み（スクリプト工程）が組み込まれている。（更には、その平均進捗度が90%を超えている場合に、自動的に関係役員宛メールが送信される仕組みにもなっている。）

このような「社内状況把握の自動化」は、業務の効率化のみならず、品質管理体制の強化等にも寄与するだろう。（受託事業、建設業、など）

[進捗報告プロセス-自動計算]

真の進捗率は、プロジェクト関係者に聞くしかない！

「工事進行基準」の会計処理には、"不正" の影が付きまとう。（東芝さん、ダイジョウブ？）

なんせ「進捗」に合わせて売上と原価を計上するのだから、会社は「真の進捗率」を把握し続けなければならない。もちろん、当初見積もり通りにプロジェクトが進んでいる場合は、「発生原価」と「当初見積」から導かれる「発生原価から算出された工事進捗」でよい。しかし、ゼネコン会社にせよ、SI会社にせよ、、、全てのプロジェクトが目論見通りには行くハズがない！

実際、、、進捗が100％になっても、150％になっても(!)、200％になっても(!!)、その工事が終わる気配がない "泥沼プロジェクト" は、必ず発生してしまうのだ。泥沼の発覚後に、取締役会がどれほど議論を尽くしても、現実の進捗は変わらない。

以下の業務プロセスは、非常にシンプルな「進捗報告プロセス」だ。

最大のポイントは「主観での工事進捗」を、複数人に報告させている点にある。この業務プロセス例では、最大４名のプロジェクト関係者が「報告作業」を行う仕組みだ。しかし、業務の流れとしては、経理部門（あるいは監査部門）が報告者を指名するところに始まる。したがって、「進捗 "調査" プロセス」と言ってもよい。

もし、プロジェクト関係者の多くが、「スケジュールは残り半分。でもマダ10％程度の進捗。」と思っているようならば、早い段階で会計上の修正を行う。それだけの話だ。

[進捗報告プロセス]

ワークフローに流れる業務データ、改竄せざるを得ない時とは

1. 第三者の生命財産をおびやかす可能性がある情報
2. 業務記録として保存必要のない個人情報
3. 犯行予告など法令に違反する可能性のある記述
4. わいせつなど公序良俗に反する記述

といった情報が業務データに含まれてしまっている場合、どうすべきか？

あまり考えたくない話ではあるが、"目安箱フロー" や "内部告発処理" といった匿名性を高めた業務フローなど、業務によっては良くある話だ。ここでは、特権ユーザによる [データ編集] について考えたい。

そもそも業務データは、承認者のチェックを受けたり、差し戻し工程で修正されたり、、、最終工程に至るまでに何度も編集されるモノだ。案件が [終了イベント] に到達する頃には、会社の記録として仕上がった業務データになっているだろう。そして、その後は誰も編集しない。
この完成したデータについて多くのワークフロー製品では、（クラウド型ワークフロー Questetra においても同様）、特権ユーザですらデータ改変できない仕様になっている。もし仮に "後で編集ができてしまう" となれば、それはデータ改竄を許す仕組みであり "データ信頼性" あるいは "監査証跡" (コンプライアンス) の視点で問題になる。過去のデータに誤りを見つかけ場合には、新しい案件として然るべき手続をやりなおすべきだ。 (集計上のノイズになるなら、元のデータは [削除] する)

以下のワークフローは、 "Google アラート" (や "Analytics アラート" など) を自動的に取り込み、インターネット上の新着コンテンツ情報等を検知し、必要なリアクションを取ると言う業務だ。機械的に収集される情報であり、多くの場合は "情報共有不要" を選んで終了させる事になる。しかし、中にはその一部を [データ編集] すべきデータが含まれてしまう案件もある。この例は、特権ユーザに対して [データ編集] できる猶予を与えている所が、非常に地味な配慮ではあるが、秀逸だ。

[インターネットネット監視業務]

「取締役会議事録を電子化する」と言う ≪大変革≫ の意義

【会社の意思】は取締役会で決まる。

多くの場合、「議論の深まり」の中で決まっていく。と言うか、典型的なパターンは社長が取締役達を説得し、「あーだ、こーだ」と事前のヤリトリがあった後、取締役会の場で決まる。当然ながら【取締役会議事録】には、『慎重審議の結果、提案は全員異議なく可決』とのみ記録される。込み入ったヤリトリや各取締役の当初意見などは、公式記録に残らない。

しかし【最も大切な情報】は、決まるまでの「過程」だ。
未来の取締役達が読みたくなる情報は、決まるまでの「過程」だ。

以下のワークフローは、各取締役が独立して意見を記録できるシステムだ。まず『-2.反対』『-1.どちらかと言えば反対』『0.分からない/判断保留』『+1.どちらかと言えば賛成』『+2.賛成』を選び、その上で、自分の意見を自由に記録する。とかく形式主義に陥りやすい『議事録』とは別に運用される。つまり、会議の前に意見や考えを表明しておくため、あるいは会議の後に議論後の意見や議論感想を記録しておくために活用される。単なる「電子採決システム」とは違う。

[事案に対する意見表明フロー]

社外からの通報、どう対応しているの？ （回答業務フロー）

「業務プロセスを改善せねば・・・」

そう考える経営者や管理職者は多い。しかし「実践にうつす」となると、そう簡単な話ではない。『ウチの課長は、なぜ業務フロー図を書かないのか？』の記事の中にもあるが、まずもって「業務フロー図」を書くのがムツカシイのだ。 （う～む）

とは言え『社外の方』に影響のある様な業務であれば、そうも言ってられない。その手順やルールを日々カイゼンしたい。例えば「個人情報 苦情相談窓口」への相談案件があった時、いつ誰がどの様な対応を行ったのか（行っているのか）が把握できない様では、やっぱりマズイ。

以下のワークフロー定義は、Web サイトで受け付けた「外部からの相談や通報」に対し、必要な対応を行う業務フローを表している。
この定義（プロセスモデル）をインポートして稼働させれば、全ての問い合わせが自動的に記録され、権限者はその対応進捗をモニタリングできる様になる。秀逸な工夫は、相談者／通報者が「ファイルを添付できる」所だ。つまり、スマホで撮影した画像ファイルも簡単に添付する事ができるのだ。

＃個人的には「街路灯(街灯)の球切れ」を通報するシステムも、「電話受付(9:00-17:00)」ではなく、Web サイトで受け付けてもらいたい。（気付くの、夜だし）

[個人情報 苦情相談対応フロー]

クラウド型ワークフローの製品比較方法

「よし、Google Apps の導入は完了した！」
「さて、Google Apps アカウントでログインできるワークフローを検証してみたい！」

近年、法人向け業務システムは確実に「クラウド・コンピューティング化」している。
平たく言えば『使った分だけ料金を払う仕組み』に移行しているのだ。ITも、水道、ガス、電気と同じ歴史を歩んでいる。特筆すべきは SaaS 製品の普及と多様化だ。ソフト購入の手間やバージョンアップの手間を大幅に削減した。実に便利な世の中になったものだ。

• クラウド型グループウェア(メール+カレンダ+...)/オフィススイート(ワープロ+表計算+...)： Google Apps、Microsoft Office 365、IBM SmarterCloud （旧 LotusLive）、、、
• クラウド型顧客管理[CRM]： Salesforce、Microsoft Dynamics CRM、Synergy!、ZOHO CRM、、、
• クラウド型経営資源計画[ERP]： SAP、Oracle、NetSuite、、、

「よし、ワークフローのテスト環境はできた！」
「さて、実際の業務データ(仕事)を流し、ワークフローを評価してみよう！」

良くあるテストとして、『無意味な業務フロー』に『無意味なテストデータ』を流す。しかし、それでは現実感（リアリティ）が湧かない。実のある評価が進まないのだ。たとえば「ココには注意書きが必要だな」など、実運用時に必要となる機能を試す機会を失ってしまう。

以下に紹介する業務テンプレート『目安箱フロー』は、(1)あまり存在しない業務フロー（業務重複にならないフロー）で、にもかかわらず、(2)リアリティが湧く業務フローで、ひょっとすると、(3)本運用の際にも稼働させ続けてもイイかもしれない、そんな業務フローだ。徳川吉宗（暴れん坊将軍）の『小石川養生所』や『町火消』の様に、新事業のヒントが上申されるかもしれない!!

[目安箱フロー]

発表すべき情報をクラウド型ワークフローで管理する

「新サービスの発表」、「障害の発生」、「紛争の発生」・・・。
『正確さ』と『迅速さ』の両方が求められる情報開示業務はタイヘンだ。IT端末が進化したイマドキは、投資家に限らず、顧客・仕入れ先・従業員…と全てのステークホルダーへの"適時開示"が欠かせない。言い換えれば、事実を素早く広く伝えられなければ、企業としての信頼を得られない。更に言えば、「組織の大小」や「上場非上場」を問わない。あるいは「民間組織か行政組織か」の区分も関係ない。現実、ホームページの Information なり News なりのコンテンツが滅多に更新されない組織は、支持を得られない。

この手の『情報』は伝統的に、[1] (内発的な)決定事実、[2] (外発的な)発生事実、[3] 決算、に区分される。
いずれの「情報開示プロセス」も、社内の情報を如何に収集できるかがキモになる。それらの情報は「情報開示プロセス」の中で淘汰され、発表の要否・発表内容・発表日時が検討され、最終的にその一部が発表されるに至るのだろう。

「業務プロセス管理」のセオリーとして、情報開示プロセスの整備は、やはり『[1] 内発的な決定事実』から始めるのが良い。

[情報開示ワークフロー]