--- type: guideline title: Step.5 調達手続とプロジェクト管理 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.5 調達手続とプロジェクト管理 調達仕様書等の調達に必要なドキュメント類が完成しました。あとは、実際に調達の手続を進めていくことになりますが、焦らずにここで一呼吸置きます。調達の手続を開始する前にプロジェクト管理の視点で再度確認することで、実際の調達案件の履行の際の管理がより効果的に行えるようになります。 では、調達の手続の前に確認すべきポイントを見ていきます。 ## 調達手続に伴うプロジェクト管理作業とは 【標準ガイドライン関連箇所：第３編第６章全般】 政府情報システムの整備に係る調達の手続では、調達に直接係る作業以外に、プロジェクトを適正かつ効果的に管理・遂行するためにやるべき作業があります。これの作業内容とタイミングを事前に理解した上で調達の手続を進めることで、無駄な作業を減らし、調達案件を円滑に履行することができるようになります。 ### 第一次工程レビューを意識して資料をチェックする 第一次工程レビューは、調達仕様書が完成するタイミングで実施します。 工程レビューの対象は、ＰＭＯが指定したプロジェクトではありますが、通常のプロジェクトでも同じタイミングで調達仕様書の自己点検を行っておくことで、調達が不落に終わることによる調達事務手続きの手戻り等の無駄を未然に防ぐことになり、効果的です。 特に次の点について留意して、自己点検（工程レビュー対象のプロジェクトの場合は、正式な第一次工程レビュー前）を実施することをお勧めします。 確認の留意事項 - 各ドキュメントと整合性が取れているか？ Step.3で示したとおり、調達仕様書は様々なドキュメントと関係性を持ちます。関連するドキュメントと、プロジェクト及び調達の目的の達成に必要な項目が抜け落ちていたり、矛盾して定義されていたりしないかをチェックすべきです。また、要件定義書とは内容面のチェックを行い、調達仕様書で定義した実施作業や成果物の内容が、要件定義時の想定と合っているかをチェックすべきです。 - 他の調達と整合が取れているか？ １つのプロジェクトでは、複数の調達が実施されることがあり、大規模なプロジェクトほど数多くの調達を行う傾向があり、各調達間の認識に不整合が存在すると、目標・目的が達成できないおそれもあります。そのため、各調達間（異なる調達や時間経過を経た過去の調達）で、特に当該調達と依存関係があるものについて、その内容の整合性、作業や要件の抜け漏れがないかをチェックすべきです。 ## 情報システムの調達に特有の注意点 【標準ガイドライン関連箇所：第３編第６章全般】 情報システムの整備に係る調達には、情報システムならではの注意点があります。これらを事前に理解せずに調達を進めてしまうと、後々問題となることがあります。これらの事態を未然に防ぐため、事前に情報システムの調達特有の観点を理解し、調達仕様書や契約書等に制約等を適正に盛り込み、ポイントを抑えて調達案件を管理していきましょう。 ### ベンダーロックインを理解し、回避する Step.3の「成果物の取り扱いに注意する」で示したように、情報システムの設計・開発を進めてから、その設計情報等が受注者側の人質のようになり、次の作業や調達を行う際に、制約条件となる可能性があります。 その発生原因として、次の３点の要素が考えられます。 ベンダーロックインの発生原因 - 設計情報が専門的であり、かつ大量に存在するため、作成者以外の第３者が把握して理解するのが難しい。 - 発注者側が調達仕様書や設計書等のドキュメント類を適切に管理していない場合には、作成者以外の第３者が正確に仕様を把握することが難しい。 - 情報システムは作りっぱなしではない。運用に入った後も、社会情勢等の環境変化に伴う様々な要因によって要件変更が発生し、情報システムの機能改修・拡張が発生しやすい。このとき、情報システムの開発当初にある特定ベンダーのみが権利を有して、排他的な独自技術や開発フレームワーク等が採用されている場合には、その特定ベンダー以外が改修を行うことは難しい。 情報システムに何らかの改修等を行う際、これらが原因となって、設計・開発を実施した外部事業者以外の応札希望者が情報システムの設計情報等を理解することが難しくなるため、必ずその外部事業者を頼る必要が出てきます。 ここで問題となるのは、過度に外部事業者に任せてしまった結果、どの外部事業者でもできるはずの作業が特定の外部事業者にしかできなくなってしまい、追加作業に対して過度な費用を請求される事態に陥ることです。（※Step.3の「成果物の取り扱いに注意する」がその１例です。） そのような事態を未然に防ぐためには、これら特性を踏まえた上で次に挙げる留意事項に従って対策する必要があります。 なお、過度に制約を入れ過ぎると、応札希望者を減らすことになりますので、作成した調達仕様書に記述した各種条件は、ＲＦＩ等を通じて、外部事業者と透明かつ公正な事前ヒアリングをしておく必要があります。 ベンダーロックインを未然に防ぐための留意事項 - 情報システムを構成する要素を理解しましょう。 情報システムは、ＡＩや機械学習を応用するような先進的な例を除いて、基本的には人間が定義した命令や処理どおりにしか動作しません。つまり、情報システムを利用して業務を行う発注者側の各関係者が、それぞれの立場で正しく業務要件を定めることに始まり、発注者側の各関係者と契約した外部事業者と協働して各要件を詰めていくことが重要です。また、実際に動くプログラム（実行モジュール）とそれを生み出すソースコードだけでは動きません。これら以外にも例えば以下のようなものが必要となります。 - マスタデータ、移行データ、情報システムにより登録されたデータ - パラメータファイル、パッケージやクラウドサービスに設定する設定値 - ログファイル、統計情報等の実行情報 - コード規約、データ標準、マニュアル等のドキュメント 様々な要素から出来上がっていますが、特にデータについては帰属先が曖昧になりがちですので、注意が必要です。 - 調達仕様書に成果物の定義と権利関係を明確に記載しましょう。 成果物の定義を明確にした上で、設計・開発で作成される成果物が制限なく納品されるかを確認してください。最低限必要な成果物は、「調達仕様書テンプレート」に成果物一覧として記載してありますので、それぞれが納品されるか確認してください。 また、成果物の権利関係次第では、開示されない設計情報が発生する可能性があります。そういった場合、その後の運用保守改修を進める上で問題とならないかをPMO等に確認してください。 - 発注者側で最新のドキュメント類を確実に管理しましょう。 情報システムの整備に係る調達を実施する際に、設計書等から現状の情報システムがどのようになっているかを確認できるようにしておくことが重要です。運用・保守に入った後も、調達仕様書や設計・開発で最終確定した設計書等のドキュメント類は適切に管理しましょう。 ドキュメント類は保存しておくだけではなく、適切に管理することが重要です。ここで言うドキュメントの保存とは、ドキュメントをそのままの状態でフォルダに格納し、記載内容を維持することを言います。一方でドキュメントの管理とは、ドキュメントをそのまま保存するだけではなく、最新の状態に保つことを言います。 情報システムの仕様に変更が入った場合は、ドキュメントの記載内容や変更内容に矛盾がないことや、必要な情報が抜け漏れなく正確に記載されていることを確認しましょう。加えて、変更管理を確実に実施することが重要です。変更管理の詳細は、実践ガイドブック「第９章Step.4-2. 変更を管理し改善活動等の初動を楽にする」を参照してください。 また、ドキュメント類は、わかりやすいフォルダ構成で整理しておくことが重要です。人事異動による職員の交代があった際に、過去のドキュメントがどこにあるのか分からなくなりがちです。ドキュメント種別や年度別等に整理して保存しておくことで、欲しい情報を見つけやすくなり、このような問題が起きにくくなります。 - 参考6-4 クラウドサービス利用時のベンダーロックインに対する注意点

