「中退共システム再構築に係る開発業務一式」調達仕様書（案）に対するご意見または修正案について
令和3年5月28日
独立行政法人勤労者退職金共済機構

該当する箇所の
章と項番

該当頁
№
該当物

ページ

章

調達仕様書（案）の記載内容（概要でも構いません）

2

全般

調達仕様書
（案）

全般

4

－

1

－

-

以下の観点において、開発スコープの全体が不明確となっております。
新システムのスコープ対象となる各種一覧をご提示いただいた上で、ドキュメント間の整合性を確保していただきますよう、お願
いいたします。

4

5

6

調達仕様書
（案）

調達仕様書
（案）

調達仕様書
（案）

調達仕様書
（案）

8

11

11

17

1

5

5

4

種別

採用／不採用回答

意見

採用

ご指摘の内容を踏まえ、要件定義工程における各成果物の内容や成果物間の整合性を確認のうえ、誤りや不明確な点があった場合は、それらを適切に修正します。

スコープの確認のため。

【スコープ確認観点】①スコープ調整区分(指定なし、0、1、2)やセルの背景色(色な
し、水色、グレー)、取り消し線の意味が不明確②「画面レイアウト」と「画面一覧表」が不整合③「本稼働後」に対応予定である旨の要件が、本調達の役務範囲に入らないことの確認④「業務一覧」、「業務・要求事項マトリクス」と「システム化
要件一覧」が不整合⑤「エンティティ一覧」と「概念データモデル」が不整合⑥「要件整理表」と「システム化要件一覧」が不整合⑦「画面一覧表」、「帳票一覧表」、「システム機能詳細一覧
表」と「システム化要件一覧」、「要件整理表」が不整合⑧データエントリーシステムの取り扱いが不明確⑨「システム化要件一覧」上に「TBD」、「保留」などが残っており、取り扱いが不明確⑩「画面レイアウト」と「要件整理表」が不整合⑪業務で使用しているツール類の取り扱いについて⑫「業務フロー」と「画面一覧表」、「帳票一覧表」、「システム機能詳細一覧表」が不整合⑬「業務フロー」と「システム化要件一覧」が不整合⑭「運用保守一覧」と「画面一覧表」が不整合⑮「アプリケーション処理方式」と「要件整理表」が不整合⑯「帳票一覧表」上に出力実績がない旨の記載があり、取り扱いが不明確
中退共システムが抱える主な課題の解決のため、「①プロ 「予定運用利回りの機動的変更」が今回の再構築においては、必 見積を行う上で影響があることから、前提および条件を確
グラム言語の刷新」、「②法令要な要件であると理解しましたが、要件定義書からは読み取れま 認するため。
等改正時におけるシステム対応の柔軟性の向上 注 1)
せんでした。
」、「③システムにかかるコストの削減」、「④業務効率の向上」を目 的としたシステム再構築を実 本要件が記載された具体的な箇所について、ご教示いただきます
施する。
よう、お願いいたします。
注1 ：予定運用利回りの機動的変更等

また、システム機能詳細一覧が提示されておりますが、システム
機能詳細一覧表の枠を超えて、現行システムより、柔軟性（保守性）を向上する必要がある機能については、具体的にお示しいた
だきますよう、お願いいたします。

図1.(4).2

左記システムについて、「【BA_A02】KF-TS-10_退職金請求、解約 見積を行う上で影響があることから、前提および条件を確手当金請求（口座振替）_1.0版.pdf」を確認すると、「（７１） 認するため。
振込停止ＰＣ」から「（７２)マシン処理」に繋がっており、振込停止システムから中退共電算システムの処理（KEX030）を起動しているように見えます。

再構築後のシステム相関図

上記図の振込停止システムについて

3

ご意見等の提出理由

項番

全般

1

ご意見、修正案、ご質問等

新システムが従うべき要件は、「ドキュメント整備」成果物及び要件定義書にすべて記載されており、その他、現行ソースコードの調査や解析は受託事業者の役務ではない認識でよろしいでしょ
うか。​

(ウ)

要件確認工程では、システム設計・開発等事業者は、「ドキュメント整備」の成果物を確認することにより、現行仕様の調査（統合対象システム及び再構築後に組込む周辺ツールの仕様調査を含む）、要件定義工程の成果物の確認、一部の要件（共通要件）の各成果物への反映を実施すること。

調達仕様書案の業務フローの説明に「全体に跨る要件は、代表的な要件のみ、現行システムの業務フローに対する変更点を「別紙3.(1).4 業務フロー」に整理している。」とあります。

(ウ)

要件確認工程では、システム設計・開発等事業者は、「ドキュメント整備」の成果物を確認することにより、現行仕様の調査（統合対象システム及び再構築後に組込む周辺ツールの仕様調査を含む）、要件定義工程の成果物の確認、一部の要件（共通要件）の各成果物への反映を実施すること。

仕様凍結までに実施が確定した現行システムの改修内容
を、基本設計で取りこむこと。

「要件整理表では、現行システムに対する変更要件を整理しており、変更要件が記載されていない機能については現行仕様を踏襲するものとする。」との方針が示されているおり、現行システム
に対する変更要件は、要件定義書にてすべて示されている認識で
す。

質問

―

見積を行う上で影響があることから、前提および条件を確認するため。

質問―

見積を行う上で影響があることから、前提および条件を確認するため。

要件確認工程で実施する「一部の要件（共通要件）の各成果物への反映」とは、一部の業務フローに対して、既に調達仕様書に記載されている共通要件を反映するということでよろしいでしょう
か。

質問

―

7

調達仕様書
（案）

19

4

(5)

各原課の機能の主な変更点説明
各原課の主な機能に つい て操作方法を説明

質問

8

9

調達仕様書
（案）

調達仕様書
（案）

20

24

4

4

(4)

(７)

次期中退共電算システムの構築にあたり、結合テスト期間
中に環境面を5面構築することとし、システムテスト以降の各環境の基本的な利用方針を「図4.(1).7 工程毎の環境面の利用方針」に示す。

教育内容（シナリオ）や実機操作用のデータを課ごとに変化させる場合、教育準備にかかる費用が膨大になる可能性があります。
各課とも、同じ、教育内容（シナリオ）、データを使用して同様の教育内容で教育を行うよう、要件の緩和をご検討お願いできませんでしょうか。

座学の教育については、貴機構の業務、システムの両方を把握されているシステム担当の職員様にて講師を実施されることが、効率的と考えます。要件を緩和いただけませんでしょうか。

10

11

調達仕様書
（案）

調達仕様書
（案）

25

4

―

5

12

調達仕様書
（案）

29

5

(３)

14

15

16

調達仕様書
（案）

調達仕様書
（案）

調達仕様書
（案）

調達仕様書
（案）

11、
12

―

―

―

1

―

―

―

工程定義

―

―

―

―

―

―

課によって主に使用する画面などは異なるため、各課の使用する画面などの操作が可能となるデータの設定が必要になると考えます。
ただし、同一データにより、各課の研修対象となる画面な
どの操作がすべて可能な場合は、データごとに変化させる
必要はありません。
座学教育は、「実機教育にて教育訓練対象者が操作方法を円滑に理解するため、次期中退共電算システムの前提知識について理解することを目的」としているため、システム設計・開発等事業者に講師を担当していただく必要があると考えています。
ここでは、再構築期間中に、仕様変更が発生し通常と別ス
ケジュールでその対応を実施する際に、その検証等で使用する環境を指しています。
また、システム設計・開発事業者の責による仕様変更の発生など、仕様変更の発生事由により、本調達の範囲になる場合もあると考えています。

