オンラインLT向け：RPA_働き方改革・業務改善前に着手したいこと　

#RPALT
RPAドキュメントのレビュー観点について
ほろ苦い思い出をもとに…書き起こしてみました
#RPALT 20200323_RPA勉強＆LT会！vol.19 ～ドキュメントスペシャル～

#RPALT
はじめまして
Zinjin ともうします。
ー IT企画・推進 / 業務自動化効率化推進－
#RPALT （京都・大阪） #MSLearn #CSBBO
BPR/RPAの経験をもとに、4月から新しい業態へチャレンジ
#RPALT 20200323_RPA勉強＆LT会！vol.19 ～ドキュメントスペシャル～ 2
RPA活動において、業務側・エンジニア側ともに経験
今回はそれぞれの観点でLTさせていただきます。

#RPALT
発表にあたって
• オンラインLT向けに構成をシンプルに
• 詳細資料は、「connpass」のイベントページからDLできるようにいたします
• 資料の構成
• レビューするために「意識すること」を中心にまとめています
• レビュー方法やレビュー成果物の中身については、今回触れておりません
• 伝えたいこと
• これまで見聞きした失敗談をもとに、おすすめしたい点をまとめています
• 一般的なIT業界のレビュー基準・方法論は記載していません

#RPALT
本日お話しすること
• ドキュメントのレビューとは
• RPA実装の工程例をもとに、レビューについて簡単に触れます
• 今後のための「備え」
• 「業務担当者」「RPAエンジニア」双方の観点で、
「まず始めてみる」点を双方の失敗例をもとに説明します
• できる範囲から始めよう
• 色んな制約の中でも、まず第一歩(Small Step)を踏み出すお話

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

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

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

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

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

#RPALT
失敗事例：業務担当者側
対象業務がそもそも不要だったケース

#RPALT
• 単純な日次報告書の作成作業
• 自身の担当範囲をRPA実装依頼することに・・・
データベース
プロセス
A
日次報告書
日次集計担当/RPA担当の把握範囲
?
?
後続
作業？

#RPALT
• 日次集計作業業務の自動化・効率化検討＆実施
• 日次作業自動化して月100分減らしました
ヒアリング
現状まとめ
問題・課題
抽出
改善策
検討
改善案に
基づく設計
実装
テスト
リリース
定着作業
現状資料・
事象一覧データベース
プロセス
A
日次報告書
Excel マクロによる自動化
日次作業の
手間が問題
エクセル
マクロ実装
• しかし・・・大事なところで見落としがありました・・・

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

#RPALT
失敗事例：業務依頼者側
失敗を防ぐ：レビューのポイント

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

#RPALT
失敗事例：RPA実装者側
消えたRPA、負の遺産再び・・・

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

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

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

#RPALT
失敗を防ぐ：レビューのポイント

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

#RPALT
その他：失敗事例

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

#RPALT
レビューの必要性

#RPALT
手戻りが発生すると、もったいないですよね

#RPALT
業務改善メンバーの作業が無駄だらけだと・・・
RPA活動の「思い」も伝わりにくい

#RPALT
RPA活動もこつこつ頑張る
レビューもこつこつ頑張ってみる

#RPALT
レビューも「業務品質を作りこむ作業」と考えよう！

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

#RPALT
• 私たちがRPA活動で意識していたこと
Small Start (Step) & Quick Win
私たちはプロのエンジニアではない、だからこそ、小さな成功体験を積み重ねみんなの成長を促していきたい

#RPALT
• SmallStart (Step) & Quick Win
業務定義書と
IPOのみ記述
業務フローと
RPA実装ルール
業務マッピング
とRPAテスト
ルール
統合環境にお
ける検討・実装
パッケージン
グ
関係者「全員」でフェーズごとのドキュメントレベルを決めよう。
それに合わせてレビューレベルをあげていこう!

#RPALT
関係者全員の「合意」から逃げてはいけない
最初が肝心です。お互いに襟元広げてどの段階においてどのレベルのドキュメントを用意するか決める事

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

#RPALT
ドキュメントレビューにつなげるために
- 参考情報 -

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

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

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

オンラインLT向け：RPA_働き方改革・業務改善前に着手したいこと

Recommended

Recommended

More Related Content

Similar to オンラインLT向け：RPA_働き方改革・業務改善前に着手したいこと

Similar to オンラインLT向け：RPA_働き方改革・業務改善前に着手したいこと　 (20)