第６章　調達

デジタル・ガバメント推進標準ガイドライン 実践ガイドブック

第６章　調達

目次

Step.1 調達の活動の全体の流れ

Step.2 調達の事前準備

１ 調達の単位・計画を確認する

A. プロジェクト立上げ時点で調達を計画する

B. 様々な調達単位があることを理解する

C. 調達にあった落札方式、評価方式を検討する

D. 調達計画を早めに公開する

２ 調達の注意事項を理解する

A. 調達手続の基本的なルールを確認し理解する

B. 入札制限を正しく理解する

C. 一者応札の状況を改善する

D. 調達の前にリスクを再確認する

Step.3 調達仕様書の作成

１ 関連ドキュメントとの関係性を理解する

A. 調達仕様書と要件定義書の住み分けを理解する

B. 付属文書を活用して可読性を上げ機密性を確保する

２ 調達仕様書の記載内容を理解する

A. 調達の意図や目的を正しく伝える

B. 関連する調達、入札制限を伝える

C. 作業内容・納品物を関連付けて網羅的に記載する

D. 外部事業者の具体的な作業内容を明確にする

E. 作業の実施体制を明確にする

F. 成果物の取り扱いに注意する（知的財産権）

G. 再委託に関する事項を定める

H. 納品後に不具合が発覚したときの責任を明確にする。(契約不適合責任)

Step.4 調達仕様書以外のドキュメント作成

１ プロジェクトに合わせた契約書を作る

A. 調達仕様書と契約書の整合性を確認する

２ 提案依頼書の内容を工夫する

A. 具体的な作業計画を評価する

B. 加点の配分を工夫する

Step.5 調達手続とプロジェクト管理

１ 調達手続に伴うプロジェクト管理作業とは

A. 第一次工程レビューを意識して資料をチェックする

２ 情報システムの調達に特有の注意点

A. ベンダロックインを理解し、回避する

Step.6 検収

１ 検収の位置づけと内容を理解する

A. 検収と受入れテストの違いを理解する

B. 残存する課題（軽微な瑕疵等）の対応を明確にする

事例・参考の一覧

事例：サブシステム間でのシステム監視業務の統合

事例：複数の組織で共通利用するＬＡＮ構築の調達

参考：クラウドサービスの調達にあたって検討すべき点

事例：異なる立場の職員による説明会の実施

参考：ＩＴダッシュボードから事業者を選定する

事例：調達日程表のイメージ

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

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

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

参考：オープンソースの有償と無償の境界について

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

事例：事業者の設計・開発実施計画書の作成能力に問題があった例

参考：総合評価落札方式の加点配分について

Step.1 調達の活動の全体の流れ

プロジェクトの中で検討してきたことを具体的に形作るためには、プロジェクトの目的と内容に適した事業者を選定することが重要です。１つのプロジェクトでは、通常、複数の調達を実施します。情報システムの設計・開発や保守・運用の委託、必要となる製品の購入や保守契約等が代表的ですが、その他にも調査研究やプロジェクト管理支援等の支援業務の委託、コールセンタやデータ入力等の運用サポート業務の委託、必要となる施設の賃貸借等、様々な種類の調達を実施することになるでしょう。

政府情報システムでは、これらの調達の進め方にルールが定められています。まず、大前提として、国の契約方式は一般競争契約を原則としています。政府の財政的消費は納税者の負担に基づいているため、納税者の機会均等と公正な処理を行うべきであり、金銭面での有利性を見いだすことが必要であるためです。

ここでは、このような調達を進める際の具体的なルールや手順とともに、発注者として知っておくべき工夫・ノウハウについて、説明します。

本ドキュメントの構成は、次のとおりです。

Step.2　調達の事前準備

多くの方は、プロジェクトの立ち上げと同時に調達を意識するのではないでしょうか。

調達について計画を具体化していく際にまず知っておくべきこととして、調達の単位・計画や、調達の決まりごと等を説明します。

Step.3　調達仕様書の作成

調達仕様書とは、プロジェクトの目的の達成に必要な製品の入手や、必要となる役務を実施する外部事業者を選定するために示す、発注者側の条件を集めたドキュメントです。

ここでは、設計・開発作業を行う外部事業者を選定するための調達仕様書をサンプルとして、調達仕様書に記載する事項ごとに何に気をつけて記述すべきかを解説します。

Step.4　調達仕様書以外のドキュメント作成

調達では、調達仕様書以外にも様々なドキュメントを用意する必要があります。

ここでは、その主なドキュメントとして、提案依頼書と契約書を対象として、記載項目の紹介と作成時の留意点について解説します。

Step.5　調達手続とプロジェクト管理

プロジェクトの活動において、調達はそれ以前の活動の結果を集約し、その後の活動を方向づけるプロジェクトの結節点とも言えます。このタイミングでのポイントをおさえた上で調達手続きを行うことは、プロジェクト管理の視点からも重要です。

ここでは、調達活動中に実施するプロジェクト管理作業について解説します。

Step.6　検収

調達の結果、外部事業者との契約が締結され、製品の購入手続も含め委託した作業がスタートします。その結果、製品であれば納品、作業であれば完了報告が行われ、発注者はそれに対して検収を行ないます。

ここでは、設計・開発作業の外部委託をサンプルとして、プロジェクト活動の終了と調達に伴う検収との関係について解説します。

Step.2 調達の事前準備

調達は、プロジェクト成功の命運を左右する重要な活動です。プロジェクトの成功に向けて目標を着実に達成するためには、不調や不落といった後々の手戻りにつながることを防ぎ、さらには調達した情報システムを継続的に利用していくに当たって一者応札やベンダロックイン等による適正な競争を阻害する事態が発生しないよう十分な注意を払い、確実に調達内容を履行できる外部事業者又は製品等を選定できるように、事前に十分な時間を設けた上で準備をすることがとても大切です。(注記 ベンダロックインとは、ソフトウェアの機能改修やバージョンアップ、ハードウェアのメンテナンス等、情報システムを使い続けるために必要な作業を、それを導入した事業者以外が実施することができないために、特定の事業者（ベンダ）を利用し続けなくてはならない状態のこと。)

ここでは、実際の調達を始める前に行う事前の準備について説明していきます。

１ 調達の単位・計画を確認する

【標準ガイドライン関連箇所：第３編第６章第１節】

情報システムを整備する多くのプロジェクトでは、外部事業者への作業の委託や製品の購入などの複数の調達が行われますが、情報システムに関する専門的な知識を有していないと、何の調達をどの単位でいつ行うかよくわからないものです。

しかし、ポイントを押さえて事前準備をすることで、実際の調達時に不十分な内容に起因する手戻りなどによる無駄な手間をかけずに効率的に調達作業を行うことができます。

では、具体的な調達の事前準備のポイントは次のとおりです。

A. プロジェクト立上げ時点で調達を計画する

調達の計画では、「何の調達を」「どの単位で」「いつ調達するか」を計画します。

調達の計画は、まず、プロジェクトの立上げ時に行うことが一般的です。プロジェクトの立上げ時には、プロジェクトの概要スケジュールとして「どの活動を」「いつ行うか」を計画していきますが、その際に「どの活動を事業者に委託するか」「製品等がいつから利用可能になるか」を踏まえて、予算要求の計画も行っていきます。これらの内容は、まさに調達の計画の基礎情報となりますので、後々漏れることのないよう、プロジェクト計画書の実施計画（標準ガイドライン「第２章２．1) ク 実施計画」参照）に調達の計画も明記・可視化しておくべきです。

また、プロジェクトの立ち上げ時点で調達計画を立案することには、以下のメリットがあります。

プロジェクト立上げ時点で調達計画を立案するメリット

・ 予算要求時点等、プロジェクト初期の段階でＰＭＯやＣＩＯ補佐官の確認や助言を受けることができます。

・ プロジェクト計画等の公開と併せて調達計画を公開することで、事業者に事前に調達の内容や時期を伝えることができ、事業者から多くの提案を得られる可能性が上がります。

B. 様々な調達単位があることを理解する

調達の計画で「何の調達を」「いつ調達するか」を特定した後、それらの調達を「どの単位で行うか」を検討します。

調達の単位は、標準ガイドライン解説書「第６章１．1) 合理的な調達単位の検討」で示す16種類が基本の単位となりますが、これらの複数を１つの調達にまとめることや１つの単位を分割して複数の調達にすることも可能です。最適な調達の単位は、プロジェクトの規模や性質によって異なります。

また、調達を複数に分ける考え方を分離調達と言い、そのメリット及びデメリットは次のとおりです。

分離調達を実施した場合のメリット・デメリット

・ 分離調達によるメリット

・ 特定事業者に偏るというベンダロックイン状態の解消

・ 競争性・透明性の向上による価格の適正化と提案内容の質の向上

・ 競争による市場の活性化

・ 分離調達によるデメリット

・ 調達を分割して参画する事業者が増えることによる、事業者の管理や事業者間の調整、リスク管理や問題発生時の対処等、発注者側の管理労力の増加及び調達作業負荷の増加

これらの分離調達のメリットとデメリットを理解し、競争性・透明性を保ちつつ、適切なプロジェクト運営が行えるよう、プロジェクトの規模や性質に合った調達の単位を検討してください。

