RPA・業務自動化の最初の打ち合わせで聞くこと｜後戻りを防ぐ

RPA・業務自動化の初回の打ち合わせは、案件の成否がほぼ決まる場です。結論から書きます。初回で聞くべきなのは「何を自動化するか」ではなく、「どの条件が揃えば自動化を止めずに済むか」です。前者だけを聞いて帰ると、開発の終盤で必ず後戻りが起きます。この記事では、初回の打ち合わせで必ず確認する質問と、その回答をどう判断するかの基準を、受注後の実務の手順として整理します。

初回の打ち合わせで本当に決まっているもの

RPAの案件で後戻りが起きるとき、原因はほとんど技術ではありません。対象業務の輪郭が曖昧なまま作り始めたこと、例外処理の数を誰も数えていなかったこと、実行する端末や権限の話が最後まで出てこなかったこと。この3つに集約されます。どれも初回の打ち合わせで聞けば分かる話であり、聞かなかったから分からなかっただけです。

発注側の担当者は、多くの場合「この作業を自動化したい」という粒度で話を始めます。そこで受け手が「承知しました」と受け止めると、以降の会話はすべてその粒度のまま進みます。作業と業務は違います。作業は手を動かす単位で、業務は責任を負う単位です。自動化するのは作業ですが、止まったときに困るのは業務です。初回で切り分けておかないと、納品後に「この場合はどうなるんですか」という質問が延々と続きます。

もう1つ、初回の場で確定しておくべきなのが意思決定の経路です。目の前の担当者が決められる範囲はどこまでか、稟議が要る金額や条件は何か、情報システム部門の承認が必要か。ここを曖昧にしたまま設計を進めると、完成した頃に別の部署から差し戻しが来ます。RPAは他部門のシステムに触る性質上、担当者だけで完結する案件のほうが少ないという前提で臨むのが安全です。

「作れますか」に即答しない

初回の打ち合わせでよく飛んでくるのが「これ、RPAで作れますか」という質問です。ここで即答すると、その場の空気は良くなりますが、後で必ず不利になります。作れるかどうかは、画面の構造、データの持ち方、例外の量、実行環境の制約で決まります。それらを見ないうちの「作れます」は、条件付きの約束を無条件の約束に変えてしまう行為です。

代わりに返すべきなのは「作れる可能性は高いですが、判断のために3つ確認させてください」という形です。確認する項目を先に言うことで、こちらが何を見ているのかが相手に伝わり、専門性の提示にもなります。その場で答えが出なくても構いません。むしろ答えが出ない項目こそ、後戻りの火種として記録しておく価値があります。

RPAが得意とする領域には明確な傾向があります。この点は導入支援の現場でも繰り返し語られています。

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

つまり、初回で確認すべきなのは「手順が決まっているか」「アプリケーションをまたぐか」「量はどれくらいか」の3点です。この3つが揃っていれば効果が出ますし、揃っていなければ、揃うように業務側を整えてもらう提案が先になります。

打ち合わせに入る前に用意しておく3点

準備なしで初回に臨むと、その場は雑談で終わります。相手も何を話せばいいのか分かっていないことが多いためです。逆に、こちらが枠組みを持ち込めば、相手はその枠に沿って情報を出してくれます。用意すべきなのは次の3点です。

業務の棚卸しシートを事前に送る

対象業務を1行ずつ書き出してもらうシートを、打ち合わせの数日前に送ります。列は「業務名」「発生頻度」「1回あたりの所要時間」「使うシステム」「担当者」「例外が起きる条件」の6つで十分です。これを埋めてもらうだけで、当日の会話が具体になります。

重要なのは、埋まらなかった欄そのものが情報になるという点です。「例外が起きる条件」が空欄で返ってきたら、それは例外がないのではなく、例外を誰も把握していないという意味です。ここを当日の最優先の議題にします。所要時間が空欄なら、効果測定の基準が社内にないということですから、これも先に決めておく必要があります。

