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

駅前での違和感から

私の最寄り駅はそれほど大きくはありませんが、それなりに商店があります。よくあるチェーンの牛丼店やハンバーガーショップ、コーヒーショップなどありふれた風景です。そのなかでも信号待ちで目にするたい焼き屋の前でいつも違和感がありました。

なぜなら今更ながら、たい焼きの作り方は極めて合理的だなと感じたからです。

具体的には、最終的なアウトプットとなるたい焼きを焼くためのフレームワーク（型）があり、材料はモジュール（部品）単位（生地・餡）で管理されています。さらにはモジュールの種類（小豆あん・白あん・カスタード・サツマイモ等）で様々なバリエーションを再現しています。

自動車やコンピュータなどメーカーの製造現場では当たり前だと思いますが、よく考えるとたこ焼きも同じような仕組みだし、世の中のビジネスや商売では、品質の均一化やバリエーションを再現する手段としてのモジュール化で溢れているのかも知れません。

RPA開発におけるモジュール化

RPA開発におけるモジュール化について考える前に、RPA開発におけるモジュールとは、対象とする業務における機能単位（つまりは、複合した動作の各パーツ）と言えます。以下のような機能(A)や機能(B)のようなRPAの動作がモジュールです。

以下の図を見ると、機能(B)は会社ごとに取引データは違うものの、「データを基に請求書を作成する」という同じ動作を行ないます。しかしながら、個社ごとにRPAを開発するのは非効率です。

---

そこで、私たちが利用するRPAツールであるUiPathでは、複数の共通処理に対して同一モジュールで同じように処理させることができます。これをモジュール化と呼んでいます。

特に長い業務処理を求められる場合にワークフローも複雑化しがちですが、モジュール化を上手におこなうことで様々なメリットが得られます。

① 品質の安定化
既に動作が保証されている（もしくは動作検証をおこなった）モジュールを活用するためRPA品質を安定化させます。

② テスト工数の削減
テスト段階で検証が必要な範囲が限定されるため、問題点の検出を容易にするとともに、テスト工数自体の削減に繋がります。

③ 管理・保守工数の削減
モジュール化の範囲が大きくなれば、RPAの保守対応が必要となった場合でも、管理するメンテナンス対象が限定されるため保守工数の削減に繋がります。

では以下の図を再度具体的に見ていきましょう。

---

当月の全取引データを取引DBから取得して、得意先ごとの請求書を作成するという業務をRPA化する場合、上記の機能(A)取引データを取得する、機能(B)請求書を作成するという機能に分解します。
そして、そのうち機能(B)をモジュール化します。

上述の通り、機能(B)では、得意先ごとの取引データをインプットとして得意先ごとの請求書をアウトプットするという動作は、個社が異なっても全く同じです。
よってこの部分を共通機能として、同じモジュールで処理をさせて品質安定化やテストや管理工数の削減を狙います。

RPAプロジェクトでは、このような効果を期待し、モジュール化は積極的に検討すべきです。

ただし、利用範囲が広域になればなるほど効果は大きく得られる反面、その影響範囲は大きくなるため、“「目指す姿はピクトさんでした」深すぎるアクティビティ階層問題について“で触れた通り、複雑な階層構造になってしまうと視認性が悪くなり保守性を損なう等、いたずらに実行しても期待する効果は得られないどころか非効率性を招きます。

よってモジュール化は、共通する範囲を上手に選択するために業務を十分に理解し、慎重に設計することが重要です。

---

モジュール化の取組はそれだけに留まらない

---

またモジュール化の取組はそれだけに留めず、前述のイメージからさらに利活用度合いを高める検討を行います。

利活用を高めるには2つの方向があります。1つは機能を限定する代わりに、より幅広く使うということ、2つ目は機能をより拡張させることで活用できる範囲は狭まってしまいますが、その中でも複数のシーンで活用できるような最大範囲を発掘する、という2点です。

検討の視点①：限定の方向
モジュールの範囲を限定することで、より多くのRPAに活用できないかを検討します。私たちはこれを共通部品化と呼んでいます。
料理に例えると、どんな食材であろうと料理を作ろうと、「手を洗う」とか「包丁やまな板を準備する」は常に発生します。
逆に言うと「手を洗う」も「包丁やまな板を準備する」も、あまり負荷は大きくないし作業量も多くはないけれど、毎回発生するので頻度が高い作業ですよね。また「手を洗う」ならば、料理だけでなく、食事をする前や、外出先から帰った時など、複数のシーンで行います。
このような使用頻度が高く、多くの活用シーンで利用ができるような機能をRPAで開発しておき、共通部品として活用するのです。

