RPA・業務自動化の納期に間に合わないとき｜伝える順番

2026年3月27日

丸山桃子

この記事のポイント

✓RPA・業務自動化の納期遅れが見えたとき
✓再発を防ぐ分割納品の設計までを実務手順として整理します

RPA・業務自動化の案件で納期遅れが見えたとき、いちばんまずいのは「まだ間に合うかもしれない」と黙って手を動かし続けることです。RPAの開発は、対象業務の実物を触ってはじめて分かることが多く、着手前の見積もりからずれること自体は珍しくありません。問題はずれたことではなく、ずれを伝える順番を間違えて、依頼側の業務計画まで巻き込んで壊してしまうことにあります。

この記事では、納期遅れが起きる構造の話から始めて、遅れが確定する前に兆候をつかむ方法、第一報で何を先に言うべきか、原因別にどう手を打つか、そして契約と記録の面で押さえておくことまでを、受注側の実務手順としてまとめます。読み終えたときに、そのまま送れる連絡文の骨格が手元に残る形にしてあります。

RPA案件の納期遅れが起きる構造

納期遅れの対処を考える前に、なぜRPAの案件で遅れが起きやすいのかを押さえておく必要があります。原因の構造が分かっていないと、伝える内容がただの言い訳になり、次の依頼につながらないからです。

業務の実物を見ないと工数が読めない

RPAの開発対象は、依頼側の社内で長年運用されてきた手作業です。ヒアリングの段階では「請求データを基幹システムに登録するだけ」と説明されていた業務が、実際に画面を触ると、取引先ごとにファイル形式が違い、月末だけ承認者が増え、特定の条件のときだけ紙の書類を見に行く、といった分岐を持っていることがよくあります。

この「聞いた業務」と「実物の業務」の距離が、そのまま工数の誤差になります。しかも誤差は開発の中盤、テストデータを流し始めた頃に一気に表面化します。着手直後は順調に見えるのに、後半で急に進まなくなるのはこのためです。

さらにやっかいなのは、依頼側の担当者自身が全ての例外を把握していないことです。担当者は日々の作業として例外を処理しているので、それを「例外」だと認識していません。ヒアリングで漏れが出るのは、担当者が隠しているからではなく、当人にとっては当たり前の作業だからです。この前提を持っておくと、遅れの説明が相手を責める調子になりません。

環境の都合で手が止まる時間が長い

RPAは、依頼側のシステムに直接触る仕事です。開発用のアカウント発行、テスト環境の準備、対象システムの管理部門からの許可、社内ネットワークへの接続手段。これらはどれも受注側の努力では短縮できません。

「あとはテストするだけ」の状態で、テスト用のアカウントが降りてこないまま数日が過ぎる。この止まり方は、進捗率の数字には表れにくいのに、納期を確実に食います。RPA案件の遅延要因の中でも、この待ち時間の扱いを最初に決めておかなかったことが原因のものは、相当な割合を占めます。

「動いた」と「任せられる」の間に距離がある

自分の手元で一度通したロボットは、たしかに動きます。しかし依頼側が求めているのは、担当者が見ていない時間に、想定外のデータが来ても止まらずに、止まるときは正しく止まって通知が飛ぶ状態です。この「任せられる」水準まで持っていく作業は、最初に動かすまでの作業と同じか、それ以上の時間がかかります。

エラー時のリトライ設計、画面が想定と違ったときの停止条件、実行ログの残し方、担当者への通知。ここを最後にまとめてやろうとすると、納期の直前で膨らみます。見積もりの段階でこの部分を別工程として切っておくかどうかが、遅れの出方を大きく変えます。

遅れが確定する前に兆候をつかむ

納期遅れの連絡は、遅れた後に出すものではありません。遅れる可能性が見えた時点で出すものです。そのためには、自分の進捗を主観でなく、外から見て分かる形で測る必要があります。

進捗を工程でなく成果物で測る

「開発70%完了」という報告には意味がありません。RPA開発の進捗は、次のような成果物の単位で数えると、遅れが早く見えます。

