RPA・業務自動化の実績の見せ方｜出せない仕事をどう伝えるか

2026年6月19日

丸山桃子

この記事のポイント

✓RPA・業務自動化の実績の見せ方を
✓画面もデータも出せない前提で解説
✓ダミーデータでの再現まで

RPA・業務自動化の実績の見せ方で行き詰まる理由は、腕の問題ではありません。作ったものが依頼元の社内システムの中にしかなく、画面には取引先名も従業員の氏名も並んでいて、そのまま外へ出せないからです。結論から書くと、この分野で通用する実績の出し方は「成果物を見せる」ではなく「意思決定の過程を見せる」に寄せることです。どの業務を選び、どこで人の手を残し、止まったときに何を用意したのか。この三つが説明できる人は、画面を一枚も見せずに信用されます。

実績が出せないのはRPA・業務自動化の構造上あたりまえ

まず前提を整理します。RPA・業務自動化の仕事は、他の在宅ワークと比べて成果物の持ち出しがきわめて難しい職種です。理由は四つあります。

第一に、動作対象が依頼元の業務システムであることです。会計システム、販売管理、勤怠、金融機関のインターネットバンキング。ロボットが触る画面はどれも社外秘で、操作の録画はもちろん、スクリーンショットの一枚も外に出せません。第二に、扱うデータが個人情報や取引情報そのものであることです。入金消込のロボットなら口座情報と取引先名が、勤怠集計のロボットなら従業員の氏名と出退勤が画面に映ります。マスキングしたところで、レイアウトから依頼元が特定できる場合もあります。

第三に、ツールのライセンス条項です。有償のRPA製品には、開発したワークフローの定義ファイルを第三者に開示することを制限する条項が入っていることがあります。エンジニアが業務委託契約と同時にライセンス規約の適用対象になっている場合、契約書だけを見て「守秘義務の範囲外だから出せる」と判断すると危険です。第四に、業務そのものが競争上の情報である点です。どの業務を自動化しているかは、その会社の弱点と改善方針を示します。「この会社は請求書の突合を人手でやっていた」と外部に伝わること自体を嫌う依頼元は珍しくありません。

つまり、実績が出せないのは例外ではなく標準です。だからこそ、出せない前提で組み立てられた実績の見せ方を持っている人が、選考で明確に有利になります。逆に「守秘義務があるので詳しくは話せません」で会話を終える人は、何も作っていない人と区別がつきません。区別をつけるための材料を、あらかじめ設計しておく必要があります。

見せられないものと見せられるものを線引きする

作業に入る前に、手元の資産を三つの箱に分けます。一つ目は絶対に外へ出せないもの。実データ、システムの画面、依頼元の社名と紐づく記述、ワークフローの定義ファイルそのものです。二つ目は抽象化すれば出せるもの。業務フローの構造、例外処理の分岐、設計上の判断とその理由、運用の引き継ぎ手順です。三つ目は最初から自分の資産であるもの。自分で作った命名規則、テストの観点表、エラー時の連絡フロー、ドキュメントのひな型です。

多くの人が一つ目の箱だけを見て「何もない」と結論を出します。実際に価値が高いのは二つ目と三つ目です。発注する側は、ロボットが動く画面を見たいわけではありません。自分の会社の業務を任せたときに、この人が同じ品質で仕上げてくれるかどうかを知りたいだけです。判断の再現性は、画面ではなく言語化された考え方の中にあります。

発注者が実績で確かめている四つのこと

見せ方を考える前に、見る側が何を探しているかを押さえます。RPA・業務自動化の依頼者が実績資料を読むとき、確認したいのは次の四点に集約されます。

業務を選ぶ目を持っているか

RPAは、対象業務の選定を誤ると導入そのものが失敗します。手順が固まっていない業務、判断が属人化している業務、月に数回しか発生しない業務にロボットを作っても、保守の手間が効果を上回ります。発注者は、依頼した業務をそのまま作る人ではなく「その業務は自動化に向きません、こちらを先に整えましょう」と言える人を探しています。

