--- type: guideline title: Step.3 調達仕様書の作成 source: デジタル庁 ds_code: ds-120 category: government-system updated: 2025-06-19 source_url: https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/9ab95eed/20250619_resources_standard_guidelines_guideline_06.zip --- # Step.3 調達仕様書の作成 調達仕様書は、発注者側の要望（要件）だけでなく、制約となる条件を記載するものです。実現したいことを書くことはもちろんですが、実現を図っていく過程で守るべき前提条件や制約条件を合わせて書くことで、調達仕様書としての完成度を高めることができます。 このStepでは、調達仕様書を作る上で知っておくべき知識・ノウハウをご紹介します。 ## 関連ドキュメントとの関係性を理解する 【標準ガイドライン関連箇所：第３編第６章第３節】 調達では、調達仕様書以外にも次のようなドキュメントが存在します。それぞれのドキュメントの定義と関係性をあらかじめ理解しておくことが重要です。 - 図6-3
![](../assets/ds-120-ch06-image7.png)

調達に必要なドキュメントの関係図

### 調達仕様書と要件定義書の住み分けを理解する 調達案件で満たすべき要件の内容は、調達仕様書の中に全部書いた方が良いのでしょうか？それとも、要件定義書として添付の付属文書にした方が良いのでしょうか？ 要件の内容は、様々な内容を取りまとめたものであるため、調達仕様書に直接記載するのではなく、要件定義書を別紙として、調達仕様書に添付することが一般的です。 要件の内容を別文書とした方が良い理由 - 要件定義の内容は、事業者の提案等を踏まえて、事業者の決定後に発注者との協議を経た上で最終的に決定するものです。つまり、要件定義の内容には変更が入ります。一方で、調達仕様書の内容は、よほどのことがない限り、変更しません。これらに対する変更は明確に分けて管理する必要があり、調達仕様書と要件定義書を分離することで、変更管理が容易になります。 - 要件定義の内容は、詳細な内容を記載するため量が多くなる傾向があります。調達仕様書の中に全てを記載しようとすると読みにくくなってしまうおそれがあります。 - 調達仕様書の中に調達に関連する要件のみを記載しようとすると、要件の全体像がわからなくなったり、記載事項が漏れたりする可能性があり、適切な提案や見積りを妨げるおそれがあります。 - 要件定義書には「こういうシステムがほしい」、調達仕様書には「こういうシステムを作るために何をやってほしい」というように、読み手に伝えたい内容を分けることで可読性が増し、読み手の理解を深めることになります。 これらの内容を踏まえた上で、小規模な調達内容であったり要件の変更の可能性が低かったりする場合は、調達仕様書の中に要件定義の内容を記載することも可能です。 また、調達仕様書と要件定義書を分けた場合にも、調達仕様書には「要件定義書を満たす旨」のみをただ書けばよいわけではありません。調達単位を分割する場合は、要件定義書の内容のどの部分が当該調達で満たすべき部分かを指し示す必要があります。要件の中でも提案を求める部分や未確定の部分がある場合は、その箇所を明確にする必要があります。また、調達仕様書に要件定義書の内容のまとめと要件定義書の該当箇所への参照リンクを記載することで、外部事業者の理解を促す工夫をすることも有効です。 ポイントは、外部事業者が要件の内容を漏れなく正確に理解できるか？理解しやすい形式になっているか？です。 ### 付属文書を活用して可読性を上げ機密性を確保する 調達仕様書には、応札等の検討に不可欠な情報を網羅的に示す必要がありますが、調達仕様書の本編に全てを記載することは困難です。無理に記載しようとすると、かえって調達内容が理解しにくいものとなってしまうおそれがあります。それを未然に防ぐため、情報量や粒度に応じて、別文書として準備し、調達仕様書の付属文書とすることを検討すべきです。 また、調達に必要な情報の中には、機密保持の観点から一般に公開できない内容も含まれます。このような内容は、独立した文書として準備し、その文書の閲覧を希望する外部事業者が閲覧手続きを発注者に対して行った上、発注者の立会いの下、執務場所での閲覧等として機密性を確保します。 付属文書は、調達仕様書の「付属文書」の事項にて、事業者が入手又は特別な手続きを経ずに閲覧できる資料一覧として整理し、公開しない文書については閲覧要領にて閲覧手続き方法を伝えます。 ### 既存情報システムの機能改修を行う場合に準備するドキュメントを理解する 既存情報システムの機能改修を行う場合には、「Step.3-1 調達ドキュメントとの関係性を理解する 図6-3 調達に必要なドキュメントの関係図」で示す当該情報システムの要件定義書とは別に、機能改修の要件を明確にした要件定義書を準備しましょう。 ## 調達仕様書の記載内容を理解する 【標準ガイドライン関連箇所：第３編第６章第３節1)】 この実践ガイドブックには、別添として、設計・開発工程の調達を例にした調達仕様書のひな形を示しています。 - 様式例6-１ 調達仕様書のひな形

