RPA・業務自動化の継続案件にする｜単発で終わらせない

RPA・業務自動化の仕事は、ロボットを1本納品した時点で関係が切れやすい職種です。動くものを渡した以上、依頼側から見れば用件は済んでいるからです。結論から書くと、継続案件になるかどうかは技術力ではなく、受注直後の30日間で「運用が始まったあとに何が起きるか」を先に言語化できたかどうかで決まります。この記事では、単発で終わらせないために現場で実際に行われている手順と、そのときの判断の基準を順に整理します。

単発で終わる案件と続く案件を分けているもの

RPAの案件が単発で終わる典型は、依頼が「この作業を自動化してほしい」という作業単位で来て、そのまま作業単位で納品したケースです。作業単位の依頼は、作業が自動化された瞬間に完了します。次の依頼を出すには、依頼側が自分で次の自動化候補を探し、稟議を通し、再び声をかける必要があります。この手間を依頼側に負わせている限り、次の発注は運任せになります。

一方で続く案件は、納品物が「動くロボット」ではなく「動き続ける仕組み」として設計されています。仕組みには必ず、壊れたときに直す人、変化したときに直す人、次を決める人が要ります。その役割を最初の契約で自分の側に寄せておくと、案件は自然に運用フェーズへ移行します。技術的な難易度は変わりません。変わるのは、契約書と初期のヒアリングの設計です。

依頼側は「作った人」に頼み続けたい

自動化されたロボットは、社内の誰にとってもブラックボックスになりがちです。作った本人以外は中身を読めず、読めたとしても業務の背景まではわからない。だからこそ、依頼側は不具合が出たときに社内の情シスではなく、作った人に連絡したくなります。この心理は、業務が止まるリスクが大きい部門ほど強く働きます。

つまり継続の芽は、最初から依頼側の中に存在しています。問題は、連絡してよい相手なのかどうかが相手側からわからないことです。納品時に「今後の問い合わせは受け付けません」とも「受け付けます」とも言わずに終えると、依頼側は他社に相談してしまいます。継続案件にする第一歩は、技術の話ではなく、窓口を開いたままにする意思表示です。

自動化は一度で終わらないという前提を共有する

RPAの導入は、最初の1本で終わることはまずありません。1本動くと、隣の部署が同じ作業をしていたことがわかり、次の候補が出てきます。逆に、1本目がうまくいかないと社内の空気が冷え、次が出なくなります。したがって1本目の役割は、対象業務を自動化することだけでなく、社内に「これは続けられる」という手応えを残すことにあります。

この前提を初回の打ち合わせで共有しておくと、以降の会話が変わります。「今回の対象はここまでですが、運用が安定した段階で次の候補を一緒に洗い出しましょう」と最初に言っておくだけで、依頼側は次を前提に予算を考え始めます。言っていなければ、予算は単発として消化されて終わります。

受注直後の30日でやること

受注してから最初の1か月は、実装よりも観察に時間を割いたほうが結果的に早く終わります。RPAは業務の手順をそのまま写し取る性質があるため、手順の理解が浅いまま作ると、後から例外が出て作り直しになるからです。ここでの観察の質が、そのまま保守の量に跳ね返ります。

業務の棚卸しは画面ではなく帳票から始める

自動化対象の業務を教えてもらうとき、多くの現場では担当者が実際の画面操作を見せてくれます。ただし画面操作だけを見ると、その担当者の癖まで含めて写し取ってしまいます。先に確認すべきなのは、その業務に出入りする帳票やファイルです。入力元は何か、出力先はどこか、月次でどれだけの量が流れるのか。入口と出口を先に固定してから、間の操作を見に行くと、余計な作業を自動化せずに済みます。

棚卸しの過程で、実は不要だった手順が見つかることも珍しくありません。前任者が始めた確認作業が、システム更改で意味を失っているのに残っている、といったケースです。これを指摘できると、依頼側の評価は「言われたものを作る人」から「業務を見てくれる人」に変わります。この評価の変化こそが、次の依頼を呼ぶ最大の要因です。

