ここではガバナンス(管理体制・内部統制)の構築方法について、ご説明しようと思います。まず何故ガバナンス構築が必要なのかについてですが、一定のルールや作業の流れが定められていないと個人毎に独自の成果物を作り出したり、観点もばらばらのため確認すべき項目が抜け漏れてしまったり、セキュリティ事故を起こしてしまったりと、様々な問題が発生してしまいます。
また、ガバナンスが整っていない期間が長く続くと、それまでに作成された成果物の管理が大変になってしまったり、やり方に慣れてしまった人の行動を変えるのが大変になってしまうため、RPAの大規模展開を始める前には必ずガバナンスは構築すべきと考えます。では早速ガバナンス構築方法について、説明していこうと思います。
【目次】
ガバナンス構築の検討方法
ガバナンス構築が必要である事は分かったけど、なにから手を付けていけばよいか分からないと思いますが、構築に関してPWCという大手コンサル会社とUiPathが共同で執筆したガイドラインとハンドブックがあるため、やらなくてはいけない事を理解するのはこちらの情報を使う事で、可能となります。
資料は2種類の構成となっており、1つ目がリスク管理部門や監査部門の人が読む事を想定でつくられている「ガイドライン」とRPA開発や推進部門の人が読む事を想定で作られている「ハンドブック」の2つがあります。ガバナンス構築に関わる方であれば、全体的に抑えておく必要があるため、2つとも読む事をお勧めいたします。無料で公開されているためサイトからダウンロードする事が可能です。
ガバナンス構築方法
上記ガイドラインでやるべき事を把握したら、リスクの洗い出しと対応策の検討を行います。その後リスクを防ぐために案件推進のガイド作成や各種ドキュメントの準備をしていきます。社内に既にあるドキュメントを改造して作成していくのも良いですが、UiPathではなんとこの資料も無料でフォーマットが公開されております。既にあるドキュメントから作る際にも、考慮すべき内容が漏れていないか確認するために、資料は目を通しておくことをお勧めします。
UiPathはEUC(エンドユーザコンピューティング。ITにそこまで詳しくない業務担当)の人が開発することも視野に入れて、各種ドキュメントを提供しようとしています。資料は下記4つのカテゴリに分けられています。
1.ビジネスメソドロジー(計画と測定に関わる部分)
2.PoCメソドロジー(導入検討に関わる部分)
3.導入メソドロジー(プロフェッショナル)
導入メソドロジーは計画、開発、測定全てのフェーズに関わる部分を対象にしています。現時点ではまだEUCとプロフェッショナルの資料に大きく違いもなく、何が違うのかわかる資料も展開されていないため、まずはプロフェッショナルの方をベースにしてガバナンスを構築していくのが良いと思います。
開発規約の構築について
開発規約の構築方法について、メソドロジーの初版ではコーディング規約もメソドロジー内に含まれていたのですが、現在の最新版にはメソドロジー内にはコーディング規約の資料はなくなっています。理由としては現在コーディング規約と品質評価チェックツールが纏まって別の資料となっているからです。この別の資料は下記からダウンロードする事が可能です。こちらの資料も無料でダウンロードする事が可能です。(ツールはuiPathGoからダウンロード)
開発に関わるベストな作り方もコーディング規約内に含まれており、規約通り作成できているかツールを使う事で自動でチェックすることも可能です。開発規約は汎用的な記載になっており、命名規則部分は利用者(各社)ごとに個別に定義を行う必要があります。命名規則定義のサンプルドキュメントは用意されていないため、UIPathに関わる命名(StudioやRobot、Orchestrator)は別資料として定義したものを作成するのが良いです。プロジェクト名等の規則を考える上で大事な事は、大規模展開を見据えて命名を考える事です。会社全体で一元管理を後々行うのであれば、どこの部署のどのロボットなのか区別がつくようにしておく必要があります。部署名やチーム名は体制変更でいつか変わる可能性があるため、部署名等は略称や名称を扱うのではなく、部署名を識別するための番号を振った変換マスターテーブルを作って扱うのが良いと思います。部署やチームの管理負荷は結構高いので、会社で一意となる番号にする事が出来れば部署コード等は利用しない方が良い事もあります。
UiPathコーディング規約とワークフロー品質評価キット | UiPath
現在の体制のチェックについて
現在のチームに関して、どこの部分で強化や改善が必要なのか定期的にチェックする事が推奨です。UiPathではこのようなチェック観点を纏めた情報も展開しています。こちらにチェックリストがあり、チェックしていくとどのカテゴリの整備ができていないか可視化を行う事ができます。
運用規模によって整備されているべき内容は変わってきますので、現在のチーム内で対応すべき箇所は何なのかはチーム内で協議して進めていくと良いです。チェック自体は難しくできない、チェックは外部に実施して客観的に指摘ほしい場合はUiPath社に問合せして人を入れてもらうと良いです。
さいごに
ガバナンス構築や開発規約の構築は非常に重要なものとなります。複数の有識者でレビューをしたり、作ったものをいきなり全体に展開するのではなく、検証用の案件で実際に扱ってみて問題がないかを評価して、修正をおこなったりして完成に近づけてから全体に展開を行うやり方が推奨です。
UiPathに関わる他の情報はこちらの一覧記事に纏めています。
