長時間労働の是正

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

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

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

参考)日本の労働基準法
  • 1週間について40時間を超えて労働させてはならない
  • 1日について8時間を超えて労働させてはならない

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

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

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

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

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

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

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

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

[出退勤報告フロー]

誰が持っているのか?

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

会社にある備品は積極的に「活用」してもらいたいものです。しかしその「管理」となると非常に面倒です。たとえば「Excel や Spreadsheet に記録する」という管理方法では、遅かれ早かれ形骸化してしまうことでしょう。
  • 更新がメンドウ。
  • 誰が更新すべきか分からない。
  • 前回いつ更新されたのかが分からない。
  • そもそも、管理ファイルが何処にあるか分からない (+_+)
  • アレレ、、管理ファイルが沢山あるぞ。。。 (-_-;)
特に「長期貸出」が前提となる場合は絶望的です。結果として、誰が持っているのか?、本当に持っているのか?、本質的なことすら管理できなくなります。

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

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

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

[貸し出し管理プロセス]
過去3回の記事
では、「業務プロセス内」の自動化について
  • A. 業務プロセス内の「次の工程」に自動的に進むようにする
  • B. 業務プロセス内の「とある工程」が無人で処理されるようにする
という2視点の違いを解説するとともに、それぞれの設定方法について述べました。


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


業務プロセス同士の接続

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

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

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

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

◇ 業務プロセスの列挙

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

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

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

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

<APQCによるプロセス分類手法>
  1. 戦略立案プロセス (Develop Vision and Strategy)
  2. 製品開発プロセス (Develop and Manage Products and Services)
  3. 製品販売プロセス (Market and Sell Products and Services)
  4. 製品納入プロセス (Deliver Products and Services)
  5. 顧客支援プロセス (Manage Customer Service)
  6. 人材開発プロセス (Develop and Manage Human Capital)
  7. IT管理プロセス (Manage Information Technology)
  8. 財務管理プロセス (Manage Financial Resources)
  9. 設備管理プロセス (Acquire, Construct, and Manage Assets)
  10. リスク管理プロセス (Manage Enterprise Risk, Compliance, and Resiliency)
  11. 渉外関係管理プロセス (Manage External Relationships)
  12. 遂行能力開発プロセス (Develop and Manage Business Capabilities)

[見積承認プロセス-受注報告を起動]

[受注報告プロセス-見積承認から起動]

前々回記事『第518話:業務プロセスの自動化とは?(その1)』では、
  • [A] 工程間における案件情報の受け渡しを自動化する
  • [B] とある工程における処理を自動化する
という業務プロセスの自動化についての2つの視点について述べました。

また、前回の記事『第519話:業務プロセスの自動化とは?(その2)』では、『[A] 受け渡しの自動化』が適用可能な範囲と実現方法について述べました。


今回の記事では『[B] 処理の自動化』が適用可能な範囲と実現方法について、整理してみたいと思います。


どの様な「処理」が自動化できるのか

◇ 完全な自動化(自動工程)

『[A] 受け渡しの自動化』が「とある工程から次の工程への案件情報受け渡し」をコンピュータに任せてしまう発想だったのと同様に、『[B] 処理の自動化』は「とある工程内の作業」をコンピュータに任せてしまいます。

たとえば「見積書の作成承認」のような人間依存度の高い業務プロセスにあったとしても、
  • 見積書 PDF ファイルを作成する
  • ファイルを添付してメール送信する
  • 見積概要を社内ソーシャルに投稿する
といった工程であれば、完全にコンピュータに任せてしまうことが可能です。

※ ちなみに『[A] 受け渡しの自動化』と対比させる必要が無い場合には、(『自動化』という言葉を使わず)、『業務プロセスの一部工程を「無人化」する』といった表現の方が分かりやすいかも知れません。


◇ 部分的な自動化

一方で、完全に任せてしまうわけではない工程もあります。

たとえば「見積書の作成承認」という業務プロセスにある「見積案を作成する」という工程で言えば、
  • 見積総額を計算する
  • 消費税額を計算する
といった支援機能は業務の省力化に貢献します。しかし、このケースは「見積書の作成」という工程が無人化できている訳ではなく、何らかの人間入力(ヒューマンインターフェース)が必要です。したがって、この様な工程は「ヒューマン工程」(人間工程)に分類すべきだと言えるでしょう。

[見積書の作成承認プロセス]

前回記事『第518話:業務プロセスの自動化とは?(その1)』では、
  • [A] 工程間における案件情報の受け渡しを自動化する
  • [B] とある工程における処理を自動化する
という業務プロセスの自動化についての2つの視点について述べました。

今回の記事では『[A] 受け渡しの自動化』の適用範囲について、整理してみたいと思います。
※『[B] 処理の自動化』については次回記事で整理します。


どの様な「受け渡し」を自動化できるのか

