#はじめに
はじめまして。RPAエンジニアの@ParkSetagayaです。
UiPath FriendsさんのAdvent Calendarに乗っかり、Qiitaデビューをすることになりました。
よろしくお願いいたします！
テーマには色々と悩みましたが、僭越ながら「RPAの上流工程の勘所」というテーマで記事を書いてみました。
今年1年間、社外のお客様のRPA導入支援を行ってみて大切だと感じたことを自分なりにまとめています。
本当はUiPathメソドロジーとからめつつ、上流だけでなく実装も含めて書きたかったのですが、うまくまとまらなさそうなので、それは別の記事で書ければいいなあと思います。
#RPAの上流工程を3段階に分けて考える
まず、RPAの上流工程を下記の3段階に分けて考えます。
- **案件化決定段階：**自動化する業務決定直後に、今後の進め方の擦り合わせや資料の提供を依頼する段階
- **業務内容の把握段階：**ユーザーから提供された資料（マニュアルや実際に業務で利用するファイル等）を確認する段階
- **仕様策定段階：**ユーザーとすり合わせた業務手順について、どういう仕様で自動化を実現するかを検討する段階
実際には状況や案件によって、もっと段階が増えたり、あるいは省略できたりする場合もあると思います。
あくまでナレッジを言語化するための便宜上3つに分けて考えてみました。
それでは順を追って、私なりの各工程でやること・気を付けるべきことを書いていきます。
#案件化決定段階
案件化決定段階は、自動化する業務決定直後に、今後の進め方の擦り合わせや資料の提供を依頼する段階です。
この段階でのポイントは、
- 開発者が主導権を握って進めること
- できる限り協力的な姿勢をみせること
の2つです。
Point①開発者が主導権を握って進めること
RPAの開発をスムーズに行うためには、エンドユーザーの協力が不可欠です。
エンドユーザーの理解・協力がないと、開発工数がかかったり、後でトラブルが発生したり、そもそも開発が頓挫したり、難しいプロジェクトになります。
そこでその時の状況に合わせ、あらゆる手段を使って開発者が主導権を握って進められるようにします。
- ルールや制度、契約でユーザーが協力して「当たり前」の状況を作る。
- 上司や営業など、交渉力のある立場の人を通じて事前に根回しする。
- 協力することがあたかも「当たり前」であるような空気感を醸し出す。
- 協力がない場合、最終的にエンドユーザーが損することを説明する。
初めの段階でこちらのペースに引き込むことでプロジェクトの進めやすさがまったく変わってくるので、自分の立場や相手との力関係、キャラクター等に応じて工夫することが大切だと考えています。
はじめが肝心！
Point②できる限り協力的な姿勢をみせること
Point①だけだと、逆に不信感を抱かれてしまうので、こちら側も可能な限り協力てきな姿勢をみせることが重要だと考えています。
例えば、難しいことも「できません」と即答せず、「持ち帰って検討してみます」「〇〇すればできます」など、前向きな姿勢をみせる（本当に前向きな姿勢であることが前提）ことで、相手の態度も軟化していく傾向にあります。
初心を忘れず真摯な姿勢を心掛けるとともに、相手にもその姿勢がみえるようにするしたたかさも重要だと思います。
#業務内容の把握・確認段階
業務内容の把握段階は、ユーザーから提供された資料（マニュアルや実際に業務で利用するファイル等）の確認をする段階です。
この段階でのポイントは、業務手順の曖昧な点をリストアップすること です。
具体的には、
- 手順書の誤字/脱字、複数の意味に解釈できる点をリストアップし、確認する。
- RPA用にルールをより具体的に定義する必要のある個所をリストアップし、すり合わせる（「最新月」「昨日」の定義、ファイルやフォルダの命名規則など）。
- 例外パターン、インプットファイルにありがちなミスを確認する（UiPathでいうところのBusinessRuleException）。
を注意深く行います。
このとき、提供されたマニュアルの手順を一つ一つ再現しながら確認を行うことが重要です。
面倒だからと読んで終わりにすると、後々困ることが多いです。
業務手順を丁寧に確認するプロセスをすっ飛ばし、いきなり仕様を考え始めると、あとで手戻りが発生する可能性が高くなるので超重要です。
確認・合意した内容は課題管理表等にまとめ、エンドユーザーにもわかる形でエビデンスとして残します（後々のトラブル回避のため）。
※エンドユーザーから資料を提供してもらえる前提で書いていますが、こちらでヒアリング＆資料作成する場合も注意することは同じです。ただし、基本的には資料は提供してもらうようにした方がよいと思います。
仕様策定段階
仕様策定段階は、ユーザーとすり合わせた業務手順について、どういう仕様で自動化を実現するかを検討する段階です。
※この段階は深堀するとロボの設計の話になり収集つかなさそうなので、エンドユーザーとのコミュニケーションで重要なポイントをまとめたいと思います。
この段階でのポイントは、ロボの導入後の業務フローやエラー発生時の対処方法をエンドユーザーがイメージでき、かつ、納得してもらうようにすること です。
特に「エンドユーザーがイメージできる」というのが重要だと考えています。
開発者の立場でいると、ついついロボの細かい仕様の話をしてしまい、エンドユーザーを「？？？？？」と困惑させてしまいがちです。
そうするとエンドユーザーはよくわからないままOKを出してしまい、実際に運用がはじまってから「こんなはずじゃなかった」と手戻りを生んでしまう可能性が高くなります。
具体的には、私は下記のことに注意しています。
- ロボを実行する前の手順と、実行後の後続業務の作業を伝える。
- インプットファイルとアウトプットファイルのサンプルを作成し、確認してもらう。
- エラーが発生した場合にロボが出力する内容と、対処方法を説明する。
エンドユーザーに合意を取る際、「これでいいですか？」とざっくり聞くのではなく、後で手戻りそうなポイントを具体的に絞ってきくことも大切だと思います。
何も質問・コメントもなく「大丈夫です」と言われた場合、たいてい大丈夫ではありません。
ITリテラシーが高くはないエンドユーザーほど、ポイントを具体的に絞り、よくイメージできるように説明する必要があります。
業務内容の把握・確認段階と同様に、合意した内容をエンドユーザーが確認できる形でエビデンスを残すことも忘れずに行います。
終わりに
Qiitaへの投稿が初ということもあり、記事の粒度やまとめ方、書き出しに悩み、無駄に時間がかかってしまいましたが、自分のナレッジを言語化するのはやはり良いですね。
正直中途半端な記事になってしまったなあという気持ちでいますが、投稿を重ねてもっとクオリティを上げていきたいです（続けば）。
Advent Calendarイベントへの参加がアウトプットの良い機会となりました。
ありがとうございました。
来年はUiPath FriendsでLTデビューしたいと思います！