--- type: guideline title: Step.2 調達の事前準備 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.2 調達の事前準備 - 注記 ベンダーロックインとは、ソフトウェアの機能改修やバージョンアップ、ハードウェアのメンテナンス等、情報システムを使い続けるために必要な作業を、それを導入した事業者以外が実施することができないために、特定の事業者（ベンダー）を利用し続けなくてはならない状態のこと。 調達は、プロジェクト成功の命運を左右する重要な活動です。プロジェクトの成功に向けて目標を着実に達成するためには、不調や不落といった後々の手戻りにつながることを防ぎ、さらには調達した情報システムを継続的に利用していくに当たって一者応札やベンダーロックイン等による適正な競争を阻害する事態が発生しないよう十分な注意を払い、確実に調達内容を履行できる外部事業者又は製品等を選定できるように、事前に十分な時間を設けた上で準備をすることがとても大切です。 ここでは、実際の調達を始める前に行う事前の準備について説明していきます。 ## 調達の単位・計画を確認する 【標準ガイドライン関連箇所：第３編第６章第１節】 情報システムを整備する多くのプロジェクトでは、外部事業者への作業の委託や製品の購入などの複数の調達が行われますが、情報システムに関する専門的な知識を有していないと、何の調達をどの単位でいつ行うかよくわからないものです。 しかし、ポイントを押さえて事前準備をすることで、実際の調達時に不十分な内容に起因する手戻りなどによる無駄な手間をかけずに効率的に調達作業を行うことができます。 では、具体的な調達の事前準備のポイントは次のとおりです。 ### プロジェクト立上げ時点で調達を計画する 調達の計画では、「何の調達を」「どの単位で」「いつ調達するか」を計画します。 調達の計画は、まず、プロジェクトの立上げ時に行うことが一般的です。プロジェクトの立上げ時には、プロジェクトの概要スケジュールとして「どの活動を」「いつ行うか」を計画していきますが、その際に「どの活動を事業者に委託するか」「製品等がいつから利用可能になるか」を踏まえて、予算要求の計画も行っていきます。これらの内容は、まさに調達の計画の基礎情報となりますので、後々漏れることのないよう、プロジェクト計画書の実施計画（標準ガイドライン「第２章２．1) カ 実施計画」参照）に調達の計画も明記・可視化しておくべきです。 また、プロジェクトの立ち上げ時点で調達計画を立案することには、以下のメリットがあります。 プロジェクト立上げ時点で調達計画を立案するメリット - 予算要求時点等、プロジェクト初期の段階でＰＭＯの確認や助言を受けることができます。 - プロジェクト計画等の公開と併せて調達計画を公開することで、事業者に事前に調達の内容や時期を伝えることができ、事業者から多くの提案を得られる可能性が上がります。 ### 様々な調達単位があることを理解する 調達の計画で「何の調達を」「いつ調達するか」を特定した後、それらの調達を「どの単位で行うか」を検討します。 調達の単位は、標準ガイドライン解説書「第６章１．1) 合理的な調達単位の検討」で示す16種類が基本項目となりますが、これらの複数を１つの調達にまとめることや１つの単位を分割して複数の調達にすることも可能です。最適な調達の単位は、プロジェクトの規模や性質によって異なります。 また、調達を複数に分ける考え方を分離調達と言い、そのメリット及びデメリットは次のとおりです。 分離調達を実施した場合のメリット・デメリット - 分離調達によるメリット - 特定事業者に偏るというベンダーロックイン状態の解消 - 競争性・透明性の向上による価格の適正化と提案内容の質の向上 - 競争による市場の活性化 - 分離調達によるデメリット - 調達を分割して参画する事業者が増えることによる、事業者の管理や事業者間の調整、リスク管理や問題発生時の対処等、発注者側の管理労力の増加及び調達作業負荷の増加 これらの分離調達のメリットとデメリットを理解し、競争性・透明性を保ちつつ、適切なプロジェクト運営が行えるよう、プロジェクトの規模や性質に合った調達の単位を検討してください。 なお、十分な検討をせずに調達単位を決めてしまうと、事業者からの応札がなく不落となったり、一者のみからの応札となったりする場合もあり、結果として分離調達の意義が失われるおそれがあります。 以下に、調達単位を検討する際の具体的な事例を挙げます。 調達単位を考える際に留意すべき具体例 - 問題となる例 - 【現行情報システムの調査】を、今後整備する新たな情報システムのアプリケーション設計・開発、機器賃貸借業務に含める。 - 【現行情報システムからのデータ抽出】を、今後整備する新たな情報システムのアプリケーション設計・開発、機器賃貸借業務に含める。 現行情報システムに対する作業を、これから予定している調達の中に含めた場合、現行情報システムの知識を十分に有する既存の運用・保守事業者が有利となり、競争性が損なわれるため、問題となります。 - 慎重に検討すべき例 - 【アプリケーションの導入】を機器賃貸借業務に含める。 - アプリケーション及び機器の【総合テスト】を機器賃貸借業務に含める。 - 【データ変換/投入作業】を全面的に機器賃貸借業務に含める。 - 【情報システムの切替え作業】を全面的に機器賃貸借業務に含める。 - 【障害の切り分け】を機器賃貸借業務（保守業務を含まない）に含める。 - アプリケーション設計・開発事業者がＳＷを選定・設計・開発し、【ＳＷの導入】のみ機器賃貸借業務に含める。 専門性の異なる分野の業務を安易に束ねてしまうと、本来であれば多数の事業者に参入機会がある業務であっても、特定の事業者にしか応札できないものとなってしまいます。 ただし、１つの事業者が関連する作業をまとめて実施した方が、全体として効率的な場合もあります。上述のような例については、調達単位を分割することによる競争性確保と、束ねることによる効率性向上の両面を検討した上で、調達単位を決めてください。 - プロジェクトを跨って調達単位を統合した例（良い事例） - 複数のプロジェクトやサブプロジェクトで別々に実施していた業務を統合する。 - 複数の組織で別々に実施していた業務を統合する。 １つのプロジェクトだけで調達を行うだけでなく、他のプロジェクトや他の組織と連携することで、調達単位を統合し、対象業務も効率的に実施できる可能性があります。 - 事例6-1 サブシステム間でのシステム監視業務の統合

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