・対象業務のうち、シナリオとして手順を書き起こせた作業の数・実データで通しテストが1回でも成功した作業の数・例外パターンを含めて連続実行できた作業の数・依頼側の担当者が自分で起動して結果を確認した作業の数

このうち3番目と4番目が動いていない状態で日数だけ過ぎているなら、その時点で赤信号です。1番目と2番目だけが進んでいる案件は、後半で必ず詰まります。

週次で見るべき指標

週に一度、次の3つを自分で確認しておくと、遅れの発見が数日早くなります。

1つ目は、未着手の作業に残っている日数です。残り作業を、これまでの実績ペースで割って所要日数を出します。感覚ではなく、実際に終わった作業にかかった日数を使うのが要点です。

2つ目は、待ち状態になっている項目の滞留日数です。アカウント発行待ち、仕様確認の返答待ち、テストデータの提供待ち。これらが3営業日を超えて動いていないなら、催促の仕方を変える段階に入っています。

3つ目は、新しく判明した例外パターンの件数です。この数が週を追うごとに減っていないなら、業務の全体像がまだ見えていません。増え続けている場合は、納期そのものを組み直す相談が必要です。

兆候が出た日に自分の手元でやること

赤信号が点いたら、依頼側に連絡する前に、まず自分の手元で3つ整理します。ここを飛ばして連絡すると、相手からの質問に答えられず、余計に不安を与えます。

第一に、遅れの見込み日数を幅で出します。「最短でも3営業日、最長で10営業日」のように、上限と下限をそろえて出します。単一の日付だけを出すと、それが守れなかったときに二度目の遅延連絡が必要になります。

第二に、遅れの原因を、受注側の要因と依頼側の要因と外部要因に分けます。分けること自体が目的で、責任の押し付け合いにするためではありません。依頼側の要因が含まれる場合、相手が動けば短縮できる余地があるということなので、それは相手にとっての選択肢になります。

第三に、部分的に先に渡せるものがないかを探します。全部そろわないと渡せない、という状態は多くの場合思い込みです。1つでも動くロボットがあるなら、それだけ先に本番で使ってもらう選択肢が生まれます。

伝える順番を間違えない

ここからが本題です。納期遅れの連絡は、内容そのものより順番で印象が決まります。多くの人が謝罪から書き始めますが、それは受け取る側にとって最も知りたい情報ではありません。

手順1 事実を確定させてから連絡する

「たぶん遅れそうです」という段階での連絡は、相手を不安にするだけで判断材料になりません。連絡する前に、何がどこまで終わっていて、何が終わっていないのかを確定させます。ただし確定に時間をかけすぎるのも問題で、目安としては赤信号を認識してから1営業日以内には第一報を出します。

確定させるべき事実は、現在の完了範囲、未完了の範囲、遅れの見込み幅、原因の3分類、この4点です。これ以上を待つ必要はありません。

手順2 影響範囲を最初に伝える

第一報の冒頭に置くべきは、謝罪でも原因でもなく、相手の業務にどう影響するかです。依頼側の担当者は、この連絡を受けた後、上長への報告や関係部署への調整をしなければなりません。その材料を最初に渡します。

具体的には、「当初予定していた月初の運用開始が、最短でも第2週にずれます。月初の締め作業は従来どおりの手作業で回していただく必要があります」という書き方です。相手が次に何をすればいいかが、最初の3行で分かる状態にします。

手順3 復旧案を2つ用意する

原因の説明の後に、どう取り戻すかの案を出します。案は1つでなく2つ出すのが実務的です。1つしかないと、それを受けるか揉めるかの二択になります。

典型的な2案は次の形です。A案は、範囲をそのままにして納期を延ばす案。B案は、納期を守るために対象業務を絞り、残りを第2弾として後日納める案。どちらが良いかは依頼側の事情によるので、こちらで決めずに材料として並べます。

案を出すときは、それぞれで何が犠牲になるかも書きます。B案を選ぶと、当初想定していた自動化の範囲が一部残るので、担当者の手作業がしばらく続く。この不都合を先に書いておくと、後から不満が出ません。

