第５章 要件定義
目次
第５章 要件定義
ＰＪＭＯは、「第４章 サービス・業務企画」で策定した業務要件を踏まえ、これを実現するための情報システムに求める要件（以下「情報システム要件」という。）として、情報システムの機能を定めた要件（以下「機能要件」という。）及び情報システムが備えるべき機能要件以外の情報システム要件（以下「非機能要件」という。）を明らかにするため、調達に先立ち、次のとおり、要件定義を行うものとする。 要件定義は、プロジェクトの目標を達成する上で、極めて重要な工程であり、 要件定義が不十分なときには、計画の遅延又は情報システムの機能・性能が要求水準に満たないものとなる事態等が発生する可能性が高まるため、適切に実施する必要がある (1) 。 |
１. はじめに
利用者の価値を最大化するサービス・業務企画を具現化し、政策目的及びプロジェクトの目標を達成するためには、情報システムに求める要件を漏れなく具体化し、意図を正しく事業者に伝えることにより情報システムの設計・開発、運用を滞りなく進められるよう準備する必要がある。
このため、要件定義では、サービス・業務企画内容を踏まえて、費用対効果等を勘案しながら、情報システムが備えるべき機能・性能等を明らかにするものとする。
また、要件定義のアウトプットである要件定義書は、後続の工程においてＰＪＭＯと事業者が業務や情報システムの目指すべき姿を共有するだけではなく、契約上の合意文書となる重要なものである。誤りや曖昧な定義が行われると、後続の工程に重大な影響を与えることから、適切な手順で確実に検討を進める必要がある。
要件定義は、情報システムの整備対象となるサービス・業務企画内容の規模と難易度から、ＰＪＭＯが実施する場合と、事業者に外部委託する場合が想定され、その進め方が異なる。本解説書では、ガイドラインで示される事項について網羅的に解説するため、ＰＪＭＯが要件定義を行う場合を主として解説するとともに、事業者に外部委託する場合の注意事項等を、場合分けとして記載する。
２. 解説（1）「要件定義が不十分なときには、計画の遅延又は情報システムの機能・性能が要求水準に満たないものとなる事態等が発生する可能性が高まるため、適切に実施する必要がある」
「計画の遅延又は情報システムの機能・性能が要求水準に満たないものとなる事態等」とは、ＰＪＭＯが行った要件定義が不十分で、内容に抜け漏れ・曖昧さが存在することにより発生する事態を指す。その例を次に示す。
・ 計画の遅延やそれに伴う新たなサービス・業務の開始時期の遅延
・ 予算要求額を超える開発規模となったことによる予算額の不足
・ 更なるステークホルダーとの調整作業の発生やそれに伴う要件の追加・変更
・ 情報システムの機能・品質が要求水準を満たさないために、サービス・業務の質が下がり、プロジェクトの目的・目標が達成できない
１. 要件定義の準備
ＰＪＭＯは、要件定義に先立ち、次のとおり行うものとする。 |
１. 趣旨
情報システムの要件定義は、世の中の技術動向やサービスの動向、各種事例、要件を実現する方式に関する情報等を踏まえて実施する必要がある。必要な情報を入手しないまま要件定義を行ったときには、費用対効果に優れた手法の採用漏れや、優れた先進事例を取り込むことができない等のリスクが発生することとなる。
したがって、要件定義に先立ち、これらの情報を収集する必要があるが、多岐にわたる情報をＰＪＭＯの知識や経験のみで網羅的かつ詳細に把握することは困難である。
このため、ＰＪＭＯは、ＲＦＩ及び事業者へのヒアリング等により、要件定義の前提となる情報を広く収集し、要件定義で十分な検討が行えるように準備する。
1） ＲＦＩの実施
ＰＪＭＯは、要件定義の検討に際し、専門的な知見を広く取得するため、必要に応じてＲＦＩを実施し(1)、次の[1]から[4]までに掲げる事項を記載した説明書を作成するものとする (2)。 [1] 調達の概要 (3) [2] その時点における検討内容、要件定義案の概要等 (4) [3] 資料提供を求める内容等 (5) [4] 提出期限、提出場所、提出方法、提出資料における知的財産の取扱い等 (6) なお、このうち[3]については、要件定義案の実現性、実現方法、それらの要件を実現するために必要な経費の見込み、要件定義案への修正事項（開発方式（クラウドサービスの活用、ソフトウェア製品の活用、スクラッチ開発等）、開発手法（ウォータフォール型開発、アジャイル型開発等））等、事業者に具体的に求める内容について記載するものとする。 なお、原則としてクラウドサービスの利用を前提とした実現方式の情報も取得すること。 |
１. 趣旨
要件定義に必要となる専門的な知見は、その内容に応じて偏りなく幅広く収集する必要がある。
このため、ＰＪＭＯは、市場調査や資料提供の要請を行うときには、その内容に応じて公平性を確保し、ＲＦＩ等を通じて情報の収集を行う。
なお、ＲＦＩは、プロジェクトの規模を考慮して、準備着手の時期を判断する。
２. 解説（1）「専門的な知見を広く取得するため、必要に応じてＲＦＩを実施し」
「専門的な知見」とは、ＰＪＭＯが要件定義を行うに当り、ＰＪＭＯのみでは補完できない情報である。その例を次に示す。
[1] 市場にあるサービスの種類及びその最新動向
[2] 海外や国内の類似事例とその教訓
[3] 新たな技術の動向や製品のライフサイクル
[4] 想定する要件を実現する方式とその実現可能度や制約事項
[5] 概算の予算規模
[6] 大まかな工程やスケジュール
[7] 著作権や法的な制約
[8] 実現に際してのリスク 等
「ＲＦＩを実施し」とは、ＰＪＭＯがサービス・業務企画の実現可能性や整備する情報システムに係る有用な情報を得るために、ＲＦＩに係る説明書を作成し、ＲＦＩの実施について通知を行い、情報を収集することである。
ＲＦＩの実施を通知するに当たり、広く不特定多数からの情報を求めるときには、府省Ｗｅｂサイト上で公開する等の手法があるが、必要な情報を確実に得るためには、事業者団体への通知やプレス発表等によって積極的にアナウンスすることも効果的である。
なお、ＲＦＩにおける事業者の回答内容が期待した水準に満たない場合や、回答内容の確認のために追加の情報提供を求める必要が生じた場合等には、ＰＪＭＯは、事業者に対して個別ヒアリング等を行い、不明点や情報が不足する点等を解消・補強する必要があることに留意する。
なお、機密性の高い情報を、事業者に対し提供する必要がある場合は、ＰＪＭＯはあらかじめ守秘義務の誓約書を事業者に求め、当該誓約書の提出があった事業者にのみ機密性の高い情報を提供する。
（2）「次の[1]から[4]までに掲げる事項を記載した説明書を作成する」
「説明書を作成する」とは、ＰＪＭＯが、事業者から必要な情報を適切に収集するために、ＲＦＩに先立ち、プロジェクト内容を正確に伝達するための説明書を作成することを指す。ＰＪＭＯは、事業者に政策目的、プロジェクトの目的・目標及びサービス・業務企画内容等を正確に伝えられるよう、十分な準備を行う必要がある。
（3）「[1] 調達の概要」
「調達の概要」とは、ＰＪＭＯが調達計画を明らかにするために、当該プロジェクトの調達計画の全体像と本調達が対象とする範囲を提示することである。
（4）「[2] その時点における検討内容、要件定義案の概要等」
「検討内容、要件定義案の概要等」とは、ＰＪＭＯがＲＦＩを実施する時点で、前提として既に定まっている事項や、検討の過程で整理した案の概要等を指す。要件定義の開始前時点では、プロジェクトの計画及び進行によっては、確定していない内容が存在する可能性もあるが、要件として求める方向性等があれば、それを記載することが望ましい。
（5）「[3] 資料提供を求める内容等」
「資料提供を求める内容等」とは、ＲＦＩにて提供を要請する情報の内容、その内容に含むべき事項等を整理し明確に定義したものである。プロジェクトで提供するサービス・業務を実現する具体的な方式、適合可能な技術、調達単位のあり方等に関する情報、実現に向けての大まかなスケジュール等の意見を求め、プロジェクトの実現可能性を高めることが重要である。
また、要件定義を有効に進めるために、未検討や未確定の事項についても、幅広く事例や動向等に関する資料の提供を求めることが有効である。
なお、パッケージ製品やクラウドサービスの適用を前提とするときは、ベンダに対して提供可能な範囲の業務要件定義資料を提供し、ベンダによる適合性調査（Fit&Gap）を依頼するだけでなく、パッケージ製品等のデモに職員が参加して機能の確認を行う、ベンダへのヒアリングを実施する、パッケージ製品やクラウドサービスの最新情報（非機能要件や標準・オプションの価格等も含む）を入手する等、実際に適合することを職員がチェックすることが重要である。
（6）「[4] 提出期限、提出場所、提出方法、提出資料における知的財産の取扱い等」
「提出期限、提出場所、提出方法、提出資料における知的財産の取扱い等」とは、提出に係る取り決めを定めた内容であり、その例を次に示す。
・ 情報の提出期限や提出先、その方法
・ 提出する資料に事業者のノウハウや機密事項が含まれる場合のその情報に関する制約事項
・ 守秘義務の誓約書の提出要請
得られた情報に知的財産の制約がある場合、要件定義書等にそのまま用いることができないときがあるため、事業者に対して、公開済みで活用できる情報と、機密等を伴う情報とを区別できるような情報の明記を求める等の工夫も有用である。
2） 事業者へのヒアリング等の実施
ＰＪＭＯは、有用な情報を得られるよう、公平性・競争性を確保した上で、事業者に対し説明会・個別ヒアリング等を逐次行い (1)、取得した情報を精査し、活用するものとする。 |
１. 趣旨
ＲＦＩにより、必要な情報を広く収集することができるが、ＰＪＭＯの意図が伝わらない場合、必要な情報が得られない、情報の粒度が異なる、誤った情報が提供されるといった事態が発生するおそれがある。
そのため、ＰＪＭＯが、事業者に対して、情報システムに求める要件を直接説明し、実現可能性等について意見交換をする機会として説明会やヒアリング等を実施することは、要件定義の内容をより精緻化し、設計開発工程以降での手戻りを防ぐ上で有効である。
なお、説明会・個別ヒアリング等では、公平性と無差別性を確保するため、ＲＦＩと同様の方法で、実施について通知を行い、得られた情報については、議事録に記載する等の方法により、ＲＦＩの事業者回答と同様に取り扱うことが望ましい。
２. 解説1）「事業者に対し説明会・個別ヒアリング等を逐次行い」
「説明会・個別ヒアリング等」とは、ＰＪＭＯが、事業者に対して、情報システムに求める要件を直接説明し、実現可能性等について意見交換をする機会を指す。これらは要件定義を開始する前のみならず、要件定義の実施中に情報が必要となった場合においても、適宜活用することが可能である。
なお、ヒアリングには、既存業務システムの仕組みを理解し、業務要件を正しく伝えられる職員の参加が望ましい。
なお、機密性の高い情報を、事業者に対し提供する必要がある場合は、ＰＪＭＯはあらかじめ守秘義務の誓約書を事業者に求め、当該誓約書の提出があった事業者にのみ機密性が高い情報を提供する。
3） 必要な資料の作成
ＰＪＭＯは、「第４章５．業務要件の定義」において作成した資料のほか、要件定義に際し、必要な資料を作成するものとする。なお、 既存資料を活用する場合には、現状の検討状況が適切に反映されていることを確認し、変更がある場合には更新するものとする (1) 。 |
１. 趣旨
ＲＦＩ又は事業者に対する個別ヒアリング等で得られた情報は、要件定義や後の工程で適切に活用する必要がある。
このため、ＰＪＭＯは、サービス・業務企画で収集した情報、業務要件定義の内容とともに、ＲＦＩ又は事業者に対する個別ヒアリング等の実施結果、及び、その結果を分析した内容について整理した資料を作成する。
２. 解説（1）「既存資料を活用する場合には、現状の検討状況が適切に反映されていることを確認し、変更がある場合には更新するものとする」
「既存資料を活用する」とは、既存の業務及び情報システムの資料を活用することである。「第４章２．現状の把握と分析」にて収集した資料が活用可能であれば、それらを用いてもよいが、これら既存システムに係る各種ドキュメントが最新の状態になっているかを確認することが重要である。また、この確認作業を通じて、職員の既存システムに関する知識の向上も期待できる。
なお、業務や情報システムの内容は運用期間中に変更や追加が行われることが多いため、要件定義に当たって正確な情報を収集するには、現行情報システム運用事業者や現行情報システム保守事業者より、最新化された資料を入手する。
ＲＦＩの実施結果については、情報の網羅性や粒度について確認を行うとともに、複数の情報間での整合性についても評価を行う。プロジェクトの実行可能性の考え方に影響を与える情報が得られた場合は、所要の見直しを行う。
２. 要件定義
ＰＪＭＯは、次のとおり、業務要件、機能要件、非機能要件及び情報システムの実現案を具体的に定義し、これらを記載した要件定義書を作成するものとする。なお、作成に当たっては、「第４章 サービス・業務企画」において収集・作成した情報を基に定義することとし、要求する情報システムの特徴を踏まえ、記載内容の軽重を検討するものとする。また、定義した具体的な内容について、その必要性、網羅性、具体性、定量性、整合性、中立性及び役割分担の明確性の観点、さらに情報セキュリティ等の観点から、その実現可能性があることを確認するものとする。 なお、機能要件、非機能要件及び情報システムの実現案についても、情報システム部門のみで決定するものではなく、制度所管部門、業務実施部門を含めたPJMO全体で決定することが不可欠であることに留意すること。 また、検討に当たっては、ＰＭＯや府省ＣＩＯ補佐官等の支援や助言を受けることが望ましい (1)。 |
１. 趣旨
要件定義で定める業務要件、機能要件、非機能要件は、多くの関係者と共有し、内容を合意する必要があり、後工程の作業を実施する際の元情報としても活用される。
このため、ＰＪＭＯは、これら要件を、網羅的かつ詳細に検討した上で、関係者が共有可能な文書として整備する必要がある。さらに、様々な要件を統合し、情報システム全体構成の実現案を作成することで、要件の抜け漏れを無くし、実現性の高い情報システムの全体像を明らかにする必要がある。
要件定義を事業者へ外部委託する場合 要件定義を事業者に委託するかどうかにかかわらず、ＰＪＭＯは要件定義内容の決定について責任を持つ必要がある。ただし、その決定に至るまでの進め方については、次の点に留意する。 ・ 業務要件は、「第４章 サービス・業務企画」で決定した内容を基に業務に必要な要件を検討し、内容を確定するものである。その際、事業者が作成する各項目の定義内容について、ＰＪＭＯは全ての内容に目を通し、理解する必要がある。 ・ 機能・非機能要件は、業務要件を基に、情報システムに必要とされる要件を検討し、内容を確定するものである。その内容には、専門的なものが含まれるため、ＰＪＭＯが全ての内容を理解することが困難な場合がある。そのため、ＰＪＭＯは内容について理解できるように事業者に説明を求める必要がある。 なお、全ての要件について、サービス・業務企画を実現する上での重要性を事業者が判断することは困難であるため、ＰＪＭＯと業務実施部門が中心となって要件の重要度を決めるとともに、要件を実現する際の難易度について事業者に情報を求め、重要度と難易度を基に、要件の優先度を調整する必要がある。 |
２. 解説
（1）「検討に当たっては、ＰＭＯや府省ＣＩＯ補佐官等の支援や助言を受けることが望ましい」
「府省ＣＩＯ補佐官等」とは、自府省を担当するＣＩＯ補佐官以外に、他府省のＣＩＯ補佐官、外部組織の有識者や専門的な知見を持つ職員を含むことを指す。
1） 要件定義書の記載内容
要件定義書には、業務要件、機能要件、非機能要件及び情報システムの実現案を明らかにするため、原則として、次のアからエまでに掲げる事項について記載するものとする。 なお、定義の時点において、未確定な要件については、それがプロジェクトを進める上でのリスク要因となり得ることに厳に留意し、その旨を要件定義書において明らかにするものとする (1) 。 ア 業務要件の定義 業務要件は、情報システムを活用した業務の内容を定義する。 なお、当該要件は、「第４章５．業務要件の定義」により検討した内容を基に、他の要件等との整合性を確認し、更新するものとする (2) 。 イ 機能要件の定義 機能要件は、「デジタル・ガバメント実行計画」に掲げる「デジタル３原則（①デジタルファースト：個々の手続・サービスが一貫してデジタルで完結する、②ワンスオンリー：一度提出した情報は、二度提出することを不要とする、③コネクテッド・ワンストップ：民間サービスを含め、複数の手続・サービスをワンストップで実現する）」を踏まえについて、次のa）からf）までに掲げる事項をもって定義する (3) 。なお、機能要件は、業務の質の向上、業務の効率化等に対する有効性等を踏まえ、優先度の高い機能から整備する必要があること、また、他の情報システムと連携する場合には相互運用性及びデータ互換性についても併せて記載する必要があることに留意するものとする。 なお、クラウドサービス（SaaS）、府省共通システム等が提供する機能を利用する場合には、その利用する機能について記載するものとする (4) 。 ウ 非機能要件の定義 非機能要件について、次のa）からq）までに掲げる事項をもって定義する (5) 。定義の内容は、業務・情報システム両面で必要な要件を、網羅するものとする。なお、非機能要件は、技術的に検討を要する事項を多分に含むことから、日本産業規格等のほか、ＲＦＩ等を通じて、広く情報を取得し、実現性等の検証を行うものとする。 また、府省共通システムが提供する稼働環境を利用するときには、その仕様について記載するものとする。 さらに、原則としてクラウドサービスの活用も検討するものとする (5) 。 エ システム方式の決定 情報システムの実現案として、「ウb) システム方式に関する事項」で検討した内容を他の要件の内容と調整し、決定する。なお、この案は複数検討するものとする。 これにより「イ 機能要件の定義」及び「ウ 非機能要件の定義」に影響を及ぼす場合は、これらを更新すること (7) 。 また、 導入するクラウドサービスやパッケージ製品を「システム方式」として先に定め、「ア 業務要件の定義」、「イ 機能要件の定義」及び「ウ 非機能要件の定義」を検討することもできる(8) 。 |
１. 趣旨
要件定義書は、後工程である設計・開発、各種テストの入力情報のみならず、運用開始後における継続的なサービス・業務改善活動の基礎情報としても利用され、継続的に維持される。
要件定義書の内容に曖昧さや抜け漏れがあると、後工程で実施される作業や作成される成果物に影響を与え、提供するサービス・業務の内容・質を低下させ、プロジェクトの目的・目標の達成を阻害することになりかねない。
このため、本項で定める各項目に従って内容を定義することにより、後工程に必要となる情報を網羅しつつ、プロジェクト全体への影響を考慮しながら、各項目の定義を調整し、確定するものとする。
なお、パッケージ製品やクラウドサービスの適用を前提としているときは、パッケージ製品やクラウドサービスの適用を意識しながら、各項目を定義する。
また、既存システムを改修する場合、要件定義書は、当該改修に係る内容のみを記載した要件定義書を作成するのではなく、必ず、既存の要件定義書を追加・修正の上、該当ページを差替える等、要件定義書の全体の整合性を保った状態で最新化することが必要である。
２. 解説（1）「なお、定義の時点において、未確定な要件については、それがプロジェクトを進める上でのリスク要因となり得ることに厳に留意し、その旨を要件定義書において明らかにするものとする」
「未確定な要件」とは、ＰＪＭＯが要件定義書を作成するときに、確定するために必要な判断材料が未確定なために、その時点では決定できない要件を指す。
例として挙げると、関連法案が審議中である場合や、要件に影響がある他のサービス･業務企画内容がやむを得ない理由により確定していない場合等、である。
「プロジェクトを進める上でのリスク要因となり得る」とは、「未確定な要件」の内容が確定しないまま、事業者が情報システムの設計・開発を行ったときに、その要件が確定した際、契約変更を伴う委託内容の変更が発生する可能性があることを指す。
「その旨を要件定義書において明らかにする」とは、やむを得ず内容の確定が困難な要件が発生したときは、その対象と理由を要件定義書において明示することを指す。
既存の情報システムを更改又は改修する場合 要件定義書の各項目は、既存業務・情報システムの要件定義書を基に情報の追加・変更をすることが効率的である。さらに、既存の要件の変更であるか、新規の要件の追加であるかを明確にすることは、後工程において事業者との認識齟齬を予防する上で重要である。 |
ア 業務要件の定義
ＰＪＭＯは、「第４章５．業務要件の定義」により検討した内容を引継ぎ、業務要件とし、他の要件等との不整合がある場合は更新した上で、定義を確定する。
（2）「なお、当該要件は、「第４章５．業務要件の定義」により検討した内容を基に、他の要件等との整合性を確認し、更新するものとする」
「他の要件等との整合性を確認し」とは、「イ 機能要件の定義」、「ウ 非機能要件の定義」、「エ システム方式の決定」の結果に伴う見直しや、「１．1) ＲＦＩの実施」や「１．2) 事業者へのヒアリング等の実施」で得た情報を基に、情報システム化への実現方式の難易度や費用から、業務要件の見直しを行うことを指す。
また、パッケージ製品やクラウドサービス（SaaS/PaaS/IaaS）の適用を前提としているときは、パッケージ製品やクラウドサービス（SaaS/PaaS/IaaS）の最新版における情報と、「第４章５．業務要件の定義」で検討した際にインプットとした情報を比較して、内容の差異を確認する。
なお、この段階において、プロジェクト計画に影響を与える内容が明らかになったときには、ＰＪＭＯはＰＭＯに相談し、サービス・業務企画の方向性の変更も含めて検討するものとする。
イ 機能要件の定義
機能要件は、「ア 業務要件の定義」で定義した業務要件を実現するために情報システムに求められる要件を定義するものである。
このため、ＰＪＭＯは業務実施部門と連携し、業務要件の内容と情報システム化対象範囲を正しく理解し、情報システムが実装する機能を整理し、機能要件として定義する。
機能要件では、業務要件で定義した利用者による情報システムの使い方を、画面、帳票、処理内容等に具体化して、定義する。
なお、ＰＪＭＯは業務実施部門と連携し、利用者の利便性への寄与、提供するサービスの質や業務効率の向上等の観点を意識し、検討対象となる機能に優先度を付け、対象機能を選択し、定義することに留意する。
（3）「機能要件は、「デジタル・ガバメント実行計画」に掲げる「デジタル３原則（①デジタルファースト：個々の手続・サービスが一貫してデジタルで完結する、②ワンスオンリー：一度提出した情報は、二度提出することを不要とする、③コネクテッド・ワンストップ：民間サービスを含め、複数の手続・サービスをワンストップで実現する）」を踏まえ、次のa）からf）までに掲げる事項をもって定義する」
デジタル三原則については、標準ガイドライン解説書「第３編第４章 サービス・業務企画 １. 心構えと視点」を参照すること。
機能要件の定義対象事項を示せば、表5-1のとおりである。
定義する事項 |
記載事項 |
内容 |
|---|---|---|
| a) 機能に関する事項 | 情報システムにおいて備える機能について、処理内容、入出力情報・方法、入力・出力の関係等を記載する。なお、他の情報システムが類似の機能を持つ場合は、その機能を活用することも検討する。 | 業務要件を実現するために必要な情報システムの処理に関する事項を明らかにする。 機能要件定義として整理した機能の一覧は、パッケージ製品やクラウドサービス（SaaS）との適合性確認を行う際に、比較検討の基となる情報として利用することもあるため、機能単位で優先度を明確にすることが重要である。あらかじめ想定していた要求の全てを担保することを必須とすると、利用できるサービスの選択肢が限られたものとなるほか、カスタマイズ等の費用が上乗せされることとなるおそれがある。他方、優先順位の低い一部の要望を任意の提案事項とすることで、サービスの選択肢の幅が広がる、カスタマイズ等が不要となる等、パッケージ製品やクラウドサービス（SaaS）本来のメリットを最大限活かした案件形成が可能となる可能性があることに留意し、実現する機能の決定に際しては、想定する要件を必須事項と任意事項に分け、任意事項についても優先順位を付けた上で、RFI等を通じて情報収集を行い、事業者から幅広い選択肢について提案を得られるように配慮すること。 |
| b) 画面に関する事項 | 情報システムにおいて表示される画面について、画面の概要や表示イメージ、画面の遷移や入出力の基本的考え方等を記載する。 | 画面の説明やデザイン、画面の遷移等、標準的な画面に求められる構成要素（項目、ボタン等）の要件を明らかにする。 また、画面を構成する項目やボタンの配置ルール、画面の基本的な遷移パターン等、画面の設計に係る方針も明らかにする。 なお、機能要件定義では、当該システムの画面に関する全体方針及び現時点における個別画面の構成要素を定義するものとし、個別画面の詳細な項目定義や構成要素の配置は、「第７章 設計・開発」で確定する。 また、情報システムの画面は、業務を流れに沿って処理する上で重要な役割を担うものであり、業務効率や利用者満足度に関わるほか、適切なアクセス権限の設定単位に関わる事項のため、業務実施部門が中心となって検討することが必要である。 |
| c) 帳票に関する事項 | 情報システムにおいて入出力される帳票について、帳票の概要や表示イメージ、帳票の入出力の基本的な考え方等を記載する。なお、業務のデジタル化を前提に、帳票は最小限にすることが望ましい。 | 帳票の説明やデザイン、種類、様式、標準的な帳票に求められる構成要素（項目、罫線等）の要件を明らかにする。 また、帳票を構成する項目の配置ルール、帳票の印刷方式等、帳票の設計に係る方針も明らかにする。この際、法令で定められた様式やOCR帳等、記載事項やサイズについて厳密な指定がある場合や、逆に要件として示すものは表示イメージに留め、設計において確定することが許容される場合を、それぞれ明記する。 情報システムが提供する帳票は、業務実施手順や業務効率と密接に関わる事項のため、業務実施部門が中心となって検討することが必要である。 (参考:独立行政法人情報処理推進機構 文字情報基盤整備事業に関するＷｅｂサイト http://mojikiban.ipa.go.jp |
| d) ファイルに関する事項 | 情報システムにおいて入出力を行うファイルについて、ファイルの概要や形式、ファイルの入出力の基本的な考え方等を記載する。 | 情報システムへの入力、情報システムからの出力に用いるファイルについて、ファイルの概要、ファイル形式、入出力方法等の要件を明らかにする。 なお、ファイル形式については、業務の一連の流れの中で活用しやすいように、再利用や追加修正が容易な形式となるように留意する。 |
| e) 情報・データに関する事項 | 情報システムにおいて取り扱われる情報・データについて、情報・データの定義や概要、データの格納方針等を記載する。なお、原則として、政府において標準化された情報・データ名称、データ構造等を採用するとともに、各データが当該情報システム内における利用だけでなく、他の情報システムとの連携やオープンデータとしての活用が行われることを前提として、リスク管理を適切に行いつつ品質が維持されるようデータマネジメントに留意すること。 | 情報システムを用いて業務を処理する上で取り扱う情報及び、データベース等で蓄積するデータに係る事項を明らかにする。
情報システムで取り扱う情報・データは、これが業務上の資産であるとの認識に立って、情報システムのライフサイクルを越えた継続的な利用及び完全性、機密性等の考慮について検討が必要である。また、業務要件と密接に関わることから、業務要件及びシステム化の範囲との整合性についても留意する必要がある。 なお、情報システムは外部の情報システムと連携する場合を考慮し、特に外字として扱われる文字の表現と内部コードとの統一について留意する必要がある。 また、データの品質とは、蓄積されたデータの利用に当たっての信頼性につながるものである。精度（データの値に間違いや漏れが無い「正確性」を確保すること）・鮮度（データの反映タイミングや履歴の期間）・粒度（情報システムで取り扱うデータのまとまりと名称）の３つを意識し、それぞれについて当該情報システムに求められる要件を明らかにする。 (参考:独立行政法人情報処理推進機構 文字情報基盤整備事業に関するＷｅｂサイト http://mojikiban.ipa.go.jp |
| f) 外部インタフェースに関する事項 | 整備する情報システムと他の情報システムとの連携（外部インタフェース）について、相手先の情報システム、送受信データ、送受信タイミング、送受信の条件の基本的な考え方等を記載する。 また、外部インタフェースが公開可能なＡＰＩとしての活用が行われることを想定し、標準でＡＰＩが提供されているクラウドサービスの利用を検討するほか、独自に情報システムの設計・開発を行う際にも、標準的なＡＰＩの整備を実施するよう留意すること。 |
当該情報システム以外の情報システムと情報連携を行う際に必要となる、相互運用性及びデータ互換性を確保のために定義すべき事項を明らかにする。 |
表5-1 機能要件定義対象要件と定義内容
（4）「なお、クラウドサービス（SaaS）、府省共通システム等が提供する機能を利用する場合には、その利用する機能について記載するものとする」
「クラウドサービス（SaaS）、府省共通システム等が提供する機能を利用する場合」とは、ＰＪＭＯが当該情報システムの機能として、クラウドサービス、府省共通システム、他の情報システム、ソフトウェア、ツールが提供する機能を利用することを指す。
この際、個別の業務要件に対する適応箇所、不適合箇所を明確にし、サービス・業務企画内容に対する適合度合いが、客観的に理解できるよう記載するものとする。
ウ 非機能要件の定義
情報システムが稼働するためには、ＰＪＭＯは、「イ 機能要件の定義」で定義した要件だけではなく、稼働環境やサービス・業務を円滑に開始するためのユーザ教育等、情報システムを稼働・運用する上で必要となる機能以外の要件も検討し、定義する必要がある。
これを非機能要件と呼び、この内容について、次のa）からq）までに掲げる事項をもって定義する。
（5）「非機能要件について、次のa）からq）までに掲げる事項をもって定義する」
非機能要件の定義対象事項を示せば、表5-2のとおりである。
| 定義する事 | 記載事項 | 内容 |
|---|---|---|
| a) ユーザビリティ及びアクセシビリティに関する事項 | 情報システムの各機能におけるユーザビリティ及びアクセシビリティについて、日本産業規格等を踏まえつつ、情報システムの利用者の種類、特性及び利用において配慮すべき事項等を記載する。 | 利用者から見たサービス・業務を遂行する上での使いやすさを明らかにする。 ユーザビリティとは、利用者が情報システムで実現される機能を用いて、実施したいことを確実かつ効率的に行うための要素であり、利用者の満足度にもつながる非常に重要な事項である。 アクセシビリティとは、情報システムが提供する情報や機能へのアクセスのしやすさを指す。そのためには、利用者の年齢、身体的制約、利用環境等を配慮することが必要とされる。 |
| b) システム方式に関する事項 | クラウドサービス、ハードウェア、ソフトウェア、ネットワーク等の情報システムの構成に関する全体の方針の案について記載する。 | 情報システムを実現するために必要となるクラウドサービス、ハードウェア、ソフトウェア、ネットワーク、稼働環境等を明らかにする。 同一の機能を持つ情報システムであっても、実現の方式は多様であり、それによって調達コストは大きく異なる。システム方式は、情報システム設計の基本的な前提条件であるため、定義時点において明確にできる範囲内で複数の方式を検討し、メリット・デメリットを明らかにすることを推奨する。 |
| c) 規模に関する事項 | 情報システムの規模について、機器数、設置場所、データ量、処理件数、利用者数等を記載する。なお、データ量、利用者数等については、ライフサイクル期間における将来の見込みも記載すること。 | 機器数、保有するデータ量、単位時間当たりの処理件数、利用者数等の情報システムを構成し、規模を特定する要素を定量的に明らかにする。規模は、性能や信頼性に関する要件を検討する際の前提条件となり、機器の仕様や配置等の設計、調達コストに関わる基本的な事項であるため、将来の見込みも含めた上で試算することが重要である。 |
| d) 性能に関する事項 | 情報システムの性能について、応答時間、バッチ処理時間等を記載する。特に、「第４章５．業務要件の定義」において検討した内容に照らし、性能が過度にならないよう適切な要件とすること。 | 規模に係る要件を前提とした情報システムが備えるべき処理能力を明らかにする。 性能は、業務効率や利用者満足度に関わる重要な事項であるが、過度な要件を設定することで調達コストを押し上げることのないよう、業務要件を満たすことを基本として、サービス・業務の実施において必要十分となる要求レベルを検討する必要がある。 |
| e) 信頼性に関する事項 | 情報システムの信頼性について、稼働率等を記載する。特に、「第４章５．業務要件の定義」において検討した内容に照らし、過度にならないよう適切な要件とすること | 情報システムの構成要素の不具合や故障に際しても、情報システムの機能が停止せずに、正常な動作を保ち続ける能力（可用性）と、データの不整合等を回避する能力（完全性）を明らかにする。 なお、障害や大規模災害等により情報システムの機能が停止した場合に、必要最低限の業務を継続及び回復するために必要な情報システムの機能の維持・復旧に係る要件は、「継続性に関する事項」にて定義する。 |
| f) 拡張性に関する事項 | 情報システムの性能及び機能の拡張性要件について記載する。特に、将来の機能改修や、社会情勢の変化、技術の変化、利用状況の変化等に対して、柔軟で効率的な対応を行うことを念頭に、要件を定めること。 | 運用開始後のサービス・業務環境の変化に対応することを目的として、性能や機能をあとから向上させるための要件を明らかにする。 拡張性は将来の調達コストにも関わるため、サービス・業務企画における環境分析に基づいて、定義時点において想定されるサービス・業務の変化を明確にし、要件を定義することが重要である。 |
| g) 上位互換性に関する事項 | 情報システムを構成するＯＳ及びミドルウェア等のバージョンアップ時における情報システムの改修の許容度等を記載する。 | 運用期間中のハードウェア及びミドルウェア等のバージョンアップに対して、運用を継続するために必要となる情報システムの改修の許容度や情報システム構築時の制約を明らかにする。 パッケージ製品のバージョンアップやクラウドサービスのサービス内容と価格体系の将来的な変更についても考慮すること。 なお、上位互換性は、将来の調達コスト、可用性及び情報セキュリティの維持にも関わるため、過去のバージョンアップの頻度や影響等の情報を収集しておくことが効果的である。 |
| h) 中立性に関する事項 | 情報システムの中立性については、いわゆるベンダーロックインの解消等による調達コストの削減、透明性向上等を図るため、市場において容易に取得できるオープンな標準的技術又は製品を用いる等の要件について記載する。なお、技術又は製品について指定する場合には、指定を行う合理的な理由を明記した上で、クラウドサービス、ハードウェア、ソフトウェア製品等の構成を明らかにすること。また、情報システムを利用する端末についても、特定のハードウェア又はソフトウェアに依存しないよう留意すること。 | 情報システムを構成するハードウェア、ミドルウェア及びソフトウェア等がオープンな標準的技術又は製品であること等の制約を明らかにする。 オープンな標準的技術又は製品であるとは、原則として、 (1) 開かれた参画プロセスの下で合意され、具体的仕様が実装可能なレベルで公開されている技術であること (2) 誰もが採用可能であること (3) これら標準的技術が実現された製品が市場に複数あること の全てを満たしている標準的技術又はその標準的技術を採用している製品をいう。 また、技術又は製品について指定する場合の合理的な理由を得るには、特定のプロジェクトに閉じた視点ではなく、影響を与える他のプロジェクトも含めた広い視点で、コスト・セキュリティ・保守性等を考慮する必要がある。 本事項は、いわゆるベンダーロックインの解消等により将来にわたる調達コストの削減、透明性向上等を図るため、特定事業者に不必要に依存した情報システムとならないよう要求する事項である。 なお、デファクトスタンダードとして広く利用されている製品群については、供給を行う事業者において競争性が確保されるものであれば、内部仕様が公開されていなくても中立性の趣旨において問題とならない場合もある。また、特定の事業者に依存する製品であっても、保守や改修、次期更改の際に他の技術又は製品への移行に過大な工数を要しない場合は、当該製品を選択することも可能である。 |
| i) 継続性に関する事項 | 情報システムの運用の継続性について、障害、災害等による情報システムの問題発生時に求められる機能やシステム構成、その目標復旧時点及び目標復旧時間等を記載する。特に、「第４章５．7) 業務の継続の方針等」において検討した内容に照らし、過度にならないよう適切な要件とすること。 | 障害や大規模災害等により情報システムの機能が停止した場合に、必要最低限の業務を継続又は回復するために必要となる対策、指標値等の要件を明らかにする。 なお、継続性について過度な要件を設定することで調達コストを押し上げることのないよう、自府省の業務継続計画を参照し必要十分な要件を定義する。 参考:中央省庁における情報システム運用継続計画ガイドライン～策定手引書（第２版）（平成24年５月内閣官房情報セキュリティセンター） |
| j) 情報セキュリティに関する事項 | 情報システムの情報セキュリティ対策に関する事項について記載する。特に、「第４章５．8) 情報セキュリティ」において検討した内容に照らし、過度にならないよう適切な要件とすること。また、記載に当たっては、自府省の情報セキュリティポリシーを参照の上、要件を適切に定めるものとすること。 | 情報の機密性、完全性、可用性を確保するための要件を明らかにする。
これらは、自府省が扱う情報を適切に保護し、業務の継続性の確保、業務に対する信頼の維持のために重要な事項である。 また、情報セキュリティについては、自府省の情報セキュリティポリシーを参照し、要件を定義する。 なお、過度な情報セキュリティ要件を設定した場合、情報システムの利用者の利便性を損なうことがあるため、十分に検討した上で要件を定義する必要がある。 参考:政府機関の情報セキュリティ対策のための統一基準群」及び「情報システムに係る政府調達におけるセキュリティ要件策定マニュアル（平成23年４月28日内閣官房情報セキュリティセンター） |
| k) 情報システム稼働環境に関する事項 | クラウドサービスの構成、ハードウェアの構成、ソフトウェア製品の構成、ネットワークの構成、施設・設備要件等について記載する。なお、稼働環境については、既存の環境を最大限活用し、不要な調達を行わないこと。 | 機能要件及び非機能要件（規模、性能、信頼性、拡張性、上位互換性、中立性、継続性、情報セキュリティ等）を実現するためのハードウェア構成、ネットワーク構成、施設・設備要件等を明らかにする。 なお、公平性や無差別性を確保し、より良い提案を受けるために、事業者が代替案を提案する余地がどの程度あるか等の前提条件も明記することも留意する。 |
| l) テストに関する事項 | 情報システムの設計から運用開始に至るまでの全てのテストについて、テストの種類、目的、内容、実施者、合否判断基準、テスト実施環境等を記載する。 | 情報システムが備えるべき機能要件及び非機能要件の実現状況を段階的に確認する行為であるテストに係る要件を明らかにする。テストには、ソフトウェアの設計に基づいて事業者が行うものと、ＰＪＭＯ及び情報システムの利用者の視点で行うものがある。 |
| m）移行に関する事項 | 本番環境への業務移行、システム移行及びデータ移行について、移行時期、移行方式、移行対象、移行環境等を記載する。 | 移行には、既存のサービス・業務から新たなサービス・業務へ移行する業務移行、既存の情報システムが保有する資産を新たな情報システムへ移行するシステム移行、既存のサービス・業務で利用しているデータを新しいサービス・業務に移行するデータ移行が存在するため、３種類の移行に係る要件を明らかにする。 タ構造が把握できる情報等の設計書を納品すること、運用保守事業者はデータ移行作業に必要なデータ構造がわかる情報を常に最新化した上で維持し、契約完了時にはそれらを納品することを要件として定めることが重要である。 なお、既存の情報システムが存在する場合、サービス継続の方針をどのように設定するかによって移行に係る作業内容や作業量が根本的に異なることに留意し、サービス継続の優先度に応じた移行要件となるように留意すること。 |
| n) 引継ぎに関する事項 | 情報システムの開発、運用等について、他の関係事業者への引継ぎに関する要件を記載する。 | 情報システムの安定的な運用を実現するため、関係事業者や要員の交代に際して、円滑かつ効率的に引継ぎ作業が行われるための要件を明らかにする。 設計・開発事業者から運用事業者及び保守事業者への引継ぎ及び当年度の運用事業者から翌年度の運用事業者への引継ぎや、ＰＪＭＯの交代について、あらかじめ想定した上で要件定義書に記述する。 なお、開発事業者は、運用保守事業者が適切に設計書等をメンテナンスし情報システムを適切に運用保守できるよう設計書やソースコード、テストコードを引き継ぐこととし、引継ぎに必要な情報を明確にし、引継ぎ時に不要なコストが発生しないよう留意する。 |
| o) 教育に関する事項 | 情報システム部門、業務実施部門等を中心とする情報システムの利用者に対する教育について、教育対象者の範囲、業務実施手順やシステム操作説明等のマニュアルの作成、教育の方法、研修環境等を記載する。 | 新たなサービス・業務を利用者が活用するために必要な教育に関する要件を明らかにする。 また、職員の人事異動やサービス利用意向により随時新たな利用者が加わることを前提として、機能の理解や操作への習熟を維持するために必要となる、情報システムの利用者の区分ごとに必要な教育について記述する。 |
| p) 運用に関する事項 | 情報システムの運用時間、運用監視、障害復旧、その他の運用管理方針、運用環境等に関する要件を記載する。なお、この運用要件は、次のq）に掲げる保守要件と明確に区別して記載すること。 | 情報システムの運用は、情報システムの設計された仕様及び構成の変更を原則として行わずに、稼働状態を維持して、情報システムを用いたサービス・業務が成立させることを目的とした行為である。詳細な内容は「第９章 運用及び保守」で検討することになるが、運用要件によって、情報システムの機能要件及び非機能要件に求める内容が異なることが考えられるため、要件定義段階で概要を明らかにする。 |
| q) 保守に関する事項 | 情報システムを構成するクラウドサービス、ハードウェア、ソフトウェア製品、アプリケーションプログラム等の保守、サポート体制、保守環境等に関する要件を記載する。なお、この保守要件は、情報システムの「機能改修」、「更改」と明確に区別して記載すること。 | 情報システムの保守は、機能維持、品質維持等、情報システムを設計された仕様どおりに動作させることを目的とした行為である。詳細な内容は「第９章
運用及び保守」で検討することになるが、保守要件によって、情報システムの機能要件及び非機能要件に求める内容が異なること、ハードウェア又はソフトウェア製品の選定に影響することが考えられるため、要件定義段階で概要を明らかにする。 なお、開発事業者が作成した設計書等の納品物においては、運用保守やその引継ぎ、開発改修、次期開発に向け最新化の維持が必要なものを明確にし、保守対象として引継ぐものとし、運用保守事業者は、当該設計書一式を最新状態に保ち、開発改修作業が行われる際には、ＰＪＭＯを通じて最新の情報を開発事業者に提示するよう留意する。 |
表5-2 非機能要件定義対象要件と定義内容
（6）「さらに、原則としてクラウドサービスの活用も検討するものとする」
「原則としてクラウドサービスの活用も検討する」とは、非機能要件として定義する複数の項目において、クラウドサービス（SaaS/PaaS/IaaS）が利用可能かを検討することを指す。また、標準でＡＰＩが提供されるクラウドサービスの活用を検討し、機能要件との整合を取り、必要な非機能要件を定義する。
エ システム方式の決定
「イ 機能要件の定義」及び「ウ 非機能要件の定義」の定義結果から、整備対象の情報システムに対する要件が明らかになるが、様々な技術要素の組み合わせにより、最終的な情報システムの全体像は複数の実現案が考えられることがある。
このため、複数の実現案が考えられる場合は、メリット・デメリットを考慮し、とり得る実現案を数案に絞り記載する。
なお、予算要求時に作成した情報システムの構成に係る全体の方針及び構成図等も、併せて更新するものとする。
（7）「これにより「イ機能要件の定義」及び「ウ 非機能要件の定義」に影響を及ぼす場合は、これらを更新すること」
「これにより「イ 機能要件の定義」及び「ウ 非機能要件の定義」に影響を及ぼす場合は、こちらも更新させること」とは、ＰＪＭＯが情報システムの実現案を確定する際に、「イ 機能要件の定義」及び「ウ 非機能要件の定義」の関連項目の内容を変更し、整合性を担保することを指す。なお、情報システムの実現案が複数存在するために、関連する機能要件及び非機能要件が確定できないときは、該当する要件とその理由を明確にすることが重要である。
（8）「導入するクラウドサービスやパッケージ製品を「システム方式」として先に定め、「ア 業務要件の定義」、「イ 機能要件の定義」及び「ウ 非機能要件の定義」を検討することもできる」
「導入するクラウドサービスやパッケージ製品を「システム方式」として先に定め」とは、要件定義を行う前にサービス・業務を実現する具体的な手段としてクラウドサービスやパッケージ製品が特定されていることを指す。
この場合、クラウドサービスやパッケージ製品が提供する機能や利用方法等に合わせて、業務要件、機能要件及び非機能要件を検討することになる。
2） 要件定義書の調整・作成
ＰＪＭＯは、要件定義書を、関係機関、情報システムの利用者等と調整し、作成するものとする。なお、他のＰＪＭＯが実施するプロジェクトと相互に密接に関係する場合には、それぞれのプロジェクトにおける要件定義書間の整合性が確保されるよう調整するものとする。 なお、 府省重点プロジェクト等に係る要件定義に対して第一次工程レビュー及び第二次工程レビューが実施されることについては、「第６章３．3) 第一次工程レビューの実施」及び「第７章３．第二次工程レビューの実施」参照 (1) 。 また、ＰＪＭＯは、要件定義の調整後に内容を変更する必要が生じたときは、関係機関等との再調整を行った上で変更内容を要件定義書に反映するものとする (2) 。 ＰＪＭＯは、この要件定義書が、次工程以降及び後続のプロジェクトにおいても、引き続き使用されることに留意する。 |
１. 趣旨
提供するサービス・業務が他のサービス・業務・情報システムと連携する場合に、ＰＪＭＯが関係者への情報共有等を疎かにすると、サービス・業務が成立せず、プロジェクトの目的・目標が達成しないおそれがある。
このため、ＰＪＭＯは、連携するサービス・業務・情報システムを把握し、関係者に情報を提供し、調整をする必要がある。
特に、地方公共団体や独立行政法人等の府省以外を含む関係機関との調整が必要な場合は、十分な情報共有と調整をすることが必要である。
このため、ＰＪＭＯは、関係機関との検討会議や説明会等を実施し、その結果を踏まえて要件定義書を調整し、作成する。
また、当該プロジェクトが府省重点プロジェクトのときは、第一次工程レビュー及び第二次工程レビューを実施し、要件定義書の内容がプロジェクト目的・目標達成に向け妥当であるか確認するものとする。
| 要件定義を事業者へ外部委託する場合
ステークホルダーとの調整はＰＪＭＯが実施し、事業者には決定事項を伝達する。事業者は要件定義書への反映作業を担当するものとする。 |
２. 解説
（1）「府省重点プロジェクト等に係る要件定義に対して第一次工程レビュー及び第二次工程レビューが実施されることについては、「第６章３．3) 第一次工程レビューの実施」及び「第７章３．第二次工程レビューの実施」参照」
「府省重点プロジェクト等」とは、府省重点以外のプロジェクトについても、ＰＭＯ等により指定された場合は、工程レビューの対象となることを指す。
（2）「また、ＰＪＭＯは、要件定義の調整後に内容を変更する必要が生じたときは、関係機関等との再調整を行った上で変更内容を要件定義書に反映するものとする」
「要件定義の調整後に内容を変更する必要が生じたとき」とは、ＰＪＭＯが要件定義の内容を関係機関等と調整した後で、調達後の事業者の決定に伴い当該事業者の提案内容を採用した結果、要件定義書の内容に変更が必要と判断した場合や、設計・開発工程において事業者が検討の過程で要件定義書の内容の変更を申し出、ＰＪＭＯが了承した場合等を指す。
ＰＪＭＯが要件定義書の内容の変更が必要と判断したときは、それまでに決定された情報と変更する該当箇所との整合性を保ち、更新する必要がある。
なお、変更に当たっては、プロジェクト管理要領の変更管理の管理手順に従って、確認、承認を得る必要がある。
３. プロジェクト計画書の段階的な改定
プロジェクト推進責任者は、適時、プロジェクト計画書を段階的詳細化し、当該計画書の内容を更新する(1)とともに、必要な情報をＯＤＢ等へ登録する (2)ものとする。 |
１. 趣旨
要件定義書の作成に伴い、プロジェクト計画書で定義した内容も具体化・詳細化されるため、その内容については、ＰＪＭＯがプロジェクト計画書に反映させ、関係者に周知する必要がある。
なお、プロジェクト計画書の各項目に大幅な変更が発生する可能性があったときは、ＰＪＭＯはプロジェクト計画の軌道修正も含めて検討する。
プロジェクト計画書への反映については、標準ガイドライン解説書「第３編第２章 プロジェクトの管理」を参照すること。
２. 解説（1）「適時、プロジェクト計画書を段階的詳細化し、当該計画書の内容を更新する」
「適時、プロジェクト計画書を段階的詳細化し」とは、ＰＪＭＯがプロジェクト計画書を最新の状態に保つために、要件定義書の内容が変更されたときは、その変更内容に応じて、プロジェクト計画書への反映を行うことを指す。
（2）「必要な情報をＯＤＢ等へ登録する」
「必要な情報」とは、要件定義においては、「１．1) ＲＦＩの実施」で作成したＲＦＩに関する説明書の情報を指す。
ＯＤＢ登録については「ＯＤＢ操作マニュアル」を参照すること。