RPAエンジニアのスキルシートの書き方｜面談で評価される実績の見せ方

RPAエンジニアのスキルシートは、製品の名前とロボットの本数を並べるより、どの工程を担ったか、ロボットをどう動かしていたか、例外処理と保守のしやすさにどう工夫したか、本番で起きたことにどう対応したかを書くのが基本です。読み手は、シナリオを作れる人かどうかに加えて、そのロボットが止まらずに使われ続けたかを知りたいと考えています。

案件で求められるスキルの中身はRPAエンジニアのスキルの記事、全体の構成はスキルシートの基本で扱っています。この記事では、RPAならではの書き方に絞って説明します。

担った工程をプロジェクト欄の冒頭に書く

RPAの案件は、どの工程を求めているかで読み手の関心が違います。プロジェクト欄の冒頭に、自分が担った工程を書きましょう。

開発だけの経験でも、案件は多くあります。ただ、可視化と管理の工程は、判断の場面が多いぶん面談で深く聞かれます。担っていない工程は書かないことが大切です。「関わった」「支援した」のように関わり方が浅い場合は、そのとおりに書きましょう。

使用技術の欄は「製品・動かし方・周辺」で区切る

RPAのスキル一覧は、製品の名前だけが並ぶ欄になりやすいところです。次のように区切ると、読み手が自分の案件に関係する部分を探しやすくなります。

総務省の「自治体におけるRPA導入ガイドブック」（令和7年7月）も、RPAのツールを1台のパソコンで動かす「デスクトップ型」と、複数のロボットをまとめて管理する「サーバー型」に分けて説明し、クラウド型の製品も出ていると紹介しています。どの形で動かしていたかを書くと、無人で動かす案件や管理の案件に合うかが伝わります。

製品は、案件によって使うものが違います。1つの製品の経験しかなくても、動かし方と操作先を具体的に書けば、ほかの製品の案件でも検討されることがあります。

例外処理と保守の工夫を1〜2行で書く

RPAのスキルシートで差がつくのは、例外処理と保守のしやすさの工夫です。プロジェクトごとに、次のような観点で1〜2行を書き添えます。

• 例外処理：「更新の前に画面の表示を確かめ、想定と違えば処理を飛ばして一覧に残す作りにした」
• やり直し：「処理済みの記録を残し、途中で止まっても続きから二重登録なしで再開できるようにした」
• 保守のしやすさ：「ログインとファイルの受け渡しを部品にし、操作先の変更時の修正箇所を減らした」
• 引き継ぎ：「仕様、操作方法、手作業に戻すときの手順を文書にして、社内の担当者に引き継いだ」

ガイドブックも、想定外の入力データや操作先の停止・遅延に備えた例外処理、部品化と分かりやすい命名、手作業で代わりに行う手順の文書化を、シナリオの完成度や保守性を高める点として挙げています。こうした工夫を書いておくと、面談で「本番で動き続けるロボットを作れる人か」を判断してもらいやすくなります。

効果の数字は「算定の前提」と一緒に書く

RPAの成果は「年間◯時間の削減」と書かれることが多い欄です。ただ、削減時間は、何を含めて数えるかで大きく変わり、読み手には良し悪しが判断できません。

ガイドブックは、効果を検証するときに、ロボットを動かす前の準備（入力のファイルの作成や仕分け）や結果の確認の時間、ロボットで処理できない件数の割合も把握することで、削減の効果を正しく出せるとしています。スキルシートにも、次のように前提を添えると伝わりやすくなります。

• 「手作業の時間から、ロボットの準備と結果の確認の時間を引いて算定」
• 「ロボットで処理できない分は担当者に回す設計で、その割合も記録」
• 「効果の測定は自分が担当／発注元の算定を引用」

数字を書いてよいと確認できた場合も、「作業時間を半分程度に」のように相対で書くと、守秘義務に触れにくくなります。書かないほうがよい情報の考え方はスキルシートに書いてよいこと・いけないことをご覧ください。

プロジェクト欄の記入例

以下は書き方を示すための架空の例で、実在の案件や実績ではありません。業界や規模はぼかしています。

例1：開発と運用保守

期間：20XX年X月〜20XX年X月（1年）
案件概要：製造業の経理部門 請求書の受け付けから会計システムへの登録までの自動化
規模・立場：推進チーム3名（自分は開発と運用の担当）
工程：開発、運用保守
使用技術：RPA製品（既存の環境で開発）、文字の読み取りの仕組み、表計算ソフト、会計システム（Web型）
動かし方：仮想デスクトップで、平日の決まった時刻に無人で実行
担当内容：読み取りの結果を確かめる処理を入れ、取引先名や金額が想定と合わない分は登録せずに一覧に残す作りにした。止まったときの通知と再実行の手順を文書にした
工夫・成果：処理済みの記録を残し、途中で止まっても二重に登録しない形で続きから動かせるようにした。会計システムの画面の変更の際は、部品を直すだけで対応できた

例2：全社の管理の仕組みづくり

期間：20XX年X月〜20XX年X月（8か月）
案件概要：サービス業 各部署で個別に作られたロボットの棚卸しと管理の仕組みづくり
規模・立場：情報システム部門と推進担当（自分は管理の仕組みの設計を担当）
工程：全社の管理
担当内容：各部署のロボットを棚卸しし、対象業務・操作先のシステム・管理者・担当者を台帳にまとめた。開発のルール（命名、文書化、テスト用データの使用）と、本番に出す前の確認項目を作った
工夫・成果：管理者が不在のロボットを洗い出し、部署と相談して引き継ぐものと止めるものを決めた。操作先のシステムの改修の際に、台帳から影響するロボットを調べられるようにした

例2の「引き継ぐものと止めるものを決めた」の1行で、いわゆる野良ロボットへの対処を関係者と調整して進めたことが伝わります。

業務の経験とのつなげ方

業務部門から自動化に広げてきた方は、その経歴がスキルシートの強みになります。何を自動化すべきかを判断するには、業務を知っていることが欠かせないためです。

• 要約で「経理（または人事・営業事務など）の業務経験をもとに、自動化の範囲を判断できる」ことを示す
• 業務の経歴は短くまとめ、自動化の対象を選んだ場面と結びつけて書く
• 開発の経験がある方は、部品化やテストの考え方を厚く書く

自己PRの組み立てはスキルシートの自己PR欄の書き方も参考になります。

よくある質問

社内で作ったロボットの経験だけでも、スキルシートに書けますか？

書けます。社内の自動化でも、担った工程、動かし方、例外処理の工夫、運用での対応は同じように書けます。自分の部署の業務だけを扱った場合は、その業務の知識を強みとして要約に書き、ほかの部署から相談を受けた経験があれば添えておきましょう。

製品のバージョンまで書くべきですか？

製品の世代によって画面や機能が大きく違う場合は、使った時期と合わせて書いておくと、読み手が判断しやすくなります。細かい番号より、開発ツールと管理ツールのどちらを扱ったか、新規に導入したか既存の環境で作ったかを書くほうが、案件との相性を伝えやすくなります。

自動化しなかった業務のことも書いたほうがよいですか？

書いておくと評価されることがあります。件数が少ない、判断が多いなどの理由で自動化を見送り、手順の見直しや別の手段を提案した経験は、業務の可視化と対象の選定の力を示す材料になります。理由を1行添えて書きましょう。