--- type: guideline title: 第７章　設計・開発 source: デジタル庁 ds_code: ds-110 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/d647a7ca/20250619_resources_standard_guidelines_guideline_04.zip --- # 第７章　設計・開発 ＰＪＭＯは、要件定義に基づき、次のとおり設計・開発を進めるものとする。 なお、本章は、開発手法としてウォータフォール型を選択した場合に合わせて記載している。**アジャイルを選択した場合は、同じ作業が繰り返し発生することを考慮して読み替える(1)**ものとする。開発手法については、「１．1) オ開発形態、開発手法、開発環境、開発ツール等」で決定する。 1. １. はじめに 設計・開発は、要件定義の内容を基に設計・開発することで具体化・詳細化し、テストを通じて妥当性等を検証した後に本番移行を行うまでの一連の活動である。これらは技術的な専門性を要する作業であり、政府情報システムにおいては、外部の設計・開発事業者が大部分の作業を行うことが一般的である。設計・開発事業者は、契約に基づきＰＪＭＯが作成した調達仕様書及び要件定義書を満たす情報システムを構築することが責務となるが、求めた要求水準を確実に満たすためには、設計・開発実施計画書等に要求及び制約に合わせた作業の進め方や管理方法を定めた上で、特に要件定義の内容が確実に反映されるよう、ＰＪＭＯが作業の進捗と併せて、成果物の確認や受入テスト等を主体的に行っていくことが重要となる。 このため、本章は、設計・開発において、ＰＪＭＯが設計・開発事業者と協働し、プロジェクトの目標達成に資する情報システムを構築するために必要となる活動を定めるものである。 なお、本解説書では、設計・開発とプロジェクトの他の活動との関係を[図7-1](#_Ref520363749)のように想定している。 - 図7-1
![](../assets/ds-110-ch07-image1.png)

設計・開発と前後の工程との関係

#### 「アジャイルを選択した場合は、同じ作業が繰り返し発生することを考慮して読み替える」 「アジャイルを選択した場合」とは、設計・開発実施計画書の「開発形態、開発手法、開発環境、開発ツール等」にて、開発手法としてアジャイルを選択した場合を指す。詳細は、「１．1) オ 開発形態、開発手法、開発環境、開発ツール等」の解説を参照すること。 ## 設計・開発実施計画の策定 ＰＪＭＯは、設計・開発を計画的に実施するため、**設計・開発事業者（プロジェクト管理支援事業者を調達する場合には当該事業者を含む。）とともに、設計・開発実施計画書及び設計・開発実施要領を作成する(1)**ものとする。また、プロジェクト計画書、要件定義書等に変更が生じる場合には、これを更新するものとする。 2. １. 趣旨 設計・開発の工程では、情報システムの整備に係る様々な作業を、ＰＪＭＯと設計・開発事業者とが協働しながら進めていく必要がある。また、調達単位によっては、複数の設計・開発事業者が作業を行うこともあり、それぞれの作業を漏れなく円滑に進めるために分担や調整を行うことが必要となる。そのためには、ＰＪＭＯ及び設計・開発事業者が、調達仕様書及びプロジェクト計画書に記載した基本的な関係者ごとの作業範囲、役割、スケジュール、作業の進め方等の計画を、設計・開発工程を実施するために必要な内容について具体・詳細に定め、事前に合意することが重要となる。 以上のことから、ＰＪＭＯは、これらの内容を設計・開発事業者とともに、設計・開発実施計画書及び設計・開発実施要領としてまとめる。 なお、設計・開発実施計画書及び設計・開発実施要領は、設計・開発工程の基本となる計画及びルールを示すものであり、常に最新の情報を示す必要がある。そのため、内容に変更が必要な場合は、設計・開発実施要領の変更管理に従って更新を行う。 3. ２. 解説 #### 「設計・開発事業者（プロジェクト管理支援事業者を調達する場合には当該事業者を含む。）とともに、設計・開発実施計画書及び設計・開発実施要領を作成する」 「設計・開発実施計画書及び設計・開発実施要領」とは、プロジェクトの基本計画であるプロジェクト計画書と整合性を確保しつつ、調達仕様書、要件定義書及び調達時の提案書等に基づき、設計・開発の工程で実施する作業について具体化・詳細化した計画書及び実施要領を指す。 設計・開発実施計画書の作成に当たっては、設計・開発事業者に支援を求め、内容について十分に協議・調整する。ＰＪＭＯがプロジェクト管理支援事業者と契約している場合には、当該事業者が発注者側の立場からＰＪＭＯによる作成を支援する。いずれの場合においても、ＰＪＭＯが記載内容の確認及び承認を行う。 なお、ＰＪＭＯは、プロジェクト計画書を設計・開発事業者に開示する（開示することが適切でない記載事項の開示を除く。）等して、プロジェクト計画書の内容についてＰＪＭＯ・当該事業者間で認識が一致するようにする。 ### 設計・開発実施計画書の記載内容 **設計・開発実施計画書には、調達仕様書、要件定義書等に基づき、少なくとも次のアからカまでに掲げる事項について記載する(1)**ものとする。また、附属文書として、作業項目、作業内容、スケジュールをより詳細に階層化し、担当者等を記載したＷＢＳを作成するものとする。 ア　作業概要 **設計・開発の対象範囲(2)**、作業概要等について記載する。 イ　作業体制に関する事項 ＰＪＭＯ及び設計・開発事業者のみならず、**設計・開発に携わる関係機関、情報システムの利用者、関係事業者等、設計・開発に関連する全ての関係者について、その体制、関係者間の関係性、役割分担・責務等について記載する(3)**。 ウ　スケジュールに関する事項 プロジェクト計画書及び調達仕様書に基づき、作業内容、スケジュール、マイルストーン等について記載する。 エ　成果物に関する事項 設計・開発によって納品される成果物、品質基準、担当者、納入期限、納入方法、納入部数等について記載する。 なお、設計・開発によって納品されるドキュメントについては、記載レベル、記載内容等を明らかにし、メンテナンス性を考慮したものとすること。 オ　開発形態、開発手法、開発環境、開発ツール等 設計・開発において採用する開発方式（スクラッチ開発、ソフトウェア製品の活用及びクラウドサービスの活用等）、開発手法（ウォータフォール型、アジャイル等）、開発ツール等を記載する。 なお、**利用者が多岐にわたり、要件定義等の関係者に対して綿密な調整が必要となる等の場合は、開発手法としてアジャイルを導入することで、利用者の利便性を向上させるよう考慮する(4)**。その際、**変更管理に基づき、既に作成された設計書や要件定義の内容を見直すことも想定した計画を立案する(5)**こと。 カ　その他 上記アからオまでに掲げる事項のほか、設計・開発の実施における前提条件、時間、予算等の制約条件等について記載する。 4. １. 趣旨 設計・開発を円滑に進めていくためには、ＰＪＭＯと設計・開発事業者が、活動の遂行に関して理解すべき事項を把握し、共通認識を持って活動することが重要である。 このため、ＰＪＭＯは、設計・開発事業者とともに、調達仕様書、要件定義書及び設計開発事業者の提案内容との整合性を確認しながら、設計・開発実施計画書を作成し、活動遂行上の指針として関係者で共有する。 5. ２. 解説 #### 「設計・開発実施計画書には、調達仕様書、要件定義書等に基づき、少なくとも次のアからカまでに掲げる事項について記載する」 - 表7-1 設計・開発実施計画書の記載内容 設計・開発実施計画書の記載事項を示せば、次のとおりである。
定義する事項 記載事項

  1. 作業概要

設計・開発工程の全体像及び設計・開発事業者の作業範囲を明らかにするために、設計・開発の対象範囲と作業概要等を記載する。

なお、調達仕様書に、調達時点で要件定義に不確定事項（提案又は代替案を求めている場合を含む。）がある場合には、それらについて確定する。

  1. 作業体制に関する事項

 プロジェクトに係る情報伝達を抜け漏れなく行うために、発注者側の体制（ＰＪＭＯ、ＰＭＯ及びプロジェクト管理支援事業者を含む全ての関係者）と、設計・開発に当たり事業者が整備する体制、及び同一プロジェクト内の他の調達案件に係る事業者も含めた全ての関係者について、その体制、関係者間の関係性、役割分担・責務等を記載する。

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

 設計・開発工程の開始から完了に至るまでの進め方を明らかにするために、プロジェクト計画書及び調達仕様書に基づき、作業内容、スケジュール、マイルストーン等を記載する。

  1. 成果物に関する事項

 設計・開発工程において納品すべき成果物を明らかにするために、成果物、品質基準、担当者、納入期限、納入方法、納入部数等を記載するとともに、記載レベル、記載内容等も明らかにし、メンテナンス性を考慮したものとすること。特に基本設計書については、システムメンテナンスの中心となるドキュメントであることから、データに関する設計・定義事項の一元的記載、及び機能・処理の連携を含めた全体を俯瞰できる記載内容とすること。

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

設計・開発の実施方針及び実施環境を明らかにするために、開発方式、開発手法、開発ツール等を記載する。

なお、調達仕様書に、調達時点で要件定義に不確定事項（代替案等の提案を求めている場合を含む。）がある場合には、それらについて確定する。

  1. その他

 「ア 作業概要」から「オ 開発形態、開発手法、開発環境、開発ツール等」の記載事項以外に、特記すべき前提条件及び制約等を記載する。
#### 「設計・開発の対象範囲」 「設計・開発の対象範囲」とは、設計・開発の活動全体の中で、当該設計・開発事業者が対象とする作業の範囲を指す。 対象範囲を特定するに当たって、設計・開発における作業名称は、事業者により呼称が異なることがあるため、当該作業内容が何を意味するのか明らかにし、発注者側と事業者の理解にそごを生じさせないこと。特に同一テスト名称であっても、事業者によりテスト内容と検証対象工程の関係に差異が発生しやすいため、その差異が明らかになるように留意すること。本ガイドラインにおけるテストの種類と検証対象の関係を[図7-2](#_Ref520370066)に示す。 - 図7-2
![](../assets/ds-110-ch07-image2.png)

テストの種類と検証対象の関係

