はじめに

こんにちは。GxPのブルースです。
この記事はグロースエクスパートナーズアドベントカレンダー 18日目の記事です。

私はITを約2年間独学し、今年の春に新卒として入社しました。
現在はローコードツールを活用したアプリ開発に携わっています。

ローコードツールと聞くと、「簡単にアプリが作れる便利なツール」というイメージを持つ方も多いかもしれません。
しかし、それは時に大きな落とし穴になることもあります。

特に私にとっては、実務経験ゼロ、テストやパフォーマンス、運用設計など、すべてが手探り状態の中でのスタートでした。

この記事では、Power Appsと向き合ったこの4か月で感じたことや、AIにも頼れず、試行錯誤を繰り返しながら身につけた「考える力」について共有します。

同じように悩んでいる方に、少しでも参考になる部分があれば嬉しいです！

Power Apps（パワーアプリ）とは？

Power Appsは、Microsoft が提供するローコード開発プラットフォームです。

専門的なプログラミング知識がなくても、業務アプリを短期間で開発できます。

ExcelやSharePoint、Dataverse、Box、Teamsなどと連携し、申請管理・台帳管理・業務フローの可視化などの社内アプリが構築できます。

画面設計はドラッグ＆ドロップ、ロジックは Excel に近いPower Fxを使うため、

業務ユーザーとIT部門の橋渡しとなるツールとして、多くの企業で注目されています。

PowerAppsは「簡単」と「複雑」の間でぐるぐるしているもの

最初に詰まったのは、まさかの“スクロール”

開発を始めて最初に詰まったのは、驚くほど基本的な操作でした。

画面がスクロールできない
チェックボックスの値がうまく保存されない
保存ボタンを押してもデータが反映されない

UIは表示されていても思った通りに動かない。

「こんな簡単なことがなぜできない？」という違和感の連続でした。

原因は「Power Apps的な考え方」ができていなかったこと

原因を一つずつ整理すると、それはツールの問題ではなく、自分の思考のズレでした。

スクロールできなかったのは、コンテナ設計の理解不足
チェックボックスが保存できなかったのは、データとコントロールのつながりを理解していなかった
保存ボタンが動かないのは、Formの設計を誤解していた

見た目のシンプルさに油断していたんですね。

UIは簡単そうに見えるけど、考えることは山ほどある

Power Appsは、見た目も操作も「簡単そう」に見えます。

でも実際は、状態管理・データ構造・UIの設計など、かなり多角的な思考が求められます。

たとえば：

「どの値が、どこから来て、どこに保存されるのか？」
「表示されている値と、実際に使われるデータの型は一致しているのか？」

これらを理解していないと、「なぜ動かないのか」が全く分からない状態になります。

AIに頼れなかった——最後に頼れるのは自分の試行錯誤

Power Apps開発中、AIにも何度も質問しました。

でも、AIの答えは9割くらい“惜しいけど違う”。

というのも、Power Appsはアップデート頻度が高く、Canvasアプリ・Dataverse・Automate連携などによって答えが全く変わるからです。

最初に特に苦しんだのは、型エラー。

Record vs Table vs OptionSet
OptionSetValue vs Text

AIは「これを書けば動く」とは言ってくれますが、「なぜそう書くのか」「それがどうデータと関係しているのか」は説明できないし、型エラーという認識もあんまり配慮していないと感じました。

だから結局、変数のバリュー確認・GalleryやFormの戻り値を確認 → ラベルに表示 → 式を1つずつ分解しながら、自分で仮説を立てて試すしかない。

この経験を通じて感じたのは、「AIを使いこなすには、自分で“正解かどうかを判断する力”が必要だ」ということでした。

トライアンドエラーこそが最大の武器

振り返ると、この経験を通して最も成長につながったのは、とにかく手を動かして試したことでした。

仮のデータを入れて表示確認
変数を設定して流れをチェック
エラーが出たら分解して何が違うかを確認

特に印象に残っている挑戦ー Office365ユーザーの読み込み制限を超えた話

開発中に特に苦労したのが、Office365 ユーザー一覧の取得とコンポーネント内での表示でした。

当初、Office365ユーザーコネクタを使ってデータを取得し、一覧をコレクションにキャッシュする方法を考えました。

しかし、ここでもすぐに壁にぶつかります。

Power Apps では Office365Users.SearchUser によるデータ取得は最大999件までという制限があり、

そこで試したのが、A〜Zごとにフィルタリングしてコレクションを複数作るというアプローチです。

Filter(Office365Users.SearchUser({searchTerm:"A", top: 999}), ...)
Filter(Office365Users.SearchUser({searchTerm:"B", top: 999}), ...)
...

ですが、これも限界がありました。全社員を完全にカバーするには届かないのです。

悩んだ末にたどり着いたのは、「コンポーネント内の Items プロパティで動的に取得する」という方法です。

If(
    IsBlank(ComboBox1.SearchText),
    colUsers,
    Filter(
        Office365Users.SearchUser({
            searchTerm: ComboBox1.SearchText,
            top: 999
        }),
        "@example-domain" in Mail
    )
)

※ @example-domain は実際のメールドメインに置き換えて使っています

このように、検索文字列が空ならキャッシュを使い、入力されていれば SearchUser を使ってフィルタリングし、表示件数を絞るという構成です。

地味な工夫ですが、これによりコンポーネント単体でもユーザー検索が可能になり、パフォーマンスも確保できました。

この解決方法にたどり着けたのは、最初から正解が見えていたからではなく、失敗を繰り返し、試しながら「Power Appsではこう考えれば動くのでは？」と推論し続けたからです。

まさに、自分の“考える力”が武器になる場面だったと感じました。

今、同じように悩んでいるあなたへ

最初、私はスクロールすらできずに本気で悩んでいた新卒でした。

でも、失敗しても諦めずに試し続けた結果、いつの間にか「なぜ動かないか」が見えるようになってきたんです。

Power Appsには、正解がひとつではない世界があります。

だからこそ、完璧じゃなくてもいい。まずやってみること。試して壊して、また直せばいい。

この経験を通じて私は、「考える力」や「観察する目」が、一番の武器になると強く実感しました。

Power Appsは、ただの業務ツールではなく、自分の思考と創造力を鍛えてくれるフィールドです。

今つまずいているあなたも、絶対に大丈夫。

少しずつ、確実に、力になっていきます。

ぜひ、気楽に挑戦してみてください。

最後に

この4か月間、Power Appsでたくさん悩み、たくさん試し、少しだけ自信が持てるようになりました。

この記事が、これからPower Appsに挑戦する方のヒントになれば嬉しいです。

最後まで読んでいただきありがとうございました！

もし「ここも困ったよ！」「この機能どう実装？」などあれば、ぜひコメントください！

一緒にトライアンドエラーしていきましょう！

参考資料