# 39-40 目次 ```table-of-contents title: minLevel: 0 maxLevel: 0 includeLinks: true ``` # 39 政府情報システムの整備及び管理に関する標準ガイドライン ## 39.2 標準ガイドラインの概要 ![[Untitled 62.png|Untitled 62.png]] 過度な分離調達を抑制 実務手引書（2015年度内に作成予定） ## 39.3 既存ガイドラインとの関係 ![[Untitled (3).png]] 従来の「業務・システム最適化指針」、「行政機関におけるIT人材の育成・確保指針」、「情報システムに係る政府調達性の見直しについて」、「情報システムに係る調達の基本指針」を廃止して、 新たに「政府情報システムの整備および管理に関する標準ガイドライン」として再構成。 ### 39.3.0.1 （引用）第2回　「政府情報システムの整備及び管理に関する標準ガイドライン」（その1）－概要および要件定義と調達－ （http://www.mri.co.jp/opinion/column/gov_info/gov_info_20150410_1.html） ■標準ガイドラインの概要 従来、ベンダーやソフトウエア会社は自社の開発標準を有していた。しかしながら、開発工程の定義や作業内容、用語、ドキュメント様式などが異なっており、会社が違えば「同じ言葉で話す」ことが難しかった。それを解決する共通の枠組みとして、ソフトウエア・ライフサイクル・プロセスを標準化した共通フレームが定義された。この共通フレームは1994年の共通フレーム2004から、2007年の共通フレーム2007を経て、現在は共通フレーム2013へと進化しているが、業務・システム最適化計画を始める2005年頃は一般的に普及しているとは言えなかった。 そのため業務・システム最適化計画を進めるにあたり、共通フレームでいうところの特に要件定義プロセスで、共通的な表現でシステムを「見える化」することを目的にEA（エンタープライズ・アーキテクチャ）の概念が導入され、そのためのドキュメント体系が定義されることとなった。計画を進める中で「業務・システム最適化指針」、「情報システムに係る政府調達の基本指針」、「電子政府ユーザビリティガイドライン」などが作成されてきたが、それぞれカバーする分野が異なっており、プロジェクトを進めるにあたり常に複数のガイドラインを参照する必要があった。また、これらガイドラインを利用する中で、改善すべき部分も見えてきた。 そのような状況の下、「世界最先端IT国家創造宣言」（2013年6月）で政府のITガバナンス強化施策の一つとして、情報システム調達やプロジェクト管理に関する共通ルールなどを整備するという方針が示された。図1は既存の指針と新しい標準ガイドラインとの関係を示したものである。これまで活用されてきた指針は廃止され、それぞれの内容を現状に則したものに見直した上で、図右側に示す標準ガイドラインの記載項目に取り込まれている。 ■要件定義 要件定義は、情報システムを整備する上で「どのようなシステムを実現するか」の絵姿を描く重要な作業であり、その成果物である要件定義書は後工程の重要なインプットとなる。さらに、見積もりや、特に政府においては調達のための主要なドキュメントの一つとして位置付けられる。 要件定義が不十分なまま構築を進めたため、システムが所期の目的を十分に果たせない、あるいは工程上の手戻りが発生し費用や開発期間の面で問題を残したという例も見受けられる。そのため標準ガイドライン､特に実務手引書では、業務の見直しとそれに伴う要件定義の部分にかなりのページ数を割いて、必要な作業や要件定義書の記載項目を定めている。要件定義の確定は、設計・構築事業者を調達する前と、事業者が決定し設計作業を開始する前の2段階で行うこととしており、特に調達前にどこまで要件定義を精緻化できるかがポイントとなる。 ■調達 従来の指針に基づいた調達には、大きく以下の二つの課題があった。標準ガイドライン（実務手引書を含む）は、これらに対する解決の糸口を与えるものとなっている。 (1)調達単位 従来は公平性の確保、調達機会の拡大等の観点から、例えば、基盤システムと業務システム、ハードウエアとソフトウエア製品、アプリケーションの保守など可能な限り調達単位を分けるという「分離調達」が推奨されていた。しかしながら、調達を分離することでプロジェクトが複数の事業者により構成されることとなり、管理の難易度が増したためにプロジェクトの品質低下や期限遅れを生ずるなど、過度な分離調達による弊害が発生することもあった。 そのため、標準ガイドラインでは発注者が適切に管理・統合できることを前提に、合理的な調達範囲を検討することとされている（例えば「設計業務」と「開発業務」の統合など）。「合理的」の解釈には難しいものがあるが、PMO※2、CIO補佐官の判断や意見招請なども活用しつつ、実現可能性と競争性の確保のバランスを取ることが重要となる。 (2)選定方式 もう一つの大きな課題は、選定方式である。比較的機能が単純で仕様を明確に記述可能なもの（例えばプリンターなどのハードウエア）については、最低価格落札方式でも一定の仕様を満足するものを調達することが可能であり、大きな問題を生ずることは少ない。 一方、アプリケーションプログラムの設計・開発のように、入札者の技術的要素を評価することが重要なものもある。このような場合、価格要素と技術要素を総合的に評価する「総合評価落札方式」を採用することが有効である。従来は価格評価点と技術評価点の配分は原則1対1とされていた※3。そのため、技術評価点で相当程度の差がついていたとしても、低価格で入札することにより落札できる可能性が大きかった。標準ガイドラインでは、適用範囲に該当すれば価格評価点と技術評価点の配分を1対3まで選択できることが明記され、調達案件ごとの最適な調達方式選択の幅が広がった。 ## 39.4 人材の育成・確保の留意点 ![[Untitled 2 9.png|Untitled 2 9.png]] 人事ローテーションの工夫を検討するなど、中長期的な視点に立って計画的に推進。 専門的・技術的な知識・能力だけでなく、業務分析、業務の見直しの企画立案、プロジェクト管理等の能力の取得が重要。 業務は、情報システムを活用してデータの作成や活用ができることが不可欠。一般職員のITリテラシの向上にも努めることが重要。 ## 39.5 ガイドラインに示す計画書等の関係（概要） ![[Untitled 3 9.png|Untitled 3 9.png]] システム開発業務の成果物となる各種計画書の関係 ## 39.6 政府標準ガイドラインに沿ったタスクと必要なスキル ### 39.6.1 政府標準ガイドラインに沿ったタスクプロフィールとドキュメント ![[政府標準ガイドラインに沿ったタスクプロフィールとドキュメント.png|政府標準ガイドラインに沿ったタスクプロフィールとドキュメント.png]] [[政府標準ガイドラインに沿ったタスクプロフィールとドキュメント.png|政府標準ガイドラインに沿ったタスクプロフィールとドキュメント.png]] ## 39.7 総論 情報システムは、単なる行政事務処理上の道具ではなく、業務・サービス運営の中核を成す基盤として存在するに至っている。 ITを活用し、行政サービスの利便性の向上並びに行政運営の効率性及び透明性の向上を実現する電子政府の構築が喫緊の課題 業務の効率化及び高度化、情報セキュリティを含む情報システムの運用リスクへの適切な対応等、具体的な取組を政府横断的に進める 政府情報システムの標準的な整備及び管理について、その手続・手順に関する基本的な方針及び事項並びに政府内の各組織の役割等を定める体系的な政府共通のルールとして、「政府情報システムの整備及び管理に関する標準ガイドライン」（以下「本ガイドライン」という。）を策定する。 ### 39.7.1 根拠 高度情報通信ネットワーク社会形成基本法（平成12年法律第144号。以下「ＩＴ基本法」という。）第26条第２項第３号、「世界最先端ＩＴ国家創造宣言」（平成25年６月14日閣議決定。平成26年６月24日全部変更）、「世界最先端ＩＴ国家創造宣言工程表」（平成25年６月14日高度情報通信ネットワーク社会推進戦略本部決定。平成26年６月24日改定）及び「内閣情報通信政策監をもって充てる本部員への事務の委任について」（平成25年６月14日高度情報通信ネットワーク社会推進戦略本部長決定。平成26年６月24日一部改正）１(３) ## 39.8 ＩＴガバナンスの全体像 ![[Untitled 5 9.png|Untitled 5 9.png]] 政府ＣＩＯ及び府省ＣＩＯを中心とする体制において、政府情報システムの整備又は管理のための全ての活動、成果及び関係者を適正に管理 ガイドラインでは、プロジェクトの手続・手順、政府内の各組織の役割等について共通的なルールを定める趣旨から、組織、人材、各種計画、予算関係、管理等について規定する。 ## 39.9 組織体制 ＩＴ総合戦略本部 ｅガバメント閣僚会議───新戦略推進専門調査会 │ 電子行政分科会等 ＣＩＯ連絡会議 ＣＩＯ連絡会議幹事会 各種ワーキンググループ等 政府ＣＩＯ │　ＩＴ総合戦略本部員 │　ＣＩＯ連絡会議議長 │ ├─政府ＣＩＯ補佐官 │ 内閣官房　総務省 ＣＩＯ連絡会議事務局等 ### 39.9.1 組織内体制 情報化推進委員会 府省ＣＩＯ 電子政府推進担当課長 総務担当課長 人事担当課長 会計担当課長 府省ＣＩＯ補佐官　等 府省ＣＩＯ │ＰＭＯ │ ├─府省ＣＩＯ補佐官 │ 電子政府推進担当課長 │ その他構成員 府省内における情報化戦略等の策定・推進・評価 ・　政府の全体方針に沿った府省内における情報化戦略等の策定・推進・評価 ②　投資管理 > ・　府省内における情報システム及びその資産の管理・評価 > > ・　情報システム関係予算及びその執行の統括 > > ・　情報システムを活用した業務の見直しの企画・実施・評価 > > ・　コスト適正化に向けた方針の策定・推進（情報システムの運用に関するコスト構造の分析・評価及び適正化に向けた方針の策定・推進等） ③　人材育成・確保 > ・　府省内における人材の把握及び育成（情報システム統一研修への派遣推進等）並びに外部人材の登用による確保 情報化推進委員会：府省CIO、府省CIO補佐官、電子政府推進担当課長、総務担当課長、人事担当課長、会計担当課長等から構成 CIO：政府の全体方針に沿って、府省内における電子政府の取組を推進し、かつ、府省内の情報化戦略及び基本的な方針又は計画の策定・推進・評価、ＩＴを活用した業務の見直し、投資管理及び人材の育成・確保等の事務を統括 PMO：必要に応じ、総務、人事、会計等の担当部局と連携の上、府省ＣＩＯの下、府省内を統括し、電子政府の取組を推進する。PMOは、その責任の所在を明確にするため、役割分担、担当職員の役職名等を記載した体制表を作成。 PJMO：プロジェクトには、本ガイドライン等に基づき、対象となるプロジェクトを統括し、推進するため、ＰＪＭＯを定める ## 39.10 人材の育成・確保 - 情報システムを整備するプロジェクトを適切に遂行し、かつ、運用管理ができる人材（以下「ＩＴ人材」という。）は高度かつ専門的な技能と経験を有すべきである。また、当該情報システムを効果的に活用して政策目的を達成するためには広く職員のＩＴリテラシー（情報活用能力のこと。以下同じ。）の向上が不可欠 - ＩＴ人材の育成は、単に情報システムに関する専門的・技術的な知識・能力だけでなく、業務分析、業務の見直しの企画立案、プロジェクト管理等の能力の取得が重要 - 各人が不足する技能や経験をそれぞれで補い合いながら、個別の職務に当たらせるような工夫が必要 - 情報システムを活用してデータの作成や活用ができることが不可欠であることや、近年情報セキュリティについて様々な問題が生じている現状からすれば、情報システムに携わる職員に限らず、一般職員のＩＴリテラシーの向上にも努めることが重要 ### 39.10.1 人事・人材交流 特にＩＴ分野に適性のある職員を中核に、情報システム部門と業務実施部門との間、政府共通プラットフォーム等基盤系の情報システムの部門と業務系の情報システムの部門との間、官民間等において、積極的かつ計画的に人事及び人材交流を推進する ### 39.10.2 人材の育成・確保の留意事項 プロジェクトの核となる職員が、プロジェクトのライフサイクルの適切な節目までそのポストに留まるよう、人事ローテーションの工夫を検討する等、中長期的な視点に立って、計画的にＩＴ人材の育成・確保を推進する ### 39.10.3 外部人材の登用 必要に応じて外部の専門家を登用し、当該プロジェクトに参画させるよう努める ## 39.11 情報システムの管理（ＯＤＢの活用） - 情報システムに関する基本情報、担当組織、公開ドメイン、予算情報、調達情報、システム構成、取扱情報、運用・保守情報等を掲載する情報システム台帳及び情報資産台帳としての機能を有するＯＤＢを提供する - 情報システムの設計・開発、運用、保守等のほか、電子政府に関する企画立案等の基礎情報として活用する ## 39.12 ＩＴマネジメントの全体像 ![[Untitled 6 9.png|Untitled 6 9.png]] ## 39.13 プロジェクトの管理 ### 39.13.1 プロジェクト計画書等の作成 ＰＪＭＯは、プロジェクトを計画的に遂行するため、プロジェクトの実行に先立ち、プロジェクト計画書及びプロジェクト管理要領を作成する ### 39.13.1.1 プロジェクト計画書の記載内容 - 政策目的 - 業務の実施によって目指す政策上の目的・背景等について記載する。 - 対象範囲 - 業務の実施によって目指す政策上の目的・背景等について記載する - プロジェクトの対象となるべき情報システムの名称、主な機能及び当該情報システムを整備して実施する業務内容等について記載 - 既存の業務の見直しの方向性等 - 見直しの方向性、課題、効果等について構想段階のものを記載する - ＰＪＭＯは、多角的かつ複層的な検討・議論を経た上で見直し効果等について記載する - 予算 - 整備する情報システムに要する予算等を「別紙２　情報システムの経費区分」に基づき区分等して記載する。 - 目標 - 目指す目標・達成目標年度等について記載する - 体制 - 体制表、関係機関の役割等について記載する - 実施計画 - 情報システムの設計・開発、運用及び保守について記載するのみならず、法令改正を伴う場合、有識者会議において議論する場合等にはその日程等について記載する等、業務面に影響を与える他の取組についても併せて記載する - その他 - プロジェクトを実施する上での前提条件、リスク要因等について記載する ### 39.13.1.2 プロジェクト管理要領の記載内容 ＰＪＭＯがプロジェクトを管理する手法、手順、遵守事項等を明確に記載する - コミュニケーション管理 - 合意形成に関する手続、関係機関、情報システムの利用者等との連絡調整に関する方法、手順、頻度、議事録管理等について記載する - 工程管理 - 各作業管理方法、進捗状況の報告先、内容、頻度等について記載する - 指標管理 - 指標項目、指標の実績値の取得目的・取得手法・取得頻度、指標の変動による対応策等について記載する - リスク管理 - リスク顕在時の報告先、報告内容、リスクの管理手法等を記載する - 情報セキュリティリスクについては、自府省の情報セキュリティポリシーを参照 - 課題管理 - 解決すべき課題の発生時の報告先、報告内容、課題の管理手法等を記載する - 変更管理 - 変更内容について、管理対象、変更手順、管理手法等を記載する ### 39.13.1.3 プロジェクト計画書等の案の調整等 ### 39.13.2 プロジェクトの工程レビュー ⅰ）調達仕様書に添付する要件定義書の作成終了前 ⅱ）設計・開発工程に入る前に要件定義の確定を行う前 ⅲ）本番移行開始前のそれぞれの場面（以下「レビューポイント」という。） において、次のとおり工程レビューを実施する - 自己点検 - ＰＪＭＯは、レビューポイントにおいて自己点検を行い、その結果をＰＭＯに送付する - ＰＭＯレビュー - 内閣官房による指摘、助言又は指導 - レビュー対応 ### 39.13.3 プロジェクトの進捗及び実績報告 ＰＪＭＯは、プロジェクトの進捗・実績等について、ＷＢＳ注記）の更新状況等を原則として１か月ごとにＯＤＢに登録する ### 39.13.4 プロジェクト計画書等の改定の検討 ### 39.13.5 プロジェクトの完了 ## 39.14 予算要求 ### 39.14.1 経費の見積り 概算要求の積算に当たって、次の1）から7）までに掲げる事項を遵守する 複数年度にわたる契約を行うことに合理性が認められる場合には、国庫債務負担行為の活用を検討する - ＩＴ基本法第26条第２項第２号の規定に定める経費の見積り方針に従うこと。 - 情報システム単位で積算し、区分できるようにすること。 - 「別紙２ 情報システムの経費区分」に基づき区分等すること。 - 数量、工数、単価等の積算内訳を明確にすること。 - 原則として複数事業者の見積りを比較すること。 - ライフサイクルコストの見積り及びその根拠を示すこと。 - 事業者から見積りを取得するときは、実現したい業務・機能の内容、調達スケジュール等、事業者が見積りをするための必要な情報（特に政府共通プラットフォーム上に整備し、移行する情報システムについては、政府共通プラットフォームの仕様等）の提供を行い、次のアからウまでに掲げるものを取得すること。 - ア　情報システムの新規開発又は更改をする場合には、ライフサイクルコストの見積り - イ　要求内容に設計又は開発に関する工程が含まれる場合には、原則として、ファンクションポイント注記１）の見積り（ＬＯＣ注記２）の見積りも可能である場合には、プログラムごとに算出したＬＯＣの見積りを併せて行う）及びその根拠 - ウ　経費に人件費が含まれる場合には、ＷＢＳ（「第２章３．プロジェクトの進捗及び実績報告」参照）による作業内訳を示した工数の見積り - 注記１）ファンクションポイントとは、 - ソフトウェアが持つ入出力等の機能数を洗い出し、洗い出した各機能を複雑さによって重み付けして集計した点数をいう。一般に、集計したファンクションポイントを開発生産性（１人月で開発できるファンクションポイント）で除して単価を乗じたものが見積金額となる。 - 注記２）ＬＯＣとは、 - プログラムの総ステップ数をいう。一般に、過去に行った類似のシステム開発実績等から推定して総ステップ数（開発規模）を見積り、総ステップ数を開発生産性（１人月で開発できるステップ数）で除して単価を乗じたものが見積金額となる。 ### 39.14.2 要求内容等に関するＯＤＢへの登録 ### 39.14.3 資料作成 ＰＪＭＯは、概算要求に関連して、内閣官房又は総務省から資料提供の求めがあった場合には、これに応じる ＜提供を求める資料例＞ ○ 概算要求の概要 ○ 概算要求明細書（目細レベルの要求額、その積算内訳（数量、工数、単価等）、事業者の見積書、前年度予算額との対比） ○ 情報システム構成図（当該構成とした理由を含む。） ○ 情報システムを活用した場合の業務フロー ○ プロジェクト計画書（「第２章１．プロジェクト計画書等の作成」参照）及びこれを補足する資料 ○ 効果指標の目標、過去に支出した投資がもたらした効果とその算出方法 （新規開発の情報システムを除く。） ○ 年間運用実績（アクセス件数、処理件数、保守実績等） ○ 要求事項と同等の内容の直近の調達結果の詳細（契約日、契約額、契約期間、応札者数、契約相手方等） ## 39.15 業務の見直し 制度所管部門及び業務実施部門を中心に、次のとおり検討し、既存の業務の見直しを行う ### 39.15.1 プロジェクト計画書等の確認及び見直し - プロジェクト計画書及びプロジェクト管理要領を確認し、必要に応じてこれらを見直す - 作業内容、作業分担及び作業スケジュールを具体化・詳細化し、プロジェクト計画書に反映する ### 39.15.2 業務の見直し範囲の検討 ### 39.15.3 分析等 - 業務分析 - 業務及びデータの内容、流れ、業務量、データ保有形態、データ量、実施体制、実施時期・時間、実施場所、残存課題等 - 関係者分析 - 業務実施部門の従事者、業務によるサービスを受ける者その他当該業務に関係する者のそれぞれの規模、特徴、満足度、要求事項等 - 実績分析 - 業務の運営実績、各種指標の状況等 - 環境分析 - 業務を取り巻く現在の環境、将来の環境変化の見込み等 - 関連調査 - 業務に影響する関連法令の存否、影響度、見直しの必要性、類似する業務の存否、優良事例、失敗事例等 ### 39.15.4 業務の見直し内容の検討 - 見直しにより高い効果が見込まれる内容について、これを取り組むべき主要課題として整理の上、政策目的を実現するためにより効果的な業務となるよう、具体的な業務の見直し内容とその結果期待される効果について、多角的かつ複層的に検討する - 当該業務のみならず、関連組織の関係業務にも影響が及ぶと想定される場合には、ＰＪＭＯは、ＰＭＯの支援を受け、当該関係業務の見直し権限を有する者と調整・協議を行う ### 39.15.5 業務要件の定義 - 業務実施手順 - 業務の実施に必要な体制、手順及びそれらを記載した業務フロー図 - 入出力情報項目及び取扱量　等 - 規模 - サービスの利用者数及び情報システムの利用者数 - 単位（年、月、日、時間等）当たりの処理件数 - 時期・時間 - 業務の実施時期、期間及び繁忙期　等 - 業務の実施・提供時間　等 - 場所等 - 業務の実施場所、諸設備、必要な物品等の資源の種類及び量　等 - 管理すべき指標 - 業務の運営上補足すべき指標項目、把握手順・手法・頻度　等 - 情報システム化の範囲 - 業務の継続の方針等 - 業務の継続に伴うリスク及び基本的な考え方。なお、する 業務継続計画を策定する必要がある業務にあっては当該計画の策定時に検討 - 情報セキュリティ - 取り扱われる情報の格付・取扱制限等に応じた情報セキュリティ対策の基本的な考え方 ### 39.15.6 プロジェクト計画書への反映 - ＰＪＭＯは、業務の見直し内容の検討結果について、 適時、プロジェクト計画書に反映し、当該計画書の内容を更新する ## 39.16 要件定義の準備 - 明確な要件定義を行えない場合、 計画の遅延又は情報システムの機能・性能が要求水準に満たないものとなる事態等が発生する可能性が高まる ### 39.16.1 要件定義の対象範囲等の特定 プロジェクト計画書及びプロジェクト管理要領を確認の上、必要に応じてこれらの見直しを行うとともに、業務の見直し内容を踏まえ、要件定義の対象となる業務と情報システムの範囲及び内容を特定する ### 39.16.2 ＲＦＩの実施 専門的な知見を広く取得するため、必要に応じて、ＲＦＩ（用語は「第２編第７章２．1) 調達案件等に関するＯＤＢへの登録」参照）を行う - ＲＦＩに関する説明書の作成 - ①　調達の概要 - ②　その時点における検討内容、要件案の概要等 - ③　資料提供を求める内容等 - 業務要件を実現するために必要な情報システムの機能（以下「機能要件」という。）の案の実現性、実現方法、情報システムが備えるべき機能要件以外の情報システム要件（以下「非機能要件」という。）、 - それらの要件を実現するために必要な経費の見込み、明らかにすべきと考える要件定義事項又は開発方式（スクラッチ開発注記１）、ソフトウェア製品の活用、政府共通プラットフォームを含むクラウドコンピューティングサービス注記２）の活用等）、開発手法（ウォータフォール型注記３）、反復型注記４）等）等、事業者に具体的に求めたい内容について記載するものとする。 - ④　提出期限、提出場所、提出方法、提出資料における知的財産の取扱い等 - 注記１）スクラッチ開発とは、既存のソフトウェア製品を改修する等の方法で開発するのではなく、新規に開発することをいう。 - 注記２）クラウドコンピューティングサービスとは、インターネット等のネットワークを通じてハードウェアやソフトウェア製品をサービスの形で必要に応じて利用する方式をいう。 - 注記３）ウォータフォール型開発とは、ソフトウェアの開発を分析、設計、プログラミング、テストといった流れで行う開発手法をいい、原則として上流の工程が完了してから次の工程に進む。 - 注記４）反復型とは、情報システムを小さな機能単位に分割し、設計、プログラミング、テストを繰り返しながら徐々に機能や改良を加えて、最終的に完全なシステムを開発する手法をいう。 - ＲＦＩに関する説明書等のＯＤＢへの登録 ### 39.16.3 事業者へのヒアリング等の実施 ＲＦＩにおける情報取得が不足した場合等には、有用な情報を得られるよう、事業者に対する個別ヒアリング・説明会等を逐次行い、取得した情報を精査し、活用する ### 39.16.4 必要な資料の作成 既存資料を活用する場合には、現状の検討状況が適切に反映されていることを確認し、変更がある場合には更新する ## 39.17 要件定義 ### 39.17.1 要件定義書の記載内容 不確定要素のある要件については、それがプロジェクトを進める上でのリスク要因となり得ることに厳に留意し、その旨を要件定義書において明らかにする ### 39.17.1.1 業務要件の定義 情報システムを活用した業務の内容を定義する ### 39.17.1.2 機能要件の定義 - 業務の質の向上、業務の効率化等に対する有効性等を踏まえ、優先度の高い機能から整備する必要がある - 他の情報システムと連携する場合には相互運用性及びデータ互換性についても併せて記載する - 機能に関する事項 - 処理内容、入出力情報・方法、入力・出力の関係等を記載する - 画面に関する事項 - 画面一覧、画面概要、画面出力イメージ、画面遷移の基本的考え方、画面入出力要件・画面設計要件等を記載する - 帳票に関する事項 - 帳票一覧、帳票概要、帳票出力イメージ、帳票入出力要件・帳票設計要件等を記載する - 情報・データに関する事項 - 情報・データ一覧、情報・データ処理要件、データ構造等を記載する - 原則として、政府において標準化された情報・データ名称、データ構造等を採用する - 外部インタフェースに関する事項 - 外部インタフェース一覧、相手先システム、送受信データ、送受信タイミング、送受信の条件等を記載する ### 39.17.1.3 非機能要件の定義 - 技術的に検討を要する事項を多分に含むことから、日本工業規格等のほか、ＲＦＩ等を通じて、広く情報を取得し、実現性等の検証を行う - 政府共通プラットフォーム等、府省共通システムが提供する稼働環境、サービス等を最大限利用するとともに、その仕様について記載する - クラウドコンピューティングサービスの活用についても検討する - ユーザビリティ及びアクセシビリティに関する事項 - 日本工業規格等を踏まえつつ、情報システムの利用者の種類、特性及び利用において配慮すべき事項等を記載 - システム方式に関する事項 - ハードウェア、ソフトウェア、ネットワーク等の情報システムの構成に関する全体の方針等について記載する - 規模に関する事項 - 機器数、設置場所、データ量、処理件数、情報システムの利用者数等について記載する - データ量については、ライフサイクル期間における将来の見込みも記載 - 性能に関する事項 - 応答時間等を記載する - 性能が過度にならないよう適切な要件とする - 信頼性に関する事項 - 稼働率等を記載する - 過度にならないよう適切な要件とする - 拡張性に関する事項 - 情報システムの性能及び機能の拡張性要件について記載する - 特に、将来の機能改修、運用及び保守について、柔軟で効率的に行うことを念頭に、要件を定める - 中立性に関する事項 - ベンダーロックインの解消等による調達コストの削減、透明性向上等を図るため、市場において容易に取得できるオープンな標準的技術又は製品を用いる等の要件について記載する - 技術又は製品について指定する場合には、指定をする合理的な理由を明記した上で、ハードウェア、ソフトウェア製品等の構成を明らかにする - 継続性に関する事項 - 障害、災害等による情報システムの問題発生時に求められる必要最低限の機能、その目標復旧時間等を記載する - 過度にならないよう適切な要件とする - 情報セキュリティに関する事項 - 過度にならないよう適切な要件とする - 自府省の情報セキュリティポリシーを参照の上、要件を適切に定める - 情報システム稼働環境に関する事項 - ハードウェアの構成、ソフトウェア製品の構成、ネットワークの構成、施設・設備要件等について記載 - 既存の環境を最大限活用し、不要な調達を行わない - テストに関する事項 - テストの種類、目的、内容等を記載する - 移行に関する事項 - データ等の移行手順等を記載する - 引継ぎに関する事項 - 他の関係事業者への引継ぎに関する要件を記載する - 教育に関する事項 - 情報システムの利用者に対する教育について、教育対象者の範囲、教育の方法等を記載する - 運用に関する事項 - 運転管理・監視等に関する要件を記載する - 保守要件と明確に区別して記載する - 保守に関する事項 - アプリケーションプログラム、ハードウェア、ソフトウェア製品、データ等の保守要件を記載する - 情報システムの機能改修及び更改と明確に区別して記載する ### 39.17.1.4 要件定義書の調整・作成 - 関係機関、情報システムの利用者等と調整し、作成する - それぞれのプロジェクトにおける要件定義書間の整合性が確保されるよう調整する - 関係機関等との必要な調整を行った上で変更内容を要件定義書に反映する ### 39.17.2 プロジェクト計画書への反映 - プロジェクト計画書に反映し、当該計画書の内容を更新する ## 39.18 調達の計画 - 会計法等の関係法令等を遵守し、透明性、公正性及び競争性の確保を図り、要件定義を満たす成果物を得る - 調達手続を通じて、業務の見直しや要件定義の内容等が事業者に明確かつ十分に伝達されるようにする - 発注者として、主体性を持って事業者を管理する責任があることに厳に留意する - 調達手続に要する期間等も踏まえつつ、次のとおり、合理的な調達単位及び調達の方式を精査した上で、実施時期等を検討 - 調達単位、調達の方式、実施時期等、調達の計画については、関連する一連の調達仕様書の全てに記載する - プロジェクト計画書の内容に変更が生じる場合には、これを反映し、当該計画書の内容を更新する - 事業者において質の高い提案が行えるよう適切な期間を確保する - 特に予定価格が80万ＳＤＲ注記）以上となる見込みの大規模な調達案件については、調達内容に応じ、当該公告の期間（50日）を延長することも検討する - 注記）ＳＤＲ（Special Drawing Right）とは、特別引出権と訳され、国際通貨基金(ＩＭＦ)の公式為替単位である総合通貨単位 - 合理的な調達単位の検討 - 履行可能性、ライフサイクルコスト、技術的妥当性等を考慮の上、競争性が確保されコストが低減されるよう合理的な調達単位を検討する - ①　調査研究又は要件定義作成支援 - ②　プロジェクト管理支援 - ③　設計・開発（設計・開発の内容が細分化できる場合であっても、必ずしも調達単位を分割する必要はない。） - ④　ハードウェアの賃貸借又は買取り - ⑤　ソフトウェア製品の賃貸借又は買取り - ⑥　回線 - ⑦　アプリケーションプログラムの保守 - ⑧　ハードウェアの保守 - ⑨　ソフトウェア製品の保守 - ⑩　運用 - ⑪　運用サポート業務 - ⑫　業務運用支援 - ⑬　施設の賃貸借 - ⑭　施設の整備等 - ⑮　システム監査（情報セキュリティ監査を含む。） - 調達の方式の検討 - 契約方式の検討 - 一般競争入札（総合評価落札方式を含む。）を原則とする - **例外的に随意契約によらざるを得ない場合には、企画競争又は公募を行う**ことにより、透明性及び競争性を担保する - **公募を行った結果、応募が複数あった場合には、一般競争入札（総合評価落札方式を含む。）又は企画競争を行う** - 随意契約によらざるを得ない場合の留意事項 - 調達は一般競争入札が原則であり、随意契約とすることは例外であるが、随意契約による場合は、政府調達に関する協定、会計法、予決令等に照らし、随意契約とする理由・根拠を十分に検討し、競争性のない随意契約によらざるを得ない場合も含め、「公共調達の適正化について」（平成18年８月25日財計第2017号）に沿った取組が必要であることに留意する。また、専門的・技術的な判断を要する場合は、府省ＣＩＯ補佐官や専門知識を持つ有識者による第三者チェックや評価を受けることが肝要である。 - 企画競争 - 「企画競争」とは、複数の者に企画書等の提出を求め、その内容について審査を行う方法をいう。 - 企画競争を行う場合には、特定の者が有利とならないよう、 -  参加者を公募すること -  業者選定に当たっては、業務担当部局だけではなく契約担当部局も関与する必要があること -  審査に当たって、あらかじめ具体的に定めた複数の採点項目により採点を行うこと - 等により、競争性及び透明性を担保する。 - 企画競争が適する調達案件には、**政策上の理由等で品質を最優先する必要がある案件、民間事業者のノウハウや創意工夫を積極的に活用すべきであって調達仕様書及び要件定義書で具体的な仕様を定義することが適切でない案件**等が考えられる。 - なお、総合評価落札方式と同様に、提案依頼書の作成注１）や審査注２）を行い、公平を期すべきことに留意する。 - 公募 - 「公募」とは、行政目的達成のため、どのような設備又は技術等が必要であるかをホームページ等で具体的に明らかにした上で、参加者を募ることをいう。 - すなわち、**特殊な技術又は設備等が不可欠な場合であっても、それを有する者が複数存在する可能性を排除せず、必要な技術又は設備等を明示した上で参加者を募るもの**である。 - したがって、**当初から複数の者による競争が存在することが考えられるようなものについては、原則として、一般競争入札（総合評価落札方式を含む。）を行う**こととし、事務又は事業の性格等から、これにより難い場合には、企画競争を行うものとする。 - 公募を行った結果を踏まえ、示した要件を満たす者が一しかなく、他にはないことが明らかとなった場合は、その者と契約をすることがやむを得ないが、**当該要件を満たす者が複数ある場合には、総合評価落札方式による一般競争入札又は企画競争を行う**。 - 情報システムに係る調達では、例えば次のような案件が随意契約の対象となり得るものと考えられるが、上記を踏まえた対応が必要である。 -  特殊な技術要件（例えば、特定の１者が特許を保有する技術）が含まれ、要件定義内容を実現し得る他製品やサービスが市場に存在しないものと見込まれる案件 -  必要な要件がソフトウェア製品、アプライアンス製品（専用のソフトウェアが機器に固定的に組み込まれたものであり、特定の用途に特化した製品）で充足され、要件定義内容を実現し得る他製品が市場に存在しないものと見込まれる案件 - なお、秘密の保持が必要とされている案件について、随意契約を行うことができるものは、外交又は防衛の活動等において、その行為を公にすることによって重大な支障が生じ、公の秩序又は公共の安全の維持が困難となる場合に限られることに留意する必要がある - 落札方式の検討 - 調達案件が価格以外の技術的要素を評価することが必要と認められるものであるときは、次のa）及びb）に掲げる総合評価落札方式によることができる。 - その場合予定価格が80万ＳＤＲを超える調達案件以外のものについては、入札公告又は入札公示の前日から起算して少なくとも30日前に財務大臣に届け出る - 採点 - ![[Untitled 7 8.png|Untitled 7 8.png]] - 除算方式 - 入札者の申込みに係る性能等の各評価項目の得点の合計を当該入札者の入札価格で除して得た数値が最も高い者を落札者とする方式 - 「コンピューター製品及びサービスの調達に係る総合評価落札方式の標準ガイド」（平成７年３月28日調達関係省庁申合せ）に基づいて行う - 加算方式 - 入札価格に対する得点配分と、性能等に対する得点配分を等しいものとし、入札者の入札価格の得点に当該入札者の申込みに係る性能等の各評価項目の得点の合計を加えて得た数値が最も高い者を落札者とする方式であり、「情報システムの調達に係る総合評価落札方式の標準ガイド」（平成14年７月12日調達関係省庁申合せ）に基づいて行う。 - 適用範囲に該当すると認められる場合には、入札価格に対する得点配分の割合を全体の４分の１以上とすることも可能 - 入開札の方式の検討 - 電子調達システムを用いて行う ## 39.19 調達仕様書の作成等 - 調達仕様書を作成し、契約書に必要な事項が記載されるよう会計担当部門に依頼する ### 39.19.1 調達仕様書の記載内容 - 事業者が提案内容を検討するために不可欠な情報が網羅されるようにする - 契約書とその一部を構成する調達仕様書との整合性を確保するよう、会計担当部門と必要な調整を行う ### 39.19.1.1 調達案件の概要に関する事項 - 調達の背景、目的、期待する効果、業務・情報システムの概要、契約期間、作業スケジュール等について記載する ### 39.19.1.2 調達案件及び関連調達案件の調達単位、調達の方式等に関する事項 - 関連する調達案件の調達単位、調達の方式、実施時期等について記載する ### 39.19.1.3 作業の実施内容に関する事項 - 作業の内容、成果物の範囲、納品期日等について記載する - 当該調達案件に関係するもの及び「別紙３　調達仕様書に盛り込むべきＯＤＢ登録用シートの提出に関する作業内容」に定める内容を盛り込む ### 39.19.1.4 満たすべき要件に関する事項 - **要件定義書を満たすべき旨を記載****する（別紙として要件定義書を添付する）** ### 39.19.1.5 作業の実施体制・方法に関する事項 - 作業実施体制、作業要員に求める資格要件、作業の管理に関する要領等について記載する ### 39.19.1.6 作業の実施に当たっての遵守事項 - 機密保持、資料の取扱い、遵守する法令等について記載する ### 39.19.1.7 成果物の取扱いに関する事項 - 知的財産権の帰属、瑕疵担保責任、検収等について記載する - 知的財産権の帰属については、産業技術力強化法（平成12年法律第44号）に基づき、技術に関する研究開発活動を活性化し、及び事業活動における効率的な成果物の活用の促進に資するため、受注者側に知的財産権が帰属するものであることに留意する - 国の業務に特化した汎用性のないもの及び継続的な機能改修が見込まれるものについては、原則として次のとおりとする - ①　発注者側に知的財産権が帰属する旨を例外的に記載する。発注者側が不利にならないことを条件として、受注者側に対し、その利活用を認める旨を記載する - ②　成果物の機密の確保や改変の自由を担保するため、受注者側により勝手に著作者人格権が行使されないよう、その旨を記載する - ③　納品物における瑕疵担保責任の期間、内容及び責任分界点について記載する ### 39.19.1.8 入札参加資格に関する事項 - 入札参加要件 - 下位の等級に格付けされた者の参入、複数事業者による共同提案等について検討した上で記載する - 審査において履行可能性を検証する等の必要な措置を講ずる - 公的な資格や認証等の取得、受注実績等を求めるときは、特定の事業者のみに有利なものとならないようにする - 入札制限 - 透明性及び公正性並びに確実な契約履行等を確保する - 各工程の調達仕様書の作成に直接関与した事業者 - 工程の調達仕様書の作成に直接関与した事業者は、透明性及び公正性の確保の観点から、当該調達案件の入札に参加させない - 設計・開発等のプロジェクト管理支援事業者 - ＰＪＭＯを支援する事業者をいう。以下同じ。）については、相互牽制の観点から、その管理の対象となる情報システムの設計・開発の作業に関する内容を含む調達案件の入札に参加させない - 監査対象である情報システムに関与した事業者 - 監査の独立性及び客観性の確保の観点から、当該情報システムの監査業務に関する調達案件の入札に参加させない ### 39.19.1.9 再委託に関する事項 - 再委託（再々委託を含む。以下同じ。）の制限並びに再委託を認める場合の条件、承認手続及び再委託先の契約違反等に関する責任についての定め等について記載する ### 39.19.1.10 その他特記事項 - 前提条件、制約条件、要件定義、調達仕様書の変更手順等について記載する ### 39.19.1.11 附属文書 - 事業者が閲覧できる資料一覧表、閲覧要領、提案書等の審査要領その他事業者の提案に必要な資料を作成し、調達仕様書に添付する ### 39.19.2 契約書の記載事項 - 会計担当部門に対し、契約書に、損害賠償、契約変更手続、契約解除等に関する条項を記載するよう依頼する - 特に、損害賠償については、事業者による契約の履行が不可能となった場合の社会的影響等を踏まえ、損害賠償の範囲の限度を記載する ### 39.19.3 調達案件に関するＯＤＢへの登録 ### 39.19.4 第一次工程レビューの実施 第一次工程レビューを実施するものとする。その際、調達仕様書の内容が適正なものとなっているか否かの確認を行う ### 39.19.5 意見招請の実施 - 予定価格が80万ＳＤＲ以上と見込まれる調達案件については、「政府調達手続に関する運用指針」（平成26年３月31日関係省庁申合せ）に基づき、意見招請を行うとともに、当該意見招請手続の情報をＯＤＢに登録する - 調達仕様書等の案の内容についての十分な理解が得られるよう、事業者に対する説明等を積極的に行う - 事業者との質疑応答を通じて、提供すべき情報が明確で、かつ、漏れがないことを確認し、必要に応じて、調達仕様書等の案を修正し、確定する ## 39.20 ＲＦＰ・公告 ### 39.20.1 提案依頼書の作成等 総合評価落札方式による調達を行うときは、次のア及びイのとおり、提案依頼書の作成等を行う ### 39.20.1.1 提案依頼書の記載事項 - 事業者が適切に提案するために必要となる情報が網羅されるよう、原則として、次のa）からd）までに掲げる事項について記載する - ＲＦＰの内容 - 提案書の記載要領、具体的な提案依頼の内容（作業内容の実施体制（再委託に関する事項を含む。）、実施計画、プロジェクト管理手法等）その他提案時に提出すべき資料等（その際、提案に盛り込まれるべき事項が具体的かつ漏れなく提案書に記載されるよう依頼内容を明確に提示する - 提案手続 - 提出期限、提出場所、提出方法等 - 評価基準 - 価格点及び技術点の配点、評価事項の設定、評価方法等（調達内容の特性（制度・業務の内容、開発規模の大きさ等）を踏まえ、例えば、次の①から⑦までに掲げる事項について的確に評価ができ、かつ、提案内容の実現性の根拠、具体的な実現方法等が記載されるよう評価事項を定める - 評価方法についても、作業内容の履行可能性等、必須事項のうち最低限の要求事項を、合否を判断する基礎点として設けるほか、重要視する評価事項を考慮の上、加点の配分割合の重点化、相対評価の活用等によって、優れた提案が評価されるよう工夫する - ①　制度、業務及びシステムに対する理解度 - ②　要件定義の理解度 - ③　プロジェクトの計画能力 - ④　プロジェクトの管理能力 - ⑤　設計・開発等に関する技術的能力 - ⑥　設計・開発等の実績 - ⑦　組織的対応力 - 審査手法 - 事業者におけるプロジェクト遂行の責任者となることが予定される者による提案内容のプレゼンテーション、質疑応答の実施等、技術力を適正に評価するために行う審査の具体的な手法等 ### 39.20.1.2 提案依頼書に関するＯＤＢへの登録 ### 39.20.2 調達に関する公告 - 調達の計画に基づき、調達に関する公告手続を会計担当部門に依頼する - 調達仕様書、提案依頼書等の内容についての十分な理解が得られるよう、公告後、必要に応じて、事業者に対する説明等を行う - 事業者からの提案に重要な影響があると認められる応答内容については、応札が見込まれる全ての事業者に通知する ## 39.21 審査 ### 39.21.1 審査体制の確立 公正性の確保に留意しつつ、審査を的確に実施できるよう、調達内容に応じた知見を有する者（例えば政府ＣＩＯ補佐官、外部有識者）、制度・業務に精通した者及び情報システムに精通した者により構成される審査体制を確立する ### 39.21.2 審査 審査体制の構成員は、評価基準及び審査手法に基づき、要件定義等の内容を的確に理解した提案内容であるか、実現性のある提案内容であるか等について厳格に評価する ## 39.22 入開札 ### 39.22.1 入開札の実施 - 開札の結果、一者応札となった調達案件については、入札説明会等には参加したが応札しなかった事業者等、応札を辞退した事業者に対するヒアリング等を行い、以後の調達手続の改善に活用する ### 39.22.2 低入札価格調査の実施 - 低入札価格調査を実施することとなった調達案件については、当該調査の対象となる入札をした事業者に対し、調達内容のそれぞれについて履行可能であるとする具体的な根拠資料（開発規模、工数、作業工程、作業スケジュール、生産性の詳細等）の提示を求めるなどし、契約の内容に適合した履行がなされるかどうかについて確認するものとする。 - その際、会計担当部門のみで調査を行うことが困難である場合には、ＰＪＭＯ、府省ＣＩＯ補佐官等の協力を得る ## 39.23 契約 ### 39.23.1 契約書の確認及び写しの保管 - 会計担当部門は、契約を締結するときは、ＰＪＭＯに対して契約書の内容を確認するよう依頼する - 取得した契約書の写しを適切に管理する ### 39.23.2 契約情報に関するＯＤＢへの登録 - 落札事業者との契約が締結された後、当該者から契約額の内訳等の情報を速やかに入手 ### 39.23.3 再委託の審査 - ⅰ）再委託を行う合理的理由、ⅱ）再委託先事業者が、再委託される業務を履行する能力、ⅲ）その他必要と認められる事項について厳格に審査し、適当と認められる場合に承認を行う - 受注事業者に再委託先事業者の業務の履行状況を確認・報告させること、再委託先事業者に受注事業者と同等の義務付けを行うこと等、契約の着実な履行のための必要な措置を講ずる ### 39.23.4 契約の変更・解除 - 会計担当部門は、契約を変更したとき、又は契約の解除をしたときは、その事実及びその理由を速やかにＰＪＭＯに連絡す ## 39.24 設計・開発 要件定義に基づき、次のとおり設計・開発を進める ### 39.24.1 設計・開発実施計画書等の作成 - 設計・開発事業者（プロジェクト管理支援事業者を調達する場合には当該事業者を含む。）とともに、設計・開発実施計画書及び設計・開発実施要領を作成する プロジェクト計画書、要件定義書等に変更が生じる場合には、これを更新する ### 39.24.2 設計・開発実施計画書の記載内容 - 調達仕様書、要件定義書等に基づき、少なくとも次のアからカまでに掲げる事項について記載する - 附属文書として、作業項目、作業内容、スケジュールをより詳細に階層化し、担当者等を記載したＷＢＳを作成する ### 39.24.2.1 作業概要 - 設計・開発の対象範囲、作業概要等について記載する ### 39.24.2.2 作業体制に関する事項 - ＰＪＭＯ及び設計・開発事業者のみならず、設計・開発に携わる関係機関、情報システムの利用者、関係事業者、府省ＣＩＯ補佐官等、設計・開発に関連する全ての関係者について、その体制、関係者間の関係性、役割分担・責務等について記載す ### 39.24.2.3 スケジュールに関する事項 - プロジェクト計画書及び調達仕様書に基づき、作業内容、スケジュール、マイルストーン等について記載す ### 39.24.2.4 成果物に関する事項 - 納品される成果物、品質基準、担当者、納入期限、納入方法、納入部数等について記載する ### 39.24.2.5 開発形態、開発手法、開発環境、開発ツール等 - 採用する開発方式（スクラッチ開発、ソフトウェア製品の活用及び政府共通プラットフォームを含むクラウドコンピューティングサービスの活用等）、開発手法（ウォータフォール型、反復型等）、開発ツール等を、必要に応じて、記載す ### 39.24.2.6 その他 - 設計・開発の実施における前提条件、時間、予算等の制約条件等について記載する ### 39.24.3 設計・開発実施要領の記載内容 - プロジェクト管理要領と整合性を確保しつつ、少なくとも次のアからケまでに掲げる事項について記載する ### 39.24.3.1 コミュニケーション管理 - 設計・開発事業者、関係事業者等との合意形成に関する手続、連絡調整に関する方法、設計・開発事業者が参加すべき会議・開催頻度・議事録等の管理等について記載する - ＰＪＭＯが議事録の正確性を確認し、修正する手順も併せて盛り込む ### 39.24.3.2 体制管理 - 作業体制の管理手法等について記載する ### 39.24.3.3 工程管理 - 設計・開発の作業、その工程の管理手法等について記載する - ＥＶＭ（アーンドバリューマネジメント（Earned Value Management））を用いて報告できるよう管理手法にこれも組み込む ### 39.24.3.4 品質管理 - 品質基準、品質管理方法等について記載する ### 39.24.3.5 リスク管理 - リスク認識の手法、リスクの管理手法、顕在時の対応手順等について記載する ### 39.24.3.6 課題管理 - 解決すべき問題について、発生時の対応手順、管理手法等について記載する ### 39.24.3.7 システム構成管理 - 設計・開発における情報システムの構成（ハードウェア、ソフトウェア製品、アプリケーションプログラム、ネットワーク、外部サービス、施設・区域、公開ドメイン等）の管理手法等について記載する ### 39.24.3.8 変更管理 - 設計・開発の進捗により発生する変更内容について、管理対象、変更手順、管理手法等について記載する ### 39.24.3.9 情報セキュリティ対策 - 設計・開発における情報漏えい対策等について記載す ### 39.24.4 設計・開発実施計画書等の調整・確定 - ＰＪＭＯは、設計・開発実施計画書等の案を、必要に応じて、関係機関と調整し、確定する ## 39.25 設計・開発工程に入る前の要件定義の内容の調整・確定 - ＰＪＭＯは、調達手続開始後の事情の変化、受注事業者等の提案等を踏まえ、要件定義の内容に関する認識に可能な限り相違が生じないよう、必要に応じて、関係機関、情報システムの利用者、設計・開発事業者、関係事業者等と、要件定義の内容について確認及び調整の上（府省重点プロジェクトにあっては第二次工程レビューの後）、要件定義を確定するものとする - 必要に応じ、プロジェクト計画書を更新するものとする。なお、開発手法について反復型（「第５章１．2)ア ＲＦＩに関する説明書の作成」の注記４を参照）を採用した場合には、最終サイクルで要件定義を確定する前に、必要な調整を行うものとする ### 39.25.1 第二次工程レビューの実施 ## 39.26 設計 - 設計の対象には目的とする情報システムの運用設計及び保守設計を含める - 設計・開発事業者からシステム方式、情報システム構成及びライセンスについて確定した内容に関するデータの提出を求める - バックアップ環境、テスト環境、研修環境等を常時設けている場合も同様とする ### 39.26.1 要件定義の内容との整合性確認 - 設計・開発事業者に対し、 設計の検討内容の報告を求め、要件定義の内容が確実に反映されていることを確認し、必要に応じ、課題等の指摘又は指導を行う ### 39.26.2 関係機関、情報システムの利用者等との調整 - 設計・開発事業者とともに、情報システムの利用者、関係機関、関係事業者等と調整を行い、それぞれと設計内容について合意する ### 39.26.3 移行計画書の案の作成 - 設計・開発事業者に対し、移行の方法、環境、ツール、段取り等を記載した移行計画書の案の作成を求め、提出を受けた後、その案について、移行リスクを低減するため、必要に応じ、関係機関、関係事業者等と調整を行う ### 39.26.4 中長期運用・保守作業計画の案の作成 - 情報システムの次期更改までの間に計画的に発生する作業内容、その想定される時期等を取りまとめた中長期運用・保守作業計画の案の作成を求め、提出を受ける ### 39.26.5 運用計画及び保守作業計画の案の作成 - 定常時における月次の作業内容、その想定スケジュール等を取りまとめた運用計画及び保守作業計画の案の作成を求め、提出を受ける - 保守と瑕疵担保責任の範囲内で実施する作業の分担を明確にするよう留意する ### 39.26.6 運用体制等 - 定常時及び障害発生時において想定される運用体制、実施手順等を取りまとめる - 政府共通プラットフォーム等府省共通システムが提供するサービスを利用する場合には、サービス提供者、運用事業者及び保守事業者の間で必要な作業が行われるよう作業分担、実施手順等を明確にするよう留意する ## 39.27 開発・テスト ### 39.27.1 テスト計画書の作成 - 単体テスト、結合テスト及び総合テストについて、テスト体制、テスト環境、作業内容、作業スケジュール、テストシナリオ、合否判定基準等を記載したテスト計画書の作成を求め、提出を受けた後、テスト内容の十分性、テストデータの適切性等を確認し、必要に応じ、課題等の指摘又は指導を行う ### 39.27.2 単体テスト - 単体テストの実施状況の報告を求め、必要に応じ、課題等の指摘又は指導を行う ### 39.27.3 結合テスト・総合テスト - 結合テスト及び総合テストの実施状況の報告を求め、必要に応じ、課題等の指摘又は指導を行う - テストの実施状況について、要件定義の内容及び設計内容に照らし、設定した合否判定基準を全て満たしたと認められる場合に限り、設計・開発事業者に対し、次の工程の開始の承認を行う ### 39.27.4 テスト手順・データの再利用対策 - 将来の保守や更改時におけるテスト工程の合理化に資するため、テストシナリオ・スクリプト、テストデータ等を保存し、保守後等の動作確認等において、それらを一部改変して再利用できるようにする ### 39.27.5 受入テストの実施 - 受入テストのテスト計画書の作成 - 設計・開発事業者の支援を受ける等により、テスト体制、テスト環境、作業内容、作業スケジュール、テストシナリオ、合否判定基準等を記載した受入テストのテスト計画書を作成する ### 39.27.6 受入テスト - 開発されたシステムが要件定義書に記載した事項を適切に実現しているかどうかを検証するため、受入テストのテスト計画書に基づき、設計・開発事業者の支援を受けて、本番稼働時のデータに近いテストデータを用いて、受入テストを行う - ユーザビリティ要件及びアクセシビリティ要件を検証するときは、業務実施部門、情報システム部門等、主たる情報システムの利用者が受入テストに参加する - 受入テストの結果を踏まえ、設計・開発事業者に対し、必要に応じ、課題等の指摘又は指導を行う ### 39.27.7 第三次工程レビューの実施 ## 39.28 情報システムの本番移行 ### 39.28.1 移行計画書の確定等 - あらかじめ作成された移行計画書の案（「４．3) 移行計画書の案の作成」参照）の内容確認を行った上で確定させ、これに基づいた作業が行われるよう、管理を行う ### 39.28.2 移行判定 - ⅰ）受入テストにおいて、要件定義に添った内容で、かつ、設定した品質基準を全て満たしたと認められ、ⅱ）府省重点プロジェクトにあっては第三次工程レビューにおいて問題なく妥当なものと判断され、ⅲ）移行計画書の内容も適正であると確認の上確定した場合に限り、本番移行を開始する ### 39.28.3 データ移行等 - 設計・開発事業者に対し、新規情報システムのデータ構造の明示、保有・管理するデータの変換、移行要領の策定、例外データ等の処理方法等に関する手順書を作成させ、承認を行う - 当該手順書に従い、データを変換・移行した後は、移行後のデータだけでなく、例外データ等についても確認を行い、データの信頼性の確保を図る ## 39.29 引継ぎ - 情報システムの整備後の事業者変更のリスクを最小限に抑えつつ、円滑かつ効率的に当該情報システムを運用するため、設計・開発事業者に対し、運用事業者及び保守事業者に設計・開発の設計書、作業経緯、残存課題等を確実に引継ぐよう求める ## 39.30 検査（検収）・納品管理 ### 39.30.1 納品検査（検収） - ＰＪＭＯは、納品予定の成果物に対し、要件定義書等において求める要件及び品質が満たされているか否かについて適切に確認するものとする。特に、 情報システムの納品に当たっては、受入テストを通じた修補等の措置を講ずるものとし、合否判定基準を満たすことを確認した上で、検収を行う ### 39.30.2 事業者の評価及び検収結果に関するＯＤＢへの登録 - 受注事業者の業務実績、品質等を評価し、検収に関する情報とともに、これをＯＤＢに登録する ### 39.30.3 納品管理 - 各納品物を適切に管理し、所在を明確にしておく ## 39.31 業務の運営開始 情報システムを用いて業務を開始し、当該業務の運営の定着を図り、その中で不断の業務の改善に取り組む ### 39.31.1 業務の運営開始前の準備 - 業務の運営開始に先立ち、必要な法令の改正、業務手順書等の作成等、必要な準備を行う ### 39.31.2 リハーサルの実施 - 業務の運営開始に先立ち、原則として、業務のリハーサルを行う - 業務の運営に支障を来す不具合等を発見したときは、業務の実施手順を見直す等により、当該不具合等を回避する ### 39.31.3 教育・訓練の実施 - 業務実施部門の担当者、外部委託先等の業務に携わる全ての者（下記２．において「業務実施担当者等」という。）に対し、業務の実施が円滑に行えるよう、役割分担、責任の範囲等を含め、教育・訓練を計画的に実施する - 情報システムの操作、業務の運営手順等を一体として教育・訓練するよう留意する ### 39.31.4 **業**務の運営開始時の課題対応 - 業務の運営開始時に発生する課題に対応するため、あらかじめ、リスクを分析し、リスク顕在時の対応案を準備してお ## 39.32 運営の定着 ### 39.32.1 モニタリングの実施 - 業務の運営中に、定期的に（通常であれば月に一度）管理すべき指標の実績値を把握する ### 39.32.2 業務手順書等の見直し - 業務の運営開始後に、業務をより円滑に実施するため、定期的に（例えば半年に一度）業務手順書等の見直しを行う ### 39.32.3 教育・訓練の継続 - 業務を継続的に行うため、運営開始時と同様、業務実施担当者等に対し、継続的かつ計画的に教育・訓練を行う - 人事異動等により業務の運営に支障を来すおそれがないよう、組織的な教育・訓練の実施に努める ### 39.32.4 利用促進のための施策の実施 - 情報システムの利用を促進するため、有効な施策を実施するとともに、業務実施担当者等に対し、情報システムを利用すると想定される利用者を誘導する施策の具体例について教育・訓練する ## 39.33 日常運営における業務改善 ### 39.33.1 管理すべき指標等の活用 - 管理すべき指標等を活用し、定期的に業務の実態を分析する - 対応すべきリスク及び課題であると認識したものについては、その原因を分析し、費用対効果を踏まえて優先順位を付け、順次改善する ### 39.33.2 業務運営上の課題への対応 - 業務の運営の中で発生した課題について、その原因を分析し、費用対効果を踏まえて優先順位を付け、順次改善する ### 39.33.3 関係機関、情報システムの利用者等からの要望等の収集等 - 関係機関、情報システムの利用者等からの業務・情報システムに対する改善要望等を定期的に収集するとともに、これを課題として認識し、費用対効果を踏まえて優先順位を付け、順次検討・改善する ### 39.33.4 システム監査の指摘事項 - システム監査の指摘事項について、その内容を精査し、対応すべき課題及びリスクであると認識したものについてはその原因を分析し、費用対効果を踏まえて優先順位を付け、順次改善する ## 39.34 運用開始前の準備 - 運用及び保守を計画的に実施するため、自ら運用及び保守を行わない場合、次の1）から5）までに掲げる事項に取り組む - その際、プロジェクト計画書、要件定義書等に変更が生じる場合には、適宜これらを変更する ### 39.34.1 運用事業者、保守事業者等の調達 - 情報システムの監視又は運用を行う運用事業者、保守を行う保守事業者、プロジェクト管理支援事業者（「第６章２．1)クb)ﾛ) 設計・開発等のプロジェクト管理支援事業者」参照）等について、その作業範囲、作業内容、スケジュール、品質、責任分界等を定めた調達仕様書を作成し、調達を行う ### 39.34.2 中長期運用・保守作業計画の案の確定 - 1）において決定した受注事業者とともに、設計・開発時に作成・提出させた中長期運用・保守作業計画の案（「第７章４．4) 中長期運用・保守作業計画の案の作成」参照）の確定を行う ### 39.34.3 運用計画の案の作成・記載内容・確定 - 設計・開発時に作成した運用計画の案（「第７章４．5) 運用計画及び保守作業計画の案の作成」参照）、調達仕様書、要件定義書等に基づき、必要に応じて関連する他の事業者の支援を受けて、運用計画の案の作成を行う - 附属文書として、監視項目、運用業務フローなどの作業項目、作業内容、スケジュール、担当者等について記載する - ＰＪＭＯは、これにより作成した運用計画の案を、必要に応じて、ＰＭＯ及び関係機関と調整し、確定する ### 39.34.3.1 作業概要 - 監視、運用作業の対象範囲、作業概要等について記載する ### 39.34.3.2 作業体制に関する事項 - ＰＪＭＯ、運用事業者のみならず、運用に関わる関係機関、情報システムの利用者、関係事業者等の運用に関連する全ての関係者について、その体制、関係者間の関係性、役割分担、責務等を記載する ### 39.34.3.3 スケジュールに関する事項 - プロジェクト計画書及び調達仕様書に基づき、運用を行う上で基本とする作業内容、そのスケジュール、関係する他の作業工程、そのスケジュール等について記載する - 成果物に関する事項 - 運用によって納品される成果物の内容、担当者、納入期限、納入方法、納入部数等について記載す ### 39.34.3.4 運用形態、運用環境等 - 運用において採用する運用形態（オンサイト、リモート等）、運用環境（本番環境、検証環境、研修環境等の有無）等を、必要に応じて、記載す ### 39.34.3.5 その他 - 上記アからオまでに掲げる事項のほか、運用を行う上での前提条件、時間、予算、品質等の制約条件等について記載する ### 39.34.4 運用実施要領の作成・記載内容 - プロジェクト計画書及び運用計画と整合性を確保しつつ作成し、原則として次のアからクまでに掲げる事項について記載する ### 39.34.4.1 コミュニケーション管理 - 運用に携わる事業者、関係事業者等との合意形成に関する手続、連絡調整に関する方法、運用事業者が参加すべき会議・開催頻度・議事録等の管理等について記載する - インシデント発生時の連絡手段や報告要領についても記載する - ＰＪＭＯが議事録の正確性を確認し、修正することができること及びその手順を盛り込む ### 39.34.4.2 体制管理 - 運用に携わる事業者における作業体制の管理手法等について記載する ### 39.34.4.3 作業管理 - 運用の作業及びその品質の管理手法等について記載する ### 39.34.4.4 リスク管理 - リスク認識の手法、リスクの管理手法、顕在時の対応手順等について記載する ### 39.34.4.5 課題管理 - 発生時の対応手順、管理手法等について記載する ### 39.34.4.6 システム構成管理 - 運用における情報システムの構成（ハードウェア、ソフトウェア製品、アプリケーションプログラム、ネットワーク、外部サービス、施設・区域、公開ドメイン等）の管理手法等について記載する ### 39.34.4.7 変更管理 - 運用により発生する変更内容について、管理対象、変更手順、管理手法等について記載する。特に、ＯＤＢの格納データ及び文書の変更管理については適切に行えるよう記載する ### 39.34.4.8 情報セキュリティ対策 - 運用における情報漏えい対策等について記載する ### 39.34.5 保守作業計画の案の作成・記載内容・確定 - ＰＪＭＯは、設計・開発時に作成した保守作業計画の案（「第７章４．5) 運用計画及び保守作業計画の案の作成」参照）、調達仕様書、要件定義書、運用計画等に基づき、必要に応じて他の関連する事業者の支援を受けて、保守作業計画の案の作成を行う。保守作業計画には、原則として次のアからカまでに掲げる事項について記載する - 附属文書として、定期保守項目、保守業務フローなどの作業項目、作業内容、スケジュール、担当者等について記載するものとする - ＰＪＭＯは、これにより作成した保守作業計画の案を、必要に応じて、ＰＭＯ及び関係機関と調整し、確定する ### 39.34.5.1 作業概要 - 保守の対象範囲、作業概要等について記載する。この際、瑕疵担保責任の範囲内で実施する作業との分担を明確にする ### 39.34.5.2 作業体制に関する事項 - ＰＪＭＯ、保守事業者のみならず、保守に関わる関係機関、情報システムの利用者、運用事業者等の関係事業者等の保守に関連する全ての関係者について、その体制、関係者間の関係性、役割分担、責務等について記載する ### 39.34.5.3 スケジュールに関する事項 - プロジェクト計画書及び調達仕様書に基づき、保守を行う上で基本とする作業内容、そのスケジュール、関係する他の作業工程、そのスケジュール等について記載する ### 39.34.5.4 成果物に関する事項 - 保守によって納品される成果物の内容、担当者、納入期限、納入方法、納入部数等について記載す ### 39.34.5.5 保守形態等 - 保守において採用する保守形態（オンサイト、リモート等）等を、必要に応じて、記載す ### 39.34.5.6 その他 - 保守を行う上での前提条件、時間、予算、品質等の制約条件等について記載する ### 39.34.6 保守実施要領の作成・記載内容 - 保守実施要領は、プロジェクト計画書、運用実施要領及び保守作業計画と整合性を確保しつつ作成し、原則として次のアからクまでに掲げる事項について記載する - コミュニケーション管理 - 保守に携わる事業者、関係事業者等との合意形成に関する手続、連絡調整に関する方法、保守事業者が参加すべき会議・開催頻度・議事録等の管理等について記載する - ＰＪＭＯが議事録の正確性を確認し、修正することができること及びその手順を盛り込む ### 39.34.6.1 体制管理 - 保守に携わる事業者における作業体制の管理手法等について記載する ### 39.34.6.2 作業管理 - 保守の作業及びその品質の管理手法等について記載する ### 39.34.6.3 リスク管理 - 保守における作業を阻害する可能性のあるリスクを適切に管理するため、リスク認識の手法、リスクの管理手法、顕在時の対応手順等について記載する ### 39.34.6.4 課題管理 - 保守において解決すべき問題について、発生時の対応手順、管理手法等について記載する ### 39.34.6.5 システム構成管理 - 保守における情報システムの構成（ハードウェア、ソフトウェア製品、アプリケーションプログラム、ネットワーク、外部サービス、施設・区域、公開ドメイン等）の管理手法等について記載する ### 39.34.6.6 変更管理 - 保守により発生する変更内容について、管理対象、変更手順、管理手法等について記載する ### 39.34.6.7 情報セキュリティ対策 - 保守における情報漏えい対策等について記載する ## 39.35 運用の実施 - 運用を行うときは、少なくとも次のア及びイのとおり実施する ### 39.35.1 定常時対応 - 運用計画及び保守作業計画に基づき、運用事業者、保守事業者等と定期的（毎月等）に会議（以下単に「定期運用会議」という。）を開催し、次のとおり作業を行う ### 39.35.1.1 作業実績把握と確認 - 運用事業者等に対し、当該月の作業実績等をまとめて報告するよう求め、少なくとも次の①から⑥までに掲げる事項を確認するものとする - ①　作業実績状況 - ②　サービスレベルの達成状況 - ③　情報システムの構成と運転状況 - ④　情報システムの定期点検状況 - ⑤　情報システムの利用者サポート、教育・訓練状況 - ⑥　リスク・課題の把握・対応状況 ### 39.35.1.2 ライセンス管理 - ソフトウェア製品の保守の実施において、ソフトウェア製品の構成に変更が生じる場合には、運用事業者等からその旨の報告を受け、変更後の環境がライセンスの許諾条件に合致するか確認する ### 39.35.1.3 作業実績に関するＯＤＢへの登録・更新 - 毎月、運用事業者等から提出されたデータに基づき、速やかに、ＯＤＢに登録・更新する ### 39.35.1.4 情報共有 - 運用事業者、保守事業者等に対し、業務の運営状況、今後の見通し等を提示するとともに、情報システムの運用上のリスク等について確認し、情報を共有の上、リスク対応等が必要な場合には対応策を検討する ### 39.35.2 障害発生時対応 ### 39.35.2.1 対応 - 情報システムについて障害が発生し、又は発生するおそれがあるときは、運用及び保守における実施手順等に基づき、運用事業者、保守事業者等の作業分担を明らかにし、対応を行う - 関係機関、情報システムの利用者等に発生事象内容と対応策を連絡する - 同様の事象が将来にわたって発生する可能性がある場合には、運用事業者等に対し、事象の分析及びその対応策の提出を求め、必要な措置を講ず ### 39.35.2.2 障害報告 - 運用事業者、保守事業者等から障害発生の報告を受け、情報システムの安定的な運用が困難になるおそれがあると認められる場合及び他の情報システムの運用に悪影響が生じるおそれがあると認められる場合には、ＰＭＯ等へ報告するものとし、併せて府省ＣＩＯ補佐官等の支援及び助言を受けて、必要な対策を講ず - 情報漏えい等の情報セキュリティインシデントが発生した場合は、自府省の情報セキュリティポリシー等により規定されたルールに基づき、対応す - る ## 39.36 保守の実施 - 保守を実施することにより、情報システムを構成するソフトウェア製品、ハードウェア等を改修又は更改する場合には、設計書の変更管理等、設計・開発時と同様の取組を行 - 保守について、保守契約に基づく作業と瑕疵担保責任に基づく作業とを明確に区別して管理する - 作業内容、作業手順等について事前に確認し、業務への影響等について把握の上、保守作業の実施の時期について判断を行う ### 39.36.1 定常時対応 - 定期運用会議に保守事業者の参加を求め、次のとおり作業を行う ### 39.36.1.1 作業実績把握と確認 - 保守事業者に対し、当該月の作業実績等をまとめて報告するよう求め、少なくとも次の①から④までに掲げる事項を確認す - ①　作業実績状況 - ②　サービスレベルの達成状況 - ③　情報システムの定期点検状況 - ④　リスク・課題の把握・対応状況 ### 39.36.1.2 作業実績に関するＯＤＢへの登録・更新 ### 39.36.2 障害発生時対応 - 保守事業者が担当する案件についても、「２．1)イ 障害発生時対応」に規定する内容と同様の取組を行う ### 39.36.3 情報システムの現況確認 - ＯＤＢの格納データの内容が実際の情報システムの状況を反映したものとなるよう、運用計画及び保守作業計画に基づき、毎年度末までに、運用事業者、保守事業者等とともに、ＯＤＢの格納データと情報システムの現況との突合・確認を行う - ①　ＯＤＢの格納データと情報システムの現況との間に相違があった場合　ＯＤ - Ｂの格納データの更新及び再発防止策の検討・実施 - ②　ライセンス許諾条件違反　ライセンス許諾条件への適合等 - ③　サポート切れ　サポート切れの影響及び今後の対応策の検討等 - ④　ハードウェア、ソフトウェア製品等の利用を停止したとき　ＯＤＢにその旨の登録（ただし、その利用を一旦停止 - 利用の停止から再利用の実施までの手続は、会計担当部門の協力を得て、会計法令等に基づく手続の実施、再利用候補物の保管場所の確保等が必要となることに留意する ### 39.36.4 運用及び保守作業の改善 - 毎年度末までに、当該年度の運用実績等から、作業効率や作業項目の過不足を評価・検証する - 要求する水準を満たしていないときは、ＰＪＭＯは、運用事業者、保守事業者等に対し、運用実施要領又は保守作業実施要領に沿った対応を求めるほか、当該事業者とともに運用実施要領又は保守作業実施要領の改善を検討する - やむを得ず原契約の範囲に含まれない作業項目を追加する必要が生じた場合には、契約変更等を検討する ### 39.36.5 大規模災害等の発災時の対応 - 各府省の業務継続計画に基づき、情報システム運用継続計画を策定する - 大規模災害等の発災時においては、この情報システム運用継続計画に従い、情報システムの運用及び保守を行う - 発災時における円滑かつ迅速な対応のため、ＰＪＭＯは、定常時から定期的に、発災時における運用及び保守の体制への移行について、訓練を行う - 当該訓練の結果を受け、情報システム運用継続計画の見直しを行う ### 39.36.6 運用計画及び保守作業計画の見直し - 毎年度末までに、当該年度の運用実績等を踏まえ、必要に応じて、府省ＣＩＯ補佐官からの助言を受け、運用事業者、保守事業者等とともに、運用計画及び保守作業計画の見直しを行う - 中長期運用・保守作業計画の見直しも併せて行う ### 39.36.7 運用事業者、保守事業者等からの引継ぎ等 - 運用事業者、保守事業者等から必要な引継ぎ等が確実に行われるようにする ### 39.36.7.1 情報システムの更改に関する情報提供 - 情報システムを更改するときは、運用事業者、保守事業者等に対し、次期の情報システムにおける要件定義又は設計・開発に携わる事業者に作業経緯、残存課題等に関する情報を提供させ、かつ、質疑応答等の必要な協力を求める ### 39.36.7.2 更改を伴わない事業者の交代に伴う引継ぎ - 情報システムの更改を伴わずに、運用事業者、保守事業者等に交代が生じるときは、交代前の事業者から交代後の事業者に対し、作業経緯、残存課題等について確実に引継ぎがなされるよう求める ## 39.37 システム監査の実施 - 所管する情報システムがもたらす業務への影響等を客観的に評価するために、内部又は外部からの支援を得て、次のとおり監査を行う - システム監査計画に定めがない場合であっても、ＰＪＭＯが監査を行う必要があると認めたとき、又はＰＭＯから監査の指示があったときは、ＰＪＭＯは監査を行う ### 39.37.1 監査体制の確立 - 監査の独立性及び客観性の確保の観点から、監査実施前に、少なくとも次のアからエまでに掲げる事項を満たす監査体制を確立する ### 39.37.1.1 監査責任者 - 監査体制に監査責任者を置くこ ### 39.37.1.2 独立性 - 監査体制の構成員の半数以上の者は、監査対象となるプロジェクト、情報システムに関する業務等に関与していないこと ### 39.37.1.3 監査能力 - 監査体制の構成員のうち少なくとも一人は、監査の実務経験を有すること ### 39.37.1.4 専門性 - 少なくとも一人は、監査目的に応じた技術的な知識及び実務経験を有すること ### 39.37.2 監査実施計画書の作成と記載内容 - 監査実施計画書の記載内容 ### 39.37.2.1 監査対象 ### 39.37.2.2 監査目的 ### 39.37.2.3 監査範囲 ### 39.37.2.4 スケジュール ### 39.37.2.5 監査体制 ### 39.37.2.6 監査実施方法 - 利用する監査技法について記載する - 監査手続を実施するために監査体制の構成員に技術的な能力が要求される情報システムを利用した監査技法又は実施に一定の準備が必要になるアンケートの実施等の監査技法を用いる場合には、その旨を必ず明記する - 主たる監査手続におけるインタビュー対象人数、調査対象の書類数等のおおよその数（サンプリング数）について記載する ### 39.37.2.7 その他 - 監査を実施する上での条件、守秘義務等について記載する ### 39.37.3 監査実施計画書の調整・確定 システム監査計画に基づき監査を行うとき、又はＰＭＯの指示により監査を行うときは、あらかじめ監査実施計画書の案をＰＭＯと調整した上で、確定する ### 39.37.4 監査の実施 監査体制の構成員が監査を実施するときは、監査手続書を作成した上で監査を行う ⅰ）ＰＪＭＯに報告するものとし、また、ⅱ）ＰＪＭＯがシステム監査計画に基づき監査を行ったとき又はＰＭＯの指示により監査を行ったときはＰＭＯに併せて報告する ### 39.37.5 指摘事項への対応 監査結果により指摘された事項については、これを課題として認識の上、対応し、当該対応の結果について、ⅰ）監査責任者に報告するものとし、ⅱ）システム監査計画に基づく監査又はＰＭＯの指示による監査の場合はＰＭＯに併せて報告するものとする ### 39.37.6 フォローアップ システム監査計画に基づく監査又はＰＭＯの指示による監査の場合は、ＰＭＯは、当該監査の結果への対応について、必要に応じ、フォローアップを行う ### 39.37.7 監査に関する調達の特例 監査業務を委託する場合、「第６章 調達」の規定に従うものとする。このほか、特例として、監査に関する調達仕様書を作成するときは、次の1）から3）までに掲げる事項を盛り込む ### 39.37.7.1 作業の実施に当たっての遵守事項 監査結果及び監査で知り得た情報を監査体制の構成員以外の者と共有してはならない ### 39.37.7.2 入札制限 監査対象である情報システムの調達案件（監査業務案件を除く。）に関与した事業者は、監査の独立性及び客観性の確保の観点から、当該情報システムの監査に関する調達案件の入札に参加できない ### 39.37.7.3 再委託に関する事項 原則として、監査業務の再委託は行ってはならない ## 39.38 情報システムの見直し又は廃止 ## 39.39 ハードウェア、ソフトウェア製品等の廃棄又は再利用 ### 39.39.1 廃棄 ### 39.39.1.1 廃棄対象物の確認 - 廃棄を行う事業者に対し、廃棄物、数量、所有形態、再利用の可否、廃棄方法等を記載した廃棄対象物リストの提出を求め、適切に廃棄されるようその内容を確認する ### 39.39.1.2 廃棄物の確認 - 廃棄後、廃棄を行う事業者に対し、廃棄対象物リストどおりに廃棄したことを確認する - 自府省の情報セキュリティポリシーに基づき、電磁的記録の抹消・破壊等の適切な措置を講ずる ### 39.39.2 再利用 - 復元困難な方法によりデータを消去する等の措置を講じた上で、再利用先への引渡しを行う - その購入の際に納品されたメディアやライセンス証書等、ライセンスの保有を証明するために必要となる部材も併せて引き渡す ## 39.40 【別紙】情報システムの経費区分 ## 39.41 【別紙】調達仕様書に盛り込むべきＯＤＢ登録用シートの提出に関する作業内容 ### 39.41.1 契約金額内訳 「別紙２　情報システムの経費区分」に基づき区分等した契約金額の内訳 ### 39.41.2 設計・開発 ### 39.41.2.1 開発規模の管理 - 情報システムの開発規模（工数、ファンクションポイント（「第３編第３章２．経費の見積り」参照）等）の計画値及び実績値 ### 39.41.2.2 ハードウェアの管理 - ハードウェアの製品名、型番、ハードウェア分類、契約形態、保守期限等 ### 39.41.2.3 ソフトウェアの管理 - ソフトウェア製品の名称（エディションを含む。）、バージョン、ソフトウェア分類、契約形態、ライセンス形態、サポート期限等 ### 39.41.2.4 回線の管理 - 回線の回線種別、回線サービス名、事業者名、使用期間、ネットワーク帯域等 ### 39.41.2.5 外部サービスの管理 - 情報システムを構成するクラウドコンピューティングサービス（「第３編第５章１．2)ア ＲＦＩに関する説明書の作成」参照）等の外部サービスの外部サービス利用形態、使用期間 ### 39.41.2.6 施設の管理 - 情報システムを構成するハードウェア等が設置され、又は情報システムの運用業務等に用いる区域を有する施設の施設形態、所在地、耐久性、ラック数、各区域に関する情報等 ### 39.41.2.7 公開ドメインの管理 - 情報システムが利用する公開ドメインの名称、ＤＮＳ名、有効期限等 ### 39.41.2.8 取扱情報の管理 - 情報システムが取り扱う情報について、データ・マスタ名、個人情報の有無、格付等 ### 39.41.2.9 情報セキュリティ要件の管理 - 情報システムの情報セキュリティ要件 ### 39.41.2.10 指標の管理 - 情報システムの運用及び保守の間、把握すべきＫＰＩ注記）名、ＫＰＩ分類、計画値等の案 注記）ＫＰＩ（Key Performance Indicator）とは、目標・戦略を実現するために設定した具体的な業務プロセスをモニタリングするために設定される指標（業績評価指標：Performance Indicators）のうち、特に重要なものをいう ### 39.41.3 運用及び保守 ### 39.41.3.1 各データの変更管理 - 内容に変更が生じる作業をしたときは、当該変更を行った項目 ### 39.41.3.2 作業実績等の管理 - 情報システムの運用及び保守中に取りまとめた作業実績、リスク、課題及び障害事由 ### 39.41.4 その他 - 役務を伴う調達案件については、ＰＪＭＯの求めに応じ、スケジュールや工数等の計画値及び実績値 ## 39.42 【別紙】スタンドアロンコンピュータの管理 # 40 政府情報システムの整備及び管理に関する標準ガイドライン【実務手引書】 【参照】000348369政府情報システムの整備及び管理に関する標準ガイドライン【実務手引書】 [http://www.soumu.go.jp/main_sosiki/gyoukan/kanri/infosystem-guide.html](http://www.soumu.go.jp/main_sosiki/gyoukan/kanri/infosystem-guide.html) ## 40.1 プロジェクト計画書の記載事項 ### 40.1.0.1 プロジェクトの目的 - 目的 - 背景 - 位置づけ ### 40.1.0.2 対象範囲 対象とする主要業務の数は、プロジェクトの規模によって異なるため、場合によっては、一つであることもあり得る。 - 対象とする主要業務 - 整備する情報システム - 整備する情報システムの一覧 - 整備する情報システムの主要機能 - 調達単位 - 小規模プロジェクトの場合は、設計・開発から保守までをひとつにまとめることもあり得る。プロジェクトの性格に応じて考慮する。 - 成果物 - 成果物及び納期は、最初から全て決定することはできないため、決定するたびに記入を行い、更新履歴に示す。 ### 40.1.0.3 業務の見直しの方向性等 - 見直しの方向性 - 業務統合、ワンストップサービス化、業務内容の高度化、内部統制の強化、情報セキュリティの強化、、、、 - プロジェクトの推進にかかわる課題 - 既存業務の継続、利用者の理解度・習熟度向上、法令順守の徹底、関係部局との適切な調整、、、 - 求める効果 - 政策目標の達成、業務統合、内部統制の強化、情報セキュリティの強化、、、 ### 40.1.0.4 予算 各年度で見直しを行うものとするので、その結果を反映させ、更新履歴に示す。実績との対比ができるように管理されることが望ましい。 各年度において予算が承認された段階で、より詳細な経費区分で予算の明細を作成し、プロジェクト計画書に添付する。 - 整備経費、運用等経費、その他経費 ### 40.1.0.5 目標 要件定義の確定等で、当初計画とは異なるものが設定されることもあるので、その結果を反映させ、更新履歴に示す - 業務効果に関する指標 - 情報システム効果に関する指標 ### 40.1.0.6 体制 当該プロジェクトの性格によって体制及び役割・責任は異なるので、実態に即したものとする。 プロジェクトの進行（特に要件定義の確定）で、体制は見直されるため、修正を行い、更新履歴に示す。 - 全体体制図 - ＰＪＭＯの体制 - 有識者が関わる会議 - 有識者が関わる会議の開催目的 - （開催の目的を記述） - 有識者に期待する事項 - （有識者に求める知識や経験の内容等を記述） - 関係機関 - 事業者 - プロジェクト管理支援事業者 - プロジェクト全体の管理支援 - 要件定義書作成支援 - 業務情報システム設計・開発 - 業務情報システムの要件確定 - 業務情報システムの設計・開発 - 関連サブシステム間の調整 - 業務支援サブシステム設計・開発 - 業務システム基盤システム構築 - 業務情報システム保守 - 業務支援サブシステム保守 - 業務システム基盤システム保守 - 全体システム運用 ### 40.1.0.7 実施計画 - プロジェクト全体のスケジュール - 予算の確保 - 有識者会議等 - ＲＦＩ等実施 - プロジェクト管理支援 - 業務の見直し及び設計 - 要件定義（全体） - 設計・開発の調達 - 運用及び保守の調達 - ○○業務情報システム - ○△業務支援サブシステム - ○□業務支援サブシステム - ○○業務システム基盤システム - 工程レビュー - 総合運用 - 継続的な業務改善 - プロジェクト計画の見直し - プロジェクト完了 - 目的の達成、その他の条件の成立によって完了する場合には、その条件を記す。 - スケジュール詳細 - 予算の確保 - 有識者会議等 - ＲＦＩ等実施 - プロジェクト管理支援 - 業務の見直し及び設計 - 要件定義（全体） - 設計・開発の調達 - 運用及び保守の調達 - ○○業務情報システム - ○△業務支援サブシステム - ○□業務支援サブシステム - ○○業務システム基盤システム - 工程レビュー - 総合運用 - 継続的な業務改善 - プロジェクト計画の見直し - 進捗および実績報告 ### 40.1.0.8 その他 - 前提条件 - 前提条件、対応方針 - リスクの要因 - リスクの要因、対応方針 - その他 - その他、プロジェクトの進行上で留意すべき事項を記述 ## 40.2 プロジェクト管理要領 ガイドラインで示されている範囲の個別管理について、記述の概要を示す。（当初計画段階） プロジェクトの進行に応じて作成される個別管理（構成管理等）の要領については、作成されたものを添付することで、全体を管理する。 ### 40.2.0.1 コミュニケーション管理 - PJMO内の会議 - 関係機関等との調整 - プロジェクトの実行体制内における会議体 ### 40.2.0.2 工程管理 - 工程管理方法について - 工程管理手法 - 工程管理で使用するツール - 進捗状況の報告 - 報告を求める事項 - 報告の責任者 - 報告の流れ - 報告の頻度 - 工程終了条件 - （各工程の終了条件、判定手続等を示す。終了条件となるのは、各工程の成果物の完成や終了を判断する基準となるものである。このうち成果物とは、各工程で完成すべきもの（設計書、アプリケーションプログラム等）を指し、終了を判断する基準には、設定した品質基準や性能水準を達成すること、利用者教育の完了や次の工程の事業者への引継ぎ完了等がある。また、判定手続とは、納品物の内容の確認、品質基準や性能水準を確認する各テストの実行と判定といった手続がある。） ### 40.2.0.3 指標管理 - 業務効果に関する指標 - 情報システム効果に関する指標 - その他の指標 - 情報システムの品質や性能の目標、運用段階におけるサービスレベルの目標等について、管理のサイクルとともに、別途、各工程の前に定めるものとする。 - 指標の達成に関する課題の取扱いについて - プロジェクトの進行段階に応じて、新たに管理すべき指標が設定される。業務の見直しの結果で設定されるもの、設計・開発段階であれば品質管理に関するもの等、運用段階ではサービスレベル等がある。 - 各段階で、管理すべき指標が追加されることを想定している。 - また目標値の見直しもある。 - 各段階で新たに設定されたものを追加しながら、各段階において重要な指標が適切に管理されることが重要である。 - また、管理のための帳票は、それぞれの府省の事情に応じて作成されるものである。 ### 40.2.0.4 リスク管理 プロジェクトの進行段階に応じて、新たに管理すべきリスクの要因が発見されるため、その都度、管理する対象に加える。 - リスク管理の手法 - リスク管理で使用する帳票 ### 40.2.0.5 課題管理 問題、課題、情報セキュリティインシデント、リスク顕在化時の対応等、解決すべき事項については一元的に管理することが望ましい。 - 課題管理の手続 - 課題の特定と分類 - （問題となる事象の分類、優先順位付け、対応の方針等について記述する） - 問題となる事象の調査と診断 - （問題となる事象の調査と診断の手続を記述する） - 課題の登録と対策の検討 - （課題及びその解決策等の登録、解決策の実行管理等について記述する。） - 課題登録簿 - 課題個別管理票 ### 40.2.0.6 変更管理 変更管理の対象は、最初からすべて決まっているわけではなく、プロジェクトの進行に応じて、変更管理すべき対象が追加される。 変更管理の対象が追加されたら、更新履歴に示す。 - 変更管理の手続 - 変更管理の対象 - 変更管理簿 - その他 - 変更管理の原因となった事項が、課題として管理されるべき事項であれば、課題管理にも反映させるものとする。 ## 40.3 業務の見直し ![[Untitled 8 8.png|Untitled 8 8.png]] ![[Untitled 9 8.png|Untitled 9 8.png]] - 既存の業務において新たに情報システムを整備する場合 -  既存の業務において新たに情報システムを整備する場合 既存の情報システムが存在しないため、本実務手引書の記述のうち、既存情報システムに関する調査及び分析を除外して適用する。 ただし、連携する情報システムが想定される場合には、連携のための要件（外部インタフェース）について、調査を行っておく必要がある。 -  既存の業務及び情報システムを見直し、更改する場合 - 本実務手引書の記述の全体を適用する。 -  新たな業務を開始するに当たって情報システムを新規に整備する場合 - 既存の業務も既存の情報システムも存在しないため、実務手引書「第３編第４章２．業務の見直し範囲の検討」、同「第３編第４章３．分析等」及び同「第３編第４章４．業務の見直し内容の検討」は適用対象外となる。 - トップダウンアプローチから業務の設計を行い、そのために必要となる情報システムの要件を明らかにする。その際に、新業務及び新規情報システムを実現する上で解決すべき課題を洗い出すこと、連携する必要があると想定される他の業務及び情報システムについて、連携のための条件を洗い出すことが必要である。 ### 40.3.1 業務の見直し範囲の検討 ＰＪＭＯは、情報システムの整備を行う場合には、業務全体の見直しを検討するものとする。なお、情報システムの更改又は機能改修を行う場合には、その対象となる業務の範囲を超えた見直しの必要性を検討するものとする。 - プロジェクトを遂行するにあたっては、情報システムの整備対象範囲にとどまらず、業務そのものの見直しを検討することが重要となる。 - この場合、当初計画段階のプロジェクト計画書において設定した目標の達成に向けて、具体的にどのような方策を採るべきか、情報システムのみならず、業務体制や業務処理ルールも含め、どの範囲までの改善に取り組むか、業務全体の見直しを検討することが必要である。 - 特に、情報システムの更改又は機能改修は、業務全体の見直しを行う有効な機会であり、単に情報システムの機器等の入替えや操作性等の機能面の改修にとどまることなく、**更なる業務の効率化や新たな価値の創出（新しい行政サービスの提供等）に心掛け、当該情報システム又はその機能が対象とする業務の範囲を超えて、この際業務を見直すべき点はないか、業務見直しの必要性を検討する**ことが適当である。 - なお、業務の見直しに当たっては、現行業務の分析を行う必要があるが、分析に先駆けて、プロジェクトの目標が表す価値や効用を理解し、その達成要因として実現すべき状態を段階的に詳細化し（図４－２－１参照）、業務見直しの可能性を洗い出すことが肝要である。さらに、それを基に問題点の抽出を行い、対応の方向性と業務の見直しの具体策を検討するアプローチ（図４－２－２参照）が有用である。 - また、業務の見直しにおいては、当該業務の範囲にとどまらず、当該業務を実施する端緒となった前工程（例えば、地方自治体からの通知受領等）も含めて、全体の業務フローの各工程を詳細に整理する。これにより、分析において、各工程間の所要時間、連絡手段（例えば、郵送、電子メール）、連絡手段に係るコスト（例えば、郵送料、宅配便の料金、通信費用等）等も含め、費用対効果を含めて全体を詳細に把握することが可能となる。 ![[Untitled (4) 1.png]] ![[Untitled (5) 1.png]] ### 40.3.2 分析等 ![[Untitled 12 5.png|Untitled 12 5.png]] 業務を抜本的に見直す場合は、既存の業務処理方法・情報システム如何を問わず、政策目的及び制度に基づくトップダウンの視点から理想的な業務の在り方を検討する。 必要に応じて、他の類似業務の調査を行い、業務処理方法の標準化を検討することが肝要である。また、汎用的なソフトウェア製品やクラウドコンピューティングサービスの機能を、カスタマイズを最小化して導入し、業務をこれらの情報システムに合わせる方法も検討する価値がある。 業務の抜本的な見直しに当たって、既存の業務や情報システムが足かせになり、これに縛られて見直しが妨げられることがないように留意する必要がある。一方で、現に行われている業務を新たな業務・システムに円滑に引き継ぎ、確実に履行できることを担保する必要もある。そのためには、例外処理等の特殊な運用も含め、現在の業務の実態を詳らかにした上で、それをどのように見直すのかを一つ一つ丁寧に整理することが不可欠である。複数の府省や組織が関わるプロジェクトや、国民が利用する情報システムの場合は、このプロセスが特に重要である。 また、業務の確実な履行を担保するためには、制度所管部門及び業務実施部門が中心となり、情報システム部門や運用・保守等の事業者、当該業務のサービス利用者など、多角的・複層的な観点で現状を把握し、その問題点を把握することが必要である。 - 業務分析 > 業務及びデータの内容、流れ、業務量、データ保有形態、データ量、実施体制、実施時期・時間、実施場所、残存課題等 - 業務の現状把握 - 業務の範囲（業務機能とその階層） -  業務機能一覧（表形式） -  業務機能階層図（ツリー図形式） - 業務の内容、流れ - BPMN - UML - データの内容、流れ - データ保有携帯、データ量 - データの構造 - UMLクラス図 - ![[Untitled 13 5.png|Untitled 13 5.png]] - [http://www.soumu.go.jp/denshijiti/system_tebiki/hyouki/gyomu/2a-9-uml.html](http://www.soumu.go.jp/denshijiti/system_tebiki/hyouki/gyomu/2a-9-uml.html) - ![[Untitled 14 5.png|Untitled 14 5.png]] - [http://www.soumu.go.jp/denshijiti/system_tebiki/hyouki/kadai/4-2-erd.html](http://www.soumu.go.jp/denshijiti/system_tebiki/hyouki/kadai/4-2-erd.html) - 業務量、実施体制、実施時期・時間、実施場所 - 関係者分析 - 業務実施部門の従事者、業務によるサービスを受ける者その他当該業務に関係する者のそれぞれの規模、特徴、満足度、要求事項等 - 実績分析 - 業務の運営実績、各種指標の状況等 - 環境分析 - 業務を取り巻く現在の環境、将来の環境変化の見込み等 - 関連調査 - 業務に影響する関連法令の存否、影響度、見直しの必要性、類似する業務の存否、優良事例、失敗事例等 ### 40.3.3 業務の見直し内容の検討 - 見直しにより高い効果が見込まれる内容について、これを取り組むべき主要課題として整理の上、政策目的を実現するためにより効果的な業務となるよう、具体的な業務の見直し内容とその結果期待される効果について、多角的かつ複層的に検討する - 当該業務のみならず、関連組織の関係業務にも影響が及ぶと想定される場合には、ＰＪＭＯは、ＰＭＯの支援を受け、当該関係業務の見直し権限を有する者と調整・協議を行う - 主要課題の定義 - 分析において洗い出された問題点とその対応案について、内容の精査及び集約整理を行った上で、重点的に取り組むべき問題点とその対応案を主要課題として定義し、優先順位付けを行う。その手順を次に示す。 -  問題点への対応案について、偏りがないか、網羅的に検討がなされているかを精査する。対応案を検討する際には、実務手引書「第３編第４章別紙４－１－４ 問題点洗い出しの観点と見直しの方向性の対応例」を参考に、少なくとも代表的な見直し内容については検討することを推奨する -  問題を放置した場合の影響や対応の方向性として同種と思われるものをグループ化し、また、それらを階層化し、グループ間の因果関係や相反関係を整理する -  実務手引書「第３編第４章２．業務の見直し範囲の検討」で検討した業務見直しの可能性を踏まえ、対応案をひも付けて整理する -  問題点の全体を俯瞰し、抽出漏れがある場合は補完する -  問題点を解決する上での有効性（政策目的及びプロジェクトの目標への貢献）を検証し、解決の困難性、緊急性、費用対効果等の観点も考慮の上、取り組むべき優先順位を設定し、主要課題を抽出する - なお、行政サービスの提供を行政自らが行う目的・理由について、現状追認でなく、今後のあるべき姿（例えば、民間開放や民間・地方自治体協働）を検証する中で検討し、当該サービスの提供価値を最大化するよう取り組んでいくことも重要である。 - 見直し内容の検討 - 主要課題の定義を踏まえ、講ずるべき具体的な手段を検討するとともに、それにより実現が期待される効果を記載する。 - なお、情報システムを利用する業務が複数の組織で行われている場合、その全業務の一斉集約や全情報システムの一斉統合が、必ずしも効率化をもたらすとは限らない。業務には適正な規模が存在するため、急激な統合ではなく、段階的にプロセスを踏んだ統合が望ましい場合もある。業務の見直しに当たっては、当該業務の個別事情を把握し、多角的かつ複層的に検討の上、システム統合の効果を見積もる必要がある。例えば、まずは類似する業務から見直しを行い、共通化できた業務に合う情報システムを構築するという方法もあり得る。また、見直しによる効果が現れやすいと見込まれる部分から措置を講ずることで、目的もなく全てのプロセスを見直すといったことがないようにすることも一案である。 - 主要課題及び見直し内容の検討結果は、実務手引書「第３編第４章別紙４－１－３ 主要課題と見直し内容整理表」を活用して整理することができる。 ## 40.4 業務要件定義書 業務要件の定義は、情報システムの機能要件及び非機能要件を具体化する前段階として、見直し後の業務の内容及び手順並びに情報システムに対する機能及び性能等の要求を具体化し、要件定義以降の工程に的確に伝えることを目的として行う。 なお、この段階で定義した業務要件は、要件定義段階におけるＲＦＩ等の結果注１）や、機能要件及び非機能要件の定義過程における技術的観点や業務に対する有効性の観点等からの検証を踏まえ、整合性（定義した機能要件と業務実施手順及び情報システム化範囲の一致等）を確認し、更新する必要があるものである。そのため、制度所管部門及び業務実施部門を中心として、要件定義段階でも引き続き業務の見直しに関する主体的な検討が必要である。 さらに、設計・開発段階では、業務要件を実現するために必要な機能及び性能を確実に実現するため、制度所管部門及び業務実施部門の立場から、情報システムの設計や受入テストに参加することが必要である。加えて、これと並行し、業務の運営開始に先立つ必要な法令の改正、業務手順書等の作成等の準備を行う必要がある。 - 業務実施手順 業務の実施に必要な体制、手順及びそれらを記載した業務フロー図 入出力情報項目及び取扱量　等 - 業務の範囲（業務機能とその階層） - プロジェクトの対象範囲において情報システム化されない業務を含めて、見直し後の業務を構成する業務機能を階層的に定義するものである。 - 業務フロー図 - 見直し後の業務フローとして、「誰が（どの組織が）」「何を」「どのような手順で」実施するのか、また「どの部分をシステム化するのか」を定義するものである。 - 業務の実施に必要な体制 - 入出力情報項目及び取扱量 - 規模 サービスの利用者数及び情報システムの利用者数 単位（年、月、日、時間等）当たりの処理件数 - サービスの利用者数 - 見直し後の業務によるサービス及び情報システムの利用者の種類とその人数の見込みを明らかにするものである。 - 単位（年、月、日、時間等）当たりの処理件数 - 時期・時間 業務の実施時期、期間及び繁忙期　等 業務の実施・提供時間　等 - 業務の時期・時間 - 「業務を実施・提供する時期・期間・繁忙期はいつか」「業務の実施・提供時間はどの程度か」の見込み - 場所等 > 業務の実施場所、諸設備、必要な物品等の資源の種類及び量　等 - 実施場所 - 諸設備、物品等資源の定義方法 - 情報システム以外に必要な諸設備、物品等資源の追加 - 管理すべき指標 > 業務の運営上補足すべき指標項目、把握手順・手法・頻度　等 - プロジェクトの目標 - 例えば、定性的な目標に対して実績を評価するための段階を定義することや、中間的な達成点に相当する目標値を定義することが必要となる（例えば、５年後に達成すべき目標値に加えて、各年度の目標値を定義する等）。 - 業務効果指標 - プロジェクトの目標の達成及び業務の主要課題の解決という目標につながる達成要因を明らかにする。 - 業務実施指標 - 情報システム以外の業務改善によるものを「業務実施指標」として設定し、その実施状況を評価するための目標値（計画値）及びモニタリング方法を定義する。 - 情報システム性能指標 - 情報システムの機能・性能によるものを「情報システム性能指標」として設定し、その実施状況を評価するための目標値（計画値）及びモニタリング方法を定義する。 - 情報システム化の範囲 - 見直し後の業務において情報システムを用いて実施する業務の範囲及び情報システムを用いずに実施する業務の範囲を整理するものである。 - なお、通常は、この時点で情報システム化の範囲をほぼ確定させることになるが、要件定義の段階で最終的に決定することになる。 - また、ここで定義した情報システム化の範囲は、要件定義段階において機能要件を定義する際の素材として活用することになる。 - 業務の継続の方針等 > 業務の継続に伴うリスク及び基本的な考え方。なお、業務継続計画を策定する必要がある業務にあっては当該計画の策定時に検討する - 業務継続方針を踏まえ、当該業務の停止原因となり得る要因と業務停止による影響を念頭に置き、当該業務の継続のための基本的な考え方を明らかにするものである。 - ここで明らかにする見直し後の業務の継続の方針等は、要件定義段階において情報システムの非機能要件（信頼性、継続性等）の前提として活用する。 - 定常時と大規模災害等の発災時に考慮すべき要因の例を次に示す。 - 定常時：人為的なオペレーションミス、アプリケーションプログラム障害、 - 機器・ソフトウェア故障、情報セキュリティインシデント（サイバー攻撃、情報漏えい、情報改ざん等） 等 - 大規模災害等の発災時：震災、風水害、火災、建物・設備損壊、停電、爆破 > テロ 等 - 上記の要因による影響度を念頭に、業務の継続の方針として次の事項を定義する。加えて、業務継続計画を策定する必要がある業務にあっては、当該計画の内容を確認し、復旧までの間に必要な活動についても確認する。 - 定常時における復旧：復旧の水準（縮退運用、完全復旧等）を考慮した、復旧内容（業務の内容、情報システム機能、データの復元等）及び復旧水準ごとの目標復旧時間 - 大規模災害等の発災時：復旧スケジュールに応じた、業務の実行体制、情報システム機能、データの復元、各段階（初期対応、暫定運用開始及び完全復旧等）の目標復旧時間等 - 定常時における年間の稼働率：年間で稼働が期待される全時間のうち、故障やメンテナンスによる停止時間を除いた実質の稼働時間の比率。なお、稼働率を設定する上では、業務の性格と影響度を踏まえて、過度な要求とならないよう考慮して設定する。 - 一般的に、次のような特徴を有する業務は、目標復旧時間及び稼働率をある程度緩和することが考えられる。 -  長期間停止したとしても、社会的影響が軽微な業務 -  長期間停止したとしても、代替手段（手作業等）により一定の継続が可能な業務 -  発災後２週間～１か月以上業務が停止しても社会的影響や批判が若干程度と予想される業務 - また、大規模災害等の発災時においては、次のような特徴を有する業務は目標復旧時間を短く設定することが考えられる。 -  複数の業務を実施する上で共通的に必要となる業務 -  災害等対策用の業務（安否の確認、伝言掲示板等） - 情報セキュリティ - 取り扱われる情報の格付・取扱制限等に応じた情報セキュリティ対策の基本的な考え方 - 実務手引書「第３編第４章５．1) 業務実施手順」に係る解説「１(2)業務フロー図」及び同「１(4)入出力情報項目及び取扱量」による取扱情報の洗い出し結果を確認する。 - また、要件定義の段階で情報セキュリティ上のリスクを特定し、その対策を機能要件及び非機能要件として定義できるように、情報セキュリティ対策の対象となる情報について、自府省の情報セキュリティポリシーに準拠した格付の区分及び取扱制限を明確化する。特に、新たな業務を開始するに当たって情報システムを新規に整備する場合や、既存の業務の見直しに伴って新たに取り扱う情報がある場合を中心として行うが、従来の格付についても必要に応じて見直しを行う。 - 情報漏えい等による個人のプライバシーの侵害や、国民・組織に財産上の被害を与える等、情報の機密性保護に係るリスクに対する対策は特に重要であるが、情報の改ざんや情報システムの停止による利用者への影響についても考慮する必要がある。 - 【表４－33】(参考)機密性についての格付の区分注） - 格付の区分：分類の基準 - 機密性３情報：行政事務で取り扱う情報のうち、秘密文書に相当する機密性を要する情報 - 機密性２情報：行政事務で取り扱う情報のうち、秘密文書に相当する機密性は要しないが、漏えいにより、国民の権利が侵害され又は行政事務の遂行に支障を及ぼすおそれがある情報 - 機密性１情報：機密性２情報又は機密性３情報以外の情報 - さらに、情報の取扱いについて定められている根拠法令（例えば行政機関個人情報保護法、番号法等）が存在する場合は、要件定義の段階で当該法令を遵守するために必要な情報セキュリティ対策に漏れが生じないよう適切に要件を定める必要があるため、当該法令の存在について確認する。 - また、実務手引書「第３編第４章３．分析等」において情報の漏えい、改ざん等の情報セキュリティに係る問題点が洗い出されている場合は、実務手引書「第３編第４章４．業務の見直し内容の検討」及び同「第３編第４章５．業務要件の定義」が問題点を踏まえたものとなっているかを確認する。 ## 40.5 要件定義書の記載事項 ### 40.5.0.1 業務要件の定義 実務手引書「第３編第４章５．業務要件の定義」において検討した内容及び作成した資料を基に、ＲＦＩの結果注）等を踏まえ、整合性（定義した機能要件と業務実施手順及び情報システム化の範囲の一致等）を確認し、更新する -  業務実施手順 -  規模 -  時期・時間 -  場所等 -  管理すべき指標 -  情報システム化の範囲 ### 40.5.0.2 機能要件の定義 - 業務要件を踏まえて必要な機能を網羅的に整理する - 業務の質の向上、業務の効率化等に対する有効性等を踏まえ、優先度の高い機能から整備する必要がある - 他の情報システムと連携する場合には相互運用性及びデータ互換性についても併せて記載する - 機能に関する事項 - 業務要件として定義した情報システム化の範囲注）を基に、情報システムにおいて備える機能として再構成し、段階的に詳細化した上で、具体的な処理内容、入出力情報・方法、入力・出力の関係等を整理する - 留意点 -  機能の整理に当たり、技術的な実現方法について事業者の提案に委ねる場合は、提案の余地を残した記載（求める結果を記載し、技術的な実現方法に踏み込まない等）とする -  業務の単位ごとに記載する場合も、共通処理機能を識別できるように整理するなど、機能の総数が分かるように記載する - 画面に関する事項 - 画面一覧、画面概要、画面出力イメージ、画面遷移の基本的考え方、画面入出力要件・画面設計要件等を記載する - 帳票に関する事項 - 帳票一覧、帳票概要、帳票出力イメージ、帳票入出力要件・帳票設計要件等を記載する - 情報・データに関する事項 - 情報・データ一覧、情報・データ処理要件、データ構造等を記載する - 原則として、政府において標準化された情報・データ名称、データ構造等を採用する - 外部インタフェースに関する事項 - 外部インタフェース一覧、相手先システム、送受信データ、送受信タイミング、送受信の条件等を記載する ### 40.5.0.3 非機能要件の定義 - 技術的に検討を要する事項を多分に含むことから、日本工業規格等のほか、ＲＦＩ等を通じて、広く情報を取得し、実現性等の検証を行う - 政府共通プラットフォーム等、府省共通システムが提供する稼働環境、サービス等を最大限利用するとともに、その仕様について記載する - クラウドコンピューティングサービスの活用についても検討する - ユーザビリティ及びアクセシビリティに関する事項 - 日本工業規格等を踏まえつつ、情報システムの利用者の種類、特性及び利用において配慮すべき事項等を記載 - 情報システムの利用者の種類、特性 - ＩＴリテラシー、対象業務の実施頻度、対象業務に対する専門性等 - ユーザビリティ要件 - アクセシビリティ要件 - 日本工業規格JIS X8341シリーズ及び情報システムのアクセシビリティに関する自府省の規程を踏まえて定義する - システム方式に関する事項 - ハードウェア、ソフトウェア、ネットワーク等の情報システムの構成に関する全体の方針等について記載する - 情報システムの構成に関する全体の方針 - 情報システムの全体構成 - 開発方式及び開発手法 - 【例】本情報システムの開発方式は【スクラッチ開発／アプリケーションプログラムの移植／ソフトウェア製品のカスタマイズ】を前提とする。 - 【例】本情報システムの開発手法は、【ウォータフォール型／プロトタイピング／アジャイル開発】とする。 - 規模に関する事項 - 機器数、設置場所、データ量、処理件数、情報システムの利用者数等について記載する - データ量については、ライフサイクル期間における将来の見込みも記載 - 機器数及び設置場所 - データ量 - 詳細な定義までは困難な場合であっても、不明確な記載が調達コストの見積り精度に大きく影響することを考慮し、その時点で定義できる範囲で具体的かつ定量的に記載する。 - 処理件数 - 利用者数 - 性能に関する事項 - 応答時間等を記載する - 性能が過度にならないよう適切な要件とする - 応答時間（レスポンスタイム、ターンアラウンドタイム、サーバ処理時間） - スループット - 信頼性に関する事項 - 稼働率等を記載する - 過度にならないよう適切な要件とする - 可用性要件 - 可用性に係る目標値 - 可用性に係る対策 - 機器の故障に起因するデータの滅失や改変を防止する対策を講ずること。 - 異常な入力や処理を検出し、データの滅失や改変を防止する対策を講ずること。 - 処理の結果を検証可能とするため、ログ等の証跡を残すこと。 - データの複製や移動を行う際に、データが毀損しないよう、保護すること。 - データの複製や移動を行う際にその内容が毀損した場合でも、毀損したデータ及び毀損していないデータを特定するための措置を行うこと。 - 電子データの送受信を行う際には電子署名やタイムスタンプを用いることで偽造等から保護することが可能であること。 - 完全性要件 - 【例】• 機器の故障に起因するデータの滅失や改変を防止する対策を講ずること。 - 異常な入力や処理を検出し、データの滅失や改変を防止する対策を講ずること。 - 処理の結果を検証可能とするため、ログ等の証跡を残すこと。 - データの複製や移動を行う際に、データが毀損しないよう、保護すること。 - データの複製や移動を行う際にその内容が毀損した場合でも、毀損したデータ及び毀損していないデータを特定するための措置を行うこと。 - 電子データの送受信を行う際には電子署名やタイムスタンプを用いることで偽造等から保護することが可能であること。 - 拡張性に関する事項 - 情報システムの性能及び機能の拡張性要件について記載する - 特に、将来の機能改修、運用及び保守について、柔軟で効率的に行うことを念頭に、要件を定める - 性能の拡張性 - 【例】• ＸＸ年に予定される全国展開が完了した場合、利用者数が1.5倍になると想定されるが、これに伴い性能が落ちることのないよう、処理能力の向上やデータ保存領域の拡張等が容易に可能な構成とすること。 - 本情報システムの刷新は、全国の拠点を地域で分割して段階導入を行うため、その段階導入のタイミングと併せて、ネットワーク機器やサーバ機器の予備のポートやスロットを用いて適宜最適な拡張が可能な構成とすること。 - 機能の拡張性 - （記載例１：拡張性に関わる設計指針を記載する場合） - 利用者ニーズ及び業務環境の変化等に最小コストで対応可能とするため、本情報システムを構成する各コンポーネント（ソフトウェアの機能を特定単位で分割したまとまり）の再利用性を確保する。 - （記載例２：機能の拡張に際しての費用に言及する場合） - ＸＸ年に予定される制度変更に伴いＸＸ率の値が変更されることが見込まれるため、追加費用なく当該変更への対応を可能とすること。 - 上位互換性に関する事項 - 【例】• クライアントＯＳのバージョンアップに備え、ＯＳの特定バージョンに依存する機能が判明している場合は、その利用を最低限とすること。 - Ｗｅｂブラウザ及び実行環境等のバージョンアップの際、必要な調査及び作業を実施することで、バージョンアップに対応可能な情報システムとすること。 - 中立性に関する事項 - ベンダーロックインの解消等による調達コストの削減、透明性向上等を図るため、市場において容易に取得できるオープンな標準的技術又は製品を用いる等の要件について記載する - 技術又は製品について指定する場合には、指定をする合理的な理由を明記した上で、ハードウェア、ソフトウェア製品等の構成を明らかにする - （記載例１：オープンな標準的技術又は製品の採用を求める場合） - 提供するハードウェア、ソフトウェア等は、特定ベンダーの技術に依存しない、オープンな技術仕様に基づくものとすること。 - 提供するハードウェア、ソフトウェア等は、全てオープンなインタフェースを利用して接続又はデータの入出力が可能であること。 - 導入するハードウェア、ソフトウェア等の構成要素は、標準化団体（ＩＳＯ、ＩＥＴＦ、ＩＥＥＥ、ＩＴＵ、ＪＩＳＣ等）が規定又は推奨する各種業界標準に準拠すること。 - （記載例２：事業者交代時の対応を求める場合） - 次期情報システム更改の際に、移行の妨げや特定の装置や情報システムに依存することを防止するため、原則として情報システム内のデータ形式はＸＭＬ、ＣＳＶ等の標準的な形式で取り出すことができるものとすること。 - 特定の事業者や製品に依存することなく、他者に引き継ぐことが可能なシステム構成であること。 - 継続性に関する事項 - 障害、災害等による情報システムの問題発生時に求められる必要最低限の機能、その目標復旧時間等を記載する - 過度にならないよう適切な要件とする - 継続性に係る目標値 - 継続性に係る対策 - 【例】• 設置する機器については可能な限り共通化し、共通化した単位で予備機を設置（コールドスタンバイ）すること。本番環境の機能が停止した際に、テスト環境に切り替えて運用を継続できること。 - 対象ごとにバックアップの取得手法や保存先、取得時期等を考慮し適切なバックアップ処理が可能なシステムとすること。 - 業務に用いるデータのバックアップ処理は業務への影響を排除した設計とすること。 - バックアップの取得は自動化し、成否について運用管理者へ通知する機能を具備すること。なお、自動化されたバックアップ処理についても運用管理者により手動でバックアップの取得が可能であること。 - 天災等により情報システムの設置場所が完全に滅失した場合に備え、バックアップデータは設置場所からＸkm以上離れた場所に保持すること。ただしＤＲ（Disaster Recovery）サイトの構築は不要とする。 - データ保存機器について二重化すること。 - 情報セキュリティに関する事項 - 過度にならないよう適切な要件とする - 自府省の情報セキュリティポリシーを参照の上、要件を適切に定める - 情報セキュリティ対策要件 - 例： -  主体認証 -  アクセス制御 -  権限管理 -  ログ取得及びログ管理 -  暗号化及び電子署名 -  ソフトウェアの脆弱性対策 -  不正プログラム対策 -  サービス不能攻撃対策 -  標的型攻撃対策 - 情報システム稼働環境に関する事項 - ハードウェアの構成、ソフトウェア製品の構成、ネットワークの構成、施設・設備要件等について記載 - 既存の環境を最大限活用し、不要な調達を行わない - ハードウェア構成 - ハードウェア要件 - ソフトウェア構成 - ネットワーク構成 - 施設・設備要件 - テストに関する事項 - テストの種類、目的、内容等を記載する - 留意点 -  総合テストの内容には性能テスト、負荷テスト及び他の情報システムとの接続試験を含めるほか、必要に応じて、脆弱性検査等を含めることを検討する -  受入テストはＰＪＭＯが実施主体となり、情報システムの主たる利用者が参加して行う。広く国民に利用される情報システムや、府省共通システムの場合も、利用する国民や府省の立場に立ったテストを検討する。 - また、府省共通システムの場合は、必要に応じ、利用する府省に対して、利用府省の立場での受入テストを実施することについて依頼することを検討する。 - 移行に関する事項 - データ等の移行手順等を記載する - 移行手順 - （移行作業の例） -  移行データ調査（既存の情報システムのファイルレイアウト、データレイ - アウトの調査・整備、外字利用の調査、不備データの調査等） -  移行データ整備（不備データの訂正、次期の情報システムで追加されるデ - ータ項目への値設定等） -  移行ツール設計・開発 -  移行リハーサル（移行データの検証、移行時間の測定等） -  移行判定項目と基準の設定 -  移行判定 -  移行の実施 -  稼働判定 -  本番切替え - 移行要件 - 移行対象データ - 引継ぎに関する事項 - 他の関係事業者への引継ぎに関する要件を記載する - 特に設計・開発事業者から運用事業者及び保守事業者への引継ぎ及び当年度の運用事業者から翌年度の運用事業者への引継ぎについて、あらかじめ想定した上で要件定義書に記載する - 教育に関する事項 - 情報システムの利用者に対する教育について、教育対象者の範囲、教育の方法等を記載する - 教育対象者の範囲、教育の方法 - 教育対象者の範囲 - 教育の内容 - 教育の実施時期 - 教育の方法 - 使用教材 - 教育対象者数 - 補足 - 教材の作成 - 例： -  利用者区分ごとに操作手順書の内容を分割するなど、利用しやすいよ - うに工夫すること -  個々の業務に沿った画面の流れを中心に作成すること -  管理者権限のみが操作可能な機能に特化したシステム管理用操作手順 - 書を作成すること - 運用に関する事項 - 運転管理・監視等に関する要件を記載する - 保守要件と明確に区別して記載する - 運転管理・監視等要件 - （代表的な作業項目の例） 運転管理・監視 ① -  死活監視 -  性能監視 -  稼働状況監視 第３編第５章－Ｐ87 -  セキュリティ監視（不正侵入・不正アクセス等の監視） -  障害の一次対応（障害検知又は受付、保守事業者への連絡等） -  バックアップ管理（バックアップの実施、及びバックアップデータからの復旧の実施等） -  情報システムの設定変更（ユーザの追加・削除、アカウントロック解除、パスワードの変更・初期化等） -  修正プログラム又はアップデートファイルの適用 - 運用サポート業務 - （代表的な作業項目の例） -  ヘルプデスク業務（情報システム利用者からの問合せに対し、解決策を講ずるために行う業務） -  コールセンタ業務（情報システム利用者からの問合せに対し、あらかじめ決められた事項を案内又は回答する業務であり、主に大量の問合せがある場合） -  操作研修（情報システムの利用に当たり、当該情報システム部門の担当者又は情報システムの利用者に対する操作研修等） - 業務運用支援 - （代表的な作業項目の例） -  データ作成（ホームページやｅラーニングのコンテンツ作成等） -  データ受付・登録 -  帳票印刷 - 運用実績の評価と改善 - （代表的な作業項目の例） -  運用実績（サービスレベルの達成状況、情報システムの構成と運転状況等）の値の取得、評価及び管理 -  運用実績が目標に満たない場合の要因分析、改善措置の検討 - 保守に関する事項 - アプリケーションプログラム、ハードウェア、ソフトウェア製品、データ等の保守要件を記載する - 情報システムの機能改修及び更改と明確に区別して記載する - アプリケーションプログラムの保守要件 - （保守要件として記載する事項の例） -  不具合の受付と修正サービスの提供期間 -  不具合の確認や修正プログラムの作成及びテストのための環境（委託者が用意するか、事業者が用意するか等） -  不具合修正に係る作業の実施期間 - ハードウェアの保守要件 - （保守要件として記載する事項の例） -  製品の保守継続可能期間 -  契約形態（故障発生時のみ対応、年間契約による対応） -  修理のための対応方法（障害機の送付・作業員のオンサイト作業） -  保守受付時間（平日のみ・休日込み、日中営業時間帯、24時間） -  保守対応時間（平日のみ・休日込み、日中営業時間帯、24時間） -  保守応動時間（オンサイト作業の場合、障害の連絡を受け付けてから機器設置場所までの応動時間） - ソフトウェア製品の保守要件 - （保守要件として記載する事項の例） -  不具合の受付とパッチ提供サービス等の提供期間 -  リビジョンアップやバージョンアップにおける使用権の提供有無 -  サポート対応 - データの保守要件 - （代表的な作業項目の例） -  設定データに異常が生じた場合の復旧作業 -  マスタデータに異常が生じた場合の復旧作業及びアップデート時の更新作業 - 保守実績の評価と改善 - （代表的な作業項目の例） -  保守実績（サービスレベルの達成状況等）の値の取得、評価及び管理 -  保守実績が目標に満たない場合の要因分析、改善措置の検討 ## 40.6 要件定義書の調整・作成 ### 40.6.1 関係機関との調整 ### 40.6.1.1 情報システム間の連携（外部インタフェース）の整合性確認、調整 -  データ連携を実施する情報システム間で、連携するデータの種類、内容、サイズ、件数、連携タイミング、連携頻度等について確認、調整を行う -  データ連携にエラーが発生した場合の処理方法について、再送タイミング、エラー通知先、運用方法等について確認、調整を行う ### 40.6.1.2 運用及び保守方法の整合性確認、調整 -  相互に関係する情報システム間で、運用時間（業務の開始/終了時間、夜間バッチやバックアップ等の処理開始/終了時間等）の確認、調整を行う -  相互に関係する情報システム間で、運転管理・監視内容（死活監視、リソース監視、プロセス監視、ログ監視等）、情報セキュリティ対策内容（パッチ適用、ウイルス対策等）等について確認し、責任分界も含めて調整を行う ### 40.6.1.3 指標の整合性確認、調整 -  相互に関係する情報システム間で、性能に関する指標（応答時間や稼働率等）及び目標値の確認、調整を行う。関係する情報システムの全てで目標値を一致させる必要はないが、それぞれの情報システムで設定した目標値が相互に矛盾しないよう留意する ### 40.6.1.4 情報システムの利用者等との調整 - 業務実施部門が利用者となる場合は、十分な調整による合意形成が必要である。また、広く国民に利用される情報システムの場合は、利用者の意見を取り入れるため、パブリックコメントや説明会等を実施することが考えられる。 ## 40.7 調達仕様書の記載事項 - 事業者が提案内容を検討するために不可欠な情報が網羅されるようにする - 契約書とその一部を構成する調達仕様書との整合性を確保するよう、会計担当部門と必要な調整を行う ### 40.7.0.1 調達案件の概要に関する事項 - 調達の背景 - 目的 - 期待する効果 - 業務・情報システムの概要 - 契約期間 ### 40.7.0.2 調達案件及び関連調達案件の調達単位、調達の方式等に関する事項 - 調達案件の調達単位 - 調達の方式 ### 40.7.0.3 作業の実施内容に関する事項 - 作業の内容 - 設計・開発に係る記載内容 - 設計・開発実施計画書等の作成 - 設計 - 開発・テスト - 受入テスト支援 - 情報システムの移行 - 引継ぎ - ＯＤＢ登録用シートの提出 - 運用に係る記載内容 - 中長期運用・保守作業計画の確定支援 - 運用計画及び運用実施要領の作成支援 - 定常時対応 - 障害発生時対応 - 情報システムの現況確認支援 - 運用作業の改善提案 - 引継ぎ - ＯＤＢ登録用シートの提出 - 保守に係る記載内容 - 中長期運用・保守作業計画の確定支援 - 保守作業計画及び保守実施要領の作成支援 - 定常時対応 - 障害発生時対応 - 情報システムの現況確認支援 - 保守作業の改善提案 - 引継ぎ - ＯＤＢ登録用シートの提出 - ＯＤＢ登録用シートの提出に係るその他の記載内容 - 成果物の範囲、納品期日等 - 成果物 - 成果物名 - 成果物名とその内容、納品数量、納品期日等 - （設計・開発に係る成果物） -  設計・開発実施計画書 - 設計・開発実施要領 -  設計・開発実施要領に基づく管理資料 -  標準コーディング規約 -  設計書（基本設計書、詳細設計書、実体関連図（ＥＲＤ）、データ定義表、情報システム関連図、ネットワーク構成図、ソフトウェア構成図、ハードウェア構成図、プログラム一覧等） -  ソースコード一式 -  実行プログラム一式 -  テスト計画書 -  単体テスト結果報告書 -  結合テスト結果報告書 -  総合テスト結果報告書 -  脆弱性検査結果報告書 第３編第６章－Ｐ36 -  テストデータ -  移行計画書 -  移行結果報告書 -  操作手順書（一般利用者向け及び情報システム管理者向け） -  研修用資料 -  中長期運用・保守作業計画（案） -  運用計画（案） -  保守作業計画（案） -  要件定義書の改定案 - （ソフトウェア製品の賃貸借又は買取りに係る成果物） -  納入ソフトウェア製品一式 -  ソフトウェア構成表 -  ライセンス関係資料（ライセンス証書、ライセンス種別、ライセンス数、ライセンス料等） -  導入計画書 -  導入作業手順書 -  設定作業報告書 - （ハードウェアの賃貸借又は買取りに係る成果物） -  納入機器一式 -  設置図面 -  導入設置計画書 -  導入作業手順書 -  設定作業報告書 -  保守計画書 - （運用に係る成果物） -  運用実施要領に基づく管理資料 -  運用作業報告書（月次、年次、スポット等） -  情報システムの現況確認結果報告書 -  運用作業の改善提案書 -  運用計画の改定案 - （保守に係る成果物） -  保守実施要領に基づく管理資料 -  保守作業報告書（月次、年次、スポット等） - 内容及び納品数量 - 納品期日 - 補足 - 法品方法 - 納品場所 ### 40.7.0.4 満たすべき要件に関する事項 - 「別紙Ｘ 要件定義書」の各要件を満たすこと。 ### 40.7.0.5 作業の実施体制・方法に関する事項 - 作業実施体制 - 作業要員に求める資格要件 - 実務手引書「第３編第６章別紙６－１ 調達する作業内容ごとの人材に関する要求要件（参考）」を参考に記載する。 - 作業場所 - 作業の管理に関する要領等 ### 40.7.0.6 作業の実施に当たっての遵守事項 - 機密保持、資料の取扱い - 遵守する法令 - 法令等の遵守 - その他文書、標準への準拠 - プロジェクト計画書 - プロジェクト管理要領 - プロジェクト標準 ### 40.7.0.7 成果物の取扱いに関する事項 - 知的財産権の帰属 - 瑕疵担保責任 - 検収 ### 40.7.0.8 入札参加資格に関する事項 - 入札参加要件 - 競争参加資格 - 公的な資格や認証等の取得 - 受注実績 - 複数事業者による共同提案 - 入札制限 - ![[Untitled 15 5.png|Untitled 15 5.png]] ### 40.7.0.9 再委託に関する事項 - 再委託の制限及び再委託を認める場合の条件 - 承認手続 - 再委託先の契約違反等 ### 40.7.0.10 その他特記事項 ### 40.7.0.11 附属文書 - 要件定義書 - 参考資料 - 事業者が閲覧できる資料一覧表 - 閲覧に供する資料の例を次に示す。 -  プロジェクト計画書、プロジェクト管理要領 -  プロジェクト標準（標準コーディング規約、セキュアコーディング規約等） -  遵守すべき各府省独自の規定類 -  政府共通プラットフォーム移行対象システム移行検討連絡票 第３編第６章－Ｐ62 -  現行の業務分析結果 -  既存の情報システムの情報システム設計書、操作マニュアル -  関連する他の情報システムの操作マニュアル、設計書、各種プロジェクト標 - 準 -  過去の受注事業者の検討資料、作業報告書等 - 閲覧要領 - 提案書等の審査要領 -  審査における基本方針及び前提条件 -  審査体制 -  審査方法・手順 -  審査項目 ### 40.7.0.12 その他事業者の提案に資する資料 ## 40.8 契約書の記載事項 ### 40.8.0.1 損害賠償 ### 40.8.0.2 契約変更手続 ### 40.8.0.3 契約解除 ## 40.9 提案依頼書の記載事項 ### 40.9.0.1 提案書の記載要領 - 言語、用紙サイズ、ページ数、表紙の記載事項、提出媒体及び部数等 ### 40.9.0.2 具体的な提案依頼の内容 - 評価基準注）の項目を章立てとして採用（又は評価基準と提案書の章立ての対応関係が明確となるよう定義） ### 40.9.0.3 その他提案時に提出すべき資料等 - ① 入札書（別記様式Ｘ号） - ② 委任状（別記様式Ｘ号） - ③ 適合証明書（別記様式Ｘ号） - ④ 誓約書（別記様式Ｘ号）