様式例：調達仕様書のひな形

調達仕様書のひな形を本章別紙としてまとめています。

![](../assets/ds-120-ch06-image8.png)
このひな形はあくまで例示ですので、調達内容に応じて記載内容を個別に追加、変更して構いません。ひな形を見ると、何をどのようなレベルで書くべきかの参考になると思います。 以降では、調達仕様書を作成するときに、特に注意が必要なポイントについて説明していきます。項目の詳細な説明は、ひな形を参照してください。 ### 調達の意図や目的を正しく伝える 外部事業者に応札を促してプロジェクトにとって有用な提案を引き出すためには、プロジェクトの背景及び目的、調達に至るまでの経緯、成果物やサービスに期待する効果、プロジェクトの全体像や見通しといった発注者の意図を明確に伝えることがとても大切です。要件や作業内容を伝えるだけでは、要件どおりの情報システムを構築するために必要な提案は得られるかもしれませんが、プロジェクトの目的や目標をよりよく達成するために十分な効果を発揮する提案を引き出すことができません。 これらは、調達仕様書の「調達案件の概要に関する事項」にて、プロジェクトの背景、調達目的及び調達で期待する効果、業務・情報システムの概要にて記載するとともに、契約期間を含むプロジェクト全体のスケジュールで全体像を示します。 - 図6-4 作業スケジュール例 ![](../assets/ds-120-ch06-image9.png) ### 関連する調達、入札制限を伝える 事業者が応札を検討する際に、他の調達案件との関係性を理解してもらうことはとても重要です。事業者によっては後に予定している調達案件への応札を検討していることもありますので、過去や将来の調達案件、それらに係る入札制限も含めて明確に記載します。 今後調達する調達案件の全体像や入札制限の関係については、プロジェクト計画書で明確にした上で、その要点を早期から外部に公開することを推奨します。 もし、これらの関係が明確に示されておらず、事業者がある案件を落札し契約した後で、後続案件に入札できないことが判明すると、大きな問題になってしまいます。 関連する調達や入札制限を明確に記載し早期に公開することで、未然に上記のような事態を防ぐことが重要です。 - 図6-5 調達案件及び関連調達案件の調達単位、調達の方式、実施時期等の例 ![](../assets/ds-120-ch06-image10.png) ### 作業内容・納品物を関連付けて網羅的に記載する 調達仕様書では、外部事業者の作業内容、納品物をそれぞれ漏れなく定める必要がありますが、設計・開発等の調達では多種多様な作業や納品物があるため、漏れなく記載するのはなかなか難しいものです。 これらを定義する際は、作業内容、納品物を関連付けて定義していくことで、効果的に抜け漏れを確認していくことができます。 - 図6-6 作業の実施内容と納品物一覧の確認イメージ ![](../assets/ds-120-ch06-image11.png) このように作業の実施内容と納品物を関連付けて一覧としてまとめておくと、工程完了時の納品物のチェックにも活用でき、検収時の確認負荷を減らすことができます。 また、中小・スタートアップ企業など、資金繰り面の課題を抱えやすい企業の入札参加が具体的に見込まれる場合、単一年度内に複数回の検収・支払いタイミングを設定することも可能です。RFIや発注者と事業者が対話を通じて相互理解を深めた上で、納品物と納品期日、検収・支払いタイミングを検討しましょう。 ### 外部事業者の具体的な作業内容を明確にする 作業内容の記載から、事業者が実際に何を実施する必要があるのか、わかりにくいケースがときどき見受けられます。 例えば、「支援」という言葉は人によって解釈が大きく異なります。「マニュアル作成支援」という作業項目があった際に、職員が元となる原案や素材を用意した上で事業者が体裁を整えるという役割分担も考えられますし、事業者がマニュアルの原案自体を作成して職員が内容を確認するという役割分担も考えられます。このような役割分担の違いによって、事業者が実施する作業範囲や必要工数は大きく変わってきます。 実際に実施する内容が事業者に正確に伝わらない場合、以下のような事態をまねくおそれがありますので、事業者に実施を求める内容は正確に記述してください。 作業内容が曖昧な場合に懸念される事態 - 必要な人員のスキルや数について、応札希望者等の想定と発注者側の希望や想定とがミスマッチとなる場合、契約した後に業務を完遂できない。 - 作業を終えることができた場合であっても、成果物の品質（機能性、信頼性、使用性、効率性、保守性、移植性）が著しく低下する。 - 契約した外部事業者からの問合せや協議等が増加し、発注者側に想定していた以上の作業が発生する。 ### 作業の実施体制を明確にする 調達案件を通じてプロジェクトの活動を円滑に進めていくためには、発注者側であるＰＪＭＯや関係する職員が、体制や役割分担、責任範囲を明確にし、外部事業者と一緒に協働していくことがとても大切です。調達仕様書や要件定義書をしっかり記載して適切な外部事業者を選定することが仮にできたとしても、望んだ情報システムを必ずしも手に入れられるわけではありません。プロジェクトを進めていくと、要件の内容を設計として具体化・詳細化していく中で発注者側が決定しなければならないこと、他の関係者と調整しなければならないことは多く発生しますし、進捗上の課題や問題が発生した場合に発注者側の判断を要する場合もあります。 - 事例6-5 発注者にも受注者にも遵守しなくてはならない義務がある

