はじめに

このブログは、RPAに関わって6年経過した自分の体験もとにまとめた記事です。
筆者はUiPathを中心に開発を行っているため、他のRPAツールにも該当するかはわかりませんが備忘録の意味を込めて記載します。

なお立場上、本件の事象に当てはまる方とそうでない方もいますので、あくまで「客先に常駐することが多いプロ開発者」の視点で見ていただけると幸いです。

プロ開発でぶつかる点

UiPathでは必ず何らかのシステムに触れることが多いと思います。
それは、Excelのみの処理やログインを伴うシステムもあれば、ただサイトにアクセスして参照するだけの場合もあります。

プロ開発の場合、別の企業(SIer等)から派遣されて常駐という形でお世話になることが多いと思います。この場合、客先の視点だとある意味「余所者」に該当します。
そのため、アカウントを貸与されたとしても権限やアカウントに関して制限がかかります。(むしろガバガバなのは問題)

セキュリティ上の観点から、客先の社員とは異なりシステムの権限やフォルダのアクセス等に制限がかかっていることが大半だと思います。
実際の開発では提供されたアカウントで問題なく対象のシステムにアクセスできるかという点や、客先から提示された手順で本当に実装できるのかを、要件定義や開発前のヒアリング時に確認しておく必要があります。
なお客先担当者がシステムの仕様を知らない、把握できていないケースの場合は、実装中に発覚することもあり、その対応によって工程が遅延することもあります。

使用するシステムで実際に発生した事象

過去、何社ものお客様のもとで常駐した際に遭遇した事例を「気を付けるべき点」として、以下10点を挙げてみます。

①検証環境がないときはどうするか
②ダミーデータが作れない、もしくは作成NGの場合
③物理的に使用できる環境に制限がある場合
④検証でも本番環境でもシステム稼働時間が存在する場合
⑤検証と本番で画面差異がある(もしくはアップデートがありどちらか先行で走っている)
⑥多重ログインの可否を確認
⑦パスワードNG処理の動作確認は注意して実行
⑧アカウントを拝借している場合は、パスワード変更に注意
⑨アカウントによって画面の見える場所の権限、画面レイアウトが違う
⑩検証と本番でデータの数量に差異がある

①検証環境がないときはどうするか

客先や体制によって大きく変わってくるのですが、開発に使用するシステムの検証環境があるケースとないケースが存在します。
もし検証環境がない場合、対象の開発案件の最終ゴールを確認しておくことが必要になります。

・そのシステムでは、データを取得するもしくは参照するだけなのか(参照系)
・そのシステムでは、データの更新を行うものか(更新系)

参照系の場合は、ファイルのダウンロード等「そのシステムに更新を加えない」ものを指します。本番環境で実行する際は「指定された手順」以外のことは行わないようにしましょう。
更新系の場合は、インシデントになっても困るので客先の担当者へUATテスト(受入テスト)時に確認する等、事前に合意を得る必要があります。

②ダミーデータが作れない、もしくは作成NGの場合

先述①の「本番環境しかない」場合について、動作確認やテストで使用できるデータ(ダミーデータ)が作成できるかどうかを確認してみましょう。
ダミーデータの作り方の手順がある場合は、ヒアリング(もしくは要件定義)の際に確認しておきましょう。
ダメそうなら本番前のUATテストの過程で本番データを使用して確認するしかないので、その際は「OOのテストは更新を伴うためUATテストで確認します」という感じで客先への説明と了承を得る必要があります。

③物理的に使用できる環境に制限がある場合

これはかつて参画した案件でありましたが、手順通りに一気通貫で進められる環境が開発拠点になく、本番環境の設置場所が開発拠点と異なるケースがあり、テストするにも制限がある状態での実行になったことがありました。

もし開発拠点ですべて確認できない場合、出張なりして現地で実装するのか、開発拠点ではどこまでであれば確認できるのかもチェックしておきましょう。
(なお筆者は当時この開発案件で別部門の関係者を巻き込むことになりました。その件はお世話になりました。)

④検証でも本番環境でもシステム稼働時間が存在する場合

