RPAを拡大する前に早めに考慮した方が良い事とシステム部門との連携について 2022年10月22日 UiPath Friendsイベント登壇資料

1. RPA拡大を考えた時に
早めに考慮した方が良い事と
システム部門との連携について
畠山 竜太（ハタケ） @RPA_AI_it
🎃Tech三昧 推進テクニック🎃

2. 自己紹介
所属：パーソルプロセス＆テクノロジー株式会社
UiPath Friendsメンバー
Twitter：@RPA_AI_it
UiPath Community Forum:
出身
●千葉県
過去の経歴
●2009年4月～2019年7月まで、大手都市銀行の
様々な案件で開発者(PL/I,Java)やPLを経験
●2019年8月より業務改善や
RPA導入コンサルティングを担当中
得意分野
●業務プロセス改善、標準化、高度な課題解決
●開発者や初心者目線を持ったリーダー業務及び教育
●インフラ、Web、プロジェクト管理等
幅広い業務の遂行

3. RPAを拡大 保守運用が大変
RPA拡大時によく発生する問題
RPAを拡大していくと保守運用が大変になってしまうケースがあります。
ERROR対応
作った人以外
保守運用できない

4. 早々に考慮した方が良い事
１
２
３
RPA推進の管理フォルダ、プロセス別の案件フォルダの取り決めをして、
資源管理を行うべし！
開発の標準化(初期テンプレート)の活用、最低限守るべき
開発ルール整備を行うべし！
作成したプロセスの業務がブラックボックス化、保守運用が
属人化しないように適切な情報を残すべし！
４ 自動化候補や自動化した内容は一覧で管理すべし！
５ 障害管理を行い、頻発するエラーや影響度が大きい問題のエラーは
早々に改修するなりして、障害件数を抑えるべし！

5. ファイルサーバA
１ RPA推進の管理フォルダ、プロセス別の案件フォルダの取り決めをして、
資源管理を行うべし！
考慮しないと、、、 考慮しておくと
ファイルサーバB
• どこに何が入っているのか分からず、探すのに
時間が掛かる。最新がどれか分からない。
• 後々になって欲しかった情報が見つかり、
調べたり、作っていた時間が余計な作業
だったと知り、やる気がさがる。
ファイルサーバA
• 一定のルール通りにフォルダやファイルが
配置されているため、どこに何があるか
探しやすい。適切に履歴管理され最新が
一目でわかる。
• 欲しかった情報が後から見つかる事が無くな
り、余計な作業をする事が無くなる。
必要な情報に
すぐアクセス！
必要な情報が見つからない

6. 考慮しないと、、、 考慮しておくと
Main.xaml
• 作る人、時期によって作り方がバラバラで、
仕様の理解に加えて、どのように作られてい
るかの分析作業が毎回必要になる。
• とてもわかり難い作り方になっている場合、
理解するのにかなりの時間が必要となる。
• 作る人、時期が変わっても作り方が統一されて
いるため、仕様の理解に専念できる。
• 同じ作りになっているので理解が短い時間で
行える。
• 初期テンプレートや共通部品を活用している場
合、開発時間、テスト時間が短縮されていく。
２ 開発の標準化(初期テンプレート)の活用、最低限守るべき開発ルール
整備を行うべし！
開始
終了
Main.xaml
開始
終了
見ないと
分からない
開く前から大枠の
作りが分かる
作りの理解が毎回必要

7. 考慮しないと、、、 考慮しておくと
要件定義書
• 要件定義時に確認した事を、改修時に
再度業務担当者に確認しないと分からない。
• 保守運用に必要な情報が無く、改修やテストが
できない、ミスをしてしまう。動かすのが怖い。
• 担当者がいないと何か起きても誰も対応できない。
• 同じことを業務担当者に確認しなくても済む。
• 情報が無くて保守運用で困る事が無くなる。
• 開発者以外でも何か起きた際に対応を行える。
(属人化抑止)
３ 作成したプロセスの業務がブラックボックス化、保守運用が属人化しないよ
うに適切な情報を残すべし！
設計書
情報不足
存在しない
要件定義書
設計書
存在する
必要な情報が
揃っている
当時の担当者しか分からない 当時の担当者以外も分かる

8. 考慮しないと、、、 考慮しておくと
• どこで何が動いているか分からない。
• なんの業務がヒアリング待ちなのか済なのか、
開発中なのか稼働中なのか状況が分からない。
• 担当が変わると、またヒアリングから始めたり
と重複作業が発生する。
• どこで何が動いているか分かる。
• 自動化対象業務の状況が把握できる。
• 作業の重複が発生しない。
４ 自動化候補や自動化した内容は一覧で管理すべし！
開発
稼働中
要件確認中
状況が一目でわかる
状況の確認に時間が掛かる

9. 考慮しないと、、、 考慮しておくと
• 発生したエラーが初めての事象か過去起きた
ものか分からない。
• 過去障害時にどんな対応をしたか分からず、
毎回対応に時間が掛かる。
• 自動化の数が増えていくと、エラー対応に
多くの時間が使われる。対応しようとしても
エラー一次対応で手一杯な状況に。
• 初めての事象か過去起きているものか分かる。
• 過去対応した事と同じ対応で問題なさそうであ
れば、過去実施した事と同じ事で対応できる。
• 数が増えていっても、エラーの本格対応に
時間を充てる事ができる。直したい時に
直しやすい。
５ 障害管理を行い、頻発するエラーや影響度が大きい問題のエラーは
早々に改修するなりして、障害件数を抑えるべし！
毎日エラー対応に追われる エラー対応に
集中できる

10. 自動化の数が多くなってからこれらの事を
対応しようとすると、結構苦労します！

11. こんな時はシステム部門との連携が必要に
１
２
３
Cloud OrchestratorやオンプレミスのOrchestratorを扱いたい時
Google Cloud Platformにプロジェクトを作成して、
会社のGoogle workspaceにアクセス(API連携)しようとした時
仮想環境上にUiPathの開発や実行環境を使いたい時
４ RPA用のアカウントを作りたくなった時
どこまでが業務部門の判断で進めて良いのか、どこからがシステム部門の
協力や判断が必要となるのか、早い段階から相談して進めていける事が、
理想です。自社のルールを確認しましょう！

12. ありがとうございました