VBAマクロ業務整理を359認知モデルと5設計書でつなぐ

要件定義の前に、業務をどう見るかを決めるための暫定メソッド

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

記事要約

VBAマクロ開発で難しいのは、VBAの構文だけではありません。むしろ現場でつまずくのは、お客様の話、Excelブック、CSV、帳票、手作業、部署、判断、例外、目的が混ざった状態から、何を見ればよいのか分からなくなることです。

業務フロー、データフロー図、項目定義書、方式案などは、いきなり書くものではありません。まず現実の業務をどう認知するかを決め、そのうえで、目的に応じて必要な断面を設計書へ落とします。

この記事では、研究途中の方法論として、現実業務を捉えるための「359認知モデル」、それを現場で整理する「業務構造化」、そしてVBAマクロ開発へ落とすための「5設計書メソッド」を紹介します。これは完成した教科書ではなく、現時点の暫定整理です。ただし、VBAマクロの業務整理を教えるための骨格としては、かなり実用的な形が見えています。

本記事の対象とゴール

想定読者

VBAマクロを作る前に、業務内容をどう聞けばよいか迷う人
業務フローや設計書を書けと言われても、何を軸に書けばよいか分からない人
既存マクロを読んでも、業務上の意味へ戻せず困っている人
VBAマクロ開発を、単なるコード作成ではなく業務改善として教えたい人
すごい改善のような現場型のExcel/VBA改善活動で、軽量な方法論を持ちたい人

本記事で得られること

359認知モデルが、設計書テンプレートではなく「業務を見るためのレンズ」であることが分かります。
5設計書メソッドが、359で見た業務を実務資料へ落とすための標準セットであることが分かります。
お客様の「これを作ってほしい」をそのまま要件にせず、「何に困っているか」へ戻す必要が分かります。
VBA改善活動では、SI型要件定義をそのまま持ち込まず、軽量に始めるべき理由が分かります。

1. 要件定義が難しい本当の理由

VBAマクロ開発では、依頼の入口がかなり曖昧です。

お客様は、次のような言い方をします。

CSVを出したい
この表を自動化したい
Accessへ入れたい
ボタンを作りたい
毎月の集計を楽にしたい
既存マクロがよく分からないので直したい

これらは、要件そのものに見えます。しかし、多くの場合、これはお客様側の解決策仮説です。

たとえば「CSVを出したい」という要望の裏には、次のような困りごとがあるかもしれません。

毎月の転記作業が重い
集計に時間がかかる
手入力ミスが多い
誰が正しいデータを持っているか分からない
別システムへ渡すための形式が毎回崩れる

この場合、CSV出力は解決策の一つであって、目的そのものではありません。Power Queryで取り込めばよいかもしれません。Accessに直接連携した方がよいかもしれません。そもそも帳票の作り方を変えれば、CSV出力自体が不要になるかもしれません。

したがって、VBAマクロ開発で最初に必要なのは、いきなりコードを書くことでも、いきなり設計書テンプレートを埋めることでもありません。

まず必要なのは、現実の業務をどう見るかです。

2. 359認知モデルは業務を見るためのレンズである

359認知モデルは、現実業務を認識するための暫定モデルです。

これは、業務フローやER図の代わりになるものではありません。むしろ、それらの設計書を書く前に、何を見ているのかを整理するための考え方です。

2.1 まず3で見る

最小の見方は、次の3つです。

Entity
Relation
Event

Entityは、業務に登場するものです。人、部署、ファイル、Excelブック、シート、CSV、帳票、取引、商品、顧客などが該当します。

Relationは、それらの関係です。部署と担当者、ブックとシート、注文と顧客、出力ファイルと入力データの関係などです。

Eventは、何かが起こることです。入力する、承認する、集計する、転記する、出力する、送付する、締める、取り込むなどです。

この3つだけでも、業務を見る目が変わります。

たとえば「売上表を加工する」という依頼を聞いたとき、ただ処理手順だけを見るのではなく、次のように見ます。

何が登場しているのか
それらはどう関係しているのか
どのタイミングで何が起きているのか

この時点で、業務は単なる作業の羅列ではなくなります。