なお、十分な検討をせずに調達単位を決めてしまうと、事業者からの応札がなく不落となったり、一者のみからの応札となったりする場合もあり、結果として分離調達の意義が失われるおそれがあります。

以下に、調達単位を検討する際の具体的な事例を挙げます。

調達単位を考える際に留意すべき具体例

・ 問題となる例

・ 【現行情報システムの調査】を、今後整備する新たな情報システムのアプリケーション設計・開発、機器賃貸借業務に含める。

・ 【現行情報システムからのデータ抽出】を、今後整備する新たな情報システムのアプリケーション設計・開発、機器賃貸借業務に含める。

現行情報システムに対する作業を、これから予定している調達の中に含めた場合、現行情報システムの知識を十分に有する既存の運用・保守事業者が有利となり、競争性が損なわれるため、問題となります。

・ 慎重に検討すべき例

・ 【アプリケーションの導入】を機器賃貸借業務に含める。

・ アプリケーション及び機器の【総合テスト】を機器賃貸借業務に含める。

・ 【データ変換/投入作業】を全面的に機器賃貸借業務に含める。

・ 【情報システムの切替作業】を全面的に機器賃貸借業務に含める。

・ 【障害の切り分け】を機器賃貸借業務（保守業務を含まない）に含める。

・ アプリケーション設計・開発事業者がＳＷを選定・設計・開発し、【ＳＷの導入】のみ機器賃貸借業務に含める。

専門性の異なる分野の業務を安易に束ねてしまうと、本来であれば多数の事業者に参入機会がある業務であっても、特定の事業者にしか応札できないものとなってしまいます。

ただし、１つの事業者が関連する作業をまとめて実施した方が、全体として効率的な場合もあります。上述のような例については、調達単位を分割することによる競争性確保と、束ねることによる効率性向上の両面を検討したうえで、調達単位を決めてください。

・ プロジェクトを跨って調達単位を統合した例（良い事例）

・ 複数のプロジェクトやサブプロジェクトで別々に実施していた業務を統合する。

・ 複数の組織で別々に実施していた業務を統合する。

１つのプロジェクトだけで調達を行うだけでなく、他のプロジェクトや他の組織と連携することで、調達単位を統合し、対象業務も効率的に実施できる可能性があります。

事例：サブシステム間でのシステム監視業務の統合 あるプロジェクトでは、複数のサブシステムを持つ大規模情報システムの監視・運用コストの見直しに取り組んでいました。このプロジェクトでは、サブシステムの単位でサブプロジェクトの体制を組んでおり、各サブシステムの運用・監視を行う事業者を個別に調達していました。 現状の監視・運用業務を調査した結果、個別に実施している運用・監視業務の中には類似作業が多く含まれており、これらを統合することによって更に効率的に実施できることが明らかになりました。そこで、サブシステムごとに保有していた統合監視サーバ、統合監視端末、パッチ配信サーバを１セットに統合し、運用作業についても一元管理する事業者を調達する方針に変更しました。

事例：複数の組織で共通利用するＬＡＮ構築の調達 ある地方拠点事務所では、同一拠点で複数の組織が業務を行っており、過去の経緯からＬＡＮが個別に整備されていました。 ＬＡＮの整備や運用に関する煩雑な業務とコストを削減するため、中心となる組織の担当者がＬＡＮの統合に向けた検討を行いました。検討の中では、まず現状を詳細に把握するところからスタートしました。例えば、それぞれのＬＡＮでは、メールやグループウェア等の業務を行うためのサーバを多数導入していましたが、各サーバのCPUやメモリの使用率を調べると余裕が大きいことがわかりました。そこで、これらのサーバを統合することでコストを削減するとともに、サーバを設置していたサーバルームについても統合することとしました。 このように、ＬＡＮを統合して共通利用する場合のメリットとデメリットをまとめ、複数組織合同による情報化推進委員会に諮り、改善を進めました。

参考：クラウドサービスの調達にあたって検討すべき点 最近では、多くの政府情報システムでクラウドサービスの検討や導入が進んでいます。クラウドサービスは、従来型のサーバ等の資産を自身が保有する形態（オンプレミス）と比較すると、システム自体のコストを大きく削減できる可能性があります。しかし、クラウドサービスに移行すれば自動的にコストが減少するというほど単純なものではありません。 まずは、システム方式の検討が重要です。オンプレミスの時のシステム構成をそのままクラウドサービスに持ち込んで多数の仮想サーバを立てるだけでは、本質的なコスト削減は難しいでしょう。クラウドサービス事業者が提供しているマネージドサービス（ストレージ、データベース、セキュリティ対策、運用管理等の仕組みを、従量課金のサービスとして利用できるもの）を適切に活用することで、コスト面のみならず性能面、品質面を含めた効果を得ることができます。 その上で、もう１つ重要なことがクラウドサービスの契約方法です。クラウドサービスは同じような種類のサービスを複数の事業者が提供しているため、要件を提示した上で競争入札（総合評価方式等）によって事業者を選定することが前提となります。一方で、毎年クラウドサービスの事業者が変わってしまうと移行やテスト等の作業が毎回発生することとなり、無駄なコストが発生してしまいます。調達における競争性確保と、移行等の手間を発生させないこととは、両立が難しい問題ですが、この問題に対処した２つの事例を紹介します。 初年度を競争入札として、翌年度以降を随意契約で継続する方式 　契約期間を単年度とする場合の方法です。初年度は競争入札でクラウドサービス事業者を選定した上で、翌年度以降は原則として随意契約で同じ事業者と継続的に契約をします。随意契約を行うことで、クラウドサービス事業者が変わった場合に発生する移行等のコストを節減することができます。 　ただし、この方式であっても随意契約を無制限に繰り返すわけではなく、適切なタイミング（例えば5年程度）でクラウドサービス事業者を見直すことが必要です。 複数年度で契約する方式 契約期間を複数年度とする場合は、上記の問題に比較的対処しやすくなります。 また、クラウドサービスの中には、複数年予約型割引の価格体系を持つものがあります。サービスの利用量が経年で大きく変化しないような見込みのあるものについては、この予約割引を適用することで大幅にコストメリットが出ることがあります。契約期間を複数年度とすることで、このような予約割引も活用しやすくなります。 いずれにしても、クラウドサービスの利用方法、契約方法には様々な選択肢が考えられます。クラウドサービスの導入にあたっては、クラウドサービスそのものの費用だけでなく整備、移行、運用等に必要となる人件費も含めたプロジェクト全体のコストを俯瞰して、適切なクラウドサービス、契約方式の検討をすることが大切です。

C. 調達にあった落札方式、評価方式を検討する

情報システムの整備に関する調達を行う際には、実施する案件の技術面や管理面等の難しさを踏まえて、調達内容を着実に履行できる事業者を選定する必要があります。残念ながら、契約した事業者が調達内容を十分に履行できずに、うまく立ち行かなくなったプロジェクトは少なくありません。

このような事態を防ぐためにも、調達時には、その内容に適した落札方式を選択し、価格以外の技術的な評価を行う場合は、審査に必要となる評価基準、審査体制等を十分に検討した上で事業者の選定の準備を整えます。

総合評価落札方式には、除算方式と加算方式という２つの評価方式があります。ただし、除算方式は価格点が分母となり低入札価格による影響を極端に受けやすいため、基本的には加算方式を採用するのが良いでしょう。

なお、総合評価落札方式による調達を行う場合は、予定価格が80万ＳＤＲを超える調達案件以外のものについては、入札公告又は入札公示の前日から起算して少なくとも30日前に財務大臣への届出が必要となります。

調達の計画時点で、落札方式や評価方式も合わせて検討し、調達の手続を適正に行えるように、計画を立てるようにします。

D. 調達計画を早めに公開する

入札が不調（応札者が現れない）や不落（応札価格が全て予定価格を超過）となってしまうと、プロジェクト全体のスケジュールが大幅に遅延してしまいます。また、一者だけからの応札となってしまうと、十分な価格競争が働かない可能性があります。

このような事態を防ぐためには、次に示すような対策を行い、極力多数の外部事業者から応札を受けられるように準備しましょう。

・ 過去に別プロジェクトで情報システムの調達を行った際に、応札や仕様書を受領した外部事業者等に問合せる。

・ プロジェクトの目的の達成に必要な技術的要件が明らかな場合には、その要件に合致しそうな製品等を探す。

さらに、調達計画を広く公開して透明性を確保し、外部事業者がプロジェクトの目的や調達内容について十分に理解できるような公平な機会を設けることも有効です。似たような調達が過去にないなどで外部事業者が見つからないときや調達計画の公開を検討する際は、ＰＭＯ、府省ＣＩＯ補佐官に相談してください。

事例：異なる立場の職員による説明会の実施 ある省庁では、ＲＦＩやＲＦＰを実施する前に、調達内容に関連しそうな事業や製品等を提供可能な外部事業者を複数探しだし、透明性を確保した上で説明会を開催し、公正に直接意見交換を行う機会を設けています。 このとき、担う業務特性又は所属部署に基づく特定の立場の職員だけが説明を行うと、外部事業者に伝える内容に立場上の偏りが生じるおそれがあるため、会計担当、技術担当等の異なる立場の職員が、それぞれの視点から説明を行うようにしています。また、大規模な情報システムでは、サブシステムごとに個別の説明会を実施し、外部事業者へ丁寧な情報提供を行っています。 この結果、ＲＦＩによる有用な情報の入手や、公正で適切な調達が実行しやすくなり、プロジェクトの目的の達成に大きく寄与しました。

