第５章　要件定義

ＰＪＭＯは、「第４章サービス・業務企画」で策定した業務要件を踏まえ、これを実現するための情報システムに求める要件（以下「情報システム要件」という。）として、情報システムの機能を定めた要件（以下「機能要件」という。）及び情報システムが備えるべき機能要件以外の情報システム要件（以下「非機能要件」という。）を明らかにするため、調達に先立ち、次のとおり、要件定義を行うものとする。

要件定義は、プロジェクトの目標を達成する上で、極めて重要な工程であり、要件定義が不十分なときには、計画の遅延又は情報システムの機能・性能が要求水準に満たないものとなる事態等が発生する可能性が高まるため、適切に実施する必要がある(1)。

１. はじめに

利用者の価値を最大化するサービス・業務企画を具現化し、政策目的及びプロジェクトの目標を達成するためには、情報システムに求める要件を漏れなく具体化し、意図を正しく事業者に伝えることにより情報システムの設計・開発、運用を滞りなく進められるよう準備する必要がある。

このため、要件定義では、サービス・業務企画内容を踏まえて、費用対効果等を勘案しながら、情報システムが備えるべき機能・性能等を明らかにするものとする。

また、要件定義のアウトプットである要件定義書は、後続の工程においてＰＪＭＯと事業者が業務や情報システムの目指すべき姿を共有するだけではなく、契約上の合意文書となる重要なものである。誤りや曖昧な定義が行われると、後続の工程に重大な影響を与えることから、適切な手順で確実に検討を進める必要がある。

要件定義は、情報システムの整備対象となるサービス・業務企画内容の規模と難易度から、ＰＪＭＯが実施する場合と、事業者に外部委託する場合が想定され、その進め方が異なる。本解説書では、ガイドラインで示される事項について網羅的に解説するため、ＰＪＭＯが要件定義を行う場合を主として解説するとともに、事業者に外部委託する場合の注意事項等を、場合分けとして記載する。

２. 解説

「要件定義が不十分なときには、計画の遅延又は情報システムの機能・性能が要求水準に満たないものとなる事態等が発生する可能性が高まるため、適切に実施する必要がある」

「計画の遅延又は情報システムの機能・性能が要求水準に満たないものとなる事態等」とは、ＰＪＭＯが行った要件定義が不十分で、内容に抜け漏れ・曖昧さが存在することにより発生する事態を指す。その例を次に示す。

計画の遅延やそれに伴う新たなサービス・業務の開始時期の遅延
予算要求額を超える開発規模となったことによる予算額の不足
更なるステークホルダーとの調整作業の発生やそれに伴う要件の追加・変更
情報システムの機能・品質が要求水準を満たさないために、サービス・業務の質が下がり、プロジェクトの目的・目標が達成できない

要件定義の準備

ＰＪＭＯは、要件定義に先立ち、次のとおり行うものとする。

１. 趣旨

情報システムの要件定義は、世の中の技術動向やサービスの動向、各種事例、要件を実現する方式に関する情報等を踏まえて実施する必要がある。必要な情報を入手しないまま要件定義を行ったときには、費用対効果に優れた手法の採用漏れや、優れた先進事例を取り込むことができない等のリスクが発生することとなる。

したがって、要件定義に先立ち、これらの情報を収集する必要があるが、多岐にわたる情報をＰＪＭＯの知識や経験のみで網羅的かつ詳細に把握することは困難である。

このため、ＰＪＭＯは、ＲＦＩ及び事業者へのヒアリング等により、要件定義の前提となる情報を広く収集し、要件定義で十分な検討が行えるように準備する。

ＲＦＩの実施

ＰＪＭＯは、要件定義の検討に際し、専門的な知見を広く取得するため、必要に応じてＲＦＩを実施し(1)、次の[1]から[4]までに掲げる事項を記載した説明書を作成するものとする(2)。

調達の概要(3)
その時点における検討内容、要件定義案の概要等(4)
資料提供を求める内容等(5)
提出期限、提出場所、提出方法、提出資料における知的財産の取扱い等(6)

