RPA・業務自動化のもう一度頼まれる人｜次に繋がる終わり方

2026年1月9日

長谷川奈津

この記事のポイント

✓RPA・業務自動化でリピートされる人が納品時に何を渡し
✓その後どう関わっているのかを整理しました
✓保守契約の線引きまで実務手順で解説します

RPA・業務自動化の仕事でリピートされる人と、一件で終わる人の差は、作ったロボットの出来ではありません。差がつくのは終わり方です。納品の当日に何を渡したか、その後の数週間に何を見ていたか、次の話をどう切り出したか。この三つで、次の依頼が来るかどうかがほぼ決まります。この記事では、継続案件になる人が実際にやっている手順を、納品前の準備から保守契約の線引きまで順に整理します。

業務自動化は「一度作って終わり」にならない仕事

そもそもRPAという仕事は、構造的に継続が発生しやすい分野です。理由は単純で、対象が動いているシステムだからです。会計システムが更新されれば画面が変わり、取引先が増えれば書式が増え、法改正があれば帳票が変わります。作ったロボットは、放っておくと必ず劣化します。

つまり、依頼した側から見ると、ロボットを一体作ってもらった時点で「これから面倒を見てもらう相手」が必要になります。その相手が作った本人であることが自然なのに、そうならない場合が多い。ここに、継続につながらない人の問題が集約されています。

RPAで何ができて何ができないかを理解している依頼元ほど、この継続の必要性を最初から見込んでいます。

金融業界を中心に大手企業が導入を始め、最近では中小企業でも導入が進んでいるRPA。手間のかかる定型業務を自動化することで、さまざまな業務効率化が図れるツールと言われていますが、実際にどんなことができるのかご存じでしょうか。企業としては、できるだけ多くの業務を自動化したいところですが、RPAにも得意・不得意があり、すべての業務を人間の代わりにできるわけではありません。そこで、どこまで自動化できるのか、人間が関与しなければならない作業はないのかについて、具体例を挙げながら解説します。RPAで「できること」と「できないこと」をしっかり見極めて活用することが、導入を成功させるための近道です。出典: hitachi-solutions.co.jp

得意と不得意を見極めることが導入成功の近道だという指摘は、そのまま継続の話につながります。一度目の案件で「できないこと」を正直に伝えた人だけが、二度目に呼ばれます。すべてできると言った人は、期待とのずれが必ず表面化し、そのずれが継続を切る理由になります。

依頼元の社内では何が起きているか

もう一つ、外からは見えにくい事情があります。RPAを導入する部署の担当者は、多くの場合、社内で成果を説明する立場に立たされています。導入の稟議を通した以上、効果を報告しなければならない。ここで担当者が求めているのは、ロボットそのものではなく「報告できる材料」です。

継続される人は、この事情を理解しています。納品時に、担当者が社内で使える形の資料を添える。どの業務がどう変わったか、次に手を付けると効果が出そうな業務はどれか。担当者がそのまま上長に見せられる資料を渡された時点で、その人は外注先ではなく味方になります。味方は切られません。

継続が切れる四つの理由

次を頼まれない人には、はっきりした共通点があります。相談を受ける立場から見ていると、理由はほぼ四つに収まります。

理由1：止まったときに連絡がつかない

もっとも多い理由です。ロボットは必ず止まります。止まった日に連絡がつかず、担当者が自力で手作業に戻す羽目になった。この一回で信頼は消えます。技術的な問題ではなく、連絡体制の問題です。

対策は、納品時に連絡の取り決めを文書にしておくことです。平日の何時までに連絡すれば当日中に一次回答を返す、それ以降は翌営業日になる、緊急時の連絡手段は何か。範囲を明示することは、責任を限定することでもあります。あいまいなまま「何かあったら連絡ください」とだけ言うと、相手は24時間対応を期待し、こちらは無限の待機を背負います。どちらにとっても不幸です。

理由2：中身がブラックボックスになっている

作った本人しか触れない状態で引き渡すと、依頼元は不安になります。この不安は、皮肉なことに継続を生みません。むしろ「この人に依存しすぎると危ない」という判断につながり、別の会社に作り直しを頼む動きが出ます。

読める形で残すことは、自分の仕事を奪う行為ではありません。逆です。中身が読めるからこそ、依頼元は安心して次も同じ人に頼めます。触れる人が自分しかいない状態は、依頼元にとってのリスクであり、そのリスクを解消してくれる人が選ばれます。

