・RPAシナリオ設計の概要は理解できた ・RPAシナリオ設計書を作成したい ・「業務の構成要素を記述する」はクリアした
という人に向けて、RPAシナリオ設計書を作成する第2ステップ「業務シナリオを記述する」について解説します。
本記事は次の記事の一部となっています。
それではどうぞ！
業務シナリオを記述する【RPAシナリオ設計】
業務の構成要素を把握してドキュメント化したことを前提に、次のステップである「業務シナリオの記述」について解説します。
図1が業務シナリオのフォーマットです。Excelで作成しています。
【図1】業務シナリオのイメージ
業務シナリオ上部の業務構成要素は前項で解説しました。「基本シナリオ」以下の書き方を解説します。4つのステップで完成させます。
(2) 参照を記述する
(3) 代替シナリオを記述する
(4) 例外シナリオを記述する
1つづつ解説するよ
基本シナリオを記述する
基本シナリオには5つの項目があります
(2) アクション
(3) 参照
(4) サブプロセス
(5) 業務プロセス
業務を行っている本人が、［アクション］列に現状行っているアクションを箇条書きします。その後、ステップに番号を振ります。
アクション列には以下の決まりを守って書きます。
(2) 基本シナリオには分岐する処理は書かない
アクション列の決まりも1つづつ解説するよ
(1) 1行には1つのアクションのみを書く
「RPAシナリオ作成のために業務の構造を理解しよう」で例として使用した「売上集計表配信業務」の［ログイン］サブプロセスの基本シナリオを書いてみます（図2）。
【図2】［ログイン］サブプロセスの基本シナリオ
まだ［参照］や［サブプロセス］は書きません。ステップの最後は「終了」で終わります。
(2) 基本シナリオには分岐する処理は書かない
基本シナリオには正常に作業が行われていた場合のアクションのみを書きます。
例えば、［ログイン］サブプロセスでは、次のような場合はログインに失敗します。
(2) システムの不具合で利用できない
この場合ログインに失敗し、ステップ5のアクション「お知らせ画面で［読みました］をクリックする」は実施できません。
しかし、基本シナリオにはステップ5のアクションが必ず実現できるものとして記述します。
参照を記述する
「基本シナリオを記述する」の解説が終わったので、次のステップだよ。
画面イメージ図があると、当業務を知らない人との情報共有が容易になります。
文字だけの情報より格段に多くの情報が伝えられますからね。
Excelファイルにシートを追加して図3のように画面イメージをキャプチャーして貼り付けま
す。図に番号を振り、シート名に「図1」と名前を付けておきます。
【図3】ログイン画面の図
［業務シナリオ］シートを開いて、［参照］に［図No. ］を記述します（図4）。
ハイパーリンクを付けておくと、さらにいいですね。
【図4】［ログイン］サブプロセスの基本シナリオ
代替シナリオを記述する
「参照を記述する」の解説が終わったので、次のステップだよ。
「代替シナリオ」には基本シナリオが成功しなかった場合のアクションを記述します。
「例外が発生した」状態なのですが、例外に対応する方法が用意でき、基本シナリオに復帰できることが代替シナリオを使うときの条件です。
［ログイン］サブプロセスの例で解説します。
ログインに失敗した場合は、お知らせ画面に画面遷移しません。
ログイン画面に留まったまま、エラーメッセージが画面上部に表示されます。
基本シナリオのステップ2「ユーザーIDを入力する」に戻り、ログインをリトライします（図5、6）。
ステップの番号の付け方は、ステップ5に対する代替シナリオなので、「5a」と付けます（ステップに5に対して2つ目の代替シナリオがあれば、「5b」と付けます）。
「5a 」の中のステップが複数ある場合は図のように「5a1」「5a2」…と採番していきます。
【図5】［ログイン］サブプロセスの代替シナリオ
【図6】ログインエラーの図
例外シナリオを記述する
「代替シナリオを記述する」の解説が終わったので、最後のステップだよ。
代替シナリオだけでは、問題が解決しない場合があります。
引き続き、［ログイン］サブプロセスを例に解説します。
ステップ1からスタートし（図7①）、基本シナリオのステップ5で失敗すると、代替シナリオのステップ5a1に移動します（図7 ②）。
代替シナリオのステップ5a2から基本シナリオのステップ2に戻って（図7 ③）、再びステップ5までアクションが実行されます。
そこで、また失敗したら…永遠にログインを繰り返すことになります。
【図7】［ログイン］サブプロセスの永久ループ
これを「永久ループ」と呼びますが、実際の業務でこのようなことはありません。何度
か失敗したら、あきらめて業務を中断します。
このように、最終的に業務のアウトプットを生成できない例外が発生する場合は、「例外シナリオ」に記述します。例外シナリオは基本シナリオには復帰しません（図8）。
【図8】［ログイン］サブプロセスの例外シナリオ
ステップの採番も「5a1」に対する例外なので「5a1a 」とします。さらに連番があるので「5a1a1」「5a1a2」…とします。
全体の流れを追っていきましょう。
ログインに失敗したら（図9②）、ステップ2に戻ります（図9③）。数回トライしても失敗するならば（図9④）、ブラウザーを閉じて業務を終了させます。
終了は基本シナリオのステップ6にもありますが、業務の終了はこのステップとは異なります。
基本シナリオのステップ6の「終了」は正常終了ですが、例外シナリオは異常終了を表します。
【図9】［ログイン］サブプロセスの流れ
業務シナリオの検討・修正を行う
業務シナリオ完成しました！
では、業務シナリオ作成後に行うことを解説します。
業務シナリオを整理したら、一枚の紙に印刷して業務の関係者と共有します。
自動化の知識が豊富な人とも共有しておいた方が、後に自動化する際に有用なアドバイスが得られるでしょう。
検討の結果、修正が必要であれば業務シナリオを改修してください。検討するのは以下の3点です。
(2) 発生し得る例外が網羅されているか
(3) 全体のアクションが長すぎないか
これも、1つづつ解説するよ
内容が正しいか
全員が読んで文章の意味がわかるかということから始めます。
文章の意味がわかったところで、以下の点をチェックします。
(2) インプットとアウトプットが業務の構成要素と合っているか
(3) 関連するデータやドキュメント、情報システムが漏れなく記述されているか
発生し得る例外が網羅されているか
例外が網羅されていない場合、信頼性の高いシナリオを開発できません。
また、例外に対する代替シナリオと例外シナリオが、適切に記述されているかどうかもチェックします。
例外が多すぎることも問題です。
分岐したシナリオが増え、業務シナリオが複雑化します。例外の発生条件に誤りがないか、事前に例外の発生をなくすシナリオを入れられないかを検討します。
全体のアクションが長すぎないか
業務シナリオで紹介しているフォーマットはA4一枚に業務シナリオが収まるように設計しています。
基本シナリオは20ステップ、代替シナリオは15ステップ、例外シナリオは10ステップです。
基本シナリオ、代替シナリオ、例外シナリオのステップ数の割合は変更してもかまいませんが、3つのシナリオを合わせて45ステップを目安にしましょう。
もし収まらないとしたら、業務として複雑すぎるかもしれません。実務者が設計して開発するのには不向きです。
複数の業務が混在しているケースもあります。もう一度、「インプット⇒処理⇒アウトプット」の構造を整理してください。
まとめ
業務シナリオを作成する手順を解説しました。
図10が業務シナリオのフォーマットです。
【図10】業務シナリオのイメージ
業務シナリオを作成する4つのステップを解説しました。
(2) 参照を記述する
(3) 代替シナリオを記述する
(4) 例外シナリオを記述する
業務シナリオを整理したら、業務の関係者とチェックしましょう。
(2) 発生し得る例外が網羅されているか
(3) 全体のアクションが長すぎないか
わかりました！
関連する記事
RPAシナリオ設計の全体をまとめて読みたい方は書籍をご購入ください。
RPAシナリオ設計をまとめた記事です。
RPAシナリオ設計のために業務の構造を理解しましょう。