手順4 謝罪と再発防止は最後に置く

謝罪は必要ですが、最後に置きます。冒頭に長い謝罪文があると、読み手は肝心の影響範囲にたどり着くまでにスクロールすることになります。再発防止策も同様で、第一報では簡潔に触れる程度にとどめ、詳細は納品後の振り返りで出します。

第一報の目的は、相手が今日中に判断できる材料を渡すことです。反省の表明は、その次の優先度になります。

連絡文の組み立て方

順番が決まったら、あとは文面に落とします。ここでは第一報と、その後の更新連絡の型を示します。

第一報のひな型

件名には「遅延」の語を入れます。「進捗のご報告」のような柔らかい件名にすると、相手が開封を後回しにして、対応が遅れます。

本文の構成は次の順です。

1行目から3行目で、影響を書きます。「◯◯業務の自動化について、当初◯月◯日の納品予定でしたが、最短で◯月◯日、最長で◯月◯日にずれる見込みとなりました。◯月の締め作業は従来の手順で進めていただく想定でお願いいたします」

次の段落で、現状を書きます。完了している範囲と、未完了の範囲を並べます。ここは箇条書きが読みやすいです。

その次の段落で、原因を書きます。原因は事実だけを書き、感情や推測を混ぜません。「テスト段階で、取引先ごとにファイル形式が3種類存在することが判明し、当初1本で想定していた処理を分岐させる必要が出ました」のように、何が起きたかだけを書きます。

続けて復旧案を2つ並べ、最後に謝罪と、判断の期限を書きます。「◯月◯日までにどちらの案で進めるかご連絡いただけますと、その後の日程が確定いたします」と期限を添えると、相手も動きやすくなります。

更新連絡の出し方

第一報を出したら、そこで終わりではありません。決めた頻度で状況を更新します。頻度は第一報の中で宣言しておきます。「今後は毎週火曜と金曜の午前中に進捗をお送りします」と書いておけば、相手は間の日に催促する必要がなくなります。

更新連絡には、前回からの差分だけを書きます。全体像を毎回書き直すと、読む側の負担になります。「前回お伝えした3種類のファイル形式のうち、2種類の処理が完成しました。残り1種類は◯日に完了見込みです」という形で十分です。

そして、状況が悪化したときこそ、更新の頻度を落とさないことです。悪い報告をしたくなくて連絡が途切れるのが、信頼を最も損なう瞬間になります。

やってはいけない伝え方

いくつか、避けるべき伝え方があります。

まず、原因を依頼側の落ち度として書くことです。仕様の説明に漏れがあった場合でも、「ご説明いただいていなかった仕様が判明したため」とは書きません。「テスト段階で新たな仕様が判明したため」と、主体を出さずに事実だけを書きます。責任の所在は、契約と記録で扱う話であって、第一報で争う話ではありません。

次に、原因を技術的に細かく書きすぎることです。依頼側の担当者は開発の専門家ではないので、詳細な技術説明は判断の助けになりません。何が起きたかを業務の言葉で書きます。

最後に、遅れの見込みを楽観的に出すことです。間に合わせたい気持ちから短めの日数を出すと、二度目の遅延連絡が必要になります。二度目の遅延は、一度目の何倍も信用を削ります。

原因別の対処

遅れの原因によって、打つ手が変わります。ここでは代表的な4つに分けて整理します。

相手側の環境や権限の待ちが原因のとき

この場合、受注側が頑張っても進みません。やるべきことは、待ちが発生していることを可視化して、依頼側の担当者が社内で動ける材料を渡すことです。

具体的には、何日から何を待っているか、それが解消しないと何ができないか、いつまでに解消すれば納期に間に合うか、この3点を書いて送ります。担当者はこれをそのまま社内の情報システム部門に転送できます。「催促」ではなく「相手が社内で使える資料」として出すのが要点です。

