【RPA】開発工数の見積について

# はじめに

この投稿は、RPAツールで開発工数の見積をする際の考慮ポイントを、個人的にまとめたものです。

この記事は、`UiPath Friends もくもく会 2021年4月開催 2021-04-24（土）08:45 - 12:00` で書きました。

https://uipath-friends.doorkeeper.jp/events/119957

# RPAの工数見積は難しい

そもそもの話ですが、RPAに限らずとも「工数見積は難しい」です。
主な理由として下記があります。

|No| 理由 | 補足 |
|:-:|:-|:-|
|1| 後の方で全貌が見えてくる | 追加要件や課題は「最初は見えない」  |
|2| 案件ごとに要件は違う | 過去案件と似ていても「全く同じでは無い」  |
|3| 案件ごとに環境も変わる | 「条件や人や環境」によって工数も大きく変わる  |
|4| 経験や勘が必要| 「場数」を踏んで、規模感やリスクをイメージできる |

一番大きい理由は「1：後の方で全貌が見えてくる」ですが、これは有名な「不確実性のコーン」のお話です。
**見積をしている初期フェーズでは、そもそも情報の確度が低い** という事です。

https://blog.takuros.net/entry/2017/05/18/121145


上記に加えて、**RPA独自の要素** が加わります。

|No| 理由 | 補足 |
|:-:|:-|:-|
|1| 短納期／低工数の期待 | RPAなら「早いはず・安いはず」という期待 |
|2| 要件が不十分 | 想定外の手順等が漏れがち・ヒアリングが都度必要 |
|3| 深い業務理解が必要 | 開発者も業務担当者レベルの理解が必要になることも |
|4| 開発スキルのバラ付き | 初心者も多く、標準工数で収まらない可能性あり |
|5| テストの準備が必要 | テスト環境整備やデータ準備に時間が掛かる |
|6| 動かなくなりやすい | 外部システムの仕様変更等の環境変更に弱い |

「ツールを使ったローコード開発」で「短期」で「業務改善をする」ゆえの要素です。
こう見ると、RPAの開発は「その他一般的な開発」よりもリスクが高いです。

工数見積も、上記のリスクを踏まえて計算する必要があります。
![tenbin01_231.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/154139/e21e4d9d-04b6-bbf4-27dd-51bfe4d9d510.png)


# 見積の手順

手順としては、通常の開発工数見積と同じです。

```
1）情報を可能な限り集める
　　↓
2）機能に分解して、難易度や規模感を数値化する（ファンクションポイント法）
　　↓
3）実際のフェーズごと積み上げていく（ボトムアップ法）
　　↓
4）算出しにくい部分は、過去の類似案件や経験から考えてみる（類推法・KKD法）
　　↓
5）工数についてチームメンバーや第三者と議論をする（プランニングポーカー）
　　↓
6）バッファを積んでリスクを回避する
```

但し、上記に **RPA独自の考え方** が加わります。

```
- 1）画面操作があれば「Ui要素/セレクタ/オブジェクト」の操作が一通り出来るかを確認
- 2）複雑な判定や曖昧なルールがないかチェックする
- 3）入出力データを見て、読み取り書き込みが難しくないかを考える
- 4）イレギュラーデータやイレギュラー処理がありそうか探ってみる
- 5）テストの実施が容易に出来そうかイメージする
- 6）開発する人の経験・レベルで重みを大きく変える
- 7）ユーザーが仕様を隠していないか考慮
```

1の「**Ui要素確認**」は、気になる方は多いのではないでしょうか。
ちょっと凝ったデザインの画面や、逆に古いアプリケーション（例えばNotesやOracle）だと「単純に操作が出来ない」ので、工数へのインパクトが大きいです。なんとか工夫して「操作方法をひねり出す」必要があります。（または操作ではなくAPI呼び出しとか）

5の「**テスト実施の容易さ**」も意外と工数インパクトが大きくて、テスト環境が無かったりデータ作成が難しかったり等で、場合によっては実装以上に工数がかかることがあります。

6の「**開発する人のレベル**」も工数に影響が大きいです。RPAは「ツール開発」なので、実装フェーズでは「ツールの理解度・操作慣れ」がそのまま工数に出ます。初心者と熟練者では数倍の差が出ます。

![tenbin01_232.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/154139/f9060383-9418-1514-aa7e-b882875f2da4.png)


また、例外的な見積方法として「RPAツールの移行案件」の考え方もあります。

```
例）RPAツールAからツールBへ移行する（＝処理の書き換えをする）
⇒ ツールAでの「アクション / アクティビティ」の合計数に係数をかけて工数を出す（LOC法の考え方）
```

参考）

https://e-words.jp/w/%E9%A1%9E%E6%8E%A8%E6%B3%95.html#:~:text=%E9%A1%9E%E6%8E%A8%E6%B3%95%E3%81%A8%E3%81%AF%E3%80%81%E6%83%85%E5%A0%B1,%E6%8E%A8%E5%AE%9A%E3%81%97%E3%81%A6%E3%81%84%E3%81%8F%E6%96%B9%E5%BC%8F%E3%80%82

https://e-words.jp/w/FP%E6%B3%95.html

