Blue Prismベストプラクティス 設計編 1 プロセスとオブジェクトの役割分担

お待たせしました。ベストプラクティスシリーズも、今回からいよいよ、設計編に入ります。引き続きよろしくお願いいたします。まずは設計編 1 プロセスとオブジェクトの役割分担 についてです。

プロセスとオブジェクト

先の記事で、オブジェクトで実装すべきものについてご紹介しました。大原則を再掲します。
ロジックは、オブジェクトには実装しない。
ロジックは、すべてプロセス側に実装する。
です。

プロセス

プロセスには、業務フローを実装します。業務ロジック、例えば、判断、分岐、順序、エラー処理などです。これに加えて、アプリケーションの起動「指示」や終了「指示」、そしてもちろん、オブジェクトの呼び出しがプロセスの役割になります。Work Queueの操作もここになります。Work Queueの操作をオブジェクトで実装することは、「原則的に」あり得ません。

オブジェクト

これに対して、オブジェクトには、アプリケーションの「操作内容」を実装します。例えば、フィールドへの書き込み、フィールド値の読み込み、ボタン押下、画面遷移などです。アプリケーションの起動、終了、ログイン、ログアウトなどもあります。

オブジェクトは、極限まで細かく切って、シンプルかつ小さなオブジェクトを作るようにします。これにより、必然的に、業務ロジックはそぎ落とされていきます。
目指すは、
１画面＝１オブジェクト
１操作＝１アクションページ
です。

例えば、「ERP上の顧客データの住所を更新する」という業務プロセスを自動化したい、という要件があったとします。ERPアプリケーションの以下の操作が必要となる、というケースです。
1. 起動
2. ログイン
3. メニューで顧客名を検索
4. 検索結果から顧客データをクリック
5. 顧客データの住所情報を更新
6. ログアウト
7. 終了

このとき、ありがちなのが、以下のようなオブジェクトを作ってしまうことです。

ひとつのオブジェクトとその中に、4つのアクションページが作られています。しかも、操作手続きを前提とした処理が、ひとつのアクションページに書かれています。（「検索」とか「住所変更」がそうなってしまってますよね。）

これでは、確かに要件を満たすオブジェクトを実装することになりますが、再利用性が全く考慮されていません。

今後、例えば、
「分析目的で住所を参照するだけの自動化業務」
「顧客一覧から自動的にDMを発送する業務」
などの自動化要件が来た場合に、別のオブジェクト、もしくは別のアクションページを作らなくてはならなくなってしまいます。

では、以下のようにするとどうでしょうか。

最初の表と内容を比べてみて下さい。

うへー、オブジェクトの数が5倍じゃん！

って思いますよね。。。
ですが、やっていること＝操作内容のステップの合計の数は同じです。
オブジェクトとページを細分化しただけです。決して、これで初期開発工数が増大したわけではありません。
反対に、再利用性は格段に上がっています。
（メモリなどのリソース消費効率性も、個々のオブジェクトが小さくなる分、上がっています。）
（チーム作業・作業分担もし易くなります。あなたの双肩にすべてがのしかかることも回避できます！）

「分析目的で住所を参照するだけの自動化業務」
「顧客一覧から自動的にDMを発送する業務」
が将来、あなたにやって来たとしても、これらオブジェクトをそのまま使って、新たなプロセスを構築することができるはずです。

ほら、保守運用工数・メンテナンス工数の削減が実証されます。
Blue Prismを選んでよかった、と思う瞬間です。

さて、じゃあ、どうやるか。

自動化対象業務プロセスの洗い出しとAsIsの業務フローが書けたなら、いきなりBlue Prismのスタジオに向かうのではなく、Excelのスプレッドシートに、アクションステップをすべて書き出してみて下さい。

対象とするアプリケーションに対するアクション（操作内容）を書き出すだけです。そこには、ロジックや条件はいりません。
書き出せば、オブジェクトとページの整理ができるはずです。

「設計」というと仰々しいですが、「画面とアクションのリストアップ」だったら簡単ですよね。
この程度で良いんです。（＝これがオブジェクト設計です！ これがオブジェクト設計書になります！）

オブジェクト設計書を作る、作らない、とで、「Blue Prismらしさ」の度合いが全く変わってきます。

検索関連処理、メニュー関連処理は少々トリッキーですが、基本的には、Javaのメソッドと同じような考え方で、あるひとつの画面やデータの塊に対して「SetXXX()」（つまり入力・更新系）と「GetXXX()」（つまり取得・読み込み系）の組み合わせがひとつのオブジェクトになる、とすればシンプルに設計できます。実際は、これらに加えて、「Attach」や「前画面に戻る」「メインメニューに戻る」などが加わると思います。

アプリケーション画面上で指定する内容や値は、パラメータ化して、プロセス側から渡すようにします。オブジェクトのデータアイテムに初期値で書いておく実装はダメです。
ですので、オブジェクトのアクションページのInput、Outputのパラメータも設計時に定義するようにしましょう。

オブジェクト設計書がExcelのスプレッドシート、セルに収まらないようであるならば、それはベストプラクティスに沿っていないと思って下さい。

まとめ

読者の皆様のプロジェクトや自動化案件の中で、
・ 似たようなオブジェクトが増えていませんか？
・ それを回避する為に、ひとつのオブジェクトの中に大量のアクションページが含まれていませんか？
・ いくつかのアクションページは似たような処理が実装されていませんか？
・ それを回避する為に、あるアクションページの中で、他のアクションページを呼んでたりしませんか？

これらは、全部、バッドプラクティスです。
気を付けましょう。

・ 取り敢えず、プロセスとオブジェクトを親と子の関係ぐらいの絡みで役割分担して作ったりしていませんか？
・ 取り敢えず、先ずはHappy Pathで動けばいいや、と、自分のプロセスと絡むオブジェクトだけを作り始めていたりしませんか？

これらも、全部、バッドプラクティスです。

断言します。
Blue Prismを選んだ人は、後先を考えて、RPA製品を選定した方々です。

Blue Prism以外を選んだ人は、目先の。。。

あ、失言でした。

実装する際も、後先を考えて、ちゃんと設計しましょう。
オブジェクト設計が出来ちゃえば、先にオブジェクトだけ、だぁーっと作っちゃうのも良いでしょう。

※本投稿は、別ブログで掲載・公開していた内容に加筆・修正を加え再掲載しています。