「RPA、取りあえずやってみよう」はダメ、正しい開発プロセスとは？
ユーザー部門自らが“取りあえず開発を始められる”ことが一つのメリットでもあるRPAだが、いつまでも考えなしに取りあえずやってみるだけでは、トラブルの絶えないロボが作られ続けることになってしまう。作り手の視点や、ちょっとした前準備が、現場で役立つ優秀なロボット開発につながるのだ。RPA開発の正しいステップとは何か――現場のユーザーでもできることを紹介する。
前回は、RPAロボット（以下、ロボ）が止まってしまう“ロボトラブル”の原因とその対策を説明した。RPAを開発する際に、業務を知っているユーザーの視点と、システムに詳しいシステム担当者の視点のどちらか一方でも欠ければ、トラブルの絶えないロボができてしまう。今回は、ロボトラブルの発生を予防し、RPAの導入で狙った投資対効果（ROI）を出すために、品質やコスト、時間を意識した正しい開発プロセスについて解説する。
1.「ロボの開発コストがかかる！」「ロボが止まる！」良くある現場の悩み
ロボの開発は、「システム部門主導型」と「ユーザー部門主導型」の2パターンの体制で行うことが多い。企業の方針や、開発の規模に従って主導する部門は異なるが、それぞれ一長一短で課題がある。
システム部門主導型は、システム部門またはシステム部門から発注を受けた開発ベンダーがロボ開発を行うパターンだ。ロボ化の範囲が大規模または複雑な場合に多く採用される。課題として、プロジェクトが重厚長大になり、コストや時間がかかる。
一方、ユーザー部門主導型は、ユーザー部門が主体となり、ロボ開発を行うパターンだ。「取りあえずやってみよう」と小規模にRPA導入を始めた場合に多い。開発が場当たり的になりがちで、ロボットの品質が悪くなりやすいという課題がある。
2.ロボの望ましい開発プロセスとは
SHIFTは、ロボの業務設計および開発の各プロセスに、システム部門と現場のユーザー部門が参加し、タスクの完了状況を確認し合いながら進める手法を推奨している。
ロボ開発の体制は企業によって異なるが、両部門の視点をロボ開発に取り入れることで、開発のやり直しといった無駄を防げる。また、両部門が関わることで、業務特性への考慮とシステムとしての構造整理が両立し、運用・保守フェーズでメンテナンスもしやすい。
図3は、業務設計とロボ開発のプロセスを示した図だ。開発の規模や複雑度によってカスタマイズが必要だが、基本形として捉えていただきたい。次項では、図3における赤枠内の業務設計および開発プロセスで押さえるべきポイントを説明する。ロボ開発をシステム部門またはユーザー部門の双方で臨むことを意識しながら、これから紹介する開発のコツを実践してほしい。
3.業務設計（システム要件定義）を行う際のポイント
RPAツールを使ってゼロから開発を始めようとしても、どこから何をロボ化すればよいかをイメージできないだろう。まずは、人間の動作をロボの機能に翻訳する作業が必要だ。現状の業務はどのように行われているかを詳細に確認し、ロボの操作にどう置き換えるのかを検討する。その後、ヒトとロボの作業の組み合わせを整理して、新たな業務として設計することが必要だ。業務設計のプロセスは、大きく以下3つのタスクで構成される。それぞれの内容を説明する。
- AsIs／Tobeフローの整理
- 技術検証
- 方式設計
AsIs／Tobeフローの整理
業務設計は、ロボ化前（AsIs）とロボ化後（Tobe）の業務を可視化することから始まる。現状の業務フローがどうであるのか、ロボに置き換えた際にどのような流れがふさわしいのかを整理するというタスクだ。業務フローを可視化する際は、ヒトが操作や判断を行う一つ一つの作業を抜け漏れなく洗い出すことが重要だ。意外にも、対象業務を日常的に行っているユーザー部門がこのタスクを行うと抜け漏れが発生する場合が多い。アウトプットに反映されず、暗黙知化されている作業は特に漏れやすいので注意が必要だ。給与振込業務に関わる事務作業を例に説明しよう。
図4は、給与情報を取得する業務のフローをヒトの作業単位で詳細に可視化したものだ。この例で、アウトプットに反映されず、暗黙知化されている作業とは、「給与の支払い対象となる全員のデータがそろっているかを確認する」作業だ。普段、ヒトが当たり前に行うことであるため、洗い出しの際に抜け漏れやすい。
たった1つの作業工程だが、実際の運用で抜け漏れた場合は、大きな事故の原因になり得る。結果的には、テストフェーズなどで抜け漏れに気付き、開発をやり直すことになるだろう。手戻りが多ければ、無駄な開発工数が生じてしまい、開発スケジュールも遅延する。
以上のように、複雑で間違えやすい作業のパターンをあらかじめチェックリスト化しておく対策が有効だ。特に、ロボ開発を主導する部門と、ロボを活用する部門が異なる場合には、作業フローの認識合わせを行う際に役立つ。システムにログインするためのユーザーID／パスワード、給与情報をダウンロードするフォルダ名、給与情報の具体的なチェック方法など、作業に付随する情報も整理して記載したい。
可視化を効率化する手法も検討してほしい。業務フローの可視化は、詳細に抜け漏れなく行いたいが、システム部門が人の作業単位を超えたシステムレベルの要件を洗い出し、Excelに詳細にまとめあげた結果、膨大な時間とコストがかかるケースも珍しくない。日常的にシステムレベルで物事を整理しているシステム部門にとって、この引き算は難しいだろう。対策として、業務フローを階層ごとに整理し可視化するツールや、操作ごとの画面キャプチャーを自動で取得できるツールを活用する方法がある。商用ツールも多く出回っているので参考にしたい。
技術検証
技術検証とは、ロボが操作する対象、すなわち「オブジェクト」を認識する方法を評価・検証し、適切なものを選択するタスクだ。少し専門的な言い方をすれば、オブジェクトコントロールの指定パターンの中から適切な「指定方法」を見つけ出すことを指す。
表1では、ロボがシステムの操作対象（オブジェクト）を認識する方法を整理した。a、b、cの方法は、PC画面の座標位置など、システムの外部的な要素を手掛かりに対象を認識し、指定してコントロールするものだ。
一方、d、eの方法は、htmlタグなど、内部的な要素を手掛かりに操作対象を認識する。内部的な要素は変化が少ないため、一般的に後者の方がオブジェクトコントロールの安定性が高いといわれる。しかし、ホスト・コンピューターやクライアントアプリケーションにhtmlタグが存在しないように、そもそも内部的な指定の対象がないシステムの場合には、この方法は使えない。
さらに同じRPAツールでも「操作対象システム」と「指定方法」の組み合わせ次第では、ロボがうまく動作しなかったり、開発に時間がかかったりすることがある。自社のシステムを内部的にコントロールできる、より「マッチした」RPAツールを選び直し、技術検証を行って解決する方法もあるだろう。しかし、既に本格的な開発フェーズに突入している場合は、時間やコストの制約により他のツールを選択する余地はなく、動作の安定性を諦めa、b、cなどの外部的にシステム操作を行う方法に頼らざるを得ない。
有効な対策として、本格的なロボの開発に着手する前に、操作対象のシステムやアプリケーションの一部分に対して試験的なロボ開発を行うとよい。事前のひと手間によって、本番では最善のオブジェクトの指定方法を選択できる。
方式設計
方式設計では、効率よく品質の高いロボを作るために、どのように開発するのかを決める。まずは、業務フローをロボ化する前のタイミングで、ロボが頻繁に行う「ログイン」や「ログアウト」といった操作を整理し、ロボを作る際の「共通部品」にできるようまとめておく。
この共通部品をどう組み立てて、操作を完成させるのかということも事前に決めておくとよいだろう。
適切に共通部品を作り活用できれば、いざ一連の業務フローをロボ化する際に作り手による品質の差も生まれにくい。また、ロボ開発の工数も減らせるなどメリットは多い。
共通部品化された操作の組み合わせ方として、方式設計の段階で、ロボがどうやってヒトに作業の結果をわたすのか、エラー時のアラートをどのように報告・通知するのか、ルールも決めておく。例えば、ロボが何らかの原因で停止した場合には、ヒトにメールで通知を送るというルールや仕組みがあれば安心だ。何をきっかけにしてメールを通知するのか、その仕組み自体は、開発フェーズで個別に設定する。
段取り八部という言葉があるように、開発方針を決めておくことで、開発工程における作業の無駄や重複を避けられる。これらは、最終的に開発の品質やコスト、期間に大きく影響する。
4.ロボの開発を行う際のポイント
開発フェーズでは、小さな作業単位でロボを作成しながら、改善と開発を繰り返す反復開発が重要だ。具体的には、ロボを作成するたびに、ロボを活用するユーザーに試験的にロボを動かしてもらい、ユーザー目線で気になる箇所について細かくフィードバックをもらう。フィードバック情報をロボ開発に役立てることで、現場のニーズを反映したロボができる。
システム部門主導型でロボを開発する場合、このユーザー確認というステップを怠り、ロボを現場にリリースした後に、「現場が求めているものと違う」と手戻りが発生するケースが多いため、注意してほしい。
さらに、ロボ化の対象となる業務は、多くの場合「通常の業務パターン」と「例外的な業務パターン」が存在することに注意したい。この2つの業務パターンは、明確に段階を分けてロボ開発を行わなくてはならない。まずは、通常の業務パターンにおけるロボ開発から着手し、ロボの基本動作を確定しておく。その後、例外的な業務パターンのロボ開発に着手する。
通常の業務パターンに対するロボ開発
通常業務をロボ化するコツは基本動作の開発を迅速に済ませ、ユーザーに早い段階でロボを動かしてもらうことだ。レビューの段階が早ければ早いほど、ユーザーが求めるロボのイメージ、つまり要件定義の抜け漏れを拾いやすくなり、開発の手戻りも防止できる。また、ユーザーがロボ動作に関するレビューを行う際には、「業務設計（システム要件定義）を行う際のポイント」における「AsIs／Tobeフローの整理」で取り上げた複雑で間違えやすい作業のチェックリストを活用すると良い。
例外的な業務パターンに対するロボ開発
例外業務をロボ化する際は、ロボが誤動作しやすいパターンをユーザーと事前に確認し合っておかなければならない。「実例で学ぶ、RPAが止まる4つの原因と回避の手引き」でロボが誤作動を起こす原因の一つに「例外的な業務パターンの考慮漏れ」があるという話を書いた。ロボ開発の際には、ロボが稼働中に例外的な業務パターンが発生した場合にどのような対応を取るべきかを事前に決めておくことが大切だ。ロボ化する業務ごとに、どのような例外的な業務パターンを想定すべきか一目で把握できるように、あらかじめ考慮すべき観点一覧を作成しておきたい。実際にロボが誤作動をした場合など、いざというときの対処にも役立つだろう。SHIFTで活用している、例外的な業務パターンの観点一覧を再掲しておく。
ロボの反復開発は、ロボ開発のプロセス全体を効率化させ、業務設計（システム要件定義）の抜け漏れリスクを低減させることにもつながるため、ぜひ取り入れてほしい。
今回は、望ましいロボの開発プロセスについて、特に業務設計（システム要件定義）プロセス、開発プロセスにおけるコツを中心に解説した。次回はロボのテストフェーズについて説明をしたい。RPAにおけるテストでは具体的に何を行うのか、そもそもなぜ必要なのかを想像できない人も多いだろう。実は「止まらないロボ」や「手離れのよいロボ」を実現するに当たって非常に重要なプロセスだ。特に、RPAはあらゆる外部環境と連携して動作するため、本番と同じ条件でテストを行いにくいことが課題になっている。確実に、そして効率よくテストを行うためにはどうしたらよいのかを分かりやすく解説したい。
著者紹介：樋口 匡
SHIFT ビジネストランスフォーメーション事業本部 エンタープライズビジネスユニット 金融第2グループ プリンシパル
大手SIerで、金融機関に向けた構想策定、要件定義、設計、テストまで一連の開発業務を経験。電子マネーの新規事業構築にも従事。その後、外資系大手コンサルティング会社において、金融機関のIT戦略／投資立案、IT構想策定、IT導入支援（PMO／テスト戦略など）など、多数のプロジェクトをシニアマネジャーとしてけん引する。また、IT投資フレームワーク構築などにも従事。SHIFTでは、複数の金融系プロジェクトの統括責任者としてコンサルティング業務を行い、RPA／BPM新規事業構築、方法論構築にも精力的に取り組む。
著者紹介：浜村佳史
SHIFT ビジネストランスフォーメーション事業本部 技術推進部 RPA推進グループ
大手通信会社にて、通信インフラの設計・運用に関わるシステム開発プロジェクトにコンサルタントとして参画。システムの構想策定から要件定義、設計、テストまで一連の開発業務を経験。国内において、RPAという概念の認知・普及が広がる10年以上前から、UI操作による既存システムの自動化、メール連動業務の自動化など、現場の業務改善活動に関わる多くの取り組みを手掛ける。SHIFTでは、企業の業務プロセス改善およびRPAロボの品質向上に向けた支援業務に注力している。
企業紹介：SHIFT
ソフトウェアの品質保証・テストの専門企業として、金融機関や保険会社、大手流通系企業や自動車メーカーに至るまで、さまざまな領域における企業のITシステムやソフトウェアの品質向上を手掛ける。製造業の業務プロセスコンサルティングを前身とすることから、プロジェクトおよびプロダクトの品質向上を目指した業務プロセス改善には、独自のノウハウと数多くの実績を持つ。2017年ごろからは、RPAロボットの開発・運用に関するご相談が急激に増え、2018年にはRPA診断改修サービス「ROBOPIT!」の提供を開始。現在は専任部署を立ち上げ、RPA事業に取り組む。
Copyright © ITmedia, Inc. All Rights Reserved.