Power Appsを使ってアプリ開発する際の、一般的な流れを紹介します。
一般的なシステム開発経験者から見て抜け・漏れあるかもしれませんが、あくまでも市民開発者視点であることをお含みおきください。
- 要件定義
- 環境構築
- 設計
- 開発
- プロトタイプの公開
- 本公開
- メンテナンス
開発の流れは料理でかんがえるとわかりやすい
難しく考える必要はありません、料理をする時を想像しましょう。
これと同じことを、アプリ開発においても考えてみましょうというものです。
| 開発 | 詳細 | 料理 |
|---|---|---|
| 要件定義 | なにを作るか？ | ご飯何にしよう？ |
| 環境構築 | ツールを考える | 材料や調理器具の準備 |
| 設計 | 仕様や動作 | 玉ねぎはどう切る？ お米は何合？ |
| 開発 | 実際の開発 | 材料を切る、炒める |
| プロトタイプの公開 | 試作品の公開 | 味見 |
| 本公開 | 完成 | 完成 |
| メンテナンス | 保守・メンテナンス | 後片付け |
0. 最初の注意
Power Platformを勉強したての人は、これらの順番はあまり気にせず、開発に慣れる意味でいきなり作ってみることをおすすめします。
UdemyやYouTubeを見つつ、手を動かして真似して作っていく中で、開発の流れを自然と理解できるようになります。
1. 要件定義
要件定義では、アプリで解決しようとしている問題や、ユーザーのニーズを理解し、アプリに求められる具体的な要件を明確にします。
- いま困っていることは何か
- アプリでそれをどう解決するのか
- アプリを使うユーザーは誰か
- 必須機能は何か
- あったら便利な機能は何か
最低限、これぐらいの項目があるといいかなと思います。
本場のプログラム開発現場では、もっと細かく、もっと深く要件定義をするらしいのですが、市民開発レベルではここで示した内容で十分ではないかと思います。
要件定義というと難しく聞こえますが、簡単にいえば、アプリ作成における地図をつくるようなものですね。
ゴールがあいまいでは、途中で道に迷います。
ゴールは決まっていても、道順がわからなければ迷います。
ゴールに到着したはいいものの、通過しなければならないチェックポイントを見逃しているかもしれません。
地図を作ることでこのようなミスを無くし、目指すゴールに正しい順序で到着するための前準備となるのです。
要件定義はいつも必要
アプリ作成の出発点は主に次の2つのシーンが想定されますが、どちらの場合も要件定義を作りましょう。
- 受け身で作るアプリ
- 自発的に作るアプリ
『受け身で作るアプリ』とは、周りから◯◯に困っているという声を受け、作成の依頼を受けて作るアプリです。
他人の依頼を形にするわけなので、要件定義が大切というのは理解できるでしょう。
『自発的に作るアプリ』とは、自らが業務改善をするために作るアプリです。
市民開発は会社のIT部門が担当することが多いかもしれませんが、私のように元営業だった非エンジニア人間が、配置転換で自部署のIT・DXを担当するケースもあります。
後者の場合、現場の仕事を理解した状態でアプリ作成を担当するので、業務改善・DX化が進みやすいメリットがありますね。
ですので、つい要件定義を省略して好き勝手アプリを作ってしまいがち（私がそうでした）なのですが、ちゃんとした運用を考えるのであれば、やはり要件定義は必要です。
自分の思考を見える化することで整理ができますし、他人が見ても共通のゴールと道筋が見えるのが大切なのです。
要件定義の一例
アプリの一例を出して、要件定義を作ってみました。
| 定義項目 | 詳細 |
|---|---|
| いま困っていることは何か | テレワークが増え、部内で誰がテレワークなのか出社なのか把握しづらい |
| アプリでそれをどう解決するのか | ひと目で全員のテレワークと出社を見ることができる |
| アプリを使うユーザーは誰か | 自分の部署と関係部署、合わせて3部署 |
| 必須機能は何か | Outlookスケジューラーの予定を抽出する機能。 テレワークと出社を判別し、わかりやすく表示する機能。 |
| あったら便利な機能は何か | 1週間ほど先まで予定が見える機能。 部署ごとにわけて表示する機能。 出社人数がわかる棒グラフ機能。 |
このような感じです。
Excelにでもまとめておき、進捗に合わせて色付けするなどして管理しやすいようにしておきましょう。
ちなみにこのアプリは、実際に私が作った『自発的に作るアプリ』の一例に属するものです。
（作った当時は右も左もわからない市民開発の初心者だったので、きちんと要件定義も作らない制作していました）
判断できる力が必要
注意する点として、必須機能として挙げた項目が、本当に実装可能かどうか判断できる力が必要です。
要するに、Power Appsでできることとできないことを要件定義で明確にする必要があり、市民開発者はその判断を求められるわけです。
『実装できる』ものは問題ありませんが、『実装できない』ものは3つのレベルにわけて考えましょう。
- それが実装可能かどうか知らないので『実装できない』
- 実装できることは知っているが、その経験値が自分にないので『実装できない』
- Power Appsの仕様上、『実装できない』
初心者の市民開発者は、まず1が該当するでしょう。
Power Appsに詳しい人に尋ねたり、ネットや書籍で調べる必要があります。
2のケースは、時間をかければ自力で解決できるかもしれません。
3の判断がつくのであれば、非常にラクですね。
ステークホルダーと共有する
要件定義がまとまれば、ステークホルダー（利害関係者）を集めて次のことを共有します。
- いまこんなアプリを作ろうとしている
- アプリがあれば業務がこう変わる
- こんな機能を搭載しようとしている
要するに、今後アプリを使う関係者に対して事前にコミュニケーションを通しておくわけです。
特に重要なことが2つあります。
- アプリを浸透させるにあたってキーマンになる人に話を通しておくこと
- メインでアプリを使う人に話を通しておくこと
まずは1点目の『キーマン』から。
せっかくアプリを作ったはいいものの、ある程度ちからを持つ人の鶴の一声でアプリがおじゃんになる可能性があるかもしれません。
それが誰なのか、あなたのケースに置き換えてよく考える必要があります。
その人にはまず先にアプリ計画のことを共有して了承を得ておきましょう。
次に2点目の『メインでアプリを使う人』。
これはアプリに必要な機能を考える上で非常に重要です。
現場の声を聞き、必須機能をもれなく洗い出す必要がありますし、そもそも、既存業務のやり方をアプリに置き換えていくことに抵抗する人が出てくる可能性もあるのです。
アプリを導入する目的や効果を根気よく説明し、理解してもらう必要がありますね。
設計のスコープを決めておく
設計のスコープとは、どこまで作成し、何を作成しないか、ということです。
特に「何を作成しないか」はとても重要で、これを明確にしておかないと後から苦労します。
日報提出アプリを作成する。リマンインド機能は付けるが、集計機能は搭載しない、という具合に、アプリが担う機能を決めておきます。
ある程度開発が進んだところで設計が変わるのは絶対に避けなければいけません。
下手するとアプリの中身をごっそり変更することを求められるかもしれず、無駄なマンパワーをかけないためにも「何を作成しない」ははっきりさせておきましょう。
業務手順の見直し提案もおすすめ
業務をアプリ化する前に、本当にその業務が必要なのか、無くすことはできないか、やり方を変えられないか、という考え方も要件定義で必要になることがあります。
機能を作ったはいいものの、そもそも省略できる業務であれば機能を作るだけ無駄になってしまいますね。
「この業務は何のためにやっているのか」
「やり方を変えられるか」
「業務を無くせないか」
こういう考え方が重要です。
2. 環境構築
ここでいう環境とは、Power Appsを使うか、Power Platformを使うか、両方使うか、データベースは何にするか、を意味します。
もともとPower Platformには、外部サービス連携のためのコネクタと呼ばれる機能が1,000種類以上用意されています。
しかし、企業によっては業務に関係ないSNSや海外サービスのコネクタは使用制限がかかっていることが多いかと思います。
果たして自社で使用できるコネクタや制限を考えた上で、Power Appsが適当なのか、Power Automateが適当なのか、別のサービスを使う必要があるのか、を考えなければいけません。
プレミアム機能で外部API連携も可能ですが、お金がかかる上にハードルが上がります。
さらに、Power Appsは万能ツールではないため、機能上限があります。
Power Automateは会社のライセンスPower Automate次第で1日の使用に制限がかけられています。
データベースの種類も考える必要があります。
Excelにすると、一部機能が制限されることがあります。
SharePoint Listsにすると、委任問題や5,000件問題があります。
Dataverseにすると、ほぼ万能なツールですが追加料金がかかります。
すべてを勘案し、どんな環境にするかを考える必要があります。
3. 設計
設計では、アプリで扱うテーブルを計画します。
エンティティ、属性、リレーションシップなどを定義し、データの整合性とアクセス効率を最適化するためのスキーマを設計します。
この設計が、後のアプリケーションのパフォーマンスと拡張性に大きく影響します。
私がまだ市民開発初心者だったころ、データベースはアプリに1つあれば十分じゃん、と考えていました。
アプリから入力して保存する、それをアプリで表示する、アプリ作りなんて楽勝だ！と考えていました。
でもアプリを使う人が増えたり、凝った内容にしようとすると、『あれ、これユーザー情報をまとめた一覧表が別で必要じゃないか？』とか『選択肢の名称が変更になったら、全部の記録を手動で修正するの、現実的に無理じゃないか？』とか、行き詰まることに気づいてきたのです。
特に、Dataverseを使ったアプリ作成に乗り出してからは、特にこのデータベース設計は重要な意味を持つことに気づいてきたのです。
データベース設計の基本
データベース設計は簡単にいうと、データべースにどんな列を持たせる必要があるかを考え、正規化し、その関係性を明確にすることです。
例えば、社員のデータベースを作るなら、『名前』『部署』『入社年月』『出身地』などの列を作って管理するでしょう。
そのデータベースで何を管理したいかに合わせて列を設けます。
こうして出来上がったものは『テーブル』と呼びます。
正規化とは、テーブルの余計な列を無くし（冗長性の排除）、データの整合性を保つための最小単位のかたまりにすることです。
このような名簿テーブルがあるとします。
一見するとこのままデータベースとして使えそうですが、先々のメンテナンスを考えてみましょう。
例えば社内の部署名変更があり、『営業部』が『営業統括部』に変更するとします。
すると先程の名簿はこのように修正が必要です。
これは件数が少ないので手動変更でも問題ありませんが、大量のデータが存在すると煩雑になるだけでなく、入力ミスの恐れも出てきます。
ではこれをどうするべきかというと、部署名に固有IDを持たせて2つのテーブルで管理します。
すると、部署名を変更するときも部署テーブルを1箇所変更するだけで済み、間違うリスクを減らすこともできます。
Power Appsのデータソースには、この2つのテーブルを連携します。
あとはギャラリーコントロールなどで参照が可能になりますね。
このような作業を正規化といいます。
非エンジニアの私は、このデータベース設計のことを知らないままPower Appsに触れていました。
ところがアプリを作っていくうち、テーブルをわけて別々にデータを管理しないと、作業が複雑すぎて対応できなくなると気付いたのです。
結果的にデータベース設計の大切さを知ることになり、初心者向けデータ設計の書籍を数冊読み込んで勉強しました。
要件定義とデータベース設計は一朝一夕ではならず
いままで紹介した『要件定義』と『データベース設計』は、理屈を知ったからといって最初から完璧なものができるわけではありません。
アプリを作るうち、やっぱりあの機能があったほうがいいとか後で思いつくことはザラにありますし、必要なデータベースを忘れていて、後から追加することもあります。
これらは経験を重ねて慣れていくしかないと思っています。
学べば学ぶほど、必要な機能やデータ構成がわかるようになってきます。
一朝一夕ではいかないものです。
4. 開発
開発段階では、要件定義で特定された核となる機能に焦点を当て、アプリの基礎となる部分を構築します。
このフェーズでの目標は、アプリケーションの必須要求を満たし、核となるプロセスが正しく機能するのを確認することです。
具体的な例を挙げて要件定義を見てみましょう。
| 定義項目 | 詳細 |
|---|---|
| いま困っていることは何か | テレワークが増え、部内で誰がテレワークなのか出社なのか把握しづらい |
| アプリでそれをどう解決するのか | ひと目で全員のテレワークと出社を見ることができる |
| アプリを使うユーザーは誰か | 自分の部署と関係部署、合わせて3部署 |
| 必須機能は何か | Outlookスケジューラーの予定を抽出する機能。 テレワークと出社を判別し、わかりやすく表示する機能。 |
| あったら便利な機能は何か | 1週間ほど先まで予定が見える機能。 部署ごとにわけて表示する機能。 出社人数がわかる棒グラフ機能。 |
必須機能は、『1. Outlookスケジューラーの予定を抽出する機能』と『2. テレワークと出社を判別し、わかりやすく表示する機能』の2つです。
優先的にこれらの機能の実装を進めましょう。
必須機能がうまく機能することがわかれば、このアプリはほぼ成功したも同然です。
5. プロトタイプの公開
プロトタイプの公開では、初期バージョンのアプリを限定的なユーザーグループにリリースし、実際の操作を通じたフィードバックを収集します。
この段階で得られる意見や提案は、アプリの改善と最終的な製品の品質向上に不可欠です。
最低限のUI（ユーザーインターフェース：ボタンや入力項目など）を作り、テストユーザーに公開してアプリを使ってもらいましょう。
自分一人では見落としていた挙動を指摘してもらったり、使い勝手向上のためのヒアリングを進めます。
Power AppsはURLを通じてアクセスしますので、改修したアプリはすぐに使ってもらうことが可能です。
Teamsを使って専用チームを作成し、気付いたことをどんどん投げてもらうといいですね。
6. 本公開
本公開の段階では、アプリを関係者全員に対してリリースし、実運用を開始します。
ここまでくれば一通りの開発フェーズが終了です。
場合によっては、付属機能の実装と本公開はオーバーラップしてもいいですね。
7. メンテナンス
メンテナンスフェーズでは、アプリの運用を継続的に監視し、バグ修正、パフォーマンスの最適化を行います。
また、ユーザーからのフィードバックに基づき、新たな機能の追加や既存機能の改善を継続的に行い、アプリの価値を持続的に向上させます。
プロトタイプでは拾いきれなかったバグが次々と出てくることが予想されますので、これもTeamsを駆使して素早く対応していきたいところですね。
Power Appsは一般的なシステムとは違い、スクラップアンドビルドが容易という特徴があります。
大幅な機能改善が必要になれば、既存アプリの運用を終了し、いちから新しいアプリを作ったほうが早いことがあります。
何がもっとも効率的か見極めて行動しましょう。
アプリを作って作って慣れよう
アプリ開発の一連の流れをまとめます。
- 要件定義
- 環境構築
- 設計
- 開発
- プロトタイプの公開
- 本公開
- メンテナンス
『要件定義』は、アプリ開発における肝になるフェーズです。
『開発』『プロトタイプの公開』は、ひたすら手を動かすフェーズ。
『本公開』『メンテナンス』はアフターフォローのフェーズです。
アプリの規模にもよりますが、最も時間がかかるのは手を動かして作るフェーズですね。
1つ機能をつけたらできるだけ早くプロトタイプとして公開し、フィードバックを得るといいでしょう。
今回紹介した流れは、アプリを作れば作るほど自然と身についてくることです。
とにかく手を動かして、1つでも多く経験を積みましょう。
