🛠️ ローコード開発のリファクタリング Power Apps 編
- ローコード・ノーコード開発の需要と展望
- 【PowerPlatform】ローコード開発のリファクタリング Power Apps 編
- 【PowerPlatform】ローコード開発のリファクタリング Power Automate 編
✨ はじめに
Power Apps の中でも、特に キャンバスアプリ は個人で簡単に作成できるため、業務改善の現場で広く活用されています。しかし、アプリが複雑になり、複数人での開発が進むにつれて、コードの書き方にばらつきが生じ、不要な処理が残ってしまうことがあります。その結果、アプリの品質や保守性が低下してしまうケースも少なくありません。
本記事では、ローコード開発における「リファクタリング」 に焦点を当て、Power Apps キャンバスアプリ を対象に、開発の中でどのように整理・改善を行うべきかを解説します。複数人が関わる開発プロジェクトでも、他の人が見て理解しやすく、一貫性があり、パフォーマンスが高く、保守しやすいアプリを構築するための考え方と実践的な工夫を紹介します。
🧭 ローコード開発の方針
ローコード開発は、迅速にアプリを構築できるという利点がある一方で、できることとできないことが明確に分かれているという特徴があります。これは、Power Apps に限らず、他のローコードプラットフォームにも共通する性質です。
そのため、従来のフルスクラッチ開発と比較して、事前のフィジビリティ (実現可能性) の確認と基本設計の徹底が特に重要になります。これらを怠ると、目的とズレた、使いにくいアプリが出来上がってしまうリスクがあります。逆に、初期段階でしっかりと方針を定めておくことで、プロジェクトの成功率を高めることができます。
✅ 実現性の確認
ローコード開発では、使用するプラットフォームの機能や制約を事前に把握し、プロジェクトの要件がその範囲内で実現可能かどうかを確認する必要があります。これは、開発の初期段階で行うべき最も重要なステップの一つです。
- 要件を具体的に洗い出し、それがローコードツールで対応可能かを評価します。
- 対応が難しい場合は、機能の見直しや代替案の検討を行い、関係者と事前に合意を取ります。
- 検証用の環境で実現できたとしても、本番環境では制約により実現できないケースがあるため注意が必要です。たとえば、接続できるデータソースの種類や、ユーザー権限、ネットワーク制限などが異なる場合があります。
このように、「できると思っていたのにできなかった」という事態を防ぐためにも、実現性の確認は机上の検討だけでなく、実際の運用環境を想定した検証が重要です。
🧱 基本設計の重要性
ローコード開発では、要件に沿った基本設計をしっかりと行うことが、プロジェクト成功の鍵となります。これは、従来の開発と同様に、設計の質がそのままアプリの品質や保守性に直結するためです。
- 基本設計には、データモデルの設計、ユーザーインターフェースの構成、ビジネスロジックの整理などが含まれます。
- 設計段階での詳細な計画が、後の開発や改修をスムーズに進めるために不可欠です。
- 特に、前章「実現性の確認」で把握した制約や仕様を前提に設計を行うことが重要です。これにより、実装段階での手戻りや仕様変更のリスクを最小限に抑えることができます。
ローコード開発はスピード感が魅力ですが、設計を省略してしまうと、結果的に使いにくく、保守しづらいアプリになってしまう可能性があります。だからこそ、「設計に時間をかけることが、最終的な効率化につながる」という意識が重要です。
🔄 継続的な評価と調整
ローコード開発では、開発初期の設計だけでなく、開発中や運用後も継続的に評価と調整を行うことが重要です。要件や業務の変化、ツールの進化に柔軟に対応できる体制を整えておくことで、アプリの品質と価値を維持できます。
- 開発中も定期的に設計や要件を見直し、必要に応じて調整します。
- ローコードツールは頻繁にアップデートされるため、以前は実現できなかったことが、今では簡単に実現できるようになっている場合もあります。最新の機能や仕様を定期的にチェックし、必要に応じて設計や実装を見直すことが、開発効率や品質向上につながります。
- また、ツールのバージョンアップに伴う仕様変更や改善を取り入れていくことを、あらかじめ関係者と合意しておくことも重要です。これにより、将来的な改修や機能追加の際にスムーズな対応が可能になります。
そして何よりも重要なのは、『 過剰な作り込みは避け、既存の機能で実現する』という姿勢です。これはローコード開発において最も重要なポイントであり、柔軟性・保守性・将来の拡張性を確保するための基本方針です。
このように、作って終わりではなく、使いながら育てていくという姿勢が、ローコード開発では特に重要です。
📐 コーディングの規約を定める
ローコード開発では、誰が見ても理解しやすく、保守しやすいコードを書くことが重要です。特に複数人で開発する場合、コーディングスタイルにばらつきがあると、後の改修やレビューに大きな負担がかかります。そのため、あらかじめチーム内で一定のルールを定めておくことが推奨されます。
🏷️ 命名規則
Microsoft が公開している標準の『コーディング規約』は、Power Apps のキャンバスアプリを開発するうえで一度は目を通しておくべき重要な資料です。
ただし、この規約を厳密に遵守すること自体が目的ではありません。
たとえば、Power Apps ではコントロールを作成すると自動で名前が付けられますが、この自動命名は公式の命名規則とは異なるルールに基づいています。そのため、公式の命名規則を無理に適用しようとすると、かえって開発効率が下がることもあります。
重要なのは、公式の規約を参考にしつつ、プロジェクトやチームにとって扱いやすい命名ルールを定めることです。現場に即した柔軟なルール設定が、実用性と保守性のバランスを取る鍵となります。
- 参考リンク：【Power Apps】命名規則について
🧠 変数の使い分け
変数の種類と使用範囲を理解して整理することで、定義するタイミングや参照されるタイミングを明確にします。改修時に変数の影響範囲による思わぬバグの発生を軽減する事ができます。
この変数は本当に必要なのか？を整理して、可能な限り変数の定義を減らすことで、保守性や可読性があがります。
📊 変数の種類とスコープ
以下のような変数の種類があります。
| 名前 | スコープ | 定義関数 | 用途 |
|---|---|---|---|
| グローバル変数 | アプリ全体 | Set | アプリ全体でどこからでも使用可能な変数 |
| コンテキスト変数 | 画面内 | UpdateContext | 一つの画面内のみで参照可能な変数 |
| コレクション | アプリ全体 | ClearCollect | テーブル型の配列 |
🌐 グローバル変数
アプリ全体のスコープで使えるので、深く考えずに App.OnStart イベントで定義して使用するような、旧来の使い方をしてしまうケースが多い。影響範囲が広すぎるため、意図せぬ更新が起こりバグを生み出すリスクとなる。
- グローバル変数を乱用しない。アプリ全体で使われるような変数は最小限に留める。
🖼️ コンテキスト変数
画面単位でのスコープで使用するため、他の画面で意図せぬ更新をしてしまうようなバグを防げる。
- 画面に配置しているコントロールのプロパティにはグローバル変数ではなくこちらを使用する。
- 他の画面に値を渡したい場合は、Navigate 関数で遷移先画面のコンテキスト変数として受け渡します。
📦 コレクション
コレクションに関しては、グローバル変数同様にアプリ全体のスコープで使えるので、意図せぬ更新によるバグに注意する。
🧪 ローカル変数的に使う：with 関数の活用
一時的に使うローカルな変数が必要な場合は、With 関数を使うことで、スコープを限定した変数定義が可能です。
- 変数のスコープを極力狭く保ちたいときに有効
- 一時的な値の保持や、複雑な式の整理に役立つ
- グローバル変数やコンテキスト変数を使わずに済む場面では、積極的に活用を検討する
🚀 起動時の設計と初期化の工夫
かつてはアプリの初期処理を App.OnStart にまとめて記述するのが一般的でしたが、現在ではこれは古い手法とされており、推奨されていません。代わりに、StartScreen プロパティや Formulas プロパティ を活用することで、パフォーマンスと保守性の向上が期待できます。
App.OnStart を使用すると、アプリの読み込み時にパフォーマンスの問題を引き起こすことがあります。OnStart での Navigate 関数の使用は廃止されました。
※デフォルトの設定で OFF になっています
❌ App.OnStart を使わない設計
App.OnStart に初期処理を集中させると、アプリ起動時のパフォーマンスが低下しやすく、処理の見通しも悪くなります。特に Navigate 関数の使用は非推奨となっており、Microsoft からも使用を避けるよう案内されています。
※デフォルトの設定では ON になっていますが、OFF にしてアプリを作成します。
✅ StartScreen プロパティの活用
以前は、App.OnStart 内で、Navigate 関数で最初に表示する画面へ遷移するという手法でした。
アプリの起動を簡素化し、パフォーマンスを向上させるため、App.StartScreen プロパティの使用が推奨されています。アプリの起動時に表示する画面を App.StartScreen プロパティで指定し、その画面の OnVisible イベントで初期処理を行うことで、処理の分散と可読性の向上が図れます。
🧮 Formulas プロパティの活用
定数的な値や再利用される式は、App.Formulas プロパティで名前付き計算式として定義することができます。これにより、グローバル変数を使わずに済む場面が増え、アプリの構造がより明確になります。
2025/03 現在、App.Formulas でのユーザー定義関数は現在実験段階です。
🎨 テキスト整形によるコードの可読性向上
Power Apps では、数式の可読性を高めるために、数式バーに備わっている「テキストの書式設定」コマンドを活用することができます。この機能を使うと、記述した Power Fx 数式に対して自動的にインデントや改行、スペーシングが適用され、コードの構造が整理されます。
※「書式設定の解除」を選択すると、1 行のコードになります。
特に複雑な関数や長い数式では、手動で整形するよりも効率的で、見通しの良いコードを保つことができます。また、ユーザーごとに記述スタイルが異なると、チーム開発時にコードの読みづらさや混乱を招くことがありますが、書式設定コマンドを使えば、スタイルのばらつきを抑え、統一感のあるコードを維持できます。
整形されたコードは、エラーの発見や修正がしやすくなるだけでなく、コメントの追加や Copilot による数式の説明とも整合性が取りやすくなります。
✅ 書式設定コマンドの利点まとめ
- ユーザーごとの記述スタイルのばらつきを抑えられる
- コードの構造が明確になり、読みやすさが向上する
- エラーの発見や修正がしやすくなる
- コメントや Copilot による説明との整合性が保ちやすくなる
- チーム開発や保守の効率が向上する
📝 コメントの使い分けと Copilot の活用による可読性の向上
Power Apps では、コード内に書くコメントと、アプリ作成画面で使えるコメント機能 (ビジュアルコメント) の 2 種類のコメント手段があります。これらを状況に応じて使い分けることで、コードの可読性を保ちながら、意図や背景を効果的に伝えることができます。
✂️ コード内コメントは最小限に
コードの各行に詳細なコメントを付けすぎると、ロジックが埋もれて読みづらくなります。また、コードの修正後にコメントを更新し忘れると、内容の不整合が発生し、読解の妨げや誤解の原因になります。コメントとコードが一致しているかを確認しながら読むのは非効率であり、可読性を下げる要因にもなります。
さらに、Power Apps の「テキストの書式設定」コマンドを使用すると、コード内のコメントが意図しない位置に移動したり、整形が崩れたりすることがあります。特に行コメント（//）は、次の行のコードと分離されずに連結される場合があり、整形後の見た目が乱れる原因になります。
そのため、コード内には極力コメントを残さず、必要に応じて Copilot やコメント機能を活用することを推奨します。
🤖 Copilot による数式の説明とコメント生成
Power Apps の Copilot には、数式バーに記述された Power Fx 数式の意味を自然言語で説明する機能があります。数式を選択して「この数式を説明する」を実行すると、Copilot がその処理内容を簡潔に解説してくれます。
[コピー] を選択して、この説明をコードコメントとして利用することができます。数式の変更後にも再生成することで、コメントの更新漏れを防ぎ、コードとコメントの整合性を保つことができます。
✅ Copilot 活用の利点
- コメントの自動生成により、記述ミスや理解不足を防止できる
- 数式の変更後も、再説明によりコメントの更新漏れを防げる
- コードとコメントの乖離を防ぎ、保守性が向上する
- コメントの品質と一貫性が保たれ、チーム開発でのコミュニケーション精度が高まる
💬 Power Apps Studio のコメント機能
Power Apps Studio では、コードとは別にコメントを残す専用の機能 (ビジュアルコメント) があります。ツリー ビューやキャンバス上のコンポーネントを右クリック、または画面右上の「コメント」ボタンから追加できます。
@メンションを使えば、チームメンバーに通知を送ってフィードバックを促すことも可能です。
このようなコメントは、コードの外に残るため、コードの可読性を損なわずに意図や背景を共有する手段として有効です。
📌 コメントの使い方の指針
- コード内コメントは最小限にとどめる
- Copilot を活用して、正確で一貫性のある説明を得る
- ビジュアルコメント機能を使って、コード外での意図共有やチーム内コミュニケーションを行う
- コードとコメントの整合性を保つことを最優先とする