20
17

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

RPA導入前にまず考えておくべきこと

Last updated at Posted at 2019-12-11

はじめに

RPA(Robotic Process Automation,業務の自動化)って
魔法のツールのように思われちゃうか「使えねぇな!!」って言われるかの二極化しがちなんですが
あれもこれもできる、そうRPAならね(実際はRPAツールだけでやっているわけではなく、他のツールと組み合わせたりしている)という広告を真に受けすぎていたり
プログラミング分からなくても大丈夫!!かんたん!!と勘違い
⇒話が違ってがっかり、ルートをたどってしまってたりというのが多いので、
今回はその辺の誤解を解いていきたいと思います。
(なお、アドベントカレンダーの日付を1日間違えました…すみません!)

前提:RPA業務の4分類

(表現の仕方の差異はあれど、皆大体似たようなこと言うかと思われます。
いきなりデカいヤマに手を付けず、大きなタスクを洗い出し・分解して
小さなタスクとしてスモールステップで作っていくのが王道ですね。)
4分類.png

1.決めていますか?音頭を取る人

何ならこれが全てと言っても過言ではないです。
この場合の「音頭を取る人」というのは「RPA導入だ!」と言っている偉い人…の事ではなく
実際的に以降の要件定義や設計を行い、実際のプログラミングを指揮する人の事です。
ちゃんと「ある程度の決定権」とセットにしてあげてくださいね。
ここがはっきりしていないと後の工程で大変つらい目にあいます(主にエンジニアが)。
また、会社としても「思ったよりRPAの効果が出ない」という事になり、誰も幸せになりませんので
ここはきっちり決めて、かつ定期的に見直しをしてください。

よくある例

  • EU(エンドユーザー)部門でEUCだ!!と、業務担当者(非エンジニア)に丸投げしてしまう。
    • 業務量の見積もりを正確に算出することが出来ず、一人に負担が集中します。RPAを憎悪する人間がまた一人生まれてしまうのでやめてください。
  • 派遣エンジニアに丸投げする。
    • 社内の業務・部門などが分からない派遣エンジニアに、きちんとした業務の洗い出しをしないまま要件定義からやらせると(洗い出ししたと思っていても出来ていない例もよくある)工数が膨らむ可能性があります。派遣エンジニアのいう事に「はい」か「Yes」で答える、予算をどぶに捨てるくらいの覚悟がないならやめましょう(しかしそのお金で最初から業務改善コンサル入れたほうがいいです)。
  • IcT部門の社内SE(非管理職)に社内全部面倒見てもらう
    • 上記2つよりはマシですが、RPA化をどこまで行うかによっては一番の地獄になる場合もあり。RPAには些末な事の洗い出し・検証などが多く、一つ一つは大したことがなくても、膨大な量となって襲い掛かってきます。RPAは「簡単でしょ?」と思われがちで(1件1件は実際大したことがない)助けが入りにくい・本人も助けを求めづらく、気付いた時には末期症状ケースもあるので周囲のフォローが必要です。

2.見直してますか?業務フロー

上記1の音頭を取る人次第なところがありますけれども。
通常のシステム開発だと要件定義する時に洗い出されますが(んなことない、と思う気持ちは一旦棚上げしてください)
RPAだと、なぜか何の洗い出しもしないまま着手させちゃったり
洗い出ししても不十分(後から要件が変わる)が頻発しますね。
「使うシステム」とか「ファイル形式」は後からでもいいので、
「どのような事をしたいのか、例外は何か、制約条件は何か」だけははっきりさせておきましょう。
(いわゆる、要件定義ではなく「要求定義」ですね)

明確にすべきこと

  • RPA化する範囲(いきなり大きな切り口でやるのはやめ、タスクを小さく分割する)
  • ユーザーが何を求めているか?(慣例でやっていて必要のないことまでRPA化しない)
  • 誰にどの程度の権限を割り振って、誰が決裁するか(ここがあやふやだと仕様変更ばかりでRPAエンジニアが地獄を見る事となる。1.でも書いたけれども大事なので2回言うやつです。)

3.使ってますか?RPA以外の自動化ツール

RPAはなんかいい感じの魔法で全てをシャランラ~♪…できるわけではないので
別のツールを使用したほうがいい場合も多々あります。
あるあるなのがExcelの操作ですが、VBAやVB.netで書いたコードを
RPAにキックさせて動かし、その結果データをまたRPAで操作していく…とか。
もう少しプログラミングに抵抗なければ、JavaScriptで書いたコードを動かすとか
Pythonでコード書いちゃうとか。
Python書けるならRPAツールいらなくね?と思われるかもしれませんが、
メンテできる人員が制限されてしまう事も考えられるので
変更可能性の低い基幹部分だけコードで書いて、
変更になる可能性のある部分をRPAツールを使用して作るのが最適解の場合もあります。
(例えば、外部サイトへのログイン部分はログインページなどの変更がありえるので
RPAで作成、データ取得した後のデータ解析部分はPythonでなど。)

おまけ:独断と偏見コミコミのRPAツール選定表

なお異論は認める。(個人的にはUIPathとAAEが好き)
選定表.png

20
17
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
20
17

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?