―

質問

―

ご認識のとおりです。

質問―

セキュリティ対策を含め、作業体制について（入札参加時の）提案書にてご提案頂き機構内で評価させて頂きます。

原案はそのまま（原則として日本国内）といたしますが、やむを得ず海外拠点を用いる場合は、（入札参加時の）提案書の中でセキュリティ対策や個人情報の扱い、サプライ
チェーンリスクへの対応を含む作業体制をご提案下さい。
機構内で評価させて頂きます。

意見

採用

意見

不採用

契約の分割は可能ですが、協議の上決定いたします。
入札により決定した契約金額の変更および追加費用の請求はできません。

意見

採用

コロナウィルス（COVID‐19）等の外的要因による納期・費
用面に影響が出ることが判明した時点で、機構に報告していただき、協議することといたします。
これらに係る協議全般において、機構が承認しない限り
は、支払いに一切応じませんのでご留意ください。

質問―

ご認識のとおり、機構が提供した資料に、明らかに不備がある場合は別途協議いたします。

意見

採用

現時点、調達仕様書P.26の体制を想定しています。プロ
ジェクトが円滑に進むよう、機構として体制を検討します。

見積を行う上で影響があることから、前提および条件を確認するため。

世界的に影響が出ているコロナウィルス（COVID‐19）により、部 記載内容及び条件の確認をするため。
品供給不足に伴う開発環境用の資材（サーバおよび端末等機器）の納期遅延、または作業者が感染し構築作業の進捗が遅れるといったリスクが想定されます。万一このような事態に至り、本調達の納期に影響がでることが見込まれる場合には、納期および費用について貴機構と協議とさせていただくことは可能でしょうか。

貴機構から提示いただく業務仕様やドキュメント（要件定義成果
物、ドキュメント整備成果物）などに誤りがあり、本役務の作業に影響が出た場合は、別途、スケジュール、工数ともに貴機構と協議いただける認識でよろしいでしょうか。​

記載内容及び条件の確認をするため。

「要件の提示」、「現行仕様の調査」、「貴機構内での調整」、「各種設計書、ドキュメントのレビュー」など貴機構においても、相当な作業量が発生すると想定されます。本調達規模の開発
では、貴機構が十分な体制を確保されることが重要と考えますので、体制確保をご検討いただきますよう、お願いいたします。

プロジェクトフィージビリティと品質を高めるための確認。

1

しかしながら、急遽法改正、行政のデジタル化に伴う止むを得ない現行システムの変更等が生じた場合には、ご意見のとおりご意見のとおり、費用、期間等について別途協議させて頂きます。

質問

見積を行う上で影響があることから、前提および条件を確認するため。

そのため、開発に必要となる見積を正確に行うため、以下のような契約形態とされるのはいかがでしょうか。
（パターン)
・「要件確認」と「基本設計行程以降」にて契約を分割する。
・一括契約し、「要件確認」後に後続の「基本設計行程以降」の再見積を行うことを契約条件に盛り込む。

ウ

不採用

ピーク時に250人を超えるような大規模開発になることが想定され プロジェクトフィージビリティと品質を高めるための確ることや、日本国内の技術者の需要供給状況などから、要員確保 認。
の観点で、日本国内に閉じた開発が難しくなる可能性があると考えております。

本案件は大規模開発の調達となっており、要件確認工程を経ることで、開発対象の全容が正確にわかるものと読み取りました。

一部の業務フローに対して反映済みの共通要件は、「要件整理表（共通_帳票・OCR）」及び要件整理表（共通_ワークフロー）」になります。その他、「要件整理表（共通_画面・権限）」及び「要件整理表（共通_その他）」は業務フ
ローへの反映は実施しておりません。
要件確認工程においては、これらすべての共通要件を、必要に応じて、各成果物に反映することになります。

見積を行う上で影響があることから、前提および条件を確認するため。

例えば以下のような条件を付して、海外拠点での開発を許可いただけますよう、要件の緩和をご検討いただけませんでしょうか。
・個人情報を持ち出さない。
・開発の特性を鑑み詳細設計～結合テストなど特定の工程に限
定する。
ウ

13

意見

(３)

3.関連事業者の作業場所は原則として日本国内とする。

不採用

見積を行う上で影響があることから、前提および条件を確認するため。

設計者や開発者が中心に使用する、設計書やソースコード等については、専門用語が含まれるものであり、設計者と開発者が一意に意味を理解できることがを要件であると理解しておりますが、相違ないでしょうか。

(８)イ

2.作業場所については事前に機構と協議を行い、許可を受 在宅勤務については、セキュリティ対策を行ったうえで、許可いけた場所でのみ作業を実施すること。
ただける認識でよろしいでしょうか。
29

意見「図 4.(7).1 開発期間中の環境面の利用方針」中に、仕様変更対 見積を行う上で影響があることから、前提および条件を確応の線が引かれておりますが、現時点で発生する作業内容が不明 認するため。
なため、本調達の範囲外であると理解しておりますが、相違ないでしょうか。

・日本語で作成し、専門用語や略等は説明文を付すこと。 成果物のエンドユーザ様が目に触れるマニュアルや、各種報告書に関する記載と認識してよろしいでしょうか。

要件確認工程においては、基本的には、「ドキュメント整備」成果物及び要件定義書を確認いただくことを考えています。
ただし、現行システムのドキュメントが存在しないまたは不明確なため、仕様が正しく把握できない場合においては、必要に応じて、システム設計・開発事業者においても、現行ソースコードの調査・解析を実施し、仕様を把握する必要があると考えています。その場合の機構側との役割分担などについては、別途、協議させてください。

ご認識のとおり、現行システムに対する変更要件は、要件定義書にてすべて示されております。

要件整理表に示されていない変更については仕様変更として、仕様、納期、金額含め協議となる認識でよろしいでしょうか。

各原課の機能の主な変更点説明
各原課の主な機能に つい て操作方法を説明

振込停止システムは開発対象といたします。なお、バンキ
ングシステムについては開発対象外といたします。

見積を行う上で影響があることから、前提および条件を確認するため。

要件定義書に記載されていない変更については、正しく作業量を把握することができず、応札業者間でも認識齟齬し、公平な調達にならないものと考えます。

(１)ア

不採用

なお、KHFMの分割は、必須要件ではありません。それ以外の方法でも、柔軟性向上が図れるのであれば問題ありません。

上記を踏まえ、「図1.(4).2 再構築後のシステム相関図」では、再構築後のシステム化対象範囲に、振込停止システムが入っておりませんが、問題無いでしょうか、また再構築を実施すること
で、振込停止システムに影響がある場合も、その改修は本役務の対象外という認識で問題無いでしょうか。

(4)

意見

「システム対応の柔軟性の向上」はシステム再構築の主目的の一つとしており、具体的な機能面について言及するものではなく、システム再構築全般において適用されるものと認識しております。よって要件定義書等に具体的に記しておりません。

「中退共システム再構築に係る開発業務一式」調達仕様書（案）に対するご意見または修正案について
令和3年5月28日
独立行政法人勤労者退職金共済機構

該当する箇所の
章と項番

該当頁
№
該当物

17

18

調達仕様書
（案）

[別紙1.(6).2]【RD_I07_008】
別紙2.1.4_全体
ロードマップ
_1.0版

ページ

―

1

章

―

―

調達仕様書（案）の記載内容（概要でも構いません）

19

1

－

―

―

―

―

－

