MENU
  1. ホーム
  2. 技術記事
  3. 複雑な業務マクロの実行ボタンをデータ変換単位で設計する

複雑な業務マクロの実行ボタンをデータ変換単位で設計する

記事154 | 複雑な業務マクロの実行ボタンをデータ変換単位で設計する

LWP ARTICLE · EXCEL & BUSINESS DESIGN

複雑な業務マクロの実行ボタンをデータ変換単位で設計する

～一括実行の便利さと、途中確認・再実行・障害調査のしやすさを両立させる～

Copyright © 2026 LWP 山中 一弘

本資料は、出典を明記いただければ、商用・非商用を問わず、ご自由に複製・改変・再配布していただけます。なお、著作権表示は改変せず、そのまま記載してご利用くださいますようお願いいたします。

記事要約

複雑な業務マクロを「一括実行」ボタンだけで操作できるようにすると、平常時は簡単に見えます。しかし、入力不備、仕様変更、途中データの確認、失敗後の再実行が起きた瞬間に、処理のどこまでが正しく、どこからやり直せばよいか分からなくなります。

解決の要点は、内部の細かな命令ごとではなく、データが業務上意味のある状態へ変わる境界ごとに、独立した実行単位を設けることです。個別実行を正本とし、一括実行はそれらを順番に呼ぶ案内役にします。さらに、各段階の入力条件、完了条件、件数、ログ、再実行時の扱いまで決めておけば、便利さと保守性を両立できます。

判断の核：ボタンの数は、コードの関数数ではなく、「利用者が確認・承認・再実行したいデータ状態の数」で決めます。

本記事の対象とゴール

想定読者

  • Excel VBAやPower Queryを使う業務マクロを設計している人

  • 一括実行はできるが、途中で止まると復旧しにくい仕組みに困っている人

  • 開発者以外でも運用できる操作画面を作りたい人

  • AIへ実装を依頼するとき、機能分割の基準を具体的に渡したい人

本記事で得られること

  1. ユーザー向け機能を分ける境界を、データフローから判断できます。

  2. 個別実行と一括実行を、同じ処理の二重実装にせず構成できます。

  3. 中断、再実行、仕様変更、障害調査に耐える運用条件を設計できます。

  4. AIへ渡す要件を、ボタン名ではなく入出力と完了条件で記述できます。

1. 一括実行だけでは、失敗の場所が見えない

業務マクロは、見た目が一つのExcelブックでも、内部では複数のデータ状態を順番に作っています。たとえば、請求明細を作る処理は、次のように進みます。

受領ファイル
↓ 取込
取込済みデータ
↓ 標準化
整形済みデータ
↓ マスタ照合
照合結果
↓ 人による確認・承認
確定データ
↓ 帳票生成
提出ファイル

この全工程を一つのボタンに閉じ込めると、「押す」という操作は簡単になります。しかし、途中でマスタ未登録が見つかった場合、一括処理のどこまでが完了したのか、修正後にどこから再開できるのかが分かりません。最終ファイルが出たかどうかしか見えない仕組みでは、異常を早期に見つける力が弱くなります。

一括実行が悪いのではありません。一括実行しかないことが問題です。

2. 分割の基準は「意味のあるデータ状態」

内部コードには、ファイルを開く、列を削除する、型を変える、並べ替える、保存するといった多くの処理があります。これらをすべてボタンにすると、利用者は実装順を覚えなければならず、操作画面が開発者向けになります。

利用者へ公開する単位は、次の条件を満たすデータ変換です。

  • 実行後に、人が確認できる成果が残る

  • その段階だけを再実行する現実的な場面がある

  • 前後でデータの意味や責任が変わる

  • エラー原因を切り分ける境界になる

  • 業務用語で短く説明できる

  • 入力条件と完了条件を明示できる

たとえば「列Cを削除」は内部処理ですが、「受領データを標準形式へ変換」は利用者にも意味があります。前者は後者の内部に隠し、後者を独立した実行単位にします。

良い実行単位は、「何をしたか」よりも「実行後に何が確認できる状態になったか」で名付けられます。

3. 全体概要図からボタン候補を取り出す

ボタン名を先に考えると、既存画面や思いつきに引っ張られます。先に、データの場所と状態を示す全体概要図を作ります。

3.1 データを名詞で置く

最初に、処理前後のデータを名詞で並べます。

受領ファイル → 取込済みデータ → 照合結果 → 確定データ → 提出ファイル

3.2 矢印を動詞で説明する