実績の中で、対象を選んだ理由を書けるかどうかが分かれ目になります。処理件数の多さ、手順の固定度、入力元の安定性、エラー時の影響範囲。この四つの軸で候補を並べ、なぜその業務を先に選んだかを説明できれば、それだけで業務選定の経験があると伝わります。実際、最初の一手を誤らなければ効果が出やすい分野であることは、導入支援の現場からも繰り返し報告されています。

実際に、1件7分の転記が2分になった事例や、2時間の請求処理が20分になり残業がゼロになった事例、年間7,500時間の見積書作成が10分の1になった事例など、業務選定さえ適切であれば、RPAは確かな成果をもたらしてくれます。出典: macroman.jp

この引用が示しているのは効果の大きさではなく、効果が「業務選定さえ適切であれば」という条件つきである点です。実績資料でも、この条件の部分を語れるかどうかが読み手の評価を決めます。

止まったときの設計をしているか

ロボットは必ず止まります。画面のレイアウトが変わった、ログインの二要素認証が追加された、元データの列が一つ増えた。止まること自体は失敗ではありません。止まったときに誰がどう気づき、誰が復旧し、その間の業務をどう回すかが決まっていないことが失敗です。

発注者から見て怖いのは、ロボットが止まったまま数日気づかれず、月末に帳簿が合わないという事態です。そのため、実績資料に「異常終了時にどこへ通知を出すか」「途中まで処理したデータをどう扱うか」「手作業に戻す手順を誰が持っているか」が書かれていると、経験の質が一段上に見えます。ここは画面を見せずに書ける領域であり、しかも書ける人が少ない領域です。

業務を理解しようとする姿勢があるか

自動化の失敗の多くは、技術ではなく業務理解の浅さから起きます。担当者が口では「毎回同じ手順です」と言っていても、実際には例外が三つも四つも隠れているのが普通です。締め日の前後で処理が変わる、特定の取引先だけ書式が違う、担当者が目視で弾いている条件がある。こうした暗黙のルールを引き出すヒアリングができるかどうかが問われます。

実績としては、ヒアリングで使った質問の型を出すのが有効です。「例外はありますか」と聞いても出てきません。「直近三か月で、いつもと違う対応をしたのはどんなときでしたか」「この作業を新人に引き継ぐとしたら、最初にどこでつまずくと思いますか」といった聞き方を持っていることは、そのまま実務経験の証明になります。

引き渡した後を考えているか

業務委託でロボットを作る場合、作った本人がずっと保守するとは限りません。依頼元の担当者が引き継ぐ、あるいは別のパートナーが触ることになります。そのときに読める形で残っているかどうかは、発注者にとって費用の話に直結します。命名規則、変数の定義、外部ファイルの置き場所、テスト手順。これらを整えている人は、次の依頼でも安心して任せられます。

画面を出さずに実績を伝える五つの型

ここからが本題です。守秘義務を守ったまま実績を伝える具体的な型を、実務でよく使われる順に並べます。

型1：業務フローを抽象化した図で見せる

もっとも汎用性が高い方法です。実際の業務フローから、依頼元を特定できる要素を抜き、構造だけを残します。システム名は「販売管理システム」「グループウェア」といった一般名詞に置き換え、部署名は「申請部門」「承認部門」と役割で書きます。残すのは、処理の分岐、待ち合わせ、人の判断が入る位置、そしてロボットが触るシステムの数です。

図には自動化前と自動化後を並べます。前の図では、人が三つのシステムを行き来し、途中で目視の確認が二回入っている。後の図では、二つの往復がロボットに置き換わり、目視は一回だけ残した。この「残した一回」に注釈を入れるのが要点です。なぜ残したのかを書けば、全部を自動化しようとしない判断力が伝わります。

型2：判断の記録を文章で見せる

設計判断の記録は、そのまま職務経歴の代わりになります。書式は単純で構いません。ある業務について、直面した制約、検討した選択肢、選んだ案、選んだ理由、後から見た反省。この五項目を一件あたり数百字でまとめ、三件から五件そろえます。

