Power Platformで人事評価アプリを作ってみた

# はじめに
近年、手軽にアプリを開発できることからノーコード・ローコードが注目されています。
ノーコード・ローコードとは、コードを書かずに、または少ないコード量でアプリを開発することを指します。

私は、ローコードツールの一つである、Power Platformを用いて社内のMBO評価制度における運用プロセスをシステム化しました。
MBO評価制度の詳細は、[目標管理制度（MBO）](https://www.hrpro.co.jp/glossary_detail.php?id=24#:~:text=%E3%80%8C%E7%9B%AE%E6%A8%99%E7%AE%A1%E7%90%86%E5%88%B6%E5%BA%A6(MBO),%E7%B5%84%E7%B9%94%E3%83%9E%E3%83%8D%E3%82%B8%E3%83%A1%E3%83%B3%E3%83%88%E3%81%AE%E6%A6%82%E5%BF%B5%E3%81%A7%E3%81%99%E3%80%82)(HUMAN RESOURCE PROFESSIONALより引用)を参照ください。

今回、MBO評価制度の運用プロセスをシステム化するに至った背景は以下です。
今まで、目標設定や評価における情報のやり取りは、メールやエクセルファイルを利用していました。しかし、情報の一元管理や間違いのないやり取りができないかを考えて、ツールによる評価管理作業の改善を考えてみました。

また、開発用のツールとしてPower Platformを選んだ理由は以下の2つです。

- 弊社では社員の情報をMicrosoftアカウントで管理しており、Microsoft社の提供しているツールを使用すれば新たにログイン管理機能を開発する必要がなくなるため。
- Power Platformは無料で利用でき、かつ手軽に開発ができるため。

しかし、Power Platformには不明な点が多く、システム的なふるまいや制限事項を明らかにする必要があったため、まずはプロトタイプを開発しました。

MBO評価制度にて扱う情報は各種ありますが、プロトタイプ開発時は、やり取りするであろう情報を仮想的にシンプルに考えながら開発しました。

本記事では、作成したプロトタイプの概要とPower Platformを使用して感じたメリット・デメリットを紹介します。

想定読者は、Power Platformを用いた開発経験が浅い人を想定しています。
また本記事は、Power Platformを用いるメリット・デメリットを少しでも皆さんに共有することを目的としています。

# Power Platformとは
Power Platformとは、Microsoft社が提供している業務アプリケーションプラットフォームであり、Power Apps、Power Automate、Power BIの3つのツールを用いてデータの収集から解析・予測までローコーディングで実現するプラットフォームです。
3つのツール全てを使用する必要はなく、例えばPower Appsのみを使用したアプリの開発も可能です。

以下に3つのツールの特徴を記載します。

- Power Apps
    - Power Appsは主に、アプリ作成を行うツールです。
    - アプリに必要な機能や要素をライブラリから選択し、開発画面内に配置することで、簡単にアプリを開発できます。
    - SharePointやoutlook、Youtubeなど多数のデータソースと連携が可能なため、多くのユースケースに対応可能です。
    - 条件分岐やループ処理も記載可能なため、手軽に独自のロジックでカスタマイズ可能です。

- Power Automate
    - 主に処理の自動化を行うツールです。自動化する一連の処理をフローと呼びます。
    - 以下の3パターンの方法で、フローの起動が可能です。
        - ある事象をトリガーにしてフローを起動する。
        - 手動でフローを起動する。
        - 起動するタイミングや頻度を指定してフローを起動する。
    - Power Appsから呼び出される際、引数にJSON関数を使用する事ができるため、Power AppsからPower Automateに多くの情報を引き渡せます。

- Power BI
    - 主にデータ分析を行うツールです。データの抽出や、結合、変換を行えます。
    - データ分析の結果を基に、レポートを作成できます。
    - 作成されたレポートを、自動的に更新できます。

Power Platformの概要は[Microsoftが提供するPower Platformとは一体何なのか？簡単に解説！](https://www.cloudtimes.jp/dynamics365/blog/microsoft-power-platform.html)を参照ください。(BizAppチャンネルより引用)

またデータの格納先には、SharePointやCommon Data Serviceが挙げられます。

Common Data ServiceはSharePointよりも複雑な権限管理が可能であったり、作成したエンティティにWebAPI経由で容易にアクセス可能であるなど、機能面ではCommon Data Serviceの方が優れています。
しかし、Common Data Serviceの使用は有料ですが、SharePointは無料で使用できます。

# プロトタイプの概要
## プロトタイプの構成図
今回のプロトタイプ開発では、データ分析の要件は無いため、Power AppsとPower Automateを使用しています。データの格納先は、無料で利用できるSharePointを使用しました。

また、評価者アプリと被評価者アプリの2種類のアプリを作成し、使用する人の役割(評価者か被評価者か)によってアプリを使い分ける運用にしました。

以下、MBOシートの新規登録や編集を実現している構成図です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/905863/bf5dff86-087e-9b0d-818a-c893e38b8ded.png)
MBOシートの新規作成時、被評価者は、SharePointへの投稿権限がない状態でMBOシートを登録する必要があります(※1)。そのため、Power Automateを経由することでMBOシートをSharePointに登録できるようにしています。
そして、SharePointにMBOシートを登録した後にMBOシートの閲覧・編集権限を被評価者と評価者にPower Automateを使用して付与しています。

MBOシートの編集時は、SharePointへの投稿権限がある状態なため、直接SharePointにMBOシートの変更情報を登録しています。

※1
SharePointの権限管理では、SharePointに対する投稿権限と投稿したリスト内の全レコードの閲覧権限がセットで付与されるという制約があります。
この制約があると、被評価者が予めSharePointに対する投稿権限を持っている場合、他の被評価者のMBOシートも閲覧できてしまいます。

業務の運用上、他の被評価者のMBOシートが自由に閲覧できてしまうと、評価結果まで筒抜けになってしまうので望ましくありません。
そのため、被評価者はSharePointに対する投稿権限が無い状態で、MBOシートを登録し、後から自分の登録したMBOシートのみに対して閲覧・編集権限を付与する必要があります。

## プロトタイプの機能紹介
プロトタイプの主な機能を以下の流れで紹介します。
被評価者が目標設定を行い、評価者が目標を承認するケースを想定して機能を紹介します。

1.被評価者が目標を入力する
2.MBOシートを新規登録し、被評価者と評価者にMBOシートの閲覧・編集権限を付与する
3.評価者が被評価者のMBOシートを閲覧・編集する
4.評価者が被評価者の目標を承認する

### 1.被評価者が目標を入力する
↓被評価者アプリ、MBOシートページ1
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/905863/4233c947-6865-499d-420f-88ad9f7fef9e.png)
↓被評価者アプリ、MBOシートページ2
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/905863/181332e2-f5ec-e82e-cd76-079c2c1af0b9.png)
被評価者は「被評価者アプリ」を用いて、目標承認者や目標、各目標の配分を入力します。
入力後に保存ボタンを押下することで、Power Automateのフローが作動し、MBOシートの登録や被評価者と評価者にMBOシートの閲覧・編集権限を付与する処理が行われます。


