Power Platform での野良アプリ対策について考えてみる


# はじめに

Power Apps など、ローコード開発を促進しようとすると、「野良アプリ」について相談をいただくことが沢山あります。そのため、今回は、「野良アプリ」対策について、私の考えを整理してみました。

# そもそも「野良アプリ」とは？

正直、「野良アプリ」どうすればいいですか？と初めて聞かれた際、「野良アプリって何？どういう意味？」と疑問に感じました。

調べてみるとこんな感じでした。

https://ja.wikipedia.org/wiki/%E9%87%8E%E8%89%AF%E3%82%A2%E3%83%97%E3%83%AA

`野良アプリ（のらアプリ）とは、アプリケーションソフトのうち、オペレーティングシステムの開発元や通信事業者などが提供する公式のアプリケーションストアから提供される以外のもの。`

これを見たとき、Power Apps で市民開発者が作成したアプリやフローって、Microsoft の公式なクラウドサービスをベースに作成されるものですし、野良アプリという言葉が適切なのか疑問に感じました。


そのため、**何をもって野良アプリと呼んでいるのか、認識を合わせることが不安を解消したり対策をしたりする上で重要と思っています。**

個人的に、大きく分けると以下のいずれかの状態を野良アプリと呼んでいると感じています。そのため、それぞれの状態の定義やそのような状態にならないための対策などについて私の考えを述べます。

* 作成者が不在になり保守できない状態
* IT 管理者が管理出来ていない状態

# 作成者が不在になり保守できない状態

作成者が不在になり保守できない状態とは、アプリやフローを作成した市民開発者が退職してしまい、そのアプリの保守が出来なくなった状態です。
※プロ開発でローコードを利用する際は、その点を考慮した設計がなされている認識です

**個人的には、この状態について、野良アプリと呼ぶと認識がずれるかもしれないので、単に「所有者が不在になったアプリやフロー」と呼んでいます。**

こちらの対策としては、以下のようなアプローチが考えられます。

* ユーザーズガイド等を通じてそのような状態とならないよう、複数人が関わるアプリやフローについては所有者を複数人にしておく

* 退職時の引き継ぎ事項にアプリやフローの引き継ぎを加えておく


また、最悪の場合、IT 管理者の方で所有者を追加することは可能です。
以下は、CoE スターターキットの "Set App Permissions" というアプリですが、環境からアプリを探して所有者を追加したり、退職に伴いアカウントが削除されて所有者が不在になったアプリの一覧からアプリを探して所有者を追加することが簡単にできます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3074511/62ed684d-f24b-45d9-399a-88858393c9ac.png)
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3074511/9d845244-4775-03e3-09e7-b79e46d185ce.png)


:::note
"Set Flow Permissions" というアプリもございます。CoE スターターキットについては以下を参照ください。
:::

https://learn.microsoft.com/ja-jp/power-platform/guidance/coe/starter-kit

個人的には、あくまで依頼があればこういったアプリで所有者を追加してあげる対応でいいと思っています。

IT 管理者が全てのアプリを網羅的に調べて所有者を追加してあげるというアプローチも考えられますが、単にテスト的に作成したアプリやフロー、その人だけが利用しているアプリやフロー、つまり、所有者不在になったり、なくなったりしても困らないアプリやフローもそれなりにある認識で、そういったもの含め、全てのアプリやフローに対して積極的に所有者を追加しなくてもいいと思っています。

実際やろうとするとかなりの労力がいりますし、ある意味、組織内に存在するマクロや数式や他のサービスとの連携を含む、何かしらの作業効率化目的で作成している Office ファイル全てに対してそのようなことをやるようなものですし、現実的ではない気がしています。

# IT 管理者が管理出来ていない状態

次に、IT 管理者が管理出来ていない状態について考えてみます。

まず、管理出来ていない状態とはどういったことを指すのかについて人によって認識が異なると考えます。そういった意味で、以下の観点で整理してみます。

・誰が作成したのか (Who)
・いつ作成したのか (When)
・どこに作成したのか (Where)
・何が出来るのか (What)

##  誰が作成したのか (Who)

CoE スターターキットの Admin View アプリを使えば簡単に把握できます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3074511/77c5bc48-5806-3a0f-2e87-5261ccbf2693.png)

もちろん、この情報から、何かあればアプリの所有者に連絡をしたり、上述の通り、所有者を管理者の方で追加することも出来ます。

## いつ作成したのか (When)

CoE スターターキットの Admin View アプリを使えば簡単に把握できます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3074511/805ae51f-a650-f918-c4e9-6f36a92db9f4.png)

## どこに作成したのか (Where)

CoE スターターキットの Admin View アプリを使えば簡単に把握できます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3074511/c122b2e8-fabd-0efd-b909-ecf55b11c9d7.png)


## 何が出来るのか (What)

