１０月９日　kintoneとRPA

１０月９日ですね。

昨晩、どうしても仕方なく、pythonとseleniumでRPA的な動きをするコードを突貫で作りました。AIの力を借りながら一時間ほどかけて。

やりたい動きはそう難しくなく、kintoneにアクセス&ログインし、あるアプリの特定条件で一覧を絞り込み、2000件ほどのレコードを一つ一つ開いては再保存するものです。

なぜこういう動きをさせるかと言うと、Webhookを経由してAWS Lambdaで動くロジックがあり、AWS Lambda側のLogicを変えるのが面倒だったからです。また、CSV読み込みではWebhookが動作しません。
そのための苦肉の策です。

今回は、AWS Lambdaのコード内で、あるSaaSに対してさらに複雑な処理をさせているため、Webhook経由の処理が必須でした。

本来、kintoneはAPIを使うか、CSVの入出力でデータを取り扱います。
ところが、今回の動きはいわゆるRPA的な動きをさせています。

先日、DX総合EXPOを訪れました。会場の中で、RPAをメインで扱うブースはあまり見かけませんでした。
各ブースで展示されているSaaSの中にはRPA対応を謳っているものも散見されましたが、表立ってRPAを謳うサービスは一時期の隆盛をへて、ひと段落ついたのでしょう。

RPAとAPI連携は、対立軸のように言われます。どちらを選ぶか。kintoneを扱う際は、上に書いた通り通常はAPI一択です。
裏側で見えないうちにAPIでデータを加工する、ある意味スマートなやり方です。

それに比べてRPAは表立って動きを再現します。
つまりオペレーターの操作をそのままなぞります。
私は以前、RPAの利点とは目で見える処理を行うことにあると考えていました。
つまり、何が行われているか分からないAPIよりも、現場のオペレーターにとっては普段の操作を確認できるため、RPAの方が安心で、それが支持されるということです。

私が昨夜作ったロジックも、一件一件開いては保存していて、その姿に健気さと愛おしさを感じました。

ただ、効率性から考えるとAPIに軍配を上げるほかありません。

実際、RPAの使い道を考えると、APIが備わっていないレガシーシステムからデータを取る用途か、スタンドアローンのデバイスに保存する用途か、メール送信をする用途のどれかです。
またはなんらかの理由でAPIが使える環境なのに技術的に費用的につかえないとか。

つまり、RPAは　APIが利用できない環境でこそ効力を発揮します。

ですが、その用途は、使うシステムがクラウドに置き換わり、保存もOneDriveなどに置き換っていくにつれ、不要となります。
これからはデジタルネイティブの世代が主力になるでしょうから、API設定も軽々と行ってくれるはずです。

なので、RPA界隈でも名の知れたサービスは、APIも使え、iPaaS的な方向に進化しています。

今回の実装は、私にRPAの使い道の新しいパターンを教えてくれました。

私たちもその辺りを知見を溜めながら、適切な構成をお客様に提案したいと思います。