タグ別アーカイブ: Uipath

Power Automate Desktop入門~PADの凄さ/ノーコード~

 今回はPower Automate Desktop(PAD)の凄さを、<有名なRPAの「Uipath」との比較>を絡めながら、一部紹介したいと思います

皆さんはRPAというとどんな事をイメージされますでしょうか?

 世の中には「どうして毎回毎回こんなことしなくてはいけないんだろう?でも・・・どうしても必要なんだよね・・・」という業務が存在します

 そんな「必要だけど低付加価値の業務」を、プログラミング未経験者でも削減できるということで登場したのがRPAです

RPAはノーコードなので、プログラミング未経験者でもRPAを動かすシナリオを作成できるというふれこみなのですが、実際にはプログラミングの知識がある程度は必要です

ところが、

PADの場合は本当の意味でノーコードになっています

今回の記事ではPADが「なぜノーコードなのか?」について、実際の事例で解説させて頂きます

インストール&ログイン

サイトにアクセス

 まずは、インストーラーをダウンロードする必要がありますので、下記のURLからMicrosoft社のサイトにアクセスしてください(あくまで2021年12月19日の時点の情報です)

https://docs.microsoft.com/ja-jp/power-automate/desktop-flows/install

上のリンクにアクセスすると下記のような画面が開きます

上の画像の黄色の印の箇所をクリックしてインストーラーをダウンロードします

インストールの実際

以降はYOUTUBE動画をご参照ください

新しいフロー作成(シナリオ作成)

PADにログインしたら、画面左上の「+新しいフロー」をクリックしましょう

次に開いた画面で「フロー名」を入力します

フロー名を入力したら、画面右下の「作成」をクリックします

するとシナリオ作成用の別画面を開けるようになります

シナリオ作成画面

シナリオ作成画面の概要

シナリオ作成画面は3つの構成になっています

画面左➡アクション

画面左にシナリオを構成するアクションが並んでいます

こちらから、シナリオに必要なアクションを画面真ん中にドラッグ・アンド・ドロップします

今回は「入力ダイアログを表示」と「メッセージを表示」を画面真ん中にドラッグ・アンド・ドロップします

画面真ん中➡シナリオ

画面の真ん中にアクションを配置してシナリオを描いていきます

画面右➡変数

こちらは後で詳細を後述します

こちらの変数が今回の記事の大きなポイントです

シナリオ作成

今回はアクション2つをつなげて、アクション1「入力ダイアログを表示」で入力したメッセージを、アクション2/「メッセージを表示」で表示します

下は既に完成しているシナリオです

2つのアクションに「UserInput」という内容がありますが、こちらが前述の変数です

試しにシナリオを実際に動かしてみます

入力ダイアログボックスに「TEST」と入力した後に、メッセージボックスにて「TEST」と表示されます

では、画面右の変数がどうなっているか見て見ましょう

UserInputの右側に「TEST」という文字が表示されています

これは変数:UserInputに「TEST」という文字列が格納されているという意味になります

つまり、2つのアクションにて使われている変数:UserInputを通じて「TEST」という文字列がやりとりされていることが分かります

*ButtomPress~の横にOKが表示されていますが、アクションのボタンが押されたという意味合いになります

これは他の言葉でいい変えると、2つのアクション間(入力・表示)で手紙がやり取りされているようなものです

そして、この手紙の中味である変数は名前の通り、内容を変えることができます

では、もう一度シナリオを動かしてみます

今度は入力ダイアログボックスに「テスト」と入力してみます

すると、変数:UserInputには「テスト」が入力されています

変数の設定

では、上記のシナリオ内では変数はどのように設定されたのでしょうか?

変数の設定についてみてみましょう!

下の画像は、1つ目のアクションの「入力ダイアログを表示」をクリックして中味を開いた時の画像です

このアクションでは変数が自動的に作成されています

この変数が自動的に設定されるところが、このPADの凄さです

では、2つ目のアクションをみてみましょう

