RPA・業務自動化の受ける相手を見きわめる｜断ってよい依頼

2026年5月10日

朝比奈蒼

この記事のポイント

✓RPA・業務自動化のクライアントの選び方を
✓依頼文と初回打ち合わせから読み取れる判断材料で整理しました
✓受けると消耗する依頼の特徴

RPAの案件で消耗するかどうかは、開発に入る前にほぼ決まっています。結論から言うと、依頼者を見きわめる作業は、技術的な要件を確認する作業よりも先に置くべきです。同じ内容の自動化でも、依頼者側の準備状況と意思決定の構造が違えば、必要な工数は何倍にも変わるからです。

この記事では、RPA・業務自動化のクライアントの選び方について、依頼文の段階で読み取れる情報、初回の打ち合わせで確認すべき質問、受けると消耗しやすい依頼の特徴、そして角を立てずに断る方法までを順に整理します。正直なところ、この領域は「断る技術」を持っているかどうかで、働き方の質が大きく変わります。

RPA案件で相手を見きわめる必要がある理由

Web制作やライティングの案件では、成果物の範囲が比較的はっきりしています。ページ数、文字数、デザインの点数といった単位で区切れるためです。ところがRPAは、成果物が「業務が自動で回る状態」であり、その業務の輪郭は依頼者の頭の中にしかありません。

依頼者が自分の業務を説明できないことがある

これは能力の問題ではなく、業務が長年の慣習で回っているからです。日々こなしている作業を、他人に伝わる手順として言語化する機会は、通常の業務のなかでほとんどありません。そのため、依頼者が説明する手順と、実際に行われている作業の間には、ほぼ確実にずれがあります。

このずれを埋める作業を、誰がどこまで担うのか。ここが決まっていない案件は、開発の工程に入る前の段階で時間を消費します。依頼者が業務整理を担ってくれる案件と、開発者が業務整理から担う案件では、必要な準備がまったく違います。後者が悪いわけではなく、その分を見積もりと期間に反映できているかどうかが問題です。

自動化の可否は依頼者側の条件で決まる

RPAは万能ではありません。判断に人の裁量が入る業務、入力の形式が毎回異なる業務、紙の書類が起点になる業務は、そのままでは自動化に向きません。この点は、ツールを紹介する記事でも共通して指摘されています。

毎日繰り返されるデータ入力や転記作業、帳票作成といった定型業務に、多くの時間を費やしていないでしょうか。業務自動化ツール（RPA）は、こうしたルーティン作業をソフトウェアロボットが代わりに実行することで、担当者の工数を大幅に削減し、ミスのない処理を24時間継続できる仕組みです。出典: japan-ai.co.jp

つまり、RPAが力を発揮するのは定型業務です。ところが依頼者は、自分の業務が定型かどうかを判断できていないことが多い。だからこそ、依頼を受けるかどうかの判断は、対象業務が本当に定型であるかを確認したうえで行う必要があります。ここを確認せずに受けてしまうと、開発の途中で「この判断は自動化できません」と伝えることになり、依頼者は期待を裏切られたと感じます。

依頼文の段階で読み取れること

案件の募集文や最初の連絡には、依頼者の準備状況がかなり出ます。ここで判断できることは判断してしまうほうが、時間の節約になります。

良い兆候として読める記述

対象業務が具体的に書かれている依頼は、期待が持てます。「毎朝、基幹システムから前日の受注データを出力し、指定の様式に転記して部内に共有している。この転記部分を自動化したい」。この水準で書けている依頼者は、業務を工程として把握できています。

使用しているシステム名やツール名が明記されているのも良い兆候です。対象が特定できていれば、動作環境の確認が早く進みます。さらに、既に部分的な自動化を試したことがある、社内に情報システムの担当者がいる、といった記述があれば、変更管理の相手が存在することを意味します。

「まずは一つの業務から始めたい」という記述も、実は重要な兆候です。小さく始める意図を持っている依頼者は、自動化の効果を測ってから次に進む姿勢があり、無理な要求をしにくい傾向が見られます。

注意して読むべき記述

反対に、慎重に扱うべき記述もあります。「社内の事務作業を全部自動化したい」という抽象的な依頼は、対象が定まっていないことを示します。この場合、受注前に対象業務を一つに絞る合意が必要です。絞らずに着手すると、範囲が動き続けます。

