BizRobo!の運用を円滑にするプロジェクト設計のすゝめ


## はじめに

はじめのうちは `Default Project` にまとめて登録していたロボットも、利用者やロボットの数が一定量を超える頃には管理効率や統制の観点から運用方法を見直す必要が出てきます。

もしくは個社ごと部門ごとに独立して運用していた環境を統合する際に、その後の運用方法について頭を悩ませることもあると思います。

あるべきは「導入前に設計しておく」ことですが、仮に時間をかけて綿密に設計したとしても実際その時になってみると「重厚過ぎて使いにく」というケースもあり、住んでみてから後悔しやすい家の間取りに近いのかなぁと思ったりします。
![Shutterstock_1666949905.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3090491/715df983-7e50-baf4-f5eb-0ea6bab01156.png)

:::note warn
本稿はプロジェクトマネジメントの話ではなく、Management Console の管理機能である `プロジェクト` をどのように設計するかのお話です。
:::

## Management Console のプロジェクト機能

まずは Management Console の管理機能である `プロジェクト` についておさらいしましょう。

### プロジェクトとは

マニュアルによると
> プロジェクトは、ロボット、タイプ、スニペット、リソース、スケジュール、およびその他の作業アセットを分割するための手段です。ロボットは、そのロボットが属するプロジェクトに含まれるタイプ、スニペット、およびリソースにのみアクセスできます。

とあります。

言い換えると `リポジトリ` や `スケジュール` などを共有できる範囲のことで、実際に BizRobo! を運用する際には `部門` や `チーム` などの組織単位、`業務プロジェクト` などの業務基準で設計されることが多いです。

### プロジェクトの特徴

前述のように `プロジェクト` はリポジトリなどの共有や管理の単位として用いられますが、それ以外にはどのような特徴があるのか整理します。

#### プロジェクトの用途

- リポジトリ等の共有範囲を管理する　…　（既出）
- 利用者と権限（操作対象と範囲）を設定する
- 外部プログラムとの連携（サービスとしての公開）を設定する
- リポジトリの管理方式を設定する

#### プロジェクトの設定

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3090491/2e21bce0-f2eb-3a65-b250-d6490728c2f4.png)

| 項目 | 説明 |
|:-:|:-|
| 基本 |  プロジェクトの `名前` と `説明` を指定します |
| 権限 |  `プロジェクトロール` と `セキュリティグループ` [^2] の組み合わせでプロジェクトの権限を設定します |
| サービス | ロボットが `REST サービス` として呼び出されたときにこのプロジェクトのロボットを実行するための各種設定をします  |
| リポジトリ | Git バージョン管理システムで作業オブジェクトを制御できるようにする `ロボット ライフサイクル マネジメント` 機能を設定できます  |

#### 権限の種類と対象
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3090491/b46e9906-1ccd-2f3e-2e54-cfba795f8e65.png)

`プロジェクトロール` としては様々なものがデフォルトで用意されていますが、RPAとして人が利用することを考えると下記「対象」欄に `人` と記載されているもののみで十分です。