参考：クラウドサービス利用時のベンダーロックインに対する注意点

クラウドサービスを利用する場合においても、ベンダーロックインへの注意が必要です。以下では、クラウドサービスを利用する際にベンダーロックイン対策の観点から注意すべき点を例示します。

・閉鎖的なクラウドサービス

クラウドサービス提供者の中には、自社の関連事業者しか利用できないクラウド環境を提供している場合があり、それ以外の第三者が運用・保守事業者として受注した場合に、そのクラウド環境の利用に制約が発生する可能性があります。そのため、クラウドサービスはクラウドサービス提供者及びその関連事業者以外の第三者も利用できるよう要件を定めましょう。

・SaaSにおけるアプリケーションやデータの知的財産権

SaaSで提供されるアプリケーションは、あらかじめクラウドサービス提供者が構築したものなので、アプリケーションの知的財産権はクラウドサービス提供者に帰属します。このため、将来的に別のクラウドサービス等へ移行する際に、設計情報やソースコードを流用することはできず、類似のサービスがない場合には移行にかかる費用が高額となる可能性があります。

また、アプリケーションだけでなく、データレイアウト等は、クラウドサービスの一部として扱われ、クラウドサービス提供者に帰属します。発注者が必要なデータを標準的な形式で出力できるなど、このことが別のクラウドサービス等へ移行する際に障害とならないサービスを選定することが必要です。

