バックオフィスに自動化ツールをいれる際に要件をとりまとめて業務プロセスを標準化する作業は、システムというより顧客側の調整に依存する部分が大きく、IT企業側だけでは立ち行かなくなり「やはりインドネシアには早すぎた」と結論付けられるのは不幸です。 インドネシアのビジネス インドネシア市場でのビジネスで重要な要素は価格とブランド、コネの3つと言われますが、必ずしもこれらを持ち合わせない日本人はどのように戦えばよいのか。これはインドネシアに関わり合いを持って仕事をする人にとっての共通の問題意識かと思います。 続きを見る
RPAツールUiPathを試してみた所感
2019年2月現在ジャカルタの日系IT企業が扱っているRPA（Robotic Process Automation）にはUiPath（UiPath社）、Winactor（NTTアドバンステクノロジ社）、Kofax Kapow（Kofax社）などがありますが、あくまでも定型業務の自動化ツールとしての導入であり、AI（Artificial Intelligence人工知能）が機械学習を行い自律的に何らかの判断しをして、具体的な処理をRPAで行うというロボット的な導入はまだまだこれから先の話です。
実際にUiPathの無料版であるCommunity版で、Excelから読み込んだデータをキーとして、WEBで情報検索し、表示された結果をExcelに書き込む手順を自動化してみましたが、開発ツールUiPath Studio上で制御文を選び変数を定義し、アクティビティで自動化プロセスのアルゴリズムを表現する作業は決して簡単ではなく、情報システム部のないインドネシアで、トレーニングを受けたエンドユーザー主導で導入するにはハードルが高いと感じました。
- RPAツールはExcelやメールソフト、WEBブラウザなど外部アプリと統合しながら定型作業を記録するマクロである。
Excelマクロでよくやる「マクロの記録」して自動生成されたVBAソースを切り貼りしてプログラムを作る、のと同じ作業をUiPath Studioの「レコーディング」で行う - 現場のエンドユーザーがトレーニングを受けただけでRPAを扱えるようになるとは考えにくい。
- OCR（Optical Character Recognition/Reader 光学的文字認識）と連携して紙のアナログ情報をデジタル化するところからはじめる案件はインドネシアでは重そう。
- 導入効果は生産性向上、ポカミス軽減、労務費軽減の3つの指標で総合的に判断し、短期で費用対効果を求めすぎないこと。
- 帳票作成業務はRPAを使うよりシステム化したほうが良さそう。
- インドネシアで導入効果が見込まれる定型作業は、元データがデジタル化されており、量が多く、標準化しやすいもの。例えば・・・
- フィンガープリントからAccessに蓄積された出退勤データのPayrollシステムへの登録。
- シーケンサーから取得した出来高情報の生産管理システムへの製造実績登録。
- 顧客から受信したExcelやCSV形式の受注POを業務システムに受注登録。
- 月末にExcelの給与支払いデータをインターネットバンキングシステムに送金一覧として登録
またルールエンジンによる定型業務の自動化を行うだけのRPAが、ロボット（デジタルレイバー）を標榜することに対する違和感は、元データであるExcelファイルの値とフォーマットに対する整合性チェック（Validation）ができないことが理由だと再確認しました。
生産性向上の取り組みはペーパレス化からはじめるべき
日々の事務処理業務の中では媒体間、システム間でデータ移行作業が頻繁に発生し、それぞれに自動化するためのツールがあるとはいえ、元データの正誤を保証する手段はありません。
- アナログ媒体（紙）からデジタル媒体への変換 ⇒ OCRまたは複合機（スキャナ）
- Excel内での参照・加工 ⇒ 式やマクロで加工
- Excelから業務システムへの入力 ⇒ Dataloader（Oracle社）やRPAで自動化
- システム間をまたぐデータ移行 ⇒ RPAで自動化
顧客からFAX受信した受注POを複合機でイメージスキャンしてPDF化し、PDFファイルの変換ツール（Small PDFなど）でExcel化している場合、「0（ゼロ）」と「O（オー）」、または「8（はち）」と「B（ビー）」などの誤認識の発生は避けられないため、Excel化したデータをチェックし修正する作業が発生します。
RPAツールは元データの値が正しく、正しくフォーマットで保存されていることが正確に稼動する前提条件であるため、OCRでアナログ媒体である紙から取得したデジタル情報は、マニュアルによる正誤チェックがどうしても必要になります。
過去の顧客からの受注POデータの蓄積の中から「0（ゼロ）」と「O（オー）」の傾向を分析し、自律的に正しい選択をするには、機械学習機能を持つAIが必要となり、そのためにAIを導入するくらいならペーパレス化のほうがコスパが高く、より本質的な業務改善となります。
ペーパレス化が叫ばれて何十年も経つのに、いまだ現場での紙フォーマットへの手入力と、Excelへの書き写し作業がなくならない理由は、タブレットなどの端末への入力が紙フォーマットにボールペンで手入力する作業に比べて、使い勝手が悪いからです。
本来ならExcelで作った入力フォームをそのまま端末上のフォームに変換しデータ連携を行うi-Reporter（シムトップス社）などのツールを使うことでペーパレス化を実現した後に、業務システムの実装に漏れた定型作業をRPAで自動化するほうが、順番として自然だと考えます。
RPAツール開発とプログラミングの違い
話は逸れますが、僕が昔新卒入社したシステム会社は社員に情報処理試験を強制受験させていまして、それは会社が経済産業省システムインテグレーター認定企業として登録されるには、社員に一定数の資格合格者をキープする必要があったからです。
当時は社会人になってまで試験勉強をさせられることに抵抗を感じていましたが、情報処理試験の出題範囲にあるシステム工学というジャンルの勉強は、結果的にその後ITの仕事を続ける上での土台となってくれました。
- システム開発を行うためのプログラミング言語のコードは、変数、値（リテラル）、式、制御文の4つから構成され、制御文の書き方の基本は順次処理、分岐処理（if, selectなど）、繰り返し処理（for, whileなど）の3種類であり、これらを駆使して処理手順を定型化することでアルゴリズムが出来上がる。
最初に配属された現場が銀行の海外支店のシステムを開発する部署でIBMのAS/400上で動くRPG言語とCLジョブ制御言語、次は国内支店の勘定系システムを開発する部署でIBM汎用機上で動くPL/1言語とJCLジョブ制御言語、インドネシアに来てからVB6を使ったクライアントサーバー型のシステム開発、ASPやPHP、.NET C#によるWEBシステムの開発など、仕事によって使う言語が変わっていきました。
言語によって構文の作法が異なり、コード内部に書かれるSQL文も、接続するデータベースによって若干差異がありますが、すべての基本はこのアルゴリズムです。
UiPath Studioの開発画面。左にアクティビティのリスト。
外部アプリケーションとの連携を開発プログラムで実装しようとすれば、外部アプリが開放するCOMインターフェイスを通して、プロジェクトオブジェクト（アプリケーションオブジェクト）を取得し、クラス階層をたどって目的のオブジェクトに対するメソッドを発行することで操作を実行する、というコーディング作業が発生しますが、RPAツールを使う場合は「アクティビティ」という処理（システムの振る舞い）のかたまりをフローチャートに配置することでアルゴリズムを実装できます。
RPAは業務要件をすべてツールに覚えさせる必要があるため、要件の洗い出しや業務フローの整備が避けられないのは通常のシステム開発とあまり変わりなく、その要件のとりまとめをユーザー主体でやりますので、IT企業側の仕事はRPAツールの使い方のトレーニングになります。
インドネシアのIT企業にとってのRPAビジネス
自動化をRPAツールで行う大きな理由として、システム開発するよりRPAのほうが安くスモールスタート可能、というのがありますが、これはエンドユーザー側で自動化プロセスを構築できる前提の話であり、それが可能であるのは情シスのある日本だけです。
RPAツールを使うにあたってプログラムのコーディングは必要ないとはいえ、条件や繰り返しなどのアルゴリズムの理解は必須であり、インドネシアの日系企業のエンドユーザーが、通常業務の範囲の中でRPAを習得し、自律的に業務の自動化を行うのは厳しいと思います。
これは日本企業の組織論の問題ですが、インドネシアをはじめとする海外拠点が日本本社の生産拠点や営業拠点という位置づけである以上、仮にホワイトカラー労働者の質に大差はなくとも、組織として情報システムを専門に扱う部門を持たなければ、RPAツールの導入はIT企業主導にならざるを得ません。
その場合、通常のシステム開発と同じように要件定義を行い、RPAでプロトタイプを作成し、レビューを繰り返し、トレーニングを行うという工数が発生しますので、システム開発に比べてRPAのコスト面での優位性がなくなります。
要件をとりまとめて業務プロセスを標準化する作業は、システムというより顧客側の社内社外との調整に依存する部分が大きく、顧客側の日本人担当者の指示に対して現場がすぐに動かない、現場の部門長がシステム導入に協力的でないなどの阻害要因があると、IT企業側だけでは立ち行かなくなる、というシステム開発と同じ問題が発生します。
UiPath StudioなどのRPA開発ツールは、プログラム開発者であれば容易に習得できるツールであるため、インドネシアのIT企業はRPA専用の人材を育成・確保するよりも、既存の開発者に対して、長期的にRPAの技術習得を推奨し、案件ベースでアサインしていけばいいと思います。
日本でRPAを導入する際には情シスに対するトレーニングが中心になるようですが、インドネシアの日系企業への導入では、通常の業務システムと同じようなインプリメンテーションが発生し、導入後の処理手順の変更や外部アプリの仕様変更に伴う定義の変更などに対応するための保守ビジネスが重要になると思います。
インドネシアの最低賃金（Upah Minimum Kota/Kabupaten＝UMK）は年々高騰し、日本の労働市場の給与水準は下がりつづけ、両国の間接労務費水準が近づくほど、基幹システムに実装しにくいアプリ間の連携を伴う大量データ入力処理を自動化することにより生産性の向上とポカミス削減という、RPA導入のメリットを出しやすくなります。