本連載記事ではPower Automateにおけるロジックの構築方法を段階的なアプローチを中心に解説します。初心者から熟練の方まで共通で、効率的にワークフローを設計・実装するためのヒントになればと思います。
解説に使用するサンプルフローをソリューションにまとめてGitHubにアップロードしました。
GitHubで公開しているソリューションに含めているフローは下記5つです。
- 指定された形式に日付を変換_1_プロトタイプ1 ★本投稿で使用するフロー
- 指定された形式に日付を変換_2_プロトタイプ2
- 指定された形式に日付を変換_3_プロトタイプ3_追加パターン対応前
- 指定された形式に日付を変換_4_プロトタイプ3_追加パターン対応後
- 指定された形式に日付を変換_5_完成形
- 概要
- 背景
- そもそも、ロジックを組み立てることは難しいことである
- 避けたほうがよいこと、およびその理由
- 段階的なフローのロジック作成のすすめ
- 段階的にフローを組み立てる5つのメリット
- プロトタイプ1の作成
- 解説で使用するフローをGitHubで公開しました。（再掲）
- 「連載その2」へ続きます
- 【追記】「連載その2」を投稿しました
概要
この連載ではPower Automate におけるフローのロジックの組み立てかたについて私の経験則を解説します。普段はほとんど感覚的に行っていることを今回言葉に表してみました。これがどなたかのお役に立てれば幸いです。
背景
X（旧：Twitter）で見かけたアルゴリズムクイズ
X（旧：Twitter）でこんな投稿がありました。
#エクセルクイズ
— としじ (@toshi81350036) June 26, 2024
＜問題＞
A1のようなデータが与えられたときに、C1以下のものを出力してみてください。
＜入力サンプル＞
a: 6/1, 2, 10, 7/3, 6, 9
b: 6/15-17, 7/15-20
c: 6/21-22, 7/23, 25 pic.twitter.com/fO0ekmbrtd
これは「アルゴリズムクイズ」や「コーディングチャレンジ」と呼ばれる問題です。
この問題をPower Automate用に読み変えます
この問題をPower Automate用に読み変えるとこうなります。
<問題>
下図の通り、「作成-入力」アクションの値を入力情報として「作成-出力」アクションの値を得ること
さて、下図の赤枠部分で何をするか想像できますか？
多くのかたは「できます！」と自信を持って答えられないと考えています。
そもそも、ロジックを組み立てることは難しいことである
今回のアルゴリズムクイズでは、「入力情報」と「求められる出力情報」がお題として提示されています。これらを比較することで、必要となる「繰り返し処理」や「条件分岐」の概要は把握できますが、全体のフローを具体的にイメージするのは場数を多く踏んでいる熟練者でなければ難しいものです。
避けたほうがよいこと、およびその理由
避けたほうがよいこと
フローの設計・実装において避けたほうがよいことがあります。それは下記のことです。特に初心者のかたはこれらの状況におちいりやすいと思われます。
- はじめから完成形を目指して上から順番にフローを作成すること
- フローが使いそうな値をすべて変数アクションで扱おうとすること
（= 定数にするべきかを検討しない） - フローがすべて組み終わってからはじめて動作確認をすること
避けたほうがよい理由
理由を下表に示します。
| 避けたほうがよい理由 | 詳細 |
|---|---|
| 完成までの見通しがたてにくい | 全体的な処理の流れや課題を洗い出さずに実装を進めるため、作業ボリュームの見通しがたてにくい。最悪の場合、作業時間をかけたにも関わらず「開発の進捗が進まない」という事態が起こり得る。 |
| 課題の発見が遅くなる可能性がある | 開発の過程（特にフローの後半・終盤）でにおける課題の洗い出しが後回しにされることがあり、問題解決に時間を要することがある。 |
| 可読性やメンテナンス性が低下しやすい | フロー全体をイメージしない状態で開発を進めるため、一貫性が保たれず表記のブレや冗長な実装が発生する場合がある。 |
| 開発の引き継ぎが難しくなりやすい | 途中で他のメンバーに開発を引き継ぐ際、最初に開発した人が後続処理をどのように考えていたかが伝わりづらい。 |
段階的なフローのロジック作成のすすめ
【結論・主旨】フローのロジックは段階的に組み立てよう
最初は出力の範囲を最小減に絞ってフローを作り、徐々に出力の対象範囲を広げていきます。
この図は、段階的にフローを構築していくプロセスを示しています。まず、プロトタイプ1では1つの値だけを出力し、次にプロトタイプ2・3と進むにつれて出力対象の範囲を広げていきます。最終的に、全ての必要な出力を網羅する完成形のフローを作成するという流れです。
段階的に作成を進めることで、フローの複雑さに対応しやすくなり、効率的なロジックの構築が可能です。
必要なプロトタイプの個数（= 段階の個数）はフロー全体を通してのロジックの複雑さによって変わります。「ロジックの複雑さ」とは主に「入出力のパターンの多さ」を指します。
段階的なロジックの組み立てかたをフロー図で表すとこの通り
段階的なロジックの組み立てかたのイメージを下図に示します。
段階的にフローを組み立てる5つのメリット
機械的に設計・実装を進められる
- この手法では、最初に小さな出力範囲で簡単なフローを作成し、実際に動作するか確認してから徐々に複雑な処理や出力対象を追加していきます。
- 開発者は、個々のステップごとに具体的なゴールを持って作業するため、迷うことなく効率的に作業が進みます。
- 段階的なアプローチにより、次に何をすべきかが明確で、フローの設計や実装が機械的に進められます。
かけた時間が無駄にならない
- 出力範囲を小さく設定し、動作確認を行ってから次のステップに進むため フローが予期せず動作しないケースを早期に発見できます。
- また、逐次確認することで、実装の過程で発生する問題を小さな単位で特定しやすくなり手戻りを最小限に抑えることができます。
- この方法により、後になって大きなフロー全体を修正する必要がなく 初期段階で問題を解決できるため、かけた時間が無駄になりません。
可読性・メンテナンス性を保ちやすい
- 段階的な開発手法を採用することで、各段階のフローが整理された状態で作成されるため、可読性が向上します。
- 各ステップで明確で簡潔なゴールをもとに開発が行われるため、 フロー全体を通してロジックが煩雑になることが回避しやすいです。
- フローを段階的に拡張していくことを前提とした開発手法であるため 要件の追加や変更があった場合にも、比較的柔軟に対応できます。
ケース漏れが発生しにくい
- 段階的にフローを拡張することで、各ステップごとに動作確認を行いながら開発を進めるため、ケース漏れが発生しにくくなります。
- 出力範囲を少しずつ広げていくことで、想定される処理や例外ケースも小さな単位で確認でき、結果としてすべてのケースが網羅されやすくなります。
- 最初から大規模なフローを構築する場合に比べて、 細かく動作確認を行えるため、後からケース漏れが発覚するリスクを 減らせます。
開発途中での引継ぎが行いやすい
- この開発手法では、小さな範囲ごとに確実に動作するフローが構築されているため途中で別の開発者に開発を引き継ぐ場合も引き継ぎが比較的スムーズに行えます。
- 各ステップが明確に分かれており、それぞれの範囲で期待される出力が明示されているため、新しい開発者がフローの意図を理解しやすく、開発を継続しやすいです。
プロトタイプ1の作成
まずはプロトタイプ1を作ります
このフロー作成手法ではまず最小限の出力範囲に絞ってプロトタイプを作り、段階的に対象範囲を広げていくアプローチをとります。最初のプロトタイプでは1つの値だけを出力対象にします。
入力と出力
プロトタイプ1のフローは下図の通りになります。このフローは最終的な完成形のフローの出力に含まれる値のうちひとつの値を出力します。
繰り返し処理を行うべき箇所を「ひとつの要素を対象にした処理」に仮置き
このフローでは本来繰り返し処理を行うべき箇所を「ひとつの要素を対象にした処理」に読み替えてフローを作成します。「"本来繰り返し処理の対象となる配列"からひとつの要素を取得する」ための"仮置き"目的のアクションを配置します。
プロトタイプ 1 では変数・条件分岐を使用しない
プロトタイプ1では特定のひとつの値を出力することを目的としているため変数アクションと条件分岐を使用しないという特徴があります。
解説で使用するフローをGitHubで公開しました。（再掲）
解説に使用するサンプルフローをソリューションにまとめてGitHubにアップロードしました。ソリューションに含めているフローは下記5つです。
- 指定された形式に日付を変換_1_プロトタイプ1
- 指定された形式に日付を変換_2_プロトタイプ2
- 指定された形式に日付を変換_3_プロトタイプ3_追加パターン対応前
- 指定された形式に日付を変換_4_プロトタイプ3_追加パターン対応後
- 指定された形式に日付を変換_5_完成形
「連載その2」へ続きます
「プロトタイプ2の作成」以降については次回の投稿で解説します。
今回は以上です。