受入テストは、要件定義の内容を満たしていることを確認するためのテストであり、発注者側である職員が主体となって実施すべきものも含まれる。そのため、ＰＪＭＯは、十分な受入テストが行えるよう、テストを実施する職員やテスト期間と時間等を確保できるように事前に計画する。 #### 「設計・開発に携わる関係機関、情報システムの利用者、関係事業者等、設計・開発に関連する全ての関係者について、その体制、関係者間の関係性、役割分担・責務等について記載する」 「設計・開発に携わる関係機関、情報システムの利用者、関係事業者等」とは、設計・開発に携わる関係機関、情報システムの利用者、関係事業者以外に、外部組織の有識者や専門的な知見を持つ職員を含むことを指す。 #### 「利用者が多岐にわたり、要件定義等の関係者に対して綿密な調整が必要となる等の場合は、開発手法としてアジャイルを導入することで、利用者の利便性を向上させるよう考慮する」 「利用者が多岐にわたり、要件定義等の関係者に対して綿密な調整が必要となる等の場合」とは、利用者のニーズに不確定な要素が多く存在し、詳細な要件の確定に多大な労力を要する、又は、確定後にさらなるニーズの追加が多く見込まれるような場合を指す。 「開発手法としてアジャイルを導入することで、利用者の利便性を向上させるよう考慮する」とは、利用者のニーズに不確定な要素が多い機能については、アジャイル開発の手法を用いて、要件を具体化した情報システムを用いて要件の確認・調整を行い、徐々に機能や改良を加えていくような計画とする等、効率的に利用者のニーズを取り込めるような開発計画を検討することを指す。 情報システムの整備においては、要求する情報システムの特徴や開発手法によって表7-2に示すような記載内容の具体性、見直しの可能性の特徴を有 - 表7-2 開発手法の概要 する。
開発手法 開発手法の概要
ウォータフォール型

図7-2で示したような工程を時系列に進め、原則として前工程の完了後に次工程を開始する情報システム構築作業の進め方である。

設計・開発に着手する時点で、要件がしっかり定まっており、設計・開発の途中で要件の変更が少ないと見込まれる場合に用いる。

工程を時系列で進めることから、計画が立てやすく、進捗の管理がしやすい。
アジャイル

開発対象となる機能の設計・開発をイテレーション（反復）と呼ばれる短い期間に分けて進め、イテレーションが終了するごとに機能の動作を確認できることを特徴とした情報システム構築作業の進め方である。

設計・開発に着手する時点で、要件が十分に固まっておらず、設計・開発の途中で変更が多く発生すると見込まれる場合に用いる。

短期間で機能が出来上がるため、情報システムの利用者に確認を取りやすく、利用者の要望等をこまめに反映しやすい。
#### 「変更管理に基づき、既に作成された設計書や要件定義の内容を見直すことも想定した計画を立案する」 「既に作成された設計書や要件定義の内容を見直すことも想定した計画」とは、アジャイルの開発手法を用いた場合は、実際の情報システムを用いた要件の調整や検証結果の確認を行うタイミングを計画し、そのタイミングで既に作成された設計書や要件定義の内容が変わる可能性があることを設計・開発事業者と合意することを指す。 なお、設計書や要件の変更に当たっては、設計・開発実施要領の変更管理に従って、各種関係者と合意の上で変更する必要があることに留意する。 ### 設計・開発実施要領の記載内容 **設計・開発実施要領には、プロジェクト管理要領と整合性を確保しつつ、少なくとも次のアからケまでに掲げる事項について記載する(1)**ものとする。 ア　コミュニケーション管理 設計・開発事業者、関係事業者等との合意形成に関する手続、連絡調整に関する方法、設計・開発事業者が参加すべき会議・開催頻度・議事録等の管理等について記載する。特に、ＰＪＭＯと設計・開発事業者との仕様における認識の相違が生じないよう、ＰＪＭＯが議事録の正確性を確認し、修正する手順も併せて盛り込むものとする。 イ　体制管理 設計・開発事業者における作業体制の管理手法等について記載する。 ウ　工程管理 設計・開発の作業、工程を定め、その管理手法や完了判定基準等について記載し、次工程に進むときには、工程ごとに完了判定を実施するものとする。 エ　品質管理 成果物の品質を確保するため、**品質基準、品質管理方法等について記載する(2)**。 オ　リスク管理 設計・開発における作業を阻害する可能性のあるリスクを適切に管理するため、リスク認識の手法、リスクの管理手法、顕在時の対応手順等について記載する。 カ　課題管理 設計・開発において解決すべき課題について、課題の管理手法、発生時の対応手順等について記載する。 キ　システム構成管理 設計・開発における情報システムの構成（ハードウェア、ソフトウェア製品、アプリケーションプログラム、ネットワーク、外部サービス、施設・区域、公開ドメイン等）の管理手法等について記載する。 ク　変更管理 設計・開発の進捗により発生する変更内容について、管理対象、変更手順、管理手法等について記載する。 なお、変更内容に応じて、影響する範囲（プロジェクト計画書、サービス・業務企画、要件定義、設計等）を判断し、適切な作業を実施できるように変更管理を行うものとする。 ケ　情報セキュリティ対策 セキュリティ要件に基づいて必要なセキュリティ設計（機能面、非機能面）を行う方法、脆弱性が含まれないように実装を行う方法、セキュリティ観点でのテストを実施しセキュリティ要件が漏れなく十分に対策ができているかをテストで検証する方法、セキュリティ対策を十分に考慮した運用を行う方法を含め、情報セキュリティの管理手法等について記載する。 6. １. 趣旨 設計・開発を円滑に進めていくためには、ＰＪＭＯと設計・開発事業者の間で、活動を進める上で必要となるルールを明確に定め、合意することが重要となる。また、ＰＪＭＯが、設計・開発を進める上で、利用者、情報システム部門、他の設計・開発事業者等の関係者と調整を行うことも多くあり、適切で実効性のある調整を行うためには、プロジェクト管理要領で定められたプロジェクト全体のルールを関係者が共有し、これに従う必要がある。 このため、ＰＪＭＯは、設計・開発事業者とともに、プロジェクト管理要領と整合性を確保する形で、調達仕様書、要件定義書等に基づき、設計・開発実施要領を作成し、活動の遂行上の指針として関係者で共有する。 7. ２. 解説 #### 「設計・開発実施要領には、プロジェクト管理要領と整合性を確保しつつ、少なくとも次のアからケまでに掲げる事項について記載する」 - 表7-3 設計・開発実施要領の記載内容 設計・開発実施要領の記載事項を示せば、表7-3のとおりである。
定義する事項 記載事項

  1. コミュニケーション管理

 設計・開発工程におけるＰＪＭＯ、設計・開発事業者、関係事業者、関係機関、情報システム利用者等が認識を一致させ、調整事項や課題等を共有した上で合意形成を行うために、連絡調整方法や会議開催方法、情報共有方法等のコミュニケーションの方法を記載する。

  1. 体制管理

 設計・開発工程の作業内容に合致した作業体制を構築・維持するため、作業体制の管理手法を記載する。

  1. 工程管理

ＰＪＭＯ、設計・開発事業者、関係事業者、関係機関、情報システム利用者等が設計・開発の工程（作業項目、日程、工数等）の進捗を共有するために、現在の進捗の可視化方法や将来の見通しの予測方法、遅延発生や工数の過剰投与等の予防及び対処方法等の管理方法を記載する。

また、設計・開発の各工程の完了に先立って、ＰＪＭＯが成果物の内容及び品質状況等を確実に確認し、早期に品質の強化や問題の発見等を行うことを目的として、各工程における完了判定基準、完了判定方法を記載する。

  1. 品質管理

 情報システムをはじめとする成果物が充分な品質となるように、具体的かつ定量的な品質基準を定め、その達成状況を確認し、求める品質が確保されていない場合には、その対応策の検討と実施を行う方法等の品質管理方法を記載する。

  1. リスク管理

設計・開発において目標達成等に悪影響を与える可能性のあるリスクが顕在化した際に適切かつ迅速な対応が取れるようにするため、リスクの認識手法や管理手法、顕在時の対応手順等について記載する。

ただし、リスク管理自体は「第２章２．2)オ リスク管理」の記載事項に従い、プロジェクト全体で一元的に実施するため、本項目では、設計・開発事業者が認識するリスクの基準や記録の方法、どのような手順で報告するかを中心に記載する。

  1. 課題管理

設計・開発業務を遂行する上で発生した課題に対して、迅速かつ適切な対応が取れるようにするため、課題の管理手法や課題発生時の対応手順等について記載する。

ただし、課題管理自体は「第２章２．2)カ 課題管理」の記載事項に従い、プロジェクト全体で一元的に実施するため、本項目では、設計・開発事業者が認識する課題の基準や記録の方法、どのような手順で課題を報告するかを中心に記載する。

  1. システム構成管理

 設計・開発工程において情報システムを構築・稼働するための環境は時系列で準備する必要があることを踏まえ、環境の過不足を無くすために、その構成要素や環境構築スケジュール等を意識した管理する方法を記載する。

  1. 変更管理

設計・開発業務を遂行する上で発生した変更事項の重要性や発生原因を認識し、対応の要否について正しく判断するために、その変更内容を確実に記録し、管理する方法について記載する。

これにより、関連する各工程や作業への連携を図れるようにする。

ただし、変更管理自体は「第３編第２章２．2)キ 変更管理」の記載事項に従い、プロジェクト全体で一元的に実施するため、本項目では、設計・開発事業者が認識する変更事項の基準や記録の方法、どのような手順で変更事項を報告するかを中心に記載する。

  1. 情報セキュリティ対策

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