あるプロジェクトでは、複数のサブシステムを持つ大規模情報システムの監視・運用コストの見直しに取り組んでいました。このプロジェクトでは、サブシステムの単位でサブプロジェクトの体制を組んでおり、各サブシステムの運用・監視を行う事業者を個別に調達していました。

現状の監視・運用業務を調査した結果、個別に実施している運用・監視業務の中には類似作業が多く含まれており、これらを統合することによって更に効率的に実施できることが明らかになりました。そこで、サブシステムごとに保有していた統合監視サーバ、統合監視端末、パッチ配信サーバを１セットに統合し、運用作業についても一元管理する事業者を調達する方針に変更しました。
- 事例6-2 複数の組織で共通利用するＬＡＮ構築の調達

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

ある地方拠点事務所では、同一拠点で複数の組織が業務を行っており、過去の経緯からＬＡＮが個別に整備されていました。

ＬＡＮの整備や運用に関する煩雑な業務とコストを削減するため、中心となる組織の担当者がＬＡＮの統合に向けた検討を行いました。検討の中では、まず現状を詳細に把握するところからスタートしました。例えば、それぞれのＬＡＮでは、メールやグループウェア等の業務を行うためのサーバを多数導入していましたが、各サーバのCPUやメモリの使用率を調べると余裕が大きいことがわかりました。そこで、これらのサーバを統合することでコストを削減するとともに、サーバを設置していたサーバルームについても統合することとしました。

