稼働日の午前9時。スタッフが一斉にシステムにログインしようとして、エラー画面が広がった。
管理部門の担当者だった田中（仮名）は、その瞬間のことを今でも鮮明に覚えている。「画面が真っ白になって、ログインできないというメッセージだけが出ていました。最初はネットワークの問題だと思ったんですが、違いました」。
そのシステムは、受注管理の効率化を目的として約3ヶ月かけて開発されたものだった。導入費用は280万円。中小企業にとっては決して小さくない投資だった。
問題はその2ヶ月前にさかのぼる。開発会社との打ち合わせで、テスト工程の期間が議題に上がった。当初の計画では2週間を確保していたが、予算の上限が見えてきた段階で「テストは3日でやります」という話になった。「開発会社の担当者が『大丈夫です、しっかり確認します』と言っていたので、そのまま合意してしまいました」。
その判断が、3ヶ月にわたる混乱の入口になった。
何が起きたか
受注管理システムの導入は、手作業でのExcel管理からの脱却を目指すプロジェクトだった。注文データの入力、在庫との連携、請求書の自動生成。これらをひとつのシステムで完結させることができれば、毎日2時間かかっていた作業が30分に短縮できるはずだった。
開発はおおむねスケジュール通りに進んだ。画面の見た目も、デモ環境での動作も問題なかった。本番稼働の前日、開発会社から「テスト完了しました」という連絡が来た。その夜、田中は翌朝からの運用を心待ちにしていた。
しかし稼働後1週間で、深刻な問題が表面化した。特定の条件、具体的には同日に同じ顧客から複数の注文が入った場合に、後から入力したデータが消えてしまうバグだった。最初は「入力ミスだろう」と思っていたが、何度確認しても再現する。データが消えているのではなく、上書きされていたのだ。
原因を調査した結果、テスト環境では「1顧客1日1注文」のパターンしか確認していなかったことが判明した。実際の業務では頻繁に発生する「同日複数注文」のケースを、3日間のテストでは一度も試していなかった。本番環境で初めてそのパターンが発火した。
バグが発覚してから2週間、システムは実質的に使えない状態が続いた。その間、スタッフは「バグがあるかもしれないシステム」を使いながら、手動でデータの整合性を確認するという二重作業を強いられた。結局、開発会社による修正と再テストが完了するまでに3ヶ月を要した。その間は旧来のExcel管理に完全に逆戻りした。
「テストを削れば安くなる」の本当のコスト
あのとき、テスト工程を圧縮することで削減できた費用はいくらだったか。開発会社の見積書を確認すると、テスト工程の費用は約50万円だった。「それが浮いたから良かった」とは、とても言えない状況になった。
その後に発生した費用を整理すると、以下のようになる。
バグの調査と修正：開発会社への追加費用として約80万円が発生した。契約上の瑕疵担保責任の範囲については争いになり、最終的に折半という形で決着した。
スタッフの対応工数：バグが発覚してから修正が完了するまでの3ヶ月間、毎日1〜2時間の追加作業が発生した。社員3名が関与していたとすると、月60〜120時間の余分な工数となる。時給換算すれば、3ヶ月で100万円を超える人件費ロスだ。
取引先への対応：注文データが消えていた事実が取引先に判明したケースでは、個別に謝罪と確認作業が必要になった。信頼の問題は金額で換算できない。
結果として、50万円を節約するために200万円以上のコストが発生した。見積書の上で安くなったものが、現場では何倍にもなって返ってきた。
なぜテスト削減を受け入れてしまったのか
あの判断を振り返ったとき、田中が最初に口にするのは「仕方がなかった」という言葉だ。しかし少し話を聞くと、その「仕方がなかった」の中身が見えてくる。
「開発会社が大丈夫と言っていたから」。これは理由ではない。開発会社は「仕様通りに動くか」を確認するのが仕事であって、「この会社の業務で本当に使えるか」を判断できる立場にはない。「大丈夫」という言葉を鵜呑みにしたのは、判断を相手に委ねた行為だった。
「予算が厳しかったから」。これも理由ではない。予算が厳しいならば、機能を削るか、スケジュールを延ばすか、あるいは別の資金調達を検討するかという選択肢があった。テスト工程を削るという選択は、リスクを先送りにしただけだった。
「早く稼働させたかったから」。これも同様だ。3ヶ月後に逆戻りするシステムを早く動かすことに、意味はなかった。
買い手の負荷を引き受けるのが商売の本質だとすれば、この開発会社は納期とコストを最優先にした結果、顧客が本来負うべきでないリスクを引き受けさせた。しかし発注者側も、相手の言葉を真に受けることで判断を外注してしまっていた。テスト削減に同意したのは、その判断を放棄した結果だった。
テスト工程で何を確認すべきだったか
単体テスト・結合テスト・受入テストの違い
テストにはいくつかの段階がある。混同されやすいが、それぞれが確認する対象が異なる。
単体テストは、個々の機能や部品が設計通りに動くかを確認するものだ。注文登録ボタンを押したとき、データベースに正しく書き込まれるか、といったレベルの確認をする。
結合テストは、複数の機能が組み合わさったときに正しく動くかを確認するものだ。注文を登録したとき、在庫数が連動して減るか、請求書の生成に正しいデータが渡されるか、といった確認をする。
受入テストは、実際の業務シナリオの中でシステムが使えるかを確認するものだ。「月末に大量注文が来たとき」「同じ顧客から同日に複数回注文が来たとき」「キャンセルと再注文が短時間で発生したとき」。こうした現場特有のシナリオを使って確認する。
「受入テスト」は発注者がやるべき理由
今回のケースで抜け落ちていたのは、この受入テストだった。
開発会社のテストは「仕様通りに動くか」を確認するものだ。契約した仕様に基づいて機能を作り、その仕様通りに動いていれば、開発会社の仕事は完了している。しかし「仕様書に書かれていなかった業務シナリオ」は、開発会社には確認のしようがない。
発注者のテストは「自社の業務で使えるか」を確認するものだ。現場のスタッフが実際の業務データを使って操作してみて、「こういう使い方をしたらどうなる」を試す。このテストができるのは、その業務を知っている発注者だけだ。
この2つは別物だという認識が、あの現場には欠けていた。「開発会社がテスト完了と言ったから大丈夫だろう」という思い込みが、受入テストをスキップさせた。
同じ失敗を防ぐために発注前に決めること
テスト工程を削ることで起きる問題は、今回の事例に限らない。システム開発において、テストは「あれば丁寧、なくても動く」というものではなく、「なければ必ず何かが発覚する」というものだ。同じ失敗を避けるために、発注前に確認しておくべきことがある。
1つ目は、テスト仕様書を契約前に確認することだ。「テストします」という言葉だけでは何も分からない。「何を」「どのような手順で」「どういう結果になれば合格か」を文書化したものを求めるべきだ。テスト仕様書がない開発会社は、テストをしていないか、「やった気になっている」かのどちらかだ。
2つ目は、受入テストの期間を契約に明記することだ。「稼働後に問題が出たら対応する」という取り決めではなく、「稼働前に発注者が確認する期間として○週間を設ける」と明文化しておく。受入テストの期間中は本番稼働を始めない、という合意が重要だ。
3つ目は、本番稼働前に「最悪のケース」を想定した動作確認をすることだ。業務の中で「こういうことが起きたらシステムはどう動くか」という最悪のシナリオを5〜10個洗い出し、それをすべて試す。異常系のテストを怠らないことが、本番環境での予期せぬバグを防ぐ。
4つ目は、テスト費用を削らないことだ。削るとしたら機能を削る方が健全だ。実装した機能が正しく動くかを確認しないまま本番投入するのは、設計図だけ見て建物に入るようなものだ。テストにかけるコストは、リスクを金で買う行為だと理解しておく必要がある。
よくある質問
- Q: テストにはどのくらいの期間が必要ですか？
- システムの規模によって異なるが、中小企業向けの業務システムであれば開発期間の20〜30%が目安だ。3ヶ月の開発であれば、テストに2〜4週間を確保するのが現実的だ。「開発が終わったら即稼働」という計画はリスクが高い。受入テストの期間は別途1〜2週間を設けることを勧める。
- Q: 開発会社に「テストは万全です」と言われたら信じていいですか？
- その言葉は「仕様に基づくテストは完了した」という意味で受け取るべきだ。発注者側の業務シナリオで確認したわけではない。「テストは万全」という言葉を聞いたら、「何をどのようにテストしたか」「テスト仕様書を見せてもらえるか」と確認するのが適切な対応だ。
- Q: 稼働後にバグが出た場合、修正費用は誰が負担しますか？
- 契約内容による。多くの場合、契約に「瑕疵担保責任」として稼働後一定期間内のバグ修正は無償対応という条項が入っている。ただし「仕様に記載されていなかった動作」については有償になるケースがある。今回のケースのように費用負担が争点になることを防ぐには、受入テストを通じて稼働前に問題を発見しておくことが最善だ。
読んで気になることがあれば、まず話だけでも。
まず、業務を聞かせてください →