また、待ちの間にできる作業を先に進めておくと、解消後の巻き返しが速くなります。テストデータの準備、シナリオの設計書作成、例外処理の方針整理などは、環境がなくても進められます。

対象業務の例外が後から出たとき

これは最も多い原因です。対処は、例外を全部拾い切ってから作り直すのではなく、まず例外の全体像を確定させる作業を独立した工程として切ることです。

依頼側の担当者と一緒に、過去数か月分の実データを見ながら、どのパターンが何回出ているかを数えます。頻度の低いパターンは、自動化の対象から外して手作業で残す判断もあり得ます。全部を自動化しようとして納期を落とすより、頻度の高いパターンを確実に自動化して先に渡すほうが、依頼側の得になることが多いです。

日立ソリューションズの解説でも、RPAの導入では自動化の範囲を見極めることが成功の条件として挙げられています。

金融業界を中心に大手企業が導入を始め、最近では中小企業でも導入が進んでいるRPA。手間のかかる定型業務を自動化することで、さまざまな業務効率化が図れるツールと言われていますが、実際にどんなことができるのかご存じでしょうか。企業としては、できるだけ多くの業務を自動化したいところですが、RPAにも得意・不得意があり、すべての業務を人間の代わりにできるわけではありません。出典: hitachi-solutions.co.jp

範囲を絞る提案は、逃げではなく、この見極めを実務に落とす行為です。そう説明できると、依頼側も受け入れやすくなります。

ツールの制約に当たったとき

使っているRPAツールの仕様上、どうしても実現できない処理に当たることがあります。特定の業務システムの画面を認識できない、ファイルの排他制御と競合する、実行ライセンスの本数が足りない、といったケースです。

このときは、代替手段を3つの層で検討します。第一に、同じツール内で別の方式に切り替えられないか。画面操作でなくファイル出力経由にする、といった迂回です。第二に、部分的に別のツールや簡易なスクリプトを組み合わせられないか。第三に、その処理だけ手作業として残す設計にできないか。

いずれの案も、依頼側の運用負担と保守のしやすさが変わります。案を出すときは、導入後に誰がどう保守するのかまで含めて説明します。ツールを増やすと後の保守が難しくなるため、案としては魅力的でも選ばれないことがあります。

自分の見積もり違いが原因のとき

原因が自分の見積もり違いだと分かった場合、それを隠さないことが結果的に一番早く収まります。ただし、伝え方は「見積もりが甘かった」という自己評価ではなく、「どの前提が実際と違っていたか」という事実で書きます。

「テスト工程を実データ1周分で見積もっていたが、実際には例外パターンごとに個別の確認が必要で、想定の周回数を超えました」という書き方であれば、相手も次回以降の見積もりの精度が上がると理解できます。

そのうえで、追加の費用を求めるかどうかは契約の内容次第です。固定報酬の契約で、原因が自分の見積もり違いであれば、追加請求は難しいのが通常です。ここで無理に費用を求めると、遅延の連絡が交渉に変わり、関係が悪化します。

契約と記録の面で押さえること

納期遅れは、感情の問題であると同時に契約の問題でもあります。ここを整理しておくと、話がこじれたときに戻る場所ができます。

検収条件と遅延の扱いを最初に確認する

契約書や発注書に、納期遅延時の扱いが書かれているかを確認します。遅延損害金の定めがあるのか、納期の変更はどういう手続きで行うのか、検収の合格条件は何か。これらは着手前に読んでおくべきものですが、遅延が見えた時点で読み直す価値があります。

特に重要なのが検収条件です。「正常に動作すること」とだけ書かれている契約は、後から解釈が割れます。何をもって完了とするかが曖昧なまま納期だけが決まっていると、納品したのに検収が終わらない、という別の遅延が起きます。

変更の記録をどこに残すか

RPA案件では、開発中に仕様が動きます。動くこと自体は避けられないので、動いた記録を残す場所を決めておきます。

打ち合わせの議事録をメールで送って相手の確認を取る、専用のシートに変更内容と決定日を書いて共有する、といった方法があります。口頭やチャットの流れだけで決まった変更は、後から「そんな話はしていない」となりやすいところです。

