LASSIC Media らしくメディア

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

頼んだ機能は届いたものの、どこまで確かめれば受け取ってよいのか分からない。契約の更新が近いのに、この数か月の作業をどう振り返ればよいのかが決まっていない——。業務委託エンジニアに開発や保守を任せている現場では、こうした迷いが起こりがちです。業務委託エンジニアの参画後の評価とは、参画したエンジニアが納めた成果物と、契約にもとづいて行った作業を、決めておいた基準に照らして確かめることを指します。

評価の手順を決めておけば、受け取るかどうかの判断が担当者によって変わらず、次に頼む作業の中身も決めやすくなります。ただし万能ではなく、作業を頼む前に基準を決めていなければ、あとから公平に評価するのは難しくなります。本記事では、開発チームを管理するマネージャーに向けて、評価の対象、検収と受入テストの違い、合否の基準の決め方、確かめる手順と振り返り、そして外部に頼むときに確認したい点を整理します。

業務委託エンジニアの参画後の評価とは

参画後の評価は、社員の人事評価とは見るものが違います。人事評価は、社員の働きぶりを昇給や昇格に結びつける仕組みです。業務委託エンジニアとの間で決めてあるのは、頼む作業と、納めてもらう成果物です。評価の対象もこの2つで、本人の人柄や印象ではありません。

この考え方の手がかりになるのが、経済産業省の「システム管理基準」です。情報システムを管理するときに目指す状態と、そのための作業の例をまとめた文書で、2023年4月26日に改訂されました。外部委託管理の項目は、管理活動の例として、外部委託契約の実施状況を評価して契約どおりに委託が行われるよう維持することと、「外部委託契約に基づいて検収を実施し、成果物を受け入れる」ことを挙げています。^*1

ここから、評価には2つの種類があることが分かります。1つは、納められた成果物を確かめて受け取るときの評価です。もう1つは、契約期間を通して、決めた作業が決めたとおりに行われているかを見る評価です。前者は機能の追加や改修を受け取るたびに、後者は月ごとや契約の更新の前に行います。

検収と受入テストの違い

成果物を受け取る場面では、検収と受入テストという2つの言葉がよく出てきます。デジタル庁の「デジタル・ガバメント推進標準ガイドライン」は、国の情報システムを整備し管理する手順を定めた文書です。その解説書は検収を、決めた成果物が決めた方法で納品されているか、要件定義書（発注する側が求める機能や条件をまとめた文書）などで求める要件と品質を満たしているかを確かめ、受け取ることとしています。^*3

受入テストは、テストするシステムが業務で意図した仕様で動き、実際の運用で使える状態にあるかを確かめることです。解説書は、検収と受入テストを混同しないよう求めています。システムを作る仕事では、設計書などの書類だけでなくシステムそのものも成果物になります。解説書は、受入テストで見つかった不具合の修正と、本番の環境への移行が済んだことを、検収の前に確かめる必要があるとしています。^*3

解説書はあわせて、検収では成果物だけでなく、成果物の品質を保証していることが分かる資料の作成と提出を、受注した事業者（委託先）に求めるとしています。^*3 業務委託エンジニアに当てはめると、プログラムを受け取るときに、どんなテストを行い、見つかった不具合をどう直したかという記録も一緒に受け取る、ということです。

合否の基準を決める時期

評価でいちばん食い違いやすいのは、受け取ってよいかどうかの基準です。解説書は、調達仕様書（発注する内容を書いた文書）の成果物の取扱いの項目に、検収の基準と、検収の結果が基準に満たない場合の修正方法の取決めを書いておくとしています。^*3 基準と、満たさなかったときの直し方は、作業を頼む時点で決めておくということです。

受入テストについては、テスト計画書に書く事項が表で示されています。テスト体制、テスト環境、作業内容、作業スケジュール、テストシナリオ、合否判定基準の6つです。^*3

国の大きなシステムを前提にした表ですが、業務委託エンジニアに1つの機能の追加を頼む場合にも使えます。たとえば会員登録の画面に入力チェックを追加するなら、合否判定基準の欄に「郵便番号の欄に7桁の数字以外を入れると登録できず、理由が表示される」と書きます。テストシナリオの欄には、確認に使う入力の例と、結果として受け取る画面の写しを書いておきます。基準を文にしておけば、受け取る側の担当者が替わっても判断は変わりません。

