アスタリスト株式会社の代表をしております池上と申します。
この度、国内初の財務会計領域特化型のクラウドネイティブなエンタープライズiPaaS*「ActRecipe（アクトレシピ）」をリリースさせていただきました。同時にこれまで続けてきたRPAの事業をやめることにしましたので、その理由をお伝えしたいと思います。
今回リリースしましたActRecipeのサービス概要は以下をご参照ください。

*iPaaSとは
iPaaS（integration Platform-as-a-Service、略して「アイパース」と読みます）は、「クラウド統合プラットフォーム」とも呼ばれるクラウド上で企業様のデータ統合を構築・展開するためのプラットフォームです。用途に応じたクラウドサービス利用の急激な進展によって、企業様のデータはあらゆるサービス内に点在しており、そのデータ統合は日々複雑化しております。iPaaSは、クラウドサービス間のデータ連携をニーズに合わせて拡張・縮小可能とすることで、業務プロセスの最適化とトータルコストの削減にお役立ていただけます。

ActRecipeは
・（最初は）財務会計領域に特化している
・クラウドネイティブでAPIがぐるぐる動く
・（エンタープライズ）企業向け
なiPaaSですので、個人で利用されることは想定しておらず、業務系のSaaS間をシームレスに繋ぎ、企業のデータ連携のインフラとしてご利用いただけるように企画・開発しています。
AcrRecipeの最大の特徴は、その名の通り「使えるRecipe」を備えていることです。iPaaSには「integration」が含まれますが、従来のようにSIerさんが都度開発するようなことは必要なく、更にお客様がRecipe（ワークフローやテンプレートのようなもの）を作成することなく、事前に用意されたRecipeを選ぶだけでSaaSやクラウド間の連携を実現できる究極のシンプルさを目指しております。なぜRecipeかは後述します。

(※開発中のActRecipeの画面イメージです)

RPAを捨てる理由

さて、なぜRPAの事業をやめるに至ったかについてお話ししたいと思います。
RPAとは「Robotic Process Autimation」の略で、人がPC上で行う作業を代替してくれるソフトウェアのことです。マウス操作とか文字入力とか、「面倒なことはロボット（ソフトウェア）にやらせよう」という感じです。ざっくりと。
アスタリストでは2017年に「Asterist RPA」として、複数のRPAツールを用いたコンサルティングサービスを開始しておりまして、これまでに複数のお客様へRPAの導入をさせていただきました。
処理対象次第では、便利になったりミスが減ったり工数が減るという効果がありましたが、よくよく考えてみると「そもそもRPAじゃなくて良いのでは？」というケースが多々ありました。つまり、手段の置き換えになっていただけ、というわけです。

ここ数年でRPAの事例は多数発表されていますので、その実例の一つを数字だけ変えて検証したいと思います。

例えば「年間1万時間削減できました」という事例を紐解いてみると「一人当たりの労働時間は年間約2,000時間（内訳：1日8時間x20日x12ヶ月=1,920時間）」なので1万時間の削減は5人分にしかなりません。（ちなみにこのケースでの利用企業の売上は550億円です。人件費換算しても限定的であることがわかるかと思います。）もちろんRPAを手放しで運用できることはないので、5人分の工数が完全に浮くわけではありません。5人分の工数を削減するためのツール代と導入工数（の費用換算）を算出すると、おそらく初年度は赤字でしょう。日進月歩なIT業界において「2年目から少しずつ効果が出ます」なんてことをしていたら競争力は生まれず時代に置いていかれるだけです。最後に笑うのはツール屋さんと導入屋さんだけで、お客様へのメリットは極めて限定的どころかマイナスにもなり得ます。弊社のお客様でも工数やコストの削減に向けて試行錯誤をした結果、残念ながらRPAが適さなかったケースがあります。
SaaSをはじめとするクラウドサービスが多用されている中で（主に）デスクトップツールのRPAを使う意味がどこにあるのか疑問符が付きまして、試行錯誤をした結果、この時代においてRPAは本質的な解決策にならないと判断し、事業をやめることにしました。（既存のお客様サポートは継続しますのでご安心ください）
RPAや自治体や処理業務を大量に行っている一部の領域や金融機関等には有益であり残り続けると思いますし、クラウドに置き換えられない場合には手段として必要になると思いますから完全になくなることはないでしょう。しかし、一般的な民間企業の処理業務にRPAを使う必要がないことはもはや明らかではないでしょうか。

