RPAエンジニアのフリーランス案件の仕事内容｜案件の種類と働き方

フリーランスのRPAエンジニアの仕事は、業務の担当者から手順を聞き取り、ロボットに任せる範囲を決め、止まりにくいシナリオを作って本番で動かし続けることです。ただ、案件の種類によって、1日の大半がシナリオの開発になることもあれば、会議と文書づくりが中心になることもあります。

この記事では、RPAの案件を5つの種類に分け、それぞれの1日と1か月の流れ、関わる相手、成果物を整理します。報酬の決まり方はRPAエンジニアの報酬の記事、求められる力はRPAエンジニアのスキルの記事で扱っているので、ここでは「参画したら実際に何をしているか」に絞ります。

案件は5つの種類に分かれる

RPAの仕事は、作って終わりではありません。総務省の「自治体におけるRPA導入ガイドブック」（令和7年7月）も、導入の進め方とは別に、運用の段階でガバナンスとマネジメントの体制、開発・保守の体制を整えることを説明しています。フリーランスの案件も、どの段階を担うかで次のように分かれます。

1つの案件で複数を兼ねることもよくあります。たとえば開発の案件で参画し、半年後には保守と台帳の整備が中心になる、といった形です。以下の流れは典型的な例なので、目安として読んでください。

新規の開発案件

1日の流れ（例）

午前は、業務の担当者に実際の操作を見せてもらいながら手順を聞き取り、条件の分かれ目を書き出します。午後は、前日までに聞き取った業務のシナリオを作り、テスト用のデータで動かして確かめます。夕方は、担当者に確かめたい点をまとめて送り、翌日の聞き取りの段取りをつけます。

開発の時間が長く見えますが、聞き取りと確かめの往復が仕事の半分近くを占めることも珍しくありません。手順書に書かれていない「いつもこうしている」という判断が、テストの段階で見つかるためです。

1か月の流れ（例）

• 月初：対象の業務を決め、聞き取りの日程を業務の担当者と押さえる
• 前半：業務の流れを図にし、ロボットに任せる部分と人に残す部分を担当者と合意する
• 後半：シナリオを作り、例外のデータも含めてテストする。担当者に結果を確かめてもらう
• 月末：処理の対象を絞って本番の運用を始め、結果を見ながら範囲を広げる

成果物

業務の流れ図、自動化の範囲の定義、シナリオ、テストの観点と結果、操作の手順書、止まったときに手作業に戻す手順などです。ガイドブックも、作成者以外の人が直せるよう、部品化や分かりやすい命名で保守性を確保し、引継ぎを通じて継承していくことの大切さを挙げています。

運用保守の案件

1日の流れ（例）

朝は、夜間や早朝に動いたロボットの実行結果とログを確かめます。止まっていたものがあれば、原因が入力のデータなのか、操作先の画面の変更なのか、システムの遅れなのかを切り分け、直すか、担当者に手作業での対応をお願いします。日中は、業務の担当者からの問い合わせへの対応と、小さな修正や改善を進めます。

1か月の流れ（例）

• 毎日：実行結果の確認、停止への対応、問い合わせの受け付け
• 毎週：止まった件数と原因を一覧にし、繰り返し起きているものの直し方を決める
• 月の半ば：操作先のシステムの改修予定を確かめ、影響を受けるロボットを洗い出す
• 月末：対応の記録をまとめ、推進の担当者や情報システム部門に報告する

ガイドブックは、シナリオに不具合がなくても、操作先の業務システムの画面や帳票、データの仕様が変われば、その時点からロボットは意図した動作ができなくなるとしています。外部のWebサイトは事前の通告なく変わることもあるため、保守の仕事は「止まってから直す」だけでなく、変更を先に知る段取りが大きな比重を占めます。

成果物

停止と対応の記録、修正したシナリオ、変更の影響の一覧、月次の報告資料、手順書の改訂などです。

業務の可視化と対象の選定の案件

これから導入する組織や、導入したものの対象業務が広がらない組織で出てくる案件です。手を動かしてシナリオを作るより、業務を知り、何を自動化するかを決めることが仕事の中心になります。

1日・1か月の流れ（例）

1日の多くは、業務部門ごとの聞き取りと、その内容の整理に使います。1か月の単位では、前半で対象の部署の業務を棚卸しし、後半で件数・作業時間・判断の多さから候補を絞り、効果の見込みとあわせて推進の責任者に示します。