「簡単な作業なのですぐできると思います」という前置きも、注意して読む記述です。作業自体は簡単でも、例外処理とエラー処理を含めた実装は簡単ではありません。この認識のずれを開発前に埋めておかないと、工数の説明が最後まで通じません。

「予算はあまりないが、うまくいけば継続的にお願いしたい」という書き方は、条件を先送りにする姿勢の表れです。継続の可能性を理由に初回の条件を下げると、その水準が基準になります。継続の話は、初回の条件を確定させたうえで別に議論すべきものです。

初回の打ち合わせで確認すべきこと

依頼文だけで判断しきれない部分は、初回のやりとりで確認します。ここで聞くべき質問は決まっています。技術的な質問より先に、体制と意思決定の構造を確認してください。

誰が最終的に判断するのか

窓口の担当者に決裁権があるのか、上長の承認が必要なのか、複数部署の合意が要るのかを確認します。これを聞かずに進めると、仕様が固まったあとで別部署から要望が入り、やり直しになります。

決裁の構造が複雑な案件が悪いわけではありません。複雑であれば、その分の確認期間を工程に組み込めばよいだけです。問題なのは、構造を知らないまま短い納期で受けてしまうことです。

対象業務を実際に見せてもらえるか

「実際の作業を画面共有で見せていただけますか」という依頼に、前向きに応じる依頼者かどうかは、大きな判断材料になります。応じてもらえれば、業務の実態を直接確認でき、例外処理を洗い出せます。

理由なく難色を示す場合は、社内の調整が難しいか、担当者が業務を把握していないかのどちらかです。前者なら期間を長めに取り、後者なら業務整理そのものを作業として見積もりに含める必要があります。この確認一つで、案件の性質がかなり見えます。

動作させる端末と権限はどうなっているか

RPAは端末上で動きます。そのため、実行する端末の管理者権限、ソフトウェアのインストール可否、セキュリティ製品による制限、リモート接続の可否といった条件が、実装可能性を直接左右します。

情報システム部門の承認が必要な環境で、その承認プロセスを確認せずに着手すると、完成したのに動かせないという事態が起こります。これは技術的な失敗ではなく、確認漏れによる失敗です。着手前に、実行環境と権限の確認を必ず入れてください。

業務が変わる予定はあるか

近い時期に基幹システムの入れ替えや業務フローの変更が予定されていないかを聞きます。予定があるなら、自動化の対象を変更後の業務に合わせるか、変更前提で保守の条件を設計するかを決めます。

この質問を投げると、依頼者側も「そういえば来期から様式が変わる」と思い出すことがあります。事前に分かれば設計に織り込めますが、開発後に判明すれば作り直しです。聞くだけで防げる失敗は、聞いて防ぐべきです。

受けると消耗しやすい依頼の型

現場の相談で繰り返し見られる、消耗しやすい依頼の型があります。すべてを避ける必要はありませんが、該当する場合は条件を厚くしてから受けるべきです。

効果の測定基準が示されない依頼

「効率化したい」という目的だけがあり、何をもって成功とするかが決まっていない依頼です。この場合、納品後の評価が依頼者の主観になります。動くものを納めても「思ったほど楽にならない」と言われる余地が残ります。

対策は、着手前に測定基準を合意することです。処理にかかっていた時間、対象となる件数、削減したい作業の範囲。数字でなくても、「この工程を人が触らなくなること」という状態の合意でも構いません。基準がないまま進めるのは避けてください。

依頼者側に検証できる人がいない依頼

作った自動化が正しく動いているかを、依頼者側で確認できる人がいない案件です。この場合、検証の負担がすべて開発側に来ます。しかも、正しい結果がどれかを知っているのは依頼者側なので、確認できないまま検収が長引きます。

受ける場合は、検証に立ち会える担当者の指定を条件にします。「テスト時に業務担当の方に確認いただける時間を確保してください」と最初に伝え、応じられない場合は納期を延ばすか、検証工程を有償の作業として見積もりに入れます。

過去に他の開発者が離脱している依頼

前任者が途中で降りた案件は、理由の確認が必要です。技術的に難しかったのか、条件の折り合いがつかなかったのか、依頼者側の対応に問題があったのか。理由によって、受けてよい案件かどうかが変わります。

正直なところ、この確認を遠慮する人が多いのですが、聞いて機嫌を損ねるような相手であれば、その反応自体が判断材料になります。前任者の成果物を引き継ぐ場合は、その品質を確認するための調査工数を別途見積もってください。既存の実装を読む作業は、新規に作るより時間がかかることがあります。

