rpa開発における工数見積りと非機能設計の勘所に...

Copyright ©2019 by Future Architect, Inc.

2019年9月12日

フューチャーアーキテクト株式会社

ファイナンシャルビジネスグループ

長坂昭彦

[email protected]

RPA開発における工数見積りと非機能設計の勘所について

ソフトウエア品質シンポジウム2019

ソフトウェア品質シンポジウム2019

1. RPAを取り巻く環境

2. 課題と要因

3. 改善施策

4. ファンクションポイント法に基づいた概算見積り

5. 非機能設計ガイドによる設計標準化

6. 施策実施結果

7. 今後に向けて

8. 最後に

- 1 -

本日のAgenda

Copyright ©2019 by Future Architect, Inc. ソフトウェア品質シンポジウム2019

１． RPAを取り巻く環境

日本におけるRPA市場は近年急成長

- 2 -

多くの企業がホワイトカラーの作業を自動化・効率化する技術としてRPAを採用 RPA開発の需要は年々増加傾向

出典：矢野経済研究所 RPA市場に関する調査（2018年）https://www.yano.co.jp/press-release/show/press_id/2085


１．１ RPAの技術成熟度

日本におけるRPAは「過度な期待」のピーク期からから減退期へ移行しつつあると想定（2019年時点）

- 3 -

RPAの普及に伴いRPA開発における課題も顕在化

出典：ガートナージャパン日本におけるテクノロジのハイプサイクル（2018年10月） https://www.sbbit.jp/article/cont1/35887


１．２ RPA開発における誤解

RPA開発における誤解と弊社認識

- 4 -

RPAにおける誤解を解き、正しい理解のもと取組めばより一層の効果があるものと想定

RPAには『向き・不向き』あり『業務整理』と『人との役割分担』が必要

よくある誤解弊社認識

現行業務を『そのまま・全て』自動化するのが良い

完全

自動化

処理構造設計や例外処理の実装など設計・実装スキルは必要

RPA製品の使い方さえ習得すれば設計・実装スキルは不要

開発スキル

不要

対象システムのレベルアップやMS製品の V-Upに追従するにはメンテナンスが必要

一度作ってしまえばメンテナンスは不要

メンテナンス

不要

（コーディングレス≠スキルレス）


２．課題と要因

弊社RPA開発における課題

- 5 -

見積精度

バラツキあり

ロボの操作数やRPA化対象システムの複雑度よって開発工数は大きく変動場合によっては1ロボの開発に数か月を要する場合もあるが、『1ロボ1人月』など、一律見積を行うと過小見積りとなりスケジュールの遅延を招く。

ロボ品質

バラツキあり

非機能仕様は設計書に明記されず、暗黙的なルールとなりやすい。 RPAは実装の自由度が高く、開発者依存となりやすい。


２．１見積精度バラツキ要因

見積精度にバラツキが発生する主な要因

- 6 -

対象業務が

不明瞭

現行業務を把握するために必要なマニュアル類の整備が不十分だと業務手順や対象システムの画面操作が不明瞭なまま概算見積りを実施しなければならない。結果、後の要件定義にて多くの例外手順が判明し当初見積もった工数・期間では過小となる場合がある。

対象業務が

複雑

RPA化案件は業務量が多く、適用効果が高い業務から選定されるのが一般的だがそのような業務は手順が複雑でデータ起因の処理パターンも多い。業務を未整理のままRPAを適用すると後の要件定義にて多くの処理パターンが判明し当初見積もった工数・期間では過小となる場合がある。

開発プロセス

が未整備

通常のシステム開発とは異なり、RPA開発はEUC（End User Computing）の一環として実施される場合が多い。結果、要件確定後に工数・期間の再見積もりを実施するプロセスとなっていない場合がある。


２．２ロボ品質バラツキ要因

ロボ品質にバラツキが発生する主な要因

- 7 -

RPA化

対象システム

品質差異

対象システムの画面応答が不安定であったり、連続操作すると画面応答しなくなったりする場合がある。

対象システムの潜在不具合に起因して想定外のエラーが発生する場合がある。

RPA化

対象システム

本番/開発

差異

更新処理は開発環境でのみテスト可能端末設定やシステム性能、ネットワーク帯域など、対象システムの本番開発差異が大きく、開発環境では正しく動作していても本番ではエラーが発生する場合がある。