なお、このうち[3]については、要件定義案の実現性、実現方法、それらの要件を実現するために必要な経費及び要員の見込み、要件定義案への修正事項（開発方式（クラウドサービスの活用、ソフトウェア製品の活用、スクラッチ開発等）、開発手法（ウォータフォール型開発、アジャイル開発等））等、事業者に具体的に求める内容について記載するものとする。

なお、原則としてクラウドサービスの利用を前提とした実現方式の情報も取得すること。

１. 趣旨

要件定義に必要となる専門的な知見は、その内容に応じて偏りなく幅広く収集する必要がある。

このため、ＰＪＭＯは、市場調査や資料提供の要請を行うときには、その内容に応じて公平性を確保し、ＲＦＩ等を通じて情報の収集を行う。

なお、ＲＦＩは、プロジェクトの規模を考慮して、準備着手の時期を判断する。

２. 解説

「専門的な知見を広く取得するため、必要に応じてＲＦＩを実施し」

「専門的な知見」とは、ＰＪＭＯが要件定義を行うに当り、ＰＪＭＯのみでは補完できない情報である。その例を次に示す。

市場にあるサービスの種類及びその最新動向
海外や国内の類似事例とその教訓
新たな技術の動向や製品のライフサイクル
想定する要件を実現する方式とその実現可能度や制約事項
概算の予算規模
大まかな工程やスケジュール
著作権や法的な制約
実現に際してのリスク等

「ＲＦＩを実施し」とは、ＰＪＭＯがサービス・業務企画の実現可能性や整備する情報システムに係る有用な情報を得るために、ＲＦＩに係る説明書を作成し、ＲＦＩの実施について通知を行い、情報を収集することである。

ＲＦＩの実施を通知するに当たり、広く不特定多数からの情報を求めるときには、府省Ｗｅｂサイト上で公開する等の手法があるが、必要な情報を確実に得るためには、事業者団体への通知やプレス発表等によって積極的にアナウンスすることも効果的である。

なお、ＲＦＩにおける事業者の回答内容が期待した水準に満たない場合や、回答内容の確認のために追加の情報提供を求める必要が生じた場合等には、ＰＪＭＯは、事業者に対して個別ヒアリング等を行い、不明点や情報が不足する点等を解消・補強する必要があることに留意する。

なお、機密性の高い情報を、事業者に対し提供する必要がある場合は、ＰＪＭＯはあらかじめ守秘義務の誓約書を事業者に求め、当該誓約書の提出があった事業者にのみ機密性の高い情報を提供する。

「次の[1]から[4]までに掲げる事項を記載した説明書を作成する」

「説明書を作成する」とは、ＰＪＭＯが、事業者から必要な情報を適切に収集するために、ＲＦＩに先立ち、プロジェクト内容を正確に伝達するための説明書を作成することを指す。ＰＪＭＯは、事業者に政策目的、プロジェクトの目的・目標及びサービス・業務企画内容等を正確に伝えられるよう、十分な準備を行う必要がある。

「[1] 調達の概要」

「調達の概要」とは、ＰＪＭＯが調達計画を明らかにするために、当該プロジェクトの調達計画の全体像と本調達が対象とする範囲を提示することである。

「[2] その時点における検討内容、要件定義案の概要等」

「検討内容、要件定義案の概要等」とは、ＰＪＭＯがＲＦＩを実施する時点で、前提として既に定まっている事項や、検討の過程で整理した案の概要等を指す。要件定義の開始前時点では、プロジェクトの計画及び進行によっては、確定していない内容が存在する可能性もあるが、要件として求める方向性等があれば、それを記載することが望ましい。

「[3] 資料提供を求める内容等」

「資料提供を求める内容等」とは、ＲＦＩにて提供を要請する情報の内容、その内容に含むべき事項等を整理し明確に定義したものである。プロジェクトで提供するサービス・業務を実現する具体的な方式、適合可能な技術、調達単位のあり方等に関する情報、実現に向けての大まかなスケジュール等の意見を求め、プロジェクトの実現可能性を高めることが重要である。

また、要件定義を有効に進めるために、未検討や未確定の事項についても、幅広く事例や動向等に関する資料の提供を求めることが有効である。