なぜiPaaSか？

世の中にはクラウド上で動くRPAツールやサービスもありまして「クラウドとクラウドを繋ぐのであればそれらでも良いのでは？」と思われがちですが、SaaSのように常にトレンドに合わせて最適なUIが適用され続けるシステムに対するRPA（定型処理）は入り口で破綻していますし、RPAの考え方は人の代替ですのでAPIでのデータ連携のようにそもそも処理に人が介在しない場合はRPAじゃない感が強かったのです。
既に世界にはエンタープライズ向けからパーソナルユースまで数多くのiPaaSがリリースされています。ここではあえて言及しませんが、国内にもいくつかiPaaSがあります。中にはオンプレミスのデータ連携ツールをクラウドに持って行って「iPaaS」としているものもあるようですが、クラウドネイティブ（クラウド上での利用を前提して設計されたシステムやサービス）でないデータ連携サービスをiPaaSと呼ぶのは、かつてのASPをクラウド呼ぶのと同じで少し違和感が残りますが、ここはいずれカテゴライズされるでしょう。
日本にも世界にも優れたSaaSがたくさんありますので、iPaaSによってそれらのSaaSをもっともっとシンプルに連携することができれば利便性も生産性も向上しますし、本質的なコストの削減と競争力強化に貢献できるのではないかと考えています。加えて、弊社で日本一の実績を誇る出張・経費管理のSaaSである「SAP Concur」や決算業務の省力化SaaSの「BlackLine」の導入コンサルティングを通じて、データ連携の煩雑さが目についたこともiPaaSへ舵を切る理由の一つでもありました。ActRecipeを「財務会計領域特化」としているのは、弊社の既存事業とのシナジーもありますが、財務会計の領域はどの企業様にとっても必要かつ重要な業務のため、厳しい条件をクリアできるサービスに育てる目的もあって選択しました。既に最先端のクラウドを活用される上場企業様でのActRecipeのPoCが進んでおりますので、近日中に導入事例もご紹介できるかと思います。

Recipeって何？

次にサービス名の「ActRecipe」について。
イメージするのはレシピサイトやレシピの動画サイトではないかと思いますがいずれも関係ありません。。
「Act」は「働く、ふるまう」の意味を、「Recipe」はそのまま「調理法」の意味を持たせている一方で、「ActRecipe is Already completed technical Recipe.」（意：完成した技術レシピ）という意味合いもあります。これまでのiPaaSは「キッチンと調理器具と食材はあるから好きなように料理をして」というもので、ActRecipeは「高級レストランの冷凍食品を提供」という感じでしょうか。レンジでチンするだけで食べられるほど完成されている上に味も十分なので好みの味付け（カスタマイズ）は最小限で良い、という感じです。
ではなぜサービス名にRecipeを付けたのかと言いますと、スペインの「サン・セバスチャン」という街の出来事に由来します。

スペイン北東部にあるフランス国境にも近い、人口わずか18万人に満たない街、サン・セバスチャン。10数年前までは目立った産業もなく観光資源も存在しなかったが、現在はミシュランの一つ星レストランが4店、二つ星レストランが2店、そして三つ星レストランが3店もあり、人口一人あたりのミシュランの星の数はダントツの世界一。世界中から観光客や美食家が詰めかけるまでになった。（人口18万の街がなぜ美食世界一になれたのか―― スペイン サン・セバスチャンの奇跡より要約）

Q.なぜサン・セバスチャンは短期間で世界一の美食都市になれたのか？

短期間で成功した理由は、料理業界の伝統的な弟子制度を廃止し、外国で料理の勉強をして身につけた技法や世界を旅して学んだ料理の知識を故郷に戻ってみんなで共有し、教えあうことで、一軒のレストランだけではなく、街全体が美食都市として急成長。手法やレシピを独占せずに共有するという「料理のオープンソース化」をすることで、新しいスペイン料理がどんどん生まれ、若い有名なシェフが次々と育っていった。（同）

A.レシピを公開した

