はじめに
この記事は「RPAにおける開発見積」についての個人的意見・メモです。
「RPA」カテゴリ の アドベントカレンダーの 2日目 の記事でもあります。
前回の続き
以前に、RPAの見積について書きました。今回はその続きを書きます。
前回の内容を簡単にまとめると、こんな内容でした。
# そもそも、工数見積は難しい
- 後の方で全貌が見えてくるから
- 見積をしている初期フェーズでは、そもそも情報の確度が低いから
# RPAの見積は、さらに難しい
- ツールを使ったローコード開発だから
- 短期で低コストが前提だから
- ぞもそも業務改善自体が難しいから
# RPA特有の見積の仕方
- 画面操作／複雑ルール／イレギュラーパターンをどうするか
- テスト難しい／要件定義とか無いことも多い
- 開発する人のレベル差が大きい
# じゃあどうするの？
- 前提を整理する
- 先にプロトタイプを作っちゃう
- 成果物どこまで作るか考える
- 契約を考える
前回は「上記のような内容」で書いたのですが、
- そもそも「開発の形態（プロ開発・ユーザー開発）」によって、考え方が変わるよね
- 見積工数よりも「イテレーション（改善スプリント）」が大事だよね
という事を書けていなかったので、今回「追記」として書きます。
開発の形態（ユーザー開発／プロ開発）によって、考え方が変わる
ここで言う「ユーザー開発／プロ開発」は、以下のような意味合いです。
| 分類 | 内容 | メリット | デメリット |
|---|---|---|---|
| ユーザー | 自社（部門）が、自ら業務を自動化する | 柔軟に開発できる | 品質担保が難しい |
| プロ開発 | 外部会社が、プロとして開発をする | 品質担保が楽 | お金がかかる |
ユーザー開発の一番のメリットは「スピード感」です。
極端な話、ユーザー開発であれば「バグ発生」は仕方ないものとして バグが発生したら速やかに直す ことを優先する進め方も「健全」です。
開発工数も、厳密に見積りしないで「ざっくり」 でも良いと思います。
ただし、この 「バグ出たら考えよう＆スケジュールはざっくり」で頑張ろう」 作戦を続けると、「品質が低くなり、手がつけられない状態になる」ことも多いので
- 「振り返り」や「見なおしポイント」を設けること
- 「仕組みから作り変える」ことを予定すること（その分の工数＆仕組み作りが出来る人 を用意）
が必要だと思います。
リスク回避という観点で、初期時点で「プロ開発」の手を借りておくと、今後の拡張・保守も考えてアドバイスを貰えるかもしれません。（品質面・拡張面での「手詰まり」を避けられる）
RPAの見積はイメージ力が大事
RPAの開発をしていると、以下のような「意外」な場面に出会います
-「この機能なら2日できるだろ！」と言っても 5日 掛かった（とある機能でハマった）
-「分かんないから10日にしとこ！」としといたら、3日で終わった（類似ロボを流用できた）
この「予想との乖離」は、RPAがローコードツール開発 であり、 普通の開発より「ブレ幅」が大きい から「起きやすい」のだと思います。
このブレ幅は、案件をいくつか経験し「危険予想力・妥当な見積力」が上がることで、減っていきますが、そこで、いちばん大事なのは「処理フロー／コード」をイメージする力だと思います。
要件を聞いて「どの部品を使って、どんな風に組み立てるか？」をどれだけイメージできるか。
「苦労しそうな部分はどこか？落とし所はどこになるか？」まで事前に考えられると、後々楽になると思います。
実装のイメージは、人によって様々ですが、突き詰めていくと数パターンに落ち着きます。
なので、日頃から「人の書いたコード」や「他人がハマったポイント」を読んで「引き出し／パターン」を増やしておくと、イメージ力がアップして、見積の際にも役に立つはずです。
見積工数よりもイテレーション（スプリント）が大事
RPA開発は人の手作業を自動化するもので、最初は人とロボットの一部協業を目指して、将来的に「完全自動化」を目指すのがセオリーだと思います。また、段階的に業務を自動化することで、後から見えてくる課題も正確に対応できます。
そういう意味で、RPAは最初から完全系を目指すのではなく「今月はココまでを目指そう」といったスプリント（短期的な目標）を重ねる（イテレーション）が向いています。（アジャイル開発的な考え方）
ただし、初期見積フェーズではこの「スプリント／イテレーション」を意識して数字を出すのは難しい、というより不可能に近い。なので、
- 開発フェーズを積極的に分ける
- 今月はここまでやろうという目標決め
- 成果を振り返るタイミングを用意しておく
といった「短期目標＆中長期目標」を意識して、フェーズを設定できるプロジェクトが健全 なのかもしれません。
終わりに
RPAの開発見積は簡単ではありません。難しさには「RPAならでは」の部分もあります。
この記事が参考になったら、 LGTMをお願いします。閲覧ありがとうございました。