ノンプロアプリのテストは検算から考える

自分用・部門用VBAで品質を守るための現実的な確認設計

Copyright © 2026 LWP 山中 一弘

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

記事要約

VBAで作る自分用ツールや部門内ツールでは、業務システムと同じ水準のテスト仕様書、網羅的な単体テスト、自動テスト環境を求めると、ほとんどの場合で作業が止まります。ノンプロアプリは、作る人も使う人も業務担当者であり、開発工数も保守工数も限られています。そこに業務システム開発のテスト工程をそのまま持ち込むと、品質が上がる前に継続できなくなります。

ただし、これは「動けばよい」「確認しなくてよい」という話ではありません。むしろ、ノンプロアプリでは、テストという言葉よりも、結果が合っていることを確認する「検算」を中心に置いたほうが現実的です。手計算、ピボットテーブル、既存帳票、別手段の集計などを使い、最終結果と主要な中間結果を照合できる状態にします。

この記事では、ノンプロアプリに必要な品質確認を、テスト仕様書の網羅性ではなく、検算可能性、実データ確認、中間データ、利用範囲の限定という観点から整理します。自分だけが使うツール、部門内で使うツール、対価を受けて他者へ納品するツールでは、求める確認水準を分けて考える必要があります。

本記事の対象とゴール

想定読者

• Excel VBAで自分用または部門用の小さな業務ツールを作っている人

• ノンプロアプリにも単体テストやテスト仕様書が必要なのか迷っている人

• 業務マクロの確認作業が重くなりすぎて、開発や改善が止まりがちな人

• 「動いた」だけで終わらせず、結果の正しさを現実的に確認したい人

本記事で得られること

1. ノンプロアプリで、網羅的なテストより検算を優先すべき理由が分かります。

2. 自分用、部門用、受託・納品用で、品質確認の水準を分けて考えられます。

3. 手計算、ピボット、既存帳票、中間データを使った確認設計の型が分かります。

4. VBAコードを、検算しやすい構造へ寄せるための実務上の判断軸が得られます。

本記事で扱わないこと

• 大規模システム開発における正式なテスト工程の作り方

• テスト自動化フレームワークやCI環境の構築手順

• すべての条件分岐を網羅するテストケース設計

• 受託開発、外販ソフト、基幹システムと同等の品質保証手順

先に結論

ノンプロアプリでは、最初から業務システムと同じテスト工程を目指す必要はありません。まず必要なのは、結果が正しいと説明できる検算の仕組みです。

自分だけが使うVBAツールなら、全条件を網羅するテスト仕様書よりも、実データで処理し、手計算やピボットや既存帳票と照合し、出力が業務上正しいことを確認できるほうが重要です。作って動かすだけでも大変な段階で、形式的なテスト仕様書を要求すると、ツールそのものが作れなくなります。

一方で、他人から対価を受けて作る場合、または複数人が継続利用する場合は、話が変わります。その場合は、検算だけでなく、仕様、入力条件、例外、再実行、修正後確認を残す必要があります。つまり、テストを捨てるかどうかではなく、利用範囲と責任に合わせて、確認方法を選ぶことが大切です。

第1章 ノンプロアプリに業務システムのテストをそのまま持ち込まない

1.1 ノンプロアプリは開発条件が違う

ノンプロアプリは、業務担当者が自分や自部門の作業を楽にするために作る小さなアプリです。多くの場合、専任の開発者、レビュー担当、テスト担当、保守担当が分かれているわけではありません。作る人は、通常業務を持ちながら、必要に迫られてVBAを書きます。

この条件で、業務システム開発と同じようにテスト仕様書を書き、条件分岐を洗い出し、修正のたびに再テストし、カバレッジを上げる運用を要求すると、ほとんどの場合で破綻します。品質を上げるための作業が、実際には改善を止める要因になります。

ノンプロアプリでは、まず「何を確認できれば業務上困らないか」を決めるべきです。形式としてのテスト工程を先に置くのではなく、業務結果の正しさを確認する方法から考えます。

