LASSIC Media らしくメディア

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

外部エンジニアに開発を頼むとき、単体テストを誰がどこまで行い、社内は何を確かめればよいのかは決めにくいところです。単体テストは、プログラムの部品を1つずつ動かして、設計どおりに動くかを確かめるテストのことです。項目が細かく数も多いため、社内の担当者がすべてを見直そうとすると、それだけで手が止まってしまいます。

特許庁が公表している設計・開発ガイドラインは、この点に1つの答えを出しています。単体テストの項目表は開発する事業者の手元で管理し、特許庁の側は計画書と結果報告書、次の工程への申し送り事項を受け取って確かめる、という分担です。本記事では、このガイドラインとデジタル庁の標準ガイドライン解説書をもとに、外部エンジニアが加わる開発で、単体テストのテスト体制をどう組めばよいかを解説します。

単体テストは作った人が行う

特許庁の「特許庁システム設計・開発ガイドライン（システム刷新＆新規システム構築編）」第1.3版は、プログラムを作り、単体テストまで行う工程を「ソフトウェア構築プロセス」と呼んでいます。目的は「プログラム設計を適切に反映した実行可能なソフトウェアコードを作り出すこと」とされ、対応する工程の名前は「プログラム設計・製造・単体テスト工程」です。^*1 単体テストは、プログラムを作る作業と切り離さず、同じ工程の中で行うものとして扱われています。

この工程で手を動かすのは、ガイドラインでAP-Vと呼ばれる、設計・開発を請け負う事業者です。AP-Vはプログラムのソースコードを作り、そのソースコードについて、ソフトウェアユニット（テストできる最小の部品）の単位で単体テストを行います。^*1 特許庁の側で実際の作業を受け持つ単位PJ（設計・開発単位プロジェクトチーム）は、テストを自分で行うのではなく、報告を受けて内容を確かめる立場です。

外部エンジニアに開発を頼む場合も、この形はそのまま当てはまります。コードを書いた人が、そのコードの単体テストも書いて流すのが自然です。社内でテスト体制として決めるべきなのは、単体テストを誰が行うかよりも、その結果を社内の誰がどの書類で受け取り、何を見て次の工程へ進めるかのほうです。

受け取る書類と手元に残す書類

ガイドラインは、工程ごとに作る成果物について、誰が作って誰に示すかを表にしています。^*1 単体テストの工程で作るもののうち、テストにかかわる書類を抜き出すと次のとおりです。書類の目的は、ガイドラインの別紙3の記載をもとにしています。

別紙3では、計画書は「単体テスト計画について関係者と意識を合わせるために」作り、結果報告書は「単体テストを実施したことを示すために」作るとされています。^*2 項目表だけは、項目を一覧にして管理するための書類で、示す先が作った事業者自身になっています。発注する側に届くのは、どう進めるかを書いた計画と、行った結果をまとめた報告、そして積み残しの一覧です。

書類の名前にこだわる必要はありません。ガイドラインは、出力成果物の名称は事業者が「自由に決定して良く」、どの書類に何を書くかにも裁量があるとしています。^*1 そのうえで、書くべき要素に「漏れがあってはならない」とも定めています。少人数のチームなら、計画はチケットの説明欄に、結果はテストの実行結果とひとことの所見で、という形でも中身はそろえられます。大事なのは書類の数ではなく、計画と結果と積み残しの3つが社内に届くことです。

なぜ項目表まで見ないのか

項目表を発注する側に示さない理由について、ガイドラインは脚注で「単体テストは細かい項目が多く単位PJがチェックすることは現実的ではない」と説明しています。^*1 さらに、既存のシステムを改造する場合でも、この部分のチェックはしていないと添えています。

単体テストの項目は、関数に渡す値の組み合わせや、境界の値、エラーの起き方など、コードの細部に沿って増えていきます。コードを読み込んでいない人が一つずつ見ても、項目の抜けに気づくのは難しいでしょう。社内の担当者が項目表の見直しに時間を使うと、計画が妥当か、結果から品質の傾向が読み取れるかといった、本来見るべき点が後回しになります。

