1.1　背景と環境

　元々、ガチガチのセキュリティで自社開発アプリしか動かせないような職場だったのですが、昨年会社の吸収合併がありまして、筆者のいる部署はMicrosoft 365をバリバリ使っている部署に編入することになりました。定型業務の少ない職場であったため、これまで自動化等はあまり取り組んでおらず、Power Automateが使えるようになったものの、その存在を知ってる人はほとんどいない状況でした。社内的に「Power Automateを使ってもいい」というところは確認済だったのと、併せて部署内でDX推進チームができ、そこに入れて頂けることとなったので、部署内へのPower Automateの推進を実施してみました。

　Power Automateの推進にあたり、部署内でのハンズオン勉強会を開催することとなり、開催に向けて以下の点を気を付けてやってみました。

　・実際に利用してもらえるフローを作ること

　・実際に手を動かして作ってもらうために、簡単なフローにすること

　・ハンズオンをきっかけに「こうすればいいのか！」を気づいてもらうこと

　つまり、「Power Automate簡単じゃん！これなら俺でもできるよ！！」

　と思ってもらうことを第一とし、ハンズオン勉強会終了後も自分たちで「やってみよう！」と思えるような仕掛けをしてみました。

1.2　STEP0 ハンズオン勉強会のポイント

　実際のハンズオンに入る前に、ハンズオン勉強会の方向性を決めます。前項でも述べたように、今回はハンズオン勉強会終了後でも自分たちで「やってみよう！」と自ら動くことができる（以下、自走と表現します）ようにすることを目的としています。ここで、ハンズオン勉強会参加者が自走するためのポイントをいくつかあげたいと思います。

　・スタートでつまづかない

　・感覚で理解できる

　・「ここをこうしたい」と思ってもらう

1.2.1　ポイント：スタートでつまづかない

　「やろう！」と思った瞬間に、開発環境が立ち上がることが大事です。開発環境の構築方法がわからない、開発環境をどこからどう開けばいいのかわからない、開発環境の操作方法がわからない、せっかくやる気があってもこれでは熱も冷めてしまいます。Power Automateの場合、開発環境はPower Automateのサイトになるのですが、Microsoft 365のポータルサイトにさえログインしてしまえば、後は簡単にアクセスできます。ただし、そのアクセス方法はしっかり丁寧に説明します。

　説明する側は知っているから「当たり前」と感じていることも、触ったことのない人にとっては当たり前ではありません。ですので、専門用語等はできるだけ使わず、また必要であれば都度説明をしながら進めていきましょう。特に口頭だけではなく、画面キャプチャ等を使い実際に目で確認しながら説明していくことが大切です。また、後からハンズオン勉強会の参加者の方が「あれ？どうやって操作するんだっけ？」とならないように証跡（資料やアーカイブ動画）は残し、共有しておきましょう。

1.2.2　ポイント：感覚で理解できる

　Power Automateでも、ループ処理や条件分岐等は、少しロジカルに考える必要があります。たとえばハンズオン勉強会の初回で、いきなりループ処理や条件分岐の説明をしてもプログラミング経験のない人には難しい話になります。ですから、Power Automateのハンズオン勉強会を実施するなら、まずはトリガーとアクションがそれぞれひとつずつ程度、全2ステップの簡単なフローが望ましいと考えています。

　Power Automate以外のハンズオン勉強会を実施する場合でも、できるだけステップ数の少ないフローがいいでしょう。ステップ数が少ないフローなので説明も簡単ですし、理解もされやすいです。ただ、2ステップしかないので、少し機能面で物足りないところがあると思いますが、そこが「肝」なのです。

　また、簡単にフローの説明ができるため、そもそものPower Automateとは？という説明に時間を割くこともできます。筆者は、Power Automateの説明を30分、フローのハンズオン勉強会を30分、フリーの質疑応答を30分として実施しました。最後のフリーの質疑応答は必要な人のみですから、実施は1時間で終了しています。

1.2.3　ポイント：「ここをこうしたい」と思ってもらう

　先ほど、機能面で物足りないところがある、という話をしました。2ステップでもやりたいことはできるのですが、実際に動かしてみると「もうちょっとこうしたい」「ココの動きは、こっちの方が……」と感じてくれる人が必ず何割かは出てきます。これがハンズオン勉強会における、最大のポイントだと思っています。

　・「機能面で物足りないフローをハンズオンする」

　こうすることで、「こうするにはどうしたらいい？」と聞きに来てくれる人がいます。なかには自分で調べて実装してくれる人もいます。彼らはハンズオン勉強会を通じて、物足りなかったところを「自走」してくれる人たちです。

