「次期建退共電子申請システムの構築に係る業務一式」調達仕様書（案）・要件定義書（案）に対するご意見ご質問について

（ご意見）
番号

該当物名頁

項番

記載内容

意見内容

意見提出理由回答

1 要件定義書

65

2-2-2（14）

就労実績報告作成ツールのWeb版では工事情報につ就労実績ツールで作成した工事情報を取込み、工事情報を いてはファイル出力ではなく、データ連携と記載されて連携手順確認のため表示できること。
いるため、取込手順は発生しない認識ですがいかがでしょうか。

掛金納付システムと就労実績報告作成ツールのWeb版との間は、ご認識のとおりデータ連携となります。
なお、就労実績報告作成ツールのWeb版においては、既存スタンドアロンの就労実績報告作成ツールからの移行等の用途で、ファイルによる取り込みが必要になります。

2 要件定義書

75

2-2-4（2）

再構築においては、複数の就労実績報告のCSVを取り込む 就労実績報告作成ツールのWeb版では就労実績情報場合に、支店事業により取込む対象を指定できるようにす についてはファイル出力ではなく、データ連携と記載さ連携手順確認のためる。
れているため、CSV取込手順は発生しない認識ですがいかがでしょうか。

ご認識のとおりです。要件定義書の記載を修正します。

3 要件定義書762-2-4（6）

再構築においては、現行掛金収納システムと就労実績ツー 就労実績報告作成ツールのWeb版では掛金充当書のルとで掛金充当書の表示項目、表示順、デザイン等が異な 出力機能は存在していないと読取れたため、、統一出力帳票確認のためるため統一（見直し）すること。
（見直し）は不要の認識ですがいかがでしょうか。

現行の就労実績報告作成ツールの様式類と掛金収納システムの様式で、共通・類似する項目等の表現について整合確認することを意図しています。
認識の齟齬が生じないように要件定義書の記載を見直します。

4 要件定義書

78

2-2-4（14）

再構築においては、被共済者番号より建退共マスタから氏 就労実績報告作成ツールのWeb版ではツール用のマ名を印字すること（現行は就労実績ファイルの登録名で表 スタ登録を行う記載(P102)があるため、建退共マスタ
データ不整合の可能性があるため示しており、建退共マスタの氏名と異なるケースが発生する とは一致しない氏名となる可能性がある認識ですがいため）。
かがでしょうか。

就労実績報告作成ツールのWeb版においても、自社の被共済者は事前登録を行う必要があります（建退共の情報には共済契約者と被共済者の最新の雇用情報を保持していないため）。
その際、登録時にデータ連携基盤の被共済者情報と照合して問題ないものだけ登録します（被共済者番号やセイメイが一致しない場合は登録できない仕組みを想定）。一度、登録した被共済者情報は、自社の被共済者として参照できるようにします。
建退共側の被共済者に変更が生じた場合（姓名の変更など）は、データ連携基盤の情報を参照して、最新データを取り扱うため、齟齬が生じない想定です。
認識の齟齬が生じないように要件定義書の記載を見直します。

5 要件定義書

80

2-2-5
（6）

再構築においては、被共済者番号より建退共マスタから氏 就労実績報告作成ツールのWeb版ではツール用のマ名を印字すること（現行は就労実績ファイルの登録名で表 スタ登録を行う記載(P102)があるため、建退共マスタデータ不整合の可能性があるため示しており、建退共マスタの氏名と異なるケースが発生する とは一致しない氏名となる可能性がある認識ですがいため）。
かがでしょうか。

No4と同様6 要件定義書

102

2-3-1
（10）

•利用者の権限に基づき、登録した被共済者の情報についデータ連携基盤の情報を表示する場合、就労実績報て、データ連携基盤を参照して被共済者情報を一覧で参照
告作成ツールのWeb版で登録した被共済者情報とはデータ不整合の可能性があるためできること。
一致しない表示となる可能性がある認識ですがいか•データ連携基盤の情報が更新された場合、表示される情報がでしょうか。
も更新されること。

No4と同様7 要件定義書

2-3-3
107 （1）
1）

