PowerPlatform 中級編2

microsoft365

現状の把握

製造業にお勤めの方ですと、QC活動というのをしたことがあるかもしれません。システム開発も基本的にはQC活動と同じような流れで進めれば間違いはありません。

まずは取り上げる案件について現状の把握をして、今どんな事で困っているのか、裏を返せばどんな事が良くなれば問題が解決するのかを予測し、それをゴールとして計画を策定します。

現状、うさぎの消耗品について一切の管理をしていません。

餌は二種類で、たくさんあげるものが「牧草」、1日1回あげるものが「ペレット」です。ペレットは1カップ分なので目分量ながら大体の消費量は均等。牧草は食べるだけあげる(うさぎは常に腸を動かしている生き物なので)ので、日によってまちまちです。餌なので毎日消費します。

トイレ用品も二種類で、トイレに撒く「砂」と、巣箱の下に敷く「ペットシーツ」があります。トイレ掃除時に消費します。砂は目分量ですがトイレ一杯分、シーツは毎回3枚と餌に比べてほぼ消費量が均等ですが、トイレ掃除は数日に1回行う為、消費期間が異なります。

前章で述べた通り、問題点はこれら消耗品は切れるまで何もせず、切れたらすぐに買いに走らねばならない点です。裏を返せば、いつ頃切れるかが予め分かっていれば、鮮度も嵩張りも気にせず、ついで買いができるので、緊急の買い出しという非定常作業が発生しなくなります。

目標(あるべき姿)の設定

問題点、何に困っているのかが判明しました。次に具体的に何がどうなったら問題点は解決できるのかという目標(あるべき姿)を設定します。

今回のケースでは、いつ頃消耗品が切れるかが目で見てわかることがあるべき姿です。これをもうちょっとシステマティックに言い換えると・・・

  • 目で見てわかる:「可視化」された状態にある
  • 何が:各「消耗品」の在庫が切れることが
  • どのように:具体的に何月何日ごろにという日付ベースで

となります。「可視化」というキーワードで頭をよぎるのはPowerBIです。要はPowerBIのレポートで上記内容がいつでも見られる状態にしておけば解決という事です。突き詰めていけば例えばここで出た日付をカレンダーに入れてスケジュール化、とか夢が膨らみますが、今回は欲張らず

各消耗品が切れる日程が表示できるPowerBIレポートを作る

というのを目標(あるべき姿)にしましょう。

あるべき姿に向かうために必要なもの、足りないもの

あるべき姿を設定できたので、現状とあるべき姿のギャップを埋めるために必要なものや足りないものについて考えます。これを埋める事ができればあるべき姿に向かえます。より具体化したものがシステム設計です。

前項現状の把握で書いたように、消耗品は決まった量や決まったタイミングで定期的に消費していきます。したがって消耗品はそれぞれ切れるまでのサイクルが決まっているのではないかと推測します。つまりこのサイクルを消耗品ごとに掴めれば、牧草は30日サイクルで切れているので切れる日は前回買った日の30日後の◯月◯日である、と予測が立てられそうです。

サイクルを掴むために必要なものは「記録」です。餌をあげた記録、トイレを交換した記録、そして消耗品を購入した記録の3点があれば、購入と消費の関係を明らかにでき、サイクルも明確になってきます。システム化はおろか紙で記録すら取っていないため、足りないものも「記録」です。

つまりこれら3点の記録を取るための仕組みが必要になってきます。記録の置き場、すなわちPowerPlatformで言うところのデータソースが必要です。最終的にPowerBIとデータ連携する事を考えると、データソースはアプリ間を横断できるようなものが良く、SharePointリストを想定します。記録を取る、すなわち入力アプリが必要となりますが、これは直感的にPowerAppsを想定できます。

PowerAppsで消耗品の記録を取る→SharePointで貯める→PowerBIで分析して可視化する

と、なんとなく一連の流れが見えてきました。

ヒューマンエラー

ここでもう一つ考えておかないといけないのは、ヒューマンエラーの発生についてです。人の手を介して行う作業の場合、100%完璧を求めるのは極めて難しく、問題が発生することは見越しておく必要があります。

今回の場合、最も重要なのは「記録」です。記録自体に間違いがあった場合、サイクル算出に必要な情報も間違いとなり、間違ったサイクルを出すことになり本末転倒です。記録を極力間違いないように設計していくのも開発者の責務となります。

記録自体の間違いもですが、今回一番懸念されるのは「入力忘れ」です。例えば餌は毎日入力が必須ですが、1日でも入力を忘れれば1日分サイクルがズレてしまいます。入力忘れだけは絶対に発生させない仕組みにしないといけません。ただ、忘れたからと言ってシステムが勝手に入力する訳にもいきませんので、入力者に入力を促す「通知」機能が必要となります。

通知方法として一番簡単なのは、カレンダー等にスケジュールを入れてリマインダー表示する事ですが、これはお勧めできません。自分が入力者の気持ちになって考えてみてください。リマインダーは入力していようがしていまいがスケジュールで通知します。入力しているのに通知されると気分はどうでしょうか?「やってるよ」「うるせーな」と思いませんか?そういう気持ちになると、通知を切ってしまいたくなりますよね。通知は本当に必要な時だけするべきです。(TVの災害速報とかと同じです)

条件によるアクション、と聞いて想定するのは、PowerAutomate(クラウド)です。クラウドフローを用いて未入力の時だけ、定期的に通知するようにすれば本当に必要な時だけの通知となります。これを盛り込むことにより、記録の正確性が保証され、正確なサイクル算出が期待できます。

システム設計

以上の情報を整理しまとめ、システム設計をします。

このように、別に無理やり3アプリを入れ込んだ訳ではなく、ちゃんと筋道を立てて考えていき必要なものを揃えていった結果3アプリを用いることになりました。それだけPowerPlatformは密接な関係にあります。

次のステップ

まずは記録を取らないと話が始まらないので、記録を取る受け皿となるSharePointリストの設計を行います。

コメント