#RPALT RPAドキュメントのレビュー観点について ほろ苦い思い出をもとに…書き起こしてみました 

#RPALT はじめまして ニックネーム：zinjin ー IT企画・推進 / 業務自動化効率化推進 － #RPALT （京都・大阪） #MSLearn #CSBBO BPR/RPAの経験をもとに、4月から新しい業態へチャレンジ 1976年、京都市出身。 大学卒業後、ネットワーク関連業務を経て、IT企画関連の業務を13年経験 主に業務自動化効率化 （BPR/RPA) 推進やコールセンター関連の IT企画・定着推進を行う。これらの経緯で、「ブリッジ役」「守りの企画」の 機能を果たすことが多く、幅広いIT企画の展開・定着・改善業務に強み。 2020/02/10 #RPALT hands-on lab Osaka 2 

#RPALT 本日お話しすること • ドキュメントのレビューとは • RPA実装の工程例をもとに、ドキュメントのレビューを簡単に触れます • 今後のための「備え」 • どの工程で何を、どの観点でまず見ることをお勧めするかのお話 • これまでの失敗例をもとに・・・ • できる範囲から始めよう • 色んな制約の中でも、まず第一歩(Small Step)を踏み出すお話 2020/02/10 #RPALT hands-on lab Osaka 3 

#RPALT 発表にあたって • この資料のターゲット • ドキュメントの作成とチェックにこれから取り組まれる方 • これからRPAに取り組まれる方 • 「市民開発者」でレビューを実施したことがない方 • レビューを始めたいけど、何から手を付けていいかわからない方 • 資料の構成 • レビューするために「意識すること」を中心にまとめています • レビュー方法やレビュー成果物の中身については、今回触れておりません • 伝えたいこと • これまで見聞きした失敗談をもとにして、皆さんにおすすめしたい点をまとめています • ですので、一般的なIT業界のレビュー基準・方法論は記載していません 2020/02/10 #RPALT hands-on lab Osaka 4 

ドキュメントの「レビュー」とは 業務自動化・効率化でまず意識してほしいこと 

#RPALT ドキュメントのレビューとは • 各作業工程で発生する成果物をチェックし、問題を指摘すること • チェックシートに基づいて、自己チェックを行う • 工程・成果物・レビューする方に合わせた、依頼内容（チェック内容）に基づき実施 2020/02/10 #RPALT hands-on lab Osaka 6 ヒアリング 現状まとめ 問題・課題 抽出 改善策 検討 改善案に 基づく設計 実装 テスト リリース 定着作業 「業務の自動化・効率化取り組み」の工程例 （上段：工程 / 下段：工程ごとの成果物) 現状資料・ 事象一覧 問題点・ 課題一覧 課題毎： 改善案 ・・・ ・・・ ・・・ レビュー レビュー レビュー 

#RPALT 2020/02/10 #RPALT hands-on lab Osaka 7 レビューの必要性 (実際のところ) ドキュメントに 費やす工数 確保できない… RPA作ってから 作成するかな めんどくさいし。 私はこれで失敗しました 

#RPALT 2020/02/10 #RPALT hands-on lab Osaka 8 これまでの失敗例をもとに、気づきを得ていただきたい そのために、いろいろ事例をご紹介いたします どの会社様でも当てはまりそうな事例を極力チョイスしました - 「クスッ」と笑顔で観てください - 

今後のための「備え」 各工程で最低限レビューいただきたいこと ✓ 失敗例をもとにご説明いたします 

#RPALT 失敗事例：A 対象業務がそもそも不要だったケース 2020/02/10 #RPALT hands-on lab Osaka 11 

#RPALT 失敗事例：A • 日次集計作業担当とマクロ大好きRPA担当で打ち合わせ • 担当者間で 日次作業 自動化して月100分減らしました 2020/02/10 #RPALT hands-on lab Osaka 12 ヒアリング 現状まとめ 問題・課題 抽出 改善策 検討 改善案に 基づく設計 実装 テスト リリース 定着作業 現状資料・ 事象一覧 データベース プロセス A 日次報告書 Excel マクロによる自動化 日次作業の 手間が問題 エクセル マクロ実装 • しかし・・・大事なところで見落としがありました・・・ 