記録を残すのは相手を疑うためではありません。両者とも数か月前の会話は覚えていないので、共通の参照先を作るためです。

支払いに関する法律上の枠組み

業務委託で受けている場合、報酬の支払いに関する取り決めは、フリーランス・事業者間取引適正化等法の対象になり得ます。発注者は、給付を受領した日から起算して一定期間内に報酬を支払う義務を負い、受領を不当に遅らせることや、あらかじめ定めた報酬を一方的に減らすことは禁じられています。

納期遅れがこちらの原因である場合でも、納品済みの部分に対する支払いを無条件に止められるわけではありません。逆に、遅延によって発注者に損害が生じた場合は、その扱いを契約に沿って協議することになります。制度の詳細は公正取引委員会や中小企業庁の資料で確認できます。

ある電子機器メーカー様では、従来、商社から納入される材料に関し、納期遅延や予定前の入庫のチェックは担当者が随時行っており、約1時間/日を費やしていました。そこで、OLDEのRPA「発注検収結果反映システム」を導入。納期遅延を自動で検知し、担当者へアラートメールの自動通知を可能にしました。結果、人手によるチェック作業を無くし、正確な自動チェック作業も実現できました。出典: olde.co.jp

納期の遅れそのものをRPAで検知する、という発想は、受注側の進捗管理にも応用できます。自分の案件で、期日を過ぎた待ち項目を自動で洗い出す仕組みを作っておくと、赤信号の発見が確実に早くなります。

ツールの選び方が納期に効いてくる

納期遅れの話をするとき、見落とされやすいのがツール選定です。どのRPAツールで作るかは、開発の速さだけでなく、遅れたときの巻き返しやすさにも影響します。

開発が速いツールと、保守が楽なツールは別物

画面の記録機能が強く、手順を録画するだけでシナリオが組めるタイプのツールは、最初の1本を作るまでが速いです。初心者が最初に触るツールとしておすすめされることが多いのもこのタイプです。一方で、記録した手順は画面の位置に依存しやすく、対象システムの画面が少し変わっただけで止まります。

逆に、処理をコードに近い形で書くタイプは、最初の1本に時間がかかりますが、例外処理を明示的に書けるため、後半のテスト工程で崩れにくいです。納期が短い案件ほど前者を選びたくなりますが、例外パターンが多い業務では後者のほうが結果的に速く終わります。

選定の判断基準はひとつです。対象業務の例外パターンが多いか少ないか。ヒアリングの段階で例外が3種類以上見えているなら、記録型だけで押し切るのは危険です。

依頼側が既に導入しているツールがある場合

企業側が既にRPAツールのライセンスを持っているケースでは、原則としてそのツールを使います。ここで自分の得意なツールを提案し直すと、ライセンスの追加手続きが発生して、それ自体が納期を食います。

ただし、既存のツールでは実現が難しい処理に当たったときのために、着手前に「このツールで実現できない処理が出た場合、どう扱うか」を確認しておきます。手作業として残すのか、別の手段を検討するのか。この一問を最初にしておくだけで、後半で行き詰まったときの相談が格段にしやすくなります。

ツール起因の遅れを見分ける

遅れの原因がツールの制約なのか、自分の設計の問題なのかは、切り分けが必要です。判断の目安は、同じ処理を別の方式で書き直したときに動くかどうかです。画面操作でうまくいかない処理が、ファイル経由やAPI経由で動くなら、それは方式選択の問題であって、ツールそのものの限界ではありません。

この切り分けをせずに「ツールの制約で無理です」と伝えると、依頼側の情報システム部門から反論が来ることがあります。何を試して駄目だったかを記録しておくと、説明が通ります。

遅れを繰り返さない設計に変える

一度の遅延の対処より価値があるのは、次から遅れにくい進め方に変えることです。RPA案件では、次の3つが効きます。

分割納品を前提に組む

