最近、大手金融機関などで実施しているような大規模な終わらないRPAプロジェクトの話をよく聞くようになってきています。ベンダー側の上手い誘導で周辺プロジェクトが続いているのであればまだ良いのですが、当初予定していた範囲が終わらないのは問題です。
そもそも、当初の計画範囲（プロジェクトスコープ）が間違っているのか、進め方が間違っているのかのどちらかでしょう。
RPA導入プロジェクトが終わらない理由
プロジェクトが終わらない原因をベンダー側に言わせれば、「依頼側の仕様が度々変更になる」など、いろいろな理由を挙げられるかとは思います（これもベンダーがコントロールすべき事ではあります）が、次の点が大きいのではないかと考えています。
導入プロジェクトを強引にウォーターフォールモデルで進めようとする
これにつきるのではないでしょうか。更に言えば、経済産業省のITに関するモデル契約もウォーターフォールを基本としていますので、お役所のお墨付きです。
元々メインフレームと言われる大型の専用コンピュータで実行されることを前提としたお役所のスクラッチ開発システムであれば、当然ウォーターフォールで良いのだと思います。一部機能だけ稼働させても恐らく役にたたないでしょうし、行政とはミスが許されない減点主義の世界です。
ウォーターフォール開発モデルとは
ウォーターフォール開発モデルの詳細はこちらを参照して頂くとして、
要はウォーターフォール開発モデルとは、開発対象（スコープ）としている業務の全体を同時に、フェーズ毎に順次進めていき、決して後戻りしない（させない）ことを前提としたやり方です。
大規模な公共事業や建設工事、プラント建設などのハード的なプロジェクトは後戻りするとスケジュールや費用に大きな影響が及ぶため、多少の手直しはあったとしても決して前の工程に戻らないことが重要になってきます。
ウォーターフォール開発モデルの問題点
◆ RPAプロジェクトにウォーターフォールは不向き
RPAでの業務自動化にウォーターフォール開発モデルが向かない理由として次の点が挙げられます。
- RPAはシステム化が難しかった隙間業務を対象とする
- RPA化対象の業務は規模（頻度＊手間（工数））がまちまち
- 全てを同時に稼働させる必要はない（クイックウインの考え方が重要）
１．に関して異論を唱える人はあまりいないのではないかと思います。逆に言うと、カッチリと要件が決まりシステム開発出来るのであれば従来型のシステム開発をしたほうが良いのではないかと思います。そのほうが余程安定したシステムを構築出来ます。
そこにはやはり、
- 業務要件が細かい
- 業務がすぐに変わってしまう
- 人が柔軟に判断して行っているイレギュラー処理が多い
などの理由があるために今までシステム化の対象から除外されてきたのです。上記３つ目に関してはRPAで全てのイレギュラー処理を対象に出来る訳ではなく、業務負荷（頻度＊手間）が高いイレギュラー業務から順次RPAシナリオに取り込んでいく考え方となります。
２．に関して言えば、元々ロングテールの部分を自動化するのがRPAだとの認識にたてば、業務負荷が大きな業務から順に自動化していけば良いのです。そして、３．に記たように順次自動化していくのです。
ウォーターフォール開発モデルの様に、全てのシナリオ（テストケース）を済ませ、一斉に稼働させる必要など全くありません。
◆ 要件は変わるもの
業務は外部のビジネス環境や自社の戦略・戦術、顧客との取引条件などの様々な要素に影響を受けて常に変化する生き物です。従って、業務が変わっていく以上、それに応じて業務要件も変化します。
この様に要件が変わり易い業務は従来のシステム開発アプローチには向かないため、「RPAでの自動化」となっている、と認識すべきでしょう。従来のシステム開発が向かない「変わり易い業務」に、従来型のシステム開発アプローチであるウォーターフォール開発モデルが向かないのは明らかです。
◆ 現代のスピード感に合わない
上記の「要件は変わるもの」にも通じますが、ウォーターフォール開発は正直言ってスピードの速い（更に加速している）現代のビジネス環境に向いていないのです。海外のソフトウエア会社では既に殆ど使われていないモデルですし、元々は開発フェーズの後戻りが許されない、多大な影響を及ぼすインフラなどの建設工事などの為の開発モデルです。
RPA以外にも終わらないプロジェクトは多い
これまでシステム開発を含む多くのプロジェクトに関わってきましたが、終わらないプロジェクトは以外に多いものです。途中で要件が変更になったり、追加になったりとその原因は様々なのですが、何れにしてもSIベンダー側にとっては好都合です。
要件定義フェーズで確定したはずの要件を変更すれば、それは顧客側の責任であり追加の費用請求対象となります。スケジュールの遅れもその要件変更を理由に出来ます。準委任契約ですから仕方ありません。
要はSIベンダーにとって都合が良いのです。システムが稼働する1年以上も先のビジネス環境を前提とした要件を完全に出せるなどと言うことはあり得ないのです。
それでもSIベンダーはウォーターフォールでやりたがる
- SIベンダーにとって都合が良い
- 金額を膨らませやすい
などいろいろなSI側の問題はあるとは思いますが、結局のところこれが大きいのではないかと最近思っています。
- それしか知らない
新卒でシステム会社に入り、社内外のトレーニングなどを受けてもほぼ全てがウォーターフォール開発モデルを前提とした内容になっています。教えている本人達もこれしかやったことがないですし、準委任契約でSIとしてリスクが無く都合が良い。
その他のやり方をしようとしても、進め方も契約の仕方も知らないのではどしようもありません。もちろんウォーターフォール開発が向くシステム開発もあります。先に書いたメインフレームで動作させる大規模なスクラッチ（１から全てコーディングする）開発や、組み込み型のシステムなどです。
これらはプロジェクト当初に開発しようとするシステムの要件をキッチリと出せる（むしろ出す必要がある）システム開発です。そして、自社のGUIベースのパッケージソフトを持っている会社（の製品開発部門）以外のいわゆるSI部門は大規模なイベントドリブンなソフトウエア（パッケージ）を開発したことが無いのです。
それ（ウォーターフォール）しか知らないし、社内でもそのやり方しか提案出来ない、やったこともないのですから仕方がありません。
どの様にRPAプロジェクトを進めるべきか
それでは、どの様にRPAプロジェクトを進めるべきかですが、やはり世界中のソフトウエアベンダー（日本的なSIではない）が行きついている進め方になるのだと思います。
- アジャイルモデル
- DevOps
しかし、これらは概念的には理解出来ても、一部のソフトベンダー以外日本のSIにはこれらの進め方をやったことのあるPMが殆どいないのが現状です。この辺りも大規模なRPAプロジェクトを難しくしている原因かも知れません。
そして、これらの根底には「期限を決めて品質を極限まで向上していく」また、その品質向上を稼働後も継続する考え方があるのだと思います。
昔のソフトウエアのように、誰かが（時間でも）プログラムを起動し、予め決めた処理対象データや外部入力は受けつけるが基本的に処理フロー通りにプロセスするだけのソフトではなく、現在のGUIベースのソフトはユーザがどのタイミング・順番でどの様な操作（ボタンを押したり、キー入力したり）をしても、エラーで停止したりしてはいけません。
作ったほうとしてはどんなに想定外のあり得ない操作をされたとしても対応しなければいけないのです。この様な（あらゆる場合を考慮した）要件を最初に全て出すのは不可能です。従って、
品質はテストのパターン＊データ量＊回数によって担保する
そう言うものです。出来る限り多くのデータ・前提の元でテストを繰返し、品質を担保するしかありません。それは、実運用に入ってからも続くものであり、従って、開発（Development）とオペレーション（Ops）の連携・一体化を志向する２．DevOpsの考え方に行きつくのだと思います。
まとめ：ウォーターフォールでのRPA導入は終わらない
薄々気付いている人も多いかと思いますが、結局RPAの導入プロジェクトはウォーターフォール開発モデルとは相いれないものです。もし、この進め方が出来た（向いていた）と言い切れるのであれば、むしろその業務要件は従来型のシステム開発として行うべきだった内容に違いありません。