### 2.MBOシートを新規登録し、被評価者と評価者にMBOシートの閲覧・編集権限を付与する
Power Automateのフローを用いて、MBOシートの登録や被評価者と評価者にMBOシートの閲覧・編集権限を付与する処理を行います。

被評価者はSharePointに対する投稿権限が無い状態なため、直接SharePointにMBOシートを投稿できません。そのため、MBOシートの新規登録はPower Automateのフローを使用します。

MBOシートの新規登録は、親フローから子フローを呼び出すことで実現しています。
親フローとは、自分のフローの中で別のフローを呼び出すフローを指します。
子フローとは、別のフローによって呼び出されるフローを指します。

(SharePointに対する投稿権限がない状態で子フローを用いると、なぜMBOシートを登録できるのかは[SharePointに対する投稿権限が無い状態で、MBOシートを登録する](#プロトタイプ作成にあたって苦労したポイント)の項目に記載しています。)

### 3.評価者が被評価者のMBOシートを閲覧・編集する
↓評価者アプリ、トップページ
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/905863/36b585b3-2310-2000-2b51-0fa70220454a.png)
評価者は「評価者アプリ」を用いて、被評価者のMBOシートを閲覧します。
先ほど、被評価者が登録したMBOシートが評価者アプリのトップページに表示されています。
表示されているMBOシートを選択すると、MBOシートの詳細が閲覧・編集できます。

### 4.評価者が被評価者の目標を承認出来るようにする
↓評価者アプリ、MBOシートページ
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/905863/853a3a9d-3690-5ffc-2fb9-7d74e6f219f9.png)
評価者は、MBOシートページにて承認ボタンを押下すると、被評価者の目標を承認できます。

↓評価者アプリ、トップページ
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/905863/2357953f-1846-1634-13bc-3ba3ca65f43d.png)
承認ボタンを押すと、トップページに遷移します。トップページにて、ステータスが「目標設定中」から「目標設定済」となり、目標の承認を確認できます。

## プロトタイプ作成にあたって苦労したポイント
### 1.SharePointに対する投稿権限が無い状態で、MBOシートを登録する
SharePointの権限管理では、SharePointに対する投稿権限と投稿したリスト内のレコードに対する閲覧権限がセットで付与されます。
そのため、今回のプロトタイプ開発のようにSharePointに対する投稿権限が無い状態で、MBOシートを登録したいというケースには工夫が必要です。