たとえば「複数の担当者が同じロボットを実行するため、同時実行で処理が二重に走る危険があった。ロック用のファイルを置く案と、実行を一台の端末に集約する案を比較し、運用の手間が少ない後者を選んだ」という記録は、実データを一切含まないのに具体性があります。読む側は、この人が運用まで考えていると受け取ります。

型3：ダミーデータで再現版を作る

代表的な処理を、自分で用意した架空のデータと架空の画面で作り直します。表計算ソフトで作った疑似的な業務システム、自分で立てたテスト用のWebフォーム、公開されている書式のPDFなど、材料はいくらでもあります。ここで再現するのは業務そのものではなく、処理の型です。

再現版の価値は、動画やコードを堂々と公開できる点にあります。データも画面も自分のものなので、守秘義務に触れません。注意点は、依頼元の業務を細部までなぞらないことです。あくまで「同じ構造の処理を、汎用の題材で組んだもの」として作ります。

型4：設計ドキュメントのひな型を見せる

自分が普段使っている要件定義シート、テスト観点表、運用手順書のひな型は、中身を空にすればそのまま提出できます。項目立てを見るだけで、どこまで考えて仕事をする人かが伝わります。特に、テスト観点表に「元データが0件のとき」「想定外の文字コードが混ざったとき」「処理途中でネットワークが切れたとき」といった項目が並んでいると、経験の厚みが出ます。

型5：数字ではなく変化の構造で語る

削減時間や金額を出せない場合でも、変化の構造は語れます。「月末に集中していた作業が、毎日少しずつ処理される形に変わった」「担当者が退勤後に手を動かす必要がなくなった」「入力ミスの発見が翌月から当日に早まった」。こうした表現は、依頼元が特定されず、しかも効果の性質を正確に伝えます。数字を出せる案件で許可が取れているなら添える、という順序で構いません。

守秘義務の線引きと、許諾を取る手順

実績を出す前に必ず踏むべき手順があります。ここを飛ばして事故を起こすと、次の仕事が来なくなるどころではありません。

契約書のどこを読むか

確認するのは三か所です。秘密情報の定義、目的外使用の禁止条項、契約終了後の存続期間です。秘密情報の定義が「本業務に関して知り得た一切の情報」となっている契約は多く、この場合は業務内容そのものが秘密情報に含まれます。存続期間が契約終了後も数年続く条項も一般的です。「もう終わった案件だから」は理由になりません。

加えて、成果物の権利がどちらに帰属するかも見ます。著作権が依頼元に譲渡されている場合、自作のワークフローであっても自分の作品として公開できません。逆に、汎用的に作った部品について自分に利用権を残す取り決めをしておけば、次の案件でも使えるうえに実績としても出しやすくなります。この交渉は契約の段階でしかできないため、受注前の確認事項に入れておきます。

許諾は具体的に、書面で取る

実名で書きたい場合は、依頼元に許諾を求めます。口頭の「いいですよ」は、担当者が異動した瞬間に消えます。メールで構わないので、次の三点を書いて送ります。どこに掲載するか、どの範囲を書くか、いつまで掲載するか。「業務委託の実績紹介として自分のポートフォリオサイトに、貴社名と業務の概要のみを掲載したい。数値と画面は掲載しない。掲載期間は取り下げのご連絡があるまで」といった書き方です。

断られたときのために、代替案も同時に出します。「社名は伏せ、業種と企業規模のみで記載する形でも構いません」と添えると、通る確率が上がります。

抽象度の目安

実名の許諾が取れないときの記述は、次の粒度が実務上の落としどころです。業種は大分類まで（製造業、卸売業、士業事務所など）。企業規模は幅で（従業員数十名規模、数百名規模）。業務は一般名詞で（請求書の発行、入金の消込、勤怠データの集計）。システムは種別で（会計システム、勤怠管理システム）。この粒度なら、特定は困難で、しかも読み手には仕事の輪郭が伝わります。

ツールごとに見せ方が変わる

使ったツールによって、出せるものと出せないものが変わります。

デスクトップ型の商用RPA製品を使った案件では、ワークフローの定義ファイルが依頼元の資産になることがほとんどです。この場合は型1と型2、つまり抽象化した図と判断の記録が主力になります。製品名を書けるかどうかも契約次第ですが、製品名は書けるケースが比較的多いので、確認する価値があります。

