Whyベストプラクティス？
どもども、ジャナイホーです。
先日、Blue Prismのユーザ会＆ユーザ分科会がありました。
非常に内容の濃い、熱いディスカッション、発表がありました。
回を追うごとに、盛況になっていっています。
さてそんな中、
「開発ベストプラクティスって、あったんだね。でも、実際その通りやるのって大変だよね」
というお話があったり、逆に
「ベストプラクティス、やって良かったよ」
というお話もあったり、で、非常に興味深かったです。
これまでの記事でも、シリーズで書いてきましたが、ここで改めておさらいとして「Whyベストプラクティス」を整理したいと思い至った次第です。
端的に言いますと、開発ベストプラクティスは、
ROIを向上させるためにRPAを効率良く開発・運用する
為の手段の一つです。
RPA導入における課題
RPAを導入してみたけれど、イマイチ効果（ROI）が出ない、、、
という声を聞いてみると、こんなことが多いようです。
- ロボットが落ちる。止まる。
エラーが頻発する。リカバリは手作業で最初から全部やり直し。
⇒ 結果、「運用工数の増大を招く」「拡張、拡大に人（開発者）を割くことが出来ない」「利用者の不満増幅」が発生。
- 負荷増大に対応できない。
人が手動で実行している。並列処理による負荷分散が出来ない。
⇒ 「時間どおりに終わらない」「業務遅延リスク増大」「ロボットの有効稼働できず、コスト垂れ流し」が発生。
- 修正の工数が増大。
人が好き勝手に開発。システムの画面一部変更で、すべて作り直し。あちこちで。
⇒ 「実行するたびに、ロボットの作り直し」「引継ぎという言葉を聞くだけでゲロ吐きたくなる」「挙句の果て塩漬け」「導入当初と同じコストが毎月、毎四半期、毎年、発生」「業務の標準化が進まない」
最近ではさらに、こんな話も聞くようになってきました。。。
- 情報漏洩事故が発生
管理統制が取れない。ログ、監査も不正。
⇒ 「重大なセキュリティリスクを発生」
- 基幹システム・業務を止めた
高負荷な処理を行うロボットが無秩序に動いてしまった。未完成のロボットを本番環境でテスト。
⇒ 「業務システムにアクセスできなくなり、業務停止が発生」「復旧に莫大なコストが発生」
脅しじゃありません。マジです。実話です。絶対これからもっと増えます。
怖いですね。ぞっとします。
。。。さて、どうすればいいもんでしょうか。
そこで登場、ベストプラクティス
ロボットが止まる。落ちる
⇒ 耐障害性、回復性を向上させましょう。（安定稼働）
負荷増大に対応できない
⇒ 柔軟かつ拡張し易い実装にしましょう。（柔軟性・拡張性）
修正の工数が増大
⇒ 再利用、共通部品化を促進しましょう。（開発・保守効率）
情報漏洩事故が発生
⇒ 認証・認可・監査を徹底させましょう。（セキュリティと統制）
基幹システム・業務を止めた
⇒ 開発～デプロイ手順を整備しましょう。（品質保証）
言葉で言うのは簡単ですが、実行に移すのは難しい。。。
これらを達成する為の手段が、ベストプラクティスです。
耐障害性、回復性の向上（安定稼働）
具体的にどうするか。
必要なことは、以下です。
- 高度なエラーハンドリング
- リカバリ、原状回復
- 想定外のエラーもキャッチ
- リトライ、再実行
- 自律復旧、続行
下記を参考にして下さい。
柔軟かつ拡張し易い実装に（柔軟性・拡張性）
これはロボットの作りと、スケジュール定義と両面で考えます。
- 並列稼働できるロジック
- 拡張する際にも修正不要な作り
- データボリュームに依存しない
- 無人運転を可能にする技術
ロボットの作りは、下記が参考になるかと思います。
そして、スケジュール定義については、下記が参考になります。
これを支える上でも、プロセステンプレートでの構築が必要ですね。
再利用、共通部品化（開発・保守効率）
そして、一番のポイントです。これですわ。
- 汎用性が高く再利用を促す部品
- 視認性が高くメンテナンスしやすい構造
- 標準化を促すテンプレートの整備
- 変更影響範囲の最小化
- 「アプリケーションは変わる」前提
オブジェクトの作り方。これにつきます。
認証・認可・監査の徹底（セキュリティと統制）
これ、重要だと思うんですよね。。。マジで。
- ロボットの一元管理
- 操作ログ、開発ログの自動記録
- ログイン認証、ログイン履歴管理
- 認証情報の一元化
- 規約文書の整備と徹底
ですので、これ。
開発～デプロイ手順の整備（品質保証）
手順と体制を整備しましょう、という話です。
- 設計書の作成とレビュー
- 設計書に基づいたロボット開発
- レビューチェックリストと相互レビュー体制
- テストアプローチの整備
- デプロイ手順の明確化と記録
。。。記事は未だ無い。
あ、レビューの観点と言う意味では、下記の記事が少しお役に立てるかと。
ベストプラクティスを適用した方々の声
以下のような声を開発者の方々からお聞かせ頂けるようになってきました。
「隣の人が作ったオブジェクトを使えたので、オブジェクトを作る必要が無く、今回は開発・テスト工数が格段に減少した」
「ロボットが安定してきた。ここまで2，3週間、落ちてない」
「他の人が作ったプロセスの中身の視認性が上がり、修正やレビューをしたり、他の人のものを参考にする、などがし易くなった」
「修正するポイントが絞られているので、工数も時間も効率化された」
「再利用が実際に出来たことから、副次的な効果として”他の業務でもこの部品を活用できるかも”と気付くことが出来た」
「”再利用”とか”ボリューム対応”とか、”設計”とか考えて作っていると、個別個別の各タスクの自動化、といった従来の考え方から、全体業務を見直してみる、きっかけとなった」
さすがに「情報漏洩事故を防ぐことが出来ました」とか「基幹システムは安定しています」なんて声を聴くことは出来ないのが残念ですが、ま、これは難しいでしょうね。。。
でも、RPAとは何ぞや、RPAで何を達成したいのか、考えてみて頂くのも良いかもしれません。
まとめ
「ベストプラクティスって大変。メンドクサイ。ここまでやる必要あんの？」と感じると思います。
「最初だし、手っ取り早く効果を出すには、あるいは、エンドユーザに開発を任せるには、ガチガチに縛ってベストプラクティスに則って、なんてやり方、採用できない」という声もあるのも知っています。
でも、今、やらないと、あとで苦労します。あとで問題が出ます。
ロボットが止まりました。落ちました。。。
処理が終わらなくって汗かきました。。。
毎日修正・修正で残業続き。。。
情報漏洩事故が発生。。。
業務停止を引き起こした。。。
あとでいいや、と。本格展開始まるときにしっかりみんなで考えよう。
いやいや。あとでできます？作り直し、できます？
最初が肝心です。最初に少し、苦労しておくと、あとあとで絶対に結果が違ってきます。
RPAのトラブルシューティングで過ごす毎日を送るのか。
それとも、RPA推進委員長として社内表彰される日が来るのか。
それは、あなた次第。
私ジャナイホー、今後は「ベストプラクティスを適用した結果、得られた効果」の声を拾って皆様にご紹介したいと思っています。
また、この「得られた効果」をデジタルに見える化する仕組みが出来ないか、考えていきたいと思います。皆様のお知恵・ご経験を拝借したく存じます。
今後とも、どうぞ宜しくお願い致します。