理由3：業務の変化に気づかない

納品したロボットが、半年後には業務の実態と合わなくなっていることがあります。担当者は忙しく、ロボットの範囲外の作業が増えていることに自分でも気づいていない場合があります。ここで定期的に様子を聞く仕組みを持っている人は、変化を先に見つけられます。

理由4：次の提案がない

一件目が問題なく終わっても、こちらから何も言わなければ、依頼元は「もう頼むことはない」と考えます。担当者は自動化の候補を体系的に把握しているわけではありません。次に何を頼めばいいかを、こちらから示す必要があります。ここを飛ばして「何かあればご連絡ください」で終える人が非常に多い。これ、知らない人が本当に多いのですが、依頼元は次の候補を自分では思いつきません。

納品の前にやっておく四つの準備

終わり方の設計は、納品の直前に始めるものではありません。着手時点から仕込みます。

準備1：受け入れの基準を先に合意する

何をもって完成とするかを、着手前に文書で合意します。処理対象の範囲、想定する件数の上限、対応する例外の種類、対応しない例外の種類。ここが曖昧なまま作ると、納品時に「思っていたのと違う」という話になり、追加の作業が無償で発生します。無償の追加作業が続いた案件は、こちらの意欲が落ち、結果として継続の話が出ません。

合意の書き方は難しくありません。「以下の条件を満たしたとき、検収完了とする」として、条件を箇条で並べるだけです。テストに使うデータも、この段階で決めておきます。

準備2：例外の扱いを決めておく

対応しない例外を決めることは、手を抜くことではありません。すべての例外に対応しようとすると、ロボットが複雑になり、保守が困難になり、結果として長く使えなくなります。「この条件に当てはまるデータは処理せず、一覧に出して人が判断する」という設計は、正しい判断です。

重要なのは、この判断を依頼元と共有しておくことです。共有していれば設計思想として評価され、共有していなければ不具合として扱われます。同じ挙動でも、事前の合意があるかどうかで評価が正反対になります。

準備3：運用の担当者を決めてもらう

依頼元の側で、日々ロボットの結果を確認する人を決めてもらいます。これを決めずに納品すると、誰も見ない状態が生まれ、静かな失敗が放置されます。担当者が決まっていれば、その人に向けて手順書を書けるので、資料の粒度も定まります。

準備4：引き継ぎ資料を作りながら進める

納品直前にまとめて書くと、必ず抜けが出ます。設計の判断をしたその日に、理由を一行書き足す習慣にしておけば、納品時には資料が完成しています。

引き渡しで渡すべき六つの資料

継続される人が渡しているものを、内容ごとに並べます。

運用手順書

日常の操作を、担当者がそのとおりに動ける粒度で書きます。起動方法、正常終了の見分け方、結果ファイルの置き場所、確認すべき項目。専門用語は使わず、業務の言葉で書きます。ここで技術用語を並べると、担当者は読まなくなり、結局こちらに問い合わせが来ます。

障害時の対応表

起こりうる異常を並べ、それぞれに対処を書きます。「途中で止まった」「実行できない」「結果の件数が明らかに少ない」といった、担当者が観測できる現象を左側に置くのが要点です。エラーコードを左側に置いた表は、担当者には使えません。

設定値の一覧

ファイルの置き場所、対象期間の指定、しきい値、通知先。変更する可能性のある値を一か所にまとめ、どこを直せば何が変わるかを書きます。設定値が処理の中に埋め込まれていると、些細な変更でも開発者を呼ぶことになり、依頼元の負担になります。

手作業に戻す手順

ロボットが長期間使えなくなった場合に、元の手作業へ戻す手順を残します。これを渡すと仕事を失うと考える人がいますが、逆です。この資料を渡せる人は、依頼元の事業継続まで考えていると評価されます。

未対応事項と既知の制約

対応しなかった例外、性能上の限界、依存している外部条件を正直に書きます。隠すと、後から発覚したときに信頼が一気に崩れます。明記しておけば、それは次の改修の提案材料になります。

変更履歴

いつ何をなぜ変えたかの記録です。数か月後に「なぜこの処理はこうなっているのか」と聞かれたとき、記録があれば即答できます。記録がないと、自分でも思い出せません。

納品後の三週間に何を見るか

引き渡して終わりにする人と、継続する人の差がもっとも出るのがこの期間です。

