Pegasus 拠出金システムにかかる オンライン申告対応改修業務仕様書
Pegasus 拠出金システムにかかる オンライン申告対応改修業務仕様書
令和5年8月
独立行政法人 医薬品医療機器総合機構
目次
2 調達案件及び関連調達案件の調達単位、調達の方式等に関する事項 4
i
1 調達案件の概要に関する事項
(1) 調達件名
Pegasus 拠出金システムにかかるオンライン申告対応改修業務
(2) 用語の定義
表 1.1 用語の定義
用語 | 概要 |
医薬品、医療機器等の品質、有効性及び安全性の確保等に関する法律 (医薬品医療機器等法、 薬機法) | 本書では、「薬機法」という。平成26年11月25日に施行された、医薬品、医療機器等の安全かつ迅速な提供の確保を図るため、添付文書の届出義務の創設、医療機器の登録認証機関による認証範囲の拡大、再生医療等製品の条件及び期限付承認制度の創設等の 所要の措置を講ずるための法律。 |
医薬品・医療機器 申請・審査システム (Pegasus) | 薬機法に定められた許認可に関する申請等を受付けて審査し、行政側の許可・承認等の業務を全国的に一括処理する、独立行政法人 医薬品医療機器総合機構(以下、「PMDA」という。)におけ る、基幹業務処理システム。(以下、「Pegasus」という。) |
申請電子データシステム (Gateway) | 新医薬品製造販売許可を申請する企業が、インターネットを介して、申請日の予告と「承認申請書」「eCTD」「申請電子デー タ」等を電子的に提出することができるシステム(以下、 「Gateway」という。)。また、PMDA内部における提出データの 保管、統計解析処理等の機能を備えている。PMDAが運用・管理している。 |
独立行政法人医薬品医療機器総合機構法(機構 法) | 平成16年4月1日に施行された、当機構が各拠出金を徴収することの根拠となる法律。 |
副作用拠出金 | 副作用救済給付の給付金やその事務に係る経費に充てるための費用。医薬品や再生医療等製品の売り上げに応じて計算される一般拠出金と副作用救済給付の原因医薬品とされ給付金として支払わ れた金額の一部である付加拠出金を併せたもの。 |
感染拠出金 | 感染救済給付の給付金やその事務に係る経費に充てるための費 用。生物由来製品等の売り上げに応じて計算される一般拠出金と感染救済給付の原因とされた生物由来製品等とされ給付金として 支払われた金額の一部である付加拠出金を併せたもの。 |
用語 | 概要 |
安全対策等拠出金 | 医薬品等の安全業務に係る経費に充てるための費用。医薬品・医療機器・再生医療等製品・体外診断用医薬品の売り上げに応じて計算される。 |
拠出金システム | 機構法に定められた副作用拠出金、感染拠出金及び安全対策等拠出金の徴収管理業務並びに進捗管理を行うシステム。 |
会計システム | PMDAの財務会計業務を円滑に処理するためのシステム。 |
(3) 調達の背景
現在使用している拠出金システムは、すでに開発から 20 年以上経過しており、システムを更新する必要がある。また、各拠出金の納付対象者は、医薬品等の製造販売業者であることから、各種製造販売業者や承認された品目を管理している審査系システム内に移行することでデータの共有を図ることで、効率の良いシステムを開発する。
各拠出金の申告は、申告者がPMDA に郵送することで成されるが、現在政府が進める
「デジタル・ガバメント実行計画」に則り、紙媒体の提出を不要とするオンライン申告も可能になるようにする。
本調達では、拠出金に関して申告から納付までを含めてオンライン化すべく、別途調達するクラウド型ファイル共有サービス(以下、Box という)を利用したファイル授受に係る仕組みの構築、及び決済代行サービスとの連携(決済情報連携、決済結果情報取得、月次集計データ取込み等)を実施するものである。
(4) 目的及び期待する効果
Box や決済代行サービスと連携することで、各拠出金のオンライン申告に対応できるようにする。
(5) 業務・情報システムの概要
副作用拠出金、感染拠出金及び安全対策等拠出金の徴収業務は、機構法により、医薬 品・再生医療等製品・医療機器等の出荷数量や売り上げに各係数を乗じて算出した金額を医薬品製造販売業者等から徴収する業務である。
徴収にあたっては、対象となる製造販売業者に対し、機構より申告書等の書類を発送
し、毎年 7 月 31 日までに申告してもらっているが、紙によるやり取りであるため、機構及び製造販売業者の負担が大きいことから、今回のPegasus へのシステム移行の際に、電子的な申告も可能にする。
(6) 契約条件
受注者は、落札後に以下の契約条件にて PMDA と協議の上、契約を行うこと。
① 契約期間
契約締結日から令和6年3月31日までとする。
② 契約形態
請負契約形態とし、検収や支払方法等は契約書にて定める。
(7) 作業スケジュールおよび作業内容・役割分担
① 受注者は、契約締結日から構築業務の開始までに構築業務を実施するための準備を実施し、必要な情報について PMDA より引継ぎを受けること。
② 本業務に係る想定スケジュールの概要は、別紙1「作業スケジュール」のとおりとする。なお、このスケジュールはあくまで想定のスケジュールであり、応札者は提案書に詳細な実施スケジュールを明示すること。受注者は、当該スケジュールをプロジェクト実施計画書に記載すること。
2 調達案件及び関連調達案件の調達単位、調達の方式等に関する事項
関連する調達案件の調達単位、調達の方式、実施時期等は次の表の通りである。
表 2.1 関連する調達案件の調達単位、調達の方式、実施時期等(既存契約)
項番 | 調達案件名 | 調達の方式 | 実施時期 | 事業者名 | 役割 | 補足 |
1 | 拠出金システムの審査系システムへの移行及びオンライン申告対応改修業務 | 一般競争 | 令和 5 年 6月から令和 5 年 9 月 30 日 | BIPROGY 株式会社 | 拠出金システムの Pegasus への移行 | |
2 | 令和 5 年度及び 6 年度審査系システムに係る統合運用支援業務及び統計処理業務 | 一般競争 | 令和 5 年 4 月 1 日から 令和 7 年 6 月 30 日 | BIPROGY 株式会社 | 審査系システムの運用支援業務 | |
3 | 拠出金システムにかかるファイル共有サービスの調達 | 一般競争 | 令和 5 年 10 月 1 日から令和 11 年 3 月 31 日 | 株式会社xx商会 | Box の提供 |
表 2.2 関連する調達案件の調達単位、調達の方式、実施時期等(契約予定)
項番 | 調達案件名 | 調達の方式 | 実施時期 | 役割 | 補足 |
1 | 拠出金システムにかかる決済代行サービスの調達 | 一般競争 | 令和 5 年 8 月 | 決済代行サービスの提供 |
3 作業の実施内容に関する事項
(1)作業の内容
受注者は、本調達仕様書に記載された作業内容や別紙2「各タスク役割分担詳細」に記載された作業内容および納入成果物を参照の上、以下に関し必要な作業を実施すること。また、追加提案できることがあれば、提案書に記載して追加提案すること。
(2) システム資産簿登録に係る作業
PMDA においては、システムのインベントリ情報をxx管理する閲覧資料6に示すシステム資産簿を作成している。受注者は、本システムで利用する機器、ソフトウェア、ネットワーク等の構成情報を PMDA へ報告し、xx管理するシステム資産簿の管理情報について常に最新の状態を保つこと。なお、以下に示す事項以外に管理が必要と考えられる事項があれば PMDA と協議の上、合わせて管理すること。
受注者は対象システムに更新等が発生した場合、下記のインベントリ情報に関し、PMDAが指定するシステム資産簿登録用シートを、PMDA が指示する時期に提出すること。
ア ハードウェア管理台帳(ハードウェア名称、システムモデル、シリアル番号、サポート内容・期間等)
イ ソフトウェア管理台帳(ソフトウェア名称、エディション・バージョン、ソフトウェアの搭載機器、サポート内容・期間等)
ウ ライセンス管理台帳(ソフトウェア名称、エディション・バージョン、ライセンス番号(シリアル番号)、提供形態、有効期限、保有ライセンス数等)
エ その他 PMDA が指定する項目
受注者は、本システムを構成する機器・ソフトウェアの変更、業務アプリケーションの変更、仕様書、設計書等の本システムにかかる各種ドキュメントの変更について、変更理由、変更内容、影響範囲、対応状況、責任者、対応者等と記録し、xx管理を行うこと。
(3) 構築準備作業
(ア)受注者は、契約締結日から移行業務の開始までに、本業務の実施に必要な準備作業として、本業務に必要な什器等の準備、回線引込等を行うこと。
(イ)受注者は、契約締結日から2週間以内に準備作業に関するプロジェクト実施計画書を作成し、PMDA の承認を受けること。
(4) 成果物の範囲、納品期日等
① 成果物
作業工程別の納入成果物は別紙2「各タスク役割分担詳細」に示す。ただし、示した納入成果物に含まれるべき内容を網羅する前提として、納入成果物の構成、記載内容等の詳細については、提案内容に含めること。最終的な納入成果物の構成・内容詳細については、受託後、PMDA と協議し取り決めることとする。
② 納品方法
別紙2「各タスク役割分担詳細」の納入成果物を期日までに提出すること。構築に係る全ての納入成果物を令和6年3月31日に納品すること。なお、納入成果物について は、以下の条件を満たすこと。
ア 成果物は、すべて日本語で作成すること。ただし、日本国においても、英字で表記されることが一般的な文言については、そのまま記載しても構わないものとする。
イ 用字・用語・記述符号の表記については、「公用文作成の要領」に準拠すること。ウ 情報処理に関する用語の表記については、日本産業企画(JIS)の規定に準拠す
ること。
エ 受注者は、指定のドキュメントを外部電磁的記録媒体(CD‐R等)により納品すること。また、PMDA が要求する場合は紙媒体でも納品すること。紙媒体の納品部数については、PMDA と協議すること。ただし、ソフトウェア、ソースコード等は外部電磁的記録媒体(CD-Rなど)のみとする。
オ 紙媒体のサイズは、日本産業企画A列4番を原則とする。図表については、必要に応じてA列3番を使用することができる。また、バージョンアップ時等に差替えが可能なようにバインダ方式とする。
カ 外部電磁的記録媒体に保存する形式は MicrosoftWord2016、同 Excel2016、同 PowerPoint2016 で読み込み可能な形式及びPDF 形式とすること。ただし、PMDAが他の形式による提出を求めた場合は、これに応じること。なお、受注者側で他の形式を用いて提出したいファイルがある場合は、協議に応じるものとする。
キ 納品したドキュメントに修正等があった場合は、紙については、それまでの変更内容を表示するとともに変更履歴と修正ページ、外部電磁的記録媒体については、それまでの変更内容及び修正後の全編を速やかに提出すること。
ク 外部電磁的記録媒体は、2部納品すること。
ケ 納品後、PMDA において改変が可能となるよう、図表等の元データも併せて納品すること。
コ 成果物の作成に当たって、CAD等の上記以外の特別なツールを使用する場合は、
PMDA の承認を得ること。
サ 成果物が外部に不正に使用されたり、納品過程において改ざんされたりすることのないよう、安全な納品方法を提案し、成果物の情報セキュリティの確保に留意すること。
シ 外部電磁的記録媒体により納品する場合は、不正プログラム対策ソフトウェアによる確認を行う等して、成果物に不正プログラムが混入することのないよう、適切に対処すること。
ス 成果物の作成及び納品に当たり、内容、構成等について PMDA が指摘した場合には、指摘事項に対応すること。
セ 納品に当たっては、現存するドキュメント等を変更する必要がある場合はそれらを修正することとし、修正点が分かるように表記すること。
ソ 報告書、計画書等の成果物の記載様式については、記載様式案を PMDA に提示すること。PMDA は、案について受注者と協議の上、決定する。
③ 納品場所
独立行政法人 医薬品医療機器総合機構 BPR・DX 推進x
xxx、PMDA が納品場所を別途指示する場合はこの限りではない。
4 満たすべき要件に関する事項
本業務の実施にあたっては、以下に記載の各要件を満たすこと。
(1) 機能要件
機能要件については、別紙3「拠出金システム開発要件」、別紙4「外部インターフェース要件」を参照すること。
なお、外部インターフェース要件については現時点で想定している外部インターフェースであるため、要件確認および設計の際に一部変更が発生することが想定されるため、最大追加で5つ程度の外部インターフェースが追加される可能性、および外部インターフェース要件に記載したインターフェースもしくは既存の外部インターフェースについて、最大5つ程度で最大5項目追加および変更の可能性があることに留意すること。
(2) 非機能要件
非機能要件については、別紙5「非機能要件」を参照すること。
5 作業の実施体制・方法に関する事項
(1) 作業実施体制
受注者は、本業務に係る要員の役割分担、責任分担、体制図等をプロジェクト実施計画書の一部として作成し、PMDA に報告するとともに、承認を得ること。また、受注者は、必要な要員の調達を遅滞なく実施し、体制図等の要員配置関連資料を確定すること。
①プロジェクトマネジメントに係る、品質管理・進捗管理・セキュリティ管理・リスク管理等の必要な機能を、体制に組み込むこと。
②作業体制の品質確保のため、本業務の運用責任者・リーダーは業務開始から業務終了まで継続して遂行すること。交代する場合は同等以上の要員が担当するものとし、事前に PMDA の承認を得ること。
③受注者は、PMDA 側やその他関連事業者を含めた全体の体制・役割を示した上で、プロジェクトの推進体制及び本件受注者に求める作業実施体制を PMDA と協議の上定めること。また、受注者の情報セキュリティ対策の管理体制については、作業実施体制とは別に作成すること。
④受注者は、インシデント発生時などの連絡体制図をPMDA と協議の上定めること。
⑤機構側の想定体制は以下のとおりとする。
(2) 管理体制
① 本業務の実施に当たり、PMDA の意図しない変更が行われないことを保証する管理が、一貫した品質保証体制の下でなされていること。また、当該品質保証体制が書類等で確認できること。
② 本情報システムにPMDA の意図しない変更が行われるなどの不正が見つかった時(不正が行われていると疑わしい時も含む)に、追跡調査や立入検査等、PMDA と受注者が連携して原因を調査・排除できる体制を整備していること。また、当該体制が書類等で確認できること。
③ 当該管理体制を確認する際の参照情報として、資本関係・役員等の情報、本業務の実施場所、本業務従事者の所属・専門性(情報セキュリティに係る資格・研修実績等)・実績及び国籍に関する情報提供を行うこと。具体的な情報提供内容についてはPMDA と協議の上、決定するものとする。
(3) 作業要員に求める資格等の要件
作業要員に求めるスキル及び資格等を以下に示す。なお、以下に示す資格等については目安であるため、以下に示す資格等を保持していない場合は、それに準ずるものであること示すこと。但し、体制構築においては費用対効果の観点を踏まえ、管理者及び作業実施者を適切に配置すること。
ア プロジェクト管理責任者の必要スキル
A) PMP 又は、情報処理技術者(プロジェクトマネージャ)の合格者
B) IT スキル標準(ITSS)V3 2011 のプロジェクトマネジメント(システム開発 orIT アウトソーシング)のレベル4or5以上の能力
イ セキュリティ
A) 情報処理技術者(情報セキュリティスペシャリスト試験 (SC))、又はテクニカルエンジニア(情報セキュリティ)資格を保持していること。又は、CISSP、CISM 認定資格を保持すること。
ウ データベース
A) 情報処理技術者(データベーススペシャリスト試験(DB)、又はテクニカルエンジニア(データベース))資格を保持していること。又は、それと同等のデータベース専門スキルを持つ技術者が運用業務者の中に含まれること。
B) 本情報システムに導入されている、RDB を使用したシステム開発もしくはログ分析の経験を 5 年以上有すること。なお、対象の RDB の製品は、閲覧資料7「主要ソフトウェア一覧」を参照すること。
(4) 作業場所
① 受託業務の作業場所(サーバ設置場所等を含む)は、(再委託も含めて)PMDA 内、又は日本国内で PMDA の承認した場所で作業すること。
② 受託業務で用いるサーバ、データ等は日本国外に持ち出さないこと。
③ PMDA 内での作業においては、必要な規定の手続を実施し承認を得ること。
④ なお、必要に応じてPMDA 職員は現地確認を実施できることとする。
(5) 作業の管理に関する要領
① 受注者は、PMDA の指示に従って運用業務に係る進捗管理、品質管理、課題管理、変更管理、リスク管理、文書管理、情報セキュリティ管理、コミュニケーション管理、インシデント管理、システム構成管理、体制管理を行うこと。
② 受注者は、PMDA の指示に従って保守業務に係る進捗管理、品質管理、課題管理、変更管理、リスク管理、文書管理、情報セキュリティ管理、コミュニケーション管理、インシデント管理、システム構成管理、体制管理、を行うこと。
③ PMDA が管理するエリアからの情報の持ち出しは許可しない。持ち出しが必要な場合は事前にPMDA に対し、持ち出し目的、対象情報の範囲、情報利用端末、情報の利用者等に関し申請を行うこと。また受注者は、持ち出した情報を台帳等により管理するこ
と。さらに受注者は、持ち出した情報は使用後に確実に消去し、そのエビデンスを提出すること。
No | 管理項目 | 内容 |
1 | 進捗管理 | ・作業の進捗状況等を報告するため、PMDA との進捗会議を定期的に行うこと。また、当該会議の開催を、「プロジェクト実施計画書」に記載すること。 ・当該会議の開催の都度、原則、3営業日以内に議事録を作成し、関係者に内容の確認を行った上で、PMDA の承認を得ること。 ・当該会議においては、受注者の作業の進捗状況を PMDA に報告するとともに、進捗管理に当たっての問題等がある場合や、PMDA から問題を指摘された 場合は、その内容と対応策を PMDA に報告し、PMDA と協議の上、その指示に従うこと。 ・月次でステアリングコミッティにて進捗報告等を行うため、会議資料作成の支 援をすること。また、これについても「プロジェクト実施計画書」に記載すること。 |
2 | 品質管理 | 受注者の成果物に関する品質を管理すること。品質状況を PMDA に報告するとともに、品質管理に当たっての問題等がある場合や、PMDA から問題を指摘された場合は、その内容と対応策を PMDA に報告し、PMDA と協議の上、その指 示に従うこと。 |
3 | 課題管理 | 受注者の作業範囲に関する課題を管理すること。課題状況を PMDA に報告するとともに、課題管理に当たっての問題等がある場合や、PMDA から問題を指摘された場合は、その内容と対応策を PMDA に報告し、PMDA と協議の上、その指示に従うこと。 |
4 | 変更管理 | 受注者の成果物に関する変更を管理すること。変更管理状況を PMDA に報告するとともに、変更管理上の問題等がある場合や、PMDA から問題を指摘された場合は、その内容と対応策を PMDA に報告し、PMDA と協議の上、その指示に 従うこと。 |
5 | リスク管理 | 受注者の作業範囲に関するリスクを管理すること。リスク管理状況を PMDA に報告するとともに、リスク管理上の問題等がある場合や、PMDA から問題を指摘された場合は、その内容と対応策を PMDA に報告し、PMDA と協議の上、その指 示に従うこと。 |
6 | 文書管理 | 受注者が作成又は受領した文書を管理すること。文書管理状況を PMDA に報告するとともに、文書管理上の問題等がある場合や、PMDA から問題を指摘された場合は、その内容と対応策を PMDA に報告し、PMDA と協議の上、その指示に従 うこと。 |
7 | 情報セキュリ ティ管理 | 「9.情報セキュリティ管理」のとおり。 |
No | 管理項目 | 内容 |
8 | コミュニケーション管理 | コミュニケーション管理状況を PMDA に報告するとともに、コミュニケーション管理上の問題等がある場合や PMDA から問題を指摘された場合は、その内容と対応策を PMDA に報告し、PMDA と協議の上、その指示に従うこと。また、受注者は、PMDA から出席を指示された会議に参加し、議事録の作成及び PMDA へ の報告を実施すること。 |
9 | インシデント (障害)管理 | 受注者の運用・保守作業におけるインシデントを管理し、速やかにインシデントによる不具合の解決・解消を実施すること。インシデント管理状況を PMDA に報告するとともに、インシデント管理上の問題等がある場合や、PMDA から問題を指摘された場合は、その内容と対応策を PMDA に報告し、PMDA と協議の上、 その指示に従うこと。 |
10 | システム構成管理 | 受注者の作業範囲に係る構成管理を実施すること。構成管理状況を PMDA に報告するとともに、構成管理上の問題等がある場合や、PMDA から問題を指摘された場合は、その内容と対応策を PMDA に報告し、PMDA と協議の上、その指示に 従うこと。 |
11 | 体制管理 | 受注者の作業実施体制を管理すること。体制上の問題等がある場合や、PMDA から問題を指摘された場合は、その内容と対応策を PMDA に報告し、PMDA と協議の上、その指示に従うこと。また、作業実施体制を変更する場合は、PMDA と協議の上、承認を得た上で、プロジェクト実施計画書に記載した要員の役割分 担、責任分担、体制図等について速やかに更新し、PMDA に提出すること。 |
6 作業の実施に当たっての遵守事項
(1) 基本事項
受注者は、次に掲げる事項を遵守すること。
① 本業務の遂行に当たり、業務の継続を第一に考え、善良な管理者の注意義務をもって誠実に行うこと。
② 本業務に従事する要員は、PMDA と日本語により円滑なコミュニケーションを行う能力と意思を有していること。
③ 本業務の履行場所を他の目的のために使用しないこと。
④ 本業務に従事する要員は、履行場所での所定の名札の着用等、従事に関する所定の規則に従うこと。
⑤ 要員の資質、規律保持、風紀及び衛生・健康に関すること等の人事管理並びに要員の責めに起因して発生した火災・盗難等不祥事が発生した場合の一切の責任を負うこと。
⑥ 受注者は、本業務の履行に際し、PMDA からの質問、検査及び資料の提示等の指示に応じること。また、修正及び改善要求があった場合には、別途協議の場を設けて対応すること。
⑦ 次回の本業務調達に向けた現状調査、PMDA が依頼する技術的支援に対する回答、助言を行うこと。
⑧ 本業務においては、業務終了後の運用等を、受注者によらずこれを行うことが可能※となるよう詳細にドキュメント類の整備を行うこと。
※受注者のみが権利を有する排他的な独自技術や開発フレームワーク等を採用しないこと
(2) 機密保持、資料の取扱い
本業務を実施する上で必要とされる機密保持に係る条件は、以下のとおり。
① 受注者は、受託業務の実施の過程でPMDA が開示した情報(公知の情報を除く。以下同じ。)、他の受注者が提示した情報及び受注者が作成した情報を、本受託業務の目的以外に使用又は第三者に開示若しくは漏洩してはならないものとし、そのために必要な措置を講ずること。
② 受注者は、本受託業務を実施するにあたり、PMDA から入手した資料等については管理簿等により適切に管理し、かつ、以下の事項に従うこと。
⚫ 複製しないこと。
⚫ 用務に必要がなくなり次第、速やかにPMDA に返却又は消去すること。
⚫ 受託業務完了後、上記①に記載される情報を削除又は返却し、受注者において該当情報を保持しないことを誓約する旨の書類を PMDA に提出すること。
⚫ PMDA へ提示する電子ファイルは事前にウイルスチェック等を行い、悪意のあるソフトウェア等が混入していないことを確認すること
⚫ 本業務において取り扱う情報の漏洩、改ざん、滅失等が発生することを防止する観点から、情報の適正な保護・管理対策を実施するとともに、これらの実施状況について、PMDA が定期又は不定期の検査を行う場合においてこれに応じること。万一、情報の漏洩、改ざん、滅失等が発生した場合に実施すべき事項及び手順等を明
確にするとともに、事前に PMDA に提出すること。また、そのような事態が発生した場合は、PMDA に報告するとともに、当該手順等に基づき可及的速やかに修復すること。
③ 応札希望者についても上記①及び②に準ずること。
④ 「独立行政法人 医薬品医療機器総合機構 情報システム管理利用規程」の第 52 条に従うこと。
⑤ 「秘密保持等に関する誓約書」を別途提出し、これを遵守しなければならない。
⑥ 機密保持の期間は、当該情報が公知の情報になるまでの期間とする。
⑦ 機密保持及び資料の取扱いについて、適切な措置が講じられていることを確認するため、PMDA が遵守状況の報告や実地調査を求めた場合には応じること。
(3) 遵守する法令等
本業務を実施するにあたっての遵守事項は、以下のとおり。
① 受注者は、本業務の遂行に当たっては、民法、刑法、著作xx、不正アクセス行為の禁止等に関する法律、行政機関の保有する個人情報の保護に関する法律等の関連法規及び労働関係法令を遵守すること。
② 受注者は、次の文書に記載された事項を遵守すること。遵守すべき文書が変更された場合は変更後の文書を遵守すること。
ア 独立行政法人 医薬品医療機器総合機構 サイバーセキュリティポリシー
イ 独立行政法人 医薬品医療機器総合機構 情報システム管理利用規程
ウ 独立行政法人 医薬品医療機器総合機構 個人情報管理規程
なお、「独立行政法人 医薬品医療機器総合機構 サイバーセキュリティポリシー」は非公開であるが、「政府機関等のサイバーセキュリティ対策のための統一基準(最新 版)」に準拠しているので、必要に応じ参照し、その内容を取り込むこと。
「独立行政法人 医薬品医療機器総合機構 サイバーセキュリティポリシー」の開示については、入札説明会に参加した事業者のうち、事業者がPMDA に「秘密保持等に関する誓約書」を提出した際に開示する。
7 成果物の取扱いに関する事項
(1) 知的財産権の帰属
知的財産の帰属は、以下のとおり。
① 本件に係り作成・変更・更新されるドキュメント類及びプログラムの著作権(著作xx第 21 条から第 28 条に定めるすべての権利を含む。)は、受注者が本件のシステム開発の従前より権利を保有していた等の明確な理由により、あらかじめ書面にて権利譲渡不可能と示されたもの以外、PMDA が所有する等現有資産を移行等して発生した権利を含めてすべてPMDA に帰属するものとする。
② 本件に係り発生した権利については、受注者は著作者人格権(著作xx第 18 条から第
20 条までに規定する権利をいう。)を行使しないものとする。
③ 本件に係り発生した権利については、今後、二次的著作物が作成された場合等であっても、受注者は原著作物の著作権者としての権利を行使しないものとする。
④ 本件に係り作成・変更・修正されるドキュメント類及びプログラム等に第三者が権利を有する著作物が含まれる場合、受注者は当該著作物の使用に必要な費用負担や使用許諾契約に係る一切の手続きを行うこと。この場合は事前にPMDA に報告し、承認を得ること。
⑤ 本件に係り第三者との間に著作権に係る権利侵害の紛争が生じた場合には、当該紛争の原因が専らPMDA の責めに帰す場合を除き、受注者の責任、負担において一切を処理すること。この場合、PMDA は係る紛争の事実を知ったときは、受注者に通知し、必要な範囲で訴訟上の防衛を受注者にゆだねる等の協力措置を講ずる。なお、受注者の著作又は一般に公開されている著作について、引用する場合は出典を明示するとともに、受注者の責任において著作者等の承認を得るものとし、PMDA に提出する際は、その旨併せて報告するものとする。
(2) 契約不適合責任
① 受注者は本業務の納入成果物に対する契約不適合責任を負うものとする。本業務の最終検収後 1 年以内の期間において、委託業務の納入成果物に関して仕様書と異なる、または契約目的に照らして通常期待される条件を満たしていない等本システムの正常な稼動等に関わる契約不適合の疑いが生じた場合であって、PMDA が必要と認めた場合は、受注者は速やかに契約不適合の疑いに関して調査し回答すること。調査の結果、納入成果物に関して契約不適合等が認められた場合には、受注者の責任及び負担において速やかに修正を行うこと。なお、修正を実施する場合においては、修正方法等について、事前にPMDA の承認を得てから着手すると共に、修正結果等について、PMDA の承認を受けること。
② 受注者は、契約不適合責任を果たす上で必要な情報を整理し、その一覧を PMDA に提出すること。契約不適合責任の期間が終了するまで、それら情報が漏洩しないように、 ISO/IEC27001 認証(国際標準規格)又は JISQ27001 認証(日本産業企画)に従い、また個人情報を取り扱う場合には JISQ15001(日本産業企画)に従い、厳重に管理をすること。また、契約不適合責任の期間が終了した後は、速やかにそれら情報をデータ復元ソフトウェア等を利用してもデータが復元されないように完全に消去すること。データ消去作業終了後、受注者は消去完了を明記した証明書を作業xxとともにPMDA に対して提出すること。なお、データ消去作業に必要な機器等については、受注者の負担で用意すること。
(3) 検収
納入成果物については、適宜、PMDA に進捗状況の報告を行うとともに、レビューを受けること。最終的な納入成果物については、別紙2「各タスク役割分担詳細」に記載のすべてが揃っていること及びレビュー後の改訂事項等が反映されていることを、PMDA が確認し、これらが確認され次第、検収終了とする。
なお、以下についても遵守すること。
① 検査の結果、納入成果物の全部又は一部に不合格品を生じた場合には、受注者は直ちに引き取り、必要な修復を行った後、PMDA の承認を得て指定した日時までに修正が反映されたすべての納入成果物を納入すること。
② 「納入成果物」に規定されたもの以外にも、必要に応じて提出を求める場合があるので、作成資料等を常に管理し、最新状態に保っておくこと。
③ PMDA の品質管理担当者が検査を行った結果、不適切と判断した場合は、品質管理担当者の指示に従い対応を行うこと。
8 入札参加資格に関する事項
(1) 入札参加要件
応札希望者は、以下の条件を満たしていること。
① 開発責任部署は ISO9001 又はCMMI レベル 3 以上の認定を取得していること。
② ISO/IEC27001 認証(国際標準)又は JISQ27001 認証(日本工業標準)のいずれかを取得していること。
③ PMDA にて現行関連システムの設計書等を閲覧し、内容を十分理解していること。
④ 応札時には、開発する機能毎に十分に細分化された工数、概算スケジュールを含む見積り根拠資料の即時提出が可能であること。なお、応札後に PMDA が見積り根拠資料の提出を求めた際、即時に提出されなかった場合には、契約を締結しないことがある。
(2) 入札制限
情報システムの調達のxx性を確保するために、以下に示す事業者は本調達に参加できない。
① PMDA のCIO 補佐が現に属する、又は過去 2 年間に属していた事業者等
② 各工程の調達仕様書の作成に直接関与した事業者等
③ 設計・開発等の工程管理支援業者等
④ ①~③の親会社及び子会社(「財務諸表等の用語、様式及び作成方法に関する規則」
(昭和 38 年大蔵省令第 59 号)第 8 条に規定する親会社及び子会社をいう。以下同じ。)
⑤ ①~③と同一の親会社を持つ事業者
⑥ ①~③から委託を請ける等緊密な利害関係を有する事業者
9 情報セキュリティ管理
(1) 情報セキュリティ対策の実施
受注者は、以下を含む情報セキュリティ対策を実施すること。また、その実施内容及び管理体制についてまとめた情報セキュリティ管理計画書を受注後速やかに提出して PMDA
の承認を受けること。
① PMDA から提供する情報の目的外利用を禁止すること。
② 受注者側の情報セキュリティ対策の実施内容及び管理体制が整備されていること。
③ 本業務の実施に当たり、受注者又はその従業員、本調達の役務内容の一部を再委託する先、若しくはその他の者により、PMDA の意図せざる変更が加えられないための管理体制が整備されていること。
④ 受注者の資本関係・役員等の情報、本業務の実施場所、本業務従事者の所属・専門性
(情報セキュリティに係る資格・研修実績等)・実績及び国籍に関する情報提供を行うこと。具体的な情報提供内容については PMDA と協議の上、決定するものとする。
⑤ 情報セキュリティインシデントへの対処方法(対処手順、責任分界、対処体制、対応時間、情報伝達時間・手段等)が確立されていること。
⑥ 情報セキュリティ対策その他の契約の履行状況を定期的に確認し、PMDA へ報告すること。
⑦ 情報セキュリティ対策の履行が不十分である場合、その原因について調査・排除するため、PMDA による追跡調査や立ち入り検査等について連携・協力する体制が構築できていること。また速やかに改善策を提出し、PMDA と協議の上、その指示に従うこと。
⑧ 本業務に係る業務の遂行における情報セキュリティ対策の履行状況を確認するために、
PMDA が必要と判断した場合は、速やかに情報セキュリティ監査を受入れること。
⑨ 本調達の役務内容を一部再委託する場合は、再委託されることにより生ずる脅威に対して情報セキュリティが十分に確保されるように上記①~⑧に関する事項を記載した情報セキュリティ管理計画書を作成し、PMDA の承認を受けること。
⑩ PMDA から要保護情報を受領する場合は、予め PMDA と合意した情報セキュリティに配慮した受領及び管理方法にて行うこと。
⑪ PMDA から受領した要保護情報が不要になった場合は、これを確実に返却、又は抹消し、書面にて報告すること。
⑫ 本業務において、情報セキュリティインシデントの発生又は情報の目的外利用等を認知した場合は、速やかにPMDA に報告すること。
(2) 情報セキュリティ監査の実施
① PMDA が必要と判断した場合は、その実施内容(監査内容、対象範囲、実施等)を定めて、情報セキュリティ監査等を行う(PMDA が選定した事業者による監査を含む。)ものとする。受注者は、あらかじめ情報セキュリティ監査等を受け入れる部門、場所、時期、条件等を「実施計画書」に付記し提示すること。
② 受注者は自ら実施した外部監査についてもPMDA へ報告すること。
③ 受注者は、情報セキュリティ監査の結果、本調達における情報セキュリティ対策の履行状況についてPMDA が改善を求めた場合には、PMDA と協議の上、必要な改善策を立案して速やかに改善を実施するものとする。
④ 本調達に関する監査等が実施される場合、受注者は、技術支援及び情報提供を行うこと。
⑤ 受注者は、指摘や進捗等把握のための資料提出依頼等があった場合は、PMDA と協議の上、内容に沿って適切な対応を行うこと。
情報セキュリティ監査の実施については、本項に記載した内容を上回る措置を講ずることを妨げるものではない。
10 再委託に関する事項
(1) 再委託の制限及び再委託を認める場合の条件
① 受注者は、受託業務の全部又は主要部分を第三者に再委託することはできない。
② プロジェクト管理責任者を再委託先事業者の社員とすることはできない。
③ ①における「主要部分」とは、以下に掲げるものをいう。
ア 総合的な企画及び判断並びに業務遂行管理イ 手法の決定及び技術的判断
ウ SLCP-JCF2013 の 2.3 開発プロセス、及び 2.4 ソフトウェア実装プロセスで定める各プロセスで、以下に示す要件定義・基本設計工程に相当するもの。
・ 2.3.1 プロセス開始の準備
・ 2.3.2 システム要件定義プロセス
・ 2.3.3 システム方式設計プロセス
・ 2.4.2 ソフトウェア要件定義プロセス
・ 2.4.3 ソフトウェア方式設計プロセス
ただし、以下の場合には再委託を可能とする。
・ 補足説明資料作成支援等の補助的業務
・ 機能毎の工数見積において、工数が比較的小規模(本調達における工数全体の 2 分の 1 以下を目安とし、PMDA が事前に承認したもの)であった機能に係るソフトウェア要件定義等業務
④ 再委託先が「8(2)入札制限」の要件を満たすこと。
⑤ 受注者の責任において、サプライチェーンリスクの発生を未然に防止するための体制を確立すること。
⑥ 再委託における情報セキュリティ要件については以下のとおり。
・ PMDA から提供する情報の目的外利用を禁止すること。
・ 受注者は、再委託先における情報セキュリティ対策、及びその他の契約の履行状況の確認方法を整備し、PMDA へ報告すること。
・ 受注者は再委託先における情報セキュリティ対策の履行状況を定期的に確認すること。また、情報セキュリティ対策の履行が不十分な場合、その原因について調査・排除するため、PMDA による追跡調査や立ち入り検査等について連携・協力する体制が構築できていること。また、その対処方法を検討し、PMDA へ報告すること。
・ 受注者は、情報セキュリティ監査を実施する場合、再委託先も対象とするものとする。
・ 受注者は、再委託先が自ら実施した外部監査についても PMDA へ報告すること。
・ 受注者は、委託した業務の終了時に、再委託先において取り扱われた情報が確実に返却、又は抹消されたことを確認すること。
(2) 承認手続
受注者は、受託業務を再委託する場合、予め再委託の相手方の商号又は名称及び住所並びに再委託を行う業務の範囲、再委託の必要性(及び契約金額)について記載した「再委託に関する承認申請書」を提出し、PMDA の承認を受けること。
申請にあたってあ、次に掲げる事項を遵守すること。
・再委託先が「9(1)情報セキュリティ対策の実施」の要件を満たしていることを証明する書面※及び受注者と再委託先との委託契約書の写し及び委託要領等の写しを、「再委託に関する承認申請書」に添付して提出すること。
※情報セキュリティに関する管理体制と管理基準、社内規程が整備されている事実を証明する書面。(例:管理体制図、社内規程、ISO 認証、外部監査実績、等)
・再委託の相手方は「8(2)入札制限」の対象となる事業者でないこと。
・受注者は、機密保持、知的財産権等に関して本仕様書が定める受注者の責務を再委託先業者も負うよう、必要な処置を実施し、PMDA に報告し、承認を受けること。
・受注者は再委託先の資本関係・役員等の情報、委託事業の実施場所、委託事業従事者の所属・専門性(情報セキュリティに係る資格・研修実績等)・実績及び国籍に関して、 PMDA から求めがあった場合には情報提供を行うこと。
(3) 再委託先の契約違反
再委託先において、本調達仕様書の遵守事項に定める事項に関する義務違反又は義務を怠った場合には、受注者が一切の責任を負うとともに、PMDA は、当該再委託先への再委託の中止を請求することができる。
11 その他特記事項
(1) 環境への配慮
環境への負荷を低減するため、以下に準拠すること。
① 本件に係る納入成果物については、最新の「国等による環境物品等の調達の推進等に関する法律(グリーン購入法)」に基づいた製品を可能な限り導入すること。
② 導入する機器等がある場合は、性能や機能の低下を招かない範囲で、消費電力節減、発熱対策、騒音対策等の環境配慮を行うこと。
(2) その他
PMDA 全体管理組織(PMO)が担当課に対して指導、助言等を行った場合には、受注者もその方針に従うこと。
12 附属文書
(1) 調達仕様書 別紙
別紙1 「作業スケジュール」
別紙2 「各タスク役割分担詳細」 別紙3 「拠出金システム開発要件」
別紙4 「外部インターフェース要件」別紙5 「非機能要件」
別紙6 「情報セキュリティ対策の運用要件」別紙7 「SLA 項目」
(2) 事業者が閲覧できる資料一覧
閲覧資料1 「独立行政法人 医薬品医療機器総合機構サイバーセキュリティポリシー」
閲覧資料2 「PMDA 情報セキュリティインシデント対処手順書」閲覧資料3 「セキュリティ管理要件書(ひな型)」
閲覧資料4 「Pegasus 設計書一式」
閲覧資料5 「Gateway 設計書一式」閲覧資料6 「情報システム台帳」
閲覧資料7 「主要ソフトウェア一覧」
13 窓口連絡先
独立行政法人 医薬品医療機器総合機構 BPR・DX 推進室 斉藤電話:03 (3506) 9600
Email:saito-takashi●pmda.go.jp
(※迷惑メール防止対策のため●を半角のアットマークに置き換えてください。)
以 上
別紙1.作業スケジュール(想定)
凡例
計画書
作成
総合
テスト
要件
確認
基本設計
詳細
設計
開発・単体テスト
結合テスト
受入テスト
稼動
導入
本番
・拠出金システムオンライン化対応
5月
4月
3月
2月
1月
12月
11月
10月
9月
8月
7月
6月
5月
4月
2024年
2023年度
受注者作業
PMDA作業
「※上記は想定であり、詳細についてはプロジェクト実施計画時に協議すること」
別紙2
■各タスク役割分担詳細(想定)
フェーズ | 位置づけ | PMDA | 受注者 | 事業者に求める納入成果物 (最低限、適宜追加) | 備考 | ||
計画策定~ | 各種計画、方針書作成 | ・各計画書・方針書の作成を、該当タスクが始まる前に、計画書・方針書を事前に作成しする。 | ・作業スケジュール(想定)のPMDA作業について、PMDA側で該当計画書等を作成し、PMDA内の合意を取る。 ・作業スケジュール(想定)の受注者作業について、レビューを行う。 | ・作業スケジュール(想定)の受注者作業について、プロジェクト実施計画書を作成し、プロジェクト関係者の合意を取る。 | ・プロジェクト実施計画書(案) ・進捗会議等定例会資料 ・議事録 | 納入成果物の作成にあたっては、SLCP-JCF2013(共通フレーム2013)を参考とすること。 | |
ファイル共有サービスに係る基礎トレーニング | ・ファイル共有サービスにおけるAPIの仕様等に関して基礎的な知識を 身に着ける。 | ・基礎トレーニングに同席する。 | ・ファイル共有サービス提供者及びPMDAと調整し基礎トレーニングを 受講する。 | ・基礎トレーニング受講記録 | |||
計画策定 | ・稼働に至るまでの各フェーズごとの目的・タスク・役割・体制などを示したプロジェクト計画書を作成する。 | ・プロジェクト実施計画書のレビュー及びキックオフへの参加する。 | ・プロジェクト実施計画書を作成し、キックオフを開催する。 ・他システム提供者についても適宜キックオフに招集する | ・プロジェクト実施計画書 ・進捗会議等定例会資料 ・議事録 | |||
要件確認 | 要件確認書作成 | ・調達仕様書、公示時の閲覧資料等において不明確であった部分について要件の確認を行う | ・受注者から提示される不明点等について、機能要件を具体的に伝え、その結果が反映される要件確認書の妥当性をレビューする。 ・要件確認書を踏まえた上で、修正される機能一覧を確認し、機能の充足性・妥当性をレビューする。 ・合わせて非機能要件として、性能・権限・移行等の情報をレビューする。 | ・調達仕様書の内容を確認し技術面、機能面において不明な点を明らかにするとともにPMDAに実現方式を示し、要件確認書としてレビューを受けること。機能面の実現方式について不明な点があれば PMDAに確認し、機能一覧としてまとめてPMDAのレビューを受けること。技術面のうち、別途PMDAが契約するファイル共有サービス及び決済代行サービスに係る不明点については、サービス提供者に直接確認することも可能だが、確認方法等についてはPMDAと調整の上対応すること。 ・非機能要件として、調達仕様書に記載されている内容を踏まえて、 Pegasus基盤上で備えているバックアップ機能等を使用し、どのように非機能要件を満たすかを整理しPMDAのレビューを受けること。 | ・要件確認書 ・機能一覧 ・非機能要件定義書 | ||
基本設計 | (業務) | 基本設計 | ・調達仕様書、公示時閲覧資料、要件確認書に基づき、基本設計を実施する。 ・基本設計としては機能ごとに基本事項(機能要件、業務領域、利用者、利用頻度、連携機能等)に加えて、画面仕様、インプット /アウトプットの定義を行う。 ・非機能となる権限・メニュー・JOB・テストや移行等のスケジュール、役割分担、タスクを明確にする。 | ・受注者から提出される新機能の基本設計書をレビューする。 ・非機能要件となるテストや移行等の計画資料をレビューする。 ・他システム連携、外部機関連携で、連携方式・連携ファイルが変更となる対象を洗出し、変更となる他システム・外部機関へ共有・調整を実施する。 | ・調達仕様書、公示時閲覧資料、要件確認書に基づき、必要に応じて新機能の基本設計書を作成し、PMDAのレビューを受ける。 ・必要に応じて権限設計書を作成し、PMDAのレビューを受ける。 ・非機能要件設計資料を作成し、PMDAのレビューを受ける。 | ・パラメータ設定書 ・基本設計書 ・権限設計書 ・メニュー設計書 ・JOB定義書 ・非機能要件設計資料 ・(システム機能一覧) ・(データ項目群一覧) | |
(インフラ) | インフラ環境設定 | ・インフラ基盤に関して、新システムに必要な設定を行う。 | ・新システムのインフラ環境の最終的なリソース情報、設定情報を受注者から説明を受けレビューする。 ・インフラ基盤の構築、設定を行う。 | ・新システムのインフラ環境の最終的なリソース情報、設定情報を新システム機器仕様・設定仕様書として纏めて、PMDAのレビューを受ける。 | ・新システム機器仕様・設定仕様書 | ||
設計・開発 | 詳細設計 | ・内部処理については、詳細設計として詳細設計書を合わせて作成する。 | ・基本設計書に基づき詳細設計(詳細ロジックを定義)を作成する。 ・他システムとの連携が発生する部分については、適宜他システム提 供者に相談し、レビューを受ける。 | ・詳細設計書 | |||
開発・単体テスト | ・新機能の開発、及び単体テストを行う。 | ・基本設計書、詳細設計書に基づき、プログラム開発を行う。 ・完成したプログラムについて、作成した単体テスト計画書を元に単体テスト実施・不具合改修を行い、単体テスト結果報告書を作成す る。 | ・単体テスト計画書 ・単体テスト結果報告書 | ||||
(インフラ) | インフラ環境等システム導入・設定 | ・インフラ環境へ必要なパラメータ設定等を行う。 | ・PMDAで用意したインフラ機器へ導入・設定する内容について、受注者から提出される新システム導入設定書をレビューする。 | ・PMDAが用意したインフラ環境へ必要な設定を新システム導入設定仕様書として作成し、PMDAのレビューを受ける。 ・承認された内容で各環境ごとに動作確認を行う。 | ・新システム導入設定仕様書 | ||
テスト・移行 | 結合テスト | ・新業務フローベースに即した、テストデータを使用し、権限割り当てを行わず、PKG内/システム内に閉じた形での、全機能単体・機能間 連携やデータフローが正しく動作し、一連の業務(年間業務)が問題無く行えることを検証する。 ①業務:新業務フローに基づき一連の業務が正しく行えること。新機能が正しく連携して動作すること ②I/F:システム内のI/F機能が正しく動作し、データ連携が行えること ③ジョブ:あり ➃権限:あり ⑤データ:テストデータ | ・受注者から提出される結合テスト計画書・テストシナリオをレビューする。 ・受注者から提出される結合テスト結果報告書をレビューする。 | ・PKG内/システム内に閉じた、新機能間の結合テスト計画書・シナリオを作成し、PMDAのレビューを受ける。 ・テストシナリオに基づきテスト実施、不具合改修、再テスト等を行う。 ・テスト結果を纏めて、結合テスト結果報告書を作成し、PMDAのレビューを受ける。 | ・結合テスト計画書 ・結合テストシナリオ ・結合テスト結果報告書 | ||
総合テスト | 業務シナリオ | ・新業務フローベースに即した、実データ(移行データ)を使用し、業務上の権限を割り振った形でJOB実行等を行い、機能間連携・他システム間連携・外部機関連携やデータフローが正しく動作し、一連の業務(年間業務)が問題無く行えることを検証する。 ※実際の本番想定で実施する。 ①業務:新業務フローに基づき一連の業務が正しく行えること。新機能が正しく連携して動作すること ②I/F:システム内・システム跨ぎのI/F機能が正しく動作し、データ連携が行えること ③ジョブ:ジョブが正しく実行されること ➃権限:権限要件がが正しく実装されていること ⑤データ:移行データを使用し、業務が行えること | ・受注者から提出される総合テスト計画書・シナリオをレビューする。 ・テストシナリオに他システム間連携・外部機関テストのシナリオを追加加筆し、対象となる他システム・外部機関と調整を行う。 ・受注者から提出される総合テスト結果報告書をレビューする。 ・他システム間連携の事業者間調整、検証環境や本番環境でテストを実施する場合の各種調整を行う。 | ・他システム間連携を含み、実データ(移行データ)・実権限・JOB実行を含む本番想定での、総合テストテスト計画書・シナリオを作成し、PMDAのレビューを受ける。 ・テストシナリオに基づきテスト実施、不具合改修、再テスト等を行う。他システムに係る問合せについて、当該システム提供者に問合せを行う。 ・テスト結果を纏めて、総合テスト結果報告書を作成し、PMDAのレビューを受ける。 | ・総合テスト計画書 ・総合テストシナリオ ・総合テスト結果報告書 |
性能評価(パフォーマンス) | ・新システムで求められる性能(パフォーマンス)を実データボリューム・実権限を用いて実機性能テストを実施する。 | ・受注者から提出されるテスト計画書をレビューする。 ・受注者から提出されるテスト結果報告書をレビューする。 | ・性能評価を行う機能を選定し、計画書(対象機能・想定パフォーマンス結果等)を作成し、PMDAのレビューを受ける。 ・テスト対象機能のパフォーマンスを実施し、チューニング、再テスト等を行う。 ・テスト結果を纏めて、総合テスト結果報告書を作成し、PMDAのレビューを受ける。 | ・総合テスト計画書(性能) ・総合テスト結果報告書(性能) | ||||
受入テスト | ・PMDAによる最終オペレーションテストとして、新業務フローベースに即した、実データ(移行データ)を使用し、業務上の権限を割り振った形でJOB実行等を行い、機能間連携・他システム間連携やデータフローが正しく動作し、イレギュラーパターンを含む、一連の業務(年間業務)が問題無く行えることを検証する。 ※実際の本番想定で実施する。 | ・総合テストシナリオを参考にし、業務運用上のイレギュラーテストを加筆する形で、受入テスト業務シナリオを作成する。 ・テストシナリオに基づきテストを行う。 ・テスト結果を纏めて、受入テスト結果報告書を作成する。 | ・PMDAが受入テストシナリオを作成する上での、QA対応を行う。 ・PMDAが受入テストを行う上での、サポート・QA対応を行う。 ・本番運用でもPMDAユーザーが実行しないJOB等の実行を行う。 ・テストを行う上で必要となるデータ作成を行う。 ・不具合等が発生した場合に、不具合改修を行う。 | ・受入テストQA対応表 | ||||
①業務:新業務フローに基づき一連の業務が正しく行えること。新機能が正しく連携して動作すること ②I/F:システム内・システム跨ぎのI/F機能が正しく動作し、データ連携が行えること ③ジョブ:ジョブが正しく実行されること ➃権限:権限要件がが正しく実装されていること ⑤データ:移行データを使用し、業務が行えること | ||||||||
・受入テスト結果から、新システムの検収を行う。 | ||||||||
運用テスト | ・バックアップ、耐障害性、監視機能等の運用機能の正常動作を確認する為、運用テスト計画書に基づき、テストを実施し、運用テスト結果報告書を纏める | ・受注者から提出されるテスト計画書をレビューする。 ・受注者から提出されるテスト結果報告書をレビューする。 | ・運用テスト計画書を作成し、PMDAのレビューを受ける。 ・運用・保守計画及び手順通り操作等できることを確認するため、運用・保守テスト計画書、テスト仕様書を作成しテストを行う。 ・テスト結果を纏めて、運用・保守テスト結果報告書を作成し、 PMDAのレビューを受ける。 | 運用・保守テスト計画書運用・保守テスト報告書 | ||||
業務移行 | 業務移行整理・業務切替計画 | ・現行業務から新業務への切替スケジュール、関係者への周知タイミング等の計画を策定する | ・業務切り替えに伴う、関係間周知方法、周知タイミング、周知時期を明確化し、計画書を作成し、関係者間の合意を得る。 ・業務切り替えが必要となる、個別業務について担当者に周知を行い、必要に応じてマニュアル改定を実施する。 ・切替に伴う、規定変更を切替日までに対応する。 ・エンドユーザ問合せ窓口を明確化するとともに、窓口担当者への教育、インシデント作成方法、エスカレーション方法を定めておく。 | ・必要に応じてPMDAのフォローを行う。 | ||||
教育 | 操作マニュアル業務マニュアル 教育コンテンツ準備教育実施 | ・PMDA実務担当者・職員向けに教育研修会を実施し、ユーザーの習熟を図る。 ・教育研修環境を用意し、必要に応じて対面・リモートのどちらも対応できるようにする。 | ・教育計画書作成し、教育コンテンツを定め研修対象の職員を選定して、日程調整を行う。 ・新システムを利用した業務運用マニュアルを作成する。 ・PMDA実務担当者・職員向けの教育研修資料を作成し、教育研修会を主催し説明会を行い、参加者のフォローを行う。 ・受注者から提出される操作マニュアルをレビューする。 | ・新システムで実装する標準機能/追加開発の画面操作マニュアルを作成し、PMDAのレビューを受ける。 ・教育研修環境を構築する。 ・教育研修会を前後で、PMDA主催者・参加者向けにフォローを行う。 | ・操作マニュアル | |||
保守・運用 | 保守運用方針検討保守運用設計 保守引継 | 新システム保守事業者調達に向けた、保守計画・保守作業設計を行う。 | ・受注者が提出する保守計画・保守作業設計書、手順書をレビューする。 ・新システム保守事業者を調達するための調達仕様書を作成し、調達手続きを行う。 | ・新システムにおける保守計画・保守作業設計、手順書を纏めて、保守計画書、保守作業設計書をPMDAへ提出し、PMDAのレ ビューを受ける。 | ・保守運用計画書 ・保守設計書及び手順書 |
別紙 3 拠出金システム開発要件
1. ファイル共有サービス(以下、Box という)連携機能の追加
別途機構で調達する Box を使用して、申告者と申告書類の受け渡しおよび Box に対する権限付与等を行うことを目的とし、以下の対応を行うこと。対応に当たっては、他システム連携となることから、ジョブ管理機能を利用したディレイドオンラインにて連携すること。また、会計システム連携の際に作成している管理画面を改修し、当該 Box連携にかかる連携状況等を確認できる管理機能を設けること。
なお、Box のインターフェース仕様については一般的に公開しているサービスを利用する予定であるため、インターネット上の情報を参考にすること。
(ア) フォルダ作成インターフェース機能の追加
Box のフォルダ構成として、基本的に業者番号ごと、年度ごとに構成されており、当該年度内において「申告依頼」および「入力済み」フォルダを配置する。
業者数が多いことから、手動で作成することが難しい状況であるため、期首処理時に当該インターフェースにおいて、業者番号ごとに、指定した年度のフォルダを作成し、その配下に「申告依頼」「入力済み」フォルダを作成する。
なお、年度の配下に作成するフォルダ名についてはマスタにて設定可能なようにすること。
(イ) 申告書類配置インターフェース機能の追加
拠出金システムにおける一括処理機能にて作成した業者毎の申告書類について、上記「フォルダ作成インターフェース」にて作成した年度毎の各フォルダ配下の
「申告依頼」フォルダに当該インターフェースを呼び出すことで申告書類を格納できるようにすること。また、ファイルの格納に成功したユーザに対して、対象ファイルに対するURL を含めたメールの通知を行うこと。
なお、取得先は(ア)でマスタ管理しているフォルダから取得できるようにすること。
(ウ) 申告書類取得インターフェース機能の追加
申告者が申告書に入力後、各業者番号の各年度の「入力済み」フォルダにファイルを格納するため、Box 内の当該フォルダを閲覧し、新たにファイルが格納されていることを確認し、ファイルが格納されていた場合はファイルを取得し、各審査画面で閲覧可能となるフォルダにファイル類を格納し、審査画面の入力用 Excel 取り込みと同じロジックにて取り込み処理も同時に行うこと。さらに後述する決済代行サービスより入金可能となるためのメール送信も自動で行うこと。
なお、当該インターフェースは定期的に全業者のフォルダを巡回するものと、臨時で審査画面からボタンをクリックすることで当該業者および年度のみ取得するためのボタンを配置しインターフェース機能を起動する2パターン存在するため、
それぞれ対応すること。
(エ) 登録アカウント取得インターフェース機能の追加
業者番号ごとに設定されているアクセス制御のためのアカウント情報(メールアドレスおよびアクセス権)について、全業者分一括で取得後データベースに保管する機能を作成すること。
(オ) アクセス権設定インターフェース機能の追加
登録されたメールアドレスおよびアクセス権について、審査画面にボタンを追加し、当該業者番号フォルダに対してアクセス権を付与するインターフェース機能を作成すること。アクセス権は対象となるメールアドレスがすでにセットされている場合は権限を上書きし、メールアドレスが存在しない場合は新たに権限を追加すること。
(カ) Box に格納されているファイル等確認インターフェース機能の追加
Box に格納されているフォルダおよびファイルについて現在のフォルダやファイルの格納状況を取得し、Excel 等のファイルに出力しマスタにて指定されるフォルダに出力すること。なお、本機能は定期的に実施するものとし、ジョブ管理機能に登録し実行されるようにすること。
2. 決済代行サービスとの連携機能の追加
別途機構で調達する決済代行サービスを活用し、現在納付書のみで行っている決済手続きに対して「コンビニ決済」「Pay-easy 決済」の2つの支払い方法を追加する予定である。決済代行サービスへのデータ連携については以下のプロセスで行う。
1.Box に登録された申告書類等を取得(Box のインターフェースにて実施)
2.申告書類から副作用、感染、安全それぞれの拠出金額を取得
3.拠出金の区分ごとに取引を一意に識別するための情報(以下、消込キー情報という)を生成および登録
4.消込キー情報および拠出金額等をパラメータとし、決済代行サービスを呼び出すための処理を行う。(決済代行サービスにより呼び出す方法が異なるため、詳細については決済代行サービスの仕様書を参考にすること。)
対応に当たっては、他システム連携となることから、ジョブ管理とし会計システム連携同様に管理画面を設け外部インターフェースとの連携状況等を確認できる管理機能を設けること。
連携を行うために必要な対応は以下の通り。
(ア) 共通
① 消込キー情報の作成および登録
決済代行サービスの取引結果や決済代行サービスからの入金などと紐づけを行うため、拠出金システム内のデータ(例えば、債権発生番号等)と決済代行
サービスの債権データとを関連付ける必要があるため、申告書類取り込み時に、当該債権に対して消込キー情報を生成し登録すること。消込キー情報で使用する項目数等については利用する決済代行サービスによって異なるため詳細は仕様書を確認すること。
(イ) 決済代行サービスへの誘導および支払い結果確認対応
① 申告者への支払い依頼メール通知機能の追加
Box から申告書を受領後、もしくは、審査画面に新たに配置するボタンをクリックすることで、以下の通り、決済代行サービスが提供する WEB 画面を呼び出すためのURL を記載したメールを送信できるようにすること。なお、決済代行サービスが提供する WEB 画面を呼び出す際はリダイレクト処理を行って呼び出す必要があるため、メールに記載されるURLは外部 WEB サーバにリダイレクト用のWEB画面を作成し、そのWEB画面を呼び出すようにすること。また、リダイレクト用のWEB画面については、セキュリティの観点からなるべく都度URLを生成しアクセスさせるようなものとし、一時的な URLとして生成できるようにすること。
1. メールの件名および文面について
メールの文言についてはメール文書および件名のひな型をマスタ等で管理し、動的に設定できる文言として、進捗一覧に表示される項目および業者番号に紐づくデータ項目を利用できるようにすること。
2. メールに記載される URL について
決済代行サービスが提供する WEB 画面を呼び出せる外部WEBサーバが提供するURL とすること。なお、必要なパラメータについては PMDAが提供するリダイレクトページを申告者に返す際にリダイレクト先に post でパラメータを渡すため、HTML ソース内に埋め込む形とすること。
3. 決済代行サービスに引き渡すためのパラメータについて
(ア) Box から申告書を取得した場合
Box から申告書(Excel)を取得し、各種取り込み処理を行うが、その際に合わせて決済代行サービスに引き渡すために必要なデータ、例えば、拠出金額の取得や消込キー情報を生成しパラメータとして利用すること。
(イ) 審査画面から任意に呼び出す場合
各画面においてボタンクリックした際にデータベースに保持している拠出金額の取得および消込キー情報を生成しパラメータとして利用すること。
② 申告者による支払い完了通知機能の追加
決済代行サービスが、申告者による支払い完了時に申告者に直接支払い完了
を通知する機能を具備していない場合、決済代行サービスから支払い完了の API 連携を受けて拠出金システムから申告者に支払い完了のメール通知ができるようにすること。メール通知にあたっては、API 連携で通知されるキー情報から拠出金システム内で該当する取引を検索し、当該取引に対応するメールアドレスを取得して当該メールアドレスに支払い完了メールを通知すること。メールの件名および文面については、支払い依頼通知機能と同様、マスタで管理できるようにすること。
③ 申告者による支払結果確認機能の追加
申告者にて決済代行サービスを利用して支払いをした場合、決済代行サービスに API 連携することで支払い確認を行えるケースと、決済代行サービスから拠出金システムに作られたページにアクセスし、その際に form 等に埋め込まれたパラメータを取得する形で決済代行サービスから送信されるケースの
2パターンで決済完了確認を行える。それぞれ消込キー情報が埋め込まれた状態でステータス等が連携されるため以下の通り支払い結果確認を行えるようにすること。
なお、コンビニ決済、Pay-easy 決済のいずれかが、いずれかの方式をとるため、1つの決裁で両方の方法で取得することはないようにすること。
1. 拠出金システム ⇒ 決済代行サービス
決済代行サービスにて具備する WebAPI をコールすることで、その戻り値を確認し支払い確認を行う。
この WebAPI については、ジョブ等で定期的に実行する、もしくは審査画面から個別に実行し、支払い確認を行えるようにすること。
コールする際に必要となるパラメータ等の受渡方法については決済代行サービスごとに異なるため、設計時に確認を行うこと。
2. 決済代行サービス ⇒ 拠出金システム
決済代行サービス側から拠出金システムにて作成する WEB ページにアクセスされることで決済完了を受け取れるケースがある。その場合、必要なパラメータ等は決済代行サービスにて post 形式で埋め込まれるため、それを受け取りサーバ側で処理できるようにすること。この際に、このページにアクセスできるのは決済代行サービス側のURL もしくはグローバル IP アドレスのみとするように Pegasus の FW の設定を行うこと。
④ 決済代行サービスから PMDA の口座への入金確認機能の追加
決済代行サービスから一定期間の間に入金されたものについて、まとまった形でPMDAの口座に入金されることになる。その場合、どの債権に対する入金かが振込人欄などからはわからないため、以下の対応を行うこと。
1. 決済代行サービスにて具備する管理画面からその振込がどの支払いのも
のかがわかる消込キー情報を含むリスト(以下、取引明細 CSV という)を手動でダウンロードし、Pegasus に手動でアップロードすることで、 Pegasus 内で保持する消込キー情報と突合させ判別できるようにする。
2. 取引明細 CSV をアップロードした情報等から会計連携するための CSV
データ(インターフェース)を作成すること。
3. 会計システム連携後に会計システムから送付される取込結果 CSV を受け取るためのインターフェースも作成し、Pegasus に取り込むこと。
なお、会計システムとのインターフェースの設計および実装においては、会計システムの担当者と調整の上対応すること。
3. 拠出金システムの改修
各インターフェース等の追加により収集した情報を利活用するための改修を以下の通り行うこと
(ア) Box から取得したメールアドレス情報の利活用
データベースに保存されたメールアドレスを審査画面内で表示、かつ、「メール送信」リンクも併せて表示しリンクをクリックすることで、メーラーの宛先欄にメールアドレスがセットされた状態でメーラーのメール送信画面が起動するようにすること。また、メールアドレス欄と合わせてアクセス権欄を追加し、メールアドレスと合わせて編集可能となるようにすること。
(イ) 手動支払い依頼通知機能の追加
基本的には自動的に決済代行サービスを呼び出し、支払い依頼通知を行うが、追徴等により個別に支払い額を計算して徴収するケースが存在する。そのような場合を想定し、審査画面から支払い依頼を行える子画面を作成し支払い依頼を行えるようにすること。その際に必要となる消込キー情報等の固定パラメータは裏で保持しつつ、支払期限日や取引額の変動する部分のみ設定し依頼をかけられるようにすること。
また、追徴等において前回入金分からの差額を依頼する場合が考えられるため、今回請求額との差額を算出し審査画面に参考値として副作用、感染、安全それぞれ表示する欄を設けること。
(ウ) 取引明細 CSV 取り込み機能の追加
一括処理機能の1つとして、決済代行サービスから提供される取引明細 CSV を取り込むための画面を作成すること。画面項目としては、入金番号(単一項目)の入力欄と、CSV アップロードを行える欄を用意し、両方登録されることで Pegasusに取り込めるようにすること。取り込んだデータについて以下の処理等を行えるようにすること。
① 取引明細 CSV には、消込キー情報が設定されているため、対応する債権デー
タを検索し「債権発生番号」を取得する。元の取引明細 CSV の項目と併せて管理項目の1つとして登録できるようにすること。
② 取り込んだデータおよび新たに付与した情報含め画面で確認できるようにし、検索等行えるようにすること。
③ 取込み完了後、取引日、債権発生番号、入金番号、金額に加え、必要な管理項目を追加したデータを会計連携するための CSV を作成し所定の場所に格納すること。なお、会計連携後に連携結果の CSV が出力されるため、従前の会計連携の際に管理する会計連携管理機能にて取り込み結果を管理できるようにすること。
(エ) 消込キー情報における任意に指定できる番号の発番機能の追加
消込キー情報については総合機構側で任意に決定できる番号があるため、その番号については Pegasus にて発番管理(連番)できるようにする。なお、期首処理のタイミングで番号をリセットできるように対応すること。
(オ) 各サービスからデータ取得等を行った際のステータス変更および追加対応
Box から申告書を受領した際や、決済代行サービスに入金確認がされた状態、取引明細 CSV 連携後に会計システムから結果を受け取ったタイミングにおいて、それぞれステータス遷移する必要があるため、その対応を行うこと。なお、決済代行サービスに入金確認がされた状態においては、今までにないステータス遷移となるため、新たにステータスを追加し、ステータス追加に伴う制御およびその前後のステータスに遷移する際の制御について設計時に確認の上対応すること。
決済代行サービスとの連携における入出金一覧への反映対応
決済代行サービスに入金された段階で入出金一覧においても入金処理として取り扱い、さらに、実際に機構の口座に入金されたことをもって、決済代行サービスに入金された内容について取り消しを行うなど、決済代行サービスが間に入ることで入出金一覧の処理の一部が変更になるため、入出金処理管理を適切に行えるようにすること。
(カ) 一斉メール通知機能の追加
Box から取得したアカウント情報(メールアドレス)を取得し、一斉同報通知を行うための機能を追加すること。具体的には、一斉同報通知を行うための件名、メール本文、メール発送開始日時等を入力できる画面を作成し、「メール送信申請」ボタンをクリックすることで管理者権限にメールにて許可依頼通知が送付され、同機能において管理者権限者すべてが「許可」ボタンをクリックすることで指定された日時に一斉にメールを送信できる機能とすること。なお、メール件名およびメール本文のテンプレートをマスタ等で管理し、定型文に関しては最初から入力することがないようにすること。また、今までに一斉同報通知を行ったものを検索できるようにするとともに一覧に表示、さらに各レコードに「詳細」ボタンを設け「詳
細」ボタンをクリックすることで詳細な内容が表示されるようにすること。なお、検索画面上で「新規作成」ボタンを配置し、そのボタンをクリックすることで通知メールを作成するための画面を呼び出せるようにすること。
メール本文、件名については、メールアドレスに紐づく業者マスタの各項目は変数として利用できるようにすること。
4. 当該改修にかかる帳票修正対応
決済代行サービス経由による決済方法が増えることにより、新規帳票および現時点で利活用している帳票に対して修正が発生する。既存帳票に対して、個別設計にて作成している5帳票、汎用帳票にて作成している5帳票について修正を行い、また、新規に個別設計にて作成する2帳票、汎用帳票にて新規に2帳票作成する予定であるため、設計時に内容確認の上対応すること。
5. 総合機構担当者向けおよび申告者向け操作マニュアル等の整備
総合機構担当者向け操作マニュアルについては、既存システムとして存在するが、その 操作マニュアル内に今回の改修において変更となる個所について追記修正等行うこと。なお、Box や決済代行サービスを利用する業務が発生する場合、操作マニュアル内に業 務上必要となるサービスを使用する部分についても記載すること。(業務上使用しない 操作に関する機能等に関してはマニュアルに記載する必要はない。)
また、申告者向けに対しても、各種サービスを含め申告をするまでの操作や入金等を行うための各種サービスの操作など、画面イメージを含めつつ、わかりやすい操作マニュアルを作成すること。
6. オンライン申告を行うための説明用動画の作成対応
申告者向けにテスト利用できるオンライン環境を用意しないため、実際の操作感が得られない状況である。そのため、申告者がマニュアルだけでは補えない実際の動きや操作感を得られるよう説明用動画を作成すること。動画作成にあたり構成等について本業務実施者にて提案を行い、総合機構担当者と調整の上作成すること。動画作成に必要な機材やソフトウェア等については本業務実施者の負担と責任において用意し作成後は総合機構に納品すること。なお、作成した動画は総合機構が保持している Youtube チャンネルに登録するため、動画ファイルについては Youtube にアップロードできる形式で納品すること。また、動画作成にあたり収集した素材等についても併せて納品すること。
7. 各システム間の調整支援業務
「Box」「決済代行サービス」「会計システム」の3つの他システムとの連携が発生し、
構築期間中においては様々な状況で調整等を行う必要が発生する。他システムとの設計やテスト等にかかる調整においては機構担当者が実施するが、調整が必要な事項や調整内容等については本業務実施者が主体的に検討および洗い出しを行い、他システムの担当者を含む関係者とスムーズに調整が可能となるよう支援および対応を行うこと。
なお、「Box」の調達においては、以下の支援を受けられる想定であるため、必要に応じて活用すること。
1.Kickoff Meeting への参加(最大 1h×2 回程度)
2.基礎トレーニング(最大 1h×2 回程度)
3.アーキテクチャー相談・レビューセッション(最大 2h×4 回程度)
・ビジネス要件・機能要件・非機能要件の確認、設計文書の確認
・アプリケーションのホスティング環境、ネットワーク
・認証/トークン取得、キャッシングサービス、ログや監視サービスとの連携
・アカウント、フォルダ構成、スケールリミット(Box の各種閾値)の考慮
・API コール箇所のデザイン
4.Weekly Meeting(Q&A、課題またはプロジェクトステータスの共有)への参加
(最大 1h×12 回程度:3 ヶ月間)
5.API 基礎資料の提供
6.上記以外のQA 対応(最大 50 時間程度:3 ヶ月間)
※いずれの支援も日本語でのコミュニケーションが前提
※いずれの会議もリモートで、平日営業時間内(9:00-18:00)の想定
8. 他システムとのテスト実施にかかる費用について「Box」「決済代行サービス」「会計システム」について検証環境は総合機構にて準備するが、検証を行うにあたり必要な作業等については本業務実施者の負担と責任により行うこと。なお、「会計システム」については必要な事項等を総合機構担当者に依頼することで、総合機構担当者が会計システム運用支援業者に依頼し対応してもらうこととする。
9. 拠出金システムの Pegasus 移行にかかる設計書およびプログラムのマージ作業
令和5年8月末まで対応している当該案件において、Phase1(5月末リリース)、Phase2
(8月末リリース)の計画で対応している。そのため、本業務において要件確認および設計また一部プログラムにおいては対応期間が重複するため Pegasus 移行プロジェクトの状況を把握し適切に設計書等についてマージ処理を行うこと。
別紙4
:外部インターフェース要件
# | 相手システム | インターフェース対象データ | 入出力 | 連携方 式 | 発生頻度 | 備考 |
1 | Box | フォルダ作成インターフェース | 出力 | WebAP I | 年1回程度 | 期末期首処理後に、オンライン申告を希望する業者に対して一斉にBoxに対して各業者毎のフォルダを作成する。 主な連携情報(案) ・業者番号 ・年度 ・フォルダパス ・作成するフォルダ名 ※権限は上位フォルダの権限を継承する |
2 | Box | 申告書類配置インターフェース | 出力 | WebAP I | 年1回程度 | 上記フォルダ作成インターフェースにて作成されたフォルダに対して申告書類を配置する。そのため、期末期首処理後の当該インターフェース実行にあたっては希望する業者数分実行する。 主な連携情報(案) ・業者番号 ・フォルダパス ・申告書類(入力用Excel) ※申告書類へのアクセス権限はフォルダ権限を継承する |
3 | Box | 申告書類取得インターフェース | 入力 | WebAP I | 日一回程度 (場合によっては日に数回の可能性あり) | オンライン申告希望者がBoxに配置した申告書および証跡等のファイル類を取得する。 主な連携情報(案) ・業者番号 ・フォルダパス |
4 | Box | 登録アカウント取得インターフェース | 入力 | WebAP I | 日一回程度 (場合によっては日に数回の可能性あり) | 各業者毎のフォルダからアカウント情報およびアクセス権を取得する 主な連係情報(案) ・業者番号 ・メールアドレス ・アクセス権 |
5 | Box | アクセス権設定インターフェース | 出力 | WebAP I | 日一回程度 (場合によっては日に数回の可能性あり) | 各業者毎のフォルダに対して、審査画面で設定されたメールアドレスおよびアクセス権情報で設定を行う 主な連係情報(案) ・業者番号 ・メールアドレス ・アクセス権 |
6 | Box | Boxに格納されているファイル等確認インターフェース | 入力 | WebAP I | 日一回程度 (場合によっては日に数回の可能性あり) | Boxに格納されているフォルダおよびファイル等の一覧を作成する 主な連携情報(案) ・フォルダパス |
7 | 決済代行サービス | 申告者への払い込みメール通知機能 | 出力 | WebAP I | 年1回程度 もしくは審査画面で要求の都度 | 会計システムに取り込まれた入金データの消込状況が通知される。 主な連係情報(案) ・口座番号(副・感・安) ・業者番号 ・入金額 ・消込結果 |
8 | 決済代行サービス | 申告者による支払結果確認機能① | 入力 | WebAP I | 日一回程度 (場合によっては日に数回の可能性あり) | 決済代行サービスにて入金した情報を取得する (拠出金システム⇒決済代行サービス) 主な連係情報(案) ・消込キー情報 ・業者番号 ・消込結果 ・メッセージ |
9 | 決済代行サービス | 申告者による支払結果確認機能② | 入力 | WebAP I | 日一回程度 (場合によっては日に数回の可能性あり) | 決済代行サービスにて入金した情報を取得する (決済代行サービス⇒拠出金システム) 主な連係情報(案) ・消込キー情報 ・業者番号 ・消込結果 ・メッセージ |
別紙4
:外部インターフェース要件
10 | 会計システム | 決済代行サービスからPMDAの口座への入金確認機能 | 入力 | WebAP I | 日一回程度 (場合によっては日に数回の可能性あり) | 決済代行サービスからある一定期間入金されたまとまった金額をPMDAの口座に振り込まれるため、ある一定期間で入金された債権情報とPMDAに振り込まれた金額との突合を行うためのCSVインターフェース 主な連係情報(案) ・業者番号 ・債権発生番号 ・入金番号 ・入金額 ・取引年月日 もしくは、 決済代行サービスによる入金を打ち消すための伝票情報を作成し、その後、取引明細CSVのデータで普通預金/仮受金のデータを作成する |
※検証環境用にパラメータを一部修正するなどの対応があるため、検証環境と本番環境との環境差異を設定ファイル等で変更できるようにすること。
※契約するBoxもしくは決済代行サービスによっては一部仕様が異なる可能性があることから、5つ程度インターフェースを追加する可能性がある。
別紙5 非機能要件
令和5年8月
独立行政法人 医薬品医療機器総合機構
目次
1 ユーザビリティ及びアクセシビリティに関する事項 1
2 システム方式に関する事項 1
3 規模に関する事項 2
4 性能に関する事項 2
(1) 応答時間(レスポンスタイム、ターンアラウンドタイム、サーバ処理時間) 2
5 信頼性に関する事項 3
6 拡張性に関する事項 4
7 上位互換性に関する事項 4
8 中立性に関する事項 4
9 継続性に関する事項 4
10 情報セキュリティに関する事項 5
11 情報システム稼働環境に関する事項 8
12 テストに関する事項 9
13 移行に関する事項 12
14 引継ぎに関する事項 14
15 教育に関する事項 15
16 運用に関する事項 15
1 ユーザビリティ及びアクセシビリティに関する事項
(1) 情報システムの利用者の種類、特性
No. | 利用者区分 | 利用者の種類 | 特性 | 補足 |
1 | PMDA 内 | PMDA 職員 | 特定ユーザ。内部ネットワークからのみのアクセス | システムにおける管理権限を有する |
2 | PMDA 外 | 厚生労働省、地方厚生局、各都道府県の職員 | 特定ユーザ、専用ネットワークからのみのアクセス | システムにおける管理権限を有しない |
3 | PMDA 外 | メーカーユーザ、薬局ユーザ | 不特定ユーザ、インターネットからのアクセス |
(2) ユーザビリティ要件
本調達において作成される機能については、Pegasus に付随する画面、ジョブ等の機能を利用することになるため、それらシステムや機能等のユーザビリティを継承して本システムを構築すること。なお、Pegasus 基盤上で使用しているソフトウェアに依存する機能において、該当ソフトウェアが販売中止で使用できない、または新バージョンにおける機能変更等でやむを得ず変更が発生する場合は、PMDA の承認を得ることで変更を許可する場合がある。
(3) アクセシビリティ要件
本調達において、アクセシビリティ要件においても、Pegasus におけるアクセシビリティ要件を継承すること。ただし、本調達作業開始後に別途定める推奨環境以外での利用については、利用は妨げることはないが、動作の保証はしないものとする。
2 システム方式に関する事項
(1) 情報システムの構成に関する全体の方針
本調達では、既存の拠出金システムの統廃合が主たる目的であり、稼働環境は既存の Pegasus 等を使用する想定であるため、ハードウェアの新規購入は予定せず、Pegasus のプログラム改修、拠出金管理システム構築の際に必要となるソフトウェア購入および導入、既
存機材・ソフトウェア等の設定変更、既存拠出金管理システムからのデータ移行等を想定している。
(2) 情報システムの全体構成
現時点で想定する稼働環境の全体構成は閲覧資料に示すとおりである。
3 規模に関する事項
現時点で想定する規模に関する事項は、以下に示すとおりである。
【Pegasus】
・同時ログインユーザ:内部約 228 名(内訳:PMDA170 名、厚生労働省、地方厚生局、都道府県:58 名)、外部約 100 名
※内、拠出金に関する機能については、PMDA10 名
・登録利用者数:内部約 1,350 名(内訳:PMDA1,050 名、厚生労働省、地方厚生局、都道府県:300 名)、外部約 2,000 名
・申告件数:12,000 件/年
【その他】
・ 接続機器:ドットインパクトプリンター1 台
(薬局向け申告書印刷時に使用しているのみ)
4 性能に関する事項
本システムの性能に関する要件は、以下に示すとおりである。
(1) 応答時間(レスポンスタイム、ターンアラウンドタイム、サーバ処理時間)
① オンライン処理
本調達において求めるレスポンスタイム及び、ターンアラウンドタイムに係る考え方を「図 4-1」に示す。ここで、レスポンスタイムとは、ノードごとのサーバ内部処理時間とし、ターンアラウンドタイムとは、利用者が端末を利用して処理要求を送ってか ら、すべての結果が出力されるまでの時間とする。なお、レスポンスタイム及びターンアラウンドタイムの遵守率は、90%以上とすること。
ア Pegasus 及び拠出金システムのレスポンスタイムは、全て 5 秒以内とすることイ 画面遷移を伴うターンアラウンドタイムは、全て 5 秒以内とすること
ウ 文書ファイルの表示、検索等に関わるターンアラウンドタイムは、全て 5 秒以内とすること
エ 上記に関わらず、ファイルやデータのサイズに依存する処理、高負荷となる処理及び処理件数の変動幅が大きな処理等、応答時間の要件を満たすことが困難なケースについては、PMDA と協議の上、個別に定めるものとする。
図 4-1 レスポンスとターンアラウンドタイムのイメージ
② バッチ処理
バッチ処理の設計に当たっては、以下の点に留意すること。
ア オンラインの稼働時間中に実施するバッチ処理については、オンライン/ディレイドオンライン業務サービスとの同時処理を可能とし、かつオンライン処理のレスポンスタイムに影響を与えないようにすること。
イ 平日については、原則として、翌朝 6 時 30 分までにバッチ処理が終了し、オンライン/ディレイドオンライン業務サービスに影響を与えないこと。
5 信頼性に関する事項
(1) 可用性要件
本システム構築後に、別紙7に示す「SLA 項目」を満たせるよう構築すること。
(2) 完全性要件
本システム構築後に、別紙7に示す「SLA 項目」を満たせるよう構築すること。
(3) 機密性要件
利用を許可された者以外の第三者は、システムを利用できないこととする。
6 拡張性に関する事項
(1) 機能の拡張性
本業務においては機能構築対象外ではあるが、今後オンライン化に向けて検討等行う予定であるため、本調達において構築する機能等においては、オンライン化を見据えた機能改修とすること。
7 上位互換性に関する事項
本業務において購入するソフトウェア対して、バージョンアップの影響範囲が限定的 で、小規模の改修で対応可能なシステムとすること。また、将来発生する導入するソフトウェアのバージョンアップへの対応が技術的に困難であるソフトウェアを導入する場合 は、PMDA に説明の上、PMDA の指示に従うこと。
8 中立性に関する事項
特定の製品、技術等に依存することなく、運用・保守を担当するベンダの交替時、システム拡張時、あるいは次期更改時等において、他の業者等に必要な情報を、支障なく引き継ぐことが可能なシステム構成とすること。
9 継続性に関する事項
(1) 継続性に係る目標
大規模災害(地震、火災及び風水害等又は第三者による情報システムへの攻撃等による直接的な設備及び情報システムの損壊、あるいは、ライフライン(電力、通信及び交通 等)の機能不全による情報システムの長時間停止)が発生した場合を除いて、Pegasus 及び拠出金システムを用いた業務処理が維持できること。
(2) 継続性に係る対策
大規模災害が発生した場合に対しては、早急にその状態を把握し、リスクの拡大を防止し、速やかに回復させるための処置を講じることとして、その対策をシステム運用マニュアル、保守実施計画書に取りまとめること。
10 情報セキュリティに関する事項
(1) 基本事項
「医薬品医療機器総合機構情報セキュリティポリシー」に準拠した情報セキュリティ対策を講じること。また、受注者は、最新の「政府機関の情報セキュリティ対策のための統一基準群」、「高度サイバー攻撃対処のためのリスク評価等のガイドライン」、「『高度標的型攻撃」』対策に向けたシステム設計ガイド」及び「オンライン手続におけるリスク評価及び電子署名・認証ガイドライン」を参照の上、必要に応じてその内容を取り込むこと。このほか、Pegasus 及び拠出金システムに係る情報セキュリティ要件は、「閲覧資料
4 Pegasus 設計書一式」及び「閲覧資料5 Gateway 設計書一式」に示す。
(2) 情報セキュリティ対策
原則として、基本設計書に規定する施策を踏まえ、本調達において本受託者が納入するシステムについて、Pegasus で既に実装している機能と併せて、下記①及び②に示す機能を実装し、③から⑧に示す項目について対応すること。なお、すでに Pegasus 基盤で実現されているものについては、実現済みであることがわかるよう示すこと。また、本受託者が納入するシステムに求める情報セキュリティ機能については、別紙6「情報セキュリティ対策の運用要件」に示す。
① 情報セキュリティ機能の実装
ア 業務上必要なアクセスに限るための利用者認証機能
イ 盗聴等の脅威に対処するために、伝送データを暗号化する機能ウ データベースやバックアップ等の蓄積データを暗号化する機能
エ テストデータ等をマスキング(変換、置換、シャッフル等)する機能
オ 権限を持つ PMDA 職員が、利用者の画面操作に関するログを参照又は分析するための不正追跡機能
カ 権限を持つ PMDA 職員が、特権ID を利用したすべての保守及び運用に関する作業証跡を参照又は分析できる、特権 ID 不正追跡機能
キ サーバ、ストレージ等に対する不正アクセス等の監視を行うための不正監視機能
ク ブラウザ経由にて想定される Web アプリケーションに対する不正アクセス(クロスサイトスクリプティング、SQL インジェクション等)対策機能
ケ あらかじめ検知対象に定義されたファイルに加えられた不正な変更を検知する、改ざん検知機能
コ ウイルス、スパイウェア等の不正プログラムを検知し、駆除又は隔離を行うとともに、定義ファイルの自動配布・適用を行う不正プログラム対策機能
サ セキュリティレベルの異なるネットワーク境界上にて、ネットワーク間で行われる通信の通過制御を行うファイアウォール機能
シ ネットワーク、サーバ等に対する不正アクセスを検知、遮断し、警告を通知する不正侵入防御機能
ス ネットワークに対して、許可のないハードウェアの接続を自動で検知し、通信の遮断、記録の取得、警告を通知する不正接続防御機能
② 脆弱性対策の実施
ア 本調達に基づくシステム開発が影響する範囲について、第三者による脆弱性検査を実施し、その結果をPMDA に書面にて報告すること。なお、インターフェイスシステム等、他機関より提供され改修することなく実装するソフトウェアについては、脆弱性検査の対象外とする。
イ 原則として、Pegasus 及び拠出金システムを構成するハードウェア、ソフトウェアパッケージ、端末機器等のすべての構成要素に対し、脆弱性対策を実施すること。
ウ Pegasus 及び拠出金システムを構成するハードウェア、ソフトウェアパッケー ジ、端末機器等のすべての構成要素について、公表されている脆弱性情報及び業務期間中に公表される脆弱性情報を収集すること。
エ 収集した脆弱性情報に係る対処の要否、可否について検討するとともに、対処要としたものに関しては、対処方法を PMDA と協議し、決定すること。否としたものに関しては、その理由、代替措置及び影響を、PMDA に報告すること。
オ Pegasus で今まで扱うことがなかったデータ種別のデータが格納されることにより行うべき脆弱性試験等が従前のもの異なる可能性があるため、取り扱うデータの内容を確認し脆弱性試験およびその対策を実施すること。なお、脆弱性試験の結果、別途ソフトウェア等を購入して対策する必要がある場合は、本受託者の責任及び負担において購入し設定等の対応を行うこと。
カ 決定した対処又は代替措置を実施すること。
③ 情報セキュリティインシデントへの対応
本調達に係る業務遂行に当たり、情報セキュリティが侵害された、又はその恐れがある場合には、速やかにPMDA に報告すること。これに該当する場合には以下の事象を含む。
ア 本受託者に対して提供した、あるいはアクセスを認めた PMDA の情報を目的外に利用した場合又は外部漏えいした場合
イ 本受託者に対して提供していない又はアクセスを認めていないPMDA の情報にアクセスした場合
④ 製品サポート期間の確認
本業務で納入する製品(ソフトウェア及びハードウェア)については、当該情報システムのライフサイクル(システム利用期間の終了まで)におけるサポート(部品、セキュリティパッチの提供等)を継続し受けられる製品を選定すること。
サポートライフサイクルポリシーが事前に公表されていない製品を納入する場合は、サポートが継続して行われるように後継製品への更新計画を提出すること。なお、後継製品に更新する場合の費用は本調達に含むものとする。
⑤ 情報セキュリティ対策の履行状況の報告
本調達に係る業務の遂行におけるセキュリティ対策の履行状況について、PMDA から報告を求めた場合には速やかに提出すること。
⑥ 情報セキュリティ監査への対応
PMDA が第三者機関等による情報セキュリティ監査を受ける場合には、PMDA を支援すること。情報セキュリティ監査の結果、対策が必要な場合は、PMDA と協議を行い、合意した対策を実施すること。
⑦ 情報セキュリティ対策への対応
本調達に係る業務の遂行において、本受託者における情報セキュリティ対策の履行が不十分であると認められる場合には、本受託者は、PMDA の求めに応じ、PMDA と協議を行い、合意した対応を実施すること。
⑧ 管理体制の整備
納入するシステムについて、不正が見つかったときに、追跡調査や立入検査等により原因を調査・排除できる体制を整備していること。
11 情報システム稼働環境に関する事項
(1) ソフトウェア構成
① 基本事項
必要に応じて購入するソフトウェアについては以下の要件を満たす製品を選定すること。
ア ボリュームライセンス、ガバメントライセンスの適用を考慮すること。
イ 選定する製品には、製品に付属する取扱説明書、並びにシステム環境の構築及び運用・保守作業に利用する製品仕様や操作手順等に係るドキュメント類を含むものであること。
ウ 当該ドキュメント類は、日本語で書かれたものであること。
エ ソフトウェアパッケージ間の連携を考慮した上で、動作保証できるソフトウェアパッケージの組み合わせとすること。
② ソフトウェア要件
本調達において改修するPegasus 基盤で購入しているソフトウェア構成を「閲覧資料4に含む(構成要素一覧)」に示す。このソフトウェア構成にないソフトウェアを導入する場合はPMDA に説明の上、PMDA の指示に従うこと。なお、当該ソフトウェア構成において導入済みであった場合においても、追加のサーバを構築することや、CPU
等のスペックを上げる場合は追加でライセンス購入の必要が発生する場合があるため、追加でライセンスが必要となる場合においても、受託者の責任および負担において導 入、設定等行うこと。Pegasus 基盤で購入しているソフトウェア構成のうち、開発ライセンスではソフトウェアベンダに確認することができない質問等がある場合、PMDA が保持するライセンスにて技術サポートが受けられる可能性があるため、適宜相談すること。
また、本システム構築後、令和7年3月31日まで保守対応を行うようにすること。
(2) ネットワーク構成
本調達の対象として想定するネットワーク構成を「閲覧資料4に含む(システム構成図)」に示す。
12 テストに関する事項
(1) テスト工程共通要件
実施する単体テスト、結合テスト、総合テスト、受入テストについて、共通となる要件は以下のとおり。
① Pegasus 及び拠出金システムの正常稼働を保証するためのテストとして、新システム構築事業者は、以下テストを実施すること。また、PMDA が行う受入テストの支援を行うこと。
⮚ アプリケーション
・単体テスト
・結合テスト
・総合テスト
⮚ インフラ
・システム基盤構築テスト
・運用テスト
⮚ データ移行
・移行リハ①~
② 各テストを行うため一連のテストケース(入力、出力、及びテスト合否基準)、テストデータ、及びテスト手順を整理し、PMDA と協議の上、承認を得ること。
③ 各テスト終了時に、実施内容、品質評価結果、及び次工程への申し送り事項等について、テスト結果報告書を作成し、PMDA と協議の上、承認を得ること。
④ テストに使用するテストツール等については、PMDA と協議の上、使用すること。なお、テストツールを利用する際に費用等が必要な場合は、受託者の責任及び負担
において用意し対応すること。また、使用したテストツールにおいては、本契約終了後 5 年間使用できるようライセンス購入等行うこと。
(2) テスト計画書
実施するテスト(12-(1)-①記載)について、テストの位置づけ、目的・スコープ、検証ポイント、実施方法、スケジュール、タスク、役割、体制、開始条件・終了条件
及びテストシナリオ考え方・作成方法を記述し、テスト計画書として提示し、テスト開始 1
ヶ月前までにPMDA と協議の上、承認を得ること。
承認されたテスト計画書に基づき、進捗管理を確実に実施すると共に、進捗状況の報告を定期的かつPMDA の求めに応じて行うこと。
以下に、テスト計画書で必要と考える事項を示す。
① テスト概要
ア テスト範囲(テストの位置づけ、目的・スコープ)イ テストシナリオ(考え方、シナリオ作成方法)
ウ テスト検証ポイント(検証箇所、実施方法) エ テスト品質目標(テスト項目数、バグ検出数)オ テスト開始・終了条件
② テストに関する実施作業タスク及びスケジュール
③ テスト環境(テストに使用した回線及び機器構成、その他ツール、場所等)
④ テスト体制(テスト実施者、テスト結果確認者(評価者))
⑤ 使用及び提出するドキュメントとその定義ア テスト項目一覧(テストシナリオ)
イ テスト仕様書
ウ 懸案事項一覧(申し送り事項含む)エ テスト結果報告書
(3) 単体テスト
プログラム及びモジュールが個別単体において正しく機能することを確認する。パッケージ化されたプログラム及びモジュールについてもテスト範囲とする。パッケージ化されている範囲について単体テストを実施しない場合には、実施しなくても該当機能が正しく機能することを別の手段で証明し、PMDA と協議の上、承認を得ること。
単体テストで行うテストにおいては基本的には自動化し、同じテストであれば自動でテストを実行し、結果を出力すること。なお、テストに必要なデータ投入においても自動的に行い、テスト完了後にテストデータは廃棄されること。もし、自動化できないテストがある場合は、PMDA に説明を行い、許可を得ること。
(4) 結合テスト
プログラム及びモジュールを、今回構築するシステム内に閉じた状態で、結合テストを実施する。以下の①~⑤の要領で結合テストを行い、ソフトウェアの結合が完全であることを確認する。
①業務:新業務フローに基づき一連の業務が正しく行えること。新機能が正しく連携して動作すること
②I/F:システム内の I/F 機能が正しく動作し、データ連携が行えること
③ジョブ:ジョブが正しく実行されること
④権限:権限要件が正しく実装されていること
⑤データ:テストデータ
(5) 総合テスト
Pegasus 及び拠出金システム全体として要件どおりにシステムが構築されていることを確認するために、実運用を想定した業務シナリオテスト・性能評価(パフォーマンス)テストを行い、システムが納品可能な状態であることを確認する。確認に当たっては、ソフトウェア製品が仕様に適合し、かつ実稼働環境で利用可能であることを確認できる評価指標及び合格条件を設定した上で、テストを実施する。脆弱性診断テストについても、ここで行う。
■業務シナリオテスト
・以下の①~⑤の要領で業務シナリオテストを行い、一連の業務(年間業務)が問題無く行えることを検証する。
①業務:新業務フローに基づき一連の業務が正しく行えること。新機能が正しく連携して動作すること
②I/F:システム内・システム跨ぎの I/F 機能が正しく動作し、データ連携が行えること
③ジョブ:ジョブが正しく実行されること
④権限:権限要件が正しく実装されていること
⑤データ:移行データ等を使用し、業務が行えること
■性能評価(パフォーマンス)
・新システムで求められる性能(パフォーマンス)を実データボリューム・実権限を用いて実機性能テストを実施する。
特に、性能及び負荷のテストにおいては、想定する最大人数が同時に利用開始した場合であっても問題が生じないことを確認する。
負荷テスト等、単純に繰り返し動作を実行させるなどして行うテストについては、ツールを利用して、機械的にテストを行うこと。
(6) 受入テストの支援
PMDA が実施する受入テスト(テスト計画の策定、準備、テストの実施、成果物の作成、テスト実施結果の報告等)において、本受託者は、テスト準備工程での QA 対応、システムに関する設定変更、テスト運用対応(ユーザのオペレーションに因らない自動連携に係る対応等)、テストデータの作成、情報提供等の必要な支援を行うこと。
(7) テストデータ及びその取扱い
受注者が主体的に実施するテスト(以下、テスト工程)においては、受注者が準備したテスト用データを使用することとするが、総合テストに関しては、移行データ等を使用すること。ただし、テスト工程においてPMDA のデータ(以下、本番データ)を使用する場合は、必要性等をPMDA に説明し、PMDA の承諾を得て使用すること。なお、テスト工程における本番データの管理責任は受注者が負うこと。
特に、外部接続を行うテストにおいて本番データを使用する場合は、外部にデータが漏洩しないことが前提となる。そのため、外部接続を行うテストにおいては、アプリケーションおよび機器等の設定を確認し、さらに、スタブモジュール等を作成するなど、本番データにアクセスできないような施策を講じること。なお、外部接続を行うテストにおけるテスト方針およびデータの取り扱い等については、テスト計画時にPMDA と協議の上取り決めを行うこと。
PMDA が主体的に実施するテスト(以下、受入テスト)においては、本番データを使用することになり、その管理責任は PMDA が負うことになる。ただし、受入テストにおける操作ではなく、受注者の操作等により漏洩等のインシデントが発生した場合はその限りではない。
13 移行に関する事項
(1) 移行手順
移行において想定する作業は以下のとおり。
① 移行計画書の策定
② 移行設計
③ 移行手順の作成・検証
④ 移行プログラムの作成・検証
⑤ リスクの洗い出し・コンティンジェンシープランの作成
⑥ 移行リハーサルの実施
⑦ 移行判定
⑧ 移行作業の実施
(2) 移行要件
現行システムから更改後のシステムへの移行に当たっては、機器の安定稼働及び業務の継続に影響を与えることなく、速やかに実施する必要がある。以下の基本方針に基づき、移行計画・作業を行うこと。
① Pegasus 及び拠出金システムの安定した稼働及び業務の継続に影響を与えることがないよう、安全で確実な作業を優先すること。
② PMDA が承認した日時を除き、現在稼働中のシステムのサービスを停止することなく、移行作業を行うこと。
③ システムの停止を伴う作業が避けられない場合には、システム利用者への影響を最小限に抑えるため、平日においては、勤務時間外、その他土日及び休日を作業実施日の基本として検討し、停止予定日より、原則 1 ヶ月前に停止日時及び停止による影響(停止するサービスの範囲)について、PMDA の承認を書面にて得ること。
④ 移行作業中に障害が発生した場合には、速やかに原因究明にあたるとともに、移行実施計画書、システム切替手順書とに従い、切り戻し作業を行い、PMDA の承認を得て、必要な障害対処作業を本受託者の責任と負担により実施すること。
⑤ 移行の実施前に、現行機器のデータについて、バックアップを取得すること。
⑥ 移行に伴い必要となるPegasus 及び拠出金システム等への設定変更等については、基本的には本受託者がそれらのヘルプデスク(運用保守支援事業者)等へ説明し依頼することになるが、説明等必要となる資料作成及び日程調整等について主体的に実施し対応すること。なお、ヘルプデスク(運用保守支援事業者)対応範囲外でヘルプデスク(運用保守支援事業者)が対応しきれない変更等が発生した場合は、本受託者の責任及び負担において、移行において必要となる変更作業等を実施すること。
⑦ 移行において必要となる機材・ソフトウェア等が発生した場合は本受託者の責任と負担により機材・ソフトウェア等を用意し対応すること。
(3) 移行対象データ
現行稼働している拠出金システムに存在する付加拠出金にかかる支給決定情報に関しては当該システムでは取り扱わないため移行対象外(現価算定額は移行対象(詳細は別途定義))とするが、それ以外のデータおよびファイルについては移行対象とする。
14 引継ぎに関する事項
(1) 運用・保守業者への引継ぎ
以下の事項に留意して、運用・保守業者等に引継ぎを実施すること。
なお、引継ぎ先、引継ぎ内容及び手順等の概要を、「表 14-1 引継ぎ内容、手順」に示す。
① 運用・保守業務の円滑な実施に役立つよう、必要な各種情報及び資料の提供を行うこと。
② 引継ぎの内容は、事前にPMDA に示し承認を得ること。
③ 引継ぎの実施に当たっては、PMDA 及び引継ぎ先と日程を調整した上で実施すること。
④ 引継ぎに必要な資料等は、本受託者において用意すること。
⑤ 必要に応じて、実機での操作説明等を行うこと。
⑥ 運用・保守業者等へ引継ぐテスト済みの環境については、セキュリティパッチ及びウイルスパターンファイルを最新化の上、引継ぐこと。
表 14-1 引継ぎ内容、手順
No. | 引継ぎ発生時(予定) | 引継ぎ元 | 引継ぎ先 | 引継ぎ内容 | 引継ぎ手順 |
1 | 令和 5 年 3 月~9 月 (リリースが多段階になるため段階的に引き継ぎ予 定) | 本受託者 | 審査系システム運用業者 | 拠出金システムに係る運用手順等、本受託者及び PMDA が必要と判断した引継ぎを行うこと。 | ・引継計画書を策定すること。 ・引継計画書に基づき、引継ぎを実施し、引継ぎ実施後、引継ぎ完了報告書を作成すること。 |
15 教育に関する事項
(1) 教育対象者の範囲、教育の方法
本調達は主に拠出金システムの統廃合となるが、機構外向けの機能については別途作成しないため、機構内のシステム利用者に対して 1 回程度説明会を実施し、システムの利用方法等について周知すること。
当該説明会においては、マニュアル等を用いて実施すること。
(2) 教材の作成
基本機能の操作マニュアルを作成すること。また、PMDA が研修教材を作成するにあたって既存の資料や動画等があれば提供するなど、協力すること。
16 運用に関する事項
(1) 運転管理・監視等要件
Pegasus 及び拠出金システムの運用時間については、「5(1)可用性要件」に示す。
(2) 運用サポート業務
Pegasus 及び拠出金システムの運用サポート業務は、別途調達するヘルプデスク(運用保守支援業者)が実施するため、本調達の対象外とする。
ただし、本調達に伴って既存の運用手順書に対して追記、修正すべき事項については対応すること。
(3) 業務運用支援
Pegasus 及び拠出金システムの業務運用支援業務は、別途調達するヘルプデスク(運用保守支援業者)が実施するため、本調達の対象外とする。
(4) バックアップ・リストア
拠出金システム用に新たにデータベースを構築することが想定されるため、新たに作成したデータベースをバックアップする仕組みを構築すること。
すでに Pegasus や申請電子データシステムは Pegasus 基盤で提供しているバックアップツールを使用してデータベースバックアップを行っているため、同様の仕組みおよび手順にて取得すること。
なお、バックアップする周期、保持期間等については設計時に確認すること。
また、リストアにおいても他システムと同様の手順で行えるように設計、実装すること。
(5) ログ管理
Pegasus 基盤ではログ管理を Logstorage にて行っている。取得するログについては、拠出金管理システムからのログとして個別に管理できるよう、取得するログを Pegasus と切り分けるなどして、Logstorage 管理機能においても、テキストで確認する場合においても、システム別に判別可能なようにすること。
(6) システムアカウント管理
Pegasus 基盤ではシステムごとにデータベース起動用アカウント、システム起動アカウントなど個別にアカウントを分けているため、今回新たに作成するデータベース等でアカウントを使用して起動する場合はアカウントを新たに作成すること。なお、極力システムアカウントについてログオン不可の状態となるようにすること。ログオン不可の状態にできない場合は PMDA に説明し許可を得ること。
(7) プログラム等の資産管理
本業務にて作成した設計書やプログラム等については最終納品物をPegasus 基盤内で管理しているSubversion に格納し管理できるようにすること。
別紙6 情報セキュリティ対策の運用要件
情報システムの運用・保守の業務遂行にあたっては、調達・構築時に決定した情報セキュリティ要件が適切に運用されるように、人的な運用体制を整備するとともに、機器等のパラメータが正しく設定されていることの定期的な確認、運用・保守に係る作業記録の管理等を確実に実施すること。
対策区分 | 対策方針 | 対策要件 | 運用要件 | 定期点検 |
侵害対策 | 通信回線対策 | 通信経路の分離 | 不正の防止及び発生時の影響範囲を限定するため、外部との通信を行う | セキュリティヘルスチェック(構成管理資料の原本と |
(AT: Attack) | (AT-1) | (AT-1-1) | サーバ装置及び通信回線装置のネットワークと、内部のサーバ装置、端末等のネットワークを通信回線上で分離すること。ネットワーク構成情 報と実際の設定を照合し、所定の要件通りに設定されていることを定期 | 実際の設定状況を目視にて突合せチェックすることにより各種セキュリティ設定の不正変更の有無をチェッ クする)と合わせて実施し報告すること。 |
的に確認すること。 | ||||
不正通信の遮断 | 通信に不正プログラムが含まれていることを検知したときに、その通信 | |||
(AT-1-2) | をネットワークから遮断すること。 | |||
通信のなりすまし防止 (AT-1-3) | 通信回線を介した不正を防止するため、不正アクセス及び許可されていない通信プロトコルを通信回線上にて遮断する機能について、有効に機能していることを定期的に確認すること。 | セキュリティヘルスチェック(構成管理資料の原本と 実際の設定状況を目視にて突合せチェックすることにより各種セキュリティ設定の不正変更の有無をチェッ | ||
クする)と合わせて実施し報告すること。 | ||||
サービス不能化の防止 (AT-1-4) | サービス不能攻撃を受けているかを監視できるよう、稼動中か否かの状態把握や、システムの構成要素に対する負荷を定量的(CPU 使用率、プ | |||
ロセス数、ディスク I/O 量、ネットワークトラフィック量等)に把握す | ||||
ること。監視方法はシステムの特性に応じて適切な方法を選択するこ | ||||
と。 | ||||
不正プログラム対策 (AT-2) | 不正プログラムの感染防止 (AT-2- 1) | 不正プログラム対策ソフトウェア等に係るアプリケーション及び不正プログラム定義ファイル等について、これを常に最新の状態に維持すること。不正プログラム対策ソフトウェア等により定期的に全てのファイルに対して、不正プログラムの検査を実施すること。 | ||
不正プログラム対 | 不正プログラム対策ソフトウェア等の定義ファイルの更新状況を把握 | |||
策の管理 (AT-2- | し、不正プログラム対策ソフトウェア等が常に有効に機能するよう必要 | |||
2) | な対処を行うこと。 |
セキュリティホ ー ル 対 策 (AT-3) | 運用時の脆弱性対策 (AT-3-2) | 情報システムを構成するソフトウェア及びハードウェアのバージョン等を把握して、製品ベンダや脆弱性情報提供サイト等を通じて脆弱性の有無及び対策の状況を定期的に確認すること。脆弱性情報を確認した場合は情報システムへの影響を考慮した上でセキュリティパッチの適用等必要な対策を実施すること。 | 脆弱性対策の実施状況は、月次で報告すること。 | |
対策が適用されるまでの間にセキュリティ侵害が懸念される場合には、当該情報システムの停止やネットワーク環境の見直し等情報セキュリティを確保するための運用面での対策を講ずること。 | ||||
不正監視・追跡 (AU: Audit) | ログ管理(AU- 1) | ログの蓄積・管理 (AU-1-1) | 情報システムにおいて、情報システムが正しく利用されていることの検証及び不正侵入、不正操作等がなされていないことの検証を行うために必要なログ(システムへのログオンや資源へのアクセスのロギング等)を取得すること。 | ログが所定の要件通り、取得・蓄積されていることを確認すること。(年 1 回以上) |
ログの保護 (AU- 1-2) | 取得・蓄積されたログが不正な改ざんや削除が行われないようログの格納ファイルのアクセス権を制限する等必要な対策を講じること。 | 取得・蓄積されたログが不正な改ざんや削除が行われていなことを確認すること。(年1回以上) | ||
時刻の正確性確保 (AU-1-3) | システム内の機器の時刻同期の状況を確認すること。 | |||
不正監視(AU- 2) | 侵入検知 (AU-2- 1) | 不正行為に迅速に対処するため、通信回線を介して所属するPMDA外と送受信される通信内容を監視し、不正アクセスや不正侵入を検知した場合は通信の遮断等必要な対処を行うこと。 | ||
アクセス・利用制限 (AC: Access) | 主体認証(AC- 1) | 主体認証 (AC-1- 1) | 主体認証情報(ID、パスワード)は不正に読み取りできないよう保護すること。 | |
アカウント管理(AC-2) | ライフサイクル管理 (AC-2-1) | 主体が用いるアカウント(識別コード、主体認証情報、権限等)は、主体の担当業務に必要な範囲において設定すること。 また、アカウント管理(登録、更新、停止、削除等)の作業内容は記録し、証跡を保管すること。 アカウント棚卸を定期的に実施し、不要なアカウントを削除すること。 | アカウント棚卸を定期的(年1回以上)に実施すること。 | |
アクセス権管理 (AC-2-2) | 主体が用いるアカウント(識別コード、主体認証情報、権限等)は、主体の担当業務に必要な範囲において設定すること。また、アカウント管理(登録、更新、停止、削除等)の作業内容は記録し、証跡を保管すること。 権限の再検証を定期的に実施し、不要な権限を削除すること。 | ユーザーIDの棚卸と合わせて実施すること。 |
管理者権限の保護 (AC-2-3) | システム特権を付与されたアカウント及び使用者を特定し、アカウントの使用状況を記録し、アカウントの不正使用がないことを定常的に確認すること。 | 管理状況を「特権ID台帳」及び「特権ID使用管理簿」により、月次で報告すること。 | ||
データ保護 (PR: Protect) | 機密性・完全性の確保 (PR-1) | 通信経路上の盗聴防止 (PR-1-1) | 通信回線に対する盗聴行為による情報の漏えいを防止するため、通信回線を暗号化する機能について、有効に機能していることを定期的に確認すること。 | セキュリティヘルスチェック(各種セキュリティ設定の不正変更の有無、および不正操作の痕跡の有無の確認)と合わせて実施し報告すること。 |
保存情報の機密性確保 (PR-1-2) | 情報システムに蓄積された情報の窃取や漏えいを防止するため、情報へのアクセスを制限すること。構成情報と実際の設定を照合し、所定の要件通りに設定されていることを定期的に確認すること。 また、業務データへのアクセス権限の付与状況を点検し、不要なアクセス権限が付与されていないことを確認すること。 | ユーザーIDの棚卸と合わせて実施すること。 | ||
業務データへのアクセス管理 | 情報の格付の見直し及び再決定が行われた際や、当該情報システムに係る職員等の異動や職制変更等が生じた際には、情報に対するアクセス制御の設定や職務に応じて与えられている情報システム上の権限が適切に変更されていることを確認すること。 | ユーザーIDの棚卸と合わせて実施すること。 | ||
受託者によるアクセス | 受託者は受託した業務以外の情報へアクセスしないこと。 | 情報セキュリティ遵守状況は月次で報告すること。 | ||
物理対策 (PH: Physical) | 情報窃取・侵入対策 (PH-1) | 情報の物理的保護 (PH-1-1) | 受託者の管理区域において、受託者がPMDAより提供された情報を格納する機器は、情報の漏えいを防止するため、物理的な手段による情報窃取行為を防止・検知するための機能を備えること。 また受託者の管理区域内のバックアップテープ等の可搬記憶媒体についても、管理(受領、返却、廃棄、等)の内容を台帳に記録し、証跡を保 管すること。 | 情報セキュリティ遵守状況は月次で報告すること。可搬記憶媒体の棚卸と合わせて実施すること。 |
侵入の物理的対策 (PH-1-2) | 受託者の管理区域において、受託者がPMDAより提供された情報を格納する機器は、物理的な手段によるセキュリティ侵害に対抗するため、外部からの侵入対策が講じられた場所に設置すること。 | 情報セキュリティ遵守状況は月次で報告すること。 | ||
入退室管理の履行 | PMDAが管理するサーバ室、事務室等の管理区域への入退出については、PMDA入退室管理規程を遵守すること。 |
PMDAの管理区域内での作業は、原則として、PMDA職員の立会いのもとで行うこと。 | ||||
障害対策 (事業継続対応) (DA: Damage) | 構成管理(DA- 1) | システムの構成管理 (DA-1-1) | 情報セキュリティインシデントの発生要因を減らすとともに、情報セキュリティインシデントの発生時には迅速に対処するため、情報システムの構成(ハードウェア、ソフトウェア及びサービス構成に関する詳細情報)が記載された文書を実際のシステム構成と合致するように維持・管理すること。 | 変更作業時の構成管理資料の更新については、「変更作業一覧」により、月次で報告すること。 |
可用性確保 (DA-2) | システムの可用性確保 (DA-2-1) 情報のバックアップの取得 | システム及びデータの保全が確実に実施されるため、システム及びデータのバックアップが所定の要件通りに取得されていることを定期的に確認すること。 また、回復手順について机上訓練を実施し、バックアップや回復手順が適切に機能することを確認する。 | バックアップの実施状況は、月次で報告すること。 バックアップによるリストア等回復手順については、机上訓練を年 1 回以上実施すること。 | |
サプライチェーン・リスク対策 (SC: Supply Chain) | 情報システムの構築等の外部委託における対策(SC- 1) | 委託先において不正プログラム等が組み込まれることへの対策 (SC-1-1) | 情報システムの運用保守において、PMDAが意図しない変更や機密情報の窃取等が行われないことを保証するため、構成管理・変更管理を適切に実施すること。 | 変更管理の状況は「変更作業一覧」により、月次で報告すること。 |
別紙 7 「SLA(Service Level Agreement)項目」
No | 指標の種類 | 指標名 | 目標値 | 計算式・計測方法・評価基準 | 計測 周期 |
1 | システム運用 | サーバおよび機器 | 冗長化さ | • (各監視対象ノードが稼働している時間の延べ時間)÷(各監視対象ノードが稼働すべき時間の延べ時間) • ハードウェアおよびミドルウェアが正常稼働している場合、稼働している時間とみなす。 • 評価対象ノードは物理サーバ、仮想サーバ、ネットワーク機器、ストレージ装置とする。 • 評価対象時間は、平日 9:30~18:00 の時間帯とするが、参考情報として平日 9:30~18:00 以外の時間帯も計測する。 • システムの提供時間は、原則 24 時間 365 日とする。 • 予め計画されたサービス停止、コールドスタンバイのように予め想定されるノードダウンは除き、稼働すべき時間とする。 申請電子データシステムにて業務利用されているサーバ等のメンテナンスを実施する場合は、5 週間以降の日で PMDA 職員と調整する。 • 申請電子データシステムにて業務利用されているサーバ等以外のメンテナンスを実施する場合については、緊急の場合を除き、作業を実施する 5 営業日前までに PMDA と調整する。 • ネットワーク障害に起因し、ノード監視が出来ない場合もサーバダウンとみなす。 | 毎月 |
可用性 | れている | ||||
ノード: | |||||
月間 | |||||
99.9% | |||||
冗長化さ | |||||
れていな | |||||
いノード: | |||||
月間 | |||||
99% | |||||
2 | システム運用 | レスポンス | 遵守 | • 以下の応答速度を達成する。 画面応答(参照系)3 秒 画面応答(更新系)3 秒 ※1 DB 検索結果表示 3 秒 ※1 DB 更新処理 3 秒 ※1 文書ファイル表示 5 秒 ※1 文章ファイル検索結果表示 3 秒 ※1 文章ファイル全文検索結果表示 3 秒 ※2 ファイル更新(アップロード、ダウンロード)10 秒以内 ※3 なお、VPN 経由のアクセス、100 件以上のダウンロード、1MB 以上のファイル送受信、複雑な組合せでの検索などについては、以下の条件とする。 ※1:10 秒 ※2:30 秒 ※3:60 秒 • 遵守状況の報告のみ。定量的報告は不要。 | 毎月 |
No | 指標の種類 | 指標名 | 目標値 | 計算式・計測方法・評価基準 | 計測 周期 |
3 | システム運用 | データ保全性 | 遵守 | • バックアップについては、下記を要件とする。なお、下記が満たせない場合は都度状況を報告し、PMDA 担当者の指示に従い、対応をすること。 仮想サーバ:メンテナンスの都度1世代取得(手動)物理サーバ:メンテナンスの都度1世代取得(手動) NAS ファイル:1回/1日(自動) 遠隔地保管(仮想サーバ):1回/1日(自動) 申請審査 DB トランザクションログ:1回/30 分(自動)各種アプリ、機器等のログ:常時、1 年保存(自動) • データのリカバリについては、下記を要件とする。 ◇データ障害 RPO(目標復旧時点):障害発生時(最大 30 分前) RTO(目標復旧時間):6 時間以内 ◇サーバ障害 RPO(目標復旧時点):前回取得バックアップ時点 RTO(目標復旧時間):10 時間以内 ◇災害 RPO(目標復旧時点):前回取得バックアップ時点 RTO(目標復旧時間):機器、データ等必要部材が揃った状態から1か月以内。 • 遵守状況の報告のみ。定量的報告は不要。 | 毎月 |
4 | システム運用 | 障害通知 | 遵守 | • 障害発生時刻から 30 分以内に確実に PMDA 職員に連絡をとり応答を得る。 • データセンタに設置されたハードウェア及びソフトウェアにて発生した障害については、現地作業が必要な場合は障害検知後 180 分以内にデータセンタへ入館し、一次切分け作業を開始出来ること。 • 障害発生時刻がヘルプデスク提供時間内の場合に限るが、提供時間外だった場合は、翌営業日のヘルプデスク提供時間開始後 30 分以内に初動開始とする。 • 遵守状況の報告のみ。定量的報告は不要。 • 一次切分け作業の結果、及び状況については、原因の特定有無にかかわらず 1 時間以内に行うこと。 | 毎月 |
No | 指標の種類 | 指標名 | 目標値 | 計算式・計測方法・評価基準 | 計測 周期 |
5 | システム運用 | 障害復旧遵守率 (4.5 時間以内) | 95% | • (障害発生時刻から、障害復旧までの経過時間が 4.5 時間以内の件数) ÷(発生障害件数) • 対象は影響レベル 3 以上のインシデントとする。 • データパッチ、代替手段の提供、縮退運転などの暫定対応も障害復旧とみなす。 • 障害発生時刻がヘルプデスク提供時間外の場合、経過時間はヘルプデスク提供時間開始後から起算する。 | 年間 |
6 | システム運用 | 障害原因切分け遵守率 (翌営業日以内) | 80% | • (障害発生の当日又は翌営業日に障害原因切分けが完了した件数) ÷(発生障害件数) • ハードウェア障害、ミドルウェア障害の場合はベンダ問合せを行うこと、アプリケーション障害の場合は、対応方針を決定しシス テム管理者へ報告することを以って障害原因切分け完了とみなす。 | 毎月 |
7 | ヘルプデスク | 問合せ回答率 (翌営業日以内) | 80% | • (問合せ受付の当日又は翌営業日に、回答が完了した件数)÷(問合せ受付件数) • 問題解決につながる回答を行った時点で回答完了とする。 • 作業依頼の連絡については除外する。 | 毎月 |
8 | ヘルプデスク | ヘルプデスク提供時間 | 遵守 | • 平日 9:30-18:00 まで。ヘルプデスク業務に支障をきたさないように調整した上で、1時間の休憩時間をとる。 • 行政機関の休日(「行政機関の休日に関する法律」(昭和 63 年法律第 91 号)第 1 条第 1 項に掲げる日をいう。)を除く日とする。 • 要因別作業項目別に月間の作業時間を集計し、月次にて報告すること。 | 毎月 |
9 | セキュリティ | 重大障害の件数 | 0 回/年 | • 下記に例示するような重大なセキュリティインシデントを発生させない。 サーバ上で不正プログラムが実行される等の方法による、データの破壊や改ざん。 FAX やメール等の機構外への誤送信。 機密情報(申請情報など)の第三者への漏洩。書類、PC、IC カードなどの紛失。 • システムで利用する製品等について、セキュリティ情報の公開から、5 営業日以内にセキュリティパッチ適用等の検討を完了する。 セキュリティ情報は以下のサイト等から取得し、検討対象となったセキュリティインシデントおよび情報取得元、検討内容および対応方針等を取りまとめ、PMDA に報告し、対応内容については PMDA の指示を仰ぐこと。 • https://jvn.jp/ | 毎月 |