表示するメッセージの欄に「%UserInput%」と入力されています

何故「%」にてUserInputが囲まれているかというと、文字列のUserInputと区別するためです

%を入力するのは面倒だと感じた方もいらっしゃるかと思いますが、こちらは既に作成してある変数が選択できるようになっています

{x}をクリックすると既に作成されている変数が表示され、変数の選択が行えるようになります

この「変数の自動作成」から、「変数の一覧表示・選択」する仕組みが、PADが画期的な点なのです

この仕組みならば、変数に関わる作業が省力化されているだけでなく、本来はプログラミングの肝の一つであり、未経験者が躓きやすい「変数」の概念が理解し易いのです

これが私が言う「ノーコード」という意味です

別のRPAのUipathにて同じシナリオを作成する場合には、変数を設定しなくてはなりません

ですので、他のRPAでは「変数とは何か?どういう役割なのか?」を理解するところから始めなくてはなりません

PADでは変数に関わる作業が省力化されているだけでなく、変数の概念も理解できるので、まさに一石二鳥なのです

<まとめ>

RPAは慣れると、自転車を乗るようにシナリオを作成できるようになります

RPAに慣れるまでに障壁が何個かあるわけですが、まず最初に躓きやすいのが「変数」の箇所だと思います

もし、これからプログラミングを学ぼうと考えている方は、PADから始めるのもいい手かもしれませんね!


にほんブログ村

RPA・便利技2

エクセルからデータを読みこんでRPAを動かす、これはもう定番の技術といっていいでしょう(ちなみに以下はUipathを想定しています)

エクセルファイルを開き、セルを読み込み、読みこんだデータをWebサイトなどに入力する

この一連のシナリオは、単純なものであれば、初心者でも参考図書を見ながらであれば、すぐにシナリオを書けるのではないでしょうか?

但し、RPAの作業時間が長く要しているので、もっとスピードアップしたい、もしくはエラー発生頻度を低くしたい、そう思ったらテーブル機能を活用しましょう

詳細は他ブログやUipathサイトに譲りますが、テーブル機能を使うのと使わないのではスピード、エラー発生頻度が大きく違います

Uipath・テーブル構築

それは何故か?

ファイルを開く頻度の違いがポイントになります

ちなみに、テーブルは何かと言うと、e-WORDsでは以下のように書いてありました

要素を縦横に碁盤目状に並べて整理した表の意味で使われることが多い

この記事内では”データの一塊”として説明させて頂きます

1.テーブルを使わない場合

例えば100個のデータを読み込む必要があった場合には、100回ファイルを開きます。その間にエラーが発生する可能性が高くなります。もちろん、100回ファイルを開く分、時間がかかります

2.テーブルを使う場合

ファイルを開くのはテーブルを作成する時、1回のみです。1のテーブルを使わない場合と比べると、スピード及びエラー発生頻度ともに格段の違いがでます

<まとめ>

RPAはアイデア次第、機能を知っているか知らないかで効率に大きな差がでます。今回紹介したテーブル機能は典型的な”差”が出る例です。もし使っていない人がいたらぜひ活用してみましょう!結構、直感的な操作で出来ますよ!

にほんブログ村 資格ブログ ビジネススキルへ

にほんブログ村 IT技術ブログ VBAへ

にほんブログ村

RPA導入日記~パートナーは選べない~

RPAを導入する上で欠かせないのがパートナーの存在だと思います。ここで言うパートナーとは一緒にRPAを作成するユーザーのことです。このパートナーとの関係がRPAの出来を大きく左右します

今回は、今までRPAを導入する上で感じたパートナー作りのポイントについて述べていきたい

話しの大前提は、”パートナーは選ぶことができない”です

1.とにかく喰らいつく

