---
type: guideline
title: ＩＴマネジメント
source: デジタル庁
ds_code: ds-100
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/e15f0693/20250619_resources_standard_guidelines_guideline_02.zip
---

# ＩＴマネジメント

## 

## ＩＴマネジメントの全体像

ＰＪＭＯは、本編に規定されている手順に基づき、政府情報システムを用いるサービス・業務の企画、運営及び改善を計画的に実施するものとする。本編の位置付け及び全体像は、次のとおりである。なお、本編において、「政府情報システム」は「情報システム」と省略して記載する。

### ＩＴマネジメントの位置付け

本ガイドラインにおいて、ＩＴマネジメントとは、情報システムを活用するプロジェクトの計画、整備、運営、状況把握の一連の活動のことである。

この活動の目的は、デジタル技術を活用して利用者中心のサービス・業務改革を推進するため、サービス・業務改革を支える情報システムの整備及び管理に係る各プロジェクトにおいて、利用者が実感できる効果を確実に達成することである。

標準ガイドラインでは、ＰＪＭＯによるＩＴマネジメントが、デジタル庁やデジタル統括責任者を頂点とするＩＴガバナンスにより適正化されるよう、ＩＴガバナンスとＩＴマネジメント及びその各章を、[図 ３‑1](#_Ref518050644)のように位置付けて規定している。

<figure>
![](../assets/ds-100-ch01-image3.png)
<figcaption><p>図 ３‑1　ＩＴガバナンスとＩＴマネジメント及びその各章の関係（イメージ）</p></figcaption>
</figure>

### プロジェクトの標準的な活動スケジュール

ＰＪＭＯが管理するプロジェクトは、作業の特性や期間の違い等があるため、一様とはならないが、プロジェクトの標準的な活動スケジュールの一例として、サービス・業務を新規に構築し事業を行うプロジェクトのイメージを、[図 ３‑2](#_Ref518050615)に示す。

<figure>
![](../assets/ds-100-ch01-image4.png)
<figcaption><p>図 ３‑2　プロジェクトの標準的な活動スケジュール</p></figcaption>
</figure>

本ガイドラインにおけるプロジェクトの期間は、当該情報システムのライフサイクル期間とすることを基本とし、更改の場合は、後続プロジェクトとして当該プロジェクトと分けて管理するものとする。なお、制度や業務の中で数年単位のサイクルがある場合は、プロジェクトの期間をそのサイクルに合わせて設定することもできる。

なお、情報システムが本番稼働を開始した後も、制度改正への対応、他の新たなサービスとの連携、業務内容の変更、利用状況の変化等、プロジェクト期間中に情報システムの状況に変化が生じ得る。外部環境・内部環境それぞれの変化やモニタリング結果等を踏まえ、図３-3に示すイメージのように、プロジェクトの期間を通じて何度も機能改修のサイクルを繰り返し、情報システムの有効性を高め続けることが重要である。

<figure>
![](../assets/ds-100-ch01-image5.png)
<figcaption><p>図３-3　プロジェクト期間を通じた機能改修のサイクル</p></figcaption>
</figure>

ＰＪＭＯは、プロジェクトにおける各活動を実施するための体制、予算、期間等が十分に確保できるように考慮して、プロジェクトの全体像を取りまとめるものとする。

### プロジェクトを適切に推進するために留意すべき事項

#### セキュリティ・バイ・デザインの実施

近年の大規模かつ高度なサイバー攻撃に対応するために、情報システムのライフサイクル全般を通じてセキュリティ確保に努めること。

例えば、設計・開発段階でセキュリティ対策を実施するのみで完結するのではなく、技術やセキュリティ脅威等の外部環境や仕様変更等の内部環境の変化に応じて、継続的に対策を見直すことに留意すること。

#### クラウドサービスの適切な利用

クラウドサービスを活用して情報システムを整備する際は、「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」の記載に従って、適切にクラウドサービスを利用すること。

#### 情報システムの安定的な運用

プロジェクトの推進においては情報システムの整備を確実に行うことに着目しがちであるが、情報システムが本番稼働を開始した後も、日頃の運用・保守作業を確実に行い、利用者が情報システムを安定的に利用できるように努めること。その上で、機能改修のサイクルを繰り返し、情報システムの有効性を高め続けることも重要である。

#### テーラリングの実施

標準ガイドラインでは、デジタル庁及び各府省のサービス・業務改革並びにこれらに伴う政府情報システムの整備及び管理の手続・手順に関する基本的な方針を示している。しかし、プロジェクトが持つ特性や置かれている状況は異なり、画一的に適用してもプロジェクトが目指す成果を達成できない懸念がある。そのため、プロジェクトへの適用に当たり、ＰＪＭＯは、本ガイドラインが示すＩＴマネジメントの内容をテーラリング<sup>注記）</sup>することが重要である。

注記） テーラリングとは、個々のプロジェクトの特性等に応じて、手続・手順や成果物などを適切に調整して適用することをいう。

#### 非常時におけるプロジェクト推進

平常時のみならず感染症の拡大、大規模災害の発生等の非常時においても、ＰＭＯ等の支援や助言を受けるなど、適切なサービスを提供するために必要な開発プロセスを経るものとする。

## プロジェクトの管理

ＰＪＭＯは、次のとおりプロジェクトの管理を行うものとする。

### プロジェクトの立ち上げ及び初動

#### 目標の明確化

プロジェクトの立ち上げに当たっては、プロジェクトの目標を明確に定めるものとする。目標の設定に当たっては、提供しているサービスや実施している業務の状況を詳細に把握した上で、国民や職員等の利用者視点から十分に効果を実感できるものとするように留意する。

また、法令、政府戦略、政策方針・計画や、中長期計画等の上位計画に基づいてプロジェクトを立ち上げる際には、上位計画の内容を把握し、上位計画の目標に対してプロジェクトが達成する成果を明確にした上で、プロジェクトの目標を定義するように留意する。

#### 立ち上げの承認

デジタル統括責任者は、プロジェクトの新規立ち上げに当たって、目標設定、手段の妥当性及び費用対効果を確認し、その承認を行い、プロジェクト推進責任者及び当該プロジェクトに関する情報システム責任者を指名するものとする。（「第２編第２章２．1) 府省内全体管理」参照）

#### 体制準備

プロジェクト推進責任者は、対象となるプロジェクトを統括し、推進するためのＰＪＭＯを組織する。

ＰＪＭＯの体制は、プロジェクトの成否に影響を与える重要なものであることから、情報システム部門だけでなく、制度所管部門及び業務実施部門が適切に参画するよう組織するものとする。

なお、ＰＪＭＯは、特に職員主体開発を行う場合、それら業務を十分に遂行できるよう要員計画を立てて実施するものとする。

また、プロジェクト推進責任者は、プロジェクトの主目的であるサービス・業務改革の要点について、ＰＪＭＯ及び関係者が充分に理解できるように努めるものとする。

#### 事前調整

プロジェクト推進責任者はＰＪＭＯ各担当と調整し、対象となるプロジェクトに関連する主要なステークホルダーを把握し、プロジェクトへの関与の仕方（役割、専門性、関与度合等）について、事前調整を行うものとする。

#### 複数プロジェクトの統括管理

デジタル統括責任者は、複数のプロジェクトを統括して管理することにより、単独でプロジェクトを管理するよりも得られる効果が高いと判断したときは、複数プロジェクトの統括管理を導入する。

複数プロジェクトの統括管理は、原則として管理対象となるプロジェクトのうち、新しいサービス・業務を実現することで達成する目標や成果に対する中心的な役割を果たすプロジェクトのＰＪＭＯが行うものとする。統括管理を行うＰＪＭＯには、各プロジェクト間の調整を十分に行える体制を確保するとともに、統括管理するＰＪＭＯが調整を実効的に行えるよう、情報共有方法や合意形成方法等について関係者間で事前に申し合わせておくものとする。

#### サブプロジェクトの導入

プロジェクトの管理、運営を効率的に行うために、ＰＪＭＯはプロジェクト内の活動のまとまりを単位として分割し、それぞれをサブプロジェクトとして扱うことができる。

サブプロジェクトを導入した際は、プロジェクト計画書の詳細化等を行い、各サブプロジェクトの対象範囲や実施期間等を整理する。

### プロジェクト計画の策定

プロジェクト推進責任者は、プロジェクトを計画的に遂行するため、プロジェクトの実行に先立ち、プロジェクト計画書及びプロジェクト管理要領を作成するものとする。

なお、ＰＪＭＯは、特に職員主体開発を行う場合、要員計画を人的資源管理の要素の一つとし、プロジェクト計画書の一部として管理するものとする。

プロジェクト推進責任者は、プロジェクト計画書において、プロジェクトのライフサイクルを通じて達成すべき成果を明確にし、各工程における意思決定や関係者との合意における指針として参照することにより、プロジェクト本来の目的に対して最大の成果を発揮することを目指す。

#### プロジェクト計画書の記載内容

プロジェクト計画書には、少なくとも次のアからクまでに掲げる事項について記載するものとし、プロジェクトの進捗に合わせ、その内容を具体化・詳細化していくものとする。

##### 政策目的

業務の実施によって目指す政策上の目的・背景等について記載する。

##### 対象業務範囲及びサービス・業務企画の方向性等

上記アで記載した政策目的を達成するためにプロジェクトの対象となるべき事業のサービス・業務の内容について記載する。

また、サービス・業務企画の方向性、データ利活用の方向性、課題、効果等について構想段階のものを記載する。なお、「第４章 サービス・業務企画」を実施した後は、その結果をこの項目の記載内容に反映するものとする。

##### 対象とする情報システム

サービス・業務に用いる情報システムの名称、主な機能及びサービス・業務での利用方法について記載する。

##### 目標及びモニタリング

プロジェクトを推進し、新しいサービス・業務を実現することで達成する目標を、具体的な指標及びその達成目標年度等で記載する。

また、プロジェクトの目標が達成されているかを判断するために実施する継続的モニタリングの方法について記載する。

プロジェクトの実施状況を判断するモニタリングの対象は、「2)ウ 工程管理」、「2)エ 指標管理」及び「2)ク 品質管理」に記載した項目とする。

##### 前提条件・制約条件等

プロジェクトを実施する上でＰＪＭＯ及び関係者が理解すべき前提条件、制約条件、リスク等の事項があれば記載する。

##### 実施計画

当該情報システムのライフサイクルを通して必要となる作業内容・スケジュール・調達計画の概要等について記載する。法令改正を伴うときは、有識者会議における議論日程について記載する等、業務面に影響を与える全ての取組について記載すること。

##### 予算

業務を実施するために必要となる全ての経費項目を洗い出し、その金額を見積り、必要となる予算及び要求年度等を記載する。経費項目は「別紙２　情報システムの経費区分」に基づき区分等して記載する。

##### 体制

ＰＪＭＯを含むプロジェクトを推進するための体制、役割等について「１．3) 体制準備」で把握した内容を基に記載する。

なお、プロジェクトの所管組織を変更するときは、変更後の体制や役割等を明確化するとともに、変更後の所管組織に対してプロジェクトを推進するための必要事項を全て引き継ぐものとする。

#### プロジェクト管理要領の記載内容

プロジェクト管理要領には、プロジェクトを遂行する際に、ＰＪＭＯがプロジェクトを管理する手法、手順、遵守事項等を明確に記載するものとし、少なくとも次のアからケまでに掲げる事項について記載するものとする。

##### ステークホルダー管理

「１．3) 体制準備」及び「1)ク 体制」の内容を参考に、プロジェクトに係る主要なステークホルダーを定義し、プロジェクトへの関わり方について記載する。

##### コミュニケーション管理

ステークホルダーとの情報共有方法や合意形成方法等として、ステークホルダー間の連絡調整に関する方法、会議体の種類や開催頻度、合意形成手順、議事録管理等の具体的内容について記載する。

##### 工程管理

「1)カ 実施計画」に定めた作業内容・スケジュールを所定の時期に完了させるために、作業管理方法、進捗状況の報告先、内容、頻度等について記載する。

##### 指標管理

「1)エ 目標及びモニタリング」に定めたプロジェクトの目標の達成状況を適切に管理するために把握すべき指標項目、実績値の取得目的・取得手法・取得頻度、実績値の変動による対応策等について記載する。なお、本項目で定めた指標は、サービス、業務、情報システムの改善検討にも活用する。

##### リスク管理

プロジェクトの遂行を阻害する可能性のあるリスクについて、リスク顕在時の報告先、報告内容、リスクの管理手法等を記載する。なお、情報セキュリティ対策リスクについては、自府省の情報セキュリティポリシーを参照して記載内容を検討するものとする。

##### 課題管理

プロジェクトの遂行上発生する解決すべき課題について、その発生時の報告先、報告内容、課題の管理手法等を記載する。

##### 変更管理

プロジェクトの進捗により発生する変更について、管理対象、変更手順、管理手法等を記載する。

##### 品質管理

プロジェクトの各工程で実施する作業の品質を管理する手法及び改善する手法について記載する。

##### 記録管理

プロジェクト実施中に作成する各種文書・データの保存期間、保存期間満了時の措置等について記載する。

#### 作成時の留意点

プロジェクトの内容等に応じて、次の点に留意するものとする。

##### 他のＰＪＭＯが実施するプロジェクトと相互に密接に関係する場合

