こんにちは、黒糖です。

前回から間が空いてしまいました。今回読んだ本はこちら。

いちばんやさしい教本　シリーズですね。

座学形式ではなく、実戦形式で進んでいく（レッスンがいくつか設けられており、実際の製品を使用して簡単なロボットを作成する。為替の情報を蓄積して1日1度メールで通知する等）構成となっており、具体的な製品名も示してくれており、非常に良かったです。

そして今回からはちょっとやり方を変えまして、先述のような感想とは別に、この本の要約を残すことにしました。（自分自身読んだ本の内容を忘れるので・・・ｗ）

以下要約（自分的解釈）です。

【要約1】SaaS同士をつなぐAPIに替わる役割としてもRPAは利用できる。

【要約2】導入の流れ ①情報収集 どんなRPAがあるのか調査 ②企画 具体的な導入の手順や代替する業務、スケジュール、運用体制、ROI試算 ③提案 ①「情報収集」と②「企画」の成果物をまとめたものを経営会議などに提案し、会社の事業として承認を得る。 ⇒ 「押し切る提案」より「理解を得る提案」をする ④導入から運用まで 業務フローと人間に密接にかかわるシステムなので、人間の気持ちに配慮しながら導入を図っていく。

【要約3】RPAが増えるにつれて、周辺のサービスも増えてきている。タイプは3つあり、RPAを操作するオペレーターの人材派遣、研修サービス、RPAの運用を請負うサービス、経理や日程調整などに特化したサービス群がある。

【要約4】Windows環境が必須の業務かどうかが指標になる。Windows環境の操作がメインになる場合はデスクトップ型か、オンプレミス型のRPAを最初に検討する。クラウド型の場合はスプレッドシートなどのWeb環境にファイルを用意しなければならないことがあり、運用上のネックになる。一方でMacの場合はデスクトップ型、オンプレミス型は対応していないことが多いため、クラウド型RPAが適している。

【要約4】少量多品種の業務の場合は、初期導入費がかかってもロボットが作り放題のサービスがあるオンプレミス型RPAを選んだほうが賢い。

【要約5】デスクトップ型RPAであればヘルプデスクのようなスキルが必要だし、オンプレミス型RPAであればシステムエンジニアのようなスキルが必要。

【要約6】投資対効果の算出に有効なのが「最低○○くらい、最大○○もいけるかもしれない」というやりかた。

【要約7】RPAプロジェクトを行う場合、ディレクター、ロボットを作るオペレーター、RPAがアウトプットしたものをチェックして改善するグロースハッカー、インフラ担当の4人がセット。

【要約8】RPAベンダーからの質問にきちんと答えることも、プロジェクトの成功には欠かせない。RPAベンダーもチームの一員として働いてもらうことが得策。

【要約9】各メンバーの紹介時には「〇〇を期待して参加してもらいました、〇〇さんです」というように期待を明確に伝え、チーム全体に対して役割をコミットしてもらう機会にする。

【要約10】RPAは人と一緒に業務を回していく側面もあり、RPAが属人化しないようにする配慮も必要になる。

【要約11】最初に定常的な運用のチェックと課題検出、改善のフローを構築する「構築期」からはじまる。次に、成果をほかの業務や部署に広げ、ITシステムとして統制する「横展開期」に入る。そして社内での安定稼働が実現できたら、AIなどの外部システムや取引先システムとの連携、業務システムの開発といったRPAを基盤とした成長を目指す｢拡大期｣に入っていく。

【要約12】RPAの運用が始まると、人間はその業務から開放されたように感じるが、それは間違い。 ｢とても素直な新入社員｣を迎え入れて、仕事を教えた状態と同じ。 言われた通りの仕事を進めるが、変化には苦手。

【要約13】業務の中にRPAからの報告フローを含んでおくとよい。

【要約14】5W1Hストーリー方式 なぜこの業務が必要か、いつやるのか、何をやるのか、どこ（システム）でやるのか、誰がやっていたのか、どのようにやるのかを明確にする。

【要約15】ユーザフォーラムは製品を使用している人同士の情報交換やトラブルに対する解決策の提示の場。

【要約16】ロボットの作成と実行結果については現場責任が良い。

【要約17】RPAの評価にはQCDを使用する Quality（品質） Cost（コスト） Delivery（納期）

【要約18】導入に直後は、 週一ペースでKPTによる振り返りをし、軌道に乗ったあとは QCDベースの報告とディスカッションによる振り返りをする。

【要約19】こまめで定期的な広報は低コストな割に有効な解決策。

【要約20】勤怠管理など、そもそもシステム化されているものは、RPAを走らせるよりも、元のシステムを変更した方が良い場合もある。

【要約21】成果が出ているからといって、RPAだけに選択肢を絞る理由はない（Excelのマクロや、データ分析のBIツールなども検討すべし）

【要約22】RPAは既存のシステムの大規模な改修が不要で、業務フローの大幅な変更を伴わず、小さな投資で生産性向上が図れることがメリットであるが、それゆえに強い副作用も持っている。 元々現行システムの使い勝手が悪く、改修を行う予定だったところにRPAを導入した結果、使い勝手の悪いシステムを使い続けることになったりする。 また、システム間のやり取りをするAPIを開発しようとしていたとしても、RPAの導入で当面は不要となることもある。 改修や開発が本当に不要であればよいが、｢ダメなシステムの延命｣にならないよう注意。

【要約23】RPA導入のメリットは労働時間やミスの削減だけでは無い。 RPA化の工程でデータ入力のルールやデータベースが整備されることで機械でも読めるデータを獲得する流れができる。

【要約23】RPAプラスAIでできることは、1.人間の高度な仕事を代行する 2.人間の判断の参考情報を瞬時に出す 3.代わりに判断する

【要約24】削減した時間よりも、削減した時間で何ができているか、ということを常に意識することが大事。

【要約25】RPAによってもたらされる恩恵は、業務の棚卸、マニュアル化、効率化など多岐に渡るが、人間に時間的余裕が出来ることで、精神的余裕がも生まれることが最も大きな恩恵と言えるかもしれない。

【要約26】かつてパソコンやスマホをいち早く使いこなせた人が評価されたように、いち早くRPAを使いこなせる人が評価されるかもしれない。

以上、よろしくお願いいたします。