業務部門の担当者がPower Apps・Power Automateでアプリ開発をするときに大事にしておきたい思考

Power Apps・Power Automateで顧客の業務アプリ開発を始めてから、かれこれ5年程が経ちました。業界の中でも、多くのキックオフ・サービスインを経験してきたと思います。

お客様から挙げられる課題や実現したいことは、いたってシンプルで共通項があるものの、その中身（機能要件）が複雑になりがちです。「複雑なのに開発がコーディングよりも効率的に行えない中、どのようにしたら生産性を高め、顧客への価値提供を最大化できるか」を考えた結果、ある思考に基づいて自身の生産性をコントロールできるようになった経緯があります。

今回は、そのあたりをかいつまんでお話し、業務部門の担当者さんが参考にできるように落とし込みたいと思います。初学者からステップアップ中の中級者向けです。

まず私はどのような人？

とあるMS系のSI会社で、Power Platformに関する事業立ち上げを行い、黎明期から引き合いのほとんどを一人でリードしました。
多い時で1か月に4プロジェクトの開発を行うくらいでしたので、開発生産性を意識しながらプロジェクトを進行していました。

現在はフリーランスとして、以前と同様にPower Platformに関するコンサルティング・開発を行っています。他には、上場前のベンチャー企業でSaaSの立ち上げやスタートアップ企業でのプロダクトマネジメントの経験があります。いずれも小規模な会社だったため、ロールに縛られず、Webから営業まで何でも行っていました。

お客さんはどういう課題を抱えていたの？

当時は、アウトバウンドでの営業活動は一切行っておらず、インバウンドでの契約に限定されていました。そのため、問い合わせてくるお客様の傾向には共通点が比較的多かったです。

• 業務部門の場合
  開発しているアプリが適切な設計であるか不安。
  利用者が増えた場合に耐えうる仕様になっているか不安
  業務設計を基に仕様を考えているが、本当に実現可能なのかわからない
  トラブルがないようメンテナンスできる環境を整えたい

• IT部門の場合
  導入に耐えられる体制が欲しい

業務部門は、開発に関する知見が不足していることで発生する課題があります。一方、IT部門はリソース計画による課題があります。最近は認知が進んだことで、お客さんが作成するアプリのアプローチもこなれてきていると感じますが、やはり独自のアプローチで開発していることで、組織へのノウハウの浸透が開発スピードよりも遅いため、課題は以前とあまり変わっていない様子です。

ではどういうことをするといいの？

Power Apps・Power Automateを含むローコード・ノーコード開発は、プロトタイプ開発が最速・最適と言って間違いありません。最速で機能を実現することが最大の価値とも言えますが、MVPに向けたプロダクト開発ならともかく、Power Platformのように自身の業務をデジタル化するという視点のソフトウェア開発では、速度だけでなく、業務担当者たちで継続的な改修をしていく必要があることに注目する必要があります。
そのため、初動の時点で改修・最適化する、いわゆるリファクタリングしながら開発する考えをインストールしておくことが、効果的な開発スタイルの実現につながると考えています。

これは、Power Apps・Power Automateに新たに機能を追加する場合、当初の設計では機能不足となり、リファクタリングどころか、機能を丸ごと作り直すことが必要になることがよくあるためです。外部の開発者は納期があり、作り直しの時間は丸ごとサンクコストですので、非常にロスが大きくなります。

このロスを最小化するためには、思い付きではなく、リファクタリングを考慮した再現性のあるアプローチで開発を行う必要があります。また、繰り返しによる経験値の向上により、リクエストされた機能の実現までに必要な時間が（h時間m分の精度で）見えてくるため、アジャイルなスタイルでも見積もりの精度が高くなると考えられます。

具体的にどういうことを考えておけばいいの？

再現性のあるアプローチであれば、言語化・フォーマット化が可能となり、チームメンバーにも習得しやすくなりますし、他のメンバーが開発したアプリをメンテナンスする際にも理解しやすくなります。
Power Apps・Power Automateにおいては、以下のことを常に考慮することで開発生産性を向上させることができるでしょう。

1. 関係性があることを必然とする
   
   Power Appsはデータベースにデータを入力するサービスであるため、リクエストされたアプリの要望を聞いている段階で、正規化されたデータがイメージできていると、設計しながら開発できるので、初動が最速になります。
   

2. 各種定義はアルファベット・英単語で作り、開発の初動で決める
   
   通常の開発同様、データベース・リスト・列・構造の定義には、ダブルバイト文字は使用しません。近年ではお客さんにも浸透している様子はありますが、SharePoint・Dataverseでの落とし穴があるため、うっかりしていると再作業に時間を取られてしまうことになります。私の場合、アッパーキャメルケースとスネークケースで統一しています。
   

3. 2回作業を行うものは変数化する
   
   Power AppsよりもPower Automateで顕著なことがあります。二重のメンテナンスはサンクコスト全体に影響を及ぼします。プロジェクトが後半になると改修作業の負荷が高まることもあります。例えば、申請ワークフローで、ステージ毎に文言を作成していませんか？変数だけでなく、処理を共通する設計を初期段階で構築できると最高です。
   

4. フォームのUIデザインは考えない
   
   現在もコントロールで設定できるスタイルがまちまちなため、特にフォームに対して洗練されたデザインを取り入れることは諦めます。その代わりに、タッチポイントの高い場所の操作性やファーストスクリーンに力を入れます。開発生産性を向上することで、リクエストの実現の高速化で捻出した時間を、ユーザー体験を洗練させることに使います。
   

5. 周囲の習熟度に合わせる
   
   複雑な業務要件を1つのアプリに落とし込むことができても、習熟度によっては「あえて」そうしません。ローコード開発の最大の弱点は、時系列とともに保守性が著しく低くなることです。曼荼羅ワークフローを複数のフローに分割するなど、最小限のコントロール・アクションを維持し、保守性を高めることが重要です。この方が、提供価値が高いと考えます。
   

〆

実装のHow toはあってもアプローチのHow toがずっとないよなぁと思って、言語化しました。製品の認知度が上がったのでノウハウを蓄積しやすい環境ができてきていると思いますが、どんなことでも興味のある人は自走していく一方、受け身な方も世の中にはいますので、そういった方がいきなりアサインされても安心して能動的に開発できる情報を提供できたらなぁと思っています。