2019年6月8日～9日の土日で開催されました「Power BI 勉強会＠番外編～伊勢EBI会議　EBI-Kaigi～」に参加してまいりました。一般参加者なのか、運営なのか、よくわからない立場でしたが、最高に楽しい2日間でしたよ。

まえおき

初日は生まれて初めての伊勢参りをし、
ゑびやさんで美味しい昼食をいただき、
EBI LAB さんの見学＆説明をしていただき、
小田島社長のセッションを拝聴したうえで素敵な旅館で宴会。

↑ ゑびやサンでの昼食風景。美味しかったなぁ。

2日目は「Power BI エビ会議ハッカソン」ということで、名付けて「ゑびっかそん」を開催。『ゑびやさんの売り上げデータと”何か”を比較する』というお題で、A～Eの5チームにわかれてPower BIを駆使してチーム各々が独自の視点でデータ分析と比較をして、最後に発表する、という流れ。

発表は各チーム持ち時間5分で実施してもらったのですが、その際に利用したアプリが今回紹介するモノです。各チームの発表に対して「おもいろい」とか「へぇなるほど」とか思ったら押してもらうルールで評価を集計する、というアプリというか仕組みです。
なお、このアプリのネタはFaceBookの Japan Power BI User Group で質問されていた方のアイディアをそのまま頂戴しております。お名前を明記するのは避けますが、ありがとうございました。

実際の動作イメージ

#PowerPlatform Collaboration.#PowerApps → SPO → #Flow → #PowerBI pic.twitter.com/KW0y8kTuVa
— やま (@yamad365) 2019年6月14日

”何か”に似ているけど、気のせいですｗ
本来は複数人が連打するので、Power BI のリアルタイムダッシュボードがぐりぐり動いて面白いのですが・・・。上記の動画は当方が独りで頑張ったヤツなのでご容赦ください。

アーキテクチャー

今回、当方が採用したアーキテクチャーは下記になります。

以前に書いたこちらと考え方は完全に同じです。

　1)PowerApps で作成したボタン押すアプリ
　　↓
　2)SharePoint Onlie のカスタムリストへクリック毎にデータ追加
　　↓
　3)Microsoft Flow のアイテム登録・更新トリガーで着火
　　↓
　4)Power BI ストリーミングデータセットをFlowで更新
　　↓
　5)ストリーミングデータセットを Power BI ダッシュボードで表示

データストアとしてSharePointのカスタムリストを利用している点、および登録トリガーでFlowを着火させる、といった”ひと手間”を加えているため、若干レスポンスが遅いです。もちろん、PowerApps から直接 Flow を着火させることも可能です。おそらく、直接Flowを着火させる手段のほうがレスポンスも早いと思います。
しかし、以前にもお伝えしているとおり、その場合はFlowを利用者全員へ共有する必要が発生します。加えて、今回はもう１つの理由があったのです。それは・・・

あえてデータソースを経由させた、もう1つの理由

実は、ゑびっかそん本番で利用した仕組みは2名がかりで組み上げているのです。

上図のように、PowerApps とそれ以降で綺麗に役割分担が可能です。データソースとなるSharePointのカスタムリストを設計してしまえば、あとは各々が平行して作業も可能です。
当方は準備にあまり時間を取れなかったため、先にPowerApps でアプリを作成してしまいました。その環境をそのままPower BI担当してくださる方に引き継いで出発の日を迎える、という状態でした。が、ちゃんと完成して動いてます。この場合、引き継ぐ方がPowerApps に詳しくなくても、データソースの定義が明確であればPower BIの知識で全て完結できるため、お互い余計な心配が不要になります。

つまり、お互いに影響することなく作業分担を実施可能なアーキテクチャーになっている、ということですね。その前提を強固なものにするためには、やはり「データの設計」が重要になってきます。

蛇足：もっと実装したかったポイント

準備時間がほとんど取れなかったので必要最低限の仕組みしか組み込んでいません。ほんとは、下記のような機能も実装したかったんですよね。

管理者側から「今どのチームが発表しているか？」を強制する
カウントをバッファして数秒単位に送信するなどの操作性とレスポンス改善
セッション終了したチームへの投票禁止
後から投票しなおしを許可するモード（一定時間解除など）
ボタン押下時の音（音声準備するのがめんどくさかったｗ）

アイディアはあるんですが、時間が足りなかった・・・。
まぁ、本来やりたかった本筋はおさえたつもりですし、参加者皆さんの反応も好印象だったので、大成功だったんじゃないかな、と思っている次第です。

まとめ

伊勢神宮へ参拝する際は、ゑびやサンでランチがおススメ
データソースを起点にアーキテクチャーを分割すると役割分担が簡単
- PowerApps 、Power BI ともに1つの対象へ複数人アプローチが現状できない
- それを、アーキテクチャーで回避することができる！
データソース設計が一番重要。これを疎かにするのは危険
- ちゃんと設計できれてば、今回のようにスムーズな連携も可能
システムやソリューション間の結合度は低い方が良い

今回はあまりに技術的要素が薄い内容になってしまいましたが、いかがでしたでしょうか？おそらく、あのアーキテクチャー図と、実際の動きを確認いただければ、作成できる方はサクッとやれちゃう内容だと思います。また、データソースをSQLDatabaseやCDS等の別モノにすることもできますし、前半や後半を別の仕組みに置き換えることも簡単にできるかと思います。各ソリューション間の結合度が低いコトは良いことです。

ゑびやサン、EBILABさんの社長はじめスタッフの皆さん、さらには赤福さんの方まで2日にわたりEBI会議へ様々なご支援を賜った点、こちらで御礼申し上げたいと思います。ありがとうございました！

それでは、皆さま。素晴らしい Power Platform Life を！