投稿者「dekkaino」のアーカイブ

PowerAppsでオフィス内宅配ロッカーを作ろう

Power Appsを使って、オフィス内で荷物をやり取りする宅配ロッカーのような仕組みを作ります。

情報をやり取りする手紙がメールに置き換わっても、小包のような荷物の配送は依然として大量に存在します。郵便局が扱う手紙が減っても荷物の宅配が増加しているのはその一例です。オフィスの中で荷物を配達するのに、宛先の人のデスクに荷物を置いておくというやり方があります。一方で、最近ではフリーアドレスのようにオフィス内に決まった居場所を持たない働き方が増えています。決まった居場所・デスクのない方へ宛てた荷物を受け渡すための仕組みとして、宅配ロッカーのような仕組みを考えてみましょう。

問題の整理

オフィス内で荷物をやり取りするために必要な機能を宅配ロッカーを参考に考えてみましょう。

  • 荷物を一時的に保管できるスペース(ロッカー)がある。
  • 宛先の人物に、荷物が保管スペースへ納品されたことを知らせる。
  • 宛先の人物に、荷物を回収するように催促する。
  • 宛先の人物が荷物を回収したら、その保管スペースに新たな荷物を設置できるようになる。

他にも、世間の宅配ロッカーには宛先の人物以外が荷物を取り出せないといった機能があります。これは不特定多数の利用者がいる場合に必要ですが、小規模なオフィス内では省略しても問題ないと考えます。また、形状もロッカーである必要はなく、テーブルなどモノを置ける場所に区切りや仕切りを施せば十分です。

また、利用ケースとして、外部から届いた荷物を配送する場合だけでなく、同じオフィスで働く従業員間で荷物をやり取りするケースも想定します。

設計

ソフトウェア

  • 各保管スペース(ロッカー)の情報を管理するSharePointのリスト
  • 各保管スペース(ロッカー)の情報を配達員または利用者が書き換えるためのPower Appsアプリ
  • 利用者に納品通知や回収の催促を送るためのPower Automateフロー

ハードウェア

  • 荷物を一時保管するためのスペース
    広めのデスクをテープ
  • 各保管スペース(ロッカー)に対応するPower Appsアプリを呼び出すためのURLを埋め込んだQRコード
  • 利用方法を案内する掲示物

業務のフロー

荷物の預け入れ

配達員は保管スペースに荷物を設置します。また、配達員は保管スペースに掲示されたQRコードをスマートフォンで読み込むことでPower Appsアプリを起動します。
配達員はアプリを通して、荷物の受取人を選択します。このとき配達員から受取人に対して伝言があれば、伝言を記入します。受取人と伝言を記入してアプリから送信すれば、配達員の手続きは完了です。
Power Appsアプリから送信されたデータはSharePointのリストに格納されます。SharePointのリストを監視しているPower Automateのクラウドフローが受取人に対して通知を送ります。通知には、荷物が届いた旨、どの保管スペースに荷物があるかの情報、配達員が誰かの情報、配達員からの伝言が記載されます。

荷物の受け取り

受取人は保管スペースで荷物を回収します。また、受取人は保管スペースに掲示されたQRコードをスマートフォンで読み込むことでPower Appsアプリを起動します。
受取人はアプリを通して、荷物を回収したことを送信します。
Power Appsアプリから送信されたデータはSharePointのリストに格納されます。SharePointのリストを監視しているPower Automateのクラウドフローが受取人に対して通知を送ります。通知には、荷物を回収したことを確認する旨が記載されます。

荷物回収の催促連絡

未回収の荷物がある場合、カレンダーベースのPower Automateで当該荷物の受取人に通知を送ります。特定の日数(1週間など)を超えて放置されている場合、配達員にも通知を送ります。荷物の放置が通知された場合、配達員は受取人の所属グループ同僚や上司に対して荷物の回収を催促します。


作り方

各保管スペース(ロッカー)の情報を管理するSharePointのリスト

荷物のやり取りに必要な情報を一元的に管理します。

どのロッカー(保管場所)を操作するかをID列で指定します。

列名列名(内部)列の型目的
タイトルTitle一行テキスト人の目で見てわかりやすい各保管スペース(ロッカー)の名前を示します。
SharePointのリストで自動生成されるタイトル列を使用します。
IDID数値各保管スペース(ロッカー)と紐づけます。
SharePointのリストで自動生成されるID列を使用します。
受取人Receiver個人荷物の宛先(受取人)をユーザーで指定します。
荷物ありhasItemはい/いいえ荷物が設置されているか否かを示します。荷物がある場合は「はい」、荷物がない場合は「いいえ」です。
配達人PostedBy個人荷物を各保管スペースに設置したユーザーを指定します。
荷主Sender一行テキスト組織外部から荷物を発送した荷主の社名や名前を示します。荷物を各保管スペースに設置したユーザーではありません。
伝言message一行テキスト配達員から受取人への伝言を示します。
更新日時Modified日付最後に情報が更新された日時を示します。
SharePointのリストで自動生成されるModified列を使用します。

SharePointのリストで作ったイメージが次の図です。


各保管スペース(ロッカー)の情報を配達員または利用者が書き換えるためのPower Appsアプリ

SharePointのリストに対して、PowerAppsの編集フォームコントロールによる編集操作を行います。荷物があるかないかをhasItem列で判別し、hasItem列が「はい」の場合は荷物の回収動作、hasItem列が「いいえ」の場合は荷物の預け入れ動作を行います。

荷物の預け入れ動作 hasItem列が「いいえ」の場合

預け入れ動作用のスクリーンを表示します。

荷物を設置しようとする対象のロッカー名およびIDを表示します。

入力欄として、宛先人のユーザー選択を必須とします。必須でない項目として、荷主の名前と宛先人への伝言を入力できるテキストボックスを用意します。
この入力欄に対して「登録」ボタンを用意し、SubmitFormで入力欄の情報をリストに登録します。また、リストのhasItem列を「はい」に変更します。

荷物の回収動作 hasItem列が「はい」の場合

荷物の回収動作用のスクリーンを表示します。

荷物を設置しようとする対象のロッカー名およびIDを表示します。また、その時点で設定されている荷物の宛先ユーザー名、荷主の名前、宛先人への伝言、更新日時、荷扱人を表示します。

入力欄として、「荷物回収」ボタンだけを表示します。このボタンが押されたとき、リストのhasItem列を「いいえ」に変更します。


利用者に納品通知や回収の催促を送るためのPower Automateフロー

リストの変更があったときに動作するフローと、定時で動作するフローの2つを作ります。前者は荷物の預け入れと回収に関する通知、後者は回収の催促に使用します。

荷物の預け入れと回収に関する通知

「自動化されたクラウドフロー」をSharePointの「アイテムが作成または変更されたとき」トリガーで実行します。

