【Power Platform】オリジナルのコーディング標準を作ろう（前編）

2024/01/11

マイクロソフトソリューション Power Apps モデル駆動型アプリ Power Platform Power Automate

こんにちは。システムソリューション営業本部の吾妻です。

Power Platformを導入した企業においては、市民開発者の数が増えていくにつれて、個々人のスキルの差が生まれていき、Excelマクロを利用していた頃のような「属人化」の問題が現れてきます。

そこで、今回・次回の2回に分けて、Power AppsやPower AutomateなどのPower Platform製品群を対象として、自社独自のコーディング標準（ガイドライン資料）を用意することを目標として、その際に抑えておくべきポイントについてご紹介します。

属人化とは

属人化とは、スキルを有する（Power Platformのスキルに限らず、業務知識や立場、人間関係も含みます）特定の人だけがアプリを作成、運用、保守することで、アプリの挙動や、そのアプリを利用した業務の進め方を把握しているのも本人だけとなってしまい、他の人が、後からアプリを利用したり、機能を追加したり、動作を修正したりしようと思っても、容易に行えない状態を指します。

属人化のデメリットとしては、以下のようなことが考えられます。

担当者が休み／異動した／退職した際に、業務を代行できる人がいなくなる
担当者以外に内容を理解している人がおらずチェックできないため、品質が悪化する
業務を通じて習得した知識を、担当者以外に横展開することができない
特定の人（大抵はスキルが高い人）に負荷が集中する

こうした課題を解決し、運用・保守しやすいアプリを作成させるための手段として、業務やアプリ内製の手順を標準化するために「コーディング標準」を整備することが挙げられます。初学者がつまずきやすいポイント、悩みがちなポイントでうまく誘導するようなガイドライン資料を用意しておくことで、誰でも一定レベルのアプリを作成できるようになり、また、他の市民開発者が作成したアプリの中身を理解できるようになることから、属人化を防ぐことができます。

マイクロソフト社の公式ホワイトペーパーとして、 PowerApps Canvas App Coding Standards and Guidelines のような資料は公開されていますが、Power Appsキャンバスアプリに関する内容しか記載されていません。そのため、市民開発にキャンバスアプリから入門したユーザーが、次のステップとして、キャンバスアプリとクラウドフローを連携させようとしたり、Dataverseテーブルをもとにモデル駆動型アプリを作成しようとしたりすると、参考にできるガイドライン資料が見つからず、社内のサポート窓口に問い合わせが殺到したり、アプリを作成すること自体を諦めてしまったりといった結果となりがちです。

また、こうしたマイクロソフト社やサードパーティ各社によって一般向けに公開された資料の場合、Power Platformに関して読み手がある程度知識を持っていることを前提に記載されていることも多いため、市民開発とレベル感が合致しないこともよくあります。たまに、ガイドライン資料だけを販売して欲しいといったご要望をいただくこともありますが、これらの理由から、出来合いの資料をご提供しただけでは、個々の組織ごとに最適な運用とすることができないと考えているため、弊社では、ガイドラインの策定支援として、検討フェーズからご提案させていただいています。

予め確認しておくべき事項

コーディング標準を作成する前に、決めておく必要があることとして、以下のようなものがあります。

読み手のITリテラシー

コーディング標準を読んでもらいたい市民開発者のスキルレベルを絞り込んでおき、コーディング標準に記載する内容や粒度の目安を決めておきます。初学者向けは動画資料のみとして中級者以上向けのみ文書化したり、想定レベルごとに分冊を作成したりすることも考えられます。

また、ガイドライン資料に強制力を持たせるかどうかについても、読み手のスキルレベルに応じて検討する必要があります。

一定以上のスキルを有する開発者を対象とするのであれば、「コーディング標準」として、あくまでも標準的な手順を紹介するのみとしますし、初学者を対象とするのであれば、より強制力の高い「コーディング規約」として、禁止事項や制限事項を列挙していくことも必要になってきます。

文書の長さ

