Excel VBAをある程度書けるようになると、
次のような壁に必ずぶつかります。
- 「Subがどんどん長くなってきた」
- 「どこで処理を分ければいいのか分からない」
- 「関数化した方がいい気がするが基準が曖昧」
- 「とりあえず動くけど、修正が怖い」
VBA初心者のうちは、
1つのSubにすべての処理を書く ことが多いですが、
実務ではこれが大きなトラブルの原因になります。
- 修正の影響範囲が分からない
- 同じ処理を何度も書く
- 他人が読めない
- 自分でも後から理解できない
これらの問題は、
プロシージャを分ける基準が曖昧なまま書いていることが原因です。
この記事では、Excel VBA初心者〜中級者の方を対象に、
「プロシージャ(Sub / Function)をどの基準で分けるべきか」を、
設計思想・コード例・実務ケースを交えながら徹底的に解説します。
最後まで読むことで、
「何となく分ける」状態から卒業し、
自信を持って設計できるVBAが書けるようになります。
目次
- ✅ そもそもプロシージャとは何かを再確認する
- ・プロシージャとは
- ・SubとFunctionの違い(簡単に)
- ✅ なぜプロシージャを分ける必要があるのか
- ・分けない場合に起きる問題
- ・プロシージャ分割の本当の目的
- ✅ プロシージャを分ける最も基本的な基準
- ・基準①「1つのプロシージャは1つの役割」
- ・悪い例(役割が混在)
- ・良い例(役割ごとに分割)
- ✅ 「長くなったら分ける」は間違い
- ・なぜ行数基準が危険なのか
- ✅ 処理の「流れ」と「中身」を分ける
- ・流れを制御するプロシージャ
- ・中身を担当するプロシージャ
- ✅ SubとFunctionを分ける基準
- ・判断基準は「戻り値が必要か」
- ・Functionにするべき例
- ・Subにするべき例
- ✅ 同じ処理が2回出てきたら分ける
- ・NG例
- ・OK例
- ✅ プロシージャの「粒度」をどう決めるか
- ・分けすぎの例
- ・適切な粒度の目安
- ✅ ユーザーフォームを使う場合の分割基準
- ・やってはいけない例
- ・正しい分割例
- ✅ エラー処理は分けるべきか
- ・理由
- ・設計例
- ✅ 実務でよくある失敗パターン
- ・Mainが存在しない
- ・名前が抽象的すぎる
- ・処理の順序が分からない
- ✅ プロシージャ分割がもたらす最大のメリット
- ✅ まとめ:プロシージャ分割は設計力そのもの
✅ そもそもプロシージャとは何かを再確認する
本題に入る前に、
「プロシージャ」という言葉を整理しておきましょう。
ここが曖昧なままだと、分割基準も理解できません。
・プロシージャとは
VBAにおけるプロシージャとは、
処理のまとまりを表す単位です。
- Sub プロシージャ
- Function プロシージャ
この2種類が存在します。
・SubとFunctionの違い(簡単に)
- Sub
→ 処理を実行する - Function
→ 処理を行い、結果を返す
どちらも「処理のかたまり」である点は共通です。
✅ なぜプロシージャを分ける必要があるのか
「動いているなら分けなくてもいいのでは?」
と思う方もいるかもしれません。
しかし、分けない設計は必ず破綻します。
・分けない場合に起きる問題
- 1つのSubが300行以上になる
- 途中の処理が何をしているか分からない
- 再利用できない
- テストできない
👉 VBAが“書けない”のではなく、“管理できない”状態になります。
・プロシージャ分割の本当の目的
プロシージャを分ける目的は、
- 処理を理解しやすくする
- 修正しやすくする
- 再利用しやすくする
つまり、
将来の自分や他人を助けるためです。
✅ プロシージャを分ける最も基本的な基準
まず、最も重要な結論からお伝えします。
・基準①「1つのプロシージャは1つの役割」
これが 最重要ルール です。
- データ取得
- データ加工
- 出力
これらを1つのSubに詰め込むと、
一気に読みにくくなります。
・悪い例(役割が混在)
Sub MainProcess()
' データ取得
' データ加工
' ファイル保存
End Sub
・良い例(役割ごとに分割)
Sub MainProcess()
Call GetData
Call ProcessData
Call SaveResult
End Sub
👉 Mainは流れだけを書く
これが基本設計です。
✅ 「長くなったら分ける」は間違い
よくある誤解がこれです。
「行数が多くなったら分ける」
これは 基準として不十分 です。
・なぜ行数基準が危険なのか
- 短くても役割が多い場合がある
- 長くても1つの役割なら問題ない場合がある
重要なのは 行数ではなく意味 です。
✅ 処理の「流れ」と「中身」を分ける
実務でおすすめなのが、
流れと中身を分離する設計です。
・流れを制御するプロシージャ
Sub ExecuteJob()
Call ValidateInput
Call CalculateResult
Call OutputResult
End Sub
・中身を担当するプロシージャ
Sub ValidateInput()
' 入力チェック
End Sub
👉 こうすることで、
処理全体が文章のように読めるようになります。
✅ SubとFunctionを分ける基準
次に悩みやすいのが、
SubにするかFunctionにするかです。
・判断基準は「戻り値が必要か」
- 結果を返したい → Function
- 実行するだけ → Sub
これが基本です。
参考:【VBA】メソッドの戻り値(返り値)とは?取得方法と活用例
・Functionにするべき例
Function GetLastRow(ws As Worksheet) As Long
GetLastRow = ws.Cells(ws.Rows.Count, 1).End(xlUp).Row
End Function
・Subにするべき例
Sub ClearSheet(ws As Worksheet)
ws.Cells.Clear
End Sub
✅ 同じ処理が2回出てきたら分ける
非常に分かりやすい基準です。
・NG例
Cells.Clear
Cells.Clear
・OK例
Call ClearSheet
Call ClearSheet
👉 重複=分割のサイン
と覚えておくと便利です。
✅ プロシージャの「粒度」をどう決めるか
分けすぎも問題になります。
・分けすぎの例
- 1行ごとにSub
- 名前が意味不明
- 呼び出しが多すぎる
・適切な粒度の目安
- 名前を見て役割が分かる
- 10〜30行程度が読みやすい
- コメントが不要なくらい明確
✅ ユーザーフォームを使う場合の分割基準
フォームを使うと、
設計の重要性が一気に上がります。
・やってはいけない例
Private Sub CommandButton1_Click()
' すべての処理を書く
End Sub
・正しい分割例
Private Sub CommandButton1_Click()
Call ExecuteRegister
End Sub
👉 フォームは「きっかけ」だけを担当します。
参考:【VBA】ユーザーフォームの基本構造と仕組みを初心者向けに徹底解説
✅ エラー処理は分けるべきか
結論から言うと、
分けるべきです。
・理由
- 本処理が読みにくくなる
- エラー対応を使い回せない
参考:【VBA】On Error Resume Nextでエラーを無視してエラーの制御|危険な理由
・設計例
Sub MainProcess()
On Error GoTo ErrorHandler
Call ExecuteMain
Exit Sub
ErrorHandler:
Call HandleError
End Sub
✅ 実務でよくある失敗パターン
・Mainが存在しない
→ 入口を1つにまとめる
・名前が抽象的すぎる
→ 動詞+目的語を意識する
・処理の順序が分からない
→ 流れ専用のSubを作る
✅ プロシージャ分割がもたらす最大のメリット
- 読みやすい
- 修正しやすい
- 再利用できる
- テストしやすい
これは、
コード量が増えるほど差が出ます。
✅ まとめ:プロシージャ分割は設計力そのもの
- 1プロシージャ1役割
- 行数ではなく意味で分ける
- 流れと中身を分離する
- 重複は分割のサイン
- フォーム・イベントは呼び出し専用
プロシージャをどう分けるかは、
VBAの「書き方」ではなく「考え方」です。
この基準を身につけることで、
あなたのVBAは、
- 壊れにくく
- 直しやすく
- 他人に伝わる
設計へと確実に進化します。