「ついでに」が続く依頼

打ち合わせのたびに、対象範囲が少しずつ広がる依頼です。一つ一つは小さいため断りにくく、気づくと当初の倍以上の作業になっています。

この型は、依頼者に悪意がないことがほとんどです。自動化の可能性が見えてくると、他にもやりたいことが浮かぶのは自然な反応です。だからこそ、追加の要望が出たときの扱いを最初に決めておきます。「追加のご要望はいったん一覧に記録して、現行分の納品後にまとめてお見積もりします」という運用にすれば、要望を拒否せずに範囲を守れます。

依頼者の環境から読み取る判断材料

依頼者が使っているツールや社内体制からも、案件の性質は読み取れます。ここを見る目を持っておくと、打ち合わせの短い時間で判断の精度が上がります。

導入済みのツールがあるかどうか

社内に既にRPAツールが導入されている場合、ライセンス、実行環境、管理者の所在がある程度整理されています。この場合、開発者はロボットの設計と実装に集中できます。ツールの選定から関わる案件と比べて、着手までの助走が短くて済みます。

一方、ツールが未導入の案件では、選定そのものが作業になります。選び方のポイントは、対象業務の性質と、社内で保守できる人がいるかどうかです。現場の担当者が自分で手直しできることを重視するタイプのツールも増えています。

ロボオペレータは、現場の実務担当者が使うことを前提に設計されたAI搭載のRPAツールです。プログラミング知識が一切不要で、視覚的・直感的な操作でロボットを作成できるため、システム部門に依存せず現場が自律的に業務自動化を推進できます。出典: dx-pro.resocia.jp

つまり、現場が自分で触れることを前提としたツールを選ぶと、納品後の細かな手直しを依頼者側で吸収できます。これは依頼者にとってのメリットであると同時に、開発者にとっても、納品後の細かい連絡が減るというメリットになります。逆に、開発者しか触れない作りにすると、保守の依存度が高まり、短期的には仕事が続くように見えても、依頼者側の不満が溜まりやすくなります。

ただし、現場で触れる作りにはデメリットもあります。依頼者側が手を入れて動かなくなったときに、原因の切り分けが難しくなる点です。この場合は、改変後の動作を保証対象外とする条件を先に決めておく必要があります。ツールの選び方は、実装のしやすさだけでなく、納品後の責任の切り分けまで含めて考える論点です。

情報システム部門との距離

社内に情報システムの担当者がいるかどうかで、進行の性質は変わります。担当者がいる場合、実行環境の準備、権限の付与、セキュリティ製品の例外設定といった作業を依頼できます。反面、承認プロセスが増えるため、着手までの期間は長くなります。

担当者が不在で、現場の担当者だけで進める案件は、意思決定は早いものの、環境面の障害が出たときに解決手段がありません。この型の案件を受ける場合は、実行環境の制約が判明した時点で仕様を見直す前提を、着手前に共有しておいてください。この一言があるかどうかで、途中の方向転換のしやすさが変わります。

過去の自動化の履歴

社内で以前に自動化を試したことがあるか、それがどうなったかを聞いておくと、依頼者の温度感が分かります。過去に導入して定着しなかった経験がある場合、その理由に今回も同じ落とし穴がある可能性があります。

よくあるのは、作った人が異動していなくなり、誰も直せなくなって使われなくなったという経緯です。この経験がある依頼者は、保守の重要性を理解しているため、条件の話が通りやすい傾向が見られます。逆に、初めての自動化で期待値だけが高い依頼者には、できることとできないことの説明に時間を割く必要があります。

受注前に決めておくと失敗が減るポイント

相手を見きわめたうえで受けると決めたなら、着手前に条件を固めます。ここで手を抜くと、見きわめた意味がなくなります。

対象範囲を工程単位で書く

「請求処理の自動化」ではなく、「基幹システムから請求データを出力し、指定の様式へ転記し、PDFとして所定のフォルダに保存するまで」と書きます。工程の始点と終点を明示すると、その外側の作業は範囲外であることが自動的に決まります。

範囲外にした工程は、明示的に「本作業には含まない」と書いておくとさらに安全です。書かなければ、依頼者は含まれていると考えます。この非対称性を理解している人と、していない人で、後半の消耗の量が変わります。