次に、状態を変える矢印へ処理名を付けます。

受領ファイル
↓ 取り込む
取込済みデータ
↓ マスタと照合する
照合結果
↓ 確定する
確定データ
↓ 帳票を作る
提出ファイル

3.3 矢印ごとに契約を書く

各矢印について、最低限、次の五つを決めます。

  1. 入力：どのデータを読むか

  2. 前提：何がそろっていれば実行できるか

  3. 処理：どの業務ルールを適用するか

  4. 出力：何をどこへ作るか

  5. 完了条件：何を確認できれば成功か

この契約を持つ矢印が、トップレベル関数と操作ボタンの候補になります。

4. 個別実行を正本にし、一括実行を薄くする

個別ボタンと一括ボタンで同じ処理を別々に実装すると、修正漏れが起きます。一括実行は、検証済みの個別処理を順番に呼ぶだけにします。

Public Sub 一括実行()

If Not 入力取込() Then Exit Sub
If Not データ標準化() Then Exit Sub
If Not マスタ照合() Then Exit Sub
If Not 提出データ作成() Then Exit Sub

MsgBox "全工程が完了しました。", vbInformation

End Sub

ここで重要なのは、単にSubを並べることではありません。各処理が成功・失敗を呼び出し側へ返し、失敗した時点で後続処理へ進まないことです。途中で失敗したのに帳票だけ作る、といった不整合を防ぎます。

個別ボタンも同じ入口を呼びます。

Public Sub 取込ボタン_Click()
Call 入力取込
End Sub

Public Sub 照合ボタン_Click()
Call マスタ照合
End Sub

実際の関数名や戻り値の型は開発規約に合わせます。設計上の要点は、ボタンのイベント処理に業務ロジックを書かないことです。

5. 前提条件が満たされない処理は実行させない

工程を分けると、利用者が順序を飛ばす可能性が生まれます。したがって、各ボタンは「押せるかどうか」だけでなく、「押した後に前提を検査する」必要があります。

たとえばマスタ照合の前提は、次のように定義できます。

  • 取込済みデータが存在する

  • 必須列がそろっている

  • 取込件数が0件ではない

  • 使用するマスタの版が確定している

  • 前回の照合結果を上書きしてよい状態である

前提を満たさない場合は、「処理できません」だけで終わらせません。何が不足しており、どの操作へ戻ればよいかを案内します。

マスタ照合を開始できません。
理由：取込済みデータがありません。
先に「1. 受領データ取込」を実行してください。

利用者が自力で復旧できるメッセージは、操作設計の一部です。

6. 中間データは「見せる」だけでなく「確認可能」にする

中間シートを表示しても、何を見ればよいか分からなければ確認にはなりません。各工程では、確認観点を明示します。

6.1 件数のつながり

取込100件、除外5件、正常95件なら、100＝5＋95が成立する必要があります。工程ごとの件数を記録すると、消えたデータや重複を早く見つけられます。

6.2 例外データの隔離

不正データを黙って削除せず、「要確認」一覧へ出します。正常データと例外データを分けることで、処理継続の可否を業務担当者が判断できます。

6.3 使用条件の記録

入力ファイル名、更新日時、マスタ版、実行者、実行日時、処理件数を残します。後から同じ結果を説明できる状態が重要です。

6.4 次工程へ進める条件

警告が0件なら自動で次へ進めるのか、担当者の承認が必要なのかを決めます。人の確認を挟む工程は、一括実行がそこで停止しても失敗ではありません。「確認待ち」という正規の状態です。

7. 再実行できる設計にする

「個別ボタンがある」ことと「安全に再実行できる」ことは別です。同じ処理を二回実行したとき、データが二重追加されたり、前回結果と混ざったりするなら、復旧手段として使えません。

再実行の方式は、工程ごとに決めます。

  • 作り直し型：前回出力を初期化し、同じ入力から再生成する

  • 差分型：未処理分だけ追加する

  • 版管理型：実行ごとに別の結果として保存する

  • 継続型：中断位置を記録し、そこから再開する

Excel業務マクロでは、結果シートをいったん初期化して再生成する「作り直し型」が分かりやすい場合が多いです。ただし、人が追記する欄まで消さないよう、機械生成領域と手入力領域を分離します。

8. 操作画面は三つの領域に分ける

ボタンを横一列に並べるだけでは、順序と状態が伝わりません。操作画面は、次の三領域に分けると理解しやすくなります。

実行領域