・IaaSにおけるデータの帰属先

IaaSでは、アプリケーションやデータレイアウトは調達対象の業務で新たに構築することとなるため、多くの場合、データは発注者に帰属するとしています。しかし、クラウドサービスにアップロードしたデータをクラウドサービス提供者に帰属させる場合もありうるため、データの帰属先は発注者であることを明確にし、移行に支障がないようにする必要があります。

このような方法によって権利上、データが発注者に帰属したとしても、情報システムからデータを抽出する機能がなかったり、特定の製品でしか読み込めない形式でしか抽出できなかったりすると、別システムへ移行することができません。したがって、これらのデータは標準的な形式で取り出すことができるように、あらかじめ要件として定めておくことが必要です。
- 参考6-5 ベンダーロックインによる問題を回避するための工夫

参考：ベンダーロックインによる問題を回避するための工夫

ベンダーロックインに陥ると適正な競争が阻害され、調達コストの増加、事業者のサービス品質の低下などの問題が発生する懸念があります。発注者としてこれらの問題を回避するためにどのような工夫ができるでしょうか。

・優れた提案を受けられる環境の整備

ある情報システムは、複数のモジュールに分割して構築すべきところまでモノリシックな構成で構築してしまったため、保守性が低く、既存事業者以外が参入しにくい状況になっていました。

また、運用・保守に対する既存事業者のサービス品質についても、問合せや依頼事項への対応が遅いなど不満を感じる部分が多く、再三にわたって改善を要望したものの十分に対応されませんでした。

そこで、当該システムの更改に伴い、既存事業者だけでなく新規事業者からも優れた提案を受けられるように、以下のような取組みを実施しました。

【要件の明確化】

  • 発注者側組織の責任者自身が、次期システムの目指す姿、構想、実現方針を明確な文書としてまとめて、関係者へ共有した。

  • システム利用者に対して既存システムについてのアンケート調査を実施し、現場の声に即して新システムに求める機能要件を整理した。

  • 既存事業者がこれまで対応できなかった改修要望を洗い出し、提案時に加点項目として評価できるように明示した。

【情報提供による競争性の確保】

  • 機密保持契約を結んだ上で、既存システムの設計書等を応札予定の事業者が閲覧できるようにした。

  • 新規事業者でも既存システムについて詳細に把握できるように、既存システムの疑似環境が使える端末も準備し、応札予定の事業者へ貸し出した。

これらの取組みの結果、既存事業者と新規事業者間で競争が働き、発注者の要望への充足度が高い提案を行った新規事業者が落札しました。

なお、これらの取組みを行えた背景としては、発注者側の管理者が、「当該情報システムの動きを熟知した利用者である職員の意見を仕様策定の中心とする」ことを方針として打ち出し、新規事業者が落札した場合に生ずるであろう発注側作業負担の増大への覚悟を決め、さらに、それに対して情報システム部門の協力が得られた、という要素もありました。

また、別のある情報システムは、既存事業者によるベンダーロックインが発生しており、一社応札が継続していました。そこで、当該情報システムをオンプレミスからクラウドサービスへ移行するタイミングで、この状況の改善を図ることにしました。

発注者は、当該移行業務の調達に先立ち、クラウドサービスへの移行可能性調査を発注しました。これにより、新規事業者が当該情報システムの仕様等を十分に理解でき、クラウドサービスへの移行業務の調達では、既存事業者だけでなく新規事業者も応札しました。その結果、双方の事業者から技術面、価格面で質の高い提案がなされ、既存事業者が落札しました。

上記2つの事例では、いずれも発注者が競争性を確保するための工夫を行いました。後者の事例では、既存事業者が落札したことから、一見するとベンダーロックインが発生している状況と変わらないように見えますが、決してそうではありません。事業者が変わったかという表面的なことではなく、発注者が調達における競争性を適切に確保したことで、より優れた提案を事業者から受けられた点が重要です。

・随意契約時における交渉

