「RPA、取りあえずやってみよう」はダメ、正しい開発プロセスとは？

ユーザー部門自らが“取りあえず開発を始められる”ことが一つのメリットでもあるRPAだが、いつまでも考えなしに取りあえずやってみるだけでは、トラブルの絶えないロボが作られ続けることになってしまう。作り手の視点や、ちょっとした前準備が、現場で役立つ優秀なロボット開発につながるのだ。RPA開発の正しいステップとは何か――現場のユーザーでもできることを紹介する。

[樋口 匡, 浜村佳史，SHIFT]

　前回は、RPAロボット（以下、ロボ）が止まってしまう“ロボトラブル”の原因とその対策を説明した。RPAを開発する際に、業務を知っているユーザーの視点と、システムに詳しいシステム担当者の視点のどちらか一方でも欠ければ、トラブルの絶えないロボができてしまう。今回は、ロボトラブルの発生を予防し、RPAの導入で狙った投資対効果（ROI）を出すために、品質やコスト、時間を意識した正しい開発プロセスについて解説する。

1.「ロボの開発コストがかかる！」「ロボが止まる！」良くある現場の悩み

　ロボの開発は、「システム部門主導型」と「ユーザー部門主導型」の2パターンの体制で行うことが多い。企業の方針や、開発の規模に従って主導する部門は異なるが、それぞれ一長一短で課題がある。

　システム部門主導型は、システム部門またはシステム部門から発注を受けた開発ベンダーがロボ開発を行うパターンだ。ロボ化の範囲が大規模または複雑な場合に多く採用される。課題として、プロジェクトが重厚長大になり、コストや時間がかかる。

　一方、ユーザー部門主導型は、ユーザー部門が主体となり、ロボ開発を行うパターンだ。「取りあえずやってみよう」と小規模にRPA導入を始めた場合に多い。開発が場当たり的になりがちで、ロボットの品質が悪くなりやすいという課題がある。

図1　システム部門主導型

図2　ユーザー部門主導型

2.ロボの望ましい開発プロセスとは

　SHIFTは、ロボの業務設計および開発の各プロセスに、システム部門と現場のユーザー部門が参加し、タスクの完了状況を確認し合いながら進める手法を推奨している。

　ロボ開発の体制は企業によって異なるが、両部門の視点をロボ開発に取り入れることで、開発のやり直しといった無駄を防げる。また、両部門が関わることで、業務特性への考慮とシステムとしての構造整理が両立し、運用・保守フェーズでメンテナンスもしやすい。

図3　ロボの設計／開発工程における標準開発プロセス

　図3は、業務設計とロボ開発のプロセスを示した図だ。開発の規模や複雑度によってカスタマイズが必要だが、基本形として捉えていただきたい。次項では、図3における赤枠内の業務設計および開発プロセスで押さえるべきポイントを説明する。ロボ開発をシステム部門またはユーザー部門の双方で臨むことを意識しながら、これから紹介する開発のコツを実践してほしい。

3.業務設計（システム要件定義）を行う際のポイント

　RPAツールを使ってゼロから開発を始めようとしても、どこから何をロボ化すればよいかをイメージできないだろう。まずは、人間の動作をロボの機能に翻訳する作業が必要だ。現状の業務はどのように行われているかを詳細に確認し、ロボの操作にどう置き換えるのかを検討する。その後、ヒトとロボの作業の組み合わせを整理して、新たな業務として設計することが必要だ。業務設計のプロセスは、大きく以下3つのタスクで構成される。それぞれの内容を説明する。