例外処理の扱いを決める

自動化の実装でもっとも工数を食うのは、正常系ではなく例外系です。データが空だったとき、対象が見つからなかったとき、システムの応答が遅かったとき。これらをどう扱うかで、実装量は大きく変わります。

決めておくべきは、例外時に処理を止めるのか、飛ばして次に進むのか、通知を出すのかです。この方針を依頼者と合意しておけば、実装の判断が迷いなく進みます。合意していないと、納品後に「エラーで止まっていることに気づかなかった」という指摘が来ます。

検証データを誰が用意するかを決める

テストに使うデータを依頼者が用意するのか、開発者が作るのかを決めます。実データには個人情報や取引情報が含まれることが多く、そのまま受け取ることには慎重であるべきです。依頼者側でマスキングしたデータを用意してもらうのが基本になります。

この調整には時間がかかります。着手後に依頼者へ頼むと、データが揃うまで作業が止まります。受注時点で「テスト用データのご用意をお願いします」と伝え、いつまでに揃うかを工程に入れてください。

成功の条件を文章にする

何をもって完了とするかを、一文で書けるかどうかを確認します。「毎朝8時に自動で実行され、前日分の受注データが指定様式で所定フォルダに保存されている状態」。この形で書けていれば、検収の議論は起きません。

書けない場合、まだ要件が固まっていません。固まっていない状態で見積もりを出すと、後から範囲が広がります。この一文を依頼者と一緒に作る作業を、受注前の最後の工程に置いてください。

書面でのやりとりを避けようとする依頼

条件を文書にしようとすると話をそらす、契約書の締結を面倒がる、口頭やチャットの断片的なやりとりだけで進めようとする。この姿勢が見える依頼は、条件が守られない可能性を織り込むべきです。

取引条件の明示は、フリーランス保護新法（特定受託事業者に係る取引の適正化等に関する法律）のもとで発注者側の義務として整理されています。制度の内容は公正取引委員会が公表しています。つまり、条件を書面や電磁的方法で示すことは、開発者側のわがままではなく、発注者が本来行うべきことです。この前提を知っておくと、条件の提示を依頼する場面で気後れせずに済みます。

断ってよい依頼と、その伝え方

すべての依頼を受ける必要はありません。むしろ、条件の合わない依頼を受けることは、依頼者にとっても良い結果になりません。中途半端な成果物と気まずい関係が残るだけです。

断ってよいのは、次のような場合です。対象業務が定型ではなく、自動化しても効果が出ないと判断できる場合。実行環境の制約により、技術的に実現できない場合。決裁の構造が確認できず、仕様が固まる見込みがない場合。提示された条件と必要な工数が明らかに釣り合わない場合。そして、やりとりの段階で、書面での合意に応じない姿勢が見える場合です。

断り方には型があります。否定から入らず、判断の根拠を示し、代替案を添える。この3点です。たとえば「ご相談ありがとうございます。伺った内容ですと、対象の業務に人の判断が入る工程が含まれており、自動化しても確認作業が残るため、期待される効果が出にくいと考えます。まず、前段のデータ集計の部分だけを対象にする方法であればお役に立てます」という形です。

この伝え方であれば、依頼者は拒否されたとは受け取りません。実際、断った案件の依頼者から、条件を整えて再度相談が来ることは珍しくありません。断ることは関係を切ることではなく、条件を提示することです。

条件を厚くして受けるという選択

断るか受けるかの二択ではなく、条件を変えて受けるという選択肢もあります。業務整理の工程を別作業として見積もる、対象範囲を一工程に絞る、検証期間を長めに取る、保守の条件を先に決める。これらはすべて、消耗を防ぐための条件設計です。

条件を提示した結果、依頼者が離れることもあります。それは相性の問題であり、失注ではなく回避と考えるべきです。条件を飲めない依頼者と進めた場合に発生していたはずの損失を、事前に避けたことになります。

見きわめた結果を提案書に反映する方法

相手を見きわめた結果は、頭の中に留めず、提案書や見積書に反映します。判断の根拠を相手にも見える形にすることで、条件の交渉が個人の主張ではなく、業務上の必要として扱われます。

前提条件の欄を必ず設ける

提案書には、金額と作業内容だけでなく、前提条件の欄を作ります。対象の実行端末、必要な権限、依頼者側で用意するもの、確認に立ち会う担当者、テストデータの提供時期。これらを列挙します。

