はじめに
福祉職からPower Platformエンジニアに転職して3ヶ月が経過。
この記事は「福祉職からPower Platformエンジニアへ：最初のプロジェクトで学んだこと」シリーズの第4回です。
前回はPower Appsで検索機能を実装した話を書きましたが、今回はPower Automateでフローを作成した話を書いていきます。
正直に言うと、Power Automateはかなり苦手でした。でも、向き合ってみて苦手意識がだいぶ減りました。その過程を書いていきたいと思います！
なぜ苦手だと感じていたか
Power Appsを使ったアプリ開発と違って、形が見えにくいから苦手だと感じていたのかもしれません。
Power Appsでのアプリ開発は、直感的にコントロールを配置することができたり、プロパティに式を入れることで動作したりと、すぐに形になって表現できます。レゴブロックのように出来上がっていく工程が楽しく思えます！
しかし、Power Automateは裏で自動処理をするものなので、形が見えないように感じてしまいます。僕の感覚では、Power Appsは直感が使えて、Power Automateは直感があまり使えないように感じていました。
これまであまり触れてこなかったので、慣れていないせいもあるかと思いますが…
最初にルールを知っておく大切さ
今になって気づいたのは、最初にルールを知っておくことの大切さです。
変数の定義の仕方、配列の基本的なこと、オブジェクト内にある要素へのアクセス方法など、事前に予備知識があれば、エラーメッセージを読んでも「何が何だかわからない」といった現象が起こりにくい気がしました。
僕の場合、「変数と配列といえば箱のイメージ」くらいしか思っていなかったので、もう一歩踏み込んで理解を深める必要がありました。
また、「フローの実行に成功した/失敗した」の2軸だけで考えないことも大切だと思いました。
使い慣れていないころは、どうしてもフローの実行が失敗してしまうことが多いと思います。失敗の連続で変に苦手意識を持ってしまいそうになる。実際に苦手意識を持ってしまいました。
「成功した/失敗した」で考えるよりも、「なぜこういう結果になったのか」と考え、原因を追究していく姿勢が大事なのかなと思います。
実装した処理の概要
今回のプロジェクトでは、以下のような処理をPower Automateで実装しました。
- CSVファイルをSharePointリストに一括登録する処理
- BOM検出、文字コード判定などのバリデーション
- 拡張子チェック、ヘッダー検証、列数チェック
- 必須項目チェック、文字数チェック、数値型・日付型チェック
- エラー時はHTMLテーブルを生成してTeamsに通知
- 成功・失敗に応じたメッセージ通知
かなり盛りだくさんでした。
つまずいたこと①：BOM検出の実装
一番苦労したのがBOM検出の実装です。
そもそも「文字コードって何？」「BOMって何？」から始まりました。
調べていくうちに、BOM（Byte Order Mark）はファイルの先頭に付ける「このファイルはUTF-8ですよ」という目印だとわかりました。Power AutomateではUTF-8（BOM付き）のCSVファイルが推奨されているため、BOMの有無をチェックする必要がありました。
具体的には、ファイルコンテンツをBase64形式で取得して、先頭が 77u/ で始まるかどうかを startsWith() 関数で判定する、という実装をしました。
startsWith(base64(body('ファイルコンテンツの取得')), '77u/')
この式にたどり着くまでに、文字コードの仕組み、BOMの役割、Base64変換の意味など、いろいろなことを学びました。時間はかかりましたが、理解が深まった部分でもあります。
つまずいたこと②：120秒タイムアウト
もう一つ大きなつまずきがありました。
最初は、処理結果をアプリ画面にポップアップ表示させるように作り込んでいました。しかし、「Power Appまたはフローに応答する」アクションは120秒以内に応答を返さないとタイムアウトになるという制限があることが判明しました。
今回のフローは120秒以上かかる処理だったため、急きょTeams通知へと変更することに。
これは結構大きな軌道修正になり、スケジュールがタイトになりました。事前に制限事項を把握しておくことの大切さを学びました。
実装しやすくなったきっかけ
変数や配列、Power Automateフローを構築するうえでのルールなど、基本を押さえることでエラーの対処がしやすくなりました。
エラーが出ても「何が何だかわからない」という状態から、「この部分がおかしいのかな」と当たりをつけられるようになってきました。
基本を理解してからは、デバッグも楽になりました。
AIの活用
Power Automateの開発で大きく助けられたのがAIの活用です。
AIにエラーメッセージを渡してあげて、分析してもらうと、わかりやすく返してくれることがわかりました。
特に効果的だったのは、**「なぜこのエラーが出ているのかを解説してほしい」**という旨を付け加えること。
ただエラー箇所を特定するだけでなく、原因を探ってわかりやすく解説してくれるのでありがたかったです。理解も進むし、開発スピードも上がりました。
AIは間違ったことを言うこともあるので、完全に信じ切ることはできませんが、一人で試行錯誤するよりもAIと対話しながら開発を進めると、気持ち的にも余裕が生まれます。
以前は、調べものをしながら開発をしていました。その時は、「ほしい情報が載っているけど、自分には理解できない」といったことがしばしばありました。だから一人で試行錯誤するやり方は時間がかかる。
AIを活用できるようになってから、開発が楽しくなってきた気がします。AIという心強い味方がいるのは本当にありがたい。
完成して感じたこと
Power Automateへの苦手意識がだいぶ減りました。
AIをうまく活用して実践を積み重ねることで、進歩が格段によくなると感じました。まだまだ学ぶことはたくさんありますが、「苦手だから避けたい」という気持ちはなくなりました。
むしろ、次のプロジェクトではもう少しスムーズにできそうだという手応えを感じています。
おわりに
この記事では、苦手だったPower Automateと向き合った経験について書きました。
まとめると：
- 形が見えにくいから苦手だと感じていた
- 「成功/失敗」ではなく「なぜこうなったか」 を考える姿勢が大事
- 基本（変数、配列、ルール）を押さえることでエラー対処がしやすくなる
- AIに「なぜこのエラーか解説して」と聞くと理解が深まる
- AIと対話しながら開発すると気持ちに余裕が生まれる
次回は「テストケースを初めて作った話」について書く予定です！
この記事は「福祉職からPower Platformエンジニアへ：最初のプロジェクトで学んだこと」シリーズの一部です。