カードNavi, カードセキュリティ最新情報, カードセキュリティPCI DSS, カード新着情報, トップページ用注目ニュース, ペイメントニュース, ペイメント新着情報

オンラインにおけるカード決済不正と対抗策の過去10年とこれからの展望　不正検知ソリューション「ReD Shield」、デバイス情報「iovation」を提供（下）

2018年5月15日8:00

■株式会社スクデット/ジグザ株式会社

RPAでホワイトカラーの定型業務を自動化

ジグザは2012年の設立で、RPA（Robotic Process Automation）のソリューションや一般的な業務システムの受託開発、コンサルティングなどを行っています。

さきほど、スクデット・細江氏より、スクリーニング業務の運用が大変であるという話がありました。確かにソリューションを利用すると、大半のトランザクションには「問題ない」「NGである」という判断が付いてきます。しかし、グレーなレコード・ログイン・取引については、現状、手動で捌かれている企業が多いと思います。その解決のアイディアとして、RPAについてご紹介します。

まず、スクリーニング業務を整理すると、大半の場合、4つのプロセスで構成されているかと思います。まず、一次スクリーニングは、例えば「iovation」や「ReD Shield」などのソリューションを通過したトランザクションで、これを一次的振り分けとします。その結果として、このログイン・取引は問題ない、あるいはこのログイン・取引は絶対ダメであると判定されますが、大体、数％のグレーなレコードが存在します。それを二次スクリーニングで判断していきます。この二次スクリーニングでは、一次スクリーニングの中でシステムから発行された取引のIDに紐付くECシステムや顧客情報などを、Excelのような一覧表にまとめ、それを担当者、責任者が1件ずつチェックしていきます。

例えば、携帯電話の購入を例にとると、携帯電話はひとり1台買うのが通常だと思います。ところが、場合によっては1人で3台を購入する。これがグレーになります。その場合、例えば「家族で購入されていると想定される場合OK」といった人間によるチェックを二次スクリーニングでやっています。

二次スクリーニングでも判断がつかない場合には、確定処理ということで、例えば取引に紐付く電話番号に担当者が直接電話をし、正当な取引か、実際に存在する住所かなどを確認します。最後に後処理ということで、取引停止や本人から必要な書類が提出されない限り出荷を止める保留処理などを行っています。

この4つのプロセスのうち、一次スクリーニングは基本的にシステムがこなすので、特に人手はかかりません。確定処理、後処理に関しては、大抵の場合、人間が調整をかけるような業務になり、手作業以外ではやりにくいところがあります。今回、私どもが問題にしているのは二次スクリーニングです。この二次スクリーニングをさらに見ていくと、ほとんどが手作業になっています。一次スクリーニングで特定したIDについて、社内システムに問い合わせるためには、ログインし、検索し、必要な情報をコピーして貼り付けるといったことを、取引システムや顧客システムに対して実施することになり、その後で判断することになります。

その中で価値のあるところは判断するところです。しかし、実際の業務の8～9割はログインして、コピーして、貼り付けてといったことで、非常に時間がかかっています。コピーして貼り付けるところはあまり付加価値の高くないところですので、ここを潰すことで業務量が減り、タイムリーなチェックが可能になります。何か急ぎでトランザクションを調べなければならないという時に仕組みがあったほうがタイムリーに対応できます。

例えば、EC業者はECシステムだけではなく、出荷システム、コールセンターシステム、決済システムなど、さまざまなシステムを使っています。これらのシステムがすべて自社開発であればよいのですが、多くはクラウドシステムやパッケージソフトも活用していると思います。すると、連携しないシステムが非常に多く点在しているという状況になります。したがって、情報をさまざまなシステムに照会しようとすると、どうしても手作業が発生します。今後、さらにクラウドが発展し、パッケージソフトが増加すると、手動の仕事がますます加速していきます。その場合の解決策のひとつがRPAです。

RPAの機能は、ホワイトカラーの定型業務を自動化することです。定型業務とはコピーして貼り付ける、定型文を作ってメールを送信するといった業務で、提案資料をパワーポイントで作成するなどの創造的な作業はRPAの範囲外です。具体的には、ファイルやシステムなどから情報を読み取り、人間であればそれを文章にしたり、判断をしたりするわけですが、ソフトウェアで最終的にアウトプットとしてExcelに吐き出す、メールを送るなどの定型作業であれば、これを自動化します。翻って、こういった定型作業はまさに二次スクリーニングの部分であり、ここに活用できると考えています。

RPAの導入ハードルと対応

このようなRPAのソリューションを導入すると、素晴らしい未来が待っていると思いがちですが、実際には大変なことがあります。1つは設定難易度の高さです。そもそもRPAソフトは、WindowsでいうEXEファイルのようなものです。EXEファイルを起動すると画面が開き、プロセスを1つ1つ登録していきますが、内容が広く、処理を分岐させる必要などもあり、設定が大変です。当然、RPAのソフトウェア・ベンダーでサポートやトレーニングは用意しますが、それでも大変です。また、設定にあたっては、WEBなどのIT知識も要求されます。また、できることにも限度があり、RPAソフトはGUIベースで設定できる項目しか対応できません。したがって、RPAソフトでできること・できないことを識別した上で、できる項目のみについて設定すると考えると、全般的に設定難易度は高くなります。

