RPAを作成すると、必ず「もしもRPAが動かなくなったらどうするの？ちゃんと仕様書を残しておかないと。○○さんがいなければ直せないのでは意味ないからね」という人がいる

これは正論である

但し、これはこれまでのシステムとは事情が違う。何故かというと・・・

１．RPAのメリット

これまでのシステムと違って、RPAは開発・修正が容易なのがメリットである。ということは、多くのケースで仕様書を書いている時間の方がRPAを開発・修正より多くの時間を割くことになってしまう。つまり仕様書の作成に時間をかけすぎるとRPAのメリットが薄れてしまう

２．RPAの対象業務の特徴

RPAの対象業務は、これまでのシステム開発の対象だった業務より単位が細かく、且つ、より現場に近い。よってRPAは開発した後も修正が様々な形で起こる可能性がある。ある時はRPA操作対象のアプリケーションが修正された・・・ある業務手順の考慮が欠けていた・・・、やっぱりああしたい、こうしたい・・・などなど様々な修正が起こる可能性がある。そのたびに仕様書を修正したいたら時間が無くなってしまう

上記に付け加えて、RPAが扱うアプリケーション、RPA機種、対象業務の分野・レベルの組み合わせによって事情が違うので、”これだ”という解決方法を述べることは現実的ではないが、仕様書を補完するヒントになると思えることは以下に羅列していきたい。

１．RPAシナリオ自体を仕様書にする

＊以下、Uipathを想定して記述

➀シーケンス（箱）を構造化しておく

　箱の見出しを見れば何のシナリオが書かれているかを分かるようにしておく

②Activityの見出しをきちんと記入しておく

そして、一番おすすめが

③コメントを丁寧に記入しておく

２．動画を活用する

RPA導入前とRPA導入後の業務の動画を撮っておく

１にも通じることだが、細かいことより、RPAシナリオによって何をしたいのかを分かるようにしておくのが、とても重要です

これは仕様書で細かい事を書いてある場合も一緒です

何故なら事情が分からない第三者がRPAシナリオを見たときに、細かいことを見てもあまり響かない、もしくはピンと来ないからです

逆な言い方をすればRPAの場合には直感的なもののほうが分かり易いはずです。スマホを最初に操作した時を思い浮かべてもらったほうが良いかもしれませんが、”何をしようとしているか”が理解できれば何とかなるものです

後、動画をとっておくと、万が一、RPAを当分動かせない時に動画をまねすれば業務を再現できる可能性が高くなります

３．１と２でカバーできそうにない箇所を画面コピーする

繰返し条件や分岐処理の条件設定など少し複雑で第三者に分かりにくいものはシナリオの該当箇所のコピーをエクセルに貼り付けたりした上で、コメントを添えておくといいでしょう

以上、自分なりの経験から回答になりそうなものを３つ羅列しましたが、仕様書の問題は本当に重要かつ解決が難しいと思います。ただ最後に言えるのは、RPAシナリオの各部分で何がしたかったのか？これを分かるようにしておくこと、これが最重要だと言うことです。この点を外さなければ何とかなるだろうとは思っています。

最後まで読んでいただきありがとうございました

にほんブログ村

　爆発的にRPAが拡大しています。2018年はRPA元年と言っても過言ではないと思います。但し、当初と目論見が違った、目測を誤ったなどの体験をされた方も多いと思います。そんな”当初の○○と違った”というあるあるを自分の推測も入りますが、まとめてみました

１．RPAを導入したら人は要らないよね？

　経営者の方に多いと思いますが、RPAを導入したら、”人が要らなくなるので人の行き場に困る”、と悩んだ方もいらっしゃるのではないかと思います。

　実際には、RPA開発者を増やすなど、逆に人の頭数が増えたケースすらあるのではないかと思います。

RPAの効果は導入業務の種類、または対応の仕方で効果の出方が大幅に変わるので、現実的には”人が要らなくなるケースもある”ということにとどまるものだと思います。それよりRPAの導入目的をどこに置くのかが一番問題なのだと思います。

　敢えて付け加えるとRPAを起動させる人はどうしても必要です（やり方次第でそうでないケースもありますが・・・）。

２．AIと違うの？

　RPAとAIを混同される方がいますが、RPAとAIは違います。但し、新しいテクノロジーとして同じカテゴリーで話されるケースもあると思いますが、厳密には全然違います。重要なのはRPAとAIをどう連携していくか？ということに尽きます

３．RPAは止まらないよね？

これは止まります。RPAのデモで動画を準備している方も多くいらっしゃいますし、動画のみでデモすると割り切っている方もいらっしゃると思います。重要なのはエラーを防ぐ（止まらないようにする）努力と起こってしまった時に回復する仕組みの構築です

４．RPAはユーザー（システム部門以外）で開発できるよね？

これはできるということもできます。開発する内容、そして選択したRPAとの相性次第になります。後、もちろんユーザーの質も影響します。ただ総じていうと難しいと言わざるおえないとは思います「この○○RPAはユーザーが開発できます」という触れこみのセミナーにも参加したことがありますが、セミナー開発会社が社内で行ったであろう啓蒙活動や教育活動は他の会社でできるとは限りません。但し、ユーザーがRPA開発するのは究極的な理想形ではあるので、SEとの協業、融合を追い求めるのは当然の流れになるかとは思います

５．RPAは業務が人より早いよね？

これも業務によります。そしてRPAのシナリオにもよります。私の場合には業務自体を再構築しつつ、エクセルマクロと組み合わせてなるべくスピードアップする努力をしています。RPA機種によるとは思いますが、RPAにエクセル処理をさせると人間より遅いと感じることもあります。当然、エクセル内の処理はエクセルで行った方が早いので、スピードを意識する場合、どうしてもエクセルマクロとの連携は重視せざるおえません

以上、思いつくまま羅列しましたが、続編を書くことがあるかもしれません

最後に、どんな”あるある”が生まれてこようとRPAと人間の協業の流れは止まることはないと思います。長文でしたが、最後まで読んで頂きありがとうございました。

にほんブログ村

前回、RPAの導入は特定の業務に照準を合わせて進めたという話をしたが、その時の苦労について書いていこうと思う

恐らく、どこでもRPAを導入する際に苦労するのは、どうやってRPA対象業務の内容を理解するか？だと思う

中には今までシステム開発の時に行っていた業務ヒアリングと何が違うの？と思われる方も実際にいらっしゃったが、次のようなことを想像してみて欲しい

「今、自分が行っている業務を１から１０まで全部、正確に話してくれ」

と、いきなり自分が聞かれたらどう説明をするか？

「業務の単位はどの単位で話したらいい？」「あの件まで話すのか？」

意外と混乱すると思う

RPAの場合は今までシステム化対象だった業務より細かい内容である。

しかも、今までなら最悪、人間にシステムへ業務を合わせてもらえばいいが、RPAの場合にはそうはいかない

だからユーザーに対して蝕知定規な聞き方をすると「１から１０まで全部説明して！」となってしまう。

そうは言ってもRPA化の対象となる業務の担当者だからヒアリングを行う時間も十分に取れないし、業務も整備されていないケースが多いので系統立てて説明する術も持ってはいない

ましてやRPAを初めて導入するとなると、現実的に考えて説明はしてくれない。どこか時間を短く切ろうとしながら話してくる

だから、最初に導入しようとした時には焦りばっかりが募り、虚しく時間ばかりが過ぎて言ってしまった。

そんな時に考えたのが次の様なことだ

「とにかく10のうち２で走り始める」

ということだ

詳細は次回、また書きたいと思う

にほんブログ村