成果物を確かめる手順

基準が決まっていれば、成果物を受け取るときの手順は4つに分けられます。システム管理基準は、ユーザ受入テスト（利用者の立場から行うテスト）の項目で、業務で必要な条件を満たしていることを示す資料を受け取って内容を確かめること、結果を文書にして承認を得ること、見つかった不具合と改善の結果を記録して改善の状況を追うことを挙げています。^*1 これを業務委託エンジニアの成果物に当てはめると、次の流れになります。

1. 成果物と、品質を確かめた記録（行ったテストと、直した不具合）を受け取る
2. 決めておいた合否判定基準に照らして、成果物を確かめる
3. 合否とその根拠を文書に残し、受け取りを決める権限のある人の承認を得る
4. 不合格の点は、どの基準に満たないかを示して直してもらい、直ったことを確かめて記録する

4つ目の直してもらい方について、解説書は、合否判定基準を満たさず課題がある場合に、課題の箇所と指摘事項を明らかにしたうえで事業者に指摘し、プログラムなどを修正させることとしています。重大な課題や、他の工程に影響する課題、原因を分析する必要がある課題は、課題の一覧に載せて対応を追い、進捗の報告会などで関係者と共有するとしています。^*3

口頭で「ここがおかしい」と伝えるだけでは、どの基準に照らして不合格なのかが残りません。指摘は、基準の文と、実際に起きた結果を並べて書いておくと、直す側も何を直せば合格になるのかが分かります。この記録は、あとで行う振り返りの材料にもなります。

契約期間中の作業の見方

成果物がはっきりしない作業もあります。保守での問い合わせへの対応や、設計の相談に応じる作業などです。こうした作業は、決めた作業が決めたとおりに行われているかを、実績の記録で見ます。標準ガイドラインは運用と保守について、毎年度末までに、その年度の実績から作業効率や作業項目の過不足を評価・検証するよう定めています。^*2

解説書は、この評価では表面上の出来事から結論を出さず、定期の会議などで報告された詳しい実績値で事実を捉えてから分析するよう求めています。作業が遅いという印象だけで判断せず、どの作業に何時間かかったかを確かめてから話し合う、ということです。そのうえで、状況ごとに原因を分けて、改善を考える例を表にしています。

同じ「時間がかかる」という状況でも、原因によって取るべき対応が変わります。手順書が無いことが原因なら、エンジニアを替えても同じことが起こります。状況と原因を分けて書き出すと、エンジニアの作業の進め方に問題があるのか、頼む側の作業の決め方に問題があるのかを見分けられます。

標準ガイドラインは、運用作業と保守作業の改善を、定期的に、たとえば半年に一度行うとしています。^*2 業務委託の契約を3か月や半年ごとに更新しているなら、更新の前に1回、この形で作業を見直しておくと、更新するかどうかや、頼む作業を変えるかどうかを決めやすくなります。

契約の終わりに行う振り返り

契約期間が終わるときや、大きな作業の区切りでは、振り返りを行います。解説書は、プロジェクトを完了するときに、得た経験を今後に生かすため振り返りを行うことが重要だとしています。そのうえで、振り返りでは「良い点、悪い点を分析して、今後のプロジェクトに活かすべき教訓をまとめることが望ましい」としています。^*3

業務委託エンジニアとの振り返りでも、良い点と悪い点の両方を挙げます。良い点は、次の依頼でも同じやり方を続けるための材料になります。悪い点は、エンジニアの作業の問題なのか、頼む側の仕様の決め方や基準の示し方の問題なのかを分けて書きます。先に見た受け取りの記録と指摘の記録があれば、印象ではなく記録をもとに話し合えます。

システム管理基準は、システムが動き始めたあとの評価の項目で、数えられる目標（定量的な目標）だけでなく、数えにくい目標（定性的な目標）についても、客観的な証拠を示すことを達成目標に挙げています。^*1 不具合の件数や作業時間のように数えられる結果だけでなく、「設計の意図を説明する資料が残っている」「質問への回答が次の作業に使える形で残っている」のような数えにくい結果も、実際の資料で確かめます。

