気分を奮い立たせ宿題を解消する　～Task Capture使ってみた～

なにか具体的な問題が発生していれば否応なく問題解決に向けたタスクとして取り組むが、「いつかやりたいなと思っているので宿題かな」と記憶しておくようなタイプのタスクはしばらく残ってしまっていませんか。

わたしが改めて自分のタスク管理を確認すると「保留」「担当者未決」とか、酷いものとなると「対応中」までしばらく進捗のない場合があります。

良し悪しは別として、ビジネスシーンでは問題解決に奔走せざる得ない状況が続く場合があり、まさに今がその状況です（この記事も締め切り過ぎに書いているため言い訳です）。

とは言え、それでは解決しないため夏休みの終わり間際のように気持ちを奮い立たせ、「UiPath プラットフォームの各種ツールの機能調査」から「Task Captureの検証」タスクを解消したいと思います。

UiPath プラットフォームとは

Task Captureに入る前にUiPath プラットフォームを説明します。

UiPath プラットフォームは、RPA対象領域の「発見」から、RPA開発実行環境を含む「開発」・「管理」・「実行」、ヒトとRPAの「協働」など、RPAプロジェクトの円滑な推進と高度利用を実現するためにRPAプロジェクトのさまざまなフェーズに対応するUiPath製品群です。

---

RPAプロジェクトを進めるなかで、次のような問題に悩まされていませんか。

　✓　業務担当者が業務を説明する時間がとれない。
　✓　手順書がなく説明準備の負担が大きい。

特にRPA開発や運用保守等を専門組織が担う場合、開発担当者はRPA対象業務を正しく把握することが必要ですが、業務担当者の繁忙により思ったように進まないという問題はよくある悩みと言えます。

UiPath プラットフォームのうち、本日取り上げるTask Capture はRPA対象領域の選定からサポートする「発見」というカテゴリにある作業手順のキャプチャツールです。

