（別紙１－１）本調達にて求める作業内容と SLCP-JCF2013 のアクティビティとの関係
電力広域的運営推進機関
広域予備率のＷｅｂ公表に係る開発及び運用・保守の業務委託入札仕様書
電力広域的運営推進機関
目次
１．調達案件の概要に関する事項 6
（１）調達案件名 6
（２）調達の背景 6
（３）目的及び期待する効果 6
（４）業務・情報システムの概要 7
（５）契約期間 7
（６）設計開発作業スケジュール 8
（７）担当課室・連絡先 8
２．当該調達及び関連調達の調達単位、調達の方式等に関する事項 8
（１）調達案件及び関連する調達案件の調達単位、方式、実施時期 8
（２）調達案件間の入札制限 9
３．情報システムに求める要件に関する事項 9
４．作業の実施内容に関する事項 9
（１）作業の内容 9
ア 設計・開発に係る作業の内容 9
（ア）設計・開発実施計画書及び設計・開発実施要領の作成 10
（イ）設計 11
（ウ）開発・テスト 11
（エ）受入テスト 12
（オ）情報システムの移行(本番環境への入れ込み) 13
（カ）教育研修 13
（キ）引継ぎ(広域機関、運用保守事業者への引継ぎ) 14
イ 運用に係る作業の内容 14
（ア）運用計画書及び運用実施要領の作成 15
（イ）定常時対応 15
（ウ）障害・情報セキュリティインシデント及び大規模災害等の対応 16
（エ）情報システムの現況確認支援 16
（オ）運用作業の改善提案 17
（カ）引継ぎ 17
ウ 保守に係る作業の内容 17
（ア） 保守計画書及び保守実施要領の作成 18
（イ）定常時対応 18
（ウ）障害・情報セキュリティインシデント及び大規模災害等の対応 18
（エ）情報システムの現況確認支援 19
（オ）保守作業の改善提案 19
（カ）引継ぎ 19
エ 工程管理に係る作業の内容 19
（ア）プロジェクト計画書等の作成 19
（イ）コミュニケーション管理 19
（ウ）進捗管理 20
（エ）リスク管理 21
（オ）課題管理 21
（カ）変更管理 21
（キ）情報セキュリティインシデント対応 22
オ 最終報告書の作成 22
（２）成果物の範囲、納品期日等 22
ア 成果物 22
（ア）成果物の範囲 22
（イ）納品期日 23
イ 納品方法 23
ウ 納品場所 24
５．作業の実施体制・方法に関する事項 24
（１）作業実施体制 24
（２）管理体制 24
（３）作業要員に求める資格等の要件 25
（４）作業場所 26
（５）作業の管理に関する要領 26
６．作業の実施に当たっての遵守事項 27
（１）機密保持、資料の取扱い 27
（２）遵守する法令等 27
ア 法令等の遵守 27
イ その他文書、標準への準拠 27
（ア）プロジェクト計画書 27
（イ）プロジェクト管理要領 28
（ウ）プロジェクト標準 28
（３）情報セキュリティ管理 28
７．成果物の取扱いに関する事項 29
（１）知的財産権の帰属 29
（２）契約不適合責任（改正前の民法における瑕疵担保責任） 30
（３）検査 30
８．入札参加資格に関する事項 31
（１）入札参加要件 31
ア 公的な資格や認証等の取得 31
x 受注実績 31
ウ 複数事業者による共同提案 31
エ その他 31
（２）入札制限 32
９．再委託に関する事項 32
（１）再委託の制限及び再委託を認める場合の条件 32
（２）承認手続 32
１０．その他特記事項 33
（１） 前提条件及び制約条件 33
（２）環境への配慮 33
（３）その他 33
１１．附属文書 33
（１）要件定義書 33
（２）閲覧要領 33
（３）提案書等の審査要領 34
（４）契約締結後に開示する資料 34
（別紙１－１）本調達にて求める作業内容と SLCP-JCF2013 のアクティビティとの関係
（※1）...................................................................................................................................35
１．設計・開発に係わる成果物 35
２．ソフトウェア製品の賃貸借又は買取りに係る成果物 37
３．ハードウェアの賃貸借又は買取りに係る成果物 37
４．運用に係わる成果物 37
５．保守に係わる成果物 37
６．工程管理・支援に係わる成果物 38
（別紙１－２）検査等の際に確認するべき事項（チェックリスト） 39
＜参考文献等＞ 41
＜用語集＞ 43
１．調達案件の概要に関する事項
（１）調達案件名
広域予備率のＷｅｂ公表に係る開発及び運用・保守の業務委託
（２）調達の背景
・広域予備率公表業務では、新規に公表する広域予備率を小売電気事業者、発電事業者、一般需要家に公表するため、分かり易い情報提供のシステム構築が求められている。このため、情報セキュリティの徹底を図ったうえで安価なシステム構築と運用コストの低減を図ることが強く求められている。
・本案件は Web 閲覧が主な機能であり、季節や需給状況によって閲覧数が変動することから、スケーラビリティの自由度を確保し運用コストを低減するため、クラウドサービスを含め、クラウド技術の積極的な活用を図ることとする。本案件は、クラウドサービスの利用を前提とした構築・運用とすることで、クラウドサービスのメリットを最大限に享受できるシステム構築を求める。
・本案件は Web 閲覧が主な機能であり、本システムの設計・開発に関しては、設計・開発の段階でも可能な限り利用者のニーズを反映させていく必要がある。また、広域機関システムの改修期間（1 年程度）と比較し短期間となる、1 年未満での開発を考えている。このことから、設計・開発手法は従来のウォータフォールに限定せず、スパイラル／アジャイル等柔軟な対応を可能とする手法を積極的に採用する。
（３）目的及び期待する効果
・本システムの確実な稼働によって、広域予備率の分かり易い情報提供を実現し、一般需要者が電気の受給状況を意識することにより、小売電気事業者、発電事業者の電力供給コストを最適化することを目的とする。
・クラウドサービスを利用することにより情報セキュリティ水準の向上や運用・保守コストの削減等に資することを目的とする。
・最適な開発手法を採用することで、運用者ニーズの反映、短期間でシステム構築することを目的とする。
（４）業務・情報システムの概要
広域予備率 Web 公表業務及び広域機関システムの概要は次の図の通りである。
※運用事業者と開発事業者は同一を想定しているが、入札仕様書８．（１）ウに示す複数事業者による共同提案などにより異なる事業者となることも認める。
（５）契約期間
契約締結日(2021 年 8 月下旬頃)から 2027 年 3 月 31 日まで
上記のうち設計開発については、契約締結日(2021 年 8 月下旬頃)から 2022 年 3 月
31 日まで
運用・保守については、2022 年 4 月 1 日から 2027 年 3 月 31 日まで
ただし、運用・保守の契約は 1 年更新とする。
本システムでは、本調達における運用・保守期間終了後もクラウドサービスの契約期間終了前に契約の延長又は他のクラウドサービスブローカへの引継ぎ等を実施することにより、本システムの運用等を行うクラウドをそのまま継続利用可能とすることを想定している。但し、本システムの運用等に支障をきたさず、次期運用・保守事業者等の調達に支障をきたさないスケジュールで実施する限り、契約期間中、広域機関の承認を得て、クラウドサービスブローカの負担において他のクラウドサービスへ移行することは妨げない。
（６）設計開発作業スケジュール
設計開発に係る作業スケジュールは次の図の通りである。
2020年度
2021年度
広域予備率(2021年4月対応)
運用開始
対向試験開始
※オリンピックの影響で
12月からとなる可能性あり
広域予備率(2022年4月対応)
運用開始
詳細設計
製造～ＳI
2027年3月31日まで運用保守
※契約は1年更新
①【本委託】
広域予備率のＷｅｂ公表に係る開発及び運用・保守の業務委託
③【基本設計】
広域機関システム 広域予備率対応(2022年4月運開)におけるプロジェクト計画の更新及び基本設計に関する業務委託
⑤【中央算定システム連携セキュリティ装置の開発】
中央算定システム連携セキュリティ装置のシステム開発委託
②【要件定義】
広域機関システム 2021年度の広域予備率対応 （要件定義）に関する業務委託
➃【詳細設計～SI】
広域機関システム 広域予備率対応
(2022年4月運開)における詳細設計～SIに関する業務委託
⑥【中央算定システム連携セキュリティ装置の運用保守】中央算定システム連携装置の保守業務委託
関連調達案件
【本委託】
広域予備率Web公表に係る開発と運用・保守一式
広域予備率のWeb公表に係る開発および保守委託業務一式（本案件）
詳細設計
設計
定義
【開発工程２】
広域予備率・補正算定インデックス Web公表
対向試験
I
製造～Ｓ
基本
要件
【開発工程１】
補正料金算定インデックス中央算定連携
マイルストン
3月
2月
1月
12月
11月
10月
9月
8月
7月
6月
5月
4月
3月
2月
1月
12月
11月
10月
9月
・広域予備率の算定開始が、２０２２年４月１日からとなっていることに鑑み、２０
２２年３月中～下旬(24 日ごろを想定)までに新環境での本稼働を開始する。なお、当該本稼働前に性能評価用のテスト版・試用版等の形で事前リリース等を行うことは妨げない。
（７）担当課室・連絡x
x調達に関する問い合わせ先は以下の通り。電力広域的運営推進機関
x000-0000 xxxxxxxx 0-0-00
総務部経理グループ（契約担当）
２．当該調達及び関連調達の調達単位、調達の方式等に関する事項
（１）調達案件及び関連する調達案件の調達単位、方式、実施時期
本調達案件及び関連する調達案件の調達単位、調達の方式、実施時期は次表の通りである。
No. | 調達案件名 | 委託機関 | 補足 |
1 | 広域予備率のＷｅｂ公表に係る開発及び運用・保守の業務委託 （本調達） | 契約締結日(2021 年 8 月下旬頃)～2022 年 3 月(開発) | 運用・保 守は一年更新 |
2022 年 4 月 ～ 2027 年 3 月(運用・保守) | |||
2 | 広域機関システム 2021 年度の広域予備率対応（要件定義）に関する業務委 託 | 2020 年 9 月 ～2020 年 11 月 | 発注済 |
3 | 広域機関システム 広域予備率対応 (2022 年 4 月運開)におけるプロジェクト計画の更新及び基本設計に関する業 務委託 | 2020 年 12 月 ～2021 年 2 月 | 発注済 |
4 | 広域機関システム 広域予備率対応 (2022 年 4 月運開)における詳細設計～ SI に関する業務委託 | 2021 年 3 月 ～2022 年 3 月 | 発注済 |
5 | 中央算定システム連携セキュリティ装 置の開発委託 | 2021 年 1 月 ～2022 年 3 月 | 発注済 |
6 | 中央算定システム連携セキュリティ装 置の運用保守委託 | 2022 年 4 月 ～2027 年 3 月 | 発注未 |
（２）調達案件間の入札制限
・当該調達案件における詳細な入札制限は、「８．入札参加資格に関する事項
（２）入札制限」に記載する。
３．情報システムに求める要件に関する事項
・本調達の実施に当たっては、「別紙 要件定義書」の各要件を満たす。
キックオフ後に要件定義の確認、確定を行う際など、設計の中で変更が生じた場合や改定案がある場合は要件定義書改定案を提出すること。
４．作業の実施内容に関する事項
（１）作業の内容
ア 設計・開発に係る作業の内容
設計・開発に係る作業の実施内容は以下を想定している。
必要となる費用（人件費、機器資材費等）は漏れなく見積もり、各項目について可能な限り詳細に表記すること。
また、その他必要な費用がある場合は示すこと。
項番 | 作業の内容 | 概要 |
1 | プロジェクト管理 | · 開発の設計／開発・テスト／受入テスト／移行(システムの入れ込み)／引継ぎ(広域機関、運用保守事業者への引継ぎ)の各フェーズの工程を本機関と調整、管理すること。 · 入札仕様書 4.(1)エ、オも実施すること。 |
2 | 設計・開発・試験・移行 | · 基本設計／詳細設計／製造／テスト/移行(システムの入れ込み)を実施すること。 · 入札仕様書 4.(1)ア(ア)、(イ)、(ウ)、(エ)、(オ)、(カ)、(キ) に該当。 |
3 | 機器／ソフトウェア調達 | · 設計に従い必要となる計算機やネットワーク機器、必要に応じて使用するソフトウェアを調達すること。本調達では クラウドの調達を本項目に含む。 |
4 | その他費用 | · 1～3 以外に必要となるものがあれば記載すること。 |
（ア）設計・開発実施計画書及び設計・開発実施要領の作成
設計・開発時の実施方針、開発手順、開発フロー、補足すべき KPI とその把握手法を策定した設計・開発実施計画書を作成する。また、設計・開発業務に係るコミュニケーション管理、体制管理、工程管理、品質管理、リスク管理、課題管理、システム構成管理、変更管理、情報セキュリティ対策を規定した設計・開発実施要領を作成する。これらの文章は広域機関と協議のうえ作成し、広域機関の承認を受ける。設計・開発実施計画書及び設計・開発実施要領には以下を考慮して記載すること。
・ウォータフォール、スパイラル／アジャイル等開発手法によって、成果物が異なるため、広域機関の承認をうけ追加または削除する。
・画面のイメージや操作感等について本稼働前に利用者向けに周知を行い、必要に応じて性能評価用のテスト版・試用版等の形で事前リリースを行う等により、利用者の要望を取込むことに配慮した手法を採用する。
・利用者の使用性の確保を重視する観点から、プロトタイピングの採用を視野に入れ、利用者のレビューを得ながら設計・開発を進める。その際、ノンプログラミングによる画面生成、データ流通等のツール等（以下同様）を採用する場合は、当該ツールは中立性の観点を考慮し選定する。
・受注者は開発に当たり、プログラムの開発又は保守を効率的に実施するため、
「標準コーディング／名称付与等各種規約 策定指針」を策定し、それに即してプログラミング等のルール（標準コーディング／名称付与等各種規約、データ／データベース設計規約、セキュアコーディング／名称付与等各種規約 等）を定め、広域機関の確認を受ける。但し、ノンプログラミングツール等を採用する場
合、プログラミング等のルールを定めた標準が当該ツール等に依存するときは、その旨をあらかじめ広域機関に報告し、承認を得ることでプログラミング等のルールを定めた標準について省略することができる。
・受注者は開発に当たり、情報セキュリティ確保のためのルール遵守や成果物の確認方法（例えば、標準コーディング／名称付与等各種規約、データ／データベース設計規約遵守等の確認、ソースコードの検査、現場での抜き打ち調査等についての実施主体、手順、方法等）を定め、広域機関の確認を受ける。但し、ノンプログラミングツール等を採用する場合、情報セキュリティ確保のためのルール遵守や成果物の確認方法が当該ツール等に依存するときは、その旨をあらかじめあらかじめ広域機関に報告し、承認を得ることで情報セキュリティ確保のためのルール遵守や成果物の確認方法を定めることを省略できる。
（イ）設計
・受注者は、「別紙 要件定義書」の機能要件及び非機能要件を満たすための基本設計及び詳細設計を行い、成果物について広域機関の承認を受ける。成果物については(別紙１－１)を参照のこと。
・後述する運用計画書、保守計画書を作成し、広域機関の承認を受ける。
・受注者は、本システムでクラウドサービスを利用するうえで、リソースの使用状況に応じてサーバのスペック等を調整し、リソースの効率的な使用を通じてコスト削減を継続的に図っていく取組（オートスケールを利用する場合の変更条件・上下限値等を含む。）を運用設計及び保守設計の中に含めて設計する。
・公開される Web サイト等のドメインについては、利用者にわかりやすいサイトとし、フィッシング等のセキュリティ事故が起こりにくい環境の実現のため、「ドメイン運用管理手順書」を作成する。
（ウ）開発・テスト
・受注者は、設計工程の成果物及び設計・開発実施計画書に基づき発を行う。
・受注者はテスト計画書を作成する。テスト計画書には、単体、結合及び総合テストについて、テスト方針、テスト体制、テスト環境、作業内容、作業スケジュール、テストシナリオ作成基準、合否判定基準を記載し、各テスト実施前に広域機関の承認を受ける。なお、これらテストにおいて、静的/動的コード解析ツール等を使用することにより合理的に品質の向上を図ることができる場合には、積極的にこれらツールを活用することが望ましい（但し、対象言語に係る解析の品質が一般に認められているもので、且つ原則として中立性が担保される OSS（Open Source Software）であることを前提とする）。この場合、人的レビューと重複する部分に
ついては、原則として省略してもよい。テスト計画書は当該テスト実施前に広域機関から承認を得る。
・受注者はテスト計画書に基づくテストの実施に当たって、具体的なテスト内容（テスト項目・使用するデータ等を含む。）について規定した「テスト仕様書」を作成し、テストを実施する。その際、総合テスト及び必要に応じて結合テストに関しては、テスト実施前に「テスト仕様書」について広域機関の確認を受ける。
・各テストの実施状況及び結果については、随時広域機関に報告を行い、単体テスト結果報告書、結合テスト結果報告書、総合テスト結果報告書を納入する。
・受注者は、開発・テストの際に、本システムの稼働時に必要なソフトウェア等がある場合は必要に応じて購入し、作業実施後に広域機関に納入する。その際、受注者は、納入ソフトウェア製品一式、ソフトウェア構成表、ライセンス関係資料（ライセンス証書、ライセンス種別、ライセンス数、ライセンス料等）、導入計画書、導入作業手順書、設定作業報告書を広域機関に提出する。クラウドサービスに関する設計やパラメータ設定も提出書類に記載のこと。
・受注者は、環境の設定を行う場合、非機能の設計に応じた内容で、各種環境の構成やパラメータ等の設定の報告を行う。
・受注者は、運用を補助するためのツールが必要となる場合、当該ツールの実装及び単体テストの実施状況の報告、運用ツールの操作方法等に関する手順書の作成を行い、広域機関の承認を受ける。
・受注者は、情報システムの操作方法を示した運用操作マニュアルを作成し、広域機関の承認を受ける。
・受注者は、試験開始前までに試験結果の評価に関する品質管理計画書を作成する。受注差は作成した品質管理計画書に基づき、品質管理が実施されているかどうか監査を行い、品質確認報告書を作成し、広域機関に報告する。
（エ）受入テスト
・受注者は、広域機関と合同で実施する受入テストのテスト計画書を作成し、広域機関の承認を受ける。
・受注者は、広域機関と合同で受入テストを実施するに当たり、環境整備、運用等を行う。
・受注者は、広域機関の指示に基づき、広域機関システム担当者以外のシステム利用者のテスト実施も含めて、テスト計画書作成を行う。
・受注者は具体的なテスト内容（テスト項目・使用するデータ等を含む。）について規定した「テスト仕様書」を作成し、テストを実施する。
・受入テストは、利用者の視点や意見が重要であることから、実際の利用を想定した広域機関システム担当者以外の広域機関のシステム利用者がテストに参加することを想定すること。
・受入テスト完了後、最終ソースコード一式、実行プログラム一式について、静的/動的コード解析ツールによる分析評価リストを含めた受入テスト結果報告書を成果物として出力し納入すること。
・最終ソースコード、実行プログラムは納品対象とする。
・テストデータは受注者、広域機関が想定したシナリオに沿って受注者が作成し、成果物とする。
（オ）情報システムの移行(本番環境への入れ込み)
・受注者は、本番環境の運用開始までの移行手順についてリハーサルを実施し、運用開始までの移行シナリオ、運用開始までの移行スケジュールの適切性等を確認する。
・受注者は、情報システムの移行の方法、環境、ツール、段取り等を記載した移行計画書を作成し、広域機関の承認を受ける。
・受注者は、広域機関の移行判定を受け、移行計画書に基づき、具体的な移行手順を記載した移行手順書を作成する。
・受注者は、移行計画書、移行手順書にデータ移行に当たり、新規情報システムのデータ構造を明示し、保有・管理するデータの変換、移行要領の策定、例外データ等の処理方法等に関し記載し、機関の承認を受ける。ただし、本案件は新規運用開始であるため、現状、移行するデータは発生しない見込みである。
・受注者は、移行実施計画及び移行手順書に基づき、本番環境への移行を行う。
・受注者は、移行実施以降、移行結果報告書を作成し、広域機関に提出する。
（カ）教育研修
・受注者は広域機関職員向け教育研修を必要に応じて行う。また、広域機関職員に異動があった場合も必要に応じて教育研修を行う。なお、新たな資料が必要となる場合には広域機関に報告の上、作成する。
・研修内容の伝達がより効果的になるよう操作手順書、教育訓練教材の作成及び教育研修作業を実施する。作業の上で、問題が発生した場合は広域機関と調整し改善をはかる。
・受注者は、教育研修時及びその他システムに関してシステム利用者から質問があった事項のFAQ を作成する。
（キ）引継ぎ(広域機関、運用保守事業者への引継ぎ)
・受注者は、設計・開発の設計書、作業経緯、及び広域機関の承認のもと本システムの運用・保守業務として解決すべきとした残存課題等を文書化し、運用・保守開始前に広域機関とともに受注者の運用・保守管理部門に対して確実な引継ぎを行う。
イ 運用に係る作業の内容
今回の調達では運用に関わる事項と、保守に関わる事項を分けて記載している。
・運用に関わる事項
システム操作、運転管理・監視、稼働状況監視、サービスデスク提供等の役務提供に関する内容を規定する。
・保守に関わる事項
定期点検、不具合受付等の役務提供に関する内容を規定する。
本件はクラウドサービスの利用を前提としていることから、運用と保守を一体として、以降に記載する運用計画書及び運用実施要領は、広域機関の承認のもと運用保守計画書及び運用保守実施要領とし、文書内で運用、保守の実施を明確にしたうえで統合してもよい。
運用・保守作業の実施内容は以下を想定している。
必要となる費用（人件費、機器資材費等）は漏れなく見積もり、各項目について可能な限り詳細に表記すること。また、その他必要な費用がある場合は示すこと。
項番 | 作業の内容 | 概要 |
1 | プロジェクト管理業 務 | · 運用保守の作業全体を本機関と調整、管理すること。 入札仕様書 4.(1)エも実施すること。 |
2 | 運用・保守 | ・インシデント問合せ、定期点検、システム操作、運転管理・監視、稼働状況監視を実施する。 ・入札仕様書 4.(1)イ(ア) (イ) (ウ) (エ) (オ) (カ)に該当。 ・入札仕様書 4.(1)ウ(ア) (イ) (ウ) (エ) (オ) (カ)に該当。 |
3 | ハードウェア費用 | · 装置を使用するに当たり、毎年ハードウェアライセンス費用等が必要なとなる場合は計上すること。クラウドサービスのハードウェア費 用を含む。 |
4 | ソフトウェア費用 | · 装置を使用するに当たり、毎年ソフトウェアライセンス費用等が必要 となる場合は計上すること。クラウドサービスのソフトウェア費用を含む。 |
項番 | 作業の内容 | 概要 |
5 | その他費用 | · 1～4 以外に必要となるものがあれば記載すること。 |
（ア）運用計画書及び運用実施要領の作成
・受注者は、入札仕様書 4.(1).ア(イ)で作成した運用計画書に更新があった場合、更新を行う。なお、運用計画書には定常時における月次の作業内容、その想定スケジュール、障害発生時における作業内容、運用体制、実施手順、業務フロー、補足すべき KPI とその把握手法等を取りまとめる。また、運用実施要領を作成し、運用業務に係るコミュニケーション管理、体制管理、作業管理、リスク管理、課題管理、システム構成管理、変更管理、情報セキュリティ対策を記載する。
作成に当たっては、具体的な作業内容や実施時間、実施サイクル等に関する資 料、大規模災害等の発災時の情報システム運用継続計画等を別紙として作成し、広域機関の承認を受ける。
（イ）定常時対応
・受注者は、「別紙 要件定義書」の運用要件に示す定常時運用業務（システム操作、運転管理・監視、稼働状況監視、サービスデスク提供等）を行う。
・受注者は、運用計画書及び運用実施要領に基づき、以下の内容について月次で運用作業報告書を取りまとめ評価する
（１）運用業務の内容や工数、作業時間等の作業実績状況
（２）サービスレベルの達成状況
（３）情報システムの構成と運転状況（情報セキュリティ監視状況を含む）
（４）情報システムの利用者サポート、必要に応じて実施する教育・訓練の実施状況
（５）リスク・課題の把握・対応状況
（６）クラウドサービスの利用状況（リソース使用量の変動、構成変更の実施状況等を含む。なお、クラウドサービスプロバイダから提供される管理ツール等により出力可能な情報があれば、当該情報を管理ツール等から出力したそのままの形で添付することとしても差し支えないが、グラフ化等、参照性の担保には配慮する。）
・受注者は、月間の運用実績を評価し、達成状況が目標に満たない場合はその要因の分析を行うとともに、達成状況の改善に向けた対応策を提案する。また、クラウドサービスのリソース使用量の変動等を踏まえ、リソース最適化の観点からクラウドの運用に係る方針（オートスケールを利用する場合の変更条件・上下限値等を含む。）を変更すべきと考えられる場合には、見直しのための対応策を提案する。
受注者は、運用作業報告書の内容について、月例の定期運用保守会議に出席し、その内容を報告する。広域機関は、必要に応じて、詳細内容を求めることがあ る。
（ウ）障害・情報セキュリティインシデント及び大規模災害等の対応
・受注者は、システムの障害発生時（又は発生が見込まれる時）には、運用計画書及び運用実施要領に基づいて対応を行う。速やかに広域機関に報告するととも に、その緊急度及び影響度を判断の上、「別紙 要件定義書」の運用要件に示す障害発生時運用業務（障害検知、障害発生箇所の切分け、保守事業者への連絡、復旧確認、報告等）を行う。なお、障害には、情報セキュリティインシデントを含めるものとする。
・受注者は、情報システムの障害に関して事象の分析（発生原因、影響度、過去の発生実績、再発可能性等）を行い、同様の事象が将来にわたって発生する可能性がある場合には、xx的な対応策を提案する。
・受注者は、大規模災害等の発災時には、広域機関の指示を受けて、運用計画書の別紙として作成した情報システム運用継続計画に基づく運用業務を実施する。この対応には、アクセス集中に伴う緊急対応（リソース追加など）も含め、予め定めておくこととする。
（エ）情報システムの現況確認支援
・受注者は、業務開始時及び完了時、広域機関の実施する現況確認を広域機関の指示に基づき、情報システムの現況の確認（以下、「現況確認」という。）を支援する。また、受注者は、現況確認支援の実施実績を証跡として作成し、現況確認結果報告書を提出する。
・受注者は、現況確認の結果、管理簿等と情報システムの現況との間の差異がみられる場合は、運用実施要領に定める変更管理方法に従い、差異を解消する。
・受注者は、現況確認の結果、ライセンス許諾条件に合致しない状況が認められる場合は、当該条件への適合可否、条件等を調査の上、広域機関に報告する。
・受注者は、現況確認において、IPA の MyJV バージョンチェッカを用いる等により、ソフトウェア製品のバージョンを確認し、その結果、サポート切れのソフトウェア製品の使用が明らかとなった場合は、当該製品の更新の可否、更新した場合の影響の有無等を調査の上、広域機関に報告する。なお、サポート切れのソフトウェア製品にならないよう、常時製品状況をモニタし、発見した場合は、製品事業者から詳細を聴取し、対処方法を含め早い段階で整理し、合わせて報告す
る。
・受注者は、広域機関了解のもとサポート切れのソフトウェア製品を更新した場合は、改めて広域機関に報告する。
（オ）運用作業の改善提案
・受注者は、次年度の運用に必要となる情報として、年度末もしくは 1 月末までに年間の運用実績を取りまとめ評価するとともに、運用計画書、運用実施要領に対する改善提案を行う。
・受注者は、広域機関に取りまとめた運用実績の評価及び運用計画書、運用実施要領の改善提案をもとに改訂案を作成し、広域機関の承認を受ける。
（カ）引継ぎ
・受注者は、広域機関が本システムの更改を行う際には、次期の情報システムにおける要件定義支援事業者及び設計・開発事業者等に対し、作業経緯、残存課題等に関する情報やデータの提供及び質疑応答等の協力を行う。
・受注者は、本契約の終了後に他の運用事業者が本情報システムの運用を受注した場合には、次期運用事業者に対し、作業経緯及び広域機関の承認のもと本システムの運用・保守業務として解決すべきとした残存課題等についての引継ぎを行 う。
・本システムで利用するクラウドサービスを運用保守契約終了時に、他の運用・保守事業者に対し、本システムの運用等を行うクラウドを原則としてそのまま引継ぐ。他の運用・保守事業者及びクラウドサービスプロバイダとの間で書面による契約等を行い、しかるべく管理者権限の引き渡し等クラウドの引継ぎを可能とする。クラウドサービスプロバイダとの契約内容や引継ぎ手順等を整備、広域機関に説明を実施すること。
ウ 保守に係る作業の内容
運用作業要件と同様に、今回の調達では運用に関わる事項と、保守に関わる事項を分けて記載している。
本件はクラウドサービスの利用を前提としていることから、運用と保守を一体として、以降に記載する保守計画書及び保守実施要領は、広域機関の承認のもと運用保守計画書及び運用保守実施要領とし、文書内で運用、保守の実施を明確にしたうえで運用計画書及び運用実施要領と統合してもよい。
運用・保守作業の実施内容は 4.(1) イに示した表を想定している。
必要となる費用（人件費、機器資材費等）は漏れなく見積もり、各項目について可能な限り詳細に表記すること。また、その他必要な費用がある場合は示すこと。
（ア） 保守計画書及び保守実施要領の作成
・受注者は、入札仕様書 4.(1).ア(イ)で作成した保守計画書に更新があった場合、更新を行う。なお、運用計画書には定常時における定期点検、不具合受付等の実施手順や業務フロー、補足すべきKPI とその把握手法等を取りまとめる。また、保守実施要領を作成し、保守業務に係るコミュニケーション管理、体制管理、作業管理、リスク管理、課題管理、システム構成管理、変更管理、情報セキュリティ対策を記載する。
作成に当たっては、具体的な作業内容や実施時間、実施サイクル等に関する資 料、大規模災害等の発災時の情報システム運用継続計画等を別紙として作成し、広域機関の承認を受ける。
（イ）定常時対応
・受注者は、「別紙 要件定義書」の保守要件に示す定期点検、不具合受付などの定常時保守作業を行う。具体的な実施内容・手順は保守計画書に基づいて行う。
・受注者は、保守計画書及び保守実施要領に基づき、以下の内容について月次で保守作業報告書を取りまとめ評価する。
（１）保守作業の内容や工数等の作業実績状況（脆弱性への対応状況を含む）
（２）サービスレベルの達成状況
（３）情報システムの定期点検状況
（４）リスク・課題の把握・対応状況
・受注者は、月間の保守実績を運用実績と同様評価する。
・受注者は、保守作業報告書の内容について、運用作業方向書と同様報告を行う。
（ウ）障害・情報セキュリティインシデント及び大規模災害等の対応
・受注者は、情報システムの障害発生時（又は発生が見込まれる時）には、広域機関又は運用主体箇所からの連絡を受け、保守計画書及び保守実施要領に基づいて対応を行う。「別紙 要件定義書」の保守要件に示す障害発生時保守作業（原因調査、応急措置、報告等）を行う。なお、障害には、情報セキュリティインシデントを含めるものとする。
・受注者は、大規模災害等の発災時には、広域機関の指示を受けて、保守計画書の別紙である情報システム運用継続計画に基づく保守作業を実施する。この対応には、アクセス集中に伴う緊急対応（リソース追加など）も含め、予め定めておくこととする。
（エ）情報システムの現況確認支援
・運用作業要件と同様。
（オ）保守作業の改善提案
・受注者は、次年度の保守に必要となる情報として、年度末もしくは 1 月末までに年間の保守実績を取りまとめ評価するとともに、保守計画書、保守実施要領に対する改善提案を行う。
・受注者は、広域機関に取りまとめた運用実績の評価及び保守計画書、保守実施要領の改善提案をもとに改訂案を作成し、広域機関の承認を受ける。
・要件定義書、設計書の改定が発生する場合は改定案を提出する。
（カ）引継ぎ
・運用作業要件と同様
エ 工程管理に係る作業の内容
（ア）プロジェクト計画書等の作成
・受注者は、プロジェクト開始時にプロジェクト計画書（参考）と整合をとりつ つ、プロジェクト計画書及びプロジェクト管理要領を広域機関と協議のうえ作成する。プロジェクト計画書、プロジェクト管理要領は、プロジェクトを進めて行く上で必要に応じて広域機関と協議の上、その策定又は改定可否について検討し改定を行う。
（イ）コミュニケーション管理
■会議体について
打ち合わせ資料は原則として会議前日までに電子ファイルにて共有するものとする。
●全体会議等の企画等
・プロジェクト全体会議等の企画、開催、運営、調整を行うとともに、本システムに係る開発及び運用状況等を広域機関に報告する全体会議を開催する。
・会議内容を踏まえ、専門的・技術的観点から、積極的な提案・助言を行う。
・議事進行の実施、議事録案等を作成し、営業日３日以内に提出する。
●定例会の実施（毎週：1～２時間程度）
・定例会を実施し、広域機関に進捗を報告するとともに、専門的・技術的な観点から、問題解決のための積極的な提案・助言をする。
・議事進行の実施、議事録案等を作成し、営業日３日以内に提出する。
●各種会議への参加
・広域機関の要請に基づき、各種会議、関係省庁、企業との連絡調整並びに広域機関内打ち合わせ等に同席し、積極的な提案・助言をする。
・会議内容を踏まえ、広域機関に専門的・技術的観点から適切な回答及び助言を行う。
・議事録案等を作成し、営業日３日以内に提出する。
●各個別報告会の開催
・受注者の作業予定及び実績について、毎月１回作業報告書を広域機関に提出する。その他必要に応じて、個別報告会等において広域機関に報告する。定例会の中で実施することを認める。
・議事進行の実施、議事録案等を作成し、営業日３日以内に提出する。
●議事録案等の作成
・受注者は、上記の議事録案等を作成し終えたら、広域機関の承認を得る。
●会議資料の作成
・広域機関と協議の上、会議資料を作成し、事前、場合によっては事後に広域機関の了承を得る。
■関連事業者間調整等
・広域機関が関連事業者間の調整を行う際に、プロジェクトマネジメントの観点からの助言を行う。
・関連事業者間に生じる課題、引継事項の調整は、広域機関と協議の上、実施する。
・本システムと他システムとの連携等の仕様やテストに係る調整を支援する。
・個別プロジェクトにおいて作成された設計・開発実施計画書等に基づいて、個別プロジェクトの進捗管理、課題管理等を行い、管理手法が適切であり且つ問題がないことを広域機関の指示にもとづき、ヒアリング等により事業者に確認し、広域機関に報告する。
（ウ）進捗管理
・受注者は必要な作業を全て盛込んでスケジュールを策定すること。
・受注者は策定したスケジュールに対して、作業内容の妥当性及び実現性を広域機関に報告する。また、妥当性及び実現性に関して広域機関より疑義等が発生した場合は、協議のうえ策定スケジュールの是正を行う。
・受注者は、データ連携など関連事業者に係る全てのスケジュールを管理するマスタスケジュールを作成し、広域機関に報告する。
・受注者は、マスタスケジュールにおける各作業の進捗状況をモニタリングする。
・受注者は、広域機関とともに関連事業者の業務進捗状況を把握し、遅延が生じた場合、本システムに係る関連事業者と原因究明を行い、広域機関とともに関連事業者と協議の上、対応策等を決定する。
・受注者は、広域機関の求めにより、関連事業者が作成する各種進捗報告を定量 的・定性的な側面から分析し、見解を進捗報告書として取りまとめ、広域機関と関連事業者が主催する定例会等にて助言を行う。
（エ）リスク管理
・プロジェクト全体に対するリスクを監視し、顕在化したリスクの対応責任者及び対応期限等を明確にするとともに、リスク発生率及び影響度から、その対応策の要否を決定するために、専門的・技術的な観点から、提案・助言を行う。
・受注者において、リスク管理表を作成して対応状況を管理し、定例会議等で説明する等により関係者間において情報共有がなされるよう配慮する。
・リスク対応については、リスクが顕在化し、課題としてエスカレーションされない限り、関連事業者に対しては指示が通りにくいことがあるため、受注者側から関連事業者へ対応を促すよう広域機関に対して、助言を行う。
（オ）課題管理
・プロジェクト全体の課題を抽出し、明確に管理し、抽出した課題の解決策の検討を行い、解決策について広域機関に対し、専門的・技術的な観点から、提案と助言を行う。広域機関と合意できた内容は対応を実施する。
・課題解決状況を、課題管理表を作成、管理し、定例会で説明する等により、課題の状況を定期的に報告し、関係者間で情報共有がなされるよう配慮する。
（カ）変更管理
仕様変更が発生した場合の作業を実施する。
・変更に関する詳細な管理手順・ルールを各計画書、実施要領などにてあらかじめ確立する。
・「変更更管理表」を作成し、仕様変更項目を管理する。また、仕様変更による業務・システム面での影響の分析結果を評価する。また、仕様変更の要否について、広域機関と協議する。
・仕様変更項目に関して、本システムに係る工数見積と内容を提示し、仕様変更に係る「見積評価書」を作成し報告する。
・仕様変更の実施については、広域機関と協議のうえ決定する。
（キ）情報セキュリティインシデント対応
・本システムに関するインシデントの対応は、受注者を運用管理者として実施す る。受注者は、本システムに関して発生した情報セキュリティインシデントについて、会議が開催される場合には、これに参加するとともに、情報セキュリティインシデントの早期解決の対応策等について広域機関に対し提案を行う。
・本システムについて第三者による脆弱性を検査し、把握した脆弱性情報につい て、対処の要否、可否を判断すること。対処したものに関して対処方法、対処しなかったものに関してその理由、代替措置及び影響を「脆弱性検査結果報告書」として提出すること。
オ 最終報告書の作成
・受注者は本調達案件が終了と判断したら、以下の内容を含む最終報告書を作成し、広域機関の承認を得ることとする。
・本調達または工程の概要レベルの説明
・スコープ目標、スコープの評価に使用される基準、完了基準が満たされていることの証拠
・品質目標、本調達や成果物の品質評価に使用される基準、成果物の品質、検証と実際のマイルストーンの創出日、差異の理由
・最終のサービス、成果物（記述内容含む）の検証概要
・広域機関は、最終報告書の内容が最低でも以上の内容を満たしていることを確認する。
（２）成果物の範囲、納品期日等ア 成果物
開発にスパイラル／アジャイル手法の採用を視野に入れているため、本業務の成果物は、広域機関と協議しプロジェクト計画書で規定する。
（ア）成果物の範囲
「（別紙１－１）本調達にて求める作業内容と SLCP-JCF2013 のアクティビティとの関係表」は、各工程での代表的な成果物例としての内容を示す。成果物は本委託で必要となる調達内容や開発方式等によって大きく異なるため、「必要」な成果物は、広域機関と協議のうえ決定する。成果物の主な構成は以下のとおり、
・設計・開発に係る成果物
・ソフトウェア製品の賃貸借又は買取りに係る成果物
(本調達ではソフトウェア製品にクラウドサービスを含む)
・ハードウェアの賃貸借又は買取りに係る成果物
(本調達ではハードウェアにクラウドサービスを含む果物)
・運用に係る成果物
・保守に係る成果物
・工程管理・支援に係る成果物
なお、成果物は、SLCP-JCF2013 を参考に意味ある成果物に対し、漏れの無いよう留意する。
（イ）納品期日
最終的な成果物としての納品は、2022 年 3 月下旬頃とする。
「（別紙１－１）本調達にて求める作業内容と SLCP-JCF2013 のアクティビティとの関係表」に示す納入期日は、工程上の中間報告の目安である。広域機関と協議しプロジェクト計画書で中間報告の納入期日は改めて規定するものとす る。
イ 納品方法
・成果物は、全て日本語で作成する。但し、日本国においても、英字で表記されることが一般的な文言については、そのまま記載しても構わないものとする。
・用字・用語・記述符号の表記については、「公用文作成の要領（昭和 27 年４月４
日内閣閣甲第 16 号内閣官房長官依命通知）」に準拠する。
・情報処理に関する用語の表記は、原則、日本工業規格（JIS）の規定に準拠する。
・成果物は紙媒体及び電磁的記録媒体（CD-R 等）により作成、広域機関から特別に示す場合を除き、原則紙媒体は正１部・副１部、電磁的記録媒体は２部を納品す る。
・紙媒体による納品について、用紙のサイズは、原則として日本工業規格Ａ列４番とするが、必要に応じて日本工業規格Ａ列３番を使用する。また、バージョンアップ時等に差し替えが可能なようにバインダ方式とする。
・電磁的記録媒体による納品について、MSOffice で読み込み可能な形式、又はPDF形式で作成し、納品する。但し、広域機関が他の形式による提出を求める場合は、協議の上、これに応じる。なお、受注者側で他の形式を用いて提出したいファイルがある場合は、協議に応じるものとする。
・納品後、広域機関で改変できるよう、図表等の元データも併せて納品する。
・成果物作成時、特別なツールを使用する場合、広域機関の承認を得る。
・成果物が外部に不正に使用されたり納品過程において改ざんされたりすることのないよう、安全な納品方法を提案し、成果物の情報セキュリティの確保に留意する。
・電磁的記録媒体により納品する場合は、不正プログラム対策ソフトウェアによる確認を行う等して、成果物に不正プログラムが混入することのないよう、適切に対処する。
・プログラムの納品は、実機に導入したプログラムのソースを収めた電子媒体を別途で納入する。
ウ 納品場所
原則として、成果物は次の場所において引渡しを行う。但し、広域機関が納品場所を別途指示する場合はこの限りではない。
〒135－0061
xxxxx区豊洲 6-2-15
電力広域的運営推進機関
運用部 広域システムT（00-0000-0000）
５．作業の実施体制・方法に関する事項
（１）作業実施体制
プロジェクト計画書（参考）で定義した発注者側の体制と受注者側が整備すべき体制を考慮し、作業実施体制を提案する。提案にあたっては以下を考慮する。
・作業実施に当たり、最低限必要な規模の体制を示すよう留意する。
・適切な体制が採られるかを判断するために、具体的に作業員に求める資格等の要件にあたるメンバを記載する。
・作業体制の品質確保のため、受注者側の遂行責任者が業務終了まで継続して遂行すること、万一交代する場合は同等以上の資格及び経験等を有する人物が担当するものとして、広域機関に事前に承認を得ること。
・受注者の工程管理者と設計・開発部門、運用部門、保守部門との間の業務の責任分界を、プロジェクト計画書などの書類に役割分担表としてまとめる等して明確化する。
（２）管理体制
・委託業務の実施に当たり、広域機関の意図しない変更が行われないことを保証する管理が、一貫した品質保証体制の下でなされている。また、当該品質保証体制が書類等で確認できる。
・本システムに広域機関の意図しない変更が行われる等の不正が見つかった時（不正が行われていると疑わしい時も含む）に、追跡調査や立入検査等、広域機関と受注者が連携して原因を調査・排除できる体制を整備している。また、当該体制が書類等で確認できる。
・当該管理体制を確認する際の参照情報として、資本関係・役員等の情報、委託事業の実施場所、委託事業従事者の所属・専門性（情報セキュリティに係る資格・研修実績等）
・実績及び国籍に関する情報提供を行う。
・再委託先に求める要件については、「９．再委託に関する事項」に記載する。
（３）作業要員に求める資格等の要件
・受注者における遂行責任者は、システム（構築工数 100 人月以上且つ構築期間 10
ヶ月以上）の設計・開発の遂行責任者としての経験を 5 件以上有する。また、EVMによる進捗管理に精通し、経験を有する。
・受注者における遂行責任者は、情報処理の促進に関する法律（昭和 45 年 5 月 22 日
法律第 90 号）に基づき実施される情報処理技術者試験のうちプロジェクトマネージャ試験の合格者又は技術士（情報工学部門又は総合技術監理部門（情報工学を選択科目とする者））の資格を有する。但し、当該資格保有者等と同等の能力を有することが経歴等において明らかな者については、これを認める。その根拠（PDU受講証明書等）を明確に示し、広域機関の理解を得る。
・チームリーダは、情報システムの設計・開発又はシステム基盤導入の経験年数 5 年
以上有する。また、その中でリーダクラスとしての経験を 5 件以上有する。
・チームリーダは、以下のいずれかを満たす。
・情報処理の促進に関する法律に基づき実施される情報処理技術者試験のうちプロジェクトマネージャ試験の合格者。
・「IT スキル標準V3 2011」（平成 24 年 3 月 26 日 IPA）における「プロジェクトマネジメント」のいずれかの専門分野で達成度指標及びスキル熟達度ともにレベル 4 以上に相当する知識・経験を有する者。
・設計・開発に関わるメンバのうち、情報システムの設計・開発等の情報処理業務の経験年数が 5 年以上の者又は同等の実績を有する者を 5 分の１以上配置する。
・設計・開発を行う担当者には、情報処理の促進に関する法律に基づき実施される情報処理技術者試験のうち、次に掲げる試験区分の合格者を 1 名以上必要な人数含むことである。なお、同一人が全ての試験区分に合格していることを求めるものではない。
・システムアーキテクト試験、データベーススペシャリスト試験、ネットワークスペシャリスト試験
・設計・開発を担当者には、情報処理の促進に関する法律（昭和 45 年５月 22 日法律
第 90 号）第 15 条の規定に基づく情報処理安全確保支援士の登録を受けている者
・アジャイル開発を利用する場合は以下を満たしていること。
・受注者の遂行責任者はPMBOK 第 6 版について知識を得ていること。
・受注者の遂行責任者は、以下の事項を対象としてスケジュールを管理する。
①納入され、且つ受入れられた作業の総量と、経過時間サイクルでの作業完了の見積りとの比較によるプロジェクト・スケジュールの現在の状況の確認
②必要に応じて、プロセスの修正及び改善のための振り返りレビューの実施
③残作業計画（バックログ）の優先順位の再設定
④１回の反復単位（合意した作業サイクルの所要時間、通常は２週間か１ヶ月）の所定の時点で、成果物を生産し、妥当性が確認され、受入れられる速度の確定
⑤プロジェクト・スケジュールが変更されたことの確認
⑥変更発生時における実際の変更のマネジメント設計・開発を行う担当者は、アジャイル開発の経験を 5 件以上有する。
・更新の必要性がある資格（PMP 等）は、資格の失効がないように留意すること。なお、更新の必要がない資格については、資格取得年月日及び経歴を確認すること。
※資格等に対応した IT スキル標準の職種やレベルについて、「（別紙２） 調達する作業内容ごとの人材に関する要求要件（参考）」を参考とすること。
（４）作業場所
・本業務の作業場所及び作業に当たり必要となる設備、備品及び消耗品等について は、受注者の責任において用意する。また、必要に応じて広域機関が現地確認を実施することができるものとする。
・広域機関内での作業は、必要な規定の手続を実施し承認を得る。
・運用・保守において、広域機関が緊急招集した場合は、広域機関に３時間以内に参集できる。広域機関が発注者を緊急招集する場合としては、システム上のトラブルが発生する等した場合、直に受注者からの説明や対策等を求めることを想定としている。
・クラウドサービスを利用する場合は、リモートによる運用・保守等の体制整備について、広域機関に提示のうえ別途規定し承認を得る。
（５）作業の管理に関する要領
「４．作業の実施内容に関する事項」で作成を求めた要領（設計・開発実施要領、運用実施要領及び保守実施要領）に基づき、各管理及び報告作業を行うこと。なお、情報システムの設計・開発に当たっては、入札仕様書・要件定義書で定めた要件が過不足無く実現され、且つその内容が設計書等の成果物に適切に反映されること。
これらの点に鑑み、広域機関では成果物の検収を含むプロジェクトの各段階において、「（別紙１－２）検査等の際に確認するべき事項（チェックリスト）」を参考に必要な確認を実施する。
６．作業の実施に当たっての遵守事項
（１）機密保持、資料の取扱い
１ 受注者は、受注業務の実施の過程で広域機関が開示した情報（公知の情報を除 く。以下同じ。）、他の受注者が提示及び作成した情報を、本受注業務の目的以外に使用又は第三者に開示若しくは漏えいしてはならないものとし、そのために必要な措置を講ずる。
２ 受注者は、本受注業務を実施するに当たり、広域機関から入手した資料等については管理台帳等により適切に管理し、且つ、以下の事項に従う。
・複製はしない。
・用務に必要がなくなり次第、速やかに広域機関に返却する。
・受注業務完了後、上記１に記載される情報を削除又は返却し、受注者において該当情報を保持しないことを誓約する旨の書類を広域機関へ提出する。
・広域機関が許可する拠点から資料を持ち出さないこと。
３ 機密保持及び資料の取扱いについて、適切な措置が講じられていることを確認するため、広域機関が遵守状況の報告や実地調査を求めた場合には応じる。
（２）遵守する法令等ア 法令等の遵守
・作業方法等について広域機関の指示に従い、秘密保持契約を締結する等した上で、作業する。
・受注者は、受注業務の実施において、民法、刑法、著作xx、不正アクセス行為の禁止等に関する法律、行政機関の保有する個人情報の保護に関する法律等の関連する法令等を遵守する。
イ その他文書、標準への準拠
（ア）プロジェクト計画書
・本調達案件の業務遂行に当たっては、広域機関が定めるプロジェクト計画書（参考）との整合を確保して行う。プロジェクト管理の具体的な方法に関して記載したプロジェクト計画書(参考)については、入札説明会にて広域機関が提示する。
（イ）プロジェクト管理要領
・本調達案件の業務の管理に当たっては、広域機関が承認したプロジェクト管理要領との整合を確保して行う。
（ウ）プロジェクト標準
・本調達案件の開発に当たっては、「標準コーディング／名称付与等各種規約」を受注者が定めたうえで、これに準拠して作業を行う。
（３）情報セキュリティ管理
・受注者は、以下を含む情報セキュリティ対策を実施する。また、その実施内容及び管理体制についてまとめた情報セキュリティ管理計画書を提出する。
・広域機関から提供する情報の目的外利用を禁止する。
・本業務の実施に当たり、受注者又はその従業員、本調達の役務の内容の一部を再委託する先、若しくはその他の者による意図せざる不正な変更が情報システムのハードウェアやソフトウェア等に加えられないための管理体制を整備する。
・本委託業務の契約に先立ち事前に、受注者及び再委託先の資本関係・役員の他社の役職との重要な兼任に関する情報、委託業務の実施場所、委託業務従事者の所属・専門性（情報セキュリティに係る資格・研修実績等）・実績及び国籍に関する情報について記載した「サプライチェーンリスク管理票」を本機関に提出し、承認を受けること。ただし、委託業務従事者に関する情報は個人単位(名指し)である必要はない。
・情報セキュリティインシデントへの対処方法が確立されている。
・情報セキュリティ対策その他の契約の履行状況を定期的に確認し、広域機関へ報告する。
・情報セキュリティ対策の履行が不十分である場合、速やかに改善策を提出し、広域機関の承認を受けた上で実施する。
・広域機関が求めた場合に、速やかに情報セキュリティ監査を受入れる。
・本調達の役務内容を一部再委託する場合は、再委託されることにより生ずる脅威に対して情報セキュリティが十分に確保されるように情報セキュリティ管理計画書に記載された措置の実施を担保する。
・広域機関から要保護情報を受領する場合は、情報セキュリティに配慮した受領方法にて行う。広域機関から受領した要保護情報が不要になった場合は、これを確実に返却、又は抹消し、書面にて報告する。本業務において、情報セキュリティインシデントの発生又は情報の目的外利用等を認知した場合は、速やかに広域機関に報告する。
・契約締結後に再委託先の申請があり、情報セキュリティ管理計画書に記載された再委託先にサプライチェーンリスクがあると判断した場合には広域機関に相談すること。再委託先の変更があった場合も同様に扱う。
・本委託業務に関連して開示する機関の秘密情報の厳正な情報管理を維持するため、以下の点に留意し、情報セキュリティを確保するものとすること。
（１） 委託業務の実施に関して知りえた相手方の情報(以下「秘密情報」という)を秘密として保持し、これを相手方の書面による事前の承諾なく第三者に開示・漏洩してはならない。
（２） 委託業務遂行の目的以外で秘密情報を使用してはならない。
（３） 本委託業務の契約に先立ち事前に、業務に係る情報セキュリティ対策及び管理体制について、本機関に書面をもって提出すること。
（４） 秘密情報の漏洩、紛失、盗難、盗用等の事態が発生し、又はその恐れがあることを知った場合は、直ちにその旨を機関に書面をもって報告すること。
（５） 本機関から提供された秘密情報が業務終了等により不要になった場合には、確実に返却し又は廃棄すること。
（６） 本業務の一部を他の者に再委託し、再委託先に秘密情報を開示することとなる場合は、あらかじめに書面をもって本機関に届け出た上で、再委託先にも以上と同様の制限を課して契約すること。
７．成果物の取扱いに関する事項
（１）知的財産権の帰属
本調達に係り発生する成果物は、広域機関に知的財産権を帰属し、受注者に成果物の利活用を認めることを基本的な考え方とする。
・本業務における成果物の原著作権及び二次的著作物の著作権（著作xx第 21 条か
ら第 28 条に定める全ての権利を含む。）は、受注者が本調達の実施の従前から権利を保有していた等の明確な理由によりあらかじめ提案書にて権利譲渡不可能と示されたもの以外は、全て広域機関に帰属するものとする。
・広域機関は、成果物について、第三者に権利が帰属する場合を除き、自由に複製し、改変等し、及びそれらの利用を第三者に許諾することができるとともに、任意に開示できるものとする。また、受注者は、成果物について、自由に複製し、改変等し、及びこれらの利用を第三者に許諾すること（以下、「複製等」とい う。）ができるものとする。但し、成果物に第三者の権利が帰属する時や、複製等により広域機関がその業務を遂行する上で支障が生じるおそれがある旨を契約締結時までに通知した時は、この限りでないものとし、この場合には、複製等ができる範囲やその方法等について協議するものとする。
・本件プログラムに関する権利（著作xx第 21 条から第 28 条に定める全ての権利を含む。）及び成果物の所有権は、広域機関から受注者に対価が完済された時受注者から広域機関に移転するものとする。
・納品する成果物に第三者が権利を有する著作物（以下、「既存著作物等」とい う。）が含まれる場合には、受注者は、当該既存著作物等の使用に必要な費用の負担及び使用許諾契約等に関わる一切の手続を行う。この場合、本業務の受注者は、当該既存著作物の内容について事前に広域機関の承認を得ることとし、広域機関は、既存著作物等について当該許諾条件の範囲で使用するものとする。
・受注者は広域機関に対し、一切の著作者人格権を行使しないものとし、また、第三者をして行使させないものとする。
（２）契約不適合責任（改正前の民法における瑕疵担保責任）
広域機関が本委託の成果物が種類又は品質に関して本契約の内容に適合しないことを知った日から 1 年以内に通知した場合には、受注者に対し成果物の修補又は代替物の引渡し（以下「補修等」という。）の請求、契約金額の減額、損害賠償の請求及び本契約の解除の請求をすることができるものとする（ただし、成果物の引渡が完了した日から 5 年以内に限る）。
広域機関が補修等の通知をした場合には、その方法等について事前に広域機関の承認を得た上で、受注者の責任及び負担において速やかに修補等を行い、指定された日時までに補修等を完了すること。
なお、受注者は、修補等に過分の費用を要する場合であっても、契約不適合が重大な場合には、受注者の責任及び負担において修補等を行わなければならないものとする。
（３）検査
・本入札仕様書「４．（２）ア」に則って、成果物を提出する。その際、広域機関の指示により、別途品質保証が確認できる資料を作成し、成果物と併せて提出する。
・検査の結果、成果物の全部又は一部に不合格品を生じた場合には、受注者は直ちに引き取り、必要な修復を行った後、指定した日時までに修正が反映された全ての成果物を納入する。
・本入札仕様書「４．（２）ア」に依る以外にも、必要に応じて成果物の提出を求める場合があるので、作成資料は常に管理し、最新状態に保っておく。
・検査時には、「（別紙１－２）検査等の際に確認するべき事項（チェックリスト）」を活用する。
８．入札参加資格に関する事項
（１）入札参加要件
ア 公的な資格や認証等の取得
・品質管理体制について ISO9001:2015、組織としての能力成熟度について CMMI レベル 3 以上のうち、いずれかの認証を受けている。
・プライバシーマーク付与認定、ISO/IEC27001 認証（国際標準規格）、JIS Q27001
認証（日本工業標準規格）のうち、いずれかを取得している。
x 受注実績
以下の受注実績があることを客観的に説明することができる資料を添付すること。
・クラウドのリージョン数 2 以上のシステムを構築した実績を過去 5 年以内に有する。
・10000 名以上の閲覧が想定される Web 情報システムの設計・開発を行った実績を過去 5 年以内に有する。
ウ 複数事業者による共同提案
・複数の事業者が共同提案する場合、その中から全体の意思決定、運営管理等に責任を持つ共同提案の代表者を定め、本代表者が本調達に対する入札を行う。
・共同提案を構成する事業者間においては、その結成、運営等について協定を締結 し、業務の遂行に当たっては、代表者を中心に、各事業者が協力して行う。事業者間の調整事項、トラブル等の発生に際しては、その当事者となる当該事業者間で解決する。また、解散後の契約不適合責任に関しても協定の内容に含める。
・共同提案を構成する全ての事業者は、本入札への単独提案又は他の共同提案への参加を行っていない。
・共同提案を構成する全ての事業者は、全ての入札条件を満たす。
・競争入札参加資格が低ランクの者が企業規模の大きい高ランクの者と共同提案を行うことは、受注事業者の履行能力を担保しつつ、低ランクの者にも参加機会を拡充することに資することから、共同提案に対する参加機会を与える趣旨のも と、共同提案を認める。
・受注事業者における情報セキュリティの確保については、共同提案を構成する事業者それぞれの管理体制や責任者の明確化を事業者間で協定に盛り込む。
エ その他
・入札説明書２．競争参加資格を満たすこと。
（２）入札制限
特になし
９．再委託に関する事項
（１）再委託の制限及び再委託を認める場合の条件
・受注者は、受注業務の全部又は受注業務における総合的な企画及び判断並びに業務遂行管理部分を第三者に再委託することはできない。また、本事業の契約金額に占める再委託契約金額の割合は、原則２分の１未満とする。
・受注者は、知的財産権、情報セキュリティ（機密保持及び遵守事項）、ガバナンス等に関して本入札仕様書が定める受注者の債務を、再委託先事業者も負うよう必要な処置を実施する。また、再委託先事業者の対応について最終的な責任を受注者が負う。
・受注事業者は、広域機関の求めに応じて再委託先事業者の業務（情報セキュリティ対策も含む。）の履行状況を確認・報告する。
・広域機関は、必要に応じて、再委託先事業者に受注事業者と同等の義務付けを行う場合がある。
・広域機関は、必要に応じて、情報セキュリティ確保のためのルール遵守や成果物の確認方法（例えば、標準コーディング／名称付与等各種規約 遵守の確認、ソースコードの検査、現場での抜き打ち調査等についての実施主体、手順、方法等）を求めることがある。
（２）承認手続
・受注業務の一部を再委託する場合は、あらかじめ再委託の相手方の商号又は名称、住所及び代表者名並びに再委託を行う業務の範囲、再委託の必要性について記載した「再委託に係る承認申請書」を提出し、承認を受ける、なお、再委託の相手方は
「８．（２）入札制限」の対象となる事業者でないこと。
当初申請内容に変更が生じた場合は「再委託に係る変更承認申請書」を提出すること。
・再委託の相手方から更に第三者に委託が行われる場合は、当該第三者の商号又は名称及び住所並びに委託を行う業務の範囲等を記載した「履行体制図」を提出する。
・広域機関は、再委託先から更に委託が行われる場合も考慮し、当該調達案件に係る履行体制を受注者に確認することがある。受注者は、再委託の相手方から更に第三者に委託が行われる場合も管理を行う。
１０．その他特記事項
（１） 前提条件及び制約条件
・本システムでは、2022/4/1 以降のデータを公表することを想定している。3 月中旬に 2022/4/1 のデータが演算対象になるため、システムの稼働開始が 3 月中～下旬になる可能性がある。
・本件受注後に入札仕様書（別添要件定義書を含む）の内容の一部について変更を行おうとする場合、その変更の内容、理由等を明記した書面をもって広域機関に申入れを行う。
（２）環境への配慮
１ 調達に係る納入物については、「国等による環境物品等の調達の推進等に関する法律（グリーン購入法）」に基づいた製品を可能な限り導入する。
２ 導入する機器については、性能や機能の低下を招かない範囲で、消費電力節減、発熱対策、騒音対策等の環境配慮を行う。
（３）その他
・広域機関内の監査により、広域機関のシステム開発に対して指導、助言を受けた場合には、受注者もその方針に従う。
・受注者は、電子行政推進に係るの各種施策・方針等(今後出されるものを含む)に従う。
・広域機関のCIO やCIO アドバイザよりシステム開発担当箇所に対して、開発手法や工程管理等において指導、助言等を行った場合には、受注者もその方針に従う。
１１．附属文書
（１）要件定義書
別紙「広域予備率のＷｅｂ公表に係る開発及び運用・保守の業務委託 要件定義書」を参照する。
（２）閲覧要領
別紙 1. 2021 年度以降のインバランス料金の詳細設計等に係る検討状況
別紙 2. 第 39 回 制度設計専門会合 資料 4
別紙 3. 第 42 回 制度設計専門会合 資料 5-1
別紙 4. 第 22 回電力・ガス基本政策小委員会 資料 7-2
別紙 5. 第 47 回調整力及び需給バランス評価等に関する委員会 資料 2
別紙 6. 第 52 回調整力及び需給バランス評価等に関する委員会 資料 2
別紙 7. 第 54 回調整力及び需給バランス評価等に関する委員会 資料 3
（３）提案書等の審査要領
提案書等の審査要領については、「応札資料作成要領」、「評価手順書」を参照する。
（４）契約締結後に開示する資料
セキュリティ対策など、部外者に安易に開示できなく、契約締結後に開示となる資料は以下の通り。
・情報セキュリティ対策規程
・広域機関システム運用実施要領
システム運用実施要領中にセキュリティ対策に関連記載あり。
・広域機関システムセキュリティ基本設計書
（別紙１－１）本調達にて求める作業内容と SLCP-JCF2013 のアクティビティとの関係（※1）
１．設計・開発に係わる成果物
項番 | 工程 | 成果物 | 納入期日（予定） | SLCP-JCF2013 のアクティビティ |
１ | 計画 | ・プロジェクト計画書 | 2021 年 9 月 17 日 | 5.1.2 プロジェクト計画 |
２ | プロジェクト管理 | ・設計・開発実施計画書 （スケジュール、WBS、体制図等含む） ・設計・開発実施要領 ・設計・開発実施要領に基づく資料（課題管理表、進捗管理資料、リスク管理x x） ・標準コーディング／名称付与等各種規約 | 2021 年 9 月 17 日 | 5.1.2 プロジェクト計画 1.2.4 契約の実行 5.2.1 プロジェクトの監視 5.2.2 プロジェクトの制御 2.4.2 ソフトウェア要件定義プロセス |
３ | 要件定義 | ・要件定義書改定案 | 2021 年 10 月 15 日 | 2.2.4 要件の評価 |
４ | 基本設計・詳細設計 | ・設計書（基本設計書、詳細設計書、実体関連図（ERD）等、データ／テーブル定義書、情報システム関連図、ネットワーク構成図、ソフトウェア構成図、ハードウェア構成図、プログラム一覧等） ・ドメイン運用管理手順書 | 2021 年 11 月 26 日 | 2.3.2 システム要件定義プロセス 2.3.3 システム方式設計プロセス 2.4.2 ソフトウェア要件定義プロセス 2.4.3 ソフトウェア方式設計プロセス 2.4.4 ソフトウェア詳細設計プロセ ス |
５ | 開発 | ・ソースコード一式 ・実行プログラム一式 | 2022 年 2 月 28 日 | 2.3.4 実装プロセス 2.4.5 ソフトウェア構築プロセス |
６ | テスト | ・テスト計画書 ・テスト仕様書 ・単体テスト結果報告書 ・結合テスト結果報告書 ・総合テスト結果報告書 ・受入テスト結果報告書 ・テストデータ ・品質管理計画書 ・品質確認報告書 | 試験実施前試験実施後 | 2.3.5 システム結合プロセス 2.4.6 ソフトウェア結合プロセス 2.3.6 システム適格性確認テストプロセス 2.4.7 ソフトウェア適格性確認テストプロセス 4.3.2 検証 4.4.2 妥当性確認 |
７ | 移行 | ・移行計画書（WBS 含む） ・移行手順書 ・移行結果報告書 | 2022 年 3 月 24 日 | 3.1.3 業務及びシステムの移行 |
８ | 教育 | ・操作手順書 ・教育訓練教材 ・FAQ ・引継ぎ資料 ・クラウドサービスプロバイダとの契約内容や引継ぎ手順等 ・運用ツールの操作方法等に関する手順書 | 2022 年１月 31 日 | 3.1.5 利用者教育 6.4.2 スキルの識別 6.4.2 スキルの開発 |
９ | 運用・保守 (※2) | ・運用計画書（案） ・保守計画書（案） ・運用実施要領 ・保守実施要領 | 2022 年１月 31 日 | 1.2.4 契約の実行 4.3.2 検証 |
１０ | 情報セキュリティ管理 | ・情報セキュリティ管理計画書 ・履行体制図 ・再委託に係る承認申請書 ・サプライチェーンリスク管理票 ・公知の情報を除いた広域機関が開示した情報を削除又は返却し保持しないことを誓約する旨の書類 ・広域機関から入手した資料の管理台帳 ・要保護情報を削除したことを報告する資料 ・脆弱性検査結果報告書 | 2021 年 9 月 17 日 2022 年 3 月 24 日 受入試験終了後 | 1.2.4 契約の実行 4.3.2 検証 |
１１ | プロジェクト 管理 | ・最終報告書 ・残存課題 | 2022 年 3 月 24 日 | 5.2.4 プロジェクトの終了 |
１２ | その他 | ・打ち合わせ資料 ・議事録 | 随時 | 1.2.4 契約の実行 4.1.3 文書発行 |
※1 アジャイル開発やプロトタイピングの場合は納入期日、成果物を広域機関と調整する
※2 保守計画書及び保守実施要領は、運用計画書及び運用実施要領は広域機関の承認のもと運用保守計画書及び運用保守実施要領とし、文書内で運用、保守の実施を明確にしたうえで統合してもよい。
２．ソフトウェア製品の賃貸借又は買取りに係る成果物
項番 | 工程 | 成果物 | 納入期日(予定) | SLCP-JCF2013 のアクティビティ |
１ | 導入 | ・納入ソフトウェア製品一式ソフトウェア構成表 ・ライセンス関係資料（ライセンス証書、ライセンス種別、ライセンス数、ライセンス料等） ・導入計画書 ・導入作業手順書 ・設定作業報告書 | 受入試験実施後 | 1.2.5 製品・サービスの納入及び支援 2.4.1 ソフトウェア実装プロセス開始の準備プロセス 2.4.8 ソフトウェア導入プロセス 2.4.9 ソフトウェア受入れ支援プロセス |
３．ハードウェアの賃貸借又は買取りに係る成果物
項番 | 工程 | 成果物 | 納入期日(予定) | SLCP-JCF2013 のアクティビティ |
１ | 導入 | ・納入機器一式 ・設置図面 ・導入設置計画書 ・導入作業手順書 ・設定作業報告書 ・保守計画書 ・撤去作業結果報告書 ・データ消去結果証明書 | 納入予定なし | 1.2.5 製品・サービスの納入及び支援 2.5 ハードウェア実装プロセス 6.2.1 プロセス開始の準備 6.2.2 インフラストラクチャの確立 2.6.1 プロセス開始の準備 3.2.1 システム又はソフトウェア廃棄計画 3.2.2 廃棄の実行 |
※今回はないことを想定しているが、開発の過程で必要となった場合は成果物とする。
４．運用に係わる成果物
項番 | 工程 | 成果物 | 納入期日(予定) | SLCP-JCF2013 のアクティビティ |
１ | 運用 | ・運用実施要領に基づく管理資料 ・運用作業報告書 ・運用実施要領、運用計画書の改善提案書 ・運用実施要領、運用計画書の改定案 ・運用操作マニュアル ・現況確認結果報告書 ・残存課題 | 随時 | 3.1.1 運用の準備 3.1.4 システム運用 3.1.6 業務運用と利用者支援 3.1.7 システム運用の評価 3.1.8 業務運用の評価 |
５．保守に係わる成果物
項番 | 工程 | 成果物 | 納入期日(予定) | SLCP-JCF2013 のアクティビティ |
１ | 保守 | ・保守実施要領に基づく管理資料 ・保守作業報告書 ・現況確認結果報告書 ・保守計画書、保守実施要領の改善提案書 ・保守計画書、保守実施要領の改定案 ・要件定義書、設計書の改定案 | 随時 | 2.6.1 プロセス開始の準備 2.6.2 問題把握及び修正の分析 2.6.3 修正の実施 2.6.4 保守レビュー及び/又は受入れ |
６．工程管理・支援に係わる成果物
項番 | 工程 | 成果物 | 納入期日(予定) | SLCP-JCF2013 のアクティビティ |
１ | 計画 | ・プロジェクト計画書 ・プロジェクト管理要領 ・マスタスケジュール | 2021 年 9 月 17 日 | 2.1.2 システム化計画の立案プロセス 5.1.2 プロジェクト計画 1.2.4 契約の実行 |
２ | プロジェクト管理 | ・議事録案 ・会議資料 ・進捗報告書 ・課題管理表 ・リスク管理表 ・変更管理表 ・見積評価書(変更管理が発生した時) | 2022 年 3 月 24 日 | 5.7 情報管理プロセス 5.2 プロジェクトアセスメント及び制御プロセス 5.4 リスク管理プロセス 5.5 構成管理プロセス 4.3.2 検証 4.2.4 品質システムの保証 4.4.2 妥当性確認 |
※当該表の内容は一例である。各情報システム調達に応じた成果物名、SLCP-JCF2013 のアクティビティ等を設定する。
項番 | 成果物名 | SLCP-JCF2013 のアクティビティ |
1 | 進捗管理表 ※プロトタイピングを採用する場合等、特に進捗管理の状況を成果物として明確に求めるとき | 1.2.4 契約の実行 2.1.2 システム化計画の立案プロセス 3.1.1 運用の準備 5.5.1. 構成管理計画 |
2 | 納入ソフトウェア製品一式/ソフトウェア構成表/ライセンス関係資料 （ライセンス証書、ライセンス種別、ライセンス数、ライセンス料等）/導入計画書/導入作業手順書/設定作業報告書 ※改修後のシステムの稼働に当たって必要なソフトウェア等がある場合 | 1.2.4. 契約の実行 1.6.7 ソフトウェアコード作成及びテスト 3.1.1 運用の準備 5.5.1. 構成管理計画 |
なお、上記の表に記載した代表的なもの以外で、採用する開発手法等に応じて求めることが考えられる成果物名と SLCP-JCF2013 のアクティビティ等との対応関係の例を以下補足する。
（別紙１－２）検査等の際に確認するべき事項（チェックリスト）
目標 | 仕様書、要件定義書、設計書等の「ドキュメント類」と「最新の状態(システム構成/運用業務等)」の整合 性、一貫性が確保されている。 | ||
Ａ．調達時 | |||
Ａ１ | ・入札仕様書の要件として、広域機関が承認した設計・開発実施要領に基づき、変更管理を行うことが含まれ ているか。 | ||
Ｂ．設計・開発時 | |||
計画作成時 | 設計・開発に当たっては、受注者が設計・開発実施計画書及び設計・開発実施要領の案を作成し、その内容について広域機関が承認を与える必要がある。承認に当たっては、変更管理のプロセスとして以下のＢ～Ｄの内容が網羅されていることを確認した上で承認する必要がある。その際、広域機関の誰が承認したかも含めて記 録として残す必要がある。 | ||
Ｂ１ | 設計・開発作業の進捗報告（変更管理の報告を含む。）等を行う会議体が定められているか。 | ||
Ｂ２ | 広域機関が承認を与える必要がある対象や、対象ごとの承認の手順・承認者等が定められているか。 ・承認を与える必要がある対象(基本設計書、テスト計画書等) ・対象毎の承認の手順（承認を申請する際のフロー、承認のタイミング(テスト計画書はテスト開始前に承認が必要等)） ・対象ごとの承認者(担当者、マネージャ、部長等) | ||
Ｂ３ | B2 に基づいて承認が与えられ一旦内容が確定したもの等（※）について、設計・開発を進める過程で変更の必要性が生じた際に、その変更管理をどのように実施するか定められているか。 ※B2 に基づく承認の対象となっているもの以外でも、システムの実態を正確に把握するために必要な情報は、変更管理の対象となる。 ・変更管理の対象（設計書類、ハードウェア・ソフトウェア等のパラメータ設定等） ・再承認の手順 ・事業者が広域機関の承認を得ずに変更作業を実施しないことを担保する仕組み ・記録の残し方(いつ、誰が、どこを、どのように、なぜ変えたのか) ・その他 | ||
設計等作業中 | |||
Ｂ４ | ・実施された又は実施されている作業と実施計画の紐付けが客観的に確認できるようになっているか。 ※進捗報告資料等において、作業報告内容と WBS 番号が紐付けられていて、内容が後々確認できるようになっている等。 | ||
Ｂ５ | ・実際に変更が生じた際に、B3 で定めた変更管理プロセスに基づいて行われているか。（計画自体に変更が 生じた場合も含むことに注意が必要。） | ||
設計書等作成完了時(検査時) | |||
Ｂ６ | ・上位文書で規定された内容が下位文書に適切に反映されているか。また、下位文書の内容に上位文書に規定されていない内容が含まれていないか。 （例文／留意事項：[上位文書]要件定義書→基本設計書→詳細設計書→設定書 [下位文書]) ※要件定義書上の全ての要件が、基本設計書、詳細設計書、設定書に抜け漏れなく詳細化されている。また、下位文書に、上位文書に記載されていない内容が含まれていないことを確認する。（トレーサビリティの確保） 上記の確認に際しては、受注者に要求要件が抜け漏れなくシステムに実装されていることを証明する根拠 資料（要求要件と各設計書類の該当箇所の対応xx）の提出を求めること等も考えられる。 | ||
Ｂ７ | ・詳細設計の過程で、基本設計で規定されていた一部機能の実現が技術的に困難であったことが判明する等、上位文書にも影響がある場合には、成果物の承認と併せて、上位文書も B3 で定めた変更管理プロセスが適切に実施されているか。 ※入札仕様書・要件定義書の内容は、調達内容（受注者との契約）に直結しているため、これを変更する際には、場合によっては契約変更等が必要となることに留意が必要。原則として、入札仕様書・要件定義書は変 更しないようにすることが重要である。 | ||
Ｂ８ | ・稼働開始後の運用・保守に関する運用計画書、保守計画書等（以下、「運用設計等」という。）において、変更管理に関するプロセスが定められているか。また、IT 資産管理簿がある場合、登録済みの内容に変更があった場合に、最新の状況を管理簿に反映することが定められているか。（管理簿がない場合、プロジェクト管理者に問題提起することが重要である。財務帳票がないのと等しいことを意識すること。） ※特に運用段階では、設計書に影響がない変更(ファイアウォールにおいて許可する送信元 IP アドレスや、ア プリケーション保守時のソースコードの軽微な変更、運用業務フローの軽微な修正等)が頻繁に発生することが想定される。こうした運用段階の変更についても適切に変更管理が行われるよう、運用の手順等を定め る運用設計等の中で変更管理プロセスを規定する必要がある。 | ||
Ｃ．運用・保守時 | |||
実行中 | |||
Ｃ１ | ・実施された又は実施されている作業と運用計画書・保守計画書の紐付けが客観的に確認できるようになっているか。 ※定例会の資料や議事録等により、その内容が後々確認できることが必要である。 確認するとは、事実（実態）を知る／見ることである。 | ||
Ｃ２ | ・実際に変更が生じた際に、B８で定めた変更管理プロセスに基づいて行われているか。（計画自体に変更が 生じた場合も含むことに注意が必要。） | ||
Ｄ．改修時(運用・保守とは別に調達する場合) | |||
改修作業～改修後運用時 | 既存のシステムに改修を加える場合にも、A～C と同様の管理が必要。特に改修内容がxxの設計書等に反映されておらず、最新の状況を把握するためには改修内容をxx追いかけていく必要があるケースが散見される。これらは１者応札や改修経費の高止まりの原因となるので、設計書類については常に最新版に「更新」するこ とが必要（追補版は認めない。）。検収時のチェック作業と捉える必要がある。 | ||
Ｄ１ | ・部分改修の場合であっても、Ａ～Ｃのチェック項目を実施しているか。 | ||
Ｄ２ | ・改修業務の役務に、改修によって影響を受ける既存の設計書等の更新作業も含めているか。 | ||
＜参考文献等＞
・調達に関する協定
（xxxx://xxx.xxxx.xx.xx/xxxxxx/xxxxx_xxxxxx/xxx_xxxxxxxxxx/xxxxxxxxx/xxxx/xxx00.xxxx）
・デジタル・ガバメント推進標準ガイドライン群（xxxxx://xxx.xx.xx/xxxxxx）
・デジタル・ガバメント推進標準ガイドライン
・デジタル・ガバメント推進標準ガイドライン解説書
・デジタル・ガバメント推進標準ガイドライン実践ガイドブック
・情報システムに係る調達制度の見直しについて
（xxxx://xxx.xxxx.xx.xx/xxxxxx/xx_xxxxxx/xxxxxxxx/xxxxxxx.xxx）
・加算方式による総合評価落札方式の導入について
（共働支援システム 情報システムに係る調達関係資料/20020715 20 加算方式による総合評価落札方式について.pdf）
・情報システムの調達に係る総合評価落札方式の標準ガイド
（xxxx://xxx.xxxxxx.xx.xx/xx/xxxxxx/00xxxxxxxx/xxxxxxxxxxxx/x0-00.xxxx）
・情報システムの調達に係る総合評価落札方式の標準ガイドライン
（xxxx://xxx.x-xxx.xx.xx/xxx/xxx/00_xxxxxxxxx.xxx）
・IＴコスト適正化指針
（xxxx://xxx.xxxxxx.xx.xx/xx/xxxxx/xx0/xxxxxxxxxxx/xxxxxx.xxx）
・環境物品等の調達の推進に関する基本方針
（xxxx://xxx.xxx.xx.xx/xxxxxx/xxxxx/xxxxx/x-xxx/xxxxxxxxxxxx.xxxx）
・「情報システムに係る政府調達におけるセキュリティ要件策定マニュアル（SBD マニュアル）」
（xxxxx://xxx.xxxx.xx.xx/xxxxxx/xxxxxxx/xxx_xxxxxxx.xxxx）
・経済産業省「クラウドサービス利用のための情報セキュリティマネジメントガイドライン」
（xxxx://xxx.xxxx.xx.xx/xxxxxx/xxxxxxxxxxx/xxxxxxxxxxxxx/xxxxxxxx0000xx.xxx）
・総務省「クラウドサービス提供における情報セキュリティ対策ガイドライン」
（xxxx://xxx.xxxxx.xx.xx/xxxx_xxxx/x-xxxx/00xxxxx00_00000000_00000.xxxx）
・金融情報システムセンター「金融機関におけるクラウド利用に関する有識者検討会報告書」
（xxxxx://xxx.xxxx.xx.xx/xxxxxxx/?xxx000&xxxxxxxx&xxxx000）
・一般社団法人 日本クラウドセキュリティアライアンス『Cloud Control Matrix（日本語版）』
（xxxx://xxx.xxxxxxxxxxxxxxxxxxxxx.xx/xxx_xx.xxxx）
・クラウドセキュリティ推進協議会（JASA）「クラウド情報セキュリティ管理基準」
（xxxx://xxxxxx.xxxx.xx/xxxxxxxxx/）
・政府情報システムのためのセキュリティ評価制度（ISMAP）
(xxxxx://xxx.xxx.xx.xx/xxxxxxxx/xxxxx/xxxxx.xxxx)
・電力広域的運営推進機関ホームページ
(xxxxx://xxx.xxxxx.xx.xx/xxxxx.xxxx)
・でんき予報
(xxxxx://xxx.xxxxx.xx.xx/xxxxxxxxxxxx/)
＜用語集＞
No. | 用語 | 説明 |
1 | SLCP-JCF2013 | ソフトウェアを中心としたシステムの開発及び取引のため の共通フレーム体系（2013 年版）。 |
2 | EVM | Earned Value Management の略称。プロジェクトの進捗を定量的に計測し、管理するためのプロジェクト管理手法。コスト、スケジュール、品質等について、計画と実績の差異を測定し、今後の推移を予測することで、プロジェクト 完了時のコストやスケジュールが推定できる。 |
3 | PMBOK | プロジェクトマネジメント知識体系ガイド（Project Management Body of Knowledge）の略称。アメリカの非営利団体 PMI が策定したプロジェクトマネジメントの知識体系。プロジェクトマネジメントの遂行に必要な基本的な知 識を汎用的な形で体系立てて整理したもの。 |
4 | SLA | サービスレベル合意書（service level agreement）の略称。サービスを提供する側とその利用者の間に結ばれるサービスのレベル（定義、範囲、内容、達成目標等）に関す る合意書。 |
5 | クラウドサービス | 事業者により定義されたインタフェースにより、拡張性、柔軟性を持つ共用可能な物理的又は仮想的リソースにネットワーク経由でアクセスでき、利用者により自由なリソース設定・管理が可能なサービスで、情報セキュリティに関する十分な条件設定の余地がある。この構成要素として、 SaaS(Software as a Service)、PaaS(Platform as a Service)、IaaS(Infrastructure as a Service)等が存在す る。 |
6 | クラウドサービス事業者 | クラウドサービスを提供する事業者又はクラウドサービス を用いて広域機関の情報システムを開発・運用する事業者。 |
7 | クラウドサービスプ ロバイダ | クラウドサービス事業者のうち、クラウドサービスを提供 する事業者。 |
8 | クラウドサービスブローカ | クラウドサービス事業者のうち、クラウドサービスを用いて機関の情報システムを開発・運用する事業者 ※本調達においては受注者に該当する。 |
9 | エンドユーザ | クラウドサービスの提供は行わず、クラウドサービスの利用のみを行う者。 ※本調達においては広域機関に該当する。 |
10 | IaaS | CPU，メモリ，ストレージ，ネットワーク等のハードウェア 資産をサービスとして提供するクラウドサービス。 |
11 | PaaS | OS や実行環境をサービスとして提供するクラウドサービ ス。 |
12 | SaaS | アプリケーションやデータベースをサービスとして提供す るクラウドサービス。 |
13 | クラウド | クラウドサービスに基づきクラウドサービスプロバイダか ら提供される物理的又は仮想的な全てのリソース。 |
No. | 用語 | 説明 |
14 | ISMAP | 政府情報システムのためのセキュリティ評価制度 （Information system Security Management and Assessment Program）。政府が求めるセキュリティ要求を満たしているクラウドサービスを予め評価・登録することにより、政府のクラウドサービス調達におけるセキュリティ水準の確保を図り、もってクラウドサービスの円滑な導入に資することを目的とした制度。 |
15 | CIO | CIO は、Chief Information Officer（情報化統括責任者）の略称。全体方針の策定、全組織における電子の取組を推進し、各組織内の情報化戦略及び基本的な方針又は計画の策定・推進・評価、IT を活用した業務の見直し、投資管理 及び人材の育成・確保等の事務を統括する責任を持つ。 |
16 | CRYPTREC （クリプトレック） | Cryptography Research and Evaluation Committees の略称。総務省及び経済産業省が共同で実施している暗号技術 評価プロジェクトのこと。 |
17 | ERD | データベース設計等のために使われるデータモデリング、 実体と実体・実体間の関連を表記するもの。 |
18 | EVM | Earned Value Management の略称。プロジェクトの進捗を定量的に計測し、管理するためのプロジェクト管理手法。コスト、スケジュール、品質等について、計画と実績の差異を測定し、今後の推移を予測することで、プロジェクト完了時のコストや完了までのスケジュールが推定できる。また、コスト超過やスケジュール遅延等を分析すること で、プロジェクトの問題点を把握できる。役務をベースとしているため、必要な役務自体の見積もり前提の妥当性を 図ることが重要である。 |
19 | IEC | International Electrotechnical Commission（国際電気標準会議）の略。電気及び電子技術分野の国際規格の作成を 行う国際標準化機関。 |
20 | ISO | International Organization for Standardization（国際標準化機構）の略。電気分野を除く工業分野の国際的な標 準である国際規格の策定を目的とする国際機関。 |
No. | 用語 | 説明 |
21 | IT アーキテクト | 情報システムの設計を行い、その成果物と効果に責任を持つ専門職。情報システムの構成が複雑化しており、システム全体の整合性や一貫性を保つことが困難になってきていることから、より高度な IT アーキテクトが必要とされてい る。 |
22 | OS | Operating System の略。プログラムの実行を制御するソフトウェアであって、資源割振り、スケジューリング、xx x制御、データ管理等のサービスを提供するもの。 |
23 | PJMO | Project Management Office（個別プロジェクト推進組織）の略。プロジェクトを遂行し、その進捗等を管理する機 能、責任を担う組織のこと。 |
24 | PMO | Portfolio Management Office（個別プロジェクト横断管理組織）の略。個別プロジェクトの IT 施策に関する全体管理の機能、責任を担う組織のこと。企業方針により PJMO が代 替することもある。 |
25 | WBS | プロジェクトの成果物単位に必要な作業を定義し、当該作業に必要な要員、工数及び期間を記載したもの。Work Breakdown Structure の略字。 |
26 | 業務フロー図 （業務流れ図） | Work flow Architecture の略。業務の流れや仕事の手順等を進行順に図で表したもの。「業務流れ図」を用いて業務の流れを整理することにより、誰が（どの部門が）何を行って、誰と（どの部門と）どんな関連があるのか、また、その業務がどのように流れて行くのかが明瞭となる。時間 の観点が重要である。 |
27 | アジャイル型開発 | 開発対象となる機能の設計・開発をイテレーション（反 復）と呼ばれる短い期間に分けて進め、イテレーションが終了する毎に機能の動作を確認できることを特徴とした開発の進め方である。要件が明確に確定しない場合に採用され、ユーザ側がリードし、要件サポート要否判断／意思決 定が迅速でなければ失敗する。 |
28 | インタフェース | 利用者との間の処理手順、データのやり取りに係る規則の 意味。 |
29 | 受入テスト | システムが仕様どおりに作成されているかどうかを確認す るためのテスト。定められた手順に従い、発注者が確認作業を実施すること。 |
No. | 用語 | 説明 |
30 | 運用 | 情報システムの設計された仕様及び構成の変更を原則として行わずに、情報システムの稼働状態を維持することを目 的とした活動及びこれに付随する活動 。 |
31 | 可用性 【availability】 | 許可された者が必要な時に必要な情報を利用できること。 |
32 | 機能改修 | 新規開発された情報システムについて、設計された仕様を変更又は追加し、当該情報システムの機能等に修正を行う こと。 |
33 | 機能要件 | 業務要件を実現するために必要な情報システムの機能のこ と。 |
34 | 更改 | ハードウェア、ソフトウェア製品、AP プログラム等の入替 え、その入替え時に発生する一連の活動。 |
35 | 部課情報セキュリティポリシー | 部課において、情報セキュリティの確保のために採るべき対策及びその水準を更に高めるための対策の方針と基準を 定めたものである。 |
36 | コンテンツ | 情報の内容、中身、文脈。 |
37 | 承認 | 受注者が作成する文書等の最終的な内容確認を行い、正式 版として認めること。 |
38 | 制約条件 | 時間、予算、品質等を制限する条件のこと。 |
39 | 前提条件 | 事前に必要となる条件のこと。 |
40 | デジタル・ガバメント推進標準ガイドライン | 政府情報システムの標準的な整備及び管理について、その手続・手順に関する基本的な方針及び実施事項、各組織の役割等を定める体系的な共通ルール。標準ガイドラインと 略称している。 |
41 | デジタル・ガバメント推進標準ガイドライン附属文書 | 標準ガイドラインの下位文書として、情報システムの整備及び管理に直接関係する内容のうち、特定の分野に関する内容について、その手続・手順に関する基本的な方針及び実施並びに内の各組織の役割等を定める共通ルールのこ と。 |
42 | 反復型開発 | 情報システムを小さな機能単位に分割し、設計、プログラミング、テストを繰り返しながら徐々に機能や改良を加え て、最終的に完全なシステムを開発する手法のこと。 |
43 | 非機能要件 | 機能要件以外の情報システム要件のこと。 |
44 | フレームワーク | 骨組みや枠組み、組織や体制のこと。 |
No. | 用語 | 説明 |
45 | プロジェクト | 特定の対象範囲に対し、特定の目的、目標を実現するため に、特定期間に実施する作業全体。 |
46 | 保守 | 機能維持、品質維持等、情報システムを設計された仕様どおりに動作、維持させることを目的とした活動及びこれに付随する活動。その対象は、AP プログラム、HW／SW 製品、 データ等がある。 |
47 | 広域機関 | 電力広域的運営推進機関。本案件の発注者。 電力の安定供給確保、送配電設備のxx・xx・効率的利用の推進、需給状況・系統運用状況監視などを実施する。 |
48 | 広域機関システム | 広域機関業務を実施することを目的に開発された、現行のシス テム。 |
49 | コマ | 翌日データでは 00:00～00:30 を 1 コマ目とし、そこから 24 時間について 30 分ごと 48 コマを持つ。 週間データでは、1日のうち最大需要となる30分、最小予備率となる30分の2つのコマを持つ。 |
50 | KPI | Key Performance Indicator の略。目標の達成度合いを計 るために継続的に計測・監視される定量的な指標。 |