もう1つはコストがかさむということです。ソフトウェアでライセンス料を払うかたちですが、設定は導入した企業の社員が行うことになります。したがって、キャッシュアウトはソフトウェアのライセンス料だけですが、設定の内部コスト的な部分は見えにくいながらも人件費はかさみます。その結果、導入期間が長くなったり、頓挫したりすることが、頻繁に起きています。

ではどうしたらよいか。2つの解決策があります。1つはRPAソフトの特性を知った上で、使い倒すということです。このソフトはこれができる・これができないということを、予めわかった上で割り切ってしまう。「10の業務のうち5～6でも自動化できれば、人件費が下がるのでよしとしよう」というくらいの割り切りが必要です。ただ、専門的な知識や設定がわからないということがあるので、できれば社員の中で情報システム部のメンバーや元エンジニアの社員などを起用し、社内サポートを充実させるとよいと思います。

2番目の解決法としては、RPAソフトウェアに頼らず、自社で自動化のプログラムを作ってしまうということが挙げられます。RPAというと最先端のテクノロジーを使っていると考える人もいると思いますが、実はベースとなる要素技術はずいぶん前からあり、現在ではフリーソフトを活用できたりだとか、MicrosoftのVBA（Visual Basic for Applications）で実現できたりすることの方が多いかもしれません。したがって、全社レベルではないが、ある程度自動化したいという場合には、RPAソフトという選択肢ではなく、協力会社にお願いし、もしくは自社で開発するほうがよいと思います。

ちなみに、日本でRPAソフトを知っている人はかなり少ないと思います。しかし、プログラムを知っている人は多いので、そういった意味で2番目の選択肢はかなり現実的です。

三層構成となる「ziggxa flow」

一般的なRPAソフトは、いわゆるWindowsでいうEXEファイルで、ソフトウェアを立ち上げて設定していくかたちですが、弊社のソリューション「ziggxa flow」では、少し特殊なアプローチをとっており、三層構成になっています。まず、ベースとなるプラットフォームに、例えば、途中で処理失敗したらメールを送るなどの自動化を実行するベース技術を置いて、その上にお客様ごとにさまざまな条件で分岐をするなどの独自ロジックを置きます。しかし、独自ロジックの構築は難しいので、それを支援するたくさんのライブラリを用意しています。このかたちをとることで、さまざまなことが制約なく実現できますし、弊社はAIにも力を入れていますので、AIを使った処理もできるようになります。

ちなみに、このアプローチは弊社独自のものではなく、実はGoogleが以前からこのようなアプローチを採用しています。例えば、Google MAPでは出発地と終着点で経路が提示されますが、その中ではGoogleのライブラリを使っており、それを実行するのは彼らのプラットフォームです。そのライブラリはホームページの中に組み込むこともできますし、企業内のシステムに組み込んで、例えば営業向けのルートを作ることもできます。つまり、Googleもプラットフォームとライブラリを提供し、個別のお客様ごとに自社に必要な開発・カスタマイズは行ってください、というアプローチです。弊社のアプローチもこれを踏襲したものになり、先ほどの2番目の自社で作り込む方法と近いメリットが得られます。

RPAソフトを利用する場合とは、大きく違う点が3つあります。一般的なRPAソフトでは導入期間が3～6カ月間かかりますが、弊社に限らず、独自で作りこむのも含めて、仕様さえ決まっていれば短い期間で作れます。弊社では最短3日です。また、RPAソフトで作り込むと作り直すのが大変です。例えば、システムのデザインを変えたいという場合、一から作り直すのは大変ですが、プログラマーが行えば即日完了できます。さらに、できることに制約がなく、限定されません。

スクデットと決済の不正防止業務で連携

現在、スクデットと弊社がパートナーシップを結んで行っている業務の1つとして決済不正防止業務があり、カード不正のソリューションを通過した後にグレーとなってしまったレコードについて、社内システムに問い合わせ、それを集約して、定型チェックまでかけて、本当に人間が必要なところまで持っていくところを、すべてボタン1つでこなすことができるという意味でRPAがおすすめという事例があります。これはシステム化一般にそうですが、作業時間も削減できますし、ミスがなく、引継ぎも簡単にできます。

▶▶前編へ戻る

※本記事は2018年3月2日に開催された「ペイメントカード・セキュリティフォーラム2018」のスクデット、ジグザの講演をベースに加筆を加え、紹介しています。

お問い合わせ先
■株式会社スクデット
〒104-0028
東京都中央区八重洲2-11-7　一新ビル8F
TEL：03-4520-5550
HP：https://www.redshield.jp/
URL：https://www.redshield.jp/contact/