システム開発のテスト・品質保証とは｜発注者が知るべき基礎と受入テスト

「発注したシステムが、本当にちゃんと動くのか不安」——初めてシステム開発を依頼する方の多くが、この不安を抱えます。開発会社が「テストしました」と言っても、何をどう確かめたのか、発注側は何をすればいいのか、見えにくいものです。この記事では、システム開発のテストと品質保証を発注者の目線でやさしく整理します。テストの種類、発注側が行う受入テストのやり方、費用に占める割合、そして検収との関係までを一通り押さえておけば、「動くはずのものが動かない」トラブルを大きく減らせます。

最初に結論だけお伝えすると、テストは開発会社に任せきりにするものではありません。発注者にしかできない確認があり、そこを飛ばすと納品後にトラブルが起きやすくなります。難しい知識は不要です。「自分の業務で本当に使えるか」を実際に触って確かめる、それが発注側のテストの本質です。

なぜテストが重要か：不具合が業務に与える被害

システムの不具合（バグ）は、単に「動かなくて不便」で済まないことがあります。業務で使うシステムだからこそ、間違った動作はお金・信用・時間に直結します。

• 金額の誤り：請求額や在庫数が間違って計算され、過大請求や欠品につながる
• データの消失・破損：入力した情報が保存されない、上書きされて消える
• 業務の停止：肝心な場面でエラーが出て、現場の作業が止まる
• 信用の低下：顧客に誤った情報を表示し、クレームや取引停止に発展する

こうした被害は、公開してから見つかると修正に何倍もの手間がかかります。テストとは、こうした問題をお客様や現場に届く前に見つけて潰す工程です。作る作業と同じくらい、確かめる作業が大切だという前提を、まず共有しておきましょう。

不具合は「見つかったタイミングが遅いほど、直す費用が高くなる」という性質があります。要件定義の段階で気づけば口頭で直せますが、公開後に見つかると、原因調査・修正・再テスト・データの手直しまで発生します。だからこそ、公開前のテストに時間を使うことが、結果的に一番安くつくのです。

なお「テスト」と似た言葉に「品質保証（QA）」があります。テストが「実際に動かして問題を見つける作業」であるのに対し、品質保証はもう少し広く、設計の段階から公開後まで、品質を保つための取り組み全体を指します。とはいえ発注者としては、両者を厳密に分けて理解する必要はありません。「良いものを、確かめながら作って、公開後も直せる状態にしておく一連の取り組み」とざっくり捉えておけば十分です。

テストの種類をやさしく整理する

開発会社が行うテストにはいくつかの段階があります。専門用語が並びますが、意味はシンプルです。小さな部品から順に、だんだん大きな単位で確かめていく、と覚えてください。

テストの種類	何を確かめるか	主に行う人	たとえるなら
単体テスト	一つひとつの機能・部品が正しく動くか	開発会社	部品単体の動作確認
結合テスト	機能どうしをつないで正しく連携するか	開発会社	部品を組み合わせた確認
システムテスト	システム全体が要件どおり動くか	開発会社	完成品全体の確認
受入テスト（UAT）	実際の業務で問題なく使えるか	発注者	お客様による最終確認

前の3つ（単体・結合・システム）は開発会社の責任範囲で、発注者が細かく関わる必要はありません。一方で、最後の受入テスト（UAT）だけは発注者が主役です。作った側では気づけない「実際の業務の都合」を確認できるのは、その業務を毎日やっている発注者だけだからです。

発注側が行う受入テスト（UAT）のやり方

受入テスト（UAT）とは、納品前に発注者が実際にシステムを触り、「自分たちの業務で本当に使えるか」を確認する工程です。専門知識はいりません。普段の仕事を、そのままシステム上でやってみるのが基本のやり方です。

進め方は次の順番が分かりやすいです。

1. 代表的な業務の流れを一通りやってみる（例：注文を受ける→登録する→帳票を出す）
2. 正しい使い方だけでなく、間違った使い方も試す（空欄のまま登録、誤った金額の入力など）
3. 数字や出力が実際の業務と合っているか突き合わせる（合計金額、在庫数、帳票の内容）
4. 見つけた問題を記録して開発会社に伝える（どの画面で・何をしたら・どうなったか）

確認するときの観点は、次の表を目安にすると漏れが減ります。

確認の観点	具体的なチェック内容
正常に動くか	普段の作業が最初から最後まで止まらず完了するか
想定外に強いか	空欄・誤入力・大量データでも壊れないか
数字が合うか	合計・在庫・請求額などが手計算やExcelと一致するか
使いやすいか	現場の人が迷わず操作できるか、手順が多すぎないか
権限が正しいか	見せたくない情報が別の担当者に見えていないか