#RPALT 業務 結果 データ 統合 マスタ情報 結果 確認 業務責任者の把握範囲 失敗事例：A • 作業対象の成果物自体、当月で廃止予定だった • イニシャルコストが無駄 • 担当2名のモチベーションダウン 2020/02/10 #RPALT hands-on lab Osaka 13 データベース プロセス A 日次報告書 Excel マクロによる自動化 日次集計担当/RPA担当 の把握範囲 自動 抽出 BI 日次 結果画面 翌月からBIで提供予定 

#RPALT 失敗事例：A 失敗を防ぐ：レビューのポイント 2020/02/10 #RPALT hands-on lab Osaka 14 

#RPALT 2020/02/10 #RPALT hands-on lab Osaka 15 失敗事例：A 失敗を防ぐ、レビューのポイント 作業単位でなく、業務単位でレビューする ⇒ 最終成果物を誰がいつ利用しているか確認も含める 当事者（業務担当/RPA担当）以外の方にもレビューをお願いする 業務自体に「偏り・重複・不要」作業がないか、まず確認する ⇒ 業務に「ムリ・ムダ・ムラ」がないかのレビュー視点は必須 「業務の現状」「発生している事象」をまずまとめ、レビューする 

#RPALT 失敗事例：B 消えたRPA、負の遺産再び・・・ 2020/02/10 #RPALT hands-on lab Osaka 16 

#RPALT 失敗事例：B • 改善方針資料は「プロセスA/BをまとめてRPAで自動化する」 2020/02/10 #RPALT hands-on lab Osaka 17 プロセス B 業務自動化範囲 Web 作業結果 CSV プロセス A 報告書 (時間単位) Web 操作 日次報告書 • マクロ大好きRPA担当に開発依頼した・・・結果・・・ 

#RPALT 失敗事例：B • RPA作業担当者間で実装設計のレビュー実施…仕様変更 2020/02/10 #RPALT hands-on lab Osaka 18 プロセス B Web 作業結果 CSV プロセス A 報告書 (時間単位) Web 操作 日次報告書 • 成果物にマクロを実装＆有人作業が一部残る形に・・・ マクロ実装 マクロ実装 有人作業 

#RPALT 失敗事例：B • 前工程と実装工程で分断が発生して、相互レビューができていなかった 2020/02/10 #RPALT hands-on lab Osaka 19 ヒアリング 現状まとめ 問題・課題 抽出 改善策 検討 改善案に 基づく設計 実装 テスト リリース 定着作業 • マクロで提供してしまったため、「ブラックボックス排除」・ 「出社前に自動で作業を完了させる」要求を満たすことができなかった マネジメント・ヒアリング担当間で検討 RPA実装担当（複数名） 開発依頼 

#RPALT 失敗事例：B 失敗を防ぐ：レビューのポイント 2020/02/10 #RPALT hands-on lab Osaka 20 

#RPALT 2020/02/10 #RPALT hands-on lab Osaka 21 失敗事例：B 失敗を防ぐ、レビューのポイント 前工程の作業者は、後工程のレビューに関与すること 実装方針や要求事項、達成したい業務結果を満たしているか RPA設計書のレビューは特に注意 「RPAが止まっても設計書を見ながら手作業で業務を完遂できるか」 後工程（実装）作業者も、前工程の成果物レビューに参加すること 

#RPALT その他：失敗事例 2020/02/10 #RPALT hands-on lab Osaka 22 