DLP ポリシーを設定することで、Power Apps で作成したアプリや Power Automate で作成したクラウドフローが連携できるサービスを制御できます。

例えば、既定の環境という多くのユーザーが利用可能な環境では、普段利用しているマイクロソフト系のサービス以外はブロックするということも出来ます。この場合、**普段利用しているサービスを通じた作業が効率化されているという状態と考えます。**

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3074511/e0b00b74-a2f6-82fd-889f-fa04f6aeb3f2.png)

また、念のための補足ですが、アプリやフローを介して、Teams、Outlook、SharePoint など、ユーザーとして認証するコネクタ―を利用する場合、**そのユーザーが普段できることしかできません。** 


例えば、以下のような Outlook のコネクタ―を利用する場合、自分の代わりにメールを送ったり、自分の予定表の情報を操作できますが、元々アクセス権のない他人の予定表を見たり、代理送信権限のない他人の代わりにメールを送るようなことは出来ません。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/3074511/3704e4c7-8f0d-53aa-9645-d00a5e52570c.png)

そのため、コネクタを Microsoft 365 系のサービスに制限している場合に何が出来るかというと、**「普段ユーザーが Outlook、Teams、SharePoint 等で出来ること」** ということになります。
 

## 管理出来るのでは？

上記を考慮すると、個人的には、**CoE スターターキットや DLP ポリシーを使えば十分管理できるのでは？既に実施している場合は管理出来ているのでは？と感じています。そのため、上記のようなことをしている状態において、野良アプリ対策が必要と言われると少し違和感を覚えます。**

実際に、上記のような方法で管理して市民開発を促進している組織も沢山あるという認識です。そのため、意思決定者など、誰かに「野良アプリ対策をしなさい、野良アプリが不安」というようなことを言われたら、まず、**Power Platform では上記のような管理が出来るということを認識していただき、未実施の場合は早い段階で実施するのが良いかと思います。**

## もっと管理する?

もし、これ以上管理するとなると、例えば、以下のようなアプローチが考えられますが、そこまでの管理をするか、デメリットについても考慮して意思決定する必要があると考えます。

* 個々のアプリやアプリやフローの詳細を把握する
* 全容が分からないので作成したものを強制削除する

### 個々のアプリやアプリやフローの詳細を把握する

こちらについて、CoE スターターキットをベースに、個々のアプリやフロー管理者に通知をして Business Justification などの把握したい情報を入力してもらい、それを元に IT 管理者が判断し、了承されれば継続利用可能にするという方法が考えられます。

ただし、膨大に存在する、大幅に増えていくことが想定される全てのアプリやフローに対してそのような管理をするためにはかなりの労力がいると思います。そのため、**本当にそこまでの管理が必要なのか、いきなりそこまでの管理が必要なのか、検討が必要と考えます。**

個人的には、少なくとも、いきなりそのような状態を目指すのは現実的ではないと考えます。仮に何かアクションを起こすとしても、利用者が多いアプリにも拘わらず所有者が一人になっているなど、インパクトが大きそうなアプリについて優先度を上げて対応するのがいいかなと思います。

この辺についても、CoE スターターキットの監査ログコンポーネントや、「Set App Permissions」 アプリを利用することで把握可能です。

https://learn.microsoft.com/ja-jp/power-platform/guidance/coe/setup-auditlog-http

:::note
そのようなアプリを見つけたら、単に所有者を追加するだけでなく、そのようなアプリを作成している人を賞賛し、市民開発者コミュニティ推進に協力してもらうのが良いかと思います。
:::

### 全容が分からないので作成したものを強制削除する

作成されたアプリやフローを管理者が強制削除することも、技術的には出来なくはありません。

ただし、物凄く労力を要します。また、人口が減少しており、IT 管理者が不足しており、2023 年には新規開発されるアプリケーションの 60% がローコード/ノーコードプラットフォームで開発されると予測されている中、せっかく業務を効率化するために作成されたアプリやフローを強制削除するのはもったいないと個人的に思います。

**更に、削除されることで新たな市民開発者が生まれようとする芽を摘むことになる可能性がある点についても考慮が必要と考えます。**

私も一市民開発者ですが、業務改善、効率化のために自己投資して、一生懸命作成したアプリやフローが強制削除されたら非常に悲しくなるというか、下手すれば転職すら考えます。

https://www.idc.com/getdoc.jsp?containerId=prJPJ49023422

上記のようなデメリットも踏まえ、そこまでのことをするか、検討が必要と考えます。

# まとめ

Power Platform での野良アプリ対策について、野良アプリの定義を踏まえつつ私の考えを整理してみました。

そもそも何をもって野良アプリと呼んでいるのか、認識を合わせ、Power Platform で管理出来ることを認識し、どのような対策を取るかという意思決定をするためのお役に立てば幸いです。