新人の私が初めてプロジェクトを担当した：RPAやってみた！Vol.1
はじめに
近年、業種・業態や規模の大小を問わず、業務効率化に向け多くの企業が取組むデジタル変革（DX）。三井情報でも社内のあちこちで業務のデジタル化が進められています。
そうした中、輸出入業務の一部をRPAで自動化する話がでてきて、その実装を当時社会人になりたてであった新人の“私”が担当することになりました。
今回は新人の私がはじめてRPAを実装してみた体験をもとに、「RPAってなに？」といったことから実装のプロセスまで、裏話を交えながら紹介いたします。
RPAってなに？
RPA（Robotic Process Automation）とは簡単に言うと人間の代わりに業務をこなしてくれる自動化ツールです。これまでは人が行っていた決まった手順の定型業務や事務作業など、繰り返し行うルーティンワークを「ロボット」と呼ばれるソフトウェアが代行します。
今、IT業界で最も盛り上がっている分野のひとつですが、一体RPAの何が良いのかというと・・・
まず、従来、人が行っていた作業を自動化することで、人件費の削減や、人手不足の改善、働き方改革の実現などに効果があります。さらに、浮いた時間で企画や提案といった、人間にしかできないような付加価値のある仕事に集中できる点も大きなメリットです。
一方で、「決められたこと以外はできない」というデメリットもあります。
実装したRPAのご紹介
依頼のあった部署のユーザは、それまで以下の定型業務を毎日行っていました。
① 業務で使用する共有PCにリモートデスクトップ(RDP/Remote Desktop Protocol)接続する。
② 輸出入許可申請用のアプリを使用して、受信した電文(輸出入許可書)を開く。
③ 多いときは20件以上、新規に受信した電文(輸出入許可書)を1件ずつ手作業でPDF形式に変換しBoxフォルダに保存する。
私たちは、RPAを使ってこの業務を自動化しました。実装したRPAの処理を簡単にまとめると、以下の図の通りになります。
図にしてみると、とてもシンプルな処理に見えます。実際、RPAで実現するべき業務はこのような単純作業です。ところが、、、実際にRPAを作り始めてみると、どうにも一筋縄ではいきませんでした。
プロジェクトが始まった
（１）仕事が来た
新人研修が終わって私が配属された部署は、社内システムの構築や他部署のプロジェクトへの技術支援に加え、新入社員向けのプログラミング研修を開催したり、技術的な研究を行ったりと、業務範囲がとても広く技術的な知識とスキルが必要とされる部署でした。そんな部署でも初めて扱うRPA業務を担当することになった私ですが、恥ずかしながらこのときはRPAという言葉すら知りませんでした。プロジェクトのキックオフミーティングでは、大勢の先輩方に囲まれITの専門用語も分からずメモを取るだけで精一杯でした。
このプロジェクトで何を実現したいのか、まず私は何をすればいいのか分からず、頭の中がモヤモヤしていました。
（２）RPAについて一から調べた
開発チームのメンバーもRPAは初めてでしたので、まずRPAとは何者なのかを調べてみることになりました。インターネットで「RPAとは」と検索してみたり、専門書で開発に使うフレームワークについて使い方や機能を調べたりしました。
ここで気づいたことは、調べて頭で理解して終わりにしてはいけないということです。開発で大切なのは「動くもの」を自分たちで作ることです。
例えば、『RPAではファイルを自動で開くことができる』という記事を見たとします。ここで、「そうなんだ」で終わるのではなくて、自分でファイルを自動で開く処理を作って本当にできるのか実験をする必要があります。この実験が成功して初めて、開発チームのメンバーに「RPAではファイルを自動で開くことができます」と報告することができるのです。
入社前はプログラミングなんて簡単にできてしまイメージを持っていましたが、実際にやってみると非常に地道なものでした。教科書通りのコードを書いても処理が動かないということは日常茶飯事で、実際に自分でコツコツ作ってみて確認しながら進めるしかない世界だと知りました。
（３）ユーザに話を聞いてみた
RPAについて調べつつ、実際にどんな業務を自動化したいのか、ユーザにヒアリングを開始しました。話を聞いているうちに、日々行っている業務に関連する電文の保存作業を自動化したいということが分かりました。
概要が分かった後も、開発チームのメンバーはヒアリングを続け更に細かいことも聞いていきます。電文を保存するときのファイル名の命名規則や、RPAで動かす予定のPCの性能、電文を受信するアプリケーションは常に起動しているのか、等々。やたらと細かいことまで質問をするので、このとき私はなんでそんなことまで聞くのか、RPAを作るのに関係あるのかと疑問に思いました。（しかし、この細かいヒアリングが重要であることを後々痛感します。）
また、ヒアリング後、今回はAs-Is（現状の業務内容のまとめ）としてここまでで聞いた内容を資料としてまとめました。ここで気づいたことは、資料を完成させてから上司にレビューをしてもらうのではなく、2割作成したらレビュー、5割作成したらレビューというように、資料作成の最初の段階から上司を巻き込む重要性です。
自分では「よくまとまった資料が完成した」と思っていても、他人から見たら読みづらいということや、資料構成など上司のイメージとかけ離れたものを作ってしまう可能性もあります。見やすく、目的に沿っていて、正しい内容が書かれている資料を作成するには細かな確認が必須です。
ただ、上司はとても忙しい。自分のこの業務に上司の時間を取ってもいいのか、迷惑でないか、お願いしても良いのか、判断に困るときがあります。そんなときは迷わず上司に時間を取ってもらいましょう。5分でも10分でも、もっと短い時間でもいいです。仕事をするときに報連相が大切とよく言いますが、これは自分から上司やチームのメンバーに報告や相談を行うことが大切です。
何か報告はあるか、困っていることはないか、と聞かれたら答えるのではなくて、些細な情報でも自分から発信することができるようになりました。
資料が完成したら、次はユーザに内容の認識齟齬が無いか確認します。資料があるからユーザの皆さん見て確認しておいてくださいね、とするのではなく、会議を設け、関係者を集め、細かい要件をひとつひとつ言葉に出して間違いがないか確認していきます。ユーザが伝えた内容を正しく理解したつもりでも、このプロセスで認識齟齬が見つかることもあり、資料にまとめ、ひとつひとつ一緒に確認することの重要性を学びました。
また、会議の雰囲気づくりも重要です。ユーザから業務内容や要望を聞き出すためには堅苦しすぎない、なんでも言いたくなるような空気感を作るとともに、「この人たちになら安心して開発をしてもらえそう」という信頼を得るために、堂々とまとめた要件を説明することが大切だと学びました。
（４）RPAを作ってみた
要件のヒアリングが終わり、RPAの調査・実装を進めました。ただここでも、RPAについて教えてくれる人はいないので自分たちで調べながら、実験しながら開発を進めていきます。
ここで開発チームのメンバーが要件定義で細かい内容をヒアリングしていた理由に気づきます。RPAはメモリをとても使うのでPCの性能を知っておく必要がありました。電文を受信するアプリケーションは起動している前提で自動化を行うのか、絶対に起動させなくてはならないのかで処理が全く異なりました。要件定義ではユーザの希望を聞くだけでなく、本当にRPAで実現できるか、実現が難しい場合はどう工夫して実現するかを考えてヒアリングをする必要があることを痛感しました。
一方で、実装を進めるうちに要件で聞いてないようなことがたくさん出てきました。例えば書式の異なる電文の内容を正しく理解したり、不定期に表示されるポップアップへの対応をしたり、普段人間が何気なく行う処理もRPAでは一つ一つ指示しないと行えません。最初の方でRPAには「決められたこと以外はできない」というデメリットがあるというお話をしましたが、この問題が大きな壁となりました。シンプルな処理を組めばいいと思っていましたが、段々と複雑になっていきます。この経験から、ユーザが習慣づいて無意識に行っている業務や、気づかないこと、知らないことがあるということを実感し、またユーザから要件を聞くだけでなく、自分でユーザ業務を深堀し、システム化できるレベルまで調べることの重要性を学びました。
こうして紆余曲折と沢山の学びを経て、なんとかRPA実装は完了しました。
ユーザにもRPAの動きを確認してもらい、同意を得て開発チームはホッと一安心。続けて、実際にRPAの保守運用を行うRPAに詳しい方に、実装したプログラムをレビューしてもらうことになりました。開発チームは実装が完了したので気分はルンルンです。
しかし、レビューをしてもらうと、予想外の結果となりました。
【執筆者】
橋本
現在、新入社員に対する開発技術研修の企画／運営及び社内の開発技術力強化に向けた仕組み作りに従事。
池田
入社直後に社内プロジェクトでRPAの開発に従事。現在は、新入社員に対する開発技術研修等を担当。
※本記事は、三井情報Webサイトで掲載しているMKIナレッジを転載したものです。