【Power Automate入門】備品購入申請システム#3　～要件定義とフローの設計をしよう！～

第2回目では、フローの基本的な仕組みや、変数とデータ型、プログラミングの基本処理3つなど、開発に必要な基礎知識を学びました。

【Power Automate入門】備品購入申請システム#2　～Power Automateで必要な基礎知識を学ぶ！～第2回目の今回は、Power Automateを開発するために必要となる、フローの基本的な仕組み、変数とデータ型、関数等について学んでいきましょう！...

第3回目の今回は、第2回目に学んだ知識を使って、現状の業務の課題整理から、要件定義、フローのアルゴリズム設計、テーブル設計まで、システム開発の「上流工程」を一気にやっていきましょう！

Power Automateについて詳しく学びたい方は、ぜひパワ実のPower Automate入門書もご覧ください！

Power Automate入門書を出版しました！ パワ実 ついに、私のPower Automate入門書も出版されました！ ミムチ 「ゼロから学ぶ」シリーズの第2弾ですぞ！ ...

YouTube動画で見たい方は、こちらからどうぞ！

今回実施するところ

このシリーズでは、Power AutomateとPower Appsを使って、申請・承認フローを一から作っていきます。

第3回となる今回は、いよいよ開発の最初のステップ、「要件定義」と「設計」を実際にやっていきます！

現状の業務フローと課題の整理

最初に、今の業務がどのように回っているかを、整理するところから始めます。

現状を把握しないままシステムを作り始めると、途中で「あの機能も必要だった」と手戻りが発生したり、完成してから「欲しかったものと違う」となったりします。

現状の業務フロー

現状の備品購入申請は、以下のようになっています。

課題を洗い出す

次に、この業務フローの中で「どんなことに困っているか」を書き出してみます。

業務フローの絵の上に困りごとを書き込んでいくと、誰が、どの場面で困っているかが見えやすくなります。

実務では、この工程が関係者への「ヒアリング」にあたります。

改善策を考える

洗い出した課題に対して、それぞれ改善策を考えて、表に整理します。

このように課題と改善策を1対1で並べておくと、「何のためにこの機能を作るのか」が明確になります。

要件定義

ここから要件定義に入ります。

要件定義とは、先ほどの改善策を、「システムへの要望」として具体的に言葉にすることです。

主語と、きっかけと、結果をはっきりさせておくと、あとで実装するときに迷わなくなります。

申請者の要件

まず、申請者の要件から見ていきます。

申請者は「申請の入力」だけすればよくて、あとの承認依頼や、添付ファイルの格納などは、すべて自動化する形です。

承認者の要件と承認ルート

続いて、承認者の要件です。ここで、承認ルートのルールも確定させます。

これまで「毎回確認が必要」だったルールを、ここで明文化しました。

課題と要件の対応をチェックする

要件定義の仕上げとして、大事なチェックをします。

洗い出した課題が、要件でぜんぶ拾えているか？　課題と要件を対応させながら確認していきます。

5つの課題すべてに、対応する要件があることが確認できました。

改善後の業務フロー

要件が固まったので、次は「改善後の業務フロー」を描いていきます。

従来のメールとExcelの業務を、Power Apps・Power Automate・SharePoint・Teamsを組み合わせたフローに変えます。

流れを順番に見ていきます。

① アプリで新規申請を登録

申請者は、Power Appsで作った「備品購入申請アプリ」から、品目名や数量、金額などを入力して申請します。

② データソースに自動で登録

申請データが、SharePointリストに自動で登録されます。

Power AppsはSharePointリストをデータソースとして直接読み書きできるので、この登録はアプリの標準機能だけで完結します。

③ Teamsで課長に承認依頼の通知

アプリで申請を登録したタイミングで、Power Automateのフローが実行され、課長にTeamsで承認依頼を通知します。

課長は、届いた依頼から内容を確認して、承認か却下を選ぶだけで、メールを探す必要はありません（課題3の解消）。

④ Teamsで部長に承認依頼の通知

金額が30万円以上の場合は、課長の承認のあと、部長にもTeamsで承認依頼が届きます。30万円未満なら、課長の承認だけで完了です。

「この申請は部長まで回すんだっけ？」という確認を、人がやる必要はもうありません。

金額を見て、システムが自動でルートを判定してくれます（課題5の解消）。

⑤ データソースを自動で更新／⑥ 申請者にメール通知

必要な承認ルートでの処理が完了したら、承認・却下の結果やコメントがSharePointリストに自動で更新され、最後に申請者へ結果がメールで通知されます。