対象業務を1本のかたまりとして納めるのをやめて、作業単位で区切って順に納める形にします。1本目が本番で動き始めれば、依頼側はその時点から効果を得られますし、こちらも実運用でのフィードバックを2本目以降に反映できます。

分割納品には副次的な効果があります。1本目の納品時点で、依頼側の環境や承認の流れが実際に通るかどうかが分かるので、後半でまとめて詰まる事故を防げます。3本以上に分けられる規模なら、分割を検討する価値があります。

バッファの置き方を変える

工程ごとに少しずつ余裕を持たせるやり方は、実務ではあまり機能しません。余裕がある工程はその余裕を使い切ってしまい、足りない工程には回らないからです。

代わりに、全体の最後にまとめてバッファを置きます。そのうえで、そのバッファを何に使ったかを記録します。記録が溜まると、次回以降の見積もりで、どの工程がどれだけ膨らみやすいかが自分のデータとして分かります。

監視と引き継ぎ資料を先に作る

納品直前に作ることになりがちなのが、実行ログの設計と、担当者向けの操作手順書です。これを開発の後半でなく前半に作ると、遅れの影響を受けにくくなります。

さらに、手順書を先に書くと、仕様の抜けが早く見つかります。手順を文章にしようとして書けない箇所は、決まっていない箇所だからです。書けない箇所を依頼側に確認する作業が、そのまま例外パターンの洗い出しになります。

職種としてのRPA案件と、遅れの後にどう見られるか

RPA・業務自動化の仕事は、対象業務が企業ごとに違うため、案件ごとの個別性が高い領域です。どんな作業が発注されているかの全体像は、RPA・業務自動化ツールのお仕事にまとまっており、業務システム連携から定型作業の自動化まで幅広い依頼があることが分かります。隣接領域として、データ処理やAI活用と組み合わせた案件も増えており、こちらはAI・マーケティング・セキュリティのお仕事で扱われている仕事の内容が参考になります。

技術的な裏付けを外から見える形にしておくと、遅延の連絡をしたときの受け取られ方が変わります。ネットワークやシステム構成の理解があることを示す指標としてCCNA（シスコ技術者認定）のような認定を持っていると、環境まわりの説明に説得力が出ます。連絡文そのものの精度も評価に直結するため、ビジネス文書検定で扱われる文書構成の考え方は、遅延連絡のような難しい文面で効いてきます。開発職としての市場の位置づけを俯瞰したいときは、職種ごとの統計をまとめた資料に当たると全体像がつかめます。

20年この市場を運営してきた立場から見て、遅延を出した後に仕事が続く人と続かない人の差は、遅れの長さではありません。差が出るのは、連絡が来る早さと、連絡の中に相手が使える情報が入っているかどうかです。遅れの連絡が来た時点で、依頼側の担当者は自分の上長に説明する必要が生じます。そのとき、受注者からの連絡文をほぼそのまま転送できるなら、担当者にとってその人は「困ったときに助けてくれる相手」になります。逆に、連絡が遅く、内容も曖昧で、担当者が自分で情報を集め直さなければならないなら、次の依頼先から外れます。

もう一点、運営者として見てきた限りでは、直接取引の形で仕事をしている人ほど、この種の連絡が丁寧です。仲介が入らない取引では、発注者と受注者が直接やり取りするため、説明の質がそのまま関係の質になります。中間マージンが乗らない手数料0%の取引は、同じ予算で依頼側はより多くを頼め、受け手は手取りが厚くなる構造ですが、その分だけ関係を維持する責任も直接的です。長く続いている人は、遅延のような不都合な連絡こそ早く出すことで、その責任を果たしています。

海外案件では時差の関係でこの連絡の設計がさらに重要になり、Upworkの使い方ガイド｜日本人フリーランスが海外案件を取る方法でも、進捗共有の頻度が評価に直結する点が触れられています。年齢を重ねてから独立した人の事例をまとめた定年後のフリーランス独立｜退職金を活かした起業プランと注意点を読むと、技術力そのものより、報告の丁寧さで仕事を継続している例が多いことが見えてきます。