アナリティクスいわく「○×工務店さんが困ってマス!?」

前々回記事前回記事では、「先週のWebアクセス動向」が社内通知される(ほぼ無人の)ワークフローを紹介しました。

この業務プロセスが運用されれば、社員は毎週月曜日の朝、「Google Analytics Reporting API」を通じて得られた最新情報について、メールで確認できるようになります。その結果、日々の「サポート業務」や「セールス業務」は、より効率良いものになるでしょう。

ただ、もう少し欲を言えば、「Analytics に無い情報」も併記しておいてもらいたいものです。つまり、
  • 先週火曜日、プレスリリースを配信した
  • 先週木曜日、ユーザ向けセミナーを実施した(○×工務店さんも居た!)
もしこういった Analytics に無い情報も併記されていれば、「流入の多いリンク元」や「特定の顧客が調べているページ」といった動向情報について、もっと深い理解・洞察が可能となるかも知れません。

カレンダー情報も API 取得

以下の業務プロセス定義は、社内カレンダー『広報予定およおび出展予定』(Google Calendar)に書き込まれているイベント(先週分)が、通知メールの文頭に付加される仕組みです。

これにより、通知メールを受ける社員達は、「Webアクセスに影響を及ぼしたかもしれない関連情報」についても、同時に確認することが可能となります。

[自社サイト運用状況報告プロセス3]

人気ページのランキング

前回記事では、『Google Analytics Reporting API』との自動通信によって「週次レポート」が自動的に生成される方法を紹介しました。

ポイントは、
  • ディメンジョン: ga:hostname, ga:pagePath, ga:pageTitle
  • メトリックス(指標): ga:pageviews, ga:sessions
というルールで集計データを自動取得する自動工程(サービス工程Addon)です。

この工程では「沢山アクセスを得たWebページのリスト」が複数行テキストとしてまとめられます。もし「フィルタ」に『ga:pagePath=~/blog/』の様な設定をすれば「blog フォルダ以下のWebページ」を対象としたランキングも自動的に取得することが可能です。

これらの文章が挿入された通知メールは、マーケティング・チームにとって非常に有用な情報となるでしょう。

他にも数万パターンの集計方法

しかし Google Analytics のデータは、もっと他の角度からも集計したい所です。

前回例では、上述の「3つのディメンジョン」と「2つのメトリックス」でランキング集計されましたが、Google Analytics には他にも約260のディメンジョンと約230のメトリックスが存在しています。つまり、組み合わせを変えることによって、多種多様な集計が可能となります。

たとえば、サイトコンテンツの視点(『行動(BEHAVIOR)』)だけでなく、『ユーザー(AUDIENCE)』や『集客(ACQUISITION)』の視点で集計すれば、「どんな人がアクセスしているのか?」や「どんなサイトから誘導されてきたのか?」といった情報も抽出できるハズです。

参考: ディメンジョン名とメトリックス名

[自社サイト運用状況報告プロセス2]

分析ツールなのか、集計ツールなのか

Web 業界に関わる人であれば、誰でも『Google Analytics』の存在を知っています。

改めて説明するまでもありませんが、『Google Analytics』(グーグル・アナリティクス)とは、自社サイトのアクセス数や訪問者数などが分かるサービスで、「人気ページ」や「不人気ページ」を確認したり、「ネット広告の投資効果」を確認したりと、「その道の人」には無くてはならないツールとなっています。

しかし一方で、多くの人にとっては「多機能すぎるツール」とも言えます。

見たい情報を表示するための操作は、多機能であるが故に複雑な手順を踏むことになります。たとえば「社内週報」を作るために毎週『Google Analytics』にログインしているような方でも、ごく一部の機能しか使わないのが実情です。そこで、毎回の作業を効率化すべく『カスタムレポート』(ダッシュボード)や『カスタムアラート』(メール通知)を使っている人も少なくありません。

今週も集計値に異常なし!

以下の業務プロセス定義は、週次で行われる「自社サイト運用状況報告プロセス」です。

毎週月曜日の朝には、「Google Analytics の集計データがプリセットされた報告文草稿」が用意されます。したがって、マーケティング担当者は一言コメントを入力するだけで全社への報告を完了させることが可能です。特段の変化が発生していない限り『Google Analytics』にログインする必要がありません。

[自社サイト運用状況報告プロセス]

Google Group 登録者のメンテナンス

前回記事および前々回記事では、『Google Group』のメンバー追加やメンバー削除が自動的に実行される業務プロセス定義を紹介しました。