データ連携基盤の情報を表示する場合、就労実績報
被共済者の情報についてはデータ連携基盤から取得した最 告作成ツールのWeb版で登録した被共済者情報とは
データ不整合の可能性があるため新の情報を表示すること。
一致しない表示となる可能性がある認識ですがいかがでしょうか。

No4と同様

8 要件定義書

2-3-3
108 （1）
2）

データ連携基盤の情報を表示する場合、就労実績報
被共済者の情報についてはデータ連携基盤から取得した最 告作成ツールのWeb版で登録した被共済者情報とはデータ不整合の可能性があるため新の情報を表示すること。
一致しない表示となる可能性がある認識ですがいかがでしょうか。

No4と同様2-10-1
表40

就労実績報告作成ツールのWeb版では被共済者情報についてはツール用のマスタ登録を行う記載(P102)があるため、記載内容が一致していません。被共済者情報についてはツール側へマスタ登録した内容ではな
データ不整合の可能性があるためく、データ連携基盤の情報を常に参照するということでよろしいでしょうか。
その場合、被共済者情報のマスタ登録機能は必要なのでしょうか。

No4と同様下記①、②について将来実施される可能性を想定したDB構成とする認識ですが相違ないでしょうか。
①追加掛金・特別掛金の導入②１日当たりの就労単価の見直し（現在は320円）

将来的な制度改正により導入の可能性があります。その前提でDB構成等を検討ください。追加掛金、特別掛金の取り扱いについて、要件定義書の記載を見直します。
なお、追加掛金、特別掛金を利用した充当等の具体的な機能は、制度改正後の対応とするため、本業務の対象には含まれません。

9 要件定義書

10 要件定義書

215-

No32 被共済者情報（データ連携基盤から参照）

用語一覧 「特別掛金」と「追加掛金」の用語

1

機能要件への考慮要否の確認のため

11 要件定義書

12 要件定義書

13 調達仕様書

13 1-3-1

証紙貼付方式と電子申請方式の併用について、下記①～⑤の併用を想定したDB構成とする認識ですが相違ないでしょうか。
①１社の共済契約者での併用（例）部署等により証紙・電子が混在
電子申請方式の本番実施システム（以下、「本システム」と②１つの支店事業での併用いう。）と証紙貼付方式に対応した共済契約者及び被共済（例）支店配下の工事等により証紙・電子が混在
機能要件への考慮要否の確認のため者を管理するシステム（以下、「既存システム」という。）が併③１つの現場での併用存する。
（例）現場で被共済者や工期等で証紙・電子が混在④１つの工事での併用（例）工事で被共済者や工期等で証紙・電子が混在⑤１人の被共済者での併用（例）被共済者が、証紙・電子混在で退職金積立

証紙貼付方式と電子申請方式の併用については、現行と同様になります（①～⑤があり得ることが前提）。

303 3-12-3

アプリケーション及びネットワーク設計によっては、現在業務で利用されている機構端末をご利用いただくこ
機構内連携（情報LAN、業務LAN）に接続する端末を、6 台とを受入可能でしょうか。
導入すること。
例えば、機構職員の操作はWebブラウザのみで完結 端末要件確認のため機構内連携（情報LAN、業務LAN）する端末の要件は、以下するなど、特殊なツールをインストールする必要がなに示すとおりである。
い場合、運用・保守性を考慮して、個別端末を利用しない方針も可能ではないかと思料いたします。

専用端末６台は要件定義書に記載のとおり必要です。
その上で、その他の建退共端末の活用については、具体的な条件や内容を提示いただいた上で協議するものとします。

38

9 再委託に関する事項

本件、短期での大規模開発になることが想定され、技術者要員確保の観点から再委託の必要性を考えております。
一方、再委託においては貴機構のご承認が必要であプロジェクトの実現可能性と品質を高めるため確認り、審査に時間がかかることは認識しております。
再委託先要員を含めたプロジェクト体制を早期に構築し開発着手できるよう、手続き方法についてご検討いただくことは可能でしょうか。

2

調達仕様書に記載のとおり、主たる部分の再委託でないこと、サプライチェーンリスクがないことについて、確認が必要となります。契約後に、これらの確認を速やかに実施できるように、提案書提出の段階で再委託内容の詳細、再委託先の資本の状況が分かる資料をの提出を求めるようにします。
上記について、「次期建退共電子申請システムの構築に係る業務」にかかる提案依頼書に記載します。