一方、業務システムに標準で付いている自動化機能や、表計算ソフトのマクロ、スクリプト言語で組んだ処理の場合は、汎用的な部品を自分の題材で書き直して公開しやすい傾向があります。処理の考え方を示す最小限のコードを、架空のデータ構造で書き直して置いておくと、技術面の説明が一気に楽になります。

クラウド型の自動化サービスを使った案件では、接続先のサービス名の組み合わせ自体が依頼元の内情を示すことがあります。「表計算ソフトとチャットツールを連携させた」までは書けても、業種と組み合わせると推測できてしまう場合は、連携先を種別で書きます。

RPAが得意とする業務の性質を押さえておくと、抽象化の粒度を決めやすくなります。

RPAが得意とするのは、業務フローや作業手順が決まっている定型業務です。また、複数のアプリケーションを横断するような業務、大量のデータを扱う業務も得意です。しかし、そう言われてもなかなかイメージしづらいかもしれません。まずは、実際の企業活動の中で、具体的にどんな業務にRPAが導入できるのかを紹介します。出典: hitachi-solutions.co.jp

複数のアプリケーションを横断する処理が中心という性質は、そのまま実績の書き方に反映できます。「三つのシステムをまたぐ処理を、人の判断を一か所だけ残して連結した」という書き方は、どの依頼元にも当てはまる表現でありながら、仕事の難度を正確に伝えます。

やりがちな失敗と、その直し方

失敗1：守秘義務を盾に何も語らない

もっとも多い型です。「守秘義務がありまして」で説明が止まると、選考する側は判断材料をまったく得られません。直し方は単純で、話せない部分を明示したうえで、話せる部分を先回りして出すことです。「依頼元と画面はお出しできませんので、同じ構造の処理を汎用の題材で組み直したものをご覧ください」と言えば、会話が前に進みます。

失敗2：ツール名の羅列で終わる

扱える製品名を並べただけの資料は、同じ製品名を並べた他の候補者と区別がつきません。製品名は前提条件であって実績ではありません。直し方は、製品名のそれぞれに「その製品で解決した業務の型」を一行添えることです。「複数システムをまたぐ突合」「大量データの一括処理」「定時起動と結果通知」といった具合に、業務の型で語ります。

失敗3：効果の数字を盛る

削減時間を大きく見せたくなる誘惑は強いのですが、面談で根拠を聞かれた瞬間に崩れます。どう測ったのか、対象期間はいつか、比較の前提は何か。答えられない数字は出さないほうが安全です。数字を出さずに構造の変化で語る型5に切り替えれば、信頼を落とさずに済みます。

失敗4：技術の話に寄りすぎる

処理の実装方法を細かく説明しても、発注者の多くはその良し悪しを判断できません。判断できる人が読む場面（技術者が同席する面談など）では有効ですが、最初の書類選考では業務の話が先です。業務の課題、選定の理由、運用の設計、その次に実装という順序で並べます。

失敗5：一件も実績がないまま応募する

未経験からこの分野に入る場合、最初の一件をどう作るかが課題になります。ここは次の章で扱います。

実績が一件もない段階での作り方

まったくの未経験でも、提出できる材料は自分で作れます。題材の選び方に条件が三つあります。誰にでも業務内容が想像できること、処理の分岐が二つ以上あること、そして元データが公開情報で用意できることです。

たとえば、公開されている統計データを定期的に取得して整形し、条件に合う行だけを抽出して通知する処理は、この三条件を満たします。省庁の統計ページや公的機関の公開資料は、利用条件を確認したうえで題材にできます。総務省や経済産業省のように、統計や資料を公開している機関のサイトは題材の宝庫です。

作ったら、必ず設計ドキュメントを添えます。要件、対象データ、処理の流れ、例外処理、テスト観点、既知の制約。この六項目がそろっていれば、業務経験がなくても「仕事として組める人」という印象を与えられます。逆に、動くものだけを提出して説明がないと、独学の練習作としか見てもらえません。