シートを送るときは「完璧に埋めなくて構いません」と添えます。完璧を求めると返ってこなくなり、当日の準備がゼロになります。埋まった部分から議論を始めるほうが、結果的に多くの情報が取れます。

実行環境の質問票を作っておく

RPAは動く場所を選びます。担当者のPCで動かすのか、共用のサーバーで動かすのか、仮想デスクトップの中なのか。これによって設計が根本から変わります。事前に質問票の形にしておき、当日にその場で埋めていくのが効率的です。

質問票に入れる項目は、OSの種類とバージョン、実行する端末の管理者権限の有無、業務時間外に端末を起動したままにできるか、社内ネットワークの制限、対象システムへのログイン方法とアカウントの管理者、この5つです。どれも技術的な確認に見えますが、実際には運用の話です。たとえば「業務時間外に端末を起動したままにできない」という回答が出た瞬間に、夜間バッチ型の設計は消えます。

相手の言葉で「完了」を定義する用紙

3つ目は、何をもって完了とするかを書き込む1枚です。RPAの案件では「動いた」と「使える」の間に大きな距離があります。テスト環境で1回動いたことを完了と考える受け手と、1か月間トラブルなく回ったことを完了と考える発注側では、認識が完全にずれます。

用紙には「検収の判断をする人」「検収に使うデータ」「連続稼働を何営業日見るか」「異常終了が何回までなら許容か」を書く欄を作ります。当日に全部埋まらなくても、この4つが議題に上がったという事実が後で効きます。曖昧なまま進めた案件と、曖昧だと確認した案件では、揉めたときの立場がまったく違います。

初回で必ず聞く質問リスト

ここからは実際の質問です。順番にも意味があります。業務の話から始め、技術の話に降り、最後に運用の話で締めます。技術から入ると相手が身構えるためです。

入力と出力を先に確定する

最初に聞くのは「この業務は何を受け取って、何を出しますか」です。入力と出力が言えない業務は、自動化の対象として成立しません。入力がメールの添付ファイルなのか、基幹システムの画面なのか、共有フォルダのファイルなのか。出力がExcelなのか、別システムへの入力なのか、承認申請なのか。

ここで具体的なファイルを見せてもらうのが理想です。「だいたいこんな感じです」で済ませると、実物を見た瞬間に想定が崩れます。ファイル名に日付が入っていて毎回変わる、シート名が担当者ごとに違う、セルの結合が不規則、といった現実は、実物を見ないと出てきません。

入力と出力が確定すると、対象範囲の線が引けます。「入力を作る工程は範囲外です」「出力の後の承認は人が行います」と初回で言っておけば、後から範囲が広がるのを防げます。線を引くことは断ることではなく、責任の所在を明確にすることです。

例外の「数」を聞く

次に聞くのが例外です。ここが最も後戻りを生みます。質問の仕方が重要で、「例外はありますか」と聞いてはいけません。ほぼ確実に「ありません」と返ってきます。聞くべきなのは「先月この業務で、いつもと違う手順を踏んだのは何回ありますか」です。

回数を聞くと、相手は記憶をたどり始めます。そこで初めて「そういえば月末は別の帳票が来る」「A社だけフォーマットが違う」といった話が出ます。例外は存在するかどうかではなく、何種類あって、それぞれ月に何回発生するかで捉えるのが実務的です。

例外の扱いには判断の基準があります。発生頻度が高く手順が決まっている例外は自動化に含めます。発生頻度が低く手順も揺れる例外は、自動化から外して人に戻す設計にします。すべてを自動化しようとすると、稀な例外のために大半の工数を使うことになり、費用対効果が崩れます。この線引きを初回で共有しておくと、後から「これも自動化できると思っていた」という食い違いが起きません。

画面と帳票が変わる予定を聞く

