チームでプロジェクトを運営している際に発生しがちなのが「日々の報告をどうするか？」という問題。その問題に対して、１つのアプローチを Power Platform で提案したいと思います。
前提条件
- Microsoft（Office）365 利用中
- Microsoft Teams 利用中
- Power Apps、Power Automate 利用可能
ユースケース
例1：チームメンバーの進捗と予定を把握したい
「昨日までの実績」「今日の予定」「問題点」などを毎朝把握したいマネージャーさんはナカーマ。しかし、この報告を、Aさんはメール、BさんはWeb会議、Cさんはチャット、etc・・・。チームメンバー各々がバラバラの手段で実施されても困りますよね？
かといって、プロジェクト管理ツールのような大きな仕組みが必要でもない。あるいは、利用している管理系ツールが複数プロジェクトを横断してチェックできない等、ようは「チームメンバーの報告を集約する仕組み（しかも、簡単に）」がほしい状況。
例2：稼働時間や体調を把握したい
決まったタイミングで、メンバーのAさんが、先日はどのプロジェクトに何時間使ったか？が把握したい場合や、チームメンバーの体調や発熱（平熱、微熱、やばい等）を把握したい場合。おそらく、毎朝チェックしたい、という要望が多いと想定。
要するに
マネージャーは特定のユーザー（チームメンバー）の状況を、決まったタイミング（多くは朝）に確認したい。つまり、報告を求めたい。各ユーザーは、報告のテマを極力最小化して、本来やるべきタスクに注力したい。（マネージャーとしてもさせたい）
アーキテクチャー
Power Automate で各メンバーの Teams へ AdaptiveCards で作成した状況報告フォームを発信して、それに回答してもらい、データストアへ蓄積します。状況を把握したい場合は、閲覧専用の Power Apps アプリから「今日の状況」をデフォルト表示にした状態で確認できるように提供します。
単純に「報告を求める」「報告をしてもらう」「結果を閲覧する」の3点を全て満足するだけなら、この仕組みで十分ではないでしょうか。
Power Automate 補足
AdaptiveCards のカードを Teams に投げて入力してもらわなくても「毎日報告用 Power Apps アプリ」を作成しておいて、Automate からリマインドして「入力してね」と促すことも可能です。
- Adaptive Cards ＋ Teams 個人宛てはメリットが多い
- スマホやPC、ブラウザーなど利用者が何を使っていても”気づき”がある → Teamsの通知
- 報告の実施が、全て Teams 上で完結できる
- フローを共有せずにシステム用アカウント等で一本化できる
- 対象者が50名以上の場合は、フローを練らないとダメ
- Automate の仕様で、同時平行でカードを投げられるのが最大 50
- 報告間違い等の修正は割愛している
- 前述のイメージでは変更・削除の導線を意図的に記載していません
- データソースによって対応が変わってくるため、対応方法は各位でご検討ください
なお、この仕組みは、@mofumofu_dance さんが 『コロナ対策エンジニア』 で紹介されていた仕組みを参考に構築しております。Hiroさん、毎度ありがとうございます！！
30分でランチ勉強！Microsoft Power Automateで健康状態報告フローを作る
Power Apps 補足
前述のイメージだと、関係者全員がデータを閲覧可能な状況になります。閲覧制限を実施したい場合は、それにあったデータソースとアプリの実装が必要になります。有償ライセンスを所有されているのであれば、モデル駆動型が良いかな？と思います。
今回の例だと、ここで登場する Apps は閲覧のみなので、さほど難しくないと想定しています。
おことわり（あるいは、諸注意）
あえて、実装に関する詳細は記載していません。そのため「ここがうまくデキないんですけど」等のご質問には対応いたしません。個人的な思いですが、自分たちで調べて、実装して試してみて、使ってみて初めて身につくモノがあると考えております。是非、みなさん挑戦を。どうしても・・・、という場合はお仕事として対応できる方などにご相談ください。
「こういう設計のが良いのでは？」や「こういうデザインもあるよ」というご意見は大歓迎です。
当方のチームな場合
下イメージのような状態で運用しています。稼働日の毎朝、マネージャー含めてチーム全メンバーが下記の仕組みで状況報告を登録しています。データストアが SharePoint Online（以降、SPO）のため「間違えちゃったテヘペロ」は直接データソースを修正してもらいます。
対象ユーザーの特定方法や稼働日の判定について詳細は割愛しています。ヒントを出しておくと「対象ユーザーを Groups から取得できませんか？ → ダメならターゲットの一覧持つしかないですね」「古来から伝わる”非稼働日マスター”みたいな発想が必要になります」ですかね。※これも正解は1つではないので、各々の状況に応じた解決案をご検討ください。
はじめから、SPO の該当リストへデータ登録してもいいんですよ。でも、毎日、決まった時間に、決まったリストへデータ登録（しかも、データ分析しやすいように列を設定しているので直感的じゃないトコが多少ある）するのって、思った以上にメンドクサイです。メンドクサイってコトは、ユースケースにもあげた「報告のテマを極力最小化」されてないというコトです。メンドクサイと長続きしないんです。
閲覧などを権限保有者に限定する例
例えば、下記のようなイメージになるのかな？と考えます。
データに対して閲覧可能な対象ユーザーを絞るには CDS がオススメだと判断しています。その場合、データソースを直接該当ユーザーに修正させるワケにはいかないでしょう。なので、メンテナンス用の報告修正アプリが必要になる想定です。
データの閲覧は、Power BI でも、 Power Query 利用して Excel でも、今まで紹介してきたように Power Apps のアプリ（キャンバス・モデル駆動型 どちらでも可）でも、何でもOKです。
黄色で囲んだ箇所は、今まで紹介したアーキテクチャーと変わりありませんね。ランニングコストは「閲覧させたいユーザー数に依存」すると予想されます。ここらへんがイメージしづらい場合は、プロに相談されることをオススメします。あるいは、学習あるのみです。
まとめ
今回のアーキテクチャーも、Automate に関してはシステム用アカウントで統一できます。他のメンバーへフローを共有する必要はありません。Power Apps と Automate のフローを組み合わせる際の「当方の基本姿勢」は別の記事で解説しております。Power Apps と Automate を組み合わせて活用されたい方は、当記事とあわせて是非ご確認ください。
PowerApps + Microsoft Flow 組み合わせ時の設計思想
今回のような「報告を集めたい」場合は、
- 報告をもとめる（＝報告してもらう）
- データを貯める
上記2点が主軸になると思います。まず、そこをしっかり設計・構築しちゃいましょう。閲覧やら、報告の修正やら、集計はデータソースとデータの項目がしっかり設計できていれば、どんな手段でも比較的簡単に実現できると想定しています。なので、まずは「期待するタイミングで、欲しい報告を集める」コトに注力してみてください。データが集まれば、あとは閲覧するだけなので。
この時「全部１つのアプリや仕組みにまとめちゃう」という発想はしないでくださいね。
『小さくて鋭いツール』で生産性をUpして、楽して業務をたのしみましょう。
それでは、皆さま、素晴らしい Power Platform Life を！