システム開発やアプリ開発において、リリース後の品質トラブルは企業の信頼を大きく損なうリスクとなります。しかし、「テスト」と一言で言っても、どのような種類があり、どのような工程で、何をどこまで確認すればよいのか、全体像を把握するのは容易ではありません。
本記事では、システム発注や外部委託を検討されている企業の担当者様に向けて、ソフトウェアテストの基礎知識から、具体的な種類・工程、さらにはコスト削減や品質向上につながる自動化・AI活用の最新トレンドまでを解説します。あわせて、テストの種類・工程という土台知識を踏まえたうえで、発注先（委託予定または既存のベンダー）の品質保証体制をどのように評価すればよいかについてもご紹介します。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
ソフトウェアテストとは？
ソフトウェアテストとは、開発されたシステムが「意図した通りに動くか」を確認し、不具合（バグ）を取り除くための活動です。しかし、単にエラーが出ないかを確認するだけではありません。品質保証には大きく分けて2つの重要な視点があります。
「検証」と「妥当性確認」の2つの視点
ソフトウェアテストの目的は、以下の2点を満たすことです。
検証
仕様通りに作られているか、設計図通りにプログラムが書かれているかを確認する視点です。「正しく作られているか」をチェックします。
妥当性確認
ユーザーのニーズを満たしているか、仕様そのものが、ユーザーが本当に求めているものと合致しているかを確認する視点です。「正しいものを作っているか」をチェックします。
例えば、家を建てる場合に例えると、「設計図通りに柱が立っているか」を確認するのが検証であり、「この間取りで実際に家族が快適に暮らせるか」を確認するのが妥当性確認です。システム開発においても、バグがないだけでなく、使いやすさや目的達成の両輪が揃って初めて「品質が良い」と言えます。
なぜテストが必要なのか？
テストを十分に行わずリリースを急ぐと、結果的に大きな損失を招くことがあります。ここではコストとリスクの観点から解説します。
1:100の法則
ソフトウェア開発には「1:100の法則」と呼ばれる経験則があります。これは、開発の初期段階（設計など）でバグを見つけて修正する場合のコストを「1」とすると、リリース後に同じバグを修正するには「100」倍以上のコストがかかるというものです。早期にテストを行い不具合を発見することは、最大のコストダウン策になります。
ビジネスリスクの回避
リリース後に個人情報の漏洩やシステム停止といった重大なトラブルが発生すれば、損害賠償だけでなく、企業の社会的信用を失うことになります。テストは単なる作業ではなく、これらのリスクを未然に防ぐための「投資」です。
ソフトウェアテストの7原則
テストを行う上で、国際的な標準として知られる「7つの原則」があります。これらを知っておくことで、テストに対する過度な期待や誤解を防ぎ、適切な戦略を立てることができます。
テストは欠陥があることは示せるが、欠陥がないことは示せない
テストによってバグが見つかれば「ここにおかしい箇所がある」と証明できます。しかし、いくらテストをしてバグが出なかったとしても、「このシステムには絶対にバグが存在しない（バグゼロ）」という証明はできません。
あくまで「現時点で行ったテストの範囲では問題がない」という確認であり、テストは品質を高める手段であって、完全無欠を保証する魔法ではないと理解することが重要です。
全数テストは不可能
「すべての入力パターンをテストしてください」という要望は、現実的ではありません。例えば、Webフォームに入力される文字の組み合わせや、ユーザーが操作する手順のパターンは天文学的な数になります。
これら全てをテストしようとすれば、莫大な時間と費用がかかり、いつまでもリリースできなくなります。そのため、リスクが高い箇所や重要な機能に絞って優先順位をつける戦略が必要です。
早期テストで時間とコストを節約
前述の「1:100の法則」でも触れた通り、開発の後半になればなるほど、手戻りのコストは雪だるま式に増えます。プログラムが出来上がってからテストをするのではなく、設計書などの上流工程（開発の初期段階）からレビューや検証を行う「シフトレフト（工程表の左側＝早期にテストを移すこと）」という考え方が、現代の開発では重要視されています。
欠陥の偏在
ソフトウェアの不具合には、「バグの約80％は、システム全体の約20％の箇所に集中する」という傾向があります（パレートの法則）。複雑な計算処理を行う機能や、頻繁に修正が加えられた箇所にバグは潜みやすいです。
テストを行う際は、システム全体を均等に確認するのではなく、こうした「バグの巣」になりそうな箇所を重点的にテストすることで、効率よく品質を高められます。
殺虫剤のパラドックス
同じ農薬を使い続けると害虫に耐性がついてしまうように、ソフトウェアテストでも、同じテストパターンを繰り返しているだけでは、新しいバグを見つけられなくなります。
これを「殺虫剤のパラドックス」と呼びます。開発が進むにつれて、テストデータやチェックする観点を定期的に見直し、新しいパターンを取り入れていく必要があります。
テストは状況次第
テストの内容や強度は、対象となるシステムによって全く異なります。例えば、人の命に関わる「医療機器の制御システム」と、暇つぶしのための「無料ゲームアプリ」では、求められる品質基準や許容できるリスクが違います。
一律の基準を設けるのではなく、そのシステムの目的や利用シーン（コンテキスト）に合わせたテスト計画が必要です。
不具合ゼロの落とし穴
たとえバグが一つもなく、仕様通り完璧に動作したとしても、それがユーザーにとって使いにくかったり、役に立たなかったりすれば、そのソフトウェアは失敗です。
これを「不具合ゼロの落とし穴」と呼びます。技術的な正しさだけでなく、「ユーザーの期待に応えられているか」という視点を忘れてはいけません。
ソフトウェアテストの種類
システム開発は、小さな部品を作り、それを組み合わせていくプロセスです。テストもそれに合わせて、小さな単位から全体へと段階的に進んでいきます。ここでは、テスト対象の範囲によって分類される4つの工程（テストレベル）と、確認する品質の性質によって分類される2つの観点を解説します。
テスト対象の範囲による分類（テストレベル）
テストレベル | 目的 | 主な担当者 | 主な手法 |
|---|---|---|---|
単体テスト | 部品（関数・メソッド）単位の動作確認 | 開発者自身 | ホワイトボックステスト |
結合テスト | 部品同士を組み合わせた際の連携確認 | 開発チーム | ブラックボックステスト中心 |
システムテスト | システム全体が要件を満たすかの総合検証 | テストチーム | ブラックボックステスト |
受入テスト | 実業務で使えるレベルかの最終確認 | 発注者自身 | 実業務シナリオに基づく確認 |
単体テスト
プログラムの最小単位（関数やメソッドと呼ばれる部品）ごとの動作確認です。自動車の製造で言えば、「ネジ単体」「エンジン単体」が規格通りかチェックする段階です。
主にプログラマー自身が担当し、プログラムの内部構造を見ながらロジックが正しいかを確認するため、「ホワイトボックステスト（中身が見える透明な箱）」と呼ばれる手法が用いられます。
結合テスト
単体テストをパスした部品同士を組み合わせて、正しく連携できるかを確認する工程です。例えば、「会員登録画面」と「顧客データベース」をつないだ時に、正しくデータが保存されるかなどを確認します。
これには、異なるシステム間をつなぐ「API連携」の確認なども含まれます。部品単体では動いても、つなぐとうまく動かないことは多々あるため、システムとしての統合に向けた重要なステップです。
システムテスト
本番環境に近い状態で、システム全体が要件を満たしているかを総合的に検証する工程です。ここでは、「画面通りに動くか」といった機能面の確認だけでなく、「アクセスが集中しても遅くならないか（性能テスト）」や、「不正アクセスに耐えられるか（セキュリティテスト）」といった、機能以外の品質も厳しくチェックします。
受入テスト
開発会社の作業が完了した後、発注者自身が主体となって行う最終テストです。実際の業務フローに沿って操作を行い、「業務に使えるレベルに仕上がっているか」を確認します。
ここで問題がないと判断されれば、正式な納品・検収となり、システムがリリースされます。
確認する品質の性質による分類
上記のテストレベルとは別に、「何を確認するか」という観点でも分類できます。
- 機能テスト：仕様書に書かれた機能が正しく動作するかを確認するテストです。単体テスト〜受入テストの各レベルで実施されます。
- 非機能テスト：性能（アクセス集中時の速度）、セキュリティ（脆弱性の有無）、ユーザビリティ（使いやすさ）など、機能以外の品質を確認するテストです。主にシステムテストの段階で重点的に実施されます。
発注担当者としては、提案書や報告書に「機能テストのみ」しか記載がない場合、非機能テストがどこまでカバーされているかを別途確認しておくと安心です。
ソフトウェアテストの工程
テストの「種類」を理解したら、次に押さえておきたいのが「工程」、つまりテストがどのような手順で進められるかです。テストレベルによらず、一般的なテスト工程は以下の5段階で構成されます。
- テスト計画：どの範囲を、どのレベルまでテストするか、完了基準（合格ライン）は何かを定義します。
- テスト設計：テスト計画に基づき、具体的な確認手順である「テストケース」を作成します。
- テスト実施：作成したテストケースに沿って実際にシステムを動かし、結果を記録します。
- 結果の評価・バグ管理：発見した不具合を記録し、原因を分析したうえで、修正と再テスト（リグレッションテスト）を行います。
- テスト完了判定・報告：完了基準を満たしたかを判定し、テスト結果報告書としてまとめます。
このうち、発注者が最も関わりを持つのは「テスト計画」（完了基準の合意）と「テスト完了判定・報告」（報告書の受領・確認）の2段階です。ここが曖昧なまま進むと、「どこまでテストしたのか分からないまま納品される」という事態になりかねません。工程ごとに誰が何を確認するのかを、契約前にすり合わせておくことが重要です。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
開発モデルとテストの連携
システムをどのように開発していくかによって、テストの進め方も変わります。代表的なモデルとテストの関係性を紹介します。
V字モデル
最も基本的で広く使われているモデルです。開発工程（要件定義→設計→実装）の流れを左下がりの線、テスト工程（単体→結合→システムテスト）を右上がりの線で描き、アルファベットの「V」の字のように対応させます。
「詳細設計のミスは単体テストで確認する」「要件定義の漏れはシステムテストで確認する」といったように、各段階で何を検証するかが明確なため、進捗管理がしやすいのが特徴です。
▼関連記事 システム開発のV字モデルとは？メリット・デメリットからアジャイル開発との違いまで解説
W字モデルとシフトレフト
V字モデルを進化させた手法です。V字モデルでは、プログラムが出来上がってからテスト工程（V字の右側）が始まりますが、これでは設計ミスの発見が遅れます。
W字モデルでは、設計段階（V字の左側）から並行してテストの準備や設計書のレビューを行います（V字が2つ並ぶためW字と呼ばれます）。前述の「シフトレフト」を具現化したもので、手戻りを防ぎ、効率的に開発を進めることができます。
アジャイル・DevOpsにおける継続的テスト
近年のWebサービスやアプリ開発で主流となっている、短期間で機能追加とリリースを繰り返すスタイル（アジャイル開発など）です。頻繁にプログラムを修正するため、その都度手動でテストをしていては間に合いません。
そこで「CI/CDツール」と呼ばれる仕組みを使い、プログラムを保存した瞬間に自動でテストを実行させます。スピードを維持しながら品質も担保する、現代的な開発スタイルです。
▼関連記事 アジャイル開発とは？アジャイル開発の手法から導入のポイントまで徹底解説！
ソフトウェアテストの自動化とAI活用の最新トレンド
人手不足や開発スピードの向上に伴い、テストを人間が手作業で行うのではなく、ツールに任せる動きが加速しています。
テスト自動化のメリットと「殺虫剤のパラドックス」の回避
一度作った機能を人間が毎回手動でチェックするのは大変な労力です。特に、新しい機能を追加したせいで、既存の機能が壊れていないかを確認する「リグレッションテスト（回帰テスト）」は、自動化による恩恵が最も大きい領域です。自動化ツールを使えば、夜間に数百項目のテストを無人で実施できます。
また、人間では見落としがちな細かい差異も機械的に検出できるほか、単純作業を機械に任せることで、人間はより複雑な「新しいバグを見つけるためのテスト」に集中でき、マンネリ化（殺虫剤のパラドックス）を防ぐことができます。
AI（人工知能）によるテストケース生成と自己修復機能
最新のトレンドでは、AIがテストを支援する技術も登場しています。例えば、実際のユーザーの操作履歴をAIが学習し、「よく使われる操作パターン」のテストを自動で作ってくれるツールがあります。
また、従来の自動化テストは、ボタンの位置など画面のデザインが少し変わるだけでエラーになりがちでしたが、AIが「ボタンの位置が変わっただけで、機能は同じだ」と判断し、テストプログラムを自動で修正する機能も実用化されています。
セキュリティ・バイ・デザインと脆弱性診断の統合
サイバー攻撃のリスクが高まる中、開発が終わってからセキュリティチェックをするのではなく、設計や日々のプログラミングの中に自動的なセキュリティ診断を組み込む手法が注目されています。これを「セキュリティ・バイ・デザイン（設計段階からセキュリティを考慮する）」と呼びます。
開発者がコードを書いた時点で、危険な書き方をしていないかをツールが自動判定することで、手戻りを防ぎつつ安全性を高めることができます。
ソフトウェアテストの外部委託（アウトソーシング）について
自社にテストの専門部隊がいない場合や、開発会社とは別の視点でチェックを行いたい場合、テスト専門会社へのアウトソーシングが有効です。
第三者検証のメリット
開発者が自分でテストをすると、どうしても「動くはずだ」という思いこみバイアスがかかり、バグを見落としがちです。第三者が客観的にテストを行うことで、こうしたバイアスを排除できます。
また、スマートフォンアプリの場合、数多くの機種やOSバージョンでの動作確認が必要になりますが、自社で何十台もの検証用端末を揃えるのはコストがかかります。専門会社であれば、豊富な検証端末やツールを保有しているため、コスト削減にもつながります。
失敗しないテスト会社の選び方
単に「テスト作業を代行します」という会社ではなく、品質向上のための提案ができる会社を選びましょう。確認すべきポイントは以下の通りです。
・ドメイン知識： 業界特有の業務知識（金融、EC、医療など）を持っているか。 ・自動化技術： 手動テストだけでなく、自動化による効率化を提案できるか。 ・コンサルティング能力： 上流工程（要件定義・設計）から入り込み、品質リスクを指摘できるか。
契約形態の重要性
外部委託する際は、契約形態の違いを理解しておくことが重要です。
請負契約
「仕事の完成」に対して責任を負います。成果物（テスト報告書など）の納品がゴールです。要件が明確な場合に適しています。
準委任契約
「業務の遂行」に対して責任を負います。エンジニアの稼働時間や技術提供に対して対価を支払います。開発と並走しながら柔軟にテストしたい場合に適しています。
発注時に品質保証体制を確認するポイント
会社選びの基準を押さえたら、次はより具体的に「その会社（またはすでに契約しているベンダー）の品質保証体制が、実際に機能しているか」を確認する段階です。ここでは、提案書や打ち合わせの場で発注担当者が投げかけられる、3つの着眼点を紹介します。
テスト工程の分担を確認する
前述の通り、テストは「単体・結合・システム・受入」という段階と、「テスト計画→設計→実施→評価→報告」という工程で進みます。委託先に対しては、このうちどこからどこまでを担当し、どこからが発注者側の役割になるのかを明確にしてもらいましょう。
特に「システムテストの完了基準」と「受入テストへの引き継ぎ内容」が曖昧なまま契約すると、納品直前になって「そこまではやっていない」という認識のズレが発生しやすくなります。
QAエンジニアの配置を確認する
開発者自身がテストを兼務する体制と、QA（品質保証）専門のエンジニアが独立してテストを担当する体制とでは、バグの発見精度が変わります。開発者本人によるテストは、前述の「思いこみバイアス」がかかりやすいためです。
規模の大きいプロジェクトや、品質要求が高いシステムを発注する場合は、「QA専任の担当者が何名体制で入るか」「開発者とQAの役割はどう分かれているか」を確認しておくと、テストの客観性を判断する材料になります。
評価指標（KPI）の有無を確認する
「バグが多かったか少なかったか」を感覚だけで判断するのは危険です。信頼できる委託先は、以下のような定量的な指標をあらかじめ設定し、報告時に提示してくれます。
- テストカバレッジ：計画したテスト項目のうち、どの程度を実施できたか
- バグ検出率：テストの各段階でどれだけの不具合を発見できたか
- 再テスト率（回帰率）：修正後の再テストで新たな不具合が見つかった割合
こうした指標が提案段階や報告時に一切出てこない場合、テストの実施状況を客観的に検証する手段がない可能性があります。契約前に「どのような指標で品質を報告してもらえるか」を質問してみることをおすすめします。
なお、ここで紹介した観点はテスト工程に特化した評価軸です。要件定義から運用まで含めた品質管理の全体像（QCとQAの違いやSLAの考え方など）については、以下の記事もあわせてご参照ください。
▼関連記事 システム開発の品質管理とは？目的・手法・成功のポイントを解説
まとめ
ソフトウェアテストは、単なる「バグ探し」ではなく、ユーザーに価値ある製品を届けるための重要な投資です。「1:100の法則」にあるように、テストを後回しにせず、開発の早期段階から計画的に品質を作り込むことが、結果としてコスト削減とビジネスの成功につながります。
テストの種類・工程という基礎知識は、そのまま発注先の品質保証体制を見極めるための土台になります。AI活用や自動化といった新しい技術動向も踏まえながら、テスト工程の分担・QAエンジニアの配置・評価指標の有無という3つの着眼点で、自社のプロジェクトに最適なパートナー選びを行ってください。もし社内にノウハウがない場合は、専門家であるテスト会社へ相談することから始めてみてはいかがでしょうか。
ソフトウェアテストを検討中の場合は秋霜堂にご相談ください
秋霜堂株式会社は、最先端のWeb・AI技術に精通したエンジニア集団です。単なる作業代行ではなく、貴社の「内製開発部門」のようにプロジェクトへ深く入り込み、開発からテスト戦略まで一貫して伴走します。
エンジニア主体の組織のため、テスト自動化やAI活用の技術的な相談もその場でスムーズに対応可能です。コミュニケーションロスや品質への不安を解消し、ビジネスを加速させるパートナーとして、ぜひお気軽にご相談ください。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
システム開発の外注・発注を初めて経験する担当者や、過去に失敗を経験した担当者が、発注プロセスの各フェーズで「何をチェックすべきか」を明確に把握できるようにする。
こんな方におすすめです
- 初めてシステム開発を外注する担当者
- 過去の発注で失敗を経験した方
- ベンダー選定の基準が分からない方
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- 発注者が受入テストで確認すべき最低限のポイントは何ですか？
実際の業務フローをひと通り操作し、「業務が止まる致命的な不具合がないか」「主要な入力・出力が仕様通りか」の2点を軸に確認してください。技術的な完全性よりも「自社の業務で使えるか」という視点を優先するのが受入テストの本質です。
- テストを外部委託するか自社で行うかは何を基準に判断すればよいですか？
社内にテスト設計の知識がない、または開発者と同じ目線でしか確認できないと感じる場合は外部委託が有効です。特にリリース後の障害がビジネスに直結するシステム（ECサイト・基幹業務）は、開発会社とは別の第三者検証を入れることでバイアスを排除できます。
- 開発会社から提示されるテスト工程の工数見積もりは妥当か、どう確認すればよいですか？
一般的にはシステム開発全体の工数のうち20〜30%程度がテスト工程の目安とされています。これを大幅に下回る場合はテストが省略されている可能性があるため、「どの工程で何のテストをするか」を項目単位で提示してもらうと確認しやすくなります。
- テスト自動化はどのシステムから導入するのが効果的ですか？
頻繁に機能追加が発生するWebサービスやアプリ開発が最も恩恵を受けやすく、特に既存機能が壊れていないかを確認する「リグレッションテスト」から着手するのが定石です。逆に要件が固定された一度きりの開発では、自動化の初期コストが回収しにくいケースもあります。
- 「バグゼロで納品されたのに使いにくい」という事態を防ぐにはどうすればよいですか？
受入テストの段階で「仕様通りか」だけでなく「実際の業務担当者が違和感なく操作できるか」を確認することが重要です。開発会社への発注時点で受入基準（何をもって合格とするか）を明文化し、ユーザー代表者を受入テストに参加させる体制を整えると、不具合ゼロの落とし穴を防げます。