具体的には、アプリケーションのセキュアコーディング、情報システムの要塞化（ハードニング）、脆弱性や設定不備を網羅的に検出可能な診断の実施等が挙げられるが、この例示に依らず情報システムの特性、状況や費用対効果を踏まえて対策を実施することが重要である。
#### 「品質基準、品質管理方法等について記載する」 「品質基準」とは、調達仕様書で示した目的及び期待する効果を基に、提案書の内容を踏まえ、設計・開発段階の作業ごとに、各成果物が達成すべき品質水準を、具体的かつ定量的な基準値として具体化したものを指す。品質基準には、例えば、設計書の記載量に対するレビュー観点ごとの指摘数、テストにおけるプログラム量に対するテストケース数、不具合数、不具合特性ごとの摘出率等がある。 品質基準の設定に当たっては、情報システムの品質は一様ではなく、全ての品質特性を満足させることが非常に困難であることを理解し、当該情報システムにおいて、どの品質特性を重視すべきかを踏まえて、品質基準を設定することが重要である。 なお、過去の実績に基づいた妥当な基準を定義することが難しい場合もあるため、その場合は、一定期間経過後に見直すことを前提とした暫定的な基準を定める、又は、基準を定めずに実績値を取得する等の対応を行い、まずは実績値の取得を徹底することから始める。 「品質管理方法」とは、品質基準に対して、品質の状況を誰がいつどのように確認・評価し、問題がある場合にどのように対策を行っていくかを定めるものである。 品質管理に当たっては、作業終了時点の最終的な実績値のみを評価するだけでなく、定期的に品質状況を確認することで、作業プロセスの評価も併せて行うことが重要である。 ### 設計・開発実施計画書等の調整・確定 ＰＪＭＯは、**設計・開発実施計画書等の案を、関係機関と調整し、確定する(1)**ものとする。 8. １. 趣旨 ＰＪＭＯが設計・開発事業者等の支援を受けて作成した設計・開発実施計画書等の案を、関係機関と調整せずに確定した場合、各作業における協力が十分に得られず、予定どおりに作業を遂行できなくなるおそれがある。 このため、ＰＪＭＯは、設計・開発実施計画書等の案を、関係機関と調整し、プロジェクト全体としての整合性を踏まえた上で、内容を確定する。 9. ２. 解説 #### 「設計・開発実施計画書等の案を、関係機関と調整し、確定する」 「関係機関と調整し」とは、設計・開発実施計画書等の作成による具体化・詳細化の結果として関係機関に影響が発生する場合に、関係機関にその内容を調整することを指す。 設計・開発実施計画書等の調整・確定の観点と調整先の例を次に示す。 - あらかじめ調達仕様書において、要件定義について事業者に提案又は代替案を求める旨の記載があり、提案又は代替案が妥当かつ合理的であると判断した場合は、ＰＪＭＯは、それらについて利用者、情報システム部門、他の設計・開発事業者等との調整を行う。 - 相互に密接に関係し、定期的な情報共有が必要なプロジェクトが存在する場合は、ＰＪＭＯは、コミュニケーション管理等の内容について各プロジェクトを担当するＰＪＭＯと調整を行う。 - ＰＭＯが指定したプロジェクトにおいては、ＰＪＭＯは、ＰＭＯと内容全般を共有した上で、工程レビュー等のマイルストーンの調整を行う。 ## 設計・開発工程に入る前の要件定義の内容の調整・確定 ＰＪＭＯは、調達手続開始後の事情の変化、受注者等の提案等を踏まえ、要件定義の内容に関する認識そごの防止及び不確定事項への対応方針の確定のため、関係機関、情報システムの利用者、設計・開発事業者、関係事業者等と、**要件定義の内容について確認及び調整の上、要件定義を確定する(1)**ものとする。 10. １. 趣旨 調達手続後の状況の変化等により要件に不確定事項がある場合や、調達仕様書で示した要件に対して受注者に提案又は代替案を求めている場合には、要件の確定、提案又は代替案の採否を決定する必要がある。また、受注者の提案書の内容により、要件の見直しが必要になる場合もある。これらの内容を要件定義に反映せずに設計・開発を進めた場合、後工程において要件変更が発生し、作業工数の増大やスケジュール超過が発生するリスクがある。 このため、設計・開発を開始する前に、不確定事項の検討結果等を要件定義に反映し、関係者で調整を行い、要件定義の内容を確定する。 11. ２. 解説 #### 「要件定義の内容について確認及び調整の上、要件定義を確定する」 「要件定義の内容について確認及び調整」とは、調達手続開始後の事情の変化、受注者等の提案等の内容を踏まえて変更された要件定義の内容を関係者に確認し調整することを指す。 調整の観点と調整先を次に示す。 - 提案書において要件定義書からの要件変更を提案し、変更内容が妥当かつ合理的な場合は、ＰＪＭＯは、設計・開発事業者及び利用者、情報システム部門等との調整を行う。 - 調達手続開始後に要件に関する問題が明らかになった場合は、ＰＪＭＯは、設計・開発事業者及び利用者、情報システム部門等との調整を行う。 - 通常処理だけでなく、例外処理に関して追加して考慮すべき事項が生じた場合は、ＰＪＭＯは、設計・開発事業者及び利用者、情報システム部門等との調整を行う。 - 調達手続開始後に業務改善や制度変更が発生し、要件に影響する場合は、ＰＪＭＯは、設計・開発事業者及び利用者、情報システム部門等との調整を行う。 - 相互に密接に関係する他の情報システムにおいて、調達手続開始後にシステム間で調整が必要なデータ連携や運用方法、サービスレベルの要件等に変更が生じた場合は、ＰＪＭＯは、設計・開発事業者及び各情報システムを担当するＰＪＭＯ、ＰＭＯ等との調整を行う。 ## 第二次工程レビューの実施 ＰＭＯが指定したプロジェクトについて、ＰＪＭＯは、設計・開発工程に入る前の要件定義の確定を行う前までに、「第２章４．2) プロジェクトの工程レビュー」に基づき、第二次工程レビューを実施するものとする。 12. １. 趣旨 工程レビューは、「第２章４．2)プロジェクトの工程レビュー」のとおり、プロジェクトの進捗、品質等に影響する課題・不具合等を早期に発見し、プロジェクトの円滑な遂行及びプロジェクトの目標達成を確実に行うためのものである。 ＰＪＭＯは、「第２章４．2)プロジェクトの工程レビュー」及びデジタル庁が定める手順に従って自己点検を行い、その結果をＰＭＯに送付する。また、ＰＭＯ又はデジタル庁からのヒアリングに対して必要な報告を行い、指摘、助言又は指導を受けた際は、必要な対応策を講ずる。 なお、ＰＭＯが指定したプロジェクトを対象としたものであるが、自己点検は、どのようなプロジェクトにあってもプロジェクトを成功に導くために必要な留意点を点検するものであり、ＰＭＯが指定したプロジェクト以外のプロジェクトにおいても実施する必要がある。 ## 設計の実施・管理 ＰＪＭＯは、設計に当たって、次のとおり取り組むものとする。**設計の対象には目的とする情報システムの移行・運用・保守設計、教育の計画を含める(1)**ものとする。 ＰＪＭＯは、プロジェクトが円滑に実施されるよう、**設計・開発事業者とともに、情報システムの利用者、関係機関、関係事業者等と調整を行い、それぞれと設計内容について合意する(2)**ものとする。 なお、**開発手法として、アジャイルを採用した場合は、設計の内容に応じて、要件定義の見直しが発生することを考慮する(3)**。 設計の実施に当たっては、画面、帳票等の利用者にとって直接的に理解することができる基本設計を行った後に、機能を実現するための詳細設計を行うものとする。 1) 設計の準備 ＰＪＭＯは、設計・開発事業者に対し、**システム方式の設計及び開発手法、開発ルール、設計成果物、設計・開発を遂行するために必要な開発体制及び詳細開発スケジュール、各種環境に係る計画書の作成を求め(4)**、提出を受けた後、要件定義の内容との整合性、成果物や計画の妥当性等を確認し、**課題等の指摘又は指導を行う(5)**ものとする。 2) 機能の設計 ＰＪＭＯは、設計・開発事業者に対し、**要件定義の機能要件を具体化・詳細化した画面、帳票、データ、外部インタフェース、バッチ等に関する設計の内容とともに、要件定義との整合性の確認結果の報告を求める(6)**。ＰＪＭＯは設計・開発事業者とともにその内容の確認を行い、課題等の指摘又は指導を行うものとする。 ＰＪＭＯは、設計・開発事業者に対し、**設計の内容を標準化し、情報システムの拡張性や柔軟性に配慮することを求める(7)**ものとする。また、**データの設計においては、既存の業務や情報システムで取り扱われているデータとして、「第４章２．現状の把握と分析」で収集したデータ、又は再取得した最新のデータを設計・開発事業者に提供し、調査を求める(8)**ものとする。また、デジタル３原則に掲げるワンスオンリー（一度提出した情報は、二度提出することを不要とする）の観点から、他システムとデータを連携することを検討する。 3) 非機能の設計 ＰＪＭＯは、設計・開発事業者に対し、**要件定義の非機能要件を踏まえたクラウドサービス・ハードウェア・ミドルウェア・ソフトウェア等の構成や設定等に関する設計の内容の報告を求め(9)**、提出を受けた後、要件定義の内容との整合性を確認し、課題等の指摘又は指導を行うものとする。 4) 移行の計画・設計 ＰＪＭＯは、**本番環境への業務移行、システム移行及びデータ移行に備えて(10)**、設計・開発事業者に対し、**移行の方法、環境、ツール、段取り等を記載した移行計画書の案の作成を求め(11)**、提出を受けた後、その案について要件定義の内容との整合性を確認するとともに、**移行リスクを低減するため、関係機関、関係事業者等と調整を行うものとする(12)**。 ＰＪＭＯは、設計・開発事業者に対し、**移行計画書の案に基づき、移行に必要となるデータ変換、移行ツール等に関する設計の内容の報告を求め(13)**、提出を受けた後、移行計画書の案の内容との整合性を確認し、課題等の指摘又は指導を行うものとする。 5) 運用・保守の設計 ＰＪＭＯは、設計・開発事業者に対し、**定常時における月次の作業内容及び想定スケジュール等を取りまとめた運用計画書及び保守計画書の案の作成を求め、提出を受ける(14)**ものとする。その際、保守と契約不適合責任の範囲内で実施する作業の分担を明確にするよう留意するものとする。 ＰＪＭＯは、設計・開発事業者に対し、**運用計画書の案に基づき、運用ツールに関する設計の内容の報告を求め(15)**、提出を受けた後、運用計画書の案との整合性を確認し、課題等の指摘又は指導を行うものとする。 ＰＪＭＯは、**設計・開発事業者等とともに、定常時及び障害発生時において想定される運用体制、実施手順等を取りまとめる(16)**ものとする。なお、複数の情報システムにより業務で利用されるサービスが構築される場合には、サービス提供者、運用事業者及び保守事業者の間で必要な作業が行われるよう作業分担、実施手順等を明確にするよう留意するものとする。 6) テストの計画 ＰＪＭＯは、設計・開発事業者に対し、**単体テスト、結合テスト及び総合テストについて、テスト方針、テスト体制、テスト環境、作業内容、作業スケジュール、テストシナリオ作成基準、合否判定基準等を記載したテスト計画書の案の作成を求め(17)**、提出を受けた後、テストの十分性を確認し、課題等の指摘又は指導を行うものとする。 13. １. 趣旨 政府における情報システムの整備においては、発注者側がまとめた要件定義に基づき、設計・開発事業者がその内容を理解した上で設計・開発を行うことが一般的である。 このため、ＰＪＭＯは、設計・開発事業者から設計の検討内容の報告を受け、要件定義の全ての内容が意図したとおりに検討内容に反映されているかを基本的な観点として確認し、不備があれば課題等の指摘又は指導を行うとともに、他の関係者との設計内容等の調整を適切に行うことで、情報システムの品質確保を行う。 なお、設計・開発の成果物は、運用及び保守の工程においても引き続き参照・利用されるものであることから、第三者であっても適切に理解できるように、公文書として適切な用語や標準的な技術用語を用いて作成する必要がある。 14. ２. 解説 #### 「設計の対象には目的とする情報システムの移行・運用・保守設計、教育の計画を含める」 「設計の対象には目的とする情報システムの移行・運用・保守設計を含める」とは、情報システムを稼働するために必要となる全ての作業や機能を漏れなく考慮するために、情報システムの機能・非機能の設計と並行で移行・運用・保守の設計を求めるものである。これにより、それぞれの設計内容が相互に共有し、設計の過不足が発生させないことに留意する。 なお、運用計画書及び保守計画書は、「第９章 運用及び保守」にて、運用事業者及び保守事業者の支援を受けて確定することが一般的であるため、設計において作成される運用計画書及び保守計画書の記載内容によって、運用及び保守工程の調達において特定のベンダーしか応札できなくなるということにならないよう留意する。 #### 「設計・開発事業者とともに、情報システムの利用者、関係機関、関係事業者等と調整を行い、それぞれと設計内容について合意する」 「設計内容について合意する」とは、要件定義の内容を設計として具体化・詳細化していく過程で、他の関係者に影響を及ぼす可能性がある事項が判明した場合に、その内容を関係者に共有し、対処を決定し、合意することを指す。 他の関係者との調整については、調整が遅れた場合に活動の実施に大きな影響を与えることも多いため、プロジェクトの円滑な遂行のためにも、判明し次第、できる限り早い段階で関係者と共有し、対処等の合意を行うことが重要である。 設計内容の合意が必要な場合の例を次に示す。 - 設計内容検討において、要件の瑕疵（要件の不確実、不足又は過剰）が判明し、要件の見直しを含め具体的な対応を検討した場合。 - 例外処理等に関し要件では不明瞭であったが、設計内容検討において具体的な対応を検討した場合。 - 設計段階で業務改善や制度変更の具体化が行われ、それに合わせて設計内容検討において具体的な対応を検討した場合。 - 画面・帳票等に関し、設計内容検討によって具体化した内容に対して、情報システムの利用者のニーズ等への対応状況の確認が必要な場合。 - 情報システム間で調整が必要なデータ連携や運用方法、ＳＬＡの具体的な内容に関し、関係する他システムの関係者に確認が必要な場合。 - 各府省が共通で利用する政府情報システムを利用する場合において、運用や保守方法の具体化に当たり、当初の想定から変更が生じた場合。 #### 「開発手法として、アジャイルを採用した場合は、設計の内容に応じて、要件定義の見直しが発生することを考慮する」 「設計の内容に応じて、要件定義の見直しが発生することを考慮する」とは、アジャイル開発の手法を用いる場合に、関係者と要件を確認するタイミング、要件の見直しが入った際の対処方法を計画しておくことを指す。 ＰＪＭＯは、アジャイル開発手法の特徴を踏まえ、要件定義の内容が設計の内容に確実に反映されているかを確認するタイミングについて、設計・開発事業者と事前に取り決め、合意する必要がある。ＰＪＭＯ及び業務実施部門は、定められたタイミングで内容の確認を行い、要件定義内容と設計内容にそごがないことを確認する。要件定義内容に変更が発生した場合は、設計・開発実施要領の変更管理の対象として扱う。 ### 設計の準備 #### 「システム方式の設計及び開発手法、開発ルール、設計成果物、設計・開発を遂行するために必要な開発体制及び詳細開発スケジュール、各種環境に係る計画書の作成を求め」 「システム方式の設計」とは、「第５章２．1)エ システム方式の決定」で定義した複数の情報システム全体構成の実現案について、設計・開発事業者の提案を踏まえて利用する技術要素を決定し、情報システムの構成内容を確定することを指す。 「開発手法、開発ルール、設計成果物、設計・開発を遂行するために必要な開発体制及び詳細開発スケジュール」とは、設計・開発実施計画書の当該事項を具体化・詳細化したものを指す。これらの事項は、システム方式の設計により決定した利用技術や構成内容により、計画を具体化・詳細化することが可能となるため、システム方式の設計後に具体化・詳細化を設計・開発事業者に求める。 「各種環境に係る計画」とは、情報システムの実装や各テスト、サービス提供に必要となるハードウェア・ミドルウェア・ソフトウェア等の環境について、いつどの環境が必要となるか、誰がいつ環境を構築するか、誰がどの環境を利用するか、を計画することを指す。環境の準備には一定の期間が必要となることが一般的であるため、各種環境に係る計画は、情報システムの全体構成が決定し次第、設計・開発事業者に作成を求める。 #### 「課題等の指摘又は指導を行う」 「課題等の指摘又は指導を行う」とは、設計・開発事業者から提出を受けた内容に対して、ＰＪＭＯが確認した結果、内容に不備、不足、過剰、不一致又は矛盾が発生している事項がある場合、その事項を課題として整理し、設計・開発事業者に対して指摘又は指導を行うことを指す。 課題は管理表に取りまとめ、課題箇所及び指摘事項を明らかにした上で、設計・開発事業者に指摘又は指導する。重大課題や他の工程に影響する課題、発生原因の分析等が必要な課題は、設計・開発実施要領の課題管理の対象とし、進捗報告会等での共有を図り、関係者での迅速な解決に努める。 設計・開発事業者は、課題について対応方針を検討し、修正方法（修正箇所・修正内容）を提案し、ＰＪＭＯと合意した上で修正を行う。設計・開発の成果物の修正前後を記録するとともに、修正理由や未修正箇所の未修正理由の記録を残すことで、後工程で疑義が生じたときの判断資料とすることに留意する。 なお、要件の瑕疵（要件の不確実、不足又は過剰）が判明し、要件の見直しを行う場合は、当該要件の見直し内容を設計・開発実施要領の変更管理の対象として扱う。 ### 機能の設計 #### 「要件定義の機能要件を具体化・詳細化した画面、帳票、データ、外部インタフェース、バッチ等に関する設計の内容とともに、要件定義との整合性の確認結果の報告を求める」 「要件定義の機能要件を具体化・詳細化した画面、帳票、データ、外部インタフェース、バッチ等に関する設計」とは、要件定義の機能要件及びシステム方式の設計に基づいて、情報システムの機能要素ごとに構成や処理内容を設計として具体化・詳細化することを指す。 なお、ハードウェア又はソフトウェアの賃貸借又は買取りの調達に当たり、設計･開発工程での設計内容検討に基づき調達手続を行う場合は、本作業を行った上で調達仕様書を作成する。 #### 「設計の内容を標準化し、情報システムの拡張性や柔軟性に配慮することを求める」 「設計内容を標準化し、情報システムの拡張性や柔軟性に配慮することを求める」とは、設計以降の開発・テストの効率性を高めるとともに、将来の機能改修や更改時のベンダーロックインの排除を目的として、設計・開発事業者に対して、設計の記述内容が、過度に特定の技術に依存せずに一貫性を持ち第三者が内容を客観的に理解することができる記述内容となるよう、設計の記述要領を定め、徹底することを求めることを指す。 また、ＰＪＭＯは、設計書の記述内容に保守性や柔軟性等の配慮が行われていることを効率的に確認するために、設計前又は設計開始後の早い段階において、設計の記載要領の確認や先行して作成された設計の内容を確認することが望ましい。 #### 「データの設計においては、既存の業務や情報システムで取り扱われているデータとして、「第４章２．現状の把握と分析」で収集したデータ、又は再取得した最新のデータを設計・開発事業者に提供し、調査を求める」 「データの設計」とは、情報システムが格納するデータの種類、形式、構造、項目、権限等を具体化・詳細することを指す。 既存の業務や情報システムが存在する場合は、データ移行も踏まえて設計を検討する必要があるため、「第４章２．現状の把握と分析」で収集した内容（収集後に変更が行われている場合は最新の内容）を設計・開発事業者に提供し、内容の確認を求める。 また、データの設計に当たっては、原則として、政府において標準化された情報・データ名称、データ構造等を採用するとともに、各データが当該情報システム内における利用だけでなく、オープンデータとしての活用が行われることを前提として設計することに留意する。 ### 非機能の設計 #### 「要件定義の非機能要件を踏まえたクラウドサービス・ハードウェア・ミドルウェア・ソフトウェア等の構成や設定等に関する設計の内容の報告を求め」 「非機能要件を踏まえたクラウドサービス・ハードウェア・ミドルウェア・ソフトウェア等の構成や設定等に関する設計」とは、情報システムを構成するクラウドサービス・ハードウェア・ミドルウェア・ソフトウェア・ネットワーク等の環境について、要件定義の非機能要件の内容及びシステム方式の設計に基づいて、それらの構成、設計内容及び環境を維持するために必要となる機能等を設計として具体化・詳細化したものを指す。 ### 移行の計画・設計 #### 「本番環境への業務移行、システム移行及びデータ移行に備えて」 「移行」とは、構築した情報システムを用いたサービス・業務を開始するために必要となる環境の整備及び切替え作業を指し、その内容は、業務移行、システム移行、データ移行に大別される。 「業務移行」とは、現在実施している業務から「第４章サービス・業務企画」で企画した新たな業務に切り替えるための作業を指す。業務移行の計画においては、切替えの時期や期間、拠点、方法等を明確にするとともに、業務の安定的な切替えを行うために、業務実施担当者に対する教育・訓練や業務リハーサル等の準備とも整合をとった計画とすることが重要である。サービス・業務の開始準備については、標準ガイドライン解説書「第３編第８章１．サービス・業務の運営準備」を参照すること。 「システム移行」とは、本番環境を整備し、利用者が情報システムを利用可能な状態にする作業を指す。また、既存の情報システムが存在する場合は、その利用を停止する作業や他の情報システム側の連携先を新しい情報システムに切り替える等の作業を含む。 「データ移行」とは、現行情報システムが保有するデータ又は現在業務で保有しているデータ等を、新しい情報システムに投入する又は新しい業務で利用できるようにするためのデータ変換に伴う一連の作業を指す。 #### 「移行の方法、環境、ツール、段取り等を記載した移行計画書の案の作成を求め」 「移行計画書の案」とは、移行の対象や方法、体制と役割、移行に必要となる環境、ツールとその概要、移行に関する準備作業及び実際の移行作業の内容とスケジュール等を計画書として記載したものを指す。移行計画書の内容は、開発・テストを経て内容に追加・変更が入ることもあるため、設計段階では移行計画書の案を作成し、移行の実施前に計画書を確定する。 移行計画書は、構築する情報システムの稼働に必要となる環境を整備するための計画であるため、構築する情報システムの設計内容を踏まえたものにする。さらに、現行の業務や情報システムが存在する場合はその資産を適切に引き継ぎ、現在の業務運用状況や現行情報システムの状況を鑑みた現実的かつ実行的な計画とすることが必要である。そのため、移行計画書の作成に当たっては、現行事業者や情報システム利用者等と調整し、現在の業務運用状況や現行情報システム状況を充分把握した上で行う。 #### 「移行リスクを低減するため、関係機関、関係事業者等と調整を行うものとする」 「移行リスク」とは、移行を行うことにより既存の業務、情報システム、データに対し発生することが予想される問題を指す。例を次に示す。 - 移行作業期間中、利用者へのサービス提供が停止する期間が発生する。 - システム方式の変更に伴い、連携先の情報システムからアクセスできなくなる。 - データ移行に伴い一部のデータが消失する。 移行に伴い影響を受ける対象を漏れなく抽出し、その影響を最小限に留めるよう移行計画時に十分な検討と調整を行うこと。 #### 「移行計画書の案に基づき、移行に必要となるデータ変換、移行ツール等に関する設計の内容の報告を求め」 「移行に必要となるデータ変換」とは、現行情報システムが保有するデータ又は現在業務で保有しているデータ等を、構築する情報システムに投入する又は新業務で利用可能とするためのデータの変換を指す。データ変換には、データ形式の編集やデータ構造の変更だけでなく、コード値の付与や重複データの統合・除去等様々な変換作業があり、設計・開発事業者が機械的に変換だけでなく、ＰＪＭＯや職員の確認や修正等が必要な場合もある点に留意する。 ### 運用・保守の設計 #### 「定常時における月次の作業内容、その想定スケジュール等を取りまとめた運用計画書及び保守計画書の案の作成を求め、提出を受ける」 - 参考 第９章１．2) 運用計画書の作成と確定 第９章１．4) 保守計画書の作成と確定 「運用計画書及び保守計画書の案」とは、情報システムの日々の安定稼働を確保するために必要となる具体的な監視項目や作業項目、作業体制、作業スケジュール、整備対象の文書、成果物、形態や環境等の保守又は運用の定常的な計画をまとめたものを指す。なお、作業内容は月次を基本とし、期次・年次等の業務サイクルも考慮すること。 運用計画書及び保守計画書は、定常時のみならず障害発生時においても、定められた品質水準で業務を遂行する計画とすることが必要である。そのため、運用計画書及び保守計画書の案の作成は、情報システムの設計の検討と同時に実施し、設計内容を踏まえ仕様及び構成の変更を行わず稼働状態を維持できる運用方法、機能維持、品質維持のための保守方法を可能とする情報システムを設計、開発すること目指すことが必要である。 #### 「運用計画書の案に基づき、運用ツールに関する設計の内容の報告を求め」 「運用ツール」とは、運用の実施において作業の正確性や効率性、セキュリティ等を担保するために必要となる運用を補助するツールを指す。ＰＪＭＯは、運用計画書の案に基づいて、定常的又は障害発生時に発生する作業に対してツールの必要性を判断し、設計・開発事業者に運用ツールの設計を求める。 #### 「設計・開発事業者等とともに、定常時及び障害発生時において想定される運用体制、実施手順等を取りまとめる」 「運用体制、実施手順等を取りまとめる」とは、運用計画書及び保守計画書で定めた運用体制及び保守体制を踏まえ、当該情報システムの運用及び保守に関わる詳細な関係者の役割、作業分担、作業項目に応じた実施手順等を明確にし、文書化することである。 情報システムの日々の安定稼働を確保するためには、契約内容に応じた運用事業者及び保守事業者の連携体制を確立することが不可欠である。また、ＰＪＭＯと事業者間で適切な連絡、連携を図れるようにすることが、定常時のみならず障害発生時において重要となる。 運用作業及び保守作業を一体化させた契約を行う場合等には、運用体制と保守体制が一本化されることも多いが、その場合においても、各担当者の役割、作業分担及び実施手順を明確にする点に留意する。 ### テストの計画 #### 「単体テスト、結合テスト及び総合テストについて、テスト方針、テスト体制、テスト環境、作業内容、作業スケジュール、テストシナリオ作成基準、合否判定基準等を記載したテスト計画書の案の作成を求め」 「テスト計画書の案」とは、開発した情報システムが要件定義及び設計の内容どおりに動作することを確認するための計画の案を指す。テスト計画書は、要件定義書及び設計書の内容を踏まえたものにすると同時に、設計・開発実施要領で定義した品質管理方法を遵守する方式とする必要がある。よって、ＰＪＭＯは、設計・開発事業者から提出された計画書案を参考に、主体的に確認し、承認するものとする。また、各テストの目的に鑑み、テスト種別に応じたテスト内容が含まれているかを確認するよう留意する。 なお、総合テストには、負荷テストや災害対策訓練等の運用を想定したテスト内容も含まれるよう考慮する。 ## 開発・テストの実施・管理 ＰＪＭＯは、開発・テストに当たって、次のとおり取り組むものとする。 1) 機能の実装・単体テスト ＰＪＭＯは、設計・開発事業者に対し、**実装及び単体テストの実施状況の報告を求め(1)**、報告内容を確認し、課題等の指摘又は指導を行うものとする。 2) 環境の設定 ＰＪＭＯは、設計・開発事業者に対し、**非機能の設計に応じた内容で各種環境の構成やパラメータ等の設定の報告を求め(2)**、報告内容を確認し、課題等の指摘又は指導を行うものとする。 3) 移行ツールの実装及び移行データ・移行手順書等の作成 ＰＪＭＯは、保有・管理するデータを情報システムに移行する場合には、設計・開発事業者に対し、**新規情報システムのデータ構造、保有・管理するデータの標準的及び例外的な変換方法、移行要領、移行手順書を作成させ(3)**、承認を行うものとする。 4) 運用ツールの実装及び運用手順書等の作成 ＰＪＭＯは、運用を補助するためのツールが必要となる場合には、設計・開発事業者に対し、**当該ツールの実装及び単体テストの実施状況の報告、運用ツールの操作方法等に関する手順書の作成を求め(4)**、提出を受けた後、テスト内容の十分性や手順書の妥当性等を確認し、課題等の指摘又は指導を行うものとする。 5) システム操作マニュアルの作成 ＰＪＭＯは、設計・開発事業者と協力し、**情報システムの操作方法を示したシステム操作マニュアルを作成する(5)**ものとする。システム操作マニュアルの作成に当たっては、利用者の視点から業務実施時における一連の操作手順が分かりやすい記載となるように留意する。国民等の多数の利用者が参照するシステム操作マニュアルについては、**利用環境に応じて閲覧・検索しやすい形式で提供する(6)**よう努める。 6) テスト仕様書の作成・テストの実施 ＰＪＭＯは、設計・開発事業者に対し、結合テスト及び総合テストについて、テスト計画書を基に、**テスト方針、テスト体制、テスト環境、作業内容、作業スケジュール、テストシナリオ、合否判定基準等を詳細化・具体化したテスト計画書の更新及びテストケース、使用するテストデータの内容等を記載した仕様書の作成を求め(7)**、提出を受けた後、テスト内容の十分性、テストデータの適切性等を確認し、課題等の指摘又は指導を行うものとする。 ＰＪＭＯは、設計・開発事業者に対し、**結合テスト及び総合テストの実施状況の報告を求め(8)**、報告内容を確認し、課題等の指摘又は指導を行うものとする。なお、ＰＪＭＯは、テストの実施状況について、要件定義の内容及び設計内容に照らし、**設定した合否判定基準を全て満たしたと認められる場合に限り、設計・開発事業者に対し、次の工程の開始の承認を行う(9)**ものとする。 7) テスト手順・データの再利用対策 ＰＪＭＯは、設計・開発事業者に対し、**将来の保守や更改時におけるテスト工程の合理化に資するため、ツールを利用したテスト環境の構築を求める(10)**。 設計・開発事業者は、テスト環境に必要なテストシナリオ・スクリプト、テストデータ等を保存し、保守後等の動作確認等において、それらを一部改変して再利用できるようにするものとする。 15. １. 趣旨 政府情報システムの整備において、開発・テストの活動は、設計・開発事業者が、要件定義に基づき設計及び情報システムの整備や改修等を行い、それらが要件定義書及び設計書の内容と整合性が取れたものとなっているかをテストにより確認することが一般的である。 これらは、設計・開発事業者が主として行うが、テストを進める中で要件定義や設計の不備等の課題等が頻繁に発生し、その対処が適切にとられない場合には、情報システムがリリースできないか、できたとしてもプロジェクトの目標を達成するための十分な機能・品質を備えられないことも多い。 このため、ＰＪＭＯは、設計・開発事業者と蜜にコミュニケーションを取り、開発・テストの進捗状況やテストによる品質状況の確認を主体的に行うとともに、課題等が発生した際は、設計・開発実施要領の課題管理にしたがって設計・開発事業者とともに対応を検討・決定し、関係者との調整を行う。 16. ２. 解説 ### 機能の実装・単体テスト #### 「実装及び単体テストの実施状況の報告を求め」 「実装及び単体テストの実施状況」とは、設計・開発実施計画書のスケジュールに対する実装作業の進捗状況、テスト計画書に基づき実施する単体テストの進捗状況、テスト結果、品質状況を指す。 ### 環境の設定 #### 「非機能の設計に応じた内容で各種環境の構成やパラメータ等の設定の報告を求め」 「各種環境の構成やパラメータ等の設定」とは、非機能の設計に基づいた環境ごとに設計の内容をより具体化・詳細化し、実際のハードウェア・ミドルウェア・ソフトウェア等の準備や構成の決定、パラメータの設定、動作確認等を行うことを指す。 ### 移行ツールの実装及び移行データ・移行手順書等の作成 #### 「新規情報システムのデータ構造、保有・管理するデータの標準的及び例外的な変換方法、移行要領、移行手順書を作成させ」 「新規情報システムのデータ構造、保有・管理するデータの標準的及び例外的な変換方法」とは、移行計画書の案に基づき、新しい情報システムのデータ構造、既存情報システムや業務から提供されるデータの構造、新しい情報システムに対しデータを投入、変換、確認するための方法等を具体化・詳細化したものを指す。特に、データ変換に関しては、例外的なデータの存在により移行が正常に完了しないことやサービス開始後に不具合を発生させる要因となることも多いため、データの完全性・正確性の確認方法や例外的なデータの発見時の対処方法も含めて明確に定める点に留意する。 「移行要領」とは、移行計画書の案を基に、移行作業項目に応じた移行手順書を作成する上で守るべきルールを取りまとめたものを指す。 「移行手順書」とは、移行作業項目ごとに、作業手順、確認内容を手順書としてまとめたものを指す。移行手順書は、移行作業の実施経験や担当者のスキル等に依存せずに、誰が実施しても間違えずに作業や確認を行えるような記述となっていることが必要である。 ### 運用ツールの実装及び運用手順書等の作成 #### 「当該ツールの実装及び単体テストの実施状況の報告、運用ツールの操作方法等に関する手順書の作成を求め」 「運用ツールの操作方法等に関する手順書」とは、運用ツールの直接の操作方法のみならず、運用ツールの用途、使用するための環境、操作するに当たる事前準備、操作結果の確認方法等を含めた手順書を指す。 ### システム操作マニュアルの作成 #### 「情報システムの操作方法を示したシステム操作マニュアルを作成する」 「システム操作マニュアル」とは、情報システムの操作方法を説明したマニュアルを指す。システム操作マニュアルは、情報システムの利用者の役割ごとに、業務の流れに合わせて作成することが一般的である。ＰＪＭＯは、設計・開発事業者からシステム操作マニュアルの提出を受けた後、記載内容の妥当性等を確認し、課題等の指摘又は指導を行う。システム操作マニュアルの記載内容の妥当性等の確認に当たっては、利用者の視点から業務実施時における一連の操作手順が分かりやすい記載となるように留意する。 なお、情報システムの操作方法を含んだ業務の実施手順については、業務手順書として「第８章１．サービス・業務の運営準備」にて別途作成する。 #### 「利用環境に応じて閲覧・検索しやすい形式で提供する」 「利用環境に応じて閲覧・検索しやすい形式で提供する」とは、利用者視点でシステム操作マニュアルの最適な形式を検討し、提供することを指す。例えば、利用者がＰＣやスマートフォンなどの様々な端末からインターネット経由で複数のシステム操作マニュアルを横断的に閲覧・検索することが想定される場合、目的の情報にたどり着きやすくなるようＨＴＭＬで提供することが挙げられる。ＨＴＭＬは音声読み上げソフトに対応しやすく、アクセシビリティの向上にも繋がる。 ### テスト仕様書の作成・テストの実施 #### 「テスト方針、テスト体制、テスト環境、作業内容、作業スケジュール、テストシナリオ、合否判定基準等を詳細化・具体化したテスト計画書の更新及びテストケース、使用するテストデータの内容等を記載した仕様書の作成を求め」 「テスト計画書の更新」とは、「４．設計の実施・管理」で作成したテスト計画書を、他の設計の内容を踏まえて、具体化・詳細化し、内容を確定することを指す。 「テストケース、使用するテストデータの内容等を記載した仕様書の作成」とは、テスト計画書に基づいて、実際に行うテストの内容を詳細化したテストケース、各テストケースで使用するテストデータをまとめたテスト仕様書を作成することを指す。 #### 「結合テスト及び総合テストの実施状況の報告を求め」 「結合テスト及び総合テストの実施状況の報告」とは、各テスト実施中における進捗状況や課題等の報告と、各テスト終了後の実施結果の報告を指す。 各テスト実施中は、設計・開発事業者は各テストの進捗状況や課題に加え、各テストの実施時に発生したバグや不具合についても、その対応方針や対応状況をＰＪＭＯに報告する。 各テスト終了後は、設計・開発事業者がテスト計画書に基づき実施した各テストに関し、そのテスト結果と分析結果を結合テスト実施報告書、総合テスト実施報告書としてまとめ、ＰＪＭＯに報告する。 #### 「設定した合否判定基準を全て満たしたと認められる場合に限り、設計・開発事業者に対し、次の工程の開始の承認を行う」 「次の工程の開始の承認を行う」とは、実施したテスト結果及び実施状況の報告の内容が、テスト計画書の合否判定基準を全て満たしたと判断できる場合に、設計・開発実施要領の工程管理で定義した工程開始・終了条件も踏まえて、当該工程の終了及び次の工程の開始の承認をプロジェクト推進責任者が行うことをいう。 なお、承認状況、承認理由、承認に当たっての前提条件等の記録を残すことで、後工程で疑義が生じたときの判断資料とすることができる。 ### テスト手順・データの再利用対策 #### 「将来の保守や更改時におけるテスト工程の合理化に資するため、ツールを利用したテスト環境の構築を求める」 「テスト工程の合理化」とは、各テストのテスト計画書と合わせてテストケース（テストスクリプトを含む）、テストデータ、テストツール、テスト実施手順を保存し、運用後の不具合発覚時の原因特定や、保守における改修箇所のテスト実施等の際に、これらを一部改変して再利用することで、効率的にテストを実施することをいう。 特に、アジャイル開発を導入する場合や以降の工程での改修やサービス開始後の保守、機能改修等の場合において、修正箇所が全体的にほかには影響していないことを確認する回帰テストを実施するためには、過去のテストケースやデータ及び結果を、網羅的かつ適切に整理することがテストの効率化に大きく影響する点に留意する。 「ツールを利用したテスト環境の構築」とは、プログラム資産等の管理やテスト環境へのプログラムの配備、自動テスト等を一貫して行うツールを利用して、効率的なテストを行うための環境を構築することを指す。これらの環境を準備することで、回帰テスト等を効率的に行えるようにするのみならず、開発・テストのタスク管理やテスト状況・品質状況の管理を適切かつ容易に行えるようにする。 なお、情報システムの更改等において、やむを得ず本番データをテストデータとして用いる場合や、当該テストデータを再利用の目的で保存する場合には、厳格な情報セキュリティ対策を施す必要がある。 ## 第三次工程レビューの実施 ＰＭＯが指定したプロジェクトについて、ＰＪＭＯは、**遅くとも総合テスト計画書を確定するまでに、「第２章４．2) プロジェクトの工程レビュー」に基づき、第三次工程レビューを実施する(1)**ものとする。 17. １. 趣旨 ＰＪＭＯは、「第２章４．2)プロジェクトの工程レビュー」及びデジタル庁が定める手順に従って自己点検を行い、その結果をＰＭＯに送付し、ＰＭＯ又はデジタル庁からのヒアリングに対して必要な報告を行い、助言、指摘又は指導を受けた際は、必要な対応策を講ずる。 なお、工程レビューはＰＭＯが指定したプロジェクトを対象としたものであるが、自己点検は、どのようなプロジェクトにあってもプロジェクトを成功に導くために必要な留意点を点検するものであり、ＰＭＯが指定したプロジェクト以外のプロジェクトにおいても実施する必要がある。 18. ２. 解説 #### 「遅くとも総合テスト計画書を確定するまでに、「第２章４．2) プロジェクトの工程レビュー」に基づき、第三次工程レビューを実施する」 「遅くとも総合テスト計画書を確定するまでに」とは、情報システムの品質や性能等を十分検証せずに新サービス・業務に切り替えることで生じる問題を回避するために、総合テストでの確認内容やプロジェクトの進捗状況、品質状況等を確認してサービス開始に際する課題・不具合等を早期に発見するとともに、発見された課題等の対処を行う時間や体制等を十分に確保できるようにすることを目的として、第三次工程レビューの実施時期を定めたものである。 ## 受入テストの実施 ＰＪＭＯは、受入テストに当たって、次のとおり取り組むものとする。 1) テスト計画書・仕様書の作成 ＰＪＭＯは、設計・開発事業者の支援を受ける等により、**テスト体制、テスト環境、作業内容、作業スケジュール、テストシナリオ、合否判定基準等を記載した受入テストのテスト計画書及びテストケース、使用するテストデータの内容等を記載した仕様書を作成する(1)**ものとする。 2) 受入テストの実施 ＰＪＭＯは、開発された情報システムが要件定義書に記載した事項を適切に実現しているかどうかを検証するため、**受入テストのテスト計画書に基づき、設計・開発事業者の支援を受けて、本番稼働時のデータに近いテストデータを用いて、受入テストを行う(2)**ものとする。特に、ユーザビリティ要件及びアクセシビリティ要件を検証するときは、業務実施部門、情報システム部門等、主たる情報システムの利用者が受入テストに参加するものとする。 ＰＪＭＯは、受入テストの結果を踏まえ、**設計・開発事業者に対し、課題等の指摘又は指導を行う(3)**ものとする。 19. １. 趣旨 受入テストは、整備された情報システムが、業務要件定義の内容を満たしていることを、設計・開発事業者の支援を受け、発注者側の職員自ら実施するものである。業務要件定義内容が適切に情報システムに反映されているかに関しては、設計・開発事業者が判定することは困難である。 このため、ＰＪＭＯは、受入テストの計画、実施内容、結果の評価までの一連の作業を主体的に推進し、本番移行に進むことが可能な品質状態にあるか確認する。 20. ２. 解説 ### テスト計画書・仕様書の作成 #### 「テスト体制、テスト環境、作業内容、作業スケジュール、テストシナリオ、合否判定基準等を記載した受入テストのテスト計画書及びテストケース、使用するテストデータの内容等を記載した仕様書を作成する」 「受入テストのテスト計画書」とは、当該システムが業務要件定義書の内容を適切に実現しているかを確認するための計画をまとめたものである。 受入テストのテスト計画書の記載事項を示せば、次のとおりである。
記載項目 記載内容
テスト体制