トリガーからは、アイテムが変更された後の最新の情報がフローに渡されます。
リストのhasItem列が「はい」のときは荷物が預けられたことを意味します。このとき受取人に対して荷物が届いたので回収するように連絡します。また、荷物を預けたユーザー(配達人)には入力を受け付けた旨を通知します。
リストのhasItem列が「いいえ」のときは荷物が回収されたことを意味します。このとき受取人には入力が受け付けられたことを通知します。また、配達人には荷物が回収されたことを通知します。

回収の催促

「スケジュール済みクラウドフロー」を1日ごとに実行します。

宅配ロッカーリストをSharePointコネクタ複数の項目の取得ですべてのロッカーのデータを取得します。取得したデータに対して、Apply to eachで個々のロッカーごとのレコードを取り出します。ここでhasItem列がはいであれば荷物があることになりますから、hasItem列の値を条件に代入します。条件で比較するときに注意が必要なのが、hasItemと比較する対象は式エディタでtrueと入力するという点です。ベタ書きで「はい」や「true」と書いても一致判定してくれません。
hasItemtrueのときだけ、Teamsのチャットまたはチャネルでメッセージを投稿するアクションを使って、受取人にメッセージを送ります。


アプリ作成の詳細

道具

各保管スペース(ロッカー)の情報を配達員または利用者が書き換えるためのPower Appsアプリの作成詳細

画面遷移

アプリが読み込む情報によってユーザーに求める動作が変わります。そこで、まずは画面遷移の構成を考えます。

PowerAppsのアプリ起動時に表示する画面は、ツリービュー>画面>AppのStartScreenで設定できます。If関数を使って、アプリが読み込むデータに基づいて適切な画面を表示できるように設定します。

荷物がすでにロッカーに存在する場合は、荷物の回収動作をします。荷物がない場合は、荷物の預け入れ動作をします。これらはSharePointのリスト宅配ロッカーにある情報を読み込めばhasItem列の値で判定できます。
SharePointのリスト宅配ロッカーのID列の値をロッカー番号として使いクエリパラメータLockerID=#の形で与える場合、表示すべき画面の分岐は次のようになります。hasItem列がはいTrueの場合は荷物の回収動作いいえFalseの場合は荷物の預け入れ動作という名前の画面からアプリがスタートします

If(LookUp(宅配ロッカー,ID=Param("LockerID")).hasItem,
   荷物の回収動作,
   荷物の預け入れ動作
)

ここでもう一つ考えたいのが、エラー処理です。SharePointのリスト宅配ロッカーのデータがないLockerIDを指定されたり、そもそもLockerIDの値が与えられていない場合、アプリは正しい処理をできません。そのような場合、早めにユーザーへ警告したほうがよいでしょう。そこで、IsBlankOrError関数を使って、SharePointのリスト宅配ロッカーのデータを見つける動作を正常に行えなかった場合に失敗画面へ遷移するようにしておきます。

If(IsBlankOrError(LookUp(宅配ロッカー,ID=Param("LockerID"))),
    失敗画面, 
    If(LookUp(宅配ロッカー,ID=Param("LockerID")).hasItem,
        荷物の回収動作,
        荷物の預け入れ動作
    )
)

これでアプリ起動時の画面遷移ができました。ほかに後で出てくるデータ送信が成功したときのための成功画面も作っておくとよいでしょう。

荷物を預け入れる動作画面をつくる

まずは、荷物がない場合つまりhasItemが「いいえ」のときを考えます。これは新しく荷物を設置して、受取人に連絡する業務フローです。

「編集フォーム」コントロールを用意します。これをForm1と呼びます。Form1のデータは、SharePointのリストで作成した「宅配ロッカー」リストを使用します。Form1のプロパティ>データはDataSourceが「宅配ロッカー」、DefaultModeがFormMode.Editです。ここで編集対象のロッカー番号を指定して、指定したアイテムだけを編集したいと考えます。テキスト入力コントロールを挿入し、名称を「ロッカー番号入力」とします。ロッカー番号入力にロッカー番号を記入して、ロッカー番号がIDと一致するアイテムを編集対象とするには、Itemを以下のように書きます。
LookUp(宅配ロッカー,ID=Value(ロッカー番号入力.Text))
LookUp関数はデータテーブルから1個のレコードを抽出する関数です。第1引数はデータソース(リスト)の名前、第2引数は条件式です。ロッカー番号入力.Textでロッカー番号入力コントロールに記入された文字列を読み取ります。IDは数値なのでロッカー番号入力.Textを数値変換するようにValue関数にかけます。

ユーザーに手作業をさせると、必ずどこかで間違いが生じます。いまロッカー番号を手入力するような形で作りましたが、アプリ起動時のURLから自動的にロッカー番号を設定できるようにしましょう。画面遷移のパートで書いたように、Param関数を使ってURLから文字列を取り出すことができます。FormのItemを次のように記述すれば、Param関数から直接ロッカー番号LockerIDを読み出すことができます。

LookUp(宅配ロッカー,ID=Value(Param("LockerID")))

続いて、フォームで編集する項目を変えてみましょう。
Form1のプロパティ>フィールド>フィールドの編集で、編集対象とする項目を編集できるようにましょう。ここでは、Title, Receiver, hasItem, Sender, message, PostedByを編集対象に加えます。

まず、hasItemはユーザーが値を入れるのではなく状態に応じて「はい/いいえ」が適切に変化するようにします。いまは荷物がないとこりに荷物を設置する場合を考えているので、操作をしたあたはhasItemが「はい」になるようにします。
ツリービューからhasItem_DataCard1のプロパティを開き、詳細設定Defaulttrueにします。trueは「はい」を意味します。逆にfalseは「いいえ」です。また、ユーザーが操作できないないように非表示します。同じく詳細設定Visiblefalseに設定します。

次に、受取人Receiverを工夫します。
表示がReceiverだと英語がわからない人に通じないので、受取人と表示されるようにします。ReceiverのDataCardでDisplayNameを”受取人”にしておけば、ほかの部分も連動して変わります。

Receiverはリストに「個人」型を設定したので、PowerAppsのForm1でも対応するUser型のデータを扱います。いまReceiver_DataCard1の下にDataCardValue2がある状態を考えると、DataCardValue2には選択されているユーザーのDisplayNameが表示されます。したがって、DataCardValue2で選択されているユーザーUserはDataCardValue2.Selectedで参照できます。たとえばDataCardValue2.Selected.Emailとすれば、選択されているユーザーのメールアドレスを取得できます。これを応用して、選択されているユーザーの姓だけを取り出すことができます。
Office365ユーザー.UserProfileV2(DataCardValue2.Selected.Email).surname
DataCardKey2詳細設定Textを以下のようにすることで、「受取人: 佐藤様」のような表示にできます。
"受取人: "&Office365ユーザー.UserProfileV2(DataCardValue2.Selected.Email).surname&"様"
ちなみに、このように表示項目に関数を仕込む場合は、関数がエラーを吐く場合に備えてIsBlankOrError関数でエラー処理を組み込んでおくと良いです。

