品質計画の問題か?調達の問題か?教育の問題か?
RPAの開発案件で障害が多発中。 直接原因の多くは単純なバグであり、 単体テストや結合テストで確認していないため。 ============================ シナリオ① 内部設計 根本原因は内部設計を作成していないため。 (そのためプログラム確認、単体テスト、結合テストができない) ウォーターフォール型開発で、内部設計を作らないケースというのは、 基本的に「ベンダーはバグなしでRPAを提供してくれる」という信用があって成り立つ。 ※開発標準から逸脱しているので、裏技に近いと考えている。 対して、そのように信用していたのかというと、そうではなく 「レコーディング中心の実装であれば、条件分岐や計算処理などのロジック定義が少ないため、内部設計の必要性が低い」という理由で、効率化を重視した結果、ベンダーは内部設計を作成しなかったと考える。 しかし、RPA化案件の要件は変容し、現在はロジック定義中心の案件が増えている。 にもかかわらず、ロジック定義の詳細な設計は作成されていない。 なお、内部設計をすることにより、実装工程の品質の改善は見込めるが バグだけでなく、UAT障害の一部を占める環境依存問題も、内部設計の作成により、一定量は事前に検知できるのではないかと考える。 ※内部設計について、ベンダー内で完結する方針としたい ============================ シナリオ② 単体・結合テスト 根本原因は単体テスト、結合テストの標準プロセスがないため。 (開発者任せの状態であり、単体・結合テストでバグを検知できるかは開発者次第となる) テストに強みのあるベンダーだったはずだが、このような想定原因に辿り着いてしまったのは残念。。 単体テスト、結合テストを着実に遂行するには、内部設計の作成やレビューのプロセスが必要。 ※プログラム・単体テスト・結合テストについて、ベンダー内で完結する方針としたい ============================ シナリオ③ 担当者スキル 根本原因は担当者のITスキルが見合ってないため (担当者自身が検知し解決できて然るべきレベルの問題を対応できていない。またスキル不足をカバーする対策も立てられていない。) RPA開発は「小規模案件が中心である」といった特徴があることから、1案件に1人をアサインするケースが多い。 また、「通常システムと比較するとRPAの実装は簡易」、「通常システムよりも業務要件、関連システム*は広範囲に渡る」という特徴があることを踏まえ、担当者に求められるスキルは、以下のようなものとなる。 *関連システム:RPAが利用するシステム全般(Windows、Office、社内某システム、社内某EUCツール etc..) 1. UiPath Academyを受講しており、UiPath Robot開発の担当経験があること 2. ウォーターフォール型の開発モデルで、要件定義からリリースまですべての工程の担当経験があること 3. 要件定義において、ユーザーの要求事項や関連システム*を分析し、システム要件や基本設計を作成、調整できること しかし、現状上記のようなスキルセットを持つ人材は、RPA業界内では多くないと思われる。主な理由はおそらく、RPAが「優先業務」に該当しないためと考える。つまり、このようなスキルを持つIT人材の多くは優先業務に該当するシステムにアサインされてしまう、という予想である。 現状、上記のスキルが揃っていないメンバーが多いと感じており、また彼らのスキル不足を踏まえて品質を担保する対策は立てられていない。 解決策は以下の2つが思い浮かぶ。そのうえで2つ目を推したい。 1. 上記スキルが揃っているメンバーのみで構成する 2. 他メンバーのスキル不足(低品質)をカバーできる人材を要員に加える 理由は2つあり、複数メンバー入替は品質維持リスクなど様々なデメリットがあるため、あと、2の人材の方が探しやすそうなため(高単価であれば)。 実現する場合、予算の都合上、要員追加ではなく、要員変更となる。
0 Comments
- Greetings and Self-Introductions
Good evening. this is Ichi from XXX. I am a member of RPA development and maintenance team here. I probably can understand simple and slow sentences and say something as well. I'd be happy to hear and tell a lot about RPA. Very nice to meet you. - RPA in XXX We're currently operating about 30 bots in several teams, and building new bots one by one. There're several features of bots in XXX. Firstly, each bot is small, likely automating task of 100-150 hours per year on average. Secondly, we don't have a RPA server, so each bot is operated by user. Lastly, Our team, RPA development and maintenance, is small and constantly has 4 developers. I'd be happy if I could share the view of RPA in XXX with you. - SFDC automation We're facing a frequent change of Salesforce, which usually changes every four month. The changes could affect bots which are manipulating Salesforce. So we've searched for a solution, and Uipath Inc. suggested the tool 'UiPath Activity Pack for Salesforce'. Right now, we're going to prepare for the proof of concept with that tool. 当社のRPAロードマップにおいて、2019年は拡大フェーズと位置付けられ、1年間でおよそ10部署、20ロボット程度、新たに導入することができた。社内のRPA認知度がUPしてきたことは嬉しいのだが、一方でいくつか課題も見つかってきた。 その一つが、ロボットの最適な配置方法。 ここではロボットとは、ロボット用のPCや、ロボット実行に必要な有償ライセンスのことを指す。また有償ライセンスは社内標準として、ロボットS/Wや、Microsoft365、セキュリティシステムなどがある。またロボット個別に、業務で利用している有償アプリケーション(例えば、SalesForce.comなど)が必要となる場合がある。 2019年はほとんどの部署が新規導入であったため、単純に必要数分のロボットの費用を予算計上し、調達するだけだった。しかし、2020年に入り、ロボット導入済の部署については、さらに自動化対象業務を増やそうとした場合に、ロボットを余計に調達・配置しないよう、意識しないといけなくなった。 更に最近、投資効果の実績を測定してみたところ、なんと一部赤字が出ていることが発覚! ということで、コスト削減の号令が出るのは目に見えているため、ロボット配置の最適化・標準化の検討をしてみたのだが、これが中々複雑である。 ザックリと言うと、
1時間くらいかけて作ってみたサンプルがこちら。 これはユーザーとの共同作業が必須で、初回は打合せなしではできないだろう。
実際は、業務アプリケーションは+5種くらい確認されているので、表は更に大きくなる。 まあ大変な作業ではあるが、この整理を行うことで、コスト削減だけでなく、もう一つ直面している以下の課題の解決が期待できる。
データ仮想化とは
denodo社の記事より一部加工・抜粋
DXがトレンドとなっている今日、ETLに代わるソリューションがデータ仮想化のようだ。 ETLとは SAS社の記事より一部加工・抜粋
https://www.sas.com/ja_jp/insights/data-management/what-is-etl.html ETLとデータ仮想化とETLとの大きな違いは、オンプレかクラウドか、と理解した。 レガシーシステムの移行時期を少しでも延ばすことができる点において、データ仮想化が一歩リードしている気がする。 |