【事例】よくあるRPA導入の課題と、情シスへの入社間もない転職者が担当する際のケアすべきポイント

SIerやコンサルから大手事業会社の情シス等に入社後、まずはRPA導入を期待されることもあると思います。RPAを採用する日本企業は増加の一途、とRPAツールの紹介パンフレットにもよくうたわれていますので、導入に携わる機会も実際に多いことでしょう。

「現場の業務に精通したメンバーが、業務プロセスのカイゼンを自ら進め、生産性向上を実現していく。使われない無駄システムのように、現場業務を知らない開発ベンダーやシステム部門が押し付けたものとは一線を画す業務プロセスの自動化が実現！現場も経営者もみんなニコニコ大満足。」と良い面だけを見て飛びついてしまうことも実際多いのではないでしょうか。

今回の記事では、大手事業会社に入社間もない情報システム部門への転職者がRPA導入について実務を任された場合につまずきがちな具体的なポイントや、失敗例、その乗り越え方について、まとめてご紹介します。

【目次】

1. ゆるいRPA導入のきっかけの裏にトラップが潜んでいる
2. ケース①作りきれないやりきれない
3. ケース②やりすぎ君、職人さん化による問題発生（RPAロボット増殖やメンテナンス課題）
4. ケース③RPAロボットの暴走
5. ケース④自動処理プロセスの異常停止や異常動作に備える運用設計がされていない
6. つまずきからの脱出の最終手段：RPAからの勇気ある撤退
7. 君子危うきに近寄らず」も一つの手

ゆるいRPA導入のきっかけの裏にトラップが潜んでいる

簡単におさらいですが、RPAとはRPA（Robotic Process Automation)の略で、PC上で行われる作業を、あたかもロボットが人に代わって操作しているかのように自動化する技術、という認識が一般的ではないかと思います。

PC上でひとつのシステムにログインしそこで情報を得て、別のシステムツールに入力する、といった二重インプット作業の回避、自動化がRPAツールでは簡単に実現できます。専門的なシステム構築の知識がなくても、作業の自動記録やユーザーフレンドリーなGUIでプロセスの自動化を可能にします。業務現場のメンバーが開発ベンダーやシステム部門の手を借りずに自分自身で構築可能にするツールです。

RPA導入を担当することは、情シスに転職して間もない入社後にも頼まれがちな案件かもしれません。RPAに対しての知見が情シス部門に蓄積されていたり、部門責任者がRPAの功罪について明るい場合やRPAを既に導入活用できている場合はそう問題ないでしょう。

しかしながら、導入が初めてである場合や導入したけれども活用が進んでいない場合などに担当を任される、しかもRPA導入のプロジェクトリーダーとして任命されてしまった場合は少々厄介です。職務経歴書にRPAに携わった経験アリが本物であれば問題ないですが、ちょっと盛って書いてしまっていた場合は要注意です。

現場主導、現場での開発、GUIで簡易なシステム構築が可能とされるRPAツールは現場での業務改善プロセスが自律的に進んでいくだろう、という根拠のない期待が持たれてしまっています。

入社間もない情シス部門転職者にとっても、特段、既存の社内システムにいますぐ詳しくなくてもRPA導入を任せても大丈夫だろうし、おいおい理解して社内のことにキャッチアップしていく途中段階でも並行して担当できるだろう、ぐらいに捉えられている場合は危険です。

「業務に関しては現場が熟知、かつ現場発の業務改善プロセスなので問題もない。またウォーターフォール型の業務システム開発とも違って、RPAツールではシステム修正も容易かつ現場対応でも可能なメンテナンスフリー、ぐらいに楽天的に考えていたんだけど、なんか上手く進んでいないのでちょっと現場に入り込んで見てもらえるかな、ちょっと他のメンバーは手が取れなくて。」

この機会に現場も学んでくれ、現場の人脈も作っておこう的な軽いノリで上長から任されてしまうシーンも想像に難くありません。

ゆるいRPA導入のきっかけの裏にたくさん潜むトラップをいくつ挙げることができるでしょうか。以下、ここではRPA導入に関するつまずきの事例を具体的に紹介し、その簡単な乗り越え方、つまづき前の打ち手のポイントも併せて紹介していきます。

ケース①作りきれないやりきれない

現場主導で構築可能、が実際のところRPAのロボットを上手く作りきれないというケースです。実際に業務の自動化プロセス化で改善が必要な現場は実務で忙しく、なかなか時間を割くこともままなりません。また若干取り組んでみて出来たとしても、簡単なプロセスぐらいで現場対応可能ものは作れたが、でも実際の業務改善までのレベルのモノの構築には至っていない状況が起きがちです。

RPAツール導入コストを回収するために、結局いつの間にかRPAロボット開発を情シス部門から派遣された自分がやっている、業務を知らないのでポイントも掴みにくい、といった本末転倒な事態に追い込まれてしまうこともあるでしょう。問題の解決が必要です。