見ないと決めることは、任せきりにすることとは違います。ガイドラインの分担は、細部は作った人が責任をもって管理し、発注する側は計画と結果で押さえる、という線の引き方です。項目表そのものは事業者の手元に残るので、結合テストで不具合が見つかったときなど、必要になった時点で見せてもらう取り決めにしておけば十分です。

計画書で先に決めておくこと

計画書に何を書くかについて、ガイドラインは「目次案2」としてテスト計画書とテスト結果報告書の目次を示しています。^*3 計画書の大きな項目は、目的と概要、テストスケジュール、テスト体制、テスト環境、テスト内容、完了基準の6つです。外部エンジニアに単体テストを頼む場面に当てはめると、それぞれで決めておくことは次のように整理できます。

なかでも外部エンジニアと先に決めておきたいのが完了基準です。完了基準が無いまま始めると、「テストは書きました」という報告と、社内が期待していた「この範囲は確かめ終えた」という状態がずれやすくなります。たとえば、対象の部品すべてにテストがあり、すべて通っていること、通らないものは理由と扱いが書かれていること、のように、報告を見れば判定できる言葉で書いておきます。

テスト体制の欄には、単体テストを書く外部エンジニアの名前だけでなく、結果を受け取る社内の担当者と、工程の終わりを承認する人を書いておきます。この3者が計画の段階で決まっていれば、報告の宛先に迷うことも、承認が宙に浮くこともありません。

途中の報告で確かめること

デジタル庁の「デジタル・ガバメント推進標準ガイドライン解説書」は、発注する側でプロジェクトを管理する組織（PJMO）が、開発する事業者に「実装及び単体テストの実施状況」の報告を求め、内容を確かめて指摘や指導を行うとしています。^*4 ここでいう実施状況は、計画のスケジュールに対する実装作業の進み具合、テスト計画書に基づく単体テストの進み具合、テスト結果、品質状況の4つを指します。

この4つを外部エンジニアからの報告に当てはめると、聞くことは次のように整理できます。実装はどこまで進んだか。テストはいくつ書いて、いくつ流したか。そのうち通らないものはいくつあり、原因は何か。そして、不具合が特定の部品に集まっていないか、です。数だけを並べた報告より、通らないテストとその扱いの方針が書かれた報告のほうが、社内で判断しやすくなります。

報告の頻度も計画書で決めておきます。工程の終わりにまとめて報告を受ける形だと、問題が見つかったときの手戻りが大きくなります。週に一度、あるいは機能の区切りごとなど、実装の進み方に合わせた頻度で短い報告を受けるようにしておくと、早めに手を打てます。

申し送り事項で次の工程へつなぐ

単体テストの工程で起きた課題のうち、その工程の中で解決できない事項は、次の工程への申し送り事項として整理します。^*1 ガイドラインでは、単位PJが申し送り事項について「未解決課題の解決目途や次工程作業への影響」を確かめ、申し送れないものは事業者に対応を求めることになっています。

外部エンジニアとの開発では、つなぐ先のサービスがまだ使えない、仕様が決まっていない部分を仮の値で作った、といった理由で、単体テストでは確かめきれない部分が残ることがあります。こうした部分を報告に書かないまま次へ進むと、結合テストで初めて問題が見つかり、どこに原因があるのかを切り分けるのに時間がかかります。

申し送り事項には、何が確かめられていないか、なぜ単体テストで確かめられなかったか、いつ、どの工程で確かめるかの3点を書いてもらいます。社内の担当者はその一覧を見て、次の工程で引き受けられるか、今の工程のうちに片づけてもらうべきかを決めます。申し送りを受けた後の結合テストでの役割の分け方は、結合テストの役割分担を解説した記事で扱っています。

工程の終わりは社内で承認する

ガイドラインでは、この工程は、プログラム設計書が作られ報告されていることを開始の基準とし、工程の終了判定の承認が得られていることを終了の基準としています。^*1 終了を承認するのは、プロジェクトの統括責任者で成果物の承認者でもある個別PE（プロジェクト責任者）です。