このように、ＬＡＮを統合して共通利用する場合のメリットとデメリットをまとめ、複数組織合同による情報化推進委員会に諮り、改善を進めました。

![](../assets/ds-120-ch06-image1.png)
### 調達にあった落札方式、評価方式を検討する 情報システムの整備に関する調達を行う際には、実施する案件の技術面や管理面等の難しさを踏まえて、調達内容を着実に履行できる事業者を選定する必要があります。残念ながら、契約した事業者が調達内容を十分に履行できずに、うまく立ち行かなくなったプロジェクトは少なくありません。 このような事態を防ぐためにも、調達時には、その内容に適した落札方式を選択し、価格以外の技術的な評価を行う場合は、審査に必要となる評価基準、審査体制等を十分に検討した上で事業者の選定の準備を整えます。 総合評価落札方式とは、価格点と技術点の２つの要素で事業者の提案内容を評価する方式です。なお、価格点と技術点を総合評価する方法として除算方式と加算方式という２つの評価方式があります。ただし、除算方式は価格点が分母となり低入札価格による影響を極端に受けやすいため、基本的には加算方式を採用するのが良いでしょう。 調達の計画時点で、落札方式や評価方式も合わせて検討し、調達の手続を適正に行えるように、計画を立てるようにします。 ### 調達計画を早めに公開する 入札が不調（応札者が現れない）や不落（応札価格が全て予定価格を超過）となってしまうと、プロジェクト全体のスケジュールが大幅に遅延してしまいます。また、一者だけからの応札となってしまうと、十分な価格競争が働かない可能性があります。 このような事態を防ぐためには、次に示すような対策を行い、極力多数の外部事業者から応札を受けられるように準備しましょう。 - 過去に別プロジェクトで情報システムの調達を行った際に、応札や仕様書を受領した外部事業者等に問合せる。 - プロジェクトの目的の達成に必要な技術的要件が明らかな場合には、その要件に合致しそうな製品等を探す。 さらに、調達計画を広く公開して透明性を確保し、外部事業者がプロジェクトの目的や調達内容について十分に理解できるような公平な機会を設けることも有効です。似たような調達が過去にないなどで外部事業者が見つからないときや調達計画の公開を検討する際は、ＰＭＯに相談してください。 - 事例6-3 異なる立場の職員による説明会の実施

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

ある省庁では、ＲＦＩやＲＦＰを実施する前に、調達内容に関連しそうな事業や製品等を提供可能な外部事業者を複数探しだし、透明性を確保した上で説明会を開催し、公正に直接意見交換を行う機会を設けています。

このとき、担う業務特性又は所属部署に基づく特定の立場の職員だけが説明を行うと、外部事業者に伝える内容に立場上の偏りが生じるおそれがあるため、会計担当、技術担当等の異なる立場の職員が、それぞれの視点から説明を行うようにしています。また、大規模な情報システムでは、サブシステムごとに個別の説明会を実施し、外部事業者へ丁寧な情報提供を行っています。

![](../assets/ds-120-ch06-image2.png)

![](../assets/ds-120-ch06-image3.png)

この結果、ＲＦＩによる有用な情報の入手や、公正で適切な調達が実行しやすくなり、プロジェクトの目的の達成に大きく寄与しました。
- 注記 公共調達の適正化について 契約方式を検討する 政府情報システムの調達は、原則として一般競争入札によって行うこととされています。これは、不適切な調達を行っているのではないかと国民から疑念を抱かれないように、公共調達の競争性及び透明性を確保する必要があるためです。安易に随意契約を行うと、競争性や透明性が損なわれ、国民に対する説明責任を十分に果たすことができなくなるおそれがあるため、「随意契約によらざるを得ない場合」を除いて随意契約を行うべきではありません。 どのような場合に「随意契約によらざるを得ない場合」とされるのかを理解するとともに、今回の調達の特性を踏まえ、どのような契約方式を選択すべきか検討する必要があります。 - 注記 「デジタル庁調達手続マニュアル」（デジタル庁　令和５年４月改訂） なお、仕様を詳細に確定させることが困難であるなど、発注者と事業者が対話を通じて相互理解を深めた上で契約することが特に重要な場合には、まだ政府では試行運用の段階ですが、技術的対話を取り入れた新たな調達・契約方法を採用する選択肢もあります。詳細は「デジタル庁調達手続マニュアル」（デジタル庁　令和５年４月改訂）を参照ください。 - 注記 「アジャイル開発版「情報システム・モデル取引・契約書」」 - 参考6-1 アジャイル開発を行う場合の契約方式