1.2 テスト仕様書を書くこと自体が重い

テスト仕様書は、単に表を作ればよいものではありません。入力条件、正常系、異常系、境界値、分岐、事前状態、期待結果、確認方法を決める必要があります。小さなVBAツールでも、条件分岐が増えれば、確認すべき組み合わせはすぐに増えます。

さらに、ノンプロアプリは修正が多発します。使いながら改善するため、列が増える、入力形式が変わる、例外処理が増える、出力先が変わる、といった変更が起きます。そのたびに正式なテスト仕様書を更新し、再テストする運用は、コストに見合わないことが多いです。

ここで大切なのは、テスト仕様書を否定することではありません。必要な場面では当然役に立ちます。しかし、自分用・部門用の小さなツールでは、最初の品質確認の中心に置くには重すぎることがあります。

1.3 「動く」と「合っている」は違う

だからといって、「ボタンを押してエラーが出なければよい」という確認では足りません。VBAツールで本当に怖いのは、止まることよりも、間違った結果を正常そうに出すことです。

集計結果が1行ずれている。対象外データが混ざっている。日付条件が1日ずれている。税込と税抜が混在している。こうした誤りは、アプリが止まらなくても業務結果を壊します。

ノンプロアプリで優先すべき確認は、「アプリが落ちないか」よりも「出た答えが合っているか」です。これが、テストより検算を中心に置く理由です。

第2章 検算を品質確認の中心に置く

2.1 検算とは何をすることか

ここでいう検算は、プログラムの内部構造をすべて確認することではありません。別の手段で同じ業務結果を作り、VBAの出力と照合することです。

たとえば、売上集計マクロであれば、次のような確認が考えられます。

• 元データの件数と、処理対象件数が合っているか

• ピボットテーブルで集計した金額と、マクロ出力の金額が合っているか

• 既存帳票の合計値と、新しい出力の合計値が合っているか

• 手計算できる少数サンプルで、1件ずつ処理結果が合っているか

• エラー対象や除外対象の件数が説明できるか

これは、正式な単体テストとは違います。しかし、業務担当者が自分の責任で結果を判断するには、非常に強い確認方法です。業務上の正しさは、コード行ではなく、データと結果で確認されるからです。

2.2 実データを使う理由

ノンプロアプリでは、きれいなテストデータだけで確認しても足りません。現場のデータには、空白、表記ゆれ、例外行、想定外の文字、古いコード、手入力ミスが含まれます。実際に処理するデータに近いもので確認しないと、業務で使った瞬間に壊れます。

もちろん、本番データをそのまま壊してはいけません。元データは読み取り専用にし、コピー、スナップショット、中間シートを使って確認します。ここで既存記事の「中間データ設計」の考え方が効いてきます。処理途中のデータを残しておけば、どこで件数や金額が変わったのかを後から追えます。

実データによる検算は、単に最後の出力を見るだけではありません。入力、整形、抽出、集計、出力の各段階で、件数、合計、除外理由を確認できるようにします。

2.3 手計算、ピボット、プログラムを併用する

検算では、同じ方法をもう一度繰り返しても意味が薄くなります。VBAのロジックが間違っている場合、同じロジックを使った確認では同じ間違いを再生するだけです。

そのため、確認には別の手段を混ぜます。少数データは手計算で確認します。大量データはピボットテーブルで件数や合計を確認します。複雑な変換は、処理前後の中間データを見比べます。既存帳票があるなら、その数字とも突き合わせます。

大切なのは、VBAとは別の見方で答えを見ることです。プログラムを信じるのではなく、業務データの形で確認します。

第3章 テストを捨てるのではなく、検算のために絞る

3.1 最小限のテストは必要になる

検算を中心に置くといっても、テストがまったく不要になるわけではありません。検算を正しく行うために、最低限の動作確認は必要です。

たとえば、入力ファイルがない場合に止まるか、空データで異常終了しないか、対象外データを除外できるか、出力先を間違えないか、といった確認は必要です。これらを確認しないと、そもそも検算するための出力が信用できません。