PostedByもアプリを開いたユーザーが指定すればいいだけなので、同様にVisibleをfalseにしておきます。次にDefaultをアクセスしているユーザーにしたいのですが、これが一筋縄に行きません。Power AppsからSharePointのリストに送信するデータの形式をSharePointのリストの個人型に合わせるため、フォームで送信する値を工夫する必要があります。解決方法はリンク先を参照してください。工夫が必要になる原因はPowerAppsとSharePointのリストでデータ形式が不一致を起こすためです。なんのためのローコードか。

アプリを開いているユーザーを指定する最小の設定では、PostedBy_DataCard1 > DataCardValueのDefaultSelectedItemsを以下のように記述します。

{
 Claims: "i:0#.f|membership|" & Lower(User().Email),
 DisplayName: User().FullName
}

最後に送信ボタンを設置しましょう。
「ボタン」コントロールを挿入します。詳細設定のデータ>Textには「荷物を登録」のような文言を記入します。このボタンで重要なのはアクション>OnSelectにフォーム送信アクションを設定することです。
SubmitForm(Form1)
Form1の内容がSharePointのリストに送信されます。

フォームの送信に成功したことがユーザーわかるようにするため、「正常に完了しました」とだけ表示する画面に遷移させます。フォーム送信時に画面を遷移させるには、Form1のプロパティ詳細設定のOnSuccessに以下のように記述します。ここで遷移先のスクリーン名を成功画面としています。
Navigate(成功画面)
一方で、OnFailureはfalseのままでよいです。入力必須の項目が未入力の場合に警告を表示するような動作はFormの方で勝手にやってくれるので。

成功画面は予め1枚のスクリーンとして作っておきます。PowerAppsの編集画面左上にある「新しい画面」から「成功」を選ぶとそれらしい画面が生成されます。

ここまででフォームの編集ができるようになりました。
次に考えたいのが、前のデータ残っている場合です。

ここで想定しているSharePointのリストのデータ設計では、ロッカー番号に1対1でレコードがあります。これのレコードを書き換え続けます。したがって、荷物を受け取り済みにしても、前の荷物の情報が残ります。こうしておくと、前の荷物に関するトラブルが生じたときに直前回の情報がすぐに手に入るのでトラブル解決に便利です。
一方で、新しく荷物を預け入れたいのに、編集フォームで前の荷物の情報が出てきてしまうと困ります。誤った情報の登録にもつながります。そこで、SharePointのリストから読み取った情報の一部を消してPower Apps上で表示します。

Receiver_DataCard1の詳細設定>データ>DefaultBlank関数を入れることで、入力フォームの値が入っていない状態にできます。入力フォームがBlankだとSubmitformが動作しないので、意図しない受取人を設定するミスを予防できます。

受取人はBlank関数を使えばいいのですが、荷主Sender, 伝言messageはこの方法が使えません。Sender, messageは入力必須でない項目なので、値がBlank()でもSubmitformできます。値がBlankのままSharePointのリストに送信された項目は、前の値が更新されずに残ります。受取人Receiverは入力必須なのでSubmitformが動かずこのようにはなりません。そこで、Sender, messageは明示的に空の文字列を与えてやる必要があります。Blank()の代わりに“”と書きます。

荷物を回収する動作画面をつくる

次に、荷物がない場合つまりhasItemが「はい」のときを考えます。荷物を回収する動作画面では、荷物の受取人をユーザーとして想定します。また、想定する動作は荷物を回収するのみです。

荷物を預け入れる動作の画面とほとんど同じように作れます。こういうときはツリービュー>荷物の預け入れ動作の三点ボタンから「画面の複製」を行うと楽です。各アイテムの名前の末尾に_1が付与されて画面ごとに名前が異なるように調整されることに注意して下さい。

ツリービューからhasItem_DataCard1_1のプロパティを開き、詳細設定Defaultfalseにします。falseは「いいえ」を意味します。

この画面でユーザーに期待するのは荷物の回収だけです。そこで、既存のデータを書き換えられないようにしておきます。
編集フォームコントロール自体に、動作を編集・新規投稿・ビュー(閲覧のみ)に設定できます。しかし、編集フォームコントロール全体の設定で動作モードをビューに設定してしまうと、SubmitFormでSharePointのリストを書き換える動作も封じられます。そこで、画面に表示されている各入力欄の設定を表示のみに書き換えます。
ツリービューを見るとForm配下の末端にDataCardValueという名前の付いた入力系コントロールがあります。これが入力欄です。これの詳細設定の一番下の方にDisplayModeというプロパティがあります。これをDisplayMode.Viewに設定すると、動作時に表示のみになります。


配布の準備

作成したアプリを業務で使えるようにしましょう。

「共有」から公開を行うと、Web リンクに次のようなURLが表示されます。これが作成したアプリへアクセスするためのURLです。
https://apps.powerapps.com/play/example?tenantId=example

今回作成したアプリは、URLからロッカー番号を指定できるようにしました。前述のURLの末尾に&でLockerID=#をつなぎます。#にはロッカー番号を入れます。

例:ロッカー番号51のとき
https://apps.powerapps.com/play/example?tenantId=example&LockerID=51

このURLをQRコードのして印刷し、ロッカーの現場に表示しておけば、利用者はスマホでQRコードを読み込むだけでアプリにアクセスできます。URLからQRコードを作るにはqrqrなどを使います。


本アプリの作成を通じて業務の自動化を体験するワークショップを開催する場合の進め方例

1回目
小包、郵便をオフィス内で分配する業務フローを書き出してみる。
業務フローの中で困っていること、面倒なこと、間違いが起こりやすいことを探す。
消費者として使用した宅配ロッカーの経験を基に、宅配ロッカーの業務フローを書き出してみる。
これらを踏まえて、最終的なワークフローを書く。

2回目
SharePointのリストにデータを格納する方法を考える。
まずExcelにデータを入れて、手作業ですべての操作をすることを考える。
どんな列にどんなデータが入ればいいかを考える。
業務フローをカバーできるExcelができたら、これを基にSharePointのリストを作成する。

3回目
SharePointのリストに対して、PowerAppsからデータを操作できるようにする。
PowerAppsの勉強の導入になるので時間をかけて、リード役が画面を見せながら説明する。

4回目
SharePointのリストに対して、Power Automateで連絡のフローを作成する。
「自動化されたクラウドフロー」を「SharePointのアイテムが作成または変更されたとき」トリガーで実行する。

5回目
サービス展開に必要な資料を作成する。
ユーザーへの説明書はもちろん施策の狙いをまとめた資料を作成する。
ユーザーへの説明書はできるだけ具体的でわかりやすくする。ユーザーの支持を得るため。
施策の狙いをまとめた資料は、現場の切なる問題の提示とともにDXのような今時でいい感じの雰囲気をちりばめる。このような活動に肯定的な感触を持ってもらい、今後も自由に活動しやすくするため。