書類を作るのもテストを行うのも開発する側ですが、工程を終えてよいかを決めるのは発注する側の責任者です。外部エンジニアがどれほど経験を積んだ人であっても、この判断まで預けてしまうと、社内には「なぜ次へ進めたのか」の記録が残りません。計画書の完了基準と、結果報告書、申し送り事項の3つを並べ、社内の責任者が承認したことを記録に残しておきます。

承認の場では、完了基準を満たしているか、満たしていない部分は申し送りに載っているか、申し送りの量が次の工程で引き受けられる範囲かを確かめます。ここで引っかかる点があれば、工程を延ばして片づけてもらうか、範囲を絞って次へ進むかを社内で決めます。

外部エンジニアに頼む前に決めること

ここまでの内容を、外部エンジニアに単体テストを含む開発を頼む前の準備として整理すると、次のようになります。

個人の外部エンジニアに社内のチームへ加わってもらう場合は、ガイドラインが想定する、事業者に工程ごと請け負ってもらう形とは事情が違います。それでも、細部は書いた人が管理し、社内は計画と結果で押さえ、終わりは社内で決める、という分け方はそのまま使えます。テストのコードは日々のコードレビューで目に入るので、レビューで気になった点を次の報告で答えてもらう、という進め方も考えられます。テスト体制の全体をスキルと人数のどちらから考えるかは、外部エンジニアのテスト体制、IPAが定める4つの区分にまとめました。

どの形で頼むにしても、契約で何を成果として受け取るかが、テストの取り決めと食い違っていないかは確かめておきます。契約の書き方に迷う場合は、社内の契約の担当者や専門家に確かめたうえで進めてください。

まとめ：単体テストのテスト体制で押さえる3つの点

外部エンジニアに単体テストを含む開発を頼むときに押さえておきたい点は、3つに整理できます。第一に、単体テストはコードを書いた外部エンジニアが行い、社内は計画書と結果報告書、申し送り事項の3つで押さえること。第二に、細かい項目表は作った人の手元で管理してもらい、そのかわり完了基準と報告の形を計画書で先に決めておくこと。第三に、工程を終えてよいかは社内の責任者が判断し、その記録を残すことです。この分け方を最初に共有しておけば、「テストは済んだと聞いていたのに、つないでみたら動かない」という事態を避けやすくなります。テスト体制の組み方に迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：特許庁「特許庁システム設計・開発ガイドライン（システム刷新＆新規システム構築編）（第1.3版）」（https://www.jpo.go.jp/system/laws/sesaku/gyomu/document/system_kouchiku_13/all.pdf）。出典：特許庁「特許庁システム設計・開発ガイドライン（システム刷新＆新規システム構築編）（第1.3版）」（平成30年4月）。0.6（ステークホルダ）、1.1.1（プロジェクト計画書の作成）、6.の出力成果物、7.ソフトウェア構築プロセス（入力成果物／出力成果物の表と脚注8、開始基準／終了基準、7.1.4、7.1.6、7.2、7.3）を参照（確認日2026年10月7日）（2026年10月確認）
2. *2　参考：特許庁「特許庁システム設計・開発ガイドライン 別紙3」（https://www.jpo.go.jp/system/laws/sesaku/gyomu/document/system_kouchiku_13/besshi_3.pdf）。出典：別紙3（成果物要素）のうち、No.86 単体テスト計画書、No.87 単体テスト項目表、No.88 単体テスト結果報告書の説明を参照（確認日2026年10月7日）（2026年10月確認）
3. *3　参考：特許庁「特許庁システム設計・開発ガイドライン 目次案2（テスト計画書・テスト結果報告書）」（https://www.jpo.go.jp/system/laws/sesaku/gyomu/document/system_kouchiku_13/mokuji_2.pdf）。出典：テスト計画書とテスト結果報告書の目次案を参照（確認日2026年10月7日）（2026年10月確認）
4. *4　参考：デジタル庁「デジタル・ガバメント推進標準ガイドライン解説書」（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章 5.開発・テストの実施・管理の1)機能の実装・単体テストと解説(1)を参照（確認日2026年10月7日）（2026年10月確認）

Tweet