福本氏：　私はERPベンダーでソフトウェア開発業務に従事していました。RPAはERPとは異なり、お客さまに導入メリットを直接実感してもらいやすいソリューションである点に以前から魅力を感じていました。そんな折、BTCに勤務していた知人を通じて「BTCでRPA事業を新たに立ち上げることになったが、参画してみないか？」との打診をいただきました。

　これまでのソフトウェア開発の仕事とは違って案件の提案から実装、サポートまでを一気通貫で経験できるという点に魅力を感じて、BTCへの転職を決めました。それ以降、RPA事業部でマネジャーとして顧客への案件提案や社内マネジメントの仕事に従事しています。

富山氏：　私はBTCに新卒入社して、1年目はWebシステムの保守運用の仕事に携わっていたのですが、「お客さまにより近い立場で仕事がしたい」と考え、2年目に自ら申し出てRPA事業部へ異動させてもらいました。以来、さまざまな業界のお客さまに、主にBlue PrismのRPA製品の導入支援を行っています。

　 新たにRPAを導入する企業に向けてガイドラインの策定や社内の開発要員の育成などの支援を行ったり、既に導入済の企業に対して製品ライセンスの最適化および利用規模拡大のためのアドバイスやコンサルティングなどを行ったりしています。

福本氏：　私も提案活動やマネジメント業務の傍ら、RPAの導入を検討している企業に、RPA化に適している業務についてアドバイスしたり、業務の特性に応じたRPA製品の選定を支援したりするなど、上流におけるアドバイザリーやコンサルティングを提供しています。

──やはり業務によっては「合うRPA製品」「合わないRPA製品」があるものなのでしょうか。

福本氏：　製品ごとに特徴や機能差、サポート体制の違いなどがありますから、適用する業務の特性やお客さまのニーズと照らし合わせながら最適な製品を選ぶようにしています。ただし現在ではRPA製品市場の成熟化がかなり進み、ベンダーも他社製品を研究しつつ自社製品に足りない部分を補強してきているため、製品ごとの機能やサポート体制の差はかなり小さくなってきています。

「夜中に人がRPAを見張る必要が出てきた」　失敗の原因は？

──お二人はこれまで数多くのRPA導入プロジェクトを経験されてきたと思うのですが、RPA導入プロジェクトで苦労したエピソードなどはありますか？

富山氏：　私はRPA内製化プロジェクトを支援させていただく機会が多いのですが、内製開発の担当者としてアサインされた方は別の業務を兼任されていることが多く、限られた時間と工数の中で開発の成果を出さなければいけないというプレッシャーにさらされて、見ていて「気の毒だな……」と思うことが多々あります。

──そういう方が挫折しないよう心掛けていることはありますか？

富山氏：　開発に不慣れな方がつまずきがちなポイントを先回りしてアドバイスしたり、環境を整えたりといった支援は当然行います。でも成果がなかなか見えないとモチベーションが持続しませんから、最初に着手する案件はなるべく規模を小さく抑えて、成果が早い段階で表れるよう工夫しています。

福本氏：　私はお客さまの「期待値」を適切にコントロールすることを常に心掛けていますね。先ほども申し上げた通り、RPAは外的要因の影響を受けやすい不安定な仕組みなのですが、お客さまの中には他のエンタープライズ向けシステムと同等レベルの高い可用性や堅牢性を期待される方もいらっしゃいます。そういう方に対してRPAの特性やサービスレベルについてきちんと説明して理解を得ておくことで、導入前の期待値と導入後の実態との間のギャップが生じないよう心掛けています。

　これは笑い話のような事例なのですが、とある企業では朝一番に役員に見せるレポートを、前日の夜間にRPAロボットを動かして自動作成していました。でも「役員に見せるレポートの作成は絶対に失敗してはならない！」という理由から、そのロボットがきちんと動いているかどうか夜間に人がずっと監視するというオペレーションを続けていました。本来は人手の作業を自動化するために導入したロボットのはずなのに、そのロボットを監視するためにまた人を張りつかせるというまったく本末転倒なオペレーションがまかり通っていたわけです。

──「100％止まらないロボットはない」というRPAの特性をきちんと理解していれば、そのような本末転倒な状況は生まれなかったでしょうね。