プロジェクトの数、複雑さ、難易度及び管理労力を踏まえ、ＰＭＯと相談しながら、関係するＰＪＭＯ間で協議の後、これらプロジェクト間で管理すべき必要な措置をプロジェクト計画書又はプロジェクト管理要領に盛り込むものとする。

##### サブプロジェクトを実施する場合

サブプロジェクトの管理作業を明確に定義するために、サブプロジェクト計画書及びサブプロジェクト管理要領を作成することが望ましい。なお、サブプロジェクト計画書及びサブプロジェクト管理要領は、プロジェクト計画書及びプロジェクト管理要領の内容を前提とし、差異やサブプロジェクト固有の詳細化された内容を記載する。

##### プロジェクト目標に対する具体的な実現方法が定まっていない場合

開発規模・期間を限定した試行版を提供し、効果検証を経て実運用に向けたプロジェクト計画を再度立案する等の、プロジェクトを段階的に進めていく手法（実証実験）を検討するものとする。

#### プロジェクト計画書等の案の調整等

プロジェクト推進責任者はＰＪＭＯ各担当と調整し、プロジェクト計画書の案及びプロジェクト管理要領の案を、関係機関と調整の上、確定するものとする。

特に、外部の情報システムと連携するときは、外部の情報システムを担当するＰＪＭＯ等と適切に調整を行うものとする。

#### プロジェクトの計画内容や実施状況等の公開

多数の外部関係者が存在するプロジェクトにおいては、プロジェクトの計画内容、調達予定等を含めた全体スケジュール、プロジェクトの進捗状況及び目標の達成状況について、関係者へ適時に情報を共有することに努めるものとする。なお、プロジェクト計画書自体を公開する形式でなくとも、プロジェクトの主要な状況が公開されていればよい。

また、プロジェクトの進捗状況及び達成状況に応じてプロジェクト計画書を変更したときは、外部に公開している内容も適時に変更することが望ましい。

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

プロジェクト計画書は、プロジェクト開始時に全ての内容について具体化・詳細化することは困難であるため、プロジェクト推進責任者はＰＪＭＯ各担当と調整し、次に掲げる時期を参考に、プロジェクト計画書の改定（プロジェクト管理要領の改定を含む。）を実施するものとする。なお、これらの時期以外に必要に応じて適宜改定することを妨げない。

#### プロジェクトの構想段階

ＰＪＭＯは、プロジェクトの構想段階において、プロジェクト計画の概要を整理し、プロジェクト計画書の素案を作成するものとする。

#### 当初計画段階

ＰＪＭＯは、プロジェクト計画書の素案が決定されてから、サービス・業務企画終了時までに、政策目的やプロジェクトの目標に基づき設定した業務効果に関する指標及び情報システム効果に関する指標、プロジェクトを推進する体制と各々の役割・責任、全体のスケジュール等について具体化・詳細化し、プロジェクト計画書に反映するものとする。

#### 調達及び設計・開発開始前

ＰＪＭＯは、調達及び設計・開発を開始する前までに、サービス・業務企画及び要件定義を基にして、当初計画段階のプロジェクト計画書に詳細な内容を盛り込み、設計・開発段階前のプロジェクト計画書を具体化・詳細化するものとする。

#### 運用及び保守開始前

ＰＪＭＯは、運用及び保守を開始する前までに、運用開始後の評価指標等を具体化・詳細化し、プロジェクト計画書に反映するものとする。

#### サービス・業務の運営段階

ＰＪＭＯは、サービス・業務の運営段階において、政策目的やプロジェクトの目標の達成状況、運用段階で必要となった改善点、発生した課題とその課題への対応、実施された改修、業務の状況の評価、業務の改善状況・改善計画及び実行結果等について具体化・詳細化し、プロジェクト計画書に反映するものとする。

#### サブプロジェクトの組成時

ＰＪＭＯは、当該プロジェクトに属するサブプロジェクトを組成する際、その内容を具体化・詳細化し、プロジェクト計画書に反映するものとする。

なお、サブプロジェクトに関する記載については、プロジェクト計画書に追記する形でも、サブプロジェクト計画書として独立した構成とする形でも、いずれでも差し支えない。

#### 工程完了時

工程が完了した時点で、工程で実施した作業の結果と次工程の内容を具体化・詳細化し、プロジェクト計画書に反映するものとする。既に記載されている内容についても見直しを行い、変更を検討するものとする。

### プロジェクトの実施

#### プロジェクトの実施

ＰＪＭＯは、プロジェクト計画書の内容に従って、プロジェクトを実施する。

#### プロジェクトの工程レビュー

ＰＭＯが指定したプロジェクトについて、ＰＪＭＯは、プロジェクトを適切に実施し、プロジェクトの目標を達成するため、実施要否、実施時期、実施内容等をＰＭＯと調整し、デジタル庁が別途定める手順に基づき、それぞれの場面（以下「レビューポイント」という。）において、次のとおり工程レビューを実施するものとする。

なお、工程レビューの前後でプロジェクトの所管組織が変更になるときは、原則として、移管先の府省も併せて実施するものとする。

1.  調達仕様書に添付する要件定義書の作成終了前

2.  設計・開発工程に入る前に要件定義の確定を行う前

3.  総合テスト計画書の確定を行う前

上記\[1\]、\[2\]及び\[3\]における工程レビューをそれぞれ第一次工程レビュー、第二次工程レビュー及び第三次工程レビューと称する。

##### 自己点検

プロジェクト推進責任者は、レビューポイントにおいて自己点検を行い、その結果をＰＭＯに送付するものとする。

自己点検は、どのようなプロジェクトにあっても、プロジェクトを成功に導くために必要な留意点を点検するものであり、工程レビュー対象以外のプロジェクトにおいてもその実施が望ましい。

自己点検には、「3)ア モニタリング」の結果も加えるものとする。

##### ＰＭＯレビュー

ＰＭＯは、ＰＪＭＯが行った自己点検を基に、ヒアリングを行った上でレビューを行い、ＰＪＭＯに指摘、助言又は指導を行うものとする。デジタル統括責任者又は副デジタル統括責任者も積極的に状況を把握し、レビューに関与するものとする。

##### レビュー対応

プロジェクト推進責任者はＰＪＭＯ各担当と調整し、ＰＭＯから指摘、助言又は指導を受けた際は、必要な対応策を講ずるものとする。

#### プロジェクトのモニタリング及び停止・改善

プロジェクトのモニタリング及び停止・改善については、次のとおり実施するものとする。

##### モニタリング

プロジェクト推進責任者は「２．1)エ 目標及びモニタリング」で定めた方法に基づき、継続的・定期的にモニタリングを行うものとする。モニタリングにより各活動の品質状況を把握し、活動単位の影響に加え、プロジェクト全体視点での影響を検証し、適宜対策を講じる。モニタリングの内容は、「２．1)エ 目標及びモニタリング」の記載に従う。

##### プロジェクトの停止・改善

デジタル庁は、「2) プロジェクトの工程レビュー」等の結果から、プロジェクトが次のいずれかに当てはまる状況であると判断したときは、「プロジェクト検証委員会」の設置要否を検討するものとする。なお、b)に該当するプロジェクトについては、「プロジェクト検証委員会」が定期的にモニタリングの結果を把握するものとする（「第２編第９章２．プロジェクト検証委員会の設置」参照）。

###### プロジェクトの停止が必要な状況

設計、開発等の工程で重要な問題が発生し情報システムの完成が見込めない、又は情報システムの開発や運用を継続してもサービス・業務への効果が著しく低い等、当該プロジェクトを停止することが必要な状況

###### プロジェクトの抜本改善が必要な状況

社会的影響、業務継続の観点から当該プロジェクトを停止することができないが、プロジェクトの状況に抜本的な改善が必要な状況

### デジタル庁によるレビュー

各府省システムのうち特に重要なプロジェクト、その他のデジタル庁が特に重要と認めるプロジェクトについては、中長期計画のフォローアップの結果等を踏まえ、デジタル庁によるレビューを行うものとする。

### 後続プロジェクトの策定

当該プロジェクトが完了する前に、関連する後続プロジェクトの実施が見込まれるときは「第２章 プロジェクトの管理」に定める作業を実施するものとする。

関連する後続プロジェクトが発生する場合は、次のとおりである。

1.  プロジェクトの対象とする事業が継続される場合、かつ当初計画した実施期間を終える場合（「７．1) 完了」参照）。

<!-- -->

4.  プロジェクトで扱う情報システムを更改する場合（「第８章４．情報システムの改善」参照）。

### プロジェクトの終結

プロジェクト推進責任者は、プロジェクト計画書の内容を全て実施し終えたときに、プロジェクトの終結としてＰＭＯにその旨を報告するものとする。

なお、情報システムを廃止又は更改する際、当該情報システムを構成するハードウェア、ソフトウェア製品等の利用を停止し、情報セキュリティ等の観点を踏まえ、廃棄又は再利用に取り組むものとする。

#### 完了

プロジェクトの対象とする事業が継続し、かつ当初計画したプロジェクトの実施期間が終了するときは、プロジェクトを完了させ、新しくプロジェクトを開始するものとする。

プロジェクトの完了前に、プロジェクト計画書に定めた目標の達成状況を評価し、その結果を踏まえて後続プロジェクトの計画を策定するものとする。

#### 終了

プロジェクトの対象とする事業又は情報システムを廃止するときは、プロジェクトの終了前に、プロジェクト計画書に定めた目標の達成状況を評価し、その結果をＰＭＯへ報告するものとする。

### 一元的なプロジェクト監理

デジタル庁及び各府省は、予算要求段階から執行の段階まで年間を通じたプロジェクト監理（一元的なプロジェクト監理）を行うものとし、その実施方法は「情報システムの整備及び管理の基本的な方針」によることとする。

なお、補正予算で情報システムの整備等が実施される場合も、一元的なプロジェクト監理の対象となる。デジタル庁は、一元的なプロジェクト監理を行うに当たり、対象となる情報システムに関する情報の取扱いに重大な懸念がある等の特別の事情がある場合、各府省からデジタル庁への情報の提供方法・内容について、各府省の業務に著しい支障が生じることがないよう、各府省と所要の調整を行う。

## 予算及び執行

### 予算マネジメントの基礎

ＰＪＭＯが行う予算マネジメントにおいて、必要な要素は以下のとおり。

#### コスト分解の徹底

既に存在しているシステムについては、整備や運用に要したコストを作業工程単位や機器・ソフトウェア単位まで分解するなど、システムのコスト実態の把握に努めること。

#### 運用実態の把握・検討

当初の想定と実際のシステムの運用状況との間に相違がないか、業務とシステムの動きが乖離していないかについて、調査・検討しておくこと。

#### システム資産台帳、設計書等のドキュメント類の整備

新規参入業者にとってリスク要因と捉えられないように、システム資産台帳、設計書等のドキュメント類の整備に努めること。

#### 調達方法・契約方式の検討

予算要求段階から、どのような調達方法・契約方式にするのか、単年度契約なのか複数年度契約なのかなど、あらかじめ検討しておくこと。

#### 最新のアーキテクチャの動向に関する情報の入手・活用

デジタル分野は常に新たな発想に基づく技術や仕組みが生み出されている分野であるため、常に最新の情報を把握するとともに、デジタル庁から提供される情報も含め、予算や調達への活用に努めること。

#### 予算編成日程、予算執行日程の把握・整理

予算編成や予算執行に関する作業日程を念頭に作業を行うこと。

また、予算執行日程について、デジタル庁から予算の移替えを受けている場合には、デジタル庁から示される移替えの日程を念頭に、調達スケジュールを検討しておくこと。

### 予算要求の対象の特定

ＰＪＭＯは、予算要求に先立ち、プロジェクト計画書及びプロジェクト管理要領を確認し、プロジェクトの内容や進め方等を踏まえ、情報システム関係予算の要求対象を特定するものとする。また、ＰＪＭＯは、予算要求の内容について漏れがなく、かつ、重複がないよう、ＰＪＭＯ内の各担当と確認及び調整を行うものとする。

また、デジタル庁システムが保有する共通機能との連携・活用を行う場合は、デジタル庁の各担当と確認及び調整を行う。

### 資料の準備

ＰＪＭＯは、予算要求資料を準備するときには、デジタル庁が定めるスケジュール及び提出を求める資料を確認し、要求内容及び費用対効果の合理性が十分に判断できる資料となるよう、計画的にこれを準備するものとする。

### 経費の見積り

ＰＪＭＯは、予算要求の積算に当たって、次の\[1\]から\[7\]までに掲げる事項を遵守するものとする。なお、補正予算の場合は、予算要求までの期間が短くなるため、予算要求後にも見積りの対象や金額について精査を行う等、進め方に留意する必要がある。

1.  事業者から見積りを取得するときは、実現したい業務・機能の内容、規模、サービスレベル、スケジュール等、事業者が見積りをするための必要な情報の提供を行うこと。

<!-- -->

5.  見積り金額の妥当性を確認できるように、数量、工数、作業者のレベル、単価等の積算内訳を明確にすること。

6.  ライフサイクルコストを見積り、その根拠を明確にすること。

7.  情報システム単位で積算し、区分できるようにすること。

8.  「別紙２ 情報システムの経費区分」に基づき区分すること。

9.  原則として複数事業者の見積りを比較すること。

10. 原則としてクラウドサービスの利用を前提とした見積りも取得すること。
    クラウドサービスの選定に当たっては、「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」の記載に従って、適切にクラウドサービスを利用することを前提とした見積りを取得すること。

