むー助｜DX担当のメモ帳

事務職でDX担当をやっています。PADで業務自動化→今はCopilotも実務で検証中。現場で試したことをメモ代わりに投稿。noteにPAD実務の記事あります。

[むー助｜DX担当のメモ帳 @DXmemo_pad]

本書では Power Automate × Teams × SharePoint で、

申請 → 承認 → 記録 → 自動督促 → 集計

までを、一つの実務フローとして作ります。

ただ動くフローではなく、
「作った人しか直せない」を避ける運用設計まで。

Kindle Unlimited対象です。

https://t.co/Xbkkl6cKIl

[むー助｜DX担当のメモ帳 @DXmemo_pad]

申請・承認・記録・督促を仕組みにする本
https://t.co/Xbkkl6cKIl

Excel集計をMコード＋ChatGPTで軽くする本
https://t.co/kTlOY1xC7Y

[むー助｜DX担当のメモ帳 @DXmemo_pad]

Excel作業を減らしたい。
でも、困り事が違えば選ぶ仕組みも違います。

申請→承認→記録→督促ならPower Automate。
CSV・Excelの整形→結合→集計ならPower Query。

どちらも、事務職が実際の画面で進められるように作ったKindle本です。詳細は最初の返信へ。

[むー助｜DX担当のメモ帳 @DXmemo_pad]

Power Automateで承認を自動化すれば、集計まで自動になる？

役割は分けて考えます。

Power Automate：申請・結果・日時をSharePointへ残す
Power Query：その記録を月別・部署別に整える

「残す」と「読む」を分けると、運用後の修正箇所も見つけやすくなります。

[むー助｜DX担当のメモ帳 @DXmemo_pad]

Power Automateの承認フローは、緑のチェックが並んでも安心しきれません。

実行履歴で見るのは
□ 待機に何分かかったか
□ 条件がどちらへ進んだか
□ SharePoint更新まで通ったか
□ 却下でも記録が残るか

成功マークと業務結果をセットで確かめます。

[むー助｜DX担当のメモ帳 @DXmemo_pad]

毎月のCSVを1つずつ開いて貼り付けるなら、Power Queryの入口を「フォルダーから」にします。

列構成をそろえたファイルを同じ場所へ追加し、更新でまとめて取り込みます。

取引先が列名を変えた月は、その1ファイルで全体が止まることも。エラー行と元ファイル名を残して確認します。

[むー助｜DX担当のメモ帳 @DXmemo_pad]

却下結果だけ記録しても、申請者は次に何を直せばよいか分かりません。

Power AutomateからSharePointへ残したいのは
・却下した人
・日時
・コメント
・再申請の方法

True／Falseの両方に更新処理を置き、「誰が、いつ、なぜ」を一覧から追える状態にします。

[むー助｜DX担当のメモ帳 @DXmemo_pad]

勤怠表へ氏名や部署を足すために、VLOOKUPを何列もコピーする必要はありません。

Power Queryなら社員IDで社員マスタを左外部結合し、必要な列だけ展開できます。

マスタにないIDは空欄で残し、消さずに確認。未登録や表記違いを見つける手掛かりになります。

[むー助｜DX担当のメモ帳 @DXmemo_pad]

Power Automateで承認者を2人以上にするとき、先に決めるのはメールアドレスではありません。

①誰か1人で完了
②全員の承認が必要
③課長→部長の順番

これは別の業務ルールです。画面を作る前に、承認順と却下された時点で終えるかまで決めます。

[むー助｜DX担当のメモ帳 @DXmemo_pad]

Power Queryで覚えるべきは、ボタンの場所より「変換手順が残る」こと。

一度作った処理は、翌月のファイルへ差し替えて更新すれば、同じ順番で再実行されます。

引き継ぎには
□ 入力ファイルの置き場所
□ 更新方法
□ エラーの確認場所
この3つを残します。

[むー助｜DX担当のメモ帳 @DXmemo_pad]

Power Automateのトリガー選びで、同じ申請が何度も動くことがあります。

新規申請だけで始めるなら「項目が作成されたとき」。
「作成または変更されたとき」にすると、SharePointへの結果更新が次の実行を呼ぶ設計になり得ます。

テスト後は、1申請につき実行履歴が1件か確認します。

[むー助｜DX担当のメモ帳 @DXmemo_pad]

勤怠の「855」を時刻へ変えるなら、変換ルールを先に言葉にします。

・全角を半角へ
・左側を0で埋める
・右2桁を分にする
・変換できない値は分けて確認

Power Queryの結果で、855→08:55、2200→22:00など複数例を照合してから全体へ広げます。

[むー助｜DX担当のメモ帳 @DXmemo_pad]

承認フローを作るとき、状態は最初から3つに分けます。

・申請中
・承認済み
・却下

Power Automateが途中で止まったとき、「空欄」だけでは未処理か失敗か判断できません。

SharePointへ申請中を先に記録し、完了後に結果へ更新すると、滞留も探しやすくなります。

[むー助｜DX担当のメモ帳 @DXmemo_pad]

この勤怠データ、どこが危ないか分かりますか。

22:00出勤→翌6:00退勤。
同じ日として引くと勤務時間はマイナスになります。

Power Queryでは「時刻への変換」と「日またぎの判定」を別工程にする。AIへも、退勤が出勤より早い場合は翌日扱いと伝えます。

[むー助｜DX担当のメモ帳 @DXmemo_pad]

Power Automateの画面で「承認」と表示されても、条件に入れる値は「Approve」です。

①「開始して承認を待機」の結果を選ぶ
②「次の値に等しい」
③右側へApprove

日本語の表示名をそのまま入れず、実行履歴でOutcomeを確認してから分岐を作ります。

[むー助｜DX担当のメモ帳 @DXmemo_pad]

Power QueryのMコードをChatGPTに書かせるとき、Excelファイルを丸ごと渡す必要はありません。

伝えるのは
・実際の列名
・正常な1行
・クセのある2〜3行
・欲しい結果

全角数字や空欄も混ぜると、修正すべき条件が見えます。最初は少量のサンプルで試します。

[むー助｜DX担当のメモ帳 @DXmemo_pad]

承認が止まったら、①フローの実行履歴 ②承認アクションの入力 ③対象リストの更新結果、の順で確認すると原因を切り分けやすいです。

[むー助｜DX担当のメモ帳 @DXmemo_pad]

Power Automateの承認フローは、作ることより「止まったときに追えること」が大事です。

最低限、申請者・承認者・結果・処理日時の4つはSharePointリストへ残す。
これだけで「今どこ？」の確認がかなり減ります。

[むー助｜DX担当のメモ帳 @DXmemo_pad]

Power Automateで自動化するとき、
最初に作るべきなのは「成功ルート」だけではありません。

失敗したときに、
どこで止まったか分かる記録を残す。
これだけで、直しやすさは大きく変わります。

[むー助｜DX担当のメモ帳 @DXmemo_pad]

Power Automateの自動化は、
「動いたか」より
「止まったときに分かるか」が大切です。

成功だけでなく、失敗も記録する。
これだけで、現場で使えるフローに近づきます。

[むー助｜DX担当のメモ帳 @DXmemo_pad]

承認フローを作る前に、会議で決めるのはこの7点です。

□ 誰が申請するか
□ 誰が承認するか
□ 代理承認者
□ 承認期限
□ 却下時の戻し先
□ 記録する項目
□ 督促する条件

画面づくりの前に決めると、手戻りを減らせます。