まったくの初心者にローコード開発を体験してもらうワークショップ Power Automate & Power Apps

プログラミングをしたこともなければ、Excelの関数もほとんど使ったことがないという方にPower AutomateとPower Appsを使ったローコード開発を体験してもらうワークショップの構成案を紹介します。

まず簡単な自動化を体験します。徐々に条件を複雑にして、実用的なアプリを作れるようになります。

Power Automateでメールを送ってみよう

メールを送る動作を自動化します。普段行う作業が容易に自動化できることを経験します。

Power Automateで決まった時間にメールを送ってみよう

メールを送る動作を予定したタイミングで実行します。ひとたびフローをくみ上げれば実行タイミングを自由に設定できることを経験します。

Power Automateで複数の条件に合うときだけメールを送ってみよう

条件分岐を学びます。関数を書くよりも、フローの中で視覚的に学んだ方がわかりやすいでしょう。「13日の金曜日」のように複数の条件に合致するときだけ動作するようにフローを書き換えます。

Power AppsからPower Automateを呼び出してみよう

Power Appsでユーザーインターフェースの作り方を学びます。すでにPower Automateで複数種類のトリガーによってフローを実行できると学んでいるので、新しいトリガーとしてPower Appsから呼び出すトリガーを導入します。フロー自体はすでに作ったことのあるメールの送信が良いでしょう。

Excelで関数の動作を経験しよう

Power Appsで関数を使うため、ひとまずExcelに移ります。Excelでは+演算子(数値の和)、&演算子(文字結合)、IF関数(簡単な関数)、VLOOKUP関数(引数が多く複雑な関数)を使って、関数が動作する経験をつかみます。

Power AppsのParam関数でアプリ外から値を制御しよう

関数を使った処理を学びます。プログラミング経験がない方に便利かつ意外性のある関数として、URLのクエリパラメータを解析するParam関数を紹介します。Param関数によってクエリパラメータがアプリ内に反映されることを経験します。

新型リーフ (2017) のバッテリー劣化 – 納車から4年半

新型リーフ (2017) のバッテリー劣化 – 新車48か月点検(車検)を終えての続編です。2017年10月の納車から4年半が経過しました。

バッテリーの劣化はゆっくりと進行しているようですが、体感できるような違いにはなっていません。いまのペースだと5年目の車検の時点で走行距離が8万kmになりそうです。車検時点でも、おそらくセグ欠けまで行かないでしょう。バッテリー劣化で悪評を広めた初代リーフとは大違いです。

LeafSpyで取得したSOHの経時データ。2017年10月納車、走行距離は1,000-2,000 km/月、気候は関東山間部。

最近はガソリン価格が高騰しているので、EVの低燃費の恩恵を受けています。毎月の走行距離とガソリン価格、プリウス並みの燃費(23 km/L)から計算すると、この4年半で30万円程度の燃料費削減になりました。これは充電費用定額というZESP2が安すぎることが大きな要因ですので、ZESP3だったらここまで利得は大きくないでしょう。

Power Appsを使い始めるにあたって参考になるページ

Power Appsを使い始めるにあたって参考になるページをまとめる。

総論的

作例

Tips, リファレンス的

ノーコード・ローコード開発の考え方

東名高速道路鮎沢PA下りに急速充電器設置

東名高速の鮎沢パーキングエリア下り側にも急速充電器が設置されます。

これまで鮎沢PAは上り線だけ急速充電器が設置されていました。2022年2月現在まだ公式の発表は見つかりませんが、鮎沢PA下りには目隠しされた急速充電器の看板があり、充電器の設置工事も終わっているようでした。

充電器の前には充電マスが2台分、充電待機マスが1台分あります。

設置された充電器はABBのTerra 184です。充電ケーブルが2本、最大出力180 kWであり、2台同時に90 kWでの充電を行えるようです。ただし、最近同型とみられる急速充電器が56kWに出力を制限して運用されていることから、鮎沢PA下りも56kWで運用が始まる可能性が高いでしょう。

私の乗っている40kWhのリーフでは50kWまでしか対応していませんが、リーフe+なら70kW程度、アリアなら90kWに対応しているため、恩恵が大きいでしょう。


2022/3/21追記

東名本線上にあるEV QUICKの青看板から目隠しシールがはがされていたのでPAに入ったところ、使えるようになっていました。高速充電ナビや日産のアプリ、カーナビにも充電スポットとして表示されています。充電器の出力は各口56kWという表示でした。

ただし、使用状況は正確に共有されていないようです。リーフのカーナビ上はグレーアウトしており、利用状況を入手できない状態です。私が鮎沢で充電をはじめて、高速充電ナビでは使用中の表示にならず、2台空きのままでした。

リーフの車内では充電入力44kWでした。リーフへはだいたい充電器の出量の1割減の電力で充電されるので、充電器側は50kWで出力していたのだと推測しました。

Outlook予定表を大人数に共有する操作をPower Automate Desktopで実行する

Outlookの予定表を大人数で共有することを考えます。

Outlookの予定表は、共有したい相手をひとりひとり選択することで、各人の権限(表示のみか、編集もできるか)を分けながらカレンダーを共有できます。予定表を共有する相手が数人であれば、手作業で各人のアドレスを追加すればいいでしょう。これが数十人となった場合、手作業では時間がかかったり抜け漏れが生じたりします。

Microsoft365の自動化ツールといえばPower Automateです。しかし、クラウドフローのPower AutomateにはOutlookの予定表の共有に関するコネクタがありません。そこで、OutlookのデスクトップアプリをPower Automate Desktopを使って繰り返し処理する方法を考えます。

準備するものは3つです。

  • Power Automate Desktopのインストール
    windows10以降のユーザーであれば、無償でインストールできます。
  • 共有したいOutlookの予定表
  • 選択共有したい相手のメールアドレスの一覧

Excelファイルに選択共有したい相手のメールアドレスの一覧を入れたものを用意します。Power Automate Desktopから読み込める場所に置いておきます。

Outlookのデスクトップアプリを開いて、「共有アクセス許可」の画面を開きます。ここでは「追加した予定表」という名前の予定表を作成し、大人数に共有します。

Power Automate Desktopを起動して、「新しいフロー」を作成します。下図に示すようなフローをこれから作ります。このフローは大きく2段階に分かれます。前半(1,2,3)では、Excelファイルに記録した予定表の共有相手を一覧を取得します。後半(4,5,6,7,8)では、Outlookの予定表を共有する操作を前半で取得した共有相手一人一人に対して繰り返し処理します。

前半(1,2,3) Excelファイルに記録した予定表の共有相手を一覧を取得