開発環境のデータが古く本番相当のテストが実施出来ない場合がある。

ユーザ作成

データ

品質差異

利用ユーザが作成する実行指示ファイルに不備が多く、エラーが発生する場合がある。


３．改善施策

課題とその要因から改善施策を整理

- 8 -

要因課題改善施策

要件定義

開発／テスト／保守

対象業務が不明瞭（当初見積から工数・期間増加）

見積精度にバラツキあり現行業務の可視化（マニュアル整備、撮影、打鍵環境準備など）

開発プロセスが未整備

ロボット品質にバラツキありRPA化対象システム

品質差異

2回見積りのルール化（概算/詳細）

FP法に基づいた概算見積り

RPA化対象システム本番/開発差異

ユーザ作成データ品質差異

対象業務が複雑（当初見積から工数・期間増加）

現行業務のシンプル化（BPR）

非機能設計ガイドによる設計標準化

開発環境の整備（端末/サーバー/NW/データ）

ダミーデータを用いた本番環境での事前疎通

ユーザ教育の実施

改善施策はそれぞれ相応の効果があったが、今後のプロジェクトにおいても効果が見込める『FP法に基づいた概算見積り』と『非機能設計ガイドによる設計標準化』について後述


４．ファンクションポイント法に基づいた概算見積り

各ロボの開発規模（FP)に着目し、開発工数を定量的に算出

- 9 -

概算見積とRPA適用効果より、投資対効果を検証し効果が見込める場合は案件化し要件定義を開始

システム開発に必要となる工数は規模に応じて決定する（開発規模÷生産性）着眼点

過去実績からRPA開発のFP生産性を算出対象案件の開発規模（FP）とFP生産性から開発工数を算出（開発5工程）※

見積手法（開発工数）

※ 対象工程は基本設計から総合テスト（ベンダー確認）まで要件定義、及び総合テスト（ユーザ確認）以降の付帯作業工数は別途算出

集計

弊社業務ユーザ

ヒアリング業務整理

ヒアリングシート

概算見積（工数・期間）

RPA適用効果（余力創出時間）

・・・

過去実績

FP生産性開発規模・工数生産性算出

結果まとめ規模算出工数算出開発規模

参照

投資対効果検証（開発規模÷生産性）


案件化（要件定義開始）


４．１ RPA開発のFP生産性

RPA製品『UIPath』にて開発した27ロボの実績より、外れ値を除いた23ロボのFP生産性を集計

- 10 -

N 最小 P25 中央 P75 最大平均標準偏差

23 1.4 1.9 2.6 3.2 6.1 2.8 1.1

［FP ／人日］

FP生産性はP25：1.9FP/人日、中央：2.6FP/人日、P75：3.2FP/人日（1人日：8時間換算）「案件数増加による精緻化」や「生産性向上施策実施」により、FP生産性は今後も可変する見込み

RPA開発における規模と工数

信頼区間（R²）：0.80 （やや強い相関）

FP生産性の基本統計量


回帰分析


４．２開発規模（FP）算出[1/2]

対象案件の開発規模（FP）はFP概算法（NESMA概算法）にて算出

- 11 -

RPA実行フローからデータファンクション（DF)、トランザクションファンクション（TF)をそれぞれ抽出

ファンクション

抽出

実行指示ファイルと処理結果ファイルは内部論理ファイル（ILF）としてカウント対象システムからDLする帳票は外部IFファイル（EIF）としてカウント

DF

RPA実行フロー

ログイン処理、更新処理、結果書込処理は外部入力（EI）としてカウント検索処理は外部照会（EQ）、帳票DL処理は外部出力（EO）としてカウント

TF

FP数はILF：2、EIF：1 、EI：3、EQ：1、EO：1

実行指示ファイル

処理結果ファイル

ログイン検索更新帳票ダウンロード

ILF

EI EQ EI EO

EIF

ILF

EI

結果書込

帳票

（ロボが維持管理）

（ロボが維持管理しない）

１ 2

1

1 1 2 1 3


４．２開発規模（FP）算出[2/2]

FP概算法に従いILF/EIFのDFは重付け：低、EI/EQ/EOのTFは重付け：中として開発規模を算出

- 12 -

種別 [低] [中] [高] ＦＰ合計

外部入力(EI) ×３ 3 ×４ ×６ 12

外部照会(EQ) ×３ 1 ×４ ×６ 4