参考：ＩＴダッシュボードから事業者を選定する ＩＴダッシュボードの契約情報（行政事業レビュー）から、関連する外部事業者を把握することができます。 https://www.itdashboard.go.jp/Statistics/procurement#explanation 契約情報画面では、年度ごとに契約した事業者名、事業、調達額等を確認することができます。また、グラフを構成しているデータはＣＳＶダウンロードボタンよりダウンロードも可能です。 ・ 事業情報（ＣＳＶダウンロードボタン） ・ 事業支出（ＣＳＶダウンロードボタン） ・ 事業予算（ＣＳＶダウンロードボタン） 「○○年度運用等経費10億円以上の情報システムに関わる事業一覧」では次に示す情報が参照可能です。 (1) 支出先別支出金額 支出金額を企業別に見ることができます。行政事業レビューには情報システム関連経費以外も含まれますので、情報システム別の予算とは一致しないことに留意してください。 (2) 選択ベンダ（事業者）の参加事業一覧 選択したベンダが関係する事業の一覧を見ることができます。 参加事業名を選択すると、公開されているレビューシートを参照することができます。 ※ 上図では事業者名を匿名化していますが、実際には事業者名が表示されます。 (3) 支出先別支出金額割合 支出金額割合を企業別に見ることができます。行政事業レビューには情報システム関連経費以外も含まれますので、情報システム別の予算とは一致しないことに留意してください。 (4) 運用等経費10億円以上の情報システムに関わる事業の支出先(上位20件)の分布(昇順) 支出先金額、支出金額割合の関係を見ることができます。

２ 調達の注意事項を理解する

【標準ガイドライン関連箇所：第３編第６章第１節】

調達は、契約方式や金額等に応じて調達手続や公示期間等が定められているため、いざ調達の準備を開始しようとした時点で、当初想定していたよりも時間がなかったことに気が付くことが少なくありません。調達の準備の時間が十分に取れないと、資料の準備不足や説明会等の不足から事業者への十分な理解が得られず、入札の不調や不落となりかねません。

このような不測の事態を防ぐために、プロジェクト計画の段階で調達に係るルールを理解し、調達に必要な期間を踏まえて準備を行えるように調達の計画をたてることが重要です。

A. 調達手続の基本的なルールを確認し理解する

調達に関する期間等のルールは、政府調達に関する協定や会計法等で調達手順や期間等が定められています。標準ガイドライン解説書「第６章１．調達の計画」に記載しているルールを確認して、計画を立ててください。

調達手続の流れについて、以下の図に示します。予定価格や案件の規模等により、必要な期間が異なるので、余裕を持った計画を立てるようにしましょう。

図6-1　ＩＴ調達手続の流れ

また、上の図について、関連する法令等をまとめた図を、以下に示します。

図6-2　調達に関する法令等

調達の手続については、協定や法令等で定められたルール以外に、各府省で独自のルールを定めている場合もあります。府省のルールによっては、公示のタイミングや期間が変わることもありますので、プロジェクト計画時点で各府省の調達ルールを所管する部署に対して確実に確認するようにしてください。

事例：調達日程表のイメージ ある省では、調達ごとに調達ルールに従った日程表を作成してプロジェクト内で共有し、イベントや作業締切日等を、調達に係る関係者が確実に把握できるようにしています。

B. 入札制限を正しく理解する

調達の単位を検討する際には、一部の事業者が有利とならないよう、それぞれの調達案件に対して適切な入札制限を設けて、透明性と公正性を確保する必要があります。また、調達案件の業務内容によっては、他の調達から独立性や客観性を担保するために入札制限が必要な場合があります。

標準ガイドラインでは、入札制限について、以下のように定めています。

b)　入札制限 透明性及び公正性並びに確実な契約履行等を確保するため、次のｲ）からﾊ）までに掲げる者に対し、入札制限を定めるものとする。 ｲ)　各工程の調達仕様書の作成に直接関与した事業者 各工程の調達仕様書の作成に直接関与した事業者は、透明性及び公正性の確保の観点から、当該調達案件の入札に参加させないものとする。ただし、競争上何ら有利とならないと認められるときは、この限りでない。 ﾛ)　設計・開発等のプロジェクト管理支援事業者 設計・開発等のプロジェクト管理支援事業者（プロジェクトの全部又は一部におけるプロジェクトの管理上生ずる作業について、ＰＪＭＯを支援する事業者をいう。以下同じ。）については、相互牽制の観点から、その管理の対象となる情報システムの設計・開発の作業に関する内容を含む調達案件の入札に参加させないものとする。 ﾊ)　監査対象である情報システムに関与した事業者 監査対象である情報システムに関与した事業者は、監査の独立性及び客観性の確保の観点から、当該情報システムの監査業務に関する調達案件の入札に参加させないものとする。 （標準ガイドライン「第３編第６章第３節1）クb)」）

ただし、「ｲ) 各工程の調達仕様書の作成に直接関与した事業者」に関しては、注意が必要です。例えば、調達仕様書の一部となりうる調査研究等を実施した事業者に対しても、その内容が調達内容や調達方法の決定に直接関わるものでなければ、設計・開発工程への入札制限を設ける必要がないと考えることができます。大切なことは、意思決定の責任は発注者にあることを認識し、他の応札事業者に対して、公正性が確保できる（競争上何ら有利とならない）環境を整備していくことです。

入札制限の意図を正しく理解し、透明性・公正性を確保しつつ、過度な入札制限を設けることで競争の機会損失や調達事務の効率性等を損なうことのないよう、調達単位を検討します。

C. 一者応札の状況を改善する

R FI等の事前情報収集や事業者との調整をしても、結果的に一者応札になってしまうことはあります。ですが、同じプロジェクトの案件で一者応札が続いてしまうのであれば、競争性を確保する観点から改善方法を考えるべきでしょう。

まず、既存事業者の優位性について考えてみましょう。既存事業者は、情報、要員、保有資料の３点において優位性を持っています。

入札における既存事業者の優位性

・ 情報の優位性

既存事業者は既存システムの設計情報等を保有しているため、関連業務に関して既存の情報を前提とした作業見積を行うことができ、受注後も作業を速やかに実施することが可能になります。
一方、新規事業者は応札に当たってこれらの情報の収集、分析及び習得に時間とコストを必要としますし、情報不足によって見積りミスや仕様の取り違えも起きかねないためリスクを勘案する必要もあり、見積金額が高額になりやすいと言えます。

・ 要員の優位性

既存事業者は既存システムを開発した要員を確保しており、この要員を次の関連業務に活用することが可能となります。
一方、新規事業者は関連業務を実施するために、情報システムの内部情報等を習得した要員を新たに育成する必要があり、教育の期間とコストを考慮する必要があります。

・ 保有資料の優位性

情報の優位性と似ていますが、提案書作成や見積作成等の提案活動自体についても、保有資料の有無で優位性が異なります。
既存事業者は既存システムに関する設計書や提案書等の資料を電子データで保有しているため、提案活動を効率的に実施できます。
一方、新規事業者は調達仕様書や閲覧資料等の紙面の情報から、ゼロから提案書を作成するため一定の時間とコストを必要とすることになります。

つまり、新規事業者にとっては既存システムの業務の受注にはそもそもコストやリスクが大きく、既存事業者との競争に勝てないと判断した新規事業者は、応札そのものを断念することになります。

逆に言うと、一者応札の状況を是正するには、この既存事業者の優位性を相対的に低下させ、新規事業者にとっても競争が可能であることを理解頂くことが重要です。
そのための具体的な施策例を紹介します。

一者応札状況を改善するための施策例

・ 公告から開札、作業開始まで十分な準備期間の確保

新規事業者に対し既存システムに関する技術的調査などを行うための十分な期間を確保します。これにより業務内容や情報システムの仕様や稼働状況を把握した上での正確な見積りが可能になり、新規事業者にとってのリスクの低減につながります。

・ 設計情報等の詳細開示

既存システムの基本設計書や詳細設計書等を、入札時の閲覧資料等として新規事業者が確認できるようにします。
なお、ハードウェア、ソフトウェア、ネットワーク等の構成情報、データの種類やデータ量等は調達仕様書（非機能要件定義書）にも記載しますが、この情報だけでは新規事業者にとってシステムの実態をつかむことは困難です。設計書等を開示することでアプリケーションの構造や特性を詳細に理解できるとともに、ドキュメント等の整備状況についても新規事業者が理解し、実態に合った工数積算を行えるようになります。

・ 運用・保守業務の作業内容や実績情報の開示

既存システムの運用・保守に関連するドキュメント（運用設計書、運用手順書、運用マニュアル、保守設計書、保守手順書、保守マニュアル等の名称が多い）についても、入札時の閲覧資料等として新規事業者が確認できるようにします。
また、運用・保守業務の実績が分かる資料も重要です。具体的には、サービスレベル実績、障害やインシデントの管理情報、コールセンタやヘルプデスク業務の対応実績、変更管理実績等の情報です。運用・保守業務の各種報告書（運用報告書、保守報告書、作業報告書等の名称が多い）も、新規事業者にとって参考になる部分があります。