例外ケースを先に列挙して合意する

RPAで最も工数が膨らむのは、例外処理です。通常の流れは短時間で組めますが、「取引先名が全角と半角で混在している」「月末だけ承認者が変わる」「年に数回だけ添付ファイルが2つ付く」といった例外が、実装の大半を占めます。これらを実装後に発見すると、追加費用の話がこじれます。

対策は、棚卸しの段階で例外を一覧にし、どこまでを今回の対象にするかを文書で合意することです。一覧に載せたうえで「今回は対象外」と決めた例外は、後から出てきても追加の相談として自然に扱えます。一覧に載せていない例外は、こちらの調査不足として無償対応を求められがちです。この差は大きく、例外一覧は見積書と同じくらい重要な成果物になります。

稼働環境の制約を最初に潰す

RPAは実行される端末の環境に強く依存します。誰のアカウントで動かすのか、端末はスリープしないのか、業務システムの更新はいつ入るのか、ウイルス対策ソフトが操作を妨げないか。こうした条件は、開発が終わってから確認すると必ず手戻りになります。

特に見落とされやすいのが、パスワードの定期変更です。業務システムのパスワードが90日ごとに強制変更される運用だと、ロボットは90日おきに止まります。これを知らずに納品すると、最初の停止で信頼を失います。逆に、事前に指摘して運用ルールまで一緒に決めれば、その時点で「運用まで見てくれる人」という位置づけが確定します。

ロボットは作った瞬間から劣化し始める

自動化の価値を語る文脈では、人と違ってミスをしないという点がよく強調されます。実際、稼働そのものの安定性は人の作業を上回ります。

デジタルレイバーは自己都合で辞めることはありませんし、24時間休みなく働き続けることも可能です。作業の初回から終わりまで、抜け・漏れや見落としといった“うっかりミス”とは無縁で、もし実際の稼働中にエラーが発生しても、1度修正すれば繰り返しません。さらに、業務の手順や仕様が急に変化しても、RPAツールで簡単な修正をすれば対応できる柔軟性も備えています。 出典: rpa-technologies.com

ここで注目すべきは、最後の一文です。手順や仕様が変わったときには修正が要る、と明記されています。つまり無人で動き続けることと、放置しても壊れないことは別の話です。この区別を依頼側と共有できているかどうかが、保守契約が取れるかどうかを分けます。

壊れる原因はほぼ外部にある

稼働中のロボットが止まる原因は、作りの問題よりも外部要因が圧倒的に多くなります。業務システムの画面レイアウト変更、ブラウザの自動更新、社内ネットワークの遅延、対象ファイルのフォーマット変更、共有フォルダのパス変更。どれもこちらの責任範囲の外で起きます。

この構造を納品時に説明しておかないと、停止したときに「作りが悪い」と受け取られます。説明の仕方は単純で、ロボットは操作を再現しているだけなので、操作する相手が変われば動かなくなる、と伝えれば十分です。そのうえで、変更が予定されている社内システムの更改スケジュールを共有してもらうよう依頼します。この依頼自体が、継続的な連絡関係を作ります。

停止は必ず起きるものとして手順を用意する

止まらないロボットを作るのではなく、止まったときに短時間で戻せる状態を作るほうが現実的です。具体的には、エラー時に処理を途中で止めて未処理分を記録する、担当者へ通知が飛ぶ、再実行しても二重処理にならない、この3点を設計に入れます。二重処理の防止は特に重要で、請求や在庫に関わる業務では、重複実行が実損につながります。

この設計が入っていると、停止しても業務は死にません。依頼側にとっては「止まったけれど困らなかった」という体験になり、ロボットへの信頼は逆に上がります。トラブルの経験を関係の強化に変えられるかどうかは、事前の設計で決まります。

保守を契約の言葉に落とす

継続案件の実体は、多くの場合が保守契約です。ただし「保守」という言葉は範囲が曖昧で、そのまま契約書に書くと、無限のサポートを期待されることになります。範囲を切る作業は、値段を決める作業よりも先に行います。

