LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

結合テストに入ってから、外部エンジニアが考えていた「結合テスト」と社内の想定が違うと分かった。不具合が見つかっても、誰に渡して、誰が直ったと判断するのかが決まっていない——。社外のエンジニアが開発に加わる現場では、こうした食い違いが起こりがちです。結合テストとは、別々に作って確かめたプログラムの部品をつなぎ、つないだ状態で設計どおりに動くかを確かめるテストのことです。

結合テストのテスト体制を先に決めておけば、外部エンジニアに頼む作業と、社内に残す判断を分けて伝えられます。ただし、テスト体制を決めることは万能ではなく、テストの量や必要な人数はそれだけでは決まりません。本記事では、外部エンジニアと開発を進めるマネージャーに向けて、結合テストの呼び名のそろえ方、テスト体制に書く役割、テスト環境とテストデータ、不具合の受け渡し、そして外部に頼むときに確認したい点を整理します。

結合テストとは

IPA（情報処理推進機構）の「ソフトウェア開発分析データ集2022」は、開発の工程の呼び名と、共通フレーム（開発の作業を工程ごとに定めた手引き）の工程との対応を表にしています。この表で結合テストに対応するのは、「ソフトウェア結合」と「システム結合」の2つです。^*1

ソフトウェア結合は、部品を組み合わせてひとまとまりのソフトウェアに仕上げ、結合とテストを行う作業です。システム結合は、仕上がったソフトウェアを機器や手作業、ほかのシステムとあわせてつなぎ、要件を満たしているかをテストする作業です。一口に結合テストと言っても、プログラムどうしのつなぎ目を見る段階と、ほかのシステムまで含めてつなぐ段階の両方が入っています。

同じ表では、結合テストのためのテスト要求事項と予定を決めるのは、詳細設計（プログラムの中身を決める工程）とされています。^*1 結合テストの準備は、プログラムを作り終えてからではなく、設計の段階で始まるということです。外部エンジニアが設計から加わるのか、作り終えた後のテストから加わるのかによって、テスト体制の組み方も変わってきます。

なぜ呼び名の確認から始めるのか

デジタル庁の「デジタル・ガバメント推進標準ガイドライン」は、国の情報システムを整備する手順を定めた文書です。その解説書は、作業の呼び名が事業者によって違うことに触れたうえで、「同一テスト名称であっても、事業者によりテスト内容と検証対象工程の関係に差異が発生しやすい」と注意を促しています。^*2 検証対象工程とは、そのテストでどの工程の成果物を確かめるのか、という意味です。

外部エンジニアは、それまで働いてきた会社ごとの呼び方に慣れています。ある人にとっての結合テストは画面と処理のつなぎ目の確認で、別の人にとってはほかのシステムとのデータのやり取りまで含むことがあります。呼び名だけで頼むと、終わったと報告された中身が社内の想定より狭かった、ということが起こります。

そこで最初に、今回の結合テストで確かめる対象を文にします。「受注画面から在庫を引き当てる処理までを、社内の在庫システムにつないだ状態で確かめる」のように、つなぐ部品とつなぐ相手を書き出しておけば、呼び名の違いで食い違うことはなくなります。

テスト体制に書く役割

解説書は、設計の段階でテスト計画書の案を作るよう開発の事業者に求め、記載事項として「テスト方針、テスト体制、テスト環境、作業内容、作業スケジュール、テストシナリオ作成基準、合否判定基準等」を挙げています。^*2 案は開発を受け持つ側が作りますが、発注する側がそれを主体的に確認し、承認するものとされています。外部エンジニアに頼む場合なら、案を書いてもらい、社内で確認して承認する形です。

テスト体制の欄には、人数だけでなく、誰が何を受け持つかを書きます。結合テストの作業は、テストケース（確かめる操作と期待する結果の組み合わせ）を書く設計、実際に操作して結果を残す実施、見つかった不具合を直す修正、結果を見て次の工程に進んでよいかを決める判定の4つに分けて考えると整理しやすくなります。この4つの担い手を1つずつ決めておきます。

このうち判定は社内に残します。解説書は、合否判定基準を全て満たしたと認められる場合に限って次の工程の開始を承認するとし、その承認は発注する側のプロジェクト推進責任者が行うとしています。^*2 判定まで外部エンジニアに委ねると、テストを行った人が自分の結果を合格と決める形になり、社内に判断の根拠が残りません。

設計と実施は、外部エンジニアに任せやすい作業です。作る人と確かめる人を分けたいときは、テストの設計だけを別の外部エンジニアに頼む組み方もあります。IPAのデータ集も、開発中の品質保証を「プロジェクトメンバが実施」したのか、「品質保証の専門スタッフが実施」したのかを分けて記録しており、確かめる人を開発の担当から分けるかどうかは体制を決めるときの論点の一つです。^*1

テスト環境とテストデータの準備

解説書によると、結合テストの前に、発注する側は開発を受け持つ側にテスト計画書を詳しくしてもらい、テストケースと「使用するテストデータの内容等」を書いた仕様書を作ってもらいます。発注する側はそれを受け取って、「テスト内容の十分性、テストデータの適切性等」を確かめます。^*2 テストデータとは、テストのときに入力したり、あらかじめ登録しておいたりするデータのことです。

外部エンジニアが加わるときに決めておきたいのは、環境とデータを誰が用意するかです。結合テストでは、社内のほかのシステムや、社内共通のログインの仕組みにつなぐことが多く、接続の設定や権限の付与は社内の担当者にしかできない場合があります。環境の準備を外部エンジニアの作業に含めるなら、使えるアカウントと、変えてよい設定を先に決めておきます。