・ 既存事業者が優位となる作業の分離

既存事業者が優位性を持つ作業を委託業務から分離することで、分離後の調達業務の競争性を高めることができます。
例えば、次のようなことを検討することが有効です。

・既存システムを一括で再構築するのではなく、サブシステム単位で分離して新規事業者から参入しやすくする

・運用業務から業務アプリケーションの障害対応や修正等を分離し、定常的で手順書に沿った運用業務部分を調達範囲とする

・機器賃貸借業務から、業務アプリケーションに関連する作業（設定変更、修正等）を分離する

・ 汎用的な製品への移行

特定の事業者しか供給できない製品（ハードウェア、ソフトウェア）ではなく、汎用的な製品やオープンソースソフトウェア（OSS）を調達品目とします。現行の業務アプリケーションを汎用製品に適合させるための改修作業は必要になりますが、製品を供給できる事業者の選択肢が広がります。

・ 前提条件等の緩和

事業者に求める資格や実績要件を十分に検討した上で、可能な限り仕様を緩和することで多くの事業者の参入を促します。例えば、資格要件の記載について当該資格の保有を絶対条件として求めるのではなく、他の代替可能な資格や能力を含めた要求事項とすることが望ましいです。

【例１】　ISO9001の認定事業者であること、または同等の認定を受けていること。

【例２】官公庁における同規模の情報システムの導入実績を持つこと、 または当該業務分野に関する業務や関係法令の知識を持ち同規模の情報システムの導入実績を有すること。

【例３】当該業務分野の情報システムの導入実績を持つこと、 またはその情報システムと同程度の難易度、信頼性及び特性を有する情報システムの導入実績を持つこと。

・ 契約期間の複数年度化

運用、保守業務を例にとると、新規事業者は受注後に既存システムの調査、運用保守に関わる知識の習得、作業プロセスの定義、各種連絡票や報告様式の定義等を実施します。この作業に多くのコストを要するため、契約が単年度であれば新規事業者は採算が取れないことがあります。
そのため、契約期間を複数年度にすることで、この初期コストを吸収できる契約形態も考慮することが望ましいです。

・ 委託内容に関する数量情報の開示

作業内容を文章で表現するだけでなく、定量的に数値として示すことで新規事業者が業務の規模を把握しやすくなります。
例えば、システム改修の場合、改修する画面や帳票、データ項目を明確にし、その数量も提示しましょう。運用業務の場合であれば、前年度とほぼ同じ作業になることが多いため、前年度の作業内容や件数、作業量（工数）等を提示することが望ましいです。

・ 次年度の調達を考慮した納品物

次工程や次年度の調達を考慮して、当年度の業務成果をドキュメントとして分かりやすく最新化することが重要です。
特に設計書については、契約単位ごとに分冊として納品されることがありますが、このような状態では設計内容を理解するために過去の全ての設計書に遡る必要があり、読みこなすことが大変になります。新規事業者も含めて、第三者にとっても読みやすい構成となることを考慮しましょう。

D. 調達の前にリスクを再確認する

第２章　プロジェクトの管理のStep.3 「プロジェクト計画書等の作成」にて洗い出したリスクについて、調達する前にもう一度振り返りましょう。

リスク管理をせずに安易に調達を行うと、すべてのリスクを事業者に負わせることになるため、結果として見積もり・入札額が高くなってしまったり、納期遅延を発生させてしまうことがあります。

既存事業者にとって「暗黙のリスク」であっても、新規参入事業者にとっては「見えないリスク」があることを理解し、調達仕様書に記載する、調達説明会で説明実施することを心掛けてください。

Step.3 調達仕様書の作成

調達仕様書は、発注者側の要望（要件）だけでなく、制約となる条件を記載するものです。実現したいことを書くことはもちろんですが、実現を図っていく過程で守るべき前提条件や制約条件を合わせて書くことで、調達仕様書としての完成度を高めることができます。

このStepでは、調達仕様書を作る上で知っておくべき知識・ノウハウをご紹介します。

１ 関連ドキュメントとの関係性を理解する

【標準ガイドライン関連箇所：第３編第６章第３節】

調達では、調達仕様書以外にも次のようなドキュメントが存在します。それぞれのドキュメントの定義と関係性をあらかじめ理解しておくことが重要です。

No.	関連ドキュメント例	調達仕様書との関係
1	契約書	調達仕様書を引用する文書
2	提案依頼書
3	評価基準
4	要件定義書	調達仕様書の付属文書 ※プロジェクト標準は、必ず存在しているとは限らない。
5	プロジェクト計画書
6	プロジェクト管理要領
7	プロジェクト標準（標準コーディング規約、セキュアコーディング規約等）
8	閲覧要領
9	提案書等の審査要領
10	再委託承認申請書	調達仕様書の付属文書（テンプレートのみ）として、発注者側が提供し、事業者が内容を記述するもの
11	入札書
12	委任状
13	適合証明書
14	誓約書
15	履行証明書
16	提案書（企画書）	事業者が作成するもの

表6-1 調達仕様書と関連するドキュメント例

注記:セキュアコーディングとは、脆弱性に繋がる恐れのあるコーディング作法や未定義の動作を極力減らすためのコーディング手法のこと。

A. 調達仕様書と要件定義書の住み分けを理解する

調達案件で満たすべき要件の内容は、調達仕様書の中に全部書いた方が良いのでしょうか？それとも、要件定義書として添付の付属文書にした方が良いのでしょうか？

要件の内容は、様々な内容を取りまとめたものであるため、調達仕様書に直接記載するのではなく、要件定義書を別紙として、調達仕様書に添付することが一般的です。

要件の内容を別文書とした方が良い理由

・

要件定義の内容は、事業者の提案等を踏まえて、事業者の決定後に発注者との協議を経た上で最終的に決定するものです。つまり、要件定義の内容には変更が入ります。一方で、調達仕様書の内容は、よほどのことがない限り、変更しません。これらに対する変更は明確に分けて管理する必要があり、調達仕様書と要件定義書を分離することで、変更管理が容易になります。

・ 要件定義の内容は、詳細な内容を記載するため量が多くなる傾向があります。調達仕様書の中に全てを記載しようとすると読みにくくなってしまうおそれがあります。

・ 調達仕様書の中に調達に関連する要件のみを記載しようとすると、要件の全体像がわからなくなったり、記載事項が漏れたりする可能性があり、適切な提案や見積りを妨げるおそれがあります。

・ 要件定義書には「こういうシステムがほしい」、調達仕様書には「こういうシステムを作るために何をやってほしい」というように、読み手に伝えたい内容を分けることで可読性が増し、読み手の理解を深めることになります。

これらの内容を踏まえた上で、小規模な調達内容であったり要件の変更の可能性が低かったりする場合は、調達仕様書の中に要件定義の内容を記載することも可能です。

また、調達仕様書と要件定義書を分けた場合にも、調達仕様書には「要件定義書を満たす旨」のみをただ書けばよいわけではありません。調達単位を分割する場合は、要件定義書の内容のどの部分が当該調達で満たすべき部分かを指し示す必要があります。要件の中でも提案を求める部分や未確定の部分がある場合は、その箇所を明確にする必要があります。また、調達仕様書に要件定義書の内容のまとめと要件定義書の該当箇所への参照リンクを記載することで、外部事業者の理解を促す工夫をすることも有効です。

ポイントは、外部事業者が要件の内容を漏れなく正確に理解できるか？理解しやすい形式になっているか？です。

B. 付属文書を活用して可読性を上げ機密性を確保する

調達仕様書には、応札等の検討に不可欠な情報を網羅的に示す必要がありますが、調達仕様書の本編に全てを記載することは困難です。無理に記載しようとすると、かえって調達内容が理解しにくいものとなってしまうおそれがあります。それを未然に防ぐため、情報量や粒度に応じて、別文書として準備し、調達仕様書の付属文書とすることを検討すべきです。

また、調達に必要な情報の中には、機密保持の観点から一般に公開できない内容も含まれます。このような内容は、独立した文書として準備し、その文書の閲覧を希望する外部事業者が閲覧手続きを発注者に対して行った上、発注者の立会いの下、執務場所での閲覧等として機密性を確保します。

付属文書は、調達仕様書の「付属文書」の事項にて、事業者が入手又は特別な手続きを経ずに閲覧できる資料一覧として整理し、公開しない文書については閲覧要領にて閲覧手続き方法を伝えます。

２ 調達仕様書の記載内容を理解する

【標準ガイドライン関連箇所：第３編第６章第３節1)】

この実践ガイドブックには、別添として

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

このひな形はあくまで例示ですので、調達内容に応じて記載内容を個別に追加、変更してかまいません。ひな形を見ると、何をどのようなレベルで書くべきかの参考になると思います。

以降では、調達仕様書を作成するときに、特に注意が必要なポイントについて説明していきます。項目の詳細な説明は、ひな形を参照してください。

A. 調達の意図や目的を正しく伝える