#ｷｮｳ-1
・初期表示画面（親画面）の閉じるボタンを無効化

20[別紙3.(1).3]【RD_A02_001】
要件整理表（共通_画面・権限）
_2.0版

1

－

21

22

23

[別紙3.(1).7]【RD_E03_002】（R-OR給0002_分
割退職金試算結果）_1.0版[別紙3.(1).8]【BA_B02】帳票
一覧表_1.0版

1

―

全般

―

―

種別

採用／不採用

記載内容及び条件の確認をするため。
質問―

ご認識のとおり可能です。

全体スケジュールに記載の各タスクの期間については、主要マイルストーン及び「機構主体で推進するタスク」を変更しない範囲
において、受託事業者が効率性および実現性等の観点から提案する作業内容に即した作業期間に見直すという認識でよろしいでしょうか。

プロジェクトフィージビリティと品質を高めるための確認。
―

ご認識のとおりです。
仕様書P.11のとおりとなります。
また、業者決定後、契約締結後2週間以内に提出頂くスケ
ジュールや実施計画書等にも同内容を反映して頂きます。

現行システムに存在する「OCRシステム」、「請求書読取システ
ム」、「契約書画像検索システム」は次期システムでは「AI-OCR
システム」、「帳票管理システム」に統合されると理解しましたが、統合先の「AI-OCRシステム」、「帳票管理システム」はパッケージ製品であり、システム設計・開発等事業者によるプログラ
ム開発は発生しないとの理解でよろしいでしょうか。

見積を行う上で影響があることから、前提および条件を確認するため。
―

ご認識の通りです。
ただし、パッケージ製品と基幹系システムなどとの連携機能については、システム設計・開発事業者による開発が必要になると考えています。

記載の要件を実現するためにはOSの制御が必要であり、プログラ
ムからの制御は実現できない認識のため、実現しない方針でのご検討が必要だと考えます。

プロジェクトフィージビリティと品質を高めるための確
認。

質問

質問

意見

回答

テス
ト.1.1
.1

―

不採用

―

帳票レイアウトの1/2ページ目と2/2ページ目のそれぞれの位置づけをご教示ください。

記載内容及び条件の確認をするため。

バッチ処理で出力される帳票にもかかわらず処理形態が「オンライン」や「ディレード」に○が付いている帳票はどのような意図
かお示しください。
（例）
１．バッチ実行後にオンラインやディレードから帳票出力する。
２．バッチ処理をオンラインやディレード処理に変更する。
３．バッチ実行後に帳票管理システム（パッケージ製品）の機能
で帳票出力する。
４．帳票管理システム（パッケージ製品）の機能で帳票を作成・出力する。

スコープの確認のため。

パッケージ製品の選定は入札事業者各社の提案によるものとなりますので、調達仕様書に記載されている要件に従いご提案をお願いいたします。
なお、具体的な仕様などについて不明な点がある場合は、
お問合せください。

意見

不採用

質問

―

2/2ページが当該帳票の帳票レイアウトになります。
1/2ページは不要なので、削除します。

質問―

帳票の出力タイミングと処理形態は整合している必要があります。
ご指摘の内容を踏まえ、要件定義工程における各成果物の内容や成果物間の整合性を確認のうえ、誤りや不明確な点があった場合は、それらを適切に修正します。

質問―オンライン出力とディレード出力の出力先プリンタは同一になるため、同一の帳票定義で対応できると考えていま
す。

質問

―

帳票の出力タイミングと処理形態は整合している必要があります。
ご指摘の内容を踏まえ、要件定義工程における各成果物の内容や成果物間の整合性を確認のうえ、誤りや不明確な点があった場合は、それらを適切に修正します。

質問―

ご認識の通りです。
業務システムに連動するアクティブディレクトリ機能を使
用します。

意見

採用

改修依頼については当該ドキュメントから削除します。
ただし、当該工程における「強化テスト」において検知されたバグ等についてはシステム設計・開発事業者は速やかに改修を実施するものとします。

意見

採用

改修依頼については当該ドキュメントから削除します。
ただし、サービス開始後の契約不適合責任の範囲で必要となる対応を依頼する可能性はあります。

意見

採用

2：紙媒体の帳票類については当該ドキュメントから削除いたします。
現行の紙データの電子化について、次期中退共電算システ
ム再構築時には対応する予定はありません。

質問―

ご認識の通りです。
サーバやストレージ上のディスクを指します。

―

ご認識の通りです。
要件定義工程において、主要なパッケージ製品の標準機能で実現可能な要件以外は、スコープ調整により開発対象外としました。
ただし、パッケージ製品の選定においては、AI-OCRシステ
ム、ワークフローシステム、帳票管理システムに求められる、機能要件および非機能要件を満たす製品を選定する必要があると考えています。
なお、具体的な仕様などについて不明な点がある場合は、
お問合せください。

採用

周辺システムは中退共電算システムとして一つのシステムとして統合されるため、言語が統一されることが望ましいと考えています。
ただし、現行のCOBOL以外の言語もしくは資産を踏襲することが、開発規模の縮小に寄与し、かつ、保守性やセキュリ
ティ等の観点から、Javaで再構築することと相違ないことがシステム設計・開発事業者によって保障されるのであれ
ば、その限りではないと考えています。

―

PoCは、パッケージ製品の実機を利用して、対象業務への適合可能性を検証するために実施するものです。
PoCの具体的な実施内容については、システム設計・開発事
業者からご提案いただくものと考えています。

また、本調達仕様書案を作成される際に、ご検討されたパッケー
ジ製品があるかと考えますが、上記のリスクを低減するため、適当とお考えのパッケージ製品をご指定頂くのはいかがでしょう
か。

１ページ目
２ページ目
項番46 他多数

ご指摘の通り、「閉じる」ボタンを非活性化するためには、OSの制御が必要になりますが、例えば、「閉じる」ボ
タン押下時に、ポップアップなどを起動して、「閉じる」
動作を実行しないといった処理を組み込むなど、アプリ
ケーションプログラムによる制御によって当該要件を実現することが可能と考えています。

最終的なパッケージ製品の選定はPoCを経てご判断されることと推 見積を行う上で影響があることから、前提および条件を確察いたします。
認するため。
本調達仕様案に記載されている要件を順守した上で、PoCの結果、不適格となった場合は、変更契約を行い他パッケージ製品を検討する形となるでしょうか。

帳票レイアウト
1.2

５年間の長期開発となることから、、ご請求に関しては、各工程ごと、または年度ごと等、ご相談させて頂くことは可能でしょうか。受託事業者決定後の契約書を作成する際に、協議となることを想定しております。

#72

PoC
「テスト対象」列及び「テスト観点表」列[別紙3.(1).3]【RD_H08_001】
テスト方針一覧_2.0版

ご意見等の提出理由

項番

システム再構築にあたりシステム統合を行う。
[別紙3.(1).14]【RD_B03_001】
システム相関図_1.0版

ご意見、修正案、ご質問等

上記例１または２の場合、対象となる画面についてお示しください。

オンラインと、ディレード両方から出力される帳票が存在しております。
24[別紙3.(1).8]【BA_B02】帳票
一覧表_1.0版

25[別紙3.(1).8]【BA_B02】帳票
一覧表_1.0版

26[別紙3.(2).2]【RD_H01_002】
セキュリティ方
針一覧_1.0版

27

28

29

30