SIerなどでアプリを開発するエンジニアであれば、品質を保証するための材料の1つとしてコーディング標準の分量を多くしても問題ありませんが、内製を目指す一般企業の場合は、自身の業務を抱えながらアプリの内製も進める、というパターンが多いため、コーディング標準の分量が多くなると「読まれない」「使われない」「保守（改善）されない」文書になってしまいます。コーディング標準を読んでもらいたい人たちが、アプリの内製（コーディング標準の理解＋アプリの実装）にどの程度の時間を掛けられるのかを検討し、最小限の分量で、コストパフォーマンスが高くなることを目指します。

対象とする製品

Power Platformには多種多様な製品が含まれているため、すべてを網羅したコーディング標準を用意しようとすると膨大なコストを要します。

そのため、まずはガバナンス管理の観点から、どの製品は利用させて、どの製品は利用させたくないかを検討して、文書化が必要な範囲や優先順位を決めていきます。例えば、統制を厳しくして、予め申請されたキャンバスアプリだけしか作れないようにしたい場合は、アプリの実装手順のみを案内すれば充分ですが、申請なく自由にキャンバスアプリやモデル駆動型アプリを作れるようにして内製化を推進したい場合には、環境構築の段階から手順化しておく必要が出てきます。

また、優先順位を決めるのが難しい場合は、自社で導入している製品ライセンスの割り当て状況や、市民開発者がどの製品を利用しているかモニタリングした結果をもとに、判断することも有効かと思います。

さらに、優先順位とは別に、個々の製品を説明する順序についても検討する必要があります。

一般的に、市民開発者は「Power Appsキャンバスアプリ」でUIを実装し、バックエンドで実行するロジックを「Power Automateクラウドフロー」で追加し、管理者用の一覧性が高い画面を「Power Appsモデル駆動型アプリ」で実装する、といった順番で製品を利用し始めることが多いことから、App in a Dayのようなセミナーでもこの順番で説明されますし、コーディング標準のような文書を作成する場合にも同様の順番で記載することが多くなります。

しかし、組織によっては、「他社RPA製品からの移行をした経緯からPower Automateクラウドフローから導入した」「以前はDynamics 365を利用していたのでモデル駆動型アプリのUIに慣れている」といった理由から、キャンバスアプリを最初に記載してしまうことによって、最後まで辿り着けずに脱落してしまうリスクが高くなる場合もあります。このため、市民開発者の製品利用状況から、どのような順番で説明するべきかについても検討すると良いかと思います。

実装手順と案内方法

アプリの実装方法を学習する際に、開発者によって、アプリをゼロの状態から手順書通りに作り上げて学んでいきたいと考える人も、完成しているアプリを思うままに改変しながら少しずつ学んでいきたいと考える人もいます（市民開発の場合には、前者のチュートリアル形式を好む方が多いように思います）。両方ともガイドライン資料で案内できればベストですが、文書化のコストが増えたり、ページ数が増えると資料を読んでもらえなかったりといった理由から難しい場合もあります。

コーディング標準を読んでもらいたい人たちが、どちらをより求めているのかを考えて、優先順位をつけておきます。これは、Power Platformをトップダウンで導入するのか、ボトムアップで導入するのかにもよるかと思いますので、Power Platform製品をこれから導入する（あるいはライセンスを購入したばかり）場合には、製品の展開方法と併せて検討する必要があります。

まとめ

今回は、キャンバスアプリ以外のPower Appsモデル駆動型アプリやPower Automateも対象に、自社独自のコーディング標準を用意する前に押さえておくべきポイントについてご紹介しました。次回は、実際に弊社で作成しているコーディング標準をもとに、具体的にどのように運用していけば良いかご説明したいと思います。

弊社の Power Platform サポート＆アプリカタログサービスでは、今回ご紹介したようなガイドラインの策定や、市民開発者コミュニティの運営、ガバナンス管理に対するサポートも積極的に行っています。まずはお気軽にお問い合わせください。