### ＰＭＯとの調整

ＰＪＭＯは、ＰＭＯの求めに応じて必要な資料を提出し、要求内容について説明を行うものとする。その際、ＰＭＯ等から指摘、助言又は指導を受けた際は、必要な対応策を講ずるものとする。

また、ＰＭＯは各ＰＪＭＯからの資料を取りまとめ、デジタル庁の指示に従い、提出する。

### デジタル庁による確認

デジタル庁は、提出された資料を確認の上、必要に応じて、ＰＪＭＯに対し指摘、助言又は指導をし、その内容をＰＭＯにも共有する。

ＰＪＭＯは、指摘、助言又は指導に適切に対応するとともに、デジタル庁から調整を求められた場合には、ＰＭＯに相談の上、適切に対応する。

### 概算要求作業

一括計上対象システムについては、ＰＪＭＯは、デジタル庁と調整済みの金額をもって、デジタル庁の指示・連絡に従い概算要求資料を作成し、ＰＭＯを通じて提出する。

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

プロジェクト推進責任者は、予算要求の内容について、プロジェクト計画書に反映し、当該計画書の内容を更新するものとする。

### 一括計上対象システムに関する予算の配分

#### 執行計画案の作成

ＰＪＭＯは、デジタル庁の指示・連絡に従い予算の調達スケジュールに支障を来すことのないように注意しつつ執行計画案を作成し、ＰＭＯを通じてデジタル庁に提出する。

執行計画案の作成に当たっては、調達案件ごとに金額と執行予定時期（調達予定時期）を整理して記載する。

執行計画案の策定時点で判明している契約金額は適切に反映させる。

#### 予算の配分

デジタル庁は、ＰＭＯを通じてＰＪＭＯから提出された執行計画案を基に、内容を調整し、執行計画を決定する。

また、配分する予算については、提出された執行計画案に記載されている執行予定時期を踏まえ、適切な時期に配分する。

#### 予算執行管理

ＰＪＭＯは、調達案件ごとに執行実績を記録し、デジタル庁の指示に基づきＰＭＯを通じて定期的に報告すること。

入札差額等の執行残については、デジタル庁が決定した執行計画以外の案件にＰＪＭＯやＰＭＯの判断だけで使用することはできない。

執行計画に変更の必要が生じた場合には、ＰＭＯを通じて執行計画の変更についてデジタル庁へ協議を行う。

執行計画の変更に当たっては、執行計画の妥当性や、これまでの執行実績が適正なもので、真にやむを得ないものであるか、不足額が適正なものであるか問われることになるため、日頃から適切な予算執行・管理に努める必要がある。

## サービス・業務企画

ＰＪＭＯは、制度所管部門、業務実施部門及び情報システム部門が連携し、提供者の視点ではなく利用者の視点からの検討を通して、本章に規定された事項を実施するものとする。

また、情報システムの更改又は機能改修を行うときは、利用者のニーズ及び利用状況等に応じて、既存のサービス・業務の継続必要性についても判断するものとする。

### 心構えと視点

デジタル技術を活用して利用者中心のサービス・業務改革を推進するためには、利用者のニーズを把握した上で、利用者の立場からの検討に基づいて業務要件を定義する必要がある。そのために、十分な検討期間と体制を確保した上で、概念検証（ＰｏＣ）等も適切に活用し、サービス利用者の行動等に着目したサービスデザイン思考で、現状把握、分析、検討、調整等を実施するものとする。

利用者中心の行政サービスを提供するために必要となる心構えと視点を、「サービス設計12箇条」（「情報システムの整備及び管理の基本的な方針」参照）として次に示す。

＜サービス設計12箇条＞

1.  利用者のニーズから出発する

<!-- -->

11. 事実を詳細に把握する

12. エンドツーエンドで考える

13. 全ての関係者に気を配る

14. サービスはシンプルにする

15. デジタル技術を徹底的に活用する

16. 利用者の日常体験に溶け込む

17. 自分で作りすぎない

18. オープンにサービスを作る

19. 何度も繰り返す

20. 一遍にやらず、一貫してやる

21. 情報システムではなくサービスを作る

### 現状の把握と分析

ＰＪＭＯは、提供する範囲を含むサービス・業務全体を分析対象とし、例えば、次の1）から6）までに掲げる現状の把握と分析を行うことにより、利用者のニーズや現状のサービス・業務を把握し、制約条件、前提条件、リスク及び問題点を抽出するものとする。

なお、クラウドサービスを利用するときには、ＰＪＭＯは、次の2)及び3)に掲げる業務及びデータの把握と分析の結果を踏まえ、クラウドサービスで提供される機能の喪失、低下等によるサービス停止等発生時の機密性・完全性・可用性に対する影響度の評価を行う。

情報システムの更改又は機能改修を行うときには、既存サービス・業務の継続性についても検討する。

#### 利用者の把握と分析

サービス・業務を利用することで価値や効果を得られる者・組織のそれぞれの規模、拠点、特徴、行動、満足度、要求事項等

#### 業務の把握と分析

サービス・業務の範囲、業務フロー、業務量、実施体制、実施時期・時間、実施場所等

#### データの把握と分析

業務において取り扱う情報資産の特定及び分析並びに情報システムのデータの一覧、定義、入出力、流れ、取扱量、処理件数、品質、標準の活用状況、保有形態の状況、管理ルール、管理プロセス、オープンデータとしての公開状況（「[第８章　２．5)　データマネジメントの実施](#データマネジメントの実施)」参照）等

#### 既存の情報システムの把握と分析

既存の情報システムの資料、残存課題等

#### 情報システム運用の把握と分析

情報システムの運用実績、各種指標の状況、残存課題等

#### 関連調査

類似するサービス・業務の存否、取り扱うデータに関する標準化状況、優良事例、失敗事例、その要因等

### サービス・業務企画内容の検討

ＰＪＭＯは、サービス・業務を企画するために、次の事項を実施するものとする。

#### 課題整理

ＰＪＭＯは、「２．現状の把握と分析」により得られた制約条件、前提条件、リスク及び問題点から、利用者にとってより高い効果が見込まれる内容について、これを取り組むべき主要課題として整理する。

#### 企画案作成

ＰＪＭＯは、取り組むべき主要課題を、利用者にとって有益かつ政策目的が実現可能な企画となるよう、具体的なサービス・業務内容とその結果から期待される効果について、多角的に検討し、適切な効果見積りに基づく企画案を作成するものとする。なお、企画の内容について、情報システムの利用を促進するために、有効な施策を検討するものとする。その際、必要に応じデジタル庁の支援を得ながら、サービスデザイン思考を導入するものとする。

また、当該業務のみならず、関連する制度や関連組織の関係サービス・業務にも影響が及ぶと想定される場合には、ＰＪＭＯはＰＭＯの支援を受け、関連する制度所管部門、業務実施部門と調整・協議を行うものとする。

### 軌道修正

ＰＪＭＯは、プロジェクト初期に構想したサービス・業務企画の方向性等が、「３．1) 課題整理」で得られた結果又は「３．2) 企画案作成」で作成した企画案とかい離がある場合、プロジェクト計画の修正を検討するものとする。

### 業務要件の定義

ＰＪＭＯは、作成したサービス・業務企画の内容を踏まえ、次の1）から8）までに掲げる事項を業務要件として定義するものとする（「第５章２．1)ア 業務要件の定義」も併せて参照）。

また、業務要件のうち、既存の業務がある場合は、定義する業務要件と既存実施している業務との差異が、明確に把握できるよう留意するものとする。

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

#### 業務実施手順

1.  業務の実施に必要な体制、手順及びそれらを記載した業務フロー図

<!-- -->

22. 入出力情報及び取扱量、管理対象情報一覧　等

#### 規模

1.  サービスの利用者数及び情報システムの利用者数

<!-- -->

23. 単位（年、月、日、時間等）当たりの処理件数

#### 時期・時間

1.  業務の実施時期、期間及び繁忙期　等

<!-- -->

24. 業務の実施・提供時間　等

#### 場所等

業務の実施場所、諸設備、必要な物品等の資源の種類及び量　等

#### 管理すべき指標

業務の運営上捕捉すべき指標項目、把握手順・手法・頻度　等

#### 情報システム化の範囲

情報システムを用いて実施する業務の範囲及び情報システムを用いずに実施する業務の範囲

#### 業務の継続の方針等

情報システムの障害、災害等の発生時に維持すべき必須の業務について、その業務を継続させるための基本的な考え方。なお、業務継続計画を策定する必要がある業務にあっては当該計画の策定時に検討するものとする。

#### 情報セキュリティ

業務において取り扱われる情報の格付・取扱い制限等に応じた情報セキュリティ対策の基本的な考え方。業務において取り扱われる情報資産の特定及び分析を踏まえ、セキュリティ脅威を特定しリスク分析を実施する。分析の結果、個人情報等の高い情報セキュリティ対策が必要な重要な情報資産を含む場合には、通常に増してＩＴマネジメント全体を通して情報セキュリティ対策を適切に行うものとする。

### 関係者への確認とプロジェクト計画書の段階的な改定

プロジェクト推進責任者はＰＪＭＯ各担当者と調整し、サービス・業務改革内容の検討結果について、関係者へ適時に情報を共有し、必要な意見を収集することに努めるものとする。

また、適時、その結果をプロジェクト計画書に反映し、当該計画書の内容を更新する。

## 要件定義

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

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

### 要件定義の準備

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

#### ＲＦＩの実施

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

1.  調達の概要

<!-- -->

25. その時点における検討内容、要件定義案の概要等

26. 資料提供を求める内容等

27. 提出期限、提出場所、提出方法、提出資料における知的財産の取扱い等

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

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

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

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

#### 必要な資料の作成

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

### 要件定義

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

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

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

#### 要件定義書の記載内容

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

##### 業務要件の定義

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

##### 機能要件の定義

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

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

###### 機能に関する事項

情報システムにおいて備える機能について、処理内容、入出力情報・方法、入力・出力の関係等を記載する。なお、他の情報システムが類似の機能を持つ場合は、その機能を活用することも検討する。

###### 画面に関する事項

情報システムにおいて表示される画面について、画面の概要や表示イメージ、画面の遷移や入出力の基本的考え方等を記載する。

###### 帳票に関する事項

情報システムにおいて入出力される帳票について、帳票の概要や表示イメージ、帳票の入出力の基本的な考え方等を記載する。なお、業務のデジタル化を前提に、帳票は最小限にすることが望ましい。

###### データに関する事項

情報システムにおいて取り扱われるデータベースや入出力ファイルといった全てのデータについて、データモデル、データ定義、データの利活用方法、オープンデータの範囲と方法、データ項目の標準化等、データに関する要件を記載する。また、原則として、政府において標準化されたデータ名称、データ構造等を採用するとともに、各データが当該情報システム内における利用だけでなく、他の情報システムとの連携やオープンデータとしての活用が行われることを前提として、リスク管理を適切に行いつつ品質が維持されるよう、「ウ　非機能要件の定義　l) データマネジメントに関する事項」にも留意すること。

###### 外部インタフェースに関する事項

整備する情報システムと他の情報システムとの連携（外部インタフェース）について、外部インタフェース一覧として、相手先の情報システム、送受信データ名、送受信タイミング、送受信の条件の基本的な考え方等を記載する。外部インタフェースについては、オープンなＡＰＩとしての活用が行われることも想定して整備するよう留意すること。

##### 非機能要件の定義

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

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

###### ユーザビリティ及びアクセシビリティに関する事項

情報システムの各機能におけるユーザビリティ及びアクセシビリティについて、日本産業規格等を踏まえつつ、情報システムの利用者の種類、特性及び利用において配慮すべき事項等を記載するとともに、国民向けの情報システムの整備に当たり、デジタルデバイドが是正され、全ての国民がその恩恵を受けられるよう、ユニバーサルデザインの考え方等に配慮するものとする。具体的には、障害者・高齢者を始めとして誰もがＩＣＴ機器・サービスにアクセスできるよう、整備する情報システムの内容に応じ、総務省が公開している情報アクセシビリティ自己評価様式の書式に基づき、アクセシビリティへの対応状況（あるいは対応予定）を記載するように応札者に求めることで、可能な限り、障害の種類・程度を踏まえた対応状況を確認することにより、環境整備の推進に努める。<sup>注記</sup>）

**注記）** 応札者に対し、前記自己評価様式の書式に基づく対応状況の記載の求めに加え、その他のアクセシビリティ基準等（標準ガイドライン解説書及び実践ガイドブック参照）への準拠の対応状況の確認を求めることを妨げるものではない。

###### システム方式に関する事項

クラウドサービス、ハードウェア、ソフトウェア、ネットワーク等の情報システムの構成に関する全体の方針等の案について記載する。

特にクラウドサービスについては、「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」を参考に、極力クラウドネイティブな構成となるよう留意すること。

###### 規模に関する事項

情報システムの規模について、機器数、設置場所、データ量、処理件数、利用者数等を記載する。なお、データ量については、ライフサイクル期間における将来の見込みも記載すること。

###### 性能に関する事項

情報システムの性能について、応答時間、バッチ処理時間等を記載する。特に、「第４章５．業務要件の定義」において検討した内容に照らし、性能が過度にならないよう適切な要件とすること。

###### 信頼性に関する事項