静かな失敗を探す

RPAでもっとも怖いのは、エラーを出さずに間違った結果を出す状態です。元データの列が一つずれていた、対象期間の指定が月をまたいでいた、想定外の文字が入っていて空白として処理された。どれもエラーにはなりません。

だから、正常終了だけを見ていては不十分です。処理件数、合計値、前日との差。この三つを担当者と一緒に数日確認します。「先週の水曜だけ件数が少ないのは、祝日の影響でしょうか」といった会話ができれば、業務の理解も深まります。

想定と実態のずれを拾う

稼働してみると、必ず想定外が出ます。件数が想定の倍だった、実行時間帯に他の処理が重なった、担当者が別のファイル名で保存していた。これらを早期に拾って調整すると、依頼元は「作りっぱなしにしない人」だと認識します。この認識が、次の依頼の土台になります。

効果の報告を手伝う

前述のとおり、担当者は社内で成果を説明する必要があります。稼働から数週間たった時点で、変化の内容を整理した短い資料を渡します。数字を出せる場合は測り方も添え、出せない場合は構造の変化で書きます。月末に集中していた作業が日次に分散した、退勤後の作業がなくなった、確認のタイミングが翌月から当日に早まった。こうした記述は、担当者がそのまま社内で使えます。

次の提案の出し方

継続を生む提案には型があります。思いつきで「他にも自動化できますよ」と言うのは逆効果です。

棚卸し表を作る

一件目の作業中に見聞きした周辺業務を、一覧にしておきます。業務名、発生頻度、手順の固まり具合、使うシステムの数、自動化した場合の影響範囲。この五項目で並べ、優先順位を付けて提示します。

優先順位の付け方には根拠が要ります。処理件数が多く、手順が固まっていて、失敗しても影響が限定的な業務が最優先です。逆に、判断が多く、頻度が低く、失敗すると外部に影響が及ぶ業務は後回しにします。この判断基準を添えて渡すと、担当者は社内で説明できます。

「やらないほうがよい業務」も入れる

棚卸し表には、自動化に向かない業務も理由付きで入れます。手順が固まっていない、月に一度しか発生しない、判断が属人的すぎる。これを正直に書くと、提案全体の信頼度が上がります。何でもできると言う人より、線を引ける人が信用されます。

一件目の改善案を先に出す

新しい業務の提案より前に、一件目の改善案を出すほうが通りやすい場合があります。すでに効果が見えている領域なので、社内の説明が簡単だからです。処理時間の短縮、例外への対応追加、通知の改善。小さな改修を挟むことで、関係が途切れずに続きます。

保守と継続の契約をどう作るか

継続を口約束にすると、双方が損をします。契約の形をはっきりさせておくことが、長く続ける条件です。

保守の範囲を三段階に分ける

現実的なのは、次の三段階です。第一段階は稼働の見守りで、異常時の一次調査と連絡が範囲です。第二段階は軽微な修正で、設定値の変更や画面の要素指定の修正など、あらかじめ定めた工数以内の作業を含みます。第三段階は機能追加で、これは都度の見積もりとします。

この三段階を書面にしておくと、「これは保守の範囲ですか」という不毛なやり取りが消えます。範囲外の依頼が来たときも、断るのではなく「第三段階として別途お見積もりします」と返せます。

対応時間を明記する

平日の何時から何時までを対応時間とするか、休日はどうするかを書きます。書かないと、相手は好意的に解釈して連絡してきますし、こちらは断りにくくなります。範囲を明示することは、相手を拒むことではなく、続けられる形を作ることです。

契約期間と更新の扱い

期間を定め、更新の意思確認を期限前に行う形にしておくと、双方が見直しの機会を持てます。自動更新にすると、依頼元が見直したいときに言い出しにくくなり、かえって関係がぎくしゃくします。※契約書の条項に不安がある場合や、報酬の未払いなどの具体的なトラブルが発生している場合は、弁護士など専門家への相談をおすすめします。

支払い条件の確認

発注する側と受ける側の取引条件については、近年、取引の適正化を目的とした法整備が進んでいます。契約内容の明示や支払い期日に関するルールが定められており、条文の内容は行政の公開情報で確認できます。制度の全体像はe-Govや公正取引委員会の公開情報が一次情報になります。継続案件では毎月の請求が発生するため、支払いのサイクルを最初に合意しておくと、後で揉めません。

継続を生みやすい業務、生みにくい業務