なお、パッケージ製品やクラウドサービスの適用を前提とするときは、ベンダーに対して提供可能な範囲の業務要件定義資料を提供し、ベンダーによる適合性調査（Fit&Gap）を依頼するだけでなく、パッケージ製品等のデモに職員が参加して機能の確認を行う、ベンダーへのヒアリングを実施する、パッケージ製品やクラウドサービスの最新情報（非機能要件や標準・オプションの価格等も含む）を入手する等、実際に適合することを職員がチェックすることが重要である。

「[4] 提出期限、提出場所、提出方法、提出資料における知的財産の取扱い等」

「提出期限、提出場所、提出方法、提出資料における知的財産の取扱い等」とは、提出に係る取り決めを定めた内容であり、その例を次に示す。

情報の提出期限や提出先、その方法
提出する資料に事業者のノウハウや機密事項が含まれる場合のその情報に関する制約事項
守秘義務の誓約書の提出要請

得られた情報に知的財産の制約がある場合、要件定義書等にそのまま用いることができないときがあるため、事業者に対して、公開済みで活用できる情報と、機密等を伴う情報とを区別できるような情報の明記を求める等の工夫も有用である。

事業者へのヒアリング等の実施

ＰＪＭＯは、有用な情報を得られるよう、公平性・競争性を確保した上で、事業者に対し説明会・個別ヒアリング等を逐次行い(1)、取得した情報を精査し、活用するものとする。

１. 趣旨

ＲＦＩにより、必要な情報を広く収集することができるが、ＰＪＭＯの意図が伝わらない場合、必要な情報が得られない、情報の粒度が異なる、誤った情報が提供されるといった事態が発生するおそれがある。

そのため、ＰＪＭＯが、事業者に対して、情報システムに求める要件を直接説明し、実現可能性等について意見交換をする機会として説明会やヒアリング等を実施することは、要件定義の内容をより精緻化し、設計開発工程以降での手戻りを防ぐ上で有効である。

なお、説明会・個別ヒアリング等では、公平性を確保するため、ＲＦＩと同様の方法で、実施について通知を行い、得られた情報については、議事録に記載する等の方法により、ＲＦＩの事業者回答と同様に取り扱うことが望ましい。

２. 解説

「事業者に対し説明会・個別ヒアリング等を逐次行い」

「説明会・個別ヒアリング等」とは、ＰＪＭＯが、事業者に対して、情報システムに求める要件を直接説明し、実現可能性等について意見交換をする機会を指す。これらは要件定義を開始する前のみならず、要件定義の実施中に情報が必要となった場合においても、適宜活用することが可能である。

なお、ヒアリングには、既存業務システムの仕組みを理解し、業務要件を正しく伝えられる職員の参加が望ましい。

なお、機密性の高い情報を、事業者に対し提供する必要がある場合は、ＰＪＭＯはあらかじめ守秘義務の誓約書を事業者に求め、当該誓約書の提出があった事業者にのみ機密性が高い情報を提供する。

必要な資料の作成

ＰＪＭＯは、「第４章５．業務要件の定義」において作成した資料のほか、要件定義に際し、必要な資料を作成するものとする。なお、既存資料を活用する場合には、現状の検討状況が適切に反映されていることを確認し、変更がある場合には更新するものとする(1)。

１. 趣旨

ＲＦＩ又は事業者に対する個別ヒアリング等で得られた情報は、要件定義や後の工程で適切に活用する必要がある。

このため、ＰＪＭＯは、サービス・業務企画で収集した情報、業務要件定義の内容とともに、ＲＦＩ又は事業者に対する個別ヒアリング等の実施結果、及び、その結果を分析した内容について整理した資料を作成する。

２. 解説

「既存資料を活用する場合には、現状の検討状況が適切に反映されていることを確認し、変更がある場合には更新するものとする」

「既存資料を活用する」とは、既存の業務及び情報システムの資料を活用することである。「第４章２．現状の把握と分析」にて収集した資料が活用可能であれば、それらを用いてもよいが、これら既存システムに係る各種ドキュメントが最新の状態になっているかを確認することが重要である。また、この確認作業を通じて、職員の既存システムに関する知識の向上も期待できる。