事例：発注者にも受注者にも遵守しなくてはならない義務がある

プロジェクトは発注者と受注者が協力して実施する必要があります。システム開発の失敗責任を巡って争いとなったケースの判例では、受注者の「プロジェクト管理義務」、発注者の「プロジェクト協力義務」について、それぞれ言及しています。

■ 受注者の「プロジェクト管理義務」について

ある地方銀行（以下「銀行Ｇ」という）では、基幹システムの刷新プロジェクトを立ち上げ、大手開発ベンダー（以下「ベンダーＸ」という）との間で開発作業の契約を行いました。しかし、プロジェクト開始直後から作業は難航し、数年後にプロジェクト中止という判断に至りました。

発注者側である銀行ＧはベンダーＸに対して損害賠償を求め法廷で争うことになりました。裁判の結果、情報システムの専門家であるベンダーＸが、提案したシステム方式に関する詳細な内容やリスクを銀行Ｇに十分に説明しなかった点について、プロジェクト管理義務違反等に当たるという判断が下され、ベンダーＸ側に賠償金の支払が命じられました。

■ 発注者の「プロジェクト協力義務」について

また、ある大学病院（以下「病院Ｈ」という）では、病院情報管理システムの刷新を企画し、大手開発ベンダー（以下「ベンダーＹ」という）との間で開発作業の契約を行いました。しかし、プロジェクトの開始直後から、発注者側である病院Ｈの現場担当者からの追加要件が相次ぎ、途中追加要件の取り込みについて病院Ｈ及びベンダーＹの双方が合意した上で仕様を凍結し、納期も延長することになりました。

しかし、仕様凍結後も病院Ｈの現場担当者からの追加要望は収まらず、開発はさらに遅延し、最終的に病院ＨからベンダーＹへ契約解除が通告され、プロジェクトは中止になりました。

ベンダーＹは、発注者側である病院Ｈが仕様凍結の合意後において、要件の追加、変更を繰り返したことがプロジェクト中止の原因であるとして、損害賠償を求めましたが、逆に病院Ｈは受注者であるベンダーＹが納期を守らなかったことを理由に裁判を起こしました。その結果、病院Ｈが発注者の責任として同院内の現場担当者からの追加要望を調整しなかったことが、プロジェクト協力義務違反に当たるという判決が下され、発注者側に賠償金の支払いが命じられました。