情報システムの信頼性について、稼働率等を記載する。特に、「第４章５．業務要件の定義」において検討した内容に照らし、過度にならないよう適切な要件とすること。

###### 拡張性に関する事項

情報システムの性能及び機能の拡張性要件について記載する。特に、将来の機能改修や、社会情勢の変化、技術の変化、利用状況の変化等に対して、柔軟で効率的な対応を行うことを念頭に、要件を定めること。

###### 上位互換性に関する事項

情報システムを構成するＯＳ及びミドルウェア等のバージョンアップ時における情報システムの改修の許容度等を記載する。

###### 中立性に関する事項

情報システムの中立性については、いわゆるベンダーロックインの解消等による調達コストの削減、透明性向上等を図るため、市場において容易に取得できるオープンな標準的技術又は製品を用いる等の要件について記載する。なお、技術又は製品について指定する場合には、指定を行う合理的な理由を明記した上で、クラウドサービス、ハードウェア、ソフトウェア製品等の構成を明らかにすること。また、情報システムを利用する端末についても、特定のハードウェア又はソフトウェアに依存しないよう留意すること。

###### 継続性に関する事項

情報システムの運用の継続性について、障害、災害等による情報システムの問題発生時に求められる機能、システム構成、その目標復旧時点及び目標復旧時間等を記載する。特に、「第４章５．7) 業務の継続の方針等」において検討した内容に照らし、過度にならないよう適切な要件とすること。

###### 情報セキュリティに関する事項

情報システムの情報セキュリティ対策に関する事項について記載する。特に、「第４章５．8) 情報セキュリティ」において検討した内容に照らし、過不足なく適切なセキュリティ要件とすること。また、記載に当たっては、自府省の情報セキュリティポリシーを参照の上、要件を適切に定めるものとすること。

###### 情報システム稼働環境に関する事項

クラウドサービスの構成、ハードウェアの構成、ソフトウェア製品の構成、ネットワークの構成、施設・設備要件等について記載する。なお、稼働環境については、クラウドサービスの利用環境や、オンプレミスの場合におけるサーバ環境だけでなく、クライアント環境（ＯＳ、ブラウザ等）の要件も記載すること。また、プロジェクトの特性を踏まえて合理的な構成となるよう要件整理を行い、不要な調達を行わないこと。

###### データマネジメントに関する事項

情報システムのライフサイクル全般を通じて、情報システムで保有するデータ品質の維持・向上やデータの適正な利活用等を実現するための要件を記載する。

###### テストに関する事項

情報システムの設計から運用開始に至るまでの全てのテストについて、テストの種類、目的、内容、実施者、合否判断基準、テスト実施環境等を記載する。

###### 移行に関する事項

本番環境への業務移行、システム移行及びデータ移行について、移行時期、移行方式、移行対象、移行環境等を記載する。

###### 引継ぎに関する事項

情報システムの開発、運用等について、他の関係事業者への引継ぎに関する要件を記載する。

###### 教育に関する事項

情報システム部門、業務実施部門等を中心とする情報システムの利用者に対する教育について、教育対象者の範囲、業務実施手順やシステム操作説明等のマニュアルの作成、教育の方法、研修環境等を記載する。国民等の多数の利用者が参照するマニュアルについては、利用環境に応じて閲覧・検索しやすい形式で提供するよう努める。

###### 運用に関する事項

情報システムの運用時間、運用監視、障害復旧、その他の運用管理方針、運用環境等に関する要件を記載する。なお、この運用要件は、次のr）に掲げる保守要件と明確に区別して記載すること。

###### 保守に関する事項

情報システムを構成するクラウドサービス、ハードウェア、ソフトウェア製品、アプリケーションプログラム等の保守、サポート体制、保守環境等に関する要件を記載する。なお、この保守要件は、情報システムの機能改修及び更改と明確に区別して記載すること。

##### システム方式の決定

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

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

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

#### 要件定義書の調整・作成

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

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

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

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

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

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

## 調達

ＰＪＭＯは、情報システムに関する調達について、会計法等の関係法令等を遵守し、透明性、公正性及び競争性の確保を図り、要件定義を満たす成果物を得るため、本章で示す作業を行うものとする。

なお、ＰＪＭＯは、調達手続を通じて、サービス・業務企画や要件定義の内容等が事業者に明確かつ十分に伝達されるようにするものとする。また、ＰＪＭＯは、発注者として、主体性を持って事業者を管理する責任があることに厳に留意するものとする。

### 調達の計画

ＰＪＭＯは、プロジェクト計画書に基づき、関連する一連の調達を開始するときは、調達手続に要する期間等も踏まえつつ、次のとおり、合理的な調達単位及び調達の方式を精査した上で、実施時期等を検討するものとする。なお、調達単位、調達の方式、実施時期等、調達の計画については、関連する一連の調達仕様書の全てに記載するものとし、プロジェクト計画書の内容に変更が生じる場合には、これを反映し、当該計画書の内容を更新するものとする。

また、調達に関する公告の期間については、事業者において質の高い提案が行えるよう適切な期間を確保するものとし、特に予定価格が80万ＳＤＲ<sup>注記</sup>）以上となる見込みの大規模な調達案件については、調達内容に応じ、調達スケジュールも踏まえた上で、当該公告の期間（50日）を延長することも検討するものとする。

**注記）** ＳＤＲ（Special Drawing Right）とは、特別引出権と訳され、国際通貨基金(ＩＭＦ)の公式為替単位である総合通貨単位をいう。

#### 合理的な調達単位の検討

ＰＪＭＯは、ＰＭＯ等と相談しつつ、履行可能性、ライフサイクルコスト、技術的妥当性、複数の関連調達間の整合性・効率性等を考慮の上、競争性が確保されコストが低減されるよう合理的な調達単位を検討するものとする。

#### 調達の方式の検討

ＰＪＭＯは、調達の方式の検討に当たり、次のとおり取り組むものとする。

##### 契約方式の検討

契約方式は、一般競争入札（総合評価落札方式を含む。）を原則とする。

例外的に随意契約を行う場合には、原則、企画競争又は公募を行うことにより、透明性及び競争性を担保するものとする。なお、公募を行った結果、応募が複数あった場合には、一般競争入札（総合評価落札方式を含む。）又は企画競争を行うものとする。

##### 落札方式の検討

一般競争入札において、調達案件が価格以外の技術的要素を評価することが必要と認められるものであるときは、次のa）及びb）に掲げる総合評価落札方式によることができる。

###### 除算方式

入札者の申込みに係る性能等の各評価項目の得点の合計を当該入札者の入札価格で除して得た数値が最も高い者を落札者とする方式であり、「コンピューター製品及びサービスの調達に係る総合評価落札方式の標準ガイド」（平成7年3月28日調達関係省庁申合せ）に基づいて行う。

###### 加算方式

入札価格に対する得点配分と、性能等に対する得点配分を等しいものとし、入札者の入札価格の得点に当該入札者の申込みに係る性能等の各評価項目の得点の合計を加えて得た数値が最も高い者を落札者とする方式であり、「情報システムの調達に係る総合評価落札方式の標準ガイド」（平成14年7月12日調達関係省庁申合せ）に基づいて行う。

また、「情報システムの調達に係る総合評価落札方式の標準ガイドライン」（平成25年7月19日調達関係省庁申合せ）に基づき、適用範囲に該当すると認められる場合には、入札価格に対する得点配分の割合を全体の4分の1以上とすることも可能である。

##### 入開札の方式の検討

入開札については、原則として、電子調達システムを用いて行うものとする。

### 調達仕様書の作成等

ＰＪＭＯは、各調達を行うときは、調達仕様書を作成し、契約書に必要な事項が記載されるよう会計担当部門に依頼する等、次の1）から4）までのとおり取り組むものとする。

#### 調達仕様書の記載内容

調達仕様書には、事業者が提案内容を検討するために不可欠な情報が網羅されるよう、原則として、次のアからサまでに掲げる事項について記載するものとする。契約書にも同様の事項を記載するときは、契約書とその一部を構成する調達仕様書との整合性を確保するよう、会計担当部門と必要な調整を行うものとする。

##### 調達案件の概要に関する事項

調達の背景、目的、期待する効果、業務・情報システムの概要、契約期間、作業スケジュール等について記載する。

##### 調達案件及び関連調達案件の調達単位、調達の方式等に関する事項

調達案件及びこれと関連する調達案件の調達単位、調達の方式、実施時期等について記載する。

##### 情報システムに求める要件に関する事項

「第５章 要件定義」において作成した要件定義書を満たすべき旨を記載する。

##### 作業の実施内容に関する事項

作業の内容、成果物の範囲、納品期日等について記載する。特に、標準ガイドラインにおいて、各事業者に求められる事項であって、当該調達案件に関係するもの及び「別紙３　調達仕様書に盛り込むべき情報資産管理標準シートの提出等に関する作業内容」に定める内容を盛り込むものとする。

##### 作業の実施体制・方法に関する事項

作業実施体制、作業要員に求める資格要件、作業場所、作業の管理に関する要領等について記載する。

##### 作業の実施に当たっての遵守事項

機密保持、資料の取扱い、遵守する法令等について記載する。

##### 成果物の取扱いに関する事項

知的財産権の帰属、契約不適合責任、検収等について記載する。

このうち、知的財産権の帰属については、一般に、産業技術力強化法（平成12年法律第44号）に基づき、技術に関する研究開発活動を活性化し、及び事業活動における効率的な成果物の活用の促進に資するため、受注者側に知的財産権が帰属するものであることに留意するものとする。

なお、設計・開発により構築したアプリケーションプログラム等の成果物のうち、国の業務に特化した汎用性のないもの及び継続的な機能改修が見込まれるものについては、原則として次のとおりとする。

1.  発注者側に知的財産権が帰属する旨を例外的に記載すること。ただし、当該知的財産権について、産業技術力強化法等の趣旨に鑑み、発注者側が不利にならないことを条件として、受注者側に対し、その利活用を認める旨を記載すること。

<!-- -->

28. 成果物の機密の確保や改変の自由を担保するため、受注者側により勝手に著作者人格権が行使されないよう、その旨を記載すること。

29. 成果物における契約不適合責任の期間、内容及び責任分界点について記載すること。

30. 継続的な機能改修や次期更改等に対する公正性及び競争性を担保する観点から、発注者側に帰属する成果物については、その範囲を明確にすること。

##### 入札参加資格に関する事項

次のa）及びb）について、それぞれに定めるところにより、記載する。

###### 入札参加要件

入札参加機会の拡大のため、下位の等級に格付された者の参入、複数事業者による共同提案等について検討した上で入札参加要件として記載するものとする。なお、これらを記載した場合には、審査において履行可能性を検証する等の必要な措置を講ずるものとする。

また、確実な履行の確保の観点から、公的な資格や認証等の取得、受注実績等を求めるときは、特定の事業者のみに有利なものとならないようにするものとする。

###### 入札制限

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

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

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

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

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

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

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

##### 再委託に関する事項

契約した業務の再委託（再々委託を含む。以下同じ。）の制限並びに再委託を認める場合の条件、承認手続、監査及び再委託先の契約違反等に関する責任についての定め等について記載する。

##### その他特記事項

前提条件、制約条件、要件定義、調達仕様書の変更手順等について記載する。

##### 附属文書

「第５章 要件定義」において作成した要件定義書及び参考資料のほか、事業者が閲覧できる資料一覧表、閲覧要領、提案書等の審査要領その他事業者の提案に必要な資料を作成し、調達仕様書に添付するものとする。

#### 契約書の記載事項

ＰＪＭＯは、会計担当部門に対し、契約書に、損害賠償、契約変更手続、契約解除等に関する条項を記載するよう依頼するものとする。特に、損害賠償については、事業者による契約の履行が不可能となった場合の社会的影響等を踏まえ、損害賠償の範囲の限度を記載するよう併せて依頼するものとする。

#### 第一次工程レビューの実施

ＰＪＭＯは、ＰＭＯが指定したプロジェクトについて、調達仕様書に添付する要件定義書の作成終了前（意見招請を行うものにあっては意見招請前）までに、「第２章４．2) プロジェクトの工程レビュー」に基づき、第一次工程レビューを実施するものとする。その際、調達仕様書の内容が適正なものとなっているか否かの確認を行うものとする。

#### 意見招請の実施

ＰＪＭＯは、予定価格が80万ＳＤＲ以上と見込まれる調達案件については、「政府調達手続に関する運用指針」（平成26年3月31日関係省庁申合せ）に基づき、意見招請を行うものとする。

なお、意見招請を行うに当たっては、調達仕様書等の案の内容についての十分な理解が得られるよう、事業者に対する説明等を積極的に行うものとする。また、事業者との質疑応答を通じて、提供すべき情報が明確で、かつ、漏れがないことを確認する。意見招請の結果を踏まえて、調達仕様書等の案に修正が必要な場合はこれを修正し、確定するものとする。

### ＲＦＰ・公告

#### 提案依頼書の作成

ＰＪＭＯは、総合評価落札方式による調達を行うときは、提案依頼書の作成を行うものとする。提案依頼書には、事業者が適切に提案するために必要となる情報が網羅されるよう、原則として、次のアからエまでに掲げる事項について記載するものとする。

##### ＲＦＰの内容

提案書の記載要領、具体的な提案依頼の内容（作業内容の実施体制（再委託に関する事項を含む。）、実施計画、プロジェクト管理手法等）その他提案時に提出すべき資料等（その際、提案に盛り込まれるべき事項が具体的かつ漏れなく提案書に記載されるよう依頼内容を明確に提示すること。）