2.2 次に5で見る

実務では、3つだけでは粗すぎます。そこで、PropertyとTimeを加えます。

Entity
Relation
Event
Property
Time

Propertyは、対象に付く属性です。顧客コード、商品名、金額、日付、部署名、ステータス、ファイル名、列名などです。

Timeは、時系列です。月次処理、締め日、入力日、承認日、出力日、履歴、前回との差分などです。

VBAマクロでは、PropertyとTimeが非常に重要です。

Excelの多くの問題は、列の意味が曖昧であること、日付の扱いが曖昧であること、前回と今回の差分が曖昧であることから発生します。つまり、EntityとEventだけでなく、PropertyとTimeを見ないと、実装へ落ちません。

2.3 必要に応じて9へ広げる

要件定義では、さらに次の観点が必要になります。

State
Rule
Actor
Goal

Stateは状態です。未処理、処理済み、承認待ち、エラー、対象外、完了などです。

Ruleは規則です。どの行を対象にするか、どの条件で除外するか、金額が空欄ならどうするか、同名ファイルがあるときどうするか、といった判断基準です。

Actorは主体です。誰が入力するのか、誰が確認するのか、誰が承認するのか、誰がマクロを実行するのかです。

Goalは目的です。転記を減らす、集計を速くする、ミスを減らす、属人化を下げる、確認しやすくする、という実務上の成果です。

ここまで見ると、業務はかなり立体的になります。

ただし、9要素すべてを毎回受講者へ教える必要はありません。教育上は、まず「何があるか」「どう関係するか」「何が起こるか」から始めれば十分です。

3. 359だけでは要件定義にならない

359は、業務を認知するためのモデルです。

しかし、業務を認知できただけでは、まだ要件定義にはなりません。

なぜなら、359は「何があるか」「何が起こるか」「どう関係するか」を見るためのものだからです。それだけでは、「なぜ作るのか」「何に困っているのか」「どの解決策を選ぶべきか」は決まりません。

ここで必要になるのが、目的領域の整理です。

現場では、次の問いを分けて聞く必要があります。

何をやりたいのか
なぜやりたいのか
何に困っているのか
それを放置すると何が起こるのか
期待する効果は何か
ユーザーが言っている解決策は、本当に最適なのか

特に重要なのは、「何をやりたいか」と「何に困っているか」を分けることです。

お客様が「CSVを出したい」と言ったとき、設計者はすぐにCSV出力マクロを作るのではなく、まず「何のためにCSVが必要なのか」を確認します。

この確認をしないと、ユーザーの仮説をそのまま実装してしまいます。動くマクロはできるかもしれませんが、本当の困りごとを解決しない可能性があります。

4. 業務構造化は359と設計書の間にある

当初は、次のように考えがちです。

359で見る。

そのまま5設計書へ落とす。

しかし、実際にはこの間にもう一段階あります。

それが業務構造化です。

業務構造化とは、359で見えた業務要素を、現場で扱える形に並べ直すことです。

研究資料では、ホワイトボード整理法として次のような分け方が示されています。

左側には、業務構造を書きます。

登場人物
部署
ファイル
帳票
Excelブック
シート
CSV
外部システム
入力
処理
出力
データの流れ

右側には、目的領域を書きます。

困っていること
なぜ困るか
目的
期待効果
ユーザーの希望解決策
設計者の仮説
保留事項
軽く扱う例外

この整理があると、業務フローや設計書を書く前に、議論の土台をそろえられます。

左側だけでは、業務構造は見えても目的が見えません。右側だけでは、目的は見えても実装対象が見えません。両方を並べることで、何を作るべきか、どこまで作るべきか、何を後回しにしてよいかが見えてきます。

5. 5設計書は359の断面図である

5設計書メソッドは、359で見た業務を実務資料へ落とすための標準セットです。

現時点の候補は、次の5つです。

全体概要図
データフロー図
項目定義書
方式案
補助分析資料・差分資料

ここで重要なのは、5設計書は義務ではないということです。