実装になりテストをしていると...「終了しました」という表示が出ることやログインどころか画面が固まって出てこないことがあります。
本番、検証問わず現場によりシステムの稼働時間が決まっているものがあります。
(メンテナンスで停止することも把握しておく必要があります)
実装～テスト中は、上記を把握した状態でWBSを作成したり、実装やテストを進める必要があります。

⑤検証と本番で画面差異がある(もしくはアップデートがありどちらか先行で走っている)

これも、過去の現場で実際に体験したものです。
本番より前に、検証環境で先行した画面がリリースされている場合があります。
　(某S？Pとか有名なシステムでよく見る印象...おっと誰か来たようだ)

実際に本番環境はリリース前になっており、検証環境の画面と差異はないかの確認が取りづらいです。
客先によっては、該当システムの保守担当者がいると思うので情報発信やアップデートの時期に注意しましょう。

⑥多重ログインの可否を確認

本番環境しかない場合でかつ本番稼働中のロボットがそのシステムを使用する際に、偶然テスト中にログインしたアカウントで入ろうとしたところ、本番稼働のものが「すでに誰かログイン済み」などのポップアップが出てエラーを起こす...ということが考えられます。

・対象システムは多重ログインをしても問題ないのか
・多重ログインNGの場合は、実行スケジュールを確認の上で動作確認やテスト実行を行う

客先によっては限られたリソースで稼働しています。この場合立場上どうすることもできないので、せめて本番稼働時に迷惑をかけないようにしましょう。

⑦パスワードNG処理の動作確認は注意して実行

過去の現場で実際にやっちゃった...事例で「パスワードNGの処理でエラーを出して終了する処理を作って何度か実行したら、誤ってパスワードロックをかけてしまった」ことがあります。

そのシステムは本番環境しかなく、ログイン処理を実装してパスワードを間違えた状態で数回実行の結果...パスワードロックがかかってしまい、利用している客先の担当者にパスワードを変更いただくという、大変申し訳ないことをしてしまったことがあります。
多くのシステムにログインする際はログインIDがあると思うので、ログインIDを存在しない人のに変えてログイン処理するなど、テスト時は客先に迷惑をかけないようにしましょう。

⑧アカウントを拝借している場合は、パスワード変更に注意

やむを得ない理由で客先担当者のアカウントを拝借して開発するケースもあると思います。
この場合客先担当者がパスワードを変更したものの開発者に連絡が行きわたらずにアクセスできない...というケースがあると思います。
特にパスワード更新が数か月とタイミングが短期間になる場合や、保守で改修を行う時等、本番リリースから時間が経過している場合で利用する際は必ず客先担当者へ確認してください。
なおアカウントですが、ロボット用のものを作ってもらいRPA担当部門が管理するのかどうかも、確認しておいたほうが良いです。
(こういう処理は市民開発者のほうが取り組みやすいのだろうけど...と思う今日この頃)

⑨アカウントによって画面の見える場所の権限、画面レイアウトが違う

RPAで実現したい画面操作の手順と、いざ用意いただいたロボット用アカウントでアクセスした際に画面操作が異なる場合はどうすればよいでしょうか。

1.権限を客先担当者と同じにしてもらう
2.上記1.がNGなら客先担当者へ交渉の上、自動化対象の操作箇所を変更できるかを検討

自分であれば1.を選択することが多いですかね。
もちろん、客先とのセキュリティなどルールがあると思うので、調整や交渉が必要になります。
2.でもダメな場合は...WBS等開発工程の見直しになるかもしれません。

⑩検証と本番でデータの数量に差異がある

これは検証環境がある場合に本番データと全く同じデータを表示できるかどうかや、テストで実行するケースに対して満たせるデータがあるかどうかを確認します。
検証環境のデータが古いこともあると思うので、「データを最新版にアップデートしてくれるのか」、「使えるデータは存在するか？」は設計時までに確認してもよいかもです。

まとめ

客先で開発する場合はインフラやネットワーク環境、セキュリティ等各種規約が定められていることが多く、時には開発時の障壁になることがあります。
スムーズに実装が進められるように、システム利用までに何日も待機状態などの事態を避けられるよう努めます。
最後まで読んでいただきありがとうございました。