[別紙3.(2).5]【RD_H03_001】
運用保守方針一
覧_2.0版[別紙3.(2).5]【RD_H03_001】
運用保守方針一
覧_2.0版[別紙3.(2).6]【RD_H04_001】
移行方針一覧
_2.0版[別紙3.(2).6]【RD_H04_001】
移行方針一覧
_2.0版

―

―

―

―

―

―

―

31

C.5.7.
17

C.5.7.
2

7

―

2

全般

現在、バッチ処理にて出力している汎用リスト等の帳票が、オンラインから出力に変更されているように見受けられます。出力対
象のジョブＩＤと、プログラムＩＤが変わっていないことから、どの画面から出力されるのかが不明なため、各出力元の画面をお示しください。

並行稼働開始後の導入サポート期間（ベンダに対して問い 仕様変更に相当する「改修依頼」は現時点で正しく見積もること
合わせや改修依頼できる期間）を「1か月以上」とする。 ができず、公平な調達とならないため、本役務の対象外となるよ
う要件の緩和をお願いいたします。

サービス開始後の導入サポート期間（ベンダに対して問い 仕様変更に相当する「改修依頼」は現時点で正しく見積もること
合わせや改修依頼できる期間）を「1か月以内」とする。 ができず、公平な調達とならないため、本役務の対象外となるよ
う要件の緩和をお願いいたします。

－

スコープの確認のため。

記載内容及び条件の確認をするため。

見積を行う上で影響があることから、前提および条件を確認するため。

見積を行う上で影響があることから、前提および条件を確認するため。

移行媒体は以下の2種類とする。
なお日次バックアップ等、業務運用の中で媒体へのデータ格納が実施されるものについては、移行対象外とする。
D.4.2.
1：ディスク2
2：紙媒体の帳票類

現在紙媒体で管理されている「2：紙媒体の帳票類」については、 見積を行う上で影響があることから、前提および条件を確
現時点で分量や移行内容が提示されておらず、役務内容が一意に 認するため。
特定できないため、移行対象外としていただきますよう、要件の緩和をお願いいたします。

移行媒体は以下の2種類とする。
なお日次バックアップ等、業務運用の中で媒体へのデータ格納が実施されるものについては、移行対象外とする。
1：ディスクD.4.2.
2：紙媒体の帳票類
2

移行媒体の「1：ディスク」については、サーバやストレージ上の 見積を行う上で影響があることから、前提および条件を確
ディスクを意図しているという認識でよろしいでしょうか。
認するため。

ワークフローサーバー、帳票管理サーバー、AI-OCRサーバーに関連するアプリケーション処理方式全般[別紙4.(1).1]【RD_E01_002】
アプリケーション方式設計書_1.0版

出力先プリンタが異なる場合、各々別の帳票定義を作成することが必要となるように見受けられます。
それぞれ帳票定義がいくつ必要かお示しください。

システムへのログイン時にID・パスワードを用いてユーザ 認証はアクティブディレクトリにて行う前提でよろしいでしょう
E.5.1. 認証を行うことで、悪意のある第三者がシステムにアクセ か。
1スすることを防止する。
E.5.1.
2

2

2―

スコープの確認のため。

光ディスクなどの過般媒体を意図されている場合、分量や移行内容が提示されておらず、役務内容が一意に特定できないため、移行対象外としていただきますよう、要件の緩和をお願いいたします。

ワークフローサーバー、帳票管理サーバー、AI-OCRサーバーは市販のパッケージ製品を利用して実現する処理方式と理解しましたが、いずれの処理方式もパッケージ製品の標準機能で実現できること検証済みとの理解でよろしいでしょうか。

見積を行う上で影響があることから、前提および条件を確認するため。

標準機能で実現することができない場合、パッケージ製品のカス
タマイズ開発が必要になることが考えられますが、それに関わる工数・費用は製品の仕様に依存部分が多いと考えられるため、現時点では正確なお見積りを行うことができないと考えておりま
す。

－

質問

従って、製品の標準機能で実現できない処理方式が存在した場合
は要件の取り下げを前提とした協議が必要になると考えますが認識の齟齬等問題はございますでしょうか。

・Java言語のみ​

システム全体の品質を高めるためには、プログラム全体の開発規
模を縮小する必要があると考えております。

プロジェクトフィージビリティと品質を高めるための確認。

（システム特性- 言語数）

32

[別紙4.(2).1]【RD_F01_001】
開発方針定義書
_1.0版

―

―

開発規模の削減に繋げるため、現行中退共電算システム部分ではなく、統合対象の周辺システムについては、COBOL以外の言語（VB.Net,Shell,C 等）をそのまま利用することも選択肢のひとつと考えております。

―

COBOL資産以外の流用について、要件の緩和をご検討いただけませんでしょうか。

PoC「テスト対象」列及び「テスト観点表」列33[別紙4.(3).1]【RD_H08_001】
テスト方針一覧
_2.0版

意見

1

テス
ト.1.1
.1

パッケージ製品のPoCについては、基本設計工程で実施することを 見積を行う上で影響があることから、前提および条件を確予定されていると理解しました。
認するため。
この時点では、連携対象の業務アプリケーションは存在せず、また、開発に使用する環境もないことから、以下の範囲でご確認いただくことでよろしいでしょうか。
・クライアント端末1台のみで確認可能な範囲
・事業者にてデモンストレーションを実施しご確認いただく・WEB画面：画面遷移イメージ（紙芝居）の確認により画面操作性をご確認いただく・パッケージ製品（ワークフロー、AI-OCR、帳票管理）は、製品のデモンストレーションにてイメージをご確認いただく・製品は無償版を使用する。
・パッケージ製品（ワークフロー、AI-OCR、帳票管理）のPoCは各１製品ずつとする。

2

質問

「中退共システム再構築に係る開発業務一式」調達仕様書（案）に対するご意見または修正案について
令和3年5月28日
独立行政法人勤労者退職金共済機構

該当する箇所の
章と項番

該当頁
№
該当物

ページ

章

調達仕様書（案）の記載内容（概要でも構いません）

ご意見、修正案、ご質問等

34

1

―

種別

採用／不採用―「要件定義（要件確認）方針」とは、要件確認工程の方針を示す
成果物を意図していると理解しております。
「要件定義（要件確認）方針」はどのような内容を記載する方針であるかご教示ください。

記載内容及び条件の確認をするため。

また、要件確認で実施すべき作業の方針は、意見招請時点では開調達仕様書（案）【意見招請】
示されていない 「別紙 1 .( 6).1 要件確認工程成果物の作業方
１．(6)ウ 工程定義
針」にて定義されていると想定しております、
詳細は、 「別紙 1 .( 6).1 要件確認工程成果物の作業方
針」を参照。
「別紙 1 .( 6).1 要件確認工程成果物の作業方針」について、ご提供いただきますよう、お願いいたします。

個別計画書における「要件定義（要件確認）方針」には、関連事業者が要件確認工程のタスク（※）を遂行する上で、具体的な作業内容、作業手順等を記載することを考えています。
※要件確認工程で関連事業者が遂行するべきタスクは、「別紙1.(6).2各工程におけるタスク概要」に規定していま
す。
質問

―

質問

―

また、調達仕様書（案）本文との差異を具体的にお示しいただきますよう、お願いいたします。

35[別紙4.(9).1]【RD_I07_007】
別紙2.1.3_成果
物一覧_1.0版（別紙4.(9).1 成果物一覧）【RD_I07_007】別紙2.1.3_成果物一覧_1.0版
工程名：要件確認
AP構築
タスク：AP要件定義＜関連事業者＞
要件整理表（共通）
要件整理表（個別）調達仕様書（案）では、要件確認工程では、（１） 「ドキュメント整備」の成果物を確認（現行仕様の調査）（２）要件定義工程の成果物（要件定義書と推測）確認（３）一部の要件（共通要件）の各成果物への反映（４）（基本設計工程の）先行着手を実施する工程であると定義されていると理解しております。