人がやるのは「申請の入力」と「承認の判断」の2つだけです。

必要なフローを洗い出す

いま見た流れを箇条書きで整理して、「どこに、何のフローが必要か」を確認します。

①〜②は、Power Appsの標準機能なので、フローは不要です。

そして③以降を担当する、今回必要なPower Automateフローは「1本」だけです。

Power Automateの承認機能には「相手の回答を待つ」仕組みがあるので、申請から承認、記録、通知まで、1本のフローで完結できます。

フローの分け方には色々あり、実際には、最初の承認依頼と2回目の承認依頼を分けたり、ドキュメントの保存部分を別フローにする場合もあります。

アルゴリズム設計

それでは、フローの中身を設計していきます。これが「アルゴリズム設計」です。

やることはシンプルで、フローが実行する処理を、上から順番に、箇条書きで書き出すだけです。

私はExcelを使うのをおすすめしています。

前半：申請受付から添付ファイル保存まで

まず前半、申請受付から添付ファイル保存までを書き出したものが、こちらです。

トリガーでは、どの申請かが分かるように、アプリから申請IDを引数として受け取ります。

そして④が、前回学んだ「反復」＝ループ処理です。

添付ファイルは1件のこともあれば、3件のこともあるので、「1件ずつ繰り返す」形で処理します。

ループの中でやることは、ドキュメントライブラリーへの保存と、添付ファイルテーブルへの記録の2つです。

後半：承認から結果通知まで

続いて後半部分の、承認から結果通知までです。ここにはいくつか「条件分岐」の処理が出てきます。

条件分岐を書く場合は、字下げで「条件の中の処理」を表現しておきましょう。

分岐の書き方には好みがあり、分岐の中に入れ子のように分岐を入れていく書き方もできます。

しかし、分岐が多くなる場合、入れ子形式ではフローの可読性が悪くなり、あとから修正するのも大変です。

データ設計

設計の最後は、データ設計です。

アルゴリズム設計で「リストを更新」「テーブルに登録」と書きましたが、では、どんなテーブルが必要なのか？

まずテーブルの一覧を書き出してから、それぞれの中身を設計していきます。

必要なテーブル一覧

必要なテーブルは、以下の2つです。

それから、テーブルではないので一覧には載せていませんが、添付ファイルの実体（ファイルそのもの）の保存場所として、SharePointのドキュメントライブラリーも使います。

申請IDごとのフォルダを作って、そこにファイルを保存していくイメージです。

申請一覧テーブルのカラム定義

1つずつ全部は解説しませんが、設計の判断ポイントに絞ってお話しします。

ポイント1：申請者と申請部署は「テキスト型」

SharePointにはユーザー型という便利な型もありますが、今回はあえてテキストにしています。

理由は、申請した「時点」の情報を、そのまま記録として残したいからです。

ユーザー型は、Azureに登録された最新のユーザー情報を取得しているため、その後の異動や組織変更で表示が変わってしまうことがあります。

ポイント2：金額は「数値型」

アルゴリズム設計で「金額が30万円以上かで分岐」と書きました。

数値として比較するので、テキストではなく必ず数値型にします。

ポイント3：ステータスは「選択肢型」

申請中／一次承認済／最終承認済／却下、の4つから選ぶ形です。

自由入力にすると表記ゆれが起きて、分岐の条件が安定しなくなるので、選択肢で固定します。

ポイント4：課長と部長の承認情報は、それぞれ別の列に

部長の列は、30万円以上の申請のときだけ記録されて、未満のときは空欄のままです。

今回の承認者は課長と部長の2人で、これ以上増えない前提なので、はじめての方にも分かりやすいよう、1つのテーブルで完結するシンプルな設計にしました。

申請添付ファイルテーブルのカラム定義

なぜ添付ファイルを別テーブルにするのでしょうか？

理由は、添付ファイルが「1つの申請に複数」あるからです（例：見積書と仕様書で2件）。

1件の申請に、複数のファイルがぶら下がる「1対多」の関係を表現するために、テーブルを分けて、申請IDで紐づけます。

実は、ここも設計の選択肢があるところです。

そこで今回は、あえてフローでドキュメントライブラリーにコピーして、その保存先をこのテーブルで管理する形にしました。

さいごに

この記事は、Power Automate入門の「申請・承認フロー開発シリーズ」の3回目で、備品購入申請システムの「要件定義」と「設計」の一連の流れをやっていきました。

流れをおさらいすると、以下のようになります。

この手順は、今回の備品購入申請に限らず、どんな業務の自動化でも同じように使えます。