LASSIC Media らしくメディア
外部エンジニアのテスト体制とテスト設計、どこまで測る？
監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）
この記事の結論
- 網羅の度合いを測る項目が6つある：データ項目433から438で、名前としては仕様、機能、構成、コードの4種類のカバレッジに分かれます。*1
- 選択肢6つのうち水準は4つだけ：100％、80％以上、50％以上、50％未満の4つが水準で、残る「不明」「未測定」は水準ではありません。*1
- どの水準が妥当かは書かれていない：資料に載っているのは、項目の定義と選択肢までです。
※ 本記事は2026年9月時点の公式情報（省庁・公的機関、および製品やサービスを提供する事業者が公開している資料）に基づきます。
外部エンジニアにテストを任せるとき、「テストはお願いします」とだけ伝えていないでしょうか。この頼み方だと、どこまでやれば終わりなのかが決まりません。テスト体制は誰が何人でやるかという話、テスト設計は何をどこまで測るかという話です。人数より先に、測る範囲を決めておく必要があります。
手がかりになる資料があります。IPA（独立行政法人情報処理推進機構。情報処理の分野で国が設立した法人）が公開している「ソフトウェア開発分析データ集2022」です。*1 この資料には、集めるデータを並べた項目の一覧が載っています。*1 そのなかに、テストの網羅の度合い（決めた項目のうちどれだけをテストで確かめたかという割合。ここではカバレッジと呼びます）を記入する項目が6つあります。*1
本記事は、開発の現場を回しているマネージャに向けたものです。前半で資料の区分を、後半で外部エンジニアへの頼み方を整理します。
目次
カバレッジは工程ごとに4種類に分かれている
ここで見ていくのは、IPAが案件のデータを集めるときに使う項目の一覧です。*1 記入するのは、データを提供する企業のほうです。*1 IPAが決めた基準に自社が従う、という話ではありません。
資料はデータ項目433から438までの6つを用意しており、名前としては仕様、機能、構成、コードの4種類のカバレッジに分かれます。*1 コードカバレッジだけが命令網羅、分岐網羅、条件網羅の3項目に分かれているため、名前は4つ、項目は6つという数え方になります。*1
| 項目 | 補足説明に書かれている工程 | 資料の定義 |
|---|---|---|
| 433_仕様カバレッジ | 要件定義工程 | 仕様に規定された事項のうち、テストを実施した割合 |
| 434_機能カバレッジ | 基本設計工程 | 仕様を実現するために必要な機能のうち、テストを実施した割合 |
| 435_構成カバレッジ | 詳細設計工程 | 機能を実現するために必要な構成のうち、テストを実施した割合 |
| 436_コードカバレッジ（命令網羅） | 記載なし | コード内の全ての命令のうち、テストを実施した割合 |
| 437_コードカバレッジ（分岐網羅） | 記載なし | コード内の全ての分岐のうち、テストを実施した割合 |
| 438_コードカバレッジ（条件網羅） | 記載なし | コード内の全ての条件の真偽の組み合わせのうち、テストを実施した割合 |
資料はこう書いています。「開発工程（基本設計、詳細設計、製作）に沿って段階的に詳細化された成果物に着目して、仕様カバレッジ、機能カバレッジ、構成カバレッジおよびコードカバレッジを定義している」。*1
個々の項目の補足説明には、工程名がもっとはっきり書かれています。仕様カバレッジには「要件定義工程のソフトウェア要件定義の結果に含まれる『要求仕様』に着目したテストカバレッジ」、機能カバレッジには「基本設計工程のソフトウェア方式設計の結果に含まれる『要求仕様を実現するための外部機能』に着目したテストカバレッジ」、構成カバレッジには「詳細設計工程のソフトウェア詳細設計の結果に含まれる『外部機能を実現するための内部構成』に着目したテストカバレッジ」。*1 3つとも、どの工程の成果物を見るのかが名指しされています。*1
コードカバレッジの3項目には、補足説明に工程名がありません。書かれているのは「C0カバレッジとも言う」「C1カバレッジとも言う」という別名だけです。*1 先の一文が挙げる3工程のうち残るのは製作なので、コードを見る項目は製作にあたると読めますが、これはこの記事での読み取りで、資料がそう書いているわけではありません。
成果物とは、工程ごとに作られるもののことです。要件定義では何を作るかを決めた文書、基本設計では外から見える機能を決めた文書、詳細設計では中の作りを決めた文書、製作ではコードそのものが対象になります。この言い換えは読みやすさのためにこの記事で置いたもので、資料の文そのものではありません。
構成カバレッジの「構成」について、資料は内部構成の例として「コーディング、コンパイルおよびテストを実施する単位になるソフトウェアユニット（またはモジュール）」を挙げています。*1 プログラムを分けた1つひとつのかたまりです。命令はコードに書かれた処理の1文、分岐は処理の枝分かれ、条件の真偽の組み合わせは、その枝分かれを決めている条件の組み合わせです。
選択肢に「不明」と「未測定」がある
選択肢は6項目すべてで共通です。a：100％、b：80％以上、c：50％以上、d：50％未満、e：不明、f：未測定の6つから選ぶ形になっています。*1 このうち達成した水準を表すのは前の4つで、残る2つは水準ではありません。*1
注目したいのは、最後の2つです。資料は「不明」と「未測定」を別の選択肢として並べていますが、それぞれが何を指すのかまでは書かれていません。*1 2つが分けて用意されているのは、測らないまま終わる案件があるからだと読めます。これはこの記事での読み取りです。
この6つは、終わった案件の実績をあとから記入するための選択肢です。*1 水準を表す4つを目標の言葉として借りれば、「だいたい終わった」ではなく同じ言葉で報告を受け取れます。ここから先は、この記事での使い方の提案です。刻みは4段階なので、もっと細かく約束させるなら依頼書に数字を書きます。
なお、6項目に実際の案件がどう答えたのかという集計は、今回参照した範囲の資料には載っていませんでした。どれだけの案件が「未測定」を選んでいるのかは、この記事では確かめられていません。
テスト設計に置き換えると、ここが要点です。「テストはお願いします」で頼むと、どれをどの水準まで測るのかが決まりません。決まっていなければ、終わったあとに何を報告してもらうのかも決まりません。
外部エンジニアへの頼み方
ここからは、外部エンジニアへの頼み方です。資料がこの頼み方を示しているわけではなく、工程ごとの区分からこの記事で組み立てたものです。
1つめは、4種類のうちどれを測るのかを決めることです。要件定義の内容まで確かめてほしいのか、コードの中身までか。この2つは、要る時間も要るスキルも違います。
2つめは、水準を決めることです。選択肢のうち水準を表すのは100％、80％以上、50％以上、50％未満の4つです。*1 この刻みをそのまま借りれば、「機能カバレッジは80％以上」という書き方ができます。
3つめは、測った結果をどこに残すかを決めることです。どの文書に、どの頻度で書くかまで決めます。決めずに進めると、契約が終わったあとにどこまで測ったのかを社内の誰も答えられなくなります。
つまずきやすい難所
一つめのつまずきは、カバレッジを1つの数字だと思うことです。資料は4種類を分けて定義しています。*1 「カバレッジ80％」とだけ言われたら、どの種類の話かを聞き返します。
二つめは、水準を決めずに「できるだけ」と伝えることです。資料は水準として100％、80％以上、50％以上、50％未満の4つを用意しています。*1 どの段階にするかを先に選べば、報告も同じ言葉で返ってきます。ただし、どの水準が妥当かは今回参照した資料に記載がありません。
三つめは、テスト体制の話とテスト設計の話を混ぜることです。先に測る範囲を決めておくと、人数を決める根拠になります。範囲が決まっていないまま人数だけ決めると、何人いれば足りるのかを誰も言えません。この順番も資料が示したものではありません。
外注時に確認しておきたい点
外部エンジニアに頼むときは、発注する側が依頼書に3行書き足します。たとえば「測るのは機能カバレッジと構成カバレッジ」「水準は80％以上」「結果は週次の報告書に残す」。この3行があれば、終わりの線がはっきりします。80％は選択肢の刻みから選んだ例で、資料がこの水準を示しているわけではありません。
外部の要員（自社の社員ではなく、作業を委託して働いてもらう人。個人のフリーランスのほか、開発を請け負う会社に所属している人も含みます）に頼む場合、この3行は契約の期間を決めるときにも使えます。測る範囲が広いほど時間がかかるためです。
正社員を採用するのか外部の要員に頼むのかを決めるときも役に立ちます。コードカバレッジで見るのはコードですが、仕様カバレッジで見るのは要件定義の文書なので、その業務の中身を読み解く必要があります。この見立ても資料が述べていることではありません。
テストにあたる人のスキルと人数をどの区分で書き出すかは外部エンジニアのテスト体制、IPAが定める4つの区分で扱っています。
うまくいかなかったことの残し方は外部人材活用はなぜ失敗する？IPAが定める変更の4段階にまとめました。
規模の数え方は業務委託エンジニアとシステム連携、機能とデータの数え方の違いで整理しています。
入ってもらう人のスキルの確かめ方は外部エンジニアのスキル確認、4つの軸で評価するにあります。
まとめ：テストを頼む前に決める3つのこと
外部エンジニアにテストを頼む前に決めることは3つです。第一に、どのカバレッジを測るのか。IPAの資料は、仕様カバレッジを要件定義工程、機能カバレッジを基本設計工程、構成カバレッジを詳細設計工程の成果物に着目したものとして説明しています。*1 第二に、どの水準まで測るのか。水準を表す選択肢は100％、80％以上、50％以上、50％未満の4つです。*1 第三に、測った結果をどの文書にどの頻度で残すのか。なお、どの水準が妥当かについて、今回参照した資料に記載はありません。
よくある質問
「ソフトウェア開発分析データ集2022」では、網羅の度合いを何で記録しますか
データを提供する企業が、データ項目433から438の6つに記入します。*1 名前としては仕様、機能、構成、コードの4種類のカバレッジで、コードカバレッジだけが命令網羅、分岐網羅、条件網羅の3項目に分かれます。*1 確認日は2026年9月19日です。
4種類はどう違うのですか
着目する成果物が違います。個々の補足説明では、仕様カバレッジが要件定義工程、機能カバレッジが基本設計工程、構成カバレッジが詳細設計工程の成果物に着目したものとされています。*1 コードカバレッジの補足説明に工程名の記載はありません。確認日は2026年9月19日です。
選択肢は何がありますか
100％、80％以上、50％以上、50％未満、不明、未測定の6つです。*1 前の4つが達成した水準を表し、後ろの2つは水準ではありません。*1 確認日は2026年9月19日です。
どの水準を目標にすればよいですか
今回参照した資料に記載はありません。資料に載っているのは、項目の定義と選択肢までです。6項目に案件がどう答えたかという集計も、今回参照した範囲にはありません。確認日は2026年9月19日です。
テスト体制の人数はどう決めますか
この資料からは決められません。先に測る範囲と水準を決めておくと人数を決める根拠になりますが、これは資料が示した順番ではありません。確認日は2026年9月19日です。
測る範囲と水準が決まったら相談
「機能カバレッジを80％以上まで」という形で範囲と水準が決まっていれば、そのままご相談いただけます。まだ決めきれていない段階でも構いません。
Remoguとリラシクなら、コードの中身まで測る要員も、要件定義で決めた仕様まで確かめる要員も、作業と期間を決めたうえでお探しいただけます。
Remoguは、リモート前提で全国から即戦力のITプロ人材を調達するサービスです。リラシクは、扱う求人がすべてリモートワークのITエンジニア専門転職エージェントです。どちらもLASSICが運営しています。
出典
- *1 参考：IPA「ソフトウェア開発分析データ集2022」（PDF）（https://www.ipa.go.jp/digital/software-survey/metrics/hjuojm000000c6it-att/000102171.pdf）。出典：IPA「ソフトウェア開発分析データ集2022」。独立行政法人情報処理推進機構 社会基盤センター発行。データ項目433から438のカバレッジの定義、補足説明、選択肢、およびデータ収集フォームの項目名の一次情報として。IPAの資料は無断で改変したり配り直したりできないため、この記事は示された定義を引用し、表と図は内容をもとに作成した。資料の図表そのものは写していない（2026年9月確認）
- *2 参考：IPA「ソフトウェア開発分析データ集2022」（公開ページ）（https://www.ipa.go.jp/digital/software-survey/metrics/metrics2022.html）。本編と業種編・サマリー版という構成と、収録されている指標の範囲の確認として（2026年9月確認）
- *3 参考：IPA「ソフトウェア開発分析データ集」（https://www.ipa.go.jp/digital/software-survey/metrics/index.html）。年度ごとに公開されていることの確認として（2026年9月確認）
