自作ツールと業務用ツール、どこまでテストすれば十分？

Excel（エクセル）のマクロやPython（パイソン）で作った小さなツールでも、仕事に使うならテストは必要です。ただし、企業向けの大規模システムと同じ量のテストをすべてに実施するのは現実的ではありません。

私がまず整理したいのは、**「自作か外注か」ではなく、「間違えたときに何が起きるか」**という点です。個人の集計表なら手作業で修正できても、請求額の誤計算や取引先への一括誤送信は、後から取り消すだけでは済みません。

この記事では、テストをどこまで行うかの判断基準と、依頼・納品時に確認しておきたい具体的な項目を紹介します。

「一度動いた」は、仕事で使える証明にはならない

例えば、売上CSV（シーエスブイ）を読み込んで月次集計するツールを考えます。10行のサンプルを読み込み、合計金額が画面に出た。この時点で確認できたのは、その10行、その形式、その環境では処理できたという事実だけです。

実際の業務では、金額欄の空白、重複した明細、列の順番の変更、開けないファイル、前月より多いデータが発生します。正常な入力だけを試しても、こうした条件での動きはわかりません。

さらに問題なのは、処理が止まる不具合だけではありません。エラー表示が出ないまま、間違った集計結果を保存する不具合です。人が気づかずに請求や発注へ使えば、影響が広がります。

必要なテストは「影響」と「戻せるか」で決める

テスト項目を増やす前に、次の三つを確認します。第一に、計算や出力が誤ったときの損失。第二に、誰が何人で利用するか。第三に、失敗後に元の状態へ戻せるかです。

① 個人の補助ツール：最小限を確実に

自分だけが使い、元データを変更せず、結果を目で確認してから使うツールなら、正常な入力・空データ・想定外の形式・出力結果の照合を優先します。再実行してもファイルが不必要に増えないかも確認すると安心です。

② チームで使う業務ツール：例外と環境差まで

複数人が使い、月末など決まった時期に繰り返すツールでは、担当者の操作違い、ファイル名・保存先の違い、処理件数の増加、二重実行を試します。利用するExcelの版やWindows環境に差があるなら、対応範囲を明確にします。

③ 金額・個人情報・外部送信を扱うツール：事故を防ぎ、復旧まで

請求、給与、在庫の確定、顧客情報の更新、メール一括送信などは、権限、誤操作防止、途中失敗後のデータ整合性、再実行時の重複防止、ログ（記録）、バックアップからの復旧まで検討します。必要に応じて、別の担当者による受入確認も行います。

図1：テストの量を一律に増やすのではなく、事故の影響と復旧の難しさに合わせて確認範囲を増やす考え方。

これは法律や業界共通の「3段階認定」ではなく、小規模な業務ツールのための実務上の整理です。同じExcelファイルでも、給与計算に使うなら高い水準の確認が必要になります。

CSV集計ツールなら、何をテストする？

例として、取引先別の売上を集計するツールを考えます。入力データが「田中商事：12,000円」「鈴木商事：8,000円」「田中商事：3,000円」の3行なら、合計は23,000円、田中商事の小計は15,000円です。このように、先に正解を決めてから出力と照合します。

私なら、最低限次の条件を用意します。

・ 通常データ：件数、合計額、取引先別小計が一致するか。

・ 空欄・不正値：金額が空、文字が混ざる場合に止めるのか、除外するのか。除外するなら理由が残るか。

・ 重複：同じ伝票番号が2回あったときの扱いが、業務ルールどおりか。

・ 0件・大量データ：データなしで異常終了しないか。想定する最大件数でも処理できるか。

・ 保存エラー：出力先がない、権限がない、ファイルが開かれている場合にどう知らせるか。

・ 途中失敗・再実行：中断した後にやり直しても、二重計上や元データの破損が起きないか。

重要なのは、重複を「必ず削除する」と決めつけないことです。同じ取引先・同じ金額でも別の売上かもしれません。伝票番号などを使った識別方法と、検出後の扱いを先に決める必要があります。

境界値（きょうかいち）の確認も有効です。例えば取込件数の上限を1,000行と定めるなら、999行・1,000行・1,001行を試します。この手法は、ISTQB（アイエスティーキュービー）のテスト技法でも説明されています。

「動作確認」と「受入テスト」は別の仕事

制作側が行う動作確認では、個々の計算やファイル処理が仕様どおりか、組み合わせたときに問題がないかを調べます。Pythonなら自動テストを用意できる場合もあり、Excelマクロならテスト用ブックを使って結果を照合できます。

一方、受入テストでは利用者が実際の業務手順で、期待どおりの成果物ができるかを確認します。例えば「集計結果の合計が合う」だけでなく、「経理担当者が毎月の手順だけで操作でき、必要な帳票が指定の場所に出る」までが対象です。

つまり、開発者のパソコンで一度動いたことと、利用者の業務で使えることは同じではありません。納品前に、対象のOS（オーエス）、Excelの版、ファイル配置、権限などを確認する意味がここにあります。

失敗したときの設計が、テストの価値を左右する

「エラーが出ないようにする」だけでは十分ではありません。発生したエラーが、誤った結果を確定させないことも重要です。

例えば、100件の請求書を生成する処理が60件目で止まった場合、最初の59件は保存済みなのか。再実行すると同じ請求書が二重に作られないか。送信済みと未送信を区別できるか。こうした点は、ボタンを押して正常終了するテストだけではわかりません。

削除や更新を伴う場合は、複製したテストデータで検証し、元データの保護やバックアップの復元手順を確認します。外部システムと連携するWebツールでは、入力内容の検証だけでなく、サーバー側の権限確認や処理順序も必要です。OWASP（オワスプ）のWebアプリ検証基準でも、入力妥当性と業務ロジックを重要な確認対象としています。

「何件テストしたか」より、確認範囲を残す

50件テストしてすべて成功したとしても、重要な処理を一度も試していなければ意味が薄くなります。反対に、機能が単純なツールなら、少数でも正常・異常・境界・復旧を押さえたテストが合理的な場合があります。

納品時には、少なくとも確認した条件、期待結果、実際の結果、未確認の条件がわかるようにしておくと、使い始めた後の認識違いを減らせます。「テスト済み」という一言より、何を試したのかが大切です。

特に確認したいのは、使用する入力形式、対応環境、データ量、エラー時の挙動です。未確認のOSや外部サービスの将来の仕様変更まで、動作保証したことにはできません。

外注するなら、テスト範囲も見積り条件に入れる

業務ツールの開発を依頼するときは、機能だけでなく、どのデータで何を確認するかも共有すると見積りが具体的になります。

例えば「CSVを集計してほしい」だけでは、正常データの処理なのか、壊れたファイルへの対応まで必要なのかがわかりません。「月に約5,000行、列の追加があり得る、元データは上書きしない、異常行は一覧に出す」と伝えれば、必要な処理とテストを判断しやすくなります。

私は、細かい仕様書がなくても、入力例・正しい出力例・困る失敗例の三つがあると、確認範囲を整理しやすいと考えています。機密情報を渡す必要はなく、匿名化したサンプルでも十分に検討できる場合があります。

自作する場合も外注する場合も、目指すべきは「バグがゼロ」という証明ではありません。業務にとって重要な失敗を想定し、何を確認し、何が未確認かを明らかにした状態で使い始めることです。