「Power Platform 勉強会 #1」に参加しました

2024/05/09

大阪でPower Platform 勉強会 #1に参加しました
Japan Power Apps User Group 大阪は4年ぶりにリブートされたそうです！

アールスリーインスティテュートさん、いつも素敵な会場をありがとうございます！

備品管理アプリ～キャンバスアプリとモデル駆動型アプリを作ってみた～

BizOptimars いのうえさん

キャンパスアプリは自由なデザインでインターフェースを構築するアプリ。
モデル駆動型アプリはデータベースをモデルとして連動して構築するアプリ。

ライブデモでアプリ作成をされていました。
データベーステーブルは備品マスタと貸出テーブルを作成されて、キャンパスアプリは備品を借りるユーザー向けにスマートフォン対応、モデル駆動型アプリは備品管理するユーザー向けにPCインターフェースとして作成されていました。
30分のセッションでライブデモでお手軽に開発できるんですね。
Excelとかで台帳管理みたいなことするなら、みんなPower Appsにしたらいいのにと思いました。

コレクション活用術

ダイキン工業まさキチさん

物品管理アプリや残業管理アプリを作成されて、残業管理アプリは部門で運用されている。
勤怠管理アプリや組織表アプリとかフル活用されていました。
アプリを作成される上で、困ったところやクリアされた方法や気付きや小技を惜しみなく発表されていました。

残業管理アプリがない頃は、Excelで管理されていて直接入力をしてたので数式が消えてしまったり人のデータも編集できたりという問題があったそう。
また残業運用ルールも部門で異なるので、全社統一システムというわけでもないそうです。
部門特有の運用のためにSaaSを入れるというのもなかなかな点もあると思うので、適した使用範囲なのかもしれないですね。

LT

知識ゼロの営業マンでもできた！超速で初心者を脱する、悪魔的学習ステップ3選

トレノケート株式会社西さん

営業部門で自分の仕事の自動化をPower AppsやDinamixと連携したり、Backlogと連携して実現されている。
そしてそれを自信がなくてもさくっとアウトプットしていきましょう！

Dataverse活用のメリットと課題

株式会社村田製作所近藤さん

市民開発と考えたときに役割をどう考えていくか。
その中で行レベルでのアクセス制御が必要になった。
モデル駆動型アプリは行レベルのアクセス制御はできるけど、キャンバス型は中間テーブルを介している。
親子関係のデータでは親から子への反映をPower Automateでされている。
セキュリティ設定をちゃんとできることで、市民開発を安全にやってもらえる。

Power Automateで始める、1分からの業務改善

ダイドードリンコ株式会社北裏さん

在席状況がわかりづらい。
業務開始メール、終了メールを把握しづらい。
Power Automate x Teams x SharePoint Listを連携。
業務開始時は自動で送信されるカードに答えるだけで、Teamsのリストに反映されて、一目で見られるようにされた。

Power Automate x LINE x SharePointで社外向け商品カタログを作ってみた

金谷さん

LINEのWebhookイベントからPower AutomateのHTTP受信トリガーを呼び出して、Share Pointからデータを取得して、HTTPアクションでLINEのMessaging APIへリクエストして返している。
LINEではローディングアニメーションという「・・・・・・」を出せるアニメーションが使えるようになったそうです。

Power BI を使うなら、スタースキーマは知っておこうね

Microsoft MVP 清水さん

Power BIはデータモデルがスタースキーマーになっていることを前提に作られている。
なのでPower BIを使うならスタースキーマーを知ってるほうが例外なく使いこなせる。

BIのというかビジネスの概念図。
わかりやすいです。

インプットデータの収集と加工、判断分析できる可視化までの自動化、定型化されたアウトプットまでの自動化、ここをひたすらやり込むだけでも業務効率化はかなり進むと思ってますし、実証もしてきました。
様々なデータソースからのETLサービスを組み合わせて自動化はできるけども、Power BIをより良く使うならスタースキーマを徹底しましょう、ということでした。

スタースキーマのスターは星型という意味で、1つのファクトテーブルが中心になって、星の端のようにディメンションテーブルがつながっている。
ファクトテーブルはトランザクションデータを保存し、ファクトテーブルに含まれるIDの参照先が各ディメンションテーブル。
とディメンションテーブルは1:Nの関係で、N:Nにしてはいけない。
そうすることでクエリーパフォーマンスが向上し、アプリケーション実装がシンプルになるというもの。
デメリットはディメンションテーブルが重複する。
セッション中に紹介いただいた https://www.databricks.com/jp/glossary/star-schemaを読みながら、解説を聞いてて理解が進みました。

まとめ

知らないことをたくさん知られた勉強会でした。
日常的にいつからかExcelとメールで行われている各部の業務。
Power Platformでデータベースとアプリにすれば、自動化や可視化など改善につながることがたくさんありそうです。
目的に応じたサービス、機能を選択して使う、そしてそのサービスのより良い使い方を知ることは、エンジニアだけでなくすべてのビジネス、仕事をする人に必要なスキルだということを再認識しました。

最後までお読みいただきましてありがとうございました！

「AWS認定資格試験テキスト＆問題集　AWS認定ソリューションアーキテクト - プロフェッショナル改訂第2版」という本を書きました。