このように、受注者である外部事業者側だけではなく、発注者側にもプロジェクトを完遂させるために守らなくてはならない義務があることを、十分留意しておくことが重要です。
調達仕様書の「作業の実施体制・方法に関する事項」にて、発注者側、外部事業者側、関係者の体制、役割、責任をそれぞれ明確にします。 - 図6-7 作業実施体制例 ![](../assets/ds-120-ch06-image12.png) なお、サービス・業務の企画や要件定義のように新しいサービス・業務や情報システムの内容を決定するような活動においては、特に注意が必要です。意思決定の責任は発注者にあることを認識した上で、ＰＪＭＯ以外の関係者も含めて、適切な判断ができる体制を組成して調達仕様書に明示してください。 - 参考6-2 作業実施体制に関する注意点

参考：作業実施体制に関する注意点

作業の実施体制には、受注者側が整備すべき体制、作業要員に求める資格等の要件について記載します。作業の実施体制を適切に定めなかった場合、遂行責任者として受注者内の業務全体を統括する役割は設置されているものの、発注者との一元的な窓口となる役割が設置されておらず、発注者と受注者の間のコミュニケーションが煩雑になるなど、適切な体制が採られないおそれがあるため、調達仕様書において役割も含め明確に定めることが必要です。

一方で、要件が過剰な場合もあります。資格要件等は本当に必要なものだけを定めることが重要です。近年は、作業要員にクラウドサービスの認定資格等を求める事例が増えていますが、要件によっては適切な調達につながらない場合があるため、以下のような点に注意する必要があります。

  • 過度な資格要件

過度な資格要件を設定してしまうことで、資格は保有していないものの経験豊富な事業者が応札できなくなる可能性があります。例えば、資格よりも実績を重視している事業者は、経験や技術力が十分でも資格要件がハードルとなって応札を辞退する場合があります。また、小規模の事業者にとっては、品質マネジメントシステムの規格であるISO9001の認証を受けることや、設計・開発チームから独立した品質管理者を設置することは負担が大きく、条件を満たせない場合があります。

そのような事業者の中には、クラウドサービス、アジャイル開発等の優れた実績を有している事業者もいることから、本当に技術力の高い事業者に応札してもらえるよう、資格要件は必要最小限のものとすることが望ましいです。高度な資格については、必要性を確認する、代替可能な資格や実績があれば特定の資格を保有していなくても応札可能とするなどの対応を検討しましょう。資格要件の緩和については「Step.2-2-C. 一者応札の状況を改善する」の「一者応札状況を改善するための施策例」も合わせて参照してください。

また、体制上のすべての要員に対して一律に資格の保有を求めたために見積りが高額になった事例があります。遂行責任者やチームリーダに適切な資格を求めていれば、作業担当者には必ずしも資格を求める必要はありません。必要な役割を定めるとともに、役割に応じて適切な資格要件を定めることが必要です。役割ごとに求める資格要件を定める例は、本ガイドブック別紙「調達仕様書標準テンプレート」の「5.2. 作業要員に求める資格等の要件」をご参照ください。

  • 実質的な製品・サービス指定

資格要件を定めることで特定の製品・サービスの指定になってしまう可能性があります。

例えば、調達時点では、どのクラウドサービスを採用するかは定まっていないにもかかわらず、特定のクラウドサービスの認定資格を要件とすることで、実質的に当該クラウドサービスを指定した調達となる懸念があります。

このような場合には、応札者にクラウドサービスを提案させるとともに、当該クラウドサービスを用いた設計・開発の実績や要員の保有資格などを提示させることを検討しましょう。

  • 名義貸し

応札者から提示された体制図には優れた経歴の要員が示されているにもかかわらず、業務が始まると、当該要員がプロジェクトに関与せず、実働がないという場合があります。

このような名義貸しの状態にならないよう、発注者は、当該要員に求める役割を調達仕様書で明示するとともに、応札者から、当該要員の稼働率や具体的な関与方法を提案時に示させることが望ましいです。加えて、業務開始後に当該要員が実際に果たしている役割、中間成果物や進捗状況等を確認し、それらが不十分であって、最終成果物の品質に影響が出るおそれがある場合は是正を求めましょう。

