Power Appsでアプリ開発する一連の流れを紹介

Power Appsでのアプリ開発は、流れを把握してから着手すると驚くほどスムーズに進みます。要件定義から本公開・メンテナンスまで、市民開発者の視点で一連のプロセスを整理しました。

一般的なシステム開発経験者の視点では抜け・漏れがあるかもしれませんが、あくまでも市民開発者目線の記事として参考にしてください。

1. 要件定義
2. 環境構築
3. 設計
4. 開発
5. プロトタイプの公開
6. 本公開
7. メンテナンス

開発の流れは料理でかんがえるとわかりやすい

難しく考える必要はありません。料理をするときの流れを想像してみましょう。

ご飯を作るときも、何を作るか決めて、材料を揃えて、手順通りに調理する。アプリ開発も、まったく同じ考え方で進めることができます。

1. 要件定義

要件定義は、アプリ開発でもっとも重要なフェーズです。何を作るか、誰のために作るか、どんな機能が必要かを言語化することで、開発の方向性が定まります。

Power Appsで作るアプリには、大きく2種類あります。依頼を受けて作るアプリと、自発的に作るアプリです。

依頼を受けて作るアプリは、誰かから困っていることを聞いてニーズを把握したうえで作るものです。他人の依頼を形にするわけなので、要件定義が大切というのは理解できるでしょう。

自発的に作るアプリは、自らが業務改善をするために作るアプリです。現場の仕事を理解している分、業務改善・DX化が進みやすいメリットがあります。ただし、ついつい要件定義を省略して好き勝手に作ってしまいがちです。私がそうでした。ちゃんとした運用を考えるのであれば、やはり要件定義は必要です。

自分の思考を見える化することで整理ができますし、他人が見ても共通のゴールと道筋が見えるのが大切なのです。

要件定義の一例

アプリの一例を出して、要件定義を作ってみました。

このような感じです。ExcelやSpreadsheetにまとめておき、進捗に合わせて色付けするなどして管理しやすくしておきましょう。

ちなみにこのアプリは、実際に私が作った自発的なアプリの一例です。作った当時は市民開発の初心者だったので、きちんと要件定義も作らずに制作していました。

判断できる力が必要

必須機能として挙げた項目が、本当に実装可能かどうか判断できる力が必要です。Power Appsでできることとできないことを要件定義の段階で明確にする必要があり、市民開発者はその判断を求められます。

実装できないものは3つのレベルにわけて考えると整理しやすいです。

1. それが実装可能かどうか知らないので実装できない
2. 実装できることは知っているが、経験値が自分にないので実装できない
3. Power Appsの仕様上、実装できない

初心者の市民開発者は、まず1が該当するでしょう。Power Appsに詳しい人に尋ねたり、ネットや書籍で調べる必要があります。2のケースは、時間をかければ自力で解決できるかもしれません。3の判断がつくのであれば、非常にラクですね。どのレベルに当てはまるかを把握できれば、このアプリはほぼ成功したも同然です。

この業務は何のためにやっているのか、やり方を変えられるか、業務を無くせないか――こういう考え方が重要です。

2. 環境構築

環境構築とは、Power Appsを使うか、Power Platformを組み合わせて使うか、データベースは何にするかを決めることです。

Power Platformには、外部サービス連携のためのコネクタが1,000種類以上用意されています。ただし、企業によっては業務に関係ないSNSや海外サービスのコネクタに使用制限がかかっていることが多いです。自社で使用できるコネクタと制限を把握したうえで、どのツールを使うかを考える必要があります。

Power Appsは万能ツールではないため、機能上限があります。Power Automateも会社のライセンス次第で1日の使用に制限がかけられています。まずは制約をきちんと把握することが大切です。

データベースの種類も考える必要があります。Excelにすると一部機能が制限されることがあります。SharePoint Listsにすると委任問題や5,000件問題があります。Dataverseにするとほぼ万能ですが追加料金がかかります。それぞれの特徴はPower Appsのデータベース選びの記事で詳しく解説していますので、あわせて参考にしてください。

3. 設計

設計では、アプリで扱うテーブルを計画します。エンティティ、属性、リレーションシップなどを定義し、データの整合性とアクセス効率を最適化するためのスキーマを設計します。この設計が、後のアプリのパフォーマンスと拡張性に大きく影響します。

私がまだ市民開発の初心者だったころ、データベースはアプリに1つあれば十分じゃないかと考えていました。アプリから入力して保存する、それをアプリで表示する、アプリ作りなんて楽勝だと思っていました。

でもアプリを使う人が増えたり、凝った内容にしようとすると、これユーザー情報をまとめた一覧表が別で必要じゃないか、とか、選択肢の名称が変更になったら全部の記録を手動で修正するのは現実的に無理じゃないか、と行き詰まることに気づいてきたのです。Dataverseを使ったアプリ作成に乗り出してからは、特にこのデータベース設計が重要な意味を持つことを実感しています。

逆にいえば、ExcelやListsを使ったシンプル構造のアプリは、そこまでデータベース設計にこだわる必要はないかもしれません。ただ考え方のクセはつけておいたほうがいいです。

