第534話：日付入力ミスを防ぐ工夫

入力ミスが多い？

ワークフロー・システムでは、ヒューマン工程における「入力ミス」が避けられません。

たとえば「請求書発行日」と「入金期限」の２つの日付を入力する必要があるワークフロー工程であれば、

• データ複製のまま１年前の日付を入力してしまう
• 請求書発行日と入金期限を逆に入力してしまう

といったミスが発生しがちです。（折々に、実際の発生率を計算してみるのも良いでしょう）

もちろんミスをした担当者が不注意なのかも知れません。あるいは、集中力を高めれば、その瞬間だけはミスなく入力できるかも知れません。しかし、100件・1000件と「ミスなし」を続けることは、むしろ困難と言わざるを得ないでしょう。もし入力項目数が多い業務なら、5件・10件でもミスなく入力することですら難しいかも知れません。

初期値を設定する

システム機能として「初期値の設定」が可能なら積極的に利用したい所です。

クラウド型ワークフロー『Questetra BPM Suite』の場合、日付データ項目の初期値として「今日から3日後」や「来月の末日」を設定できます。「データ複製」のケースには無力ですが、新しい案件データを業務プロセスに流す場合には、とても有効な方法です。

＜設定画面＞

[日付入力フォームのテスト]

第533話：数値入力ミスを防ぐ工夫

入力ミスが多い？

ワークフロー・システムでは、ヒューマン工程における「入力ミス」が避けられません。

たとえば「単価」と「数量」の２つの数値を入力する必要があるワークフロー工程であれば、

• 12000 が 1200 と一桁が足りない数値を入力してしまう
• 金額を入力すべき場所に数量を入力してしまう

といったミスが発生しがちです。（折々に、実際の発生率を計算してみるのも良いでしょう）

もちろんミスをした担当者が不注意なのかも知れません。あるいは、集中力を高めれば、その瞬間だけはミスなく入力できるかも知れません。しかし、100件・1000件と「ミスなし」を続けることは、むしろ困難と言わざるを得ないでしょう。もし入力項目数が多い業務なら、5件・10件でもミスなく入力することですら難しいかも知れません。

最大値・最小値を設定する

システム機能として「入力値の制限」が可能なら積極的に利用したい所です。

クラウド型ワークフロー『Questetra BPM Suite』の場合、数値データ項目には「最大値」と「最小値」を設定できます。もし「単価」の入力値を「10,000円～100,000円」と制限しておけば、その入力制限によって「1200円」という誤入力の発生率をゼロにすることが可能です。

＜設定画面＞

＜動画：ミス発生の様子＞

[数値入力フォームのテスト]

第532話：他システムへの記録、急がば回れ（改善編）

プロセス見直しの季節

4月。

日本では「新しい１年が始まる月」です。

国の会計、地方自治体の会計、学校の新学年などが、4月に始まるだけでなく、新社会人の入社式も4月に一斉に行われます。（約2割の日本企業は4月に会計年度を始めます）

日本において4月は、「業務プロセスの改善モチベーションが上がる月」あるいは「業務プロセス改善にはモッテコイの月」と言えるでしょう。

そして当ブログを運営している Questetra 社においても、4月は業務プロセスの更新量（ワークフロー・アプリのバージョンアップ回数）が増えます。

あえて所要時間を伸ばす？

今回紹介する業務プロセスは、「全工程の所要時間を伸ばす」という少し変わった改善例です。

普段の業務改善は、日頃の業務中に感じた「不満」や「課題」に対して『フローの改善』や『データ入力画面の改善』を考えるのが常です。

• 工程の自動化
• ダブルチェック工程の追加
• ガイド文の追加
• 便利ボタンの設置

そして、その多くの場合、「トータル所要時間を少しでも早める方向性」を模索します。


しかし、年度の区切りである4月においては、「全体集計作業を通じて感じた非効率」について対処したくなる場合もあります。この業務プロセス（ワークフロー・アプリ）では、あえて途中滞留させる変更が行われています。（ヒューマン工程「x.差戻滞留」の追加）

※ 改善前の業務プロセス： 第511話：振替伝票ファイルを自動生成させる（Excel-CSV）

[請求書発行プロセス-滞留]

第531話：テレビ番組表の自動検索

情報収集は「業務」か？

色々な意見がありそうです。テレビ番組も会議室で視聴すれば「業務」なのでしょうね。

ただ、たとえば百貨店に勤めている方なら「百貨店」のニュースは気になるものです。あるいはネット企業に勤めている方なら「AI」「IoT」「ビッグデータ」といったキーワードが気になるものです。

もし、それらのキーワードに関係する「特集番組」がテレビ放送として企画されているなら、見逃す訳には行きません。とくに公共放送で取り上げられるとなれば、社会への影響も非常に大きなものがあります。

＜NHK API 管理画面＞

誰でも使える NHK API

日本の公共放送であるNHKは、『番組表API』を公開しています。2016年6月にはVer.2の提供が開始され、「７日先」の番組情報まで取得できるようになりました。

レスポンス抜粋