ある情報システムでは、当初一般競争入札による事業者の調達を予定していたものの、ベンダーロックインが発生しており競争性の確保が難しく、一者応札となる見込みでした。そこで、契約方式を随意契約に変更した上で、発注者が事業者の作業計画等を精査することで発注者と事業者の認識そごの解消を図りました。例えば、不要と思われる会議や報告を削減することでプロジェクト管理工数を削減する、重複感のあるテストを絞り込むなどの対策を実施しました。その結果、当該仕様に基づいた精緻な見積りの作成が可能となり、見積額は当初取得したものと比較して大幅に減額されました。

調達時には、発注者と事業者で仕様書の記載内容に対する解釈にそごが生じ、本来は不要な作業工数が余分に見積もられるなどの理由で、見積額が高額になる場合がありますが、本事例のように随意契約をうまく利用することで、発注者と事業者が協力して仕様を詳細化でき、正確な見積りが可能となります。そのため、随意契約の方が一般競争入札より見積額が低くなることもあり得ます。

公共調達では、競争性及び透明性を確保する観点から、安易に随意契約を行うべきではありません。しかし、本来は妥当な価格で高い品質のサービスが提供されることが重要であり、これらの事例のように、それが随意契約によるものの場合もあります。随意契約とする理由・根拠が十分にあり、かつ、発注者が事業者と作業内容や実現方法について適切に交渉を行える場合には、調達コスト削減のために随意契約の採用を検討する余地もあります。随意契約の採用に当たっては「Step.2-1-E. 契約方式を検討する」も参照してください。
### 入札参加要件を緩和する 情報システムの整備に高い技術やサービスを取り込むためには、多様な事業者の参入を促すことが重要です。例えば、資格や実績要件について高いものを求めてしまうと、参入できる事業者が限定的になってしまうため、求める等級を緩和し、下位の等級に格付けされた事業者からも優れた提案を受けられるようにすることが望ましいです。 - 事例6-9 総合評価方式の入札参加資格で規模要件を撤廃

事例：総合評価方式の入札参加資格で規模要件を撤廃

ある府省では、入札の参加要件として求める等級を定めているものの、提案の優劣等を示す指標ではないことから、総合評価方式にて実施する事業すべてについて、原則、等級区分Dの事業者から入札参加を認めています。
### 入札事務手続きを簡素化する 事業者が応札を検討する際には、入札事務手続きの負担を軽減することがとても重要です。入札事務手続きの煩雑さから入札を見送っている事業者もいることから、多様な事業者の参入を促すためにもデジタル化を通じた入札事務手続きを簡素化することを推奨しています。 - 参考6-6 デジタル化による入札事務手続きの簡素化

参考：デジタル化による入札事務手続きの簡素化

事業者が応札する際に、従来は提案書等の様々なドキュメントを紙で提出することを求めていましたが、近年は電子調達システムの利用を原則としたデジタル化が進んでいます。提案書作成や見積作成等の書面の押印廃止や電子データでの提出を認めている府省庁もありますが、各省庁がもつデータの活用により事業者に求める提出書類を削減することができます。

・入札参加資格申請時の公的書類の削減

入札参加資格申請時において、事業者に提出を求めている登記事項証明書の内容や納税証明書による未納の税額の有無等には、管理する府省への問い合わせや情報提供で確認できるものがあります。必要な情報を持っている府省が明らかな場合には、府省間での情報連携を検討し、電子証明書による本人確認を前提に入札参加資格申請時の提出書類を削減していくことが大切です。

・入札説明会のオンライン化

対面での情報提供は事業者の負担になることから、入札説明会をオンラインで実施しているケースがあります。システム調達においては、オンライン環境が整備されている事業者が多いことから、対面でないと説明責任を十分に果たすことができなくなるおそれがある等の事情がなければ、オンラインでの実施が望ましいです。なお、資料閲覧にあたっては、秘密保持契約（NDA）を締結する等、機密性の確保に留意すること。

・応札ドキュメント（提案書・機能証明書等）の電子データでの提出や提出書類の削減

応札時の様々なドキュメントの押印を廃止し、電子データでの提出とすることで、事業者の負担となっている紙資料の準備や押印に必要な社内手続き等の時間や手間を削減することができます。また、gBizINFOをはじめとした既存の法人情報データベースで確認できる公的な資格等の情報については、ID情報を提供してもらうこととし、事業者に求める応札ドキュメントを削減することを心がけてください。