#RPALT その他：失敗事例 • 業務フロー図・プロセスフロー図(PFD)作成時 • 作成ルールに基づいた作成がされていないことが気づかなかった • レビュー担当者へのレビュー観点（レビュー依頼内容）からも外れた • 実装段階で記載内容の指摘が発生（あいまいさが残ったままの表記） • RPA実施テスト項目のレビュー時 • レビューでも考慮が漏れたため、テストケースに漏れが発生 • テスト後のリリース段階で問題が発生して手戻り • レビュー指摘内容のフィードバック後 • 何度も同じ項目、内容でレビュー指摘が入りレビュワーもうんざり 2020/02/10 #RPALT hands-on lab Osaka 23 どの工程でも、「当たり前レベル」のレビューを行わないと「手戻り」が発生して作業が無駄に・・・ 

#RPALT 2020/02/10 #RPALT hands-on lab Osaka 24 レビューの必要性 

#RPALT 2020/02/10 #RPALT hands-on lab Osaka 25 レビューの必要性 手戻りが発生すると、もったいないですよね 

#RPALT 2020/02/10 #RPALT hands-on lab Osaka 26 レビューの必要性 業務改善メンバーの作業が無駄だらけだと・・・ RPA活動の「思い」も伝わりにくい 

#RPALT 2020/02/10 #RPALT hands-on lab Osaka 27 レビューの必要性 RPA活動もこつこつ頑張る レビューもこつこつ頑張ってみる 

#RPALT 2020/02/10 #RPALT hands-on lab Osaka 28 レビューの必要性 レビューも「業務品質を作りこむ作業」と考えよう！ 

できる範囲から始めよう まず第一歩を踏み出してみよう 

#RPALT できる範囲から始めよう • 私たちがRPA活動で意識していたこと 2020/02/10 #RPALT hands-on lab Osaka 30 Small Start (Step) & Quick Win 私たちはプロのエンジニアではない、だからこそ、小さな成功体験を積み重ねみんなの成長を促していきたい 

#RPALT できる範囲から始めよう • 工程ごとにレビューの観点をまとめておこう • RPA実装の工程ごとに、「誰に」「何を」「どの観点で」確認してもらうか • まずRPAコアメンバーで工程ごとの観点を「箇条書きで」まとめよう • 観点を広げる努力を「始める」 • レビューの観点はその分野の専門家に協力を仰ぐ • レビューだけでも参加いただけるようにコミュニケーションをとる • レビューの工数をとりすぎず、最小単位で始めること • 1工程のレビューは30分以下で抑える • 問題点の指摘と修正の作業を分ける。問題点出しに集中する 2020/02/10 #RPALT hands-on lab Osaka 31 

#RPALT 継続していくこと • レビュー結果は必ず「つぎにも」生かす • 同じ指摘を繰り返さないための仕組みを考える • 対面レビュー / 書面レビュー を使い分ける • メンバーの共通認識をすぐに取りたいときは対面レビュー • 要点を把握したい場合は、「レビュー観点」を記載して書面レビュー • レビュー手法を「じょじょ」にビルドアップしていく • まずは、みんなで「レビューするぞ！」が大事 • サイクルを回して無理なく・続けられるレビューを回すこと 2020/02/10 #RPALT hands-on lab Osaka 32 

#RPALT 外してはいけないこと • レビュー結果はレビュー依頼者が責任を持つ • レビュー担当は、これまでの経験に基づいてレビュー実施する＆ 知らないことは指摘されない。その前提でレビュー依頼を行う • 依頼者が観点をきちんと押さえ、依頼しないと品質は上がらない • レビューもRPAのイニシャルコストに含める • 想定しておかないと、工数を確保できない • イニシャルコストに含められない場合は、実装工数に含めること • レビューは関係者の育成にも活用できる • 成功体験・失敗体験両方からレビューに生かせる • フィードバックをもとに気づきを得られる 2020/02/10 #RPALT hands-on lab Osaka 33 

#RPALT 2020/02/10 #RPALT hands-on lab Osaka 34 ありがとうございました 今回のお話で１つでも「気づき」が得られたらうれしいです - 続きはこの後のフリーディスカッションや RPALT大阪 / RPA呑み部で是非！ -