外部事業者に応札を促してプロジェクトにとって有用な提案を引き出すためには、プロジェクトの背景及び目的、調達に至るまでの経緯、成果物やサービスに期待する効果、プロジェクトの全体像や見通しといった発注者の意図を明確に伝えることがとても大切です。要件や作業内容を伝えるだけでは、要件どおりの情報システムを構築するために必要な提案は得られるかもしれませんが、プロジェクトの目的や目標をよりよく達成するために十分な効果を発揮する提案を引き出すことができません。

これらは、調達仕様書の「調達案件の概要に関する事項」にて、プロジェクトの背景、調達目的及び調達で期待する効果、業務・情報システムの概要にて記載するとともに、契約期間を含むプロジェクト全体のスケジュールで全体像を示します。

図6-3　作業スケジュール例

B. 関連する調達、入札制限を伝える

事業者が応札を検討する際に、他の調達案件との関係性を理解してもらうことはとても重要です。事業者によっては後に予定している調達案件への応札を検討していることもありますので、過去や将来の調達案件、それらに係る入札制限も含めて明確に記載します。

今後調達する調達案件の全体像や入札制限の関係については、プロジェクト計画書で明確にした上で、その要点を早期から外部に公開することを推奨します。

もし、これらの関係が明確に示されておらず、事業者がある案件を落札し契約した後で、後続案件に入札できないことが判明すると、大きな問題になってしまいます。

関連する調達や入札制限を明確に記載し早期に公開することで、未然に上記のような事態を防ぐことが重要です。

図6-4　調達案件及び関連調達案件の調達単位、調達の方式、実施時期等の例

C. 作業内容・納品物を関連付けて網羅的に記載する

調達仕様書では、外部事業者の作業内容、納品物をそれぞれ漏れなく定める必要がありますが、設計・開発等の調達では多種多様な作業や納品物があるため、漏れなく記載するのはなかなか難しいものです。

これらを定義する際は、作業内容、納品物を関連付けて定義していくことで、効果的に抜け漏れを確認していくことができます。

図6-5　作業の実施内容と納品物一覧の確認イメージ

このように作業の実施内容と納品物を関連付けて一覧としてまとめておくと、工程完了時の納品物のチェックにも活用でき、検収時の確認負荷を減らすことができます。

D. 外部事業者の具体的な作業内容を明確にする

作業内容の記載から、事業者が実際に何を実施する必要があるのか、わかりにくいケースがときどき見受けられます。

例えば、「支援」という言葉は人によって解釈が大きく異なります。「マニュアル作成支援」という作業項目があった際に、職員が元となる原案や素材を用意したうえで事業者が体裁を整えるという役割分担も考えられますし、事業者がマニュアルの原案自体を作成して職員が内容を確認するという役割分担も考えられます。このような役割分担の違いによって、事業者が実施する作業範囲や必要工数は大きく変わってきます。

実際に実施する内容が事業者に正確に伝わらない場合、以下のような事態をまねくおそれがありますので、事業者に実施を求める内容は正確に記述してください。

作業内容が曖昧な場合に懸念される事態

・

必要な人員のスキルや数について、応札希望者等の想定と発注者側の希望や想定とがミスマッチとなる場合、契約した後に業務を完遂できない。

・ 作業を終えることができた場合であっても、成果物の品質（機能性、信頼性、使用性、効率性、保守性、移植性）が著しく低下する。

・ 契約した外部事業者からの問合せや協議等が増加し、発注者側に想定していた以上の作業が発生する。

E. 作業の実施体制を明確にする

調達案件を通じてプロジェクトの活動を円滑に進めていくためには、発注者側であるＰＪＭＯや関係する職員が、体制や役割分担、責任範囲を明確にし、外部事業者と一緒に協働していくことがとても大切です。調達仕様書や要件定義書をしっかり記載して適切な外部事業者を選定することが仮にできたとしても、望んだ情報システムを必ずしも手に入れられるわけではありません。プロジェクトを進めていくと、要件の内容を設計として具体化・詳細化していく中で発注者側が決定しなければならないこと、他の関係者と調整しなければならないことは多く発生しますし、進捗上の課題や問題が発生した場合に発注者側の判断を要する場合もあります。

事例：発注者にも受注者にも遵守しなくてはならない義務がある プロジェクトは発注者と受注者が協力して実施する必要があります。システム開発の失敗責任を巡って争いとなったケースの判例では、受注者の「プロジェクト管理義務」、発注者の「プロジェクト協力義務」について、それぞれ言及しています。 ■ 受注者の「プロジェクト管理義務」について ある地方銀行（以下「銀行Ｇ」という）では、基幹システムの刷新プロジェクトを立ち上げ、大手開発ベンダ（以下「ベンダＸ」という）との間で開発作業の契約を行いました。しかし、プロジェクト開始直後から作業は難航し、数年後にプロジェクト中止という判断に至りました。 発注者側である銀行ＧはベンダＸに対して損害賠償を求め法廷で争うことになりました。裁判の結果、情報システムの専門家であるベンダＸが、提案したシステム方式に関する詳細な内容やリスクを銀行Ｇに十分に説明しなかった点について、プロジェクト管理義務違反等に当たるという判断が下され、ベンダＸ側に賠償金の支払が命じられました。 ■ 発注者の「プロジェクト協力義務」について また、ある大学病院（以下「病院Ｈ」という）では、病院情報管理システムの刷新を企画し、大手開発ベンダ（以下「ベンダＹ」という）との間で開発作業の契約を行いました。しかし、プロジェクトの開始直後から、発注者側である病院Ｈの現場担当者からの追加要件が相次ぎ、途中追加要件の取り込みについて病院Ｈ及びベンダＹの双方が合意した上で仕様を凍結し、納期も延長することになりました。 しかし、仕様凍結後も病院Ｈの現場担当者からの追加要望は収まらず、開発はさらに遅延し、最終的に病院ＨからベンダＹへ契約解除が通告され、プロジェクトは中止になりました。 ベンダＹは、発注者側である病院Ｈが仕様凍結の合意後において、要件の追加、変更を繰り返したことがプロジェクト中止の原因であるとして、損害賠償を求めましたが、逆に病院Ｈは受注者であるベンダＹが納期を守らなかったことを理由に裁判を起こしました。その結果、病院Ｈが発注者の責任として同院内の現場担当者からの追加要望を調整しなかったことが、プロジェクト協力義務違反に当たるという判決が下され、発注者側に賠償金の支払いが命じられました。 このように、受注者である外部事業者側だけではなく、発注者側にもプロジェクトを完遂させるために守らなくてはならない義務があることを、十分留意しておくことが重要です。

調達仕様書の「作業の実施体制・方法に関する事項」にて、発注者側、外部事業者側、関係者の体制、役割、責任をそれぞれ明確にします。

図6-6 作業実施体制例

なお、サービス・業務の企画や要件定義のように新しいサービス・業務や情報システムの内容を決定するような活動においては、特に注意が必要です。意思決定の責任は発注者にあることを認識した上で、ＰＪＭＯ以外の関係者も含めて、適切な判断ができる体制を組成して調達仕様書に明示してください。

F. 成果物の取り扱いに注意する（知的財産権）

調達案件にて設計・開発した文書やアプリケーションプログラムの知的財産権は、誰に帰属させるべきでしょうか？パッケージ製品を全く改変することなく採用した場合、製品の知的財産権は製品の提供元に帰属するのだろうと類推しやすいのですが、では、その製品を利用して蓄積されたデータはどちらに帰属するでしょうか？また、発注者側の要望に基づいた既成のパッケージ製品を拡張した機能やクラウドサービスの設定等は誰に帰属するのでしょうか？

標準ガイドラインでは、政府情報システムのソフトウェアに関わる知的財産権については、産業技術力強化法（平成12年４月19日法律第44号）の趣旨に鑑み、受注者に帰属させることが基本となります。しかし、設計・開発後に行われる情報システムの保守や継続的な機能追加等は、必ずしも設計・開発を行った外部事業者が行うとは限りません。成果物の知的財産権が誰に帰属するかなどを適切に定めておかないと、保守や機能改修、更改等のときに「人質」のようになってしまい、大きな問題に発展するおそれがあります。

事例：知的財産権の帰属先が問題となった例 情報システムを構成する要素は多岐に渡ります。想定していなかったものに対して「まさかこれに知的財産権が？」となり、トラブルになりかけた事例を次に示します。ここにあげた事例は、いずれも最終的には外部事業者との調整で問題を解決しましたが、本来は調達を行う時点でこのような点についても知的財産権の帰属について明確にしておくことが望ましいといえます。 ・ ある省庁の業務アプリケーションにおいて、アプリケーション本体の知的財産権は発注者側に帰属していましたが、使用している外字のフォントデータは外部事業者に帰属していました。このフォントデータがないと、登録した情報を画面や帳票に正しく出力することができません。次期システムの検討に当たり、既存情報システムの開発事業者が外字の知的財産権を主張し、ベンダロックインになる事態を招きそうになりました。 ・ ある省庁で保有している情報システムでは、データベースからデータを抽出するプログラムは外部事業者が独自に開発したもののため、使用するのであれば別途ライセンス料金が必要と言われてしまいました。

