1. システムとオフィスの融合
  2. media
  3. Power Apps Power Platform
  4. Microsoft Power Platform ローコード開発で気を付けていること - Power Apps キャンバスアプリ編

QESブログ

Microsoft Power Platform ローコード開発で気を付けていること - Power Apps キャンバスアプリ編

  • LINEで送る
  • このエントリーをはてなブックマークに追加
Microsoft Power Platform ローコード開発で気を付けていること - Power Apps キャンバスアプリ編

はじめに

 Microsoft Power Platform では、ローコード開発ができるだけでなく、データベースやネットワークも用意されており、従来のフルスクラッチ開発に比べ、アプリの総開発工数を大幅に減らすことができます。
 Microsoft Azure や AWS などのクラウドサービスの利用で、システム開発リソース・コストが削減され、ビジネスにかけられるリソースの増加に繋がっているかと思いますが、Microsoft Power Platform の導入はその最たるものになるかと思います。
 しかしながら、Microsoft Power Platform でのローコード開発には多くのメリットがある反面、留意しなければならない点もあります。今回は、Power Apps キャンバスアプリのローコード開発で、私が気を付けている点について、1つご紹介しようと思います。


Microsoft Power Platform 要求

 Power Apps では、ライセンスごとに利用できる機能が変わってきます。この点につきましては、Microsoft公式サイト「Power Apps の価格」をご確認いただければと存じます。
 機能に加え、ライセンスを選定する上で重要となってくるのが「Microsoft Power Platform 要求」の制限になります。

表1.Microsoft Power Platform 要求数の制限
ライセンス Power Platform 要求数の制限
PowerApps per app plan 6,000 コール/日
PowerApps per User plan 40,000 コール/日
M365/Office 365(E1/E3/E5) 6,000 コール/日

 以下のMicrosoft公式サイトに詳細があるので、是非、確認してみてください。
  要求の制限と割り当て

 1日の利用頻度が高いアプリや、大量のデータを取り扱うアプリでは、Power Platform 要求の制限にかかる可能性が高まります。この制限にかからないよう、Power Appsでは、APIリクエスト要求数、Power Automateではアクション数を考慮した設計が必要となります。
 しかし、最初からこれらの制限をメインに据えてしまうと、なかなか開発が進められないこともあります。まずは、自分達が求めているアプリを自由に作成し、プロトタイプ版で実際に運用してみると、イメージできるかと思います。


「Power Platform 要求」を設計に盛り込むまでの経緯

かくいう私も、初めから Power Platform 要求の制限を考慮してローコード開発を進めていたわけではありません。
ここに至るまでには、以下のような経緯がありました。

Power Platformで最初の開発

 1.取り合えず動くアプリを自由に開発(プロトタイプ開発)
 2.机上での動作確認(テスト)
 3.公開
 4.プロトタイプを実運用にのせて評価
 5.性能が急激に落ちたり、エラーが発生するケースを検知
 6.調査 ⇒ Microsoft Power Platform 要求の制限にひっかかっていることが判明
 7.Dataverse操作やAPIコール数を減らすための改修

 まず、公開前に実運用を想定したテストが必要でした。従来のアプリ開発では、性能テストやシナリオテストを実施するかと思いますが、これはPower Platformを利用したアプリ開発でも変わらないと思います。Power Platform 要求の制限にかからないよう、事前に確認するためには、以下のようなポイントがあります。

  • 1日(24時間)のアプリへのアクセス・利用頻度
  • 利用人数
  • データ量 ...など


 最初の開発で、Power Platform 要求の制限にかからないようにするための改修に思いのほか時間を要したため、次回以降の開発からは、最初から Microsoft Power Platform 要求の数を考慮した設計を実施するようになりました。
 テストフェーズでの検証の繰り返し、手戻りにかかる工数を考えると、ローコード開発でも、このあたりの設計は必須だと感じています。


具体的な対策

 ほんの一部ですが、私が Power Apps ローコード開発で、Power Platform 要求数を抑えるために実施していることをご紹介します。

  • 設計
    各ページ単位で、初回ロード、ボタン、リンク押下などで発生するPower Platform 要求数を設計書に盛り込む。
    全体の要求数を試算する際に有用です。
  • 変数、コレクションを利用する。
    アプリ起動時に、Dataverse、APIなどからデータを取得し、変数・コレクションに保存することで、可能な限り以降の処理をローカルで行うようにする(Dataverse操作、APIコールが発生しないような設定にする)。オフラインで動作するアプリの設計をイメージ。
    変数については、以下のMicrosoft公式サイトが参考になります。
    キャンバス アプリの変数を理解する
  • Microsoft Azureとの連携
    APIで実現可能な処理は、App ServiceやAzure Functionsを利用する。

 Power Platform ローコード開発を進める上で注意しなけばならない点、その対策はまだまだありますが、それは次回以降で。


おわりに

 QESでは、Microsoft Power Platformの開発を支援しています。請負での開発だけでなく、技術サポート、初心者向けのオンラインセミナーなど、多数サービスをご用意しております。Microsoft Power Platformの導入、Power Platformを利用したアプリ開発を検討されている方は、是非、お声がけいただければ幸いです。

 また、QESでは、Power Platformだけでなく様々なアプリケーションの開発・導入を行っております。私共が提供するサービス・ソリューションにつきましてはこちらに掲載しております。
 システム開発・構築でお困りの問題や弊社が提供するサービス・ソリューションにご興味をお持ちいただけましたら、「お問い合わせ」フォームから気軽にお問合せください。


 QESでは、クラウドエンジニアを募集しております。詳細につきましては、下記のリンクからご確認ください。


 QESでは、Microsoft製品やAWS製品に関するソリューションに取り組んでおります。他プロダクトに関するブログも投稿しております。下記のリンクから是非ご覧ください。
※このブログで参照されている、Microsoft、Windows、Azure、PowerApps、Application Insightsその他のマイクロソフト製品およびサービスは、米国およびその他の国におけるマイクロソフトの商標または登録商標です。また、WordPressは、WordPress Foundationの商標または登録商標です。
  • LINEで送る
  • このエントリーをはてなブックマークに追加

お気軽にお問い合わせください。

ページのトップへ