逆に、名義貸し状態でも成果物の品質に問題のないような資格要件である場合は、そもそも調達時にこのような資格要件を求めるべきではありません。
### 成果物の取り扱いに注意する（知的財産権） 調達案件にて設計・開発した文書やアプリケーションプログラムの知的財産権は、誰に帰属させるべきでしょうか？パッケージ製品を全く改変することなく採用した場合、製品の知的財産権は製品の提供元に帰属するのだろうと類推しやすいのですが、では、その製品を利用して蓄積されたデータはどちらに帰属するでしょうか？また、発注者側の要望に基づいた既成のパッケージ製品を拡張した機能やクラウドサービスの設定等は誰に帰属するのでしょうか？ 標準ガイドラインでは、政府情報システムのソフトウェアに関わる知的財産権については、産業技術力強化法（平成12年４月19日法律第44号）の趣旨に鑑み、受注者に帰属させることが基本となります。しかし、設計・開発後に行われる情報システムの保守や継続的な機能追加等は、必ずしも設計・開発を行った外部事業者が行うとは限りません。成果物の知的財産権が誰に帰属するかなどを適切に定めておかないと、保守や機能改修、更改等のときに「人質」のようになってしまい、大きな問題に発展するおそれがあります。 - 事例6-6 知的財産権の帰属先が問題となった例

事例：知的財産権の帰属先が問題となった例

情報システムを構成する要素は多岐に渡ります。想定していなかったものに対して「まさかこれに知的財産権が？」となり、トラブルになりかけた事例を次に示します。ここにあげた事例は、いずれも最終的には外部事業者との調整で問題を解決しましたが、本来は調達を行う時点でこのような点についても知的財産権の帰属について明確にしておくことが望ましいといえます。

  • ある省庁の業務アプリケーションにおいて、アプリケーション本体の知的財産権は発注者側に帰属していましたが、使用している外字のフォントデータは外部事業者に帰属していました。このフォントデータがないと、登録した情報を画面や帳票に正しく出力することができません。次期システムの検討に当たり、既存情報システムの開発事業者が外字の知的財産権を主張し、ベンダーロックインになる事態を招きそうになりました。

  • ある省庁で保有している情報システムでは、データベースからデータを抽出するプログラムは外部事業者が独自に開発したもののため、使用するのであれば別途ライセンス料金が必要と言われてしまいました。
このような問題を防ぐためにも、案件の内容を踏まえて、調達案件中に発生する中間的な成果物も含め、全ての成果物に関して、知的財産についての権利の帰属、移転の可否、第三者への再利用、著作人格権の行使等の取決めを検討し、調達仕様書の「成果物の取扱いに関する事項」に記載します。 ### 再委託に関する事項を定める 情報システムの整備においては、プロジェクトの規模が大きくなるほど、様々な役割が必要となります。特に、設計・開発工程や運用・保守工程では、情報システムの一部を担う特定の技術や専門分野に特化した外部事業者を活用する機会が多く、これらの外部事業者は、請負契約を締結している外部事業者からの再委託となることもあります。再委託先が担当する作業内容については、委託先の外部事業者（以下「委託先」という）が責任を持って管理することが原則ですが、再委託にまつわる失敗事例も少なくありません。 以下に一般的な例をいくつかご紹介します。 - 事例6-7 再委託に関する失敗例

事例：再委託に関する失敗例

  • 委託先が作成した提案内容を評価し、プロジェクトの委託先として選定したにもかかわらず、再委託先が提案内容を遂行するために必要なスキルレベルを十分に持っておらず、成果物の品質低下やスケジュール遅延を招いてしまった。

  • 委託先と再委託先との関係性の悪化や再委託先内の社内事情から、再委託先が要員を引き上げてしまい、再委託先を改めて手配するまでの期間、作業が中断してしまった。

  • 再委託先に所属するプロジェクトのキーマンが、病気や家庭の事情でプロジェクトから離脱してしまった。委託先の要員が代替となったが、そのキーマンが属人的に持っていた情報やノウハウが委託先には引き継がれていなかったため、代役を担うことができなかった。

  • 委託先が再委託先に利用者との検討や調整等の作業を丸投げしてしまい、要件や仕様の変更を把握しなかったため、工数超過やスケジュール遅延に発展してしまった。

  • 委託先が利用者から得た情報を抱え込んでしまい、再委託先が作業するために必要な情報を提供せず、再委託先が利用者に再度同じ内容に関する説明を求めるという二度手間となり、利用者側との間の関係が悪化し、利用者側からの協力を得ることが難しくなってしまった。