参考：オープンソースの有償と無償の境界について ソフトウェアのライセンス形態には様々なものが存在し、従来は提供元が大部分の権利を保有して利用者側が一切改変できないものが一般的でしたが、近年は利用者側が一定のルールの下で無償利用や改変等が可能なものも多く存在しています。一般的にオープンソースとよばれるこれらのソフトウェアにも、ライセンス形態に複数の種類があります。 最も自由度が高い例としてApacheライセンスが挙げられます。これは、使用、複製、改変、再配布、ライセンス継承等について制限がなく、「Apacheライセンスを使用していること」を明記することだけが定められています。 逆に、ＧＰＬ（General Plublic・icence）の場合は、以下４つのルールが定められています。 (1) ソフトウェアは無償で利用可能 (2) 著作権は表示しなくてはいけない (3) 複製、改変、再配布、販売は制限なし (4) 再配布する場合は、ＧＰＬライセンスにしなくてはいけない ＧＰＬライセンスのソフトウェアをプロジェクトにあわせて改変して利用する場合、当該ソフトウェアはＧＰＬライセンスのルールが維持されることになり、複製や再配布を認めなくてはならなくなります。 また、ソフトウェアの利用は無償でも、利用者ごとのカスタマイズが必要なライブラリの改変は有償のケースや、サポートが高額な場合もあるため、ソフトウェアを採用する際は、ライセンスの内容を詳細に確認することが重要です。

このような問題を防ぐためにも、案件の内容を踏まえて、調達案件中に発生する中間的な成果物も含め、全ての成果物に関して、知的財産についての権利の帰属、移転の可否、第三者への再利用、著作人格権の行使等の取決めを検討し、調達仕様書の「成果物の取扱いに関する事項」に記載します。

G. 再委託に関する事項を定める

情報システムの整備においては、プロジェクトの規模が大きくなるほど、様々な役割が必要となります。特に、設計・開発工程や運用・保守工程では、情報システムの一部を担う特定の技術や専門分野に特化した外部事業者を活用する機会が多く、これらの外部事業者は、請負契約を締結している外部事業者からの再委託となることが一般的です。再委託先が担当する作業内容については、委託先の外部事業者（以下「委託先」という）が責任を持って管理することが原則ですが、再委託にまつわる失敗事例も少なくありません。

以下に一般的な例をいくつかご紹介します。

事例：再委託に関する失敗例 ・ 委託先が作成した提案内容を評価し、プロジェクトの委託先として選定したにもかかわらず、再委託先が提案内容を遂行するために必要なスキルレベルを十分に持っておらず、成果物の品質低下やスケジュール遅延を招いてしまった。 ・ 委託先と再委託先との関係性の悪化や再委託先内の社内事情から、再委託先が要員を引き上げてしまい、再委託先を改めて手配するまでの期間、作業が中断してしまった。 ・ 再委託先に所属するプロジェクトのキーマンが、病気や家庭の事情でプロジェクトから離脱してしまった。委託先の要員が代替となったが、そのキーマンが属人的に持っていた情報やノウハウが委託先には引継がれていなかったため、代役を担うことができなかった。 ・ 委託先が再委託先に利用者との検討や調整等の作業を丸投げしてしまい、要件や仕様の変更を把握しなかったため、工数超過やスケジュール遅延に発展してしまった。 ・ 委託先が利用者から得た情報を抱え込んでしまい、再委託先が作業するために必要な情報を提供せず、再委託先が利用者に再度同じ内容に関する説明を求めるという二度手間となり、利用者側との間の関係が悪化し、利用者側からの協力を得ることが難しくなってしまった。

このような問題を未然に防ぐためにも、調達仕様の「再委託に関する事項」にて、再委託の制限及び再委託を認める場合の条件、承認手続、再委託先の契約違反等を定め、再委託時の要員の配置や品質、情報管理等に関する責任の所在を明確にします。また、プロジェクト遂行中に発生した様々な事情により、請負側の体制変更をはかることがありますが、その際は発注者側と協議の上、請負者の負担と責任において実施することが原則です。

なお、再委託に関する事項は、自府省の情報セキュリティポリシーにおける再委託先における情報セキュリティ対策に係る規定も必ず確認してください。

H. 納品後に不具合が発覚したときの責任を明確にする。(契約不適合責任)

「瑕疵担保責任」と「契約不適合責任」の違い

2020年4月に施行される改正民法においては、従来、納品されたシステムに不具合が発覚した際に適用されてきた瑕疵担保責任に関する条項がなくなり、代わりに「目的物が種類、品質又は数量に関して契約の内容に適合しないものであるとき」（契約不適合）についての条項が規定されました。これは、瑕疵担保責任の規定が現代の取引実情に合わなくなっていたものを解消するための改正であり、様々な点で改正がされておりますが、特に注意が必要な相違点としては以下が挙げられます（なお、請負契約の場合を前提にしています。）

契約不適合責任への変更による注意点

・

救済手段の多様化

瑕疵担保責任においては、瑕疵の修補、損害賠償の請求及び契約の解除のみしか認められていなかったのに対し、契約不適合責任については、①修２６６６補、代替物の引渡し又は不足分の引渡しによる履行の追完の請求、②報酬の減額の請求、③損害賠償の請求及び④契約の解除が可能となり、それぞれについて、要件が整理されました。実際に不具合が発生した際にどの救済手段を取るべきかの判断を適切に行う必要があります。

・ 権利行使の可能な期間の起算点の変更

瑕疵担保責任は、引渡しのとき又は仕事の終了時（通常は検収後）1年間であり、その後に発見された瑕疵については、いかなる救済手段の権利行使もできませんでした、改正後は、種類又は品質についての不適合は、発注者がその不適合を知ったときから、1年以内に受注者にそれを通知すれば、救済手段の権利行使をすることができ、数量の不足に関しては、そのような制限はなくなりました。もっとも、消滅時効の改正の影響で、通知した場合であっても、当該権利は、債権者が権利を行使することができることを知った時から5年間行使しないときには消滅することになります。

「契約不適合」を契約条項とするときの留意点

IT開発において検収後に発見される不具合等に新しく創設された契約不適合に関する条項を適用する場合、ベンダ側は、最長で10年もの間 (民法166条に定める債権の消滅時効期間)、不具合の対応を無償で行うことを求められる余地があり、そのための体制も維持しなければなりません。

このことが大きな負担になることから、ベンダはこの条項の削除を求めたり、長期に渡る体制維持のために、高い見積もりを提示したりする可能性があります。また、こうした条項を嫌って、応札を見送るベンダもあるかもしれません。

こうしたことを避けるためにはベンダに対して、自らの求める仕様、言い換えれば、何を担保すれば契約の内容に不適合にはならないのかを具体的に説明し、合意を得ておく必要があります。

具体的に何を説明するのかについては、個別に異なりますが、主には、①契約の目的に資するもの(※1)　が納品されていること、②提示した要件が全て満たされていること、③予定した作業や工程が全て完了していること、④予定していたレビューやテスト等の検証(※2) が全て完了し、設定した合格基準を満たしていることが、これまでのIT紛争における判例から推測される”システム完成”の基準です。

こうした基準を第三者の客観的な視点でも認識がずれることないように提示(※3)　することが、ベンダ側の過度な警戒を回避し、高い見積もりの提示や応札拒否を避けることに有効であると考えられます。

※1 契約の目的が、そのまま検収の条件となるわけではありません。システム化によって、職員の作業工数を半減されることが目的とし、それが叶わなかったとしても、客観的に見て、コスト削減に資する機能や性能を具備したシステムが納品されれば、”目的に資する”ものであると考えられます。

※2 請負契約の場合、受入テスト以外の検証については受託者に一任されますが、契約に適合するモノを作っていることを証明するために、敢えてテストやレビューの計画や実施状況、合格基準と結果等を提示してもらい、その妥当性を委託者側が評価することが有効と考えられます。

※3 第三者が同じ認識を持てるようにするには、各基準を数値化したり、Yes/Noで答えられる形式に設定したりすることが有効です。

Step.4 調達仕様書以外のドキュメント作成

調達を行うためには、調達仕様書以外にも、契約書をはじめ様々なドキュメントが必要となります。ここでは、特に重要となる契約書と総合評価落札方式による調達に必要となる提案依頼書について、説明していきます。

１ プロジェクトに合わせた契約書を作る

【標準ガイドライン関連箇所：第３編第６章第３節2)】

契約書は、会計担当部門等の契約を所管する部門が作るので、ＰＪＭＯはあまり関係がない。そう思っていませんか？

そんなことはありません。契約書に記載される内容によっては、プロジェクトの遂行に大きな影響を与えることもあります。契約書の作成に当たっての特に重要な確認・調整のポイントは次のとおりです。

A. 調達仕様書と契約書の整合性を確認する

調達仕様書の記載事項には、場合によって契約書に同様の事項を記載することがあります。これらの内容について調達仕様書と契約書で齟齬が生じている場合、後々問題となることもあるので、契約書を所管する部署と事前に意識合わせを行い、調達仕様書との記述の住み分けを決めておくことが重要です。

調達仕様書の中で特に確認すべき事項を以下に示します。

契約書との整合性を特に確認すべき調達仕様書の内容

・

標準ガイドライン「第３編第６章３．1)キ 成果物の取扱いに関する事項」の知的財産権の帰属、契約不適合責任、検収等に関する内容

