2019.01.31
RPA導入するには、どのような業務を自動化するか、いわゆる対象業務を選定しなければならなりません。
中小企業の場合、作業の種類が少なく、各部門でどのような業務があるかを大体把握している従業員がいるでしょう。
この場合、これら数人にヒアリングすれば、RPA化する可能性の高い業務が洗い出せて、とても楽です。
しかし、大中企業の場合そうもいきません。
各部署の業務がすべて把握できるといったら恐らく極めて困難です。
グループ企業の場合、複数子会社の複数部署、大人数で一つの業務を協力している場合もあり、なおさら難しいです。
この場合、中小のように全業務をヒアリングするのは膨大な時間や労働力が必要なので、非現実的でしょう。
そして、本コラムでは、A社がRPA対象業務を効率的に集めるにはどのような試みをしたかを見てみましょう。
A社は国内大手IT会社であり、従業員数は１万人を超える大手企業です。RPA案件を集めるには様々な試みをしてみました。
ここで代表的なものを紹介します。
A社が最初に試してみたことは案件を収集する掲示板でした。
A社はグループ会社のため、本社はともかく、各子会社に行って業務をヒアリングすることはできません。
そのため、一番簡単なのは各部署から要望を集めて、そしてRPA導入のチームがそれらを評価することです。
A社本社のIT部門はRPA導入プロジェクトの主体として、社内掲示板を作成しました。
掲示板にフォーマットが用意されて、各部署や子会社が各自の要望を記入する。
内容は業務の基本内容、利用するシステムやアプリ、業務の所要時間などです。
そして、IT部門のスタッフがまずこれらの業務を見て、RPAの可能性やROIを評価します。
評価結果に基づいてRPA化するかしないかを決めます。
一見特に問題ないように見えますが、掲示板を実行して数ヶ月後、大きい問題があらわれました。
それは掲示板の量です。
当初の予想は一人のスタッフは掲示板内容の評価をする予定でしたが、毎日掲示板の量があまりにも多く、二人となりました。
RPAが社内にどんどん人広がり、まだまだ毎日数十件が上がってきます。
評価の量が多い問題もそうですが、評価して、そもそもRPAに極めて向いていない業務やROIがよくない業務が全体の半分弱を占めています。
それを全部返答しないといけないし、依頼者にRPA開発しない理由なども説明しなければなりません。
しかも、これはあくまでも初期評価なので、その後に業務ヒアリングなどが残っています。
ここにあまりにもリソースを投入しても仕方がないとA社が考えて、次の手を打ちました。
それがRPAセミナーです。
RPA掲示板の発想はとても良かったです。
しかし、大企業のA社では、対応しきれない案件が上がってきていました。
その理由を分析すると、IT部門以外、社内の従業員はそれほどRPAに詳しくないからです。
詳しくないため、とりあえず要望を出して見て、IT部門の専門家に評価してもらいたいという声がありました。
もちろん、できる限りRPAを社内に多く実装させたいという気持ちはありますが、RPAができない業務やROIが悪い業務を一々評価してもリソースがもったいないです。
そこで、A社は「みんなにRPAを教える作戦」を起こし、RPAセミナー開催することにしました。
部署に関係なく、予約すれば誰でも参加できます。
最初の狙いはRPAの基本知識を教えることでした。
掲示板に依頼を出す条件はまずRPAセミナー受講必須となりました。
ある程度の知識もあれば、そもそもRPA化できない業務を依頼することも少なくなるでしょう。
また、受講してみて、自ら開発をやってみたい部署も出てきて、これらの部署にこたえて、開発実戦向けのセミナーも開催することになりました。
遠いところにある子会社は物理的に受講困難のため、ネットセミナーも用意しました。
その結果として、掲示板に上がってきた業務の量は減りますが、質が向上しました。
すなわち、RPA化可能でROIの良い業務を探すのがより簡単になりました。
もちろん、セミナー開催するには講師も必要ですし、資料の準備もしなければなりません。
最初は「逆にもっとリソースがいるのでは？」という懸念もありましたが、実行してみて、その問題はありませんでした。
まずRPA専門の従業員一人を専任講師と任命します。
そして、毎週３回ほどセミナーを開催します。
それ以外の時間は各部署（主に自ら開発をする部署）からの質問などを回答します。
これにより、掲示板に評価待ちの業務が減り、元々二人でも厳しい評価業務が一人でもクリアできるようになりました。
RPAセミナーの開催により、もう一つのメリットはRPA人材の育成です。
RPAセミナーに参加した後、自ら開発をやってみたいという部署や子会社は少なくありません。
では、なぜ最初からこと要望を言い出さなかったというと、そもそもRPAに対してあまりにも知らないからです。
セミナーを受講し、「ああ、こういうことなんだ」と思い、「これなら私はやってみたい」という発想も浮かび上がります。
ご存知の通り、RPAの導入は開発したら終わりというわけではありません。
常に調整やメンテナンスしないとうまく動作しない場合がほとんどです。
そして、メンテナンスはもちろん開発者がしたほうが一番効率がよいでしょう。
開発可能な部署や子会社がいれば、IT部門RPAメンテナンスの作業量はかなり減ります。
また、開発しない会社でも、簡単なこと解決できれば、毎回IT部門にRPAの修正依頼を出さずに済むでしょう。
例えばファイルの置き場所を変更や稼働時間の調整など。
RPAセミナーのおかげで、A社の案件集めがとても効率よくなってきています。
そして、各部署や子会社の案件依頼状況を分析してみたところ、RPAセミナーにも参加せず、開発依頼も出さない子会社が多数存在するということが判明されました。
A社はこれらの子会社の中にも価値のある案件が必ず存在していると信じて、これらの子会社に対して「営業活動」を行うという方針を決めました。
RPAの社内営業活動は簡単に言うと普通の営業活動と変わりません。
社内のRPA営業マンが各部署や子会社に訪問し（遠い子会社はWEB会議などの方式）、今RPAのメリットについて説明をします。
また、直接皆さんは日常業務についてなにが困ることないかと聞きます。
場合によってはRPAをその場で実演し、アピールをします。
直接営業以外、RPA営業説明会を開催することにもなりました。
RPAセミナーも似たような内容がありますが、セミナーと聞いて、積極的に参加しない部署や子会社がいるため、この説明会は主に過去の案件や実績などをアピールし、とりあえずRPAに興味を持つようにするのが狙いです。
また、セミナー見たいに何時間ではなく、参加しやすいするために、時間を1時間ないに抑えています。
社内営業をしてみて、実績も出るようになりました。
元々RPAに興味がない部署がRPAを知って初めてこの便利さに関心をします。
そして、セミナーに参加し、いくつかROIがとても良い案件も開発依頼しました。
その中にはとても理想的な案件もありました。
一の子会社が開発依頼した開示文書のフォーマットをチェックするRPAがありますが、別の子会社がほぼ同じものを求めて、簡単に修正して、すぐ導入できました。
この三つの施策を同時進行により、A社の案件集めは最初に比べて数倍の効率向上をしました。
ただ、色々と試行錯誤をし、半年以上の時間をかけてやっとこの体制にたどりつきました。
読者の参考になれれば幸いです。
2019.01.30
日本国内の少子高齢化が進むによって、国内市場の縮小や国内労働力の不足が避けられない、アジア新興諸国の膨大な市場のポテンシャルと安価な労働力を求める日本企業は積極的な海外事業展開をしている。
しかし、海外進出は必ずしも順調とは限らない。
そこで、アジアに進出した日系企業の現地法人では、人件費の高騰や業務品質の維持、人材の流動化といった課題に対応するため、RPAソリューション導入のニーズが高まっている。
伴に、最近、アジア諸国における日系企業や現地企業に向けてRPAソリューションを提供し始めた企業に関するニュースがよくみられる。
本文は、近年アジア新興国における日系企業や現地企業をターゲットとする企業のRPAビッグニュースをピックアップする。
アビーム、アジア市場向けにRPAクラウドサービスを提供開始
アビームコンサルティングは2019年1月8日、アジア市場向けのRPAクラウドサービスの提供を開始した。
アビームコンサルティングは従来、企業のRPA活用を支援するコンサルティングサービス「RPA業務改革支援サービス」を、主に国内企業向けに提供している。
国内のクライアントに向け、2018年6月からはクラウドサービスも開始している。
今回の海外業務について、対象はシンガポール、タイ、インドネシア、マレーシア、ベトナムといったASEAN諸国の日系企業の現地法人で、内容は対象業務の特定から、RPAツールの導入、技術者育成まで、全面的にカバーしている。
NTTデータなど3社、タイでRPAソリューションを提供開始
CSI (Thailand)、NTT DATA Thailand、クニエの3社は2018年5月1日、タイにて RPAソリューション「Office Robot」を提供開始することを発表した。
「Office Robot」はNTTデータが販売元として提供しているWinActor の英語版となり、特徴として「人的コストの削減」など以外に「タイ語によるサポート」「導入効果最大化支援」も挙げられる。
タイ語によるサポートでは、導入後も現地スタッフによるタイ語でのサポートを受けることが可能だという。
また、導入効果最大化支援については、導入効果を最大化するために様々な導入支援にも行っている。
参考記事：https://it.impressbm.co.jp/articles/-/17253
https://news.mynavi.jp/article/20180501-624691/
2019.01.29
こんにちは！
今回は、RPAをはじめとした、所謂、「働き方改革」の中で今後ますます注目を集めそうなツールについて紹介していきたいと思います。
働き方改革で期待されているツールとして、チャットボット、AI、RPA、この３つが代表格です。
Googleトレンドで、３つを比較したところ、1:3:52と出ました。
「AI」の関連キーワードを見ると「ai みんながみんな 英雄」など、人口知能の「AI」じゃない、アーティストの「AI」さんを検索している方も多くいるかと思いますが、その結果が1:3:52という差になったのは仕方がないかもしれません。
この３つのテクノロジーがどのようなものであるか解説していきたいと思います。
「チャットボット」は英語表記で、chatbotであり、ウィキペディアでは、人口無脳の項目に色々説明が書かれているので、単語としては定着していないのだと思われます。
私自身も資料作成時には、名称として「chatbot」を使っており、単語として「人口無脳」という単語は聞きなれません。
人口無能ではないので、お気を付けください。
Googleトレンドでチャットボットを検索すると、RPAやAIよりも検索されるケースが少なく、「チャット」で検索すると「AI」よりも検索されています。
「チャットボット」は、チャット+ロボットの造語で、スカイプやラインなどの人同士が文字で会話する仕組みを、人同士ではなく、人とロボットがチャットを通じて会話をすることである。
このRPALABと似たボットに光をあてる「BOTLOBO」なるメディアもあります。
参考にチャットボットを掲載していいますので、少し試してみてください。
ALAIN（アラン）
http://www.grokwork.com/alain/
説明書きには、
人の言葉をそれなりに理解して会話する、完全オリジナルのチャット型プログラムです
従来の人工無脳とはひと味違った機能を多数搭載しています
軽い気持ちでプログラムとの何気ない会話を楽しんで頂ければ幸いです
と書かれているので、会話が成り立っているようで成り立っていないことも多いです。
私がアランと会話したら下記にある通りになりました。
ちなみに私の登録はOGITI（オギッティ）で登録しています。
OGITI ： おはよう(12:37:24)
ALAIN ： おはようございます (12:37:24)
OGITI ： 貴方の名前は？(12:37:39)
ALAIN ： 本当は芸術とそうでないものを分ける垣根なんて無いんでしょうけどね (12:37:39)
OGITI ： 名前を教えてください(12:37:57)
ALAIN ： 分かりました (12:37:57)
ALAIN ： 日が沈む前の、あの深い蒼に出会うと、私は何も考える事ができなくなります (12:37:57)
OGITI ： ALAINという名前ですよね(12:38:41)
ALAIN ： そうかも知れませんね (12:38:41)
OGITI ： いい加減にしないと私は怒りますよ(12:39:09)
ALAIN ： あまり深刻に考えるよりは、休み休み冷静に考えた方が効率が良い気がします (12:39:09)
ALAIN ： こだわりを持ち過ぎると、長期的にはうまく行かない場合が多い様です (12:39:09)
OGITI ： いい加減にしてください(12:39:34)
ALAIN ： あまり深刻に考えるよりは、休み休み冷静に考えた方が効率が良い気がします (12:39:34)
ALAIN ： こだわりを持ち過ぎると、長期的にはうまく行かない場合が多い様です (12:39:34)
実際のところ、「YahooAPI-キーフレーズ抽出」を利用して、重要と思われるフレーズから優先的に返事を考えているそうですが、会話の内容が多岐に渡る場合、上のようにチグハグな会話になります。
業務に絞ったボットにすれば、会話が成立するようになるかと思います。
例えば、人の入れ替わりが激しい職場などにあり、人事・労務に絞った内容にすれば、人事部の社員がその都度対応しなくても良くなることが増えると思います。
このブログでも日々更新しているRPAですが、2016年ぐらいから急速に広まっていった用語に思えます。
しかし、Excelの関数ぐらいの感覚で使われるレベルまで普及するレベルまでにはまだまだ時間がかかりそうです。
現在、RPAのシナリオ作成をエンジニアである私などが作成していることもありますが、Excelの簡易性レベルまでRPAツールが簡易になっていない部分も多分にあるかと思います。
RPAベンダーの開発力に期待したいところです。
また、ベンダー側から「RPAを使えば誰でも自動化ができる」という触れ込みで提案された方も多いと思います。
ですが、実際に触ってみると、「誰でも」というのは難しいと感じるでしょう。
実際にRPAツールに触れたことがある方ならわかるかもしれませんが、シナリオを作成するにあたり最低限プログラミングに関する基本的な知識は必須です。
（条件分岐、繰り返し処理など）それらの経験、知識のない人が開発をしようとしても、まず何をすればいいかわからないため、結局有用なシナリオを作ることは難しいでしょう。
その為、RPAツールは使えない、といった風潮が広まる可能性も出てきてしまいます。
ですので、現状RPA化を考えている方は、「誰でもできる」という言葉を鵜呑みにせずに、実際にツールを触ったうえで判断する必要があると感じます。
逆に言えば、RPAの開発利便性をExcelレベルまでに落とし込むことができるのであれば、今後RPAによる業務改革は確固たるものになっていくでしょう。
いろんな分野でAI活用がなされており、職人技と言われるような高度な判断まで出来るAIなども出現しています。
最近であれば、自動運転などが代表的なものではないかと思います。
世界的にも研究が進んでいるので、知らないうちにAIが導入されているケースも増えてくるかと思います。
現段階は、AI搭載などを前面に押し出すことで、ビジネス上の優位性を得ているケースが多いようですが、我々が想像しているよりもAIは何でもできるわけでもなく、部分的な活用のみにとどまり、我々が想像するレベルに達するには後10年ぐらいはかかるのではないかと思います。
ここでは書ききれないため、次回触れる機会があれば書いていきたいと思います。
今回は、RPA、Chatbot、AIについて解説してきましたが、今後注目するワードとして「IPA」という単語がニュースを賑わす日が来るかもしれません。
「IPA」とは、マッキンゼー社が概念提唱してきた言葉で「Intelligent Process Automation 」の頭文字を取ってIPAと言っていますが、その意味は、RPAに業務プロセスの再設計と自動化、さらにAIを組み合わせた一連の技術セットを指す概念とされています。
分かりやすく言うと、RPAが手足、chatbotが口、OCRが目、最後にAIが頭脳、それを含めてデジタルレイバー（Digital Labor、仮想知的労働者）と位置づけかと思います。
上記のように、それぞれのツールを単独で使用するのではなく、得意分野を生かして、ひとつの「システム」として運用される機会も増えてきたように思います。
現在ではAI×チャットボット×RPAが研究されており、便利なものが続々と開発されています。
私が間接部門である総務系業務を担当した際、社内からの問い合わせの内容は、経費の精算や有休の日数など、簡単に調べることができる内容が多かったと思います。
社内問い合わせに対し、即時回答できるものもあれば、社員の個別データを確認しないと分からないものまで千差万別で、調べる場合など時間がかかるケースも多々ありました。
一方、社内FAQに調べ方など載せたりすると、私の部署への問い合わせは減りますが、社員がFAQを検索して知りたい情報に辿り着くまでに時間をそれ相応の時間がかかります。
私の時間、もしくはそれ以外の社員の時間が取られるので、FAQも万能ではありません。
チャットボットが私の代わりに応えてくれることで、私の時間を削ることなく、チャットボットが答えてくれる仕組み、それがRPA×AI×チャットボットと言えます。
2019年に入り、自動化ツールは今後ますます注目されていきます。それに伴い、我々の働く環境がどのように変化していくか楽しみでもあります。
2019.01.28
「リモートワークを当たり前にし、労働革命で人々にもっと自由を。」を掲げながら活動している、株式会社キャスター（代表取締役社長：中川 祥太、本社：東京都渋谷区、以下：キャスター）が2019年1月21日より日常業務を500円から気軽に依託することのできるアシスタントサービス「My Assistant」を提供開始しました。
キャスターはオンラインアシスタントサービス「CASTER BIZ（キャスタービズ）」を展開しており、オンライン秘書サービスとして注目を集めています。
オンライン秘書サービスとは、秘書業務である、「メールの返信代行」「スケジュール管理」「電話受付」「リサーチ業務」「退勤管理」などの様々な業務を優秀なアシスタントが行ってくれるサービスのことです。
その中でも、「CASTER BIZ（キャスタービズ）」は質の高いサービスを誇っており、アシスタントの採用確率が1％と言われており、100人に1人の洗練されたアシスタントのサービスを受けることが出来ます。
（MyAssitantホームページ より引用）
そんなキャスターが今回リリースしたのが、パソコンまたはスマートフォンから簡単にアクセスすることのできる「My Assistant」です。
このサービスは日常業務を500円から安価に依頼できるサービスで、「会食手配」や「会議室リサーチ」、「お土産・プレゼントの購入」に至るまでのタスクをオンラインアシスタントに依頼することが出来ます。
その中でも、「会食のお店探し」のメニューではクラウドRPAが導入されており、依頼するとRPAロボットが自動的に業務の実行を行ってくれる仕組みになっています。
サービスの使い方についてですが、「新しいタスクの依頼」からタスクを選び、チャットで質問事項に答えてタスクの完了を待つだけという、非常に単純な構造になっており誰でも気軽に使用できるようになっています。
これにより、多くのビジネスマンが日々の日常業務を減らし、自身にかできないような独創的な作業を行えるようになるのではないでしょうか。
今後も、人間が本来行うべきである仕事内容を重点的に行えるような取り組みが増えていくことを願います。
参考記事：キャスター、500円からスマホで簡単にお仕事依頼できるアシスタントサービス「My Assistant」提供開始
2019.01.25
日本でRPAの市場が盛り上がっている。
中国の市場では、RPAソリューションの導入の働きも本格化している。
その原因は、近年中国国内の人件費の急騰である。
中国国家統計局によると、中国国内の平均月額賃金は2013年以降、毎年10％前後の割合で伸びている。
その人件費の高騰に伴い、業務効率化やコスト削減は企業に向かって重要な課題になってきた。
その中で、特に注目を浴びているのは中国4大会計事務所の一つ「立信会計士事務所」のケースである。
立信会計士事務所とは
中国の大手会計事務所として、立信会計事務所は約10,000人の従業員を抱え、中国国内には33の拠点がある。
その顧客は中国の上場企業のほぼ4分の1をカバーし、各顧客の税務処理などを請け負っている。
このような多い人数の従業員がいるため、事務所の人件費は非常に膨大で、コストを削減するのは非常に大きな課題である。
立信会計事務所の徐呈ITシニアマネジャーの話によると、事務所に対する最大のコストは人件費である。
われわれにとって、最大のコストは人件費だ。これからも上がることを想定すると、もっと収益を上げていかなければ、上昇のスピードに対応できなくなる可能性があり、場合によってはライバルの会計士事務所に優秀な従業員を奪われてしまうかもしれない
導入経緯
2018に、立信会計事務所はKDDI上海を通じてRPAソリューションを導入した。
適用した業務範囲は主に税務当局に提出する大量な顧客会社の税務表作成業務である。
RPAの導入による、一つの税務表を作成する時間は導入前の約1時間半から導入後の3、4分に大幅短縮できたといわれている。
ITシニアマネジャーは以下のような導入効果説明をした。
たくさんの時間がかかる簡単でつまらない仕事をRPAに任せることで、社員をより価値のある仕事に当たらせることができるようになった。
立信会計事務所は今後も、今までの導入で積んだ経験を基づいて各拠点にRPAソリューションの導入を広げ、より大きな業務効率化とコスト削減効果が期待される。
参考記事：https://www.weeklybcn.com/journal/news/detail/20190121_165985.html
2019.01.24
RPA（Robotic Process Automation）とはロボットによるタスクの自動化を可能にした技術またはそのツールソフトのことです。
近ごろではあらゆる業界に浸透しており、例えば某大手銀行では RPA の活用により数千から数万の人員を削減するというニュースも耳にしました。
RPA にはいくつかの技術的ステージが存在し、人が手でやっている単純作業をマクロ機能で自動化するようなレベルから、最近流行りの AI・機械学習を絡ませてロボットに判断を委ねて人が考え実行していたような業務まで自動化するといったハイレベルなものまで存在します。
また、RPA ソフトの種類も国内外で多く存在し、日本企業がよく耳にするだろう有名どころとしては、「BizRobo」「WinActor」「UiPath」などが挙げられます。
上記に述べたように、一言で RPA といってもソフトの種類やシステムの構築レベルなど様々あります。
今回、当記事でご紹介する事例におきましては、「人が手でやっていた単純作業」を「UiPath」を用いて自動化するといった内容となります。
もちろん RPA のソフトだけではなく、作業において使用する他のアプリケーションも存在するため、それらアプリケーションと RPA との連携等についても述べさせていただきます。
当事例におきまして深堀すればいくらでも記事が書けるかもしれませんが、今回は事例内容の基本、おさえておくポイントをまとめてなるべく簡潔に書いていこうと思います。
当記事を読み、湧いてきたアイデアや疑問点等を皆様の自動化案件に活かしていただけたら幸いです。
今回の RPA 活用の事例は「問い合わせフォーム」です。顧客が予約したい日付を問合せしてくるので、予約可能かどうかを調べて問い合わせに答えるといった内容です。
簡単に現行の流れを下記に示します。
現行の流れとしまして、まず顧客が予約の問合せをメールにて行います。
次にスタッフがメールを確認し、受信を確認した場合は問い合わせ内容を確認します。
メールに記載された問い合わせ内容を WEB 上の予約スケジュールフォームにて確認し、空きがある時間帯もしくは空きなしといった内容の回答を顧客にメールにて返信します。
現行のタスクフローを簡単に上記にまとめましたが、ここで業務を自動化するうえで注意していただきたいポイントが 1 点あります。
それは、現行のやり方ありきで自動化を進めないことです。
具体的に当事例にて説明をします。
まず、当事例の現行タスクフローではじめに登場するのが「顧客がメールにて問合せを行う」です。
文章やフローで記述すると何も問題のない内容です。
しかし、実際にこのフローの中身を考えてみると、顧客が送ってくるメールは人によって問合せ方や本文がバラバラなことに気が付きます。
スタッフがメールの確認をするのであればある程度の文章のばらつきも問題なく問い合わせ内容を確認できますが、機械としてはものによっては日付の記述形式の違いであっても大きなエラーに繋がってしまいます。
そのため、現行のやり方をそのまま採用するのではなく、自動化するうえでどこかに問題点はないかを検討し、場合に応じて現行のタスクフローを変更することも考えてみてください。
今回はこの問題への対応として、無料サービスによる問合せフォームの活用を採用しました。
顧客には問合せフォームにて問合せを入力していただき、その内容を RPA で取得・確認するといったフローへの変更です。
次のポイントとして一度検討していただきたい事が、RPA とは別のプログラムを場面に合わせて使用するということです。
今回の事例で新規採用した問合せフォームですが、このフォームに入力された情報の取得を RPA で実現することは確かに可能です。
しかし、『ローカルに圧縮ファイルをダウンロードしてファイルを解凍して過去の内容と突き合わせて最新の問合せを確認して…』といった RPA 化するとやや複雑なフローになってしまいます。
そこで今回は当フォームの WEB サービスで使用可能であったスクリプト言語を使用することで、問い合わせがあったタイミングで問い合わせ内容をまとめて自分宛にメールを送るといった仕組みを構築しました。
この方法をとることで RPA のフローとしては、『メールサーバー特定フォルダの新規メールを見に行き、決められたレイアウトのメール本文から問合せ内容を取得する』といったシンプルなフローで済むようになりました。
もちろん今回はたまたまこのスクリプト言語が使用可能であったのですが、この方法をとらないにしても複雑なフローの中でより良い方法が無いかを何度か見つめなおすことは重要なことです。
例えば、圧縮ファイルをローカルにダウンロードしてくる方法をとったとしても、ファイルの解凍を RPA で「ファイルを右クリックして解凍を選んで…」といったフローを組むと複雑でエラーが起こりやすく、処理時間もかかってしまいますが、RPA の多くの製品はスクリプトを埋め込むことが可能なため、特定パスのファイルを解凍するスクリプトを埋め込む 1 つのアクティビティを用意できればシンプルで確実、処理の早いフローへと変わっていきます。
RPA のマクロ機能は確かに簡単で便利ですが、初めのうちはここの部分はプログラムで簡単にできないか、もっとシンプルなフローにできないかを常に考えながら構築することでより良いシステムが構築できるかもしれません。
このように各ポイントをおさえながら残りの予約状況の確認と返信も自動化していきました。
今回の事例では「メールサービス」「問合せフォームサービス」「予約スケジュールフォーム」といった様々な WEB サービスを使用しています。
システムや言語によっては、現在使用している WEB サービスやアプリケーションでなくてはうまく動作しないことや、改修に多くのコストを要するという状況はおおいに考えられます。
そのため、WEB サービスやアプリケーションの使用可能な限りぎりぎりまで使用して急な使用停止に対応できないという現場も存在します。
特定のサービスやアプリケーションに縛られることなく、いくつもの WEB サービスやアプリケーションと連携を取りながらタスクをこなせるというのはRPA の最大のポイントでもあります。
その特徴を活かし、現在使用しているサービスやアプリケーションについても今後のサポート状況やバージョン、運用を一度整理して RPA 化を機にこのまま使用するのか変更するのかを検討してみるのもいいかと思います。
今回の RPA 化に基づくタスクフローを改めてまとめてみます。
ここで改めて当事例を RPA で自動化したことによるメリット・効果について考えてみましょう。
まずメリットですが、第一に挙げられるのが人件費削減です。
人件費としては、給与を払うほかにも教育費用もかかってきます。
スタッフを雇う場合にはひとが入れ替わるたびに教育費用がかかり、入れ替わりのタイミングでは人件費が倍かかってきてしまうことも考えられます。
RPA で自動化した場合には日ごろの人件費だけでなく、教育費や入れ替わりのタイミングでかかるコストもおさえることができます。
次に、休憩時間や営業時間外のタイミングでも顧客の問い合わせに対応可能ということもメリットといえるでしょう。
顧客としてもスケジュール調整はスムーズに行いたいものです。
そのため、なるべくストレスを与えない運用というのは顧客の定着や企業のイメージアップにもつながります。
また、RPAは比較的に誰であっても簡単に触ることができます。
そのため、多少の変更であれば改修を委託せずに可能ですし、相談のみのコストでも解決できるかもしれません。
これはガチガチのプログラミングでシステムを構築するのに比べてもメリットといえるでしょう。
効果をまとめると以下のようになります。
・人件費削減：給与 + 教育費 + スタッフ入れ替え時のコスト
・顧客定着、企業イメージアップ：問合せの 24 時間対応
・容易なサービス変更：低コストでの対応 + 連携サービス等の変更が容易
今回の事例で伝えたかったポイントは、「タスクフローの見直しの大切さ」「他のプログラム活用でのシステム全体の性能向上」「WEB サービスやアプリケーションに縛られない柔軟な対応」です。
当事例に関わらず、システムを構築するうえで現在の業務・タスクのフローや、使用しているサービス・アプリケーションの見直しというのは大変重要になってきます。
更に言ってしまうと、全ての業務に対してフローや関連サービス・アプリケーションをまとめておくことで、サービスサポート終了時の迅速な対応や、IT 投資時のコスト削減など様々なメリットを得ることができるでしょう。
また、何を使用してシステム構築するかが決定していたとしても、開発コスト、メンテナンスコストなどを常に考えて違う視点から検討してみるというのも重要なポイントだと私は考えます。
最後に、当事例で述べたポイントを参考に、またははじめにも言いましたが当記事を読むことで湧いたアイデアや疑問点を各々の RPA・システム構築の案件に役立てていただけたら幸いでございます。
2019.01.23
株式会社LIXIL（代表取締役会長：山梨 広一、本社事業所：東京都千代田区、以下：LIXIL）は自社のRPA導入に向けてRPA活用人材の育成規模の拡大を図っている。
RPAを導入するにあたって、今後RPAを活用できる人材を増やしていく狙いだ。
実際には、今年の3月までに700人の従業員をRPA研修へ参加させる。
さらに、RPA開発についても開発可能人材を155人から500人に増やしていく見込みだ。
現場主導でRPAの適用を行うために、専用のIT部門の担当者ではない社員がスキルを磨くのを目的としている。
LIXILは昨年6月にRPA導入を開始しており、Excelへの記入とその内容のメール送信のような単純作業を含めた業務の自動化を図っている。
特に、RPA導入に向けて現場側からの適用拡大を重視している。
費用対効果が小さい業務に関しても、現場側の負担を軽減するためにRPA導入を早めていく見込みだ。
さらに、RPA化に向けた暗号化のルールや内部統制については情報システム本部が一元管理するが、どの業務をRPA化したかどうかについてはデータベースを作ることで全体で共有していく。
住宅業としては、住友林業株式会社（代表取締役会長：矢野 龍 、本社：東京都千代田、以下：住友林業）でも早くからRPA開発が行われており、2017年時点で月間130時間もの業務を自動化している。
住友林業では、働き方改革を推進するにあたって、総務人事部ではなくIT部門の人材が積極的にリードしてRPA開発を行っている。
ここでのポイントは「業務全体を見直すのではなく、作業の部分最適をすること」であるとしている。
これらの詳しい内容や、住友林業についてRPA導入の背景、過程などは以下の記事にて説明している。
参考記事：LIXILがRPA導入拡大に一手、開発可能な人材３倍以上に
2019.01.22
近年、RPAという言葉が世を騒がせています。
RPAとは、Robotic Process Automation (ロボティック・プロセス・オートメーション、直訳では「ロボットによる動作の自動化」)の略語となっています。
PC上における事務作業のうち、行程が決まっていて、マニュアルさえあれば誰でもできるような作業を、RPA専用ソフトによって自動化するロボットを作り、ロボットが自動でスピーディに行うことで、人が対応するよりも短い時間でより正確に業務を進めてくれる業務効率化の方法です。
まず、PRAが導入されて良い点は、業務上において人手不足という深刻な問題において、ロボットが人手を補ってくれることです。
特に地方では、人口減少と共に働き盛りの若手が仕事を求め都心に集まる傾向にあり、より過疎化が深刻化します。
その一方で、都心では人口減少が地方に比べ緩やかになるものの、やはりそれも時間の問題で徐々に減少していくことが予想されています。
2015年の国勢調査によると、日本の将来人口推移グラフでは2015年の時点で国民人口が1.27億人であったのに対し、 2030年には1.19億人、2050年代には1億人を下回ると考えられています。
（出典）平成29年度 高齢化の状況及び高齢社会対策の実施状況 内閣府：
http://www.garbagenews.net/archives/1999775.html
このような少子高齢化の影響で人手不足が深刻な問題となりつつある日本において、このPRAが大いに注目されてきています。
ロボットでもできる作業を自動化させることで人手を確保し、少ない人数でも多くの業務がこなせるようになるからです。
また、私たちは人間にしかできないクリエイティブな仕事に専念することができるので、その企業や社会全体の発展にもつながっていくでしょう。
しかしその一方で、PRA化などのIT化が要因で、私たちの仕事の種類は間違いなく変化していくと考えられます。
RPAが社会に普及していく中で、そこには、これまで述べてきたような良いことばかりではなく、私たちが恐れていることも起こり得る可能性があります。
RPAがもたらす社会への影響とはどんなものなのでしょうか。
まず、予想されることの一つとして、将来私たちの業種の変化が加速し、今持っているスキルが5年後10年後には役に立たないものになっているかもしれません。
定型化された簡易的な業務は全てロボットに置き換えられ、それを生業としていた人たちは仕事を奪われるでしょう。
そうならないように、私たちは常に将来を見据えて仕事を選ばなければなりません。
将来なくならない仕事の一つにエンジニアの仕事が挙げられます。
予想される未来の職種の割合を現在のものと比較すると、ITエンジニアがダントツで増えるだろうと考えられています。
恐らく世界の生産に関わるほとんどの仕組みがシステム化されると、運用する人間が減り、働く人のほとんどがそういったシステムを組み立てていく仕事になるでしょう。
よって、将来は仕事の7割くらいがITエンジニアの仕事になっていると考えられます。
最近では事務職の人が自分の業務をRPA化するため、自らRPAエンジニアに転職したという事例を耳にします。
業務をRPA化する上で、そのプロセスに一番理解が深い者がプログラムを組み立てるというのはとても理にかなっています。
能力のある人は、このようにいくらでも自分を発展させていくことができるでしょう。
しかし、人間の能力には適正があり、プログラミングをはじめロボットが代用できないような創造的な仕事に向いている人はいいですが、そうでない人もたくさんいると思います。
ITが進化していくに連れ、その進化は倍々ゲームで更に加速していきます。
このような過渡期に生きている私たちはどのようにして時代を乗り越えていくべきなのでしょうか。
「人の温もりが必要な仕事」は今後も残る。
そう筆者は思っています。
たとえば、接客業一つとっても、無表情で愛想がない事務的な接客はロボットに置き換えられても良いと思っています。
一方、人間味あふれる笑顔と会話でほっこりするような接客なら、顧客は心を癒されます。
ロボットはできない、人の温もりを感じられるような接客は今後も付加価値として生き残るでしょう。
癒しの能力で言えば、「カウンセラー」の仕事も今後生き続けるでしょう。
人間社会で生きていくということに困難を感じる人はたくさんいると思います。
心が鬱っぽくなることや、トラウマに悩まされる人も一定数はいるでしょう。
そんな時、悩みを聞いて、心に寄り添ってくれるカウンセラーは必要不可欠な存在です。
そして、その人を励ましプラスのエネルギーを生み出すというのは、人にしかできません。
心の癒しと対称的なところでいうと、体の疲れを癒す、「マッサージ師」。
これも、完全にはロボットに置き換わることはないと筆者は考えます。
ただ、マッサージチェアがあるように、何割かは機械に置き換わると思うので、どのくらいの割合が人の仕事として生き残るかは分かりません。
しかし、人の手で行うからこそ、身体の凝っている部分を感じ取り、力の入れ加減を調整することもできます。
気功でも知られるように、人の手からはエネルギーが出ているという説もあります。
これは機械に置き換えることはできません。
接客業、カウンセラー、マッサージ師とみてきましたが、どの職業においてもこの先は、「いかに人間でしかできない部分を極めていくか＝プロフェッショナリズム」が問われてきます。
人間的な感情や寄り添いの気持ちを持つということは、将来それが必要となる仕事に大いに生かされるのです。
このように、創造的な仕事と人間的な仕事の二つが残っていくと考えられますが、結局どちらにも適正がなく、職を失う人たちは今後増えると思われます。
その場合、社会の情勢において経済格差が開き、アメリカの様に、富裕層と貧困層の二極化が進み、貧富の差は街の治安を悪くするなどの悪影響にも繋がります。
そうならない為にも、国が国民全員に生活するためのベースとなる資金を無償で分け与えるような社会制度（ベーシックインカム）が日本でも導入されれば良いと筆者個人は思っています。
これは既に北欧圏で始まっているそうです。
働いている側にとっては、自分たちの税金がそういうところにあてがわれるのはまっぴらごめんだという人もいるでしょう。
しかし、今でも稼げば稼ぐほど税金の割合は高くなる仕組みです。
例えば健康保険をとっても、必要とする人にしか支払われないのは不平等とも捉えられます。
なので、金銭として少しでも平等に分け与えられる仕組みがある方が良いのではないでしょうか。
現代は一次産業、二次産業が既に自動化されて、三次産業が機械化の対象となっている時代となっています。
ITの成長は今後、曲線を描いて登っていく二次関数グラフのように拡大化していくでしょう。
2045年には人工知能(AI)が人間の能力を超える「シンギュラリティ」を迎えると言われています。
その頃には、今では世に出始めたばかりのロボットが、昔のテレビや携帯のように当たり前に普及してくる時代がやって来ます。
その時代には、人間が生きるだけに必要な食糧や家屋がシステム化によって簡単に準備、管理される時代となるのです。
その先にいつか、「将来働かなくても良くなる時代」が来るのではないでしょうか。
2019.01.21
UiPathで作成したロボットを実行する方法が複数あることをご存知でしょうか。
今回はその実行方法の1つである「Debug（デバッグ）」について、実際にUiPath Studioで作成したロボットを利用しながらご紹介していこうと思います。
今回は、
あるエクセルファイルから取得した情報を、別のエクセルファイルに出力するロボットを用意しました。
こちらがロボットの一連の処理のながれです。
2-1. チェックOKの場合⇒ログに処理開始のメッセージを出力
2-2. チェックNGの場合⇒エラー処理を行う
3-1. 新しく追加する商品情報があった場合⇒
3-1-1. 読み込んだ商品をエクセルファイル「商品データ.xlsx」に出力
3-1-2. ログに登録成功のメッセージを出力
3-2. 新しく追加する商品情報がなかった場合⇒
3-2.1 ログに登録データなしのメッセージを出力
▽商品登録ロボットフォルダ
▽データフォルダ
・登録用データ.xlsx
・商品データ.xlsx
・Main.xaml
はじめに「Debug（デバッグ）」とはどういったものなのか簡単にご説明します。
デバッグとは、作成したプログラムをテストして処理の不具合である「バグ」を発見し取り除く作業のことです。
次に、UiPath Studioでのデバッグ機能についてご紹介いたします。
「デバッグ」をクリックまたは、「F7キー」で、作成したプロジェクトをデバッグで実行することができます。
・実行中のアクティビティがハイライト表示されます。
・デバッグ中だけに表示される値の確認が可能なパネル（ローカルパネル）が表示されます。
・出力パネルには詳細なログが表示されます。
ブレークポイントとは、デバック実行中に処理を一時停止し、その時点での変数の中身を確認することができます。
ある時点での変数の中身やアクティビティ内の詳細な動作を確認したい場合に、確認したい処理の前後または該当の処理を選択し、「ブレークポイント」をクリックまたは、「F9キー」でブレークポイントを設定し処理を一時停止して確認できます。
ここでは、
・エクセルファイルから取得した変数の確認
・ifアクティビティ内の動作確認
を行いたいので、下記の3か所にブレークポイントを設定しました。
ブレークポイントで処理が一時停止しても、再度「デバッグ」を実行すると、次のブレークポイントまで処理が進みます。
このときに、ブレークポイントが設定されていない場合は最後まで処理が実行されてしまいます。
次に、処理を手動で進めることができる機能についてご紹介します。
アクティビティ内での詳細な処理内容を1つずつ実行することができ、その時の変数になにが入っているのか、どういった処理が実行されているのか確認することができます。
アクティビティ単位でデバッグ処理を進めることができます。
ステップイン同様、変数の中身を確認することが可能です。
今回の場合、
で「ステップオーバー」を使用すると、ifアクティビティ内の詳細な処理の内容までは確認することができません。
ifアクティビティ内での動きを確認したい…！
そういった場合は、「ステップイン」を使用することで、Ifアクティビティ内の詳細な処理内容を確認することができます。
それでは、ここまでにご紹介した機能を使用して実際にデバッグで商品登録ロボットを実行し、前述した変数の値とifアクティビティ内の動作を確認してみましょう。
①ブレークポイントを設定
デバッグ実行前に、一時停止したいアクティビティを選択し「ブレークポイント」を設定します。
②デバッグ実行
「デバッグ」をクリックするか、「F7キー」でデバッグ実行します。
最初に設定したブレークポイントで処理が一時停止しています。
また、実行中のアクティビティが黄色で色付けされます。
「ローカルパネル」：処理中の変数の中身を確認することができます。
「出力パネル」：実行されたアクティビティログを確認することができます。
この時点ではまだ「登録用データ.xlsx」から商品情報を取得していないので、「entryData」はnullのままです。
⇒「null」とは、変数の中身に何も値が入っていないことを表します。
それでは「登録データを読み込む」処理を通過してみましょう。
③ステップイン：登録データを読み込む
「ステップイン」をクリックすると登録データが取得され、次の登録データのチェックへと進みます。
エクセルファイルを読み込むアクティビティが実行されたため、「entryData」に取得したデータが入っています。
すべての中身を確認するため、「entryData」の値の部分にカーソルをあてると、虫眼鏡マークが表示されるので、クリックします。
このように現在の「entryData」の中身がすべて表示されます。
登録用に用意したエクセルファイルの商品情報です。
取得内容が一致しているので想定通りの結果が得られたことがわかりました。
「ステップイン」をクリックし、次のアクティビティに進みましょう。
④ステップイン：登録データのチェック
③で確認した通り、「entryData」には、「商品ID」、「商品名」、「カテゴリー」、「単価」の計4つのカラムが存在しているため、ifアクティビティの条件に一致することがわかります。
想定通りにThenセクションの「チェックOK」シーケンスに処理が進みました。
次のブレークポイントまで進みたいので、「続行」をクリックします。
デバッグ実行中に「続行」（元々はデバッグと表示されていたアイコン）をクリックすると、次のブレークポイントまで処理が進みます。
⑤ステップイン：新規登録データの存在チェック
ここではifアクティビティ内の動作確認をしたいので、ステップインを使用して1つずつ処理を追ってみましょう。
「entryData」には3件のデータが入っていたことを③で確認しました。
今回のifアクティビティの条件に一致しているため、「新規登録あり」のシーケンスへ進みます。
「続行」をクリックまたは、「F7キー」で最後まで実行してみましょう。
実行が終了すると、ローカルパネルが非表示になりUiPath Studioの表示が元に戻ります。
出力パネルで実行ログを確認してみましょう。
商品登録ロボットが正常に終了したことがわかりました。
次に、追記したエクセルファイル「商品データ.xlsx」を確認してみましょう。
実行前の商品データ.xlsx
実行後の商品データ.xlsx
③で確認した「entryData」の中身が追記されています。
今回はデバッグで使用する基本的な機能についてご紹介しました。
UiPath Studioにはほかにもデバッグ実行時に使える機能があるので、興味があればぜひ試してみてください。
ローカルパネル以外にも、メッセージボックスアクティビティやWrite Lineアクティビティ（出力パネルにメッセージを出力）を使用して処理中の変数の中身の確認を行うこともできますので、あわせて使用してみるのも良いかもしれません。
次回はバグの対処についてご紹介しますのでよろしければご覧ください。
2019.01.18
RPAとはロボットにより業務プロセスを自動化することです。
従来の人力による業務補助に比べ、RPAを活用することで低いコストで業務効率化を実現できます。
一方、金融機関は正確さを高く求める現場です。
さらに、その一部の業務は定型かつ量が膨大となっているので、標準化がしやすくなっています。
実際に、RPA導入に対するのは非常に適切な現場ですので、その活用効果も期待できます。
したがって、 最近、金融機関のRPAの導入はよく見られます。
3大メガバンクはもちろん、各地方銀行も遅れていません。
我々はこれまでに多く金融機関の導入事例を紹介しました。以下の記事をご参考にしてください。
ケース１ ゆうちょ銀行、投資信託口座開設業務の効率化にRPAを導入
ケース2 京葉銀行、RPA化推進によって営業人員増員
本日は、日本国内最大手住宅ローン業務を行っている専門金融機関アルヒ株式会社のRPA導入事例を紹介したいと思います。
アルヒ株式会社は2017年にRPAを住宅ローンの申請業務に導入しました。
従来の住宅ローン審査の申込書と比べ、同時に提出される各確認証明書を記入科目を減らしていました。
具体的には、RPAシステムによる各書類のスキャンデータからOCRで直接データを抽出し、内容別に分類して社内の審査システムへ転記・完成していました。
RPAの導入により、アルヒ株式会社は従来の申込書で記入項目の最大半分を減らすことに成功しました。
今回、アルヒ株式会社以前の導入経験に基づいて、さらなるRPAの活用に進んできます。
具体的には、今まで住宅ローンの人力での審査からRPAによる自動判断へ変更しました。
この導入によって、住宅ローンの「簡易事前審査」の時間が、大幅削減しました。
担当者によると、
「熟練の担当者しかできない業務を経験が浅い担当者でもチェック対応が可能になるほか、チェックの標準化によるオペレーションミスの防止、店舗における人の処理時間を半分に短縮できるといった効果が見込まれる。」とのことで、さらなる業務の効率化を図っています。
一方、RPA導入で住宅ローン審査を効率化するだけではなく、アヒル株式会社は住宅ローンの進捗プロセスを見える化する「ARUHI navi」も提供し始めました。
今後、会社全体は積極的にIT化に進んで、業界トップシェアを目指しています。
参考記事：https://headlines.yahoo.co.jp/hl?a=20181227-00000054-impress-sci（リンク切れ）
2019.01.17
2019年春に、労働基準法の改定が見込まれていることもあり、社会は働き方改革の必要性に迫られており、企業は自社に具体的な施策を取り入れることが急務となっています。
そこで、今回のブログでは、働き方改革のテーマにフォーカスし、各企業における取り組み事例をご紹介したいと思います。
ここからは、実際に働き方改革の取り組みを行っている企業について、経団連が作成した「働き方改革事例集」を元に、
①「長時間労働の是正・休暇取得促進」
②「柔軟な働き方がしやすい環境整備」
③「テクノロジーの活用」
の観点から事例をご紹介したいと思います。
（アシックス）
海外の拠点や取引先とのやり取りに柔軟に対応可能で、労働時間の削減にもつながる柔軟な働き方としてフレックスタイム制度を導入。従来設けていたコアタイムについても撤廃している。単なる適用範囲の拡大ではなく、働きすぎを防止する対策にも取り組んでおり、
①フレックスオフデイ（公休日・年休以外で就労しない特別休暇を1日単位で取得可能とし、清算期間内での時間調整を行う）
②勤務間インターバル制度（前日の勤務終了から翌日の勤務開始まで11時間を確保する）
を設けている。
（セイコーエプソン）
同社では、フレックスタイムを全社員の9割が利用している。フレックスタイムを活用することで、休暇を取得するまでもない、短時間の用事に対応することができるようになり、育児や介護、通院などを理由に業務遂行上、時間的制約がある社員にとっても働きやすい職場環境を整備している。
（カゴメ）
本人の希望と上長の承認をベースとして、始業時刻を7時30分から10時までの間で30分刻み（6シフト）で変更できる。一方、選択制時差勤務制度の導入が難しい工場部門は、働きやすさ向上のための取り組みとして時間単位有給休暇制度を導入した。
（三井住友銀行）
従来から導入していた時差出勤制度について、これまでは業務都合・介護事由のみで利用を認めていたが、プライベートな事由全般に適用範囲を拡大すべく、2018年8月～10月まで、約20の部店でのトライアルを実施。
（カゴメ）
2017年10月からはスケジューラへの入力ルールを全社で統一した。スケジューラに入力した内容は社内の誰もが見ることができ、各々の繁閑や対応中の業務内容等、仕事の見える化が実現された。この見える化により、部門間での打ち合わせ調整や電話の取次の際の状況確認手間を以前と比べて格段に省くことができている。
（コクヨ）
2017年10月から2か月間、希望部門を対象に時間意識の向上を目的とした「働き方コミュニケーショントライアル」を実施した。この取り組みは、対象者が毎週金曜日に、翌週の残業時間及び出退勤無時間の予定と、業務計画をスケジューラに入力し、チームで共有するというもの。このようにチーム内で業務計画の共有をすることで、管理職はなぜ部下が時間外労働をしているのか一目でわかるようになった。
（アシックス）
グループ全体として海外拠点で働くスタッフが多いことや、退社時間の前倒しによるスポーツを含めたワークライフバランスに資する余暇時間を創出する目的から、サマータイムを導入している（7月～9月に始終業時間を1時間前倒し）。取引先でサマータイムを導入していない企業も多いことから、メールの署名にサマータイム実施中である旨を表記しているほか、グループ製品販売部門では、対応可能な時間帯の理解を求める声掛けを取引先に直接行っているなど、取引先に配慮をもとめる活動も実施している。
（アシックス）
サマータイムと同様の目的で、プレミアムフライデーも導入しており、月末最終金曜日は15時に退社することを推奨している。業務の状況で退社することが難しい部署については、退社がしやすい別の曜日に変更して実施するなど、フレキシブルな運用を行っている。
（三井住友銀行）
育児と仕事を両立している従業員が多いリテール部門の従業員を対象に、サテライトオフィス制度を設けている。これは所属部店とは異なる自宅や保育所の近隣店舗での勤務を認める制度であり、時間制約のある従業員が移動時間等を効率化できる制度として位置付けている。
（アビームコンサルティング）
2018年4月から、テレワーク制度「Free Location制度」を導入した。入社時研修期間中や疾病等により就業制限のある社員を除き、原則全社員が利用でき、全国に拠点を持つシェアオフィス事業者が提供するシェアオフィスでの勤務、モバイル勤務もできる。
（コクヨ）
2017年10月に品川にオフィスを移転。これまで複数のフロアに分かれていたオフィスを1,500坪の1フロアに集約した。新オフィスでは、部署の垣根を超えたコミュニケーションを活性化する狙いから、部署や打ち合わせスペースを区切る壁を設けず、社員が希望するエリアで働けるフリーアドレスを導入している。また、集中して資料つくり等を行うための作業用ゾーンや、リラックスできるハンモックゾーンのように、ゾーンによってテーマを設けることで、社員は仕事内容に合わせた最適な環境を選べるようになっている。
（サニーサイドアップ）
月に一度、外出・直帰・在宅ワークを推奨する制度。会社にこもらず外で仕事することでより自由な発想が生まれ、普段なかなか会えない相手とコミュニケーションをとるなど、時間と空間を効率的に、有効に使って業務に取り組むことを目的としている。
（ニコン）
集中的かつ効率的な業務遂行によって、生産性向上およびワーク・ライフ・バランスを推進するため、在宅勤務制度の利用を推進している。
（三井住友銀行）
2016年から在宅勤務制度を導入し、全従業員の3分の２を占める基幹職約18,000名が対象となっている。2018年7月～9月まで、制度の浸透を進めるべく「重点推進部署」を設け、頻度高く在宅勤務を活用する前提で、在宅勤務のインフラや同行に根付いた業務プロセスや職場風土等、在宅勤務の浸透に向けた各種課題解決への提言を受け、それらを1つ1つ実行する予定としている。
（アビームコンサルティング）
RPAツールの活用により、Webメール、ファイルサーバー、デスクトップ上のExcelなど、アプリケーションをまたいで発生する広範囲業務の自動化が可能となった。
（三井住友銀行）
本部業務の生産性向上・業務効率化の観点からRPAを2017年度から本格導入している。RPAの導入により、初年度1年間で、約700業務・110万時間分の作業時間を自動化することで、大きな余力を捻出している。具体例として、1日中データの入力・チェック業務を行っていた従業員が、当該業務を自動化したことで、担当業務を俯瞰的・客観的にとらえ、さらなる効率化・高度化や当該業務を管理する立場として業務全体の新緑管理を行うようになったほか、RPAでは代替できない「人ならではの業務」に多くの時間を割くことができるようになった。
（清水建設）
同社では、最先端技術を搭載した自律型ロボットが連携するシステム「シミズ・スマート・サイト」を現場に展開し、省人化に挑戦している。シミズ・スマート・サイトは、建物の三次元モデルであるBIM（Building Information Modeling）とAIを搭載した自律型ロボットが連携し、現場で人と一緒に作業をするというものであり、繰り返し作業をできるだけ軽減して生産性を向上させることを目指している。
いかがでしたでしょうか。今回は働き方改革の先進事例についてご紹介いたしました。今年はますます働き方改革の取り組みは活発になっていくことが想定されます。まずは先進企業の事例を参考に、自社に合う取り組みについてご検討してみてはいかがでしょうか。
＜参考Webサイト＞
「働き方改革事例集」（経団連）
https://www.keidanren.or.jp/policy/2018/104.pdf
2019.01.16
さくら情報システム株式会社（代表取締役社長：小西池 透、本社：東京都港区、以下：さくら情報システム）は2019年1月9日に新たに２つのRPAソフトウェアを発表した。
今回発表された、ソフトウェアは米UiPathが提供しているRPAソフトウェアである、UiPathを簡単に扱えるようにするためのソフトウェアである。
一つ目のソフトウェアは「秘書ロボ」と呼ばれるソフトウェアで、メールを介してロボットに指示を出すことが出来る。
このソフトウェアの利点は、使用するすべてのパソコンに対するライセンスを購入する必要がなくなることである。
従来では、使用するごとにライセンスが必要となっていたが、「秘書ロボ」を使用することでメールを介して指示ができるようになるため、ライセンス費用を抑えることができる。
これらは、交通費申請のような不特定多数が使用するような場面で有効的な手段である。
二つ目のソフトウェアは「さくっとロボ」と呼ばれるソフトウェアで、UiPathを簡単に使用できる。
利点としては、Excelを利用して開発・設定を行うことができることである。
これにより、開発が容易になることで開発期間が短くなり、導入後のメンテナンスも容易になる。
従来では、IDやパスワードのような操作のすべてのをUiPathでおこなってきたが、「さくっとロボ」を使用することにより、一連の作業において簡単な操作はUiPathで設定し、比較的煩雑な計算などはExcelの関数やマクロを使用することができる。
また、不具合が発生した場合でも、どこで停止したかどうかを簡単に確認することが出来る。
それぞれのリリース価格はライセンス数に応じての個別見積もりのようだ。
参考記事：さくら情報システムがUiPath導入を支援する簡易ロボット設定ツール「さくっとロボ」と自動メール応答ロボット「秘書ロボ」を1月9日から提供開始
2019.01.15
今回のコラムでは、医療業界の中でも特に製薬会社における業務改善（BPR）およびそこから浮かび上がってくるRPAの活用機会について述べたいと思います。
もともと、製薬業界は外部コンサルタントからすると、BPRの潜在機会が比較的大きいと見なされている業界です。
これは、この業界が特に日本において以下の特徴を持っていることがその一因ではないかと考えられます。
製薬会社ごとに得意となる領域は異なりますが、マーケットの規模が患者数に依存する業界のため、畢竟、1つの製剤でリーチできる売上の限界は早期に見通しが立ちます。
がん・心疾患・脳卒中といった三大疾病の領域においても競争環境が激しく、価格も固定ですので、自社の技術評価を冷徹に行えば期待できるシェアから売上の上限は自然と決まります。
また研究開発するにしても治験計画を綿密に立てねばならず、ジェネリックをするにしても特許切れの4～5年前から準備を開始していないと間に合いません。
つまり、製剤業界というものは「計画が命」の業界であり、天変地異や予測不可能な市況の変動による影響に翻弄されることが比較的少ない業界と言えます。
そのような業界の場合、売上を伸ばしていくためにはどのような思考を持つでしょうか。
もちろん1つの疾病領域内でシェアを伸ばしていく考えもあります。
例えば糖尿病の治療には注射と経口（タブレット）があります。
注射剤においても内訳で見ると今まで主流だったインシュリンもありますし、近年伸びているGLP-1受動体作動薬という分野もあります。
研究開発に膨大な金額と時間をかける製薬業界にとっては、同じ糖尿病の治療においてであっても製剤の種類を変えることでシェアアップを狙うことは確かに一番費用対効果の高い戦略です。
しかし、1つの対象疾病に会社の運命を託すのは、この業界が各種規制の影響を受けやすいことから、非常にリスクがあることです。
ケースは少ないですが仮に何かの疾病の治療薬で上市後に問題が見つかった場合、その疾病領域での製剤の取り扱いは全面的に見直しとなります。
そのようなリスクケースを想像すると、必然、製薬会社は一つの籠に卵を盛るような真似はせずに、リスク分散をできればしたいといいうのが心情です。
つまり、売り上げを伸ばすために、対象疾病の領域を増やし製剤ラインナップ拡大を目指す。
ただし、製薬業界は1製剤の研究開発に多大な投資と時間が必要な業界であり、それが対象疾病の領域を横に拡大する上でのネックともなっています。
この二律背反性がこの業界の特徴とも言えます。
対象疾病のラインナップ拡大については、自社努力で図るケースもありますが、M&Aを通じて広げていくケースが多いのもこの業界の特徴です。
対象となる疾病が異なれば、同じ病院内であっても担当医師が変わりますし、KOL（Key Opinion Leader）ももちろん変わります。
取引先となる病院側が変わるだけでなく、製薬会社内のR&D人材も変わり、製剤の種類によってロジ回りの協業相手も変わるケースが出てきます。
つまり、製剤ごとの専門性が高すぎるがゆえに、事業部間のシナジー、標準化機会が簡単には生まれず、放っておくと、各事業部が各々の論理に従った業務設計をしてしまいがちになる傾向があります。
ベンダー／サプライヤーの選定も事業部独自に行っており、コーポ―レートの視点で集約化することに対して神聖不可侵とされがちです。
経営層からしても、各事業部の専門性の壁を越えて効率化を推し進めるのは他の業界に比べて難易度の高い取り組みとなります。
これは外部コンサルタントからすると、翻って、潜在的なBPRの機会は大きいと言えます。
もちろん事業部間の専門性は十分に配慮しなければいけませんが、過去のプロジェクトの経験からすると、ドキュメンテーションの作業や、社内システム上での作業、そしてサプライヤー管理業務については標準化／効率化の余地が残されているまま放置されていることが多い印象です。
この社内システムが乱雑でかつシステム間の連携があまり取られていない傾向については、原因として先述した事業部ごとの独立性が高いことと、あとはM&Aが比較的多い業界であることが挙げられます。
これは今までの多くの製薬業界のクライアントを相手にした経験からですが、製薬業界にもSAPを始め業界標準化されたシステムは存在しますが、それとは別に個社ごとに独自に開発したシステムが数多く存在する印象です。
例えば、臨床試験フェーズのシステムについても、製剤開発用のシステムもあれば、医療機関側のモニタリングやサンプルデリバリーのシステム、あとはEDC(電子症例報告書)のシステムもあります。
あとはCT.govのような行政機関登録用のシステムがあるケースがあります。
あとは各種ベンダーや協力会社のサプライヤーマネジメント用のシステムも存在します。
これらのシステムが統合されたシステム思想のもとに導入されているのであれば、システム間連携への配慮もなされていると思いますが、ここで問題になるのがM&Aです。
先述したように、製剤ポートフォリオの拡大を志向するが故に製薬会社間のM&Aは積極的に行われています。
必然、2社それぞれの独自システムが併存する状態となります。
もちろん経営層としては最終的に1つの統合システムにまとめてしまいたいところですが、システムの統合は十全な準備が必要であり、かつ両社の事業部の専門性に配慮せねばならず、結果としてかなりの長い期間、各社の既存システムが残ることになります。
また一連の業務に関係するシステムが複数存在するため、仮にシステムの統合をするにしても一気に全てを行うことはできず、一つ一つ片付けていくことが求められます。
即ち、あるシステムは統合版になったが、別のシステムは過去の各社の既存システムをそのまま使用しているという状態になりがちだという事です。
こうなると、そのシステム間の非連携のシワ寄せは、人間である社員の双肩にかかってくることになります。
あるシステムから別のシステムにデータを連携させるために、人間側でデータフォーマットの加工・修正をしたり、一部の機能についてはシステムで対応していないので、人間が専用のエクセル管理帳票を作って対応したり、といったケースが頻発します。
このあたりの「システムtoシステム」や「システムtoエクセル」と言った領域は正にRPAの得意分野となりますので、RPAロボットの導入により社員の業務負担を大幅に軽減できることが期待されます。
これは特に日本における医療業界についてですが、医療機関側が市場の論理と逆行してフラグメンテッドな状態で成立し、かつ製薬会社との力関係においても医療機関側のパワーが相対的に強い特徴があります。
まず、中小病院がフラグメンテッドに存続している背景ですが、それは地域への医療サービスの提供という営利活動とは別の論理が強く働くことが理由です。
もちろん、この高齢化社会による医療福祉コストの増大を受け、行政で診療報酬改定や地域医療構想を掲げることで、各地域の医療体制を合併・再編を促したいという意向は垣間見れます。
しかし、これは一部の意欲的な地域では進んでおりますが、その進捗は地域によって未だかなり温度差がある状態です。
またこの医療機関においては、大学病院の存在も欠かせません。
特に地方では、このDPC病院のⅠ群に相当する大学病院が担う役割は大きく、それらの病院は、もともと地域に根差しており、独自の業務を志向、他病院との統合の可能性は限りなく低いです。
その他にも地方には県や市レベルの公立病院が多く存在し、これは医療サービス提供における地域格差を是正するためには、必要不可欠であり、今後も継続することは必定です。
つまり、他のB2Cの業態、例えばドラッグストアやコンビニといった効率性重視の世界と異なり、大手によりシェアの収斂、寡占化は生まれにくく、あくまで地域に根差した中小規模の病院の存続は今後も粘り強く続くと予想されます。
また、製薬会社と病院側の力関係についてですが、これは医師が高度な専門職であり、製剤の採用を決める事実上の意思決定者である以上、どの国においても医師の力は強くなるものです。
ただし、この医師側の力が強い傾向が特に顕著なのが日本ではないかという印象です。
これは日本の医療業界における電子化の取り組みが遅れ気味になっていることとも関係しています。
例えば、治験フェーズにおける製薬会社の業務の中に、CTR（治験依頼書）を治験責任医師（PI）向けに作成し、署名をもらう作業がGCPで義務付けられていますが、これら一連の作業において、製薬会社側は都度病院を訪問し、医師との面談を行っています。
これらの作業は実質、書面郵送＋メール／テレカンでの補足説明で済む内容なのですが、「直に訪問しないと医師に失礼」といった諸々の理由により、比較的中小の病院であっても製薬会社の社員が訪問しているのが実情ではないでしょうか。
このような業界慣習が医療業界では未だ根強く、他業界では効率化の観点から当然のようにしていることも依然として躊躇してるケースがよく散見されます。
また、病院からの見積書においても、製薬会社側にとっては自社フォーマットに統一して出して頂きたいところですが、力関係の弱さから病院側の個別フォーマットに従わざるを得ず、その結果、事務員による膨大な集計業務が発生しています。
このあたりの事情は業界慣習上、変えることが難しいのは重々承知しておりますが、他業界では効率化されて久しい膨大なBPR機会が野放しにされているのも事実ですので、何かしらの取り組みを検討する価値はあると思います。
特に、複数のフォーマットの異なる情報の集計作業は、RPAの得意分野でもあります。
ただ、それも数百のフォーマットとなるとRPA開発の手間がかかり費用対効果が合わなくなる恐れがあるので、自社内部での取り組みと並行して、SMOやCROといった医療機関と製薬会社の間に入っている仲介事業者に協力を仰ぎ、製薬会社側の非効率な業務を減らすといった工夫もありうるかと思います。
どの業界であっても、PESTで言うところのP（政治）の動向については注視が必要ですが、特にそのドライバーの影響が強いのが医療業界です。
近年は、欧米や日本といった先進国における新薬の世界同時開発の取り組みが標準的になりつつあり、各国法規制の標準化整備の流れはあります。
しかし、依然として、日本はPMDA、米国はFDAというように、国ごとの独自の規制管轄があります。
それは即ち、どのようなグローバル製薬メーカーであっても、少なからずのローカル業務が必ず発生するこということです。
このような場合、経理や人事労務と同様、治験や営業業務の一部を各国のアウトソーシング会社に外注することもできると思いますが、製薬会社自社内でもその各国の法規制に対応する部門を持つことは必須となります。
グローバル企業の場合、効率化の観点から、業務フローの標準化は必ず取り上げられるテーマとなりますが、その障壁となるのが、この「各国の法規制対応業務」になります。
ここで難しいのは、コーポレートの標準化／効率化推進側の責任者とって、どこまでが本当に法規制上必要なのか否かが容易に判別できないケースです。
現場担当者側が言う「日本では●●の工程は必須」という意見も、本当にその全てが必要なのか、それとも解釈次第では変更の余地があるのか、容易には分かりません。
筆者の経験では、薬品のパッケージング（包装）や治験薬のランダマイゼーション（割付）と言った業務で、そのような慣習上の独自業務がローカルに残ったままになっていたケースがあります。
つまり、もともと各国の法規制の関係上、ローカル業務が残りやすい業界であるために、実はただ単に「慣習上」残っていた独自業務も多分に潜んでいる可能性があるということです。
最後に、そもそもの業界の志向性です。
製薬会社自体は、民間企業であるため、営利活動を目的としておりますが、取引先となる医療機関はそうではありません。
社会福祉を担う重要な使命をもっており、そのことが少なからず、民間企業である製薬メーカーにも影響を及ぼします。この無意識下にあるプライド・矜持は文化風土となり、業界特有の考え方を醸成することになります。
例えば、他の業界であれば、顧客との取引規模や重要度によって露骨に対応を変えます。
キーアカウントとなる重要顧客については専門チームを設け、個別カスタマイズしたフォローも行いますが、重要でない顧客群に対しては十把一絡げにして、有無を言わさない標準フローで対応します。
これは生産性向上、効率化の観点から自ずと導き出される商売鉄則です。
もちろん、製薬業界においても同様の考えは出てきます。ただ、他の業界と比べてそこまで露骨に冷徹に徹底しきることが果たしてできるでしょうか。
極端なことを言うと、「取引を失ってまで、自社内の業務効率化を優先する」という判断をするか、ということです。
これは、「取引先が医療機関のみ」という市場が狭い業界ならではとも言えますし、「そもそも地域医療サービスの一端を担うべき製薬会社がそのようなマインドでいいのか」という自省の念から発する現象とも言えます。
また医療サービス、特に製薬は人命を扱う非常に重要で注意を要する仕事です。
PMDAを始めとする規制側だけでなく、マスコミも何か非倫理的な事が起これば非常に敏感に動き、世間の耳目を集めます。
これは、製薬会社側の業務で言うと、開発の段階で必要以上のステークホルダーへの承認作業に昇華します。
社外の関係者への説明責任は規制に定められていますし必須だと思われますが、社内においても諸々の部署の人間が開発段階から入り、巡回して承認を得ていくことになります。
これは、一概に悪いとはなりませんが、この傾向が増長されると「一見、開明的で民主的な承認工程だが、実は責任を曖昧にし『お見合い』による事故を増やす」結果になりかねません。
あまりにも多数の社内承認者が必要なワークフローであったり、二重・三重のチェックを要している業務については、今一度その工程が本質的に必要なのか吟味し、場合によっては承認フローの簡素化を検討することをお勧めします。
以上が、医療業界、特に製薬業界においてBPRおよびRPAによる業務改善機会が比較的多く眠っていることの論考となります。
次コラムでは具体的にどのようなBPR施策およびRPAのソリューションが適用できるのか、実例を踏まえて述べていきたいと思いますので乞うご期待ください。
2019.01.11
今まで紹介したRPA導入事例に、金融機関が大半を占めています。
それは、金融機関の業務には高精度と大量の作業量が要求され、RPAの導入に適するためです。
しかし、実際には、RPAシステムは、低コストで業務効率化を達成でき、労働力を節約させるために、さまざまな業界の企業に取り組んでいます。
今日は、2つ不動産会社の導入事例を紹介したいと思います。
ケース1 レオパレス21、業務自動化RPAソリューションを導入 過去73.1％の業務効率化を達成
昨年8月3日、レオパレス21は業務の自動化、効率化を目的としたRPA導入の一環として、NECのRPAソリューションを本社の8業務に導入することを発表しました。
実際に、レオパレス21は、今まで各部門の各種システムへのデータ入出力、集計など業務に月間1612時間の作業時間がかかりました。
RPA活用による導入済の8業務が73.1％の業務効率化を達成しました。
今後は、さらなるの作業自動化を図る、月間1,000時間の作業時間削減を目指します。
ケース２ アパマンショップ、 55店舗にRPAを導入 店舗あたり3.2時間作業時間を短縮
APAMAN子会社アパマンショップリーシングは、昨年4月10日から業務処理にRPAソリューション「Uipath」を導入すると発表しました。
今まで人工入力をしていた不動産情報の11のうち６ステップがRPAシステムで行うようになりました。
その結果、毎日1店舗平均あたり8時間程度かかる仕事を3.2時間の作業時間を短縮することを見込まれます。
40％の業務効率化を達成しました。
今後も、フランチャイズ加盟店にもRPAの利用を拡大していく意向です。
いかがでしょうか。不動産仲介は非常に競争が激しい業界です。
今のうちに、RPAシステムを活用して業務効率化を果たします。
その削減した事務作業時間を使って接客時間などにあて顧客対応力を高め、将来の人手不足に備えるようになるのは生き残るやり方かもしれません。
弊社では、RPA導入のご相談を承っております。
RPA導入についてご検討の方は、東京ビッグサイトで開催されるRPA導入無料相談会にてご予約ください。
参考記事：https://www.leopalace21.co.jp/news/2018/08
https://www.re-port.net/article/news/0000055031/
2019.01.10
参考記事：インターコム、Web-EDIの受注業務を自動化するRPAソフトを販売
株式会社インターコム（本社：東京都台東区、代表取締役会長 CEO：高橋 啓介、以下：インターコム）は2018年12月20日、Web-EDIの受注業務を自動化する「Biware EDI Station Auto Webオプション」を発表した。
「Biware EDI Station Auto Webオプション」は様々な業界における企業間取引を手助けするEDIソフトウェア「Biware EDI Station 2」のオプション機能として発表された。
「Biware EDI Station 2」とは、インターコムが提供するEDI（オンライン電子データ交換）サーバーソフトの一つである。
インターネットEDIプロトコルとレガシーEDIプロトコルを利用することが出来、これらを用いての企業間取引も可能である。
これらはEDIプロトコルを用いたEDIであり、このほかにもWeb-EDIを用いたEDIも存在する。
Web-EDIはWEbブラウザを通じて企業ごとに専用のシステムを構築している。
この場合、それぞれのシステムの管理に関する手作業での業務が多くなる。
そんな中、今回発表されたオプションはその上記の業務をRPAによって自動化しようとするものである。
今回の「Auto Webオプション」は、Web-EDI、すなわち、発注企業がEDI取引のために用意しているWebアプリケーション画面の操作を、RPA（ロボットによる業務自動化）機能によって自動化するソフトである。EDI Station 2とAuto Webオプションを併用することで、通信手順を使ったEDIからWeb-EDIまで、各種の受注業務を自動化できる。
（インターコム、Web-EDIの受注業務を自動化するRPAソフトを販売 IT Leaders）
ここでの特徴は、取引先ごとのレイアウト変更に影響されない言語解析構造型によるロボット操作が出来ることである。
さらに、セキュリティロックの状態でも処理を実行することが可能である。
これらにより従来人間が行っていた業務をミスなく正確に自動化することが可能になるだろう。
2019.01.09
今回は、Orchestrator のQueue(キュー)とTransaction(トランザクション)のご紹介前に、UiPath Orchestratorの登録方法をご説明します。
日本語に変更したい場合は、“English”の「▼」から“日本語”を選択し、“Become a tenant(テナントを作る)”をクリックして、テナントを作成します。
テナント名（任意の名前）、名、姓、メールアドレス、管理者パスワードを入力し、“利用規約に同意します”にチェックを入れて、“テナントを作成”をクリック。
※ユーザー名は変更不可のため、“admin”となります。
2回目以降、ログイン時に必要な情報は、テナント名、ユーザー名、パスワードです。
まず、一番右上にあるアルファベット2つ書かれたアイコンをクリックします。
選択画面が表示されるので、“ユーザー”をクリックしてください。
デフォルトでは、“ロール”に“ロボット”が追加されていないので、“アクティブ”の右側にカーソルを持っていき、“編集”をクリックします。
④と同じ画面で、“ロール”に“Robot”が追加されていることを確認してください。
これでadminユーザーにRobotの機能の権限も付与したことになります。
新たに3つのアイコンが表示されるため、一番左の“標準マシン”というアイコンをクリックして、新規マシンの設定を行います。
今回は、自分のPCで動かすため、PCのコンピューター名を設定し、“プロビジョン”をクリック。
また、仮想環境を追加したい場合には、サーバー名を設定します。
※コントロールパネルから“システム”で、“コンピュータ名”を参照してください。
プロビジョンすると、下の画面になります。
画面左上の“ロボット”と表示されているアイコンをクリックします。
新たに3つのアイコンが表示されるため、一番左の“標準マシン”というアイコンをクリックして、新規ロボットの設定を行います。
マシンが複数ある場合は、新規ロボットを動かしたいマシン名を選択してください。
名前：任意のロボット名
ドメイン名＼ユーザー名：マシンで設定したマシン名＼そのマシンのユーザー名
※マシンのユーザー名は、“コマンドプロンプト”を起動して、“set”と入力して表示される“C:\Users\〇〇”の○○の部分の名前です。
パスワード：設定したマシンを使用する際に使うパスワード。
タイプ：“Development”
ここまで設定したら、“作成”をクリック。
※ロボットを起動させる前に、UiPath Robotがインストール済みであることを確認してください。（UiPath Robotのインストール方法は別途記載します。）
アイコンを右クリックして、“設定”を選択します。
マシン名：Orchestratorの使用するマシン名
Orchestrator URL：https://platform.uipath.com/
マシンキー：Orchestratorの“マシン”画面で、該当マシンの欄の表示をクリックして、マシンキーをコピーしたものをペースト。
マシンキーの右のコピーアイコンをクリックして閉じる。
全て設定したら、“接続”をクリック。
“ステータス”が“接続中”に変更されたかを確認する。
また、“マシン”画面では、“インストールされたバージョン”が記載されます。
“ロボットグループ”は、複数のロボットを一つのグループにまとめて、同一処理を実行させることができます。
“ロボット”画面の“ロボットグループ”ページを開き、右上の“追加”アイコンをクリックします。
“ロボットグループ”の名前を設定して、“作成”をクリック。
作成したグループに、ロボットにチェックを入れて追加し、“更新”をクリックします。
これで、RobotGroop1にRobotが追加されました。
デザイン＞パブリッシュ をクリックして、Orchestratorに最新のプロジェクトファイルを送ります。
“プロセス”画面に移動して、実行したいプロセスを追加します。
パッケージ名：右の矢印アイコンから先ほど追加したパッケージを選択。
パッケージのバージョン：パッケージ名を選択すると自動でパブリッシュされた最新バージョンが入力されます。
“作成”をクリックすると、“プロセス”に新しく追加されていることが確認できます。
プロジェクトを実行する際には、“ジョブ”画面の“スタート”アイコンをクリック。
“プロセス”の右の矢印より、実行したい“プロセス”を選択して、プロセスを実行させるロボットにチェックを入れて、“開始”を選択すると、ロボットが処理を開始します。
※ロボットの処理実行の状態は、“ジョブ”画面で確認することができます。
以上で、Orchestrator登録からプロセス実行までの一連の流れが完了になります。
では続いて、Orchestratorの機能であるキューとトランザクションについてご説明します。
“キュー”とは、ひとつまたは複数の箱を収納する場所のことで、“キューアイテム“は、その場所（キュー）に収納されている、値の入った箱のことを呼びます。
”トランザクション“とは、キューアイテムの「処理」のことで、Orchestratorのトランザクションページでは、処理を実行したロボットや、現在の状況（ステータス）、指定された優先度などの情報を確認することができます。
また、Orchestrator上に収納された“キューアイテム”は、トランザクションが開始されると、“トランザクションアイテム”という呼び方に変わるため注意が必要です。
キューは、あるデータテーブルのデータを、複数のロボットが並行して処理する際に適した機能です。
ロボットAが処理したデータを、ロボットBが処理しないために、キューアイテムには“トランザクションステータス“が設けられており、複数のロボットで並行した処理を行うことができます。
UiPath Studioのアクティビティ “キューアイテムを追加”を実行すると、アイテムは“New(新規)”というステータスになり、トランザクションアイテムとして処理が可能になります。
その後、追加したアイテムを取得するなどの処理を行うことにより、ステータスは“InProgress(実行中)”となります。
しかし、アクティビティの “トランザクションアイテムを追加”を実行すると、（キューにアイテムを追加しただけですが）処理を実行しているアイテムが追加されたと認識されるため、トランザクションアイテムの“ステータス”は“InProgress(実行中)”となり、その後そのアイテムへの処理ができなくなってしまいます。
そのため、キューにアイテムを追加する際は、“トランザクションアイテムを追加”アクティビティではなく、“キューアイテムを追加”アクティビティを使用してください。
PC2台（2つのロボット）で並行処理した場合、キュー内にあるトランザクションアイテムごとに順番に処理される。
例）PC①→No１のトランザクションアイテム
PC②→No.2のトランザクションアイテム
PC①→No.3のトランザクションアイテム
PC②…
今回は、UiPath Orchestratorを実行するまでの流れと、Orchestratorで使えるキューとトランザクションの概念についてご紹介しました。
次回は、Orchestratorのキューとトランザクションについて、実践を交えてご紹介していきますので、お楽しみに！！
2019.01.08
参考記事：来客対応RPAサービスACALL(アコール)の窓口案内向けアプリ「ACALL FRONT」が神戸市東灘区役所に本格導入
ACALL株式会社（本社：兵庫県神戸市、代表取締役：長沼斉寿、以下：アコール）は2018年12月から、神戸市東灘区役所にRPAを用いたアプリ「ACALL FRONT（アコールフロント）」を本格導入を開始したと発表した。
アプリ「ACALL FRONT」は、アコールが提供する来客対応RPAサービスであり、神戸市東灘区との実証実験を経て開発されたサービスである。
これにより窓口の案内が従来以上にスムーズになる見込みだ。
従来の区役所では、来庁者を適切な窓口に案内するために、案内係を配置している。
しかし、現状では様々な地域のイベントなどがその時々に存在し、来庁者の問い合わせに対する業務は多岐にわたる。
実際、マニュアルの作成などもおこなっているとはいえ、現実は案内係個人のスキルに頼っている状況であるようだ。
そのため、サービスの均一化やコスト面などからも課題が出ていた。
この状況にメスを入れたのが来客対応RPAアプリである「ACALL FRONT（アコールフロント）」である。
「ACALL FRONT」はどの職員が担当した場合でも均一なサービスが提供できるようにマニュアルを日々蓄積し、誰でも検索可能にできるツールとして開発された。
実際に実証実験を行うことにより、効果の確認や昨日のブラッシュアップを行うことが可能であったようだ。
実証実験では、職員の案内不可件数は61.7％減少し、１件当たりの平均案内時間は36.9％減少することが可能であった。
ACALL株式会社については以下に実績などを引用しておく。
ACALL株式会社は、来客対応RPAサービス ACALL（アコール・https://www.acall.jp）を提供しております。ACALLは、アポイントから入館・受付・会議・退館に至る一連の来訪者応対の流れをクラウドで一元化します。それにより、受付業務や入退館管理業務、会議室管理業務における無駄を省いて生産性の向上を図るとともに、来訪者に新しいおもてなし体験を提供することで顧客とのリレーション強化に貢献するソリューションを提供しております。
【ACALL導入実績例】
株式会社三菱東京UFJ銀行様、東急不動産株式会社様、Sansan株式会社様、学校法人近畿大学様、トレンドマイクロ株式会社様、コニカミノルタ株式会社様、株式会社Francfranc様、C Channel株式会社様、スマートニュース株式会社様、freee株式会社様、さくらインターネット株式会社様、他多数（来客対応RPAサービスACALL(アコール)の窓口案内向けアプリ「ACALL FRONT」が神戸市東灘区役所に本格導入 PRTIMES）
今後本格導入後、統計的な課題解決がなされていくのかが問題になりそうだ。
また、市民の反応も大事にして開発していくべきだろう。
2019.01.07
開発を進めていく中で、必ず登場する「変数」ってどういうものかご存知でしょうか？
おそらくプログラミング未経験の方にとっては聞きなじみのない言葉だと思います。
私自身も開発を始めるまでは聞いたことすら無かった言葉でした。
今回は未経験でIT業界に入った自分が初期の段階でつまずいた「変数」について、UiPathを使いながらご紹介していこうと思います。
プログラミング言語において、「値を入れておく入れ物」です。
処理の中で
・値をいれる
・値の取り出し
が行えます。
変数に値を格納することを「代入」といいます。
代入にはある決まりがあります。
それは、変数を作成したとき（変数の宣言）に指定したデータ型に対応したものしか代入できません。
？データ型とは？
・String型⇒文字列
例：Hello、トマト、花、あいうえお 等
・Integer型⇒桁数が大きくない整数
例：1、1000 等
・double型⇒小数点
例：3.14、20.589、1.0 等
・boolean型⇒真（True）または偽（False）の真偽値
例：Ture または、False
など上記のもの以外にもたくさんあります。
実際にUiPathで変数を作成してみましょう。
最初に「text」という名前のString型の変数を作成（宣言）します。
アクティビティパネルから「シーケンスアクティビティ」をドラッグします。
次に「変数」をクリックし、「text」という名前のString型の変数を作成します。
先ほど作成したString型の変数 text に「Hello」を代入します。
値の代入には、「Assin（代入）アクティビティ」を使用します。
文字列は “”（ダブルコーテーション）で囲む決まりなので、右辺値の部分に「“Hello”」と入力します。
それでは変数textの中身を実際に確認してみましょう。
メッセージボックスアクティビティに変数名「text」を入力し、実行します。
「Hello」と入力されたメッセージボックスが表示されました。
この時点で変数textは「Hello」が代入されていることがわかります。
すでに「Hello」が代入されている変数 text にさらに「World」を代入したらどうなるでしょう。
次は、すでに値を保持している変数に対しての代入について説明していきたいと思います。
先ほどは空の変数に値「Hello」を代入したのですが、今度はすでに値が代入されている変数に対して代入を行うとどのような結果になるのか試してみます。
先ほどの変数textに「World」を代入し、実行してみましょう。
「World」と入力されたメッセージボックスが表示されました。
このように、同じ変数に対して新しい値を代入すると、古い値は削除され新しい値のみ保持されることがわかりました。
ここまではプログラミングを行っていく中でよく使用されるString型の変数について、実際にUiPathを使用してご紹介しました。
次にString型の変数と同じくらい使用する機会が多い、Integer型（数値）の変数についてご紹介したいと思います。
まず初めに、「2.String型の変数」と同様に、Integer型の変数を作成します。
新しく作成したInteger型の変数 numberに「1」を代入します。
先ほど文字列である「Hello」や「World」を代入する際に、“”（ダブルコーテーション）で値を囲んでいましたが、文字列以外の場合は何も囲まずに代入したい数値や真偽値などを右辺値に入力します。
今回の場合、代入する値は数値なのでそのまま代入したい「1」を右辺値に入力します。
String型の変数の時と同様に、メッセージボックスに今回作成した変数 number を表示させてみましょう。
メッセージボックスに変数名 number を入力したところ、エラー発生してしまいました。
「式 numberの処理中にコンパイルエラーが発生しました。Option Strict OnでIntegerからStringへの暗黙の型変換はできません。」
これは、メッセージボックスがString型（文字列）しか受け付けていないのに、Integer型（数値）の変数 number が設定されてしまったために発生したエラーです。
String型以外の変数は扱えないの・・・？
そんなことはありません。
こうした場合は、Integer型の変数を一時的にString型に変換することで解決できます。
変数名である「number」の後ろに、「.ToString」と入力してください。
先ほどまでのエラーが解決されました。
これはInteger型の変数であるnumberを「ToStringメソッド」を使用して、一時的にString型へ変換したためです。
String型にしたい変数名.ToString
それでは実行してみましょう。
変数numberに代入した「1」が表示されました。
次に計算式や変数と変数の計算について説明していきたいと思います。
変数には「Hello」や「1」などの値だけではなく、計算結果を代入したり、変数同士で計算したりと様々な値を代入できます。
イメージてきには、数学で登場した「x」や「y」と同じ意味です。
それでは先ほど作成したInteger型の変数numberに計算式「1+1」を代入し、実行してみましょう。
1+1の和が変数numberに代入されました。
「4.計算結果を求める」では、数値同士の計算結果をInteger型の変数numberに代入しました。
今回はInteger型の変数同士を計算し、その結果をさらに変数に代入してみましょう。
新たに計算用のInteger型の変数と、計算結果を代入するためのInteger型の変数を用意します。
さらに今回は変数numberとnumber2に初期値を設定してみます。
初期値とは、変数が宣言されたときにここで設定した値が代入されます。
今回はInteger型の変数answerに「number + 10 」の結果を代入しているので、メッセージボックスに「answer.ToString」と入力し、実行してみましょう。
変数numberに「1」が代入されているため、今回の場合は1+10の和である「11」が変数answerに代入されました。
次に変数と変数の計算結果をさらに変数に代入してみようと思います。
変数answerに「number + number2」を代入して、実行してみましょう。
変数numberには「1」が、変数number2には「5」が代入されているため、「1+5」の和である「6」が変数answerに代入されました。
先ほど変数answerには「number + 10」の和である「11」代入されていましたが、今回新しく「number + number2」の和「6」が代入されたため、古い値は削除され新しく「6」が代入されていることがわかります。
「2.String型の変数」でご紹介した、すでに値が代入されている変数に対して代入を行ったときと同様に、Integer型の変数でも同様のことが起こります。
これは、変数は新しい値を保持するようになっているため、変数の型が何であれ新しく代入された値を保持します。
画面から入力された文字列に文字列を連結してメッセージを表示するロボットを作成してみましょう。
アクティビティをパネルより、「シーケンス」をドラッグします。
「変数」をクリックし、
・入力された文字列を格納する、String型の変数 inputText
・表示用の文字列を格納する、String型の変数outputText
を作成します。
ユーザーに入力してもらうための「入力ダイアログアクティビティ」をアクティビティパネルからシーケンス内にドラッグしてください。
入力ダイアログアクティビティをクリックし、プロパティを開きます。
タイトルに「”タイトル”」、ラベルに「”ラベル”」、結果にString型の変数「inputText」を入力します。
入力ダイアログに入力された値と文字列「”が入力されました！”」を連結し、表示用のString型変数に代入します。
まず、代入アクティビティをシーケンスにドラッグしてください。
・左辺値（代入したい変数名）に、表示用のString型変数outputTextを入力
・右辺値（代入する値）に、inputText(入力した値を格納したString型変数) + “が入力されました！” を入力
それでは先ほど作成した表示用のString型の変数outputTextをメッセージボックスに設定し、実行してみましょう。
入力ダイアログが表示され、任意のメッセージを入力してください。
「OK」ボタンを押すと、入力した値が表示されます。
このように、「文字列 + 文字列」をString型の変数に代入すると、前後の文字列が連結されることがわかります。
変数はUiPpathにかぎらず、様々なプログラミング言語において重要な要素だと思うので、しっかり理解して開発を進めていくことが大切だと実際に業務を通して実感しました。
また、代入された変数の動きを想像することで、データの流れや処理の流れの理解がスムーズに進められるようになるかと思います。
これからプログラミングを始める方は変数と代入を理解しておくことをお勧めします。
2019.01.04
参考記事：RPAツール「WinActor」の認定研修制度を運用開始
NTTアドバンステクノロジ株式会社（本社：神奈川県川崎市、代表取締役社長：木村 丈治、以下NTT-AT）は2019年1月から、NTT-AT認定「WinActor」研修制度の運用を開始すると発表した。
この認定研修制度は、各ユーザーがWinActorを業務フローに応じて操作・運用する技術を身に着けることが可能である講習であることをNTT-ATが証明するものであるようだ。
それらは、各代理店等が開催しているWinActorの研修に与えられるものであり、この認定によってWinactorを扱う現場においてのトラブルに対する対応や効率的なRPAの運用が可能な技術者を育成することが可能である事を示す。
ではどのような試験によって研修制度が認定されるのか。
認定を得るためには、NTT-ATの提供している「Certification of Winactor（以下CWA）」という試験に合格する必要があるようだ。
このCWAは2018年8月から販売代理店向けに提供されているサービスで、理解度に応じて3つの認定を受けることが出来る。
以下が3つの認定コースである。
１．「Certified」
WinActor、RPAの基礎知識を習得している。
２．「Sales Certified」
Winactorの操作を熟知している。
３．「Technical Certified」
Winactor導入支援に向けた説明が出来る。
この中でも、三つ目の「Technical Certified」を取得した者のみがNTT-AT認定の講師として、研修を行える資格が与えられる。
上記の「Technical Certified」を取得した者が講師を務めるNTT-ATによって認定された研修についてはWinactor公式ページに今後記載予定であるようだ。