振り返りの場で、取引の条件や作業の中身の変化を聞き、離任の予兆に気づく方法は「業務委託エンジニアの離任の予兆と、振り返りで聞く3つの点」で扱っています。受入テストの進め方をさらに詳しく知りたいときは「システム開発の検収・受入テストの進め方」も参考になります。

つまずきやすい点

一つ目は、合否の基準を成果物が届いてから決めることです。発注する側は基準を厳しくしがちで、委託先は後から条件が増えたと感じます。基準と直し方は、作業を頼むときの依頼書や契約の段階で文にしておきます。

二つ目は、評価の対象が人に移ってしまうことです。「反応が遅い」「頼りない」といった印象で評価すると、何を直せばよいのかが相手に伝わりません。見るのは、決めた成果物と作業が、決めた基準を満たしたかどうかです。印象が気になるときは、それがどの作業の、どの結果から来ているのかを記録で確かめます。

三つ目は、検収で受け取ったあとに見つかった不具合の扱いを決めていないことです。受入テストで見つからなかった不具合が、受け取ったあとに出てくることもあります。標準ガイドラインは、成果物の取扱いに関する事項として、検収とあわせて契約不適合責任（納めた物が契約の内容に合わないときの責任）についても調達仕様書に書くとしています。^*2 受け取ったあとに不具合が見つかったとき、誰にいつまでに連絡し、どう直してもらうかも、頼む前に決めておきます。

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

業務委託エンジニアを探す段階で、評価の進め方も相手と合わせておくと、参画後の評価が進めやすくなります。標準ガイドラインは、調達仕様書の作業の実施内容に関する事項として、作業の内容、納める成果物、納品の期日などを書くとしています。依頼の規模が小さくても、この3つは書いておけます。

そのうえで、委託先に確認しておきたいのは次の3つです。何を成果物として納めてもらうか。成果物と一緒に、品質を確かめた記録を出してもらえるか。作業の実績を、どのくらいの頻度で、どんな形で報告してもらうか。委託先がこの3つに答えられれば、参画した後の評価も、受け取りの記録と作業の記録をもとに進められます。

まとめ：参画後の評価で確かめておきたい3つの点

業務委託エンジニアの参画後の評価を進めるうえで、確かめておきたい点は3つに整理できます。第一に、評価の対象を人ではなく成果物と作業に置き、合否の基準と直し方を作業を頼む前に決めておくこと。第二に、検収と受入テストを分け、品質を確かめた記録と一緒に成果物を受け取ること。第三に、契約期間の途中と終わりに、実績の記録をもとに良い点と悪い点を振り返ることです。この3点を踏まえておけば、「受け取ったあとで、頼んだものと違うと気づいた」という事態を避けやすくなります。評価の進め方に迷いがあれば、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：経済産業省「システム管理基準」（令和5年4月26日）（PDF）（https://www.meti.go.jp/policy/netsecurity/sys-kansa/sys-kanri-2023.pdf）。出典：経済産業省「システム管理基準」（令和5年4月26日）。Ⅱ.2.6 外部委託管理（管理活動の例5・6）、Ⅱ.4.4 ユーザ受入テスト（管理活動の例2〜4）、Ⅱ.4.6 稼動後評価と報告（達成目標3）を参照（2026年9月確認）
2. *2　参考：デジタル庁「DS-100 デジタル・ガバメント推進標準ガイドライン」（PDF）（https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/54d8725e/20260715_resources_standard_guidelines_guideline_01.pdf）。出典：2026年6月12日 デジタル社会推進会議幹事会決定。第3編第6章2.1)エ「作業の実施内容に関する事項」・キ「成果物の取扱いに関する事項」、第3編第7章の冒頭（開発手法の読み替え）、第3編第9章3.「運用及び保守の改善」を参照（2026年9月確認）
3. *3　参考：デジタル庁「DS-110 デジタル・ガバメント推進標準ガイドライン解説書」（PDF）（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日版。第2章7.の解説(3)（振り返り）、第6章2. 表6-8の[3]検収、第6章7.「検収」の趣旨と解説(1)、第7章7.「受入テストの実施」の趣旨・表7-4と解説(3)、第9章2. 表9-7の[5]、第9章3.「運用及び保守の改善」の趣旨・解説(1)と表9-9を参照（2026年9月確認）

Tweet