ただし、この確認は「すべての条件を網羅する」ためではありません。検算できる状態を作るための最低限の確認です。ここで目的を取り違えると、ノンプロアプリには重すぎるテスト工程になります。

3.2 条件カバレッジより業務上の危険度を見る

条件分岐があると、すべての分岐を確認したくなります。しかし、ノンプロアプリでは、分岐の数よりも業務上の危険度を優先します。

金額が変わる分岐、対象件数が変わる分岐、データを削除または上書きする分岐、外部ファイルへ出力する分岐は優先して確認します。逆に、表示メッセージや補助的な見た目の分岐は、確認水準を下げてもよい場合があります。

品質確認の目的は、形式的な網羅率を上げることではありません。業務上困る誤りを減らすことです。ノンプロアプリでは、この割り切りが重要です。

3.3 修正後確認は「影響した答え」を見る

VBAツールは修正しながら育ちます。修正のたびに全テストをやり直すのが理想に見えるかもしれませんが、自分用・部門用ツールでは現実的でないことが多いです。

その代わり、修正で影響する入力、処理段階、出力を明確にし、その範囲の答えを検算します。列追加なら列の値を確認します。条件変更なら対象件数と除外件数を確認します。集計式変更なら合計値と明細数を確認します。

このためには、処理の途中を見える形にしておく必要があります。中間シート、ログ、件数表、差分表は、ノンプロアプリにおける現実的な再テスト手段になります。

第4章 利用範囲で品質確認の水準を変える

4.1 自分だけが使うなら検算中心でよい

自分だけが使うツールでは、自分が業務内容を理解し、自分で結果を見て、自分で修正できます。この場合、正式なテスト仕様書よりも、結果をすぐに検算できることのほうが重要です。

自分用ツールでは、アプリが途中で止まっても、原因を見て直せるなら大きな問題にならないことがあります。むしろ、止まらずに誤った結果を出すほうが危険です。したがって、止まらないことより、間違った結果を見逃さないことを優先します。

4.2 部門内で使うなら確認手順を残す

部門内で複数人が使う場合は、自分用より一段上の確認が必要です。使う人が作者ではないため、何を見れば正しいかを共有しなければなりません。

この段階では、詳細なテスト仕様書でなくても、確認手順メモを残します。たとえば、実行前に見る入力件数、実行後に見る出力件数、ピボットで確認する合計値、エラー一覧の見方、再実行時の注意点などです。

確認手順メモは、ノンプロアプリにおける軽量なテスト仕様書です。大げさな文書でなくても、誰が見ても同じ確認ができる形にしておくことが重要です。

4.3 対価を受けるならテストを省略できない

他人から対価を受けて作る場合、または外部へ納品する場合は、検算中心だけでは足りません。作者と利用者の責任が分かれ、業務影響も作者だけでは吸収できないからです。

この場合は、仕様、前提、入力条件、例外、確認結果、修正履歴を残す必要があります。テスト仕様書や受入確認、再現手順、障害時の切り分けも必要になります。ここでは、ノンプロアプリだからといってテストを捨てることはできません。

つまり、「テストをしない」のではありません。自分用なら検算中心、部門用なら確認手順つき、受託・納品用なら正式な確認工程つき、と水準を変えるのです。

第5章 検算しやすいVBAにするための設計

5.1 入力、処理、出力を分ける

検算しやすいVBAにするには、コードの構造も変える必要があります。最も基本になるのは、入力、処理、出力を分けることです。

シートから値を読み込む処理、配列や辞書で計算する処理、シートへ書き戻す処理を分けると、どこで値が変わったかを追いやすくなります。処理本体だけを小さなデータで確認することもできます。

これは、正式な単体テストのためだけではありません。検算するときにも有効です。入力データ、中間データ、出力データが分かれていれば、業務担当者でも途中結果を見て確認できます。

5.2 中間データを残す

ノンプロアプリでは、中間データを残すことが強い品質対策になります。たとえば、次のようなシートを分けます。