システム要件検討書
・アクター定義
・業務一覧
・業務フロー・ビジネスルール定義
・機能一覧
・開発方針定義書
・テスト方針・標準用語定義
・名称付与基準

一部の要件（共通要件）の各成果物への反映が必要な要件定義工程の成果物は調達仕様書（案）で、「共通要件（全体に跨る要件）をすべに反映していない」ことを明確に記載していただいていると理解しております。

UI規約［画面ﾚｲｱｳﾄ規約
約 等］

1

―

回答

項番

工程名：プロジェクト開始前
プロジェクト管理＜関連事業者＞
・システム導入方針
・要件定義（要件確認）方針[別紙4.(9).1]【RD_I07_007】
別紙2.1.3_成果
物一覧_1.0版

ご意見等の提出理由―

画面遷移規約、

また、「別紙 1 .( 6).1 要件確認工程成果物の作業方針」
を提供します。当該文書では、要件確認工程にて要件の最終化を行う上で、成果物ごとに作業方針を明確化していります。
［成果物作業方針（調達仕様書（案）より抜粋）］
・要件定義工程の成果物確認・一部要件（共通要件）の各成果物への反映
・基本設計工程の先行着手

記載内容及び条件の確認をするため。

（４）先行着手については、基本設計工程の先行着手であると理解しているため、基本設計工程の成果物を作成する作業と理解しております。
画面部品規約、帳票ﾚｲｱｳﾄ規

そのため、要件確認工程 AP構築 AP要件定義 関連事業者として記載されている左記の成果物については、上記（１）から（３）のどの作業の成果物であるのかご教示ください。

機能定義書
・機能定義
・画面一覧表・画面定義
・画面遷移図・帳票一覧表・帳票定義
・外部インタフェースファイル・レコード定義書
・システム内インタフェース仕様書「別紙 1 .( 6).1 要件確認工程成果物の作業方針」を提供しますので、当該文書を参照ください。

データモデル定義書
・概念ﾃﾞｰﾀﾓﾃﾞﾙ［概念ﾃﾞｰﾀﾓﾃﾞﾙ、
ｴﾝﾃｨﾃｨ一覧]
・ｴﾝﾃｨﾃｨ定義
・CRUDマトリクス（機能レベル）
PoC実施計画書

36

37

38

[別紙4.(9).1]【RD_I07_007】
別紙2.1.3_成果
物一覧_1.0版[要件定義書]【RD_A02_009】
要件整理補足資料（共通_画面）_2.0版[要件定義書]【RD_A02_009】
要件整理補足資料（共通_画面）
_2.0版

1

―

―

（別紙4.(9).1 成果物一覧）【RD_I07_007】別紙2.1.3_成 単体テスト結果の「テスト証跡」とはテスト項目表等消化済み
果物一覧_1.0版
チェックリストを意味すると理解しておりますが、相違ないで
工程名：製造・単体テスト
しょうか。
AP構築
単体テスト結果(ﾕﾆｯﾄﾃｽﾄ・ｺﾝﾎﾟｰﾈﾝﾄﾃｽﾄ)
・テスト証跡・ブラウザの「戻る」「進む」ボタンによる、画面遷移機
能を実装
・画面遷移した情報を自端末内にキャッシュとして保存
し、そこから画面の情報を呼び出し表示10－#ｷｮｳ102

・現行オンライン画面と同様、キー情報（契約者番号／被共済者番号、業務区分・選択番号、指示年月日）をもとに画面遷移する機能を実装
・業務区分にＢ（金融機関業務）などの契約者番号／被共済者番号に紐付かない業務区分を入力後、契約者番号／被#ｷｮｳ- 共済者番号等の欄に金融機関番号等を入力し、指定の画面
103 に遷移（K→Bなどの画面遷移も可）

11

全体見積を行う上で影響があることから、前提および条件を確認するため。

質問

記載の要件を実現した場合、2重更新によるデータ更新不正が起こ プロジェクトフィージビリティと品質を高めるための確る等のリスクがあることなどから、リスク回避を重要視し、実現 認。
しない方針でのご検討が必要だと考えます。
なお、上記リスクを回避するためにブラウザの「戻る」「進む」
ボタンと類似の挙動を実現するための機能を開発することは技術的には可能と思われますが、コスト増となるデメリットがあります。

記載の要件を実現した場合、画面遷移のルート、パターンが複雑 プロジェクトフィージビリティと品質を高めるための確となり、改修時の保守性の低下(影響範囲調査、プログラム修正、 認。
テスト等に関わるコスト増)により、次期システムの主要目的である保守性の向上が阻害されることが危惧されるため実現しない方
針でのご検討が必要だと考えます。
なお、改修時の保守性の低下のみならず、再構築(初期開発)そのもののコストが増加することが考えれられます。

意見

―

不採用

39

1

―

意見

不採用
ただし、実装が不可能ないし甚大な不都合が発生するのであれば、代替案の提案は歓迎致します。

「【RD_A02_011】現行画面機能の新システム踏襲対象確認結果
見積を行う上で影響があることから、前提および条件を確_1.0版.pdf」の「機能概要」欄について、「【RD_A02_001】要件 認するため。
整理表（共通_画面・権限）_2.0版.pdf」に反映されていない要件が記載されております。

なお、「【RD_A02_011】現行画面機能の新システム踏襲対象確認
結果_1.0版.pdf」では、以下のようなWebシステムとして技術的に実現できない内容が含まれております。
--------------------・#1について、「Ctrl＋Pコマンドを実行すると、画面のハードコ
ピーが印刷される。サンプルで言うとボタン部分などは印刷不要。」と記載されていますが、ブラウザの標準機能（ショートカット）の仕様上、「ボタンのみ印刷しない」といった制御ができません。
・#18について、「右Ctrlで送信」と記載されていますが、ブラウザの標準機能（ショートカット）の仕様上、押下されたCtrlキー
が、右Ctrlキーなのか左Ctrlキーなのかを判別することができません。
----------------------

ｷｮｳ-21ｷｮｳ-2240[要件定義書]【RD_A02_013】
要件整理補足資料（共通_帳票・OCR）_2.0版

4

―

―

41

42

[要件定義書]【RD_A02_016】
要件整理補足資料（共通_ワークフロー）_2.0版[要件定義書]【RD_F01_001】
開発方針定義書
_1.0版

18

3

－

1

2.新シ
ステム
での業
務プロ
セスパ
ターン
(15/15)

左記の記載内容については、帳票管理ソフトウェアの入力となる
CSVファイルを使用する認識でよろしいでしょうか。

―

要件定義工程においては、次期中退共電算システムの基本構想において抽出された現行システムに対する要求事項を元にシステム化要件をまとめ、要件定義書にまとめたものになります。
要求事項に挙がっていない現行機能については現行踏襲とし、それらの内容については要件確認工程において整理することとしていますが、その参考情報として、現行画面における機能の踏襲の要望を「【RD_A02_011】現行画面機能の新システム踏襲対象確認結果」にまとめました。
なお、指摘いただいた技術的な制約等については、要件確
認工程において、そのフィージビリティを確認いただいた
うえで、対応方針を機構側と調整するものとします。

―