データは、本番のデータを使わずに作るのが基本です。解説書も、やむを得ず本番データをテストデータに使う場合や、それを保存する場合には「厳格な情報セキュリティ対策を施す必要がある」としています。^*2 顧客の氏名や住所を含むデータを外部エンジニアの環境に渡す前に、氏名や住所を架空の値に置き換えたデータでテストできないかを検討します。

テストが終わった後の扱いも決めておきます。解説書は、テストケース、テストデータ、テストツール、テストの実施手順を保存し、後の改修のときに一部を変えて使えるようにすることを求めています。^*2 外部エンジニアの契約が終わった後も、社内の担当者が同じテストをもう一度行えるように、保存する場所と形式をテスト計画書に書いておきます。

不具合の受け渡し

結合テストの途中で見つかった不具合について、解説書は、開発する事業者が進み具合や課題に加えて、発生したバグや不具合の「対応方針や対応状況」も報告するとしています。^*2 テストが終わったら、開発する事業者がテスト結果と分析結果を結合テスト実施報告書にまとめ、発注する側に報告するとされています。

外部エンジニアが加わると、テストをした人と直す人が別になることがあります。外部エンジニアが見つけた不具合が、社内のエンジニアが作った部分にある場合がその例です。誰が不具合を記録し、誰が直す人を決め、直った後に誰がもう一度テストするのかが決まっていないと、記録だけが増えて修正が進みません。

受け渡しの決まりは、テスト計画書の作業内容の欄に書いておくと進めやすくなります。不具合1件ごとに、再現の手順、期待した結果と実際の結果、見つけた日、直す担当、直した内容、再テストの結果を1つの表に残す形です。この表を社内と外部エンジニアの両方が見られる場所に置けば、報告のたびに状況を聞き直す手間も減ります。

判定の場面では、承認の状況と理由、承認に当たっての前提条件を記録に残すよう解説書は勧めています。^*2 「軽い不具合は次のテストの前までに直す」といった条件を付けて次に進む場合も、条件を書いておけば、後から誰が見ても経緯を確かめられます。

つまずきやすい点

一つ目は、呼び名だけで作業を頼むことです。「結合テストをお願いします」と伝えても、つなぐ相手をどこまで含めるかは、頼まれた人の経験によって変わります。確かめる対象を文にしてテスト計画書に書き、それを見せてから頼みます。

二つ目は、合否判定基準を後から決めることです。テストが進んでから基準を決めると、すでに出た結果に合わせた基準になりやすく、判定の意味が薄れます。基準はテスト計画書の段階で書き、社内の責任者が承認しておきます。

三つ目は、テスト環境の準備を誰の作業にもしていないことです。外部エンジニアが着任しても、接続先の権限が出ていなければテストを始められません。着任の日までに、使うアカウントとテストデータがそろっているかを確かめておきます。

外部に委託するときに確認しておきたい点

外部エンジニアに結合テストを頼む前に、依頼の文書に次のことを書いておくと、着任してからの食い違いを減らせます。

• 確かめる対象（つなぐ部品と、つなぐ相手のシステム）
• 受け持つ役割（設計・実施・修正のどれを頼むか）
• 使うテスト環境とテストデータ、それを用意する人
• 不具合の記録の仕方と、報告の頻度
• 終わったときに渡してもらうもの（テストケース、テストデータ、結果の記録）

結合テストの作業は、開発の後半の一時期に集中します。その時期だけ人を増やしたいなら外部エンジニアに加わってもらう方法が、次の開発でも同じテストを社内で行いたいなら、テストの設計の経験がある社員を採用する方法が考えられます。どちらを選ぶ場合も、上の5つが書けていれば、求める経験の条件を決めやすくなります。

テストにあたる人のスキルと人数の不足をどう分けるかは「外部エンジニアのテスト体制、IPAが定める4つの区分」で、何をどこまで確かめるかの決め方は「外部エンジニアのテスト体制とテスト設計、依頼前に決める3つの点」で扱っています。結合テストの後に行う受入テストと検収は「業務委託エンジニアの参画後の評価、成果物と作業で確かめる手順」にまとめました。

まとめ：結合テストで確かめておきたい3つの点

外部エンジニアと結合テストを進めるうえで、確かめておきたい点は3つに整理できます。第一に、今回の結合テストで確かめる対象を、つなぐ部品とつなぐ相手まで文にすること。第二に、テスト体制に設計・実施・修正・判定の担い手を書き、判定は社内の責任者に残すこと。第三に、テスト環境とテストデータの用意、不具合の記録と再テストの流れを、テストを始める前に決めることです。この3点を踏まえておけば、「テストは終わったと聞いていたのに、ほかのシステムとつないでみたら動かない」という事態を避けやすくなります。テスト体制の組み方に迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：IPA「ソフトウェア開発分析データ集2022」（https://www.ipa.go.jp/digital/software-survey/metrics/hjuojm000000c6it-att/000102171.pdf）。出典：独立行政法人情報処理推進機構（IPA）「ソフトウェア開発分析データ集2022」。付録A5.1 表A5-1-1（工程の呼称とSLCP-JCF2007との対応関係）と、A5.2 データ項目5241（品質保証体制）の選択肢を参照（2026年9月確認）
2. *2　参考：デジタル庁「デジタル・ガバメント推進標準ガイドライン解説書」（DS-110）（https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/50952dae/20260715_resources_standard_guidelines_guideline_03.pdf）。出典：デジタル庁「デジタル・ガバメント推進標準ガイドライン解説書」（2026年6月12日改定）。第3編第7章1.の解説(2)、4.の6)テストの計画と解説(17)、5.の6)・7)と解説(7)〜(10)、第1章3.の解説（SaaSを利用する場合のテスト）を参照（2026年9月確認）

Tweet