フローの動作は画面左の「アクション」列から、Excelのグループを開きます。

「Excelの起動」では、予定表を共有する相手のメールアドレス一覧が入ったファイルのパスを指定します。

「Excelワークシートから読み取り」では、先ほど開いたExcelファイルの中身を読み取ります。冒頭で示したように各セルにメールアドレスが1個ずつ入っているだけのワークシートであれば、「ワークシートに含まれる使用可能なすべての値」を取得すればメールアドレスの一覧を読み込めます。

メールアドレスの一覧を取得したらExcelファイルは用済みです。後半の操作の邪魔にならないように閉じておきましょう。

後半(4,5,6,7,8) Outlookの予定表を共有する操作を前半で取得した共有相手一人一人に対して繰り返し処理

メールアドレスの一覧を取得したので、この中にあるメールアドレス1個1個に対して同じ処理を繰り返します。この場合は「ループ」から「For each」を選択します。

「For each」のパラメータ設定では、どのデータセットに対して繰り返し処理を行うかを指示します。入力欄の右端にある{x}を押すと、フローに登場する変数などの一覧が表示されます。Excelファイルから読みだしたデータを選択すれば%ExcelData%というテキストが設定されます。

あとは、Outlookでメールアドレスを指定して予定表を共有する操作を設定すれば完了です。フローにOutlookの起動からすべてを任せるのは面倒なので、人の手で繰り返し処理の直前の画面を表示させておきます。

ここでPower Automate DesktopにOutlookのどこを操作すればよいかを教えます。画面右端にある菱形が重なったアイコンを押して「UI要素」を表示します。青色の「UI要素の追加」ボタンを押すと、画面に映っているどの部分に着目するかを教える画面になります。

UI要素の追加を行っている最中は、注目している場所に赤枠が表示されます。狙いたい場所が赤枠で囲まれている状態になったら、Ctrlキーを押しながらクリックしてください。

Ctrlキーを押しながら、予定表の共有を操作を行う際にクリックしたりメールアドレスを入力したりする場所を登録していきます。予定表の共有を行うには、下図のように「追加」ボタンを押す、入力欄にメールアドレスを入力する、「OK」ボタンを押す、という操作が必要です。Outlookの操作画面とPower Automateで対応するフローを次に示します。

登録したUI要素は名前を変更することができます。画面右端の「UI要素」で登録したUI要素を選択し、「名前の変更」を選びます。これらのUI要素はフローを作っていく中で選択しますので、わかりやすい名前に変更しておきましょう。

Outlookのように別のアプリケーションを操作する場合は、「UIオートメーション」内のアクションを使用します。各アクションでは、どのUI要素を操作するのかを指定する必要があります。先述のように、操作が必要なUI要素を登録しておけば、プルダウンリストから選ぶだけです。

メールアドレスを入力する操作は「テキストフィールドに入力する」アクションを使用します。For eachループの中でメールアドレス一覧から取り出された1個ずつのメールアドレスは%CurrentItem%で読みだせます。これも{x}ボタンを押せば候補が選択肢に表示されます。

以上でフローは完成です。画面上部の実行ボタンを押して、フローを動作させてみましょう。作成したフローが正常に動作するのか確認するため、最初は少ない数のメールアドレスを使うことをお勧めします。作成したフローが意図したように動くのであれば、大規模なデータに対して本番処理を実行しましょう。

移動が多いオフィスに適したモニタ

移動が多いオフィスに適したモニタを紹介します。フリーアドレスのオフィスで自席がない場合や、在宅勤務の普及により会社のPCをオフィスと自宅で持ち運ぶ場合など、業務用のPCを携えて移動する頻度が高い働き方が近年増えています。

移動が多い場合に問題になるのが、PCの周辺機器をどのように持ち運ぶかです。特に、電源がなければPCは数時間で動かなくなるので、電源ケーブルの運搬は重要な課題です。

最近のノートPCではUSB Type-Cコネクタを使って充電する方式が増えてきました。これはUSB PD (Power Delivery)を利用したものです。もしUSB PDで十分に高い出力を備えたモニタを外部ディスプレイとして使えれば、電源ケーブルを持ち歩かなくても給電しながらPCを使えます。
USB PDにどれだけの出力が必要なのかは、使っているPCの仕様書や電源アダプタを確認してください。ノートパソコンであれば、たいてい45 Wくらいでしょう。ノートパソコン付属の電源アダプタが45 Wなのであれば、45 W以上に対応してUSB PDを備えるモニタを使用すれば大丈夫です。

価格comでUSB PDと映像入力USB Type-Cでモニタを検索すると100件以上の製品が該当します。24インチで2万円台の製品もあり、給電機能があるからといって驚くほど高価になるわけではありません。

私はDELLのU2721DEを在宅勤務のために購入しました。USB Type-Cで給電しながら映像の伝送ができるのに加えて、モニタ側に有線LANポートを備えており自宅でも高速かつ安定したインターネット接続が可能です。本記事の執筆時点で購入できる後継機はU2722DEです。

SharePointのリストに予め登録した時間帯と本文に応じてTeamsにボットからメッセージを送る

まとめ

SharePointのリストに投稿時間帯、投稿する本文を登録しておきます。PowerAutomateで1時間ごとに動作するクラウドフローを使い、リストの内容に応じたメッセージをTeamsに投稿します。

本記事の後半では、発展編として動作条件を複数にする場合や宛先を複数人にする場合を紹介します。

Google環境で同様の仕組みを作成する方法はリンク先をご覧ください。

前提とするリストの構造

以下のようなリストをSharePointに作成しておきます。投稿時間帯はhour列で指定します。

時間帯の判別をODataクエリで行う場合

時間帯の判別をSharePointのリストからアイテムを取得する段階で行います。この方法の利点は、リストから取得するアイテムの上限数制限に触れにくいこと、動作が高速であることです。

まず、現在時刻を取得し、時間の部分だけを抜き出します。

現在時刻の取得は、「組み込み」>「日時」にある「現在の時刻」と「タイムゾーンの変換」アクションを用います。現在時刻を協定世界時(UTC)で取得し、東京のタイムゾーンに変更します。「Recurrence」アクションの次に「現在の時刻」アクションを追加し、その次に「タイムゾーンの変換」アクションを追加してください。

次に、東京の現在時刻から、時間の部分だけ取り出します。「タイムゾーンの変換」アクションの後ろに、「組み込み」>「データ操作」にある「作成」アクションを追加してください。入力には式の入力画面に入ったあと次の式を入力してください。formatDataTime関数は、第1引数に現在時刻、第2引数に出力文字列の書式を設定します。次の式でbody(‘タイム_ゾーンの変換’)は東京の現在時刻、%Hは24時間表記での時間部分を示します。カスタム日時書式設定で時間はHで指定できますが、一文字だけで使う場合は%を頭に付ける必要があります。%がないとエラーを吐きます。