含むものと含まないものを並べて書く

保守の範囲は、含むものだけを書くのではなく、含まないものを同じ数だけ並べたほうが誤解が減ります。含むものの例としては、稼働監視、エラー発生時の一次調査、既存仕様の範囲内での軽微な修正、実行環境の変更に伴う設定調整。含まないものの例としては、新しい業務の自動化、対象システムの入れ替えに伴う全面改修、業務手順そのものの変更に伴う作り直しです。

この線引きを文書にすると、追加の相談が自然に発生します。「これは含まれない範囲ですね」という会話は断りではなく、次の見積の入口です。範囲を曖昧にしたまま全部引き受けると、追加の会話が生まれないまま作業だけが増えます。

応答の速さと対応の速さを分けて約束する

サポートの約束をするとき、問い合わせに返事をする速さと、修正を完了させる速さを混ぜてはいけません。修正の所要時間は原因によって大きく変わるため、完了を約束すると守れない場面が出ます。約束するのは応答の速さだけにして、営業日の受付時間内であれば1営業日以内に一次回答をする、といった形にします。

そのうえで、業務が止まる緊急度の高い停止と、翌日以降でも支障のない不具合を区別し、緊急時の連絡手段を別に決めておきます。この区別があると、深夜や休日の連絡が減ります。区別がないと、すべてが緊急として扱われます。契約書の文言は、こちらの生活時間を守る道具でもあります。

費用の形は月額固定か時間清算かを先に決める

保守の費用の形は、大きく分けて月額固定と、発生した作業時間での清算の2つです。月額固定は依頼側の予算化が容易で、社内稟議を通しやすい利点があります。時間清算は、作業が発生しない月に費用が出ない代わりに、毎回の承認が必要になり、心理的な壁が生まれます。継続を狙うなら、金額の大小よりも「毎月の稟議が不要である」ことのほうが効きます。

なお、業務委託の契約条件や支払い期日については、発注側にも法令上の義務があります。契約条件を書面や電磁的方法で明示すること、報酬の支払い期日を定めることなどが定められているため、条件が口頭のままになっている場合は、内容の確認を求めて問題ありません。制度の詳細は公正取引委員会の情報が参考になります。

引き継ぎ資料が次の依頼を呼ぶ

継続案件を狙うなら資料を出し惜しみすべきだ、という考え方があります。実務ではこれは逆効果です。資料がないロボットは、担当者が異動した時点で「誰も中身がわからない危険物」に変わり、まるごと作り直される対象になります。作り直しの発注が自分に来る保証はありません。

資料は運用者向けと開発者向けを分ける

必要な資料は2種類です。ひとつは運用者向けで、実行の手順、正常終了の見分け方、エラーが出たときに現場で確認する項目、連絡先を書いたもの。もうひとつは開発者向けで、処理の流れ、外部システムとの接点、例外処理の一覧、設定値の置き場所を書いたものです。

運用者向けの資料は現場に配り、開発者向けの資料は管理部門に預けます。開発者向け資料を渡すと乗り換えられると心配する人もいますが、実際には、資料が整っている業者ほど社内で評価され、次の案件で指名されます。文書を整える力は技術力と別に評価されるため、事務文書の書き方を体系的に学び直す価値もあります。文書作成の基礎を資格で確認したい場合はビジネス文書検定の出題範囲が実務の目安になります。

仕様変更の履歴を残す

継続案件では、半年後に「なぜこの処理だけ例外にしたのか」を誰も思い出せない事態が必ず起きます。変更のたびに、日付、変更内容、変更を依頼した部署、理由を1行ずつ残しておくと、この事故が防げます。履歴は複雑な管理ツールを使う必要はなく、表計算ファイル1枚で足ります。

この履歴には副次的な効果があります。契約更新の場面で、この半年に何をしてきたかを一覧で提示できることです。保守は成果が見えにくい仕事なので、更新のたびに価値を疑われます。履歴があれば、疑いに対して事実で答えられます。