"id" : "2017041215654",
"event_id" : "15654",
"start_time" : "2017-04-12T04:30:00+09:00",
"end_time" : "2017-04-12T05:00:00+09:00",
"title" : "ＮＨＫニュース　おはよう日本",
"subtitle" : "▼国内外の最新ニュース　▼スポーツ情報　▼地域の課題や話題のリポート　▼日本と世界の気象情報",
"content" : "※番組内容は変更になる場合があります　▼番組ＨＰ　ｈｔｔｐ：／／ｗｗｗ．ｎｈｋ．ｏｒ．ｊｐ／ｏｈａｙｏｕ／",
"act" : "【キャスター】森田洋平，【気象キャスター】酒井千佳",

この API は非常にシンプルな OPEN API です。

ユーザー登録さえすれば、誰でもスグにアクセスでき、利用上のルールに関しても「１日300アクセスまで」と非常に明快です。OAuth1/OAuth2といった認可フローもなく、セキュア通信（HTTPS）ですらありません！


一方で、標準仕様に厳格な API と言うこともできます。

日頃いろいろな API を活用している方であれば、Web サイトで使用できる文字（UTF-8）は、そのまま通信されるものと思い込んでしまっています。しかし、ソコは「流石NHK」です。「英数記号（ASCII 文字）だけで送受信」（Unicodeエスケープ）というルール（JSON RFC7159）をしっかり守り、日本語一文字一文字が \nXXXX と変換されています。（通信ログの検証等では使いづらいのですが）

[テレビ番組のキーワード検索]

第530話：「更新系API」で支払業務の自動化

銀行口座の自動操作

日本では『銀行API』が盛り上がっています。

この Workflow Sample ブログを運営しているクエステトラ社においても、「『MFクラウド』（会計クラウド）と『みずほビジネスWEB』（銀行オンラインサービス）とのAPI連携の恩恵」によって、入金情報のリアルタイム確認が可能となり、会計システムへの記録もおよそ当日処理（日次決算）されるようになりました。（ワークフローによってしか作成できない売掛金等の情報は「CSVインポート」のままですが…、MFクラウドさん自身がAPIを提供する日も遠くないハズ…）

• 『MFクラウド会計』『MFクラウド消込』『MFクラウド経費』の「みずほ連携」（2016-10-17）
• 『クラウド会計ソフト freee』の「みずほ連携」（2016-10-17）

※ちなみに「スクレイピング方式」（会計クラウドに銀行パスワードを預ける方式）による連携は使用禁止にしていました

そして、この入出金情報のデータ連携を可能とする『銀行API』という政策は、2017年中にも「改正銀行法」として法整備される見込みであり、また FinTech 業界も好意的に受け止めていることから、銀行システムと様々なオンラインサービスが密接に接続されていく将来が予想されています。

まずは「参照系API」から

ただ、目下のところは、一部の事業者しか『銀行API』にアクセスできません。

今後についても、そのアクセスできる事業者となるには一定の審査が入ることが予想されています。また、今国会における議論如何によっては、「許認可制」になってしまう可能性もゼロではない状況にあります。


銀行側のアクセス許可についても、当面は「参照系API」に限定される可能性があります。

つまり、「APIサービス」の試運転期間のようなものとして、「入出金情報の取得」や「残高情報の取得」といった資産の移動を伴わないデータ参照通信に限定したサービスとして開始されることが想定されます。（既にこの2017年4月から「更新系API」の事例も出てきましたが…）


ちなみに「日本独自の課題」も見え隠れしています。

すなわち、大半の口座名が「半角カナ」で処理されてきた歴史的経緯があり、長音、拗音、中黒点といった文字データが、（少なくとも現時点では）、正式なカナ名称として表示されません。

• キヨウトダイガクガクチヨウ ヤマギワジユイチ
• カ)リクル-トホ-ルデイングス

つまるところ、少なくとも当面はAPIアクセスするシステム側で「データ変換」を行う必要があります。（「自動仕訳ルール」など）

[送金プロセス]

第529話：PayPal業務のサブルーチン化

経理工程の独立

「独立したサブルーチン・プロセス」として『PayPal 請求フロー』を準備しておくと、とても便利です。

ワークフローシステム内の様々なビジネスフローから呼び出すことができるので、プロセスオーナーは、メインのビジネスフローの設計やメンテナンスに注力することができます。

下流側の経理部門の視点で言っても、複数のビジネスフローを区別なく処理できるため、効率よい業務をこなせるようになるでしょう。（ただし上流への関与は減る傾向になります）。また、ここ１・２年の変化が極めて激しい経理システム（※）にあって、「一元的に管理メンテナンスしたい」というニーズもあります。

※「クラウド会計」「銀行API」「会計BPO」など

PayPal請求書の処理

以下の業務プロセス定義（ワークフロー・アプリ）は、PayPal と自動連携する『PayPal 請求プロセス』です。

「PayPal REST API」、具体的には「PayPal Invoicing API」を通じて、ワークフローシステム側から様々なリクエストが行われます。つまり、

• PayPal 側に『PayPal請求書』を生成させ、
• PayPal から『PayPal請求書』を送信させ、
• PayPal に対して『PayPal請求書』の決済状況を確認する

という仕組みになっています。（直接 PayPal にログインする機会は減ることになります）

[PayPal請求プロセス]

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

請求の自動化

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

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

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

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

更なる自動化

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

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

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

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

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

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

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