このような問題を未然に防ぐためにも、調達仕様の「再委託に関する事項」にて、再委託の制限及び再委託を認める場合の条件、承認手続、再委託先の契約違反等を定め、再委託時の要員の配置や品質、情報管理等に関する責任の所在を明確にします。また、プロジェクト遂行中に発生した様々な事情により、請負側の体制変更をはかることがありますが、その際は発注者側と協議の上、請負者の負担と責任において実施することが原則です。 なお、再委託に関する事項は、自府省の情報セキュリティポリシーにおける再委託先における情報セキュリティ対策に係る規定も必ず確認してください。 ### 納品後に不具合が発覚したときの責任を明確にする。(契約不適合責任) 「瑕疵担保責任」と「契約不適合責任」の違い 2020年4月に施行される改正民法においては、従来、納品されたシステムに不具合が発覚した際に適用されてきた瑕疵担保責任に関する条項がなくなり、代わりに「目的物が種類、品質又は数量に関して契約の内容に適合しないものであるとき」（契約不適合）についての条項が規定されました。これは、瑕疵担保責任の規定が現代の取引実情に合わなくなっていたものを解消するための改正であり、様々な点で改正がされておりますが、特に注意が必要な相違点としては以下が挙げられます（なお、請負契約の場合を前提にしています。） 契約不適合責任への変更による注意点 - 救済手段の多様化 瑕疵担保責任においては、瑕疵の修補、損害賠償の請求及び契約の解除のみしか認められていなかったのに対し、契約不適合責任については、①修補、代替物の引渡し又は不足分の引渡しによる履行の追完の請求、②報酬の減額の請求、③損害賠償の請求及び④契約の解除が可能となり、それぞれについて、要件が整理されました。実際に不具合が発生した際にどの救済手段を取るべきかの判断を適切に行う必要があります。 - 権利行使の可能な期間の起算点の変更 瑕疵担保責任は、引渡しのとき又は仕事の終了時（通常は検収後）1年間であり、その後に発見された瑕疵については、いかなる救済手段の権利行使もできませんでした。改正後は、種類又は品質についての不適合は、発注者がその不適合を知ったときから、1年以内に受注者にそれを通知すれば、救済手段の権利行使をすることができ、数量の不足に関しては、そのような制限はなくなりました。もっとも、消滅時効の改正の影響で、通知した場合であっても、当該権利は、債権者が権利を行使することができることを知った時から5年間行使しないときには消滅することになります。 「契約不適合」を契約条項とするときの留意点 IT開発において検収後に発見される不具合等に新しく創設された契約不適合に関する条項を適用する場合、ベンダー側は、最長で10年もの間 (民法166条に定める債権の消滅時効期間)、不具合の対応を無償で行うことを求められる余地があり、そのための体制も維持しなければなりません。 このことが大きな負担になることから、ベンダーはこの条項の削除を求めたり、長期にわたる体制維持のために、高い見積もりを提示したりする可能性があります。また、こうした条項を嫌って、応札を見送るベンダーもあるかもしれません。 こうしたことを避けるためにはベンダーに対して、自らの求める仕様、言い換えれば、何を担保すれば契約の内容に不適合にはならないのかを具体的に説明し、合意を得ておく必要があります。 具体的に何を説明するのかについては、個別に異なりますが、主には、①契約の目的に資するもの(※1)　が納品されていること、②提示した要件が全て満たされていること、③予定した作業や工程が全て完了していること、④予定していたレビューやテスト等の検証(※2) が全て完了し、設定した合格基準を満たしていることが、これまでのIT紛争における判例から推測される”システム完成”の基準です。 こうした基準を第三者の客観的な視点でも認識がずれることないように提示(※3)　することが、ベンダー側の過度な警戒を回避し、高い見積もりの提示や応札拒否を避けることに有効であると考えられます。 1. 契約の目的が、そのまま検収の条件となるわけではありません。システム化によって、職員の作業工数を半減されることが目的とし、それが叶わなかったとしても、客観的に見て、コスト削減に資する機能や性能を具備したシステムが納品されれば、”目的に資する”ものであると考えられます。 2. 請負契約の場合、受入テスト以外の検証については受注者に一任されますが、契約に適合するモノを作っていることを証明するために、敢えてテストやレビューの計画や実施状況、合格基準と結果等を提示してもらい、その妥当性を委託者側が評価することが有効と考えられます。 3. 第三者が同じ認識を持てるようにするには、各基準を数値化したり、Yes/Noで答えられる形式に設定したりすることが有効です。