Blue Prismベストプラクティス<設計編①> プロセスとオブジェクトの役割分担
「ジャナイホー」による「ベストプラクティス」シリーズ、今回からいよいよ、設計編に入ります。設計編① プロセスとオブジェクトの役割分担 についてです。
プロセスとオブジェクト
先の記事で、オブジェクトで実装すべきものについてご紹介しました。
大原則を再掲します。
ロジックは、オブジェクトには実装しない。
ロジックは、すべてプロセス側に実装する。
です。
プロセス
プロセスには、業務フローを実装します。業務ロジック、例えば、判断、分岐、順序、エラー処理などです。
これに加えて、アプリケーションの起動「指示」や終了「指示」、そしてもちろん、オブジェクトの呼び出しがプロセスの役割になります。
Work Queueの操作もここになります。Work Queueの操作をオブジェクトで実装することはあり得ません。
オブジェクト
これに対して、オブジェクトには、アプリケーションの「操作内容」を実装します。
例えば、フィールドへの書き込み、フィールド値の読み込み、ボタン押下、画面遷移などです。アプリケーションの起動、終了、ログイン、ログアウトなどもあります。
オブジェクトは、極限まで細かく切って、シンプルかつ小さなオブジェクトを作るようにします。これにより、必然的に、業務ロジックはそぎ落とされていきます。
目指すは、
1画面=1オブジェクト
1操作=1アクションページ
です。
例えば、「ERP上の顧客データの住所を更新する」という業務プロセスを自動化したい、という要件があったとします。ERPアプリケーションの以下の操作が必要となる、というケースです。
- 起動
- ログイン
- メニューで顧客名を検索
- 検索結果から顧客データをクリック
- 顧客データの住所情報を更新
- ログアウト
- 終了
このとき、ありがちなのが、以下のようなオブジェクトを作ってしまうことです。
オブジェクト |
ページ |
操作内容 |
ERPシステム |
初期処理 |
起動 ログイン |
検索 |
ホーム画面から検索画面へ遷移 検索条件を入力 検索ボタン押下 検索結果表示 |
|
住所変更 |
該当の顧客名を検索結果表示画面で探し出す 見つかった顧客データ詳細を表示 新住所の値をフィールドに書き込み 更新ボタン押下 |
|
終了処理 |
ログアウトボタン押下 画面を閉じる(アプリケーションの終了) |
ひとつのオブジェクトとその中に、4つのアクションページが作られています。
しかも、操作手続きを前提とした処理が、ひとつのアクションページに書かれています。(「検索」とか「住所変更」がそうなってしまってますよね。)
これでは、確かに要件を満たすオブジェクトを実装することになりますが、再利用性が全く考慮されていません。
今後、例えば、
「分析目的で住所を参照するだけの自動化業務」
「顧客一覧から自動的にDMを発送する業務」
などの自動化要件が来た場合に、別のオブジェクト、もしくは別のアクションページを作らなくてはならなくなってしまいます。
では、以下のようにするとどうでしょうか。
オブジェクト |
ページ |
操作内容 |
ERPシステム – |
起動 |
起動 |
終了 |
画面を閉じる |
|
ログイン |
ログイン |
|
ログアウト |
ログアウト |
|
ERPシステム – |
検索へ遷移 |
ホーム画面から検索画面へ遷移 |
ERPシステム – |
検索実行 |
検索条件を入力 検索ボタン押下 |
ERPシステム – |
結果リスト取得 |
検索結果表示に表示された一覧情報を画面から読み込む |
顧客詳細へ遷移 |
検索結果表示画面上に表示された任意のレコードの詳細表示画面へ遷移するボタンを押下 |
|
ERPシステム – |
詳細情報表示 |
表示された顧客データの詳細情報を画面から読み込む |
詳細情報更新 |
表示された顧客データの詳細情報について、呼び出し元プロセスから渡された値を画面へ書き込む 更新ボタン押下 |
最初の表と内容を比べてみて下さい。
“うへー、オブジェクトの数が5倍じゃん!”って思いますよね。。。
ですが、やっていること=操作内容のステップの合計の数は同じです。
オブジェクトとページを細分化しただけです。決して、これで初期開発工数が増大したわけではありません。
反対に、再利用性は格段に上がっています。
(メモリなどのリソース消費効率性も、個々のオブジェクトが小さくなる分、上がっています。)
(チーム作業・作業分担もし易くなります。あなたの双肩にすべてがのしかかることも回避できます!)
「分析目的で住所を参照するだけの自動化業務」
「顧客一覧から自動的にDMを発送する業務」
が将来、あなたにやって来たとしても、これらオブジェクトをそのまま使って、新たなプロセスを構築することができるはずです。
Blue Prismを選んでよかった、と思う瞬間です。
さて、じゃあ、どうやるか。
自動化対象業務プロセスの洗い出しとAsIsの業務フローが書けたなら、いきなりBlue Prismのスタジオに向かうのではなく、Excelのスプレッドシートに、アクションステップをすべて書き出してみて下さい。
対象とするアプリケーションに対するアクション(操作内容)を書き出すだけです。
そこには、ロジックや条件はいりません。
書き出せば、オブジェクトとページの整理ができるはずです。
「設計」というと仰々しいですが、「画面とアクションのリストアップ」だったら簡単ですよね。
この程度で良いんです。(=これがオブジェクト設計です! これがオブジェクト設計書になります!)
オブジェクト設計書を作る、作らない、とで、「Blue Prismらしさ」の度合いが全く変わってきます。
検索関連処理、メニュー関連処理は少々トリッキーですが、基本的には、Javaのメソッドと同じような考え方で、あるひとつの画面やデータの塊に対して「SetXXX()」(つまり入力・更新系)と「GetXXX()」(つまり取得・読み込み系)の組み合わせがひとつのオブジェクトになる、とすればシンプルに設計できます。
実際は、これらに加えて、「Attach」や「前画面に戻る」「メインメニューに戻る」などが加わると思います。
アプリケーション画面上で指定する内容や値は、パラメータ化して、プロセス側から渡すようにします。
オブジェクトのデータアイテムに初期値で書いておく実装はダメです。
ですので、オブジェクトのアクションページのInput、Outputのパラメータも設計時に定義するようにしましょう。
オブジェクト設計書がExcelのスプレッドシート、セルに収まらないようであるならば、それはベストプラクティスに沿っていないと思って下さい。
まとめ
読者の皆様のプロジェクトや自動化案件の中で、
- 似たようなオブジェクトが増えていませんか?
- それを回避する為に、ひとつのオブジェクトの中に大量のアクションページが含まれていませんか?
- いくつかのアクションページは似たような処理が実装されていませんか?
- それを回避する為に、あるアクションページの中で、他のアクションページを呼んでたりしませんか?
これらは、全部、バッドプラクティスです。
気を付けましょう。
取り敢えず、プロセスとオブジェクトを親と子の関係ぐらいの絡みで役割分担して作ったりしていませんか?
取り敢えず、先ずはHappy Pathで動けばいいや、と、自分のプロセスと絡むオブジェクトだけを作り始めていたりしませんか?
これらも、全部、バッドプラクティスです。
断言します。
Blue Prismを選んだ人は、後先を考えて、RPA製品を選定した方々です。
Blue Prism以外を選んだ人は、目先の。。。あ、失言でした。
実装する際も、後先を考えて、ちゃんと設計しましょう。
オブジェクト設計さえしっかりできていれば、プロセス設計なんて楽なもんです。
オブジェクト設計が出来ちゃえば、先にオブジェクトだけ、だぁーっと作っちゃうのも良いでしょう。
プロセス設計については、次回(↓)、解説します。