次の自動化候補は相手の言葉の中にある

継続案件を伸ばす局面では、次に自動化する業務を提案する必要が出てきます。ここで多くの人が、自分の技術で作れるものから逆算して提案してしまいます。順序が逆で、先に相手の困りごとを集め、その中から自動化に向くものを選ぶほうが通ります。

現場の雑談を記録する

打ち合わせの前後で交わされる雑談には、次の候補が大量に含まれています。「月初は残業になる」「あの一覧を作るのが面倒」「毎回2人で目視確認している」。こうした発言を、その場で判断せずに記録しておきます。技術的に実現可能かどうかは後で考えれば済みます。

集めた困りごとは、頻度と所要時間の2軸で並べます。頻度が高く1回あたりの時間が短い作業は、自動化の効果が体感されやすく、社内の承認が通りやすい傾向があります。逆に、年に数回しか発生しない大がかりな作業は、効果額は大きく見えても、投資判断が保留されがちです。最初の提案では前者を選び、実績を作ってから後者に進む順番が現実的です。

自動化しないほうがよい業務を伝える

提案の説得力を上げる最短の方法は、自動化に向かない業務を正直に伝えることです。判断が人によって変わる業務、対象システムが頻繁に変わる業務、手順が文書化されておらず担当者ごとに違う業務は、自動化しても保守費用が効果を上回ります。

「これはやめておいたほうがよい」と言える相手は、社内で信用されます。一方、何でも自動化できると答える相手は、一度失敗した時点で切られます。RPAの周辺領域を含めた仕事の広がりを知っておくと、自動化以外の解決策も併せて提示できるようになります。対象業務の全体像はRPA・業務自動化ツールのお仕事で扱う範囲が参考になり、隣接する提案領域はAI・マーケティング・セキュリティのお仕事の内容が近い位置にあります。

ツールの選択が継続の長さを左右する

RPAの案件は、使うツールによって継続の形が変わります。ツールは大きく、端末上で動くデスクトップ型、サーバーで集中管理する型、ブラウザ上の作業を対象にするクラウド型に分かれます。どれを選ぶかは依頼側の情報システム部門の方針で決まることが多く、こちらが選べる場面は限られますが、それぞれの継続のしかたを知っておくと提案の精度が上がります。

デスクトップ型は導入が早く、現場の担当者の手元で完結します。その分、端末の入れ替えやアカウントの変更で止まりやすく、細かい保守が継続的に発生します。サーバー型は稼働の安定性が高い代わりに、権限やジョブ設計が複雑になり、体制の変更に合わせた再設計の依頼が周期的に出てきます。クラウド型は対象が限定されますが、導入の心理的な壁が低く、最初の1本を通しやすい特徴があります。

クラウド型RPAツールによる自動化のメーンターゲットは、Webブラウザ上で行われる単純作業で、現場の担当者が日々の業務の中で行っている作業を自動化できます。こうした身近な領域から業務自動化を進めることで、導入の効果がより早く感じられ、広範囲の業務自動化に取り組みやすくなるでしょう。 出典: rpa-technologies.com

近年の募集で目立つのは、既存のロボットを別のツールへ移す移行案件です。ライセンス方針の変更や統合を理由に、社内に蓄積した資産をまとめて作り替える必要が生じるためです。移行案件は対象が複数本まとまっているうえ、移行後の稼働確認と保守がそのまま続くため、継続に発展しやすい性質があります。新規開発の経験が浅くても、既存の仕様を読み解いて再現する作業は入りやすい入口になります。

副業として続ける場合の稼働設計

自動化の仕事は、本業を持ちながら副業として続けている人が多い領域です。開発そのものは時間をまとめて確保できれば進みますが、保守は連絡が不定期に来るため、副業との相性で問題が起きやすくなります。ここを設計せずに引き受けると、平日の日中に対応できず、信頼を落とします。