（ご質問）
番号

該当物名頁

項番

1 調達仕様書

4 1(6)

2 要件定義書

229 2-11

記載内容

質問内容

質問提出理由回答

関係業務・関係者と調整を行い、連携仕様、移行等を具体化する事項について

調達仕様書（6）作業スケジュールに記載のとおり、関連業務・関係者と調整作業は、本件の受託者が主体的に実施する必要があります。その上本件実施に伴う関係業務・関係者側に発生する費用 見積を行う上で影響があることから、前提および条件 で、関係業務・関係者側の実施する作業は、それぞれの主体の責と負担は委託者負担の認識でよろしいでしょうか。
を確認するためで実施します。ただし、本件の受託者の瑕疵等により、関係業務・関係者の作業に影響を与えた場合、協議によって本件の受託者に費用負担を求める場合があります。

外部インターフェースに関する事項について

本件実施に伴う関係業務・関係者側に発生する費用 見積を行う上で影響があることから、前提および条件
No1と同様は委託者負担の認識でよろしいでしょうか。
を確認するため
現行システムの運用保守事業者側に対して、契約終了時の移行及び引継ぎに関する事項を定めておりますので、移行のためのデータ出力、引き本件実施に伴う現行システムの運用保守事業者側に見積を行う上で影響があることから、前提および条件 継ぎは現行システムの運用保守事業者の責と費用負担で実施します。そ発生する費用は委託者負担の認識でよろしいでしょうを確認するための上で、移行データを受領した後の作業は、本件の受託者の責と費用負か。
担で実施することになります。

3 調達仕様書

11 2(6)

システム移行について

4 要件定義書

312 3-14

移行に関する事項について

本件実施に伴う現行システムの運用保守事業者側に見積を行う上で影響があることから、前提および条件発生する費用は委託者負担の認識でよろしいでしょう
No3と同様を確認するためか。

機能要件の定義

本業務内でシステム化する機能要件は、「2.機能要件定義」に記載されている認識です。
また、現行システム要件を踏襲し要件不明確または見積を行う上で影響があることから、前提および条件仕様が正しく把握できない場合は、必要に応じて受託を確認するため者にて現行ソースコードの調査・解析を実施し仕様の把握も役務の範囲と考えますが、認識相違ありませんでしょうか。

現行システムの設計書類は提供可能です。
なお、現行システムの設計書類の不備等により現状が把握できない場合は、現行システムの運用保守事業者側に対して問合せ、必要な情報を取得することは可能です。
次期建退共電子申請システムの設計に係る範囲で調査・解析等の作業が必要な場合は、本件の受託者の負担で実施いただくことになります。

機能の詳細【掛金納付】
変更点に関して現行機能から変更・追加となる内容を赤字で記載している

現行システムに対する変更要件は要件定義書に全て示されている認識です。
要件定義書に記載されていない変更については、正しく作業量を把握することができず応札事業者間でも 見積を行う上で影響があることから、前提および条件認識齟齬が発生すると考えます。
を確認するため要件定義書に記載されていない変更については仕様変更として、仕様、納期、金額含め協議となる認識でよろしいでしょうか。

要件定義書に記載されていない変更については仕様変更として、仕様、納期、金額含め協議を実施します。
なお、本業務は、現行システムの機能改修を前提としたものではなく、再構築としております。そのため、赤字にしていない機能についても、次期システムの構築方針に基づき、画面の内容等を適宜、見直すことが前提です（必ずしも現行システムの画面を踏襲する必要はありません）。

機能の詳細【就労実績ツールWeb 版】
変更点に関してスタンドアロン機能から変更・追加となる内容を赤字で記載している

現行システムに対する変更要件は要件定義書に全て示されている認識です。
要件定義書に記載されていない変更については、正しく作業量を把握することができず応札事業者間でも 見積を行う上で影響があることから、前提および条件
No6と同様認識齟齬が発生すると考えます。
を確認するため要件定義書に記載されていない変更については仕様変更として、仕様、納期、金額含め協議となる認識でよろしいでしょうか。
・共済契約者が雇用する被共済者としてスタンドアロンのツールに登録した被共済者情報は、2-3-1（9）の要件の具体化「被共済者情報登録」として移行する必要性はあるか。