ご認識の通りです。
調達仕様書において、帳票管理システムに求められる要件として、「帳票の出力形式（紙、PDF、CSV）の指定・変更が標準機能で可能であること」をあげています。

質問―

ワークフローの入力画面の作成や連絡票の回付パターンに応じた承認ルートの設定作業等は、システム設計・開発事
業者の分担と考えています。
なお、それらの作業にあたっては、ワークフロー製品における標準機能により実施することを考えています。

質問―

ご認識の通りです。
現在の各種一覧に過不足はないと考えています。

質問

スコープの確認のため。

帳票の出力形式が「電子のみ」、「紙＋電子」の場合、以 アプリケーション側で上記CSVファイルとは別に、CSVの作成処理
下の出力形式から選択する。
等を実装する場合、開発規模が増加することが考えられます。
– PDFのみ– PDF＋CSV
アプリケーション側で実装する場合は、帳票一覧でCSV欄に「○」が付いている機能で実装すると認識しておりますが、紙媒体・PDFのすべての内容を出力するのか、出力項目の値のみを出力するのか等、CSV帳票の仕様の詳細についてお示しください。

WF起案/データ作成

本件については、現場の非常に強い要望に基づくものであるため、原案通りとさせて頂きます。
データベース等への2重更新による更新不正が起こるリスクについては、職員に対する適切な操作方法の徹底等により低減することができるものと思料します。
ただし、実装が不可能ないし甚大な不都合が発生するのであれば、代替案の提案は歓迎致します。

本件については、現場の非常に強い要望に基づくものであるため、原案通りとさせて頂きます。

「【RD_A02_001】要件整理表（共通_画面・権限）_2.0版.pdf」に記載のあるシステム化要件が正であるという認識で、相違ないでしょうか。
[要件定義書]【RD_A02_011】
現行画面機能の新システム踏襲
対象確認結果_1.0版

ご認識の通りです。
単体テストレベルでは、エビデンスの提示は必須ではございません。ただし、品質懸念発生時等に機構から、単体テ
スト時の単体テストの実行結果等のエビデンスの提示を求める場合があります。

質問

現行業務において職員がExcel連絡票を作成していた部分が次期シ 見積を行う上で影響があることから、前提および条件を確
ステムではワークフロー製品上でデータを入力することになると 認するため。
理解しましたが、Excel連絡票に相当するワークフロー製品上のデータ入力画面を作成する作業の担当は「システム基盤構築等事業者」という認識でよろしいでしょうか。
データ入力画面の作成に関わる工数・費用は製品の仕様に依存部分が多いと考えられ、画面一覧表上記載がなく、必要な画面数も不明なため、現時点では正確なお見積りを行うことができないと考えております。
なお、連絡票の回付パターンに応じた承認ルートに関するワークフロー製品の設定作業等、製品の設定作業そのものに関する分担も上記と同様の考えに従う必要があると考えています。

廃止業務に関する残存プログラム、及び残存する非稼働プ 「廃止業務に関する残存プログラム、及び残存する非稼働プログ
ログラムは不要プログラムとして整理すること。
ラムは不要プログラムとして整理すること。」とありますが、要件定義工程において、廃止業務や非稼働のプログラムは排除された状態で、要件定義書を作成いただいているものと理解しております。
受託事業者は、廃止業務や非稼働プログラムを意識せず、システ
ム機能詳細一覧や画面一覧、帳票一覧などの各種一覧に記載の資1.2.1.
材を構築するものと理解しております。
3.開発
方針
現在の各種一覧に過不足がある場合、明確にお示しいただきます
よう、お願いいたします。

3スコープの確認のため。

「中退共システム再構築に係る開発業務一式」調達仕様書（案）に対するご意見または修正案について
令和3年5月28日
独立行政法人勤労者退職金共済機構

該当する箇所の
章と項番

該当頁
№
該当物

ページ

章

調達仕様書（案）の記載内容（概要でも構いません）

ご意見、修正案、ご質問等

ご意見等の提出理由

種別

採用／不採用

回答

項番

【質問１】
「オンプレミス環境で学習が可能であること」の「学習」とは、以下2つの「学習」の意味を含むと認識していますが認識あっていますでしょうか？
①帳票形式が定型ではなく非定型（※1）の帳票の場合、非定型帳票の項
目箇所を特定する機能についての学習（※1 定形帳票、非定型帳票の定義は別紙1参照）②手書き文字の読み取りについての学習43

調達仕様書本文

15

(３)
３ 情
パッ
報シス
ケージ ア AI OCR システム
テムに
製品に ②オンプレミス環境で学習が可能であること
求める
関する
要件
要件

【質問２】
弊社で提供するAIOCR製品については①についてはオンプレミスの学習が可能ですが、②については製品のポリシーとしてオンプレミス環境のデータについては秘匿性が高いため、学習対象外としております。ただ パッケージ製品のポリシーで一部対応不可の要件があるた
し、同製品のクラウド版で収集した手書き文字データをもとに、年に1回 め。
手書き文字の読み取り機能について、バージョンアップをすることは可能です。（この場合、オンプレミス環境のデータが学習データとなるわ 学習したデータ如何で、読取精度が下がる事もあるため。
けではありません）①はオンプレミス環境で学習が可能、②はオンプレミス環境での学習は不可であるものの、クラウド環境での学習をもとに定期的にバージョン
アップが可能となります。このような対応が許容されますでしょうか？

【質問１】についてご認識の通りです。

質問―【質問２】についてご記載いただいた内容の対応でも問題はありません。
【質問３】について
学習及びバージョンアップを実施しないほうが、総合的なメリットが大きい場合は、学習及びバージョンアップを行
わない選択肢もあると考えています。

【質問３】
初期構築時の読取精度が確立された状態をキープする（※2）為、学習及びバージョンアップを行わない選択肢もあると思いますが、このような考えは受け入れられますでしょうか？
（※2 バージョンアップ対応をすると基本的にはOCRの精度が向上するのですが、項目によっては精度が下がる可能性もあります。初期構築時の状態をキープするとそのような変化がないことにあります）③
住民基本台帳システム（５４０万ステップ）とAI OCRを合わせて使っておられる自治体があります。また、その中で、バッチやRPAで連携をしております。ただし、個々の顧客名を出すのは難しい
ため、エビデンスの部分などについて緩和できる方向にしていた
ア AI OCR システム
③大規模基幹システム（1Mステップ以上）との自動連携の実績が だけないでしょうか。
44

調達仕様書本文

同上

同上

同上

仕様書の実績等の要件について、必ずしも文字通り満たせない箇所があり、そのような要件について、代案を相談し
たいため。

質問

「機構職員がOCRの読み取り設計、設定等ができること」とは、定形帳票について、AIOCR製品に標準で搭載されている設定画面にて、項目の位置・項目の文字種類などを設定することを想定しています。
非定型帳票については、当社が提供するAIOCR製品の項目位置特定機能を使用しますが、当機能は秘密事項のため、手順書を作成し 非定型帳票の読取り設定について、機構職員での設定は難任意の保守ベンダに設定依頼する等の対応も難しく、「機構職員 しいと考えるため。
がOCRの読み取り設計、設定等ができること」には合致しないと考えています。
定形帳票については当該要件を満たし、非定型帳票については当該要件を満たさないと考えますが、このような考えは許容されますでしょうか？