##### 提案手続

提出期限、提出場所、提出方法等

##### 評価基準

価格点及び技術点の配点、評価事項の設定、評価方法等（調達内容の特性（制度・業務の内容、開発規模の大きさ等）を踏まえ、例えば、次の\[1\]から\[8\]までに掲げる事項について的確に評価ができ、かつ、提案内容の実現性の根拠、具体的な実現方法等が記載されるよう評価事項を定めること。また、評価方法についても、作業内容の履行可能性等、必須事項のうち最低限の要求事項を、合否を判断する基礎点として設けるほか、重要視する評価事項を考慮の上、加点の配分割合の重点化、相対評価の活用等によって、優れた提案が評価されるよう工夫すること。）

1.  制度、業務及び情報システムに対する理解度

<!-- -->

31. 要件定義の理解度

32. 任意で提案を求める事項に対する充足度

33. プロジェクトの計画能力

34. プロジェクトの管理能力

35. 設計・開発等に関する技術的能力

36. 設計・開発等の実績

37. 組織的対応力

##### 審査手法

事業者におけるプロジェクト遂行の責任者となることが予定される者による提案内容のプレゼンテーション、質疑応答の実施等、技術力を適正に評価するために行う審査の具体的な手法等

#### 調達に関する公告

ＰＪＭＯは、調達の計画に基づき、調達に関する公告手続を会計担当部門に依頼するものとする。なお、ＰＪＭＯは、調達仕様書、提案依頼書等の内容についての十分な理解が得られるよう、公告後、事業者に周知・説明等を積極的に行うものとする。

公正性及び競争性の確保の観点から、事業者からの提案に重要な影響があると認められる応答内容については、関係する全ての事業者に通知するものとする。

### 審査

#### 審査体制の確立

ＰＪＭＯは、提案書等に関する審査を行うときは、公正性の確保に留意しつつ、審査を的確に実施できるよう、調達内容に応じた知見を有する者（例えば外部有識者等）、制度・業務に精通した者及び情報システムに精通した者により構成される審査体制を確立するものとする。

#### 審査

提案書等に関する審査について、審査体制の構成員は、評価基準及び審査手法に基づき、要件定義等の内容を的確に理解した提案内容であるか、実現性のある提案内容であるか等について厳格に評価するものとする。

### 入開札

#### 入開札の実施

ＰＪＭＯは、入開札の実施後、一者応札となった調達案件については、入札説明会等には参加したが応札しなかった事業者等、応札を辞退した事業者に対するヒアリング等を行い、以後の調達手続の改善に活用するものとする。

#### 低入札価格調査の実施

会計担当部門は、開札の結果、低入札価格調査を実施することとなった調達案件については、当該調査の対象となる入札をした事業者に対し、調達内容のそれぞれについて履行可能であるとする具体的な根拠資料（開発規模、工数、作業工程、作業スケジュール、生産性の詳細等）の提示を求めるなどし、契約の内容に適合した履行がなされるかどうかについて確認するものとする。その際、会計担当部門のみで調査を行うことが困難である場合には、ＰＪＭＯ等の協力を得るものとする。

### 契約

#### 契約書の確認及び写しの保管

会計担当部門は、契約を締結するときは、ＰＪＭＯに対して契約書の内容を確認するよう依頼するとともに、契約締結後、速やかに契約書の写しをＰＪＭＯに送付するものとする。ＰＪＭＯは、取得した契約書の写しを適切に管理するものとする。

#### 再委託の審査

ＰＪＭＯは、受注者が再委託を行いたい旨申し出た場合の審査に当たっては、不適切な再委託により効率性及び機密性が損なわれないよう、ⅰ）再委託を行う合理的理由、ⅱ）再委託先事業者が、再委託される業務を履行する能力、ⅲ）その他必要と認められる事項について厳格に審査し、適当と認められる場合に承認を行うものとする。また、ＰＪＭＯは、受注者に再委託先事業者の業務の履行状況を確認・報告させること、再委託先事業者に受注者と同等の義務付けを行うこと等、必要に応じて契約の着実な履行のための措置を講ずるものとする。

#### 契約の変更・解除

会計担当部門は、契約を変更したとき、又は契約の解除をしたときは、その事実及びその理由を速やかにＰＪＭＯに連絡するものとする。

### 検収

ＰＪＭＯは、検収を実施し、納品予定の成果物に対し、要件定義書等において求める要件及び品質が満たされているか否かについて適切に確認するものとする。特に、情報システムの納品に当たっては、受入テストを通じた修補等の措置を講ずるものとし、合否判定基準を満たすことを確認した上で、検収を行うものとする。

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

プロジェクト推進責任者は、意見招請、ＲＦＰ及び調達の結果等によりプロジェクト計画書に変更が必要な場合は、当該計画書に反映し、当該計画書の内容を更新する。

## 設計・開発

ＰＪＭＯは、要件定義に基づき、次のとおり設計・開発を進めるものとする。

なお、本章は、開発手法としてウォータフォール型を選択した場合に合わせて記載している。アジャイルを選択した場合は、同じ作業が繰り返し発生することを考慮して読み替えるものとする。開発手法については、「１．1) オ開発形態、開発手法、開発環境、開発ツール等」で決定する。

### 設計・開発実施計画の策定

ＰＪＭＯは、設計・開発を計画的に実施するため、設計・開発事業者（プロジェクト管理支援事業者を調達する場合には当該事業者を含む。）とともに、設計・開発実施計画書及び設計・開発実施要領を作成するものとする。また、プロジェクト計画書、要件定義書等に変更が生じる場合には、これを更新するものとする。

#### 設計・開発実施計画書の記載内容

設計・開発実施計画書には、調達仕様書、要件定義書等に基づき、少なくとも次のアからカまでに掲げる事項について記載するものとする。また、附属文書として、作業項目、作業内容、スケジュールをより詳細に階層化し、担当者等を記載したＷＢＳを作成するものとする。

##### 作業概要

設計・開発の対象範囲、作業概要等について記載する。

##### 作業体制に関する事項

ＰＪＭＯ及び設計・開発事業者のみならず、設計・開発に携わる関係機関、情報システムの利用者、関係事業者等、設計・開発に関連する全ての関係者について、その体制、関係者間の関係性、役割分担・責務等について記載する。

##### スケジュールに関する事項

プロジェクト計画書及び調達仕様書に基づき、作業内容、スケジュール、マイルストーン等について記載する。

##### 成果物に関する事項

設計・開発によって納品される成果物、品質基準、担当者、納入期限、納入方法、納入部数等について記載する。

なお、設計・開発によって納品されるドキュメントについては、記載レベル、記載内容等を明らかにし、メンテナンス性を考慮したものとすること。

##### 開発形態、開発手法、開発環境、開発ツール等

設計・開発において採用する開発方式（スクラッチ開発、ソフトウェア製品の活用及びクラウドサービスの活用等）、開発手法（ウォータフォール型、アジャイル等）、開発ツール等を記載する。

なお、利用者が多岐にわたり、要件定義等の関係者に対して綿密な調整が必要となる等の場合は、開発手法としてアジャイルを導入することで、利用者の利便性を向上させるよう考慮する。その際、変更管理に基づき、既に作成された設計書や要件定義の内容を見直すことも想定した計画を立案すること。

##### その他

上記アからオまでに掲げる事項のほか、設計・開発の実施における前提条件、時間、予算等の制約条件等について記載する。

#### 設計・開発実施要領の記載内容

設計・開発実施要領には、プロジェクト管理要領と整合性を確保しつつ、少なくとも次のアからケまでに掲げる事項について記載するものとする。

##### コミュニケーション管理

設計・開発事業者、関係事業者等との合意形成に関する手続、連絡調整に関する方法、設計・開発事業者が参加すべき会議・開催頻度・議事録等の管理等について記載する。特に、ＰＪＭＯと設計・開発事業者との仕様における認識の相違が生じないよう、ＰＪＭＯが議事録の正確性を確認し、修正する手順も併せて盛り込むものとする。

##### 体制管理

設計・開発事業者における作業体制の管理手法等について記載する。

##### 工程管理

設計・開発の作業、工程を定め、その管理手法や完了判定基準等について記載し、次工程に進むときには、工程ごとに完了判定を実施するものとする。

##### 品質管理

成果物の品質を確保するため、品質基準、品質管理方法等について記載する。

##### リスク管理

設計・開発における作業を阻害する可能性のあるリスクを適切に管理するため、リスク認識の手法、リスクの管理手法、顕在時の対応手順等について記載する。

##### 課題管理

設計・開発において解決すべき課題について、課題の管理手法、発生時の対応手順等について記載する。

##### システム構成管理

設計・開発における情報システムの構成（ハードウェア、ソフトウェア製品、アプリケーションプログラム、ネットワーク、外部サービス、施設・区域、公開ドメイン等）の管理手法等について記載する。

##### 変更管理

設計・開発の進捗により発生する変更内容について、管理対象、変更手順、管理手法等について記載する。

なお、変更内容に応じて、影響する範囲（プロジェクト計画書、サービス・業務企画、要件定義、設計等）を判断し、適切な作業を実施できるように変更管理を行うものとする。

##### 情報セキュリティ対策

設計・開発における情報漏えい対策等について記載する。また、セキュリティ要件に基づいて必要なセキュリティ設計（機能面、非機能面）を行う方法、脆弱性が含まれないように実装を行う方法、セキュリティ観点でのテストを実施しセキュリティ要件が漏れなく十分に対策ができているかをテストで検証する方法、セキュリティ対策を十分に考慮した運用を行う方法を含め、情報セキュリティの管理手法等について記載する。

#### 設計・開発実施計画書等の調整・確定

ＰＪＭＯは、設計・開発実施計画書等の案を、関係機関と調整し、確定するものとする。

### 設計・開発工程に入る前の要件定義の内容の調整・確定

ＰＪＭＯは、調達手続開始後の事情の変化、受注者等の提案等を踏まえ、要件定義の内容に関する認識そごの防止及び不確定事項への対応方針の確定のため、関係機関、情報システムの利用者、設計・開発事業者、関係事業者等と、要件定義の内容について確認及び調整の上、要件定義を確定するものとする。

### 第二次工程レビューの実施

ＰＭＯが指定したプロジェクトについて、ＰＪＭＯは、設計・開発工程に入る前の要件定義の確定を行う前までに、「第２章４．2) プロジェクトの工程レビュー」に基づき、第二次工程レビューを実施するものとする。

### 設計の実施・管理

ＰＪＭＯは、設計に当たって、次のとおり取り組むものとする。設計の対象には目的とする情報システムの移行・運用・保守設計、教育の計画を含めるものとする。

ＰＪＭＯは、プロジェクトが円滑に実施されるよう、設計・開発事業者とともに、情報システムの利用者、関係機関、関係事業者等と調整を行い、それぞれと設計内容について合意するものとする。

なお、開発手法として、アジャイルを採用した場合は、設計の内容に応じて、要件定義の見直しが発生することを考慮する。

設計の実施に当たっては、画面、帳票等の利用者にとって直接的に理解することができる基本設計を行った後に、機能を実現するための詳細設計を行うものとする。

#### 設計の準備

ＰＪＭＯは、設計・開発事業者に対し、システム方式の設計及び開発手法、開発ルール、設計成果物、設計・開発を遂行するために必要な開発体制及び詳細開発スケジュール、各種環境に係る計画書の作成を求め、提出を受けた後、要件定義の内容との整合性、成果物や計画の妥当性等を確認し、課題等の指摘又は指導を行うものとする。

#### 機能の設計

ＰＪＭＯは、設計・開発事業者に対し、要件定義の機能要件を具体化・詳細化した画面、帳票、データ、外部インタフェース、バッチ等に関する設計の内容とともに、要件定義との整合性の確認結果の報告を求める。ＰＪＭＯは設計・開発事業者とともにその内容の確認を行い、課題等の指摘又は指導を行うものとする。

ＰＪＭＯは、設計・開発事業者に対し、設計の内容を標準化し、情報システムの拡張性や柔軟性に配慮することを求めるものとする。また、データの設計においては、既存の業務や情報システムで取り扱われているデータとして、「第４章２．現状の把握と分析」で収集したデータ、又は再取得した最新のデータを設計・開発事業者に提供し、調査を求めるものとする。また、デジタル３原則に掲げるワンスオンリー（一度提出した情報は、二度提出することを不要とする）の観点から、他システムとデータを連携することを検討する。

#### 非機能の設計

ＰＪＭＯは、設計・開発事業者に対し、要件定義の非機能要件を踏まえたクラウドサービス・ハードウェア・ミドルウェア・ソフトウェア等の構成や設定等に関する設計の内容の報告を求め、提出を受けた後、要件定義の内容との整合性を確認し、課題等の指摘又は指導を行うものとする。

#### 移行の計画・設計

ＰＪＭＯは、本番環境への業務移行、システム移行及びデータ移行に備えて、設計・開発事業者に対し、移行の方法、環境、ツール、段取り等を記載した移行計画書の案の作成を求め、提出を受けた後、その案について要件定義の内容との整合性を確認するとともに、移行リスクを低減するため、関係機関、関係事業者等と調整を行うものとする。

