要件定義とは、プロジェクトを始める前の段階で、システムに必要な機能や要求ををまとめる作業のことを言います。
RPAの場合は、主にRPAで自動化する一連の動きをまとめること、そしてシナリオ・ワークフローの形に落とし込みを行い、開発することを指しています。
この記事では、なにかと「難しい」と言われることの多い、RPAの要件定義について解説します。
できるだけ簡単に進めるにはどのようなポイントを抑えるべきか、そして失敗なく適切に要件定義と開発を実現するためのコツについてご紹介します。
RPAの要件定義はなぜ「難しい」？
RPAの要件定義の難しさには、主に2つの原因が隠れているようです。
- 業務がそもそも見える化されていないので、要件定義のどこから手を付ければいいのかわからない
- RPAでできることは「定型的な業務の自動化に限られている」にも関わらず、それ以外の業務にも広げようとしてしまうことがある
上記2つは、RPAツール導入および運用が失敗する原因にもなりがちなことです。
逆に適切な手順を踏んで要件定義を実施し、適切な業務へRPAを適用すると、シナリオ開発はやりやすくなるものです。
またRPAツールの導入が失敗に終わる可能性もぐっと低くできます。
RPAの要件定義は、シナリオ開発の基礎となる重要な部分です。要件定義ができないと開発ができません。
要件定義を簡単かつ確実に実施するには「そもそも簡単な作業の要件定義からはじめて、だんだん複雑なものへ移行していく」という前提を持っておくことがまず重要です。
RPAへの移行に適している業務とは
もともとRPAは定型的な作業の処理に強く、反対に判断や学習が必要な業務には不向きという特性を持っています。
AIほどの高度な判断・学習はRPAにはできません。
RPAツールは、手順が明確かつ単純であるPC操作を自動で再現するロボットです。
同じ仕事を正確に繰り返すので、きっちりと手順が決まっている仕事を自動化することは得意です。
そのためRPAの対象業務を決定する際には各業務のワークフローを見直し、単純作業に対してRPAを導入することで、より高い費用対効果を実現できます。
業務自動化をする前に、ワークフローは見える化できている？
先述の通り、RPAは定型業務の自動化を得意としています。
実際に自動化したい業務がRPAに適しているかどうかを見極めるためには、その業務のワークフローを見える化することが重要です。
以下2つの項目を確認することで、その業務がRPAでの自動化に適しているかどうかを判断することができます。
- 業務の手順が担当者から明確に説明可能である
- フローチャートや、手順書などで可視化できている
また一口に「定型業務」と言っても、工程の長さ・複雑さに違いがあるでしょう。
その場合はより単純な業務から、2〜3工程の作業を選んで要件定義を行い、RPAの導入を始めることをおすすめします。
徐々に工程が長いもの・複雑なものの要件定義を実施し、RPAを浸透させていくようなイメージを持つと導入を拡大しやすいです。
このように徐々にRPA運用を拡大していけば、既に作成された要件定義を似ている他の業務へ使いまわすことができ、効率が良いでしょう。
また見える化のプロセス図、フローチャートの形式に気を取られてしまうと、核心である「業務工程を正確に再現できているかどうか」が問題になることもあります。
これはRPAツールの導入の失敗にもつながります。
あくまでも、業務の可視化はRPAの要件定義およびシナリオ開発のために作っているもので、プロセス図やフローチャートの完成度を問われているのではありません。
まずは形式よりも、正確性を優先するようにします。その意味では「箇条書きで十分」と思っておきましょう。
【注意】非定型作業への導入は失敗の原因になり得る
1→2→3→4、と手順を踏むだけで完了するのが定型業務です。
「○○がどういう条件ではこう動く」といった工程が枝分かれするような業務は、枝分かれのところに「判断」が入りますので、RPAの得意とする定型業務であるとは言えません。
こうした業務は、RPAで対応できない業務なので、導入の失敗を呼び込んでしまいがちです。
RPA開発の要件定義・手順を解説
RPAの導入は、定型的かつ工程の少ない作業から始めるとうまく行くことが多いです。
このあたりは要件定義がそこまで難しくならないでしょう。
実際に要件定義が問題になるのは、さらに工程の長い作業です。
このような業務はワークフローの可視化から進め、要件定義およびシナリオ開発を、業務をよく知る担当者が中心となって手掛けていくことをおすすめします。
その上で、RPAの要件定義の部分は、ITサポート、プロジェクトチーム、システムエンジニアなどが補助をするのが理想です。
また現行のRPAのほとんどがプログラミング不要のシナリオ開発を可能としているため、このフェーズは業務担当者のみで進められる場合も多いです。
1. 作業の見える化と絞り込み
まずは、作業の可視化から始めましょう。
業務の可視化は、プロセス図・フロー図作成の中心になります。
シナリオ開発に伴う可視化になるため、最初は業務担当者なら誰でも書ける箇条書きから始めて、プロセス図・フロー図に移っていくようにします。
この点について、RPAの担当者が現場の従業員など業務の担当者からヒアリング→作業を可視化するという流れも多いようです。
この場合は、まず業務担当者から「正確に」手順を引き出すことにフォーカスし、直接担当者に記載してもらうことをおすすめします。
その際、手順をコマ送り式に記載しもらうようにし、抜けがないようにすることがポイントです。
PCの動きを一つ一つ再現することが重要ですので、どこかの操作を飛ばしている、ということがないか、確認してもらうようにします。
定型業務であるか、そうでないかの峻別は先ほどご説明した通り、1→2→3→4と順を追って作業をすると完了するもの＝定型的であるべきことに注意して、可視化の作業を進めます。
2. プロセス図・フロー図の設計
プロセス図・フロー図の作成において、要件定義のために特別なことを書いてもらう必要はありません。
通常のフローチャートの作成で問題ないでしょう。
フローチャートを書くスキルやITリテラシーには人によって差があることを意識し、もしも業務部門の担当者が苦戦するようであれば、箇条書きを元に得意な方が書いても構いません。
各RPAツールの情報共有サイトなどで、フローチャートのサンプルやテンプレートがシェアされていることも多いので、書き方をこれらに学ぶのも一つの手です。
これらのテンプレートを使うことができれば、要件定義のあとのシナリオへの落とし込みがうまく行きやすいでしょう。
上手くいかない場合に効果的な方法
そしてやっとシナリオへの落とし込みに着手できるようになります。
ところが、工程が長い業務の場合、要件定義をそれ自体は正しく行っても、シナリオへの落とし込み・実行の段階になって、うまく行かないケースも生じます。
このような場合は、実際に担当者が作業をしているところを画面共有してもらい、システムエンジニアが検証をする＝要件定義を再度行う、という方法がおすすめです。
画面を共有して行う
画面共有で確認していく上でよくあるケースが、「正しいと思っていた要件定義に遺漏がある」ということです。
業務の手順を可視化し、ワークフローを作った上でそれでもうまく行かなければ、実際の操作画面を共有してエンジニアが検証する方法を試してみましょう。
画面をレコーディングして行う方法も
PCのレコーディング機能を使い、画面をレコーディングして要件定義を行うこともまた有効です。
レコーディングすると、RPAが操作を正確に再現できているかどうかの分析にも役立ちます。
まとめ
今回は、RPAの要件定義について解説しました。
何かと難しいと考えられがちな要件定義ですが、シンプルなところから始めると、シナリオ開発までスムーズに進められます。
RPAの要件定義は、シナリオ開発の基礎となる重要な部分です。
最初は業務担当者なら誰でも書ける箇条書きから始めて、プロセス図・フロー図に移っていくようにしましょう。
