プロセス見直しの季節

4月。

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

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

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

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

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

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

普段の業務改善は、日頃の業務中に感じた「不満」や「課題」に対して『フローの改善』や『データ入力画面の改善』を考えるのが常です。
  • 工程の自動化
  • ダブルチェック工程の追加
  • ガイド文の追加
  • 便利ボタンの設置
そして、その多くの場合、「トータル所要時間を少しでも早める方向性」を模索します。


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

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


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

情報収集は「業務」か?

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

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

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

<NHK API 管理画面>

誰でも使える NHK API

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

レスポンス抜粋

"id" : "2017041215654",
"event_id" : "15654",
"start_time" : "2017-04-12T04:30:00+09:00",
"end_time" : "2017-04-12T05:00:00+09:00",
"title" : "NHKニュース おはよう日本",
"subtitle" : "▼国内外の最新ニュース ▼スポーツ情報 ▼地域の課題や話題のリポート ▼日本と世界の気象情報",
"content" : "※番組内容は変更になる場合があります ▼番組HP http://www.nhk.or.jp/ohayou/",
"act" : "【キャスター】森田洋平,【気象キャスター】酒井千佳",


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

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


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

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

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

銀行口座の自動操作

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

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

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

まずは「参照系API」から

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

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


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

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


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

すなわち、大半の口座名が「半角カナ」で処理されてきた歴史的経緯があり、長音、拗音、中黒点といった文字データが、(少なくとも現時点では)、正式なカナ名称として表示されません。
  • キヨウトダイガクガクチヨウ ヤマギワジユイチ
  • カ)リクル-トホ-ルデイングス
つまるところ、少なくとも当面はAPIアクセスするシステム側で「データ変換」を行う必要があります。(「自動仕訳ルール」など)

[送金プロセス]

経理工程の独立

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

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

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

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


PayPal請求書の処理

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

「PayPal REST API」、具体的には「PayPal Invoicing API」を通じて、ワークフローシステム側から様々なリクエストが行われます。つまり、
  • PayPal 側に『PayPal請求書』を生成させ、
  • PayPal から『PayPal請求書』を送信させ、
  • PayPal に対して『PayPal請求書』の決済状況を確認する
という仕組みになっています。(直接 PayPal にログインする機会は減ることになります)

[PayPal請求プロセス]