前提条件が崩れた場合の扱いも一行添えます。「上記前提に変更が生じた場合、工数および納期を再度お見積もりします」。この一文があると、途中の変更を交渉の場に戻せます。書いていなければ、変更は無償で吸収されるものと解釈されます。

工程を分けて提示する

一括の金額で提示するのではなく、業務整理、設計、実装、テスト、引き渡しといった工程に分けて提示します。分けて出すと、依頼者は各工程の意味を理解でき、業務整理に工数がかかる理由も伝わります。

工程を分ける利点はもう一つあります。依頼者の予算が合わない場合に、工程単位で調整できることです。全体の金額を値引きするのではなく、「業務整理の部分を貴社で担っていただければ、その分を外せます」という提案ができます。値引きではなく、範囲の調整として交渉できる形にしておくことが大切です。

判断材料が足りないときは調査を有償の工程にする

見きわめようとしても、情報が出てこない案件があります。依頼者自身が業務を把握しておらず、実行環境の条件も分からない。この状態で全体の見積もりを出すと、必ず外れます。

このときに有効なのが、調査だけを独立した工程として提案する方法です。対象業務の棚卸しと実行環境の確認を行い、その結果をもとに本開発の見積もりを出す、という二段構えにします。依頼者にとっても、いきなり大きな金額を決めずに済むため、受け入れられやすい形です。

この方法には、もう一つの効果があります。調査工程を一緒に進めるなかで、依頼者の対応の速さ、資料の出し方、決裁の通り方が見えます。つまり、本開発を受けるかどうかを判断する材料が、実際の協働を通じて手に入ります。書面上の情報だけで判断するより、はるかに精度が高くなります。調査の結果、自動化に向かないと分かった場合でも、その判断自体が依頼者にとって価値のある成果になります。

期間の見積もりに確認待ちを織り込む

作業時間だけで納期を出すと、必ず遅れます。依頼者側の確認待ち、環境準備の待ち、承認の待ち。これらは開発者が制御できない時間です。

見積もりの段階で、確認に要する期間を明示します。「テスト結果のご確認に3営業日を見込んでいます」。この形にしておけば、確認が遅れたときに納期がずれる理由を、責任の押し付け合いにせず説明できます。段取りを可視化しておくことが、遅延をめぐる摩擦を減らす方法です。

案件の入口をどこに置くか

20年この市場を見てきた立場から言えば、依頼者を選べるかどうかは、開発者の交渉力だけでなく、案件をどこから取っているかに大きく左右されます。仲介が何層も入る経路では、開発者が依頼者本人と話す機会が限られ、業務を実演してもらうことも、決裁構造を確認することも難しくなります。判断材料がないまま受けるしかない状態が、そもそも消耗の入口です。

一方、依頼者と直接やりとりできる経路では、着手前の確認をすべて自分の手で行えます。中間マージンが乗らない直接取引では、同じ予算でも依頼者はより多くを頼め、受け手は手数料0%のぶん手取りが厚くなります。ただ、長く続けている人が重視しているのは金額よりも、条件を自分で決められるという点のほうです。運営者として見てきた限りでは、安定して続いている開発者ほど、受注前の確認に時間をかけ、その結果として断る案件も持っています。

RPAの依頼がどのような形で発注されているかを知っておくと、依頼文を読む精度が上がります。定型業務の自動化がどう案件化されているかはRPA・業務自動化ツールのお仕事にまとまっています。自動化の周辺では、データ分析や広告運用の効率化といった隣接領域の依頼も発生します。この広がりはAI・マーケティング・セキュリティのお仕事で確認できます。

条件の妥当性を判断するには、開発職の報酬水準の考え方を知っておくと役立ちます。基準となる情報はソフトウェア作成者の年収・単価相場で整理されています。また、確認事項を文書として整える力は、そのまま案件の安全性に直結します。実務文書の型を体系的に学べるものとしてビジネス文書検定があります。ネットワークやセキュリティの制約が絡む環境を扱うなら、CCNA（シスコ技術者認定）の知識が、実行環境の確認や情報システム部門との会話で効いてきます。

依頼を受けるかどうかの判断は、技術的にできるかどうかではありません。この依頼者と、この条件で、完了まで進められるか。この問いに答えられる材料を集めてから受ける。それが、RPAの仕事を長く続けるための最初の工程です。