福本氏：　そうですね。絶対に失敗してはならないクリティカルな業務には、RPAはあまり向いていないと思います。またRPAを適用する場合でも、処理が途中で止まる、エラー終了してしまうケースをあらかじめ想定して業務設計をしておかないと、いざ導入した後に何かと問題が生じることが多いですね。

RPAが「定着した」といえる目安は？

──逆に「この案件はうまくいった」と感じたプロジェクトはありますでしょうか。

福本氏：　RPAは一般的なパッケージソフトウェア製品とは異なり、それ自体で何か独自の価値を提供するものではありません。既存のシステム同士を連携させ、人手に頼ってきた作業を自動化することが目的ですから、日々使われ続けることで初めて効果を発揮します。つまり「ツールを開発・展開して終わり」ではダメで、業務現場に定着した時点で初めてプロジェクトが成功したと言えます。

──何をもって「きちんと定着した」と判断されているのでしょうか。

福本氏：　RPAはその特性上、業務の変化やシステムの仕様変更といった外的要因の影響を大きく受けます。外部要因の変化や業務の要請に応じて、適宜改善を加えていくことが定着のコツです。加えて、こうした改善や維持、運用を外部のベンダーに頼り続けていると多くのコストと時間がかかってしまうので、最終的には社内でまかなえる体制を構築できればベストです。

　多くのRPAツールは、ITの専門知識がない人でも比較的容易にシステムを開発できるようになっていますから、私たちのようなコンサルタントの支援の下に社内の開発人材を育成して、RPAの開発・運用を“自走”できるようになればそのプロジェクトは成功したと言えるのではないでしょうか。

富山氏：　そのためには何より、お客さまとの良好な関係性の構築が重要だと考えています。ただ単に言われたことをこなすのではなく、相手の立場に立って物事を考えながらプロアクティブな提言をすることで「対等なビジネスパートナーとしての関係性」が築けますし、ひいては継続的な関係を構築できると考えています。

──ITコンサルタントという職業に対して、憧れを抱いている方も多いかと思います。実際にこの仕事を経験されて、どのような実感をお持ちですか。

富山氏：　憧れの職業であるかどうかはさておき、個人的には「答えがない問題に対して答えを探していく」という点にとても魅力を感じていますし、実際日々の仕事を楽しんでいますね。その一方で、クライアントの意思決定をサポートしていくに当たっては、クライアントが意思決定を下す際の「評価軸」「決定基準」がなかなか推し量れずに苦労する場面もまだまだ多いです。先輩のコンサルタントは皆さんこの辺りに長けているので、自分もこうしたスキルを磨いていきながら、将来的にはRPA以外のソリューションも含めた幅広い提案ができるコンサルタントを目指していきたいですね。

福本氏：　私はITコンサルタントという職業を「ITとユーザーの間に橋を架ける人」だと捉えています。企業の業務現場や経営陣の方々はITの詳しい知識は持ち合わせていませんし、ITの専門家はユーザーの業務に関する知識はありません。この両者の間の通訳を務めて正確な意思疎通を図ることが、ITコンサルタントの最も大事な仕事の1つだと考えています。

　将来的にITシステムが現在よりもっとユーザーフレンドリーになって、業務現場の一般ユーザーでもシステムを理解できるようなればこうした役割は不要になるのかもしれませんが、これが実現するのは相当遠い未来の話になるでしょうから、やはりITコンサルタントという存在は今後も必要とされ続けるだろうと思います。

RPAは「マッチポンプ」か　SaaS利用の拡大で見えてきたこと

──DX（デジタルトランスフォーメーション）に本格的に取り組む企業が増え、デジタル技術による業務効率化が叫ばれるようになった今、RPAに寄せられる期待も高まっているように見えます。

福本氏：　多くの企業がDX推進のためにSaaSアプリケーションを積極的に導入した結果、SaaSのデータ連携をRPAで行うというニーズが増えつつあります。このこと自体は、RPAビジネスの成長という面では歓迎すべきことなのかもしれませんが、一方でエンタープライズシステムの「本来あるべき姿」という観点から見ると、必ずしも良いことばかりとは言えない気もします。

　用途ごとにアプリケーションをばらばらに導入し、その連携のために手間を掛けてツールを入れるというのは、見方によっては「マッチポンプ」と捉えられても仕方ないかもしれません。こうした流れは当面の間は続くのでしょうが、個人的にはいつかは潮目が変わると思っています。そのときにはRPAとは別のソリューションが台頭しているかもしれませんね。

──ありがとうございました。