テスト体制について、システム利用者、システム運用者、ＰＪＭＯ、設計開発事業者、その他関係者の体制と役割、責任範囲等を記載する。

設計・開発事業者の品質保証担当も体制に組み込み、不具合発生時に迅速に対応できるようにする。

ユーザビリティ要件を検証するときは、業務実施部門、情報システム部門等、主たる情報システムの利用者が受入テストに参加する。

また、システム運用のみならず業務運営の観点からの確認も行うことが必要なことから、情報システム利用者の積極的な参画や、設計・開発事業者の支援・参画に留意する。

なお、運用業務の円滑な実施に向け、運用事業者に受入テスト段階から参加させ、具体的な運用業務を試行しつつ運用対象である情報システムについてあらかじめ把握させることで、本番運用に備えることが望ましい。
テスト環境

テスト環境について、テストで利用する環境やツール、さらに、それらを利用するための前提条件、特記事項等を記載する。

本番移行への可否を判断する最終段階であることから、テスト環境としては可能な限り本番環境に近い環境を確保する。
作業内容

作業内容について、テストの目的、確認・検証事項、テスト対象・テストケース・テストデータの作成方法、テスト実施手順等を記載する。

本番移行への可否を判断する最終段階であることから、可能な限り本番データに近いテストデータの利用、正常系のみならず異常系のテストデータの利用、新旧システムの運用結果の比較による妥当性確認等を行う。
作業スケジュール

