効率2倍！？システム開発にもRPA

2018.11.26

投稿者: Kojima

この記事では以下のことがわかります
・RPAの誕生経緯の一つは、開発部門の試験自動化ニーズである
・テスト項目は開発工程のうち平均30～最大60%を占めている
・RPA導入は｢試験項目を明確化｣｢パーツを作る｣｢フローにあわせて組み替える｣だけ！

業務効率化といえばRPA、といっても過言ではないぐらいにRPAという言葉は浸透しつつあります。
しかしその対象はあくまで｢単純作業の自動化｣であって、開発のような｢ゼロからイチを作る｣現場には適合しない、と思っている人も多いのではないでしょうか。
実は、開発の現場はRPAを生み出した労働環境の一つなのです。
それは｢開発部門がRPAを開発した｣ということではなく、｢開発部門の要望によってRPAが誕生した｣ということです。それぐらい、開発の現場とRPAは親和性の高い関係性にあります。

開発の現場がRPAを生み出した

ゼロからイチを作ることが求められる｢開発｣という仕事は、たしかに一見RPAはなじまないように思われます。RPAとはイチを繰り返すためのツールだからです。
しかし、それでは開発部門に繰り返しの作業は存在しないのか、というとそんなことはありません。例えば部門共通の事務作業。開発部門といえども一般的な事務処理から逃れることはできませんね。しかしそれ以上に業務に直結しているのが｢テスト工程｣です。
事実、RPAの誕生経緯にはいくつかのパターンがありますが、そのうちの一つが｢開発の現場が使っていたテスト自動化ツール｣なのです。Automation Anywhereがその代表格で、元々の名前はTesting Anywhereといいました。
開発を｢コーディング｣｢試験｣の二つに大別してしまえば、｢試験｣は開発の半分に相当するわけで、ここを自動化できてしまえば業務効率は2倍になる、ともいえるかと思います。…まぁ、少々、いやかなり、乱暴な言い方ですが(笑)。
しかし独立行政法人情報処理推進機構（ＩＰＡ）の発行する｢ソフトウェア開発データ白書2016-2017｣によれば、｢結合テスト｣と｢総合テスト｣の工期をあわせると平均値で30%、最大値で60%にもなる、という結果も出ていますので、｢半分｣とは言わないまでも、かなり大きな部分を占めるのは確かなのではないでしょうか。それこそ｢RPAツールを生み出すぐらいには大きい｣といったところでしょう。
テスト工程は同じ作業の繰り返しですし、そうである必要があります。そこで、｢同じ作業の繰り返し｣を自動化し、プロジェクトの状況に応じて変化するテスト項目に対応して、柔軟かつ簡単に変更できるツールが求められRPAが生まれたのです。この経緯からすれば、まさに開発部門こそがRPAを導入すべき、という言い方もできるのではないでしょうか。

RPAでどのように自動化するのか？

さて、それではどのようにRPAを適用したらいいか、具体策が欲しいですよね？
開発部門の人には釈迦に説法なのかもしれませんが、そうはいっても畑違いで想像がつかないという人や、マネージャー層の人のためにも、大きく3つのステップに分けてご紹介したいと思います。

ステップ１：試験項目と実施方法を明確化する

ここが不明瞭な開発担当は存在しないかのように思われがちですが、私の経験では意外と明文化されていなかったり、｢○○を確認する｣とだけ指示されていて手法が示されていなかったりすることは多いです。まずは試験項目と実施方法を固めましょう。
これはRPA化する/しないに関わらず、｢業務標準化｣として必須のステップです。

ステップ２：試験項目を実施する｢パーツ｣を作る

試験項目と実施方法が固まったら、次に試験単発を実行する機能を作りましょう。試験内容が｢TeraTermでコマンドを投入｣のように、他の試験でも共通で利用できる動作に細分化できるならそのレベルまで細分化しておくとよいです。これが試験実施の｢パーツ｣となります。
この際、パーツ同士のデータのやり取りがスムーズになるようにパーツからのデータの入出力形式やパラメータ設定項目は共通化しておきましょう。私は過去にここをないがしろにして、折角パーツ化したのにあとから組み替える際にイチから作るのと近い時間がかかってしまったことがあります…。

ステップ３：試験フローを作成してパーツを組み合わせる

パーツが出来上がったら、あとは試験のフローにあわせてそのパーツを組み合わせていきます。フローがしっかりしていれば、かつパーツのデータ入出力形式を共通化できていれば、ここの作業は楽なものだと思います。
また、プロジェクトの開発状況に応じてフローは変化していくと思いますが、その場合もパーツは既にできているので変化したフローに応じて組みなおすだけです。プロジェクトが変わっても試験項目は共通で使えることは多いと思いますし、作ったパーツは末永く使える｢財産｣になると思います。

おわりに

いかがでしたか？クリエイティブな現場であり、一見するとRPAはなじまないかのように思える開発の現場でも、RPAの活用によって効率が大幅にアップすることがお分かりいただけたのではないかと思います。
最初にRPA化する際は、パーツの開発や試験項目の標準化などで少し時間がかかるかもしれませんが、試験を手動で実施する時間に比べればそれほどの差はないのではないかと思いますし、一度パーツを作り上げてしまえばあとは試験内容に応じてそのパーツを組み替えるだけなので充分にペイできる投資なのではないかと思います。
是非、この記事を参考にして開発の現場にもRPAを導入し、開発スピードを倍速化してみてください！