従来のSIでは、同じプログラムであっても個社ごとに開発をしていたため、社会全体でみると時間とお金の無駄が発生していました。また、顧客の資産であるソフトウェアを簡単に公開することができないために、まさに弟子制度のように新しい空気も取り入れないままに受け継がれてきたのではないかと思います。当然提供者が変わったりお客様が変わるとその都度開発をしているわけです。ActRecipeでは、処理フローを「レシピ」としてオープンにすることで、利用される方の集合知を全てのサービス利用者のメリットに繋げられる思い、サービス名にRecipeを加えています。
ちなみにこの「サン・セバスチャン」の出来事は高城剛さんの本や各種ブログ、テレビ番組でも話題になりました。以下の本はとても読みやすいのでご興味がありましたら読んでみてください。（サン・セバスチャンに行きたくなると思います）

実は他にもワークフローやテンプレートのことを「Recipe」と称されているiPaaSもありまして、名称だけ切り取ると丸被りなのですが、ActRecipeは「使えないレシピは公開しない」という方針で展開する予定です。イメージとしては、「アプリの審査があるApp Store＝ActRecipe、審査がないGoogle Play＝他のiPaaS」といったところでしょうか。レシピが大量に公開されていてもそれをそのまま使えなかったり、追加で費用が発生してしまっては本質的にユーザの方のメリットには繋がらないと考えております。使えるレシピを揃えるにはそれなりに時間も手間もかかりますが、「サン・セバスチャン」のような魅力的な存在になるにはやむを得ないと考えています。

APIエコノミーについて

iPaaSは下図のようにAPIでSaaSやクラウドを繋ぐことがメインなので、ActRecipeもレシピだけに拘るわけではなくお客様が自由にSaaS間をシンプルにAPI接続できるような仕組みを準備しています。

出展：Crisp Research

例えば単純に「Gmailに届いたメールをSlackに通知する」ような連携は既にSlack社が提供されているため、いわゆる「車輪の再発名」はしません。また、それ以外にも単純なAPI接続であれば海外製品で実現ができているため積極的に取り組むことはしません。
我々がすべきことは国内外の業務系SaaSをシームレスに接続することで、特に海外のiPaaSが対応していない国内SaaSの連携を積極的に進めたいと思っています。既に数社のSaaS事業会社さんにアプローチをさせていただいており、ポジティブな反応をいただいているので順次サービスリリースができると思います。もしこの記事をお読みの方で「うちのSaaSのレシピも作ってよ」という事業者の方がいましたらお気軽にご連絡頂戴できればと思います。

最後に

最後まで長々とお読みいただきましてありがとうございます。
iPaaSの日本における認知度はまだまだ高くありませんし、その事例も表には出てきていません。タイムリーに弊社のような新しいサービスをされている会社が数社あったり海外製品が日本に入ってきたりしておりますので、今年以降はiPaaS界隈が非常に盛り上がるのではないかと思います。国内外のiPaaSが増えれば当然競合もすると思いますが、健全な競争は社会にとってプラスですので、互いに切磋琢磨していこうじゃありませんか。我々も良いサービスをお届けできるように精進します。そのためにもActRecipeを盛り上げてくれるエンジニア・セールス・カスタマーサクセス・アドミン等の人材が必要です。「iPaaS面白そう！」と思ったあなたからのご応募をお待ちしております。
ActRecipeの今後にご期待ください！

最後の最後に、以下のイベントにてそれぞれスポンサーとして出展や講演を行います。InTheBlackは展示を、SAP Concur Fusion Exchangeでは講演と展示を予定しております。どちらのイベントでもActRecipeのご紹介をしますのでご興味がある方は是非お越しください。お待ちしております。

InTheBlack TOKYO
日時： 2019年8月29日（木）
　特別ユーザーセッション 10:00-12:00（受付開始 9:30AM）
　第1部 カンファレンス 13:15-17:00 (受付開始 12:30PM)
　第2部 ネットワーキングパーティ 17:00-19:00
場所： 特別ユーザーセッション
カンファレンスルーム 4F
InTheBlackカンファレンス&ネットワーキングパーティ
東京 ミッドタウン カンファレンスホール B1F
主催： ブラックライン株式会社
協賛企業： EY Japan・アスタリスト株式会社・SAPジャパン株式会社・KPMGジャパン・アビームコンサルティング株式会社
参加費： 無料（事前登録制）
対象： CFO/経理財務部門、情報システム部門、監査法人、パートナー

SAP Concur Fusion Exchange Tokyo
日時：2019年9月10日（火）
場所：グランド ハイアット 東京
セッション：12:30 - 13:00　ランチセッション / ランチブレイク
「導入実績日本一のアスタリストによる革新的なiPaaSを用いた自動化 」