10分間_RPA概論_導入_開発編__UiPath_Developer_Community拡大版.pdf

Transcript

1. 10分間 RPA概論 ～導入・開発編～ UiPath Developer Community拡大版
2. 自己紹介 • 一戸 寿哉（いちのへ かずや） • ３４歳 • 青森県五所川原市 • 趣味 バスケ、カラオケ • 職歴 • 2017年2月までSE 無線LAN、カーエレ、金融（外為） • 2017年3月からコンサル RPA（約1年4ヶ月） がメイン
3. アジェンダ RPAの導入～開発の「概論」と「導入経験で得た気付き」を UiPathのエッセンス を加えてお話します。 • なぜUiPathか • 業務選定 • RPAを導入する意義 • 開発 • 運用 • etc
4. なぜUiPathか • Community Edition ＆ UiPath Academy ⇒ 自学できる • アプリケーション認識：Selector が柔軟 ⇒ SelectorNotFoundがよく起きる… ⇒ 変数をSelectorに組み込んだり、TryCatchを使うことで十分に運用可能 ⇒ 他ツールは、それ以前にそもそもの認識精度が低かった…（あくまで1年4ヶ月前時点） • .NETが使える（Assign） ⇒ プログラミングを活かせる • ワークフローが見やすい ⇒ 設計書を不要にできる（後述） 他ツール2つと比較。UiPathに優位性ありと判断
5. 業務選定 定型で共通 定型で共通でない 複雑で共通 非定型で共通でない 業務全体における難易度の割合（イメージ） • シンプルで効果の大きい、コスパが良い業務を狙うのがセオリー（青枠） 定型 非定型 共通 共通でない • 拡大を目指す場合、業務ロジックが複雑な領域 （赤枠）を攻める必要がある 以下の要素がより必要になる ・ 実装 … 安定化、例外処理 ・ 運用 … コンティンジェンシープラン ・ その他 … 扱うシステムそのものを改修 • しかし、すぐにコスパの良い業務は尽きてくる…
6. Propertiesサンプル TryCatchサンプル 安定化 例外処理 処理速度は求めない デフォルトは上記の設定。（＝人間レベルの動作） うまく動作しないときだけ変更。 エラーは必ず起こる。検知⇒対応スピードが重要。 エラー発生時は下記を必ず行うよう フレームワーク化 • エラー発生時のスクリーンショット を保存 • 業務担当者 or RPA管理者へ メール（スクショ＆ログ添付） 最近は、上記を標準装備した 「ReFrameWork」という便利な フレームワークがUiPathさんから 提供されています。
7. RPAを導入する意義 工数削減（費用対効果）ばかりに目が行くと、手詰まりに • 作業効率化・生産性向上 ⇒ 働き方改革 • 外部委託、システム改修の削減 ⇒ コスト削減 • 人はコア業務に注力 ⇒ 付加価値の創出 • 24H365日稼働 ⇒ CS・サービスレベル向上 • 事務ミス防止 ⇒ 品質向上 • 業務フロー、マニュアルを作成 ⇒ 業務の見える化・標準化
8. ・業務フロー改善が後回し ・現場の作業内容を上長が把握していない ・フォーマットがバラバラであることを後悔する 今の時点で ロボット化できる・できない は、さておき 「ずっと、そうしてきたから」と、何となくそのままにされ、可視化・標準化されて いない業務が多いのが実情。 真の目的 RPAを口実にして、社内業務の可視化・標準化をする 今は出来なくても、将来のデジタル社会（AI、BI、RPA再チャレンジなど）やBPRの チャンスに備える。 RPALT vol2 RPAあるある抜粋
9. 開発 要件定義 基本設計 詳細設計 製造 単体テスト 結合テスト システム テスト ユーザ テスト 要件定義 基本設計 詳細設計 製造 単体テスト 結合テスト システム テスト ユーザ テスト システム開発 RPA UiPath Studioでフローが確認できる システムテストが必要になるような 大規模な案件はRPA対象としない RPAの開発工程は ⇒ そこから、詳細設計・基本設計・結合テスト が削減できるイメージ 基本的にシステム開発と同じ
10. ①ソースで視覚的に業務の流れを理解できる プログラム言語知識が無くてもレビューできる ②コメントを充実させてワークフローを設計書に コメントをしっかり書くことで、ソースを設計書と同等の ものにできる（ソースを読めば業務も分かる状態にする） ◆悪いコメント アクティビティの説明になってしまっている • ◦◦をクリック • ブラウザを開く ◆良いコメント ある程度の機能の塊について業務的に何をしているかを書く • ◦◦システムから対象ユーザデータをダウンロード • システム状況によってDL失敗するので3回リトライ コメントが記載できる ・Display Name ・Annotation 開発 設計書を不要にできる理由
11. 成果物の例 • ヒアリング … ヒアリングシート • 要件定義 … As-Is／To-Beフロー ロボット概要資料（紙芝居＋要件） • 製造 … xaml（コメントをしっかり書く） 開発標準チェックシート • テスト … テスト仕様書 • UAT … 運用マニュアル 一般的なシステム開発より、かなり成果物を少なくできる 大前提 開発
12. 開発 開発標準の例 • プロジェクトフォルダの構成 Input／Output／Templateなど • 命名規則 変数、引数、Asset、①DisplayName、 ②ロボットID • ワークフロー記載ルール Flowchart／Sequenceの使い分け、ネストは3階層まで • 例外処理 システム例外（Error）、業務例外（Warning） • ログフォーマット ③実行PC・実行ユーザ・ロボットID・xaml名、エラー内容（Add Log Fields） RPA001 … Aシステム登録処理 • xaml_01 … InputのExcel処理 • xaml_02 … Aシステム転記 ： 個々のxamlではなく、 RPA化の業務単位に採番 ⇒ nupkg単位に振るイメージ ②ロボットID ①DisplayName ユニークNoを振る （マクロを利用） ⇒エラー時、 DisplayNameが表示され るため、発生箇所が特 定しやすくなる UiPath Studioで 自動的に降ってくれな いかな… ③ログフォーマット OrchestratorまたはElasticに集積されたログから 以下のような傾向を把握するため。 ・どのロボが使われている／使われていない ・どのロボのエラーが多い／少ない ・どの部署で使われている／使われていない ・どの部署でエラーが多い／少ない など ロボ＝ロボットID、部署＝PC × ユーザ ⇒ 集中管理・分析する際に必要
13. 運用 • 運用こそ、RPAプロジェクト成功の鍵 • 作りっぱなしでは、使ってもらえない ⇒ 使ってもらうための仕組みが重要 サポートデスク • 問合せ対応 ⇒ ロボットの使い方 ⇒ 障害管理（保守と連携） • エラー監視 ⇒ Orchestrator／Kibanaで確認 ⇒ エラー発生時、自動メール設定も可 ⇒ エラー発生時にはユーザへ連絡 • リリースやシステムメンテナンス時のユーザ調整 • etc 分析 • 定期的にログデータを分析 どのロボが使われている／使われていない どのロボのエラーが多い／少ない どの部署で使われている／使われていない どの部署でエラーが多い／少ない など • 利用が進んでいない傾向があれば、ユーザとコミュニケー ションし、必要に応じてロボの改修や、ロボの撤去を行う ※ログはOrchestrator/KibanaからDL、ElasticからRESTで取得するなど
14. • OCRは、RPAではない 自動化プロセス中に組み込むイチ機能であって、RPAとは別物。 RPAと組み合せることで自動化範囲が広がるため、よくセットで出てくる。 • RPAで考えるときは、精度ではなく… • いかに効率的に紙をデータかするか • データ化したものを、いかに効率的にOCRにかけるか • その結果を、いかに効率的に人の目で確認させるか（精度100%は有り得ない） というプロセスを考えることこそ、RPAとしては肝要 ＃紙を止める検討が最優先 OCR