ＰＪＭＯは、設計・開発事業者に対し、移行計画書の案に基づき、移行に必要となるデータ変換、移行ツール等に関する設計の内容の報告を求め、提出を受けた後、移行計画書の案の内容との整合性を確認し、課題等の指摘又は指導を行うものとする。

#### 運用・保守の設計

ＰＪＭＯは、設計・開発事業者に対し、定常時における月次の作業内容及び想定スケジュール等を取りまとめた運用計画書及び保守計画書の案の作成を求め、提出を受けるものとする。その際、保守と契約不適合責任の範囲内で実施する作業の分担を明確にするよう留意するものとする。

ＰＪＭＯは、設計・開発事業者に対し、運用計画書の案に基づき、運用ツールに関する設計の内容の報告を求め、提出を受けた後、運用計画書の案との整合性を確認し、課題等の指摘又は指導を行うものとする。

ＰＪＭＯは、設計・開発事業者等とともに、定常時及び障害発生時において想定される運用体制、実施手順等を取りまとめるものとする。なお、複数の情報システムにより業務で利用されるサービスが構築される場合には、サービス提供者、運用事業者及び保守事業者の間で必要な作業が行われるよう作業分担、実施手順等を明確にするよう留意するものとする。

#### テストの計画

ＰＪＭＯは、設計・開発事業者に対し、単体テスト、結合テスト及び総合テストについて、テスト方針、テスト体制、テスト環境、作業内容、作業スケジュール、テストシナリオ作成基準、合否判定基準等を記載したテスト計画書の案の作成を求め、提出を受けた後、テストの十分性を確認し、課題等の指摘又は指導を行うものとする。

### 開発・テストの実施・管理

ＰＪＭＯは、開発・テストに当たって、次のとおり取り組むものとする。

#### 機能の実装・単体テスト

ＰＪＭＯは、設計・開発事業者に対し、実装及び単体テストの実施状況の報告を求め、報告内容を確認し、課題等の指摘又は指導を行うものとする。

#### 環境の設定

ＰＪＭＯは、設計・開発事業者に対し、非機能の設計に応じた内容で各種環境の構成やパラメータ等の設定の報告を求め、報告内容を確認し、課題等の指摘又は指導を行うものとする。

#### 移行ツールの実装及び移行データ・移行手順書等の作成

ＰＪＭＯは、保有・管理するデータを情報システムに移行する場合には、設計・開発事業者に対し、新規情報システムのデータ構造、保有・管理するデータの標準的及び例外的な変換方法、移行要領、移行手順書を作成させ、承認を行うものとする。

#### 運用ツールの実装及び運用手順書等の作成

ＰＪＭＯは、運用を補助するためのツールが必要となる場合には、設計・開発事業者に対し、当該ツールの実装及び単体テストの実施状況の報告、運用ツールの操作方法等に関する手順書の作成を求め、提出を受けた後、テスト内容の十分性や手順書の妥当性等を確認し、課題等の指摘又は指導を行うものとする。

#### システム操作マニュアルの作成

ＰＪＭＯは、設計・開発事業者と協力し、情報システムの操作方法を示したシステム操作マニュアルを作成するものとする。システム操作マニュアルの作成に当たっては、利用者の視点から業務実施時における一連の操作手順が分かりやすい記載となるように留意する。国民等の多数の利用者が参照するシステム操作マニュアルについては、利用環境に応じて閲覧・検索しやすい形式で提供するよう努める。

#### テスト仕様書の作成・テストの実施

ＰＪＭＯは、設計・開発事業者に対し、結合テスト及び総合テストについて、テスト計画書を基に、テスト方針、テスト体制、テスト環境、作業内容、作業スケジュール、テストシナリオ、合否判定基準等を詳細化・具体化したテスト計画書の更新及びテストケース、使用するテストデータの内容等を記載した仕様書の作成を求め、提出を受けた後、テスト内容の十分性、テストデータの適切性等を確認し、課題等の指摘又は指導を行うものとする。

ＰＪＭＯは、設計・開発事業者に対し、結合テスト及び総合テストの実施状況の報告を求め、報告内容を確認し、課題等の指摘又は指導を行うものとする。なお、ＰＪＭＯは、テストの実施状況について、要件定義の内容及び設計内容に照らし、設定した合否判定基準を全て満たしたと認められる場合に限り、設計・開発事業者に対し、次の工程の開始の承認を行うものとする。

#### テスト手順・データの再利用対策

ＰＪＭＯは、設計・開発事業者に対し、将来の保守や更改時におけるテスト工程の合理化に資するため、ツールを利用したテスト環境の構築を求める。

設計・開発事業者は、テスト環境に必要なテストシナリオ・スクリプト、テストデータ等を保存し、保守後等の動作確認等において、それらを一部改変して再利用できるようにするものとする。

### 第三次工程レビューの実施

ＰＭＯが指定したプロジェクトについて、ＰＪＭＯは、遅くとも総合テスト計画書を確定するまでに、「第２章４．2) プロジェクトの工程レビュー」に基づき、第三次工程レビューを実施するものとする。

### 受入テストの実施

ＰＪＭＯは、受入テストに当たって、次のとおり取り組むものとする。

#### テスト計画書・仕様書の作成

ＰＪＭＯは、設計・開発事業者の支援を受ける等により、テスト体制、テスト環境、作業内容、作業スケジュール、テストシナリオ、合否判定基準等を記載した受入テストのテスト計画書及びテストケース、使用するテストデータの内容等を記載した仕様書を作成するものとする。

#### 受入テストの実施

ＰＪＭＯは、開発された情報システムが要件定義書に記載した事項を適切に実現しているかどうかを検証するため、受入テストのテスト計画書に基づき、設計・開発事業者の支援を受けて、本番稼働時のデータに近いテストデータを用いて、受入テストを行うものとする。特に、ユーザビリティ要件及びアクセシビリティ要件を検証するときは、業務実施部門、情報システム部門等、主たる情報システムの利用者が受入テストに参加するものとする。

ＰＪＭＯは、受入テストの結果を踏まえ、設計・開発事業者に対し、課題等の指摘又は指導を行うものとする。

### 移行の実施・管理

ＰＪＭＯは、本番環境において新しい情報システムを利用するための作業として、次のとおり取り組むものとする。

#### 移行計画書の確定等

ＰＪＭＯは、本番環境への業務移行、システム移行及びデータ移行を行うときは、あらかじめ作成された移行計画書の案（「４．4) 移行の計画・設計」参照）及び移行手順書（「５．3) 移行ツールの実装及び移行データ・移行手順書等の作成」参照）を基に移行計画書に含まれる移行実施計画の内容を具体化・詳細化し確定させ、これに基づいた作業が行われるよう、管理を行うものとする。

なお、移行実施計画に基づき、移行手順書に不足がある場合、ＰＪＭＯは、設計・開発事業者に対し、移行手順書の追加作成を求めるものとする。

#### リハーサルの実施

ＰＪＭＯは、設計・開発事業者に対し、本番環境への移行手順についてリハーサルの実施を求め、移行シナリオ、移行スケジュールの適切性等を確認し、課題等の指摘又は指導を行うものとする。

#### 移行判定

ＰＪＭＯは、以下の条件を全て満たす場合に限り、本番移行を開始するものとする。

1.  受入テストにおいて、要件定義に添った内容で、かつ、設定した品質基準を全て満たしたと認められる。

<!-- -->

38. ＰＭＯが指定したプロジェクトにあっては第三次工程レビューにおいて問題なく妥当なものと判断される。

39. 移行計画書の内容及びリハーサルの結果が適正であると判断される。

#### 本番環境への移行の実施

ＰＪＭＯは、設計・開発事業者と協力し、移行手順書に基づき、データを変換・移行した後は、移行後のデータだけでなく、例外データ等についても確認を行い、データの品質の確保を図るものとする。

また、ＰＪＭＯは、設計・開発事業者と協力し、移行実施計画及び移行手順書に基づき、本番環境への業務移行、システム移行を行うものとする。

#### 稼働判定

ＰＪＭＯは、本番環境への移行の実施結果が適正であり、新しい情報システムへ切り替えても業務に支障が生じないと判断される場合は、本番稼働を開始するものとする。

#### 本番環境の切替え

ＰＪＭＯは、設計・開発事業者と協力し、移行手順書に基づき、本番環境を新しい情報システムに切り替え、本番稼働を開始するものとする。

### 引継ぎ

ＰＪＭＯは、情報システムの整備後の事業者変更のリスクを最小限に抑えつつ、円滑かつ効率的に当該情報システムを運用するため、設計・開発事業者に対し、運用事業者及び保守事業者に設計・開発の設計書、作業経緯、残存課題等を確実に引き継ぐよう求めるものとする。

### 検査・納品管理

#### 納品検査

「第６章７．検収」参照。

#### 納品管理

ＰＪＭＯは、各納品物を適切に管理し、所在を明確にしておくものとする。なお、納品期日を遵守することが困難と判断したときは、作業の繰越しを検討するものとする。

### 関係者への確認とプロジェクト計画書の段階的な改定

プロジェクト推進責任者は、設計・開発工程で作成した各種計画書等の内容を、プロジェクト計画書に反映し、当該計画書の内容を更新する。

## サービス・業務の運営と改善

ＰＪＭＯは、次のとおり、情報システムを用いて業務を開始し、当該業務の運営の定着を図り、その中で不断の業務の改善に取り組むものとする。

### サービス・業務の運営準備

#### 体制等の準備

ＰＪＭＯは、業務の運営開始に先立ち、運営体制の構築、利用者への周知・広報活動、業務手順書の作成等、サービス・業務を運営する上で必要な準備を行うものとする。

#### 教育・訓練の実施準備

ＰＪＭＯは、業務の運営開始に先立ち、業務実施部門の担当者、外部委託先等の業務に携わる全ての者（以下「業務実施担当者等」という。）に対し、業務の実施が円滑に行えるよう、役割分担、責任の範囲等を含め、教育・訓練を計画的に実施するものとする。その際、情報システムの操作、業務の運営手順等を一体として教育・訓練するよう留意するものとする。また、情報システムの障害、災害等の発生時に業務を継続するための計画や手順について、「第４章５．7) 業務の継続の方針等」において検討した内容を踏まえ、具体化するものとする。

#### リハーサルの実施

ＰＪＭＯは、業務の運営開始に先立ち、原則として、業務のリハーサルを行うものとする。この場合において、業務の運営に支障を来す不具合等を発見したときは、業務の実施手順を見直す等により、当該不具合等を回避するものとする。

#### 業務の運営開始に備えた課題対応案の準備

ＰＪＭＯは、業務の運営開始時に発生する課題に対応するため、あらかじめリスクを分析し、リスク顕在時の対応案を準備しておくものとする。

### サービス・業務の運営

業務実施部門及びＰＪＭＯは、以下の1)から6)までを実施し、業務運営上で発生した課題の収集や原因の分析、対応方針等を検討し、問題を管理するものとする。

#### モニタリングの実施及び分析

業務実施部門及びＰＪＭＯは、業務の運営中に、定期的に管理すべき指標の実績値を収集し、把握するものとする。その上で、管理すべき指標等を活用し、定期的に業務の実態を分析するものとする。

#### 教育・訓練の実施及び分析

業務実施部門及びＰＪＭＯは、業務を継続的に行うため、運営開始時と同様、業務実施担当者等に対し、継続的かつ計画的に教育・訓練を行うものとする。

特に、人事異動等により業務の運営に支障を来すおそれがないよう、組織的な教育・訓練の実施に努めるものとする。

また、教育・訓練を受けた業務実施担当者等から、訓練内容に関するアンケート等を実施し、その結果を集計・分析するものとする。

さらに、非常時を想定した業務継続訓練等を定期的に実施するものとする。

#### 利用促進のための施策の実施及び分析

業務実施部門及びＰＪＭＯは、情報システムの利用を促進するため、有効な施策を実施するとともに、業務実施担当者等に対し、情報システムを利用すると想定される利用者を誘導する施策の具体例について教育・訓練するものとする。

#### オープンデータの公開・活用

業務実施部門及びＰＪＭＯは、オープンデータとして情報を公開しているときは、その利用状況等を収集し、把握するものとする。その上で、定期的にオープンデータの活用状況を分析するものとする。

また、公開されているほかのオープンデータに係る情報を、定期的に収集し、活用の可能性について検討するものとする。

#### データマネジメントの実施

業務実施部門及びＰＪＭＯは、情報システムで取り扱うデータの品質をあらかじめ定めた水準で維持し、定期的に確認し、是正するための活動を行うものとする。特に、個人情報等の高い情報セキュリティ対策が求められる重要な情報資産に関しては、通常に増して情報資産保護を確実に行うためのリスク管理を適切に行うものとする。

#### 業務運営上の課題・要望の管理

業務実施部門及びＰＪＭＯは、業務の運営の中で発生した課題を収集し、対応すべきリスク及び課題であると認識したものについては、その原因を分析し、費用対効果を踏まえて優先順位を付け、対応方針を検討するものとする。

また、業務実施部門及びＰＪＭＯは、関係機関、情報システムの利用者等からの業務・情報システムに対する改善要望等を定期的に収集し、その詳細を把握・分析し、費用対効果を踏まえて優先順位を付け、対応方針を検討するものとする。

なお、ＰＭＯからシステム監査による指摘を受けた場合、ＰＪＭＯは、指摘事項の原因を分析し、費用対効果を踏まえて優先順位を付け、対応方針を検討するものとする。