実際、導入部門が決まってしまっていて、既にツールも選定済み導入済み段階まで進んでしまっている場合は体制面の見直しを行う以外の手段はないでしょう。早々に上長に相談し、忙しい現場のメンバーの時間を週数時間だけワークの時間を持ってもらい、業務プロセスのヒアリングを行いましょう。アジャイル的なRPAロボット開発を自分がやってしまうのか、RPAツールの販売代理店と相談して開発支援が出来る、または外注委託できる先を見つけるしかありません。

あまりRPA導入プロジェクト自体の見通しは明るくなさそうです。RPA導入メリットとして期待した現場での自律改善が回らない状況となってしまっているのがその理由です。システム導入で属人化が前提、という何だか腑に落ちない状況がRPAのパラドックスのひとつかもしれません。

そもそも、導入に適している現場とはRPAロボット構築を現場で推進できるメンバー候補が実際いて、モチベーション高く部署内の業務改善を推進してくれることが前提です。そうでないとRPA導入活用プロジェクトはそもそも成功裡に導かれないでしょう。

現場改善が自律的に回る業務現場の選定自体が重要です。これは入社直後の転職者には荷が重い役割です。業務プロセスの棚卸しとシステムを通じた効率化ではなく、人の特性を見極めたプロジェクト組織の組成がRPA導入の重要成功要因であるからです。

ケース②やりすぎ君、職人さん化による問題発生（RPAロボット増殖やメンテナンス課題）

発生しがちなRPA導入時の「野良ロボット」課題です。現場にソフトウェアを導入する際に付きまとう典型的な課題です。企業に必ず数名は存在するExcel職人、マクロ職人の課題と本質は同じです。

RPA導入で業務効率化を進めるためのロボット開発自体が残業オーバーを導き、部門や会社の生産性を落とす本末転倒の自体を招いたり、ツール開発が個人に依存する状況でブラックボックス化してしまう状況です。

ロボットファイルが作成者以外に誰もわからない、誰も知らない状況で増産されていきまが、そんな状態の中で、ロボットファイルを作った人が異動や退職してしまうことで飼い主不在の野良ロボット化が起こります。RPAロボットが作業するシステムや環境のアップデートにより、画面レイアウトや入力ルールの変更を受けた際にメンテ不能に陥るケースです。

現場でのRPA活用ガイドラインの手落ちが指摘されるでしょう。現場主導といっても野放図に開発をさせることを回避しないといけません。予見された野良ロボット化課題が発生する前に、定義のドキュメント化や注記のルール化などを事前に現場教育することが必要です。導入済みであっても、ロボットファイルの増殖前に後付けでも開発手順に必ずロボットについて形式知化するルールの定着化が重要です。しかしながら現実的にはハードル高い仕事となるでしょう。

ケース③RPAロボットの暴走

自動プロセス化する重要なものに、システムへのログインをRPAロボットが行うというプロセスがあります。自動化するプロセスに必要十分なだけのリソースへのアクセス権限を管理しなかったために、人事情報が流出してしまうなんて事態も十分に起こりえます。何にでもアクセスできるアカウントが必要と、ロボットファイル用に安易に渡してしまっていたアカウントで、開発者がRPA以外の目的で悪意に利用してしまうことを未然に防ぐことがマストです。細かい権限管理を手間を惜しまずに、また善良な人であっても、出来心が発生しないようにアクセス自体を不可にしておくのがシステムの志向として重要です。

自動化ファイルの暴走も未然に食い止めなければなりません。プロによるシステム構築のように検証環境ではなく、本番環境でそのまま開発するRPAの特性からも事前に危険な行為を避けておく必要があります。

顧客に対してメールを自動返信する、といったRPAロボットでの業務効率化例などがありますが、大量のメールを誤って発報したり個人情報の流出なんてことも最悪のケースでは起こりえます。ダミーアカウントを使って、実際の本番稼働前にやってみるテストも必要ですが、現場にその知見はないことを想定しておかねばなりません。ロボットファイルの開発管理、本番リリース管理が必要です。システム管理者としての不行届を問われてしまいます。

ケース④自動処理プロセスの異常停止や異常動作に備える運用設計がされていない

高速処理を得意とするサーバー型RPAツールでは異常停止や異常動作に備えたオンサイト保守が必要です。重要な業務プロセスやそれなりの処理の規模、締め処理などをRPAロボットが担えば担うほどウォーターフォール型業務システム開発に近い運用設計が必要となります。ほぼ現場主導の開発といった状態を離れていることでしょう。

ここまでのレベルの業務プロセス自動化において、そもそもRPA導入が必要だったか？という疑念が沸き起こってくることでしょう。適切なツール選定であったかの視点として、システム間で、どうしても外部連携出来ないレガシー型システムや自社が手を入れられないシステム作業の業務プロセスがあったかどうか、というところです。