5 要件定義書

6 要件定義書30 248 2-2

7 要件定義書99 2-38 要件定義書101

2-3-1（3）•Web版ツールを利用するに当たって必要な情報（工事情報、就労実績情報等）をスタンドアローン版からデータ移行できること。

9 要件定義書1022-3-1（9）•被共済者の情報（被共済者番号、セイメイ）をWeb版ツール Excel形式等で被共済者情報を一括登録する必要性に登録できること。
はあるか。

10 要件定義書

105

2-3-2（2）－

スタンドアロンのツールに登録した被共済者情報も移行対象になります。
上記を要件定義書に追加します。

要件の具体化

所定形式（ExcelやCSV形式）で作成した被共済者の一覧を元に一括登録できることも要件とします。
上記を要件定義書に追加します。

就労実績報告作成ツールのWeb版は、電子申請方式のみに対応したものでしょうか。Web版を利用して証紙 要件の具体化貼付方式の利用は想定していないのでしょうか。

証紙貼付方式の利用も想定しています。
工事情報、就労実績情報の基本的な管理は電子申請方式と同じにすることを想定しています。証紙貼付方式の場合は、証紙貼付方式用の帳票出力が必要となります（掛金収納システムへのデータ連携は不要）。
証紙貼付方式（貼付結果）と電子申請方式（充当結果）を含めた共済手帳受払簿として管理もできるようにすることを想定しています。
上記を要件定義書に追加します。

3当該機能は以下のような利用方法と想定されます。
①利用者の社内システム等から取込用のファイルを生成②生成されたファイルをツール側で取り込む
11

12③要件定義書（別紙2）_20240117.docx③要件定義書（別紙2）_20240117.docx③要件定義書（別紙2）13_20240117.docx

120

121

2-3-6（1）2-3-7（1）2-3-7122（2）•就労履歴連携用CSVファイルを取込み、被共済者情報、工機能重複の可能性があるため事情報、施工体制情報、就労実績情報を登録できること。 しかし、後述されている「2-3-7 工事情報・就労実績情報一括取込（API連携）」でCCUS以外のシステムからAPI連携されるような記述があります。ファイル連携
or API連携のどちらかだけあればよいのではないでしょうか。
•勤怠管理等のシステム（CCUS含む）側から連携された元請一括用の情報から対象の情報を選択し、取得を行う。取得
CCUS以外のシステムからAPI連携されるような記述した情報から被共済者情報、工事情報、施工体制情報、就があります。登録方法については「CCUS一括作業方 意図していない連携内容の可能性があるため労実績情報を登録できること。
式」として問題ないでしょうか。
•CCUSとの連携においては、登録方法が「CCUS一括作業方式」であると判別できるようにすること。
•勤怠管理等のシステム（CCUS含む）側から連携された一次下請一括用の情報から対象の情報を選択し、取得を行う。
CCUS以外のシステムからAPI連携されるような記述
取得した情報から被共済者情報、工事情報、施工体制情があるが、登録方法については「CCUS一括作業方報、就労実績情報を登録できること。
式」として問題ないか。
•登録方法が「CCUS一括作業方式」であると判別できるよう意図していない連携内容の可能性があるため両方必要となります。

登録方法の仕組み（仕様）は「CCUS一括作業方式」と共通で問題ありません（共通化できる仕様を定めてください）。

・No12と同じにすること。

③要件定義書（別紙2）14_20240117.docx

2-3-7
122（2）•勤怠管理等のシステム（CCUS含む）とオンラインでのデータ連携するためのAPI仕様の作成及び連携用中間サーバー
取得する連携データは「元請一括用の連携データ」でを構築し、勤怠管理等のシステム（CCUS含む）からの元請はなく、「一次一括用の連携データ」でよろしいでしょう 連携データ相違の可能性があるため一括用の連携データを取得できること。勤怠管理等のシスか。
テム（CCUS含む）とは連携用中間サーバーを責任分界点とご認識のとおりです。要件定義書の記載を見直します。