UiPath導入企業であれば多くのライセンスに含まれるため、現在は使用していなくとも実は利用できる環境である場合が多いと思います。
(参考：UiPathライセンスポリシー　https://www.uipath.com/ja/licensing-models)

Task Captureでは何ができるの？

---

Task Captureの機能は、操作と画面キャプチャを自動的に記録し、結果を業務プロセス定義書（Wordファイル）、またはStudioのワークフロー（XAMLファイル）として出力できるものです。

これによりRPAプロジェクトで問題となりがちな業務担当者の繁忙による自動化の停滞の解消が期待できます。ただしその期待を実現するポイントは次の2点と言えます。

　Point①　作業記録の負担がないか≒Task Capture自体が負荷ではないか
　Point②　業務プロセス定義書やワークフローを活用できるか

では実際にTask Captureを利用して検証してみたいと思います。

実際にTask Capture使ってみた

今回は通勤交通費計算業務をイメージして、Task Captureを検証したいと思います。

---

Excel管理されている従業員情報の現住所から、Yahoo!路線検索で通勤経路を検索、得られた結果である片道交通費と1ヶ月の定期代をExcelの指定された場所に入力する作業です。

※蛇足ですが、ここで利用する従業員情報は以下のサイトのダミー情報を利用しています。
個人情報テストデータジェネレータ：https://testdata.userlocal.jp/

---

Task Captureによる作業記録の手順は次の通りです。

作業記録の開始時
①    Task Capture起動後に表示される『新しいドキュメント』ボタンをクリック
②    『プロセスをキャプチャ』をクリック
③    『キャプチャ開始』をクリック
↓
記録する作業を行う
↓
作業記録の終了時
④    『■停止』をクリック

結果は下図のように作業の全体感として作業ステップの連続からなるプロセス、その作業ステップの詳細情報として画面キャプチャと実際に行われた操作が記録されます。
※下図は現住所情報がある「D2」セルの情報を「Ctrl＋c(コピー)」しているステップの詳細

---

実際利用してみると、作業記録の負荷はほとんど感じないレベルです。
普段の作業と比較して追加となるのは、作業記録の開始前の3クリック（上記①～③）と、作業記録の終了時の1クリック（上記④）のみ、あとは特別に意識する必要はなくいつも通り作業すれば自動的にその操作と画面キャプチャが記録されます。

ただ、今回のポイントは、実際出力される業務プロセス定義書（Wordファイル）、ワークフロー（XAMLファイル）が活用できるかという点なので、次からそれぞれ確認してみようと思います。

出力されるプロセス定義書（Wordファイル）をみてみよう

業務プロセス定義書（Wordファイル）は、Task Captureの「ファイル」メニュー→「エクスポート」→「Word(.docx)」から出力することができます。

業務プロセス定義書イメージ
以下のように、先ほど作業を行った手順がwordの業務プロセス定義書として出力されるのです。

---

ここでは詳細を割愛しますが、今回のテンプレートでは「Ⅰ.はじめに」という前提から「Ⅲ.自動化後のプロセス」であるToBeに至るまで、広域な情報を記述する形式となっています。

つまりはTobeで、現行のフロー（AsIs）をこう改善するべき、というものが自動で出力される形式ですが、残念ながら自動出力される項目は限定的です。

本題である作業記録の結果は「Ⅱ.5現行(AsIs)のプロセスのアクション詳細」に出力されます。

---

上図を例に内容をみていくと、3.2のアクションで従業員情報から取得した現住所をYahoo!検索の出発にペーストし、3.3で事業所の最寄駅を指定するために到着をクリックしている操作が見てとれます。

このように実際の手順で「PC操作」「画面キャプチャ」等が記録されています。よって業務プロセス定義書を確認すれば、作業手順は把握できます。しかしRPA開発者が業務を効率的かつ正しく把握できるかという点では懸念もあります。

誤った操作も記録される

---

作業の記録を漏れなく行うことから「無意味なクリック」等の不要な操作や「誤入力による削除」、操作ミスによる修正などRPA対象業務の理解を妨げるノイズ情報も漏れなく記録されます。

残念ながら実際に記録してみると、自分の作業に不要な操作が多く愕然とします。

ビジネスロジックや判断基準は記録されない

---

「PC操作」と「画面キャプチャ」をアクションとして記録するため、当然ですが「料金の安い順」を何故選択するのかという判断基準は記録されません。

今回の対象業務では判断基準がないものを選択していますが、取引先や営業担当者によって対応を分けるというような業務では、必ず〇〇をクリックすると誤解を与えるリスクがあります。

---

ただしTask Captureには編集機能があります。画面キャプチャへの注釈の追加や不要なアクションを削除することで懸念点を解消することができ、RPA開発者が業務理解をするための文書として活用できると考えられます。

またその機能はほぼマニュアル作成支援システムのようですが、それらと同様に高度な知識は必要なく、非エンジニアである業務担当者でもシステム操作を多少理解すれば利用できることもメリットとしてあげられます。

ただし上記のように、操作のノイズも記録されるため、編集操作の負担軽減のためには、作業記録段階でいつも通り作業するのではなく、不要な操作を極力しない等のルール作りが必要だと考えられます。

出力されるワークフロー（XAMLファイル）を見てみよう

開発環境であるStudioで利用可能なワークフロー（XAMLファイル）も、Task Captureの「ファイル」メニュー→「エクスポート」→「UiPath Studio(.xaml)」から出力することができます。

UiPath Studioで開いたワークフローイメージ
Flowchartの中身をみていくと、Yahoo!路線検索の出発に現住所をペーストして、到着に移動するためにクリックしている動作がフロー化されていることが見てとれます。

---

ただし単純に作業手順を記録したワークフローをRPA開発者が活用することは、率直に言えば厳しいなという印象です。

特にRPA開発を専門組織で担う場合は、保守を考慮したRPAの安定性や処理速度の向上を図るのがRPAエンジニアの肝であり、必ずしもヒトの作業の完全再現が良いわけではないからです。

では具体的にポイントをみていきます。

インプット情報をどのように扱うか

---

Excel管理された従業員情報をインプット情報として通勤交通費を算出する作業では、1セルごとに現住所情報をコピーして交通費を検索することになりますが、RPA開発者が作成するワークフローではインプット情報のExcelファイルのデータを取り込み、繰り返し処理させることでワークフローを圧縮させます。

これによりワークフローの可読性を高め、保守に負担がかからないようにします。

画面操作を減らすことができないか

---

RPA開発者が作成したワークフローでは、Yahoo!路線検索の使い方も異なります。

「出発」や「到着」に情報入力はせず、現住所と到着駅からYahoo!路線検索の検索結果画面URLを作成し直接移動するようにします。これにより、Yahoo!路線検索での「出発」「到着」の入力や「検索」ボタンのクリック操作等を省略できます。

このようにRPAの安定性や処理速度の向上を実現するためにシステム画面の移動や操作を減らせないかを考慮しながら開発を行います。

Task Capture検証結果まとめ

今回のTask Capture検証結果を、RPAプロジェクトにおける問題解決のポイントでまとめると次のようになります。

Point①　作業記録の負担がないか≒Task Capture自体が負荷ではないか
検証結果：作業記録の負担はほとんど感じないレベル
　　　　　ただし編集作業を軽減するルール整備が必要

Point②　業務プロセス定義書やワークフローを活用できるか
└ プロセス定義書（Wordファイル）
検証結果：RPA開発者が業務理解をするための文書として活用可能
　　　　　編集作業を高度な知識なく利用できる点もメリット

└ UiPath Studioワークフロー（XAMLファイル）
検証結果：ヒトの手順の完全再現でない点がRPA開発のポイントであり
　　　　　RPA開発者がこれを活用するのは難しい

RPAプロジェクトが進捗してくると、必ずしも期待効果が大きくない業務もRPA対象となるため、業務担当者・RPA開発者の負担軽減も検討テーマとして重要になってきます。

Task Captureを利用できる環境にある方は、一度業務の文書化を目的に利用してみてはいかがでしょうか。RPA対象業務でなくとも文書として可視化されている状況は将来的な業務改革を検討する材料となります。

さらには今後の技術革新によってRPA開発にも活用できる可能性もあるかもしれません。

今回はわたしのタスク解消もありTask Captureを試してみましたが、残念ながら継続課題としました。今後も時折気持ちを奮い立たせながら、UiPathプラットフォームのさまざまなツールの技術革新に期待し、検証と活用検討を続けたいと思います。

---