現実的な方法は3つあります。ひとつめは、対応する時間帯を契約で限定し、緊急時の一次対応は依頼側の社内で行える手順書を渡しておくこと。ふたつめは、エラー時の自動通知と再実行の仕組みを組み込み、人が介入する場面そのものを減らすこと。みっつめは、稼働が業務時間内に集中する処理は避け、夜間や早朝に実行する設計にして、確認を翌朝にずらすことです。

もうひとつ、副業で受ける場合に確認しておきたいのが、勤務先の就業規則と社会保険の扱いです。副業の可否は勤務先ごとに異なり、届出が必要な場合があります。健康保険や年金の扱いは働き方によって変わるため、判断に迷う場合は日本年金機構などの公的な情報で確認しておくと安全です。開発は自宅でできても、契約と制度の確認は後回しにできません。

現場に定着させないと契約は続かない

技術的に完成したロボットが、現場で使われないまま放置される例は少なくありません。原因の多くは、現場の担当者が「自分の仕事が奪われる」と感じている場合か、単に使い方がわからない場合です。どちらも技術では解決しません。

担当者の役割を言い換える

自動化の対象になった業務の担当者にとって、ロボットの導入は評価に直結する問題です。ここで「作業がなくなって楽になります」と説明すると、警戒されます。実務で通りやすいのは、確認と判断が仕事として残る、という説明です。実際、ロボットは判断を伴う作業を代替できないため、この説明は事実に沿っています。

導入時に、担当者本人にテスト実行をしてもらい、出力を確認してもらう工程を必ず入れます。自分で動かした経験があると、ロボットは奪う存在ではなく道具になります。この工程を省くと、稼働後に「結果が信用できない」という理由で二重チェックが残り、削減効果が出ません。

効果は依頼側が上に説明できる形で渡す

導入の効果は、こちらが把握しているだけでは意味がありません。依頼側の担当者が、上長に説明できる形で渡す必要があります。処理件数、実行にかかった時間、エラーの発生回数を月次でまとめた1枚があれば十分です。この1枚が、翌年度の予算を確保する材料になります。

運営者として長くこの市場を見てきた立場から言えば、長く続いている人ほど、自分の技術を説明する資料ではなく、相手が社内で使える資料を作っています。仕事を発注する側にも社内の事情があり、続けるための説明責任があります。そこを肩代わりできる相手は、多少ほかの条件が変わっても切り替えられません。

継続が切れる前に出る兆候

契約が終わるときは、突然終わるように見えて、必ず前兆があります。兆候を知っていれば、打ち手を打つ時間が作れます。

代表的な兆候は3つです。ひとつめは、窓口担当者が変わること。前任者との関係で続いていた契約は、後任にとっては引き継いだ費用項目でしかなく、見直しの対象になります。ふたつめは、問い合わせが減ること。順調だからではなく、社内で別の解決手段が動き始めている場合があります。みっつめは、対象システムの更改計画が共有されなくなることです。これは新しい相手が入っている可能性を示します。

打ち手はいずれも同じで、こちらから接点を作り直すことです。定例の報告を再開する、次の候補業務の提案を持っていく、更改予定を改めて確認する。反応がなければ、その案件は終わりに向かっています。その場合は、引き継ぎ資料を整えて円満に終えたほうが、後の再依頼につながります。

案件の探し方と、続く仕事の見つけ方

継続案件を増やす方法は、既存の関係を伸ばすことと、続きやすい案件を最初に選ぶことの2つに分かれます。後者について、募集の文面から判断できる材料があります。

続きやすい案件の文面には、対象業務が具体的に書かれ、稼働環境の条件が明示され、保守の扱いに言及があります。逆に、単発で終わりやすい案件は、成果物の完成だけが書かれ、運用の話が一切ありません。応募の段階で保守の予定を質問し、答えが返ってくるかどうかを見るだけでも、判断材料になります。