検討の視点②：拡張の方向
今度は、さらに機能を搭載しつつもさまざまな部門で利用され、全社での効率化効果の高い機能領域を見つけられないかを検討します。
共通部品よりは機能がリッチでありながら、多くの人に使ってもらえるような最大の範囲を探すのです。特定のITシステムにおいて様々な業務で利用できる最大の範囲をカバーすることが多いことから、私たちはこれを汎用RPAロボットと呼んでいます。
料理に例えるなら、カレーも、肉じゃがも、シチューも、具材を「切って」「炒めて」「煮込む」までは同じです。
この工程が仮に自動化できたら、同じロボットでカレーでも、肉じゃがでも、シチューでも調理時間を効率化できることになります。

限定の方向：共通部品化の視点

共通部品化の進め方は、ワークフローの階層単位（例えば初期処理・メイン処理等）でより細かい機能単位に着目して、より広く共通化できないかを検討します。

---

「初期処理」における共通部品イメージ
部品①：ID・PWD取得
RPAが操作するシステムのログイン情報は、アクセス権限を厳格に管理された場所に集約保管しています。この情報からログインIDやパスワードを取得する処理を部品化します。
他にもRPAが不具合を起こさないように、既に複数のブラウザが起動していないかなどRPA実行環境におけるブラウザの状態チェックなども初期処理として共通化部品化が可能です。

「メイン処理」における共通部品イメージ
部品②：システムログイン
例えば人事システムや経理システムのような基幹システムで様々な業務でRPAは多岐に利用されていないでしょうか。具体的な業務処理の共通化は難しくとも同じシステムへのログイン処理に限定すれば共通部品化が容易です。他にもログアウト処理も同様に共通部品化が可能です。

部品③：ファイルDL
システムから必要なデータをダウンロードして加工するような業務は多いと思います。システムからダウンロードを実行する処理は異なっても、ダイヤログが表示され、保存先を指定する処理に限定すれば共通です。これに加えて品質向上のために指定ファイルがちゃんとダウンロードされているかをチェックする処理も合わせて共通部品化が可能です。

部品④：Excel操作
UiPathでは、Excel関連のアクティビティは存在します。既に部品が存在すると言えますが、sheet操作や行列の追加削除に関するアクティビティは存在しないため、よく使う処理として共通部品化します。その場合、共通部品となる外部ワークフローで具体的な操作をおこなうVBAプログラムを実行するようにします。
これには特定のプログラム言語の知見がないエンジニアであったとしても共通部品を利用することでその処理(VBAなどのプログラムによる処理)を実現することが可能という面もあります。

このように共通部品化は様々なケースで検討が可能です。また開発パフォーマンスを高めるだけでなく、エンジニア個人に依存したRPA品質の均一化も期待できます。

拡張の方向：汎用RPAロボット化の視点

---

汎用RPAロボット化の進め方は、社内で広く利用されているシステムに着目して、その同一処理の範囲がないかを検討します。

汎用RPAロボットのイメージ
当社では紙に記述されたテキスト情報の電子化をサポートするシステムであるDXSuiteというAI-OCRシステムを利用しています。DXSuiteでは、紙資料を電子画像化したデータをシステムにアップロード、AIがその文字情報をテキスト化、その後システム内でAIがテキスト化したデータを確認・補正する（エントリー）処理を行います。

このエントリー処理は個別的な要素が強いため共通化は難しいものの、DXSuiteを利用する部門では必ずシステムにログインし、画像データをシステムへアップロードし、システムの処理を待つことになるためこの範囲を汎用RPAロボットとします。（実際の処理は“RPA導入で心が折れている場合でない”で変化への柔軟性として紹介している通りAPI機能にて実現しています。）

他にもシステムからデータをDLする処理を汎用RPAロボット化するなど、システム内でコアとなる処理でなく、そのシステムを利用するにあたり共通的な前処理や後処理工程がないか、またそれを共通化できないかを検討します。

汎用RPAロボットが整備されれば、開発・テスト不要、環境構築のみで即時利用が可能となります。よってこれまで大量の処理が必要であっても、締め切りもあるため自動化の検討自体を諦め、社員の時間を割いて対応せざる得ない突発的に発生する業務でのRPA活用も実現できます。

---

たい焼きモデルを目指して

これを機会に改めて駅前でたい焼きを作る姿を眺めてみると「天然たい焼き」という商品名が目に入ってきました。違和感の原因は、合理的なたい焼きの製造工程とは異なりましたが、今回の記事ではRPA開発におけるモジュール化について書きました。

私たちはより多くの現場の課題解消や期待に応えるべく、RPA開発でもたい焼きモデルに負けないような効率化に取り組んでまいります。

---