作業スケジュールについて、全体スケジュール、各工程の作業スケジュール等を記載する。

本番移行への可否を判断する最終段階であり、バグ・不具合発生等により仮に期間延長となった場合は、本番リリースのマイルストーンに影響を与える可能性が高いことから、バグ･不具合対応も考慮し、十分なテスト期間を設ける。
テストシナリオ

テストシナリオについて、シナリオ名称、目的、確認・検証事項、テスト結果の予測、テスト結果として求めるエビデンス等を記載する。

一般的には、受入テストは総合テストのテストシナリオを活用する場合が多いが、ユーザ側の観点から追加すべき内容を検討し、ケース（スクリプト）も具体化する。
合否判定基準 合否判定基準について、品質基準、合否判定基準、不合格時の対処方法等を記載する。
- 表7-4 受入テストのテスト計画書の記載事項 受入テストは、設計・開発事業者が実施する総合テストに引き続き実施するものであるため、仮に受入テストで不具合が生じた場合は、再度、開発及びテストを行う必要がある可能性もある。したがって、要件定義、設計等の段階から次に示す準備を進め、受入テストの正確性・必要十分性を高めるとともに、概要を早期に確定させ受入テスト要員の確保の準備を進める。また、設計・開発事業者のテスト計画策定のタイミングから受入テスト計画の策定に着手し、発注者側の意向を結合テスト・総合テストにも反映させることが望ましい。 受入テストのテスト計画書作成前準備として実施すべき作業の例を次に示す。 - 要件定義書に基づき業務の流れを確認し、テストシナリオ、テストケースとして設定すべき事象、特に詳細に確認すべき機能、処理等を特定する。 - 要件定義段階、設計段階の課題管理表を確認し、要件の実装に注意が必要な箇所、発注者側のニーズの実装にそごが生じやすい箇所を特定し、テストシナリオ、テストケースとしての設定方法を整理する。 - 現行情報システムの運用報告書及び保守報告書等を確認し、業務遂行に当たって犯しやすい操作ミス、誤認識しやすい箇所等を特定し、テストシナリオ、テストケースとしての設定方法を整理する。 「テストケース、使用するテストデータの内容等を記載した仕様書」とは、受入テストのテスト計画書のテストシナリオを、テスト項目、テストデータ、テスト方法、テスト環境や状態について具体化・詳細化したものを指す。 ### 受入テストの実施 #### 「受入テストのテスト計画書に基づき、設計・開発事業者の支援を受けて、本番稼働時のデータに近いテストデータを用いて、受入テストを行う」 「本番稼働時のデータに近いテストデータを用いて、受入テストを行う」とは、受入テストが本番移行への可否を判断する最終段階であることから、可能な限り本番に近い状態でテストを行うことで本番稼働時のトラブルを事前に防ぐことを目的に、作成したテスト計画書及びテスト仕様書に従って、テストを行うことを指す。 受入テストは、発注者側が主体となって行うものであり、実際の利用者がテストに参加することが必須である。なお、テスト担当者が情報システムの操作等について十分習熟していない場合は、システム操作説明書等を用いて教育を行う等した上で、受入テストを実施する。 また、不正な処理が行われた場合、操作ミスによるものなのか、バグ・不具合によるものなのかを迅速に切り分けることも重要である。そのため、受入テストをスムーズに行えるよう、設計・開発事業者から支援を受ける必要がある。 #### 「設計・開発事業者に対し、課題等の指摘又は指導を行う」 「設計・開発事業者に対し、課題等の指摘又は指導を行う」とは、受入テストのテスト計画書で定めた合否判定基準を満たさず、課題等がある場合に、課題箇所、指摘事項を明らかにした上で、設計・開発事業者に指摘又は指導し、プログラム等の修正を行わせることを指す。 重大課題や他の工程に影響する課題、発生原因の分析等が必要な課題は、課題管理の対象とし、進捗報告会等で共有した上で、関係者での迅速な解決に努める。 ## 移行の実施・管理 ＰＪＭＯは、本番環境において新しい情報システムを利用するための作業として、次のとおり取り組むものとする。 1) 移行計画書の確定等 ＰＪＭＯは、本番環境への業務移行、システム移行及びデータ移行を行うときは、あらかじめ作成された移行計画書の案（「４．4) 移行の計画・設計」参照）及び移行手順書（「５．3) 移行ツールの実装及び移行データ・移行手順書等の作成」参照）を基に**移行計画書に含まれる移行実施計画の内容を具体化・詳細化し確定させ、これに基づいた作業が行われるよう、管理を行う(1)**ものとする。 なお、移行実施計画に基づき、移行手順書に不足がある場合、ＰＪＭＯは、設計・開発事業者に対し、移行手順書の追加作成を求めるものとする。 2) リハーサルの実施 ＰＪＭＯは、設計・開発事業者に対し、**本番環境への移行手順についてリハーサルの実施を求め、移行シナリオ、移行スケジュールの適切性等を確認し(2)**、課題等の指摘又は指導を行うものとする。 3) 移行判定 ＰＪＭＯは、以下の条件を全て満たす場合に限り、本番移行を開始するものとする。 1. 受入テストにおいて、要件定義に添った内容で、かつ、設定した品質基準を全て満たしたと認められる。 2. ＰＭＯが指定したプロジェクトにあっては第三次工程レビューにおいて問題なく妥当なものと判断される。 3. 移行計画書の内容及びリハーサルの結果が適正であると判断される。 4) 本番環境への移行の実施 ＰＪＭＯは、設計・開発事業者と協力し、移行手順書に基づき、**データを変換・移行した後は、移行後のデータだけでなく、例外データ等についても確認を行い、データの品質の確保を図る(3)**ものとする。 また、ＰＪＭＯは、設計・開発事業者と協力し、移行実施計画及び移行手順書に基づき、本番環境への業務移行、システム移行を行うものとする。 5) 稼働判定 ＰＪＭＯは、本番環境への移行の実施結果が適正であり、新しい情報システムへ切り替えても業務に支障が生じないと判断される場合は、本番稼働を開始するものとする。 6) 本番環境の切替え ＰＪＭＯは、設計・開発事業者と協力し、移行手順書に基づき、本番環境を新しい情報システムに切り替え、本番稼働を開始するものとする。 21. １. 趣旨 情報システムにおける移行は、データ移行が注視されがちであるが、当該プロジェクトで整備した情報システムを利用して新たなサービス・業務の運営を開始するためには、これに加えて、業務、情報システムの移行を行うことが不可欠である。 このため、ＰＪＭＯは業務実施部門、情報システム部門及び現行運用している情報システムの運用・保守事業者等の関係者と調整を行い、移行計画書の案を確定し、「４．設計の実施・管理」「５．開発・テストの実施・管理」「７．受入れテストの実施」の活動にて移行の準備を行い、関係者への影響を最小限に抑えられるよう管理し、正確かつ確実な移行を推進する。 本番環境への移行の実施後、ＰＪＭＯは、本番稼働に必要な品質が確保されているか、本番稼働の準備が十分であるかを判断するため、稼働判定を実施する必要がある。特に「業務移行」については、事業者では最終的な確認が行えないため、職員による稼働判定の実施が不可欠である。 22. ２. 解説 ### 移行計画書の確定等 #### 「移行計画書に含まれる移行実施計画の内容を具体化・詳細化し確定させ、これに基づいた作業が行われるよう、管理を行う」 「移行実施計画の内容を具体化・詳細化し確定させ」とは、設計・開発事業者に対して、設計工程にて作成した移行計画書の案について、他の設計や開発・テストでの変更等の内容により、移行計画書に修正が必要な場合はこれを修正させ、ＰＪＭＯが、内容を確認し、関係者との調整を行い、移行計画書の内容を確定させることである。移行計画書の確定は、遅くとも、移行の各段階（データ移行段階、環境整備段階、本番移行段階）の開始前に該当箇所の確定を行う必要がある。 ＰＪＭＯは、設計・開発事業者や他の関係者が移行計画書の内容に基づいて作業を実施するよう、作業内容及び作業状況の確認し、調整や指導を行う。 - 表7-5 移行計画書の確認観点の例 移行計画書の確認に当たっては、次に示す項目に関して設計の検討内容等が確実に反映されていることを確認する。
確認項目 確認観点の例
移行データ調査

  • 現行情報システムのファイル、ファイルレイアウト、データレイアウト、使用しているコード体系、外字の利用等を調査しているか。

  • 現行情報システムの不備データを調査しているか。

  • 移行対象となるデータを確定できる手順となっているか。

  • 移行データ調査に係るリスクが網羅的に挙げられ、対応策等が整理されているか。
