Blue Prismベストプラクティス 設計編 2 プロセスの分割と設計（前編）
今回は、設計編 2 プロセスの分割と設計（前編） です。
プロセス設計
これまで、オブジェクトで実装すべきもの と オブジェクトの設計についてご紹介しました。しつこいですが、大原則を再掲します。
ロジックは、オブジェクトには実装しない。
ロジックは、すべてプロセス側に実装する。
です。
ここでは、ひとつの自動化対象業務を、どうBlue Prismのプロセスに落とし込んでいくか（＝プロセス設計）、についてお話したいと思います。
プロセス設計と言うと、大きくふたつの要素で構成されます。
一つ目は、あるひとつの業務手順をどんな形でBlue Prismの１プロセスの実装に形をかえるか、です。設計書で言う「Process Design Instructions」（PDI；プロセス設計書）にあたります。
二つ目は、複数のあるいは長大な業務フローをBlue Prismのいくつのプロセスに分割して、どんな構成で実装するか、です。設計書で言う「Solution Design Document」（SDD；ソリューション設計書）にあたります。
通常の設計フローの流れで言うと、
SDDで全体構成を設計して、
それを受けてブレークダウンした個々の１プロセスをPDIで設計する、
という手順で設計内容を落とし込んで（詳細化して）いきます。
、が、今回の記事では、より分かり易く話を進めるために、また、読者の皆様が目の当たりにする頻度がより多いであろう、PDIの領域のお話を記載します。
プロセスの設計：流れを五分割する
「業務を自動化したい」という話になった場合、通常ある一人の方がやっている業務をイメージ化すると、ばっくりとこんな形になると思います。
開始して、なんか処理を行って、最後、終了、ですね。
で、よくよく話を聞くと、最初にやることと、最後に常に行うこと、ってあると思います。
すると、初期処理、コア処理、終了処理の三つに分割されます。
で、たいていの場合は、「自動化したい」って言ってるんですから、複数の大量ボリュームのデータをせっせこ処理しているんだと思います。そうすると、同じ処理手順を違うデータで繰り返しているのでしょう。
こんな感じで。
もう一つ、その人に聞いてみてください。
「入力データに誤りがあったときとか、特定の箇所でエラーが起きた時って、どうしてます？」
まさか「いや、もうその日の業務はそれで終わり。帰る。なおるまで再開しない。」ということは無いと思います。
「飛ばして、次のデータの処理を続行します」とか「ITか入力元に直してもらって、最初に戻って再開します」というお話が聞き出せると思います。
つまり、これは、エラー回復の手順が行われているわけですね。
ひとつの業務手順がこの五分割まで行ければ、もうあとは簡単です。
1. 初期処理
2. コア処理
3. 正常時繰り返し
4. エラー回復
5. 終了処理
この図、どこかのイメージとデジャブではありませんか？
そうです。Blue Prismの標準テンプレートの形と一緒です。
この2～4の繰り返し処理を司るのが、Work Queueになります。ですので、どんなプロセスでも、Work Queueを操作するのが必須になります。Excelとループで実現しちゃえばいい、なんて考えないでください。Work Queueについては、別の機会にもご説明しますが、下記の記事も参考にしてください。
Unhappy Path
2、3のコア処理＆正常時繰り返しは、「Happy Path」と言ったりします。
要件定義や設計フェーズでは、この部分のお話をよく聞きこんで、落とし込みがちゃんと行われると思います。
でも、２の途中でエラーが発生した場合、4のエラー回復に手順が移ります。これを「Unhappy Path」と言ったりします。
どうも、皆さん、要件を伝える側も、要件を受けて実装を担う側も、この「Unhappy Path」部分を避けがちで、設計や実装が甘くなることが、多々あります。
特に人間は無意識に上手くハンドリングしてたりしますが、AI連携を標榜しているBlue Prismのロボットでさえ、人間ほど気が利いた回避対応を自然と行うのは、まだまだ遠い先の未来まで待つしかありません。
今は、人間が行っているハンドリングをロボットに教え込んでいくしかないんです。
Blue Prismのロボットで回復性、耐障害性を高いレベルで実現するには、この「Unhappy Path」をどれだけ精緻に設計しきることができるか、が分かれ目になってきます。根気よく実施するようにして下さい。
業務フロー図
五分割された大まかな分類で、業務フロー図に落とし込んでいきましょう。下記のようなイメージですね。
どの範囲を処理のグルーピング化できるか（＝サブページ化）、どのアプリケーションにどのタイミングでアクセスするか、どの画面オブジェクトを利用するか、などが詳細化出来ると思います。
ここまでくれば、標準テンプレートに落とし込むのも簡単です。
まとめ
今回、自動化業務がどのように、Blue Prismのプロセスに落とし込まれるか、シンプルな概念を使って流れをご説明しました。もちろん、現実の業務自動化プロジェクトは、こんな簡単な要件だけではないと思います。もっと複雑でやっかいな要件に対応しなくてはなりません。
ベストプラクティス 設計編 シリーズ、プロセス設計における注意点、考慮ポイントは後編に続いていきます。
※本投稿は、別ブログで掲載・公開していた内容に加筆・修正を加え再掲載しています。