◇ フローの定義方法

日常業務において「案件情報」がスムーズに受け渡しされるようになるには、(当然ながら)、「業務の流れ」が定義されていなければなりません。

案件情報を「紙」や「カンバン」で管理していた時代であれば、「業務の流れ」は業務マニュアルなどの自然言語(文章)で記述しておけば良かったと言えます。しかし、コンピュータに回付してもらうためには「コンピュータに理解できる方法」で「業務の流れ」を定義する必要があります。

言い換えれば「コンピュータに理解させられるフロー」こそが『[A] 受け渡しの自動化』の適用可能範囲と言えるでしょう。

[受注報告プロセス-役員通知]

そもそも「業務プロセス」とは何か?

業務プロセスとは「いくつかの工程」を並べたものです。

たとえば、多くの企業で日常的に発生する「受注報告プロセス」でいえば、
  • [1] 営業部社員:受注内容を登録する
  • [2] 営業リーダ:受注内容を確認する
  • [3] 営業部部長:受注内容を承認する
といった「工程」で形成されます。

自動化、2つの視点

そして今日、「生産性向上」のキーワードのもと、話題にあがることが多くなった「業務プロセスの自動化」は、
  • [A] 工程間における案件情報の受け渡しを自動化する
  • [B] とある工程における処理を自動化する
のいずれかの意味で、あるいは両方の意味で議論されています。

「A:受け渡しの自動化」とは?

第1の視点は「案件情報の受け渡しを自動的に行いたい」というニーズです。

「自動」の反対語は「手動」や「人手」であり、つまるところ「人間でない何か」に受け渡しを担ってもらうと言う話になります。今日においてはやはり、「コンピュータとインターネットによる自動化」が基本となります。

「ワークフロー・システム」と呼ばれる製品にとっては、必要条件ともいえる機能でしょう。そして、その様な自動化環境では、
  • [1]の工程のアウトプットが入力されれば[2]の工程に、
  • [2]の工程のアウトプットが入力されれば[3]の工程に、
自動的に伝達されるようになります。

もちろん「あらかじめ業務フローを設定しておく必要があります。そしてまた、現実的には、個々の案件情報が「デジタルデータ」で管理されていること(ペーパレス)が前提となります。

ワークフローによる「受け渡し」

そして今日では、フローの分岐やループに対応する製品が数多く存在します。

たとえば、以下の業務プロセス定義(業務フローの設定)は、
  • [1] 営業部社員:受注内容を登録する
  • [1x] 営業部社員:(差し戻し受け)改めて受注内容を登録する
  • [2] 営業リーダ:受注内容を確認する
  • [3] 営業部部長:受注内容を承認する
  • [4] 営業部部長:100万円超案件の内容を役員報告する
を表現しています。(国際標準表記法 BPMN: Business Process Model and Notation による)

[受注報告プロセス]

外部トリガーによるワークフロー開始

前回の記事『第516話:ワークフローを「メール」で起動しておく方法』では、「メール着信」をトリガーとするワークフローについて書きました。きっと『メール以外にも「ワークフローを開始する方法」はありますか?』という質問をいただくことになるでしょう。(まだ頂いておりませんが…)

はい、あります!

クラウド型ワークフロー『Questetra BPM Suite』の場合、提供されている API は以下のような体系になっています。この中にある『B1.プロセスの開始』は HTTP/WebForm/Email のすべてに対応しています。つまり「メール着信」に限らず、「Webフォーム入力」や「HTTPリクエストの受信」をトリガーにしたワークフローを設計することが可能です。
  • A. ワークフローシステムが常に提供する『ソフト開発 API』 (OAuth2/Basic)
    • A1. ユーザの操作 (ワークフローAPIs)
    • A2. システム管理者の操作 (システム設定APIs)
  • B. 各業務アプリが提供する『プロセスモデル接続 API』
    • B1. プロセスの開始 (メッセージ開始イベント) (HTTP/WebForm/Email)
    • B2. プロセス途中での待ち受け (メッセージ受信中間イベント) (HTTP)
    • B3. プロセス途中で外部発信 (メッセージ送信中間イベント/自動工程) (HTTP/Email)

ワークフローを開始させるワークフロー

少し「応用編」になるのですが、、、『B3. プロセス途中で外部発信』という機能もあるので、
  1. Xプロセスで「HTTPリクエスト」が『送信』されるように設定し、、
  2. Yプロセスが「HTTPリクエスト」の『受信』で開始されるように設定しておけば、
XYワークフロー間の連携も可能となります。つまり、
といったことが実現できます。


さて、、、今回の記事では更に踏み込んで、CSVデータを使った「複数案件の一括開始」について考えてみたいと思います。

[電話アンケート・プロセスの一括呼び出し(親プロセス)]

[電話アンケート・プロセス(子プロセス)]