Upgrade to Pro — share decks privately, control downloads, hide ads and more …

10分間 RPA概論~導入・開発編~

一戸寿哉
May 10, 2018
2.3k

10分間 RPA概論~導入・開発編~

5/9 RPALT vol2 at ウイングアーク1st

一戸寿哉

May 10, 2018
Tweet

Transcript

  1. 自己紹介 • 一戸 寿哉(いちのへ かずや) • 34歳 • 青森県五所川原市 •

    趣味 バスケ、カラオケ • 職歴 • 2017年2月までSE 無線LAN、カーエレ、金融(外為) • 2017年3月からコンサル RPA
  2. プログラミング不要で出来ることは少ない。 RPAを最大限に活かすには、プログラミングに よる業務ロジックが不可欠 RPAができると言っている「自動化」とは 自動化とは • 操作 • マウス、キーボード •

    ソフトウェアの呼出 • 認知 • ウィンドウ(セレクタ) • 画像認識 • プログラミング • 変数 • 判定、分岐 認知 操作 業務 プログラミング 要素毎のカバーできる業務範囲のイメージ < 要素技術>
  3. 業務選定(1/2) 「簡単で効果の大きい業務」を狙う • 定型的 (ロジックがシンプルな業務) • 全社で共通 (受益者が多い) ⇒ これらは「目立つ」業務。探さなくても案件候補がある状態

    定型で共通 複雑で 共通でない 複雑だが共通 できない 業務全体における難易度の割合(イメージ) • 効果が出やすいのは最初だけ。初期の基準のまま 案件選定し続けると、やがて手詰まりに (効果が小さいのでやらない、ということに陥りがち) • 次に複雑な領域(赤枠)を攻める準備が必要 ⇒ そのままではRPA化は出来ないことが多いので BPR(業務改善)とセットで < 選定基準 > 定型 非定型 共通 共通でない
  4. 業務選定(2/2) クリティカルな業務は原則RPA化しない • 即時性が高い • リカバリできない ⇒ RPAはエラーが起きるのが前提 定型で共通 複雑で

    共通でない 複雑だが共通 できない 業務全体における難易度の割合(イメージ) どうしてもRPA化する必要がある場合 • 扱うシステムの安定化を検討 • スピードは求めない • アジャイルではなく、ウォーターフォールで固い設計とテストを • コンティンジェンシープラン 「できない」業務 定型 非定型 共通 共通でない
  5. セキュリティ どう考える? ⇒ 「人がやっていること」をそのまま行う 人 ロボ 知らないアドレスなので破棄 ホワイトリストに無いので破棄 見慣れない件名なので破棄 予め定義した件名パターンに合致しないので破棄

    例)怪しいメールが来たら… • 社内の監視サーバ等で検疫済みなら、人と同等のチェックで十分 • 人が何気なく行っている判断、頭の中に隠されたリストを具体化できるか • むしろ人より安全になることも • インシデントが発生したらどうするか ①責任の所在を決める ②ウイルス感染等をどうやって検知するかを検討 ⇒会社ごとのセキュリティポリシーがあるはずなので、それに沿って検討 ◆検討ポイント
  6. 開発(1/2) 要件定義 基本設計 詳細設計 製造 単体テスト 結合テスト システム テスト ユーザ

    テスト 要件定義 基本設計 詳細設計 製造 単体テスト 結合テスト システム テスト ユーザ テスト システム開発 RPA RPAツール上で全体フローが確認できる (次頁) システムテストが必要になるような 大規模な案件はRPA対象としない(業務選定観点) RPAの開発工程は ⇒ 1.詳細設計が不要、2.基本設計と結合テストが削減されるイメージ 基本的にシステム開発と同じ
  7. UiPathの場合 ①視覚的に理解できる プログラム言語知識が無くてもレビュー可 ②コメントでソースを詳細設計書にできる コメントをしっかり書くことで、ソースを詳細設計書と同等の ものにできる(ソースを読めば分かる状態にする) ◆悪いコメント アクティビティの説明になってしまっている • ◦◦をクリック

    • ブラウザを開く ◆良いコメント ある程度の機能の塊について業務的に何をしているかを書く • ◦◦システムから対象ユーザデータをダウンロード • システム状況によってDL失敗するので3回リトライ コメントが記載できる 開発(2/2) 詳細設計書を不要にできる理由は…
  8. 内製 RPA工程 さらにコスト削減を目指すなら 要件定義 基本設計 詳細設計 製造 単体テスト 結合テスト システム

    テスト ユーザ テスト コンサル、ベンダ(外部) ユーザ ユーザ 現在 ユーザ(社内) 理想 社内メンバでRPA開発 • システム開発経験のない人にはRPAツールとプログラミングの教育が必要 • ユーザの業務調整が重要。現業と並行するケースが多く、時間が取れないことが多い • 新しい役割を作るなど(RPA業務改善担当など) ⇒ ハードルは高いが、システム開発よりはユーザ参画は容易
  9. RPA担当者の見る範囲 OS(例:Windows) ・.NET ・プロセス管理 ・ファイル、フォルダ管理 ・etc… Excel パワポ IE Chrome

    Access ・ネットワーク設定 業務システム② DB② 業務システム③ DB③ Outlook ・関数 ・VBA スキル 業務システム開発に比べると見る範囲が一気に広がる ⇒ ユーザが触れる全てを考慮して設計する必要がある。何かに特化した人より、幅広い知識をもった人がPJに1名は必要 業務システム① DB① ・業務知識 ・言語(Java) ・WebLogic ・SQL ・Oracle システム開発者の範囲
  10. まとめ 自動化とは • プログラミング 業務選定 • 効果が出やすいのは最初だけ • 複雑な業務はBPRしてから •

    クリティカルな業務はやらない 効果 • 工数削減だけでは手詰まりになる • 事務ミス防止 • サービスレベル向上 • 業務の可視化・標準化 セキュリティ • 人がやっていることをそのまま行う • インシデント発生時のことを決める 開発 • 基本的にはシステム開発と同じ • 詳細設計は不要(UiPathの場合) 内製 • 教育が必要 • ユーザの業務調整が重要 スキル • 幅広いスキルを持った人が必要 全体的な気付き RPA特有の考え方は実は それほど多くない。 BPR、システム開発など 既存の知識で十分に検討、 対応できる。