参考：アジャイル開発を行う場合の契約方式

アジャイル開発は、利用者にとって優先度の高いものから順次開発・リリースを進め、運用時の技術評価結果や顧客の反応に基づいて素早く改善を繰り返すという開発手法です。DX（デジタルトランスフォーメーション)時代における激しいビジネス環境の変化に対応し、利用者が真に必要としている価値を提供するプロダクトをタイムリーに開発する手法として有用であるとされています。

また、アジャイル開発では、開発プロセスの中において、ビジネス環境の変化やユーザ企業内部のニーズの変化などに応じて、開発する機能の追加・変更やその優先順位の変更が行われ、当初は開発予定となっていた機能を開発対象から外す場合もあります。そのため、あらかじめ内容が特定された成果物を予定したとおりに完成させることに対して対価を払う請負契約より、業務を受託した事業者が専門家としての注意義務を果たしながら業務を遂行することそれ自体に対価を支払う準委任契約の方が馴染みやすいとする意見もあります。

一方で、政府の調達においては、伝統的に請負契約が用いられることが多いことも事実です。これは、法令などの制約に基づくものではなく、受注者の義務及びそれへの対価が明確であり、投入した費用に対する成果を国民に説明しやすいとの理由によるものです。

そこで、本項では、請負契約と準委任契約のメリット・デメリットを記すとともに、これらをアジャイル開発の契約方式として採用するに当たっての留意点について整理します。アジャイル開発の契約にあたっては、これらについて十分に検討し、個々の事情や条件、制約などに応じて最適な方式を採用する必要があります。

  • 請負契約

説明
発注者が指定した成果物(ソフトウェア・機能など)を完成させることを受注者が約束する契約。
メリット・デメリット

メリット

  • 契約締結時に、機能要件や非機能要件を明確に定めることができ、受注者の責任範囲が明確になる。

  • 成果物が合意した仕様を満たしていないことが納品後に判明した場合、受注者に契約不適合責任（無償の修補、代替物の提供、代金減額等）を求められる。

  • 費用の妥当性を外部に説明することが容易。

デメリット

  • 契約前の見積りで対価が固定されてしまうことが多い。

  • 工数が変動する要件、機能等の変更を行いにくい。

  • 想定外の技術的困難の発見や体制変更などに対応しづらい。
アジャイル開発における留意点

  • 一括請負契約としてしまうと、対価が固定されている受注者としては、工数の増える要件、機能等の変更をできるだけ減らすことがその利益に適うため、アジャイル開発の求める柔軟な機能変更等ができなくなるリスクがある。

  • 開発対象のプロダクト全体を成果物とするのではなく、要件定義やプロトタイプの製作などについては別契約（準委任契約）で実施した上で、要件変更の可能性を極小化した部分について採用するのが望ましい。

  • 採用するに当たっては、事後的に機能等の変更のきっかけとなり得る技術的な困難も洗い出しておくことが望ましい。

  • 成果物については、双方協議の上、工数を変えない範囲で要件、機能等を変更可能であることなどを契約書に記すのが望ましい。

  • 準委任契約

説明
受注者は、成果物を完成させる義務は負わず、善管注意義務（民法第656条、第644条）を負い、専門家として期待される能力を以って業務を真摯に行うことが求められる契約。
メリット・デメリット