外部出力(EO) ×４ 1 ×５ ×７ 5

内部論理ファイル(ILF) 2 ×７ ×１０ ×１５ 14

外部IFファイル(EIF) 1 ×５ ×７ ×１０ 5

40

前述のFP生産性からP25：1.9FP/人日を生産性下限値と仮定し開発工数を算出本ロボの概算工数は21人日

FP換算用からFP算出

÷ ＝開発規模

（FP） 40 FP生産性

（FP/人日） 1.9 21 開発工数

（人日）


開発工数算出


５．非機能設計ガイドによる設計標準化

非機能設計を『8つの観点』で整理し、RPA製品を問わず遵守すべきガイドとして『非機能設計ガイド』を策定

- 13 -

今回は非機能設計ガイドの中でも重要な『画面遷移』『例外処理』『エラー制御と結果出力』をご紹介（その他5つの観点は経験論文をご参照）

非機能設計ガイド（目次）

(5) 例外処理(1) 実行指示ファイル検査

(6) ログ出力(2) 画面遷移

(7) 中間データ保持(3) 画面データ読込

(8) エラー制御と結果出力(4) 画面データ書込

ユーザ作成データや対象システムの品質に可能な限り依存しないよう設計・実装

エラーが発生した場合はユーザ主導でリトライ可能となるよう設計・実装

勘所

勘所


５．１画面遷移

画面遷移が正しく行われているか遷移前または遷移後の確認を行う

- 14 -

ユーザの使用頻度が低い遷移パターンは対象システムの挙動が不安定なため極力使用を避ける（潜在不具合の回避）


処理方式は対象システムの仕様により決定処理方式

選択

画面遷移時に押下するボタン・リンクの活性検知を待って処理を実施画面ID入力による画面遷移の場合は入力値を検査し桁落ちがないか確認

遷移前

確認

画面遷移確認イメージ

遷移後画面のIDやタイトルを取得し想定文言と一致しているか確認 IDやタイトルが一意でない場合は画面を特定できる項目を検索し文言一致を確認

遷移後

確認

遷移前確認

遷移後確認

遷移前画面のボタン・リンクの活性検知を待って画面遷移

遷移前画面の入力値検査後に画面遷移

遷移後画面のIDやタイトルを確認遷移後画面の画面項目を確認

（画面ID)


５．２例外処理

画面・ファイル・コマンド操作時の想定外の挙動を考慮し、例外処理を実施

- 15 -Copyright ©2019 by Future Architect, Inc.

同一画面にて大量データを繰返し登録・更新する場合は途中で画面応答しなくなる場合があるため、定期的にログアウトし画面応答を確保（潜在不具合の回避）

画面操作

エクセルなどのファイル操作は終了判定を実施しプロセスの残存有無を確認プロセスが残存する場合は一定時間経過後に強制終了

ファイル操作

ファイルコピーなどのコマンド操作は終了判定を実施しプロセスの残存有無を確認プロセスが残存する場合は一定時間経過後に強制終了

コマンド操作

例外処理イメージ

画面操作

ファイル操作

コマンド操作


ログイン検索更新


ログアウト結果書込

定期的にログアウト


テンプレ読込ファイル作成強制終了プロセス確認


コマンド起動ファイルコピー

一定時間経過後

強制終了プロセス確認

EOF？

EOF？

終了判定

終了判定

一定時間経過後

５．３エラー制御と結果出力

入力データ不備等により対象システムの操作エラーとなる場合あるため、エラー制御と結果出力を実施

- 16 -

エラーが発生する場合は処理成否（○✕など）を結果ファイルに出力結果ファイルには最終的に発生したエラーのみ出力し、それまでに発生したエラーはログファイルに出力


処理方式は対象システムの仕様により決定（元画面への『戻り遷移可否』が一つの判断材料）

処理方式

選択

処理中止のうえログオフし、アカウントロックを回避（フェイル・セーフの原則)

結果ファイルを実行指示ファイルとしてロボが再処理（入出力ﾌｧｲﾙのﾌｫｰﾏｯﾄ共通化）

戻り遷移

不可

エラー制御と結果出力イメージ

該当レコードをスキップし、元画面に戻り処理継続結果ファイルを確認し必要に応じてユーザが再処理（処理成否「✕」のみ再処理）

戻り遷移

可

戻り遷移不可

戻り遷移可