して連携することを基本とする。

15③要件定義書（別紙2）_20240117.docx

16 要件定義書17 要件定義書

123

2-3-8

10 図7

102

2-3-1
（9）

（1）申請状況一覧•建退共職員が各利用者における就労実績報告に関して、申請者毎・工事毎の申請状況等についてステータス等の内容を一覧で確認できるようにすること。
建退共用として業務LAN側で使用する機能ではなく、•特定の条件等で絞り込みを実施できるようにすること。
情報LAN側で使用する機能という認識でよろしいで実行環境が不明のため（2）申請状況詳細しょうか。
•申請者毎・工事毎の申請状況等の詳細内容を確認できるようにすること。
•就労実績報告に対する充当結果、エラー結果を確認できること。

就労ツールのWeb化

情報LAN側の端末で建退共職員が使用できれば問題ありません。

Web化後の中に「業務LAN側でチェックできるため、...」
情報LAN側でのチェックは必須ですが、情報LAN側と業務LAN側とのデー見積を行う上で影響があることから、前提および条件と記載がございますが、Web化後は情報LAN側でのタの受け渡しによる情報のタイムラグがあるため、業務LAN側で最低限のを確認するためチェックと認識でよろしいでしょうか。
最終チェックを行い、特退共システムに連携する必要があります。

•被共済者の情報（被共済者番号、セイメイ）をWeb版ツールに登録できること。
•登録した被共済者の情報に対してデータ連携基盤内の被就労実績報告作成ツールのWeb版では被共済者情報共済者情報と照合を行うこと。
をデータ連携基盤からの参照のみではなく、ツール内•照合が一致した場合は被共済者情報としてWeb版ツールへで別に登録するということでしょうか。の登録を行い、一致しない場合は警告を表示して登録を行
その場合、ツール側へ登録後の被共済者情報につい データ不整合の可能性があるためわないこと。て建退共マスタとの同期をどのように実施するのか。
•共済手帳の掲載されているQRコードをスマートフォン等のカ
また、登録した被共済者情報はどこでどのように使用メラで読み取り被共済者情報として必要な情報を登録可能する想定かご教授願います。とすること。
•自社雇用でなくなった被共済者などについて登録の解除ができること。

共済契約者と被共済者の雇用関係は、建退共側のマスタにはないため、就労実績報告作成ツールWeb版にて、自社雇用の被共済者を登録する必要があります。そのため、雇用関係の情報は就労実績報告作成ツールWeb版に保持しますが、被共済者自体の情報は、建退共マスタを正とします。
※個人情報の関係から被共済者情報のリストを開示することはできません。そのため、被共済者番号とセイメイ等の情報を正しく入力し、建退共マスタと照合して問題ない場合は、自社雇用の被共済者として管理できるようにすることを想定しています。

18 要件定義書

104

2-3-2
（1）

工事情報ごとに掛金収納システムへの連携状態を月別に確認できること。

掛金収納システムへの連携状態について、何の情報か記載されていないためご教授願います。
表示内容の不明点があるため（他の記述から推測すると、工事に対する掛金の充当状態（あり、なし）でよろしいでしょうか。）

ご認識のとおり、掛金の充当状態になります。
要件定義書の記載を見直します。

19 要件定義書

2402-11-7
表49

No4 工事情報・就労実績情報一括ファイル

受信した連携データに不備がある場合のエラー内容については送信元へどのように連携する想定かご教授願います。

連携した内容は、就労実績報告作成ツールWeb版上で不備内容を確認できるようにすることを基本とします。エラー結果を送信元へ返信することは想定していませんが、業務の効率化の観点で有効な手法があれば提案ください。

20 要件定義書

3-4-5(3)の「運用・管理端末」では端末を4台調達する
3-4-5(3)
運用・管理端末の機器数が「操作用端末」、「運用管理用端 ことあるが、3-12-3の「端末要件」では6台導入するこ
257 表61
調達台数の確認のため末」の設置台数ととあり、調達台数に矛盾があるため、必要台数をご3-12-3教示願います。

4

連携手順確認のため６台が正となります。要件定義書の記載を見直します。