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

始めることは難しいが、定着させることはもっと難しい

「新たなスキルを身に着けるために、毎日読書を続けよう」
「語学を習得するために、毎日オンラインで学習しよう」
「体型の維持と健康のために、毎日筋トレをやろう」　など

新型コロナウイルスの影響で、自粛による外出機会の減少やテレワーク活用による通勤時間の減少を有効に活用しようと、新たなことへ挑んだ方も多いのではないでしょうか。

内閣府の発表からもコロナ禍において新たに挑戦したと回答した方の割合は50%を超えており、日常生活や趣味、ビジネスに関連するものなど様々な挑戦を通して、空いた時間を有効活用しようという方が多くいるという事が見てとれます。

実際に、楽器演奏に挑戦しようという方も多いのか、巣ごもり需要のなかでもウクレレやアコースティックギターの売上が前年同期比200％超とか、老舗ギターメーカーFender社も過去最高の売上見込というニュースを最近目にします(「毎日がブラックマンデーのようだ」がその凄まじさを表しています。)。

---

※【新型コロナ禍】〈楽器販売事業者〉３―４月のＥＣ売上が伸長／教本や楽譜の初心者需要も
※新型コロナで"楽器需要"が増大　米ギター大手フェンダーが「過去最大の売上見込み」

冒頭のような新たな挑戦といえば、年始に「今年は絶対に…」と決意するアレに似ています。
重い腰をあげて始めてみたものの、継続できず三日坊主となった経験も含めあるあるではないでしょうか。

“オフィスへの出勤をテレワーク勤務に変更する”、“仕事帰りの居酒屋から宅飲にする”など、これまでの行動をなかば強制的に変えるという事と違い、新たな技術や能力の習得を始めるだけでも素晴らしい事ではありますが、習慣化させ定着させることはさらに難しさがあるもので、まさに一日にして成らずです。

RPA開発者はロボットと現場の伴走者であるべき

ロボットによるヒトの業務の代替は、前回の記事『RPA開発現場では「じゃない感」から逃げられない』でも触れた通り、個別的なビジネスルールを扱う事や判断基準を明確にする必要があるという特性もあり、その利用が定着するまでに時間を要する場合があります。

RPAの定着には、本来はRPA導入のメリットを正しく理解することや、本来求められる業務で成果を挙げるなど強い思いが不可欠です。

その理解が浅いと最悪の場合、

「期待していたのと違う」
　　　↓
「結局、ヒトが業務を実施せざるをえない」
　　　↓
「ロボットは放置され、従来通りヒトが業務をおこなっている」

という元の「じゃない感」をヒトが業務で担う状態へ戻ってしまうこともあります。

このような最悪のケースを避けるために、RPA開発者は現場と伴走し、ロボットが現場に定着したことを確認することが必要です。

具体的にはロボットの行動をモニタリングし、定着度合を把握、適宜対応することが必要です。ロボットの行動モニタリングは、以下のようなRPAの操作ログから把握することができます。

---

上記のようなログから、以下のような状況が発生していないかをモニタリングします。

①最後の行動から日付があいていないか
月次処理など定期的に発生する業務であるはずなのに、その時期にロボットの行動記録が確認できない場合は、ロボットが放置され、「じゃない感」をヒトが埋めている可能性があります。

②同一処理で何度もエラーが発生していないか
ロボットはITシステムとビジネスルールの不一致である「じゃない感」を扱うため、ルールの変化によりエラーが発生している場合もあります。
ただその定着までは、そもそもの業務仕様の把握、ロボット開発に漏れがある可能性があります。
（変化に強く保守性の高いロボットの開発は、機会があれば別途扱いたいと思います。）

③ 開始直後にエラーが発生していないか
担当者が慣れるまでは数回程度エラーが発生するものですが、毎回開始直後に発生するのは複雑すぎるロボットの起動手順が原因かもしれません。
ITシステムとビジネスルール間の「じゃない感」が、ロボットとヒトの間に新たに生じている可能性があります。

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

RPAは、仮想知的労働者（Digital Labor）とも呼ばれています。

リモートワークが盛んになった昨今、部下の状況把握に悩まれる管理職も多いと聞きます。実際に同僚や部下がイキイキと仕事しているか把握することは大変です。

我々は、リモート環境の部下のマネジメントをするように、ロボットの行動をモニタリングしています。この作業は大変ではありますが、でもこれによってRPA開発に生かされる教訓が得られる事もあります。

①そもそも適切なRPAを導入するのに適切な業務であるかの見極め

↓ よく確認してみると ↓

上記のようなケースでは、メンテナンス後に生じる構造変化等によりロボットはエラーを頻発させてしまいます。

このような特性がある場合でも、現場担当者とRPA開発で毎回保守をしても十分な効果が得られることが確認できていれば、必ずしも問題にはなりません。

ただし、本来想定していたRPAの活用頻度が少なく、適切な効果が出ないためRPAには不向きとも言えるため、業務特性を把握し適切なRPA対象業務を選定することは重要です。

②現場担当者にとって親切な設計になっているかの振り返り

データの取得先や、データ保管先などの軽微は修正は現場で対応できるように、以下のようなConfigファイル（設定ファイル）を利用します。

---

Configファイルによって「出力するアウトプットの保存先の変更」程度での軽微なプログラム改修を不要とし、保守性を高める事ができます。

しかし極端な例ですが、実際に利用する担当者にとって親切な設計になっていないと、ファイルの扱いを間違えたことが原因でエラーが頻発します。

今となっては非常に当たり前で、例にあげたような業務特性の把握やConfigファイル（設定ファイル）のままに開発を進める者は、我々の開発チームにはいません。

過去にはそのような例がありましたが、対象ロボットについては自戒の念を込めて【ガッカリロボット】と呼んでいます。

最後に、開発側は定着度合を把握し、ロボットの利便性を高める事はできますが、最後は担当者の業務改革に対する強い思いが必要です。

冒頭で巣ごもり需要の例として楽器に関するニュースを挙げたのは、私もクロゼットからギターを持ってきたクチだからです。

かつてのように演奏できないくやしさが原動力となり毎週末練習を続けており、まだまだではありますが少しずつ勘を取り戻しているように感じています。

一方で、かつてのような体型に戻せないのは伴走者がいないからだという言い訳を思いつきましたが、何も始めていないし、結局思いが足りないのでしょうね。

まさにロボットによる「じゃない感」からの開放は一日にして成らずです。私たちはより多くの業務改革の思いに応え、ロボット領域選定から運用の定着まで伴走いたします。

ライター「RobotA」の最新一覧

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

---