なお、業務や情報システムの内容は運用期間中に変更や追加が行われることが多いため、要件定義に当たって正確な情報を収集するには、現行情報システム運用事業者や現行情報システム保守事業者より、最新化された資料を入手する。

ＲＦＩの実施結果については、情報の網羅性や粒度について確認を行うとともに、複数の情報間での整合性についても評価を行う。プロジェクトの実行可能性の考え方に影響を与える情報が得られた場合は、所要の見直しを行う。

要件定義

ＰＪＭＯは、次のとおり、業務要件、機能要件、非機能要件及び情報システムの実現案を具体的に定義し、これらを記載した要件定義書を作成するものとする。なお、作成に当たっては、「第４章サービス・業務企画」において収集・作成した情報を基に定義することとし、要求する情報システムの特徴を踏まえ、記載内容の軽重を検討するものとする。また、定義した具体的な内容について、その必要性、網羅性、具体性、定量性、整合性、中立性及び役割分担の明確性の観点、さらに情報セキュリティ等の観点から、その実現可能性があることを確認するものとする。

なお、機能要件、非機能要件及び情報システムの実現案についても、情報システム部門のみで決定するものではなく、制度所管部門、業務実施部門を含めたＰＪＭＯ全体で決定することが不可欠であることに留意すること。また、要件を可能な限り詳細に検討した上で、実現案については事業者の創意と工夫を提案として受けられるように配慮すること(1)。

検討に当たっては、ＰＭＯ等の支援や助言を受けることが望ましい(2)。

１. 趣旨

要件定義で定める業務要件、機能要件、非機能要件は、多くの関係者と共有し、内容を合意する必要があり、後工程の作業を実施する際の元情報としても活用される。

このため、ＰＪＭＯは、これら要件を、網羅的かつ詳細に検討した上で、関係者が共有可能な文書として整備する必要がある。さらに、様々な要件を統合し、情報システム全体構成の実現案を作成することで、要件の抜け漏れを無くし、実現性の高い情報システムの全体像を明らかにする必要がある。

要件定義を事業者へ外部委託する場合

要件定義を事業者に委託するかどうかにかかわらず、ＰＪＭＯは要件定義内容の決定について責任を持つ必要がある。ただし、その決定に至るまでの進め方については、次の点に留意する。

業務要件は、「第４章サービス・業務企画」で決定した内容を基に業務に必要な要件を検討し、内容を確定するものである。その際、事業者が作成する各項目の定義内容について、ＰＪＭＯは全ての内容に目を通し、理解する必要がある。
機能・非機能要件は、業務要件を基に、情報システムに必要とされる要件を検討し、内容を確定するものである。その内容には、専門的なものが含まれるため、ＰＪＭＯが全ての内容を理解することが困難な場合がある。そのため、ＰＪＭＯは内容について理解できるように事業者に説明を求める必要がある。

なお、全ての要件について、サービス・業務企画を実現する上での重要性を事業者が判断することは困難であるため、ＰＪＭＯと業務実施部門が中心となって要件の重要度を決めるとともに、要件を実現する際の難易度について事業者に情報を求め、重要度と難易度を基に、要件の優先度を調整する必要がある。

２. 解説

「実現案については事業者の創意と工夫を提案として受けられるように配慮すること」

「事業者の創意と工夫を提案として受けられるように配慮する」とは、情報システムの調達を行う際に、より良い情報システムとするために、プロジェクトの目的や背景を要件定義書に明確に記載し、特に事業者から提案を受けたい重要な要件については加点項目として配点を高くする等、事業者から質の高い提案を受けられるようにすることを示す。また、提案内容の評価過程等において、発注者・事業者間で協議をし、事業者からの提案の実現内容について合意した上で、契約することが重要である。

「検討に当たっては、ＰＭＯ等の支援や助言を受けることが望ましい」

「ＰＭＯ等」とは、ＰＭＯ以外に、政府デジタル人材、高度デジタル人材、外部組織の有識者や専門的な知見を持つ職員を含むことを指す。

要件定義書の記載内容