すべての案件で5つ全部を作る必要はありません。小さなマクロなら、全体概要図と項目定義書だけで足りることもあります。既存マクロの修正なら、差分資料と方式案だけでよい場合もあります。

5設計書は、成果物のノルマではありません。必要な断面を選ぶための標準セットです。

5.1 全体概要図

全体概要図は、主にEntityとRelationを扱います。

業務に何が登場し、それらがどうつながっているかを俯瞰します。

VBAマクロ開発では、Excelブック、シート、CSV、外部システム、担当者、出力帳票などが絡みます。これらの関係が見えていないと、いきなりコードを書いても破綻します。

全体概要図は、細かい処理手順を書くものではありません。まず、何が存在し、何と何が関係しているかを見えるようにする資料です。

5.2 データフロー図

データフロー図は、主にEvent、Relation、Timeを扱います。

どのデータが、いつ、どこからどこへ流れるのかを見ます。

VBAマクロでは、入力ファイル、加工処理、出力ファイル、手作業、確認作業が混ざります。データフロー図がないと、どの時点のデータを正とするのか、どこで加工されるのか、どこで人が介入するのかが曖昧になります。

5.3 項目定義書

項目定義書は、主にEntityとPropertyを扱います。

列名、項目名、意味、型、必須か任意か、入力元、出力先、加工ルールなどを定義します。

Excel/VBAでは、列の意味が曖昧なままマクロを書くと、あとで壊れます。列位置だけで処理しているマクロは、表の構造変更に弱くなります。

項目定義書は、単なる列一覧ではありません。業務上、その項目が何を意味するのかを固定するための資料です。

5.4 方式案

方式案は、Goal、Rule、Actor、制約、実装方針を扱います。

たとえば、同じ「転記を自動化する」でも、実現方法はいくつもあります。

VBAで直接転記する
Power Queryで取り込む
Accessへ入れる
CSVを経由する
既存ブックの構造を変える
入力ルールを先に整える

方式案では、どの方法を採用するかだけでなく、なぜそれを選ぶのかを整理します。

これがないと、実装方針が担当者の好みに見えてしまいます。方式案は、設計判断を説明可能にする資料です。

5.5 補助分析資料・差分資料

補助分析資料や差分資料は、State、Rule、Event、Propertyの差異を扱います。

たとえば、現行と新方式の違い、AパターンとBパターンの違い、例外ケース、データ不整合、変更前後の項目差分などを整理します。

VBAマクロ開発では、例外を最初からすべて仕様化するのは重すぎます。しかし、後から問題になりやすい差分や判断材料は、補助資料として残しておくべきです。

6. 新規開発と既存マクロ解析では流れが逆になる

新規開発では、流れは次のようになります。

現実業務を聞く
359で見る
業務構造化する
必要な設計書へ落とす
VBAを書く

一方、既存マクロ解析では逆になります。

VBAコードを読む
処理の流れを復元する
設計書へ戻す
359で業務意味を再認識する
目的と困りごとを確認する
新方式へ再設計する

既存マクロの解析で難しいのは、コードだけを読んでも、業務上の意味が分からないことです。

たとえば、ある列をコピーしていることは分かっても、その列が業務上何を意味するのかはコードだけでは分かりません。なぜその条件で除外しているのか、なぜその順番で処理しているのか、誰がその結果を使うのかも、コードだけでは分かりません。

だからこそ、既存マクロ解析では、コードから5設計書を復元し、そこから359へ戻す発想が必要です。

7. VBA改善活動はSI型開発とは違う

この方法論で注意すべきなのは、SI型の要件定義をそのままVBA改善活動へ持ち込まないことです。

大規模SIでは、スコープ、境界、例外、非機能要件、承認、契約、変更管理が非常に重要です。これは正しいです。

しかし、現場のVBA改善活動に、最初からその重さを持ち込むと動けなくなります。

VBAマクロでは、比較的小さく作り、現場で動かし、必要に応じて直すことができます。変更コストが低い場合も多いです。

そのため、教育上は次の順番が現実的です。

通常業務、本筋を理解する
動くものを作る
運用しながら例外を追加する
必要に応じて境界やスコープを明確化する

