---
type: guideline
title: Step.7 要件定義終了後の対応
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.7 要件定義終了後の対応

要件定義に係る作業が一通り終わり、ほっとするところですが、実は今やっておくだけで後々発生するリスクや負荷を減らすことができる作業があります。

ここでは、それら作業とポイントについて解説します。

## 定義内容を関係者に共有する

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

要件定義書が出来上がることで、関係者にとって整備しようとしている情報システムの内容がより具体的に理解しやすくなり、これまでは意識していなかった考慮点や抜け漏れが発見できる可能性があります。

そのため、作成した要件定義書を関係者に確認してもらい、その結果明らかになった変更要望や新たな課題は、ＰＪＭＯ内で対応方針を検討し、業務要件に反映した上で、再度関係者と共有してください。内容によっては機能要件のみが変更対象となるものもありますが、機能要件の前提や根拠となる業務要件を必ず確認することが重要です。加えて、要件定義書完成時点で、当初の計画に対して工期や費用がどう変化したかについて評価し、プロジェクト計画に反映していくことが望まれます。評価の仕方や内容に不安がある場合は、ＰＭＯに支援を求めてください。

これにより、業務要件から機能・非機能要件を定義する過程で発生した変更点の確認や、要件を「見える化」した結果、「イメージしていた内容と違う」といった認識そごが発見でき、関係者一同が合意した要件定義書として確定できます。

また、役割が異なる複数の関係者が確認することにより、曖昧な内容や難解な箇所を修正でき、後続工程で事業者を含む第三者が理解しやすい内容になります。

## プロジェクト計画書に反映して最新化する

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

これで要件定義書が確定しました。要件定義のゴールは間近です。

要件定義書を作成する過程で、プロジェクト計画書に記載されていた内容とのかい離が発生した項目があるのではないでしょうか。

要件定義に係る作業の最後の締め括りとして、変更内容をプロジェクト計画書に反映しましょう。要件定義を開始した段階のプロジェクト計画書は、サービス・業務企画を受け、一通りの項目が詳細化されている状態です。本章の作業結果により変更が必要な箇所を確認し、更新してください。今回実施した内容を基にプロジェクト計画書を最新化することにより、次の調達や設計・開発において、今回の作業を基に修正したプロジェクト計画書の内容に沿って作業を進められるため、準備作業が減ります。

また、人事異動が発生しても、最新のプロジェクト計画書を整備しておけば、プロジェクトの全体像からこの時点で詳細化された情報まで正確な情報で引継ぎができます。

デジタル・ガバメント推進標準ガイドライン

実践ガイドブック

（第３編第６章　調達）

目次

[A. プロジェクト立上げ時点で調達を計画する [7](#プロジェクト立上げ時点で調達を計画する)](#プロジェクト立上げ時点で調達を計画する)

[B. 様々な調達単位があることを理解する [7](#様々な調達単位があることを理解する)](#様々な調達単位があることを理解する)

[C. 調達にあった落札方式、評価方式を検討する [10](#調達にあった落札方式評価方式を検討する)](#調達にあった落札方式評価方式を検討する)

[D. 調達計画を早めに公開する [10](#調達計画を早めに公開する)](#調達計画を早めに公開する)

[E. 契約方式を検討する [12](#_Toc151974220)](#_Toc151974220)

[A. 調達手続の基本的なルールを確認し理解する [14](#調達手続の基本的なルールを確認し理解する)](#調達手続の基本的なルールを確認し理解する)

[B. 入札制限を正しく理解する [16](#入札制限を正しく理解する)](#入札制限を正しく理解する)

[C. 一者応札の状況を改善する [17](#一者応札の状況を改善する)](#一者応札の状況を改善する)

[D. 調達の前にリスクを再確認する [20](#調達の前にリスクを再確認する)](#調達の前にリスクを再確認する)

[A. 調達仕様書と要件定義書の住み分けを理解する [21](#調達仕様書と要件定義書の住み分けを理解する)](#調達仕様書と要件定義書の住み分けを理解する)

[B. 付属文書を活用して可読性を上げ機密性を確保する [22](#付属文書を活用して可読性を上げ機密性を確保する)](#付属文書を活用して可読性を上げ機密性を確保する)

[C. 既存情報システムの機能改修を行う場合に準備するドキュメントを理解する [22](#既存情報システムの機能改修を行う場合に準備するドキュメントを理解する)](#既存情報システムの機能改修を行う場合に準備するドキュメントを理解する)

[A. 調達の意図や目的を正しく伝える [24](#調達の意図や目的を正しく伝える)](#調達の意図や目的を正しく伝える)

[B. 関連する調達、入札制限を伝える [24](#関連する調達入札制限を伝える)](#関連する調達入札制限を伝える)

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

[D. 外部事業者の具体的な作業内容を明確にする [25](#外部事業者の具体的な作業内容を明確にする)](#外部事業者の具体的な作業内容を明確にする)

[E. 作業の実施体制を明確にする [26](#作業の実施体制を明確にする)](#作業の実施体制を明確にする)

[F. 成果物の取り扱いに注意する（知的財産権） [29](#成果物の取り扱いに注意する知的財産権)](#成果物の取り扱いに注意する知的財産権)

[G. 再委託に関する事項を定める [29](#再委託に関する事項を定める)](#再委託に関する事項を定める)

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

[A. 調達仕様書と契約書の整合性を確認する [33](#調達仕様書と契約書の整合性を確認する)](#調達仕様書と契約書の整合性を確認する)

[A. 具体的な作業計画を評価する [34](#具体的な作業計画を評価する)](#具体的な作業計画を評価する)

[B. 加点の配分を工夫する [36](#加点の配分を工夫する)](#加点の配分を工夫する)

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

[A. ベンダーロックインを理解し、回避する [39](#ベンダーロックインを理解し回避する)](#ベンダーロックインを理解し回避する)

[B. 入札参加要件を緩和する [43](#入札参加要件を緩和する)](#入札参加要件を緩和する)

[C. 入札事務手続きを簡素化する [43](#入札事務手続きを簡素化する)](#入札事務手続きを簡素化する)

[A. 検収と受入れテストの違いを理解する [45](#検収と受入れテストの違いを理解する)](#検収と受入れテストの違いを理解する)

[B. 残存する課題（軽微な瑕疵等）の対応を明確にする [45](#残存する課題軽微な瑕疵等の対応を明確にする)](#残存する課題軽微な瑕疵等の対応を明確にする)

事例・参考の一覧

※事例には当時の役職名やシステム名を使用しているため、現在使用されていない名称が記載されている場合があります。