RPA関連記事を書き始めて2年をキッカケに振り返ってみる

プロスポーツの名将と呼ばれる監督には、試合や練習後のミーティングがやたら長いというエピソードが多くあります。これには、より高い成果を目指すために現状の問題点や課題の共通理解を促し、定着化させる狙いがあると考えられます。

よりよい成果を導くためのリフレクション（振り返り)導入や、有効に振り返りを実施するためのフレームワークを紹介した文献もあり、ビジネスシーンでも重要とされています。確かに周辺からは、やたらと会議が長い人の話を聞くこともありますが “キット” 同じ理由からなのでしょう。

と書き始めましたが、今回は振り返りの重要性を深堀するのではなくRPA関連記事を書き始めて2年が過ぎようとしていますので、これまでの記事を振り返りながら、次回のテーマについて考えたいと思います。

RPA開発現場では「じゃない感」から逃げられない　(2020.09.02)

---

RPA開発における要件定義の大切さを説明した、記念すべき第1号記事です。

RPAは仮想知的労働者（Digital Labor)と呼ばれる通り、ヒトの業務を代替する事から開発段階で「じゃない感」を回避できません。よってRPAプロジェクトの要件定義でヒトが担う業務を正しく把握することが不可欠であり、そのためのアプローチであるハッキリ・スッキリを紹介しています。

このハッキリ・スッキリさせることを怠り、現状をそのままに開発することで期待効果が限定されたり、ロボットが安定しないケースはよくあります。RPA開発者のみならず、RPA領域選定に係る業務担当者にも理解いただきたい内容です。

「じゃない感」からの解放は一日にして成らず　(2020.11.25)

---

RPAプロジェクトの要件定義で細心の注意を払ってもRPAロボットが定着するにはそれなりの苦労が必要であることを記事にしています。

RPA開発者はRPA実行ログを監視し「最後の行動から日付が空いていないか」「同一処理で何度もエラーが発生していないか」「開始直後にエラーが発生していないか」などから運用定着度合いを把握し、適宜対応することが必要です。

加えてRPA実行ログの監視を通してRPA開発の教訓とすべき気づきが多く得られることを紹介しています。私たちが得た教訓は、RPA導入自体が目的化していないか対象業務が適切であるかを見極めることや、業務担当者にとって親切な設計になっているかを考える等となります。

また業務担当者にはRPA運用の定着化まで時間を要するため、業務改革に対する強い思いが必要であること、RPA開発者はガッカリロボットを生み出さないために配慮すべきことについて触れています。

RPA導入で心が折れている場合でない　(2021.03.03)

---

本格的な普及期に入ったとされるRPAですが、ガッカリロボットを量産することなくヒトと同じように柔軟性を持たせることが重要であることを記事にしています。

RPA導入が加速する一方で継続利用を見直す企業があるとも言われていますが、これは高頻度の保守対応による手離れの悪さや誤作動による業務品質の不安、まさにガッカリロボットが原因と言えます。

RPAは「システム」や「ビジネスルール」の変化に晒されるため、それぞれの変化に対して柔軟であることが求められます。

記事内では基本的な例として「ITシステム」の変化への対応としてのAPI連携、「ビジネスルール」の変化への対応としてのConfigファイルの項目選定の視点を紹介しています。

これらを通してRPA開発者は発生し得る変化をイメージするとともに、柔軟性を担保するロボット開発を進めることが極めて重要であることに触れています。

「自由が幸せだとは限らない」放浪者ロボットを出さない為に　(2021.07.21)

---

RPAは高度なプログラミング知識がなくても開発できる環境がある特徴から、管理者不在の放浪者ロボット、いわゆる野良ロボット対策を記事にしています。

具体的な対策としてロボット登録により、どんなRPAロボットがどこに存在するのかを把握し、開発ルールを決めることによりRPAの可読性を高めることで実際の開発担当者以外がメンテナンスすることを容易にします。

加えて開発ルールにより保守の効率化やロボットの品質向上も期待できます。ただし0から開発ルールを策定するのは非常に労力を要するためUiPath社の提供する「UiPathコーディング規約」「UiPathデベロップメントアセスメントツール」を紹介しています。