・ 標準ガイドライン「第３編第６章３．1)ケ 再委託に関する事項」の再委託の制限及び再委託を認める場合の条件、承認手続、再委託先の契約違反等に関する内容

・ 標準ガイドライン「第３編第６章３．1)コ その他特記事項」の調達仕様書の変更手順等に関する事項

２ 提案依頼書の内容を工夫する

【標準ガイドライン関連箇所：第３編第６章第４節1)】

総合評価落札方式で調達を行う場合は、提案依頼書の作成が必要となります。調達案件を確実に、かつ効果的に履行できる外部事業者を選定することは、簡単なことではありません。

しかし、提案依頼書の作成の際に、いくつかのポイントを押さえることで、効果的に適切な外部事業者を選定する審査を行うことができるようになります。特に重要なポイントは次のとおりです。

A. 具体的な作業計画を評価する

提案書の内容だけでは、応札事業者が本当に調達案件を履行する能力があるかどうかを判断するのは難しいものです。特に大規模な情報システムや関係者が多数いるような情報システムの構築は、プロジェクトの計画能力や管理能力がとても重要になりますが、提案された体制や要員スキル、過去の実績からだけでは、評価が難しいのが現実です。

外部事業者の技術力を適正に評価するためには、具体的な作業計画の案の提出を求めて評価することが効果的です。

事例：事業者の設計・開発実施計画書の作成能力に問題があった例 ある府省の情報システムでは、基本設計で想定した内容の実現性を確認・検証する調査業務を総合評価落札方式で調達しました。提案依頼書では、ＷＢＳの案の提示を求めるとともに、本件調査業務のプロジェクトの実行可能性に関する説明も求めました。 この調達はＥ社の一者応札となり、提案に係る技術審査において、提案されたＷＢＳを審査したところ、明らかな矛盾点や作業の前提の見込み違い等が判明したので、同社に繰り返し確認したものの十分な説明はなされませんでした。しかし、その調達における技術審査委員会での議論の結果、実行可能性を引き続き確認することを条件として、同社への委託を決定しました。 プロジェクト開始後、当初予定を大幅に超過しただけでなく、プロジェクトの経緯確認及びプロジェクト実行計画書・ＷＢＳ等の作成もできなかったので、実作業の開始に至らず、Ｅ社との契約を解除することになりました。

ＷＢＳ等のプロジェクトで行うべき作業の一覧、それらの順序やスケジュールなどを計画した文書の提出を求めることは、当該プロジェクトの背景や内容に関する応札者の理解度、プロジェクト計画を含む管理能力及び履行能力を示す指標となります。

ＷＢＳの精度については、総合評価落札方式の技術点としても審査することも可能ですし、最低価格落札方式においても入札参加資格の要件の一部としてＷＢＳの案の提示を求めることにより、事前に審査を行うことが可能です。

ＷＢＳの計画の妥当性を判断できる例を次に示します。

ＷＢＳを精査する

ＷＢＳには大きくプロセスベースと成果物ベースの２種類がありますが、基本的には成果物ベースで作成することを推奨します。仮にある情報システムが４つの独立したサブシステムで構成されていたとすると、最後の総合テストはこの４つのサブシステムを統合した状態でテストを行いますが、その手前では４つのサブシステムは各々準備が整い次第、サブシステム内の総合テストを実施します。準備が整い次第とは、その配下の全ての機能における結合テストが完了したことを指します。さらに、結合テストはその配下の全てのモジュールの単体テストが完了次第、逐次結合テストを実施します。そのように考えると、単体テスト、結合テスト、総合テストそれぞれが１つずつのＷＢＳというのではなく、上流テスト工程に向けて徐々に行（タスク）が集約されてゆくようなピラミッドイメージのＷＢＳとなるはずです。「図6-7 テスト工程の名称を羅列しただけのＷＢＳ」はネットに転がっているようなテンプレート的なＷＢＳで、こんなものは調達仕様書の中身をよく検討しなくても機械的に割り当てるだけで作れてしまい、ＷＢＳとして「手抜き」以外の何物でもありません。

図6-7　テスト工程の名称を羅列しただけのＷＢＳ

通常、５～20程度のサブシステムが存在するようなシステム規模であれば、サブシステム数の10倍程度の機能数の結合テストは必要となります。確かに全くモジュール分割されずに１サブシステム１機能１モジュールなら、単体テスト→結合テスト→総合テストが順次的に隙間なく並びますが、多くの場合、結合テストは五月雨に始まって順次終了することになります。開発要員が少人数の場合は、プログラマーが希少資源となるので、単体テストは同時並行ではなくプログラマーの数以上に並列化できません。逆に大規模開発の場合であっても設計者が各サブシステムに固定化されて案件ごとに柔軟に要員を増加できないこともあるので、やはり全てのモジュール、機能が同時に単体・結合テストを開始・終了することはありえないのです。

図6-8　成果物（＝機能）単位に分解されたＷＢＳ

普通にＷＢＳに分解すると「図6-8 成果物（＝機能）単位に分解されたＷＢＳ」のようになります。左上１列目がサブシステム、２列目が機能、３列目がモジュール単位です。まずコーディング・単体テストを一緒に実行し（水色のボックス）、機能の下位のモジュールについて全て完了した後で結合テストを実行し（黄緑色のボックス）、サブシステムの下位の機能について全て完了した後でシステムテスト（オレンジのボックス）を実行します。さらに担当者によっては１機能が終わった後で次の機能に着手する場合もあり、これらの順次処理を→で表記しています。「テンプレート的な標準ＷＢＳ」である図6-7と比べると検討の深さが違い、プロジェクトの実現性が十分担保されています。

ＷＢＳの妥当性が疑われる例

・

テスト工程を羅列しただけになっている。

・ 単体テスト、結合テスト、総合テストそれぞれが１つずつで、それぞれの関係性がわからない。

・ 開発要員が少人数の場合に、単体テストがプログラマーの数以上に並列化されている。

ＷＢＳの妥当性があると判断できる例

・

成果物（＝機能）単位に分解されている。

・ 20～200ぐらいの機能（あるいはこれ以上の数ならサブシステムに分割する。）に切り分けられている。

・ サブシステムが複数ある場合、結合テストはサブシステム数の10倍程度の機能数分ある。

・ 単体テスト、結合テスト、総合テストの関係性がわかる。

・ 多くの場合、結合テストは五月雨に始まって順次終了する計画になる。特に大規模開発の場合、設計者が各サブシステムに固定化されることが多いので、全てのモジュール、機能が同時に単体・結合テストを開始・終了することはありえない。

ただし、これらの評価には専門的な能力が必要となりますので、適正な評価ができる審査体制を組成することを忘れないでください。

B. 加点の配分を工夫する

総合評価落札方式では、公正性・透明性を確保するために、評価基準となる評価事項ごとの配点を事前に決める必要があります。しかし、やみくもに（例えば均等に）配点すればよいわけではありません。

参考：総合評価落札方式の加点配分について 「情報システムの調達に係る総合評価落札方式の標準ガイドライン（平成 25 年７月 19 日調達関係省庁申合せ）」では、以下の(1)から(5)全ての要件を満たす調達については、総合評価落札方式を適用できると示してします。 (1) システム化対象の業務の実施方法や内容が複雑かつ多岐にわたるもの (2) 技術的構造の異なる複数の情報システムと連携するもの (3) 制度・業務の見直し等に伴う頻繁な機能改修を伴うもの (4) 大規模なプロジェクトで多人数の要員への高度な統制力が必要なもの (5) 連携、統合等を行う情報システムや関係組織が多く存在するもの 入札価格に対する得点配分の割合は、全体の四分の一以上（技術点：価格点が３：１以上）としますが、各評価項目に対する得点配分は、その必要度・重要度に応じて定めるものとされています。 ある省庁では、情報システム開発は３：１、プロジェクト管理支援等の役務は２：１、ハードウェアやパッケージ製品等の物品購入は１：１といった、調達する内容によって比率を変えて実施しています。 また、調達の基準額（ＳＤＲ）によっては、当該調達の総合評価落札方式の適用について、入札公告又は入札公示の前日から起算して、少なくとも30日前に財務大臣に届け出する必要があります。

技術審査を行う際は、当該調達で何を重視するかをよく検討し、重視する項目に対する優れた提案に高い配点がされるように検討する必要があります。配点に関する工夫を次に示します。

配点に関する工夫

・

基礎点の合計と加点の合計の割合は、基礎点の合計の割合を最低限にして、加点の割合を高くする（基礎点の割合が高い場合、実質の価格競争となるため）。

・ 評価事項ごとに均等に配点するのではなく、プロジェクトで重視する評価事項に加点が多くなるように配点する。

・ 一つの評価項目に対しても、評価が高ければ加点が大きくなるよう、加点に傾斜をつける。

なお、審査で重視する項目を設定する場合は、プロジェクトの目的に応じて発注者として期待する内容が応札者に適切に理解された上でそれが応札者の提案に反映されるよう、調達仕様書及び要件定義書とも整合を図ることが大切です。

Step.5 調達手続とプロジェクト管理

調達仕様書等の調達に必要なドキュメント類が完成しました。あとは、実際に調達の手続を進めていくことになりますが、焦らずにここで一呼吸置きます。調達の手続を開始する前にプロジェクト管理の視点で再度確認することで、実際の調達案件の履行の際の管理がより効果的に行えるようになります。