要件定義書には、業務要件、機能要件、非機能要件及び情報システムの実現案を明らかにするため、原則として、次のアからエまでに掲げる事項について記載するものとする。なお、定義の時点において、未確定な要件については、それがプロジェクトを進める上でのリスク要因となり得ることに厳に留意し、その旨を要件定義書において明らかにするものとする(1)。

ア　業務要件の定義

業務要件は、情報システムを活用した業務の内容を定義する。なお、当該要件は、「第４章５．業務要件の定義」により検討した内容を基に、他の要件等との整合性を確認し、更新するものとする(2)。

イ　機能要件の定義

機能要件は、「デジタル社会の実現に向けた重点計画」に掲げる「デジタル３原則（①デジタルファースト：個々の手続・サービスが一貫してデジタルで完結する、②ワンスオンリー：一度提出した情報は、二度提出することを不要とする、③コネクテッド・ワンストップ：民間サービスを含め、複数の手続・サービスをワンストップで実現する）」を踏まえ、次のa）からe）までに掲げる事項をもって定義する(3)。なお、機能要件は、業務の質の向上、業務の効率化等に対する有効性等を踏まえ、優先度の高い機能から整備する必要があること、また、他の情報システムと連携する場合には相互運用性及びデータ互換性についても併せて記載する必要があることに留意するものとする。

なお、クラウドサービス（SaaS）等が提供する機能を利用する場合には、その利用する機能について記載するものとする(4)。

ウ　非機能要件の定義

非機能要件について、次のa）からr）までに掲げる事項をもって定義する(5)。定義の内容は、業務・情報システム両面で必要な要件を、網羅するものとする。なお、非機能要件は、技術的に検討を要する事項を多分に含むことから、日本産業規格等のほか、ＲＦＩ等を通じて、広く情報を取得し、実現性等の検証を行うものとする。

さらに、原則としてクラウドサービスの活用も検討するものとする(6)。クラウドサービスの選定に当たっては、「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」の記載に従って、適切にクラウドサービスを利用すること。

エ　システム方式の決定

情報システムの実現案として、「ウb) システム方式に関する事項」で検討した内容を他の要件の内容と調整し、決定する。なお、この案は複数検討するものとする。

これにより「イ機能要件の定義」及び「ウ非機能要件の定義」に影響を及ぼす場合は、これらを更新すること(7)。

また、導入するクラウドサービスやパッケージ製品を「システム方式」として先に定め、「ア業務要件の定義」、「イ機能要件の定義」及び「ウ非機能要件の定義」を検討することもできる(8)。ただし、システム方式を詳細に指定しすぎると事業者からより良い提案を受けられなくなるおそれもあるため、記載の粒度について配慮すること(9)。

１. 趣旨

要件定義書は、後工程である設計・開発、各種テストの入力情報のみならず、運用開始後における継続的なサービス・業務改善活動の基礎情報としても利用され、継続的に維持される。

要件定義書の内容に曖昧さや抜け漏れがあると、後工程で実施される作業や作成される成果物に影響を与え、提供するサービス・業務の内容・質を低下させ、プロジェクトの目的・目標の達成を阻害することになりかねない。

このため、本項で定める各項目に従って内容を定義することにより、後工程に必要となる情報を網羅しつつ、プロジェクト全体への影響を考慮しながら、各項目の定義を調整し、確定するものとする。

なお、パッケージ製品やクラウドサービスの適用を前提としているときは、パッケージ製品やクラウドサービスの適用を意識しながら、各項目を定義する。

また、既存システムを改修する場合、要件定義書は、当該改修に係る内容のみを記載した要件定義書を作成するのではなく、必ず、既存の要件定義書を追加・修正の上、該当ページを差替える等、要件定義書の全体の整合性を保った状態で最新化することが必要である。

２. 解説

「なお、定義の時点において、未確定な要件については、それがプロジェクトを進める上でのリスク要因となり得ることに厳に留意し、その旨を要件定義書において明らかにするものとする」

「未確定な要件」とは、ＰＪＭＯが要件定義書を作成するときに、確定するために必要な判断材料が未確定なために、その時点では決定できない要件を指す。

例として挙げると、関連法案が審議中である場合や、要件に影響がある他のサービス･業務企画内容がやむを得ない理由により確定していない場合等、である。