Google Group を「社内の情報共有ツール」として活用している会社であれば、この自動追加や自動削除といった機能は、「適時更新を保証する仕組み」として非常に有効と言えるでしょう。

求められる信頼性要件の高さ

しかし、この様な仕組みを導入してもなお、「正しいメンバーを維持すること」は容易ではありません。

たとえば、急ぎの依頼を受けて「間違った Group にメンバー追加」(システム管理画面)してしまうケースもあるでしょう。あるいは、ユーザ自身が「退会処理」(ユーザ設定画面や unsubscribe メール)をしてしまうケースもあるかもしれません。その様なケースは、「届くべきでないヒトに情報が届いてしまう状態」あるいは「届くべきヒトに情報が届かないという状態」になってしまいます。

「えっ? そんな通達、あったっけ??」

何か月もメーリングリストの情報を受け取らずに仕事をしていた、、、なんかヘンだと思った、、、、といった悲劇は、(非常に恐ろしい事ではありますが)、いつか必ず発生してしまうものです。

[MLメンバー確認]

メーリングリストの管理

前回記事では、ワークフローの流れの中で、「メルマガ購読希望者」(のメールアドレス)が自動的に『Google Group』に追加される業務プロセス定義を紹介しました。(資料請求に対応する業務)

これは、1つのメールアドレスが「1つのメーリングリスト」に自動追加される仕組みです。

しかし、社内で運用されているメーリングリストを見渡せば、(いわゆる『チャットツール』の普及によって減少傾向にあるとは言うものの…)、「方針の通達」「部署内限定にしたい情報の共有」「システムアラートの受信」など、様々な業務において、様々な社内メーリングリストが日常活用されていることでしょう。

メーリングリスト管理の観点においては、「複数のメーリングリスト」に一括追加したいケースの方が、むしろ多いのかも知れません。

複数の Google Group に一括登録

以下の業務プロセス定義は「アカウント申請フロー」です。

社内からの『アカウント申請』があれば、「アカウント新規発行」や「LDAPの設定変更」など、情報システム部は必要なシステム設定を行います。

特筆すべきは「複数のメーリングリスト」への追加削除工程が自動化されている点です。(工程の無人化)

すなわち、案件が[Groupメンバ追加]や[Groupメンバ削除]の工程に到達すれば、ワークフローシステムから追加・削除のリクエスト(OAuth2)が送信されます。つまり、「メーリングリストへの追加削除」という作業について情報システム部の担当者は『メンバ追加されるGoogleGroup』(Checkbox)や『メンバ削除されるGoogleGroup』(Checkbox)が正しく選択されていることを確認するだけで良く、『G Suite』の管理画面にアクセスして Group 設定を一つ一つ編集する必要はありません。(Admin SDK Directory API v1)

[アカウント発行およびML登録]

メールでの情報共有

メーリングリストは便利です。

組織内の「情報共有」に使ったり、お客様への「情報通知」に使ったりと、多くの企業で日常的に活用されています。しかし、その「メンテナンス作業」がオロソカになってしまうケースは少なくありません。
  • メールが届くべきではないヒトに届いている(情報漏洩?)
  • メールが届くべきヒトに届いていない(新入悲劇あるある?)
そんな状況が、世界中で発生していることでしょう。

購読メンバーの自動追加

以下の業務プロセス定義は「資料請求対応フロー」です。

このワークフローはお客様の「Web申込」によって開始されます。そして、その申込案件が自動工程『メルマガ追加』に到達すれば、自動的に「お客様のメールアドレス」がメーリングリスト(Google Group)に追加される仕組みとなっています。

この様な処理の「無人化」は、G Suite 管理者が管理画面にアクセスして手動でデータコピーする手間を無くすだけでなく、設定ミスやタイムロスによるトラブルを未然に防ぐことにも寄与します。また手動設定では困難だった「アドレス追加の履歴記録」をも実現します。

[資料請求対応]

工程の無人化による生産性向上

前々回記事前回記事では、ワークフローシステムから「PayPal 請求システム」をコントロールする仕組みを紹介しました。

これらの仕組み(ワークフローアプリ)には、フロー図の途中に自動工程(Addonサービス工程)が配置されています。つまり、請求案件がこれらの工程に流れ着く度に、
  • 『PayPal請求書』を生成せよ(PayPal Create)
  • 『PayPal請求書』を送信せよ(PayPal Send)
  • 『PayPal請求書』の決済ステータスは何か?(PayPal Check)