formatDateTime(body(‘タイム_ゾーンの変換’),’%H’)

この式の出力結果は0詰めなしの時間です。9時なら9、16時なら16が文字列として出力されます。

として入力できている場合、PowerAutomateのフロー上はfxと書かれたアイコンが表示されます。黒い文字だけなら単なる文字列として入力されていますので、式の入力画面から入力しなおしてください。

このあと複数の「作成」を用いる場合は、「作成」の名前を変更しておくと分かりやすいでしょう。アクションの名前を変更したい場合は、三点ボタンをクリックすると表示されるメニューから「名前の変更」を選択します。

時間の判定に使う文字列が用意できたので、次はSharePointのリストからデータを取得します。「標準」>「SharePoint」にある「複数の項目の取得」アクションを追加してください。

「サイトのアドレス」と「リスト名」は、ご自身で用意したリストを選択してください。次に、「詳細オプションを追加する」をクリックして詳細オプションを表示させます。詳細オプションの「フィルター クエリ」には「hour eq 出力」と入力します。ここで出力は前段のアクション「作成」の結果です。

ここまでの操作で、hour列の値が現在時刻の時間(hour)と一致するデータを取り出しました。この後は取り出して複数の項目に対して、それぞれTeamsにメッセージを送る処理を行います。

「アクションを追加」で「コントロール」>「Apply To Each」を挿入します。「以前の手順から出力を選択」にはvalueを選択します。

「Apply To Each」で実行するアクションを追加します。「標準」>「Microsoft Teams」>「チャットまたはチャンネルでメッセージを投稿する」を選択してください。どこにメッセージを投稿するのかを設定する画面が表示されます。ここでは仮にボットとのチャットに投稿する場合の設定例を示します。

*投稿者 フロー ボット
*投稿先 Chat with Flow bot
*Recipient ここに受信者のメールアドレスを設定します。読み込むリストに受信者を設定する列を用意しておけば、ここを動的な値にすることができます。
*Message
「動的なコンテンツを追加」からSharePoint複数の項目を取得の下にあるMessageを選択します。Messageの前後に文字列を追加しても結構です。

以上で設定は完了です。フローを保存して、テストしてみましょう。

時間帯の判別をPowerAutomateの条件判定で行う場合

SharePointのリストからすべてのデータを取得した上で、PowerAutomateの「コントロール」>「条件」で処理すべき項目か否かを判定します。

「Apply To Each」のループの中に、「作成」で条件判定に使う文字列を作ってみましょう。ここで注意が必要なのは、型を文字列に揃える必要がある点です。hour列の値は数値型、日時を変換して出てくる出力は文字列型です。hour列の値をstring()関数に入れて文字列に変換するなどの方法があります。

ここでは、hour列に合わせて時の文字列だけを取り出す方法と、年月日に合わせて文字列を成形する方法を示します。

時の文字列のみを作る場合

string(items(‘Apply_to_each’)?[‘hour’])

次の値に等しい

formatDateTime(body(‘タイム_ゾーンの変換’),’%H’)

年月日時という文字列を作る場合

concat(formatDateTime(body(‘現在の時刻’),’yyyy-mm-dd-‘),items(‘Apply_to_each’)?[‘hour’])

次の値に等しい

formatDateTime(body(‘タイム_ゾーンの変換’),’yyyy-mm-dd-H’)


発展編

ここからは、少々複雑な処理を行って機能を追加していきます。

発展編1 TeamsのチャットではなくOutlookでメールを送る

Teamsのチャットではなく、Outlookのメールでメッセージを送ることを考えます。方法は簡単です。コネクタをTeamsではなくOutlookにするだけです。

もちろん宛先に動的なコンテンツを入力することもできます。

発展編2 時間と曜日、日付に応じて動作するようにする

SharePointのリストから複数の項目を取得する際のクエリを変更して、曜日と日付も条件と合うようにします。

リスト側の操作で、列を追加します。

曜日(内部名Day)は漢字一文字(月,火,水,木,金,土,日)で表現することにします。選択肢でも一行テキストでも結構です。選択肢にする場合は、平日を意味する「月火水木金」だとかすべての曜日を意味する「月火水木金土日」といった選択肢を用意しておくとユーザーに便利です。

日付(内部名Date)は単純に数値型でよいのですが、日付は1~31までしかないので小数点以下0桁の最小値1、最大値31などと制限をかけておくと入力ミスを減らせます。工夫として、日付に関係なく動作させたい場合に備えて、日付が0のときにも動作させることを考えます。このため、最小値を1でなく0としておきましょう。

ここまでの操作で次のようなリストが得られました。

「組み込み」>「データ操作」にある「作成」アクションを使って、クエリに使う曜日と日付を作成しましょう。なお、以下では東京のタイムゾーンに変換した後の時刻をbody(‘タイム_ゾーンの変換’)と書きますが、式で書かずにタイムゾーンの変換結果を置いても結構です。

曜日は漢字一文字(月,火,水,木,金,土,日)で表現することにします。現在時刻を入力すると、対応する曜日の漢字一文字が出力される式はリンク先を参照しました。次の式の結果を後で曜日と書きます。

createArray(‘日’,’月’,’火’,’水’,’木’,’金’,’土’)[dayOfWeek(body(‘タイム_ゾーンの変換’))]

日付は時間hourと同じようにカスタム日時書式設定を使います。月の日にちはdの一文字ですから、Hと同様に%を入れて次のように書けます。次の式の結果を後で日付と書きます。

formatDateTime(body(‘タイム_ゾーンの変換’),’%d’)

本ページの前半で説明したの詳細は省きますが、時間帯hourを同様に時間帯と書くことにします。

リストに記録されたアイテムのうち、動作条件として入力した時間帯曜日日付の3つが現在時刻と一致するものだけを取り出すクエリは次のように書けます。

(hour eq 時間帯) and substringof(‘曜日‘, Day) and (Date eq 日付)

ここで曜日の判定だけはsubstringof(‘検査値’, 列名)関数を使用しました。検査値は曜日漢字一文字なので、リストの値が’月’のときも’月火水木金’のときも条件を満たす(Trueが返る)ようになります。また、曜日を一行テキストでなく選択肢にした場合もsubstringof()を使用してください。選択肢の場合、リストには単純な文字列ではなくJSONの形式で値が記録されています。したがって、曜日の漢字一文字と同値判定されません。ちなみに、選択肢としてDay列を作ると動的なコンテンツにはDayとDay Valueという2つのアイコンが表示されます。Dayは選択肢オブジェクト、Day Valueは選択肢の値を返します。検査値は文字列として扱うため、シングルクォーテーション”で囲むことを忘れないでください。

ここでさらに一工夫です。リストにDate列を追加する際に、日付に関係なく動作させたい場合はDateを0にするように考えました。SharePointのリストから複数の項目を取得する際のクエリとしては、「Dateの値が現在の日付と等しい、またはDateの値が0」と各必要があります。またはを表すのはorですので、クエリを以下のように書きなおします。