大事なのは、責任者一人ではなく、実際に使う現場の人にも触ってもらうことです。作った人・発注担当者は「正しい使い方」で試しがちですが、現場では想定外の操作が必ず起きます。問題を報告するときは「エラーが出た」だけでなく、「どの画面で・何をしたら・どうなったか」をセットで伝えると、修正が速く正確になります。

受入テストを効果的に進めるには、あらかじめ「試すべき業務のリスト」を用意しておくのがおすすめです。頭の中で思いついた操作だけを試すと、どうしても抜けが出ます。「毎日やること」「月末だけやること」「たまにしか起きないが起きると困ること」を書き出し、それぞれをシステムでなぞってみると、確認の抜け漏れがぐっと減ります。とくに「月末の締め処理」「年に一度の棚卸し」のような頻度は低いが重要な業務は、公開後まで気づかれずに不具合が残りやすい部分なので、意識して試しておきましょう。

一般化ミニ事例：例えば、受注管理システムを導入したある会社では、通常の受注入力は問題なく動いていましたが、受入テストで「同じ商品を大量にまとめて登録する」操作を試したところ、合計金額の計算がずれることが判明しました。日常業務では起きにくい操作でしたが、月に数回の大口注文で必ず使う機能だったため、公開前に見つけられたことで実害を防げました。現場の人が「うちだと、たまにこういう入れ方をする」と試したことが発見につながった好例です。

テスト工程が費用・期間に占める割合

「テストにそんなに時間をかけるの？」と驚く方もいますが、テストは開発の中でも大きな比重を占めます。目安として、テスト工程は開発全体の2〜4割程度を占めるのが一般的です。

開発の工程	全体に占めるおおよその目安
要件定義・設計	2〜3割
開発（実装）	4〜5割
テスト・品質保証	2〜4割

この割合を知っておくと、見積もりの見方が変わります。極端に安い見積もりは、テスト工程が省かれている可能性があります。作る費用は同じでも、確かめる工程を削れば、その分だけ公開後に不具合が出やすくなります。安さの裏にテスト不足が隠れていないか、見積もりの内訳で確認しておきましょう。

当社の一律料金（スタンダード100万円／プロ200万円・追加費用なし・着手前に総額確定）には、このテスト・品質保証の工程も最初から含まれています。「テストは別料金」「不具合対応で追加請求」といったことが起きないよう、総額に組み込んで提示しています。

テストが不十分だと実際に起きること

テストを省いたり急いだりすると、公開後に次のような形で問題が表面化します。いずれも「作っているときは気づかなかった」ものばかりです。

• 公開直後にエラーが多発し、現場が混乱して手作業に逆戻りする
• 特定の条件でだけ数字が狂う（月末だけ、特定の商品だけ計算が合わない）
• 大量のデータを入れると急に遅くなる・止まる
• 一部の人にだけ不具合が出る（古い端末、特定のブラウザなど）
• 修正のたびに別の場所が壊れる（直したつもりが新しい不具合を生む）

これらは公開後に見つかると、原因調査から修正・再確認・データの手直しまで発生し、対応に時間もお金もかかります。しかも現場の信頼を一度失うと、「またバグでは」と使ってもらえなくなることもあります。だからこそ、公開前のテストに十分な時間を確保することが、遠回りに見えて一番の近道なのです。開発が遅れがちな理由や進め方については、システム開発のスケジュールの記事もあわせて参考にしてください。

システムの種類ごとに気をつけたいテスト観点

一口にシステムといっても、扱う内容によって「絶対に間違えてはいけないポイント」は変わります。受入テストのときは、自分のシステムがどこに神経を使うべきかを意識すると、確認が的確になります。

システムの例	とくに念入りに確認したいこと
販売・在庫管理	金額・在庫数の計算、値引きや返品などの例外処理
予約・受付	同じ時間帯の重複予約、キャンセル・変更時のデータ整合
会員・顧客管理	個人情報の表示範囲、権限による見え方の違い
帳票・集計	合計値が実際の数字と一致するか、月またぎの集計
申込・問い合わせフォーム	未入力・誤入力時の動き、送信された内容の受け取り

いずれにも共通するのは、お金・数・個人情報にかかわる部分は特に厳しく確認するということです。見た目のデザインより先に、こうした「間違うと実害が出る部分」から確かめていくと、限られた時間でも重要な不具合を優先的に潰せます。

バグはゼロにならない前提と付き合い方

ここで正直にお伝えしておきたいのは、どれだけ丁寧にテストしても、バグを完全にゼロにはできないという事実です。システムは想定できるすべての使い方を試し尽くすことが現実的に不可能なため、公開後に小さな不具合が見つかることは、どんな開発でも起こり得ます。

