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

自己紹介 • 一戸 寿哉（いちのへ かずや） • ３４歳 • 青森県五所川原市 • 趣味 バスケ、カラオケ • 職歴 • 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の開発工程は ⇒ １．詳細設計が不要、２．基本設計と結合テストが削減されるイメージ 基本的にシステム開発と同じ 

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、システム開発など 既存の知識で十分に検討、 対応できる。 

今後、考えたいこと • 例外設計、エラーハンドリング ⇒ どこまでしっかり作る？どんな作りがバランスがよい？ • 運用 ⇒ 問合せ、障害管理、体制 • 効果測定 ⇒ どうやって利用状況を把握する？