データベース設計の基本

データベース設計は簡単にいうと、データベースにどんな列を持たせる必要があるかを考え、正規化し、その関係性を明確にすることです。

例えば、社員のデータベースを作るなら、名前・部署・入社年月・出身地などの列を作って管理するでしょう。

そのデータベースで何を管理したいかに合わせて列を設けます。こうして出来上がったものをテーブルと呼びます。

正規化とは、テーブルの余計な列を無くし（冗長性の排除）、データの整合性を保つための最小単位のかたまりにすることです。このような名簿テーブルがあるとします。

一見するとこのままデータベースとして使えそうですが、先々のメンテナンスを考えてみましょう。例えば社内の部署名変更があり、営業部が営業統括部に変更するとします。すると先程の名簿はこのように修正が必要です。

全データを一括で修正するのは手間がかかりますし、修正ミスのリスクも高い。ではこれをどうするべきかというと、部署名に固有IDを持たせて2つのテーブルで管理します。

すると、部署名を変更するときも部署テーブルを1箇所変更するだけで済み、間違うリスクを減らすことができます。

Power Appsのデータソースには、この2つのテーブルを連携します。あとはギャラリーコントロールなどで参照が可能になりますね。このような作業を正規化といいます。

非エンジニアの私は、このデータベース設計のことを知らないままPower Appsに触れていました。ところがアプリを作っていくうち、テーブルをわけて別々にデータを管理しないと、作業が複雑すぎて対応できなくなると気づいたのです。結果的にデータベース設計の大切さを知ることになり、初心者向けデータ設計の書籍を数冊読み込んで勉強しました。

要件定義とデータベース設計は一朝一夕ではならず

要件定義とデータベース設計は、理屈を知ったからといって最初から完璧なものができるわけではありません。アプリを作るうち、やっぱりあの機能があったほうがいいとか後で思いつくことはザラにありますし、必要なデータベースを忘れていて後から追加することもあります。

これらは経験を重ねて慣れていくしかないと思っています。学べば学ぶほど、必要な機能やデータ構成がわかるようになってきます。一朝一夕ではいかないものです。

4. 開発

開発段階では、要件定義で特定した核となる機能に焦点を当て、アプリの基礎を構築します。必須要求を満たし、核となるプロセスが正しく機能することを確認するフェーズです。

先ほどの要件定義の例でいえば、ひと目で全員のテレワーク・出社状況を把握できるギャラリー画面を作ること、個人がステータスを入力する画面を作ること、これが最初の開発目標になります。

開発が進むにつれ画面が増えてきます。複数画面のアプリ設計については、Navigate関数を使った画面遷移の記事で詳しく解説していますので、あわせて参考にしてください。

完璧を求めすぎず、まず動くものを作ることが重要です。細かい調整や追加機能は、プロトタイプ公開後のフィードバックをもとに対応していけば十分です。

5. プロトタイプの公開

プロトタイプの公開では、初期バージョンのアプリを限定的なユーザーグループにリリースし、実際の操作を通じたフィードバックを収集します。この段階で得られる意見や提案は、アプリの改善と最終的な品質向上に不可欠です。

最低限のUIを作り、テストユーザーに公開してアプリを使ってもらいましょう。自分一人では見落としていた挙動を指摘してもらったり、使い勝手向上のためのヒアリングを進めます。

Power AppsはURLを通じてアクセスしますので、改修したアプリはすぐに使ってもらうことが可能です。Teamsを使って専用チームを作成し、気づいたことをどんどん投げてもらうといいですね。

6. 本公開

本公開の段階では、アプリを関係者全員にリリースし、実運用を開始します。ここまでくれば一通りの開発フェーズが終了です。場合によっては、付属機能の実装と本公開はオーバーラップしてもいいですね。

7. メンテナンス

メンテナンスフェーズでは、アプリの運用を継続的に監視し、バグ修正やパフォーマンスの最適化を行います。また、ユーザーからのフィードバックに基づいて機能の追加や改善を続けていきます。

アプリは公開して終わりではありません。使われながら育てていくものです。定期的に見直す習慣をつけておきましょう。

まとめ

アプリ開発の一連の流れをまとめます。

1. 要件定義
2. 環境構築
3. 設計
4. 開発
5. プロトタイプの公開
6. 本公開
7. メンテナンス

要件定義は、アプリ開発における肝になるフェーズです。開発・プロトタイプの公開は、ひたすら手を動かすフェーズ。本公開・メンテナンスはアフターフォローのフェーズです。

アプリの規模にもよりますが、最も時間がかかるのは手を動かして作るフェーズですね。1つ機能をつけたらできるだけ早くプロトタイプとして公開し、フィードバックを得るといいでしょう。

Power Apps全体の学習ロードマップや各機能の位置づけについては、Power Apps開発の全体マップ記事でまとめて解説しています。あわせて参考にしてください。

今回紹介した流れは、アプリを作れば作るほど自然と身についてきます。楽しみながら手を動かして、1つでも多く経験を積んでいきましょう。