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

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

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

たとえば、

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

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

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

何が出来るのか？

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

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

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

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

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

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

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

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

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

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

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

長時間労働の是正

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

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

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

参考）日本の労働基準法

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

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

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

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

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

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

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

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

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

[出退勤報告フロー]

誰が持っているのか？

レーザーポインター、モバイルバッテリー、モバイルプロジェクター。。。
法人クレジットカード、新幹線の予約カード、PCソフトのライセンス。。。

会社にある備品は積極的に「活用」してもらいたいものです。しかしその「管理」となると非常に面倒です。たとえば「Excel や Spreadsheet に記録する」という管理方法では、遅かれ早かれ形骸化してしまうことでしょう。

更新がメンドウ。
誰が更新すべきか分からない。
前回いつ更新されたのかが分からない。
そもそも、管理ファイルが何処にあるか分からない (+_+)
アレレ、、管理ファイルが沢山あるぞ。。。 (-_-;)

特に「長期貸出」が前提となる場合は絶望的です。結果として、誰が持っているのか？、本当に持っているのか？、本質的なことすら管理できなくなります。

まずは「ユルイ管理」から

以下のワークフロー定義では、物品の貸し出しや返却を記録する仕組みです。日本の行政機関の用語で言えば「供用」や「返納」といった「出納」を記録するシステムと言えます。

業務フロー図を見て頂ければわかるように、何も複雑なことはしていません。物品の使用者が「長期貸出を希望する物品」についてエントリーし、物品管理者（出納官）が「貸し出した内容」について記録するだけの仕組みです。この例では、貸出期間について、あえて日付（例： 2017-02-13）ではなく、年月（例： 2017-02）で管理しているところがユニークです。「短期貸出は申請不要」を演出している様にも見えます。

[貸し出し管理プロセス]

過去3回の記事

では、「業務プロセス内」の自動化について

A. 業務プロセス内の「次の工程」に自動的に進むようにする
B. 業務プロセス内の「とある工程」が無人で処理されるようにする

という２視点の違いを解説するとともに、それぞれの設定方法について述べました。

今回（最終回）の記事では「業務プロセス間」の自動化について、整理してみたいと思います。

業務プロセス同士の接続

◇ 業務プロセスの位置づけ

これまでは『見積書承認プロセス』や『受注報告プロセス』といった「個々の業務プロセス」にフォーカスして議論しました。しかし、全社視点での自動化（生産性の向上）を推進するには「業務プロセス同士の接続性」についても考えなければなりません。

このようなステージでは、あらかじめ社内の「業務プロセス」を可能な限り列挙しておくことが改善議論の近道となります。

つまり、全体俯瞰によって各業務プロセスの位置づけや依存関係が明らかになり、また各業務プロセスのあるべき「インプット」と「アウトプット」が明確になります。伴って、業務プロセスの責任者（プロセスオーナー）が目指すべき運用方法や改善方向も明らかになるでしょう。

◇ 業務プロセスの列挙

では社内には、どのような「業務プロセス」があるのでしょうか？

事業内容や組織規模によって大きく異なるのは言うまでもありません。同時に「社内全ての業務詳細を把握できている人は居ない」と考えるべきでしょう。つまり「業務プロセスの列挙」は誰が担当するにしても、ある程度の現場ヒアリングが必要となります。

そして、調査結果の列挙の際は、全体俯瞰しやすいようにカテゴリ分類して列挙するのが重要と言えます。

方法論としては、会社の損益を計算する際の「製造原価」「販売費」および「一般管理費」といった費用区分や、研究機関のプロセス分類法を活用して、社内の業務プロセスをマッピングするのが現実的となります。

＜APQCによるプロセス分類手法＞