質問あること④システム利用期間を考慮して、製品（メジャーバージョン）に ④
対して5年程度のサポート実績を有すること
いわゆるAI-OCRが市場に出されてから５年たっていないと考えて⑦ワークフローシステム製品、帳票管理製品との自動連携（API おり、条件を満たすことは難しいと思っています。ただし、長期等を使ってシステム間連携）の実績があることで利用を想定している顧客（地方自治体など）に対して導入実績―③⑦について実績について、顧客名を出すことが難しい場合は、顧客の業種や規模など、出せる範囲で記載していただければ問題ありません。
④についてパッケージ製品の調達時点（2023年5月）で「5年程度」の実績があれば問題ありません。

があるため、それを以て実績とできないでしょうか。
⑦
こちら③と同様です。

45

46

調達仕様書本文

調達仕様書本文

同上

同上

同上

同上

同上

同上

ア AI OCR システム
⑥機構職員がOCRの読み取り設計、設定等ができること【質問１】
複数のOCRエンジンの用い方ですが、①「複数のOCRエンジンを搭載した、ひとつの筐体（オンプレミス
機器）」②「データごとに最適な単一のOCRエンジン搭載した、複数の筐体
オンプレ版の場合、機材を買う必要がある為、OCRエンジン選択（オンプレミス機器）の組み合わせ」⑧複数のOCRエンジンを用いて、データ（活字・手書き文の自由度を高めると、その分、費用が高額になる。
のどちらでしょうか？もしくは要件が満たせればどちらでもよろ
単一OCRエンジンでも、データ種類に依らず高精度なら、費用対
字・チェック・丸囲い）にあったエンジンの選択が可能でしいでしょうか？
効果的にも、必ずしも複数OCRエンジンを用意する必要はないの
あること
【質問２】
技術的に、また実績として、複数のOCRエンジンを用いて、データにあったエンジンの選択は可能でございます。ただ、費用対効果を考え、提案については単一のOCRエンジンを用いる想定ですがよろしいでしょうか？

―「定形帳票については当該要件を満たし、非定型帳票については当該要件を満たさない」でも問題ありません。

【質問１】について「①「複数のOCRエンジンを搭載した、ひとつの筐体（オン
プレミス機器）」を考えています。

質問―ではないか。

【質問２】について
読取り精度の観点から、複数のOCRエンジンから選択可能な製品の採用を考えています。
ただし、ご指摘のように、費用対効果の観点から、単一のOCRエンジンの利用のみでも、複数のOCRエンジンの利用と同等もしくはそれ以上の読取り精度が担保されている場合
は、例外もあり得ると考えています。

【質問１】
基本設計フェーズに実施するAIOCRのPoCの位置づけ（意図、どのようなことを検証するか）をご教示いただけますでしょうか？
～弊社の想定～意図：対象帳票のうち、基準を満たすか本番導入を行う帳票を見極めるもの
どのようなことを検証するか：精度・コストなど基準を設け、基準を満たすか確認する～～～～～～～【質問１】について貴社の想定する内容と概ね認識齟齬はありません。

【質問２】
上記弊社の想定の上で、以下のようなPoCの進め方は受け入れられますでしょうか？
＜PoC進め方案＞
帳票ごとに「①読取精度目標」「②コスト目標」を設定し、もしPoCにて①②を両立できない場合、その帳票については本導入の対象外とする（人がパンもしPoCの結果に関係なくすべての対象帳票をAIOCRの対象
チ入力する）。

47

調達仕様書本文

18

４ 作
・基本設計フェーズにおける、再構築後の画面イメージ、
業 の(３)
操作感等の確認、ワークフロー、 AI OCR 、帳票管理機能とすると開発時・運用時にコスト増となり、人がパンチ入実施内 テスト＜本導入に適さない事例１＞
等の新規機能の PoC Proof of Concept ）の実施
力するよりも機構様の負担が増えるため。
容
ある帳票について、PoCの結果、非定型の帳票であることがわかり、非定型帳

質問―票の読取りプログラムを作成する必要があることが判明。ただし、非定型帳
票の読取りプログラムを作成すると、人がパンチ入力するよりもコスト増となり、本導入を見送った。

【質問２】について貴社の想定する内容と概ね認識齟齬はありません。
ただし、PoCに採用したAI-OCR製品の読取り精度に問題があると考えられる場合は、当該製品を不採用とする場合もあると考えています。
【質問３】
AI-COR製品の設定変更などにより読取り精度の向上が期待できる場合は、当該対応を繰り返し実施しますが、追加プ
ログラム開発などは考えていません。

＜本導入に適さない事例２＞
帳票Aは読取精度目標が非常に高く、OCRの結果補正を2人で行う必要があり、運用フェーズにおいて人がパンチ入力するよりもコスト増となり、本導入を
見送った。
【質問３】
もし上記【質問２】とは異なり、帳票ごとに本導入の判定を行わない場合、基準を満たすまで追加での対応（追加プログラム開発、追加要員を用いたフローの検討）を行う必要があるでしょうか。

48

別紙4

⑩AI-OCRサービスはOCR読取結果を帳票サービスに返却す
9. OCR 9.4.
る。
33/74 入力処 処理概⑪帳票サービスはOCR読取結果をデータベースサービスに
理方式
要
連携し、データベースへの登録依頼を実行する。

「AI-OCRサービスはOCR読取結果を帳票サービスに返却」とのこと
ですが、具体的には以下２つのどちらの想定でしょうか？
①AI-OCRが項目ごともしくは帳票ごと読み取るたびに帳票サービ
スに返却するAIOCRから帳票サービスへの連携仕様を確認したいため。
②AI-OCRが数枚の帳票を読み取り、結果ファイル（CSVファイル）をはきだしたらそれをまとめて帳票サービスに返却する

質問―①および②のどちらの方式でも問題ありません。

②はAIOCRの標準機能で実装できますが、①は追加開発が必要とな
ります。

【質問１】
AIOCRパッケージの標準機能であるOCR読取結果修正画面にて修正を行うのではなく、帳票サービスのWEB画面でOCR読取結果を修正する仕様としているのは、誰がどのように修正を行ったかのログを取得するためと認識していますが、合っていますでしょうか？

49

50

51

別紙4

別紙4

調達仕様書本文

10.
OCR入 10.2.
⑮システム利用ユーザが帳票サービスのWeb画面により、
AIOCRパッケージには、OCR結果を人が確認し補正する画面
力（参 処理方
34/74
OCR読取結果を修正し更新リクエストをWebサービスに送信が標準で搭載されているため、そちらを利用する方針は受照、更 式概要する。
【質問２】
け入れられるか確認したいため。
新）処図
もしログが取得できる場合、AIOCRパッケージの標準機能である
理方式
OCR読取結果修正画面にて修正を行うような仕様は受け入れられますでしょうか？

『【RD_F01_002】開発方針マトリクス_1.0版.pdf』の「キョウ36」には外字登録の検討が要件として記載されています。
一方で、
1.3.2.
『 【RD_F01_001】開発方針定義書_1.0版.pdf』の「1.3.2. 定義
定義要要素(14) 文字コード/外字登録の標準化」には外字利用の脱却にそのような状況において、次期中退共電算システムではシ素(14)ついての記載があります。
1.3.
ステム固有の外字の利用から脱却し、
文字
AIOCR導入にあたり、外字の対応有無によって、対応内容
9/40 処理方
汎用的な文字情報基盤を活用することで、現行同等の表記
コード【質問】が異なるため。
式の正確さと柔軟性を両立したシステ/外字
AI-OCR利用業務において、「外字の取扱いは無くなる」と考えてム構築に取り組むことが必要と考える。
登録のよいでしょうか？
標準化「外字の取扱いは無くなる」場合、そのタイミングは、導入当初
からでしょうか？
あるいは、導入当初は外字の取り扱いを継続し、段階的に外字の取扱いを無くしていくのでしょうか。