「プロジェクトを進める上でのリスク要因となり得る」とは、「未確定な要件」の内容が確定しないまま、事業者が情報システムの設計・開発を行ったときに、その要件が確定した際、契約変更を伴う委託内容の変更が発生する可能性があることを指す。

「その旨を要件定義書において明らかにする」とは、やむを得ず内容の確定が困難な要件が発生したときは、その対象と理由を要件定義書において明示することを指す。

既存の情報システムを更改又は改修する場合

要件定義書の各項目は、既存業務・情報システムの要件定義書を基に情報の追加・変更をすることが効率的である。さらに、既存の要件の変更であるか、新規の要件の追加であるかを明確にすることは、後工程において事業者との認識そごを予防する上で重要である。

業務要件の定義

ＰＪＭＯは、「第４章５．業務要件の定義」により検討した内容を引継ぎ、業務要件とし、他の要件等との不整合がある場合は更新した上で、定義を確定する。

「なお、当該要件は、「第４章５．業務要件の定義」により検討した内容を基に、他の要件等との整合性を確認し、更新するものとする」

「他の要件等との整合性を確認し」とは、「イ機能要件の定義」、「ウ非機能要件の定義」、「エシステム方式の決定」の結果に伴う見直しや、「１．1) ＲＦＩの実施」や「１．2) 事業者へのヒアリング等の実施」で得た情報を基に、情報システム化への実現方式の難易度や費用から、業務要件の見直しを行うことを指す。

また、パッケージ製品やクラウドサービス（SaaS/PaaS/IaaS）の適用を前提としているときは、パッケージ製品やクラウドサービス（SaaS/PaaS/IaaS）の最新版における情報と、「第４章５．業務要件の定義」で検討した際にインプットとした情報を比較して、内容の差異を確認する。

なお、この段階において、プロジェクト計画に影響を与える内容が明らかになったときには、ＰＪＭＯはＰＭＯに相談し、サービス・業務企画の方向性の変更も含めて検討するものとする。

機能要件の定義

機能要件は、「ア業務要件の定義」で定義した業務要件を実現するために情報システムに求められる要件を定義するものである。

このため、ＰＪＭＯは業務実施部門と連携し、業務要件の内容と情報システム化対象範囲を正しく理解し、情報システムが実装する機能を整理し、機能要件として定義する。

機能要件では、業務要件で定義した利用者による情報システムの使い方を、画面、帳票、データ、処理内容等に具体化して、定義する。

なお、ＰＪＭＯは業務実施部門と連携し、利用者の利便性への寄与、提供するサービスの質や業務効率の向上等の観点を意識し、検討対象となる機能に優先度を付け、対象機能を選択し、定義することに留意する。

「機能要件は、「デジタル社会の実現に向けた重点計画」に掲げる「デジタル３原則（①デジタルファースト：個々の手続・サービスが一貫してデジタルで完結する、②ワンスオンリー：一度提出した情報は、二度提出することを不要とする、③コネクテッド・ワンストップ：民間サービスを含め、複数の手続・サービスをワンストップで実現する）」を踏まえ、次のa）からe）までに掲げる事項をもって定義する」

デジタル３原則については、デジタル社会の実現に向けた重点計画（令和３年12月24日閣議決定）を参照すること。

機能要件の定義対象事項を示せば、表5-1のとおりである。

表5-1

機能要件定義対象要件と定義内容

「なお、クラウドサービス（SaaS）等が提供する機能を利用する場合には、その利用する機能について記載するものとする」

「クラウドサービス（SaaS）等が提供する機能を利用する場合」とは、ＰＪＭＯが当該情報システムの機能として、クラウドサービス、他の情報システム、ソフトウェア、ツールが提供する機能を利用することを指す。

この際、個別の業務要件に対する適応箇所、不適合箇所を明確にし、サービス・業務企画内容に対する適合度合いが、客観的に理解できるよう記載するものとする。

非機能要件の定義

情報システムが稼働するためには、ＰＪＭＯは、「イ機能要件の定義」で定義した要件だけではなく、稼働環境やサービス・業務を円滑に開始するためのユーザ教育等、情報システムを稼働・運用する上で必要となる機能以外の要件も検討し、定義する必要がある。