移行データ整備

  • 現行情報システムの移行対象データが次期情報システムのデータとして過不足なく変換される方法となっているか。

  • 不備データが適正に修正される方法となっているか。

  • 次期情報システムで追加されるデータ項目に正しい値が設定される方法となっているか。

  • 移行前データの確認、データ変換前後の整合性チェック、移行データのシステムとの親和性のチェック、基本的な整合性検査（件数チェック、合計値チェック）等、移行データの正確性を保証する方法となっているか。

  • 移行データ整備に用いるツールは十分な機能を有しているか。

  • 移行データに対する機密保護対策が十分か。

  • 移行データ整備に係るリスクが網羅的に挙げられ、対応策等が整理されているか。
本番環境構築

  • 本番環境として用意する情報システム資源は適正か。

  • 本番環境構築手順（既存機器の撤去、新規機器の搬入・設置、移行判定、データ移行、システム移行等）は適正か。

  • 新規機器の搬入・設置に係る各作業（ＯＳインストール、アプリケーションプログラムインストール、ネットワーク・サーバ等各種設定、周辺機器等各種設定、疎通テスト等）に過不足はないか。

  • 本番環境構築の各手順に係る作業量、期間の見積りは妥当か。

  • 本番環境構築に係るＰＪＭＯ、機器設置事業者、設計・開発事業者の体制と役割は適正か。

  • 本番環境構築に係るリスクが網羅的に挙げられ、対応策等が整理されているか。
