Enterprise Blue Ocean ◮

神谷町RPAブログ

  • Blue Prism 初級者向け
    • Blue Prism を 無料で利用する 方法はこちら
    • Blue Prism の Blue Prism 事始め!オンボーディングの記事はこちら
    • Blue Prism で Excelを操作 する記事はこちら
  • Blue Prism、ちょっと進んだコンテンツ☆
    • Blue Prism の ベストプラクティス 記事はこちら
    • Blue Prism の 逆引きナレッジ wiki こちら
    • Blue Prism を リアルタイムで起動する 方法はこちら
  • RPA、そもそも論!
    • Youtube で、あらためて振り返る RPA とは?・・・はこちら☆

Blue Prismベストプラクティス<番外編②> 「Blue Prism World London 2019」でも言っていたこと。

ども。久々の「ジャナイホー」です。

ジャナイホーも Blue Prism World London 2019 に行ってきました。

 

、、、しかし、あれですな。

Londonでは、夜中の3時頃に目が覚めてしまい、朝食前まで仕事をしてしまうという残念な時差ボケを食らい、日本に帰ってきたら帰ってきたで、今度は夜から朝方まで悶々と眠れない、でも夕方まで常時眠い、という、時差ボケを食らう、という。。。

そんなこんなで時差ボケの中、ちょうどLondonでエイプリルフールを迎え、その夜中?明け方?に官房長官がドヤってたのが天下のBBCに流れてました。

f:id:EnterpriseBlueOcean:20190413021714j:plain

Reiwa on BBC

 

それでも一週間仕事でなんとか戻してきました。ので、少し書こうかと思いまして。

 

別記事でちゃんとした人がちゃんとしたレポート↓

ebo.hatenablog.com

をやっていますが、その記事にある以外にも、Learning Sessionという形でいくつか小ネタを会場隅の登壇ステージでやっていました。

これはたいていが、Blue Prismの社員の発信で、中にはここでお知らせしたいものがあるのでご紹介します。

 

一つ目。

【BEST PRACTICES FOR BUILDING PROCESSES】

文字通り、このシリーズと同じ内容。

イギリス本国のコンサルタントも同じこと言ってたよ、ということです。当たり前ですが。

しかし、二日目の朝8:00からやるかなー。時差ボケだから行けるけど。やはり観客は少ない。。。

ここでは、サマリーだけお伝えします。

f:id:EnterpriseBlueOcean:20190413021833j:plain

オブジェクト
  • 大きくてたくさんのページがあるオブジェクトになるような設計は回避しなさい 
    (そもそも「設計しない」という概念が無いです)
  • ひとつのページの目的をシンプルに、機能的にしなさい 
    (ほらね)
  • オブジェクトの構築とテストは同時に行いなさい
  • 1つ、2つのページごとに止まって、テストプロセスを作ってテストしなさい 
    (つまり、一気に大量のページやオブジェクトを作り切って、単体テストを纏めて行う、というのではなく、作っては都度テストし、テスト完了したらしたら次のページ、オブジェクトを作る、というように小さな単位でAgileに近い感覚で構築を行いなさい、ということです)
  • 確実性・信頼性を上げる為に、開発途中では同じデータでのテストを繰り返しなさい
  • 動きに矛盾が無いことを証明する為に、違うデータセットでのテストも必ず行いなさい
  • 回復性があること検証するように、不正なデータを用いてテストしなさい
    (どんなテストデータを用意するか、は結構重要です。センスが要ります。これ次第で、オブジェクトのバグ発生率含めた品質に差が出てきます)
  • プロセス構築フェーズでの作業を煩雑・複雑にしないようにするために、機械的に発生するエラーを極力少なくしなさい
    (これはつまり、ロジックを排除して排除していくことを目指せ、ということになるかと思います)
プロセス
  • テンプレートと Work Queueを使いなさい
    (ほらね)
  • ケルトン(骨格のみのからっぽの)プロセスを動かすところから始めなさい
  • 最初に、対象アプリケーションの起動、終了、再起動だけを行うスケルトンでテストしなさい
  • 1つのサブページを作ったら、テストを実施して、実施しきって、次のサブページの開発に移りなさい
    (これは、一度に一気に作り切ってからやおらテストするのではなく、一つのシンプルな機能ごとに作ってはテストし、を繰り返すようにせよ、ということです。これにより、エラーが発生したら、エラー発生個所は、直前に作ったところに限定できるはずなので、問題の特定と修正が効率的に行えます。一気に作り切ってから、テストを一気通貫で行うと、最初にエラーが発生した際に、さて、どこでエラーが発生したのかね、と探しに行かなくてはなりません。場合によっては、途中でブレークさせたり、終了させたりしながら、問題個所を探すことになります。そのエラーが解消できてもう一回流したら、次はその直後のところでまたすぐエラーが。。。マジか。今日はもう寝よう、となります。)
  • ハッピーパスはもちろん、アンハッピーパスもそうですし、想定外のエラーがそこかしこで発生することを想像してテストシナリオを考えなさい
  • どのシナリオはテストしたのかをしっかりと記録して、逆に、テストしていないシナリオ、想定外のシナリオを見つけ出すようにこころがけなさい
    (回復性を究めて、想定外のエラーでプロセスがTerminateしないよう、業務が続けられるように、ハンドリングを入れましょう)

【まとめ】

かれらの朝は早い。時差ボケは無くても。

ベストプラクティスは、万国共通。

令和も、万国共通。(多分。。。)

 

ジャナイホーによるLondon二つ目のレポートは、「アップグレードについて」です。ベストプラクティスとはちとずれますので、シリーズとは外して掲載します。