:::note info
考慮すべきもののみマニュアルからの[一部抜粋](https://docshield.kofax.com/RPA/ja_JA/11.3.0_5cdzhlgb3t/help/rpa_help/help_main/mgmtconsole/t_managingusersandgroups.html#kap_t_managingusersandgroups)
:::

| プロジェクトロール | 説明 | 対象|
|:-:|:-|:-:|
| Project Administrator  |  `プロジェクト管理者`: このロールを持つユーザーは、1 つまたは複数のプロジェクトを管理し、これらのプロジェクトのグループに役割を割り当てる権限を保持しています。また、RoboServer およびクラスタ情報の `表示` 権限を持ちます。プロジェクト管理者は、すべてのプロジェクトに対して管理権限を持つ `RPA Administrators` グループのメンバーではありません。 |MC(人)<br>REST|
| Developer  |  `開発者`: 開発者にはリポジトリ内のすべてのリソース タイプをアップロード、ダウンロード、表示する権限があります。このロールを持つユーザーは、スケジュールの作成、編集、削除、ロボットの実行、実行ログとクラスタの表示が可能になります。 |MC(人)<br>REST|
| Viewer  | `閲覧者`: 閲覧者は、開発者と同様の表示権限、および変更または実行の権限を持ちます。(作成、編集、削除の権限はなし) |MC(人)<br>REST|
| API  | `このユーザーは API 経由でサービス認証としてのみログインします`: このロールを持つユーザーは、リポジトリ API を使用して、リポジトリに対して読み書きを行うことができます。このロールを持つユーザーは、REST を使用してロボットを実行することはできませんが、Java/C# API を使用してロボットを実行することはできます。  |システム|
| RoboServer  | `このユーザーは API 経由でサービス認証としてのみログインします`: リポジトリからのみ読み取ることができる制限付きのユーザー。このロールは、クラスタにアクセスする場合、リポジトリ アイテムを取得する場合、およびパスワード ストアからパスワードを要求する場合に RoboServer で使用されます。  |システム|
| Kapplet Administrator  | `Kapplet 管理者`: Kapplet を作成、表示、実行、編集できるユーザー。 |Kapplets(人)|
| Kapplet User  | `Kapplet ユーザー`: Kapplet を表示、実行できるユーザー。 |Kapplets(人)|
| Password Store Client  | `パスワード ストア クライアント`: このアドオン ロールを持つユーザーは、パスワード ストアにアクセスできます。このロールは、開発者ロールと同様に、他のロールの上位に提供されます。このロールには、Management Console のパスワード ストアへのアクセス権限のみが付与されます。  |MC(人)|
| DAS Client User  |  `DAS クライアント ユーザー (このユーザーは API 経由でサービス認証としてのみログインします)`: これはリモートの Desktop Automation Service (DAS) クライアント用に作成されたユーザーで、DAS API へのアクセス権限のみを持ちます。DAS クライアント ユーザーには DAS を Management Console に提示し、DAS 構成を取得する権限があります。 | DAS<br/>(システム)|

:::note info
デフォルトの `プロジェクトロール` は Management Console の設定ファイルである「roles.xml」 を修正することで必要に応じて任意の個数ロールを追加したり、既存のロールを変更することができます。
参照：[MCに組み込まれたユーザー権限を編集する方法](https://knowledge.bizrobo.com/hc/ja/articles/360027882832-MC%E3%81%AB%E7%B5%84%E3%81%BF%E8%BE%BC%E3%81%BE%E3%82%8C%E3%81%9F%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E6%A8%A9%E9%99%90%E3%82%92%E7%B7%A8%E9%9B%86%E3%81%99%E3%82%8B%E6%96%B9%E6%B3%95-)
:::

## プロジェクト設計のアプローチ

プロジェクトは BizRobo! 運用における一つの独立した単位であり、環境移行時にステップ・バイ・ステップで実施する単位に（も）[^1]なるため、業務レベル・システムレベルで関連するものをまとめておくと管理が容易になります。

### Case#1 組織観点で設計

最も分かりやすいアプローチです。プロジェクトの範囲を現実世界の組織と重ねることで理解しやすく、管理が容易になります。

例えば `総務` や `人事` `経理` などのスタッフ部門と `営業` や `製造` `調達` などのライン部門では業務の進め方や考え方が異なり、用語の使い方や意味も異なる場合があります。（よく知られている例でいえば `取引先` という言葉の使い方など[^3]）

このような状況でロボットファイルやリソースを共有すると思わぬ手間やトラブルを生む[^4]こともあるため、ある程度業務レベルで共通認識を持つ（日常的に会話のある）範囲を区切りとしてプロジェクト化するのがおすすめです。

### Case#2 業務観点で設計

同一組織内であっても内容により他の業務と性質が異なるものがあります。例えばセキュリティレベルを上げてアクセスできる人を絞りたい業務や、始まったばかりのプロジェクトで部署をまたがって運営をする場合など。

こう言ったケースもロボット利用の目的や業務の性質がそれぞれ異なりますので、個別にプロジェクトとして切り出すのがいいでしょう。

### Case#3 トリガーによる集約

利用者のタイミング（Kappletやデスクトップ操作などのトリガー）で実行されるロボットは、大半の「スケジュール」で動くロボットと異なり実行のタイミングが読みづらいため、プロジェクトを分けることで環境移行の際やシステムメンテナンスによる基盤停止時にある程度範囲を絞り込め運用が楽になります。

ただしロボット実行のトリガーはあくまで副次的な要素であり、管理の対象としては 組織別 や 業務別の観点が優先されます。


### Case#4 連携方法による集約（システム連携、API）

ロボット自体がシステム連携を目的に作成されたもので Java/C#、REST/SOAP のAPI経由で外部のシステムから実行される場合、利用の前提自体が通常の RPA とは異なり情報システムの一部として存在しているため、お互いが間違って干渉してしまわないようにプロジェクトとして管理領域を分けるのが安全です。
（BPMSとの連携によりシステムからロボットが呼び出される場合など含む）

### プロジェクトが増え過ぎたら？

プロジェクトをあまり細かく分類すると、今度はプロジェクトの数が増え過ぎて管理に手間を感じるかもしれません。

プロジェクト数やプロジェクト内のリソースボリュームなど、どの程度のサイズが適正か一概には言えませんが、ある程度ロボットや利用者の数が増えた[^5]ら Management Console 自体を拠点や部署ごとに分割するのも一つの方法です。


## プロジェクトの命名規則

なにかを整理する際に便利なフレームワークとして `5W1H` があります。
Management Console 単位での移行やメンテナンスなど、基盤に変更が及ぶ場合に基盤・運用チームがまず確認するのがプロジェクトなので、「基本」タブを見ただけで必要な情報が判断できると非常に嬉しいです。

#### 名前の付け方

対象のプロジェクトの主幹 `WHO` と対象 `WHAT` を明確にするために以下の形式で命名します。

```txt:プロジェクト名
{PREFIX}_{NAME}_{SUFFIX}
```
| 項目 | 視点| 例|
|:-:|:-:|:-|
|PREFIX|WHO| `部門コード` や `プロジェクトコード` などを指定|
|NAME  |WHAT| 組織により分割しているケースでロボット全般をまとめて管理する場合には `共通`、具体的な業務用途で切り出している場合には `業務名`、特定システムに対する操作全般が業務として確立している場合には `システム名` などを指定 |
|SUFFIX<br>(任意)|補足|トリガーによる分割時や連携による分割時に、そのプロジェクトの性質を明示するために `連携先システム` や `連携方法` を指定したり、時限プロジェクトの場合にはそれを明示する `FY24` などを指定|

#### 説明欄に書くこと

##### プロジェクトの責任者/管理者/問い合わせ先

基盤・運用チームから問い合わせをする際の最終連絡先。
例えば毎日エラーを出力しているロボットがあった場合、利用者にとってそのエラーが想定したものなのか異常であるのかがわかりません。

基本的には各部門に個別ロボットのメンテナンスはお任せしている立場ですが、一向にエラーが止む気配がない場合「そもそも不要なロボットが実行されて続けているのか、異動や退職などで担当者が不在となった野良ロボットなのか、もしくは部門側は把握している問題のない状態なのか。」を確認する必要があります。

個別ロボット（リポジトリ）の更新者情報から担当者を割り出すことは可能ですが、更新日時が古い＆担当者不在の場合には問い合わせ先が必要になります。

##### プロジェクトの主幹部署

プロジェクト名の PREFIX と重複する場合もありますが、プロジェクトによっては更に下位の組織やチームを記載することもありますし、業務プロジェクトで設定している場合には部署が複数関連していることもあります。

連絡先としては上の責任者情報があれば運用上支障はないため、補助情報として利用します。

##### プロジェクトの特徴と概要（上記区分けによる記述）

同様に補助情報としてプロジェクトの概要やロボットの用途が把握できる情報を記載します。


## まとめ

`プロジェクト` 機能の運用方針はBizRobo!を利用する会社ごとの状況や体制などに大きく影響されるため、上記アプローチについても単なる一例にすぎません。
とはいえ実際に現在検討されている方にとって、一つのヒントとして参考になれば幸いです。

[^1]:ロボットの環境移行においては Management Console ごとBackUp→Restoreで一括移行する場合もあれば、規模の大きな環境の場合 ステップ・バイ・ステップで、基盤構築後にプロジェクト単位で新環境に移行していく場合もあります。

[^2]:`ユーザー`を作成する際の `所属グループ` のこと

[^3]:[業務用語定義の重要性](http://www.kogures.com/hitoshi/webtext/kj2-yogo-teigi/index.html) に記述のある「ホモニムとシノニム」

[^4]:例えば、営業部で作成した `取引先` という名前のタイプファイルが存在するプロジェクトにおいて、購買部が新たにロボットを作成しようとした時、新たに `取引先` というタイプファイルを作成する代わりに既存の `取引先` タイプを編集してしまうと既存の営業部ロボの挙動に影響を与えてしまったり、営業部にとっては意味の分からない項目が追加されてしまい、それを避けるために多くの同じようなファイルが複製されてしまい実際に利用されているファイルが判別できなくなってしまう。など。

[^5]:システム制限として具体的な上限数は指定していませんが、運用の規模を考えると目安として 3桁後半になったらそろそろ考えてもいいかもしれません。
※ロボット登録可能数、ユーザ登録可能数はともにINDEXがBIGINT型でDBに定義されているため、採番できる最大値は 9,223,372,036,854,775,807（v11.3.0.2 調べ）