https://www.weblio.jp/content/KKD%E6%B3%95

https://ssaits.jp/promapedia/method/bottom-up-estimating-2.html

http://appresso.hatenablog.com/entry/2016/08/03/181355

https://e-words.jp/w/LOC%E6%B3%95.html#:~:text=LOC%E6%B3%95%E3%81%A8%E3%81%AF%E3%80%81%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2,%E5%BA%83%E3%81%8F%E6%99%AE%E5%8F%8A%E3%81%97%E3%81%A6%E3%81%84%E3%82%8B%E3%80%82

# その他のポイント

いくつかピックアップして紹介します。

## 1）前提を整理する

見積の前提、背景を明確にする必要があります。具体的には

- 納期はあるか？あればその期日は必達か？（ロボット導入の背景も読み解く）
- 予算の上ブレはOKか？（NGならバッファを多く積む or 最小構成での提供を考える）
- 外部に開発を依頼するなら、契約は請負か準委任か？
- 開発したRPAは今季限りの使用か？通年使用か？
- 追加開発の要望は出そうか？

等を確認します。

## 2）先にプロトタイプを作っちゃう

これが出来るなら、リスク回避として一番良い気もします。
RPAは「**ローコード開発**」なので、実装も早いのでプロトタイプも作りやすい。
プロトタイプを作ることで「Ui要素が触れない」という **リスクを事前に潰せる** というメリットもありますし「新しい要件」や「業務のイレギュラー処理」などの **具現化して課題が見えてくる** という副次効果　もあります。

## 3）成果物を考える

「成果物として何を残すか」は、議論して明確にする必要がありますが、可能なら「**成果物を一部省略したり最低限の内容にする**」と工数が大きく減ります。

- 面倒なので「テストエビデンスは取らない」事にして、その時間を受入試験やバグ対応に回そう
- 仕様が後から追加されるし、思い切って「設計書はつくらない」その分プロタイプを何度も作ろう

といった、アジャイル開発的な進め方のほうが、RPAには向いている気もします。
**一般的な開発では必要なドキュメントも、RPAでは必ずしも必要では無い** ケースもあります。


## 4）契約を考える

外部の会社に開発を依頼する場合「準委任 or 請負」かでリスクの性質・回避方法が変わってくるので要注意です。

契約形態として

- 準委任契約：完成義務なし。瑕疵担保責任なし（金額は低いが、期待した成果まで行かないことも）
- 請負契約　：完成義務あり。瑕疵担保責任あり（責任の分だけ、金額が高くなる傾向も）

のいずれかを選択すると思いますが、RPAの場合、どちらが向いているのでしょうか。
最終的には発注側の考え方次第ですが、上記のような

- 要件の後出しが大いにある
- 業務担当（発注側）が要件定義や発注に慣れていない

といった「懸念・リスク回避」を考えると「準委任契約」のほうが「軌道修正が随時出来る」のでリスク回避しやすそうです。ただ、請負のような「明確な期日・責任」が無いので、最悪の場合「頑張ったけど何も出来なかった」という事もありえます。

可能なら、両方の良いとこ取りをした「**請負契約のような準委任契約**」が良いかもしれません。
上で書いたとおり、最終的には発注側の考え方次第ですが。


## 5）リカバリ実行を考える

不測の事態、でロボットがエラーで止まることもあり、その際の対応手順を考えておく必要があります。俗に言う「コンチプラン（Contingency Plan(コンティンジェンシープラン)）の話です。

エラーで処理が止まった場合に、リカバリ・リトライで再度実行したい！と思いますが、その時に、

- 1）処理がどこまで終わったか？がログから把握できるか？（状態の把握）
- 2）意図的に処理フローを途中から再開できるような仕組みか？（処理ブロックのスキップ）
- 3）処理済データは、スキップできるようになっているか？（処理データのスキップ）

などが考慮された作りになっているか？が大事です。
要するに、業務の内容からリカバリ方法・コンチプランの難易度・どこまでロボットで作り込むかを考える必要があります。

特に大量データを扱う場合は、処理時間が長時間に及ぶので、途中から再実行できる仕組みがあると「気が楽」ですが、その分、工数がかさみます。

事前に顧客ヒアリングで「処理がエラーで止まった場合にどうしますか？」と聞いておくと良いかもしれません。

ただ（顧客との信頼関係が出来ているのであれば）

- あえて聞かない（またはサラッと聞いてみる）
- 聞くと大掛かりな話になってしまいそう（ロボット化しなくなるかも）
- 問題が起きた時に、迅速に検討しよう（余力を残した工数にしよう）

とするのもアリです。（難しいですが）


# 続き

続きの記事を書きました。

- そもそも「開発の形態（プロ開発・ユーザー開発）」によって、考え方が変わるよね
- 見積工数よりも「イテレーション（改善スプリント）」が大事だよね

という話です。

https://qiita.com/miya_gis/items/77d24a759f91ddd734ae


# 終わりに

いかがでしたでしょうか。見積方法は状況によって変わるので正解は無いですが、何かの参考になれば幸いです。


この記事が参考になったら、 LGTMをお願いします。
閲覧ありがとうございました。