Power Apps でアプリが大きくなってきたとき、ツリービューがカオスになった経験はありませんか。コントロールが増えるにつれて、あのボタンどこだっけ、このラベルは何のためにあるのかという状況が必ず訪れます。命名規則とツリービューの整理術を最初から意識しておくだけで、後からの修正コストが劇的に下がります。
命名規則がなぜ必要なのか
Power Apps Studio のツリービューは、コントロール数が増えると一覧で確認するだけでも時間がかかります。体感ですが、コントロールが200件を超えたあたりから検索だけでは追いきれなくなります。私が最初に作ったアプリはまさにそれで、Button1・Button2・Button3が乱立していて、どのボタンが何をするのか自分でも把握できなくなっていました。
命名規則がない状態でチーム開発をすると、さらに問題が深刻になります。Power Apps はコントロール名がそのまま数式の参照先になるため、名前が不明瞭だと数式を読んでいるときにこれは何を参照しているのかが一瞬でわからなくなります。自分が書いた数式でも、数週間後に見直すと意味がわからなくなるのが正直なところです。
コンテナ構造を使うアプリでは特にこの問題が顕著です。コンテナは階層が深くなりやすいため、ツリービュー上のどのコンテナがどのセクションに対応しているかが、名前だけで判断できる状態にしておくことが重要です。コンテナの設計思想についてはPower Apps コンテナ完全ガイドで全体像を整理しているので、合わせて参照してください。
推奨プレフィックス一覧
コントロールの種類ごとにプレフィックスを決めておくと、名前を見ただけでコントロールの型がわかるようになります。以下が私が実際に使っているプレフィックスです。
| プレフィックス | コントロール種別 | 例 |
|---|---|---|
| cnt | コンテナ（Container） | cntHeader、cntBIArea |
| lbl | ラベル（Label） | lblTitle、lblLastUpdate |
| btn | ボタン（Button） | btnSave、btnRefreshBI |
| gal / col | ギャラリー（Gallery） | galRecords、colResentVessel |
| img | イメージ（Image） | imgIcon、imgBarchart |
| rec | レクタングル（Rectangle） | recSeparator、recLeft |
| txt | テキスト入力（TextInput） | txtSearch、txtComment |
| ddl | ドロップダウン（Dropdown） | ddlStatus、ddlDepartment |
| ico | アイコン（Icon） | icoEdit、icoDelete |
| frm | フォーム（Form） | frmDetail、frmEdit |
最初はプレフィックスを覚えるのが面倒に感じるかもしれません。ですが一度習慣にしてしまえば、逆にプレフィックスなしでは落ち着かなくなります。私も今では命名なしでコントロールを置くことが気持ち悪く感じるくらいです。
階層と場所を名前に含める
プレフィックスだけでは不十分です。コンテナのネスト構造が深くなると、どのコンテナがどの画面のどのエリアに属しているかが名前からわからなくなります。そこで「場所＋階層番号」を名前に含める方法が有効です。
私のアプリ scrHome での実例を紹介します。ホーム画面のBIエリアには次のような命名をしています。
- cntAll_Home（ルートコンテナ・ホーム画面全体）
- cntRight_Home（右エリア・ホーム画面）
- cntBI（BIセクション全体）
- cntBI_1stL（BIの1行目・左側）
- cntBI_2ndL（BIの2行目・左側）
この命名を見るだけで、ツリービューのどこを開けばよいかが名前から推測できます。1stL・2ndL という連番は1行目・2行目の意味で、L は Left（左）を指しています。コンテナのネスト構造の設計についてはコンテナのネスト構造を作る方法で詳しく解説しているので、階層設計と合わせて読んでもらえると理解が深まります。
役割を名前に含める
コントロールの名前には、そのコントロールが何をするものかという役割も入れるべきです。プレフィックスで型がわかり、本体部分で役割がわかる。この2要素が揃って初めて名前が機能します。
具体的な例を見てみましょう。
- btnRefreshBI：BIエリアのデータを更新するボタン
- lblLastUpdate：最終更新日時を表示するラベル
- txtSearchKeyword：検索キーワードを入力するテキストボックス
- galVesselList：船舶一覧を表示するギャラリー
- ddlPhaseFilter：フェーズでフィルタリングするドロップダウン
名前が長くなりすぎることを気にする人がいますが、個人的には多少長くても役割がわかる名前のほうが絶対によいと思っています。Power Apps Studio の数式バーにはオートコンプリートがあるので、名前の途中まで入力すれば候補が出ます。長い名前は入力コストにならない。短すぎて意味が取れない名前のほうが、後々のコストが高くつきます。
ツリービューでの並び替えと選択操作
命名規則を整備したら、ツリービュー上の操作もスムーズになります。いくつか知っておくと便利な操作をまとめます。
並び替えの方法
コンテナ内の子要素はツリービュー上でドラッグ＆ドロップで順序を変更できます。ただしドラッグが効かない場合があり、その場合は対象のコントロールを右クリックして表示されるメニューから並び替えを選びます。
注意点として、コンテナをオートレイアウト（Auto Layout）に設定している場合、子要素の並び順がそのまま画面上の表示順になります。ツリービューで上にあるほど画面の上（または左）に表示されます。見た目の調整はプロパティではなくツリービューの順序で制御する、という感覚を覚えておくとよいです。
セクション単位での全選択
コンテナ構造の大きなメリットのひとつが、セクション単位での全選択が容易になることです。旧来の平坦なツリービューでは、ヘッダーエリアのコントロールを全選択しようとすると、Ctrlキーを押しながら1つずつ選ぶしかありませんでした。
コンテナがあれば、cntHeader を1クリックするだけでその中のすべての子コントロールが選択対象になります。移動・複製・削除もコンテナ単位で行えるため、画面レイアウトの大規模な調整がずっと楽になります。ヘッダーをまるごと別の画面に移植したいとき、コンテナごとコピーするだけで子コントロールも全員ついてくる点は特に便利です。この点についてはYAML共有の観点からもコンテナをYAMLコードで共有する方法で詳しく紹介しています。
深くなりすぎたときのリファクタリング基準
命名規則を守っていても、ネストが深くなりすぎるとツリービューが読めなくなってきます。目安として3〜4階層が限界で、それ以上は設計を見直すサインと考えてください。
よくある失敗パターンは、レイアウト調整のためにコンテナを積み重ねていくうちに、気づいたら6〜7階層になっていたというケースです。1コントロールしか持たないコンテナが連続している場合は、そのコンテナが本当に必要かどうかを見直す余地があります。ただし整列・パディング目的で1コントロールのコンテナを使うことは正当な理由になります。判断が難しければ、コンテナを省いたときに見た目が崩れるかどうかを試してみましょう。
深すぎる階層に気づいたら、思い切ってフラット化するリファクタリングを行います。一見面倒に見えますが、命名規則が整っていればcntBI_1stL 配下を全部整理するという作業がコンテナ単位で完結するため、旧来の方法より遥かに作業量が少なくて済みます。
チームで命名ルールを共有する方法
個人開発ならば自分が守れれば十分ですが、チームで Power Apps を開発する場合は命名規則をドキュメント化しておく必要があります。口頭で伝えるだけではすぐに崩れます。
私がチームでの勉強会で使っているのは、プレフィックス一覧をSharePointリストに登録しておき、いつでも参照できる状態にしておく方法です。表をひとつ共有するだけで、新しくメンバーが加わったときも命名の統一が保てます。
命名規則がドキュメント化されていると、コードレビューのときに指摘しやすくなります。感覚的な指摘ではなく、ルールに基づいた指摘ができるため、受け取る側も納得しやすいです。社内での Power Platform 推進を担っている立場としては、こういったルール整備が長期的な品質維持に直結すると感じています。
まとめ
命名規則は地味な作業ですが、その恩恵はアプリが大きくなるほど効いてきます。最初にルールを決めてしまえば、後から名前を付け直す作業がほぼなくなります。プレフィックス・場所・役割の3要素を名前に含めるだけで、ツリービューの可読性は大きく変わります。
市民開発とはこういう地道な事柄の積み重ねだと思っています。命名規則ひとつ整えるだけで、1か月後の自分がずっと楽になる。まずは自分のプロジェクトのプレフィックス表を1枚作るところから始めてみてください。
