第528話：自動工程で PayPal ステータスの自動確認

請求の自動化

ワークフローシステム『Questetra』から、請求システムとしての『PayPal』をコントロールできれば、とても便利です。

たとえば『商品納入フロー』が完了した直後に「納入内容に合わせた PayPal 請求書」が自動発行されるような仕組みを作れば、「請求ミス」や「請求モレ」の発生を防ぐことができます。もし、現状が「紙の請求書」を郵送する請求業務なのであれば、切手代・印刷費・事務人件費を全てゼロにすることも可能です。

前回までの記事では、「PayPal 内に請求書を生成させる」や「PayPal 内に生成させた請求書を更にお客様にメール送信させる」といった指示が、PayPal に対して自動的に行われる仕組みを紹介しました。

• 第525話：自動工程から OAuth2 リクエストを送出させる方法
• 第527話：自動工程で PayPal Invoicing API を呼ぶ

更なる自動化

• PayPal に「PayPal請求書」を生成させる
• PayPal に「PayPal請求書」をメール送信させる

が自動化できたのなら、更に

• PayPal に対して、入金があったか確認する

についても自動化したいものです。（債権回収業務の効率化）

今回の記事では、自動工程を上手に組み立てて『入金確認フロー』を無人化することを考察してみます。

※ここでは自動工程の一種である「スクリプト工程」を使うため、プログラミング知識が必要となります

[エントリ受付システム-ペイパル請求～入金確認]

第527話：自動工程で PayPal Invoicing API を呼ぶ

請求システムとしての PayPal

「PayPal 請求書」は、とても便利です。

PayPal にログインして「相手のメールアドレス」と「販売した商品明細」をセットするだけで、誰でも簡単に請求書を送ることができます。「ちょっとした受託作業」や「特別な値引き」にも柔軟に対応できる数少ない決済手段と言えるでしょう。その簡単さは「むしろECサイトで買い物をする手続きの方が難しい」と思えてしまうくらいです。しかも、買い手から売り手に「クレジットカード番号」を渡す必要もありません。

しかし、何十枚も発行しなければならない、となれば流石に面倒です。（その「柔軟さ」がアダとなってしまいます）

全く同じ請求内容であれば一括して処理する機能もあるのですが、それぞれに微妙に内容が異なるのであれば一つ一つ請求情報をセットせざるをえません。ただ、手作業の繰り返しは、どうしてもミスを招きます。

請求書生成と送信の自動化

以前の記事(※)で『PayPal システムに対して「PayPal 請求書を生成せよ」というリクエストが自動送信される仕組み』を紹介しました。

※ 第525話：自動工程から OAuth2 リクエストを送出させる方法

今回の記事では、更に『「生成した PayPal 請求書を先方に送信せよ」というリクエストが自動送信される仕組み』について考えてみたいと思います。（プログラミング知識が必要となります）

[エントリ受付システム]

第526話：自動生成 PDF の「証明書発行日」を和暦で！（改善編）

和暦テキスト

日本では「西暦」ではなく「和暦」を使うケースが多くあります。

現在は『2017年』であるとともに『平成29年』でもあります。

すなわち「2017-03-13」といった日付型データも、印刷物やメール本文などにおいては、「平成29年3月13日」と表示されるべきケースが多くあります。およそ１年前の記事（※）では、自動工程である［スクリプト工程］を活用した和暦変換をご紹介しました。（クラウド型ワークフロー『Questetra BPM Suite』に流れる案件データの自動変換）

第467話：自動生成 PDF の「証明書発行日」を和暦表示する！ (2016-01-25)

スクリプト工程とサービス工程

ただ、クラウド型ワークフロー『Questetra BPM Suite』のバージョン11.1以降（2016-09-05）は、「サービス定義ファイル」（アドオンXML）によって任意の［サービス工程］を追加することが可能となっています。（サービス工程の Addon）

すなわち、和暦変換を行う［サービス工程］を利用すれば、（プログラミング知識を必要とする）、［スクリプト工程］を使う必要がありません。

[証明書発行フロー-和暦変換アドオン]

第525話：自動工程から OAuth2 リクエストを送出させる方法

サーバサイド JavaScript による自動化

前回記事（※）で『Questetra BPM Suite の「自動工程」では（簡単な数値演算だけでなく）「OAuth2 通信」も実装可能』と書きました。

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

そこで今回の記事では「具体的にどの様な外部サービスと OAuth2 通信が可能なのか」と「具体的にどの様なプログラミングが必要なのか」について、簡単にまとめてみたいと思います。（ワークフローシステム側からリクエストする視点）

そもそも OAuth2 通信とは

OAuth （おーおーす）とは「サーバへのリクエストを認可する仕組み」です。

参考） 『みんな知るべきクラウド技術「OAuth」ってナニ？』 (2014-01-27)

OAuth2 が2012年に登場して以来、Google Drive や Dropbox など多くの「リソース・サーバ」の API が『OAuth2 アクセス』に対応するようになっています。つまり、外部のシステムは「リソース・サーバ」に対して、様々な「参照リクエスト」や「更新リクエスト」を投げることが可能となっています。 (RFC6749/6750)

クラウド型ワークフローである『Questetra BPM Suite』では、業務プロセス定義の中に配置した自動工程に、この「外部のシステム」（OAuth2 クライアント）として振る舞わせることが可能です。すなわち、案件が自動工程（スクリプト工程／サービス工程）に到達する度に以下の様なリクエストが自動的に実行されるよう、設定することができます。

• a. Google Sheets API v4 (Sheet の読み書き)
• Spreadsheets 全体の一括更新メソッド で、シート末尾に複数データを追加する
• b. PayPal Invoicing API REST API 版 (請求書の生成送信)
• 下書き作成メソッド で、新しい請求書を生成する
• c. Dropbox API v1
• ファイル更新メソッド で、ファイルをアップロードする

• ※ スクリプト工程： 業務設計者がサーバサイド JavaScript をセットできる工程（HttpClientWrapper を使った通信も実装可能） M230
• ※ サービス工程（Addon）： スクリプト工程をパッケージ化した工程。業務設計者はコンフィグ設定のみ可能 M415 M416

参考）

• M230 業務データの複雑なデータ加工が自動実行されるように設定する（ECMAスクリプト）
• M415 業務プロセス定義で利用可能な自動工程を追加する
• M416 業務プロセス定義で利用可能な自動工程を自作する

アクセストークンの取得方法

このリクエスト通信には「アクセス・トークン」が必要になります。

「アクセス・トークン」とは、「リソースの所有者によって認可されたリクエストであることの証（あかし）」であり、その実態は数十文字から200文字程度の文字列です。ただ、アクセス・トークンの取得方式は「リソース・サーバ」によって異なります。主だった方法としては、

• A. 所有者に「許可ボタン」をクリックさせ、その後は自動取得する （Authorization Code Grant）
• B. 秘密クレデンシャルをセットしておき、その後は自動取得する （Client Credentials Grant）
• C. アクセストークンそのものをセットしてしまう （有効期限が無い Access Token が可能な場合など）

といった方式があるのですが、「リソース・サーバ」の管理するデータの種類や性格によって多岐に及びます。

注意） 接続先 API が実装可能な OAuth2 認可方式であっても、「HTTP ヘッダ」や「Content-Type フォーマット」に関する実装制約（Questetra側）により、自動通信を設定できない場合があります。

[請求書送信プロセス]

第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）

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

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

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

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

[出退勤報告フロー]

第522話：会社物品の「長期貸し出し」を管理したい

誰が持っているのか？

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

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

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

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

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

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

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

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