RPAの弱点は、対象システムの画面が変わると止まることです。だからこそ初回で「今後1年で、このシステムの更新やリプレースの予定はありますか」と聞きます。基幹システムの入れ替えが半年後に決まっているなら、そのシステムを対象にした自動化は作るべきではありません。

同じ質問を帳票にもします。請求書のフォーマット変更、社内様式の改定、取引先の入れ替え。どれも自動化を止める要因です。予定があるなら、変更に強い作り方に寄せるか、そもそも対象から外すかの判断を初回で行います。

この質問には副次的な効果があります。相手が答えられない場合、それは情報システム部門との連携が薄いという意味です。ならば、その部門を打ち合わせに呼ぶ提案ができます。呼べるかどうかで、案件の進めやすさが大きく変わります。

権限とアカウントの持ち主を特定する

自動化するには、対象システムにログインする必要があります。そのアカウントは誰のものか。担当者個人のIDを使うのか、自動化専用のIDを新設するのか。専用IDを作るには誰の承認が要るのか。

個人IDの流用は、担当者が異動や退職をした瞬間に全部止まります。監査の観点でも問題になりやすい構成です。初回で専用IDの新設を提案し、それが可能かどうかを確認しておくのが安全です。不可能なら、その制約を前提に設計と見積もりを組み直します。

パスワードの保管方法も同時に確認します。設定ファイルに平文で書く前提なのか、資格情報を管理する仕組みがあるのか。ここは後から変えると作り直しになる部分なので、初回で押さえます。

止まったときの連絡経路を決める

RPAは必ず止まります。ネットワークの瞬断、対象サイトのメンテナンス、想定外のポップアップ。止まること自体は異常ではなく、前提です。だから初回で聞くのは「止まらないようにできますか」ではなく「止まったとき、誰が気づいて、誰に連絡しますか」です。

決めるのは3点です。異常終了をどう検知するか、検知したら誰に通知が飛ぶか、業務側は手作業で回す手順を持っているか。3つ目が特に重要です。自動化した業務の手作業の手順書が消えている職場は珍しくありません。止まった日に誰も手順を知らない状態は、自動化が生んだ新しいリスクです。

この会話をしておくと、保守の話に自然につながります。監視まで含めるのか、通知だけ設定して対応は先方が行うのか。範囲を決めるための材料が、この質問から出てきます。

聞き漏らすと後戻りする論点

質問リストとは別に、初回で触れておかないと後半で必ず火を噴く論点があります。順に見ていきます。

効果測定の基準を先に決める

RPAは効果を数字で示すことを期待されます。しかし、その数字の作り方が決まっていないケースが多い。作業時間を何で測るのか、削減した時間を何に換算するのか、削減の対象は残業なのか通常業務なのか。

導入の効果そのものは、業務選定が適切であれば確かに現れます。この点は導入支援の現場からも繰り返し報告されています。

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

ここで読み取るべきなのは、成果の大きさではなく「業務選定さえ適切であれば」という条件のほうです。初回の打ち合わせは、その業務選定を行う場です。効果が出やすい業務の条件は、手順が固定されていること、発生量が多いこと、複数のシステムをまたいでいること。逆に、判断が入る業務、量が少ない業務、年に数回しか発生しない業務は、効果が出にくい。

測定の基準を初回で決めておくと、検収の場面で議論になりません。自動化の前に対象業務の所要時間を実測してもらうところまでを、初回のタスクとして依頼するのが確実です。

誰の仕事が減るのかを確認する

自動化は必ず誰かの仕事を減らします。そこで問題になるのが、減らされる側が打ち合わせの場にいないケースです。担当者は前向きでも、実際に作業している現場が非協力的だと、必要な情報が出てきません。手順書がもらえない、テストデータが出てこない、ヒアリングの時間が取れない。

初回で「この業務を実際に行っている方は誰ですか」「その方にヒアリングの時間をいただけますか」と聞いておきます。断られたら、その案件は難易度が一段上がったと考えて設計と工程を組みます。現場の協力が得られない自動化は、完成しても使われません。

