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

#ピクトグラム
#RPA
#デジタル

DIGITAL

RobotA

2021.09.15

ピクトグラムって、いいね

「ピクトグラムパフォーマンス」、パフォーマーがさまざまな競技を表現し、国内外を問わずに話題になったのは記憶に新しい。
それに触発され、インターネット上ではピクトグラム大喜利で盛り上がったそうです。

ピクトグラムとは、『情報や指示、案内などを単純化された絵や図形で表したもの。「絵文字」「絵記号」などと訳される場合がある。言語によらず情報を伝達することができ、街頭や施設内での案内に用いられる。』ということのようです。
非常口の案内、トイレの入り口、道路標識、最近ではソーシャルディスタンスやマスクの正しい着用など日常の多くの場所に溢れています。

ピクトグラムは、公共の施設などでルールを伝達する役割であるため、次のようなことを実現していると言えそうです。

1. 正しく伝わること

2. 早く伝わること

3. 平等に伝わること

「よく伝わる、わかりやすい資料の作成」などと同じで、ビジネスにも通ずると言えそうです。ただ、ビジネス環境は複雑であり、伝えることを通してヒトに行動を起こしてもらうことが必要となります。

当然ながら、一方通行の標識には交通ルールは守るべきという前提が隠れているため「それらが求められる背景・経緯や課題」「メリット・デメリット」「金銭的価値」「取り得る代替手段」などの情報は含まれません。

RPA開発プロセスに当てはめてみよう

では私が担当するRPA開発ではどうでしょうか。

これまでも何度か触れている通り、RPAは一般的なITシステムの導入と比較して、小規模から安価で導入できるという特徴があります。よくある事例として、「解決すべき課題」「メリット・デメリット」「金銭的価値」「取り得る代替手段（RPAでの解決が適切か）」という判断がないままにRPA導入の対象領域を選定することにより、有効な効果が得られないということがあります。言い換えると適切な対象領域の選定は、それらを明確にすることであり、その後のワークフロー開発の前提となります。

よって正しい領域選定を前提に、ワークフロー開発では「正しく伝わること」「早く伝わること」「平等に伝わること」まさにピクトグラムを目指すことになります。また以前の記事 “RPA導入で心が折れている場合でない” でも触れた通り、RPAロボットはITシステムやビジネスルールの変化の影響を受けます。よって変化に対する柔軟性を追求するのは勿論のことですが、常にRPA開発者以外が保守や機能改修することを考え「正しく伝わること」「早く伝わること」「平等に伝わること」の実現は、次のような課題を解消するためにも極めて重要となります。

✔ 「正しく伝わること」
これができていないと…誤認のまま保守することになり、RPAロボットの誤動作リスクが高まる

✔ 「早く伝わること」
これができていないと…RPAロボットの保守やメンテナンスに掛かる過度な負担が生じる

✔ 「平等に伝わること」
これができていないと…開発者以外が保守できない（放浪者ロボットの誕生リスク）

「深すぎるアクティビティ階層」問題

前回の記事 “「自由が幸せだとは限らない」放浪者ロボットをださないために” では次のようなことから、ワークフロー開発ルールを定めることについて触れています。

誰が見ても理解しやすいワークフロー開発により、保守や機能改修の効率性を高めるためのルールを定めます。
ルールを定めるために、UiPath社の「Uipathコーディング規約」「デベロップメントアセスメント」などを参考にするのも有用です。
「UiPathコーディング規約」の全てのルールに準拠する必要はなく、何故守らないかを決めることでルールは定めることもできます。

3つ目について、私達が「デベロップメントアセスメント」ツールからの指摘を無視しているものに「深すぎるアクティビティ階層」というものがあります。

これは、上図のイメージの通り階層構造状にワークフロー開発を行いますが、この階層が深かすぎるため複雑な構造になっており、「正しく伝わること」「早く伝わること」「平等に伝わること」ができていないのではないかという疑義を指摘しているものです。

ただし「深すぎるアクティビティ階層」の指摘は、対象業務の複雑さなどにより、画一的に〇階層という閾値によって良し悪しを判断することはできません。よってワークフロー開発ルールはその階層の深さが〇階層以内ということではなく、守るべき約束事を定めていくことになります。

では私達のワークフロー開発における約束事について、いくつかご紹介します。

約束事①：階層は機能ごとに分割、階層ごとの粒度を合わせる

他人が開発したロボットの保守や機能改修のためにワークフローを開いた瞬間、絶望とともにそっと画面を閉じる（閉じたい気持ちになる）。これもRPA開発あるあるです。

このようなことがないよう、複雑なワークフローであっても誰が見ても理解できるよう、例えば「1.初期処理」「2.メイン処理」「3.終了処理」区切り、「1.1ブラウザチェック」「1.2変数格納処理」「1.3confingファイル処理」「1.4パスワード管理台帳処理」「1-5.SMTPメール送信」など具体的な処理プロセスの前工程を「1.初期処理」配下に理路整然と配列することで「正しく伝わる」ようにします。

約束事②：階層を示す番号を命名規則とする

RPAロボット稼働時にエラーが発生した場合、エラーが発生した箇所を通知する仕組を実装しています。ただし複雑なワークフローの中から該当する箇所を探すための識別番号となるよう「2（1階層目の番号）-1（2階層目の番号）-2（3階層目の番号）・・・」というように階層を示す番号を付けます。これにより「早く伝わる」ため「2-1-2-2-2-3■■■処理でエラー」というようなエラーメッセージを検知した場合、階層構造を順番に辿ることで素早く該当する箇所にアクセスできます。

約束事③：具体的な処理内容を注釈として示す

例えば「2-2-1①0件データ削除」では処理内容のイメージがしづらく、他の人が一連のワークフローの内容を理解するにはかなりの労力を要します。

これを軽減するためにも「ダウンロードファイルが0件またはパスがない場合はスクレイピングデータテーブルからも削除」というように具体的な処理内容や処理条件などを注釈として残し、「平等に伝わる」ようにします。これにより開発者のみならず、誰が見ても処理内容のイメージができるようになります。

目指す姿はピクトさんでした

いかがでしたでしょうか。

RPAは限定的な範囲への導入のみならず、その領域拡大や更なる高度活用も期待されていると思います。「深すぎるアクティビティ階層」問題だけでなく、「正しく伝わること」「早く伝わること」「平等に伝わること」を意識し、RPA開発ルールを策定することは、RPA開発・保守の効率化、ひいてはRPA導入効果の最大化に非常に重要となります。

今回ご紹介した内容は、あくまで一例ですが、開発ルール検討の視点として参考になればと思います。

今回の記事を書くにあたり、スマートフォンに「日本ピクトさん学会」というサイトがブックマークされていることに気付きました。よほど時間を持て余していたのか、以前も同じようなことを感じていたのかは記憶にありません。

私達はピクトさんを目指す姿として、多くの自動化ニーズに応えるべく、RPA開発の効率性を高めていきたいと再認識をしながら、今回はここまでとします。