💡 この記事でわかること
Power AppsやPower Automateをはじめとするローコード開発は、短期間でアプリを作れる一方、保守性の低さという課題を抱えています。この課題を解決する鍵は、「標準機能で対応可能な箇所はなるべく標準で作成する」という設計思想の徹底です。本記事では、代理承認機能を例に、作り込みを最小化して要件を見直す考え方と、ローコードアプリ開発で大切にすべき設計原則を解説します。
- ローコード開発のメリットと保守性が低下する原因
- 「標準機能を最大限活用する」という設計思想の重要性
- 代理承認機能を例にした作り込み最小化の考え方
- ローコードアプリ開発で保守性を高める設計原則
小刀稱 知哉ことね ともや
得意領域
Power PlatformやSharePointを中心に設計・開発・アドバイス・教育まで幅広く担当しています。内製化をご希望の場合はお気軽にお問い合わせください！
保有資格
ローコードアプリの設計方針でお悩みですか？アーティサンの内製化支援サービスでは、Power Apps・Power Automateの設計思想から実装まで、現場で使えるノウハウをお伝えします。
近年、Power AppやPower Automateをはじめとするローコード開発の市場が拡大しています。
それに伴い、ローコードアプリのエンジニアの需要も高まっています。
そこで、本日は「ローコードアプリのエンジニアが、開発を行うにあたり大切にすべき設計思想」について私の考えを述べたいと思います。
これからローコードアプリを開発していきたい方、会社でローコードアプリの開発を任された方に向けた記事です。
ローコードのメリット・デメリット
はじめに、ローコードでアプリを開発する際のメリット・デメリットについて述べます。
メリット
最大のメリットとしては、「短期間でアプリ開発が可能」という点です。
ローコードを用いてアプリを作成する際は、コーディングを伴わず、標準で提供されているフォームやボタンなどのモジュールを組み合わせることで開発を進めていきます。
また、GUI操作のみで開発が完結するため、従来のコーディングによる開発と比較し、短期間でアプリの開発が可能となります。
デメリット
一方デメリットとしては、「保守性が悪い」という点が挙げられます。
テキストエディタではなくGUIで開発するため、Power Apps上で実行されるプロパティの順番を把握していないと、デバッグが難しいということがあります。
（ブレークポイントなども設定できないので、処理を追っていくのが難しいですよね💦）
このように、短期間でアプリを作成できる一方、保守性の問題を抱えているのが現状です。
ローコードアプリの設計思想
上記を踏まえ、ローコードアプリを設計する際には、「標準機能で対応可能な箇所は、なるべく標準で作成する」という思想が、従来の開発手法と比べ重要になってきます。
「こんなの当たり前じゃん！」という方も多いかと思いますが、案外この思想を守れていない人が多いのではないでしょうか。
それは、従来の開発ではプログラムにて作り込むことが前提であったため、エンジニアはエンドユーザーから要望を受けると、「要望をどのように実現するか」ということに焦点を当てる思想が根付いているためだと私は考えております。
しかし前述したように、ローコードアプリは保守性が悪いため、機能の作り込みが多くなると、その分だけメンテナンスに時間がかかり（たまに誤ってバグを仕込んでしまい…）、ローコードアプリのメリットであった「短期間でのアプリの開発が可能」という点が犠牲になってしまいます。
よって冒頭で申し上げたように、ローコードアプリの開発を行うエンジニアは、「どれだけ標準機能を用いてアプリを作成することができるか」という思想が非常に重要になります。
しかし、実際はエンドユーザーとのヒアリングの中で、標準外の要望を受けるのも多々あります。
その際、「要望をどう実現するか」の前に、一度「その要望は本当に必要なのか」または「標準機能に落とし込むことはできないのか」という視点を持つことが非常に重要です。
（言い換えると、「アプリを人に合わせるのではなく、人をアプリに合わせる」ということです。）
代理承認機能を例にとって説明します。
Power AppsやPower Automateを用いて承認用アプリを作成する際に、「代理承認をできるようにしてほしい」などの要望を受けることがあります。
従来から存在する承認アプリには提供されていることの多い機能ですが、Power AppsやPower Automateで実現する場合、作り込みが必要となります。
代理承認機能をPower Appsにて実現させる場合、（一概には言えませんが）以下のような作業を追加で行う必要があります。
承認者と代理承認者のマッピング用テーブルを新たに追加
承認者と代理承認者の設定画面を新たに追加
新規申請時に、通常の申請か代理申請か選択するボタンを追加
承認履歴テーブルに代理承認フラグを追加
代理承認を実施した際、代理承認フラグをtrueにする処理を追加
しかし、機能の作り込みを行う前に「なぜ代理承認機能が必要なのか」という点を考えてみましょう。
その理由が「承認者が出張中の時、承認できないと困る」というような場合、「Power Automateで承認申請を行うと、TeamsやOutlookに通知される。その通知はスマートフォンでも確認できるため、出張中だから承認できないということにはならないのでは？」という考えに至るのはないでしょうか。
このような理由であれば、代理承認という機能自体が不要となります。
また、作り込みの手間が少ない機能を代替案として実装するというアプローチもあります。
例えば、申請者が自分で承認ルートを設定できる機能を追加するというアプローチです。
この機能を実装すれば、緊急時は申請者が設定した承認者に承認を依頼することが可能になります。
また、承認ルートを申請者が設定する機能だけを追加すれば良いため、先程挙げたテーブルの追加や設定用画面の準備、代理承認フラグの操作が不要となります。
もちろん全ての要望を標準機能に落とし込むことができる訳ではないですが、一度「現在の業務を疑ってみる」という視点を持つことで、ローコードのアプリ開発に対する難易度を下げることができます。
以上、ローコードアプリ開発時の設計思想について、私の考えを述べさせていただきました。
設計する際の考え方について、参考となれば幸いです。
最後までお読みいただき、ありがとうございました！
Power AppsやPower Automateを活用したアプリ開発を検討している企業様へ。アーティサンのPower Apps / Power Automate 導入支援サービスでは、設計段階からの伴走支援で品質の高いアプリを短期間で実現します。