12２ 調
システム設計・開発等事業者が担当達案件する工程定義上のタスクを以下に整理する。
及び関
連調達 (１)
案件の 調達範
調達単
囲「システム基盤設計」タスク
位、調
達の方
式等

基盤構築（HW, MW）領域の調達範囲には、「システム基盤詳細設計・構築」、「システム基盤単体テスト・システム基盤テスト」が含まれていませんが、これらは、「別紙1.(6).3 全体スケジュール」では、「システム基盤構築等事業者」がこれらを請け 「システム基盤設計」タスクの依存関係（クリティカルパ
負うよう読み取れ、調達時期が2022年度となっています。
ス）を明確にしたいため。
一方で、表2 .(2).1 本調達及び関連する調達案件の調達単位、調達の方式等には、2022年度中に調達・契約する案件が見当たりま
せん。

4

【質問１】
ログの取得ののみではなく、AI-OCRによる読取り結果の保存・検索を実現するために、AI-OCRシステムと帳票管理シ
ステムを連携させた処理方式を考えています。
質問

―
【質問２】
AI-OCRシステムおよび帳票管理システムの要件を満たすのであれば、AI-OCRパッケージの標準機能により修正を行う
仕様でも問題ありません。

質問

質問

―

ご指摘のとおり、次期中退共電算システム導入当初から外字の取り扱いを無くす計画となっております。
なお、次期中退共電算システムではUnicordにおけるJIS第3、第4水準等、およびISO/IEC 10646に該当する「戸籍統一文字及び、住基統一文字」の採用により現行システムの外字領域をカバーできると考えております。

―

ご質問の役務は本調達の範囲ではないので記載しておりません。
「表2 .(2).1 本調達及び関連する調達案件の調達単位、調達の方式等」には記載いたします。

「中退共システム再構築に係る開発業務一式」調達仕様書（案）に対するご意見または修正案について
令和3年5月28日
独立行政法人勤労者退職金共済機構

該当する箇所の
章と項番

該当頁
№
該当物

52

調達仕様書本文

ページ

18

章

調達仕様書（案）の記載内容（概要でも構いません）

ご意見、修正案、ご質問等

ご意見等の提出理由

種別

採用／不採用

回答「旧」データを受託事業者が作成する場合、見積に大きく影響があるため。

質問―

ご認識の通りです。

項番

また、テスト計画の策定にあたっては以下の内容について留意し、確認観点、及び連携を必要とする機構体制や事業者との作業等について明記する
左記のとおり、新旧同一性検証は、結合テスト、システムテス
こと。
ト、受入テストにて実施となっていますが、各テストにおける
４ 作「旧」データは機構様より提供されると考えてよろしいでしょう
業 の(３) ジ、操作感等の確認、ワークフロか。
実施内 テスト ー、 AI OCR 、帳票管理機能等の新規機能の PoC Proof
また、その場合、結合テストまでの作業場所は関連事業者にて用容
of Concept ）の実施意するとのことですが、データのマスキング等は機構様にて対応の上提供されると考えてよろしいでしょうか。
テム仕様を元にしたテストシナリオを元に実施する想定）【RD_A02_006】要件整理表（共通̲ワークフ
コメント欄ロー）̲2.0版

53

別紙3

54

調達仕様書本文―

55

調達仕様書本文

12

56

57

58

調達仕様書本文

調達仕様書本文

調達仕様書本文

14

15

27

―

―

3

5

―

―

(3)

―

「WFソリューションにおける標準機能のため～」との記載がありますが、特定の製品を想定した記述と推測いたします。ご参考までに検討された製品をご教示いただくことは可能でしょうか。

ご提案するWF製品の選定において重要な情報と考えるた
め。

質問

―

特定の製品を想定しているわけではありません。
要件定義工程においては、複数の製品を対象に調査を実施しました。

調達仕様書（案）には記載なし

調達仕様書に現行システムの規模（画面数、帳票数等）がわかる
情報の記載を検討ください

見積を実施する際の情報として活用する可能性があるため

意見採用

参考情報として提示します。

表2 .(2)

表2 .(2).に「システム基盤構築等事業者」の調達の記載がござい 関連する事業者の調達を踏まえて開発スケジュールや見積ません。記載漏れであれば追記をお願い致します。
に影響があるため

意見採用

記載いたします。

運用保守方針一覧

導入する機器の設置場所の指定があれば記載をお願い致します。
また機構本部で作業する際の制約などもございましたらあわせて記載をお願い致します。

不採用

導入する機器は、国内のデータセンターに設置する計画です。
データセンターは、システム基盤構築等事業者の調達時に決定します。

(３) パッケージ製品に関する要件

運用保守対応に関する要件を明確にするためパッケージ製品は本調達で提供する対象製品との認識で間違いな
いかご教示ください。(システム基盤構築等事業者調達での対象で 見積情報として必要なためはないか気にしております。）

システム基盤構築等事業者のタスクで以下記載がございますが、このタスクは正しいかご教示ください。
別紙3と別紙4で移行に関する資料を拝見しておりますが、『移行ツール詳細設計や製造、テスト』は、システム設計・開発等事業
システム設計・開発等事業者とシステム基盤構築等事業者 者のタスクではないでしょうか。
のタスク項目における移行について＜調達仕様書（案）抜粋＞

意見

パッケージ製品の調達は、システム基盤構築等事業者調達となります。
ただし、本調達時に、システム設計・開発事業者からパッケージ製品の提案をいただき、本調達の基本設計工程おいて、導入するパッケージ製品のPoCを実施する計画になって
います。

質問

―

各事業者で実施すべきタスクを明確にするため

質問―システム移行（基盤切替）に係る移行作業は、システム基盤構築等事業者のタスクになります。

安定したプロジェクト運営を実現するため

意見

不採用

本調達では必須の資格要件とはいたしません。
資格保持者が体制に含まれる場合は（入札参加時の）提案書にご記載ください。

採用

遅延発生の都度、遅延報告書の作成要否を調整すること
は、機構側の作業負担増大につながると考えるため、原則、6日以上の遅延の場合は、遅延報告書の提出を必須とします。
ただし、例外もあるため、ご指摘を踏まえ、「また、 6 日以上の遅延が発生した場合
は、遅延報告書を作成し、機構に提出すること。ただし、機構が不要と判断した場合は、この限りではない。」に修正します。

「本番移行 リハーサル」「本番移行」「最終移行リハーサル」「最終移行」 タスク（システム移行）」

59

60

調達仕様書本文

調達仕様書本文

29

30

5

5

(2)

(4)

今回のプロジェクトは大規模なシステム開発となりますので、資調達仕様書（案）では、プロジェクトマネージャーの資格 格要件はプロジェクトマネージャーのみではなく、ネットワーク
要件のみ記載されている。
スペシャリストやデータベーススペシャリストの資格要件を追加することが望ましいと想定しております。

各工程実行中に、関連事業者は週次で個別進捗報告書を機全ての該当事象に関して遅延報告書を作成するのではな
6日以上の遅延が発生した場合は機構と相談し、必要に応じて遅延構に提出すること。また、 6 日以上の遅延が発生した場
く、まず機構に相談し、報告書の作成可否を判断すること
報告書を作成し、機構に提出すること。
合は、遅延報告書を作成し、機構に提出すること。
で、効率的な対応工数の削減が可能となると考える。

5

意見