前置き
Power Appsを半年ほど使っていました。使っている間にPower Appsが使いにくいなぁと感じたことが多々あったので、主に短所をまとめてみます。Power Appsを今後使ってみようかなと考えている方も参考になるかもしれません。NoCode/LowCode一般に対しての私見も含みます。
個人的な意見ですがNoCode/LowCode開発は苦手です。適当にブラウジングしていると見かけるPower Appsのデモアプリは大体がこんなことが手軽にできるよ！といいますがあくまでも画面が2，3つのサンプル程度のものです。その割にこれからの時代はNoCode/LowCodeだ！誰でも簡単にシステムを作れる！と誇張されている気がします。そのたびに自分は心の奥底でモヤモヤを感じていました。デモはデモ、サンプルはサンプルです。世の中Power Appsはここが良いよ！という記事にあふれているので、ここが良くないよ！という逆張りの意味合いもあります。
なお、これは私が2020年前半に仕事していた時に感じていたことなので、調査に間違いがあったり、情報が古かったりしたら、申し訳ありません。コメント欄とかでこそっと教えていただけると幸いです。（完全に個人の意見です、所属している企業等は関係ありません。）
正直私もエンドユーザーがIT知識を持って興味を示してくれるのは歓迎ですし、生産性の向上が叫ばれている今としては必要だと考えています。ただ、RPAの時にも感じたことですが、NoCode/LowCodeはITに興味のない事務職の人が使うには複雑すぎ、かつ開発者が使うには機能が不足していて、帯に短し、襷に長しな状況だと思っています。（個人的にはループ処理をするときにLINQがサポートされていないのが一番頭を掻きむしりました。）その点を考慮しないままそのしわ寄せが現場のエンジニアに無理を強いることになり、結局お客さんの不利益につながるかもしれない、というのであれば残念なことです。評価するのであればPro、Conを両方理解したうえで正しく使うべきです。
私の開発経験
普段はC#とAzureメインで開発しています。その中で今までRPA、Power Appsと二つのLowCodeプラットフォームでそれぞれ半年～1年ほど開発してきました。Power Appsはキャンバスアプリの経験しかありません。（ちゃんと調べたわけでもないのにこんな記事を書くのもおこがましい、と正直とても躊躇しています。大体は個人の体験談に基づきます。）
Power Appsの問題点
まず特に注意してほしいのが、Power Appsで中規模以上のアプリやましてやWebサイトを作ろうとするな、ということです。初期段階の開発スピードに目を奪われるかもしれませんが、使い捨てでない数年にわたって拡張・メンテしていく本格的なアプリを作るのであれば、洗練された既存の各種ツールを利用したほうが最終的にはずっと生産性は上がるはずです。
個人的な感覚ですが、1-3画面にとどめておくのがベスト、最大でも6-7画面くらいが限度だと思います。それ以上はPower Apps特有の落とし穴があり、様々な問題が発生します。以下に述べてみたいと思います。
複数人同時開発ができない
共通処理を（気軽に）メソッド化することができない
バージョン管理ができない
UIが野暮ったい
開発環境の機能が貧弱
自動単体テストができない
環境を分けることができない
Agile開発ツールのはずなのにAgile開発に向いていない
大量データの扱いが面倒
複数人同時開発ができない
Power Appsは同じアプリを複数人で開発することができません。Power Appsの開発環境はWeb版のみでLocal版は存在しません（昔はPower Apps StudioというLocal開発環境があったらしいがいくら探してもダウンロードリンクが見つからなかった）。ログインして開かれる管理画面には、自分が編集権限があるアプリが一覧で表示されるのですが、一人がそのアプリを編集モードで開くと、他の開発者はそのアプリを開くことができない仕様になっています。ソースを読み取り専用で見ることすらできません。そのため、アプリ一覧には他の人が読むためだけにコピーした専用の「○○アプリ_tanaka」みたいな名前が続々できることになります。エンタープライズ向けの開発ツールとしては大きな欠点と感じています。
ないと思いたいですが、Power Apps初心者のマネージャが、このアプリは二人で開発するから本来1か月のところを2週間だな！なんて見積ると痛い目に合います。
共通処理を（気軽に）メソッド化することができない
こちらは私は使ったことがないのであまり書くことができないのですが、現在プレビュー中のコンポーネントという機能で再利用可能な部品（ヘッダーフッター等）を作ることができるようです。
ただ、Power Appsでは処理はあくまでもUIに結びついているものであるため、画面とセットで作る必要があり、気軽に処理を共通メソッド化するという機能はないように思います。処理にUIを利用していない場合でも不可能で、例えばAとBという値を渡して戻り値にCを得るといった普通のメソッドが作れません。
YouTubeの動画で支持を得ていたのが、非表示のチェックボックスを準備しておいて、トリガーが実行される度にOnChangeを呼び出す（なので実処理はOnChangeにまとめられる）という迂回策なのですが、NoCode/LowCode特有の無理矢理なメンテナンス性＆リーダビリティガン無視の書き方でこのような書き方にはとても賛同できません。しかし、実際の現場では「Power Apps開発のうまい人」というのは、こういうTipsをどれだけ知っているか、というおよそソフトウェア開発のスキルとはかけ離れた、知恵袋的な存在になりがちです。（非表示なコントロールは時間とともに存在を忘れ去られます。かつ、この書き方では画面を跨いで使うことができないため、全く同じ処理を画面毎に作る必要があります。）
また、普通アプリを作るときは完全に固定された処理の使いまわしというよりは似ているけど異なる処理というのがたくさんありますが、そういう場合はもちろん継承、DI等のオブジェクト指向に則った機能はないので似たコンポーネントがたくさんできることになります（それかif文の嵐か）。
バージョン管理ができない
Power Appsのバージョン管理機能はかなり限られています。前のバージョンに戻す程度の機能はあるのですが、それくらいです。ブランチ戦略なんてないので、誰でもMasterを直更新です。また、現在のバージョンと2つ前のバージョンの違いの検出、現在の最新版のアプリAとアプリA´の違いの検出等コード比較はできません。アプリを一旦コピーして、二人で開発して、後でマージというのはとても困難です。マージ時に高確率でミスが発生するでしょう。A支社用、B支社用、C支社用というように細かいカスタマイズを求められたらもうそれは差分不明の完全別のアプリとして管理するしかありません。
Power Appsのソースをmsappという形式でエクスポートしてdiffツールで比較している人を見たことはありますが、そもそも全てのソースを比較するのは現実的ではない、かつどの画面のどのコントロールのどのイベントの処理を編集したか覚えるのは人任せなので、限界があります。コードレビューは実施することを全く想定していないか、人の記憶を頼りに何とかするしかありません。
全体的にPower Appsのバージョン管理機能はほとんどないに等しく、唯一の機能も差分が不明なのにロールバックだけできてなんの意味があるのでしょう。これもエンタープライズアプリとしては重大な機能の欠落な気がします。
UIが野暮ったい
HTML、CSS、JavaScriptで書かれている普通のWebアプリと比べると、Power Appsの画面はいかにも業務用という感じであり、画面全体が野暮ったい気がします。CSSやBootstrap等を利用することができないため、ユーザーエクスペリエンスという面ではかなり限定されます。
大量データの扱いが面倒
「Power Apps 委任」や「Power Apps 500」、「Power Apps 2000」で検索してみてください。詳細は省略しますが、Power Appsはデフォルトでは500（設定変更で2000）件以上データがある場合、それ以降は取得しないで処理を終了する場合があります（処理できる場合もある）。最初は冗談かと思いましたが、そういう仕様です。普通のWebシステムであれば、「データが多いので時間がかかるんだな」と誰もが納得するところを勝手にデータ取得を中断するなんて呆気に取られました。解決方法はあるのですが、特殊な書き方をする必要があり、勿論共通化もできません。最初PoCで意気揚々とお客さんにデモしていたPower Apps初心者がある日突然データ取得がうまくいかなくなって途方に暮れるのが目に浮かぶようです。新規にアプリを作成する際にもここに注意して開発しないと、本番運用が始まってからデータ処理部分を大改修する必要が出てくる可能性があります。
開発環境の機能が貧弱
Power Appsの開発環境は使い慣れたVisual Studioに比べると貧弱な印象が否めませんでした。ソースの見通しがきかず、前任者から引き継いだ際には質問攻めにする必要がありました。
画面を複数個編集モードで開いてソースを表示することができない
最初に述べた複数人開発できないということは、正確に言うなら編集モードで複数画面を開けないということです。Power Appsは開発時には画面AのBというコントロールの処理と画面AのCというコントロールの処理をソースとして隣に見比べて表示できません。私はVisual Studio CodeやOneNoteにソースをコピペして見比べていました。（後ろを通った同僚に笑われました。）検索機能が使いづらい
Power Appsにはグローバル変数を検索する機能はあることはありますが、検索結果の一覧がとても見づらく、一回検索結果画面からコードに飛ぶと検索結果が全てリセットされます。次の検索結果を見るにはまた一から検索し直しです。また、ローカル変数、コレクションは検索することはできません。Power Appsではグローバル変数を使った分岐処理はまだなんとか検索できますが、ローカル変数、コレクションの状態によって条件分岐する場合は影響範囲を追うことができません。ローカル変数、コレクション名の変更は実質無理に近いです。単語検索は開いている画面のソース内であれば検索できます（ただのctrl + f）が、ソース全体からはできません。
そもそもPower Appsでは様々なコントロールやデータの状態を管理するために、グローバルなフラグ変数が乱舞する傾向が強い気がします。やりたくないと思いつつ、気づいたらフラグ管理が収集がつかない状態になりやすいです。一定規模以上のアプリはメンテナビリティにも問題が出てきますが、一度作るとリファクタリングは困難です。デバッグ機能がない
Power Appsでは開発中にブレイクポイントを貼れません。ログも（普通には）出力できません。ブレイクポイントがないということは、変数が実行時にどうなっているかは原始的にデバッグ用のラベルを貼って一々確認することになります。これはもうそもそもデバッグする必要があるような複雑な処理をするな、というMSからのメッセージの様な気がします。。。
ログに関しては自前でファイルかCDSか何かに出力することもできるかもしれませんが、容易に共通処理が実装できない、かつ毎回ネットワークアクセスが発生するのでパフォーマンスにかなり影響がありそうです。そのため本番でどのような処理が走ったのかトレースすることが難しく、エラー調査が困難でした。
その他エラー発生時には、PowerAppsにはセッションIDを教えてMicrosoftに調査してもらうことができますが、エラーが出るたびにMicrosoftに問い合わせるのは正直非現実的だと思います。開発者にもっとエラー調査の自由を与えてほしいところです。また、調べた限りPower Appsのアプリは複雑になるにつれて、ネットワーク負荷が増えるとそこそこの確率でクラッシュするようです。拡張性が低い
これはPowerAppsの関数の話ですが、Microsoftから提供されていない機能についてはどうすることもできません。有志が提供している便利なライブラリなんかないので、既存の機能で無理やりなんとかするか諦めるしかありません。
例えばPower Appsは端末の画面を消すと完璧に停止してしまいます。画面をずっとONにしたままにするのは現実的ではないので、GPSトラッキングを利用したアプリは実質作ることができず諦めました。開発環境が通信速度に依存する
これは開発環境だけではなく、Power Apps全体に言える話ではありますが、Pocket Wifiで接続していた時には開発環境を開くのに1-5分以上待たされることがありました。開発中に一回処理を実行し、デバッグして、ロジックを修正して、、、と繰り返しているとデバッグ中に入った変数等の状態を一旦リセットしたい場合がありますが、それには画面を開きなおすしかありません。1日に5回ページを開きなおしたとして、もしネットが遅く5分かかるとした場合、1日に25分の時間が無駄になります。深夜に疲れた目でロード画面をじっと見つめていると色々考えたくもなりました。
自動単体テストができない
Power AppsではビジネスロジックはUIに密接に結びついています。イメージで言うと、vb6で画面のコードビハインドにビジネスロジックをクラスもメソッドも作らず延々と書いていくようなものです。ゆえに全てのテストは手動テストになってしまい、インプットデータの組み合わせの数だけテストのパターン数が膨大になります。最終的に開発者のスキル云々の話になるかもしれませんが、1ボタンクリックに対して1000行を超え、複数の条件分岐を持つPower Appsのスパゲッティコードはあまりメンテしたくないものです。
通常、UIとビジネスロジックはできるだけ分離し、ビジネスロジックはできるだけ自動テストで検証し、表示部分やビジネスロジックの呼び出し部分だけを画面から手動でテストをするのが一般的かと思いますが、Power Appsでは全てのロジックを手動でテストする必要があります。ビジネスロジックが複雑な場合はパターン網羅など望むべくもありません。RPAの時も感じたことではありますが、基本的にNoCode/LowCodeはテストは開発者の裁量に任せてそこそこに済ませて、あとは本番環境でバグが出たらモグラ叩き式に直せばいいとおざなりにされることが多い気がします。（アジャイル開発の名の下にでテスト期間も与えられないし。それにしてもAgile開発、NoCode/LowCodeというだけでテストについてお客さんが全く興味を示さなくなるのは問題な気がします。Waterfallの場合はExcelエビデンスの提出を求められたりするのに(良いか悪いかは別にして)。）
しかし自動単体テストは開発者にとって、これまでのロジックの正確性を保証するものであり、今後の開発の道標でもあります。自動テストが開発者にどれだけ安心を与えてくれることか。リファクタリングしても今までのロジックが正常に動いていることがすぐにわかる安心感。Power Appsでは全体の見通しの悪さとも相まって、コードを修正するたびに手動テストをやり直し、かつ今まで正常に動作していたロジックでバグが起こるのはとてもストレスに感じました。PowerAppsは簡単にデグレします。。
なお、自動UIテストの機能は提供されているようですが、こちらは未検証です。
ただ、自動UIテストというのは作るのにかなりのコストがかかるので、作る箇所の見極めと必要性についてかなりエンジニアのスキルによるところがありそうな気がします(上述のようにパターンが膨大なため)。そもそもUIテストと自動単体テストは意味が違うし、実行時間にもかなり時間がかかるのが普通だし、アジャイル開発でガンガン変更が入るのに自動UIテストの使い所は若干疑問に感じます。
環境を分けることができない
私が作業していた時は、開発環境、ステージング環境、本番環境のように環境を分ける機能がありませんでした。Environmentという機能でアプリやCDSを分けることができたのですが、それはあくまでもリソースのフォルダ分け程度の機能しか提供してくれず、開発環境で作ったアプリを本番環境にExport、Importする際には、作業後にURLやCDS等を本番に向き先を変更する必要がありました。
今回まとめるにあたって、こんな記事を見つけたので、こちらは今はもう少し改善されているのかもしれません。
Agile開発ツールのはずなのにAgile開発に向いていない
本章はPower Appsに限った話ではなく、NoCode/LowCode全般についてです。
私はずっとVisual Studioの高機能で洗練された開発環境、オブジェクト指向、デザインパターン、AgileとDevOpsの文化に憧れてきました（未だ勉強中の身ですが）。Agileは思想とプラクティスによって支えられており、Agileの実践にはCI/CD、自動テスト、バージョンコントロール等の現代では当たり前となった高度な技術が不可欠です。その分Agile開発ツールを標榜しながら、今までのソフトウェア開発の数十年間で培われた英知を放棄するかのようなLowCode/NoCode開発に強い疑問を覚えます。個人的にNoCode/LowCodeで開発していて辛いと感じるのは、普通のプログラミングだったらこういう機能があるのに、という手足を縛られた状態で戦っているような無力感があります。対象は市民開発者だから、まだ発展段階だから、現段階では機能が制限されており、できないこともある、というのであればその点もオープンにし、向いている/いない領域があるということも認めるべきでしょう。（そうでなければエンタープライズユーズには時期尚早であると言わざるをえません、機能が不足してるんだから。銀の弾丸はありません。）
また、私見ですが、NoCode/LowCodeは結局SI企業が主導して入れている現場が多い気がしますが、開発体制や開発期間の面で問題のある現場もあるのではないでしょうか（やたらジュニアなメンバーが多かったり、テスト期間がなかったり、新規開発とメンテナンスを同じ人が並行してやってたり）。本気でやるのであれば、情シス部門のやる気がある人に開発段階から一緒に参画してもらい、SI企業の開発者と二人三脚で進めていくのをお勧めしたいです。そうでなければ幾らNoCode/LowCodeとはいえお客さんへの引き渡しのときに面食らうでしょう。会社の文化によると思いますが、NoCode/LowCodeの名目を盲信するあまりSI企業もお客さんも開発作業を軽く見ていると思います。例えばお客さんも中途半端にAgile、NoCode/LowCodeという言葉は知っているので、変更要望があればすぐ対応できるでしょ？という姿勢でSIerに迫り、SIerもNoCode/LowCodeの利点だけを強調していたため強くは反対できずにそれを呑む。しかし上記のように様々な機能が欠落している状況を鑑みると、NoCode/LowCodeは普通のシステム開発より一歩間違えるとカオスなカウボーイコーディングになりかねない危険性を秘めています。
蛇足ではありますが、そもそもAgileと変更管理というのは大きな課題であって、契約からチーム体制、実際の協業体制、Agile開発への共通認識等複雑なプロセスと顧客との信頼が前提となります。お客さんの変更要望をただ早く受けていますと胸を張るのはAgileとは違います（私は勝手に和ジャイルと呼んでいます)。そしてそのしわ寄せは数少ない開発経験があるメンバーが被ることになり、アプリの開発も属人化していきます。また、NoCode/LowCodeはその自由度の高さから独自の工夫がしやすく、結局プログラミングスキルの有無等に依存するため、書いた人以外に読みにくい不可思議なコードの傾向が多いと感じます。そしていい感じ（？）にアプリが複雑度を増してきたときにお客さんへの引継ぎという課題に直面するわけです。Agileだといってほとんど作成してこなかったドキュメントをソースからなんとか起こしたり、見通しの悪いアプリを四苦八苦しながら引き継げるように努力する必要が出てきます。チームは疲弊します。
Power Appsの向いている面
私はPower Appsはコンセプトとしてはとても面白い、魅力的なツールだと思っています。特に外部システムとの幅広い連携やPower Automateを利用したフロー処理は想像以上に簡単です。ただ、餅は餅屋というように、向き不向きがあり使い所に注意が必要です。
RPAの時に感じたことではありますが、全ての処理を無理にRPAでやろうとせずに、ExcelやAccessはVBA、ファイル操作はBatやPowerShell等それぞれのターゲットに合っているツールを使い、それらの処理をRPAで橋渡しさせるのが一番高速かつ安定していました。
以上を踏まえると、Power Appsは以下のシナリオにとどめておくべきだというのが私の意見です。
- 複雑な条件分岐を伴わない小規模なアプリの開発
- 各種API等の呼び出しを提供するため窓口アプリ
- CRM、ERP等の外部システムを連携、データの表示、更新等
- SharepointやD365等のアドオン的なアプリの開発
- AI、VR機能等を手軽に提供するためのプラットフォーム
- カメラ機能等を利用したIoTのエッジデバイスの開発
- PoCや検証
等
上記を踏まえると、結局バックエンドはSIerが開発する必要があり、市民開発者がPower Appsで全てをやるというのはまだ難しいかなという印象です(そのためのPower Automateもあるけど)。Microsoftも今後注力していく分野であり、かなり早いペースで改善が予定されていますので、私が挙げた懸念も遠くない日に払拭されればいいなと思っています。