UiPath Academyには様々なコースが用意されているものの、日本語以外のコースは受講をためらっている方が多いのではないでしょうか。
その中から今回”Solution Architect Training”を（苦労して）修了したので、興味を持たれている方の受講のきっかけになるよう、事前にインプットしておくと理解が進みやすい知識をまとめました。
・コースが想定する受講者層
・各章で”だいたいこんな事を学ぶよ”的な概略
・登場する専門(?)英語とその意味
※私の解釈で書きますので、あくまで参考程度にご覧下さい・・・
コースの内容自体は、既にRPAのプロジェクトに関わっている方であればそれほど目新しい内容は無いので、新たに何かを学ぶというよりは既にできている事／できてない事という視点で自分達の進め方の振り返りに使えます。
あとSolution Architectの修了証がもらえるのいいよね。
コースが想定する受講者層
Solution ArchitectはCoE, Center of Excellence（社内のRPA推進組織のイメージ）の中核メンバーとして主にITの立場から高品質・効率的なRPAの実現に責任(Responsibility)を持ちますので、そういった役割の方、もしくはそこを目指す方が想定受講者だと思います。
↓にBusiness Analystとの対比で主な役割を書いてみましたが、ITシステムの開発プロジェクトでいうと（プロマネ＋システムアーキテクト）÷２、一方でBusiness Analystは業務部門のコアメンバーのイメージですね。
各章で”だいたいこんな事を学ぶよ”的な概略
コースは9章のビデオ講座と5問のQuiz×2で構成されています。
1. Solution Architectに求められる役割
この章ではRPA projectにおいてSolution Architectに求められる役割と必要なスキルセットが解説されます。
ざっくり言うとSolution Architectの役割は、ITの観点からRPAプロジェクトの上流～下流までのあらゆる物事をデザイン（アーキテクチャ、ルール、ポリシー、…）し実行し成果を出す事です。そのためには業務部門からRPA開発者まで広くステークホルダーの理解を得る必要があり、アウトプットは網羅的でなければいけません。
スキルセットとしてはプログラミング経験やITインフラの知識など技術面に精通している(technically savvy)事に加え、チームをまとめるリーダーシップも求められます。
また後半は、RPAプロジェクトの6つのフェーズそれぞれでSAの果たす役割が語られます。
1. Enable (開発環境などインフラ面の用意)
2. Preparation (プロジェクト進め方を決定)
3. Design (業務プロセス分析～オートメーションの設計)
4. Build (オートメーションの実装)
5. Test (テスト～本番化判定)
6. Sustain (オートメーションの運用、変更管理)
2. UiPathのアーキテクチャ
この章ではUiPathの製品コンポーネント（Studio, Attended Robot, Unattended Robot, Orchestrator）と、アーキテクチャ全体における各コンポーネントの役割が紹介されます。
アーキテクチャはITシステムではお決まりのClient, Server, Persistency(Database)の３つのレイヤーに分けて解説され、冗長構成のためのRedisやDashboardのためのES/Kibanaにも言及があります。
3. Enableフェーズ - RPA deployment
RPAを利用可能にするために関係者で決めなければならない事(Inplication of RPA deployment)を6ジャンル(Security, Operation, Implementation, Platform, Governance, Support)に分けて紹介してます・・・が、詳細は語られません。残念。
スライドには細かく項目が書かれてるので後で見返そう。
またコンポーネントという狭い範囲でのDeploymentについてOrchestrator, Robot, Package, Credentialの4点で考慮すべきポイントが語られます。
4. Preparationフェーズ - Best practice
この章ではRPAの開発に入る前にBest practiceを確立して周知徹底する事の重要性を説いてます。UiPath社内でもBest practice用意してるぜ（コレかな？）と言ってます。
Best practiceの例として
・テンプレートフレームワークの適用
・ネーミングルールやコメント・エラーハンドリングのポリシー設定
・Selectorを積極利用
など挙げていて、そういったBest practice全部入りでEnhanced RE-Frameworkとして用意したから使ってね、という流れでRE-Frameworkの有用性が切々と説かれます。
5. Preparationフェーズ - Process optimization
この章では対象業務をいかにRPAに落としこんでゆくか、そのステップを学びます。業務プロセスの中に踏み込む必要があるため、Business Analystとの協業がカギです。
・業務プロセスを検証し、適用可能性やRPA化できる範囲を探る(Feasibility study)
・"As Is"のプロセスから"To Be"を考える、かつTo BeのRPAでの実現イメージを固める
・RPA化しやすい形に作業プロセスを変える(Process optimization)
・技術的に難しい箇所(Technical bottlenecks)を特定し優先的に対処する
といった具合です。
6. Preparationフェーズ - Development effort estimation
オートメーションの開発工数の見積りについて。正確に見積もるのは難しいけど、"こんな風にしたらそれなりに理屈の通った工数（workload, man-day）が出せるよ"というガイドライン的な内容。
工数に影響するのはステップの多さよりも、
・Selectorが効かない(Flashアプリとかね…)等の、対象アプリケーションとRPAとの相性の悪さ
・対象業務における例外ルールの多さ
・後から出てきた追加仕様による手戻り
という説明に激しく同意。
Quiz 1
Academy恒例の、クイズというには重過ぎる難易度のテスト。
RE-Frameworkの知識が必要で、あんまわかってない私は3回目でようやく合格できました。
7. Designフェーズ - Solution Design, Workflow Abstraction
※この章だけなぜか字幕ありません。なので私の理解度も低いです・・・
最初のSolution designの項では、先のPreparationで決めた"To Be"でのRPA実現イメージをいかに具現化するかを考えます。
・Attended/Unattendedどちらで動かすか？必要なロボット台数は？実行スケジュールは？
・プロセスのInputデータとOutputデータは何か？
・プロセスは一気通貫か？それとも分割すべきか？
またWorkflow abstractionの項ではワークフロー設計を可読性・再利用性の観点からLayer化して考える事を提唱しています。このLayerはStudioでワークフロー組む時のFlowchart/Sequenceの階層に該当し、今回紹介するlayerはRE-Frameworkに準拠しているとの事。
また新しいLayerとして
- Application Screen Layer（Business processに依存しない、再利用可能）
- Application Process Layer（Business processに依存）
という２つが登場します。例＞
ログイン画面でID/password入れてログインするのは 1
ログインした画面から要件に合ったデータを取り出すのは 2
8. Designフェーズ - Reusable Component, Solution Diaglam, AR vs UR
Reusable Componentの項ではコンポーネント(xamlファイルやカスタムアクティビティ)の再利用法について、4つの手段とメリット・デメリットが語られます。
Solution diaglamの項では、対象プロセスを実現するためにスケジューリング・スケーリング・プロセス分割(Sub-process)を盛り込んだ図示化を、具体例を付けて解説しています。
AR vs URの項はAttended RobotとUnattended Robotの使い分けの指針です。Attendedは仕事の"発生源"であるFront officeの立場からDispatcher（処理すべき仕事をQueueにツッコむ係）の役割を、UnattendedはBack officeのPerformer（Queueに溜まった仕事をどんどん処理する係）の役割を果たします。
9. Build, Test, Sustainフェーズ
残り3フェーズがまとめて1話で語られる、まるで打ち切り漫画のような展開 
BuildフェーズはRPA Developerが主体ですが、Developerがしっかり開発進められるように、SAもやる事いっぱいあるから覚悟しろよって感じ。
Testフェーズでは機能テストに入る前にCode reviewとAuditチェックをします。
Auditチェックの例＞
・アプリケーションのCredential(ID/password)がRobotにどう使われるか
・機密性の高い情報が不用意に流出しないか（メール・制限の緩い共有フォルダなど）
・動作に影響するパラメータが不正に改竄されないか
Sustainフェーズ、つまり本番稼動後の運用フェーズではRobotの稼働状況を見ながらUnhandledな例外に対処する事、継続的に発生する変更要望へのChange managementをしっかりやる事などSAの果たす役目に終わりはありません。
Quiz 2
こっちのクイズではRE-Frameworkの知識は不要でした。
以上です。全て修了するとスライドのPDFがダウンロードできます。
登場する専門(?)英語とその意味
普段聞きなれない英語がいくつか合ったので、自分の備忘も兼ねて一覧化しました。
| 英語 | 意味 | 補足 |
|---|---|---|
| Agreed-upon formula | 合意した（パフォーマンスなど非機能要求まで含めた）仕様 | |
| RPA deployment | RPAを利用するために必要な活動全般 | |
| PDD (Process Definition Document) | RPA対象業務のプロセス記述書、およびロボットに実行させるステップをフロー形式で記述したもの | 業務部門が作る |
| DSS (Development Specification Document) | オートメーション内部の作りを解説した仕様書？ | RPA開発者が作る |
| Feasibility study | 実現可能性の事前調査 | |
| Process optimization | シンプルなRPAの作りになるよう作業手順・内容を変える事 | よく言われる"業務の見直し"よりもう少し作り手寄りの発想 |
| Potential challenges | 潜在的な課題 | 文脈からすると、このコースで言うchallengeは"挑戦"でなく"課題"だと思う |
| Development effort estimation | 開発工数の見積り | |
| SME (Subject matter expert) | 対象領域の専門家 | ここではRPA化対象の業務に精通した人 |
| Top notch | 一流の、最高の | |
| Malicious code | 悪意あるコード | オートメーション内にID/passwordを抜き取る・偽装するコードを埋め込む等 |
今回はここまで。
"そんな発想があるのか"といった目新しい内容は無いものの、Solution Architectとしてやるべき事が網羅されており、これまで自分がやってきた事と比較する事で良い振り返りになりました。
また英語コースをクリアしたという達成感も良いですね。毎日良く眠れましたが
バッヂもらえました。