メリット

  • 要件、機能、優先順位等の変更が請負契約より容易。

  • 受注者側要員の知識・スキル・経験を求めることが可能。

  • 受注者側の要員を工数で管理することが可能。

  • 要件、機能等の変更により工数が変化した場合に支払う対価（総額）が変動するため、合理的な開発費となる。

デメリット

  • 成果物が完成しなくても、受注者に対し責任を問えない。

  • 履行割合型で報酬を定めた場合、成果物が完成していなくても報酬の支払義務が発生する。

  • 善管注意義務や専門家責任を客観的に評価することが難しい（監督職員、検査職員の負担が増える）。

  • 予算の範囲内での執行の管理が請負契約より難しい。

  • 成果物に不具合があった場合に受注者に契約不適合責任（無償の修補や減額等）を当然には求められない。ただし、善管注意義務違反を理由として損害賠償請求をすることは可能。
アジャイル開発における留意点

  • 期待される品質保証（サービスレベル）を明確にすることや、一定の成果物（レポートを含む）の納入を求める場合はその要件を明確にすることで、善管注意義務違反の有無の判断を客観的にできるように工夫することが望ましい（どのような事象が善管注意義務違反にあたるかを確認、合意しておくことも考えられる。）。

  • 期待される品質保証や成果物の要件が達成できない場合は、その理由を説明させる義務を定めておくことで、監督、検査の負担が軽減される。

  • 一定の品質保証や成果物の要件を満たす場合にのみ報酬が支払われる報酬体系（成果報酬型）とすることも検討される。

  • アジャイル開発を行うための体制、役割分担等を明確にし、執行内容の管理を適正に行う必要がある。

  • 発注者側がアジャイル開発業務の体制、役割を理解し、システム開発全般にわたって、主体的に関与する必要がある。

  • 準委任契約の類型～報酬の定め方

準委任契約には、成果物が完成したか否かにかかわらず、委託業務の履行に要した時間や工数に応じて発注者が報酬を支払う履行割合型契約と委託業務の成果に対して報酬が支払われる成果報酬型（成果完成型）契約があります。成果報酬型は、実務上は従前から用いられてきた類型ですが、新民法において明記されています（民法第648条の2）。報酬の定め方はどちらか一方にすることが義務付けられておらず、複合的に用いることも可能です（一定の指標をクリアしたことに対する加算として成果報酬を定めることなども検討されます）。ただし、成果報酬型契約の場合、契約の性質が請負契約に近づくため、アジャイル開発を選択している趣旨を失わないように注意する必要があります。

なお、民間においては、受注者に対して一定のスキル・知識・経験を持った要員が約束された工数分作業することを求める一方で、部分的に成果物の完成責任も求めるような、請負型と準委任型の性質を併せ持つ契約を行う例もあります。

