Contract
令和６年度から令和 10 年度までの生物多様性見える化システムの設計・開発及び運用・保守業務
令和６年 ２月
環境省 自然環境局 自然環境計画課
1. 調達案件の概要 1
調達件名 1
調達の背景 1
調達目的および期待する効果 1
業務・情報システムの概要 3
契約期間 3
作業スケジュール 4
2. 調達案件及び関連調達案件の調達単位、調達の方式等 4
調達範囲 4
調達案件の一覧 5
3. 情報システムに求める要件 5
4. 作業の実施内容に関する事項 5
設計・開発実施計画書等の作成 6
要件定義 8
設計 8
開発・テスト 12
受入テスト支援 13
運用・保守 13
引継ぎ 15
教育 15
定例会等の実施 15
管理するデータの基本事項 15
最終報告書の作成 15
成果物について 16
情報資産管理標準シートの提出 19
その他 20
5. 作業の実施体制・方法に関する事項 21
作業実施体制と役割 21
作業要員に求める資格等の要件 22
作業場所 24
作業の管理に関する事項 24
6. 作業の実施に当たっての遵守事項 24
機密保持、資料の取扱い 24
政府機関等のサイバーセキュリティ対策のための統一基準 25
個人情報等の取扱い 26
法令等の遵守 27
標準ガイドライン等 27
その他文書、標準への準拠 27
規定等の説明等 28
情報システム監査 28
情報セキュリティの管理体制について 28
セキュリティ要件 30
7. 成果物に関する事項 30
知的財産権の帰属 30
契約不適合責任 30
検収 30
8. 入札参加に関する事項 31
競争参加資格 31
公的な資格や認証等の取得 31
受注実績 31
複数事業者による共同入札 32
入札制限 32
9. 再委託に関する事項 32
再委託の制限及び再委託を認める場合の条件 32
承認手続 33
再委託先の契約違反等 33
10. 外部サービスの選定、利用に関するセキュリティ関連事項(要機密情報を取り扱う場合) 33
外部サービス全般の利用に関する共通セキュリティ要件 33
クラウドサービスの選定、利用に関するセキュリティ要件 34
11. その他特記事項 34
前提条件等 34
機器等のセキュリティ確保、リストの提出 35
入札公告期間中の資料閲覧等 35
その他特記事項 36
その他 36
12. 附属文書 36
（別添） 37
（別紙２） 38
（別紙３） 40
（別紙４） 41
（別紙５） 42
（別紙６） 43
（別記様式） 45
（別記様式） 46
1. 調達案件の概要
調達件名
令和６年度から令和 10 年度までの生物多様性見える化システムの設計・開発及び運用・保守業務
調達の背景
令和４年 12 月に開催された生物多様性条約第１５回締約国会議（ＣＯＰ１５）において、生物多様性に関する新たな世界目標である「昆明・モントリオール生物多様性枠組」が採択され、2030 年までに「自然を回復軌道に乗せるために生物多様性の損失を止め反転させる」という、いわゆる「ネイチャーポジティブ」や、「2030 年までに、陸地及び海洋の少なくとも 30％を保全又は保護すること（30by30 目標）」が掲げられた。
「30by30 目標」の達成のためには、国立公園や鳥獣保護区等の保護地域の拡充に加え、
「保護地域以外の生物多様性保全に資する地域（OECM：other effective area-based conservation measures）」を設定することが重要となる。そのため、環境省では、「民間の取組等によって生物多様性の保全が図られている区域」を「自然共生サイト」として国が認定する仕組みを令和５年度から開始している。自然共生サイトのうち、保護地域との重複を排除した区域については、OECM として国際データベースに登録される。
生態系ネットワークの構築を図りつつ、効果的、効率的、戦略的に自然共生サイトを設定するためには、生物多様性の現状や、保全のニーズがある場所、保全上効果的な場所や生態系の回復が必要な場所を見える化し、生態系の質的な変化を含めて評価・把握する手法の構築を図ることが必要である。また、民間等による自然共生サイトの取組を促進できるよう、自然共生サイトの申請、効果的な保全手法の検索を簡易的に実施でき、また認定されたサイトにおける保全状況を一元的に把握できる機能を具備した、保全活動の把握から保全活動効果の評価まで一気通貫の取組を「見える化」できる仕組みを構築することが必要である。
これらの状況を踏まえ、本生物多様性見える化システムは、令和５年度に要件定義、令和６年度に設計・開発を行い、令和 7 年（2025 年）４月から、新たなシステムとして運用・保守を開始する予定である。
調達目的および期待する効果
本業務は、我が国の全国各地において保全上効果的な場所等が把握され、それらの場所において効果的に民間等による自然共生サイトの取組みを促進することで、ネイチャーポジティブ、30by30 目標を達成に貢献することを目的とし、以下の目標及び期待効果を掲げている。
ア. 目標
① 地方公共団体単位の保全状況の把握
地方公共団体担当者が生物多様性地域戦略等の地域の保全戦略を策定しようとした際に、どこを保全すべきか、どの生態系タイプが特に保全されていないのか、どの程度保全すれば管内の 30by30 目標を達成できるか等が分かる。
② 保全すべき場所・種の生息場の把握
地方公共団体担当者や、自然共生サイト等保全活動に取組もうとしている者（支援者も含む）が、まず地域で保全すべき場所・種の生息場を確認できる。
③ 認定業務の効率化及び活動の活性化
保全に取組む企業、NPO、地方公共団体等が、自然共生サイトの申請→活動→報告を簡便かつ 効率的に行うことができ、活動努力の見える化により評価→企業価値の向上、マッチング等による支援につながる。
④ 30by30 等の目標達成状況の可視化
我が国の生物多様性に関する質的、量的な変化をより詳細に把握するとともに、 30by30 等の国際目標達成状況を可視化できる。
イ. 期待効果
① 地方公共団体単位の保全状況の把握
各地方公共団体が管内の生物多様性の保全状況を把握することにより、生物多様性地域戦略の立案の基礎資料にするとともに、自らが主体となる活動の推進や管内の企業や団体等の生物多様性保全の取組を促進する。
② 保全すべき場所・種の生息場の把握
既に生物多様性豊かな場所に対する自然共生サイトの申請を促し、認定によって今後も適切に保全が継続される蓋然性を高めるとともに、現時点では生物多様性の価値基準に合致していなくても、管理放棄地や開発跡地などにおける生態系の回復及び創出など、現在から未来に向けての生物多様性保全を推進する。
③ 認定業務の効率化及び活動の活性化
認定された民間等による保全活動の把握から保全活動の効果の評価まで一気通貫の取組を「見える化」でき、自然共生サイトの所有・活動を行う主体が外部の企業等から経済的及び人的な支援等を得られやすくなるなどによって、生物多様性の保全に効果的な活動が未来志向的に継続される仕組みとなり、５年ごとの自然共生サイト認定の更新を簡略化に繋げる。
④ 30by30 等の目標達成状況の可視化
ネイチャーポジティブや 30by30 目標の実現に向けた進捗を把握できるとともに、 OECM 国際データベースに登録することにより民間等の取組を国際的な評価に繋げる。
業務・情報システムの概要
①土地の所有者・管理者、②自然共生サイトの所有・活動を行う主体、③自然共生サイトの支援者、④国民、⑤研究機関・研究者、⑥行政機関職員、⑦事務局（環境省）、⑧運用・保守事業者が本システムの利用者となり、「システム準備」「認知」「自然共生サイト申請前準備」「自然共生サイト申請」「審査」「自然共生サイト認定後の保全活動」「保全促進」「システム管理」を行う。
なお、「自然共生サイト申請」「審査」等の一部機能は令和 7 年度以降に稼働を検討するものとし、初期実装機能対象外となる。
また、本システムは、クラウド・バイ・デフォルト原則に基づき、ガバメントクラウドを含むクラウド環境上に構築する。
図 1-1 システム構成概要（想定）
契約期間
契約締結日から令和 11 年３月 31 日まで
作業スケジュール
作業スケジュールは次のとおり想定している。
なお、システム設計から本稼働までの期間が８か月では不足し、全ての機能を令和６年度中に開発することが難しい場合は、主に生物多様性情報を地図上で表示する機能、日本全国・都道府県・基礎自治体ごとの保護地域等の面積・カバー率等の表示機能、生物種目録や自然共生サイトの情報検索・閲覧機能等を持つ「地理情報サブシステム」を優先し、自然共生サイト内で確認された生物種の記録及び活動実施内容の報告を行うための入力画面の関連機能は劣後することを検討すること。令和６年度中に開発できなかった機能については、令和７年度 3 か月程度以内に開発を完了すること。当該の検討においては、環境省担当官と協議し、決定すること。
設計
調達手続
開発・テスト
受入テスト
管理支援
工程
運用・保守
様定
仕決
本業務の調達範囲
等
3
2
1
12
11
10
9
8
7
6
5
令和 7 年度(2025 年度)
～
令和 10 年度(2028 年度)
工程管理支援
運 用 ・保守
シ ス テム構築
要件定義
要件定義
本
4
令和 6 年度（2024 年度）
令和 5 年度
（2023 年度）
項目
図 1-2 作業スケジュール
2. 調達案件及び関連調達案件の調達単位、調達の方式等
調達範囲
本調達では、生物多様性見える化システムの設計・開発及び運用・保守業務を行うものとし、請負者の責任範囲は、生物多様性見える化システムの設計・開発及び運用・保守業務まで一連の業務すべてとする。
なお、上記は責任分界の基本方針である。責任範囲の調整が必要となった場合には、環境省担当官と協議の上、決定すること。
調達案件の一覧
本調達案件と関連調達案件の調達単位、調達の方式、実施時期を以下に示す次期システムの運用開始は令和７年度を予定している。
表 2-1 関連する調達案件の一覧
項番 | 調達案件名 | 調達の方式 | 契約締結日 | 意見招請入札公告 落札者決定 | 契約期間 |
1 | 令和４年度 OECM 情報システム（仮称）構築に向けた要件定義書作成等業務 | 随意契約（企画競争方式） | 令和４年９月２日 | 令和４年９月２日 ～ 令和５年３月 29 日 | |
2 | 令和５年度生物多様性見える化システム （仮称）構築に向けた要件定義書作成及 び調達支援等業務 | 一般競争入札 （総合評価落札方式） | 令和５年９月７日 | 令和５年９月７日 ～ 令和６年３月 27 日 | |
3 | 令和６年度生物多様性見える化システム設計・開発及び運 用・保守業務 | 一般競争入札 （総合評価落札方式） | 意見招請：令和６年２月頃 入札公告：令和６ | （本調達） | |
年４月頃 | |||||
落札者決定：令和 ６年 7 月頃 | |||||
4 | 令和６年度生物多様性見える化システム設計・開発及び運用保守に係る工程管理支援業務 | 随意契約（企画競争方式） | 企画競争公告：令和６年３月頃 契約候補者決定： 令和６年５月頃 |
※実施時期については目安となる
3. 情報システムに求める要件
設計・開発の実施に当たっては、「別紙１ 要件定義書」の各要件を満たすこと。
4. 作業の実施内容に関する事項
本業務は、「令和４年度 OECM 情報システム（仮称）構築に向けた要件定義書作成等業務、「令和５年度生物多様性見える化システム（仮称）構築に向けた要件定義書作成及び調達支援等業務」の検討結果を踏まえて実施すること。
検討の結果、要件や設計等の見直しが必要となった場合は、原則として本業務において要件や設計等を見直しの上、構築を行うこと。（ただし、環境省担当官と協議の上、運用開始までに設計・開発が完了しないことが明らかな場合は除く。）
本業務の結果、基本設計書・詳細設計書の記載内容に変更が生じる場合は、その都度基本設計書・詳細設計書を修正する。修正に関しては環境省担当官及び工程管理支援事業者のレビューを受けた上で、環境省担当官の承認を得ること。
設計・開発実施計画書等の作成
(1) 設計・開発実施計画書及び設計・開発実施要領
請負者は、「プロジェクト計画書」及び「プロジェクト管理要領」と整合をとりつつ、環境省担当官の指示に基づき、工程管理支援事業者と調整の上、「設計・開発実施計画 書」及び「設計・開発実施要領」を作成し、環境省担当官の承認を得ること。
「設計・開発実施計画書」及び「設計・開発実施要領」は各工程での検討結果等を踏まえて必要に応じて詳細化・更新し、環境省担当官の承認を得ること。
設計・開発・テスト等に際しては、関連する事業者やシステム側への依頼・連携が必要であるため、その内容や役割分担を記載すること。
(2) 標準ガイドライン遵守
作業実施に当たり、「デジタル・ガバメント推進標準ガイドライン」(令和５年５月 12日最終改定（デジタル社会推進会議幹事会決定）。以下「標準ガイドライン」という。）※の内容を遵守すること。契約期間中に標準ガイドラインが改定された場合は最新の版を参照し、環境省担当官と協議の上、対応について決定すること。
請負者が作成する「設計・開発実施計画書（案）」には、標準ガイドライン 第 3 編第
7 章 1.「1) 設計・開発実施計画書の記載内容」に基づき、次に掲げる事項を含めること。
作業概要作業体制
スケジュール成果物
開発形態、開発手法、開発環境、開発ツール等その他(前提条件・制約条件)
本業務において作成する成果物、提出物は、納入成果物に係る納入期限によらず、作業進捗に応じた適切なタイミングで環境省担当官に提出すること。
提出した内容に変更があった場合は、変更の事由が生じた都度、再度提出し、環境省担当官の承認を得ること。
※ 標準ガイドライン：https://www.digital.go.jp/resources/standard_guidelines
(3) プロジェクト管理の実施及び報告ア 作業進捗の報告等
作業の進行方法、方針の確認、修正及び進捗状況確認に関して、別途環境省担当官が指示する必要な書類を作成し、週 1 回の報告を想定する。詳細は設計・開発実施要領の作成時に環境省担当官と協議の上、決定すること。なお、報告にはプロジェクトマネージャが出席すること。また、環境省担当官が求める場合は、必要に応じて体制に参画しているメンバー（セキュリティ要員や UI/UX 要員など）を参加させること。
イ 作業進捗管理
作業実施に当たり、次のとおり作業進捗管理を行うこと。なお、全ての管理項目について進捗会議等で定期的に環境省担当官に報告すること。
進捗管理
実施すべき全ての作業は具体的に進捗状況を把握できる単位まで詳細化し、階層構造で表したもの（WBS）及び定量的に状況が把握できる手法にて進捗管理を行
うこと。進捗状況は進捗会議等で定期的に報告すること。
具体的な進捗管理方法は、設計・開発実施計画書の策定時点で、プロジェクトの特性に合わせて環境省担当官と協議の上決定すること。
設計・開発における工程管理は以下の方針で管理を実施すること。
設計・開発段階で必要な作業項目を特定し、マイルストーンとの整合性と、その作業内容、スケジュールを詳細化し WBS で管理する。
WBS 利用にあたっては、各作業工程の作業内容や終了基準、計画工数、成果物やリスク等について記述し、環境省担当官の承認を得たのちに、各作業内容を進めるものとする。
定量的に進捗の把握ができるよう、EVM 又は同等の管理手法を用いた進捗管理を行うものとする。なお、EVM を用いて進捗管理を行う際には、次の資料を作成するものとする。
‒ EVM 進捗管理表
‒ 進捗状況表
‒ EVM 推移グラフ
‒ 進捗状況分析図
※ EVM とは、WBS により詳細化した各作業項目に出来高計画値（PV： Planned Value）を設定し、プロジェクトの進捗を出来高実績値 (EV： Earned Value)として定量化すること。EVM は Earned Value Management の略。
請負者と環境省担当官間でプロジェクト管理ツール等を共有する提案についても、妨げない。費用は原則として請負者の負担とするが、当該ツールのライセンス等を環境省担当官が保有する場合はその限りではない。利用する各種管理ツールの詳細は契約後協議の上、決定する。
課題管理
解決するべき課題・問題は、再発防止に生かすことも含めて、項目ごとに進捗等を管理し、適切に解決していくこと。
リスク管理
リスクの洗い出しを行い、リスク内容を判別した上で、各リスクの発生頻度、影響度、対応策（低減、受容、転換、回避等）、責任等を、監視・管理すること。情報セキュリティ対策
「6.作業の実施に当たっての遵守事項」の要件を満たすように実施すること。ソフトウェアに関する情報の整備
請負者は、本業務で納品又は更新する全てのソフトウェアの種類、バージョン及びサポート期間の終了日に係る情報並びにこれらの変更情報について、変更履歴及び最新の状況を管理した文書を整備すること。また、これらの内容に変更がある場合には文書を更新することで情報を提供すること。
品質管理
作業実施における品質管理について、次の事項を明確にし、実施すること。 品質管理方針
事前に各工程において品質目標及び工程完了基準を設定すること。
納入成果物に対して適切な検証活動を実施の上、結果について分析を行うこと。
分析結果から抽出した対策の立案と実施を行うこと。 品質管理方法
各工程の完了に伴いレビューを実施し、品質基準との差を把握すること。品質の自己評価を実施し、環境省担当官の承認を得ること。
変更管理/構成管理
作業実施における構成管理/変更管理について、管理手順を明確に記載すること。
環境省担当官と合意した最新の状況を適時に各種ドキュメントへ反映すること。
要件定義
請負者は、請負者の提案等を踏まえ、要件定義の内容に関する認識に可能な限り相違が生じないよう、環境省担当官と要件定義の内容について確認及び調整の上、「別紙 1 要件定義書」の要件定義を修正すること。要件の調整内容は、環境省担当官及び関係するステークホルダーに提示し、合意形成を図りつつ進めること。
請負者は、環境省担当官及び関係するステークホルダーに提示し、合意形成された「要件定義書（確定版）」に基づき、システム要件及び運用・保守要件を整理すること。
運用・保守要件の作成にあたり、環境省担当官作業の軽減等、効率的なシステム運用・保守に資する内容を反映させること。
設計
(1) 基本的な要件
ア 基本設計及び詳細設計
請負者は、要件定義書の要件を満たすための基本設計及び詳細設計（運用設計を含む。）を行い、成果物について環境省担当官からの承認を得ること。このうち、関係システムとのデータ連携に必要となる外部インタフェース仕様については、基本設計工程段階で整理し、環境省担当官の承認を受けること。なお、必要に応じ て、環境省担当官が行う関係組織との調整を支援すること。
環境省担当官の他にも、システム関係事業者が継続して本システムを運用・保守していくことが想定される。第三者が理解可能となるよう、特に用語の定義や表記ゆれに注意した上で、各種資料及び成果物は分かりやすく作成すること。
請負者は、開発時の構築環境を作成する手順を整理した「開発環境構築手順書」を作成し、環境省担当官の承認を受けること。
また、本システムにおいては、SaaS 型 GIS、及びGIS パッケージ製品の必要なパラメータ設定の内容を基本設計及び詳細設計として取りまとめる想定であるが、何らかの個別プログラム開発業務が発生する場合には、その設計内容を基本設計及び詳細設計に含めること。
イ プロトタイプの作成
新規整備機能等の実現可能性や費用対効果等については、必要に応じてプロトタイプ等により検証を行い、結果を環境省担当官に説明すること。
ウ 設計・開発に用いる環境
請負者は、設計・開発に用いる環境として、クラウドサービス上に構築する「本番環境」及び「検証環境」並びに請負者の拠点に整備する「開発環境」の 3 種類を利用すること。ただし、設計・開発に用いる環境は、原則として「検証環境」及び
「開発環境」とする。
本番環境及び検証環境では、アプリケーションプログラムのリリース、リリース後の動作確認等を行う。
開発環境では、アプリケーションプログラムの開発、業務結合テスト（アプリケーションプログラムの結合テスト）等を行うこと。
なお、SaaS 型 GIS、及びGIS パッケージ製品の仕様に照らして、「検証環境」及び「開発環境」の構築において何らかの代替手段を有している場合は、その内容を提案時に明示すること。
エ ライフサイクルコストの考慮
請負者は、本システムの設計開発から運用終了に至るまでの保守性を考慮して、基本設計及び詳細設計を実施すること。
オ クラウドネイティブなシステム構成
アプリケーションプログラムの設計・開発にあたっては、可能な限りクラウドネイティブなシステム構成を志向すること。また、Infrastructure as Code（IaC）を活用するなど、クラウドサービスの構成変更を効率的に実施できるよう配慮すること。
カ モニタリングが容易に行える構成
要件定義書「1.5.業務観点で管理すべき指標」に記載したプロジェクトの目標となる指標、システム運用に必要な情報等に対して、システムで適時に状況を取得できる構成とすること。また、統計処理等によって二次的に加工した情報だけでな く、そのこの根拠となる一次情報（ローデータ）も確認できる構成とすること。
(2) 基本設計及び詳細設計の実施（アプリケーションプログラム）ア アプリケーションプログラムの基本設計
アプリケーションプログラムについて、システム全体図、データの流れと機能構成、機能・画面・帳票一覧、画面・帳票フロー、データ一覧等の基本設計を行うこと。
以上をもとに、基本設計書（アプリケーションプログラム）をとりまとめること。
イ 要件との網羅性
基本設計書（アプリケーションプログラム）には、要件と設計項目の対応表等、要件が網羅されていることを確認できる情報を含めること。
ウ アプリケーションプログラムの詳細設計
アプリケーションプログラムについて、基本設計書（アプリケーションプログラム）に基づき、機能設計（機能定義、データチェック定義、アクセス制御方式
等）、スキーマ定義、コード定義、ジョブネット定義等の詳細設計を行うこと。 なお、本システムでは SaaS 型 GIS、及び GIS パッケージ製品の利用を想定して
いるため、詳細設計はシステム・サービス方式に関する設計に関する内容、及び個別プログラム開発が必要な場合等、必要な範囲が生じた場合に実施すること。な お、パッケージ製品の機能、もしくはサービスでまかなえない業務において、職員等の手作業による運用が発生する場合は、明確に切り分けて設計を行うこと。
以上をもとに、詳細設計書（アプリケーションプログラム）をとりまとめること。
エ 基本設計との網羅性
詳細設計書（アプリケーションプログラム）には、基本設計書（アプリケーションプログラム）の項目との対応表等、基本設計の内容が網羅されていることを確認できる情報を含めること。
オ パラメータ設計
請負者は、アプリケーションの動作の前提となるソフトウェア（パッケージ製品）を選定し、パラメータ等の必要な設計を実施すること。
(3) 基本設計及び詳細設計の実施（運用・保守）
ア 運用・保守計画
請負者は、運用設計及び保守設計を行った上で、以下の内容を取りまとめた運用計画書及び保守計画書の案を作成し、環境省担当官の確認を受けること。
情報システムの次期更改までの間に計画的に発生する作業内容 上記作業の発生が想定される時期等
イ 成果物の設定
請負者は、以下の内容について、必要な運用・保守設計を行うこと。
上記「ア. 運用・保守計画」に記載のある各運用・保守項目の作業仕様 作業実施に必要な成果物
リソースや使用する運用管理機能・ツール、各作業の完了条件 記録としての成果物等
ウ 必要経費（ランニングコスト）の算出
運用・保守設計を行う成果物には、以下を示すこと。
運用・保守段階において発生する各種コストに係る予実管理のための管理様式
運用・保守設計実施時点で判明している所要見込額
必要となるソフトウェアライセンス所要額及びクラウドサービス利用額
エ 運用・保守設計(基本設計)
請負者は、要件定義書の「3.16 運用に関する事項」、「3.17 保守に関する事項」に記載の運用・保守に関する要件を踏まえ、運用設計及び保守設計を行い、環境省担当官の承認を受けること。
オ 運用・保守設計(詳細設計)
請負者は、上記エの基本設計を踏まえ詳細な運用設計及び保守設計を行い、以下の内容を取りまとめた運用・保守計画を作成し、環境省担当官の承認を受けるこ と。
定常時における月次の作業内容、その想定スケジュール
障害発生時における作業内容（初動対応、障害切り分け、暫定対処、など） 情報セキュリティインシデントを認知した際の報告手順、対処手順等
カ 運用業務の効率化の方策
自動化、セルフサービス化等による効率的なシステム運用・保守に資するシステム改修案があれば提案すること。
キ 運用・保守設計手順書
請負者は運用・保守計画書を踏まえ、以下を取りまとめた運用・保守手順書（当該運用・保守手順書には運用・保守作業員が実作業レベルで利用するマニュアル等も含めること。）を作成し、環境省担当官の確認を受けること。
定常時及び障害時において想定される運用体制 保守体制
実施手順等
また、環境省担当官が提示する運用規定の要件に基づき運用規程の案を作成し、環境省担当官の確認を受けること。
(4) 基本設計及び詳細設計の実施（システム方式）
ア 基本設計
「別紙 1 要件定義書」の内容を参照し、システム方式に関する基本設計結果を記載したものとして「基本設計書（システム方式）」を作成し、環境省担当官の確認を得ること。「基本設計書（システム方式）」には以下の内容を含むこと。
非機能要件（可用性、性能・拡張性、運用・保守、セキュリティ等） システム設計（システム環境、ネットワーク、設備・運用）
業務継続設計（システムバックアップ、データバックアップ、障害発生時の縮退運転や自動継続運転、大規模災害対策拠点・環境）等
イ 詳細設計
基本設計書（システム方式）を踏まえ、システム方式に関する詳細設計結果を記載したものとして「詳細設計書（システム方式）」を作成し、環境省担当官の確認を得ること。「詳細設計書（システム方式）」には以下の内容を含むこと。
非機能要件（可用性、性能・拡張性、運用・保守、セキュリティ等） システム設計（システム環境、ネットワーク、設備・運用）
業務継続設計（システムバックアップ、データバックアップ、障害発生時の縮退運転や自動継続運転、大規模災害対策拠点・環境）等
ウ 環境定義
以下の環境定義に係る作業を行うこと。
次期システムが個別に配置し、独自に設計・実装して利用するソフトウェア（以下
「持込みソフトウェア」）のセットアップを行うための手順を記載したものとして
「環境構築手順書」を作成すること。
構築作業全般のスケジュール、手順、要領等も必要に応じて記載すること。また、クラウドサービスプロバイダが提供する稼動環境（本番環境・検証環境等）のセットアップ後に、稼働環境が想定どおりに構築できていることを確認するためのテスト・確認項目を記載したものとして、「動作確認テスト項目表」及び「持込み機器疎通確認項目表」を作成すること。
「詳細設計書」等をもとに、クラウドサービスプロバイダが提供する資源（OS、ミドルウェア）や持込みソフトウェアの環境パラメータをとりまとめたものとして
「環境定義書」を作成すること。
請負者は、基盤構築の結果、「環境定義書」の内容に修正が発生した場合は、「環境
定義書」も修正すること。
構築するシステム稼働環境について、クラウドサービス、機器、ソフトウェア等を一覧表でとりまとめたものとして「機器、ソフトウェア等の一覧表」を作成すること。
開発・テスト
(1) ルールの規定
請負者は、開発に当たり、アプリケーションプログラムの開発又は保守を効率的に実施するため、プログラミング等のルールを定めた標準（「標準コーディング規約」、「セキュアコーディング規約」等）を定め、環境省担当官の確認を受けること。
(2) ルール遵守や成果物の確認方法
請負者は、開発に当たり、情報セキュリティ確保のためのルール遵守や成果物の確認方法（例えば、標準コーディング規約遵守の確認、ソースコードの検査、現場での抜き打ち調査等についての実施主体、手順、方法等）を定め、環境省担当官の確認を受けること。
(3) 開発手法
本プロジェクトでは、従来のウォーターフォールに限定せず、スパイラル／アジャイル等柔軟な対応を可能とする手法をプロジェクトの特性を踏まえ検討すること。
また、出来るだけ継続的インテグレーション・継続的デリバリー（CI/CD）を可能とし、開発作業だけでなく運用保守作業も含めて効率的な手法を取り入れること。
(4) 開発ツール
請負者は、プログラム設計・製造に当たり開発フレームワーク等のツールを用いる場 合、ベンダーロックインを防ぐため、原則として特定の事業者しか使用できない技術、製品、サービス等に依存しないツールを用いること。
(5) 開発の実施
請負者は、環境省担当官の承認を得た「基本設計書」及び「詳細設計書」に基づき、本システムのプログラム設計、プログラム開発を実施すること。当該作業は、請負者の拠点に整備する開発環境にて行うこと。
開発に必要となる環境設定やテストデータ、テストプログラム等の作成は、請負者が行うこと。
(6) テスト計画と実施
請負者は、単体テスト、結合テスト及び総合テストについて、以下の内容を記載したテスト計画書を作成し、環境省担当官の承認を受けること。なお、各テスト項目のうち、反復的にテストを実施するものについては、自動化することを原則とする。
テスト体制 テスト環境 作業内容
作業スケジュール テストシナリオ 合否判定基準等
請負者は、テスト計画書に基づき、テストを実施すること。
請負者は、テスト計画書に基づき、各テストの実施状況を環境省担当官に報告するこ
と。
テストの実施に当たり必要な費用は全て契約金額に含めること。
受入テスト支援
環境省担当官請負者は、環境省担当官が実施する受入テスト計画書作成作業を支援するために、「受入テスト計画書案」を作成すること。環境省担当官は「受入テスト計画書
案」を基にして「受入テスト計画書」を作成する。なお、受入テストの実施期間は十分に確保したスケジュールとすること。
請負者は、環境省担当官が実施する「受入テスト仕様書」作成作業を支援するために、テスト項目、使用するテストデータ、合格判定基準等を示した「受入テスト仕様書案」を作成すること。環境省担当官は「受入テスト仕様書案」を基にして「受入テスト仕様書」を作成する。
請負者は、環境省担当官が受入テストを実施するに当たり、環境整備、運用等の支援を行うこと。
請負者は、環境省担当官が受入テストを実施するに当たり、検証作業を実施するために必要な支援を行うこと。
請負者は、環境省担当官が「受入テスト計画書」を作成するに当たり、情報提供等の支援を行うこと。
受入テストの実施に当たり、必要に応じて本システムの運転スケジュール、環境設定、テストデータ等の変更を行うこと。
請負者は、受入テストにおいて、指摘等があった場合には、環境省担当官の指示に従い適切な是正措置を施すこと。
受入テストの実施に当たり、環境省からの質問に対する問合せ対応を行うこと。
受入テストで発生したすべての障害が解消されている、又は問題を特定した上で対応策について環境省担当官の承認を得ていること。
請負者は、受入テストの実施状況を取りまとめた「受入テスト結果報告書案」を作成し、環境省担当官に提示すること。
運用・保守
請負者は、要件定義書の「3.16 運用に関する事項」、「3.17 保守に関する事項」に従い、運用・保守を行うこと。また、システムリリース後にインシデント数が削減される等、効率的なシステム運用・保守に資するシステム改修案があれば提案すること。
(1) 運用業務
請負者は、運用業務について、可能な限りガバメントクラウド及び環境省GIS 統合基盤が提供するサービスを活用すること。
ア 中長期運用・保守計画の確定支援
請負者は、環境省担当官が「中長期運用・保守計画」を確定するに当たり、本システムの構成やライフサイクルを通じた運用業務の内容について、計画の妥当性の確認、情報提供等の支援を行うこと。なお、「中長期運用・保守計画」は令和 7 年
度から令和 10 年度までの運用・保守業務の計画を示したものとする。
イ 運用計画及び運用実施要領の作成
請負者は、定常時における日次、週次、月次、年次等の運用計画、実施要領等を
記載した「運用計画書」、「運用実施要領」を作成し、環境省担当官の承認を得ること。
また、運用状況の変化、各種イベントの発注等により、「運用計画書」の改定も実施すること。なお、「運用計画書」、「運用実施要領」の記載内容は標準ガイドライン「第 3 編第 9 章 運用及び保守」で定義されているものとする。
ウ 運用作業
請負者は、「別紙 1 要件定義書」の「3.16. 運用に関する事項」に定められた要件を実施すること。
(2) 保守業務
請負者は、保守業務について、可能な限りガバメントクラウド及び環境省GIS 統合基盤が提供する保守サービス等を活用すること。
ア 中長期運用・保守計画の確定支援
請負者は、環境省担当官が「中長期運用・保守計画」を確定するに当たり、本システムの構成やライフサイクルを通じた運用業務の内容について、計画の妥当性の確認、情報提供等の支援を行うこと。
イ 保守計画及び保守実施要領の作成
請負者は、定常時における日次、週次、月次、年次等の保守計画、作業要領等を記載した「保守計画書」、「保守実施要領」を作成し、環境省担当官の承認を得ること。
また、運用状況の変化、各種イベントの発注等により、「保守計画書」の改定も実施すること。
なお、「保守計画書」、「保守実施要領」の記載内容は標準ガイドライン「第 3 編第 9 章 運用及び保守」で定義されているものとする。
ウ 保守作業
請負者は、「別紙 1 要件定義書」の「3.17.保守に関する事項」に定められた要件を実施すること。
エ 撤去
請負者は、本業務に係るサービスが終了する際には、環境省担当官の求めに応じて本システムで保持するデータを抽出すること。その際のデータの提供時期、データ形式等の詳細については、環境省担当官との協議により決定すること。移行用データの抽出に必要な機器・媒体は請負者の負担で準備することとし、汎用的な媒体
（ハードディスク等）を使用すること。
請負者は、文書、メディア、システムディスク等、情報が記録された物品の撤去が必要となる場合、「行政機関の保有する個人情報の保護に関する法律（平成 15 年
法律第 58 号）」、「政府機関の情報セキュリティ対策のための統一基準（内閣サイバーセキュリティセンター）」等に則り、適切な措置を講ずること。
請負者は、本業務で導入する機器等一式の撤去作業を行うこと。
請負者は、機器等の撤去が必要となる場合、撤去する機器等に備わる記憶媒体の全てについて、データを復元できないように、抹消すること。
請負者は、データの抹消後、結果を環境省担当官へ報告すること。
引継ぎ
請負者は、「別紙 1 要件定義書」の「3.14. 引継ぎに関する事項」の定めに沿って、引継ぎを実施すること。
教育
請負者は、「別紙 1 要件定義書」の「3.15. 教育に関する事項」の定めに沿って、教育を実施すること。
定例会等の実施
(1) 請負者は、定例会を隔週開催するとともに、業務の進捗状況を設計・開発実施要領に基づき報告すること。なお、開催頻度は環境省担当官と協議を行い、決定すること。
(2) 環境省担当官から要請があった場合、又は、請負者が必要と判断した場合、必要資料を作成の上、定例会とは別に会議を開催すること。
(3) 定例会の実施方式は原則オンラインでの開催を想定しているが、環境省担当官と協議を行い決定すること。ただし、環境省担当官から要請があった場合、又は、請負者が必要と判断した場合は対面での開催とすること。
(4) 請負者は、会議終了後、3 日以内（行政機関の休日（行政機関の休日に関する法律
（昭和 63 年法律第 91 号）第１条第１項各号に掲げる日をいう。）を除く。）に議事録を作成し、環境省担当官の承認を受けること。
管理するデータの基本事項
(1) 本業務にて取り扱うデータについては、環境省担当官の許可なく追加、変更、削除、公開しないこと。
(2) 本業務にて取り扱うデータについては、個人、国、地方公共団体、その他の法人等を問わず、環境省担当官が管理する ID 等を付与された者が、その権限の範囲で利用可能とする。
(3) 請負者は、上記(1)(2)における条件を満たすシステム構成において設計・開発、保守・運用を行うこと。
最終報告書の作成
請負者は、以下の内容を含む最終報告書を作成し、環境省担当官の承認を得ること。本調達又は工程の概要
スコープ目標、スコープの評価に利用される基準、完了基準が満たされていることの証拠
品質目標、本調達や成果物の品質評価に利用される基準、成果物の品質評価結果実際のマイルストーン通過日、予実に乖離がある場合の理由
サービス提供状況、成果物の評価を踏まえた本調達に対する事業者総評
成果物について
(1) 成果物一覧
本調達の成果物を以下に示す。なお、成果物の内容、納品期日等については、「設計・開発実施計画書」作成時に環境省担当官と協議の上、決定すること。
表 4-1 成果物一覧
項番 | 成果物名 | 納入期限（想定） | 納入期日 |
1 | 設計・開発実施計画書 | 契約締結後２週間以内 | 令和 7 年 3 月 31 日 |
2 | 設計・開発実施要領 | ||
3 | 設計・開発実施要領に基づく管理資料 | ||
4 | 要件定義書（確定版） | 要件定義確定後 | |
5 | ノンプログラミングによる画面生成等プロトタイピング用のツール等を利用する場合、設計書やソースコード一式の生成等に利用される設定 情報その他の必要な情報一式 | 設計開発の状況に応じて順次 | |
6 | 外部サービスを利用する場合、当該サービスに 係る設定情報その他の必要な情報一式 | ||
7 | 動作確認テスト項目表 | ||
8 | 持ち込み機器疎通確認項目表 | ||
9 | 環境定義書 | ||
10 | ソースコード一式 | ||
11 | 実行プログラム一式 | ||
12 | 機器、ソフトウェア等の一覧表 | ||
13 | 基本設計書一式 | 設計完了時 | |
14 | 詳細設計書一式 | ||
15 | サービスレベル合意書 | ||
16 | 運用計画書案 | ||
17 | 運用実施要領案(各種管理台帳を含む。) | ||
18 | 保守計画書案 | ||
19 | 保守実施要領案(各種管理台帳を含む。) | ||
20 | 標準コーディング規約 | 開発開始前 | |
21 | セキュアコーディング規約 | ||
22 | 開発環境構築手順書 | ||
23 | テスト全体計画書 | 単体テスト実施前 | |
24 | 単体テスト計画書 | ||
25 | 単体テスト仕様書 |
項番 | 成果物名 | 納入期限（想定） | 納入期日 |
26 | 単体テスト結果報告書 | 単体テスト実施後 | |
27 | テストデータ・テストツール・テストエビデン ス等（単体テスト） | ||
28 | 結合テスト計画書 | 結合テスト実施前 | |
29 | 結合テスト仕様書 | ||
30 | 結合テスト結果報告書 | 結合テスト実施後 | |
31 | テストデータ・テストツール・テストエビデン ス等（結合テスト） | ||
32 | 総合テスト計画書 | 総合テスト実施前 | |
33 | 総合テスト仕様書 | ||
34 | 総合テスト結果報告書 | 総合テスト実施後 | |
35 | 脆弱性検査結果報告書 | ||
36 | テストデータ・テストツール・テストエビデン ス等（総合テスト） | ||
37 | 受入テスト計画書案 | 受入テスト実施前 | |
38 | 受入テスト仕様書案 | ||
39 | 受入テスト説明資料 | ||
40 | 受入テスト結果報告書案 | 受入テスト実施後 | |
41 | 引継ぎ計画書 | 引継ぎ実施前 | |
42 | 引継ぎ結果報告書 | 引継ぎ実施後 | |
43 | 教育訓練実施計画書 | 教育実施１か月前 | |
44 | 教育訓練実施結果報告書 | ||
45 | ガイダンス資料 | ||
46 | 環境省職員等利用者向け操作マニュアル | ||
47 | 自然共生サイトの所有・活動を行う主体向け操 作マニュアル | ||
48 | 地方公共団体職員等利用者向け操作マニュアル | ||
49 | 国民等利用者向け操作マニュアル | ||
50 | 運用・保守マニュアル | ||
51 | 外部公開用インタフェース仕様書 | ||
52 | 中長期運用・保守計画 | 運用・保守開始１か月前 | |
53 | 運用計画書 | ||
54 | 運用実施要領(各種管理台帳を含む。) | ||
55 | 運用手順書 | ||
56 | 保守計画書 |
項番 | 成果物名 | 納入期限（想定） | 納入期日 |
57 | 保守実施要領(各種管理台帳を含む。) | ||
58 | 保守手順書 | ||
59 | 納品機器等一覧表 | ||
60 | ライセンス関連資料（ライセンス証書等） | ||
61 | リリース管理台帳 | ||
62 | リリース計画書 | ||
63 | 情報セキュリティ管理計画書 | ||
64 | プロジェクト管理資料一式（EVM進捗管理表、進捗状況表、EVM推移グラフ、進捗状況分析図 等） | 随時 | |
65 | ライセンス関連資料（販売終了、サポート終了 等について記載する） | ||
66 | 障害報告書 | ||
67 | 大規模災害等対応訓練完了報告書 | ||
68 | 情報漏洩等対応訓練完了報告書 | ||
69 | 引継ぎ資料 | 契約満了前 | |
70 | 最終報告書 | ||
71 | 運用作業報告書（月次） | 運用・保守開始翌月の月初 | 各年度の最終日 |
72 | 保守作業報告書（月次） | ||
73 | 運用改善対応 | ||
74 | 保守改善対応 | 定例会実施後３開庁 日以内 | |
75 | 中長期運用・保守計画 | 見直し実施後 | |
76 | 運用計画書 | ||
77 | 運用実施要領(各種管理台帳を含む。) | ||
78 | 保守計画書 | ||
79 | 保守実施要領(各種管理台帳を含む。) | ||
80 | 議事録 | 随時 | |
81 | 情報資産管理標準シート （契約金額の内訳） | 契約締結後 速やかに | |
82 | 情報資産管理標準シート （設計・開発に関する事項） | 設計・開発実施要領に おいて定める時期 | |
83 | 情報資産管理標準シート （運用・保守に関する事項） | 運用実施要領及び保守実施要領において 定める時期 |
※提示期限は目安であり進捗状況により別途環境省担当官と調整する
(2) 成果物の納品方法
成果物の納品方法は以下のとおり。
成果物は、全て日本語で作成すること。ただし、日本国においても、英字で表記されることが一般的な文言については、そのまま記載しても構わないものとする。用字・用語・記述符号の表記については、「公用文作成の考え方（令和 4 年 1 月 11日内閣官房長官通知）」を参考にすること。
情報処理に関する用語の表記については、日本産業規格（JIS）の規定を参考にすること。
成果物は電磁的記録媒体により作成し、環境省担当官から特別に示す場合を除き、原則 2 部を納品すること。
納品後、環境省担当官において改変が可能となるよう、Microsoft Office 形式や図表等の元データも併せて納品すること。
成果物の作成に当たって、特別なツールを利用する場合は、環境省担当官の承認を得ること。
成果物が外部に不正に利用されたり、納品過程において改ざんされたりすることのないよう、安全な納品方法を提案し、成果物の情報セキュリティの確保に留意すること。
電磁的記録媒体により納品する場合は、不正プログラム対策ソフトウェアによる確認を行うなどして、成果物に不正プログラムが混入することのないよう、適切に対処すること。なお、対策ソフトウェアに関する情報（対策ソフトウェア名称、定義パターンバージョン、確認年月日）を記載したラベルを貼り付けること。
請負者が保有する特許などを用いる場合には、成果物にその旨を明記すること。
(3) 納品場所
成果物の納品方法は以下のとおり。原則として、成果物は次の場所において引渡しを行うこと。ただし、環境省担当官が納品場所を別途指示する場合はこの限りではない。
〒100-8975
東京都千代田区霞が関 1－2－2 中央合同庁舎 5 号館環境省 自然環境局 自然環境計画課
情報資産管理標準シートの提出
請負者は、以下の情報を含む情報資産管理標準シートを提出すること。提出時期は「運用実施要領」及び「保守実施要領」にて定めること。
情報資産管理標準シートの様式や提出方法の変更が発生した場合は、環境省担当官と協議の上、対応を実施すること。
(1) 開発・運用に関する情報
開発
スマホアプリ名、スマホアプリ対応 OS、開発環境（IDE）、開発言語、開発ライブラリ
コミュニケーションツール、バグ追跡ツール、バージョン管理ツール、プロジェクト管理ツール
プロジェクト管理情報運用
個人利用者数、法人利用者数、サービス利用件数、ヘルプデスク問合せ件数 アクセス件数、利用省庁数、利用省庁
プラットフォーム
利用プラットフォーム(ガバメントクラウド、パブリッククラウド等) ネットワークアクセス、連携システム
利用 IaaS、利用 PaaS、利用リージョンソフトウェア
使用するソフトウェア一覧(以下のミドルウェア、ソフトウェアについては情報資産管理標準シートのカテゴリ分けを行うこと。)
‒ Web サーバ
‒ AP サーバ
‒ DBMS
‒ 統合運用管理
‒ バックアップソフトウェア
‒ CMS
‒ クライアント PC 資産管理ハードウェア
使用するハードウェア一覧(以下の項目を一覧に含めること。)
‒ ハードウェアベンダー名
‒ ハードウェア型番セキュリティ関連情報
利用回線、プロトコル及びポート番号、個人情報取扱件数、内部 CSIRT
SOC/ログ監視、クラウドファイヤーウォール、CASB、ネットワークセキュリティ
WAF、IPS/IDS、アンチマルウェア、EDR、実施状況、法人番号、直近実施日 固定パブリック IP、公開ドメイン、公開 E メール
(2) 契約情報
開発、運用
人件費については人件費単価ごとに工数を提示すること。再委託先がある場合は再委託先の法人番号と再委託金額を提示すること。
最大何次請負、再委託総額、累計契約額(前年度まで)、年度契約金額を提示すること。
その他
(1) グリーン購入法に定める特定調達品目については、以下 URL に掲載される令和５年２月「グリーン購入の調達者の手引き」による各特定調達品目の「判断の基準」を満たすこと。https://www.env.go.jp/content/000113502.pdf
(2) インターネット公開するシステムは環境省 GIS 統合基盤を除き、原則として政府系ドメイン(go.jp)を用いること。
5. 作業の実施体制・方法に関する事項
作業実施体制と役割
本業務の推進体制及び本業務請負者に求める作業実施体制は次の図及び表のとおりである。なお、請負者内の人員構成については想定であり、請負者決定後に協議の上、見直しを行う。また、請負者の情報セキュリティ対策の管理体制については、作業実施体制とは別に作成すること。
図 5-1 本業務の推進体制及び本業務受注者に求める作業実施体制
表 5-1 本業務における組織等と役割
項番 | 組織又は要員 | 役割 |
1 | PJMO | 生物多様性見える化システムの管理組織として、本業務の進捗等を 管理する。 |
2 | 生物多様性センター | 生物多様性見える化システムで使用するデータの提供者として必要 に応じて仕様確認への対応等を行う。 |
3 | 本業務請負者 | 本業務を実施する。 |
4 | 工程管理支援事業者 | PJMO を通じて、本システムの工程管理に係る支援を行う。 |
5 | PMO | ガバメントクラウド及び環境省 GIS 統合基盤に関する情報提供、質 疑応答対応等を行う。 |
６ | ガバメントクラウド 所管省庁 | ガバメントクラウドに関する情報提供、質疑応答対応等を行う。 |
７ | 環境省 GIS 統合基盤 運用・保守事業者 | 環境省 GIS 統合基盤に関する情報提供、質疑応答対応等を行う。 |
表 5-2 本業務請負者に求める作業実施体制の役割
組織等 | 本業務における役割 | |
遂行責任者 | 本業務全体を統括し、必要な意思決定を行う。また、各関連する組織・部門とのコミュニケーション窓口を担う。 原則として全ての進捗会議及び品質評価会議に出席する。 本業務の委託期間中は原則として変更を認めないものとする。 | |
業務担当者 | 業務を実施するグループ。グループ構成は以下を想定している。 | |
プロジェクトマネージ ャ | プロジェクト全体の管理にかかるマネージャ。 各工程チーム間の調整を図りプロジェクト全体を統括する。 | |
プロジェクトリーダ | プロジェクトマネージャの管理下でプロジェクトの推進を担い、各工程チーム における担当者の作業状況や品質等の管理を担う。 | |
設計・開発担当者 | 設計・開発を担う。 | |
テスト担当者 | テストを担う。 | |
移行担当者 | システム、データ等の移行を担う。 | |
運用・保守担当者 | 運用・保守を担う。 | |
品質管理者 | 本業務全体において所定の品質を確保するため、監視・管理を担う。 | |
情報セキュリティ責任 者 | 本プロジェクトの遂行に当たり、情報セキュリティ管理における請負者として の責任を持つ。 | |
個人情報取扱責任者 | 本プロジェクトの遂行に当たり、個人情報の取扱いにおける請負者としての責 任を持つ。 | |
作業要員に求める資格等の要件
本調達案件の作業要員に求める資格及び経験等の要件を以下に示す。
（1） 本業務の遂行責任者又はプロジェクトマネージャは、情報システムの設計・開発の責任者又はプロジェクトマネージャとしての経験を 5 年以上有すること。また、EVM
（Earned Value Management）又は同等の管理手法による進捗管理に係る業務を実施した実績を有すること。（発注者名、業務名称（非開示の場合にはその旨明記）、業務内容の概要、実施期間を記載した一覧表（任意様式）及び当該業務の契約書又は報告書の写し等を提示すること）
（2） 本業務のプロジェクトリーダは、本業務と同規模以上の情報システムの設計・開発又はシステム基盤導入の経験年数を 5 年以上有する者がいること。また、その中でプ
ロジェクトリーダは当該役職経験を 3 年以上有すること。（実績を有する者の所属・氏名、発注者名、業務名称（非開示の場合にはその旨明記）、業務内容の概要を記載した一覧表（任意様式）及び当該業務の契約書又は報告書写し等を提示すること）
（3） 本業務の実施体制において、設計・開発担当者のうち、情報システムの設計・開発等の情報処理業務の経験年数が 3 年以上の者又は同等の実績を有する者がいること。
また、ノーコード、ローコードを用いた情報システムの設計・開発等の情報処理業務の経験年数が 3 年以上の者又は同等の実績を有する者がいること。（実績を有する者の所属・氏名、発注者名、業務名称（非開示の場合にはその旨明記）、業務内容の概要を記載した一覧表（任意様式）及び当該業務の契約書又は報告書写し等を提示すること）
（4） 本業務の実施体制において、民間クラウドサービスに構築された政府情報システムの開発、運用・保守に係る業務を実施した実績を有する者がいること。（実績を有する者の所属・氏名、発注者名、業務名称（非開示の場合にはその旨明記）、業務内容の概要を記載した一覧表（任意様式）及び当該業務の契約書又は報告書写し等を提示すること）
（5） 本業務の実施体制において、ArcGIS を用いたシステムの開発、運用・保守に係る業務を実施した実績を有する者がいること。（実績を有する者の所属・氏名、発注者名、業務名称（非開示の場合にはその旨明記）、業務内容の概要を記載した一覧表（任意様式）及び当該業務の契約書又は報告書写し等を提示すること）
（6） 本業務の遂行責任者又はプロジェクトマネージャに、以下の資格のいずれかを有する者がいること（資格を有する者の所属・氏名（任意様式）及び保有資格に関する証明書類の写し等を提示すること）。又は、同等の能力を有することを証明できること。
IT コーディネータ
PMP（Project Management Professional）
公認情報システム監査人（CISA:Certified Information Systems Auditor）情報処理技術者試験の以下の区分のいずれか
‒ プロジェクトマネージャ
‒ システム監査技術者
‒ IT ストラテジスト
経済産業省の IT スキル標準（ITSS）に基づき、プロジェクトマネジメント職種、 IT アーキテクト職種、コンサルタント職種、IT スペシャリスト職種、アプリケーションスペシャリスト職種のいずれかでレベル 4 以上のプロジェクト管理能力を有する。
（7） 本業務の実施体制において、情報セキュリティに係る以下の資格のいずれかと同等以上の資格を有する者がいること（資格を有する者の所属・氏名（任意様式）及び保有資格に関する証明書類の写し等を提示すること）。又は、同等の情報セキュリティの能力を有することを証明できること。
情報処理技術者試験の以下の区分のいずれか
‒ 情報処理安全確保支援士
‒ システム監査技術者
公認情報システム監査人（CISA: Certified Information Systems Auditor） CISSP（Certified Information Systems Security Professional） CISM（Certified Information Security Manager）
（8） 本業務の実施体制において、採用するクラウドに応じて上級クラウド資格のいずれかと同等以上の資格を有する者がいること。（資格を有する者の所属・氏名（任意様式）及び保有資格に関する証明書類の写し等を提示すること）。又は、同等の能力を有
することを証明できること。
※上級クラウド資格とは、AWS であれば Solution Architect Professional が相当する
作業場所
本業務の作業場所及び作業に当たり必要となる設備、備品及び消耗品等については、請負者の責任において用意すること。また、必要に応じて環境省担当官が現地確認を実施することができるものとする。
(1) 業務の実施場所
ア 設計・開発業務
設計・開発、テスト等の作業場所は、請負者の責任において用意すること。その際は、「(2)諸設備、物品等資源」に示す要件をすべて満たすこと。また、必要に応じて担当職員が現地確認を実施することができるものとする。
イ 運用・保守業務
運用・保守業務の作業場所は、請負者の責任において用意すること。その際は、
「(2)諸設備、物品等資源」に示す要件をすべて満たすこと。また、必要に応じて担当職員が現地確認を実施することができるものとする。
(1) 諸設備、物品等資源
ア セキュリティポリシー
環境省情報セキュリティポリシー（第 11 版）※を遵守の上、環境省担当官の了承を得ること。
※ 環境省情報セキュリティポリシー（第 11 版） https://www.env.go.jp/other/gyosei-johoka/sec-policy/full.pdf
作業の管理に関する事項
(1) 請負者は、環境省担当官が承認した設計・開発計画書の作業体制、スケジュール、開発形態、開発手法、開発環境、開発ツール等に従い、記載された成果物を作成すること。また、設計・開発実施要領に従い、コミュニケーション管理、体制管理、作業管理、品質管理、リスク管理、課題管理、システム構成管理、変更管理、情報セキュリティ対策を行うこと。
(2) 環境省担当官とのコミュニケーションにあたり、ファイル共有については環境省担当官が指定するサービス（Proself 等）を活用すること。
6. 作業の実施に当たっての遵守事項
機密保持、資料の取扱い
本業務に係る情報セキュリティ要件を遵守すること。本業務に係る機密保持及び資料の取扱いに係る要件は次の通りである。
(1) 委託した業務以外の目的で利用しないこと。
(2) 業務上知り得た情報について第三者への開示や漏えいをしないこと。
(3) 作業場所から持出しを禁止すること。
(4) 情報セキュリティインシデントが発生する等、万一の事故があった場合に直ちに環境省担当官に報告すること。また、請負者の責に起因する事故であった場合は、損害に対する賠償等の責任を負うこと。
(5) 業務の履行中に受け取った情報の管理を実施し、業務終了後は返却又は抹消等を行い、復元不可能な状態にすること。
(6) 要件定義書の「2.5.データに関する事項 (2) データ一覧」で示されたデータ項目ごとの格付・取扱・アクセス制限を参照し、設計・開発時におけるデータ項目の追加・変更の際に機密性区分の格付を行うこと。また、格付ごとに適切な管理措置（例：アクセス制限、暗号化等）を講じること。
(7) 情報セキュリティ責任者は、情報取扱者を限定し情報セキュリティの管理体制を整備すること。
(8) 適切な措置が講じられていることを確認するため、履行状況の定期的な報告および必要に応じて環境省担当官による実地調査が実施できること。また、履行状況が不十分である場合は、環境省担当官と協議の上、改善策を実施すること。
政府機関等のサイバーセキュリティ対策のための統一基準
「政府機関等のサイバーセキュリティ対策のための統一基準」（令和 5 年 7 月 4 日サイバーセキュリティ戦略本部決定）に準拠して必要なセキュリティ対策を講じること（以下記載は、基本的な事項）。
(1) 不正アクセスの防止や万が一侵入された場合のログ等の証跡を蓄積するとともに、検知・通知を行えるようにすること。
(2) セキュリティパッチ等の適用を適宜正確かつ迅速に行うこと。
(3) 脆弱性が生じないよう留意して設計・開発し、リリース前及び定期的な検査を通じた確認により修正を適用できるようにすること。
(4) 不正行為の検知発生原因の特定に用いるために、システムの利用記録、例外的事象の発生に関するログを蓄積し、不正の検知、原因特定に有効な管理機能（ログの検索機能、ログの蓄積不能時の対処機能等）を備えること。
(5) ログの改ざんや削除を防止するため、ログに対するアクセス制御機能を備えるとともに、ログのアーカイブデータの保護（消失及び破壊や改ざん等の脅威の軽減）のための措置を含む設計とすること。
(6) 想定されるサプライチェーン・リスクを分析・評価し、それに対する軽減策を講じるにあたり、「外部委託等における情報セキュリティ上のサプライチェーン・リスク対応のための仕様書策定手引書（」平成 28 年 10 月 25 日内閣サイバーセキュリティセンター）を参照すること。
個人情報等の取扱い
(1) 生存する個人に関する情報であり、当該情報に含まれる氏名、生年月日その他の記述等により特定の個人を識別することができるもの（他の情報と容易に照合することができ、それにより特定の個人を識別することができることとなるものを含む。）は個人情報として取り扱うこと。
(2) 個人情報、個人関連情報、仮名加工情報及び行政機関等匿名加工情報（以下、個人情報等という。) の取扱いに係る事項について主管課と協議の上決定し、書面にて提出すること。なお、以下の事項を記載すること。
個人情報取扱責任者が情報セキュリティ責任者と異なる場合には、個人情報取扱責任者等の管理体制
個人情報等の管理状況の検査に関する事項（検査時期、検査項目、検査結果において問題があった場合の対応等）
(3) 本業務の遂行において、安全性や確実性を考慮し、仕様外の個人情報等を取得し、取り扱う必要性や有用性がある場合は、環境省担当官と協議してその妥当性を検討し、承認を得た上でこれを行うこと。また、環境省担当官と協議の上で当該個人情報等の利用目的と性質を考慮し、保持期間を定めること。当該保持期間が経過した後は、業務仕様にしたがって遅滞なく消去し又は匿名化すること。
(4) 本業務の遂行に際して個人情報等を取得し取り扱う場合、本業務のために定められた利用目的外の利用を厳に慎み、本業務のために供する個人情報等は他の個人情報等と分別して保管し、環境省担当官と協議のうえで書面により定めた環境下で所定の仕様に依拠して遂行すること。また、本業務を遂行する業務従事者にあってもこれを実効あらしめるものとするため、必要な管理監督および教育を行うこと。
(5) 個人情報等を本業務のために定められた利用目的外で複製する際には、事前に環境省担当官の許可を得ること。なお、複製の実施は必要最小限とし、複製が不要となり次第、その内容が絶対に復元できないように破棄・消去を実施すること。なお、請負者は廃棄作業が適切に行われた事を確認し、その保証をすること。
(6) 個人情報等の取扱いに際して、その本人によるデータの入力、本人による情報システムの利用に伴うデータの生成、その他本人による関与を通じてデータ処理が行われる場合には、その処理の記録（システム上のログによるもの等）を残すこと。
(7) 請負者が本業務のために取り扱う個人情報等に関して、利用者等から個人情報等の保護に関する法律その他適用ある法令上の請求が行われた場合には、速やかに環境省担当官に通知してその指示を受けること。また、環境省担当官による法令上の請求への対応のために必要な個人情報等の抽出、変更、削除その他合理的な協力を行い、これを可能とする体制および仕様を維持すること。
(8) 作業を派遣労働者に行わせる場合を含め直接雇用していない第三者の使用人等に業務従事させる場合には、本業務の一部を再委託する場合の手続きに準じて労働者派遣契約書に秘密保持義務など個人情報等の適正な取扱いに関する事項を明記し、作業実施前に教育を実施し、認識を徹底させること。なお、請負者はその旨を証明する書類を提出し、環境省担当官の承認を得た上で実施すること。
(9) 環境省担当官が必要と認めた場合であってその態様が請負者の業務その他の営業を著しく妨げるものでないとき、環境省担当官またはこれが指定した者による個人情報等の取扱いの状況および管理体制の監査を受け入れ、合理的に必要と認められる資料の提出を行うこと。
(10) 請負者は、本業務を履行する上で個人情報等（生存する個人に関する情報であって、当該情報に含まれる氏名、生年月日その他の記述等により特定の個人を識別することができるもの（他の情報と容易に照合することができ、それにより特定の個人を識別することができることとなるものを含む。）をいう。以下同じ。）の漏えい等安全確保の上で問題となる事案又はそのおそれのある事案を把握した場合には、直ちに被害の拡大を防止等のため必要な措置を講ずるとともに、環境省担当官に事案が発生した旨、被害状況、復旧等の措置及び本人への対応方針等について直ちに報告するこ と。
(11) 個人情報等の取扱いにおいて適正な取扱いが行われなかった場合は、本業務の契約解除の措置を受けるものとする。
(12) 個人情報の管理については、「環境省保有個人情報等管理規程」
（https://www.env.go.jp/johokokai/index.html）を順守すること。
法令等の遵守
請負者は、受注業務の実施において、民法、著作権法、不正アクセス行為の禁止等に関する法律等を遵守すること。
「国等による環境物品等の調達の推進等に関する法律（グリーン購入法）」（平成 15 年 7
月 16 日改正。平成 15 年法律第 119 号）第六条第 1 項の規定に基づき定められた環境物品
等の調達の推進に関する基本方針（平成 31 年 2 月 8 日変更閣議決定）別記に記載された対象機器については、各項目の【判断の基準】を満たすこと。【配慮事項】については対応していることが望ましい。
詳細は、環境省 HP に記載されている「環境物品等の調達の推進に関する基本方針」
（http://www.env.go.jp/policy/hozen/green/g-law/）を参照のこと。
標準ガイドライン等
本業務の遂行に当たっては、「標準ガイドライン」に基づき、作業を行うこと。具体的な作業内容及び手順等については、「デジタル・ガバメント推進標準ガイドライン解説書
（デジタル庁）」（以下、「解説書」という。）※を参考とすること。なお、「標準ガイドライン」及び「解説書」が改定された場合は、最新のものを参照し、その内容に従うこと。
※ 解説書
https://www.digital.go.jp/resources/standard_guidelines
その他文書、標準への準拠
本業務におけるその他文書、標準への準拠事項を以下に示す。
(1) アプリケーション・コンテンツの作成規程
ア 設計・開発業務提供するアプリケーション・コンテンツに不正プログラムを含めないこと。
イ 提供するアプリケーションに脆弱性を含めないこと。
ウ 実行プログラムの形式以外にコンテンツを提供する手段がない限り、実行プログラムの形式でコンテンツを提供しないこと。
エ 電子証明書を利用するなど、提供するアプリケーション・コンテンツの改ざん等がなく真正なものであることを確認できる手段がある場合には、それをアプリケーション・コンテンツの提供先に与えること。
オ 提供するアプリケーション・コンテンツの利用時に、脆弱性が存在するバージョンの OS やソフトウェア等の利用を強制するなどの情報セキュリティ水準を低下させる設定変更を、OS やソフトウェア等の利用者に要求することがないよう、アプリケーション・コンテンツの提供方式を定めて開発すること。
カ サービス利用に当たって必須ではない、サービス利用者その他の者に関する情報が本人の意思に反して第三者に提供されるなどの機能がアプリケーション・コンテンツに組み込まれることがないよう開発すること。
キ 国民等利用者が利用するサイトについては、「.go.jp」で終わるドメインを使用してアプリケーション・コンテンツを提供すること。
規定等の説明等
環境省情報セキュリティポリシーを遵守すること。なお、環境省情報セキュリティポリシーは、政府機関等の情報セキュリティ対策のための統一基準群（以下「統一基準群」という。）に準拠することとされていることから、請負者は、統一基準群の改定を踏まえて規則が改正された場合には、本業務に関する影響分析を行うこと。
情報システム監査
本業務における情報システム監査に関する事項を以下に示す。
(1) 本調達において整備又は管理を行う情報システムに伴うリスクとその対応状況を客観的に評価するために、環境省担当官が情報システム監査の実施を必要と判断した場合は、環境省担当官が定めた実施内容（監査内容、対象範囲、実施者等）に基づく情報システム監査を請負者は受け入れること。（契約後の委託事業開始前より実施される環境省担当官が別途選定した事業者による監査を含む。）
(2) 情報システム監査で問題点の指摘又は改善案の提示を受けた場合には、対応案を環境省担当官と協議し、指示された期間までに是正を図ること。
情報セキュリティの管理体制について
本業務における情報システムの監査体制に関する事項を以下に示す。
(1) 情報システムの設計・開発、運用、保守工程において、環境省担当官の意図しない変更や機密情報の窃取等が行われないことを保証する管理が、一貫した品質保証体制の下でなされていること。
(2) 環境省担当官の意図しない変更や機密情報の窃取等が行われないことを保証するため
の具体的な管理手順や品質保証体制を証明する書類（例えば、品質保証体制の責任者や各担当者がアクセス可能な範囲等を示した管理体制図）を環境省担当官との協議の上、必要と判断された場合は提出すること。また、第三者機関による品質保証体制を証明する書類等が提出可能な場合は、提出すること。
(3) 情報システムに環境省担当官の意図しない変更が行われるなどの不正が見つかったときに、追跡調査や立入検査等、環境省担当官と連携して原因を調査し、排除するための手順及び体制を整備していること。（例えば、運用・保守業務におけるシステムの操作ログや作業履歴等を記録し、発注元から要求された場合には提出させるようにする等）また、当該手順及び体制が妥当であることを証明するための書類を環境省担当官との協議の上、必要と判断された場合は提出すること。
(4) 情報システムの設計・開発等の各工程において、情報セキュリティに係るサプライチェーン・リスクを低減する対策が行われていること。
(5) セキュリティ関連のテストの実施結果が確認できること。脆弱性検査については、SaaS型 GIS、及び GIS パッケージ製品を用いず、個別開発を行ったプログラムに関しては実施すること。なお、脆弱性検査は、「デジタル庁 政府情報システムにおける脆弱性診断ガイドライン」の実施基準を満たすように脆弱性診断実施事業者の選定、脆弱性診断の実施、検出された脆弱性への対応を行うこと。
(6) 情報システムの開発環境、本番環境、検証環境を分離し、各環境で取扱う情報の機微性等に応じてアクセス制御等必要なセキュリティ対策を実施すること
(7) 政府情報システムにおいて含有されやすいセキュリティ上の問題点を下表に示す。各項目に対して漏れなく対応すること。
表 6-1 政府情報システムにおいて含有されやすいセキュリティ上の問題点
項番 | 要因 | セキュリティ上の問題点 | ||||||
1 | 認証管理不備 | 共用アカウントが使用される際に、利用者特定の仕組みや取扱いに関するルールが整備されていない 推測されやすい脆弱なパスワードが使用されている 認証情報がファイル等に平文で書かれている | ||||||
2 | アクセス制御不備 | 必要な強度の認証が行われていない ネットワーク、システムへのアクセス制限が実施されていない アクセス権が必要最小限のアクセス権付与が守られておらず、過剰である | ||||||
3 | 暗号化不備 | 重要情報が流れる各機器間の通信経路において、必要な暗号化が実施されていない | ||||||
4 | 資産管理、脆弱性管理不備 | 利用しているソフトウェアや機器の状態を把握していない（最新状態を維持できていない） OS やミドルウェア、ファームウェア等の脆弱性対策が適切に実施 されていない | ||||||
5 | Web アプリケーションの脆弱性 | SQL インジェクション、クロスサイトスクリプティング等の初歩的な Web アプリケーションの脆弱性が存在している パラメータ改ざんにより、本来アクセスできないデータを操作で きるなどの脆弱性が存在している | ||||||
6 | ログ管理不備 | ログ取得の範囲が目的に応じて定められていない（必要なログが取得されていない） 定期的なログの点検又は分析が実施されていない | ||||||
7 | 外部委託の管理不備 | 外部委託に係る契約に、遵守事項で定める委託先の情報セキュリティ対策が含まれていない 外部委託に係る契約に基づき、委託先における情報セキュリティ 対策の履行状況を確認していない | ||||||
セキュリティ要件
セキュリティ要件については、「別紙１ 要件定義書」の「3.10. 情報セキュリティに関する事項」に定められた要件を実施すること。
7. 成果物に関する事項
知的財産権の帰属
知的財産権の帰属については、契約書に記載の通りとする。
契約不適合責任
契約不適合責任については、契約書に記載の通りとする。
検収
(1) 本業務の請負者は、成果物等について、納品期日までに環境省担当官に内容の説明を実施し、検収を受けること。
(8) 検収の結果、成果物等に不備又は誤り等が見つかった場合には、直ちに必要な修正、改修、交換等を行うこと。また、変更点について環境省担当官に説明を行った上で、指定された日時までに再度納品すること。
8. 入札参加に関する事項
競争参加資格
本業務における競争参加資格に関する事項を以下に示す。
(1) 予算決算及び会計令第 70 条の規定に該当しない者であること。なお、未成年者、被保佐人又は被補助人であって、契約締結のために必要な同意を得ている者は、同条中、特別の理由がある場合に該当する。
(2) 令和 04・05・06 年度環境省競争参加資格（全省庁統一資格）「(3) 役務の提供等」の
「④情報処理」「⑥ソフトウェア開発」の「Ａ」、「Ｂ」「Ｃ」又は「Ｄ」の等級に格付けされ、競争参加資格を有する者であること。
公的な資格や認証等の取得
本業務における公的な資格や認証等の取得に関する事項を以下に示す。
(2) (1) 応札者は、以下の資格を全て有する者であること。
「JIS Q 9001（QMS）」又は「ISO9001」の公的機関による認証を取得している、又はこれと同等の品質マネジメントシステムを確立していること。
「JIS Q 27001」又は「ISO27001（ISMS）」の公的機関による認証を取得している、又はこれと同等の情報セキュリティマネジメントシステムを確立していること。
「JISQ15001」（個人情報保護マネジメントシステム）によりプライバシーマークの付与認定を受け、個人情報について適切な保護措置を講ずる体制を整備していること。又は、同等の個人情報について適切な保護措置を講ずる体制を整備していることを証明できること。
受注実績
本業務における受注実績に関する事項を以下に示す。
(1) 入札参加者は、本業務と同等規模以上の情報システムの開発を実施した実績を有する者であること（発注者名、業務名称（非開示の場合にはその旨明記）、業務内容の概要、実施期間を記載した一覧表（任意様式）及び当該業務の契約書又は報告書の写し等を提示すること）。
(2) 入札参加者は、以下のア若しくはイに該当する政府情報システムの開発、運用・保守に係る業務を実施した実績を有する者であること（発注者名、業務名称（非開示の場合にはその旨明記）、業務内容の概要、実施期間を記載した一覧表（任意様式）及び当該業務の契約書又は報告書の写し等を提示すること）。
ア 政府共通プラットフォームを利用する政府情報システムの開発、運用・保守に係る業務
イ 民間クラウドサービスに構築された政府情報システムの開発、運用・保守に係る業務
(3) 入札参加者は、ガバメントクラウド及び ArcGIS の保守実績を有することが望ましい。
ガバメントクラウド及びArcGIS の保守実績を有する場合、本システムの保守で必要となる適切な管理項目の件数等を提案し、環境省担当官と協議の上、保守計画書、保守実施要領にその内容を反映すること。
複数事業者による共同入札
(1) 複数の事業者が共同入札する場合、その中から全体の意思決定、運営管理等に責任を持つ共同入札の代表者を定めること。また、本代表者が本調達に対する入札を行うこと。
(2) 共同入札を構成する事業者間においては、その結成、運営等について協定を締結し、業 務の遂行に当たっては、代表者を中心に、各事業者が協力して行うこと。事業者間の調 整事項、トラブル等の発生に際しては、その当事者となる当該事業者間で解決すること。また、解散後の契約不適合責任に関しても協定の内容に含めること。
(3) 共同入札を構成する全ての事業者は、本入札への単独提案（総合評価の場合。単なる共同入札の場合は「単独参加」など）又は他の共同入札の参加を行っていないこと。
(4) 共同入札を構成する全ての事業者は、公的な資格や認証等の取得を除く全ての応札条件を満たすこと。
(5) 共同提案の代表者は、責任者及び主要担当者が所属する事業者に所属していること。
入札制限
本業務における入札制限に関する事項を以下に示す。
(1) 「令和４年度 OECM 情報システム（仮称）構築に向けた要件定義書作成等業務」及び
「令和５年度生物多様性見える化システム（仮称）構築に向けた要件定義書作成及び調達支援等業務」の受注事業者（再委託先等を含む。）及びこの事業者の「財務諸表等の用語、様式及び作成方法に関する規則」（昭和 38 年 11 月 27 日大蔵省令第 59 号）
第 8 条に規定する親会社及び子会社、同一の親会社を持つ会社並びに委託先事業者等の緊密な利害関係を有する事業者は、入札には参加できないものとする。
(2) 「令和 6 年度工程管理支援業務」の受注事業者（再委託先等を含む。）及びこの事業者の「財務諸表等の用語、様式及び作成方法に関する規則」（昭和 38 年 11 月 27 日大蔵省令第 59 号）第 8 条に規定する親会社及び子会社、同一の親会社を持つ会社並びに委託先事業者等の緊密な利害関係を有する事業者は、入札には参加できないものとする。
9. 再委託に関する事項
再委託の制限及び再委託を認める場合の条件
(1) 本業務の請負者は、業務を一括して又は主たる部分を再委託してはならない。
(2) 請負者における遂行責任者を再委託先事業者の社員や契約社員とすることはできない。
(3) 請負者は再委託先の行為について一切の責任を負うものとする。
(4) 再委託先における情報セキュリティの確保については請負者の責任とする。再委託さ
れることにより生ずる脅威に対して情報セキュリティが十分に確保されるよう、当該調達仕様書のセキュリティ対策にかかる措置の実施を再委託先に担保させること。また、再委託先のセキュリティの対策実施状況を確認できるよう、再委託先との契約内容に含めること。（再委託の相手方が更に委託を行うなど複数の段階で再委託が行われる
（以下「再々委託」という。）場合の取扱いも同様）
(5) 再委託を行う場合、再委託先が「8.5 入札制限」に該当しないこと。
(6) 請負者は、再委託先に対して十分な監査を行っていることを確認した証跡（監査証明書等）、もしくはそれに類する証跡を提示すること。
(7) 必要に応じて、再委託先の事業者に対して、環境省による実地調査あるいは直接の監査を受け入れること。
(8) 入札金額の 20%を超える再委託を予定する事業者がいる場合、当該再委託先事業者についても同様に「8.5 入札制限」に示す要件を満たすこと。
承認手続
本業務における承認手続に関する事項を以下に示す。
(1) 本業務の実施の一部を合理的な理由及び必要性により再委託する場合には、以下の内容を記載した「別紙 X 再委託承認申請書」を環境省担当官に提出し、あらかじめ承認を受けること。
再委託の相手方の商号又は名称、住所再委託を行う業務の範囲
再委託の必要性及び契約金額等
(2) 前項による再委託の相手方の変更等を行う必要が生じた場合も、前項と同様に再委託に関する書面を環境省担当官に提出し、承認を受けること。
(3) 再々委託には、当該再々委託の相手方の商号又は名称及び住所並びに再々委託を行う業務の範囲を書面で報告すること。
再委託先の契約違反等
再委託先において、本調達仕様書の遵守事項に定める事項に関する義務違反又は義務を怠った場合には、請負者が一切の責任を負う。また、環境省担当官は当該再委託先への再委託の中止を請求することができる。
10. 外部サービスの選定、利用に関するセキュリティ関連事項(要機密情報を取り扱う場合)
外部サービス全般の利用に関する共通セキュリティ要件
(1) 要機密情報を取り扱う外部サービスの利用に関しては、「政府機関等のサイバーセキュリティ対策のための統一基準 （令和５年度版）」の内容に遵守すること。
クラウドサービスの選定、利用に関するセキュリティ要件
(1) セキュリティ確保のため、本システムで用いるクラウドサービスは、原則として ISMAPクラウドサービスリストまたは ISMAP-LIU クラウドサービスリストに登録されているクラウドサービスを選定すること。なお、例外的に ISMAP クラウドサービスリスト、または ISMAP-LIU クラウドサービスリストに登録されていないクラウドサービスを選定する場合は、請負者の責任において、当該クラウドサービスが「ISMAP 管理基準」の管理策基準における統制目標（3 桁の番号で表現される項目）及び末尾に B が付された詳細管理策（4 桁の番号で表現される項目）と同等以上のセキュリティ水準を確保していることものを選定すること。
(4) (1)のセキュリティ要件に加えて、クラウドセキュリティ、データ保護に関する以下の要件を満たすようにクラウドサービスを選定し、利用すること。
「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」(以下、「クラウド方針」という。) を遵守すること。
情報資産を管理するデータセンタの設置場所に関しては、国内であることを基本とする。設置場所の考え方についてはクラウド方針を参照すること。
契約の解釈が日本法に基づくものであること。
クラウドサービスの利用契約に関連して生じる一切の紛争は、日本の地方裁判所を専属的合意管轄裁判所とするものであること。
環境省担当官の指示によらない限り、一切の情報資産について日本国外への持ち出しを行わないこと。情報資産を国外に設置されるクラウドサービスに保管する際の考え方についてはクラウド方針を参照すること。なお、利用者がアクセス可能な部分を除き、国外から情報資産へアクセスする場合も日本国外への持ち出しに該当する。
障害発生時に縮退運転を行う際にも、情報資産が日本国外のデータセンタに移管されないこと。
情報資産の所有権がクラウドサービス事業者に移管されるものではないこと。従って、環境省担当官が要求する任意の時点で情報資産を他の環境に移管させることができること。
(5) SaaS サービスの選定に関する参考事項
SaaS ベースで構築することを前提に検討し、SaaS では要件を満たさない場足は、 PaaS、IaaS などを選択すること。なお、本調達で構築するシステムでは、比較的短期間での機能の追加が求められることが想定されることから、簡易な操作で機能の追加が可能であること。
今後、利用者の拡大が見込まれることから、今後の発行アカウント数の拡大時の安定稼働や運用費用の抑制等の観点から、本調達の趣旨に適したクラウドサービスを利用すること。
11. その他特記事項
前提条件等
本業務における前提条件等に関する事項を以下に示す。
本業務受注後に調達仕様書（「別紙 1 要件定義書」を含む。）の内容の一部について変更
を行おうとする場合、その変更の内容、理由等を明記した書面をもって環境省担当官に申し入れを行うこと。双方の協議において、その変更内容が軽微（委託料、納期に影響を及ぼさない）かつ許容できると判断された場合は、変更の内容、理由等を明記した書面に双方が記名捺印することによって変更を確定する。
機器等のセキュリティ確保、リストの提出
原則として、クラウドサービスを活用すること。やむを得ず、システムで使用する機器やソフトウェア（ミドルウェア、ライブラリ）等を調達する際は、不正侵入の経路となるバックドアや脆弱性が含まれていないことを確認し、システム稼働中にメーカーサポートを受けられる安全なプロダクトを選定すること。
入札公告期間中の資料閲覧等
本業務の実施に参考となる過去の類似業務の報告書等に関する資料については、環境省内にて閲覧可能とする。なお、資料の閲覧に当たっては、必ず事前に環境省担当官まで連絡の上、閲覧日時を調整すること。
(1) 資料閲覧場所
東京都千代田区霞が関 1-2-2 中央合同庁舎５号館環境省 自然環境局 自然環境計画課
(2) 閲覧期間及び時間入札公告期間を予定
行政機関の休日を除く日の 10 時から 17 時まで（12 時から 13 時を除く。）
(3) 閲覧手続
閲覧者は最大 3 名までとする。応札希望者の商号、連絡先、閲覧希望者氏名を「別紙 X閲覧申請書（守秘義務に関する誓約書）」に記載の上、閲覧希望日の 3 日前（行政機関の
休日（行政機関の休日に関する法律（昭和 63 年法律第 91 号）第１条第１項各号に掲げる日をいう。）を除く。）までに提出すること。（「守秘義務に関する誓約書」については、閲覧日当日までに記載の上、提出すること。）
(4) 閲覧時の注意
閲覧にて知り得た内容については、提案書の作成以外には利用しないこと。また、本調達に関与しない者等に情報が漏えいしないように留意すること。(3)閲覧手続にて提出した資料閲覧申請書に準拠すること。
(5) 連絡先
環境省 自然環境局 自然環境計画課電話 03-5521-8274
(6) 事業者が閲覧できる資料一覧
閲覧に供する資料の例を次に示す。
令和４年度 OECM 情報システム（仮称）構築に向けた要件定義書作成等業務に関する報告書
令和５年度生物多様性見える化システム（仮称）構築に向けた要件定義書作成及び調達支援等業務に関する報告書
令和５年度環境省 GIS 統合基盤システムの構築・運用等業務に関する報告書いきものログ API に関する説明資料
見積り作成・提案依頼用ガバメントクラウド説明資料（政府情報システム編）
その他特記事項
本業務の履行に当たっては、障害を理由とする差別の解消の推進に関する法律（平成 25
年法律第 65 号）第９条第１項に基づく「内閣官房における障害を理由とする差別の解消
の推進に関する対応要領」（平成 27 年 11 月 16 日内閣総理大臣決定）第３条に規定する合理的配慮について留意すること。
その他
本仕様書について疑義等がある場合は、既定の質問書により質問すること。なお、質問書に対する回答は適宜行うこととする。
12. 附属文書
別紙 1 要件定義書
別紙 2 令和 6 年度から令和 10 年度までの生物多様性見える化システム設計・開発及び運用・保守業務に係る情報セキュリティ対策の実施方法等について
別紙 3 令和 6 年度から令和 10 年度までの生物多様性見える化システム設計・開発及び運用・保守業務で実施した情報セキュリティ対策について
別紙 4 令和 6 年度から令和 10 年度までの生物多様性見える化システム設計・開発及び運用・保守業務に係る運用要員について
別紙 5 令和 6 年度から令和 10 年度までの生物多様性見える化システム設計・開発及び運用・保守業務に係る再委託について
別紙 6 令和 6 年度から令和 10 年度までの生物多様性見える化システム設計・開発及び運用・保守業務に係る個人情報の管理について
別記様式 閲覧申込書
別記様式 守秘義務に関する誓約書
別添資料 1 想定業務一覧
別添資料 2 業務フロー
別添資料 3 機能・画面一覧
別添資料 4 帳票一覧
別添資料 5 ファイル一覧
別添資料 6 データ一覧
別添資料 7 外部インタフェース一覧
別添資料 8 自然共生サイト申請書様式１・２
（別添）
１．電子データの仕様
（１）Microsoft 社Windows10 以降で表示可能なものとする。
（２）使用するアプリケーションソフトについては、以下のとおりとする。
・文章：Microsoft 社 Word
・計算表：表計算ソフトMicrosoft 社 Excel
・画像：BMP 形式又は JPEG 形式
（ ３ ）（ １） による成果物に加え、「PDF ファイル形式」による成果物を作成すること。
（４）以上の成果物の格納媒体は DVD-R 等とする。事業年度及び事業名称等を収納ケース及び DVD-R 等に必ずラベルにより付記すること。
（５）文字ポイント等、統一的な事項に関しては環境省担当官の指示に従うこと。
２．その他
成果物納入後に受注者側の責めによる不備が発見された場合には、受注者は無償で速やかに必要な措置を講ずること。
（別紙２）
令和 年 月 日
環境省 自然環境局 自然環境計画課 情報システムセキュリティ責任者 殿
株式会社○○○○
代表取締役社長 ○○ ○○
令和６年度から令和 10 年度までの生物多様性見える化システム設計・開発及び運用・保守業務に係る情報セキュリティ対策の実施方法等について
令和６年度から令和 10 年度までの生物多様性見える化システム設計・開発及び運用・保守業務に係る情報セキュリティ対策とその実施方法及び管理体制について、下記のとおり届け出ます。
記
１．情報セキュリティ対策とその実施方法
環境省情報セキュリティポリシーを遵守し、情報セキュリティの確保のため別添の通り対策を実施する。
２．情報セキュリティの管理体制
情報セキュリティ管理責任者 | |||||
氏 | 名 | ||||
所 | 属 | 役 | 職 | ||
連絡先 | TEL： | E-mail： | |||
情報セキュリティ管理担当者 | |||
氏 名 | |||
所 属 | 役 職 | ||
連絡先 | TEL： E-mail： | ||
体制図
(1) 取り扱う環境省の情報の秘密保持等
【実施方法】
※仕様書の内容を確認し、実施方法を記述。以下の各項目も同様
(2) 情報セキュリティが侵害された場合の対処
【実施方法】
(3) 情報セキュリティ対策の履行状況の確認
【実施方法】
(4) 情報セキュリティ対策の履行が不十分であると思われる場合の対処
【実施方法】
(5) 再請負に関する事項
【実施方法】
（別紙３）
令和 年 月 日
環境省自然環境局自然環境計画課
情報システムセキュリティ責任者 殿
株式会社○○○○
代表取締役社長 ○○ ○○
令和６年度から令和 10 年度までの生物多様性見える化システム設計・開発及び運用・保守業務で実施した情報セキュリティ対策について
令和６年度から令和 10 年度までの生物多様性見える化システム設計・開発及び運用・保守業務で実施した情報セキュリティ対策を下記のとおり報告します。
記
情報セキュリティ対策の実施内容
(1) 体制
「令和 6 年度から令和 10 年度までの生物多様性見える化システム設計・開発及び運用・保守業務に係る情報セキュリティ対策の実施方法等について」により示した体制で、対策を実施した。
(2) 取り扱う環境省の情報の秘密保持等
「令和 6 年度から令和 10 年度までの生物多様性見える化システム設計・開発及び運用・保守業務に係る情報セキュリティ対策の実施方法等について」に従い、以下の各対策を実施した。
※以下の各項目についても個別対策について実施報告を記述願います。
(3) 情報セキュリティが侵害された場合の対処
(4) 情報セキュリティ対策の履行状況の確認
(5) 情報セキュリティ対策の履行が不十分であると思われる場合の対処
40
（別紙４）
令和 年 月 日
環境省 自然環境局 自然環境計画課 情報システムセキュリティ責任者 殿
株式会社○○○○
代表取締役社長 ○○ ○○
令和６年度から令和 10 年度までの生物多様性見える化システム設計・開発及び運用・保守業務に係る運用要員について
令和６年度から令和 10 年度までの生物多様性見える化システム設計・開発及び運用・保守業務の運用業務に従事する要員について、下記のとおり届け出ます。
記
運用業務管理責任者 | |||
氏 名 | 所 属 | ||
実績（経験年数、 資格）等 | 国 籍 | ||
氏 名 | 所 属 | ||
実績（経験年数、 資格）等 | 国 籍 |
氏 名 | 所 属 | ||
実績（経験年数、 資格）等 | 国 籍 |
氏 名 | 所 属 | ||
実績（経験年数、 資格）等 | 国 籍 |
（別紙５）
令和 年 月 日
環境省 自然環境局 自然環境計画課 情報システムセキュリティ責任者 殿
株式会社○○○○
代表取締役社長 ○○ ○○
令和６年度から令和 10 年度までの生物多様性見える化システム設計・開発及び運用・
保守業務に係る再委託について
令和６年度から令和 10 年度までの生物多様性見える化システム設計・開発及び運用・保守業務に係る再委託につき、下記のとおり届け出ます。
記
１．再委託先事業者名：
２．運用に係る要員（再委託先）
氏 名 | 所 属 | ||
専門性（資格）、 実績等 | 国 籍 |
氏 名 | 所 属 | ||
専門性（資格）、 実績等 | 国 籍 |
氏 名 | 所 属 | ||
専門性（資格）、 実績等 | 国 籍 |
氏 名 | 所 属 | ||
専門性（資格）、 実績等 | 国 籍 |
（別紙６）
令和 年 月 日
支出負担行為担当官
環境省 大臣官房 会計課長 殿
株式会社○○○○
代表取締役社長 ○○ ○○
令和６年度から令和 10 年度までの生物多様性見える化システム設計・開発及び運用
・保守業務に係る個人情報の管理について
令和６年度から令和 10 年度までの生物多様性見える化システム設計・開発及び運用・保守業務に係る個人情報の管理の状況等について、下記のとおり届け出ます。
記
１．個人情報の適切な管理のための措置
環境省保有個人情報等管理規程を遵守し、個人情報の適切な管理のための措置を別添の通り実施します。
２．管理体制及び実施体制
43
※個人情報の取扱いに係る業務を再委託する場合は体制図にその旨明記してください。
個人情報管理責任者 | |||||
氏 | 名 | ||||
所 | 属 | 役 | 職 | ||
連絡先 | TEL： | E-mail： | |||
個人情報管理担当者 | |||
氏 名 | |||
所 属 | 役 職 | ||
連絡先 | TEL： E-mail： | ||
体制図
３．検査
本業務において取り扱う個人情報の管理体制及び実施体制や個人情報の管理の状況について、環境省担当官による実地検査等が実施される場合には、適切に対応いたします。
なお、本業務における個人情報を取り扱う業務の実施計画は以下のとおりです。
＜実施計画＞
※環境省担当官が実地検査等の実施時期を検討するにあたり参考となるよう、業務スケジュールを記載してください。
４．個人情報に係る不適正管理事案発生時の対応
以上
（別記様式）
令和 年 月 日
環境省自然環境局自然環境計画課長 殿
住所 会社名
代表者氏名
閲覧申込書
株式会社○○（以下「甲」という）は、令和６年度から令和 10 年度までの生物多様性見える化システム設計・開発及び運用・保守業務の調達に係る入札への参加にあたり、環境省
（以下「乙」という。）から開示される「令和４年度 OECM 情報システム（仮称）構築に向けた要件定義書作成等業務に関する報告書」及び「令和５年度生物多様性見える化システム
（仮称）構築に向けた要件定義書作成及び調達支援等業務に関する報告書」について、当該入札の参考情報とすることを目的として、閲覧を申し込みいたします。
記
1. 応札希望者商号
2. 閲覧希望者氏名
3. 閲覧希望方法 ①図書閲覧 ②デジタルでの提供
以上
担当者等連絡先部 署 名： 責任者名：
担当者名： Ｔ Ｅ Ｌ：
E - m a i l：
（別記様式）
令和 年 月 日
環境省 自然環境局 自然環境計画課長 殿
住所 会社名
代表者氏名
守秘義務に関する誓約書
株式会社○○（以下「甲」という）は、令和６年度から令和 10 年度までの生物多様性見える化システム設計・開発及び運用・保守業務の調達に係る入札への参加にあたり、環境省
（以下「乙」という。）から開示される「令和４年度 OECM 情報システム（仮称）構築に向けた要件定義書作成等業務に関する報告書」及び「令和５年度生物多様性見える化システム
（仮称）構築に向けた要件定義書作成及び調達支援等業務に関する報告書」については、当該入札の参考情報とすることを目的（以下「本件目的」という。）として使用し、下記に定める条項を遵守することを誓約します
記
（秘密情報）
第１条 本誓約書でいう「秘密情報」とは、過年度の「令和４年度 OECM 情報システム（仮称）構築に向けた要件定義書作成等業務に関する報告書」及び「令和５年度生物多様性見える化システム（仮称）構築に向けた要件定義書作成及び調達支援等業務に関する報告書」に記載された情報をいう。
（機密保持）
第２条 甲は、秘密情報を厳格に保持するものとし、秘密情報を第三者に開示、漏洩しまたは公開しないものとする。
（目的外使用の禁止）
第３条 甲は、本件目的以外に秘密情報を使用しないものとし、デジタルの秘密情報の提供を受けた場合は使用後は速やかに消去する。なお、第三者に開示、漏洩が発覚した場合、乙は甲に本業務に係る入札及び本件に係る契約の解除措置を講ずる。
（協議）
第４条 本誓約書に定めのない事項、その他本誓約書の条項に関して疑義を生じたときは、甲乙協議の上円満に解決を図るものとする。
以上
担当者等連絡先部 署 名： 責任者名：
担当者名： Ｔ Ｅ Ｌ：
E - m a i l：
別紙 1
令和 6 年度から令和 10 年度までの生物多様性見える化システムの 設計・開発及び運用・保守等業務
要件定義書（案）
令和６年 ２月
環境省自然環境局 自然環境計画課
目次
0. 用語の定義 1
1. 業務要件定義 2
業務実施手順 2
業務の規模 6
業務実施の時期・時間 7
業務実施の場所等 9
業務観点で管理すべき指標 9
情報システム化の範囲 10
業務の継続の方針等 11
情報セキュリティ対策の方針等 11
2. 機能要件定義 12
機能に関する事項 12
画面に関する事項 14
帳票に関する事項 19
ファイルに関する事項 19
データに関する事項 19
外部インタフェースに関する事項 21
3. 非機能要件定義 21
ユーザビリティ及びアクセシビリティに関する事項 21
システム方式に関する事項 25
システム規模に関する事項 27
性能に関する事項 29
信頼性に関する事項 30
拡張性に関する事項 31
上位互換性に関する事項 32
中立性に関する事項 33
継続性に関する事項 33
情報セキュリティに関する事項 35
情報システム稼働環境に関する事項 40
テストに関する事項 43
移行に関する事項 50
引継ぎに関する事項 50
教育に関する事項 51
運用に関する事項 53
保守に関する事項 63
― 別添資料 ―
別添資料 1 想定業務一覧
別添資料 2 業務フロー
別添資料 3 機能・画面一覧
別添資料 4 帳票一覧
別添資料 5 ファイル一覧
別添資料 6 データ一覧
別添資料 7 外部インタフェース一覧
別添資料 8 自然共生サイト申請書様式１・２
0. 用語の定義
用語 | 意味 |
ネイチャーポジティブ | 2030 年までに生物多様性の損失を食い止め、反転させ、回復軌道に 乗せるという目標。 |
30by30 目標 | 2030 年までに陸と海の 30％以上を健全な生態系として効果的に保 全しようとする目標。 |
保護地域 | 自然公園や鳥獣保護区等、法律に基づき一定の開発・捕獲規制等な どの行為が制限されている地域。 |
OECM | Other Effective area-based Conservation Measures。保護地域以外の地理的に確定された地域で、付随する生態系の機能とサービ ス、適切な場合、文化的・精神的・社会経済的・その他地域関連の価値とともに、生物多様性の域内保全にとって肯定的な長期の成果 を継続する方法で統治・管理されているもの。 |
自然共生サイト | 「民間の取組等によって生物多様性の保全が図られている区域」と して国が認定した区域。 |
自然共生サイトデータベース（自然共生サイト DB） | 管理者や位置情報、モニタリングの状況といった、自然共生サイトの各種情報を格納するためのデータベース。データベースの情報 が、自然共生サイトの申請・管理及び生物多様性のマッピングに反 映される。 |
生物種 GIS データ | 特定の生物の生育・生息情報が、地理情報に紐づけられているデー タ。 |
生物多様性情報 | 保護地域や自然共生サイト等の生物多様性に資する「場」の情報 が、地理情報に紐づけられているデータ。例えば、自然環境保全地域データ、里地里山エリアデータ、自然共生サイトデータなどが該 当する。 |
生物多様性マップ | 生物種 GIS データ、生物多様性情報等を複数のデータ（レイヤー）を重ね合わせて表示し、本システムの利用者が閲覧するための地 図。 地図画面の目的に応じて、必要な機能を追加する。 例えば、本システムで実装を想定している、「図 2-4 地方公共団体 ごとの保全状況ダッシュボードの画面イメージ」や「図 2-5 自然共生サイトの情報掲載の画面イメージ」が該当する。 |
ダーウィンコア | 標本、観察データの標準交換形式であり、インターネットを通じて データ共用するために使用され、GBIF プロジェクトでも採用されて |
1
いる。いくつかのバージョンがあり、詳細は XML Schema で定義さ れている。（https://gbif.jp/datause/dataformat/） | |
伴走支援 | 保全活動や自然共生サイト申請の過程で、生物多様性の保全活動にかかる専門的な知識や経験を有する者が、サイトの所有者・管理者 等を支援すること。 |
保全活動ログ | サイトの所有者・管理者等が実施した、環境保全に資する活動を生 物多様性見える化システム上で記録したもの。 |
ア
1. 業務要件定義
業務実施手順
(1) 業務範囲
生物多様性見える化システム（以下「本システム」という。）が提供する業務の範囲を下表に示す。なお、各業務の詳細は「別添資料 1_想定業務一覧」及び「別添資料 2_業務フロー」を参照すること。
表 1-1 業務概要
No. | 業務名称 | 業務の概要 |
1 | システム準備 | 自然共生サイト申請に必要なドキュメント類を整備するとともに、各自然共生サイトの情報（サイト名、サイト管理者の氏名又は団体名称、位置情報、サイト面積、サイト概要、管理目的、アピールポイント、生物多様性の価値 [自然共生サイトの生物多様性の価値１～９]、環境価値[炭素固定量、水源涵養量、確認生物種数等]等）をデータベース化（自然共生サイト DB）する。さらに、生物多様性マップでの可視化対象のインプットとなるデータを収集する。将来的に、いきものログ等の外部システムからのデータ収集の際には API連携を活用する予定。 上記インプットデータを基に、生物多様性マップを作成・確認するとともに、システム内の情報（主に自然共生サイト認定区域の面積などを想定）を基に、 統計解析、集計情報を作成する。 |
2 | 認知 | 生物多様性情報を地図上で参照するとともに日本全国・都道府県・基礎自治体ごとの保護地域の面積・カバー率等を確認する 所在地/サイト区分/認定価値等による自然共生サイトの情報を検索するとともに、自然共生サイトで OECM に該当する認定区域を、国際 OECM データベー スに登録する。 |
3 | 自然共生サイト申請前準備（申請前の保全活動） | 自然共生サイトに申請しようとしている者が生物多様性マップ上で申請対象地の生物多様性情報（自然共生サイトに認定しうる生物多様性の価値を有しているか）を確認するとともに、申請時の添付書類である GIS データを作成する。保全計画を策定するために、生物多様性保全に係るガイドラインを検索後に、該当画面へ遷移する。 |
No. | 業務名称 | 業務の概要 |
4 | 自然共生サイト申請* | 自然共生サイト申請準備として、申請内容の作成やエビデンスの調査後に、 自然共生サイト認定を申請する。 |
5 | 審査* | 事務局が自然共生サイト申請内容に対する審査を行い、審査結果を登録し、申請者に結果を通知する。 申請者が審査結果を確認する。 |
6 | 自然共生サイト認定後の保全活動 | 認定された自然共生サイトの情報（No.1 参照）をデータベースに登録する。また、自然共生サイト申請に当たり提出した、若しくは修正した保全計画に基づき、保全活動を実施し、保全施策実施の結果をシステムに登録する。 |
7 | 保全促進 | 保全活動を促進するための機能に参照できるように掲示板を参照する。 自然共生サイト認定区域への支援を行うスポンサーの募集情報（自然共生サイトの所有・活動を行う主体のウェブサイトにおける募集ページのリンク）を登録し、自然共生サイトを支援したい人がスポンサー募集情報を確認する。スポンサーの審査、申請及び認定をする。 |
有効な支援証明書を検索する。 | ||
8 | システム管理 | 本システムを使用するユーザーを管理するとともに、ログインを管理する。システム利用者向けのお知らせやマスタテーブルを作成・編集・削除する。自然共生サイト DB のメンテナンス（情報の更新、修正、適宜連携等）を行う。掲示板等の情報を編集するとともに、ガイドラインの配置先 URL への接続を確認する。 システム利用者からの問合せを Web で受け付ける。 |
* No.4「自然共生サイト申請」、No.5「審査」及び No.7「保全促進」の一部は業務としては存在するものの、グレーアウトの業務は初期実装機能対象外であり、令和 7 年度以降に実装要否を検討予定
(2) 業務フロー
本システムが対象とする業務及び情報システム化の範囲を「別添資料 2 業務フロー」に示す。
(3) 業務の実施に必要な体制
本システム関連業務の実施に現段階で想定する体制について、以下に示す。
表 1-2 業務の実施体制
No | 実施体制 | 業務概要 |
1 | 環境省自然環境局自然環境計画課 | 本システムの統括、システム管理等を行う。 |
2 | 自然共生サイト認定事務局 | 自然共生サイト情報の登録、修正等を行う。 |
3 | 環境省生物多様性センター | 環境省のいきものログ等を主幹する部署であり、本システムに必要なデ ータの提供を行う。 |
4 | デジタル庁 | ガバメントクラウド等の政府共通基盤の開発、運用・保守等の業務を行 う。 |
5 | 環境省環境情報室 | ガバメントクラウドや環境省 GIS 統合基盤で利用する各種 ID 設定やヘルプ・トラブル時のエスカレーション等の運用・保守等の業務を行う。 |
6 | 本業務の請負者 | 本システムの設計・開発業務及び運用・保守業務を行う。 |
(4) 管理対象情報一覧
対象業務で管理すべき主な情報（主な管理対象情報）を以下に示す。
表 1-3 主な管理対象情報一覧
N o | 管理対象情報名 | 管理単位 | 主たる用途 | 主な属性 | 補足 |
1 | 自然共生サイト管理者情報 | 団体 ID | 自然共生サイトの所有若しくは活動を行う主体情 報を管理する | 団体 ID、団体名称等 | いきものログの 「団体マスタ」との連携を想定 |
2 | 自然共生サイト管理者の構成員情報 | 団体 ID、利用者 ID | 認定されている自然共生サイトの所有若しくは活動を行う主体の構成員情報（ユーザーID 等）を 管理する | 団体 ID、利用者ID | いきものログの 「団体所属ユーザーマスタ」との連携を想定 |
3 | 生物多様性 GISレイヤー | レイヤーID | 生物多様性情報を地図上に可視化するために必要なレイヤー | 保全上重要な場レイヤー （保護地域（国立公園、鳥獣保護区等）、生物多様性保全上重要な場（重要里地里山、特定植物群落等））及び生物情報レイヤー（自然環境保全基礎調査、モニタリングサイト 1000、いきものログ等） | |
4 | 自然共生サイト情報 | 接受番号 （モデル地域 ID） | 自然共生サイトの名前、位置、特徴等の基礎的なデータを持つ | サイト名、サイト管理者の氏名又は団体名称、位置情報、サイト面積、サイト概要、管理目的、アピールポイント、生物多様性の価値 （自然共生サイトの生物多様性の価値１～９）、環境価値（炭素固定量、水源涵養量、確認生物種数等）、保全活動及びモニタリング結果、支援証明書に関する情報等 | 以下の自然共生サイトの概要を参 照。 https://policies .env.go.jp/natur e/biodiversity/3 0by30alliance/ky ousei/nintei/ind ex.html いきものログの 「モデル地域管理マスタ」との連携を想定 |
5 | 保全活動ログ | 調査 ID | 自然共生サイトで実施された保全活動の情報を管理する | 調査 ID、調査名、接受番号 （モデル地域 ID）、調査年月日、活動人数、活動内 容、活動種別（外来種防 除、モニタリング、生息場創出等）、活動写真（jpegファイル）等 | いきものログの 「調査マスタ」との連携を想定 |
N o | 管理対象情報名 | 管理単位 | 主たる用途 | 主な属性 | 補足 |
6 | 生物等モニタリングデータ | 管理番号 （連番） | 画面より登録する写真ファイルを含む生物種 GISデータを格納する | 管理番号、調査 ID、利用者 ID、学名、和名、exif 緯 度、exif 経度、写真（jpegファイル）、その他天候等の環境情報等 | いきものログの 「報告生物情報」との連携を想定。画面より登録する写真ファイルは GIS データの各フィーチャ（レコード）にアタッチされる形で管理 |
(5) 入出力情報項目及び取扱量
本システムの入出力情報項目は「2.1 機能に関する事項」、「2.2 画面に関する事項」並びに
「2.5 データに関する事項」に示しているため、参照すること。また、取扱量を「1.2(2) 処理件数」に示す。なお、本システム並びに関連するシステムの利用範囲の拡大に伴い、データの範囲と種類、容量が拡大する可能性もあることを、あらかじめ留意すること。
表 1-4 主な入出力情報項目及び取扱量
項番 | 業務処理 | 入出力情報名 | 入出力情報概要 | 入出力の区分 | 主な入出力情報項目 | 取扱量* | 用途 | 取得元/提供元 |
1 | 自然共生サイト認定後の保全活動 | 自然共生サイト管理者等の情報 | 自然共生サイト管理者の情報 | 入力 | 団体 ID、団体名称等 | 年間約 200 件 | 保全活動管理 | 自然共生サイト認定事務局 |
2 | 自然共生サイト認定後の保全活動 | 自然共生サイト所有・活動を行う主体の構成員情報 | 自然共生サイト管理者の構成員情報 | 入力 | 団体 ID、利用者ID | 稼働初年度：約 1,800 人 最終年度：約 4,200 人 | 保全活動管理 | 自然共生サイト認定事務局 |
3 | 自然共生サイト認定後の保全活動 | 自然共生サイト情報 | 各自然共生サイトの基礎的なデータ | 入力 | サイト名、サイト管理者の氏名又は団体名称、位置情報、サイト面積、サイト概要、管理目的、アピールポイント、生物多様性の価値（自然共生サイトの生物多様性の価値１～ ９）、環境価値（炭素固定量、水源涵養量、確認生物種数 等）等 | 年間約 200 件 | 自然共生サイト情報の管理 | 自然共生サイト認定事務局 |
項番 | 業務処理 | 入出力情報名 | 入出力情報概要 | 入出力の区分 | 主な入出力情報項目 | 取扱量* | 用途 | 取得元/提供元 |
4 | 自然共生サイト認定後の保全活動 | 保全活動ログ | 自然共生サイトで実施された保全活動の情報 | 入力 | 調査 ID、調査名、接受番号（モデル地域 ID）、調査年月日、活動人数、活動内 容、活動種別（外来種防除、モニタリング、生息場創出 等）、活動写真 （jpeg ファイル）等 | 稼働初年度：約 14,400 件 最終年度：約 33,600 件 | 保全活動管理 | 自然共生サイト管理者 |
5 | 自然共生サイト認定後の保全活動 | 生物等モニタリングデータ | 画面より登録する写真ファイルを含む生物種 GIS データ | 入力 | 管理番号、調査 ID、利用者 ID、学名、和名、exif 緯度、exif経度、写真（jpeg ファイル）、その他天候等の環境情報等 | 稼働初年度：約 108,000 件 最終年度： 約 168,000 件 | 保全活動管理 | 自然共生サイトの所有・活動を行う主体 |
* 取扱量 1 件又は 1 人につき、入出力情報項目の全ての情報が紐づく。
業務の規模
本システムで実現する業務で想定される規模について、以下に示す。なお、本システムで実現する業務は、システム構築と合わせて令和７年度以降に新しく開始される予定である。以下の内容についても、本調達時点の想定に基づく値である点に留意すること。
(1) サービスの利用者数及び情報システムの利用者数
本サービス及び情報システムの利用者について、下表に示す。
表 1-3 サービスの利用者数及び情報システムの利用者数(想定)
利用者 | 主な利用拠点 | 主な利用時間帯 | 利用者数 |
事務局 | 本省 | 平日 8:00～20:00 | 約 10 人 |
自然共生サイト所有・活動を行う主体 | - | 24 時間 365 日 | 稼働初年度：約 1,000 人 （約 300 サイト） |
次年度以降増加：約 300 人/ | |||
年 | |||
（約 100 サイト） | |||
行政機関職員（中央省庁及び | 中央省庁、各 | 平日 8:00～20:00 | 約 2,000 人 |
地方公共団体職員） | 都道府県若し | ||
くは市区町村 | |||
の本庁及び地 | |||
方事務所 | |||
システム利用者（国民、研究 機関・研究者、自然共生サイト支援者など） | - | 24 時間 365 日 | 約 438,000 人／年 |
システム管理担当者 | 本省 | 平日 8:00～20:00 | 約 3 人 |
システム運用保守担当者 | 運用・保守拠 点 | 24 時間 365 日 | 約 3 人 |
(2) 処理件数
本システムを用いる主な業務の処理件数は下表のとおりである。
表 1-4 主な業務の処理件数
申請種別 | 処理件数 | |
令和４年度（試行） | 令和５年度 | |
認定自然共生サイト情報の登録 | 56 件 | 137 件 |
合計 | 56 件 | 137 件 |
業務実施の時期・時間
(1) 業務実施時期・期間
本システムの業務時間を以下に示す。業務は通年の業務となり、繁忙期が想定される場合に備え、システムの弾力性を持たせること。
表 1-5 業務の通常期、繁忙期
項番 | 実施時期・期間 | 補足 |
1 | 通年（4 月～3 月） | 環境省職員の主な利用時間帯：平日（土日、休祝日を除く） 9:30～18:15 （昼休み 12:00～13:00 除く） |
2 | 9～11 月（前期）、 2 月～3 月（後期） | 自然共生サイト認定後の新規自然共生サイト管理者等からの問合せ対応 ※令和５年度は前期と後期に分けて認定 |
(2) 業務の実施・提供時間ア サービス提供時間
本サービスは計画停止を除き、24 時間 365 日サービスを提供できること。
イ 運用時間
運用保守業者の運用時間は平日(土日及び祝日、年末年始を除く)の平日（土日、休祝日を除く）9:30～18:15（昼休み 12:00～13:00）とする。ただし、システムの監視は 24 時間 365 日行うこと。
夜間や休日におけるシステム障害時の連絡体制については、運用時間と同等の体制を維持することは求めないが、障害の重要性に応じた機動的な体制を提案すること。
ウ システム障害時の対応
システム障害時は復旧を優先し、一次対応を速やかに実施すること。障害の原因究明・恒久的対策は、原則としてシステム復旧後、翌開庁日の運用時間内にシステム保守として実施する。
(3) ヘルプデスク業務
ヘルプデスク業務における問合せ対応の受付時間を下表に示す。
表 1-6 ヘルプデスク業務の問合せ対応時間
項番 | 問い合わせ方法 | サポート対象者 | 受付時間 | 回答時間 | 補足 |
1 | メール | システム利用者 | 24 時間 365 日 | 開庁日 9:30～18:15 （昼休み 12:00 ～13:00 除く） | |
2 | Web フォーム | システム利用者 | 同上 | 同上 | 回答はメールにて実施する。回答メールの内容は委託者と協議して定めるテンプレート(標準ガイド別紙)を用いる。 |
業務実施の場所等
本システムの業務実施場所に関する要件について、以下に示す。
表 1-7 利用者の業務実施場所
場所名 | 実施体制 | 実施業務 | 所在地 |
本省 | 事務局、システム管理担当者 | システム準備、審査、システム管理 | 本省 |
任意 | 自然共生サイト管理者等 | 自然共生サイト認定後の保全活動 | 任意 |
中央省庁、各都道府県若しくは市区町村の本庁及び地方事務 所 | 行政機関職員（中央省庁及び地方公共団体職員） | 認知、自然共生サイト認定後の保全活動及び保全促進 | 中央省庁、各都道府県若しくは市区町村の本庁及び地方事務所 |
任意 | システム利用者（国民、研究機関・研究者、自然共生サイト支援者な ど） | 認知及び保全促進 | 任意 |
運用・保守拠点 | システム運用保守担当者 | システムの運用・保守業務 | 受注者の運用・保守拠点 |
業務観点で管理すべき指標
本サービスに係る達成度評価指標（KPI：Key Performance Indicator）を下表に示す。なお、本サービスの利用動向を踏まえ、必要に応じて更に KPI を追加または変更する場合がある。KPI の追加または変更により「3.16.運用に関する事項」に変更があった場合は、対応範囲を委託者と協議の上で決定、対応すること。
表 1-8 達成度評価指標（KPI：Key Performance Indicator）
指標の種類 | 指標名 | 計算式 | 単位 | 目標値 | 計測方法 | 計測周期 |
情報システム性能指標 | システム稼働率 | 毎月の実稼動時間 ／毎月の予定稼動時間×100 | ％ | 99.9％以上 | 運用保守作業 報告 | 毎月 |
目標復旧地点（RPO） | - | - | 日次バックアップ時点 | 運用保守作業 報告 | 随時 | |
目標復旧時間（RTO） | - | - | 障害検知後 1 営業日以内 | 運用保守作業報告 | 随時 | |
目標復旧レベル （RLO） | - | - | 特定業務（主要な機 能）が実行可能な状態 | 運用保守作業報告 | 随時 | |
目標応答時間の達成率 | 毎月の目標応答時間達成件数／毎月の全応答件数×100 | ％ | 通常時：90.0％以上アクセス集中時：80%以上 | 運用保守作業報告 | 毎月 | |
インシデント発生件数 | - | 件 | 0 件 | 運用保守作業 報告 | 毎月 |
情報システム化の範囲
(1) 情報システム化の範囲
本調達の範囲は、下図の初期稼働時機能に該当する範囲である。
なお、本システムが提供する業務のシステム化を行う範囲の詳細は、「別添資料 1 想定業務一覧」を参照すること。
図 1-1 業務概要図(イメージ)
業務の継続の方針等
業務継続に関する目標復旧時間及び稼働率を以下に示す。
表 1-9 目標復旧時間
目標復旧時間 | 稼働率 | |
定常時 | 大規模災害等の発災時 | 定常時 |
1 営業日以内 | 1 週間以内 | 99.9%以上 |
情報セキュリティ対策の方針等
本システムの情報セキュリティ対策に係る具体的な要件は、「3.10 情報セキュリティに関する事項」を参照すること。
(1) 情報セキュリティ対策の基本的な考え方
表 1-10 システムで扱う情報の特徴
No. | 分類 | 情報資産種別 | 情報資産名 | 機密性※ 1 | 完全性※ 2 | 可用性※ 3 | 概要 |
1 | 業務 | 業務データ | GIS 関連情報 | 2 | 1 | 1 | 自然共生サイトや既存 |
資産 | の保護地域などの GIS | ||||||
関連データ | |||||||
2 | 生物関連情報 | 2 | 2 | 2 | いきものログ、自然環 | ||
（希少種に係 | 境保全基礎調査、モニ | ||||||
る情報を含 | タリングサイト 1000 な | ||||||
む） | ど外部システムから連 | ||||||
携された生物種に関連 | |||||||
するデータ | |||||||
3 | 自然共生サイ | 2 | 2 | 2 | 自然共生サイトの特徴 | ||
ト情報 | や管理内容に関するデ | ||||||
ータ | |||||||
4 | 活動ログ | 2 | 2 | 2 | 自然共生サイトの保全 | ||
活動に係るデータ | |||||||
5 | 生物種 GIS デ | 2 | 2 | 2 | 自然共生サイトで確認 | ||
ータ（写真フ | された生物種の GIS デ | ||||||
ァイルを含 | ータ、写真ファイル | ||||||
む） | |||||||
6 | 証跡データ | 監査情報 | 2 | 1 | 1 | アクセスログ |
No. | 分類 | 情報資産種別 | 情報資産名 | 機密性※ 1 | 完全性※ 2 | 可用性※ 3 | 概要 |
7 | バックアッ プデータ | バックアップ データ | 2 | 2 | 2 | 業務データのバックア ップデータ | |
8 | システム資産 | 設定情報 | 設定情報 | 2 | 1 | 1 | 各種装置の設定情報 |
9 | セキュリティ管理情報 | 共通管理情報 | 2 | 1 | 1 | ユーザー情報、システム管理情報 | |
1 | 利用者 ID（メールアドレ ス）／パスワード | 2 | 1 | 1 | 認証する際に利用する ID（メールアドレス） ／パスワード |
※1：機密性の格付けの区分は以下のとおり。
・機密性 3 情報：行政事務で取り扱う情報のうち、秘密文書に相当する機密性を要する情報
・機密性 2 情報：行政事務で取り扱う情報のうち、秘密文書に相当する機密性は要しないが、漏えいにより、国民の権利が侵害され又は行政事務の遂行に支障を及ぼすおそれがある情報
・機密性 1 情報：機密性 2 情報又は機密性 3 情報以外の情報
※2：完全性の格付けの区分は以下のとおり。
・完全性 2 情報：行政事務で取り扱う情報（書面を除く。）のうち、改ざん、誤びゅう又は破損により、国民の権利が侵害され又は行政事務の適確な遂行に支障（軽微なものを除く。）を及ぼすおそれがある情報
・完全性 1 情報：完全性 2 情報以外の情報（書面を除く。）
※3：可用性の格付けの区分は以下のとおり。
・可用性 2 情報：行政事務で取り扱う情報（書面を除く。）のうち、その滅失、紛失又は当該情報が利用不可能であることにより、国民の権利が侵害され又は行政事務の安定的な遂行に支障（軽微なものを除く。）を及ぼすおそれがある情報
・可用性 1 情報：完全性 2 情報以外の情報（書面を除く。）
2. 機能要件定義
機能に関する事項
本システムでは、ガバメントクラウド上に構築する「フロントサブシステム」と環境情報室が提供するパブリッククラウド（AWS）上に構築された環境省 GIS 統合基盤を利用する「地理情報サブシステム」の 2 つのサブシステムより構成される。
前者の「フロントサブシステム」は、機能の 1 つとして、自然共生サイトを管理する主体等
（以下、「自然共生サイト管理者等」という。）による、サイト内で確認された生物種の記録及び活動実施内容の報告を行うための入力画面を持つ。入力画面より登録された生物種 GIS データ及び写真ファイルは API を通じていきものログに登録する。なお、いきものログのユーザー認証は自然共生サイト管理者等がユーザーID 及びパスワードを画面より入力することで実施する。
また、当該自然共生サイト管理者等に限定して、当該サイト内の生物種の記録を参照できるよ
う、ログイン管理を行う。ログインしたユーザーの情報を「地理情報サブシステム」に条件として渡すことにより、当該自然共生サイト管理者等のみが当該サイト内の記録に限定して生物種の記録を参照できるようにする。
後者の「地理情報サブシステム」は生物多様性情報を地図上で表示する機能、日本全国・都道府県・基礎自治体ごとの保護地域等の面積・カバー率等の表示機能、生物種目録や自然共生サイトの情報検索・閲覧機能等を持つ。
なお、令和 6 年度に、図 2-1「機能構成概念図」で示す①システム準備、②認知、③申請前準備、⑥保全活動、⑦保全促進、⑧システム管理に該当する機能を初期実装する予定だが、システム設計から本稼働までの期間の不足等により一部機能を先行リリースするとなった場合は、①システム準備、②認知、⑧システム管理を先行リリースする。
(1) 機能一覧
本システムは、「別添資料 3 機能・画面一覧」等に示す要件を踏まえ、必要となる機能を有するものとする。
なお、「別添資料 3 機能・画面一覧」に示すもの以外に必要な機能等がある場合は、それも含めて追加の対象となる機能等の整理を行い、設計時に環境省と協議の上、本システムで実現すべき機能等の設計を決定すること。
請負者は、「別添資料 3 機能・画面一覧」を踏まえ、具体的な機能及びその実装の方法（機能の単位、画面構成・遷移等を含む。）等について、提案するシステム方式等に応じて適切なものを提案すること。その際には、現時点で広く使われている技術を前提として、ユーザビリティや開発効率性の観点から優れた方法を選択するよう留意すること。
(2) 機能構成概念図
本サービスの機能構成概念図を以下に示す。なお、図の記載内容が過度に複雑化することを避けるため、下図では業務分類に着目し、各機能と情報フローに焦点を当てて表現することとしている。
図 2-1 機能構成概念図
(3) 詳細業務フロー
業務フローについては下図を参照のこと。なお、初期実装時にはシステムを構築せず、令和 7 年度以降に実装要否を検討する機能に関する業務は該当箇所をグレーで表記している。
図 2-2 業務フロー(将来)の定義例
画面に関する事項
前述の「2.1 機能に関する事項」を実現するために必要な画面については、本システムの請負者の提案を踏まえ、設計時点で決定する。
画面レイアウト等の設計に当たっては、予めワイヤーフレーム（画面の完成イメージを線や枠で表現したもの）などを作成し、委託者の了承を得た上で設計を行うこと。
(1) 画面一覧
本システムは、「別添資料 3 機能・画面一覧」等に示す要件を踏まえ、必要となる画面を有するものとする。
なお、「別添資料 3 機能・画面一覧」に示すもの以外に必要な画面等がある場合は、それも含めて追加の対象となる画面等の整理を行い、設計時に環境省と協議の上、本システムで実現すべき画面等の設計を決定すること。
(2) 画面イメージ
本サービスの基本的・代表的な画面イメージを下図に示す。紙面スペースの制約上、一部を抜粋したものとしているが、全体像については、調達仕様書に基づく資料閲覧を行う際に確認する
ことが可能である。下記に代表的な画面のイメージを掲載する。
図 2-345 本システムのトップ画面のイメージ
図 2-467 地方公共団体ごとの保全状況ダッシュボードの画面イメージ
図 2-589 自然共生サイトの情報掲載の画面イメージ
図 2-6 活動ログ一覧・詳細画面及び生物種の GIS データの入力画面イメージ
(3) 画面遷移の基本的考え方
基本的・代表的な画面遷移として、トップ画面遷移図（抜粋）を以下に記載する。
図 2-101112 画面遷移図（抜粋）
(4) 画面設計ポリシー
画面設計における要件を以下に示す。
ア UX デザイン
UX デザインについては、以下の要件を満たすこと。加えて「3.1 ユーザビリティ及びアクセシビリティに関する事項」の要件も考慮すること。
本サービス想定利用者の目的を満足する観点から、本サービスを構成する機能、コンテンツの設計に当たっては、適切なユーザー調査によって利用者の要件を把握すること。本サービスに係る UX デザインは、UX に影響を及ぼす要素を 5 階層によって把握する UX5 階層モデルの考え方を導入する。本サービスの Web サイト及び Web アプリケーションについて、本サービスの目的を基底として、体系的かつ一貫性のある UX を確保できるようにすること。
イ 画面の表示
画面の表示に関して、利用者に正しく内容を伝達するために、以下の要件を満たすこと。
画面の表示には HTML を利用し、以下の Web ブラウザ上で正常に表示されることを確認すること。
PC(Mac OS/Windows) の場合：Microsoft Edge/Mozilla Firefox/Google Chrome/Safari の最新バージョン
Android の場合：Google Chrome の最新バージョン iOS の場合：Safari の最新バージョン
画面の表示に上記 Web ブラウザに追加でプラグイン等のインストールを必要としないこと。
上記 Web ブラウザのバージョンの更新があった際は、基本的には更新前のバージョンへの対応を保ちつつ、更新後のバージョンに対応させること。やむを得ず、双方のバージョンへの対応が困難な場合は、対応を優先するバージョンは委託者が判断を行うものとする。
利用者が他に起動している Web ブラウザの動作に干渉しないように配慮すること。
ウ 入力負荷の軽減
画面での入力操作は以下の要件を満たすこと。
画面での入力操作は、業務特性に応じて、入力負荷の軽減及び誤操作防止等に配慮すること。
日付を入力する項目については可能な限りカレンダーから日付を選択できること。
エ 誤操作の防止
利用者認証情報を取り扱う重要性を考慮し、誤操作によるデータの消失や誤った情報の登録等を防止する為、以下の要件を満たすこと。
Web ブラウザ自体が備えている「戻る」、「更新」等のボタンを押下しても、二重登録などの不具合が発生しないこと。
Web ブラウザで表示する画面内のボタンを連続で押下しても、二重登録などの不具合が発生しないこと。
検索処理中に再度の検索実行が行われないこと。（検索処理中は検索実行ボタンを非活性化する等）
オ メニュー
メニューについては、以下の要件を満たすこと。
各画面の上部に統一的な操作メニューを表示し、他の画面への遷移を可能とすること。現在の画面のメニュー体系における位置を階層的に表示し、他の画面への遷移を可能とすること。
帳票に関する事項
本システムは、「別添資料 4 帳票一覧」等を踏まえ、必要となる帳票を有するものとする。帳票は特別なレイアウトは想定せず、一般的な一覧を想定している。
なお、「別添資料 4 帳票一覧」等に示すもの以外に必要な帳票等がある場合は、それも含めて追加の対象となる帳票等の整理を行い、設計時に環境省と協議の上、本システムで実現すべき帳票等の設計を決定すること。
ファイルに関する事項
本システムは、「別添資料 5 ファイル一覧」等を踏まえ、必要となるファイルを有するものとする。
なお、「別添資料 5 ファイル一覧」等に示すもの以外に必要なファイル等がある場合は、それも含めて追加の対象となるファイル等の整理を行い、設計時に環境省と協議の上、本システムで実現すべきファイル等の設計を決定すること。
データに関する事項
本システムで管理する各種情報については、以下に示す情報・データを概念レベルでの基本とする。なお、情報・データの修正が必要になる場合や、関係する組織やシステム等とのデータ授受方法の詳細については、設計工程で委託者と協議の上で対応すること。
(1) データモデル
本システムでは主に GIS データを扱う。なお、生物種に関するデータはダーウィンコア
（https://gbif.jp/datause/dataformat/）に準拠してデータを格納すること。
それ以外に自然共生サイト情報や活動ログも扱うが、もっとも複雑になる生物種 GIS データに関連するデータモデルを下図に示す。本データはガバメントクラウド上で作成するフロントシステムでいきものログと同様の入力補助（名前の一部を入力すると関連する生物種のリストが表示される等）を持つ画面より写真データに含まれる位置情報を取得し、一時的にデータベースに保存するとともに、いきものログの API を利用していきものログにデータを連携すること。
図 2-13 データモデル（主要項目のみ表示）
(2) データ一覧
本システムは、「別添資料 6 データ一覧」等を踏まえ、必要となる情報・データを有するものとする。データ一覧については、委託者が定めるDS-400 政府相互運用性フレームワーク（GIF）をを十分に理解し、作業を進めること。
本システムで必要となるGIS データの種類は、「図 2-9 GIS レイヤー区分（概念図）」で示す通りである。本 GIS データの種類は「別添資料 6 データ一覧」の「GIS レイヤー区分」列に対応する。
図 2-14 GIS レイヤー区分（概念図）
なお、「別添資料 6 データ一覧」等に示すもの以外に必要なデータ等がある場合は、それも含めて追加の対象となるデータ等の整理を行い、設計時に環境省と協議の上、本システムで実現すべきデータ等の設計を決定すること。
また、他の情報システムとの連携やオープンデータとしての活用が行われることを想定したデータマネジメントを行うこと。
外部インタフェースに関する事項
本システムの外部インタフェースに関する要件を以下に示す。なお、一部のインタフェースは機能要件の変更に合わせて修正が必要になることが想定される。新たに追加となった機能への対応を含め、外部インタフェースの修正が必要になる場合については、設計工程で委託者と協議の上で対応すること。なお、インタフェースについては API 連携を原則とし、旧来型のインタフェースについては API 化を積極的に提案すること。
(1) 外部インタフェース一覧
本システムは、「別添資料 7 外部インタフェース一覧」等を踏まえ、必要となるインタフェース
を有するものとする。なお、「別添資料 7 外部インタフェース一覧」等に示すもの以外に必要なインタフェース等がある場合は、それも含めて追加の対象となるインタフェース等の整理を行い、設計時に環境省と協議の上、本システムで実現すべきインタフェース等の設計を決定すること。
3. 非機能要件定義
ユーザビリティ及びアクセシビリティに関する事項
(1) 情報システムの利用者の種類、特性
本システムの利用者の特性を踏まえ、ユーザビリティ及びアクセシビリティに関わる特性（情報システムへの習熟度、対象業務に対する専門性など）について整理した結果を以下に示す。
表 3-1 情報システムの利用者の種類、特性
No. | 利用者区分 | 利用者の種類 | 特性 |
1 | システム利用者 | 事務局 | ・ 業務に必要な業務知識を有する。 ・ 情報システムへの習熟度が高い人は限定される。 ・ システム利用時は、キーボード及びマウスでの 入力が可能な環境を有する。 |
2 | 自然共生サイト管理者等 | ・ 情報システムへの習熟度が高い人は限定される。 ・ システム利用時は、キーボード及びマウスでの 入力が可能な環境を有する。 | |
3 | 行政機関職員（中央省庁及び地方公共団体職員） | ・ 情報システムへの習熟度が高い人は限定される。 ・ システム利用時は、スマートフォン、キーボード 及びマウスでの入力が可能な環境を有する。 |
No. | 利用者区分 | 利用者の種類 | 特性 |
4 | システム利用者（国民、研究機関・研究者、自然共生サイト支援者など） | ・ 情報システムへの習熟度が高い人は限定される。 ・ システム利用時は、スマートフォン、キーボード 及びマウスでの入力が可能な環境を有する。 | |
5 | システム管理担当者 （環境省自然環境計画課の職員） | ・ 情報システムへの習熟度が高い人は限定される。 ・ システム利用時は、キーボード及びマウスでの 入力が可能な環境を有する。 | |
6 | システム運用・保守業務担当者 | システム運用保守担当者 | ・ 本システムの運用・保守業務に必要となる知識を有する。 ・ 情報システムへの習熟度は高い。 ・ システム利用時は、キーボード及びマウスでの入力が可能な環境を有する。 |
(2) ユーザビリティ要件
本システムで求めるユーザビリティ要件を以下に示す。
ユーザビリティ要件を満たさない画面とならざるを得ない場合は、設計時に環境省との協議の上、決定すること。また、利用者が想定する流れに沿った操作手順、画面遷移、画面レイアウト、帳票レイアウト等とする。
表 3-2 ユーザビリティ要件
項番 | ユーザビリティ分類 | ユーザビリティ要件 |
1 | 画面の構成（直感・シンプル） | 利用者が何をすればよいか直感的に理解できるデザインにすること。 無駄な情報、デザイン、機能を排したシンプルでわかりやすい画面にすること。 |
2 | 画面の構成（フォント及び文字サイズ） | 十分な視認性のあるフォント及び文字サイズを使用すること。画面サイズや位置を変更できること。 一度に膨大な情報を提示して利用者を圧倒しないようにすること。 |
3 | 画面の構成（マルチデバイス対応） | スマートフォン、タブレット端末により本サービスを利用する利用者を想定し、これら端末の特性を考慮した画面にすること。 レスポンシブデザインにより、PC、タブレット端末、スマートフォン等の利用環境を問わず、同一の情報をグリッドレイアウト等の適切なレイアウトにより表示できるようにすること。 ArcGIS の機能をベースに画面を構成することとし、専用のスマートフォンアプ リを別途開発しないこととする。 |
4 | 画面の構成 （表示/非表示） | 情報の優先順位をつけ、重要度の低い情報、特定の利用者層に対して提示する情報は、利用者が必要に応じて表示/非表示を切替え可能とする等の工夫をすること。 |
5 | 画面の構成 （クリックやチェックができる箇所） | 画面上でクリックやチェックができる箇所とできない箇所の区別を明確にすること。 タップ操作が可能なタブレット端末やスマートフォンの場合は、タップ操作の 結果（どの部分をタップしたのか）を適切にレスポンスできること。 |
項番 | ユーザビリティ分類 | ユーザビリティ要件 |
6 | 画面遷移 | 利用者が次の処理を想像しやすい画面遷移とすること。無駄な画面遷移を排除し、シンプルな操作とすること。 |
7 | 画面表示・操作の一 貫性（統一） | 機能、用語、レイアウト、操作方法は統一すること。 |
8 | 画面表示・操作の一貫性（視認性） | 必須入力項目と任意入力項目の表示方法を変えるなど各項目の重要度を利用者が認識できるようにすること。 見やすさを考慮し、画面のフォントサイズを決定すること。 画面ごとに異なるフォントを使わないこと。 |
9 | 操作方法のわかりやすさ（操作説明） | 原則としてマニュアルを参照しなくても操作できるようにすること。 |
10 | 操作方法のわかりやすさ | 無駄な手順を省き、使いやすく、利用者が効率的に作業できるようにすること。使いやすくする一例として、利用者がデータを入力する際に、操作手順をポップアップで表示すること等が挙げられる。 利用者が操作しやすい手順にするため、画面上の情報項目を上から下へ、左から右へ流れる順番に配置すること。 利用者の操作を軽減できるよう、画面の初期表示時、入力項目、選択項目等に 適切な既定値を設定すること |
11 | 操作方法のわかりやすさ（Tab キー） | Tab キー等による画面上のフォーカスの移動順序について、利用者が操作しやすい順序となるようにすること。 |
12 | 操作方法のわかりやすさ（画面遷移） | 利用者が同じ情報の入力や操作を何度も行う必要がないよう、画面が遷移しても情報がその後の手順に反映されるようにすること。 利用者の手間を軽減するため、利用者の手順に即した画面遷移に留意し、可能 な限り不要な画面遷移を行わないようにすること。 |
13 | 操作方法のわかりやすさ（マルチデバイス対応） | スマートフォン、タブレット端末等の狭い表示領域、タッチインタフェースでも効率的に作業できる操作性を実現すること。 |
14 | 指示や状態のわかりやすさ | ユーザーインタフェース及び UX に関する一般的に使われているデザイントレンドを取り入れ、アイコン・図表のグラフィック表現を適切に適用すること。 本サービスが処理している内容や状況を、利用者が把握できるようにすること。 |
15 | 指示や状態のわかりやすさ（外部ドメインへの遷移） | ドメインを異にする他の Web サイトへの遷移を行う際は、離脱メッセージを表示する等、利用者が認識できるようにすること。 |
16 | メッセージ出力 | 利用者に分かりやすいメッセージとすること。 必要に応じて、登録・変更・削除等の操作を行う場合には、確認画面等で表示し、利用者の注意を促すこと。 処理時間がかかる操作では、処理中であることが分かるようにすること。 |
17 | メッセージ出力 （次の操作） | 指示メッセージは、次操作が具体的にイメージできるようなメッセージ出力を行うこと。 |
18 | エラーの防止と処理 | 利用者が操作や入力を間違えないデザインや案内を提供すること。 |
19 | エラーの防止と処理 （エラー防止） | 利用者の誤操作を想定し、入力チェック機能によりエラーを防止すること。 入力値が選択できる場合には、プルダウンメニュー等を活用し、極力キーボード入力操作をなくすこと。 |
20 | エラーの防止と処理 （エラーメッセージ） | エラーメッセージは、その内容が分かりやすく表示されるとともに、利用者が何をすればよいかを示すこと。 |
21 | エラーの防止と処理 （エラー表示と解決策） | 入力内容の形式に問題がある項目については、利用者がその都度該当項目を容易に見つけることができるようにすること。 エラーが発生した時は、利用者が迷わずに問題解決できるよう、操作の続行に必要な選択肢を利用者が適切に理解できるようわかりやすく提示すること。 入力内容の形式に問題がある項目については、それを強調表示する等、利用者 がその都度その該当項目を容易に見つけられるようにする。 |
22 | エラーの防止と処理 （確認画面） | 必要に応じて、登録、更新、削除等の処理の前に確認画面を用意し、利用者が行った操作や入力のやり直し、取り消しがその都度できるようにすること。 |
項番 | ユーザビリティ分類 | ユーザビリティ要件 |
重要な処理については、事前に注意喚起し、利用者の確認を促すこと。 | ||
23 | エラーの防止と処理 （画面遷移） | 入出力の過誤があった場合、次の画面へ遷移しないこと。 |
24 | エラーの防止と処理 （情報保持） | タブレット端末等、屋外での使用を考慮し、電波受信状況の悪い場所においても操作不能とならないよう工夫すること。 |
25 | ヘルプ | 利用者が必要とする際に、ヘルプ情報やマニュアル等を容易に参照できるようにする。 ヘルプ情報やマニュアル等についても、利用者が必要な情報を容易に検索でき るようにする。 |
27 | デザイナーによる UI/UX 検討 | 本システムで開発する Web の UI/UX 検討に当たっては、利用者の利用動機に着目し、サービスデザイン思考の観点から検討を行うこと。 UI/UX 検討に当たっては、Web 等の経験を有する専門の UI/UX デザイナーを体 制に組み入れること。 |
28 | 画面遷移、操作ログ等の分析 | 運用・保守工程において継続的に UI/UX の改善を検討できるよう、利用者の画面遷移、操作ログ等を分析できる仕組みを整備すること。 |
29 | 言語対応 | 本情報システムでは、日本語のみとすること。 |
(3) アクセシビリティ要件
本システムで求めるアクセシビリティ要件を以下に示す。
アクセシビリティ要件を満たさない画面とならざるを得ない場合は、設計時に環境省との協議の上、決定すること。
表 3-3 アクセシビリティ要件
項番 | アクセシビリティ分類 | アクセシビリティ要件 |
1 | 基準等への準拠 | JIS X 8341-3:2016「高齢者・障害者等配慮設計指針－情報通信における機器，ソフトウェア及びサービス－第 3 部：Web コンテンツ」の適合レベル AA に準拠することを目標とする。また、レベル AAA のうち、以下の達成基準についても可能な範囲で適用すること。 2.1.3 キーボード（例外なし）の達成基準 2.3.2 3 回のせん（閃）光の達成基準 2.4.8 現在位置の達成基準 3.2.5 要求による状況の変化の達成基準 注記：本仕様書における「準拠」という表記は、情報通信アクセス協議会 Web アクセシビリティ基盤委員会「Web コンテンツの JIS X 8341-3:2016対応度表記ガイドライン 2021 年 4 月版」で定められた表記による。 また、スマートフォン等での操作を行うユーザーが増えていることを踏まえ「Web Content Accessibility Guidelines (WCAG) 2.1」で追加された達成基準についても、可能な範囲で適用すること。 1.3.4 表示の向き（レベルAA） 2.5.1 ポインタのジェスチャ（レベル A） 2.5.2 ポインタのキャンセル（レベル A） 2.5.4 動きによる起動（レベル A） 4.1.3 ステータスメッセージ（レベル AA） デジタル庁が整備する「ウェブアクセシビリティ導入ガイドブック」に準 |
項番 | アクセシビリティ分類 | アクセシビリティ要件 |
拠すること。 | ||
2 | 指示や状態の分かりやすさ | 色の違いを識別しにくい利用者（視覚障がいのかた等）を考慮し、利用者への情報伝達や操作指示を促す手段はメッセージを表示する等とし、可能な限り色のみで判断するようなものは用いないこと。ただし、業務の利用用途から、画面色での振り分けを行うことを予定していることから、適用範囲及び配色については委託者及び関係省庁と協議し、決定すること。 Web ブラウザ等の音声読み上げ機能を活用し、視覚障がいの方でも問題なく利用可能な UI とすること。 |
3 | マルチデバイス対応 | 解像度の低い機種、画面サイズの小さい機種でも、業務継続が可能な UI とすること。 OS の設定でフォントサイズ・表示サイズをそれぞれ最大とした場合でも、業務継続が可能な UI とすること。 スタイルシートを利用しないユーザーと利用するユーザーにおいて得られる情報に差（表示されない文字や画像がある等）がないこと。レイアウト においても大きな差がないことが望ましい。 |
システム方式に関する事項
(1) システム方式についての全体方針
システム方式についての全体方針を下表に示す。
なお、本システムを構成するサブシステムのうち、フロントシステムはガバメントクラウド上、GIS は環境省 GIS 統合基盤上に構築すること。
本システムはクラウドネイティブの構成として、「政府情報システムにおけるクラウドサービスの適切な利用に係る基本方針」に準拠し、クラウドサービスの提供機能を最大限活用するようデザインされたアーキテクチャとすること。特に、信頼性、拡張性（スケーラビリティ）、継続性等の向上に寄与するクラウドサービスと構成を選定すること。
項番 | 観点 | 全体方針 |
1 | システムアーキテクチャ | 本システムのシステムアーキテクチャはクラウドサービス上に用意される Web アプリケーションから構成される。Web アプリケーションは利用者の端末に追加的なソフトウェアのインストール等を行うことなく、一般に利用されている Web ブラウザで処理を行うものとする。 本システムや業務機能等の特性を十分に検討し、クラウドサービスプロバイダが提供するリファレンスアーキテクチャに準拠した形で PaaS、SaaS、IaaS 等の最適なサービスを採用し、システムを構築する。 クラウドサービスプロバイダが提供するマネージドサービスを最大限活用することを基本とし、アプリケーションプログラムの作り込みを削減できる設計とする。特にデータベース、認証、セキュリティ機能や運用管理機能はクラウドサービスが提供する機能を最大限活用すること。 クラウドサービスが責任共有モデルとして提供されている前提を踏まえ、クラウドサービスを利用するにあたって必要となる考慮事項について検討を行い、安全かつ効率的にシステムを構築する。 予防的統制と発見的統制を実施すること。また、クラウドサービスを利用するために作成する各種アカウントについては、ガバナンスやセ キュリティに係るポリシーを設定の上で、権限管理を確実に行うこ |
使用するIaaS/PaaS はガバメントクラウドを原則とし、SaaS についても積極的に活用すること。表 3-4 システム方式についての全体方針
項番 | 観点 | 全体方針 |
と。管理者アカウントについては、多要素認証を必須とすること。多要素認証はハードウェア方式を原則とするが、ソフトウェア方式も許容する。ハードウェア方式の場合は対応するワンタイムパスワード用のデバイスを利用システム側で調達すること。 リソース使用量の変動等に柔軟に対応するとともに、コスト削減を図るため、民間クラウドサービスの利用を原則とする。 全体構成及び利用するクラウドサービスについては、請負者において移行、引き継ぎ、確実なサービス提供等について問題が生じないことをクラウドサービスプロバイダに応札前に確認し、本調達の要件を踏 まえ、確認結果と合わせて適切なものを提案する。 | ||
2 | アプリケーションプログラムの設計方針 | マイクロサービスアーキテクチャ、API、クラウドネイティブ、クラウドサービスのマネージドサービスのみによる構成等、モダン技術を前提として構築する。 クライアントサーバ方式、専用端末のシンクライアント（VDI）等の旧来技術は、高コスト化の要因となるため採用しないこと。 原則としてバッチ処理を採用せず、リアルタイム処理を基本とすること。バッチ処理が必要となる場合は、その理由について委託者の承認を得た上で採用すること。 情報システムを構成する各コンポーネント（ソフトウェアの機能を特定単位で分割したまとまり）間の疎結合、再利用性の確保を基本とする。 システムが取り扱うデータの保管・管理に際して、データの容量、更新頻度、保存期間等を考慮し最適なストレージサービスを選定の上、利用する。またデータの保管・管理方針が変更となった際に、ストレ ージサービス間でのデータの移行が容易となるよう設計上考慮する。 |
3 | ソフトウェア製品の活用方針 | SaaS については、開発量削減の観点から幅広く優先的に、その利用を検討すること。ただし、ニーズにマッチしているか、開発量削減に貢献するか、セキュリティ対策は十分か、費用対効果は十分に得られるか等を慎重に考慮すること。 ソフトウェア製品については、広く市場に流通し、利用実績を十分に有するものを活用する。広く市場に流通し、利用実績を十分に有するソフトウェア製品を活用する。 アプリケーションプログラムの動作、性能等に支障を来たさない範囲において、可能な限りオープンソースソフトウェア（ＯＳＳ）製品（ソースコードが無償で公開され、改良や再配布を行うことが誰に対しても許可されているソフトウェア製品）の活用を図る。ただし、それらのＯＳＳ製品のサポートが確実に継続されていることを確認しなければならない。 ノンプログラミングによる画面生成等プロトタイピング用のツール等を利用することにより、システムライフサイクルコストの削減等が 見込める場合には、積極的に採用を検討する。 |
4 | システム基盤の方針 | 政府が提供するガバメントクラウド及び環境情報室が提供する環境省 GIS 統合基盤の利用を前提とする。 環境省 GIS 統合基盤は、ESRI ジャパン社が提供する「ArcGIS Managed Cloud Service」にて運用・管理される。そのため、当該基盤としての非機能要件は、ESRI ジャパン社が提供するサービスの仕様に準ずる。 クラウドサービスへのアクセスは環境省職員及び地方公共団体職員以外はインターネット接続回線経由を可能とするが、アクセス元制御及びポート番号制御を実施し、不特定のものがアクセスすることがないよう対策を講じること。 環境省を含む中央省庁職員は GSS ﴾Government Solution Service)、地方公共団体職員は LGWAN 経由でクラウドサービスへ |
項番 | 観点 | 全体方針 |
アクセスする前提とする。ただし、GSS は令和 7 年 6 月末の稼働予定であるため、それ以前は VPN 等の代替案を検討すること。 | ||
5 | Web ブラウザ対応方針 | 以下の Web ブラウザから利用可能とすること対応 Microsoft Edge Google Chrome Mozilla Firefox Safari Android の場合：Google Chrome の最新バージョン iOS の場合：Safari の最新バージョン |
6 | 情報セキュリティ対策の方針 | 本システムの情報セキュリティ対策は、アプリケーションプログラム及び情報資産をクラウドサービス環境上で構築することに伴い必要となる情報セキュリティ対策の強化を実施する。 |
(2) 開発方式
ア 開発にあたっては、継続的インテグレーション・継続的デリバリー（以下、「CI/CD」という。）を可能とし、必要な要素（リポジトリ、検証環境等）一式を用意すること。
イ 統合開発環境にはエディタ、コンパイラ、デバッガ、リポジトリ管理などプログラミング支援機能が含まれるが、さらにプロジェクト管理の効率化やソースコード品質向上を目的としたプロジェクト関係者間のコラボレーション促進機能等の提案も許容する。
ウ これらの開発環境については運用・保守事業者に引き継ぐことを想定し、可能な限りクラウド提供の CI/CD パイプラインもしくはマネージドサービス等と連携してクラウド環境に構築すること。なお、開発ツール等の組合せで実現した場合には、運用・保守事業者が該当ライセンス等を用意した上でそれらを引き継ぐことが可能であること。
エ UI 設計は UI 設計専用のアプリケーションを利用し随時共有すること。オ API 設計には Open API 設計用のツールを利用すること。
(3) 機器数及び設置場所
本システムはクラウドサービスを前提としているため、設置場所についてはクラウドサービスプロバイダの提供する場所となるが、その際は日本国内のリージョンを選択すること。
(4) その他
システム方式に係るその他の要件を以下に示す。
ア 本システムは短期間での機能追加・改善を行うことが想定されており、できるだけ簡潔なアーキテクトかつ簡易な構成とすること。なお、IaaS/PaaS については単一クラウドサービスでの構築を想定している。
システム規模に関する事項
本サービスの規模要件を以下に示す。また、本サービスの規模に関する業務要件は、「1.2 業務の規模」を参照のこと。
(1) 規模に関する前提条件
本システムはクラウドサービスを利用して運用されるため、以下の取り組みを行うこと。
ア 運用期間中において利用予定範囲を超過することがないよう、システムの縮退を検討するために必要となる情報収集等の仕組み（クラウドサービスの課金状況やリソースの利用量の監視、一定の閾値を超えた場合のアラート処理等）を設けること。定量的に計測したデータについては、ダッシュボード等による状況の可視化を行うこと。また、リソース利用状況に基づいたリソース見直しを行う点に留意し、情報収集の仕組みについても修正可能とすること。
イ クラウドサービスのマネージドサービスを効果的に活用し、コスト削減を継続的に図ること。原則としてサーバレスの構成を取ることとするが、インスタンスを利用してサーバを立てる場合は、サーバのスペック等を適切な範囲に調整してコスト削減を継続的に図ること。（オートスケールを利用する場合の変更条件・上下限値等を含む。）
ウ リソース確保の方式（リザーブドインスタンス、スポットインスタンス等）についても検討すること。
(2) データ量
本システムで想定されるデータ量を下表に示す。本データは GIS 統合基盤のデータ容量の制約があり、フロントサブシステム側に格納し、GIS 統合基盤より参照する方式を想定している。なお、年間データ増加量は仮定をおいた上での試算結果を記載しているため、設計等を考慮の上、必要なデータ量のサイジングを行うこと。
表 3-5 データ量（想定）
No. | データ区分 | データ量 （稼働初年度） | 年間増加量 | 年間増加率 | |
1 | 業務データ | GIS 関連情報（ベクターデータ を想定） | 22GB | 1GB | 5% |
2 | 生物関連情報（希少種に係る情報を含む） | 5.2GB | 0.26GB | 5% | |
3 | 自然共生サイト情報 | 61.5GB | 61.5GB | 100% | |
4 | 活動ログ | 1.2GB | 0.4GB | 33% | |
5 | 生物種 GIS データ（写真ファイ ルを含む） | 240GB*1 | 80GB | 33% | |
6 | 証跡データ | 監査情報 | 3.4GB*2 | 1GB | 33% |
7 | バックアップデータ | 340GB*3 | 0GB | 0% | |
8 | 設定情報 | 0.03GB | 0GB | 0% | |
9 | セキュリティ管理情報 | 共通管理情報 | 0.03GB | 0.00GB | 0% |
10 | 利用者 ID（メールアドレス）／パスワード | 0.03GB | 0.00GB | 0% | |
11 | PDF データ | 66GB | 22GB | 33% | |
No. | データ区分 | データ量 （稼働初年度） | 年間増加量 | 年間増加率 |
12 | プログラムソース | 1GB | 0.1GB | 10% |
合計 | 740.39GB | 166.26GB | 22% | |
*1 令和７年度末の認定自然共生サイト想定数 300 サイト×１画像ファイル 0.002GB×100 ファイル×年間 4 回で算出
*2 業務データの 10 分の 1 の容量を想定して、算出
*3 業務データのバックアップデータを取得することを想定して、算出（バックアップデータの世代管理はしない想定）
(3) 処理件数
ア 本システムの処理件数は、「1.2(2) 処理件数」を参照すること。
(4) 利用者数
本システムの利用者数は、「1.2(1) サービスの利用者数及び情報システムの利用者数」を参照すること。
(5) 保管データ量・保管期間
本サービスに保管するデータ量やデータの保管期間については、要件の整理の中で調査を行い、委託者と協議の上、決定すること。
性能に関する事項
本サービスの性能要件を以下に示す。下記の性能要件を踏まえて、本サービスの業務処理の特徴を考慮し、業務処理のピーク時においてもレスポンスの低下等を招かないように、十分な処理性能を確保すること。
(1) 性能を考慮する対象
以下のサブシステム・機能についての性能要件を満たすことを、本システムの性能要件とする。
フロントサブシステム地理情報サブシステム
ア 性能目標の設定対象
性能目標の設定対象は本システムの Web サーバにリクエストが到着した時点からレスポンスを返す時点までとする。ブラウザ、ネットワーク部分での処理時間に関しては、性能目標の設定対象外とする。
イ 性能見積もり
本サービスのアプリケーション処理時間に係る性能見積りは、以下を考慮する。
アプリケーション又はコードの起動に要する時間、アプリケーション又はコードの実行
時間、データベースアクセスに要する時間に要素分解を行った上で実施すること。各画面・機能等の利用者体験を踏まえた余裕を見込むこと。
(2) 応答時間
本システムの応答時間に係る指標と目標値を以下に示す。
なお、以下の応答時間による要件は、通常運用を想定した環境下で達成できることを要件とし、ネットワーク回線の障害等に起因する影響は目標値達成評価の算出に含めない。
表 3-6 目標レスポンスタイム
No. | 設定対象 | 指標名 | 目標値 | 目標値達成率※ |
1 | オンライン処理 | 応答時間 | 2.00 秒以内 | 80% |
2 | 画面遷移 | レスポンスタイム | 3 秒以内 | 90 パーセンタイル |
3 | 情報検索 | レスポンスタイム | 3 秒以内 | 90 パーセンタイル |
4 | 画面入力情報登録 | レスポンスタイム | 3 秒以内 | 90 パーセンタイル |
5 | 連携データ取込 | レスポンスタイム | 3 秒以内 | 90 パーセンタイル |
6 | 連携データ出力 | レスポンスタイム | 3 秒以内 | 90 パーセンタイル |
7 | 地図データ出力 | レスポンスタイム | 3 秒以内 | 90 パーセンタイル |
※目標値に示す時間内に応答が返ってくる割合
本処理の目標値は、プロトタイプの実績に基づき、「3.3 システム規模に関する事項」にて予想される最大負荷に対して 50%の余裕を考慮して算定したものである。処理の目標値は、連携するシステムやデータベース等の状況に影響を受けることを踏まえ、必要に応じて目標値の見直しを委託者へ提案すること。
(3) スループット
本システムのスループットに係る指標は申請手続き処理件数とし、目標値は、「1.2(2) 処理件数」を参照すること。
信頼性に関する事項
本サービスに備える機能の停止等による業務への影響を最低限にとどめるため、クラウドサービスの利用を前提として、以下に示す要件を踏まえ本サービスの信頼性を確保すること。
(1) 可用性要件
単一障害点（SPOF）を極力排除するとともに、サーキットブレーカーパターンなども検討し、一律ではなく機能又はセグメントの特性に応じた合理的な提案を示すこと。また、SPOF の発生が避けられない場合においてそれら稼働状況を管理する仕組みを準備すること。
ア 可用性に係る目標値
可用性に係る目標値を下表に示す。
表 3-7 可用性に係る目標値
項番 | 指標名 | 目標値 | 補足 |
1 | 運用時間 | 24 時間 365 日 | 以下に該当する時間を除く。 ・ 接続回線の計画停止時間 ・ 大規模災害等の天災地変に起因する停止時間 ・ 連携するサービス又はクラウドサービスまたはスマートフォン端末の通信キャリアの障害・計画停止・緊急メンテナンス等に起因する停止時間 ・ 本サービスのメンテナンスによる計画停止時間 |
2 | 稼働率 | 99.9%以上 | 本サービスにおける稼働率を以下の計算式により定義する。稼働率＝年間実稼働時間／年間予定稼働時間 x 100 当該計算式において、年間実稼働時間は「利用者がサービスを利用可能な時間の合計」、年間予定稼働時間は「年間稼働時間（24 時間 365 日）から計画停止時間及び大規模災害による停止・縮退時間を 除いた時間の合計」とする。 |
イ 可用性に係る対策
本サービスの可用性を確保し、前述に示した稼働率を遵守するため、以下に示す要件に基づく対策を行うこと。
クラウドサービスの利用を前提として、本サービスを構成するサーバ、ネットワーク機器及びネットワーク経路を冗長化し、単一障害点（SPOF）を回避すること。
クラウドサービスの利用を前提として、フェールセーフの観点から、障害が発生したコンポーネントを切り離すことによりサービス全体を停止せずに運用可能とすることを考慮する。そのために各種障害発生時の影響を回避又は局所化し、原則として自動縮退運用に対応すること。
本サービスに係る運用・保守上の人的ミスに起因する障害が本サービスの可用性に影響を与える事態を未然に防止するため、「3.16 運用に関する事項」及び「3.17 保守に関する事項」を踏まえ、適切な手順書を整備すること。また、定型的なオペレーションは自動化すること。
(2) 完全性要件
以下に示す要件を踏まえ、本サービスの完全性を確保するための対策を行うこと。
ア クラウドサービスの利用を前提とし、以下の対策を講ずること。
コンポーネントの故障に起因するデータの減失や改変を防止する。異常な入力や処理を検出しデータの減失や改変を防止する。
イ 処理の結果を検証可能とするため、ログ等の証跡を収集・保全すること。対象ログの種類や保全期間はシステムの特性を踏まえた検討を行い、委託者の承認を得ること。
拡張性に関する事項
(1) 性能の拡張性ア 基本方針
本システムの利用率の増加、データ量の増加等により、利用資源の規模・性能を拡張する必要が生じた場合に備え、可能な限り機能や性能の拡張を柔軟に行えるよう、設計・開発を行うこと。
イ クラウドサービスの利用
本サービスはクラウドサービスを利用する想定としている。本サービスの構築に当たっては、当該クラウドサービスをマネージドサービスなど可能な限り活用することにより、処理能力等の動的調整を実現することとし、業務量及び処理能力の拡張性については特段の拡張性要件を定義しない。
ウ コンポーネントの再利用性
アプリケーションやインフラの設計にあたっては、将来の拡張時に効率良く対応ができるように、設定情報の外部化や一元化、機能の共通化等に努めること。
(2) 機能の拡張性ア 機能の追加
機能の追加や、新たな機能開発の必要が生じることが想定されることから、将来開発する機能も含めた機能間の連携が十分に図られるようにすること。
クラウドサービス事業者から提供される新技術・新サービスについて、効果が見込めるものについては、事前検証による導入の実現性確認を行うこと。
本サービスは、連携業務アプリケーションとの一層の連携など、拡張性を備えたシステム・サービスであることが求められる。連携機能等の拡張が必要になった際に拡張が容易となるような構成をとること。
イ モニタリングと定期的な報告
本システムの運用に当たっては、当該制約を十分に理解した上で、定期的な運用報告において定期的にサーバコア数やディスク、メモリ、ネットワークの帯域などの使用状況等を確認する。またリソースの増加の必要性が見込まれる場合は、リソースの増強の必要性の有無を判断できるような形で委託者に報告を行うこと。
ウ 割り当て変更
業務量の増加減に伴い、これらリソースの割り当てを動的に行えるようにし、環境省担当官の指示に基づきリソースの割り当てを変更すること。
上位互換性に関する事項
(1) 上位互換性
クラウドサービスの活用を踏まえ、OS、サーバソフトウェアのバージョンアップ又は変更に備え、本サービスを構成する。
ア クラウドサービスのバージョンアップ
システムの構成にクラウドサービスのマネージドサービスを採用する場合、軽微なバージョンアップについては自動適用を前提とする。大規模なバージョンアップについては、
アプリケーションへの影響を事前に精査し、適用を検討すること。
イ OS 等への依存
原則特定バージョンへの依存は避けること。なお、やむを得ず OS、ミドルウェア等の特定バージョンに依存する場合は、その利用を最低限とすること。
ウ クライアント端末の更新
クライアント端末が更新され、OS や Web ブラウザとして新しいバージョンのものを利用することとなっても、業務運営に極力支障が生じないよう計画されたシステム構成とすること。
(2) 業務分担
本システムを構成する機器・ソフトウェアの更新、バージョンアップの必要性が生じた場合は、各事業者がそれぞれの担当範囲において影響調査、対応策の検討を実施することとしている。
ア アプリケーション保守事業者は、業務アプリケーションへの影響調査、対応策の検討を実施する。
イ 運用事業者は、システム基盤の影響調査、対応策の検討を実施する。
ウ 機器・ソフトウェアの更新、バージョンアップの対象が持ち込みソフトウェアの場合 は、運用事業者が実施する影響調査、対応策の検討を機器・ソフトウェア賃貸借・保守事業者が支援する。
中立性に関する事項
(1) オープンな標準的技術又は製品の採用
本サービスを構成するサーバ、ソフトウェア、アプリケーションとして、市場で広く利用されている製品群及びクラウドサービスが提供する標準サービスを除き、原則として特定事業者の技術に依存しないオープンな技術仕様に基づくものを選択すること。
ア オープンソースソフトウェア（OSS）活用
ソフトウェア又はアプリケーションについてフレームワークを活用する場合は、可能な限りオープンソースソフトウェアとして提供されているフレームワークを選定すること。
イ オープンなインタフェースの活用
本サービスを構成するサーバ、ソフトウェア等は、原則として仕様が公開された API等のインタフェースを選定すること。
継続性に関する事項
本サービスの停止等に際しても必要最低限の業務を継続（又は回復）するため、以下に示す要件を踏まえ、本サービスの継続性を確保すること。
(1) 継続性に係る目標値
以下に、機能停止等の原因となる事象の規模に応じて継続性に係る目標値を示す。なお、連携する gBizID サービスの障害・計画停止時は、本サービスの継続も困難になることから、保全活動関連業務も停止する。この場合は、連携する gBizID サービスの復旧後、保全活動関連業務も速やかに復旧を行うこととする。
ア 予測可能な障害発生時
予測できる障害（一時的な過負荷等）については、あらかじめ業務停止を回避するための対策を講ずること。また、単一障害発生時は業務停止せずに処理継続可能であること。
イ 業務停止を伴う障害発生時
予測困難な事象により業務停止を伴う障害が発生した場合の目標復旧時間（RTO）、目標復旧レベル（RLO）及び目標復旧地点（RPO）を下表に示す。
表 3-8 継続性に係る目標値（業務停止を伴う障害発生時）
No. | 設定対象 | 指標及び目標値 | ||
目標復旧時間（RTO） | 目標復旧地点（RPO） | 目標復旧レベル（RLO） | ||
1 | 全ての機能 | 障害検知後 1 営業日以内 | 最新の日次バックアップ 時点 | 特定業務（主要な機能）が 実行可能な状態 |
ウ 大規模災害発生時
インターネット等通信インフラが被災しておらず、発災前と同様の通信環境が確保されていることを前提として、大規模災害による業務停止が発生した場合の目標復旧時間
No. | 設定対象 | 指標及び目標値 | ||
目標復旧時間（RTO） | 目標復旧地点（RPO） | 目標復旧レベル（RLO） | ||
1 | 全ての機能 | 1 週間以内 | 最新の日次バックアップ時点 | 特定業務（主要な機能）が実行可能な状態 |
（RTO）、目標復旧レベル（RLO）及び目標復旧地点（RPO）を下表に示す。表 3-9 継続性に係る目標値（大規模災害発生時）
(2) 継続性に係る対策
本システムの継続性要件を実現するために、以下の対策を講じること。
ア 冗長化
各構成要素について、故障等を検知した際、クラウドサービスの利用を前提として自動的に予備の環境へ切替える等、適切に冗長化を行い、特定の部分の障害によりシステム全体が停止してしまうような SPOF（単一障害点）を極力排除するよう、設計時に配慮すること。
イ データバックアップバックアップ対象
データバックアップに当たっては、本サービスの稼働に必要な全データを復旧可能と
することを前提として、外部組織から再入手可能なデータの有無を含め、保全対象を精査し、復旧時に必要となるデータを過不足なく保全対象に含めることができるようにすること。なお、クラウドサービスのマネージドサービスを利用することで自動的にバックアップを取得できる部分はあるが、オペレーションミスやアプリケーションのバグ等に起因するデータ破壊に対しても破壊前の時点まで遡れるように、バックアップの実施方法について配慮すること。
バックアップ頻度
バックアップの取得間隔は、原則日次とする。ただし、障害発生時点への復旧が必要なデータについては、復旧に用いる PITR：Point In Time Recovery/Restore を保存する等の対応を行うこと。
データの隔地保管
「3-2-1 ルール」（2012 年に米国土安全保障省サイバーセキュリティ・インフラストラクチャー・セキュリティ庁の US-CERT が提唱）に示されている「データはコピーして
３つ保有(プライマリー1 つ、バックアップ 2 つ)、2 種類の異なる記録媒体に保管、コピーのうち１つは遠隔地に保存」という方針を十分に理解した上で、データのバックアップについて万全を期した対応を行うこと。クラウドサービス上のスナップショットやレプリカだけではこの要件に十分対応できないので、バックアップとして永久増分と重複排除を積極的に活用し、ISMAP 管理基準が求める暗号化を行った上で、別リージョンのオフサイトに隔地保管すること。
バックアップツール
バックアップ対象、頻度、バックアップデータへのアクセス権限及び保存期間といったバックアップポリシーを一元的に管理できる機能を持った、クラウドサービスプロバイダが提供するバックアップサービスをできるだけ利用すること。なお、個別データの復旧にはデータベース等の PITR：Point In Time Recovery/Restore を実現できることが望ましい。
ウ システムバックアップ
RPO（目標復旧時点）は前稼働日のバックアップ時点、RTO（目標復旧時間）は 24 時間以内とする。クラウドサービスのマネージドサービスにおけるバックアップ機能を有効に活用すること。なお、インスタンスを利用してサーバを立てる場合のバックアップ方式 は、バックアップ＆リストア、コールドスタンバイ、ウォームスタンバイ、マルチサイトの 4 つのディザスタリカバリ方式のうち、目標復旧時間から考えて、コールドスタンバイ以上の構成を想定している。
情報セキュリティに関する事項
(1) セキュリティ対応方針
セキュリティ要件を決定するためのシステム特性や特に対処すべきセキュリティリスク、セキュリティ対応方針を下表に示す。ただし、本システムを構成する「フロントサブシステム」はガバメントクラウド、「地理情報サブシステム」は環境省 GIS 統合基盤を利用するため、それらの基盤側でセキュリティ対応がなされることを考慮すること。
表 3-10 当該システムにおけるセキュリティ対応方針
項番 | 分類 | 概要 |
1 | 原則 | 「政府機関等のサイバーセキュリティ対策のための統一基準」、「環境省情報セキィリティポリシー」に準拠した情報セキュリティ対策を講ずること。 セキュリティ対策については、高度化/大規模化するサイバー攻撃等に対応するため、多層防御やサイバーレジリエンス強化といった原則に基づいて要件を 定義する。 |
2 | システム特性 （概要） | 【システムの利用者】 当該システムは国民向けサービスであり、一日に 30 人程度の利用者が想定される 【システムで取り扱う情報】 個人情報は取り扱われるが特定個人情報は取扱われない 【使用環境・ネットワーク構成】 利用者は PC 若しくはスマートフォン等のブラウザからンターネットを介して当該 web システムにアクセスし、ログインして各種機能を使用する システム管理者はインターネット VPN を介して当該システムにアクセスし、システム管理を実施する 外部システムとの接続は将来的にはいきものログとの接続を想定 |
3 | 優先的に対処すべきセキュリティリスク | 【優先的に対処すべきセキュリティリスク】 外部からの不正アクセスにより、システムの個人情報が漏洩する。 サービス妨害を目的とした攻撃等によりシステムが長時間停止する。 |
4 | セキュリティ対応方針 | 【セキュリティ要件のベースライン】 本システムにおいては、セキュリティ要件を過不足なく導出するため、NISC の提供する SBD マニュアルをセキュリティベースラインとして利用する 【優先的に対処すべきセキュリティリスクへの対応方針】 上記の優先的に対処すべきセキュリティリスクについては、多層防御の観点で発生確率を抑えるとともに、発生時の範囲を極小化するような対策を実施する。 外部からの不正アクセス対策として不正ログイン対策、脆弱性対策を徹底するともに、攻撃やインシデントの兆候を早期検知できるような仕組みを導入する。 サービス妨害を目的とした攻撃対策については、L3～L7 層で対策可能な仕組みを導入する。 【その他セキュリティリスクへの対応方針】 ・上記以外のセキュリティリスク（内部不正や人為的ミス等に起因するもの、サプライチェーンに起因するもの等）についても発生時影響は看過できないことから、予防的な対策だけでなく早期検知するための対策を実施し、リスクを低減する。 |
(2) セキュリティ要件
本システムは、以下のセキュリティ要件を満たすこと。
なお、クラウドサービスとしての制約等によって要件を満たすことが難しい項目については、その理由を明示した上で代替案の提案を許容するものとする。
表 3-11 情報システムのセキュリティ要件
No. | 情報セキュリティ対策 | 対策に係る要件 | |
1 | 通信回線対策 | 通信経路の分離 | 不正の防止及び発生時の影響範囲を限定するため、外部との通信を行うサーバ装置及び通信回線装置のネットワークと、内部のサーバ装置、端末等のネットワークを通信回線上で分離する こと。 |
2 | 不正通信の遮断 | 通信回線を介した不正を防止するため、不正アクセス及び許可されていない通信プロトコルを通信回線上にて遮断する機能を 備えること。 | |
3 | 通信のなりすまし防止 | 情報システムのなりすましを防止するために、サーバの正当性を確認できる機能を備えること。 | |
4 | サービス不能化の防止 | サービスの継続性を確保するため、構成機器が備えるサービス停止の脅威の軽減に有効な機能（情報システムを直ちに外部ネットワークから遮断、通信回線の通信量を制限等）を活用して情報システムを構築すること。 | |
5 | 不正プログラム対策 | 不正プログラムの感染防止 | 不正プログラム（ウイルス、ワーム、ボット等）による脅威に備えるため、想定される不正プログラムの感染経路の全てにおいて感染を防止する機能を備えるとともに、新たに発見される不正プログラムに対応するために機能の更新が可能であること。 |
6 | 不正プログラム対策の管理 | システム全体として不正プログラムの感染防止機能を確実に動作させるため、当該機能の動作状況及び更新状況を一元管理す る機能を備えること。 | |
7 | セキュリティホール対策 | 構築時の脆弱性対策 | 情報システムを構成するソフトウェア及びハードウェアの脆弱性を悪用した不正を防止するため、開発時及び構築時に脆弱性の有無を確認の上、運用上対処が必要な脆弱性は修正の上で納 入すること。 |
8 | 運用時の脆弱性対策 | 運用開始後、新たに発見される脆弱性を悪用した不正を防止するため、情報システムを構成するソフトウェアの更新を効率的に実施する機能を備えるとともに、情報システム全体の更新漏れを防止する機能を備えること。 | |
9 | ログ管理 | ログの蓄積・管理 | 情報システムに対する不正行為の検知、発生原因の特定に用いるために、情報システムの利用記録、例外的事象の発生に関するログを蓄積し、1 年間保管するとともに、不正の検知、原因特定に有効な管理機能（ログの検索機能、ログの蓄積不能時の対処機 能等）を備えること。 |
10 | ログの保護 | ログの不正な改ざんや削除を防止するため、ログに対するアクセス制御機能を備えるとともに、ログのアーカイブデータの保護（消失及び破壊や改ざん等の脅威の軽減）のための措置を含む設計とすること。 | |
11 | 時刻の正確性確保 | 情報セキュリティインシデント発生時の原因追及や不正行為の追跡において、ログの分析等を容易にするため、システム内の機器を正確な時刻に同期する機能を備え、ログに時刻情報も記録 されるよう設定すること。 | |
No. | 情報セキュリティ対策 | 対策に係る要件 | |
12 | 不正監視 | 侵入検知 | 不正行為に迅速に対処するため、通信回線を介して所属する府省庁外と送受信される通信内容を監視し、不正アクセスや不正 侵入を検知及び通知する機能を備えること。 |
13 | 主体認証 | 主体認証 | 情報システムによるサービスを許可された者のみに提供するため、情報システムにアクセスするシステム利用者の認証を行う機能（ユーザーID 及びパスワード等、利用者本人のみが知り得る情報による認証）を設けること。 なお、主体認証に際しては gBizID 等、なるべく既存のアカウントを用いることとする。 地方公共団体職員は LGPKI での認証、民間企業等は gBizID での 認証を行う想定。 |
14 | アカウント管理 | ライフサイクル管理 | 主体のアクセス権を適切に管理するため、主体が用いるアカウント（識別コード、主体認証情報、権限等）を管理（登録、更新、停止、削除等）するための機能を備えること。 主体認証を行う情報システムにおいて、利用者に主体認証情報の定期的な変更を求める場合には、利用者に対して定期的な変更を促す機能のほか、以下いずれかの機能を設けること。 ・利用者が定期的に変更しているか否かを確認する機能 ・利用者が定期的に変更しなければ、情報システムの利用を継続させない機能 ・利用者が主体認証情報を変更する際に、以前に設定した主体 認証情報の再設定を防止する機能。 |
15 | アクセス権管理 | 本システムの利用範囲を利用者種別に応じて制限するため、本システムのアクセス権を種別に応じて制御する機能を備えるとともに、アクセス権の割り当てを適切に設計すること。 | |
16 | 管理者権限の保護 | 特権を有する管理者による不正を防止するため、管理者権限を 制御する機能を備えること。 | |
17 | データ保護 | 通信経路上の盗聴防止 | 通信回線に対する盗聴行為や利用者の不注意による情報の漏えいを防止するため、通信回線を暗号化する機能を備えること。暗号化の際に使用する暗号アルゴリズムについては、「電子政府推奨暗号リスト」を参照し決定すること。 |
18 | 保存情報の機密性確保 | 本システムに蓄積された情報の窃取や漏えいを防止するため、情報へのアクセスを制限できる機能を備えること。また、外部との接続のある本システムにおいて保護すべき情報を利用者が直 接アクセス可能な機器に保存しないこと。 | |
19 | 保存情報の完全性確保 | 情報の改ざんや意図しない消去等のリスクを軽減するため、情報の改ざんを検知する機能又は改ざんされていないことを証明する機能を備えること。 | |
20 | 情報の物理的保護 | 情報の漏えいを防止するため、物理的な手段による情報窃取行 為を防止・検知するための機能を備えること。 | |
No. | 情報セキュリティ対策 | 対策に係る要件 | |
21 | 侵入の物理的対策 | 物理的な手段によるセキュリティ侵害に対抗するため、本システムの構成装置（重要情報を扱う装置）については、外部からの 侵入対策が講じられた場所に設置すること。 | |
22 | 構成管理 | システムの構成管理 | 情報セキュリティインシデントの発生要因を減らすとともに、情報セキュリティインシデントの発生時には迅速に対処するため、構築時の本システムの構成（ハードウェア、ソフトウェア及びサービス構成に関する詳細情報）が記載された文書を提出するとともに文書どおりの構成とし、加えて本システムに関する運用開始後の最新の構成情報及び稼働状況の管理を行う方法又 は機能を備えること。 |
23 | 可用性確保 | システムの可用性確保 | サービスの継続性を確保するため、情報システムの各業務の異常停止時間が復旧目標時間を超えることのない運用を可能とし、障害時には迅速な復旧を行う方法又は機能を備えること。 |
24 | 不正プログラム組み込み対策 | 委託先において不正プログラム等が組み込まれることへの対策 | 本システムの設計・開発において、環境省が意図しない変更や機密情報の窃取等が行われないことを保証する管理が、一貫した品質保証体制の下でなされていること。当該品質保証体制を証明する書類（例えば、品質保証体制の責任者や各担当者がアクセス可能な範囲等を示した管理体制図）を提出すること。本調達に係る業務の遂行における情報セキュリティ対策の履行状況を確認するために、環境省が情報セキュリティ監査の実施を必要と判断した場合は、受託者は情報セキュリティ監査を受け入れること。 また、役務内容を一部再委託する場合は、再委託されることによ り生ずる脅威に対して、情報セキュリティを確保すること。 |
25 | 調達する機器等に不正プログラム等が組み込まれるこ とへの対策 | 機器等の製造工程において、環境省が意図しない変更が加えられないよう適切な措置がとられており、当該措置を継続的に実施していること。また、当該措置の実施状況を証明する資料を提 出すること。 | |
26 | 情報セキュリティ水準低下防止 | 情報セキュリティ水準低下の防止 | 本システムの利用者の情報セキュリティ水準を低下させないように配慮した上でアプリケーションプログラムやウェブコンテンツ等を提供すること。 |
27 | プライバシー保護 | プライバシー保護 | 本システムにアクセスする利用者のアクセス履歴、入力情報等を当該利用者が意図しない形で第三者に送信されないようにす ること。 |
28 | 個人情報保護 | 個人情報保護 | システムでは、個人情報等を保有するため、取り扱いには十分に注意し、情報漏えい等を防止するための対策を講じること。 |
また、以下の事項を参考とすること。
請負者は、開発の各工程において、本セキュリティ要件に則ってセキュリティ対策がもれなく実装されていることを検証する方法を定め、要件のトレーサビリティを確保することが求められる。
開発工程以降、セキュリティ対策を具体化する過程でセキュリティ上の懸念が発生し
た場合は、本要件のみに縛られず、必要に応じて追加のセキュリティ対策を講じること。また、デジタル庁「政府情報システムにおけるセキュリティ・バイ・デザインガイドライン（政府情報システムにおける セキュリティ・バイ・デザインガイドライン (digital.go.jp)）」の記載内容（要求事項、実施内容、重要なセキュリティ対策の考え方）に従い、各工程でのセキュリティ対応状況について抜け漏れを確認して是正すること。
情報システム稼働環境に関する事項
本システムにおけるハードウェアの構成、ソフトウェアの構成、ネットワークの構成、施設・設備要件等はガバメントクラウド及び環境省 GIS 統合基盤の仕様を前提とする。
(1) システム構成
本システムの構成はガバメントクラウド及び環境省 GIS 統合基盤の仕様を前提とする。
図 3-1 システム構成図（想定）本システム稼働環境については、以下の要件を満たすこと。
本システム稼働環境の基本要件は現時点の想定であり、要件に最も適した構成を提案すること。
表 3-12 システム稼働環境の基本要件（想定）
No | 環境種類 | 環境の概要 | 要件 |
1 | 本番環境 | 民間・地方公共団体等が効果的・効率的に生物多様性保全活動を実施するための支援ツールであり、生物多様性の保全上効果的な場所、保全状況等を利用者に分かりや すく提供するための環境のこと。 | ガバメントクラウド及び環境省 GIS 統合基盤が提供するサービスを利用すること。 冗長構成とすること。 検証環境との接続を可能とすること。 |
2 | 検証環境 | 本システムの統合的なテストの実施やシステムの変更(システム設定変更、パッチ適用時、新規ソフトウェア導入、ソフトウェアの新機能の確認等)に当たって本番環境への影響について事前確認等を行うた めの環境のこと。 | ガバメントクラウド及び環境省 GIS 統合基盤が提供するサービスを利用すること。 冗長構成とすること。ただし管理系のサーバはシングル構成とすること。 本番環境との接続を可能とすること。 |
3 | 開発環境 | 請負者にて本システムを開発する環境のこと。 | ガバメントクラウド及び環境省 GIS 統合基盤が提供するサービスを利用すること。 シングル構成とすること。 検証環境との接続を可能とすること。 |
(2) クラウドサービス構成
ア クラウドサービスの要件
本システムで用いるクラウドサービスは、以下を遵守すること。
クラウドサービスの可用性を保証するための十分な冗長性、障害時の円滑な切替え等の対策が講じられていること。
クラウドサービス上で取り扱う情報について、機密性及び完全性を確保するためのアクセス制御、暗号化及び暗号鍵の保護並びに管理を確実に行うこと。
クラウドサービスに係るアクセスログ等の証跡を保存し、委託者からの要求があった場合は提供すること。
インターネット回線を通じたセキュリティ侵害を防ぐため、インターネット回線とクラウド基盤との接続点の通信を監視すること。
クラウドサービスの提供に関する次のいずれかの認証を取得していること。 ISO/IEC 27017:2015
CS マーク（特定非営利活動法人日本セキュリティ監査協会（JASA）のクラウドセキュリティ推進協議会が定めるもの）
イ クラウドサービス構成
本システムのクラウドサービス構成を提案すること。なお、速やかに本番同等の環境を構築できるように、インフラの設定は Infrastructure as Code にて構成し、環境変更時にはその変更をメンテナンスできるようにすること。
(3) ハードウェア構成
本システムのハードウェアに関する要件は、ガバメントクラウド及び環境省 GIS 統合基盤の仕様を前提とする。
(4) ソフトウェア構成
本サービスの構築に当たっては、可能な限りクラウドサービス提供のサービスを活用すること。また、いずれのソフトウェアについても、原則として最新バージョンを適用する。
ア ソフトウェアの持ち込みが必要な場合においては、特定のソフトウェアへの依存により将来的なシステムの拡張及び更新や事業者間での引継ぎが妨げられることがないよう十分に配慮すること。
(5) ネットワーク構成
本システムのネットワークに関する要件はガバメントクラウド及び環境省 GIS 統合基盤の仕様を前提とする。なお、事務局、自然共生サイト管理者等並びに地方公共団体の職員等利用者のアクセスは日本国内からとする。国民等利用者等のアクセスは限定しない。
ア ネットワークセグメント構成
ネットワークセグメントはガバメントクラウド及び環境省 GIS 統合基盤の仕様を前提とする。
イ ネットワーク接続要件
ネットワーク接続要件はガバメントクラウド及び環境省 GIS 統合基盤の仕様を前提とする。
ウ ネットワーク回線要件
ネットワーク回線要件はガバメントクラウド及び環境省 GIS 統合基盤の仕様を前提とする。ガバメントクラウド及び環境省 GIS 統合基盤と接続するネットワーク回線については、基本的に環境省職員及び地方公共団体職員は Government Network(G-Net) (Government Solution Service（GSS）への移行計画有り)やLGWAN などの閉域網を経由した接続を想定すること。運用管理セグメントへの接続においては、仮想的に設けた閉域網による接続を想定すること。
なお、運用・保守業務に必要な運用端末、ネットワーク回線及びネットワーク装置
（VPN 装置）等は、請負者が受託契約の範囲として用意すること。
(6) 施設・設備要件
本システムの施設・設備に関する要件はガバメントクラウド及び環境省 GIS 統合基盤の仕様を前提とする。
(7) デバイスの要件
本システムの運用開始時点で動作保証の対象とするスマートフォン端末・OS・ブラウザの考え方について、以下に示す。
ア 本システムの運用開始時点で動作保証の対象とする端末・OS の機種やバージョンを下表に示す。
表 3-13 動作保証対象の端末
項番 | 端末 | OS | バージョン |
1 | スマートフォン | Android 又は iOS | Android 9 又は iOS 13 |
2 | PC | Mac OS 又はWindows | macOS 10.15 又は Windows7、8.1、10及び 11 |
ア 本システムの運用開始時点で動作保証の対象とするブラウザは以下とする。
PC(Mac OS/Windows) の場合：Microsoft Edge/Mozilla Firefox/Google Chrome/Safariの最新バージョン
Android の場合：Google Chrome の最新バージョン iOS の場合：Safari の最新バージョン
イ 動作確認の結果、動作しなかった端末・OS・ブラウザは、原則として、令和 6 年度に設 計・開発を行い、可能な限り運用開始時点の動作対象に含める方針とする（ただし、委託者と協議の上、運用開始までに設計・開発が完了しないことが明らかな場合は、設計・開発の対象から除外する）。
テストに関する事項
本システムのテストに関する要件を下表に示す。必要に応じて、テストデータやテストに関連する情報の提供にも協力すること。
表 3-14 テスト要件
項番 | 分類 | 要件 |
1 | テスト工程の定義 | 本システムでは調達仕様書に記載の通り、以下のテストを実施する。 (1) 単体テスト (2) 結合テスト (3) 総合テスト (4) 受入テスト |
2 | テスト環境 | 本番環境に加え、運用・保守開始後にテストを実施するためのテスト環境についても整備すること。 テスト環境については、連携先機関と接続して行う外部連動テストが実施可能な環境として整備するほか、同時並行的な開発に対応できるように複数のテスト環境を整備すること。 開発スケジュールを踏まえ、効率化を考え、各環境を流用するなど検討すること。 |
3 | テスト計画書 | 各テスト工程の開始時に、以下の内容を定義したテスト計画書を作成し、委託者の承認を得ること。 テスト体制 テスト環境 作業内容 作業スケジュール テストシナリオ テスト結果に係る定性・定量評価の方法（テスト密度、バグ検出密度等） |
項番 | 分類 | 要件 |
合否判定基準 請負者は、本業務を実施する各過程においてテスト計画書の内容に変更が生じる場合、変更箇所及び内容について委託者の承認を得ることを条件として、テスト計画書を適切に更新すること。 情報セキュリティの観点から必要なテストがある場合には、テスト項目及びテスト方法を定め、これに基づいてテストを実施し、その実施記録を保存すること。 請負者は、テストに係る管理要領を共通化し、各テスト工程において、原則として同一の管理要領を適用するようにすること。各テスト工程に応じて部分的に異なる管理要領の適用を必要とする場合は、その適用差分のみ「テスト計画書」に記載すること。機能・画面一覧を基準として欠陥の相対的な発生確率と欠陥顕在化時の相対的な影響度について、それぞれ高・中・低の 3 段階で評価することにより、本サービスの品質リスクを分析し、その結果を踏まえてテストケースの数や質に変化をつけるリスク・ ベース・テストを適用すること。 | ||
4 | テスト仕様書 | 本システムの各テスト工程の開始前に、テストシナリオ、テスト項目等を記載したテスト仕様書を作成すること。 各テスト工程のテスト項目は、設計書等の記述内容を網羅的に確認できるよう作成すること。 各テスト工程に応じたテスト技法を適用すること。 テスト項目は、品質を確保するために十分なテスト項目を定義すること。また、テスト計画の策定時に定めた定性・定量評価方法を満たすよう作成すること。 |
5 | テストの実施 | 作成したテスト項目に基づきテストを実施すること。 欠陥を検知した場合は、その原因を明らかにした上で、原因を解消すること。 検知した欠陥について修正を行った場合は、修正対象機能について回帰テストを実施すること。 委託者において、再テストが必要と判断した場合、請負者は再テストの計画を作成し、委託者の承認を得た上で、定められた期限内に再テストを実施すること。また、類似 バグを抽出するため、必要に応じて強化テストを実施すること。 |
6 | テストデータ | 総合テスト及び受入テストにおいて実データを使用する必要がある場合は、実データの取得申請を条件として、実データの使用を許可する。なお、疑似データの作成に当たり、実データの匿名化、符号化等を行う場合は請負者の作業とする。 取得した実データは、適切に保管・管理すること。 受入テストにおいて作成したテストデータは、システム切替え実施前までに、検証環境等のデータも含め削除すること。 機密性の高いデータ項目や個人情報に係るデータ項目は、マスキングした上で使用す ること。 |
7 | 対応状況の報告 | テストの進捗としては、テスト実施済項目数や信頼度成長曲線等の定量的なメトリクスの推移を示すことにより、テスト進捗状況、不具合検出状況及び不具合対応状況を報告すること。 結合テスト・総合テストでの報告書には、ソースコードメトリクスを取得し、テスト結果及び品質指標とともに、委託者に報告すること。 請負者は、各テスト工程に応じたテスト計画内容について委託者に説明し、各テスト工程における最初のテスト開始予定日の遅くとも1 週間前までに委託者の承認を得る こと。 |
8 | テスト完了報告書 | 各テスト工程の完了に当たっては、テスト完了報告書を作成し、委託者の承認を得ること。また、完了に当たっては以下をすべて満たすこと。 すべてのテスト項目が完了していること。 テスト結果について、定性評価及び定量評価（テスト密度、バグ検出密度等）により評価を行うこと。 テストで発生したすべての障害が、当該テスト工程内で解消されていること。 外的要因等により次工程への申し送り事項が発生した場合は、対応方針、対応時 期等を明確にした上で、委託者の承認を得ること。 |
9 | テストの | 各テスト項目のうち、反復的にテストを実施するものについては、自動化することを原則とする。そのために、必要となるテストツールについては、新規に作成するか、 |
項番 | 分類 | 要件 |
自動化 | 既存のツールを活用すること。 UI のテスト、受入テスト等、テストの自動化に馴染まないものについては、自動化対象外とする。ただし、自動化対象外とすることについて、委託者の承認を得ること。 | |
10 | 将来時点の仕様変 更 | OSS を適用する部分を除き、将来時点の仕様変更への対応を柔軟にする観点から、テスト駆動開発、ソースコードに対する静的解析及びリファクタリングにより、クラスや関数構造をシンプルに保つこと。 |
11 | 構築時の脆弱性対策 | ネガティブテスト、ファジング、フォルト・インジェクション等の障害注入テスト手法を活用し、エラー処理や例外処理に係る脆弱性に対処すること。 品質保証、フォレンジック及びインシデント・レスポンスの観点から、問題原因を把握するために必要な例外情報をログに出力するようにすること。 設計・開発段階の早期からセキュリティを検証すること。 |
12 | その他の要件 | テストにおいてプログラムや設定情報の修正が生じた際には、当該修正が他の機能等に影響を与えていないかを確認するための回帰テスト（リグレッションテスト）を実施すること。 総合テストにおいて応答性能の未達が判明した場合には、リソースの再配分・追加等の対応を実施すること。 テストの実施に当たって必要となるテストツール、スタブ、ドライバ等を用意すること。 災害時切替等、環境省のネットワークの設定変更を伴うテストを実施する際には、 事前に環境省のネットワーク管理担当と調整を行うこと。 |
(1) 単体テスト
単体テストは、本サービスにおける最小の実装構成要素（関数、メソッド等）に着目し、ソースコードの確からしさを確認することを目的とするコードベースの単体テストと、UI を含む単機能のテストにより構成する。現時点で想定する単体テストの要件を以下に示す。
ア 請負者は機能及びアプリケーションプログラムが「詳細設計書」の設計どおりに動作することを確認するため、「詳細設計書」に基づいた単体テスト環境、作業内容、実施スケジュール、合否判定基準等を記載した「単体テスト計画書」を作成し、テストシナリオを記載した「単体テスト仕様書」を作成すること。
イ 請負者は、「単体テスト計画書」及び「単体テスト仕様書」に基づき、単体テストを実施すること。
ウ 単体テストの結果は、必要に応じて数値的指標等（ステップ数あたりの試験項目数、試験消化率等）をもって報告すること。以下に示す事項については、あらかじめ委託者に提示すること。
単体テストのスケジュール
テスト環境（テストを実施するハードウェア、ソフトウェアの構成、テストツール等）の概要
合否判定基準 等
エ 単体テストは、原則として請負者が準備する開発環境において実施すること。
(2) 結合テスト
結合テストは、本サービスの構成要素（アプリケーション機能、ソフトウェア、ハードウェア等）に着目し、各要素の連動又は協調動作に関する設計の欠陥を検出することを目的として行う。
現時点で想定する結合テストの要件を以下に示す。ア 結合テストの観点として以下を想定する。
表 3-15 結合テストの主なテスト観点
項番 | テスト種別 | 概要 |
1 | システム基盤テスト(開発環境テスト) | 構築した本番環境及び検証環境の確認を行う。現時点で想定するシステム基盤テスト(開発環境テスト)の要件を以下に示す。 環境設計において作成したリソース定義コードを実行し、サービスのインフラストラクチャを構成する環境及び仮想資源を構築すること。 構築した環境及び仮想資源が正しく動作するか、動作確認テストを実施すること。 動作確認テストを行うにあたり、「環境テスト計画書」「環境テスト仕様書」を作成すること。 クラウドサービスが提供するツールによって実行可能なテストコードを作成すること。 動作確認テストの結果、何らかの異常またはエラーを確認した場合、実行したリソース定義コードに原因が作り込まれていないか、必要な見直しを行うこと。 問題修正後、該当する環境または仮想資源について、再構築と動作テストを 再度実施すること。 |
2 | 外部連携テスト | 外部システムとの連携部分の確認を行うため、以下を実施する。 疎通テスト：本システムと外部連携システム間で必要な通信の疎通が通ることを確認する。 異常系テスト：想定しうるエラーを発生させ、エラーメッセージ等の確認をする。また必要な対処を行うように修正する。 バリエーションテスト：インタフェースによる動作と必要なバリエーションの確認を行う。 運用観点テスト：正常時、異常時の運用に関する動作を確認する。異常時の対応として、エラーメッセージやログ等を基に、運用事業者が運用業務を行 えることを確認すること。 |
イ 請負者は、本システムのシステム基盤、単体テストにより単体として品質が保証された各種機能、ガバメントクラウド及び環境省 GIS 統合基盤が組み合わされた状態で「基本設計書」の設計どおりに動作することを確認するため、「基本設計書」に基づいたテスト体
制、テスト環境、作業内容、作業スケジュール、合否判定基準等を記載した「結合テスト計画書」を作成し、さらに、テストシナリオを記載した「結合テスト仕様書」を作成し て、環境省担当官の承認を受けること。
ウ 請負者は、「結合テスト計画書」及び「結合テスト仕様書」に基づき、結合テストを実施すること。
エ 請負者は、結合テストの実施状況及び結果を「結合テスト結果報告書」に取りまとめ、環境省担当官に報告すること。
オ 請負者は、外部システムとの連携が設計どおりに動作することを確認すること。
カ テスト対象機能について同値分析、境界値分析、原因結果分析を行い、その結果を踏まえてテストケース、テスト項目を設定し、アプリケーション機能相互間の接合に不具合が無いことを検証すること。