RPA導入をしたいという部署に限って、担当者が忙しくて時間が取れないというケースは多いと思います。でも業務を理解しないと、はじまりすら始まりません。

 しかも彼らから聞いた業務の内容には必ず”省略”が含まれています。当然、彼らは忙しいので話しやすい部分を最優先で話します

 でも喰らいつくしかありません。但し、職務質問になってはいけません。嫌われては何もなりませんので・・・後、もっとも駄目なのは感情的になることです。感情的になったらもう後戻りできません

2.動画をまずは撮らせてもらう

 まずはパートナーに業務の内容を書いてもらう、のもいいですが、”省略”されては意味がないです。必ずRPAの対象業務は動画を撮らせてもらいましょう。そうすればパートナー自身が気づいてない部分なども気づけたりします

3.成果を魅せる

パートナーに喰らいつく為には、まずは成果を魅せることが第一です。動画を撮らせてもらったらとにかくRPAを作成してみましょう。メリットない人に使う時間はありませんので、とにかく成果を挙げられるところを見せるようにすべきです。作製途中でもいいし、書類なんかなくてもいいです。”メールで動画を送る”でもいいのでRPAを動くところをいち早く見せましょう。そうすれば彼らの心も動きます

4.直感は信じましょう

 直感的に危うい・・・と思ったら、直感を信じて”危うい理由”をパートナーにぶつけましょう。そのままにしてはいけません。”危うい”と感じるのは何かしら根拠があるものです

5.腹八分

パートナーの方でよく”あれも”、”これも”したいという欲張りなことを言う人がいます。理想を追うのはいいのですが、RPA導入の場合、80点から90点に上げる為に、迷路に迷うケースもあります。時間も大幅にロスしますが、仮に完成しても誰にも直せない”城”が出来てしまうこともあります。

 ですので1.シンプル、2.完成スピードの2つを意識して、80点のものをまずは実際の現場で動かし、動作検証することを意識しましょう

 ちなみに、テスト環境と本番環境では状況が違うケースがほとんどだと思います。とにかく本番環境でテストするフェースへ早めに移行することを意識していくべきです

6.業務の仕方は十人十色

 実は業務の理解の仕方には様々なパターンがあります。頭で理解する人、体で覚える人、マニュアルに沿って理解する人、これはもう十人十色です。

 但し、確実に一つ言えるのは皆が皆、業務を完璧に理解できているわけではないのです。それぞれの業務の理解の仕方、癖を理解した上で想像を働かせ、説明が足らない部分を推測していく必要があります

7.一切時間が無いは要注意

たまに一切時間が無いという人がいます。冒頭でパートナーは選べないと述べましたが、これだけは考える余地があると私は考えています。何故かというと、”一切時間が無い”人に限って特殊な理由を持っているケースが多いからです。昼間はネットサーフィンをしているので、仕事をする時間が短い、だから忙しい、もしくは自分が興味を持てる私的なおしゃべりはいくらでもするが、自分の興味がない話には付き合わない、など極端に自己中心的な考えを持っていたりするケースがあります。この手の人の時間を確保すべく、前倒しでスケジュールを組んだりしたとしても、いざその時が来たら”都合が悪い”とか言い出すこともあります。この手の人に当たったら組織の上司に相談して、組織論から考え直すしかないと思います(尚、”時間がない”というのも言い方による点は付け加えておきます)

最後に、

 RPAの対象業務はこれまでのシステム開発と違い、細かな単位になります。システムに業務を合わせてもらうことは期待できません。とにかくパートナーと一丸になって、業務分析を一緒に行い、ゼロベースでRPAを組み入れた新たな業務を共同で作成することが理想です。

 理想を実現するためにはパートナーと良好な関係が欠かせません。長文となりましたが、皆様のパートナー作りの一助になれば幸いです

にほんブログ村 資格ブログ ビジネススキルへ

にほんブログ村

 

RPA導入日記~便利技~

 今回はRPAを作成してきて、”これは便利だ、助かった”という技を2つだけですが紹介したいと思います。

 尚、内容はUipathでの内容に限られる点と、あくまで私個人の感想である点については予めご了承いただきたいです