一件目にどの業務を選ぶかで、その後の展開の広がり方が変わります。継続を生みやすいのは、周辺に似た業務がぶら下がっている領域です。

代表例が経理まわりの処理です。入金の消込を一つ自動化すると、その前後に請求書の発行、支払いの登録、月次の集計といった処理が並んでいることが分かります。同じ部署、同じシステム、同じ担当者。二件目の話が出やすい構造になっています。

取引先に対する請求情報と実際の入金情報と照合して、確認が取れ次第消していく入金消込。毎日口座の入金情報を見ながら、目視と手作業で対応するとなると、取引先が多くなればなるほど相当な労力が必要になります。これも、RPAを活用することで作業を効率化できます。取引銀行のシステムから入金情報を取得し、それと同時に社内の会計システムから消込情報を取得して、データを突合。確認ができたものを消込、未入金のものをリスト化するといった作業をRPAで自動化することができます。出典: hitachi-solutions.co.jp

この例のように、複数のシステムからデータを取得して突合する処理は、部署をまたいで似た形が存在します。一件目で業務の構造を理解しておけば、二件目の見積もりは早く、精度も上がります。逆に、他とつながりのない孤立した業務を一件だけ引き受けると、終わった時点で関係も終わります。

引き受ける前に、その業務の前工程と後工程を聞いておくのが有効です。「この処理の前は誰が何をしていますか」「出た結果はどこへ渡りますか」。この二問で、周辺の業務が見えます。見えた業務は、そのまま棚卸し表の材料になります。

ツールと環境の選び方が、その後の関係を決める

継続できるかどうかは、着手時のツール選定と実行環境の決め方にも大きく左右されます。ここを自分の都合だけで決めた案件は、あとから必ず揉めます。

ライセンスの持ち主を最初に決める

有償のRPA製品を使う場合、ライセンスを誰が契約するかを最初に決めます。開発者が自分のライセンスで作ると、契約が終わった瞬間に依頼元の手元で動かせなくなります。逆に依頼元が契約すれば、費用は依頼元の負担になりますが、資産として社内に残ります。

どちらが正解ということはありませんが、決めずに進めるのが最悪です。納品直前に「これ、うちでは動かせないんですか」という話になると、それまでの信頼が一度に吹き飛びます。見積もりを出す段階で、ツールの費用負担と契約主体を書面に含めておきます。

実行環境を人の端末に依存させない

担当者の個人端末でロボットを動かす設計は、手軽ですが継続に向きません。その人が休んだ日に動かない、端末が更新されると止まる、退職すると全体が失われる。依頼元にとっては大きなリスクです。

共有の端末やサーバーで動かす形にできないかを、最初に相談します。難しい場合でも、どの端末に依存しているかを文書に残し、その端末の管理者を決めてもらいます。この一手間があるだけで、半年後の障害対応がまったく違うものになります。

選定の理由を残す

どのツールを選び、なぜ他の選択肢を採らなかったのかを記録します。無償のツールと有償の製品、業務システムに付属する自動化機能、表計算ソフトのマクロ。それぞれに向き不向きがあります。担当者が社内で「なぜこれを選んだのか」と問われたときに、そのまま使える説明を渡しておくと、担当者の立場が守られます。担当者を守る人は、次も呼ばれます。

依頼元の社内に自動化を根づかせる

一件で終わる人は、ロボットを納品します。継続する人は、ロボットと一緒に「自動化の進め方」を残します。この違いは大きい。

担当者が自分で候補を見つけられるようにする

自動化に向く業務の条件を、担当者に伝えておきます。処理件数が多い、手順が固まっている、入力元が安定している、失敗しても影響が限定的である。この四つの物差しを渡すと、担当者は日常の中で候補を見つけられるようになります。

自分の仕事が減ると考える必要はありません。候補を見つけられるようになった担当者は、こちらに相談を持ちかけてきます。相談が来る関係になれば、案件は自然に続きます。

小さく始めて広げる進め方を示す

最初から全社的な仕組みを作ろうとすると、要件がまとまらず時間だけが過ぎます。一つの業務で効果を確認し、その結果をもとに次へ広げる進め方を提案しておくと、社内の合意も取りやすくなります。担当者にとっては、稟議を通しやすい形で提案してくれる相手がありがたい存在です。

依頼元の担当者と一緒に触る時間を作る