　ハンズオン勉強会はやってみたものの、なかなか現場に定着しないことがよくあると聞きます。「自分たちにはどうせできない」「どうせわからない」と最初からあきらめモードで参加される方もいるでしょうし、真剣に聞いてるものの、内容が難しくついてこれない方もいると思います。しかし、こうして簡単なところからスタートし、少し物足りなさの残るフローを一緒に作ることで、自走してくれる人が必ず現れます。その自走してくれる人を少しずつ増やしていくことで確実に定着化に向かっていき、定着化することで部署や会社の生産性向上に繋がっていきます。

　では、実際どのようなフローがいいのでしょうか？次の章から、実際にハンズオン勉強会で使ったフローを用いて解説していきます。

1.3　STEP1 OutlookからTeamsへの通知

1.3.1　OutlookからTeamsへの通知 - フローの説明

　合併する前もメールはOutlookを使っていたのですが、スケジューラは社内独自のシステムを使っていました。これまではスケジュールが登録されると、確認するまでは登録通知が継続的に届く仕組みだったのですが、Outlookでは通知は一度来るだけです。もちろん、スケジュール自体も登録されているしメール通知もありますが、今までの仕組みに慣れた身には少し物足りませんでした（見逃すことがありました）。

　そこで、Power Automateを使って、スケジュールが登録されたらTeamsに通知が来るフローをハンズオン勉強会で一緒に作ることにしました。実際のフローはこちらになります。

　トリガーひとつとアクションふたつ、計3ステップのフローになります。これなら説明も簡単ですし、実際のハンズオンに入る前にPower Automateって何？という説明を入れても1時間で終えられます。

1.3.2　OutlookからTeamsへの通知 - 自走した人

　もともとこのフローは、ある機能を削って提示しています。トリガーが「新しいイベントが作成されたとき」ですので、自分が登録したスケジュール（イベント）も通知が来てしまいます。実際に使ってみると、"自分が登録したスケジュールの通知"が思いのほかうっとうしいのです。ですから、筆者が実際に使っているフローは、条件分岐を入れて筆者以外が登録した際に処理する仕組みになっています。機能を削って提示したのは、先に説明したように、説明を簡単にして参加者の理解を進めるためです。

　また、もうひとつの理由としては、この理由に気づいて提示したフローを改修してくれる人が出てきてくれるのを期待しているからです。先に説明した「『ここをこうしたい』と思ってもらう」をあえて実践するために仕込んだ、ブービートラップみたいなものですね。

　実際、ハンズオン勉強会終了後に「自分が登録したスケジュールは通知しないようにするにはどうしたらいいですか？」と聞いてくれる人が何人かいて、「シメシメ」と思ったものです（笑）。

　また、社内では以前からSlackも使っており、通知をSlackへできないか試してくれた人もいました。結果的には社内セキュリティ的にAPIをふさがれていたようでうまくいかなかったのですが、筆者の想像以上に自走してくれた人が多く、うれしかったです。他にも「メールで通知したい」なんて声も上がりまして、こうやればできますよ、という話もさせて頂きました。

1.4　STEP2 一日の予定をTeamsChatに表示

1.4.1　一日の予定をTeamsChatに表示 - フローの説明

　仕事で朝礼をされている方、どの程度いらっしゃるでしょうか？筆者の所属している部署は、基本在宅なのですが毎日Teamsを使って朝礼があり、一日の作業予定を共有しています。朝礼は「時間の無駄」なんて風潮もありますが、一緒に仕事をする仲間と顔を合わせて打ち合わせするのは、個人的には大切かなと思っています。

　さて、その朝礼で作業予定を共有するのですが、共有するにはOutlookを開かないと見られません。Teamsはパソコン起動と同時に立ち上がるのですが、Outlookは手動で立ち上げが必要です（もちろん、自動起動させる手段はあるにしても）。そうなると、Teams上で一日の予定が見られると、朝礼の際にOutlookが立ち上がってなくてもスケジュールの確認ができます。

　なら、作ってしまえ！で、作ったフローがこちらのフローになります。

　全体フローとしては、このような形になります。今日の日付を変数strTodayに取得後、今日の予定を「今日のイベントの取得」で取得してきます。取得した予定は、配列変数に格納されるので、「取得したイベントの数だけループ」にて配列を回して全件を処理します。ループ内では1件づつ予定を取得し、JSON配列に形式を整えながら格納し、最後にHTML形式に変換した後にチャットに投稿するようにしています。

リスト1.1: STEP2-フローの補足説明①

 1:    addHours(utcNow(),9,'yyyy-MM-dd')

リスト1.2: STEP2-フローの補足説明② フィルタークエリ

 1:    Start/DateTime ge '@{addHours(variables('strToday'),-9)}' and
   2:        Start/dateTime lt '@{addHours(addDays(variables('strToday'),1),-9)}'

