想定読者
- Power Platform推進担当
- 情シス/CoE担当
- Power Appsを一般社員に広げたい企業
- 「どこまで市民開発で任せてよいか」を整理したい人
この記事の目的
- Power Appsアプリの難易度を判断できるようにする
- 市民開発とプロ開発の境界を整理する
- ALM/ガバナンスが必要になるラインを可視化する
記事タイプ
- 判断支援型
- 実務ノウハウ型
結論
Power Appsの難易度は、
「画面を作れるか」ではなく
「壊さず運用できるか」
で決まります。
特にLv2→Lv3の境界から、
単なる業務改善ツールではなく、
“業務システム”としての管理が必要になります。
全体像
Power Apps開発難易度レベル
| レベル | 区分 | 主な特徴 | 一般社員運用 |
|---|---|---|---|
| Lv1 | 市民開発 | Excel/SharePoint中心の小規模アプリ | ◎ |
| Lv2 | 高度市民開発 | Power Fx・条件分岐・Power Automate | ○ |
| Lv3 | 業務部門＋IT支援 | Dataverse・権限・承認・複数部門 | △ |
| Lv4 | プロ開発 | API・ALM・複数環境・基幹連携 | × |
まず一番大事な判断軸
「作れるか」ではなく「保守できるか」
難易度を決める8つの観点
| 観点 | 市民開発寄り | プロ開発寄り |
|---|---|---|
| データ | Excel / SharePoint | Dataverse / SQL / 基幹DB |
| 利用者 | 個人・小チーム | 全社・部門横断 |
| 権限 | 単純 | ロール別制御 |
| 処理 | 登録・更新・検索 | 複雑な業務ロジック |
| 連携 | 標準コネクタ | API / カスタムコネクタ |
| 保守 | 作成者が直せる | 影響調査が必要 |
| リリース | 直接修正 | Dev/Test/Prod |
| 障害影響 | 小さい | 業務停止レベル |
レベル別イメージ
Lv1 市民開発
イメージ
典型例
- 日報
- 備品管理
- 問い合わせ管理
- 簡単な入力フォーム
特徴
✅ 作成者＝利用者
✅ 小規模
✅ 障害影響小
✅ 一人で保守可能
Lv2 高度な市民開発
イメージ
典型例
- 申請アプリ
- 通知付きワークフロー
- 条件分岐の多い入力アプリ
難しくなるポイント
| 増えるもの | 起きること |
|---|---|
| 画面数 | 修正影響が見えなくなる |
| Power Fx | 属人化しやすい |
| Flow連携 | 障害切り分けが難化 |
| 利用者 | 問い合わせ増加 |
このレベルから必要
- 命名ルール
- メンター
- レビュー
- ドキュメント
最重要ポイント
Lv2→Lv3で世界が変わる
Lv3からは、
「作れる人」ではなく、
“壊さず運用できる人”
が必要になります。
Lv3 業務部門＋IT支援
イメージ
典型例
- 部門横断ワークフロー
- 承認管理
- 権限制御
- Dataverse業務アプリ
難しくなるポイント
| 項目 | 内容 |
|---|---|
| 権限 | 誰が何を見れるか |
| データ | 整合性維持 |
| 障害 | 業務停止リスク |
| 保守 | 他人修正前提 |
| 監査 | ログ・権限証跡 |
必要になるもの
- CoE
- ITレビュー
- 環境管理
- ガバナンス
- 運用設計
Lv4 プロ開発
イメージ
典型例
- SAP連携
- 基幹システム連携
- API統合
- 全社システム
このレベルで必要
| 必要要素 | 理由 |
|---|---|
| ALM | リリース事故防止 |
| 環境分離 | 本番保護 |
| ソリューション管理 | 配布管理 |
| CI/CD | 安定運用 |
| 監査対応 | 権限・変更管理 |
MicrosoftがALMを重視する理由
ALMとは
ALM（Application Lifecycle Management）は、
- 開発
- テスト
- リリース
- 保守
- 変更管理
を管理する考え方です。
ALMが必要になる理由
市民開発だけでは危険になる瞬間
よくある事故
| 事故 | 原因 |
|---|---|
| Flow停止 | 接続切れ |
| アプリ動作不良 | 列変更 |
| データ破損 | 権限不足 |
| 本番事故 | 直接修正 |
| 属人化 | 作成者しか理解していない |
判定用チェックリスト
3個以上YESならLv3以上を疑う
| チェック | YES/NO |
|---|---|
| Dataverseを使っている | |
| 利用者が複数部門 | |
| 権限制御がある | |
| API連携がある | |
| Flow障害で業務停止する | |
| 本番/検証環境を分けたい | |
| 作成者以外が保守する | |
| 監査対象になりうる |
研修対象としての整理
| 判定 | 育成方針 |
|---|---|
| Lv1 | 一般社員向けハンズオン |
| Lv2 | メンター付き育成 |
| Lv3 | 業務部門＋IT伴走 |
| Lv4 | IT部門/プロ開発者 |
実務で一番多い失敗
「Power Appsは簡単だから全員作れる」
これは半分正しく、
半分危険です。
確かに“作る”ことはできます。
しかし企業運用では、
- 誰が保守するか
- どうリリースするか
- 障害時に誰が直すか
- 接続や権限をどう管理するか
の方が遥かに重要です。
最終整理
まとめ
Power Appsは、
「ローコードだから簡単」
ではなく、
「どこまで業務システム化するか」
で難易度が変わります。
特に重要なのはLv2→Lv3。
ここからは、
- ガバナンス
- ALM
- 権限
- 保守
- 障害管理
が必要になり、
“市民開発”だけでは支えきれなくなります。
次にやること
- 自社アプリをLv1〜Lv4で棚卸しする
- Lv3以上はCoEレビュー対象にする
- ALM対象基準を決める
- 市民開発ガイドラインを作る
- 「誰が保守するか」を設計段階で決める