もう一つの近道は、身近な事務作業を題材にすることです。家族が営む店の在庫表、地域団体の名簿管理、自分の請求書発行。実在の業務なので例外が必ず出てきます。その例外にどう対処したかを記録すれば、それは立派な実務経験です。関係者の許諾を取ったうえで、データを架空のものに差し替えて公開します。

未経験から入る道筋については、業務内容と求められる技能を整理したRPA・業務自動化ツールのお仕事が参考になります。どんな依頼が実際に発生しているかを知ってから題材を選ぶと、的外れな練習作を作らずに済みます。隣接する分野の需要を見たい場合は、データ活用や情報管理まで含めたAI・マーケティング・セキュリティのお仕事にも目を通しておくと、自分の技能をどの方向に伸ばすかの判断がしやすくなります。

選考の場面ごとに出し方を変える

同じ材料でも、出す場面によって組み立てが変わります。

応募書類の段階

読み手は数十件をさばいています。読まれるのは冒頭の数行だけだと考えて構いません。ここに置くべきは、扱える業務の型と、担当できる工程の範囲です。「業務ヒアリングから要件定義、実装、テスト、運用手順書の作成まで一貫して担当」といった一行が、技術の羅列より効きます。実績の詳細は別紙にまとめ、書類本体は要点だけにします。

面談の段階

面談では、相手の業務に引きつけて話せるかが勝負です。事前に依頼元の業種を調べ、その業種で発生しやすい定型業務を三つ想定していきます。「小売業でしたら、店舗ごとの日次売上の集計と、仕入先ごとの請求書の突合あたりが候補になりやすいと思います」と切り出せると、実績の詳細を聞かれる前に信用が生まれます。

トライアルの段階

小さな案件から始める提案は、実績が薄い段階では有効です。ただし、無償で作ることを申し出るのは避けます。無償の作業は、依頼元にとっても評価の基準が曖昧になり、双方にとって良い結果になりません。範囲を限定した有償の初回案件として提案するほうが、その後の関係が健全に続きます。

契約書と提案書の書き方も評価される

意外に見落とされているのが、提出する文書そのものの質です。誤字が多い提案書、条件が曖昧な見積書は、それだけで運用も雑だろうと推測されます。文書作成の基礎を体系的に確認したい場合はビジネス文書検定の出題範囲が実務的な目安になります。また、ロボットが社内ネットワークやシステムを横断する以上、基礎的なネットワークとセキュリティの知識は説明の説得力に直結します。CCNA（シスコ技術者認定）の学習範囲は、その土台を押さえるうえで有用です。

運用フェーズの実績こそ差がつく

開発の実績は、ある程度の期間その分野にいれば誰でも似た内容になります。差がつくのは運用の実績です。ここは語れる人が極端に少なく、しかも発注者がもっとも知りたい部分でもあります。

何をもって「動いている」と判断したか

作ったロボットが正常に動いているかどうかを、どうやって確認していたかを書きます。実行ログの保存先と保存期間、成功と失敗の判定基準、日次で見る指標。たとえば「処理件数が前日比で半分以下になったら異常として扱う」といったしきい値を持っていたなら、それは運用設計の実績です。ロボットは、エラーを出さずに間違った結果を出すことがあります。異常終了だけを監視していると、この静かな失敗を見逃します。件数や合計値の妥当性を見る仕組みまで作っていたなら、必ず書き残します。

変更にどう追随したか

業務システムは更新されます。画面のボタンが移動する、項目が追加される、認証方式が変わる。この変化にどう対応したかは、長く関わった証明になります。年に何回程度の改修が発生し、どの範囲の変更なら何時間で追随できる設計にしていたか。あらかじめ画面の要素の指定方法を工夫していた、設定値を外部ファイルに切り出していた、といった備えを書けると、設計段階から運用を見ていたことが伝わります。

手放すときに何を渡したか

契約が終わるとき、あるいは担当が交代するときに何を引き渡したかも実績です。運用手順書、障害時の対応表、設定値の一覧、既知の制約と未対応事項。特に「未対応事項」を正直に残せる人は信用されます。都合の悪い部分を隠して引き渡す人と、制約を明記して渡す人とでは、次に一緒に働きたいと思われる度合いがまったく違います。この姿勢は、そのまま提案書や見積書の書き方にも表れます。