保守の範囲を最初に線引きする

RPAは作って終わりではありません。むしろ運用が始まってからのほうが長い。保守を含むのか含まないのか、含むなら何をどこまで見るのかを初回で言葉にしておきます。

線引きの候補は、対象システムの画面変更への追随、異常終了時の原因調査、業務の仕様変更への対応、実行環境の更新への対応の4つです。それぞれ「含む」「別途相談」「対象外」のどれかを決めます。全部を含む契約は受け手の負担が読めませんし、全部を外す契約は発注側が不安になります。項目ごとに決めるのが実務的です。

ツールの話は初回で決めきらない

初回の打ち合わせでツールの選定まで踏み込みたがる発注者は少なくありません。おすすめのツールを教えてほしい、無料で試せるものはないか、という質問はほぼ毎回出ます。ここで安易に製品名を挙げるのは避けるべきです。ツールは対象業務が決まってから選ぶものであり、順番を逆にすると、ツールの制約に業務を合わせる不自然な設計になります。

初回で確認するのは、選ぶための前提だけで十分です。すでに社内で導入済みのツールがあるか、ライセンスの空きがあるか、情報システム部門が許可しているソフトウェアの一覧があるか、クラウド型のサービスを使ってよいか。この4つが分かれば、選択肢はかなり絞れます。特に4つ目は重要で、外部のクラウドにデータを出せない方針の企業では、選べる製品が大きく変わります。

導入済みのツールがある場合の進め方

すでにツールを持っているケースでは、そのライセンスが有効に使われているかを確認します。導入したものの使いこなせずに眠っている状況は珍しくありません。この場合、新しく何かを買う提案よりも、既存のライセンスで動く自動化を1つ完成させる提案のほうが通ります。決裁が不要で、社内での説明も簡単だからです。

確認する項目は、ライセンスの本数と有効期限、開発できる端末が何台あるか、過去に作られた自動化が動いているか、作った人が今も社内にいるか。4つ目で「作った人はもういません」という回答が返ってくることがあり、その場合は既存の資産の引き継ぎ自体が案件になり得ます。

まだ何も導入していない場合の進め方

ゼロから始める場合は、無料版や試用版で小さく試す進め方を提案します。いきなり全社導入の話にすると、決裁の壁で数か月止まります。まず1つの業務を対象に、試用版で動くところまで作り、効果を数字で示してから本格導入の判断をしてもらう。この順番なら、発注側も社内で説明しやすくなります。

判断の基準としては、対象業務が1つに絞れているか、その業務の担当者が協力的か、効果を測る数字が取れるか、この3つが揃っているかを見ます。揃っていない状態で試用を始めると、期限が切れるまでに成果が出ず、ツールそのものへの評価が下がって次の話が進まなくなります。選び方の議論より、最初の1つを終わらせられる条件が整っているかのほうが、成否を分けます。

初回でやりがちな失敗と、その避け方

後戻りの原因になる失敗にはパターンがあります。代表的なものを挙げます。

1つ目は、要望をすべて書き留めて帰ってしまうことです。打ち合わせで出た要望は、優先順位をつけずに持ち帰ると全部が対象範囲に見えます。その場で「今回はここまで、それ以降は次の段階」と線を引き、引いたことを議事メモに残す。この一手で範囲の膨張は止まります。

2つ目は、相手の使う言葉をそのまま受け取ることです。「毎日やっています」が営業日のみを指すのか、月末だけ休日も含むのか。「すぐに」が10分以内なのか翌営業日なのか。曖昧な言葉が出たら、その場で数字に置き換えて確認します。数字に置き換えられない要望は、検収の基準にもなりません。