報酬の水準を判断するときは、単価そのものよりも、間に何社が入っているかを見る必要があります。同じ予算でも、中間に事業者が挟まるほど、依頼側が払った金額と手元に届く金額の差は開きます。開発系の職種全体の待遇の傾向はソフトウェア作成者の年収・単価相場で確認でき、ここでの水準感は自動化領域にもおおむね当てはまります。長期の働き方の設計については定年後のフリーランス独立｜退職金を活かした起業プランと注意点が、保守中心の仕事を年齢を重ねてから続ける観点で参考になります。

独自データから見える継続の構造

在宅ワークの募集を長く扱ってきた立場から見ると、自動化系の依頼には特徴的な傾向があります。最初の募集は作業単位で出るのに、実際に成立した後の追加依頼は、業務単位や部門単位で出てくることです。依頼側は最初、自動化で何ができるかを把握していないため、確実に説明できる範囲に絞って募集を出します。動くものを見た後で、初めて範囲を広げられるようになります。

この構造を知っていれば、最初の募集の小ささを理由に応募を見送るのは損だとわかります。判断すべきは初回の規模ではなく、その先に業務が積み上がっているかどうかです。募集文に部署名や業務システム名が具体的に書かれている案件は、社内に同種の作業が複数あることが多く、続く可能性が高くなります。

もうひとつ、20年この市場を見てきた立場から言えることがあります。中間に事業者が入らない直接の取引では、同じ予算でも依頼側はより多くの作業を頼めますし、受け手の手取りは厚くなります。手数料0%という条件は、金額の話に見えて、実際には関係の話です。差し引かれる分がないと、依頼側は浮いた分を追加の依頼に回せる。受け手は同じ作業量でも手取りが厚いので、保守のような地味な仕事を続ける動機が保てます。継続案件が成り立つのは、双方にとって続ける理由があるときだけです。

よくある質問

Q. RPAの案件で保守契約を提案するタイミングはいつが適切ですか？

納品時ではなく、最初の見積を出す段階で触れておくのが確実です。納品後に切り出すと、追加費用の要求と受け取られやすくなります。初回の提案書に、開発の範囲と運用開始後の想定を並べて書き、保守は別契約になる旨を明記しておくと、依頼側も予算を分けて考えられます。稼働が安定した1か月後を目安に、正式な契約へ移す流れが自然です。

Q. 開発したロボットの設計資料を渡すと、乗り換えられませんか？

実務では逆に働くことが多い仕組みです。資料がないロボットは中身が読めない危険物として扱われ、担当者が変わった時点で全面的な作り直しの対象になります。その発注が自分に来る保証はありません。資料を整えて渡す業者は社内で評価が高く、次の業務を任される確率が上がります。渡すべきは資料であって、判断の経緯まで含めた文脈は自然に手元に残ります。

Q. 稼働中のロボットが止まったとき、無償で直すべきですか？

原因の切り分けが先です。作りの不備であれば無償の修正になりますが、対象システムの画面変更やパスワード変更など外部要因による停止は、保守の範囲か追加作業かを契約で決めておく必要があります。契約前であっても、一次調査までは対応して原因を伝え、修正の可否と条件を提示する流れにすると、無償対応が際限なく広がるのを防げます。

Q. 継続案件になりやすい業務にはどんな特徴がありますか？

毎日または毎週といった高い頻度で発生し、対象のシステムが社内で長く使われている業務です。頻度が高いと効果が体感されやすく、社内での承認が通りやすくなります。逆に、判断が人によって変わる業務や、手順が担当者ごとに違う業務は、自動化しても保守の負担が効果を上回るため、続けるほど条件が悪くなります。

Q. 未経験からRPAの仕事に入る場合、何から手をつけるべきですか？

自分の職場や身近な事務作業を対象に、入力から出力までの流れを図に書き起こす練習から始めるのが近道です。ツールの操作は学習教材で身につきますが、業務の切り出しと例外の洗い出しは経験が要ります。あわせて、手順書や報告書を読みやすくまとめる力があると、運用フェーズで評価されます。募集の内容を読み込み、求められる範囲を把握しておくことも準備になります。