Power Appsはローコード開発を可能にするツールですが、ローコードだからといってマネジメントを怠ったり品質を意識しない開発を行ったりするとプロジェクトが炎上するリスクがあります。
本記事では炎上を超えた燃えカスPJをいくつか経験した筆者が、炎上を防ぐための具体的な方法と、炎上してしまった際の対処法について一般的な観点に加え、Power Apps独自の観点も交えながら説明します。
まだまだ経験不足ですので、ローコードだとそんなこともあるんだなくらいでお読みいただければ幸いです。
Power Appsとアジャイルの親和性
Power Appsでのアプリ開発はアジャイル的な考え方で進行することがいいと言われることが多いです。
まずはなぜPower Appsとアジャイルの相性が良いとされるのかを考えてみます。
市民開発者が開発を行うので、サイクルを爆速で回すことができる
Power Appsなどのローコードツールは、基本的には市民開発者が開発することが前提となっているので、それによって得られるメリットが大きいです。
特に要件定義工程とテスト工程でその恩恵を大きく受けることができます。
それぞれの工程でかかる時間が要件定義はユーザー自身が作るためほぼ0、テスト工程はユーザー自身が使うためほぼ0になることもあるのではないでしょうか。(複雑なアプリを作る場合はどちらもきちんと時間をかけましょう)
一方で設計・開発工程では専門的な知識が必要になるため、市民開発の場合は時間を要してしまうかもしれません。
「動くもの」を素早く作ることができる
アジャイルソフトウェア開発宣言に、「動くソフトウェアこそが進捗の最も重要な尺度です。」という文言があります。
また、「包括的なドキュメントよりも動くソフトウェアを」という文言もあります。
Power AppsはPowerPointのように画面を作成することができるので、画面モックレベルのアプリを作るのは爆速です。
一方でアプリのロジック部分は程度によりますが、普通にプログラミングの知識が必要なのでそこまで早くはないです。
無駄な作業を最小限にできる
二つ目に重複しますが、市民開発者が開発を行う場合は包括的なドキュメント作成などの工数を削減できます。
もちろんないよりはあった方がいいですが、ある程度の属人化は許容されると思います。
Copilotなどの生成AIを活用することでドキュメント作成の時間を最小化するのもアリですね。
🔥炎上を防ぐ方法
主に一般的な観点での炎上を防ぐ方法を記載します。具体的なPower Apps独自の観点はまずLearnを読んでください。
アジャイル手法を正しく実行する(肉付け×、具体化〇)
アジャイルソフトウェア開発宣言では、「要件の変更はたとえ開発の後期であっても歓迎する」とされていますが、ビジネスにおいて手戻りは何よりもクソです。
たとえアジャイルであっても、手戻りが最小となるように初期段階で要件の大枠を決めておく必要があります。
例えばアジャイルのスクラム手法では、直近のタスクは具体的に、未来のタスクは抽象的に設計するというルールがあります。
このルールにより、直近何をするかを明確にしつつ、開発後期の要件変更に対応することができます。
そもそもアジャイルソフトウェア開発宣言には「シンプルさ（ムダなく作れる量を最大限にすること）が本質です。」とも記載があるので、その要件・要件変更が本当に必要なのかはきちんと議論される必要があります。
期待値コントロール
Power Appsはローコードツールなので、普通の言語での開発のように複雑なことを実装しようとするとUXが悪くなったり、むしろ時間がかかったりしてしまうことをユーザーに理解してもらう必要があります。
ローコードには得意領域があり、その領域を超えてしまうとあまりローコードである意味はないです。(とはいえニーズはあるので難しいところ)
また繰り返しになりますが、その要件・要件変更が本当に必要なのかはきちんと議論される必要があります。
特に無理な実装を伴う要件については、どのようなリスクがあり、そのリスクが顕在化した場合にはシステムやスケジュールにどのような影響を及ぼすかをユーザーに説明し、理解してもらう必要があります。
リスクのエスカレーション
アジャイルが正しく機能していればエスカレーションがされないなんてことはないはずですが、アプリの動作が前より重くなったかな？と思ったらすぐにエスカレーションしましょう。
燃えカスになってからだと1から作り直すしか解決策がなくなってしまうので、できるだけ早く上司を説得して有識者の意見を仰ぐ機会を作りましょう。
ベストプラクティスを学ぶ
ベストプラクティスを学ばないまま開発をするとひどいものが出来上がります。
| 〇 | × | |
|---|---|---|
| データの保存/編集 | 編集フォームを使用する | Patch関数+テキスト入力コントロールを使用する |
| テーブルのフィルター | 条件式を工夫する | Ifの多重入れ子 |
| 画面・コントロール数 | 最小になるように設計し、必要に応じてアプリを分割する | 1つのアプリに要件を詰め込む |
あとはアプリのパフォーマンスに影響する要素を理解し、意識しながら設計開発を行うことが必要です。
主な要素には、コントロール数/データソースの種類/ロジックの複雑さがあります。
Power Appsでの開発におけるベストプラクティスは以下のLearnや記事を読みましょう。
- Power Apps Performance Optimisation: The ULTIMATE Guide
- キャンバス アプリのパフォーマンス低下の一般的な原因
- ヒントとベスト プラクティスを使用して、キャンバス アプリのパフォーマンスを向上させる
そしてアジャイルソフトウェア開発宣言を正しく理解し、実行することも大事です。
ここまで何度か引用していますが、まだ読んでないですよね？まずは読みましょう。
🧑🚒炎上してしまった時の対処法
ボトルネックの特定
まずは開発PJ全体を俯瞰し、何がボトルネックなのかを特定したうえでそれに応じたアクションをします。
- 情報なら：ストック情報(ドキュメント)とフロー情報(チャットのやり取り)を再整理する
- タスクなら：タスクの優先度/重要度や割り振りを再整理する
- 人なら：PM/メンバーに関わらずスキルに応じたアサイン調整を行う
Power Appsに限らず炎上PJはこれらの整理がうまくできていない結果、アプリのパフォーマンスが非常に悪くなってしまっているというのがほとんどだと思います。
リカバリープランの策定
アプリのパフォーマンスが悪くなってしまった場合、取るべきアクションは以下のどれかです。
リファクタリングで対処できる段階ならまだマシですが、作り直しになると最悪です。
- アプリのリファクタリング
- リバースエンジニアリング(Power Appsでベストプラクティスに沿って作り直し)
- リバースエンジニアリング(他のソリューションで作り直し)
これらの対処と情報(要件)やタスクの再整理を並行して実施するのが定石かなと思います。
ここまでを踏まえて鎮火までのスケジュールを立てていきましょう。
逃げるは恥かもしれないが死ぬよりマシ
ここまで対策や対処を書いてきましたが、開発PJは往々にしてうまくいかないものです。
炎上PJはしんどい分様々なことを学ぶことができますが、その一方で激務によって心や体に悪影響を及ぼすことがよくあります。
自分の限界を知り、真面目になりすぎず、時には逃げることが炎上PJと向き合う上で大事なマインドだと思っています。
元記事