(hour eq 時間帯) and substringof(‘曜日‘, Day) and (Date eq 日付 or Date eq 0)

なお、時間帯がどの値でも実行するようにしたい場合は、時間帯に-1を入れるといった運用が考えられます。日付と同じ考え方であって、わかりやすい値で存在しない値を用いるという意味です。

これでフローの修正は完了です。Apply To Eachの中の処理は本ページの前半で解説した内容と変わりません。

発展編3 宛先を複数人にする

宛先を複数人にするのは少々手間がかかります。

まず、TeamsまたはOutlookコネクタに対して、どのような形式で宛先を入力すべきか考えましょう。

Teamsのボットチャットの場合はボット対1人の関係です。したがって、複数人に同じメッセージを送るには、人数分だけ繰り返し処理を宛先だけ変えて実行します。ApplyToEachで繰り返し処理するには、Arrayの中に宛先のメールアドレスが入っている形が良いでしょう。

Outlookのメールの宛先を複数人にするには、メールアドレスをセミコロン;で区切った文字列を宛先に入力することになります。そのものズバリの記事を他サイトで見つけたので、こちらを参照してください。技術的なポイントとしては、文字列変数にApplyToEachのループ処理でメールアドレスを追記していく形です。

コネクタに入力すべき値が見えてきたので、欲しい値を出力するにはどうするか考えます。リストにメールアドレスが文字列をとして入っている場合は、そのまま値を使えばいいので詳細は省きます。ここでは、リストに「個人」型かつ複数人を設定する場合を紹介します。内部名MessageToの列を以下の設定で作成します。

この列の値は、組織のユーザーデータベースから個人を指定できます。たとえば、会社のアカウントであれば同じ会社の個人のアカウントを入力できます。このアカウントはオブジェクト型なので、扱いには一工夫が必要です。

