この記事は、
- 1年で20業務のRPA化を行ってきた程度の新人が
- 頭の固い旧時代の上長に
- 「言ってやりたかった！」というような文句をまとめた（まとまっていない）記事です。
ウン番煎じです。
UiPathでの技術的な話は 新人がUiPathでのRPA開発を1年間経験して編み出した開発ナレッジ をどうぞ
敵の名は
誤解
オーバーヘッド
標準
誤解 - RPAでないとできないことはほとんどない
RPAは比較的早くスクリプトを作る手段である
誤解されがちで、いろんな人が誤解を解こうとしてまだいまいち浸透していない事実ですが、
RPAで実現するのは「今までできなかったこと」ではなく、「べつにやればできたけどコスパ悪くてやらなかったこと」です。
RPA以外でやると遅い！高い！うまい！
となるものを
RPAでやることにって早い！安い！普通！
となってトータルで考えるとRPAのがいいかな？という考え方です。
（デジタルレイバーとか擬人化してるからわかりにくいんだと思うんですよね。。。）
お客さんにとっては、工数を抑えられるので安く済むことが魅力なので、
開発を請け負う側としては、従来通りの開発工数分のお金を請求して儲ける、人月ビジネスモデルだと先細り待ったなしです。
私のチームは先細りました。
オーバーヘッド - RPA開発は要件定義から開発までは一人でやった方がいい
開発工数に対して、伝言ゲームに割く時間の割合を小さくするため。
上記より、開発が早いことがRPAにとっての美徳であることを示しましたが、
RPA開発の敵＝早さの敵＝オーバーヘッド だと考えております。
私の職場では、私が新人だったということもあり、要件定義のみRPA開発経験のない上長が行い、
自分は簡単な口頭説明と要件書だけもらって開発するというスタイルでした。
RPA導入しようとする企業ならほとんどありえないのでしょうが、以下のような問題があります。
- 要件がある程度固まってから、RPAで実現できるかという話が来るので、「できないよ」ってなったときの無駄が巨大
- RPA開発経験のない営業寄りの人が切った要件なのでQAの余地が広大無辺
- RPAでは開発を開始してからでないとわからないことが多い→一括でQAを行うことが難しい→QA回数の増加
- QAの度上長を経由する為、「量」×「頻度」×「上長への説明時間」で老化する
- 開発より案件の掘出しと要件切る方が時間がかかるので、開発しかしない人の姿はまるで社内ニート
- この作業無駄じゃね？RPA化の前に業務フロー改善したら？と開発者が思っても現場の人に提案するタイミングがない
- 経由地点が増えると比例して増える報告/管理/説明Excelファイル
- これらを経て作り出されたRPAが現場の「なんか違うんだよな」でお蔵にシューして超エキサイティング
現場の人間と開発者が机を並べることができたら最低でも上記の問題はクリアーされるはずです！
（新たな問題が発生するのだとは思いますが・・・）
標準 - RPAにとって標準化はあまり意味がない（最低限でいい）
標準という形で無限に近いRPA実行環境の差異を一般化することは難しいため。
RPAはロジック部分よりも例外への対処に工数がかかるシステムです。
環境からくる例外、通信状態からくる例外、連携先ウェブサイトのレイアウト変更からくる例外・・・
などなど、開発に完璧に漏れがなくても、よその影響を受けて例外を出すRPAは、
まるで教育に問題がなくても、思春期に悪い友達を作ってグレてしまう息子のようです。（？）
つまりがちがちにコーディング標準を作り上げるのではなく、必要最低限にとどめることを意識するべきであり、
それよりもベストプラクティスを共通部品に詰め込んで共有する方が、多くの状況に対応でき、
標準へ対応するための工数の間延びを避けることにつながるでしょう。
その代わりインシデントを含めたナレッジの共有は密にするべきです。
もしかして新人にはRPAは向いていないのでは・・・？
向いていないと思います！
現場の状況やある程度の専門知識を理解してあげないと、言われたまま作るようになってしまいます！（ました！）
（でも猛者にRPA振ったら開発者も多分安定しなさすぎて嫌がられるだろうし、人件費も高くつくので、結局新人に降りてくるのだと思います。
あとコンサルがプログラミングレスって言ってるのを上長が真に受ｋ）
おわりに
駄文にここまでお付き合いいただき、ありがとうございます。
半分ぐらい愚痴のようになってしまいましたが、こんなことを思いながら1年間を過ごしてまいりました。
できるだけ融通を利かせるべきというのは、1開発者のわがままに聞こえるでしょうし、都合のいいことを言っている自覚もありますが、
私が使っていたUiPathというRPAツールでは、
UiPath Go という共通部品のマーケットプレイスでユーザー間のベストプラクティスの共有を推進しております。
が、私のいた職場では「信用できん！使わんでおけ！」と聞かん坊で、車輪を再開発する羽目になったりもしました。
企業として、どこの馬とも知れないどのような方が作ったかわからないものは使えない、というような姿勢もわかるのですが、
web系のjavascriptとかは普通に個人で作ったライブラリ使ってるし、外国産の割と攻めたツール使っておきながら、
なんで考え方だけ日本式を維持して守りに回るのよとかも言いたかったかもしれません。
とりあえず現場へのQA戻り待ち伝言ゲームモラトリアムをいい感じに消化できたのでここまでにしておきます。
重ねて、ありがとうございました。