引き渡し時に、手順書を渡すだけでなく、担当者と一緒に一度動かします。画面を見ながら操作すると、資料では伝わらない疑問がその場で出てきます。この時間を取った案件は、納品後の問い合わせが目に見えて減ります。問い合わせが減れば、こちらの負担も減り、継続を引き受ける余力が生まれます。

断ることで、かえって続く

継続を望むあまり、何でも引き受けてしまう人がいます。これは逆効果になりやすい。

自動化に向かない業務を引き受け、無理にロボットを作ると、保守の手間が効果を上回ります。数か月後に「あれ、結局手作業に戻したんですよ」という話になり、その失敗はロボットを作った人の評価になります。断るべき依頼を断ることは、長期の関係を守る行為です。

断り方には型があります。まず、依頼の背景にある困りごとを確認します。次に、その困りごとに対して自動化以外の解決策を提示します。手順の統一、書式の見直し、システムの標準機能の活用。そのうえで「自動化はこの整理が済んだ後のほうが効果が出ます」と順序を示します。これは断りではなく、順番の提案です。この対応をした人は、整理が済んだ段階で必ず呼ばれます。

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

20年この市場を見てきた立場から言えば、長く続く人ほど、単発の作業を速くこなすことではなく「この人に任せると楽だ」という関係づくりに時間を使っています。連絡が返る、資料が読める、無理なことは無理と言う。技術の高さより、この三つが揃っている人のほうが、結果として長く仕事が続いています。

運営者として見てきた限りでは、継続の生まれ方は契約の形にも左右されます。間に何社も入る形では、依頼元の担当者と直接話す機会が乏しく、業務の背景も社内事情も見えません。次の提案を出そうにも、材料が手に入らない。一方、依頼者と直接つながる形では、雑談の中から次の課題が出てきます。中間マージンが乗らない手数料0%の形は、同じ予算で依頼者はより多くを頼めて、受け手は手取りが厚くなる。金額の差に見えて、実際には「関係が続く前提で話ができるかどうか」という質の違いを生んでいます。

どんな依頼が実際に発生しているかを把握したい場合は、業務内容と求められる技能を整理したRPA・業務自動化ツールのお仕事が参考になります。自動化の周辺には、データ分析や情報管理の依頼も隣接しており、範囲を広げる方向を考えるときはAI・マーケティング・セキュリティのお仕事にも目を通しておくと判断しやすくなります。

技能の値づけを考えるうえでは、公的統計にもとづく職種別の水準が客観的な物差しになります。開発工程を担う人材の水準はソフトウェア作成者の年収・単価相場で確認でき、手順書や報告資料の作成が主体となる工程については著述家，記者，編集者の年収・単価相場が目安になります。継続案件では後者の比重が上がるため、両方を見ておくと自分の工数配分を説明しやすくなります。

引き渡し資料の質は、そのまま継続の可否に直結します。文書作成の基礎を体系的に確認しておきたい場合はビジネス文書検定の出題範囲が実務的な目安になります。

終わり方を設計する手順のまとめ方

最後に、ここまでを作業の順序に落とします。

着手前に、受け入れの基準と対応しない例外を文書で合意します。作業中は、設計判断の理由をその日のうちに一行書き足し、周辺業務を棚卸し表に貯めます。納品時に、運用手順書、障害時の対応表、設定値の一覧、手作業に戻す手順、未対応事項、変更履歴の六点を渡します。納品後の三週間は、処理件数と合計値と前日差を担当者と一緒に確認し、想定と実態のずれを拾います。稼働が落ち着いたら、変化を整理した資料と棚卸し表を渡し、優先順位と根拠を添えて次を提案します。保守は三段階に分けて範囲と対応時間を書面にします。

この流れを一度作れば、案件ごとに中身を差し替えるだけで使えます。RPA・業務自動化でリピートされるかどうかは、才能ではなく、この手順を持っているかどうかで決まります。

継続の可否は、納品物の完成度ではなく、依頼元が次に動きやすい状態を作れたかどうかで決まります。手順書が読める、範囲が書かれている、次の候補が並んでいる。この三つが揃っていれば、担当者は社内で次の話を進められます。逆に、どれだけ精緻なロボットを納めても、担当者が社内で説明できる材料を持っていなければ、二件目の稟議は上がりません。作る相手は担当者ではなく、担当者の向こうにいる決裁者だと考えて資料を作ると、継続の確率は確実に上がります。