列の設定で複数の選択が許可されている場合、値は配列[]型です。配列の要素として、各個人の情報を示すオブジェクト{user#}が入っています。
[{user1}, {user2}, … , {userN}]
各人のアカウントを指すオブジェクトの中には、DisplayNameやEmailといったプロパティがあります。いま欲しいのはこのEmailだけです。Emailの取り出し方を考えてみましょう。

まず宛先の情報が含まれているMassageToの中身を確認します。仮の操作として、ApplyToEachのループの中に「組み込み」>「データ操作」>「作成」アクションを追加します。入力にはMassageToを置きます。

これで実行結果を確認してみると次の図のようになります。

このような複雑な値をPowerAutomateは自動で処理できません。そこで、「組み込み」>「データ操作」>「JSONの解析」アクションを使用します。上図の「未加工出力の表示」を開き、結果をコピーしておいてください。「JSONの解析」アクションを追加し、コンテンツにMessageToを選びます。次に、「サンプルから生成」を開き、先ほどコピーした「未加工出力の表示」の中身をすべてコピペします。こうすることで、PowerAutomateがJSONの構造を解析してくれます。「JSONの解析」アクションのスキーマを設定できたら、先ほどMessageToの中身を確認するために追加した「作成」アクションは削除してかまいません。

JSONの解析を行うと、MessageToの内部の情報、たとえばEmailを取り出せるようになります。JSONの解析のあとにアクションを追加すると、動的なコンテンツの中に次のような選択肢が出現することに気づきます。この中のEmailをTeamコネクタに入力すればよいわけです。

JSONの解析について詳しく学びたい方はリンク先の記事をご覧ください。

先述のように、複数の選択が許可された列の値は配列です。配列に対してはApplyToEachで配列内の各要素に対して処理を行います。「チャットまたはチャンネルでメッセージを投稿する」アクションのRecipient (宛先)にEmailを設定した場合、Emailは配列内の要素ですから、自動的にApplyToEachが追加されループの中にTeamsコネクタが移動します。ちなみに、ここで表示されているvalueはSharePointのリストから取得した各アイテムが要素である配列、本文はMessageToをJSONの解析した結果の配列です。

Teamsコネクタの場合は以上でフローが完成です。Outlookの場合は、最後に出てきた動的なコンテンツEmailを使って宛先文字列(メールアドレスが;で区切られている)を作成してください。

[PowerApps] スマホでPowerAppsを使う

PowerAppsで作成したアプリをスマートフォンで使用する場合の注意点をまとめます。

Power Apps Mobile の概要
iPhoneやiPadといったiOS端末であれ、Android端末であれ、モバイル環境でもPowerAppsで作成したアプリを動作させることはできます。ただし、一部の機能が制限される場合があります。
Power Apps Mobileアプリをスマホにインストールして、Power Apps Mobileアプリ上で各自作アプリを動作させる場合は支障がないかもしれません。一方で、Power Apps Mobileアプリをインストールせず、ブラウザアプリ上でPowerAppsのアプリを動作させる場合は、いくつかの制限が生じます。

アプリを Web ブラウザーで実行する
Edgeなどのブラウザアプリ上でPowerAppsを実行する場合は、次のような制約があります。

  • 一部のコントロールを使用できない。Barcode scannerなど。
  • プッシュ通知を使用できない。
  • モデル駆動型アプリが使用できない。キャンバスアプリのみ実行可能。
  • アプリを開く前に、Power Apps Mobileアプリをインストールするように勧めるページにリダイレクトされる。
    このリダイレクトを実行させないためには、作成したアプリを配布する際に、アプリのWEBリンク(後述)末尾に次の文字列を追加します。
    &skipMobileRedirect=1
    ただし、この文字列があるとPowerAppsモバイルアプリで開こうとする際にエラーが発生することがあります。
リンク先の「スマートフォン上の Web ブラウザーを利用してモバイル駆動型アプリを実行することはできません。Power Apps Mobile アプリを使用する必要があります。」は誤訳です。「モバイル駆動アプリ」と表記されている部分は「モデル駆動型アプリ」が正しい訳です。意味不明な表現がある場合は英語版を参照しましょう。ほかにも「Windows」が「窓」と表記されているのに気づくでしょう。

作成したアプリを配布する際には、PowerAppsでアプリの「共有」メニューから共有する相手を指定して共有するか、「詳細」画面に記載されているWEBリンクを共有します。もし実行権限を付与していないユーザーからWEBリンクのURLにアクセスがあった場合は、アプリの作成者に対して権限をリクエストする画面になります。

PowerAppsのメニュー
WebリンクのURL表示例

さいきょうの装置予約表

Microsoft365環境を前提として、共同利用する装置の予約システムの在り方を考える。

大学や研究所には、多種多様な共用装置がある。これらは予約表のような形で誰がいつ使用するのかを管理している。予約表は、装置の脇置かれたノートであったり、ホワイドボードに書かれた表であったり、あるいは共有ファイルサーバー上に置かれたExcelファイルであったりする。

装置管理の技術職員がいるような恵まれた環境でもない限り、予約表の管理は装置管理も含めた雑用のひとつとして装置利用者にのしかかる。たいていの場合、更新が必要な要素(毎年カレンダーを更新するだとか)は面倒なので誰もやらずに放置されて、我慢できなくなった誰かが更新するか、機能を喪失するかを待つ。デジタルだなんだという時代にあさましいこことだ。最新のデジタル技術を使って、いい感じの装置予約表を作れないものか。

どうせ作るなら、装置管理に必要な機能をひとまとめにしたものを作りたい。装置管理に必要な機能とは何だろうか?私の考える必要な要素は以下の通りである。各項目をMicrosoft365環境で実現できるサービスを併記する。

  • 装置の使用予定を確認、追加、編集、削除できる。
    Exchange Onlineで装置のメールアドレスを作ることで、会議室と同様に設備の予約ができる。
    参考 第30回 会議室や備品予約を簡単にする
  • 装置利用者向けの資料を閲覧できる。
    SharePointのニュースやページ、あるいはドキュメントを共有する形で資料を提示できる。
  • 装置利用者間の情報伝達手段が備わっている。
    Teamsのチャンネル機能またはグループチャットを使えば、装置利用者全員での情報共有が可能である。異常を装置管理者に報告するだけであればFormsでも良い。

ここからは各機能の果たす役割と実現にあたっての注意したい点を述べる。

装置の使用予定を確認、追加、編集、削除できる。

装置予約表としての基本機能。この機能が使いにくかったら利用してもらえない。
PCとスマートフォンの両方からアクセスできることが望ましい。通常の業務の中では常務用PCから装置予約表にアクセスできればいいが、装置の目の前にいるときにはその場でより簡便な手段を取りたい。装置の制御PCはインターネットに接続していないケースも少なくないので、スマートフォンから予約表にアクセスしたい。装置を使っていて使用を延長したり中止したりすので、予約を閲覧できるだけなく、編集機能も使えてほしい。

装置の予約状況は一目でわかるようにしたい。カレンダーアプリのような視覚的効果を使う。

これらの希望を満たすようなアプリをPowerAppsで開発すればよい。PC向けとスマホ向けで画面の広さが異なるので、それぞれアプリを作って動作とデータベースを共通化しておくとよいだろう。

装置予約表アプリは、各装置ごとに作るのではなく、装置ごとにIDを振ってどの装置にも簡便に装置予約表を追加できるようにする。アプリを作るような面倒なことはなるべく一回にして、利用者の為は極力なくす。ばらばらに低レベルのものを作るより、ひとつの一般化された高レベルのアプリを作る方がいい。

装置予約表を起点として、後述する資料提供機能と連絡手段にもアクセスできるようにする。

装置利用者向けの資料を閲覧できる。

利用者と管理者に必要な情報をそれぞれ蓄積し、必要な場面ですぐに閲覧できるようにする。

利用者向けの情報として、装置の使い方や注意点、ノウハウなどの情報を一元的に提供する。SharePointのページでもいいし、Wordファイルを共有してもいい。マニュアルのような資料が紙に印刷されて装置横に置かれている場合がよくある。紙だと修正や追加の度に印刷しなおすのが手間なので、いっそのこと電子的に共有して必要があればすぐに修正できる方が良い。装置管理者以外の利用者が多い場合には、管理者も知らないところでうまいやり方が編み出されていたり、熟練ユーザーには当たり前の注意点を初心者ユーザーがすっ飛ばして問題を起こしたりする。伝えるべきことを口頭ですべて伝えるのは無理があるので、これだけ見ればいい、ここを探せばいいという資料を用意して、それを利用者全員で優れたものにしていく取り組みが効果的である。

また、取扱説明書に書かれているような細かいスペック、パラメータの意味なども、業務に必要な情報を抜粋しておくと良い。その装置で実行できる限界の仕事を見積もったり、報告書をまとめたりする際に役に立つ。

管理者向けに必要な情報としては、メンテナンスや将来の装置更新に必要な情報を蓄積する機能を提供する。消耗品の交換や小規模な修繕は毎年のように発生するため、都度価格を調べて購買の稟議を通すのは面倒かつ時間がかかる。過去の支出情報を蓄積していけば、予算立案時にも適切な提案が可能になる。

将来の装置更新に必要な情報として忘れがちなのが、利用実績の把握である。どこの誰がどのような目的で装置を使用したのかを数年分蓄積するだけで装置更新時の費用対効果の見積もりが簡単になる。どこの誰がどれだけ装置を使ったのかは予約表または使用記録からわかるので、どのような目的で使用したかを予約表ないし使用記録に書き込ませると良い。

装置利用者間の情報伝達手段が備わっている。

利用者の多い装置では、利用者全員に対して簡便に連絡できる手段が求められる。Teamsのグループチャットやチャンネル(あるいはタグ)機能を使うと良い。

企業であれば部課単位、大学であれば研究室単位で縦割りの壁がある。同じ装置を使っている者同士であっても、不具合の報告ですら縦割りの壁に阻まれる。ちょっとおかしいかもしれないという利用者の声を吸い上げることが装置を健全に保つのに有効なのは言うまでもない。逆に、使い方の工夫をしたという有益な情報も同じように流通しにくい。これらは技術というよりコミュニケーションの課題であるから、コミュニケーションを促進するツールがあれば解決できる。コミュニケーションが促進された結果として、大きな技術的問題を回避できる。

なんでも報告できるようにするには、コミュニケーションツールそのものだけでなく運用も大事だ。ごくまれにしか使われないチャットに投稿するのは勇気がいるし、返信がもらえるか不安になる。装置管理者が積極的にツールを使うことで、過疎らせない、質問してよい不具合報告しても怒られない雰囲気を作るのもツールと同様に重視すべきである。

装置管理者の立場では、この装置予約表システムの導入時だとか、一斉に複数人が利用を開始するときに、一人一人のユーザーを利用者登録するのは面倒である。そこで、Excelなどで作成したリストを基に、PowerAutomateでグループチャットなりチームにユーザーを追加する機能が欲しいところだ。反対に、ユーザーの削除は複数人を一気に操作するケースは少ないだろうから、ユーザーの自動削除機能は優先度が低い。

むすび

すべてが紙の時代においては、装置脇に置かれた紙のノートが前述の3つの機能を網羅することができた。デジタル技術では、すべての自分で作るあげるのではなく、既存のサービスを組み合わせてやりたことを実現する場合が多い。私たちが「装置予約表」と呼んでいたものは単なる予約表ではなく、利用者間のコミュニケーションツールとしての側面を持っていたことに自覚的になることで、予約表以外の適切なサービスを組み合わせて、デジタル時代における「さいきょうの装置予約表」を構築できるだろう。