「ロボットって、何時間くらいで作れるのですか？」
そう聞かれたことがあります。
その時の答えは？
ロボット製作にかかる時間
上記質問の答えから言えば、「モノによります」です。
まあ、当たり前といえば当たり前なのですが、込み入ったロボットを作れば、それ相応の時間が掛かりますし、工数の少ないロボットであれば、短時間で作成可能です。
期待外れの回答で申し訳ないと思いながらも、そうとしか言えませんでした。
ただ、通常のプログラミングよりは短時間に出来る傾向があるのは、確かです。
既に応用できるスクリプトがあるならいざ知らず、ゼロから作成するのであれば、RPAツールの方が早いでしょうね。
大体のものは、１日で出来るの？
私もRPAに関わる前には、「そうはいっても、丸一日あれば、大体できるんでしょ！？」と思っていました。
現実は少々違っていました。
個人的利用であり、込み入ったものでなければ、確かに１日で出来ることもあるでしょう。
既に業務内容が分かっており、ただ手で行う作業をRPAツールに置き換えていくだけであれば。
しかし現実には、今まで携わっていなかった業務を自動化し、操作も他の人が行うというケースが一般的でしょう。
となると、話が全然違ってくるのです！
「自分使用」と「他人使用」の違い
自分が使うロボットであれば、スタートからエンドまで、１本の道筋で作成しても構いません。
もし本番稼働時にトラブルが起きても、何が起こっているのか判断も出来ますし、自分で手直しも可能です。
おかしな使い方もしませんから、自分で状況をコントロール出来ます。
一方、他人が行っている業務を自動化する場合、設計思想が異なってきます。
そもそもその業務に精通しているケースは稀でしょうし、一度本番稼働したら、出来る限りトラブルは避けなければいけません。
そうなると、
①そのロボットで自動化される業務内容を詳しく知る必要がある。
⇒場合によっては、ロボット作成のために業務を一部変更して貰うことも珍しくない。
②なるべく止まらないロボットにする
⇒一般ユーザーとしては、エラー表示の対応は全くできないのが普通で、その後の対応が大変。
そのため、例外処理と言われる、誰が触っても異常終了しないような、仕組みを作るのが理想的。
（理想であって、現実には様々な理由から、正常終了率１００％のロボットは、ほぼ不可能です。）
③ロボットの内容を様々なドキュメントにする必要がある
といったことを考慮したり、作成する手間が発生します。
プログラミングと同じく、作成時間だけでなく、テストの時間もかなり掛かります。
ロボット作成の段階で、小さくテストを繰り返しながら作成し、とりあえず最後まで走るようになったら、今度は色々なシチュエーションを考えて更にテストします。
呼び方は色々ですが、「ボリュームテスト」ということで、通常利用時のMAX量を処理しても異常がないか？ということを確認するテストや、「いじわるテスト」と呼ばれるような指示とは違う動作（例えば、エクセルファイルを選べと言われているのに、PDFを選んでみるとか）を色々試したりもします。
という訳で、仮に１日で簡易的に作成できるロボットであっても、「納品」ということになると、さらに数日かかるのが一般的なのです。
私もこの業界に詳しくない時には、「そんなに時間掛からないでしょ！かなりぼってない！？」と思ったものです。（苦笑）
もちろん、儲け主義の業者も多いでしょうが、実際に売り物として納品するのであれば、それなりの時間が掛かるものなのです。
後から苦情の出ないようなものを収めようとすればすれほど、手間と時間が掛かるのです。
これは、自社内で作成＆利用する、つまり内製化する場合も、ある程度は同じです。
一通り問題なく動くロボットを作成した後、本番稼働の前に、実際のユーザーに試してもらう必要があります。
その中で、少なからず修正点も出てくるでしょう。
そんなことを繰り返していると、どうしても１つのロボットを完成させるのに、１週間単位で掛かることになりますね。
一般のプログラミングに比べて、見た目が玩具のように見えるかもしれませんが、やっていることはプログラミングとほぼ同じです。
なので、マネジメント担当者の方は、導入に当たってそのあたりの理解が必要となります。
それ以外にも・・・
ロボットの作成開始前に、工数を元に作業量を計算し、それに一人当たりの人件費を掛けて費用が見積もられます。
なのですが、なかなか当初の予定通りに進まないことが少なくないのです。
というのは、要件定義をし、全体の流れをさっと頭の中で描いて、「まあ、このくらい時間があれば十分だろう。」と思い作業に取り掛かる訳ですが、途中、思いもよらないところで躓くというのは珍しくないのです（苦笑）
それは、開発者のスキルが低いというだけでなく、
・RPAツールの仕様上の問題
・EXCELの問題
・不安定なサーバの問題
・社内システムの特殊性
というようなことが重なって、不測の事態を引き起こしたりするのです。
プログラミングでも同じですが、こういった躓きに対して、ああでもないこうでもないとやっていると、平気で丸一日費やしたりすることはよくあります。
側から見れば、「今日一日、何をやっていたの？」となるのですが、よほど経験豊富で優秀なチームリーダーでもいない限りは、誰もが通る道だと思います。