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