1.条件分岐XxBOOLEAN型変数(フラグ)x条件分岐

RPAの場合、他の言語以上に分岐処理や繰り返し処理をどう行うかが重要だと考えています

特にBOOLEAN型の変数を使う機会は多いと思います

条件の発生と処理自体の分岐がシナリオ上、遠く離れていたり、並行処理を行う必要あったりするとき、もしくはAND条件やOR条件が絡む時にこの型の変数を条件分岐処理や繰り返し処理と組み合わせて使うととても便利です

➀まずフラグを設定する

②分岐処理の中でフラグの値を変える

③更にはフラグの値によって処理を変える

2.リトライスコープ

RPAが扱う業務は本来定型です。ところが、アプリケーションによってはパフォーマンスなどの要因により、以下のような、そうでないケース(定形的でない)もあります

・RPAでOKボタンをクリックしても、クリックできていない時がある

・保存などの処理を行った時に”処理しますか?”などの確認メッセージが1つだけ出てくるときもあれば、複数出てくる時もある

上記のような場合への対応策として繰り返し処理を入れたりすると、無限ループに陥るケースがあります

Uipathでは繰り返し処理以外の対応策として、リトライスコープという便利なアクティビティを用意しています

リトライスコープは条件通りの状態になるまで、”ある指定した操作”を”指定した回数”行います

ですから、指定した回数の操作を行ったら、処理を終了するので無限ループに陥ることはありません

このアクティビティはエラー対策としてとても便利なので、ぜひ有効活用してください

本来であれば”セレクター関連”もぜひ紹介しておきたかったところですが、それはまた別の機会にしたいと思います

また次回をお楽しみに!

にほんブログ村 資格ブログ ビジネススキルへ
にほんブログ村 IT技術ブログ VBAへ

にほんブログ村

RPA導入日記~AS400~

平成も終わろうとしていますが、当初はコンピューターと言えば緑が混じったインベーダ―ゲームのような画面でした

今となってはとにかく使い勝手の悪さを感じたりもしますが、それでも多くの企業で緑の画面がまだ活躍しています

使い勝手が悪いだけに、RPA導入効果が高そうですが、最初は本当にRPAが動かせるかどうか心配でした

ところが、取り組んでみると意外にもスムースに動きました

WebシステムをRPAで動した場合と比べた場合、

・待ち処理がないのでエラーが出ない

・ボタンなどが無い分、シンプルにシナリオを作成できる

などのメリットがありました!

今回はどうRPAを動かしたのか?について概要だけ紹介したいと思います

1.まずはUipathでTerminalパッケージをインストール

2.ターミナルセッション・アクティビティでAS400に接続

3.2以外に主に使用するアクティビティ

以下に印をした4つで十分だと思います。位置については行数や列数で指定するので直感的に動かしやすいと感じるかも

4.次ページへの画面移動(ページ送り)

AS400は1ページの行数に制限があるので、この処理は面倒かもしれません。カウント用変数を1ページ行数で割り、余りが0だったらページ送り処理をするなどの分岐処理を作成して対応しました

5.エミュレーター

Uipathで対応しているものを確認が必要です

今回は以上です、最後まで読んで頂きありがとうございました

にほんブログ村 資格ブログ ビジネススキルへ
にほんブログ村 IT技術ブログ VBAへ

にほんブログ村

RPA導入日記~仕様書~

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

これは正論である

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

1.RPAのメリット

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

2.RPAの対象業務の特徴

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

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

1.RPAシナリオ自体を仕様書にする

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

➀シーケンス(箱)を構造化しておく

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

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

そして、一番おすすめが

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

2.動画を活用する

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

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

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

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

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

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

3.1と2でカバーできそうにない箇所を画面コピーする

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

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

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

にほんブログ村 資格ブログ ビジネススキルへ
にほんブログ村 IT技術ブログ VBAへ

にほんブログ村

 

RPA導入日記~RPAあるある~

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

1.RPAを導入したら人は要らないよね?

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

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

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

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

