モジュール化とは？

ここでいうモジュール化とは、同じ処理があったときに、共通の処理を1つのコードで表現し、複数の箇所から利用できるようにすること。
一般的なプログラミングだと、関数を作ったりする。RPAの場合は（製品によるけど）ワークフローを別のファイルに切り出したりすることで実現できる。

モジュール以外の別の選択肢としては、次の方法が考えられる（他にもあるかも）：

コピペして増やす
ループで実装する（構造上ループで実装するのは無理な場合もあると思う）

モジュール化のメリット・デメリット

メリット

ワークフローの論理構造がシンプルになり、どこで何をやっているかを理解しやすい
- ループや分岐が増えるとどんどん複雑になる。複雑になると人間の脳では把握できなくなる
改修箇所の特定が容易
- 引数の増減や引数の型の変更にともなって、呼び出し元の変更が必要になることもある。そのような場合にも、モジュールの名前（関数名やファイル名）で検索するなどすれば、比較的容易に変更箇所を特定できる
- 改修箇所が分散していると、直すのももちろん探すのが大変。
記述量が減り、視認性が向上
- 製品によるが、RPAは（通常のプログラム以上に）記述量が増えると視認性が悪化しがち。
改修箇所が少なくて済む
- N箇所にコピペした場合、その処理が変更になったり不具合が見つかった場合、N回同じ作業をする必要がある。
  - これが一般的なプログラミングなら、テキストエディタを使って一括置換できる（＝1度の作業で済む）場合もあるが、RPA製品ではそういうことはできない¹
  - RPA開発では、特定の条件でしか再現しない不具合に遭遇することが多い。そのため、当初は想定していなかった不具合に見舞われ、事後的に手を打つことが多いように思う。²　このような場合に逐一改修していくのは本当に辛い。
再利用しやすい
- コピペする場合は、ワークフローのどこからどこまでをコピーすればいいのか考えてからコピーする必要があるが、その必要がない
- ブラックボックス化できる。中でどんな変数を使ってて、途中でどんな処理をしているのかを知らなくても使える。
- （ブラックボックス化と似てるけど）どんな変数を引数として与えればいいか、返り値として何をもらうのかが明確になる。³
テストしやすい
- うまくモジュール化すれば、その部分だけテストすることができる。
  - 小さく試したほうが開発がスムーズに進むことが多い
    - 不具合に早めに気付ける
    - 不具合箇所の特定がしやすい
    - テストの実行時間を短縮できる

デメリット

設計の検討が必要
- メリットを最大化し、デメリットを最小化するにはどうすればいいか、色々と検討する必要がある
改修の影響が複数箇所におよぶ
- 改修した後ちゃんと動くかのテストも、呼び出し箇所それぞれで行う必要がある
  - ということは、どこでその共通部品が使われているか（依存関係）を知る必要がある。検索などですぐ分かる場合もあるだろうし、製品側で依存関係を自動で管理・可視化してくれる場合もある。そういうのがない場合、予めドキュメントで管理しておく必要がある。
改修の影響が予測できない場合がある
- 共通部品XをAとBの２箇所で使っていたとする。あるとき共通部品Xを改修すると、AではうまくいくがなぜかBではうまくいかない、みたいなことが起こりうる。

共通部品の作り方について

利用範囲をどこまで広げるか

共通部品を作成したとして、それをどの範囲で利用するかはよく考える必要がある。

例えば、以下の選択肢が考えられ、下にいくほど利用範囲が広い。

一手順の中で同じ処理が複数回現れるので、その部分をモジュール化し、手順内で利用する
まとまった業務のグループの異なる手順の中に同じ処理が複数含まれるので、その部分をモジュール化し、各手順を自動化するワークフローの中で使用する
異なる業務で同じ処理が複数含まれるので、その部分をモジュール化し、様々な業務から呼び出せるようにする

利用範囲が広くなるほど改修や開発にかける時間を省ける。一方で影響範囲が大きくなり、検証が大変になったりする。

判断基準としては、次のような観点があると思う。以下の場合は利用範囲を広げるメリットが大きく、デメリットが少ない。

品質を保証しやすい処理である
- 画面操作やファイル操作など、外部とのやりとりを伴わない処理のほうが安定しやすい
  - 例えば、計算や文字列操作を行う処理とか、外部のコードやスクリプトを呼び出す処理
- 画面操作を行う処理でも、UIオブジェクトを正確に認識でき、エラー率が少ない処理
再利用する可能性が高い
処理内容が変更になる可能性が高い
その機能を呼び出すのに必要な前提条件や引数がシンプルに表現でき、使う側で誤解することが少ない

モジュール単位のコピペ

再利用可能な部品を作ったところで、異なるファイルとしてコピペして再利用するということも考えられる。
結局コピペかよ！と突っ込まれそうだけど、一定の再利用性を確保した上で、改修時の影響範囲を限定できるため、実務上は効果がある。

例えばAさんが自分用に作ったワークフローの部品を、Bさんでも使えるように渡す、というような場合。AさんはBさんに渡した後も好き勝手に改修したいし、Bさんも自分用にカスタマイズしたいことがある。
ファイルを分けていれば、お互いに気兼ねすることなく編集できる。

UiPathの場合、（裏技的に）ワークフローファイルをテキストエディタで開いて置換することはできる。ただ、間違いなくサポート対象外。他の製品はよく知らない。 ↩
RPAあるあるだと思うけど、例えば検索ボタンをクリックして、検索結果が返ってくるまでちょっと待ってから次の処理に進みたい。開発環境だと3秒だけ待てばよかったけど、実運用上は10秒くらい待った方がいい・・・とか。 ↩
ただ、これは製品によるかもしれない。少なくともUiPathはワークフローを別ファイルに切り出した際、内部で使用する変数とは別に引数を明示的に指定できる。Automation Anywhereの通常のタスクでは引数と変数の区別がない。同様のことをするにはMetabotを使う必要がある。 ↩