Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
10分間 RPA概論~導入・開発編~
Search
一戸寿哉
May 10, 2018
0
2.4k
10分間 RPA概論~導入・開発編~
5/9 RPALT vol2 at ウイングアーク1st
一戸寿哉
May 10, 2018
Tweet
Share
More Decks by 一戸寿哉
See All by 一戸寿哉
仙台・青森支部~地域課題と向き合うRPA~
k_dash_riese
0
730
ガバナンスって知ってますか?
k_dash_riese
0
720
01_RPALT青森_青森支部について_20200309_01.pdf
k_dash_riese
0
580
02_RPALT青森_RPA初心者セミナー_20200309_02.pdf
k_dash_riese
0
670
地方課題と向き合う(株式会社リアルインベント:村岡さん)
k_dash_riese
0
760
01_RPALT仙台_仙台支部_20200204_02.pdf
k_dash_riese
0
440
02_RPALT仙台_RPA初心者セミナー1_RPAとは_20200204_01.pdf
k_dash_riese
0
520
03_RPALT仙台_RPA初心者セミナー3_RPAツール紹介_20200204_01_.pdf
k_dash_riese
0
550
RPAの利用状況、エラー分析
k_dash_riese
0
760
Featured
See All Featured
Side Projects
sachag
455
42k
A designer walks into a library…
pauljervisheath
207
24k
The Straight Up "How To Draw Better" Workshop
denniskardys
235
140k
Balancing Empowerment & Direction
lara
1
430
The Language of Interfaces
destraynor
158
25k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
29
2.7k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
970
How GitHub (no longer) Works
holman
314
140k
Put a Button on it: Removing Barriers to Going Fast.
kastner
60
3.9k
Rails Girls Zürich Keynote
gr2m
95
14k
Embracing the Ebb and Flow
colly
86
4.7k
Art, The Web, and Tiny UX
lynnandtonic
299
21k
Transcript
10分間 RPA概論 ~導入・開発編~
自己紹介 • 一戸 寿哉(いちのへ かずや) • 34歳 • 青森県五所川原市 •
趣味 バスケ、カラオケ • 職歴 • 2017年2月までSE 無線LAN、カーエレ、金融(外為) • 2017年3月からコンサル RPA
目次 本日はRPAの導入~開発に関する以下のテーマについて、 「概論」と「導入経験で得た気付き」をお話します • 前置き • 自動化とは • 業務選定 •
効果 • セキュリティ • 開発 • 内製 • スキル
前置き • 私見が多めです。あくまでご参考 • ツールは「UiPath」を選択 • 無償版がある • 一通りの機能が揃っている •
.NETが使える • フローチャートが見やすい
プログラミング不要で出来ることは少ない。 RPAを最大限に活かすには、プログラミングに よる業務ロジックが不可欠 RPAができると言っている「自動化」とは 自動化とは • 操作 • マウス、キーボード •
ソフトウェアの呼出 • 認知 • ウィンドウ(セレクタ) • 画像認識 • プログラミング • 変数 • 判定、分岐 認知 操作 業務 プログラミング 要素毎のカバーできる業務範囲のイメージ < 要素技術>
業務選定(1/2) 「簡単で効果の大きい業務」を狙う • 定型的 (ロジックがシンプルな業務) • 全社で共通 (受益者が多い) ⇒ これらは「目立つ」業務。探さなくても案件候補がある状態
定型で共通 複雑で 共通でない 複雑だが共通 できない 業務全体における難易度の割合(イメージ) • 効果が出やすいのは最初だけ。初期の基準のまま 案件選定し続けると、やがて手詰まりに (効果が小さいのでやらない、ということに陥りがち) • 次に複雑な領域(赤枠)を攻める準備が必要 ⇒ そのままではRPA化は出来ないことが多いので BPR(業務改善)とセットで < 選定基準 > 定型 非定型 共通 共通でない
業務選定(2/2) クリティカルな業務は原則RPA化しない • 即時性が高い • リカバリできない ⇒ RPAはエラーが起きるのが前提 定型で共通 複雑で
共通でない 複雑だが共通 できない 業務全体における難易度の割合(イメージ) どうしてもRPA化する必要がある場合 • 扱うシステムの安定化を検討 • スピードは求めない • アジャイルではなく、ウォーターフォールで固い設計とテストを • コンティンジェンシープラン 「できない」業務 定型 非定型 共通 共通でない
効果 前述の通り、工数削減ばかりに目が行くと手詰まりに • 事務ミス防止も大きい ⇒ 事務ミスによる損失を金額換算するなど • 深夜や土日も休まず働ける ⇒ サービスレベル向上
• 現状分析、要件定義の中で業務の可視化・標準化ができる ⇒ 引継ぎ時や新人配属時の教育効率アップなど
セキュリティ どう考える? ⇒ 「人がやっていること」をそのまま行う 人 ロボ 知らないアドレスなので破棄 ホワイトリストに無いので破棄 見慣れない件名なので破棄 予め定義した件名パターンに合致しないので破棄
例)怪しいメールが来たら… • 社内の監視サーバ等で検疫済みなら、人と同等のチェックで十分 • 人が何気なく行っている判断、頭の中に隠されたリストを具体化できるか • むしろ人より安全になることも • インシデントが発生したらどうするか ①責任の所在を決める ②ウイルス感染等をどうやって検知するかを検討 ⇒会社ごとのセキュリティポリシーがあるはずなので、それに沿って検討 ◆検討ポイント
開発(1/2) 要件定義 基本設計 詳細設計 製造 単体テスト 結合テスト システム テスト ユーザ
テスト 要件定義 基本設計 詳細設計 製造 単体テスト 結合テスト システム テスト ユーザ テスト システム開発 RPA RPAツール上で全体フローが確認できる (次頁) システムテストが必要になるような 大規模な案件はRPA対象としない(業務選定観点) RPAの開発工程は ⇒ 1.詳細設計が不要、2.基本設計と結合テストが削減されるイメージ 基本的にシステム開発と同じ
UiPathの場合 ①視覚的に理解できる プログラム言語知識が無くてもレビュー可 ②コメントでソースを詳細設計書にできる コメントをしっかり書くことで、ソースを詳細設計書と同等の ものにできる(ソースを読めば分かる状態にする) ◆悪いコメント アクティビティの説明になってしまっている • ◦◦をクリック
• ブラウザを開く ◆良いコメント ある程度の機能の塊について業務的に何をしているかを書く • ◦◦システムから対象ユーザデータをダウンロード • システム状況によってDL失敗するので3回リトライ コメントが記載できる 開発(2/2) 詳細設計書を不要にできる理由は…
内製 RPA工程 さらにコスト削減を目指すなら 要件定義 基本設計 詳細設計 製造 単体テスト 結合テスト システム
テスト ユーザ テスト コンサル、ベンダ(外部) ユーザ ユーザ 現在 ユーザ(社内) 理想 社内メンバでRPA開発 • システム開発経験のない人にはRPAツールとプログラミングの教育が必要 • ユーザの業務調整が重要。現業と並行するケースが多く、時間が取れないことが多い • 新しい役割を作るなど(RPA業務改善担当など) ⇒ ハードルは高いが、システム開発よりはユーザ参画は容易
RPA担当者の見る範囲 OS(例:Windows) ・.NET ・プロセス管理 ・ファイル、フォルダ管理 ・etc… Excel パワポ IE Chrome
Access ・ネットワーク設定 業務システム② DB② 業務システム③ DB③ Outlook ・関数 ・VBA スキル 業務システム開発に比べると見る範囲が一気に広がる ⇒ ユーザが触れる全てを考慮して設計する必要がある。何かに特化した人より、幅広い知識をもった人がPJに1名は必要 業務システム① DB① ・業務知識 ・言語(Java) ・WebLogic ・SQL ・Oracle システム開発者の範囲
まとめ 自動化とは • プログラミング 業務選定 • 効果が出やすいのは最初だけ • 複雑な業務はBPRしてから •
クリティカルな業務はやらない 効果 • 工数削減だけでは手詰まりになる • 事務ミス防止 • サービスレベル向上 • 業務の可視化・標準化 セキュリティ • 人がやっていることをそのまま行う • インシデント発生時のことを決める 開発 • 基本的にはシステム開発と同じ • 詳細設計は不要(UiPathの場合) 内製 • 教育が必要 • ユーザの業務調整が重要 スキル • 幅広いスキルを持った人が必要 全体的な気付き RPA特有の考え方は実は それほど多くない。 BPR、システム開発など 既存の知識で十分に検討、 対応できる。
今後、考えたいこと • 例外設計、エラーハンドリング ⇒ どこまでしっかり作る?どんな作りがバランスがよい? • 運用 ⇒ 問合せ、障害管理、体制 •
効果測定 ⇒ どうやって利用状況を把握する?