Step.3 調達仕様書の作成

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

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

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

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

この実践ガイドブックには、別添として、設計・開発工程の調達を例にした調達仕様書のひな形を示しています。

様式例6-１

調達仕様書のひな形

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

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

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

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

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

図6-4

作業スケジュール例

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

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

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

図6-6

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

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

また、中小・スタートアップ企業など、資金繰り面の課題を抱えやすい企業の入札参加が具体的に見込まれる場合、単一年度内に複数回の検収・支払いタイミングを設定することも可能です。RFIや発注者と事業者が対話を通じて相互理解を深めた上で、納品物と納品期日、検収・支払いタイミングを検討しましょう。

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

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

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

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

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

必要な人員のスキルや数について、応札希望者等の想定と発注者側の希望や想定とがミスマッチとなる場合、契約した後に業務を完遂できない。
作業を終えることができた場合であっても、成果物の品質（機能性、信頼性、使用性、効率性、保守性、移植性）が著しく低下する。
契約した外部事業者からの問合せや協議等が増加し、発注者側に想定していた以上の作業が発生する。

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

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

事例6-5

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

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

図6-7

作業実施体制例

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

参考6-2

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

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

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

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

事例6-6

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

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

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

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

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

事例6-7

再委託に関する失敗例

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

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

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

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

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

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

救済手段の多様化

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

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

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

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

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

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

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

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

契約の目的が、そのまま検収の条件となるわけではありません。システム化によって、職員の作業工数を半減されることが目的とし、それが叶わなかったとしても、客観的に見て、コスト削減に資する機能や性能を具備したシステムが納品されれば、”目的に資する”ものであると考えられます。
請負契約の場合、受入テスト以外の検証については受注者に一任されますが、契約に適合するモノを作っていることを証明するために、敢えてテストやレビューの計画や実施状況、合格基準と結果等を提示してもらい、その妥当性を委託者側が評価することが有効と考えられます。
第三者が同じ認識を持てるようにするには、各基準を数値化したり、Yes/Noで答えられる形式に設定したりすることが有効です。

Step.3 調達仕様書の作成

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

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

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

既存情報システムの機能改修を行う場合に準備するドキュメントを理解する