私は、MBOシートの新規登録時にPower Automateの子フローを用いることで、SharePointに対する投稿権限が無い状態でも、MBOシートの登録を実現できるようにしました。
子フローを使用する事で上記が実現できる方法を以下に記載します。

子フローは、手動でフローを起動する設定であるインスタントフローという種類を使用しており、「手動でフローをトリガーします」というトリガーを使用しています。
このトリガーを選択すると、フロー詳細画面の右下に「実行のみのユーザーという項目」ができます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/905863/1a9cb5cd-6189-d59b-1178-5e8929c12fc0.png)
「実行のみのユーザー」とは「このフロー(子フロー)を実行をするユーザー」という意味です。
「実行のみのユーザー」の編集ボタンを押下すると、画面下部に「使用する接続」欄が表示されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/905863/c217e5d0-7a44-50ed-6223-84da63d2e3c9.png)
「使用する接続」では、フローの所有者の接続を指定できます。そして、指定した接続を使用して子フローが実行されるようになります。
つまり、所有者にSharePointの投稿権限が付与されていれば、子フローの使用ユーザーは投稿権限がある接続を使用するようになるため、SharePointに投稿できるようになります。

###2.特定の関数を使用すると、500レコードしか操作できなくなる
Power AppsでSharePointなどに格納しているデータを操作する際は、使用する関数に注意する必要があります。

Power Appsでは、特定の関数を使用した場合500レコードまで(2000レコードまで拡張可能)しか処理できません。
例えば、5000レコードを処理するつもりで特定の関数を使用してしまうと、最初の500レコードしか処理できません。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/905863/87d35864-9d91-80e4-4193-32b66b4a946f.png)
特定の関数は複数あり、無意識に使用してしまう可能性があります。
しかし特定の関数を使用すると、上記の画像のように警告として黄色い三角形が表示されるので、警告を避けて開発をすれば500レコードしか処理されない事象を避けられます。

特定の関数詳細は[キャンバス アプリでの委任について](https://docs.microsoft.com/ja-jp/powerapps/maker/canvas-apps/delegation-overview)(Microsoft社公式ドキュメントより引用)を参照ください。

# Power Platformを使用するメリット
- 簡易的なアプリをすぐに作成できる。
    - 必要な機能や要素をライブラリから選択して開発画面内に配置するだけでアプリを作成できます。
- 接続可能なデータソースが多い。
    - SharePointやoutlook、Youtubeなど様々なデータソースと接続ができるため、多数のユースケースに対応可能です。
- Azure Active Directoryと容易に連携できるため、ログイン機能が不要。
    - アプリを使用しているユーザーを自動で識別して、画面内にActive Directoryに登録されている情報を表示できます。
    - Azure Active Directoryに登録されている他のユーザーを容易に表示できます。

# Power Platformを使用するデメリット
- 大規模開発に向かない。(一度に複数人で開発ができない)
    - 開発画面を他人と共有できないため、複数人での開発ができません。
- データモデルを変更すると、レイアウトを一から作り直さないといけない。
    - 例えば、SharePointのカラムを一つ追加する場合、一度フォームをクリアして再度一からレイアウトを整えたり、ロジックを組み込む必要があります。
- 無料で開発する場合、制限が多い。
    - Power AppsやPower Automateで接続可能なデータソースの内、HTTPコネクタやSQLサービスなど多くのデータソースは有料です。そのため無料で開発する場合は、制限されたデータソース内で開発する必要があります。
    - 無料サービスのSharePointの場合、レコードを500件しか処理しない関数が有料サービスのCommon Data Serviceよりも多く存在します。そのため無料で大量レコードを複雑に処理する場合は、有料サービスよりも多くの関数を避けて開発する必要があります。

# 最後に
今回初めてPower Platformを使用しましたが、簡易的なアプリを作成するツールとしては、非常に有用なツールだと感じました。
簡易的と言っているのは、画面数が4~5画面で収まり、扱うデータ数が少なく、お互いのデータが関係し合っていないデータ構造を扱っているアプリを指しています。
例えば社内で利用し、開発も一人ででき、データテーブルが一つあれば開発可能なアプリであればPower Platformは向いていると感じます。

Power Platformを用いると簡単にアプリを作成できるので、ちょっとした日常業務を手軽にシステム化できることが一番のメリットだと感じています。
Power Platformが適している用途はたくさんあり、ITの知識があまりなくても気軽にアプリを作成できるので、これからも様々な場面でPower Platformは使用されるでしょう。

本記事が、皆さまのPower Platformの理解のお役に立てたら幸いです。