大切なのは「バグをゼロにする」ことではなく、次の2つです。

• 業務に致命的な不具合を残さない（お金・データに関わる重大なものは公開前に潰す）
• 見つかったときにすぐ直せる体制がある（公開後の保守・改修が用意されている）

つまり、テストは「完璧を目指す」のではなく「重大なものを確実に潰し、残りは付き合っていく」という考え方が現実的です。そのため、公開後の保守・改修の体制が重要になります。誰に・どう連絡すれば・いつまでに直してもらえるのかを、発注の段階で確認しておきましょう。公開後の費用感についてはシステム開発の保守費用の記事で詳しく解説しています。

なお、公開直後の一定期間を「様子見期間」として設けておくのも有効です。人が実際に使い始めると、テストでは再現しなかった不具合が出てくることがあります。公開後の1〜2週間は、開発会社と発注者がこまめに連絡を取り合い、見つかった問題をすぐ直せる体制にしておくと安心です。この期間にどこまで無償で対応してもらえるかも、発注時に確認しておきたいポイントです。

発注時にテストについて確認しておくこと

テストの質は見積書の金額だけでは分かりません。発注前に、次の項目を開発会社に確認しておくと安心です。

• テスト工程が見積もりに含まれているか（別料金・省略されていないか）
• 受入テスト（UAT）の期間をどれくらい取れるか（発注側が触る時間の確保）
• 不具合を報告する方法と、直すまでの流れ（連絡手段・対応の目安期間）
• 公開後に見つかった不具合の扱い（無償で直す範囲・保守契約の内容）
• どんな観点でテストするか（正常系だけでなく異常系も確認するか）

特に、受入テストの期間を最初から日程に組み込んでおくことが重要です。公開日ぎりぎりにシステムが出来上がると、発注側が確認する時間がなくなり、問題を見つけられないまま公開してしまいます。「例：公開の1週間前には触れる状態にしてもらい、現場で試す時間を確保する」といった形で、スケジュールに余裕を持たせておきましょう。開発全体の進め方はシステム開発が失敗する理由と対策もあわせてご覧ください。

また、見積もりを比べるときは「テストが含まれているか」を金額の安さより優先して確認してください。同じ機能でも、確かめる工程を削れば見積もりは安くできますが、そのしわ寄せは公開後の不具合という形で発注者に返ってきます。当社は一律料金（スタンダード100万円／プロ200万円・追加費用なし・着手前に総額確定）にテスト・品質保証まで最初から含めており、「後からテスト費用が追加される」ことはありません。総額が着手前に確定するため、テストにかける手間を惜しんで削る動機がそもそも生じない仕組みになっています。

テストと検収の関係

最後に、テストと検収の関係を整理しておきます。検収とは、納品されたシステムが「注文どおりに出来ているか」を発注者が確認し、正式に受け取る手続きのことです。この検収の判断材料になるのが、まさに受入テストの結果です。

流れとしては次のようになります。

1. 開発会社がテスト（単体・結合・システム）を終えて納品する
2. 発注者が受入テスト（UAT）で業務目線の確認をする
3. 問題がなければ検収を通し、正式に受け取る（検収完了）
4. 検収完了後は、保守・改修のフェーズに移る

ここで注意したいのは、検収を通すと「受け取った」ことになるという点です。急かされて中身を確認しないまま検収してしまうと、後から不具合が見つかっても「受入済み」として有償対応になることがあります。だからこそ、受入テストの時間をしっかり取り、納得したうえで検収するのが大切です。検収の位置づけや進め方については検収とは何かの記事で詳しく解説しています。

まとめ

システム開発のテスト・品質保証は、開発会社に任せきりにするものではなく、**発注者にしかできない確認（受入テスト）**が含まれる工程です。要点を整理します。

• テストは不具合をお客様や現場に届く前に潰す工程で、被害の防止に直結する
• テストには単体・結合・システム・受入の段階があり、受入テスト（UAT）は発注者が主役
• 受入テストは「普段の業務を一通りやってみる」のが基本、異常な使い方も試す
• テスト工程は全体の2〜4割を占め、安すぎる見積もりは省略の可能性がある
• バグはゼロにならない前提で、重大なものを潰し、保守で付き合っていく
• 検収は「受け取った」ことになるため、受入テストで納得してから通す

「テストにどこまで時間をかけるべきか」「うちの業務だと何を確認すればいいか」で迷ったら、遠慮なくご相談ください。当社は一律料金でテスト・品質保証まで含めてお引き受けし、公開前の受入テストの進め方から公開後の保守までサポートします。まずは無料相談から、お気軽にお問い合わせください。