これを非機能要件と呼び、この内容について、次のa）からr）までに掲げる事項をもって定義する。

「非機能要件について、次のa）からr）までに掲げる事項をもって定義する」

非機能要件の定義対象事項を示せば、表5-2のとおりである。

表5-2

非機能要件定義対象要件と定義内容

「さらに、原則としてクラウドサービスの活用も検討するものとする」

「原則としてクラウドサービスの活用も検討する」とは、非機能要件として定義する複数の項目において、クラウドサービス（SaaS/PaaS/IaaS）が利用可能かを検討することを指す。また、標準でＡＰＩが提供されるクラウドサービスの活用を検討し、機能要件との整合を取り、必要な非機能要件を定義する。

システム方式の決定

「イ機能要件の定義」及び「ウ非機能要件の定義」の定義結果から、整備対象の情報システムに対する要件が明らかになるが、様々な技術要素の組み合わせにより、最終的な情報システムの全体像は複数の実現案が考えられることがある。

このため、複数の実現案が考えられる場合は、メリット・デメリットを考慮し、とり得る実現案を数案に絞り記載する。

なお、予算要求時に作成した情報システムの構成に係る全体の方針及び構成図等も、併せて更新するものとする。

「これにより「イ機能要件の定義」及び「ウ非機能要件の定義」に影響を及ぼす場合は、これらを更新すること」

「これにより「イ機能要件の定義」及び「ウ非機能要件の定義」に影響を及ぼす場合は、こちらも更新させること」とは、ＰＪＭＯが情報システムの実現案を確定する際に、「イ機能要件の定義」及び「ウ非機能要件の定義」の関連項目の内容を変更し、整合性を担保することを指す。なお、情報システムの実現案が複数存在するために、関連する機能要件及び非機能要件が確定できないときは、該当する要件とその理由を明確にすることが重要である。

「導入するクラウドサービスやパッケージ製品を「システム方式」として先に定め、「ア業務要件の定義」、「イ機能要件の定義」及び「ウ非機能要件の定義」を検討することもできる」

「導入するクラウドサービスやパッケージ製品を「システム方式」として先に定め」とは、要件定義を行う前にサービス・業務を実現する具体的な手段としてクラウドサービスやパッケージ製品が特定されていることを指す。

この場合、クラウドサービスやパッケージ製品が提供する機能や利用方法等に合わせて、業務要件、機能要件及び非機能要件を検討することになる。

「システム方式を詳細に指定しすぎると事業者からより良い提案を受けられなくなるおそれもあるため、記載の粒度について配慮すること」

「システム方式を詳細に指定しすぎると事業者からより良い提案を受けられなくなるおそれもあるため、記載の粒度について配慮すること」とは、発注者は、事業者から実現方式について提案を受けられるよう、製品やサービスを限定しない程度に要件を整理し、事業者から提案を受けたい部分を明示することを指す。

なお、やむを得ず発注者から具体的に実現方式を示す場合においても、一例として示すにとどめ、事業者がより良い提案をできるよう記載の粒度について配慮することが望ましい。

要件定義書の調整・作成

ＰＪＭＯは、要件定義書を、関係機関、情報システムの利用者等と調整し、作成するものとする。なお、他のＰＪＭＯが実施するプロジェクトと相互に密接に関係する場合には、それぞれのプロジェクトにおける要件定義書間の整合性が確保されるよう調整するものとする。

なお、ＰＭＯが指定したプロジェクトに係る要件定義に対して第一次工程レビュー及び第二次工程レビューが実施されることについては、「第６章２．3) 第一次工程レビューの実施」及び「第７章３．第二次工程レビューの実施」参照。

また、ＰＪＭＯは、要件定義の調整後に内容を変更する必要が生じたときは、関係機関等との再調整を行った上で変更内容を要件定義書に反映するものとする(1)。

ＰＪＭＯは、この要件定義書が、次工程以降及び後続のプロジェクトにおいても、引き続き使用されることに留意する。

１. 趣旨