2.AIと違うの?

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

3.RPAは止まらないよね?

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

4.RPAはユーザー(システム部門以外)で開発できるよね?

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

5.RPAは業務が人より早いよね?

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

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

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

にほんブログ村 資格ブログ ビジネススキルへ
にほんブログ村 IT技術ブログ VBAへ

にほんブログ村

RPA導入日記~10と2の法則

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

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

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

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

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

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

意外と混乱すると思う

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

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

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

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

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

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

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

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

ということだ

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

にほんブログ村 資格ブログ ビジネススキルへ
にほんブログ村 IT技術ブログ VBAへ

にほんブログ村

RPA導入日記~平均の恐ろしさ~

私の場合、RPAの導入のきっかけは、よくある「全社にRPAを導入してみよう」の類ではない

実際に困っていた部署があったからだ。

どう困っていたか??

それは○○の類の業務ならこの位のスキルの人を入れておけば良いという思い込みに起因する。

どんどん人が辞めていくので、「たまたまスキルが低かった」

皆、簡単に結論づけてしまっていたが、実際に業務を体験してみると結してそんな事はない

ではスキルの高い人を入れようとしても現実的には予算やスキルの高い人の志向などを考えると無理がある

そこでRPAを導入しようとなるが、ここでまた問題が起こる

基本的に人が難しいことをRPAにやらせるのは無理だからだ

ここで一番言いたいことだが

とにかくRPAを作って動かしてみることだ

実際に動かしてみることで人間が行っていた業務の流れを変えるヒントに気づくことだ

最初に作るRPAはどうしても人間のコピーになるが、動かして見るとインピスレーションが沸く

ここからがRPAの醍醐味だと思う

~続く~

にほんブログ村 資格ブログ ビジネススキルへ
にほんブログ村 IT技術ブログ VBAへ

にほんブログ村

RPA導入日記2~情報収集~

RPA導入を決めるまでは漠然と情報収集していました。

RPA関連図書もほとんど無かったので、セミナーやRPAの体験会に参加したりしていました。

今では情報収集についてはこう思っています

”手を動かすのが、一番の情報収集”

何故なら、RPAが稼働するのは現場の最先端だからです。

隣の現場はやはり自分たちの現場とは事情が違っています。

そうは言っても有効な手段は存在すると思っています。

以下、自分なりに役に立ったものを列挙します

1.RPA Community

実はRPA Communityに参加したのがきっかけでRPA機種選定をしました。このイベントではベンダーよりではない、RPAの使い手が順々に登壇してプレゼンしていくのですが、やはり手を現場で動かしている技術者の経験は貴重です。ベンダーが主催するようなセミナーの類はどうしてもベンダー寄りなので、提供されるデータにフィルターがかかかっており、生々しさが足りていないのです。ただそれ以前に、このイベントでは若い登壇者の方の”熱さ”に刺激を大いに受けました。”とにかくRPA、やってやろう”そんな感じになりました。後から考えると”とにかくやってやろう”がRPAでは大事ですね

2.決定版 実践! RPA (日経BPムック)

決定版 実践! RPA (日経BPムック)」RPAの現場をよく取材されていると思いました。そして、現場の様子をただ伝えるだけでなく、エッセンスが”格言”の形で要約されているので、よく拝借させて頂いています。但し、ある程度、RPAを動かした経験が無いと響く部分が少ないかもしれません。私の場合は”自分の言いたいこと”、”気づいた事”をシンプルに表現するとこうだな、と、納得できる”格言”に出会うことができました。

3.Twitter

RPAに限らず、専門性の高い分野に関してはアンテナの高い方たちが集まっています。漠然とネットサーフィンするよりは最先端で筋の良いWeb記事にありつくことができます。

今日は短いですが、ここら辺で。明日また違う角度から日記を書きたいと思います。

にほんブログ村 資格ブログ ビジネススキルへ
にほんブログ村
にほんブログ村 IT技術ブログ VBAへ