上から下へ、業務順に個別ボタンを並べます。番号は操作順を示すために使い、内部関数番号にはしません。最上部または最下部に一括実行を置きます。

状態領域

各工程について「未実行」「完了」「要確認」「失敗」を表示します。色だけに依存せず、文字でも状態を示します。

案内領域

現在の入力ファイル、最終実行日時、件数、次に行う操作、警告の概要を表示します。利用者がログシートを探さなくても、次の行動を判断できるようにします。

ボタンを増やしすぎない判断

工程を分ける目的は、内部処理をすべて利用者へ見せることではありません。次の処理は、原則として一つの実行単位へまとめます。

  • 同じ担当者が、同じ入力を使い、連続して実行する

  • 途中結果を人が確認しても、判断や承認が発生しない

  • 片方だけを再実行する業務上の理由がない

  • 失敗時の戻り先と、やり直す範囲が同じである

  • 分けても業務用語で別の目的を説明できない

反対に、担当者が変わる、承認を挟む、例外データを直す、別の時刻に再開する、といった境界では分ける価値があります。目標はボタンを増やすことではなく、利用者が判断できる停止点を設けることです。

操作画面に収まらないほど候補が増えた場合は、通常運用で使う主要工程だけを前面に置き、初期化、再集計、診断出力などは「保守・再処理」領域へ分けます。毎日使う操作と、障害時だけ使う操作を同じ強さで並べないことも、誤操作防止になります。

9. ログは一括実行単位と工程単位の両方で残す

一括実行には、一連の処理を束ねる実行IDを付けます。その配下に工程ごとの開始時刻、終了時刻、結果、件数、メッセージを残します。

実行ID：20260802-001
受領データ取込 完了 100件
データ標準化 完了 95件／除外5件
マスタ照合 要確認 未登録3件
提出データ作成 未実行

この記録があれば、「一括実行が失敗した」という粗い説明ではなく、「マスタ照合まで完了し、未登録3件の確認待ち」と伝えられます。

10. テストはボタンではなく状態遷移を確認する

テストでは、正常系の一括実行だけを確認してはいけません。少なくとも次を試します。

  • 各工程を正しい順番で個別実行できる

  • 前提のない工程を実行すると、理由と戻り先が表示される

  • 同じ工程を再実行しても重複や混在が起きない

  • 警告データがあると、指定した工程で停止する

  • 修正後に該当工程から再開できる

  • 一括実行と個別実行で同じ結果になる

  • ログの件数と実データ件数が一致する

  • 途中で閉じても、次回起動時に状態を誤認しない

これらを確認すると、画面の押しやすさだけでなく、運用としての回復力を評価できます。

11. AIへ実装を依頼するときの渡し方

AIへ「ボタンを5個作ってください」とだけ伝えると、見た目の実装に寄りやすくなります。各機能について、次の形で渡します。

機能名：マスタ照合
入力：標準化済みデータ、商品マスタ
前提：標準化完了、必須列あり、入力0件ではない
処理：商品コードで照合し、未登録と重複を分離する
出力：照合済みデータ、要確認一覧、件数ログ
完了条件：入力件数＝照合済み件数＋要確認件数
再実行：前回の照合出力を初期化して作り直す
失敗時：提出データ作成へ進まない

この記述なら、AIはUIだけでなく、処理の契約とテスト条件まで実装しやすくなります。

12. まとめ

複雑な業務マクロでは、個別実行と一括実行を対立させる必要はありません。個別実行を、意味のあるデータ変換ごとの正本として設計し、一括実行はそれらを安全な順序で呼ぶ薄い制御層にします。

分割の基準は、内部コードの細かさではありません。利用者が結果を確認でき、問題時にそこから再開でき、業務上の責任が切り替わる境界です。

操作性は、ボタン数を減らすことだけでは生まれません。何が完了し、何が未確認で、次に何をすればよいかが見えることも操作性です。データフロー、実行単位、状態、ログ、再実行条件を一つの設計としてつなぐことで、平常時には速く、異常時には止まり方と戻り方が分かる業務システムになります。

出典メモ

  • 元資料：C:\Users\hoehoe\Downloads\記事ネタmd\complex_business_system_button_design_source.md

  • 関連する既存記事：記事133「Excelのユーザーインターフェースを使いやすくする工夫」、記事140「Excel VBAマクロ開発で最初に作る5種類の設計資料」

  • 元資料の「個別実行と一括実行を併設する」という主張を維持し、前提条件、状態管理、再実行方式、ログ、テスト、AIへの要件提示を補った。

LWP ·