移行リハーサル

  • 移行リハーサルにかかる作業量・移行所要時間の見積りは適正か。

  • 移行リハーサルに用いるデータは適正か。

  • 移行リハーサルにおいてＰＪＭＯの関与・役割は適正か。

  • 移行リハーサルに用いる環境は適正か。

  • 移行リハーサルにより明らかになる課題・問題等は適正に対処、管理され、移行リスクを低減する方法となっているか。

  • 移行データリハーサルに係るリスクが網羅的に挙げられ、対応策等が整理されているか。
移行判定

  • 移行判定項目は網羅性、完全性、正確性が確保されているか。

  • 移行判定基準は客観性を有し、曖昧性が排除された妥当性の高いものか。

  • 移行判定基準を満たさない場合の再実施手順は適正か。

  • 移行判定に係るリスクが網羅的に挙げられ、対応策等が整理されているか。
本番切替え

  • 移行方式により業務遂行に対し障害は発生しないか。

  • 本番切替え実施手順（移行判定、本番切替え、本番切替え判定、切戻し等）は適正か。

  • 本番切替え不成功時の切戻し条件及び方法が明確であり適正か。

  • 本番切替えに係るリスクが網羅的に挙げられ、対応策等が整理されているか。
### リハーサルの実施 #### 「本番環境への移行手順についてリハーサルの実施を求め、移行シナリオ、移行スケジュールの適切性等を確認し」 「リハーサルの実施」とは、移行手順、移行ツール、移行スケジュール等の適切性等を確認することを目的として、できる限り本番移行と同等の環境・データを用いて、本番移行と同じ手順・スケジュールで移行作業の予行演習を行うことをいう。 本番移行の完了遅延や移行不備はサービス・業務に多大な影響を与えることが多いため、リハーサルは複数回計画、実行し、その結果を確認した上で、手順やツール等の修正や改善を行い、リハーサルにて再度検証を行う。また、不測の事態が発生した場合の対処についても、リハーサルで確認することが望ましい。 ### 移行判定 「移行判定」とは、安定稼働を確実に行うために、移行作業の実施及び本番稼働の可否を最終判断することである。ＰＪＭＯは、受入テスト結果、第三次工程レビュー結果、移行計画書及びリハーサルの全てを網羅的に確認し、判断を行う。 ＰＪＭＯは、受入テスト結果（工程終了判定）、第三次工程レビュー結果（合格）、移行計画書確認結果（内容確定）及びリハーサルの結果（問題が全て解決されている）の確認に基づき、本番移行工程の開始判定を行う。 ### 本番環境への移行の実施 #### 「データを変換・移行した後は、移行後のデータだけでなく、例外データ等についても確認を行い、データの品質の確保を図る」 「移行後のデータだけでなく、例外データ等についても確認を行い」とは、移行手順又は移行ツールにより、移行を行ったデータに対して、整合性や正確性等の観点で確認を行うとともに、他の関係者が手作業での投入や変更等を行ったデータについても、整合性や正確性等を確認することを指す。 特に複数の関係者で役割を分担して作業を行う場合等は、データの確認が漏れなく行われるよう配慮する。 ## 引継ぎ ＰＪＭＯは、情報システムの整備後の事業者変更のリスクを最小限に抑えつつ、円滑かつ効率的に当該情報システムを運用するため、設計・開発事業者に対し、**運用事業者及び保守事業者に設計・開発の設計書、作業経緯、残存課題等を確実に引き継ぐよう求める(1)**ものとする。 23. １. 趣旨 引継ぎは、設計・開発段階から運用及び保守段階へと活動を進めるに当たり、設計・開発と運用・保守が分離調達となるときは、委託する業務の確実な履行を可能とするために必要不可欠である。 このため、ＰＪＭＯは、設計・開発事業者に対し、運用事業者及び保守事業者に引継書を用いた引継ぎを行うこと、ＰＪＭＯ並びに運用事業者及び保守事業者に設計・開発に係る各種資料等の共有、説明を行うことを求める。ＰＪＭＯは、引継ぎ期間内に運用事業者及び保守事業者に対する確実な引継ぎがなされたか、各事業者の習熟度を確認し、円滑かつ効率的に当該情報システムを運用するための準備を行う。 24. ２. 解説 #### 「運用事業者及び保守事業者に設計・開発の設計書、作業経緯、残存課題等を確実に引き継ぐよう求める」 「確実に引き継ぐ」とは、ＰＪＭＯが次に示す作業を実施し、設計・開発事業者から運用事業者及び保守事業者に、あらかじめ契約で定めた内容を漏れなく引き継ぐことを指す。 - 表7-6 引継ぎ作業項目 なお、運用・保守段階における機能改修や次期更改等に対する公正性及び競争性を担保できるよう、設計・開発事業者に対して、調達仕様書の成果物の取扱いに関する事項（「第６章３．1) キ 成果物の取扱いに関する事項」）を踏まえ、漏れなく引継ぎを行うよう求める。
作業項目 内容
引継ぎ前準備