• Raw_Import: 取り込み直後の元データ

• Step1_Cleansed: 整形・補正後のデータ

• Step2_Filtered: 対象抽出後のデータ

• Check_Summary: 件数、合計、除外数の確認表

• Final_Output: 最終出力

この構造にすると、最終結果だけでなく、途中で何件減ったか、どの条件で除外されたか、合計値がどこで変化したかを追えます。検算のための材料が自然に残ります。

5.3 確認表を出力する

ノンプロアプリでは、最終帳票だけでなく、確認表を出力するのが有効です。確認表には、処理対象件数、除外件数、金額合計、日付範囲、入力ファイル名、処理日時、エラー件数などを出します。

確認表があれば、使う人は毎回同じ観点で結果を見られます。これは、テスト仕様書を毎回開くよりも現実的です。実行結果そのものに確認観点を埋め込むことで、検算が運用に組み込まれます。

第6章 ノンプロアプリの品質は現実から設計する

6.1 完璧なテストより続く確認

ノンプロアプリの品質を守るには、完璧なテストを目指すより、続けられる確認を設計するほうが効果的です。毎回できない確認は、結局やられなくなります。

確認は、短く、具体的で、業務結果に直結している必要があります。件数を見る。合計を見る。サンプル明細を見る。除外理由を見る。前回結果との差を見る。このような確認は、形式的なテスト項目よりも現場で続きやすくなります。

6.2 品質を上げるとは、説明できる状態にすること

ノンプロアプリの品質は、コードがきれいかどうかだけでは決まりません。結果がなぜそうなったかを説明できるかどうかで決まります。

入力データ、処理条件、中間結果、最終出力、確認表が残っていれば、間違いが起きたときにも追跡できます。逆に、最終出力だけが残り、途中の状態が何も分からないと、正しいかどうかも、どこが間違ったかも判断できません。

検算とは、品質を人間が説明できる状態にすることです。ノンプロアプリでは、この説明可能性が最も重要な品質保証になります。

6.3 テストという言葉に縛られない

テストという言葉は便利ですが、重い言葉でもあります。正式なテスト工程を想像すると、ノンプロアプリでは現実離れしてしまうことがあります。

そこで、まず「検算できるか」と問い直します。出力は別手段で確認できるか。中間データは見えるか。件数と合計は追えるか。修正後に影響範囲を確認できるか。部門内の人が同じ確認を再現できるか。

この問いに答えられるなら、ノンプロアプリとしては強い品質確認になります。テストを捨てるのではなく、検算を軸にして、必要なテストだけを選びます。

まとめ

ノンプロアプリに、業務システムと同じテスト工程をそのまま求める必要はありません。自分用・部門用のVBAツールでは、網羅的なテスト仕様書よりも、実データを使って結果を検算できることが重要です。

ただし、確認を省略してよいわけではありません。むしろ、ノンプロアプリでは、結果が合っていることを説明できる確認が必要です。手計算、ピボット、既存帳票、中間データ、確認表を使い、業務結果の正しさを別手段で照合します。

利用範囲によって確認水準は変わります。自分用なら検算中心、部門用なら確認手順つき、受託・納品用なら正式なテスト工程つきです。この線引きを持つことで、ノンプロアプリの開発は現実的になり、品質確認も続けられます。

テストという言葉に縛られず、検算できるアプリを作る。これが、ノンプロアプリにおける最初の品質設計です。

出典メモ

• 元URL: https://togetter.com/li/1835961

• 正規URL: https://posfie.com/@hoehoe1234/p/vAjgZNC

• 元タイトル: 2022-01-25 VBA ノンプロアプリのテストはどうあるべきか - posfie

• 投稿者: @hoehoe1234

• 主な投稿日時: 2022-01-23 22:46:33 から 2022-01-23 22:57:31

• 取得日: 2026-06-11

• 参照した既存LWP公開記事: 記事008_マクロ中間データ設計論250507.md、記事015_マクロ内製化のための設計手法250521.md、記事038_マクロにおける手法とは何か250706.md