ガイドブックは、RPAの導入ありきで検討するのではなく、まず業務の棚卸しを行い、現状を可視化したうえで対象業務を特定する進め方が、より大きな効率化の効果を得るために必要だとしています。そのため、自動化しないと判断した業務とその理由も、この案件の大切な成果になります。

成果物

業務の一覧と作業時間の記録、業務の流れ図、自動化の候補と優先順位、効果の見込み、導入の進め方の案などです。読み手が業務部門の責任者や経営層であることが多く、技術の言葉より業務の言葉で書くことが求められます。業務の見直しを中心にした働き方は業務コンサルタントの仕事内容も参考になります。

全社の管理の仕組みづくりの案件

部署ごとにロボットが作られ、全体の状況が分からなくなった組織で出てくる案件です。ガイドブックは、管理されなくなったロボットが通称「野良ロボット」と呼ばれ、セキュリティ上のリスクにもなりかねないこと、各部署や個人に依存した管理では全体の運用状況を把握できないことを挙げています。

1日・1か月の流れ（例）

最初の1〜2か月は、各部署のロボットを棚卸しし、対象の業務、操作先のシステム、管理者と担当者を台帳にまとめます。その後は、開発のルール、本番に出す前の確認項目、権限と認証情報の扱いを決め、関係する部署と合意を取ります。1日の多くは、部署ごとの確認と、ルールの文書づくりです。

成果物

ロボットの台帳、開発のルール、本番化の判定の手順、権限と認証情報の管理の決まり、教育の資料などです。管理者が不在のロボットについて、引き継ぐか止めるかを部署と決めていくのも、この案件の仕事に含まれます。

内製化の支援の案件

社内の担当者が自分たちでシナリオを作れるように支える案件です。ガイドブックは、多くの自治体で業務担当課による内製化が行われていること、外部委託で作ったシナリオを手本にしたり、事業者の指導を受けながらシナリオを完成させたりする工夫が功を奏した例があったことを紹介しています。

1日の流れは、社内の担当者が作ったシナリオのレビュー、質問への回答、つまずきやすい点をまとめた手順書づくりが中心です。1か月の単位では、勉強会を開いたり、手本になるシナリオを作ったりします。自分で作るより、ほかの人が作れるようにすることが成果になるため、説明と文書の力が問われます。稼働日を決めて関わりやすい種類で、週2〜3日の案件の型はRPAエンジニアの週2〜3日・副業案件で扱っています。

どの案件にも共通する仕事と、関わる相手

種類が違っても、次の仕事はほぼすべてのRPA案件にあります。

1. 聞き取り：業務の担当者から、手順書にない判断を聞き出す
2. 合意：ロボットに任せる範囲と、人に残す範囲を担当者と決めて残す
3. 例外への備え：想定外のデータや操作先の不調のとき、無理に処理を続けない作りにする
4. 引き継ぎ：仕様、操作方法、手作業に戻す手順を文書にする

関わる相手は、業務の担当者、推進の担当者、情報システム部門の3者が中心です。業務の担当者とは日々、推進の担当者とは週次、情報システム部門とは権限や操作先のシステムの変更のたびに話します。フリーランスならではの仕事として、自分の稼働の記録と報告もあります。精算の仕組みは精算幅の記事をご覧ください。

働く場所は、操作先のシステムとロボットの実行環境の置き場所で決まります。詳しくはRPAエンジニアのリモート案件の記事で解説しています。

よくある質問

RPAエンジニアは、1日中シナリオを作っているのですか？

開発の案件でも、聞き取りやテストの結果の確認、担当者とのやりとりにかなりの時間を使います。可視化や管理の案件では、シナリオを作る時間がほとんどないこともあります。どの種類の案件かで、手を動かす時間の割合は大きく変わります。

開発の経験しかありませんが、保守や管理の案件に入れますか？

止まったロボットの原因を調べて直した経験や、部品化や命名のルールを守って作った経験があれば、保守の案件で話せる材料になります。管理の案件は台帳やルールづくりの経験が問われるため、まずは保守の案件で全体を見る経験を積む進め方もあります。

参画して最初の1か月は何をすることが多いですか？

関係者と役割の把握、動いているロボットと操作先のシステムの確認、開発のルールと環境の確認から始めるのが一般的です。初月の進め方はRPAエンジニアの参画初月にやることで詳しく解説します。