ＰＪＭＯ及び設計・開発事業者は、運用開始前に契約書の内容を踏まえ、表7-8の例を参考に引き継ぐべき各種資料等を明確にし、引継ぎ対象、引継ぎ時期、引継ぎ方法を明確にし、合意する。

設計・開発事業者は合意内容に基づき引継書の作成及び引継ぎに向けた準備を進める。
引継会議等の開催

情報システムに関連する各種資料等を確実に引き継ぎ、運用事業者及び保守事業者の監督を行うため、ＰＪＭＯは必要に応じて引継会議等を開催し、設計・開発事業者から運用事業者及び保守事業者と一緒に説明を受け、自らも各種資料等を把握する。また、引き継いだ資料は、決められた保管場所、保管方法により適切に管理する。

なお、設計・開発により整備された情報システムに対し、その機能維持や品質維持等を目的として実施されるのが保守業務であることから、調達仕様及び保守作業計画において、設計・開発事業者が契約不適合責任の範囲内で実施する修理等作業と保守事業者による保守作業とのそれぞれの責任分界点を明確にすることが必要であると同時に、引継会議の中でも、ＰＪＭＯ及び両者がその内容について合意することが必要である。
運用及び保守等現場確認 情報システムに関連する各種資料等を適切に引き継ぎ、運用事業者及び保守事業者の監督を確実に行うため、ＰＪＭＯは現場確認を実施し、設計・開発事業者から運用事業者及び保守事業者と一緒に説明を受け、情報システムの設置状況や運用監視環境の現場を把握する。
- 表7-7 引継ぎ資料の例
資料名 内容
引継書

  • 引継ぎ資料一覧

  • 課題、リスク引継事項

  • 案件特性及びシステム特性に伴う個別引継ぎ事項
設計・開発関連資料

  • 要件定義書

  • 標準コーディング規約等プログラミング等のルールを定めた標準に関する資料

  • 設計書（基本設計書、詳細設計書、実体関連図（ＥＲＤ）、データ定義表、情報システム関連図、ネットワーク構成図、ソフトウェア構成図、ハードウェア構成図、プログラム一覧等、環境構築手順書、環境定義書、ハードウェア・ソフトウェア機器の一覧、外部インタフェース仕様書等）

  • ノンプログラミングによる自動生成等のツールを利用する場合、設計書やソースコード一式の生成等に利用される設定情報その他の必要な情報一式

  • プロトタイプを作成する場合、当該プロトタイプの設定情報その他の必要な情報一式

  • テスト計画書

  • テスト仕様書

  • テスト結果報告書（テスト証跡も含むが、引継ぎ範囲はＰＪＭＯと協議の上、決定すること）

  • 受入テスト計画書（案）

  • 受入テスト仕様書（案）

  • 脆弱性検査結果報告書

  • テストデータ

  • 移行計画書

  • 移行結果報告書
操作研修関連資料

  • 操作マニュアル（利用者向け及び情報システム管理者向け）

  • 教育資料一式
運用設計及び保守設計関連資料

  • 運用計画書（案）

  • 保守計画書（案）

  • 運用実施要領、保守実施要領等一式（運用実施要領、保守実施要領、運用手順書、保守手順書、ヘルプデスク運用マニュアル、ＦＡＱ等）

  • リリース管理台帳、リリース計画書　等
システム構成管理資料

  • 情報資産管理標準シート

  • ライセンス関連情報　等
現物関連

  • ソースコード（ＩａＣ設定ファイル類を含む）一式（ソースコードのコメントは原則として日本語または英語に限定すること。）

  • 実行プログラム一式

  • ソフトウェア製品パッケージ・ライセンス証書・インストールメディア類（ソフトウェアを調達する場合に記載）　等
## 検査・納品管理 1) 納品検査 「第６章７．検収」参照。 2) 納品管理 ＰＪＭＯは、各納品物を適切に管理し、所在を明確にしておくものとする。なお、**納品期日を遵守することが困難と判断したときは、作業の繰越しを検討する(1)**ものとする。 25. １. 趣旨 ＰＪＭＯは、納品期日の到来を契機に、設計・開発工程の納品物を確認し、当該調達の完了と、運用・保守工程に向けた納品物の整備を行う必要がある。 このため、ＰＪＭＯは、「第６章８．検収」に記載した内容で納品検査を行い、確認した納品物を、運用・保守工程で引き続き管理する環境を整備する。 26. ２. 解説 #### 「納品期日を遵守することが困難と判断したときは、作業の繰越しを検討する」 - 参考 繰越ガイドブック https://www.mof.go.jp/budget/topics/kurikoshi/22guidebook/ 「作業の繰越を検討する」とは、やむを得ない事情による著しい作業の遅延等により納品期日に納品を行うことが難しいと判断される場合に、翌年度以降に作業を繰越すよう、契約変更及び予算繰越を行うこと等を検討することを指す。なお、作業の繰越しの検討に当たっては、ＰＭＯ、政府デジタル人材、高度デジタル人材、会計担当部門、外部組織の有識者、専門的な知見を持つ職員等の支援や助言を受けることが望ましい。 ## 関係者への確認とプロジェクト計画書の段階的な改定 プロジェクト推進責任者は、設計・開発工程で作成した各種計画書等の内容を**、**プロジェクト計画書に反映し、当該計画書の内容を更新する。 27. １. 趣旨 設計・開発工程の進行に伴い、プロジェクト計画書で定義した内容が具体化・詳細化されるため、その内容については、ＰＪＭＯがプロジェクト計画書に反映させ、関係者に周知する必要がある。 なお、プロジェクト計画書の各項目に大幅な変更が発生する可能性があったときは、ＰＪＭＯはプロジェクト計画の軌道修正も含めて検討する。 プロジェクト計画書への反映については、標準ガイドライン解説書「第３編第２章 プロジェクトの管理」を参照すること。 デジタル社会推進実践ガイドブック DS-110 デジタル・ガバメント推進標準ガイドライン 解説書 （第３編第8章 サービス・業務の運営と改善） 2025年（令和７年）5月27日 デジタル庁

〔ドキュメントの位置付け〕

Informative

参考とするドキュメント

〔キーワード〕

サービス・業務、業務のリハーサル、教育・訓練、指標、分析、業務改善、費用対効果

〔概要〕

標準ガイドラインの下位文書として、標準ガイドラインの記載の趣旨、目的等を理解しやすくするため、逐条的な解説等を記載した参考文書。
改定履歴
改定年月日 改定箇所 改定内容
2025年5月27日 － ・解説書全体に合わせ、日付のみ更新
2024年5月31日 第８章２．

・表記ゆれを統一

・表「業務改善による対応方法の例」の「サービス利用者」を「業務実施部門の職員」に修正
2022年4月20日

第８章２．

第８章４．

 ・標準ガイドラインからの引用箇所について、標準ガイドラインの改定に合わせて修正
第８章２．

・政府ＣＩＯポータルサイトをデジタル庁Ｗｅｂサイトに変更し関連箇所を修正

・「齟齬」を「そご」に修正
第８章４． ・府省ＣＩＯ補佐官の記載を削除し、関連箇所を修正
2021年3月30日 第８章２． ・資料間の不整合の修正
2020年11月27日 第８章５． ・ODBに関する記載を削除
2020年3月31日 第８章１． ・サービス・業務の運営準備において、情報システムの障害、災害等の発生時に業務を継続するための計画や手順を具体化することを追加
第８章２． ・サービス・業務の運営において、非常時を想定した業務継続訓練等を定期的に実施することを追加
第８章２． ・データマネジメントの実施において、高い情報セキュリティ対策が求められる情報資産に対する適切なリスク管理の実行について追加
2019年2月27日 － ・初版決定
[１. サービス・業務の運営準備 [2](#サービス業務の運営準備)](#サービス業務の運営準備) [２. サービス・業務の運営 [5](#サービス業務の運営)](#サービス業務の運営) [３. サービス・業務の改善 [12](#サービス業務の改善)](#サービス業務の改善) [４. 情報システムの改善 [13](#情報システムの改善)](#情報システムの改善) [５. プロジェクト計画書の段階的な改定 [17](#プロジェクト計画書の段階的な改定)](#プロジェクト計画書の段階的な改定)