これは、例外や境界を無視してよいという意味ではありません。

最初から重く扱いすぎると、VBA改善活動のよさが消えるという意味です。

8. 教育では理論を削る必要がある

359認知モデルは、理論としては広げられます。

既存理論との関係を考えれば、UML、ER、DFD、DDD、オントロジー、知識グラフ、認知科学、言語学などとつながります。

しかし、受講者にそれを全部教える必要はありません。

受講者向けには、次の程度まで削る方が実用的です。

まず359で見る
ホワイトボードで整理する
必要な設計書へ落とす
VBAを書く

講師や設計者は、背景理論を理解しておくべきです。しかし、現場教育では、覚えられること、使えること、ホワイトボードに書けること、VBAへつながることを優先します。

方法論は、正確であるだけでは足りません。使えなければ意味がありません。

9. 現場で使う最小手順

現時点で、実務導入時の最小手順は次のように整理できます。

9.1 最初に聞く

最初に聞くべきことは、「何を作りますか」だけではありません。

次の順で聞きます。

何に困っていますか
なぜ困っていますか
今はどうしていますか
それを放置すると何が起きますか
何ができれば楽になりますか
ユーザーが考えている解決策は何ですか
その解決策以外でもよいですか

この質問により、ユーザーの希望解決策と、本当の困りごとを分けます。

9.2 359で見る

次に、業務を359で見ます。

何が登場するか
それらはどう関係するか
何が起こるか
どんな属性があるか
いつ起こるか
どんな状態があるか
どんなルールがあるか
誰が関わるか
何を達成したいか

すべてを完璧に埋める必要はありません。見落としを減らすための問いとして使います。

9.3 ホワイトボードで整理する

左側に業務構造を書きます。

右側に目的領域を書きます。

この段階で、いきなり綺麗な設計書を作る必要はありません。まず、お客様と設計者が同じ構造を見られる状態を作ります。

9.4 必要な設計書を選ぶ

次に、どの設計書が必要かを選びます。

登場物が多いなら、全体概要図
データの流れが複雑なら、データフロー図
列や項目が多いなら、項目定義書
実現方法に迷うなら、方式案
差分や比較が必要なら、補助分析資料

この選択ができれば、設計書は形式ではなく目的を持った資料になります。

10. 現時点での暫定結論

359認知モデルは、VBAマクロ開発における要件定義の前段に置くべき考え方です。

これは、業務を認知するためのモデルです。

業務構造化は、359で見えた業務を、ホワイトボードや会話で扱える形へ並べ直す中間層です。

5設計書メソッドは、業務構造化された内容を、VBAマクロ開発で使える設計資料へ落とす方法です。

この3つを並べると、全体像は次のようになります。

現実業務を聞く
359で見る
困りごとと目的を整理する
業務構造化する
必要な設計書へ落とす
VBAを書く

この方法論は、まだ完成ではありません。特に、359の正式定義、ホワイトボード整理法、5設計書テンプレート、既存マクロ解析への適用、教育版と講師版の分離は、今後さらに検討する必要があります。

ただし、現時点でも一つの重要な判断軸は明確です。

VBAマクロ開発では、いきなりコードを書かない。

いきなり設計書テンプレートも埋めない。

まず、業務をどう見るかを決める。

そのうえで、困りごとを確認し、業務を構造化し、必要な設計書へ落とし、最後にVBAへ進む。

この順番を持つだけで、要件定義が「何となく聞く作業」から、「業務を設計可能な形へ変換する作業」へ変わります。

出典メモ

元資料: C:\Dropbox\310クライアントワーク\802_開発・育成\テキスト\01_調査設計\研究ゼミ記録_一次資料版_359認知モデルと5設計書メソッド_メタ情報付き.md
元資料の位置付け: 研究ゼミ記録・一次資料版
記事化日: 2026-07-07
素材として使った範囲: 359認知モデル、業務構造化、5設計書メソッド、SI型開発とVBA改善活動の違い、教育版と講師版の分離、現場導入時の最小手順
本記事の扱い: 研究途中の内容を読者向けに切り出した暫定記事版。元Markdownは移動、削除、変更していない。