では、調達の手続の前に確認すべきポイントを見ていきます。

１ 調達手続に伴うプロジェクト管理作業とは

【標準ガイドライン関連箇所：第３編第６章全般】

政府情報システムの整備に係る調達の手続では、調達に直接係る作業以外に、プロジェクトを適正かつ効果的に管理・遂行するためにやるべき作業があります。これの作業内容とタイミングを事前に理解した上で調達の手続を進めることで、無駄な作業を減らし、調達案件を円滑に履行することができるようになります。

A. 第一次工程レビューを意識して資料をチェックする

第一次工程レビューは、調達仕様書が完成するタイミングで実施します。

工程レビューの対象は、府省重点プロジェクト等のＰＭＯが指定したプロジェクトではありますが、通常のプロジェクトでも同じタイミングで調達仕様書の自己点検を行っておくことで、調達が不落に終わることによる調達事務手続きの手戻り等の無駄を未然に防ぐことになり、効果的です。

特に次の点について留意して、自己点検（工程レビュー対象のプロジェクトの場合は、正式な第一次工程レビュー前）を実施することをお勧めします。

確認の留意事項

・

各ドキュメントと整合性が取れているか？

Step.3で示したとおり、調達仕様書は様々なドキュメントと関係性を持ちます。関連するドキュメントと、プロジェクト及び調達の目的の達成に必要な項目が抜け落ちていたり、矛盾して定義されていたりしないかをチェックすべきです。また、要件定義書とは内容面のチェックを行い、調達仕様書で定義した実施作業や成果物の内容が、要件定義時の想定と合っているかをチェックすべきです。

・ 他の調達と整合が取れているか？
１つのプロジェクトでは、複数の調達が実施されることがあり、大規模なプロジェクトほど数多くの調達を行う傾向があり、各調達間の認識に不整合が存在すると、目標・目的が達成できないおそれもあります。そのため、各調達間（異なる調達や時間経過を経た過去の調達）で、特に当該調達と依存関係があるものについて、その内容の整合性、作業や要件の抜け漏れがないかをチェックすべきです。

２ 情報システムの調達に特有の注意点

【標準ガイドライン関連箇所：第３編第６章全般】

情報システムの整備に係る調達には、情報システムならではの注意点があります。これらを事前に理解せずに調達を進めてしまうと、後々問題となることがあります。これらの事態を未然に防ぐため、事前に情報システムの調達特有の観点を理解し、調達仕様書や契約書等に制約等を適正に盛り込み、ポイントを抑えて調達案件を管理していきましょう。

A. ベンダロックインを理解し、回避する

Step.3の「成果物の取り扱いには要注意」で示したように、情報システムの設計・開発を進めてから、その設計情報等が受注者側の人質のようになり、次の作業や調達を行う際に、制約条件となる可能性があります。

その発生原因として、次の２点の要素が考えられます。

ベンダロックインの発生原因

・

設計情報が専門的であり、かつ大量に存在するため、作成者以外の第３者が把握して理解するのが難しい。

・ 情報システムは作りっぱなしではない。運用に入った後も、社会情勢等の環境変化に伴う様々な要因によって要件変更が発生し、情報システムの機能改修・拡張が発生しやすい。このとき、情報システムの開発当初にある特定ベンダのみが権利を有して、排他的な独自技術や開発フレームワーク等が採用されている場合には、その特定ベンダ以外が改修を行うことは難しい。

最初の点のみであれば、例えば建築や電子機器の調達でも当てはまりますが、２点目の要素が加味されるために、内容の詳細がわかる人が常に求められます。

その結果、情報システムに何らかの改修等を行う際に、必ず設計・開発を実施した外部事業者を頼る必要が出てきます。

ここで問題となるのは、過度に外部事業者に任せてしまった結果、どの外部事業者でもできるはずの作業が特定の外部事業者にしかできなくなってしまい、追加作業に対して過度な費用を請求される事態に陥ることです。（※Step.3の「成果物の取り扱いには要注意」がその１例です。）

そのような事態を未然に防ぐためには、これら特性を踏まえた上で次に挙げる留意事項に従って調達を準備する必要があります。

なお、過度に制約を入れ過ぎると、応札希望者を減らすことになりますので、作成した調達仕様書に記述した各種条件は、ＲＦＩ等を通じて、外部事業者と透明かつ公正な事前ヒアリングをしておく必要があります。

留意事項

・

情報システムを構成する要素を理解しておきます。

情報システムは、ＡＩや機械学習を応用するような先進的な例を除いて、基本的には人間が定義した命令や処理どおりにしか動作しません。つまり、情報システムを利用して業務を行う発注者側の各関係者が、それぞれの立場で正しく業務要件を定めることに始まり、発注者側の各関係者と契約した外部事業者と協働して各要件を詰めていくことが重要です。また、実際に動くプログラム（実行モジュール）とそれを生み出すソースコードだけでは動きません。これら以外にも例えば以下のようなものが必要となります。

・ マスタデータ、移行データ、情報システムにより登録されたデータ

・ パラメータファイル、パッケージやクラウドサービスに設定する設定値

・ ログファイル、統計情報等の実行情報

・ コード規約、データ標準、マニュアル等のドキュメント

様々な要素から出来上がっていますが、特にデータについては帰属先が曖昧になりがちですので、注意が必要です。

・ 情報システムを構成する要素を踏まえた上で、以下を明確にし、調達仕様書に記載しておくことが重要です。

・ 成果物の定義を明確にすべきです。特に、設計・開発で作成した成果物は、制限なく納品されるかを確認してください。最低限必要な成果物は、「調達仕様書テンプレート」に成果物一覧として記載してありますので、それぞれが納品されるか確認してください。

・ 成果物の権利関係を明確にすべきです。権利関係次第では、開示されない設計情報が発生する可能性があります。そういった場合、その後の運用保守改修を進める上で問題とならないかをＣＩＯ補佐官等に確認してください。

Step.6 検収

検収は、調達仕様書で定められた納品物が正しく収められているかを確認し、成果物を外部事業者から受け取るという調達の最終盤の作業ですが、ただの儀式ではありません。ここでは検収の際に気をつけておくべきポイントをご紹介します。

１ 検収の位置づけと内容を理解する

【標準ガイドライン関連箇所：第３編第６章第８節】

プロジェクトには、その成果物の妥当性や整合性を確認する作業が何種類もありますが、それぞれの作業で確認する観点が異なります。それぞれの確認作業が持つ意味を正しく理解して実施しなければ、成果物の不備や不測を適切なタイミングで発見することができず、トラブルの原因になります。ここでは、検収での確認に関連するポイントを見ていきます。

A. 検収と受入れテストの違いを理解する

検収とは、調達手続の一つとして、調達受注者が納めた成果物が調達時に示した仕様（契約）どおりに納められたかを確認する行為です。

重要なのは、調達開始時の約束事を、受注者が果たしたかどうかという点です。検収の実施者は、発注者側の検収担当者である検査職員です。検査職員は、調達仕様書及び契約書に定められた内容と納品物との突合せを行い、仕様どおりに納品されているのかを確認します。そこには、テストに関するドキュメントも含まれますが、内容が充分かどうかは判断が付きません。

一方、受入れとは、ＰＪＭＯを中心として、納品された成果物が今後のサービス・業務の実現に足るかどうかを判断する行為です。この行為は、テストとしての一連の作業からなり、終端は職員が実施する受入れテストとなります。逆に言うと、受入れテストのみでは、その情報システムが受入れ可能かは判断が付きません。

また、プロジェクト開始時は、調達仕様書の内容に沿って作業が進められますが、様々な調整や追加変更を経て、情報システムは完成します。その際の経緯や、結果としてどうなったかは、契約変更を伴うものは検収でも発見できますが、通常のプロジェクト管理の変更管理の範囲での内容は、検査職員には認識されていません。

つまり、検収と受入れは異なるものです。検収は手続上の行為として必要であることは前提としつつ、実質の受入れに対して職員が充分に関与しないと、納品されたが機能しないだけでなくプロジェクトの目的の達成に寄与しない情報システムが出来上がることになりかねないのです。プロジェクトの目的の達成に寄与しない情報システムが出来上がった場合には、最悪、その情報システムを利用する職員が行う業務そのものに悪影響を与え、手戻りが発生するなどして手作業での修正を関係者に強いるおそれがあります。

B. 残存する課題（軽微な瑕疵等）の対応を明確にする

スケジュールや優先順位等の関係から、検収の時点で優先度の低い軽微な不具合が残ってしまうことも少なくありません。多くの場合、瑕疵と認められる不具合は契約に基づいて外部事業者が修正することになりますが、契約期間の終了とともに外部事業者側の体制は縮小（または解消）することが一般的であるため、不具合の改修時期が不明確になることもあります。

このため、検収時点で瑕疵である不具合がわかっている場合は、その不具合に対する改修計画を明確に提出するように求めましょう。各々の不具合に対して、「いつまでに」「誰が」責任を持って「どのように」対応するかを改修計画で明確にさせ、その改修計画が発注者側として受け入れることができるものかどうかを契約期間の終了前に確認し、合意形成をあらかじめ図ることが大切です。