はじめに
この投稿は、RPAツールで開発工数の見積をする際の考慮ポイントを、個人的にまとめたものです。
この記事は、UiPath Friends もくもく会 2021年4月開催 2021-04-24（土）08:45 - 12:00 で書きました。
RPAの工数見積は難しい
そもそもの話ですが、RPAに限らずとも「工数見積は難しい」です。
主な理由として下記があります。
| No | 理由 | 補足 |
|---|---|---|
| 1 | 後の方で全貌が見えてくる | 追加要件や課題は「最初は見えない」 |
| 2 | 案件ごとに要件は違う | 過去案件と似ていても「全く同じでは無い」 |
| 3 | 案件ごとに環境も変わる | 「条件や人や環境」によって工数も大きく変わる |
| 4 | 経験や勘が必要 | 「場数」を踏んで、規模感やリスクをイメージできる |
一番大きい理由は「1：後の方で全貌が見えてくる」ですが、これは有名な「不確実性のコーン」のお話です。
見積をしている初期フェーズでは、そもそも情報の確度が低い という事です。
上記に加えて、RPA独自の要素 が加わります。
| No | 理由 | 補足 |
|---|---|---|
| 1 | 短納期／低工数の期待 | RPAなら「早いはず・安いはず」という期待 |
| 2 | 要件が不十分 | 想定外の手順等が漏れがち・ヒアリングが都度必要 |
| 3 | 深い業務理解が必要 | 開発者も業務担当者レベルの理解が必要になることも |
| 4 | 開発スキルのバラ付き | 初心者も多く、標準工数で収まらない可能性あり |
| 5 | テストの準備が必要 | テスト環境整備やデータ準備に時間が掛かる |
| 6 | 動かなくなりやすい | 外部システムの仕様変更等の環境変更に弱い |
「ツールを使ったローコード開発」で「短期」で「業務改善をする」ゆえの要素です。
こう見ると、RPAの開発は「その他一般的な開発」よりもリスクが高いです。
工数見積も、上記のリスクを踏まえて計算する必要があります。
見積の手順
手順としては、通常の開発工数見積と同じです。
1）情報を可能な限り集める
↓
2）機能に分解して、難易度や規模感を数値化する（ファンクションポイント法）
↓
3）実際のフェーズごと積み上げていく（ボトムアップ法）
↓
4）算出しにくい部分は、過去の類似案件や経験から考えてみる（類推法・KKD法）
↓
5）工数についてチームメンバーや第三者と議論をする（プランニングポーカー）
↓
6）バッファを積んでリスクを回避する
但し、上記に RPA独自の考え方 が加わります。
- 1）画面操作があれば「Ui要素/セレクタ/オブジェクト」の操作が一通り出来るかを確認
- 2）複雑な判定や曖昧なルールがないかチェックする
- 3）入出力データを見て、読み取り書き込みが難しくないかを考える
- 4）イレギュラーデータやイレギュラー処理がありそうか探ってみる
- 5）テストの実施が容易に出来そうかイメージする
- 6）開発する人の経験・レベルで重みを大きく変える
- 7）ユーザーが仕様を隠していないか考慮
1の「Ui要素確認」は、気になる方は多いのではないでしょうか。
ちょっと凝ったデザインの画面や、逆に古いアプリケーション（例えばNotesやOracle）だと「単純に操作が出来ない」ので、工数へのインパクトが大きいです。なんとか工夫して「操作方法をひねり出す」必要があります。（または操作ではなくAPI呼び出しとか）
5の「テスト実施の容易さ」も意外と工数インパクトが大きくて、テスト環境が無かったりデータ作成が難しかったり等で、場合によっては実装以上に工数がかかることがあります。
6の「開発する人のレベル」も工数に影響が大きいです。RPAは「ツール開発」なので、実装フェーズでは「ツールの理解度・操作慣れ」がそのまま工数に出ます。初心者と熟練者では数倍の差が出ます。
また、例外的な見積方法として「RPAツールの移行案件」の考え方もあります。
例）RPAツールAからツールBへ移行する（＝処理の書き換えをする）
⇒ ツールAでの「アクション / アクティビティ」の合計数に係数をかけて工数を出す（LOC法の考え方）
参考）
その他のポイント
いくつかピックアップして紹介します。
1）前提を整理する
見積の前提、背景を明確にする必要があります。具体的には
- 納期はあるか？あればその期日は必達か？（ロボット導入の背景も読み解く）
- 予算の上ブレはOKか？（NGならバッファを多く積む or 最小構成での提供を考える）
- 外部に開発を依頼するなら、契約は請負か準委任か？
- 開発したRPAは今季限りの使用か？通年使用か？
- 追加開発の要望は出そうか？
等を確認します。
2）先にプロトタイプを作っちゃう
これが出来るなら、リスク回避として一番良い気もします。
RPAは「ローコード開発」なので、実装も早いのでプロトタイプも作りやすい。
プロトタイプを作ることで「Ui要素が触れない」という リスクを事前に潰せる というメリットもありますし「新しい要件」や「業務のイレギュラー処理」などの 具現化して課題が見えてくる という副次効果 もあります。
3）成果物を考える
「成果物として何を残すか」は、議論して明確にする必要がありますが、可能なら「成果物を一部省略したり最低限の内容にする」と工数が大きく減ります。
- 面倒なので「テストエビデンスは取らない」事にして、その時間を受入試験やバグ対応に回そう
- 仕様が後から追加されるし、思い切って「設計書はつくらない」その分プロタイプを何度も作ろう
といった、アジャイル開発的な進め方のほうが、RPAには向いている気もします。
一般的な開発では必要なドキュメントも、RPAでは必ずしも必要では無い ケースもあります。
4）契約を考える
外部の会社に開発を依頼する場合「準委任 or 請負」かでリスクの性質・回避方法が変わってくるので要注意です。
契約形態として
- 準委任契約：完成義務なし。瑕疵担保責任なし（金額は低いが、期待した成果まで行かないことも）
- 請負契約 ：完成義務あり。瑕疵担保責任あり（責任の分だけ、金額が高くなる傾向も）
のいずれかを選択すると思いますが、RPAの場合、どちらが向いているのでしょうか。
最終的には発注側の考え方次第ですが、上記のような
- 要件の後出しが大いにある
- 業務担当（発注側）が要件定義や発注に慣れていない
といった「懸念・リスク回避」を考えると「準委任契約」のほうが「軌道修正が随時出来る」のでリスク回避しやすそうです。ただ、請負のような「明確な期日・責任」が無いので、最悪の場合「頑張ったけど何も出来なかった」という事もありえます。
可能なら、両方の良いとこ取りをした「請負契約のような準委任契約」が良いかもしれません。
上で書いたとおり、最終的には発注側の考え方次第ですが。
5）リカバリ実行を考える
不測の事態、でロボットがエラーで止まることもあり、その際の対応手順を考えておく必要があります。俗に言う「コンチプラン（Contingency Plan(コンティンジェンシープラン)）の話です。
エラーで処理が止まった場合に、リカバリ・リトライで再度実行したい！と思いますが、その時に、
- 1）処理がどこまで終わったか？がログから把握できるか？（状態の把握）
- 2）意図的に処理フローを途中から再開できるような仕組みか？（処理ブロックのスキップ）
- 3）処理済データは、スキップできるようになっているか？（処理データのスキップ）
などが考慮された作りになっているか？が大事です。
要するに、業務の内容からリカバリ方法・コンチプランの難易度・どこまでロボットで作り込むかを考える必要があります。
特に大量データを扱う場合は、処理時間が長時間に及ぶので、途中から再実行できる仕組みがあると「気が楽」ですが、その分、工数がかさみます。
事前に顧客ヒアリングで「処理がエラーで止まった場合にどうしますか？」と聞いておくと良いかもしれません。
ただ（顧客との信頼関係が出来ているのであれば）
- あえて聞かない（またはサラッと聞いてみる）
- 聞くと大掛かりな話になってしまいそう（ロボット化しなくなるかも）
- 問題が起きた時に、迅速に検討しよう（余力を残した工数にしよう）
とするのもアリです。（難しいですが）
続き
続きの記事を書きました。
- そもそも「開発の形態（プロ開発・ユーザー開発）」によって、考え方が変わるよね
- 見積工数よりも「イテレーション（改善スプリント）」が大事だよね
という話です。
終わりに
いかがでしたでしょうか。見積方法は状況によって変わるので正解は無いですが、何かの参考になれば幸いです。
この記事が参考になったら、 LGTMをお願いします。
閲覧ありがとうございました。