PowerAppsのデメリットやできないことを解説する
はじめに
2023年のおよそ１年間、PowerAppsを使用したシステム開発に携わりました。
PythonやRubyなどの通常のプログラミング言語の経験を数年積んできた開発者としては、あまりにも機能が不足しており、とてもシステム開発に使用できるツールではなかった、というのが率直な感想です。
普通なら30分で作れるような処理を作るのに数日を費やしたり、謎の仕様によってバグが発生したり、バージョン管理もテストもまともにできなかったりで、開発者である私自身が全く信頼できないシステムを作ってしまいました。
WEBで検索するとPower Appsのメリットについ紹介する記事がたくさん出てきますが、正直言って嘘だと思っています。「未経験でもデータの入力フォームが30分で作れました！」というのは確かに可能ですが、システム開発というのはそれだけではありません。ユーザーの管理やセキュリティ、テストやデプロイ、他システムとの連携といった諸々の検討を行っている記事は全くありません。ツールを導入するにあたり行うべきメリット／デメリットについても開発者としてきちんと検討する必要があるでしょう。「プログラミングの知識が不要」である代わりに「Power Appsの知識が必要」なのです。当たり前ですね。
私が経験したのは、特にPower Appsを導入すべきでないユースケースで、そのデメリットを最大限に発揮してしまうような環境だったと感じています。
そんなわけで、私の１年間の苦痛と後悔をなるべくわかりやすく表現しようと思いました。現在導入を検討している方の参考になれば幸いです。
Power Appsについて
Power Appsとは、Microsoftが提供するPower Platformというローコード開発サービスの一部で、Power BI , Power Automate , Power Pages , Dataverseといったサービスと連携して使用します。
Power Appsで扱うデータは基本的にDataverseと呼ばれるデータベースに保存し、定期実行やイベントを検知して実行する処理はPower Automateで作成します。他にも専用のBIツールであるPower BIや、外部にサイトを公開するためのPower Pagesなどが用意されています。
Dataverseの代わりにSharePointのListやOneDrive上のExcelにデータを保存したり、TeamsやOutlookに通知を送ったりと、Microsoftのサービスならある程度スムーズに連携することができます。
なお、DataverseはSQL ServerにPower Platformで使用するためのラップを施したものです。そのため、Power Apps外のサービスを連携させて使うことは基本的に不可能であり、どうしても必要な場合はデータベースのミラーリングなどの作業が必要です。
Power Appsは、フォームやページなどのフロントエンドアプリケーションを開発するためのローコードツールです。予め用意されたUIコンポーネントを画面に配置しいくことでシステムを作っていきます。キャンバスアプリという比較的自由度の高いものと、モデル駆動アプリというDataverseに強く紐付いた高機能のものがあります。APIを処理するようなバックエンドシステムは作れません。
コンポーネントはそれぞれプロパティを持ち、フォントの色やサイズ、クリックした時の処理、ページ遷移時の動作などを設定することができます。GUI画面からマウス操作で作成していくことができるため、システム開発に慣れていない非エンジニアでも気軽に作成できます。
ローコードと言われている通り一部コードを記載する必要があり、処理の内容はPower Fxという専用の言語で実装します。HTMLやJavaScriptは使用できません。Power FxはExcelの関数に似た文法の言語です。変数を定義したりIfやWhileである程度のロジックを組んでいくことができます。
Power Appを扱う上で注意すべき点がたくさんあります。
まず、関数を定義したりクラスを作成することができません。そのため、コードの再利用や変数のカプセル化などの基本的なテクニックが使用できず、同じコードをシステム内に何箇所もコピペしなければいけないケースが発生します。これは保守する上で絶望的に不便であることは言うまでもありませんし、自動テストを実施することも不可能です。なお、「コンポーネント」という機能がありますが、これはヘッダーやボタンなどのUI要素を共通化するものであり、処理を記述して使いまわすためものではありません。
また、複数人で同時に編集することはできません。２人目以降は閲覧モードで開くことになります。Gitのようにブランチを切ってマージするということもできませんので、メンバー同士で作業する時間を分ける必要があります。そもそもPower Appsは１人または少人数で開発するためのもので、チーム開発は想定されていません。更新の方法もコミットではなく上書き保存なので、変更にコメントを残したりすることもできません。もちろん変更における差分表示もできません。過去のバージョンに戻すロールバックは可能ですが、これだけあっても何の役にも立ちません。
Github Actionsのようにデプロイを自動化する方法はありません。ProductionとDevelopで環境を分けたければ、アプリをzipファイルにエクスポートして別環境にインポートする、という作業を手動で実施する必要があります。もちろんアップデート対象を間違えるなどのミスなどが考えられますので、頑張って気をつける必要があります。Power Automateの依存を含むような場合は地獄です。
委任をサポートしていないデータソースでは2,000件以上のレコード数を扱うことができず（デフォルト500）、それ以上のレコードは表示したり計算することはできません。委任とはレコードの計算をデータベース側で行ってもらう機能のことでで、DataverseとSharePoint Listで使用できます。Power Platform以外のSQL ServerなどのDBと接続するためのコネクタも存在しますが、委任がサポートされていないため使い勝手が悪く、場合によってはシステム要件が満たせないこともあるため注意が必要です。ExcelファイルをDBの代わりに使用するなんてもってのほかです。
レコードの取得に関連しますが、Power PlatformでSQLの文法を使用することはできません。データソースから取得したレコードはPower Appsの中でコレクションという辞書型配列のような形でデータを保存し、フィルタや結合といった操作はPower Fxの関数を使用して行います。Filter, LookUp, AddColumnsといった関数がありますが、とてもSQLと同等に使える代物ではありません。もちろん旧システムで使用していたクエリ文を流用するといったこともできません。
Power Platformはフルマネージドなサービスであり、アプリケーションが動作するためのホストマシンを管理する必要はありません。ただしこれは裏を返すとランタイムをユーザー側で指定することができない、ということでもあります。Power Appsは機能の追加が度々あり、場合によっては不意のバージョンアップで急に動かなくなった、というケースも考えられます。いちおうAzure上でPower Platformを動かすことも可能らしいです。そこまでするなら別のシステム使った方がいいとは思いますが。
新しいツールであることのデメリットもあります。PowerPlatformの初期リリースは2018年です。つまり、経験者を探しても最大でも６年ほどの経験しかなく、WEBで検索してもヒットする情報が多いとは言えません。Pythonのように豊富なライブラリなど望むべくもありません。というか、サードパーティのエコシステムどころかライブラリというものすら存在しません。Microsoftが提供している機能だけでやりくりする必要があります。
また、Power Appsに限らずローコードツール全般で言えることですが、コピペができません。コードベースのプログラミング言語であれば、コピペすればそのまま動くコードを掲載してくれる親切なブログもあり、それを手元で動かしながら理解を深めていく（あるいは何も考えずに使う）ことが可能ですが、Power Appsではそのようなことはできません。ブログにある内容は「画面の左上からアイコンをクリックしてコンポーネントを追加して、、、」といったような手順が記載されており、それに従って手元で同じものを作っていく必要があります。これはノウハウを公開して共有する上で非常に不便です。また、前述の通りアップデートが度々あるので、記事の執筆時点とは手順が変わっている場合もよくあります。
あと、Power Apps Studioという専用のブラウザ画面で編集しなければならず、VSCodeやVimが使用できないのは開発体験としては非常に悪いです。これは、コード欄が狭くて読みにくい・エラー表示がわかりにくい・ブレークポイントでデバッグできない、といった個別の問題だけではありません。少なくともC言語の開発から50年以上続いてきた『テキストファイルでプログラムの実行内容を記述する』という開発体制と共に発展してきたバージョン管理システム・テキストエディタ・文法チェックツールなどの資産を活用することができない、ということでもあります。50年前にタイムスリップしたような感覚でした。
『ローコードツールにより業務を効率化する』とはどういうことか？
ローコード ツールを使用して、コストを削減し、開発時間を短縮します といったようなその手軽さを強調したキャッチコピーが公式サイトに掲載されていますが、実際にその恩恵を受けられるかどうかは業務システムの要件や導入方針によります。
勘違いされることが多いのですが、ローコードツールはエンジニアが使用するためのものではありません。社内の各部門が自分でシステムを開発するためのものです。
キャッチコピーの中には 組織内のすべてのユーザーがローコードツールを使用してソリューションを開発できるようになります と書かれてていますし、よく寄せられる質問 には ローコード開発は開発者に代わるものではなく、ITチームに追加のツールを提供します とも書かれています。コンポーネントをマウス操作で組み合わせていく操作であれば、開発未経験者の方でもハードルを感じることなく気軽に触ることができるかと思います。お客様事例としても人事・営業・在庫管理といった非開発部門が導入した事例として紹介されることが多いです。
つまり、ローコードツールによりコストが削減されるというのは、各部門が業務に必要なシステムを外部に発注することなく内部で作成し、開発部門はプロフェッショナルな知識を要求する重要なタスクに集中できるようになる、というメカニズムで実現されます。『開発時間を短縮できる』『システムを迅速に構築できる』という謳い文句は、従業員全体がITシステムの開発に参加できることを意味しています。キャッチーさよりも厳密さを重視するなら、『開発業務を社内で効率的に柔軟に配分できるようになる』と表現するべきです。ITの専門家である開発部門の業務は、アプリ作成におけるコンプライアンスを定めたり各ユーザーの使用状況を監視する、などといったことでしょうか。
前述したとおり、Power Appsには大規模なシステムを開発するための機能は備わっていません。そのような状況でエンジニアが開発・運用しているような社内システムの根幹をPower Appsに置き換えるべきではありません。用意されたテンプレートの範囲外の機能を実装しようとした途端にシステムは爆発的に複雑化し、コード欄にPower Fxをゴリゴリ書いてアップデートの度に出グレが発生する、といったことが頻発します。繰り返しますが、関数やクラスの自作はできませんので可読性や保守性は劣悪ですし、自動テストも作成できません。その他にも、リファクタリングやデプロイの工数増大、開発メンバー同士の連携の複雑化といった問題が発生します。感覚として、複数テーブルのトランザクション処理が必要・扱うレコード数が2,000以上といった要件が入ってくるとPower Appsでは手に負えなくなってくるため、素直にRails, Laravel, ASP.NETなどの使用を検討するべきでしょう。なお、DataverseにPower Platform外からアクセスすることはできないので、一部のみ置き換えるということは難しいです。Power Appsは「短納期で簡単にシステムを開発できる」のではなく、「短納期の簡単なシステムしか開発できない」と理解してください。
そもそも「簡単にシステムを開発できる」とはどういうことでしょうか？
「敷居が低い」ということと「簡単である」ということの間にはなんの関係もありません。プログラミング未経験者が入力フォームを30分で作れたからといって、同じペースでより複雑なシステムを作れるようになるわけではありません。むしろ、最初の敷居が低いものほど後々費やす時間が増えていく傾向があります。システム設計、アプリケーションの実装、インフラの保守といった一連の開発業務の中で、設計と保守を度外視してアプリの実装だけに焦点を当てた結果、30分というキャッチーな数値が一人歩きしているのです。
テクノロジーとしての難しさとビジネスロジックとしての難しさも分けて考えるべきです。難しいビジネスロジックは、どのようなツールを使用しても難しいのです。これは、通常のプログラミング言語だろうが変わりませんし、むしろ一見とっつきにくい複雑な制約のあるものの方が複雑なビジネスロジックを処理するのに有利だったりします。そのへんをよく検討せずに「ローコードツールを使用すれば開発が簡単になるんでしょ」みたいに考えるべきではありません。
ただ、非IT部門が小規模なシステムを自作するためのツールとしては非常に優れていると思います。フォームを作成するために<form>やら<input type='submit>といったコードを経由することなく、マウス操作で視覚的にコンポーネントを配置することができるというのは画期的な発明です。自分がゴリゴリのエンジニアなので忘れてしまいがちですが、コードを書いてシステムを作成するというのはけっこう特殊な技能です。業務内容は習熟しているもののプログラミングは全くわからずアレルギー反応を起こしてしまうという社員は珍しくありませんが、そういった方々をシステム開発の戦力として数えることができることは企業としてもシステム開発者としても歓迎すべきでしょう。30分で作れる小規模のシステムを現場でいくつも作成して活用してもらい業務全体を効率化していく、というのがローコードツールの意図する業務効率化の形です。また、一部の社員だけが理解しているめちゃめちゃ複雑なExcel / Accessファイルで業務が成り立っているという状況を、Power Appsによって置き換えるといったようなユースケースも考えられます（Power Appsは大量データの処理やテーブルの結合が苦手なので実際できるかどうかはわかりませんが）。
結論としては、対象となるシステム要件やビジネスロジックに最も適したツールを一般論ではなく個々に検討して決めるべきということになります。当たり前ですね。
おわりに
「アジャイル」という単語には２つの意味があります。「DDDな設計手法に基づきユビキタス言語を通じてドメインエキスパートの力を借りながらビジネスロジックを洗い出してリファクタリングやテストを実施しやすい環境を作り、競争優位性を生み出すために継続的にシステムを改修・拡張していく開発体制」というものと、「設計する工数がないのでとりあえず作って」というものです。Power Appsにおいて前者の要件を満たすことは不可能であることはこれまで書いた通りですので、もし現場でそのような単語が出てきた場合は必然的に後者の意味になります。
社内にPower Appsの導入を検討している方や、なんとなく簡単そうだからという理由で導入されそうな状況をどうにかして止めたいと思っているエンジニアの皆様にとって、この記事が参考になれば幸いです。
2020年の記事ですが、かなり同意できる内容が書いてあります。参考までに
Discussion
拝読しました。ApacheTomcat→Lambda、Windowsアプリ→XAML化ですら大変だったので、Power Appsの惨状は想像に難くないです。
事務アプリならキントーン買った方がましですかね。使ったことないですが…