自動化するに当たってどうしてもRPAが必要な自動化プロセス、他にオプションがない状況であればRPA導入運用コストも正当化できる余地もあるでしょう。普通に特段の事情がない場合、自社内のシステム連携であれば、I/F設計し集信される側から適切に必要データを吐き出し、バッチ処理をジョブ管理システムでスケジュールし、処理実行させる機能を配信側システムに持たせて構築するといった極めて普通のシステム改修の機能追加でよかったのでは？と、後出しジャンケン的に指摘されてしまうでしょう。

つまずきからの脱出の最終手段：RPAからの勇気ある撤退

良い面だけ見てシステムツールの導入が意思決定されていて、ダークサイドのリスクは関知していないことが多々あるという典型的な失敗事例の一つとして、RPAの導入も該当する場合が往々にして起こります。

RPA導入の部分だけをシステム部門に所属する自分の仕事と思って、Sier時代のように割り切った進め方をしてしまうと事業会社では事故が起きてしまいます。RPA導入してビジネスプロセスの改善が進み、人員削減や残業圧縮などPLにプラスの数字として見えるキャッシュアウト抑制がなされつつ、現場の利便性や業務キャパシティが広がるといったシステム導入に対する現場満足も両立されて初めて導入が成功と言えるでしょう。

RPA導入は手段であって目的ではないこと、小さいプロジェクトでもリーダーとしてアサインされたのであれば、プロジェクトの目的はビジネス効率の改善であることをセットし見失わないことが重要です。

場合によっては、RPA導入では解決しないことを伝え説得し、撤退コストが嵩まないうちにシステム連携改修でのプロセス自動化への方針変更、RPAからの勇気ある撤退を意思決定させていくというPMからプロジェクトオーナーへの現実的な提案もいざとなれば選択することを視野に入れておくべきです。プロジェクトオーナーへの提案や説得には投資対効果、蓋然性のあるプロジェクトの収支試算の見通しが必要です。しかしながら、数字は経営層にとっては雄弁ですので、逆に根拠に裏付けられた数字であれば長い論説は不要です。

「君子危うきに近寄らず」も一つの手

RPA導入のハードルは低く飛びつきやすいものの、ビジネス的な成功に導くのはなかなか難易度が高いというのが個人的な見解です。ある程度の規模を持つ大手企業であれば、しっかりと全体的に俯瞰したシステム設計と構築、それなりの運用保守を前提とした業務プロセスの自動化に軍配が上がるでしょう。

RPA導入で効果が見込めるのは、その自動化プロセスに対してシステム投資がツーマッチだったり、そもそも自動化できるシステムではない、レガシー系基幹システムや社外のシステムがプロセスに入っている場合などI/F設計で解決不能な場合です。

社外システム、取引先企業のシステム入力がマストだったり、取引先企業の情報を転記、二重インプットすることが回避できない場合には規模感が一定以上の大手企業でもRPA導入の十分な理由として成り立つでしょう。I/F不可能なシステムを連携させるというRPAの有用な機能が唯一の解決法だからです。

スモールビジネスに対するソリューションやレガシー系システムが刷新されるまでの少し長めの暫定対応として数年の使用後に除却しても十分にROIが取れる場合はRPA活用での自動化は十分に合理性があります。どちらも費用対効果の設計が肝になる上に、RPA活用を暫定対応とする場合には中長期のプロジェクトマネジメントが必要となってきます。

RPA導入は日本企業では盛んであることが代理店のカタログにキャッチコピーとして散見されます。裏返せば、本質課題を先送りして対処療法的に進めてしまう、経営視点でシステムを刷新することを避けがちな日本の企業体質みたいなものが投影されているのではないか、と言うのは言い過ぎでしょうか。

やや逸れましたが、簡単にまとめると大手事業会社のシステム部門に入ったばかりの時に任されてしまいがちなRPA導入は実はなかなかなシロモノです。入社したばかりでは手に余る案件のひとつです。ネガティブな姿勢ではありますが、一番の打ち手は、君子危うきに近寄らず、ということでRPA導入のプロジェクトリーダーは避ける、先輩や上司にPMやリーダーは託していちプロジェクトメンバーに徹する、のもアリかもしれません。

=================

＞情シスのキャリアに関する記事

【実話】SIerのSE・PMから情シスやDX推進部への「転職後のよくある落とし穴」と「対策」
https://www.axc.ne.jp/media/careertips/sepmcareerchangetips

“SE・PM”から”事業会社”転職後【年収1000万×部長職級】にたどり着くための具体的なスキル・経験とは
https://www.axc.ne.jp/media/careertips/sepmannualsalary1000

=================

今回の記事では、RPA導入における課題と、入社間もない情報システムへの転職者が担当する際のケアすべきポイントについてご紹介しました。

キャリアでお悩みの方は、ぜひアクシスコンサルティングにご相談ください。