システム開発の見積もりやスケジュールを見ると、必ずといっていいほど「テスト」という工程が入っています。しかし、目に見える機能をつくる工程と違い、テストは「中で何をしているのか」が見えづらいものです。
「単体テストと結合テストは何が違うの？」「なんでこんなに費用がかかるの？」など、発注者側からすると疑問に思うこともありますよね。
この記事では、システム開発のテストとは何かという基礎から、テストの4つの種類、開発工程のどこで行うか、進め方、そして発注者が押さえておくべきポイントまで解説します。テスト工程の全体像を理解し、開発会社との認識合わせに役立てていただければ幸いです。
システム開発におけるテストとは？
システム開発におけるテストとは、作ったシステムが要件どおりに正しく動くか、安全に使えるかを検証する工程のことです。
プログラムを書けば自動的に正しく動くわけではなく、意図しない不具合（バグ）は必ずといっていいほど発生します。それを本番リリース前に見つけて直すのがテストの役割です。
テストの目的
テストは単に「バグを探す作業」ではありません。
たとえば要件定義で決めた機能が設計どおりに動いているか、性能・セキュリティなど「動きの質」も含めて水準を満たすか検証する役割もあります。
また、テストの結果（テスト結果報告書やバグ管理表）は、発注者が検収時に品質を確認するための重要な証跡にもなるんです。
なぜテストが重要なのか
業務システムやWebサービスの開発でテストが極めて重要になる理由は、複雑さと責任にあります。マッチングサイトのような、お金や個人情報を扱うシステムを例に説明します。
複雑な機能の組み合わせ
規模のあるシステムは、単機能のサイトではありません。
- ユーザー登録（一般・事業者・管理者） × 認証（メール・SNSなど）
- マッチングロジック × 通知 × 権限
- 検索条件の組み合わせ
このように機能が複雑に絡み合っているため、「ある箇所の修正が、まったく関係ない箇所のバグを引き起こす」ことが頻繁に起こります。たとえば「決済手数料を修正したら、なぜか領収書発行機能が動かなくなった」といった連鎖反応です。これを防ぐには、網羅的なテストが欠かせません。
お金と個人情報を扱う責任
- 決済エラー ＝ 直接的な金銭損失
- 個人情報漏洩 ＝ 法的リスク＋信頼の崩壊
- マッチング不成立 ＝ ユーザー離脱＝収益減
システムのバグは、単なる「表示崩れ」では済まされません。事業の根幹である「金銭」と「信用」に直結するからこそ、テストに十分な工数をかける必要があるのです。
【一覧表】システム開発のテストの種類（4段階）
一般的なシステム開発（ウォーターフォール型）では、テストは開発の進捗にあわせて4つの段階に分かれて実施されます。小さな部品から検証を始め、徐々に対象を広げていくのが基本です。
| テストの種類 | テスト対象 | 主な目的 | 主な実施者 | 発注者の関与度 |
|---|---|---|---|---|
| 単体テスト（UT） | 関数・機能などの最小単位 | 部品ごとに設計どおり動くか | 開発者 | 低 |
| 結合テスト（IT） | 機能間・システム間の連携 | 組み合わせて正しく連携するか | 開発者・テスト担当 | 低〜中 |
| システムテスト（ST） | システム全体 | 要件・仕様どおり総合的に動くか | 開発会社・QAチーム | 中 |
| 受け入れテスト（UAT） | 実際の業務シナリオ | 業務で使えるかを最終確認 | 発注者・利用者 | 高 |
以下、それぞれの中身を見ていきましょう。
単体テスト（UT）
単体テストは、機能やモジュールを一つひとつ独立して動作確認する、部品ごとの品質チェックです。エンジニアがつくった機能が、設計どおりに動くかを最小単位で確認します。
- 🔍 テスト例
-
- プロフィール画像がアップロードできるか。指定の5種類のファイル形式に対応しているか。
- 入力フォームで不正な値を弾く（バリデーション）ことができるか。必須項目、文字数制限などのチェック。
主に開発者が実施し、内部ロジックの正確さを担保します。ここを削ると、基本的なバグが大量に残り、後工程で使い物にならないシステムになってしまいます。
結合テスト（IT）
結合テストは、単体テスト済みの複数の機能を組み合わせ、連携が正しく機能するかを確認するテストです。機能同士のつなぎ目、データの受け渡しに重点を置いて検証します。
- 🔍 テスト例
-
- Aさんが申請 → Bさんに通知 → Bさんが承認 → 決済処理 → チャット機能が使えるようになる、という一連のフローが途切れないか。
- 注文画面で確定すると、在庫管理システムに正しく反映されるか。
結合テストを削減すると、「通知が来ない」「決済したのに機能が使えない」といった、サービスとして致命的な欠陥が残ります。複数機能が絡むシステムの”心臓部”にあたるテストです。
システムテスト（ST）
システムテストは、本番に近い環境で、システム全体が要件定義書・仕様書どおりに動作するかを総合的に検証するテストです。「総合テスト」とも呼ばれます。
- 🔍 テスト例
-
- スマホとPCで表示崩れはないか。
- 管理画面での設定変更が、ユーザー画面に即座に反映されるか。
機能面だけでなく、後述する性能・セキュリティといった非機能面もこの段階で確認します。削減すると、リリース直後に予期せぬトラブルが多発し、運用が回らなくなります。
受け入れテスト（UAT）
受け入れテスト（受入テスト）は、開発の最終段階で発注者側が主体となり、実際の業務で問題なく使えるかを確認するテストです。「検収」の判断に直結する、発注者が最も関わるべきテストです。
- 🔍 テスト例
-
- 普段の業務の流れに沿って操作し、想定どおりの結果になるか。
- 現場の担当者が、マニュアルを見ながら迷わず操作できるか。
ここで違和感や不足を見つけられれば、リリース前に修正できます。「開発会社に任せきり」にせず、発注者自身が業務目線で必ず確認しましょう。
テスト工程はどこで行う？ V字モデルで理解する
テストは開発の最後にまとめて行うのではなく、各設計工程と対になる形で計画されます。これを図で表したものが「V字モデル」です。左側の設計工程で決めたことを、右側の対応するテストで検証する、という考え方です。
| 設計工程（つくる基準を決める） | 対応するテスト（基準どおりか検証する） |
|---|---|
| 要件定義（何を作るか） | 受け入れテスト（UAT）／システムテスト（ST） |
| 基本設計（機能・画面の仕様） | 結合テスト（IT） |
| 詳細設計（内部の作り込み） | 単体テスト（UT） |
このように、「何を基準にテストするか」は上流の設計工程で決まっているのがポイントです。だからこそ、要件定義や設計が曖昧だと、テストで何を確認すべきかも曖昧になり、品質が担保できません。
なお、短いサイクルで開発を繰り返すアジャイル型では、これらのテストを工程順ではなく各サイクル（スプリント）内で並行して繰り返し実施します。手法が変わっても、単体・結合・システム・受け入れという観点そのものが不要になるわけではありません。
機能テスト以外に必要なテスト（非機能テスト）
ここまでは「機能が正しく動くか」を確認するテストでした。しかし、システムの品質は機能だけでは決まりません。性能や安全性といった「動きの質」を検証する非機能テストも重要です。
負荷テスト
負荷テストは、アクセスが集中したときにシステムが耐えられるかを検証する耐久テストです。
- 🔍 テスト例
-
- 1,000人が同時に検索ボタンを押しても重くならないか。
- 決済が集中する時間帯でも、連携がダウンしないか。
これを省くと、ユーザー数が増えた瞬間にシステムがダウンし、せっかくのビジネスチャンスを逃すことになります。初期のユーザー数が少ない場合は、簡易版から始めて段階的に強化する進め方もあります。
セキュリティテスト
セキュリティテストは、ハッキングや情報漏洩のリスクがないかを専門ツールや専門家が診断する、いわばシステムの”防犯診断”です。
- 🔍 テスト例
-
- SQLインジェクション、XSSなどの攻撃への耐性チェック
- 個人情報の暗号化の確認
- 権限管理に抜け穴がないかのチェック
個人情報や決済を扱うシステムでは、削ってはいけないテストです。省略すると、個人情報保護法違反や損害賠償請求のリスクを抱えたまま運用することになります。
- 回帰テスト（リグレッションテスト）：修正や機能追加のあとに、既存機能が壊れていないか再確認するテスト。改修が続くシステムでは欠かせません。
- 運用テスト（OT）：本番同様の運用手順で、実際に業務を回せるかを確認するテスト。
テストを軽視するとどうなる？ 失敗事例
テスト費用は「削れるコスト」に見えがちですが、テストを軽視した結果、リリース後に当初の数倍のコストがかかるトラブルは数多くあります。
- ⚠️ 例1：決済機能の致命的バグ（損失：約350万円）
- 結合テストの工数を削減したところ、リリース後1週間で「特定の条件下で決済が失敗する」エラーが87件発生。返金対応・お詫び・原因究明に追われ、補償や対応人件費を含め約350万円の損失に。50万円のテスト費用を惜しんだ結果、その7倍を失ったケースです。
- ⚠️ 例2：1万ユーザーで崩壊したシステム（修正費用：約500万円）
- 負荷テストを実施せずにリリースしたところ、人気が出てユーザー数が1万人を超えたタイミングでシステムダウンが頻発。全面的な設計見直し・改修が必要になり、約500万円の損失に。30万円の負荷テストを実施していれば、リリース前に回避できた問題でした。
- ⚠️ 例3：個人情報漏洩リスク（損失：計測不能）
- 「セキュリティ診断は高いから」と省略したところ、本番稼働2ヶ月後に第三者がアクセス可能な脆弱性が発覚。緊急のシステム停止・改修・ユーザーへの告知に追われ、サービスの信用失墜とユーザー離脱という、金額に換算できない損失につながりました。
いずれも、目先のテスト費用を削ったことが、事業に直結する大きな損失を招いた例です。テストは「保険」ではなく「投資」と捉えることが重要です。
発注者がテスト工程で押さえるべきポイント
テストは開発会社任せにできる部分もありますが、発注者が主体的に関わるべきポイントもあります。以下を押さえておきましょう。
受け入れテスト（UAT）は発注者が主体的に行う
前述のとおり、受け入れテストは発注者の役割です。実際の業務シナリオに沿って操作し、「思っていたものと違う」がないかを確認します。ここでのフィードバックは、リリース後の修正よりはるかに低コストで反映できます。
見積もりの「テスト一式」表記に注意する
見積もりで「テスト一式：100万円」とだけ書かれている場合、何をどこまでやるのかが不明確です。「単体・結合・システム・負荷」など項目が分かれているかを確認しましょう。あわせて、次の点もチェックすると安心です。
- 📝 見積もりのチェックポイント
-
- テスト項目が分かれているか：「一式」ではなく内訳が示されているか
- セキュリティテストは含まれるか：個人情報・決済を扱うなら必須
- バグ修正費用は含まれるか：テストで見つけたバグを直す費用の扱い
- テスト費用の比率は適正か：開発費に対して15〜20%が一つの目安
「開発1,200万円・テスト50万円（比率4%）」のように極端にテストが薄い見積もりは、安く見えてもバグだらけで納品されるリスクがあるため注意が必要です。
テストにかかる費用の目安
テスト費用は、システム開発全体の15〜20%程度を占めるのが一般的です。開発工程の約4分の1がテストに割かれると考えると、決して小さくない項目であることがわかります。
たとえば1,500万円規模のマッチングサイト開発では、単体・結合・システム・負荷・セキュリティを合わせて約200万円（約300時間）がテストに充てられます。「なぜテストにこれだけかかるのか」「どのテストなら段階的に抑えられるのか」といった費用の内訳や削減方法は、以下の記事で詳しく解説しているのでぜひご覧ください！
テストだけで200万円？システム開発のテスト費用の内訳と削ってはいけない理由
Chigusa Kama
よくある質問
Q: 単体テストと結合テストの違いは何ですか？
単体テストは関数や機能などの最小単位が設計どおり動くかを一つずつ確認するテストで、主に開発者が実施します。結合テストは、単体テスト済みの複数の機能を組み合わせて連携が正しく機能するかを確認するテストです。「部品単体の検査」が単体テスト、「部品同士のつなぎ目の検査」が結合テスト、とイメージするとわかりやすいでしょう。
Q: 受け入れテスト（UAT）は誰が行うのですか？
受け入れテストは、発注者側が主体となって行うテストです。実際の業務シナリオに沿ってシステムを操作し、「業務で問題なく使えるか」「要件を満たしているか」を最終確認します。検収の判断に直結するため、開発会社任せにせず、現場の利用者を含めて確認することが重要です。
Q: アジャイル開発でもテストは種類ごとに分かれますか？
はい。アジャイル開発では工程順ではなく各スプリント内でテストを並行・反復して実施しますが、単体・結合・システム・受け入れというテストの観点そのものは変わりません。一つの機能が完成し次第すぐにテストするため、早期にフィードバックを得られるのが特徴です。
Q: テストにかかる費用の目安はどのくらいですか？
システム開発全体の15〜20%程度が一つの目安です。開発工程の約4分の1がテストに割かれると考えるとイメージしやすいでしょう。費用の内訳や、どのテストなら段階的に抑えられるかについては、テスト費用を詳しく解説した記事をご覧ください。
Q: テストは開発会社に任せておけばよいですか？
単体テストや結合テストは開発会社が主体で行いますが、受け入れテスト（UAT）は発注者が主体的に関わるべきテストです。また、見積もり段階で「テスト項目の内訳」「セキュリティテストの有無」「バグ修正費用の扱い」を確認しておくことも、発注者の重要な役割です。
まとめ
システム開発のテストは、作ったシステムが要件どおりに正しく・安全に動くかを検証する工程です。単体テスト→結合テスト→システムテスト→受け入れテストという4段階を軸に、負荷テストやセキュリティテストといった非機能テストを組み合わせて品質を担保します。
なかでも受け入れテストは発注者が主体となる工程であり、見積もりのテスト項目や費用比率のチェックとあわせて、発注者自身がテスト工程に主体的に関わることが、失敗しない開発につながります。テストは「保険」ではなく、事業を守るための「投資」と捉えて、品質保証への理解を深めておきましょう。
LIGのテスト・品質保証の進め方
最後に、参考として弊社（LIG）のテスト・品質保証の進め方を紹介します。お客様のビジネスを守るため、3段階の品質チェック体制を敷いています。
- 💡 LIGの3段階の品質チェック体制
-
- 開発チームによる単体テスト：自動テストツールも活用し、コードを書いたらチェックします。
- QAチームによる結合・システムテスト：開発者とは別の担当者がユーザー目線でテストします（PMやUI/UXデザイナーが担当する場合もあります）。
- 外部の専門会社によるセキュリティテスト：第三者の視点で脆弱性診断を実施し、安全性を担保します。
また、週次の定例では「現在テストの80%が完了」「重要度『高』のバグがあと3件」といった進捗を透明性高くご報告し、発注者が安心してリリース日を迎えられるよう努めています。
開発の相談は随時受け付けています。以下フォームからお気軽にご相談ください！