3つ目は、技術的な制約を伝えないまま持ち帰ることです。認証に二要素が必要なシステム、画面が動的に変わるWebアプリ、印刷を伴う処理。これらは難易度が上がるため、初回で「この部分は追加の検証が必要です」と伝えておきます。後から言うと、できない理由を後付けしているように見えてしまいます。

成功している案件に共通するのは、初回の時点で「やらないこと」がはっきり言葉になっている点です。やることのリストは誰でも作れますが、やらないことのリストは、聞き込みができていないと書けません。この差が、そのまま後戻りの量の差になります。

打ち合わせ当日の進め方

時間配分にも定石があります。1時間の打ち合わせなら、冒頭の10分で目的と当日のゴールを共有し、次の25分で業務の話、その後の15分で環境と権限、最後の10分で宿題の確認という配分です。

冒頭でゴールを言葉にするのが効きます。「本日は範囲を決めるところまでを目標にします。見積もりは持ち帰って翌週にお出しします」と最初に言っておけば、その場で金額を求められて曖昧な数字を出す事故が防げます。

宿題の確認は必ず口頭で読み上げます。「こちらの宿題は設計の方針を1枚にまとめること、御社の宿題は専用IDの発行可否を情報システム部門にご確認いただくこと、期限は来週の水曜日」という形です。読み上げてから議事メモを当日中に送る。この2手間で、認識のずれの大半が消えます。

議事メモに書く4項目

議事メモは長く書く必要がありません。書くべきなのは、決まったこと、決まらなかったこと、次に誰が何をするか、前提として置いたことの4項目です。

4つ目の「前提として置いたこと」が後で効きます。「対象システムの画面は今後6か月変更されない前提で設計します」「例外はA・B・Cの3種類のみを対象とします」と書いておけば、前提が崩れたときに追加の相談として持ち出せます。書いていなければ、崩れた前提の対応まで当初の範囲に含まれていたことにされがちです。

案件の探し方と、初回に臨む立ち位置

RPA・業務自動化の仕事は、ツールを触れる人よりも業務を整理できる人が求められる領域に移ってきています。どんな案件が動いているかは、職種別の解説を見ると輪郭がつかめます。実行環境や求められる関与の深さは案件ごとに幅があるため、RPA・業務自動化ツールのお仕事で仕事の内容と必要な準備を確認しておくと、初回の打ち合わせで聞くべき点も整理しやすくなります。

隣接する領域も見ておく価値があります。自動化の相談は、データの活用やセキュリティ要件とセットで来ることが多いためです。AI・マーケティング・セキュリティのお仕事には、そうした周辺領域でどんな役割が求められているかがまとまっています。自分の守備範囲の外側を知っておくと、初回で「そこは別の専門家が必要です」と正直に言えるようになります。

報酬の考え方を組み立てるうえでは、近い職種の水準を知っておくのが実務的です。ソフトウェア作成者の年収・単価相場には、開発職の一般的な水準がまとまっています。自分が提供しているのが開発なのか、業務整理なのか、その両方なのかを言語化するための材料になります。

打ち合わせの記録や仕様の文書化を苦にしない人ほど、RPAの案件では評価されます。文書の型を体系的に学ぶならビジネス文書検定のような資格の学習範囲が参考になります。資格そのものが受注に直結するわけではありませんが、議事メモや仕様書の読みやすさは、継続の判断に確実に影響します。

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

20年この市場を見てきた立場から言えば、初回の打ち合わせで最も差が出るのは技術力ではありません。相手が言語化できていないことを、こちらが質問の形にして引き出せるかどうかです。発注側は自分の業務を毎日やっているぶん、何が特殊で何が普通かを見失っています。外から来た人が「それは月に何回起きますか」と聞いて初めて、社内でも共有されていなかった事実が表に出る。この引き出しの作業自体に価値があり、実際にそこを評価して次も声をかける発注者は多い。