提供するサービス・業務が他のサービス・業務・情報システムと連携する場合に、ＰＪＭＯが関係者への情報共有等を疎かにすると、サービス・業務が成立せず、プロジェクトの目的・目標が達成しないおそれがある。

このため、ＰＪＭＯは、連携するサービス・業務・情報システムを把握し、関係者に情報を提供し、調整をする必要がある。

特に、地方公共団体や独立行政法人等の府省以外を含む関係機関との調整が必要な場合は、十分な情報共有と調整をすることが必要である。

このため、ＰＪＭＯは、関係機関との検討会議や説明会等を実施し、その結果を踏まえて要件定義書を調整し、作成する。

また、当該プロジェクトが、ＰＭＯが指定したプロジェクトのときは、第一次工程レビュー及び第二次工程レビューを実施し、要件定義書の内容がプロジェクト目的・目標達成に向け妥当であるか確認するものとする。

要件定義を事業者へ外部委託する場合

ステークホルダーとの調整はＰＪＭＯが実施し、事業者には決定事項を伝達する。事業者は要件定義書への反映作業を担当するものとする。

２. 解説

「また、ＰＪＭＯは、要件定義の調整後に内容を変更する必要が生じたときは、関係機関等との再調整を行った上で変更内容を要件定義書に反映するものとする」

「要件定義の調整後に内容を変更する必要が生じたとき」とは、ＰＪＭＯが要件定義の内容を関係機関等と調整した後で、調達後の事業者の決定に伴い当該事業者の提案内容を採用した結果、要件定義書の内容に変更が必要と判断した場合や、設計・開発工程において事業者が検討の過程で要件定義書の内容の変更を申し出、ＰＪＭＯが了承した場合等を指す。

ＰＪＭＯが要件定義書の内容の変更が必要と判断したときは、それまでに決定された情報と変更する該当箇所との整合性を保ち、更新する必要がある。

なお、変更に当たっては、プロジェクト管理要領の変更管理の管理手順に従って、確認、承認を得る必要がある。

プロジェクト計画書の段階的な改定

プロジェクト推進責任者は、適時、プロジェクト計画書を段階的詳細化し、当該計画書の内容を更新する(1)。

１. 趣旨

要件定義書の作成に伴い、プロジェクト計画書で定義した内容も具体化・詳細化されるため、その内容については、ＰＪＭＯがプロジェクト計画書に反映させ、関係者に周知する必要がある。

なお、プロジェクト計画書の各項目に大幅な変更が発生する可能性があったときは、ＰＪＭＯはプロジェクト計画の軌道修正も含めて検討する。

プロジェクト計画書への反映については、標準ガイドライン解説書「第３編第２章プロジェクトの管理」を参照すること。

２. 解説

「適時、プロジェクト計画書を段階的詳細化し、当該計画書の内容を更新する」

「適時、プロジェクト計画書を段階的詳細化し」とは、ＰＪＭＯがプロジェクト計画書を最新の状態に保つために、要件定義書の内容が変更されたときは、その変更内容に応じて、プロジェクト計画書への反映を行うことを指す。

デジタル社会推進実践ガイドブック DS-110

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

（第３編第６章調達）

2025年（令和７年）5月27日

デジタル庁

改定履歴

[１. 調達の計画 3](#調達の計画)

[1）合理的な調達単位の検討 5](#合理的な調達単位の検討)

[2）調達の方式の検討 8](#調達の方式の検討)

[２. 調達仕様書の作成等 13](#調達仕様書の作成等)

[1）調達仕様書の記載内容 14](#調達仕様書の記載内容)

[2）契約書の記載事項 28](#契約書の記載事項)

[3）第一次工程レビューの実施 29](#第一次工程レビューの実施)

[4）意見招請の実施 30](#意見招請の実施)

[３. ＲＦＰ・公告 32](#ｒｆｐ公告)

[1）提案依頼書の作成等 33](#提案依頼書の作成等)

[2）調達に関する公告 37](#調達に関する公告)

[４. 審査 38](#審査)

[５. 入開札 40](#入開札)

[６. 契約 42](#契約)

[７. 検収 44](#検収)

[８. プロジェクト計画書の段階的な改定 45](#プロジェクト計画書の段階的な改定)

第５章 要件定義