といった「リクエスト」がワークフローシステムから自動的に発信されます。言い換えれば「電子請求書の生成」「電子請求書の送信」「電子請求書のステータス確認」といった経理業務が「無人化」されています。(PayPal Invoicing API との REST/OAuth2 通信)

今日では、この例のような「決済システム」(*1)に限らず、様々な情報システムの操作が自動化され、生産性向上が図られています。たとえば「Storageシステム」(*2)への見積書保存や、「表計算システム・データ管理システム」(*3)での商品マスタ管理などが代表的な例と言えるでしょう。

*1: PayPal, Stripe, etc. *2: Dropbox, Box, Google Drive, etc. *3 Google SpreadSheet, Kintone, etc.


<設定画面:Paypal Create>

<設定画面:Paypal Send>

<設定画面:Paypal Check>

#プロセスオーナーはAddon自動工程のプロパティを設定するだけで良くなった(プログラミング知識が必要なくなった)という点も普及要因

どの様な状態変化まで無人対応させるべきか

しかし工程の無人化は「メリットばかり」ではありません。

たとえば前回記事では、電子請求書のステータスが『PAID』(支払い済み)になるまで確認し続ける(ループし続ける)という業務フローになっていました。

確かにヒトは介在しないので「確認作業」そのものには人的コストは発生しません。

しかしながら、もし「発注キャンセル」や「他の決済方法での送金」といった事象が発生しているのなら、場合によっては「出荷処理」という業務を止める必要があるかも知れません。場合によっては「売上計上」という処理にも修正が必要になってくるかも知れません。やはり「影響度×発生確率」が大きい状態変化ついては、業務プロセス定義として「想定外」のままにするのではなく、できるだけ「想定の範囲内」にしたい所です。

以下の業務プロセス定義では、比較的発生頻度の高い「CANCELLEDステータス」(キャンセル)について考慮されています。すなわち、支払いが拒否された場合などにアラートメールを発信する、という工夫が追加されています。

[Paypal請求書発行プロセス-キャンセル通知]

請求を自動化する

前回記事では、「PayPal Create」と「PayPal Send」という2つの自動工程を配置することで、『PayPal請求書』が自動的に送信されるワークフローを構築しました。

すなわちヒューマン工程でのチェックや承認を経た「請求データ」が自動的に PayPal 側に POST され『PayPal請求書』が生成されます。そして指定時刻になると(送信指令が届けられ)メール送信されます。何と言っても、「Addonサービス工程」だけで定義できる為、(=「スクリプト工程」が使われていない為)、プログラミング知識が無くても、自社の業務フローにあわせた「自動請求システム」を構築できるのが魅力です。

しかし「『PayPal請求書』が決済されたか確認する業務」については対象外(スコープ外)となっていました。

着金確認まで自動化する

以下の業務プロセスでは、更に「PayPal Check」という自動工程(Addonサービス工程)が追加されています。すなわちこのワークフローシステムは、送信させた『PayPal請求書』について、その決済ステータスを定期的・自動的に確認し続ける設定となっています。

具体的には、「(3.未決済滞留)」の工程にある案件が、
  • 経理担当者が案件を進めるたび
  • 12時間の滞留時間を経るたび
に自動工程「PayPal Check」に到達します。そして、セキュア通信(OAuth2通信/PayPal Invoicing API)を通じて決済状況が問い合わせられます。もし、ステータスが「決済された(PAID)」になっていれば、「(3.未決済滞留)」の工程に戻らず「決済された時刻」と「決済された金額」を格納して、全工程終了となる仕組みです。

[Paypal請求書発行プロセス-決済チェック]

決済に直結する請求書

『ペイパル請求書』は「メールタイプ」の電子請求書です。

メールを受信した人の視点で見れば、『請求書の表示および支払い』のボタンをクリックし、スグに決済処理(カード決済・PayPalアカウント決済)をすませることができるので非常にラクです。もちろん「経理担当者への社内転送」が必要な場合も、メーラでの転送操作だけでよいので、とても簡単です。

請求書を発行する側の視点で見ても、たとえば従来型の「紙請求の業務プロセス」が、
  1. 請求書のExcelデータの作成し
  2. 請求書を印刷し
  3. 請求書を郵送し
  4. 指定銀行口座に入金されたかを確認する
といった手順を踏んでいたのに比べて、
  1. PayPal にログインして請求データの入力する
  2. (決済完了通知が来る)
といった非常に簡素なものになります。しかも、クレジットカード情報は受け取らないので「漏洩リスク」もありません。


