「RPAツールでロボット作る際に決めておくべき開発ルール」について書いていきたいと思います。
・RPAのツールでの開発とかよくわからないけど何を準備すれば良いの？
会社で「他社では効果が出ているみたいだから、RPAを導入することになったので、よろしく頼む！」なんて言われて困っていると相談受けることが時々あります。
結果、ご自身でもきちんと理解しないまま頑張って導入してはみたものの、無事ロボットが動き出した後から、いろいろな不平・不満を寄せられて困っている人も少なくありません。
新聞や雑誌では「RPAは短期間で導入が可能で、大きな効果を享受できている」なんて記事が良く出ているので、「うちでもやってみよう！」ということで取り組んでいる企業も多いです。
しかし、苦労して導入はしてみたものの、いろいろ問題が発生しているようです。
- 何もロボット変えていないのに、ロボットが突然動かなくなった
- 同じことを操作している隣の部のロボットは動いているのに、うちの部だけ動かない
など様々です。
きちんと導入すれば効果がでることは間違いのないRPAです。
しかし、どうすればロボットをうまく開発し導入することができできるのでしょうか。
そのノウハウとして「RPAツールでロボット作る際に決めておくべき開発ルール」についてご紹介していきたいと思います。
コンテンツ
1.ロボットの構造化設計と部品化
ソフトウェアの開発では、古くは1960年代から提唱された考え方で、
- エドガー・ダイクストラ
- エドワード・ヨードン
- トム・デマルコ
- ジェームス・マーティン
など複数の人物が構造化の分析・設計手法を提唱しています。
その後、時代の流れの中で、呼び名や手法は変われども、基本的な思想に変わりはないと私は思っています。
やはり人が一度に記憶したり、理解したりすることができる量や範囲には限界があります。
そのために必要なことが構造化という分析・設計の考え方です。
一つ一つのブロックを機能単位に分かりやすく切り出して、ブロックの中身はシンプルなものに作っていくことが重要です。
このように作られたブロックをいくつか組み合わせて共通して使えるようにしたブロックのことを“部品“と言ったりします。
最近だとマイクロサービスという言葉をよく聞かれるかもしれませんが、多少異論がある方もいるかもしれませんが、広くには似たような考え方です。
＜図 ロボットの部品化の考え方＞
例えば、
- 会計システムにログインする
- 特定のデータベースからデータをダウンロードする
など、日々の業務の中には、社内で多くの社員が共通して行っている業務がありますよね？
そういうものをあらかじめ特定して、皆が共通して使えるように“部品”として用意しておきます。
皆が同じような業務の処理をロボットのプログラムを思い思いのやり方で開発していくよりは、すでに動くことが検証されているロボットの部品を繋ぎ合わせてロボットを作れるのであれば、その方法の方が効率的にロボットを開発できますよね？
例えば、先の例のように会計システムのログインの画面が変わってしまったらどうでしょう？
1,000人の社員が全社で会計伝票処理のロボットを開発して、皆が思い思いに会計システムのログインの処理を開発していたらどうなるでしょう。
極端は話、同じことを操作しているのに、中身が異なる1,000体のロボットができてしまいます。
つまり1,000のロボットの中身を一つずつ確認して中身を直さなければなりません。
一方で、会計システムのログインの画面の処理を部品にしていたらどうでしょう？
ロボットの部品を一つ直して差し替えればおしまいです。
このように部品化して皆で共用することは、ロボットを開発する時も保守で変更をしたりするときも、その手間や品質の管理という点で極めて重要な意味を持ちます。
2.テンプレートロボットの準備・利用
部品の考え方に似たものです。
会社で処理する業務は似たようなパターンに分けることができると思います。
例えば、
- データベースからデータをダウンロードして、報告用の資料を作る
- 各部門から提出されたデータをもとに、部門全体で集計する
- 申請されたデータをもとに、他のシステム（例：会計システムなど）にデータを登録する
など、典型的な処理があると思います。
このような一定のパターンの処理のひな型をあらかじめ準備しておきます。
これをロボットのテンプレートと呼んでいます。
そうすると個人ごとに創意工夫してロボットを一から作らずに、あらかじめ用意したテンプレートを自分の業務の内容に少しずつ合わせて直して使うことで、効率よく開発することができるようになります。
また、同じテンプレートを使うことで、保守する人も中身が共通化され、ロボットに何か問題があってもロボットの変更がしやすくなります。
3.ロボットのコーディングルールの策定
コーディングとはRPAのツールでプログラムを書くことを言います。
コーディングをしなくてもロボットを作ることは可能ですが、ちょっとした業務の処理を自動化しようとするとプログラムを書く必要があります。
“プログラムを書く“というとちょっと敷居が高くなりますよね。
また、知らない人が書いたプログラムだと何が書いてあるのか理解するのに時間がかかりそうですよね？
そのため、誰が見てもすぐにプログラムに何が書いてあるか分かりやすくするためにプログラムの書き方のルールを作るのです。
分かりやすさということの他に、誰でも誤りそうなプログラムの書き方をあらかじめルールで禁止することで、トラブルを未然に防ぐことができるような効果もあります。
英語の勉強を思い出してください。
普通に肯定文で書かれている方が、理解しやすいですよね。
肯定文と二重否定が混ざって出てきたらどうでしょう？英語に不慣れな人は困難しますよね。
具体的には、ロボットでデータを処理する時、データを格納するために変数といってデータを格納するための項目を定義する場合があります。
数式でいうと、Y=２X＋１という式のYとかXになり、それぞれに名前を付けていきます。
例えば、日付を入れる項目で、ある人はDate、別の人はXYZとつけたりしたらどうでしょう。
Dateと書かれていれば、ここには日付のデータが入っているのだなと想定が付きます。
XYZと書かれていると、その中身を一つ一つ確認しないとXYZが何を意味しているか分かりにくいですよね？
そのため、名前の付け方などにルールをつけて、後からロボットの中を見た人が簡単にどのようなことをしているのか分かるように共通のルールを作ります。
他には、
- ロボットのプログラムに日本語でコメントをつける
など、細かいルールを作っていきます。
コメントをつけるとは、プログラムの命令でどういう処理をしているのか、日本語で解説を書くことができます。
パッと見た時、プログラムのコードの羅列よりは、日本語で解説が書いてあれば、「ここではこんなことしているんだ」と、すぐにあたりをつけることができますよね。
他の人が作ったロボットで何かトラブルがあったり、変更しなければならなくなったりした時など、なるべく簡単に中身が理解できたほうが良いですよね？
そのために、ロボットの中のプログラムを書き方とかのルール付けをしておくことが重要になります。
4.ロボットの開発・動作環境の標準化
会社にもよりますが、Windowsやオフィスツールのバージョンが統一されているなどパソコンの環境が標準化されているケースが多いと思います。
しかし、会社によってはパソコンの環境が、部門や工場などで少しずつ違う会社もあったりします。
バージョンは同じでも、ソフトウェアが導入されているフォルダーの場所や名称が違ったりとかする場合があります。。
このような場合、Aさんのパソコンで作ったロボットをそのままBさんのパソコンで動かそうとしても、少しずつパソコンの環境に合わせてロボットを変更しないとそのままではロボットを動かすことができなかったりします。
そのため、ロボットの作り方だけではなく、ロボットが動くための環境も標準化して、そろえておく必要があります。
5.例外条件への対応
プログラムの処理の仕方をあらかじめ決めてしまい、トラブルをなるべく未然に防ごうという考え方です。
RPAのツールでは、データの内容を判断して、
- データ“１”がきた時は“X”の処理
- データ“２”がきた時は“Y”の処理
などと、条件に応じて実施する処理を変えることができます。
ロボットは、データが“１”の場合、データが“２”の場合は想定しておりますが、データ“３”の場合を知らなかったらどうでしょうか？
人であれば、自分で判断して知っていそうな人に聞くなどして対応することは可能かもしれませんが、ロボットは教えられていないことには対応できません。
つまり、“１”と“２”のデータしか来ないという場合でも、常に“１”と“２”以外のデータが来た場合はこういう処理をするというルールを決めておきます。
例えば、想定外のデータがきたことを担当者にメールする等です。
ロボットを開発する時に業務の担当者にヒアリングすると、担当の人は、「絶対に“１”と“２”のデータしか来ません」と教えてくれます。
しかし、ロボットを設計して作るときは、必ず“１”と“２”以外のデータが来るような特殊な場合への備えも用意してください。
このあたりを事前にロボットに教えておいてあげないと、想定外のデータが来てしまった場合、想定しないことをロボットが始めてしまったり、思考停止してしまったりします。
結果、会社の情報システムの中に想定がのデータが登録されてしまったということも時々発生しています。
6.まとめ
RPAのツールでロボットを開発した後は、開発した人以外の人がプログラムを直したりすることが常となります。
よって、誰でも分かりやすいプログラムの書き方をすることが重要となります。
そのために、標準化などのルール付けが必要となります。
せっかくロボットを作ったのに、ちょっとしたトラブルへの対応や軽微な変更ができずに、ロボットが止まってしまうことも時々聞きます。
結果として、せっかく作ったロボットが動かないからと放置されて、無駄になることも少なくありません。
ちょっと面倒かもしれませんが、あらかじめロボットが動いた後のことも考えた備えをしておくことが必要です。
あらかじめきちんと考えて備えをした上で導入すればそれほど難しいことではありませんよ！