リスト1.3: STEP2-フローの補足説明② 並び替え

 1:    start/dateTime asc

リスト1.4: STEP2-フローの補足説明③

 1:    {
   2:       "件名": @{items('取得したイベントの数だけループ')?['subject']},
   3:       "開始時刻": @{addHours(variables('strStartTime'), 9, 'HH:mm')},
   4:       "終了時刻": @{addHours(variables('strEndTime'), 9, 'HH:mm')}
   5:    }

　STEP1のフローと比べるとかなりステップ数も多く複雑ではあり、さらにループや配列等のアルゴリズムの基礎的な要素も含まれています。ループとは？配列とは？というアルゴリズムの基礎的なお話もしつつ、こちらをSTEP2のフローとしてハンズオン勉強会を開催致しました。

　また、ループや配列については、以前「ハジメの一歩会」というプログラミング勉強会を開催しており、その記事をnote(²)にまとめてありますので、よかったら参照してみてください。

1.4.2　一日の予定をTeamsChatに表示 - 自走した人

　STEP1では、通知先をTeamsにしていましたので、今回も通知先はTeamsに設定しました。通知方法は、STEP1のときと変更しておらず、前回の復習にもなっています。ただ、Teamsへの通知だけでは使いにくいところもありました。

　社内ではスマホへのMicrosoft 365のインストールは原則禁止されております。そのため、スマホではTeamsが見られず、もちろんOutlookもスマホでは利用できません。そうなるとTeamsに通知よりも、メールで通知してほしいと考える人が出てきます。もちろん、これも狙ってました！（笑）

　ということで、最後のTeams通知に加え、メール送信を実装してくれる方もいらっしゃいました。

1.5　STEP3 一日の予定をiCalendar形式のファイルに出力

1.5.1　一日の予定をiCalendar形式のファイルに出力 - フローの説明

　STEP2では、一日のスケジュールをTeamsに投稿するフローを作成しました。今はスケジュール管理はOutlook一本になったのですが、合併後しばらくの間はスケジュールをOutlookとこれまで使っていたスケジューラのふたつを使わなければならない平行運用期間がありました。そうなると、Outlookとこれまでのスケジューラの2か所にスケジュール登録の必要性がでてきてしまい、2重登録が発生してしまいコレが本当に面倒でした。

　これまで使っていたスケジューラの機能を調べていたところ、iCalendar形式のスケジュールは取り込みができることがわかりました。よって、ハンズオン勉強会STEP3はSTEP2で作ったフローをベースに、Outlookに登録されたスケジューラをiCalendar形式で出力するフローを実施してみました。ただし、出力項目は最小限にしています。理由はもちろん、自走してくれる人が現れるのを期待してのことです。

iCalendar形式とは

　PIMソフトなどで使われるスケジュールの標準フォーマットです。RFC5545で規定されていることもあって、多くの製品に実装、サポートされており、任意のソフトウェア間でカレンダー情報を共有する際に用いられる共通フォーマットです。

リスト1.5: STEP3-フローの補足説明①

 1:    addHours(utcNow(),9,'yyyy-MM-dd')

リスト1.6: STEP3-フローの補足説明② フィルタークエリ

 1:    Start/DateTime ge '@{addHours(variables('strToday'),-9)}' and
   2:    Start/dateTime lt '@{addHours(addDays(variables('strToday'),1),-9)}'

リスト1.7: STEP3-フローの補足説明② 並び替え

 1:    start/dateTime asc

リスト1.8: STEP3-フローの補足説明③

 1:    BEGIN:VCALENDAR
   2:    VERSION:2.0
   3:    CALSCALE:GREGORIAN
   4:    BEGIN:VTIMEZONE
   5:    TZID:Asia/Tokyo
   6:    TZURL:http://tzurl.org/zoneinfo-outlook/Asia/Tokyo
   7:    X-LIC-LOCATION:Asia/Tokyo
   8:    BEGIN:STANDARD
   9:    TZOFFSETFROM:+0900
  10:    TZOFFSETTO:+0900
  11:    TZNAME:JST
  12:    DTSTART:19700101T000000
  13:    END:STANDARD
  14:    END:VTIMEZONE
  15:    BEGIN:VEVENT
  16:    DTSTAMP:20200106T053007Z
  17:    DTSTART;TZID=Asia/Tokyo:@{addHours(variables('strStartTime'),0,
  18:                                                    'yyyyMMddTHHmmssZ')}
  19:    DTEND;TZID=Asia/Tokyo:@{addHours(variables('strEndTime'),0,
  20:                                                    'yyyyMMddTHHmmssZ')}
  21:    SUMMARY:@{items('取得したイベントの数だけループ')?['subject']}
  22:    DESCRIPTION:@{items('取得したイベントの数だけループ')?['body']}
  23:    LOCATION:@{items('取得したイベントの数だけループ')?['location']}
  24:    TRANSP:OPAQUE
  25:    X-MICROSOFT-CDO-BUSYSTATUS:BUSY
  26:    BEGIN:VALARM
  27:    ACTION:DISPLAY
  28:    DESCRIPTION:@{items('取得したイベントの数だけループ')?['subject']}
  29:    TRIGGER:-PT15M
  30:    END:VALARM
  31:    END:VEVENT
  32:    END:VCALENDAR