見積もりの立て方を説明できるか

工数の見積もりをどう組み立てているかも、立派な実績です。対象業務の画面数、分岐の数、例外の想定件数、テストの回数。この四つで概算を出し、要件が固まっていない段階では調査工程を別立てにする。こうした組み立てを説明できる人は、途中で工数が膨らんで揉める確率が低いと判断されます。逆に、根拠を示さず総額だけを出す人は、発注側から見ると危なく映ります。

市場を長く見てきた立場からの観察

20年この市場を見てきた立場から言えば、RPA・業務自動化の分野で継続的に依頼を受けている人には、共通した特徴があります。作れる範囲を広げることより、任せたときの安心感を積み上げることに時間を使っている点です。ロボットが止まったときにすぐ連絡が来る、引き継ぎ資料が読める形で残っている、無理な自動化を止めてくれる。この三つが、次の依頼を呼びます。実績資料も同じで、技術の広さより、この三つを裏づける材料が並んでいるものが強い。

もう一つ、運営者として見てきた限りでは、間に何社も入る形の契約と、依頼者と直接つながる形の契約とでは、実績の残り方が違います。間接契約では、依頼元の顔が見えないまま作業だけが流れてきて、業務の背景を聞けないことが多い。結果として、抽象化して語れる判断の記録が残りません。直接取引では、業務のヒアリングから関われる分、語れる材料が自然に貯まります。中間マージンが乗らない手数料0%の形は、同じ予算で依頼者はより多くを頼め、受け手は手取りが厚くなる。金額の話に見えて、実際には「業務に近い位置で仕事ができるかどうか」という質の違いを生んでいます。

技能の値づけを考えるうえでは、公的統計にもとづく職種別の水準を知っておくと、自分の立ち位置を客観的に把握できます。開発工程を担う人材の水準はソフトウェア作成者の年収・単価相場で、ドキュメント作成を主体とする職種の水準は著述家，記者，編集者の年収・単価相場で確認できます。RPA・業務自動化の実務はこの二つの性質をまたいでおり、どちらの要素を強く見せるかで受注できる案件の性質が変わります。

実績資料を組み立てる手順のまとめ方

最後に、ここまでの内容を実際の作業手順に落とします。

第一に、過去に関わった案件を洗い出し、契約書の秘密保持条項と権利帰属を一件ずつ確認します。第二に、出せる範囲を三つの箱に仕分けます。第三に、出せる案件については実名掲載の許諾を書面で求め、断られたものは抽象度を落として記述します。第四に、抽象化した業務フロー図を三件から五件作ります。第五に、設計判断の記録を同じ数だけ文章で書きます。第六に、代表的な処理をダミーデータで再現し、公開できる形にします。第七に、要件定義シートとテスト観点表のひな型を空の状態で用意します。

この七手順を踏むと、画面を一枚も出さないまま、業務理解と設計力と運用感覚を示す資料がそろいます。作業量としては数日分ですが、一度作れば案件ごとに差し替えるだけで使い回せます。RPA・業務自動化の実績の見せ方で悩む時間を、この七手順に振り替えるほうが、はるかに早く次の依頼につながります。

よくある質問

Q. 守秘義務があると、実績はまったく公開できないのでしょうか？

契約書の秘密保持条項の定義次第ですが、多くの場合は「実データと画面」が対象で、抽象化した業務の構造や自分の設計判断まで一律に禁じられているわけではありません。業種を大分類、企業規模を幅、システムを種別で書く粒度なら特定は困難です。実名で書きたい場合は、掲載先と範囲と期間を明記して書面で許諾を求めます。

Q. 実績がまったくない状態で応募しても意味はありますか？

自作の題材で作った処理と設計ドキュメントがそろっていれば、応募する価値はあります。公開されている統計データを定期取得して整形し、条件に合う行だけ通知するような処理は、分岐が二つ以上あり題材として適切です。動くものだけでなく、要件、処理の流れ、例外処理、テスト観点まで文書化して添えることが条件になります。