### サービス・業務の改善

#### 業務の改善

ＰＪＭＯは、業務の運営開始後に、業務をより円滑に実施するため、定期的に（例えば半年に一度）軽微な業務内容及び業務手順書等の改善を行うものとする。

#### 教育・訓練の改善

ＰＪＭＯは、「第８章２．サービス・業務の運営」の各項で分析した結果に基づき、教育・訓練の改善をするものとする。

#### モニタリングの改善

ＰＪＭＯは、「第８章２．サービス・業務の運営」の分析結果を受けて、モニタリングの実施方法及び内容そのものについて、改善活動を行うものとする。

#### システム監査の指摘事項への対応

ＰＪＭＯは、「第８章２．サービス・業務の運営」の分析結果を受けて、システム監査の指摘事項について、改善活動を行うものとする。

### 情報システムの改善

ＰＪＭＯは、モニタリング結果等を踏まえ、次のとおり情報システムの改善を検討するものとする。

#### 改善事由・時期等

ＰＪＭＯは、次の\[1\]から\[7\]までに掲げる事由が発生又は判明した場合には、情報システムの改善を検討するものとする。このうち特に\[1\]又は\[2\]の場合には、ＰＪＭＯは、その検討結果を速やかにＰＭＯに報告するものとする。

1.  プロジェクト計画書に記載された目標の達成状況が著しく低い場合

<!-- -->

40. 効率性、有効性、情報セキュリティ等で多くの課題が発生しており、それらが業務に大きな支障を及ぼしている場合

41. 法令制度の変更、業務環境の変化等により大幅な業務の変更が生じる場合

42. ハードウェアの耐用年数が経過する場合

43. ハードウェア、ソフトウェア製品等のリース期間が満了する場合

44. ソフトウェア製品のサポート期間が終了する場合

45. その他情報システムの改善が必要となる状況が発生している場合

さらに、ＰＪＭＯは、少なくとも毎年度末においては、プロジェクト計画書に記載された目標の達成状況を評価するとともに、残存するリスク及び課題について整理し、改善の必要性について検討するものとする。

#### 改善の要否及び改善方法の検討

ＰＪＭＯは、改善を検討するに当たっては、緊急性、重要性、費用対効果等を踏まえ、改善の要否及び次の改善方法、利用者への周知等を検討するものとする。なお、検討に当たっては、ＰＭＯ等の支援や助言を受けることが望ましい。

##### 情報システムの機能改修

ＰＪＭＯは、上記1）の\[1\]から\[7\]までに掲げる場合には、情報システムの機能改修の必要性を検討するものとする。

##### 情報システムの更改

ＰＪＭＯは、上記1）の\[1\]から\[7\]までに掲げる場合であって、情報システムの機能改修では対応できないと判断したとき、又は機能改修よりも更改を行った方が経済的であると判断したときは、情報システムの更改を検討するものとする。

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

プロジェクト推進責任者は、サービス・業務の運営と改善を進める中で、プロジェクト計画書との差異が発生した場合は、適時、プロジェクト計画書に反映し、当該計画書の内容を更新する。

## 運用及び保守

ＰＪＭＯは、業務を安定的に運営することはもちろん、目標として掲げた業務の成果指標及びサービスレベル達成のために、常に改善活動を実施し、安定的、かつ、効率的な情報システムの運用及び保守を行うものとする。

なお、この章中「運用事業者」、「保守事業者」が実施することとした作業について、職員が自ら実施することを妨げるものではない。

ＰＪＭＯに定められた情報システム管理者が、運用及び保守作業に関する最終的な確認、決定を行うものとする。

ただし、保守について、契約不適合責任の範囲内で設計・開発事業者が修理等を行う場合には、この章中「保守事業者」とあるのは「設計・開発事業者」と読み替えるものとする。保守には、アプリケーション保守、ソフトウェア製品保守、ハードウェア保守等が存在し、それぞれ作業内容が異なることに留意する。

### 運用開始前の準備

ＰＪＭＯは、運用及び保守を計画的に実施するため、自ら運用及び保守を行わない場合、次の1）から6）までに掲げる事項に取り組むものとする。その際、プロジェクト計画書、要件定義書等に変更が生じる場合には、これらを変更する。

#### 運用事業者、保守事業者等の調達

ＰＪＭＯは、情報システムの運用を行う運用事業者、保守を行う保守事業者、プロジェクト管理支援事業者（「第６章２．1)クb)ロ) 設計・開発等のプロジェクト管理支援事業者」参照）等について、運用及び保守業務の全てが職員及び各事業者に分担されるよう検討する。

また、各事業者の作業範囲、作業内容、スケジュール、品質、責任分界等を定めた調達仕様書を作成し、調達を行うものとする。

#### 運用計画書の作成と確定

ＰＪＭＯは、設計・開発時に作成した運用計画書の案（「第７章４．5) 運用・保守の設計」参照）、調達仕様書、要件定義書等に基づき、関連する他の事業者との調整を行った上で、運用計画書の作成を行う。運用計画書には、原則として次のアからカまでに掲げる事項について記載するものとする。また、附属文書として、監視項目、運用業務フローなどの作業項目、作業内容、スケジュール、担当者等について記載するものとする。また、ＰＪＭＯは、これにより作成した運用計画書を、ＰＭＯ及び関係機関と調整し、確定するものとする。

##### 作業概要

監視、運用作業の対象範囲、作業概要等について記載する。

運用作業として、定常時における監視作業、情報システム維持作業、ユーザサポート業務、データの収集と報告、及び障害発生時における情報システム維持作業を定義する。特に、セキュリティや業務継続の観点から、情報システムの安全性及び信頼性を確保できるように留意すること。

##### 作業体制に関する事項

ＰＪＭＯ、運用事業者のみならず、運用に関わる関係機関、情報システムの利用者、関係事業者等の運用に関連する全ての関係者について、その体制、関係者間の関係性、役割分担、責務等を記載する。

##### スケジュールに関する事項

プロジェクト計画書及び調達仕様書に基づき、運用を行う上で基本とする作業内容、関係するほかの作業工程、そのスケジュール等について記載する。

##### 成果物に関する事項

運用によって納品される成果物の内容、担当者、納入期限、納入方法、納入部数等について記載する。

##### 運用形態、運用環境等

運用において採用する運用形態（オンサイト、リモート等）、運用環境（本番環境、検証環境、研修環境等の有無）等を記載する。

##### その他

上記アからオまでに掲げる事項のほか、運用を行う上での前提条件、時間、予算、品質等の制約条件等について記載する。

#### 運用実施要領の作成と確定

ＰＪＭＯは、運用実施要領をプロジェクト計画書及び運用計画書と整合性を確保しつつ作成し、原則として次のアからクまでに掲げる事項について記載するものとする。

##### コミュニケーション管理

運用に携わる事業者、関係事業者等との合意形成に関する手続、連絡調整に関する方法、運用事業者が参加すべき会議・開催頻度・議事録等の管理等について記載する。特に、インシデント発生時の連絡手段や報告要領についても記載するものとする。その際、ＰＪＭＯと運用に携わる事業者の双方において作業内容及び手順に関する認識に相違が生じないよう、ＰＪＭＯが議事録の正確性を確認し、修正することができること及びその手順を盛り込むものとする。

##### 体制管理

運用に携わる事業者における作業体制の管理手法等について記載する。

##### 作業管理

運用の作業及びその品質の管理手法等について記載する。

##### リスク管理

運用における作業を阻害する可能性のあるリスクを適切に管理するため、リスク認識の手法、リスクの管理手法、顕在時の対応手順等について記載する。

##### 課題管理

運用において解決すべき問題について、発生時の対応手順、管理手法等について記載する。

##### システム構成管理

運用における情報システムの構成（ハードウェア、ソフトウェア製品、アプリケーションプログラム、ネットワーク、外部サービス、施設・区域、公開ドメイン等）の管理手法等について記載する。

##### 変更管理

運用により発生する変更内容について、管理対象、変更手順、管理手法等について記載する。

##### 情報セキュリティ対策

平常時のセキュリティ運用として、継続的な脆弱性管理、構成管理及び変更管理を行い、不正アクセス等のセキュリティ脅威に対する監視運用を行うための具体的方法を記載する。

また、セキュリティインシデント発生に備えた体制や手順、発生時の被害極小化、速やかなサービス復旧を行うための具体的方法を記載する。

#### 保守計画書の作成と確定

ＰＪＭＯは、設計・開発時に作成した保守計画書の案（「第７章４．5) 運用・保守の設計」参照）、調達仕様書、要件定義書、運用計画書等に基づき、他の関連する事業者の支援を受けて、保守計画書の作成を行う。保守計画書には、原則として次のアからカまでに掲げる事項について記載するものとする。また、附属文書として、定期保守項目、保守業務フローなどの作業項目、作業内容、スケジュール、担当者等について記載するものとする。また、ＰＪＭＯは、これにより作成した保守計画書を、ＰＭＯ及び関係機関と調整し、確定するものとする。

なお、保守計画はシステムプロファイルに応じた保守水準となるよう留意する。

##### 作業概要

保守の対象範囲、作業概要等について記載する。この際、契約不適合責任の範囲内で実施する作業との分担を明確にするものとする。

作業として、定常時におけるハードウェアの保守、ソフトウェア製品の保守、データの収集と報告、障害発生時におけるアプリケーションプログラムの保守、ハードウェアの保守、ソフトウェア製品の保守を定義する。

##### 作業体制に関する事項

ＰＪＭＯ、保守事業者のみならず、保守に関わる関係機関、情報システムの利用者、運用事業者等の関係事業者等の保守に関連する全ての関係者について、その体制、関係者間の関係性、役割分担、責務等について記載する。

##### スケジュールに関する事項

プロジェクト計画書及び調達仕様書に基づき、保守を行う上で基本とする作業内容、関係するほかの作業工程、そのスケジュール等について記載する。

##### 成果物に関する事項

保守によって納品される成果物の内容、担当者、納入期限、納入方法、納入部数等について記載する。

##### 保守形態、保守環境等

保守において採用する保守形態（オンサイト、リモート等）、保守環境（保守用の開発環境、テスト環境等の有無）等を記載する。

##### その他

上記アからオまでに掲げる事項のほか、保守を行う上での前提条件、時間、予算、品質等の制約条件等について記載する。

#### 保守実施要領の作成と確定

ＰＪＭＯは、保守実施要領をプロジェクト計画書、運用実施要領及び保守計画書と整合性を確保しつつ作成し、原則として次のアからクまでに掲げる事項について記載するものとする。

##### コミュニケーション管理

保守に携わる事業者、関係事業者等との合意形成に関する手続、連絡調整に関する方法、保守事業者が参加すべき会議・開催頻度・議事録等の管理等について記載する。特に、ＰＪＭＯと保守に携わる事業者の双方において作業内容及び手順に関する認識に相違が生じないよう、ＰＪＭＯが議事録の正確性を確認し、修正することができること及びその手順を盛り込むものとする。

##### 体制管理

保守に携わる事業者における作業体制の管理手法等について記載する。

##### 作業管理

保守の作業及びその品質の管理手法等について記載する。

##### リスク管理

保守における作業を阻害する可能性のあるリスクを適切に管理するため、リスク認識の手法、リスクの管理手法、顕在時の対応手順等について記載する。

##### 課題管理

保守において解決すべき問題について、発生時の対応手順、管理手法等について記載する。

##### システム構成管理

保守における情報システムの構成（ハードウェア、ソフトウェア製品、アプリケーションプログラム、ネットワーク、外部サービス、施設・区域、公開ドメイン等）の管理手法等について記載する。

##### 変更管理

保守により発生する変更内容について、管理対象、変更手順、管理手法等について記載する。

##### 情報セキュリティ対策

運用実施要領に記載した情報セキュリティ対策を踏まえ、ＰＪＭＯ、運用事業者を含めた関係者と連携して情報セキュリティ対策を推進するための具体的方法を記載する。

#### 大規模災害等の情報システム運用継続計画の作成と確定

ＰＪＭＯは、各府省の業務継続計画に基づき、情報システム運用継続計画を策定するものとする。情報システム運用継続計画は、システムプロファイルに応じた水準となるよう留意する。また、災害の発生時に、情報システム運用継続計画に定めた手順を確実に実行できるように訓練や教育活動等を定期的に実施すること。

### 運用及び保守の実施

ＰＪＭＯは、運用及び保守を行うときは、少なくとも次のとおり実施するものとする。なお、保守を実施することにより、情報システムを構成するソフトウェア製品、ハードウェア等を改修又は更改する場合には、設計書の変更管理等、設計・開発時と同様の取組を行うものとする。

#### 運用の実施

ＰＪＭＯは、運用を行うときは、少なくとも次のア及びイのとおり実施するものとする。

##### 定常時対応

ＰＪＭＯは、運用事業者、保守事業者等に対し、運用計画書及び保守計画書に基づいた作業を求め、次のとおり作業を行うものとする。

###### 作業実績把握と確認

ＰＪＭＯは、運用事業者等に対し、定期的（毎月等）に会議（以下「定期運用会議」という。）を開催し、当該月の作業実績等をまとめて報告するよう求め、少なくとも次の\[1\]から\[8\]までに掲げる事項について、記載内容を事前に合意するものとする。なお、報告は実績データに基づいた達成状況と、未達の指標に関してはその分析・評価及び対策を求め、ＰＪＭＯ自身が業務の成果指標及びサービスレベルの目標達成を常に確認できる報告内容とすること。