＜補足＞当該記事時点ではアセスメントツールを紹介していますが、UiPath Studio 2019.10以降ではStudio内のワークフローアナライザー機能として活用可能です。

「目指す姿はピクトさんでした」深すぎるアクティビティ階層問題について　(2021.09.15)

---

ちょうど一年くらい前の出来事になりますが、東京オリンピックのピクトグラムパフォーマンスに触発され、RPA開発でも「正しく伝わる」「早く伝わる」「平等に伝わる」ことの重要性ついて記事にしています。

前回の記事で「アセスメントツール」を利用しながらツールの指摘事項に必ずしも準拠する必要はなく、何故守らないのかを決めていくことで開発ルールを決めていくことに触れています。

ただし、「深すぎるアクティビティ問題」としてツールに指摘される事項は、私たちの開発チームは無視をしており、その際、階層の粒度を合わせる、階層を示す番号を命名する、具体的な処理内容を注記すること等、RPA開発者間で「正しく」「早く」「平等」に伝わるルールの実現に向けた取り組み例を紹介しています。

たい焼きは、極めて合理的な設計思想だった。～RPA開発におけるアーキテクチャについて考える～　(2021.11.10)

---

いつも目にする駅前のたい焼き屋の風景からの気付きを通して、RPAロボットの品質を均一化するモジュール化について記事にしています。

RPA開発では共通的な機能をモジュール化させ、複数のRPAロボットにて活用することで、既に動作が保証されているため品質の安定化やテスト工数の削減に加え、管理・保守工数の削減を実現することができます。

またモジュール化のみならずその利活用度合いを高めるための２つの視点でも検討します。限定の視点ではシステムログイン・ログアウトやID/PWD取得など期待効果は小さくなります。しかし、多くの場面で利用できるようにする共通部品化、拡張の視点では特定のシステムに対するログイン→データアップロード→ステータス確認など限定的な場面での利用となるが期待効果が大きく、必要になった場合に即利用可能とする共通ロボット化などの取り組み例を紹介しています。

UiPath LTS 2021.10リリースの気になるを調べてみた　～積極的な動機による替えドキを目指して～　(2022.02.09)

---

RPA製品であるUiPathのバージョンアップタイミングと記事時点での最新バージョンである2021.10の気になる点について調べた結果を記事にしています。

UiPath社の LTS 2021.10リリースからRPA高度利用に関連しそうなSelf-HealingとIntegration Serviceに着目してその内容を調べています。

特に過去の記事でも触れているRPAロボットの柔軟性を高めるためのAPI連携をより容易に実現するIntegration ServiceはAPI機能を有するシステムのイベントをトリガーにレガシーシステムを対象としたRPAロボットを実行することが可能です。
環境が許すようであれば是非積極的に活用したいサービスとして紹介しています。

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

---

UiPathプラットフォーム製品のTask Captureを実際に試してみた感想をとりまとめ記事にしています。

業務担当者の繁忙によるRPAプロジェクトの停滞や期待効果が大きくはない業務に対するRPA導入検討等により、業務担当者とRPA開発者の負担軽減は重要な課題です。

そのような場面でTaskCaptureのPC上の操作と画面キャプチャを自動記録し、結果を出力するという機能を活用できないかを検証しています。

特に作業を記録する負荷はないが編集作業を軽減するための作業記録時のルールを決め、RPA開発者が業務を利用するための資料として活用することをおススメしています。

またTask Captureは多くのライセンスに含まれていることから現在利用していなくとも、既に利用可能なライセンスを利用されている場合が多いことを紹介しています。

次回の記事について考える

RPA関連の記事を通して、私たちのRPAチームの取り組みを整理しつつ、RPAの技術的な特徴を踏まえ持つべき基本的な視点を全ての業務担当者やRPA開発を志す方の参考になれば、という思いから様々な記事を出稿してきました。

一方、今回の振り返りにより、これまでの記事では主にRPAロボットが稼働するまでのプロセスや定着化について触れてはいますが、そもそもどんな定量目標や成果を目指し、その実現に向けどのような活動をおこなっているのかを紹介していないため、私たちの取り組みを次回記事のテーマとしたいと思います。

---