昨今では、「生産性向上」や「テレワーク環境整備」の観点からも非常に注目されています。(PayPal 請求書

<受信したメールの例:メーラ画像>

ワークフローとのAPI連携

『ペイパル請求書』は、特別なシステム導入が要りません。

しかし、「Paypal にログインすれば請求書が送信できる」というこの手軽さは、同時に「上司承認が曖昧になる」や「複数人でのミスチェックがしづらい」といった新たな課題を抱えることにもなります。特に「業務プロセス」を重視する会社であれば、ガバナンス上の問題として議論される可能性があります。


以下の業務プロセス定義サンプルでは、ワークフローシステムから API 制御させることによって

「PayPal にログインせずに PayPal 請求書を活用する」

という方針を実現しています。すなわち、ワークフローシステム内で承認・チェックされたデータが API を通じて自動的に PayPal 側に連携され、「請求メールの送信指令」もワークフローシステムから API を通じて届けられます。そして「いつ誰が何をしたか」という業務記録は全てワークフローシステム側に記録されます。

※ クラウド型ワークフロー『Questetra BPM Suite』であれば、無料で実現することが可能です。(業務プロセス定義をインポートすれば数時間で構築できます)

[PayPal 請求書発行プロセス]

「検収報告を受ける」という受け身な工程

イラスト制作・Webサイト制作・内装工事。。。そんな受託事業には「検収対応」がツキモノです。

請負契約に基づく案件は、単に、(1)成果物を「納品する」だけではなく、(2)クライアントから「検収報告書を受け取る」という段階を経て始めて、(3)委託費を「請求する」ことが可能となります。

(もっとも、特別な取引関係にあっては「検収工程」が省略され「納品即請求」が許されるケースもありますが…)


世界中で
  • クライアントの為に「検収報告書」のサンプルを添付する
  • 文書名を『納品書』とせず『検収依頼書(兼 納品書)』といった名前にする
といった涙ぐましい努力や工夫が行われています。

何をする工程か決まってない?

しかし、現実の「検収報告の受領」は、
  • A. 納品当日に「検収報告書」を渡してくれるケース
ばかりではありません。
  • B. 検収期限ギリギリに「検収報告書」を送ってくれるケース
  • C. 検収報告書の提出は行われず「みなし検査合格に関する規定」の適用を前提とするクライアント
など、様々なケースが発生してしまいます。更に言えば、
  • D. 「成果物が仕様を満たしていない」と判断されて検収期間の延長を迫られるケース
  • E. 「成果物が仕様を満たしていない」と判断されて再納品を迫られるケース
もあるでしょう。

ではこの様な場合、どのように業務プロセスを描けばよいのでしょうか? とくに「何もせずに期限がきて終わる」という(C)は、どのように表現すれば良いか悩みます。

[検収対応フロー]

とある工程の作業時間を計測したい

たとえば翻訳工程における「翻訳に要した時間」を計測したい場合、「翻訳結果」とともに「実作業時間」を報告(入力)してもらう方式が考えられます。

しかし、その方式では、各翻訳者に
といった手段で実作業時間を計測してもらう必要があります。この「作業時間を自己計測して報告する」という行為は、大きな手間と言わざるを得ません。

※もっとも「離席休憩」や「割り込み作業対応」といった除外すべき時間が途中発生した際に、計測を一時停止させる等の柔軟な対応が出来るメリットもあります。

報告値の確からしさ

また、結果として「正確でない実作業時間」が報告されてしまう可能性もあります。

たとえば人事考課や能力査定などの面で、「翻訳時間」を短く見せる(長く見せる)ことに何らかのインセンティブが働く制度なのであれば、その「作業時間」は少しずつ事実とは異なる数値が入力されるでしょう。

あるいはまた、シゴトの成果そのものに誇りを持ち、「翻訳時間」などに全く興味を持たない作業者がいたとすれば、「イイカゲンなデータ」が入力されることを想定せざるを得ません。

[翻訳フロー]

ミス発生に伴う生産性ダウン

決裁者さんにとって「差し戻し処理」は、億劫(おっくう)です。

申請内容を読み『無言』でOKすれば良いハズ(3分)のところ、(無言でNGするワケにも行かず)、更に10分かけて『差し戻す理由』を書かなければなりません。しかもそれが「単純ミスや誤記の指摘」であり、それが一日に5件・10件も発生するとなれば、流石に気分も滅入ってしまうでしょう。

そして当然、帰宅する時刻も1時間・2時間と遅くなってしまいます。

システム改良で下げられるミス率

『日付』をまちがう、『金額』をまちがう、『顧客の名前』をまちがう。

申請者さん達も、好き好んで間違っている訳ではありません。基本的には(?)、「業務プロセス定義の工夫や改良」によってミス率を下げることを考えたいものです。(プロセスを憎んでヒトを憎まず!)
  • 入力画面の「注意書き」や「入力チェック」を改良する
  • 業務フローに同僚による「レビュー工程」を追加する

[申請系プロセスのベースフロー-スクリプト]

各案件のログ

業務プロセスの最適化を考えるとき、「マスタ系のデータ」と「トランザクション系のデータ」の2分類における後者データを分析します。

具体的に言えば、『商品マスター』や『顧客マスター』などの「マスタ系データ」ではなく、『見積書No123の詳細』や『請求書No123の詳細』といった発生記録としての「トランザクション系データ」を分析します。

分析に有用なログ

ワークフローシステムに流れる『〇〇案件の詳細』は、案件が開始されるたびに蓄積されるデータであり、全て「トランザクション系データ」に該当します。

しかしながら、業務プロセス内で定義された『データ項目』に、全てのトランザクション情報が格納されている訳ではありません。たとえば『第2工程に到達した時刻』や『ループ構造を周回した回数』といった「システム側で保持されている情報」(案件それぞれのログ)は、エクスポートしやすい形で格納されていません。

以下のワークフローは『差し戻された回数』(ループ構造を周回した回数)という「システム側で保持されている情報」が、業務プロセス側の『データ項目』に自動的に取り込まれる設定となっています。

[申請系プロセスのベースフロー]

小さく始める

「システムに慣れるには、どうしたら良いでしょうか?」

投資効果だけを考えれば「既存の非効率な業務」をシステム化するのが効果的です。もし「紙ベース」で行われている業務があるのなら、その業務のシステム化を検討すべきです。もし、受注・出荷・請求といった「基幹業務」に適用すれば、比較的容易に『効果』が『投資』を上回ることでしょう。

しかし、(1)管理者:システムの設定ノウハウが高くない、(2)一般社員:システムの利用リテラシが高くない、といった状況なのであれば、全く『効果』が出せない危険性もあります。それは「原稿用紙に手書き」してきた小説家に「パソコンでの制作」を強要するようなものです。

「システムの導入で、業務効率を悪化させてしまうかも」。そんな不安がある場合、まずは「小さな業務」で、(できれば毎日必ず行う業務で)、試運転するのが良いかも知れません。

改良し続けるという習慣

ペーパレスやテレワークを推進する際には、「ワークフローシステム」の導入が検討されます。

最初に適用する業務を何にすべきかは、非常に悩ましいところですが、たとえば、以下の「勤務時間報告」という小さなワークフローは有力な候補と言えるでしょう。何と言っても「必然的に毎日利用することになる」のが良いところです。

実際に「データ入力」を行ってみて、実際に「承認」を行ってみて、、、何が必要で、何が省略できるのか、おのずと理解が深まるでしょう。また、その利用の中で、様々なアイデアも生まれてきます。
  • 管理者: 業務フローの設計ノウハウが高まる
  • 一般社員: 工程を担当するという基本的な使い方を理解できる

[出退勤報告フロー]

入力ミスが多い?

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

たとえば「請求書発行日」と「入金期限」の2つの日付を入力する必要があるワークフロー工程であれば、
  • データ複製のまま1年前の日付を入力してしまう
  • 請求書発行日と入金期限を逆に入力してしまう
といったミスが発生しがちです。(折々に、実際の発生率を計算してみるのも良いでしょう)

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

初期値を設定する

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

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

<設定画面>

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

入力ミスが多い?

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

たとえば「単価」と「数量」の2つの数値を入力する必要があるワークフロー工程であれば、
  • 12000 が 1200 と一桁が足りない数値を入力してしまう
  • 金額を入力すべき場所に数量を入力してしまう
といったミスが発生しがちです。(折々に、実際の発生率を計算してみるのも良いでしょう)

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

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

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

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

<設定画面>

<動画:ミス発生の様子>

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

プロセス見直しの季節

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請求プロセス]

請求の自動化

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

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

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

更なる自動化

  • PayPal に「PayPal請求書」を生成させる
  • PayPal に「PayPal請求書」をメール送信させる
が自動化できたのなら、更に
  • PayPal に対して、入金があったか確認する
についても自動化したいものです。(債権回収業務の効率化)

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

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

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