リスト1.9: STEP3-フローの補足説明④

 1:    concat(addHours(utcNow(),9,'yyyyMMdd-HHmmss'),'-',
   2:                                   string(variables('カウンタ')),'.ics')
   3: 

　STEP2では、出力先をTeamsやメールとしていましたが、STEP3ではiCalendar形式のファイルをデスクトップに出力した上で、完了通知としてTeamsに通知だけしています。

1.5.2　一日の予定をiCalendar形式のファイルに出力 - 自走した人

　ココでもこちらが思った通り、iCalendar形式の書式を調べて「図1.7」のicsファイルに出力項目を追加してくれた人がいました。想定通りですね（笑）

　iCalendarの形式については、こちら³を参照してください。

　ちなみに、今回は参加者からはスケジュールが変更になった場合や、スケジュールがキャンセルになった場合についての問い合わせもありました。これまで使っていたスケジューラのiCalendar形式の取り込み機能は、あくまで新規追加のみに対応しており、変更や削除には対応できておりません。よって、Power Automate側でどうこうできる問題ではないため、理由を説明の上対応できないことを伝えております。せっかく自走しようとしてくれた人がいたのに申し訳ないな、と思いつつ、対応できない場合は「できません」とはっきり伝えることも大事だと感じました。

　また今回のフローの範囲は、iCalendar形式のファイルを生成するまでです。実際の取り込みは手動で行わなければなりません。自動で取り込みされないのか、という声もあがりました。Power Automate単体ではどうしようもないのですが、デスクトップ操作を行うRPA(WinActorやPower Automate for desktop等)と組み合わせることで可能ではありました。特にPower Automateは、Power Automate for desktopと連携できるため、ファイル出力が完了したらPower Automate for desktopで取り込み作業を実施させる、なんてことも可能です。

　ただし、Power Automate for desktopの利用が許可されているかどうかわからなかったこともあり、そこまでハンズオン勉強会ではそこまで範囲を広げては実施していません。範囲を広げてしまうと、今度はPower Automate for desktopの勉強会が必要になってくるので、まずはPower Automateを定着させることが先かな、と考えてのことです。

1.6　最後に

　今回、Power Automateを使ったハンズオン勉強会の事例ということで説明を進めてきました。ただ、冒頭に示した3つの事項に注意すれば、どのようなソリューションやサービスでもいい勉強会を開催することができます。3つのポイント、覚えてますか？

　・スタートでつまずかない

　・感覚で理解できる

　・「ここをこうしたい」と思ってもらう

　この３つでしたね。特に最後の「『ここをこうしたい』と思ってもらう」については、ハンズオン勉強会で用いるフローとしては70%程度の状態でちょうどいいと考えています。100%での状態でハンズオン勉強会を実施すると、参加者に考える余地を与えなくなってしまうからです。参加者が「不便だな」「面倒くさいな」と思う程度の状態でハンズオン勉強会を実施した上で、不便なポイントについて、若干のヒントを与えてあげる方が、早く広まり定着するものと考えています。

　既にRPAやクラウドフロー等を利用されている皆様も多いかと思います。でもそれは、一部の詳しい人による、いわゆる俗人的な状態になっていませんか？

　現場の仕組みをよく知るのは、やはり普段から現場でやり取りをされている方々です。これまでは、改善をしたくてもITを使った自動化等は敷居が高く難しかったと思います。ところが、現在は本章で示したPower AutomateやPRAのようなノーコード・ローコードで開発できる環境も整っています。さらに言えば、AIによるコードやフローの自動生成もこの1年で大きく成長し、エンジニアでなくても自動化に取り組むことの敷居が低くなってきています。

　このような追い風の中でも、現場主導の改善を定着させるのはなかなか難しいところもありますが、

　「考えてもらう余地を残す」≒「70%程度のデキで解説をする」

　ことで、参加者自ら考え、手を動かし、ちょっとした成功体験を得ることで、大きな一歩になると筆者自身、実感しましたので今回執筆させて頂きました。是非、改善活動やDX推進担当者の方に手に取ってみていただき、お役立て頂ければ幸いです。