確認により把握された問題は、「１．3)オ 課題管理」で定めた手順に従って、対応するものとする。

1.  成果指標とサービスレベルの達成状況

<!-- -->

46. 成果指標関連実績データと分析・評価及び対策

47. サービスレベル関連実績データと分析・評価及び対策

48. 情報セキュリティ状況

49. 作業の計画と実績状況

50. リスク・課題の発生と対応状況

51. 情報システムの構成管理状況

52. 教育・訓練状況

###### 情報共有

ＰＪＭＯは、運用事業者、保守事業者等に対し、業務の運営状況、業務量や利用者の増減等の今後の見通しを提示するとともに、情報システムの運用上のリスク等について確認し、情報を共有の上、リスク対応等が必要な場合には対応策を検討するものとする。

##### 障害発生時対応

###### 対応

ＰＪＭＯは、情報システムについて障害が発生し、又は発生するおそれがあるときは、運用及び保守における実施手順等に基づき、運用事業者、保守事業者等の作業分担を明らかにし、対応を行うものとする。また、関係機関、情報システムの利用者等に発生事象内容と対応策を連絡するものとする。同様の事象が将来にわたって発生する可能性がある場合には、運用事業者等に対し、事象の分析及びその対応策の提出を求め、必要な措置を講ずるものとする。

###### 障害報告

ＰＪＭＯは、運用事業者、保守事業者等から障害発生の報告を受け、情報システムの安定的な運用が困難になるおそれがあると認められる場合及び他の情報システムの運用に悪影響が生じるおそれがあると認められる場合には、ＰＭＯ等へ報告するものとし、ＰＭＯ等の支援や助言を受けて、必要な対策を講ずるものとする。

なお、情報漏えい等の情報セキュリティインシデントが発生した場合は、自府省の情報セキュリティポリシー等により規定されたルールに基づき、対応するものとする。

#### 保守の実施

ＰＪＭＯは、保守を行うときは、少なくとも次のア及びイのとおり実施するものとする。また、保守について、保守契約に基づく作業と契約不適合責任に基づく作業とを明確に区別して管理するものとする。その際、作業内容、作業手順等について事前に確認し、業務への影響等について把握の上、保守の実施の時期について判断を行うものとする。

##### 定常時対応

ＰＪＭＯは、定期運用会議に保守事業者の参加を求めるとともに、保守事業者に対し、当該月の作業実績等をまとめて報告するよう求め、少なくとも次の\[1\]から\[5\]までに掲げる事項を確認するものとする。

1.  成果指標とサービスレベルの達成状況

<!-- -->

53. 作業の計画と実績状況

54. 障害やインシデントの発生と対応状況

55. 情報システムの構成と稼働監視状況

56. リスク・課題の把握・対応状況

##### 障害発生時対応

ＰＪＭＯは、保守事業者が担当する案件についても、「1)イ 障害発生時対応」に規定する内容と同様の取組を行うものとする。

#### 情報システムの現況確認

ＰＪＭＯは、情報システムに係る文書の内容が実際の情報システムの状況を反映したものとなるよう、運用計画及び保守計画に基づき、毎年度末までに、運用事業者、保守事業者等とともに、同文書と情報システムの現況との突合・確認を行う。これらの取組については、ＰＪＭＯは、ＰＭＯからの依頼に応じ、具体の取組内容を報告するものとする。

ＰＪＭＯは、これらの作業を円滑に進めるために、情報システムの構成に係るハードウェア製品及びソフトウェア製品（パッケージソフト、ミドルウェア等）の保守の実施において、各製品の構成に変更が生じるときには、運用事業者等からその旨の報告を受けるものとする。なお、運用事業者等に対し、管理対象の製品に関するライセンス情報を常に正確に把握し、変更の必要性が発生したときには、速やかに定期運用会議等で報告するよう求めるものとする。

なお、次の\[1\]から\[4\]までに掲げる事項が生じた場合には、それぞれに定めるとおりの対応を行うものとする。

1.  情報システムに係る文書と情報システムの現況との間に相違があった場合　同文書の更新及び再発防止策の検討・実施

<!-- -->

57. ライセンス許諾条件違反　ライセンス許諾条件への適合等

58. サポート切れ　サポート切れの影響及び今後の対応策の検討等

59. ハードウェア、ソフトウェア製品等の利用を停止したとき　ＰＭＯにその旨を連絡（ただし、その利用を一旦停止し、その後、再利用することが適当であるもの（以下「再利用候補物」という。）に限る。なお、利用の停止から再利用の実施までの手続は、会計担当部門の協力を得て、会計法令等に基づく手続の実施、再利用候補物の保管場所の確保等が必要となることに留意すること。）

#### 大規模災害等の発生時対応

ＰＪＭＯは、大規模災害等の発災時において、情報システム運用継続計画に基づき、情報システムの運用及び保守を行うものとする。

なお、発災時における円滑かつ迅速な対応のため、ＰＪＭＯは、定常時から定期的に、発災時における運用及び保守の体制への移行について、訓練を行うものとする。

### 運用及び保守の改善

ＰＪＭＯは、毎年度末までに、当該年度の運用実績等から、作業効率や作業項目の過不足を評価・検証するものとする。この場合において、要求する水準を満たしていないときは、ＰＪＭＯは、運用事業者、保守事業者等に対し、運用実施要領又は保守実施要領に沿った対応を求めるほか、当該事業者とともに運用実施要領又は保守実施要領の改善を検討するものとする。なお、評価・検証の結果、やむを得ず原契約の範囲に含まれない作業項目を追加する必要が生じた場合には、契約変更等を検討するものとする。

#### 運用計画及び保守計画の見直し

ＰＪＭＯは、毎年度末までに、当該年度の運用実績等を踏まえ、ＰＭＯ等からの助言を受け、運用事業者、保守事業者等とともに、運用計画及び保守計画の見直しを行うものとする。

ＰＪＭＯは、運用計画及び保守計画の見直しについて、その内容をプロジェクト計画書に反映する。

#### 運用作業の改善

ＰＪＭＯは、運用の実施開始後に、運用をより円滑に実施するため、定期的に（例えば半年に一度）運用計画及び運用実施要領に基づき、運用作業の改善を行うものとする。

#### 保守作業の改善

ＰＪＭＯは、保守の実施開始後に、保守をより円滑に実施するため、定期的に（例えば半年に一度）保守計画及び保守実施要領に基づき、保守作業の改善を行うものとする。

#### 大規模災害等の情報システム運用継続計画の見直し

ＰＪＭＯは、他の地域で大規模災害等が発生した場合には、それら地域での対応状況等を参考にして対応体制や対応手順等について、情報システム運用継続計画の見直しを行うものとする。

また、「２．4) 大規模災害等の発生時対応」での訓練の結果を受け、情報システム運用継続計画の見直しを行うものとする。

#### システム監査の指摘事項への対応

ＰＪＭＯは、システム監査の指摘事項について、その内容を精査し、対応すべき課題及びリスクであると認識したものについてはその原因を分析し、費用対効果を踏まえて優先順位を付け、順次改善するものとする。

### 運用及び保守の引継ぎ

ＰＪＭＯは、次のとおり、運用事業者、保守事業者等から必要な引継ぎ等が確実に行われるようにするものとする。

#### 情報システムの更改に関する情報提供

ＰＪＭＯは、情報システムを更改するときは、運用事業者、保守事業者等に対し、次期の情報システムにおける要件定義又は設計・開発に携わる事業者に作業経緯、残存課題等に関する情報を提供させ、かつ、質疑応答等の必要な協力を求めるものとする。

#### 更改を伴わない事業者の交代に伴う引継ぎ

ＰＪＭＯは、情報システムの更改を伴わずに、運用事業者、保守事業者等に交代が生じるときは、交代前の事業者から交代後の事業者に対し、作業経緯、残存課題等について確実に引継ぎがなされるよう求めるものとする。

## システム監査

ＰＭＯは、プロジェクトの目標を達成することを目的として、所管する情報システムにまつわるリスクに適切に対処しているかを客観的に評価するために、内部又は外部からの支援を得て、次のとおり監査を行うものとする。

なお、各府省の体制等の状況によって、ＰＪＭＯ等が直接監査を行うことを妨げない。この場合においては、監査体制の確立、監査実施計画書の作成・調整・確定、監査の実施の主体はＰＪＭＯ等とする。

### システム監査

ＰＭＯは、システム監査計画（「第２編第８章 システム監査の計画・管理」参照）に基づき、次のとおり監査を行うものとする。なお、システム監査計画に定めがない場合であっても、ＰＭＯが監査を行う必要があると判断したときは、監査を行うものとする。

#### 監査体制の確立

ＰＭＯは、監査の独立性及び客観性の確保の観点から、監査実施前に、少なくとも次のアからエまでに掲げる事項を満たす監査体制を確立するよう努めるものとする。

##### 監査責任者及び監査実施者

監査体制は、監査責任者及び監査実施者により構成すること。

##### 独立性

監査体制の構成員は、監査対象となるプロジェクトや情報システムに関する業務等に関与していないこと。なお、監査対象となるプロジェクト、情報システムに関する業務等に関与した者は、自らが監査対象となる業務の監査を行うことはできないこと。

##### 監査能力

監査体制の構成員のうち少なくとも一人は、監査の実務経験を有すること。

##### 専門性

監査体制の構成員のうち少なくとも一人は、監査目的に応じた技術的な知識及び実務経験を有すること。

#### 監査実施計画の策定

監査責任者は、システム監査計画書に基づいて、次のとおり監査実施計画書を作成するものとする。

##### 監査実施計画書の記載内容

監査実施計画書には、原則として次の\[1\]から\[7\]までに掲げる事項を記載する。

1.  監査対象

<!-- -->

60. 監査目的

61. 監査範囲

62. スケジュール

63. 監査体制

64. 監査実施方法

65. その他

##### 監査実施計画書の調整・確定

監査責任者は、あらかじめ監査実施計画書の案をＰＪＭＯと調整し、ＰＭＯに報告する。

ＰＭＯは、監査実施計画書を確認し、確定するものとする。

なお、状況の変化等を勘案して監査実施計画書に変更が必要と判断されるときは、監査責任者は、ＰＭＯと相談して見直しを行うものとする。

#### 監査の実施

監査責任者及び実施者は、次のアからキに示す手順で作業を行うものとする。

監査実施者は、監査手続書を作成した上で監査を行うものとし、その結果について監査調書（指摘事項等の監査証拠を添付すること。）を作成するものとする。

監査責任者は、監査結果について、ＰＭＯに報告するものとする。

##### 予備調査

監査実施者は、監査対象を理解するために、監査対象である組織、業務、情報システムの概要について把握するための予備調査を実施する。

##### 監査手続書の作成

監査実施者は、予備調査結果等に基づき、監査の手続（入手する監査証拠及びその入手方法等）を定めた監査手続書を作成する。

##### 実地調査

監査実施者は、監査対象先に赴いて、監査手続書に基づき監査を実施する。監査体制は、実施結果、入手した監査証拠、監査の実施に際し監査実施者が気付いた点等をまとめた監査調書を作成する。

##### 監査報告書案の作成

監査実施者は、監査調書等を基に、監査結果や指摘事項等をまとめた監査報告書案を作成する。

##### 指摘事項の監査対象への確認

監査実施者は、監査報告書案の指摘事項について、監査対象の担当者等に確認を行い、監査報告書に修正が必要な箇所を修正する。

##### 監査報告書の提出

監査責任者は、ＰＭＯに監査報告書を提出した上で、ＰＪＭＯに通知する。また、監査責任者は、監査結果を合議制機関等に報告するものとする。（「第２編第８章 ３．システム監査結果の報告」参照）

##### 監査調書の整理

監査責任者は、監査調書を閲覧しやすいように整理する。

#### 指摘事項への対応

ＰＪＭＯは、監査結果により指摘された事項については、これを課題として認識の上、改善計画を立案し、監査責任者及びＰＭＯに報告するものとする。また、ＰＪＭＯは、改善計画に基づいて、指摘事項への対応を行い、当該対応の結果について、監査責任者及びＰＭＯに報告するものとする。

なお、指摘事項への対応を行った結果、プロジェクト計画書との差異が発生した場合は、プロジェクト推進責任者は、プロジェクト計画書に反映し、当該計画書の内容を更新する。

#### フォローアップ

システム監査計画に基づく監査又はＰＭＯの指示による監査の場合は、ＰＭＯは、当該監査の結果への対応について、フォローアップを行うものとする。

### システム監査に関する調達の特例

ＰＭＯは、監査業務を委託する場合、「第６章 調達」の規定に従うものとする。このほか、特例として、監査に関する調達仕様書を作成するときは、次の1）から3）までに掲げる事項を盛り込むものとする。

#### 作業の実施に当たっての遵守事項

監査事業者等は、監査結果及び監査で知り得た情報を監査体制の構成員以外の者と共有してはならないこと。

#### 入札制限

監査対象である情報システムの調達案件（監査業務案件を除く。）に関与した事業者は、監査の独立性及び客観性の確保の観点から、当該情報システムの監査に関する調達案件の入札に参加できないものとすること（「第６章２．1)クb) 入札制限」参照）。

#### 再委託に関する事項

原則として、監査業務の再委託は行ってはならないこと。

#