また、準委任契約において、バックログ管理表や変更管理表を最終成果物として納品させる例もあります。それらに最終的に記載された機能や非機能を実現する作業が全て完了していることが検収の条件となり、実質的にソフトウェアの品質を受注者が保証することを可能にする例です。
- 注記 「アジャイル開発版「情報システム・モデル取引・契約書」」 - 注記 農林水産省「農業分野におけるＡＩ・データに関する契約ガイドライン－ノウハウ活用編－」 ## 調達の注意事項を理解する 【標準ガイドライン関連箇所：第３編第６章第１節】 調達は、契約方式や金額等に応じて調達手続や公示期間等が定められているため、いざ調達の準備を開始しようとした時点で、当初想定していたよりも時間がなかったことに気が付くことが少なくありません。調達の準備の時間が十分に取れないと、資料の準備不足や説明会等の不足から事業者への十分な理解が得られず、入札の不調や不落となりかねません。 このような不測の事態を防ぐために、プロジェクト計画の段階で調達に係るルールを理解し、調達に必要な期間を踏まえて準備を行えるように調達の計画をたてることが重要です。 ### 調達手続の基本的なルールを確認し理解する 調達に関する期間等のルールは、政府調達に関する協定や会計法等で調達手順や期間等が定められています。標準ガイドライン解説書「第６章１．調達の計画」に記載しているルールを確認して、計画を立ててください。 調達手続の流れについて、以下の図に示します。予定価格や案件の規模等により、必要な期間が異なるので、余裕を持った計画を立てるようにしましょう。 - 図6-1 ＩＴ調達手続の流れ ![](../assets/ds-120-ch06-image4.png) また、上の図について、関連する法令等をまとめた図を、以下に示します。 - 図6-2 調達に関する法令等 ![](../assets/ds-120-ch06-image5.png) 調達の手続については、協定や法令等で定められたルール以外に、各府省で独自のルールを定めている場合もあります。府省のルールによっては、公示のタイミングや期間が変わることもありますので、プロジェクト計画時点で各府省の調達ルールを所管する部署に対して確実に確認するようにしてください。 - 事例6-4 調達日程表のイメージ

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

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

![](../assets/ds-120-ch06-image6.png)
### 入札制限を正しく理解する 調達の単位を検討する際には、一部の事業者が有利とならないよう、それぞれの調達案件に対して適切な入札制限を設けて、透明性と公正性を確保する必要があります。また、調達案件の業務内容によっては、他の調達から独立性や客観性を担保するために入札制限が必要な場合があります。 標準ガイドラインでは、入札制限について、以下のように定めています。

b)　入札制限

透明性及び公正性並びに確実な契約履行等を確保するため、次のｲ）からﾊ）までに掲げる者に対し、入札制限を定めるものとする。

ｲ)　各工程の調達仕様書の作成に直接関与した事業者

各工程の調達仕様書の作成に直接関与した事業者は、透明性及び公正性の確保の観点から、当該調達案件の入札に参加させないものとする。ただし、競争上何ら有利とならないと認められるときは、この限りでない。

ﾛ)　設計・開発等のプロジェクト管理支援事業者

設計・開発等のプロジェクト管理支援事業者（プロジェクトの全部又は一部におけるプロジェクトの管理上生ずる作業について、ＰＪＭＯを支援する事業者をいう。以下同じ。）については、相互けん制の観点から、その管理の対象となる情報システムの設計・開発の作業に関する内容を含む調達案件の入札に参加させないものとする。

ﾊ)　監査対象である情報システムに関与した事業者

監査対象である情報システムに関与した事業者は、監査の独立性及び客観性の確保の観点から、当該情報システムの監査業務に関する調達案件の入札に参加させないものとする。

