2019/12/24 Power Apps でローコーディングな勉強会 #11で相談させていただいた内容です。

1. 2019/12/24
PowerAppsでローコーディングな勉強会 #11
小玉 純一
失敗実例から
ベストプラクティスを
学んでみる（強引

2. 自己紹介
はじめまして。 小玉 純一（34）と申します。
[仕事]
現職：新聞を作るシステムの保守や社内業務改善など
前職：カーナビの画面を制御する組み込みSE
[趣味]
ノンコーディングアプリ作成ツール
「Power Apps」で楽器アプリを作ったり
アウトプットしたりするなど
[SNS]
Power Apps Champion
(Microsoft Ignite 2019)
@KodamaJn
@KodamaJn

3. 弊社実例（2018年夏）
 各企業のトップインタビュー記事広告
各企業のトップを取材した内容を
記事広告として紙面掲載するもの
 取材日程調整が煩雑 → アプリ化
 どの顧客を
 いつ取材して
 いくらで売るか

4. ♪～
取材日程調整運用（アプリ導入後）
各営業部員
取材担当
取材日程
調整
営業部管理者
②取材希望日の
重複をチェック
①企業に売り込み、
申込情報を登録
③取材日程
確認＆承認
⑤担当営業と
一緒に取材
④自動会議招集
Power Platform

5. 必要な情報を考える
（一般的にはこうかな～）
 顧客情報
 会社名
 住所
 電話番号
 代表者名
 担当営業
 契約情報
 取材日時
 広告料金
 校正状況
取材日時 顧客ID 広告料金 校正状況
顧客ID
会社名
住所
電話番号
代表者名
担当営業

6. Power Apps で
どうやって作ればいいの？
「データから開始」
＋
ちょいカスタマイズ
では、できないしなぁ～

7. 悩んだ挙句、3案を依頼者に提示
 フォームを分ける  1つのフォームで
2つのテーブルを
同時更新する顧客フォーム
契約フォーム
顧客
テーブル
契約
テーブル
顧客
テーブル
契約
テーブル
 テーブルを1つに
する
テーブル
顧客情報が変わった時
に2つのフォームに入
力するのが手間だなー
更新時の制御を慎重に
やらないとだなー
シンプルだけど、同じ
顧客情報増えていく。
大丈夫なのか…？

8. ユーザーが
一番操作しやすい
のは…？
他の作成者に
引継ぎやすい
のは…？
正しい
データ構造
は…？
残るモヤモヤ感

9. 結局

10. 1つのテーブルにしてしまった（汗
このツールでは顧客数
は管理していないので
大丈夫です（依頼者）
既存の顧客情報を毎度
入力しなくていいように
過去データ検索＆
自動入力機能を搭載

11. 皆さまなら
どう構築されますか？
様々な視点で
ご意見をいただきたく
m(_ _)m

12. いただいたご意見
 Dynamics 365 を買う
 顧客管理ツールとして完成されているから、これがベスト
 むしろ完成されているツールがあるものを1から作るべきではない
 CDS にして、モデル駆動型で構築する
 キャンバスアプリで頑張って作るより、モデル駆動型ならデータが
決まれば勝手に一覧やフォームが作成されるから
 既存のオンプレサーバに顧客情報があるなら顧客情報はそこから
取る
 既にある情報をわざわざ冗長管理する意味はないから
 アプリとして使う DB （テンポラリー）と、データとして貯める
DB （永続化）を分けて考える
 扱うツールによって最適なデータ構造が異なるから
（例：RDB は BI の観点から言えば扱いにくい）
 今イメージできないのであれば、顧客情報と契約情報を
分けたくなった時に分ける（データ量にもよるが）