もう1つ、長く続いている受け手に共通しているのが、初回で範囲を狭く切ることです。広く受けたほうが仕事は増えるように見えますが、実際には狭く切って確実に終わらせた人のほうが、二件目、三件目と続いています。中間のマージンが乗らない直接の取引では、同じ予算でも依頼者はより多くを頼めますし、受け手の手数料0%という条件は、金額の話というより「手取りが厚いぶん、丁寧に確認する時間を取れる」という質の話として効いてきます。初回に時間をかけて後戻りを防ぐ働き方は、その余裕があって初めて成立します。

初回の質問を設計に翻訳する

打ち合わせで集めた情報は、そのままでは使えません。設計に翻訳する必要があります。翻訳の単位は「例外1つにつき分岐1つ」「システム1つにつき接続方式1つ」「関係者1人につき確認の往復1回」です。この換算を持っておくと、聞いた内容から工程の規模がその場で見積もれます。

例外が5種類あると聞いたなら、分岐が5つ増えるだけでなく、テストの組み合わせも増えます。関係する部署が3つあるなら、確認の往復は3回では済みません。初回で得た数字を、そのまま工程の重さに変換して考える癖をつけると、見積もりの精度が上がります。

そして、翻訳した結果が重すぎると分かったときこそ、初回の情報が生きます。「この範囲だと工程が長くなるので、まず対象を2種類に絞って動くものを作り、効果を確認してから広げませんか」と提案できる。この提案は、何も聞いていない状態では出てきません。初回に質問を尽くすことの見返りは、断る材料ではなく、段階を分ける提案が作れることにあります。

在宅で受ける業務委託の案件では、対面での確認が少ないぶん、初回の情報量がそのまま案件の安定度になります。関連する働き方の実務は定年後のフリーランス独立｜退職金を活かした起業プランと注意点でも触れられていますが、経験の長い人ほど最初の確認に時間を使う傾向があるのは、業種を問わず共通しています。

よくある質問

Q. 初回の打ち合わせは何分くらい確保すべきですか？

1時間を目安に設定するのが現実的です。冒頭の10分で当日のゴールを共有し、25分で対象業務の入力と出力と例外、15分で実行環境と権限、最後の10分で宿題の確認という配分にすると、必要な論点をひと通り回せます。2時間を取るより、1時間を2回に分けて間に宿題を挟むほうが、相手からの情報が揃いやすくなります。

Q. その場で「作れますか」と聞かれたらどう答えるべきですか？

即答は避けます。「作れる可能性は高いですが、判断のために画面の構造、例外の種類と回数、実行環境の3点を確認させてください」と返すのが安全です。条件を見ないうちの承諾は、条件付きの約束を無条件の約束に変えてしまいます。確認する項目を先に言うことで、こちらの判断基準が相手にも伝わります。

Q. 例外の有無はどう聞き出せばいいですか？

「例外はありますか」と聞くとほぼ「ありません」と返ってきます。「先月この業務で、いつもと違う手順を踏んだのは何回ありましたか」と回数で聞くと、相手が記憶をたどり始め、月末だけ別の帳票が来る、特定の取引先だけ様式が違う、といった実情が出てきます。例外は有無ではなく、種類の数と月あたりの発生回数で捉えます。

Q. 保守はどこまで引き受けるべきですか？

一括で決めず、項目ごとに線を引きます。対象システムの画面変更への追随、異常終了時の原因調査、業務の仕様変更への対応、実行環境の更新への対応の4つについて、含む・別途相談・対象外のどれかを初回で決めておきます。全部を含めると負担が読めず、全部を外すと発注側が不安になるため、項目単位の合意が実務的です。

Q. 議事メモには何を書けば後戻りを防げますか？

決まったこと、決まらなかったこと、次に誰が何をするか、前提として置いたことの4項目です。特に4つ目が重要で、対象システムの画面は当面変更されない前提で設計する、例外は3種類のみを対象とする、といった条件を明記しておくと、前提が崩れたときに追加の相談として持ち出せます。当日中に送るのが原則です。