（標準ガイドライン「第３編第６章第３節1）クb)」）
ただし、「ｲ) 各工程の調達仕様書の作成に直接関与した事業者」に関しては、注意が必要です。例えば、調達仕様書の一部となりうる調査研究等を実施した事業者に対しても、その内容が調達内容や調達方法の決定に直接関わるものでなければ、設計・開発工程への入札制限を設ける必要がないと考えることができます。大切なことは、意思決定の責任は発注者にあることを認識し、他の応札事業者に対して、公正性が確保できる（競争上何ら有利とならない）環境を整備していくことです。 入札制限の意図を正しく理解し、透明性・公正性を確保しつつ、過度な入札制限を設けることで競争の機会損失や調達事務の効率性等を損なうことのないよう、調達単位を検討します。 ### 一者応札の状況を改善する ＲＦＩ等の事前情報収集や事業者との調整をしても、結果的に一者応札になってしまうことはあります。ですが、同じプロジェクトの案件で一者応札が続いてしまうのであれば、競争性を確保する観点から改善方法を考えるべきでしょう。 まず、既存事業者の優位性について考えてみましょう。既存事業者は、情報、要員、保有資料の３点において優位性を持っています。 入札における既存事業者の優位性 - 情報の優位性 既存事業者は既存システムの設計情報等を保有しているため、関連業務に関して既存の情報を前提とした作業見積を行うことができ、受注後も作業を速やかに実施することが可能になります。 一方、新規事業者は応札に当たってこれらの情報の収集、分析及び習得に時間とコストを必要としますし、情報不足によって見積りミスや仕様の取り違えも起きかねないためリスクを勘案する必要もあり、見積金額が高額になりやすいと言えます。 - 要員の優位性 既存事業者は既存システムを開発した要員を確保しており、この要員を次の関連業務に活用することが可能となります。 一方、新規事業者は関連業務を実施するために、情報システムの内部情報等を習得した要員を新たに育成する必要があり、教育の期間とコストを考慮する必要があります。 - 保有資料の優位性 情報の優位性と似ていますが、提案書作成や見積作成等の提案活動自体についても、保有資料の有無で優位性が異なります。 既存事業者は既存システムに関する設計書や提案書等の資料を電子データで保有しているため、提案活動を効率的に実施できます。 一方、新規事業者は調達仕様書や閲覧資料等の紙面の情報から、ゼロから提案書を作成するため一定の時間とコストを必要とすることになります。 つまり、新規事業者にとっては既存システムの業務の受注にはそもそもコストやリスクが大きく、既存事業者との競争に勝てないと判断した新規事業者は、応札そのものを断念することになります。 逆に言うと、一者応札の状況を是正するには、この既存事業者の優位性を相対的に低下させ、新規事業者にとっても競争が可能であることを理解頂くことが重要です。 　そのための具体的な施策例を紹介します。 一者応札状況を改善するための施策例 - 十分な準備期間の確保 新規事業者に対し、既存システムに関する技術的調査などを行うための十分な期間を確保します。 例えば、公告前にＲＦＩや公平性等を確保したヒアリングを実施すること、公告期間を調達手続上求められる最小限の日数よりも長く確保することなどが考えられます。 これにより業務内容、情報システムの仕様や稼働状況を把握した上での正確な見積りが可能になり、新規事業者にとってのリスクの低減につながります。 ＲＦＩの実施については「第3編第5章 Step3-1-A 参考：ＲＦＩ（資料提供依頼）、資料提供招請、意見招請の関係」を、公平性等を確保したヒアリングの実施については「第3編第5章 Step3-2 公平性等を確保したヒアリングを行う」をご参照ください。 - 設計情報等の詳細開示 既存システムの基本設計書や詳細設計書等を、入札時の閲覧資料等として新規事業者が確認できるようにします。 なお、ハードウェア、ソフトウェア、ネットワーク等の構成情報、データの種類やデータ量等は調達仕様書（要件定義書）にも記載しますが、この情報だけでは新規事業者にとってシステムの実態をつかむことは困難です。設計書等を開示することでアプリケーションの構造や特性を詳細に理解できるとともに、ドキュメント等の整備状況についても新規事業者が理解し、実態に合った工数積算を行えるようになります。 - 運用・保守業務の作業内容や実績情報の開示 既存システムの運用・保守に関連するドキュメント（運用設計書、運用手順書、運用マニュアル、保守設計書、保守手順書、保守マニュアル等の名称が多い）についても、入札時の閲覧資料等として新規事業者が確認できるようにします。 また、運用・保守業務の実績がわかる資料も重要です。具体的には、サービスレベル実績、障害やインシデントの管理情報、コールセンターやヘルプデスク業務の対応実績、変更管理実績等の情報です。運用・保守業務の各種報告書（運用報告書、保守報告書、作業報告書等の名称が多い）も、新規事業者にとって参考になる部分があります。 - 既存事業者が優位となる作業の分離 既存事業者が優位性を持つ作業を委託業務から分離することで、分離後の調達業務の競争性を高めることができます。 例えば、次のようなことを検討することが有効です。 ・既存システムを一括で再構築するのではなく、サブシステム単位で分離して新規事業者から参入しやすくする ・運用業務から業務アプリケーションの障害対応や修正等を分離し、定常的で手順書に沿った運用業務部分を調達範囲とする ・機器賃貸借業務から、業務アプリケーションに関連する作業（設定変更、修正等）を分離する - 汎用的な製品への移行 特定の事業者しか供給できない製品（ハードウェア、ソフトウェア）ではなく、汎用的な製品やオープンソースソフトウェア（OSS）を調達品目とします。現行の業務アプリケーションを汎用製品に適合させるための改修作業は必要になりますが、製品を供給できる事業者の選択肢が広がります。 - 前提条件等の緩和 事業者に求める資格や実績要件を十分に検討した上で、可能な限り仕様を緩和することで多くの事業者の参入を促します。例えば、資格要件の記載について当該資格の保有を絶対条件として求めるのではなく、他の代替可能な資格や能力を含めた要求事項とすることや入札参加等級を緩和することで、多様な事業者の参入を促すことが望ましいです。 【例１】　ISO9001の認定事業者であること、又は同等の認定を受けていること。 【例２】官公庁における同規模の情報システムの導入実績を持つこと、又は当該業務分野に関する業務や関係法令の知識を持ち同規模の情報システムの導入実績を有すること。 【例３】当該業務分野の情報システムの導入実績を持つこと、又はその情報システムと同程度の難易度、信頼性及び特性を有する情報システムの導入実績を持つこと。 - 契約期間の複数年度化 運用、保守業務を例にとると、新規事業者は受注後に既存システムの調査、運用保守に関わる知識の習得、作業プロセスの定義、各種連絡票や報告様式の定義等を実施します。この作業に多くのコストを要するため、契約が単年度であれば新規事業者は採算が取れないことがあります。 そのため、契約期間を複数年度にすることで、この初期コストを吸収できる契約形態も考慮することが望ましいです。 - 委託内容に関する数量情報の開示 作業内容を文章で表現するだけでなく、定量的に数値として示すことで新規事業者が業務の規模を把握しやすくなります。 例えば、システム改修の場合、改修する画面や帳票、データ項目を明確にし、その数量も提示しましょう。運用業務の場合であれば、前年度とほぼ同じ作業になることが多いため、前年度の作業内容や件数、作業量（工数）等を提示することが望ましいです。 - 次年度の調達を考慮した納品物 次工程や次年度の調達を考慮して、当年度の業務成果をドキュメントとしてわかりやすく最新化することが重要です。 特に設計書については、契約単位ごとに分冊として納品されることがありますが、このような状態では設計内容を理解するために過去の全ての設計書に遡る必要があり、読みこなすことが大変になります。新規事業者も含めて、第三者にとっても読みやすい構成となることを考慮しましょう。 - 事業者間の引継ぎ期間の確保 開札から作業開始までに、既存事業者から新規事業者への十分な引継ぎ期間を確保することで、新規事業者が参入する上でのリスクの低減につながります。引継ぎ期間が十分に確保できない場合には、調達計画の見直しを検討しましょう。 事業者間の引継ぎにおける工夫は、「第3編第7章 Step6-2 事例：異なる事業者間で引継ぎをスムーズにする工夫」をご参照ください。 ### 調達の前にリスクを再確認する 第２章　プロジェクトの管理のStep.3 「プロジェクト計画書等の作成」にて洗い出したリスクについて、調達する前にもう一度振り返りましょう。 リスク管理をせずに安易に調達を行うと、全てのリスクを事業者に負わせることになるため、結果として見積もり・入札額が高くなってしまったり、納期遅延を発生させてしまうことがあります。 既存事業者にとって「暗黙のリスク」であっても、新規参入事業者にとっては「見えないリスク」があることを理解し、調達仕様書に記載する、調達説明会で説明実施することを心掛けてください。