一覧明細


ログアウト結果書込


業務ユーザがファイル再配置

ロボが再処理（ 2件目以降99件）

100件中 2件目でエラー発生

一覧明細一覧（戻り）

100件中 2件目でエラー発生

明細


ユーザが再処理（2件目のみ）


６．施策実施結果

施策実施により見積精度、ロボ品質のバラツキは改善

- 17 -

FP法に

基づいた

概算見積り

要件定義開始時のFP法に基づいた概算見積り、要件定義終了時のタスク積上げによる詳細見積りを徹底した結果、以降のスケジュール遅延は是正

非機能設計

ガイドによる

設計標準化

不具合対応に伴う再リリース回数は1ロボあたり0.25回から0.09回と低減


６．１見積プロセスの変更点

見積プロセスの変更により、スケジュール遅延は是正

- 18 -

概算見積りに必要な入出力ファイルや画面操作が早期に明確となったため、概算見積の精度も向上

要件定義開始時の概算見積で計画要件定義終了時の詳細見積で確定

変更前変更後

要件定義開始前の概算見積で確定（要件定義後の見直しなし）

見積回数

概算：規模（FP)に基づいた工数見積もり詳細：タスク積上げによる工数見積り

KKDによる工数見積り（大：XX人日、中：XX人日、小：XX人日）

見積方法

過小見積は抑制開発工程のスケジュール遅延は抑制

一部のロボは過小見積開発工程のスケジュール遅延が発生

見積結果

プロセス変更による効果イメージ

変更前

変更後

開発要件定義案件検討（システム化計画）


詳細見積（工数・期間）

工数算出要件精緻化概算見積

（工数・期間）

要件定義書詳細見積り


工数算出要件精緻化概算見積

（工数・期間）

要件定義書

KKD

FP

確定

計画確定


遅延是正

遅延発生・・・


６．２非機能設計ガイド適用後の再リリース回数

ガイド適用により、不具合対応に伴う再リリース回数は低減

- 19 -

更新処理は本番開発差異に起因してエラーが頻発していたがガイド適用後は大きく改善ガイドに基づいた開発により、処理性能等の制約事項が早期に明確となりユーザ満足度も向上

11ロボ

適用前適用後

16ロボ新規開発ロボ数

1回 4回再リリース

回数※

0.09回／ロボ 0.25回／ロボロボあたり

再リリース回数

ガイド適用による効果イメージ ※ 仕様変更や予防保守観点での再リリース除く

適用前

適用後

本番環境開発環境

開発テスト実行

〇 × 端末設定

NW帯域システム性能依存

開発テスト実行

〇〇

端末設定

NW帯域システム性能依存解消


本番移行

本番移行


７．今後にむけて

今後は特定業務向けRPAのコンポーネント化を推進し、導入効果の更なる早期化を目指す

- 20 -

支店業務の中から特定業務に特化して選定

これまでこれから

本社業務の中から適用効果の高い業務を網羅的に選定

対象領域

既存RPAコンポーネントを基に Fit＆Gapを行いカスタマイズ

（≒業務パッケージ導入）

PoCを実施し要件定義を経て開発

（≒スクラッチ開発）

RPA開発

進め方


XXシステム〇〇検索

YY社向け帳票

結果書込帳票作成（作表替え）


XXシステム〇〇検索

XX社向け帳票

結果書込帳票作成（作表替え）

変更

コンポーネント切替え

検索結果

検索結果

RPAコンポーネント活用イメージ

既存流用既存流用


A支店向け

B支店向け


８．最後に

- 21 -

弊社では『RPAを活用した業務改革プロジェクト』を推進すべく、BPR/RPAコンサルタントを募集しています。

• お客様と一緒に業務改革を達成したい方• AIなど最新技術活用の知見を深めたい方• 『エンジニア』から『コンサルタント』へステップアップしたい方

ご興味のある方は弊社キャリア採用ページをご覧下さい。

募集要項（業務改革コンサルタント） https://progres12.jposting.net/pgfuture/u/job.phtml?job_code=395


https://progres12.jposting.net/pgfuture/u/job.phtml?job_code=395

- 23 -

本書において使用されている商標は、フューチャー株式会社または他社の登録商標または登録出願中の商標です。


rpa開発における工数見積りと 非機能設計の勘所に...

Documents

rpa開発における工数見積りと非機能設計の勘所に...