Contract
総務局⾏政改⾰推進部ICT基盤管理課
「新たな電⼦申請・届出システムの導⼊及び運⽤保守業務委託契約」契約結果
新たな電⼦申請・届出システムの導⼊及び運⽤保守業務委託について、公募型プロポーザル⽅式で、受託候補者を特定し、次のとおり契約しました。
1 件名 新たな電⼦申請・届出システムの導⼊及び運⽤保守業務委託
2 委託内容
(1) プロジェクト管理
(2) システム導⼊作業
(3) 機能開発及びテスト
(4) データ移⾏及び⽀援
(5) サービスの提供
(6) 職員への運⽤⽀援
(7) 職員研修
(8) サポートセンターの提供
3 契約の相⼿⽅ 株式会社TKC
4 契約⾦額
68,178,000 円
5 契約⽇
令和3年9⽉ 10 ⽇
6 評価結果
提案者 | 評価点数(19,110 点満点) | 順位 |
株式会社 TKC | 15,775 | 1 |
株式会社エヌ・ティ・ティ・データ関⻄ | 15,240 | 2 |
富⼠通 Japan 株式会社 神奈川⽀社 | 14,400 | 3 |
7 評価基準・評価委員会開催経過等
(1) 評価基準
別紙のとおり。
(2) 評価委員会開催経過等
委員会開催⽇時 | 第⼀回 | 令和3年7⽉1⽇(⽊)13:00〜16:00 | |
第⼆回 | 令和3年 7 ⽉ 13 ⽇(⽕)14:00〜14:15 | ||
委員会開催場所 | 第⼀回 | 市庁舎 27 階共⽤会議室(27-S02) | |
第⼆回 | 市庁舎 22 階共⽤会議室(22-S04) | ||
評価委員の出席状況 | 第⼀回 | 評価委員7名中 7 名出席 | 充⾜率:7/7 |
第⼆回 | 評価委員7名中 7 名出席 | 充⾜率:7/7 | |
議事内容 | 第⼀回 | ・提案者xxxxxの実施 | |
第⼆回 | ・評価結果の集計及び集計結果の確認 ・受託候補者の決定 | ||
事務局 | 総務局⾏政改⾰推進部ICT基盤管理課 |
8 問合せ先
総務局⾏政改⾰推進部ICT基盤管理課担当 細⽥、⻄川、⼭村
電話 000-000-0000
E メール xx-xxxxxx@xxxx.xxxxxxxx.xx
1 評価事項
提案書に対する評価項目や評価の視点等は別紙「提案書評価項目一覧」を参照。
2 評価方法
(1) 評価
各評価項目について、次のいずれかの評価を行う。ア A、 Eの2 段階評価
イ A、 C、E の3 段階評価
ウ A、 B、 C、 D、E の5段階評価
(2) 評価点
評価を基に表1のように評価点を算出する。
表1 評価点の算出
配点 | 評価点 | ||||
A | B | C | D | E | |
200 | 200 | 160 | 120 | 80 | 40 |
100 | 100 | 80 | 60 | 40 | 20 |
100 | 100 | 60 | 20 | ||
50 | 50 | 40 | 30 | 20 | 10 |
50 | 50 | 30 | 10 | ||
30 | 30 | 20 | 10 | ||
30 | 30 | 10 |
3 提案者の選定方法及び受託候補者の特定方法
(1) 評価項目について、委員長及び副委員長を含む全ての評価委員が与えた合計点が最も高い者を受託候補者として特定します。
(2) 総合計点を比較してもなお、受託候補者を特定できない場合には、次の順序で受託候補者を特定します。
ア 「機能要件の実現」の合計点が上位の者 イ 「非機能要件の実現」の合計点が上位の者ウ 「基本的事項」の合計点が上位の者
評価項目 | 記述内容(要求要件) | 評価の着眼点 | 配点 | 評価基準 | ||||||
A | B | C | D | E | ||||||
1 基本的事項 | ||||||||||
1.1 企業実績 | ||||||||||
1.1.1 従業員数 | 従業員数及びプロジェクトメンバー以外に代替できる要員の有無を記載してください。 | 十分な従業員数があり、不慮の事故等の際のプロジェクト関係者の代替が可能なこと。 | 100 | 従業員数が300人より多く、プロジェクトメンバー以外の要員の代替が可能である。 | - | 従業員数が300人以下である が、プロジェクトメンバー以外の要員の代替が可能である。 | - | プロジェクトメンバー以外の要員の代替ができない | ||
1.1.2 本業務と同種・類似業務の事業実績 | プラットフォームとしての電子申請・届出システム(職員が様々な手続を自由に作成・運用できる電子申請・届出システム)について、政令指定都市における運用期間の実績を記載してください。 | 政令指定都市におけるプラットフォームとしての電子申請・届出システムの運用に関する十分な経験を有しているか(運用保守の経験期間は十分 か)。 | 100 | 政令指定都市における運用実績の期間が2年以上である。 | - | 政令指定都市における運用実績の期間が1年以上2年未満である。 | - | 政令指定都市における運用実績の期間が1年未満である。 | ||
1.2 配置予定技術者の業務実績・経験等 | ||||||||||
1.2.1 プロジェクト管理者 | 電子申請・届出システムの導入・移行及び運用保守のプロジェクトの実績・経験等を記載してください。 | 自治体(特に政令指定都市)における電子申請・届出システムの導入・移行・運用保守プロジェクトの管理又はそれに準ずる経験があるか。 | 50 | 政令指定都市における電子申請・届出システムの導 入・移行・運用保守プロ ジェクト経験が複数ある | 政令指定都市における電子申請・届出システムの導 入・移行・運用保守プロ ジェクト経験がある | 国・自治体における電子申請・届出システムの導入・移行・運用保守プロジェクト経験がある | 電子申請・届出システムの導入・移行・運用保守プロジェクト経験がある | 業務実績・能力に不十分な点がある。 | ||
1.2.2 チームリーダーA | 電子申請・届出システムのサービス導入や移行の実績・経験等を記載してください。 | ・自治体(特に政令指定都市)における電子申 請・届出システムの導入・移行に関する経験を有しているか。 ・チームリーダーとして十分な経験を有しているか。 | 50 | 政令指定都市における電子申請・届出システムの導 入・移行プロジェクト経験が複数ある | 政令指定都市における電子申請・届出システムの導 入・移行プロジェクト経験がある | 国・自治体における電子申請・届出システムの導入・移行プロジェクト経験がある | 電子申請・届出システムの導入・移行プロジェクト経験がある | 業務実績・能力に不十分な点がある。 | ||
1.2.3 チームリーダーB | 電子申請・届出システムの運用保守の実績・経験等を記載してください。 | ・自治体(特に政令指定都市)における電子申 請・届出システムの運用保守に関する経験を有しているか。 ・チームリーダーとして十分な経験を有しているか。 | 50 | 政令指定都市における電子申請・届出システムの運用保守プロジェクト経験が複数ある | 政令指定都市における電子申請・届出システムの運用保守プロジェクト経験がある | 国・自治体における電子申請・届出システムの運用保守プロジェクト経験がある | 電子申請・届出システムの運用保守プロジェクト経験がある | 業務実績・能力に不十分な点がある。 |
評価項目 | 記述内容(要求要件) | 評価の着眼点 | 配点 | 評価基準 | |||||||
A | B | C | D | E | |||||||
2 | 機能要件の実現 | ||||||||||
2.1 要件一覧への適合 | |||||||||||
2.1.1 必須項目の実現 | 別添の「機能要件一覧」の必須項目の機能を実現できるかどうか、別紙「機能要件対応表」に記載してください。 | 「機能要件対応表」の必須項目の機能を実現できるか。 【別紙に基づき評価】 機能実現が出来ない又は実現手法に課題があり、実用には問題がある場合は不合格。 | - | ヒアリング対象外 | |||||||
2.1.2 任意項目の実現 | 別添の「機能要件一覧」の任意項目の機能を実現できるかどうか、別紙「機能要件対応表」に記載してください。 | 「機能要件対応表」の任意項目の機能を実現できるか。 【別紙に基づき評価】 | 340 | ヒアリング対象外 | |||||||
2.2 アプリケーション | |||||||||||
2.2.1 システム概要 | システムの構成や機能概要、手続の一連の流れ (申請から受領・審査・交付文書発行など)について、記載してください。また、システムの特長について記載してください。 | 概要であり、評価は以下の詳細で行うこととする。 | - | 評価対象外 | |||||||
2.2.2 共通機能 | , | ||||||||||
2.2.2.1 ポータル機能、ヘル プ・ガイド機能 | ポータル機能、ヘルプ・ガイド機能について、機能内容、画面レイアウト及び画面遷移図を記載してください。 | ポータル機能、ガイド機能が、利用者の視点から具体的であるか。目的の手続きが探しやすく(分類で分けられている、手続名で検索できるな ど)、初めての利用者でも使い方がわかるようなガイドになっているか。 | 50 | 具体的で理解しやすく、目的の手続が探しやすい。 | - | 理解でき、目的の手続が探せ る。 | - | 分かりにくく、目的の手続が探しにくい。 | |||
2.2.2.2 アクセシビリティ | 目の不自由な方、外国語を母国語とする方など、様々な利用者が使いやすいような工夫・配慮について記載してください。 また、アクセシビリティJISの等級AAの対応状況を提示してください。(WAICのJIS X 8341- 3:2016 試験実施ガイドラインにおける達成基準チェックリストの等級A及びAAの項目の適合状況について記載してください) | 様々な利用者が使いやすいような工夫・配慮がされているか。 | 50 | 障害者、母国語が日本語でない方のどちらに対しても使いやすいような工夫・配慮がされている。 | - | 障害者、母国語が日本語でない方のいずれかに対して使いやすいような工夫・配慮がされている。 | - | 障害者、母国語が日本語でない方に対する工 夫・配慮が足りていない。 | |||
アクセシビリティJISの達成基準チェックリストの対応状況が等級A及びAAに適合しているか。 | 50 | 市民側及び職員側について、等級AAに準拠している。(AA及び Aの項目全てに適合している) | 市民側につい て、等級AAに準拠している。 (AA及びAの項目全てに適合している) | 市民側及び職員側について、等級Aに準拠している。(Aの項目全てに適合している) | 市民側について、等級Aに準拠している。 (Aの項目全てに適合している) | 市民側につい て、等級Aに準拠していない。 | |||||
2.2.3 市民側利用者機能 | |||||||||||
2.2.3.1 UI/UX(ユーザイ ンターフェース/ユーザエクスペリエンス) | 市民(申請者)がサービスを利用する上で、サイトのデザインも含め、使いやすいUI(ユーザインターフェイス)の構築やUX(ユーザエクスペリエンス)を高めるために配慮されている点があれば、記載してください。 | 市民(申請者)がサービスを利用する上で、サイトのデザインも含め、使いやすいUIを構築していること。 電子申請・届出サービスを使って申請したいと申請者に思わせるようなUXを向上させる取り組みが行われていること。 例:ワンスオンリー(申請者に同じ内容を入力させない) 電子署名や電子決済などの機能が一連の入力の流れの中でスムーズに使用できること。 | 200 | デザイン、UI、 UXの取り組みが優れている。 | デザイン、UI、 UXの取り組みが良い。 | デザイン、U I、UXの取り組みに良いものがある。 | デザイン、U I、UXの取り組みが良いとは言えない。 | デザイン、U I、UXの取り組みが不十分である。 |
評価項目 | 記述内容(要求要件) | 評価の着眼点 | 配点 | 評価基準 | |||||||
A | B | C | D | E | |||||||
2.2.4 職員側利用者機能 | |||||||||||
2.2.4.1 UI/UX(ユーザイ | ・職員がサービスを利用する上で、サイトのデザ | ・職員がサービスを利用する上で、サイトのデザ | デザイン、UI、 | デザイン、UI、 | デザイン、UI、 | デザイン、UI、 | デザイン、U | ||||
ンターフェース/ユー | インも含め、使いやすいUI(ユーザインター | インも含め、使いやすいUIを構築しているこ | UXが優れてい | UXが良い。 | UXに良いもの | UXが良いとは | I、UXが不十 | ||||
ザエクスペリエンス) | フェイス)の構築やUX(ユーザエクスxxxx | と。 | る。 | がある。 | いえない。 | 分である。 | |||||
ス)を高めるために配慮されている点があれば、 | ・電子申請・届出サービスを使って手続を作成し | ||||||||||
記載してください。 | たいと職員に思わせるようなUXを向上させる取 | ||||||||||
・手続の作成にあたって、決済や証明書データの | り組みが行われていること。 | 100 | |||||||||
利用、電子署名の利用や受付・審査のフロー設定 | |||||||||||
等、手続ごとに異なる各種利用機能の設定方法に | |||||||||||
ついて記載し、利便性・効率性向上のための仕組 | |||||||||||
みについても記載してください。 | |||||||||||
・申請の受付等の処理を行う業務担当職員が利用 | |||||||||||
する際の利便性・効率性向上の仕組みがあれば記 載してください。 | |||||||||||
・手続の作成方法が具体的であり、操作が簡単に 行え、業務が効率的に行える仕組みがあること。 | 利便性・効率性 向上の仕組みが | 利便性・効率性 向上の仕組みが | 利便性・効率性 向上の仕組みに | 利便性・効率性 向上の仕組みが | 利便性・効率性 向上の仕組みが | ||||||
・受付・審査等の方法が具体的であり、操作が簡 | 優れている。 | 良い。 | 良いものがあ | 良いとはいえな | 不十分である。 | ||||||
単に行え、業務が効率的に行える仕組みがあるこ | る。 | い。 | |||||||||
と。 | |||||||||||
例:市民の入力フローや申請後の職員のワークフ | 100 | ||||||||||
ローの設計が簡単にできる。受付・審査等の処理 | |||||||||||
を効率的に行う仕組みがあるなど | |||||||||||
2.2.4.2 ユーザ認証 | ユーザ認証について、2要素認証など、正当な権 | 正当な権限をもったユーザによる利用を確保しつ | 認証基盤システ | - | 利便性とセキュ | - | 利便性が低く運 | ||||
限をもったユーザによる利用を確保するための認 | つ、利便性も期待できる認証方法であること。 | xとの連携実績 | リティ確保が期 | 用に耐えない、 | |||||||
証をどのように実現するか記載してください。 | があり、実現性 が高い。また | 待できるユーザ 認証である。 | 又はセキュリ ティが不十分な | ||||||||
自治体の認証基盤と連携している例があれば、それも記載してください。 | 50 | は、利便性とセ キュリティに優れたユーザ認証 | ユーザ認証であ る。 | ||||||||
である。 | |||||||||||
2.2.4.3 ユーザ管理 | ユーザの権限の種類と機能、設定できる範囲など | 業務を行っている担当範囲内、課範囲内での作成 | 業務に必要な範囲での手続の共有ができ、かつ課長が課内の ユーザの利用権限を設定でき る。 | - | 業務に必要な範 | - | 業務に必要な範 | ||||
を記載してください。また、作成した手続の共有 | した手続の共有など、業務に必要な範囲(グルー | 囲での手続の共 | 囲での手続の共 | ||||||||
範囲など、ユーザとグループの考え方について具 | プ)での利用権限の設定が行えること。グループ | 有ができ、効率 | 有が十分にでき | ||||||||
体的な記載をし、効率的にユーザ権限を管理する方法も記載してください。 | は部・課・担当の階層構造で管理できるなど、実際の組織に即した管理ができること。(各課長が課内のユーザの権限を設定する運用が可能である | 50 | 的にユーザの利 用権限の管理ができる。 | ない。 ユーザ管理が煩雑である。 | |||||||
こと。) | |||||||||||
2.2.4.4 申請様式の機能 | 申請様式のデザインや計算式、エラーチェック | 申請様式のデザインや計算式、エラーチェックな | 機能の作りこみ | 使用できる機能 | 使用できる機能 | ||||||
等、どのような内容まで作りこみを行えるのか | どの機能が十分備わっており、機能を活用するこ | が自由に行え | が多く、大部分 | が少なく、手続 | |||||||
(特定機能であればそのリスト)を示してくださ | とで効率的な電子手続の作成ができること。(機 | る。 | の手続が問題な | 所管課で運用の | |||||||
い。 | 能の作りこみが自由に行える、または使用できる機能が多く、様式上で想定される計算やエラー チェックの大部分が対応可能であること。) | 50 | - | く作成できる。 | - | 負荷(エラー チェックなど)が多く発生すると想定される。 |
評価項目 | 記述内容(要求要件) | 評価の着眼点 | 配点 | 評価基準 | |||||||
A | B | C | D | E | |||||||
2.2.5 システム間連携 | |||||||||||
2.2.5.1 ネットワーク構成変更 対応 | 本市のネットワーク構成が変更となり、職員が LGWANの利用から、インターネットや専用線等で利用することになった場合に、どのような対応が可能か記載してください。 また、その対応実施に当たってどの程度の負担が発生するか記載してください。 | インターネットや専用線など、LGWAN以外の方法でも職員側機能が利用可能であること。また、2要素認証などで正当な権限をもったユーザによる利用を確保できること。 変更作業の負担が少ないこと。 | 50 | 提案内容に具体性があり、ネットワーク構成変更の場合も効率的に業務ができる。 | - | 提案内容に具体性があり、ネットワーク構成変更の場合も業務ができる。 | - | ネットワーク構成変更の場合に業務が困難になる。 | |||
2.2.5.2 業務システム連携対応 | 他業務システムとのデータ連携についてどのように実現するかを記載してください。 連携によって業務効率化が行える方法があれば記載してください。 | 業務システムとの連携について実現する方法や考え方が記載されており、その結果業務効率化が期待できること。 | 50 | 電子申請・届出システムにAPI等の連携機能が用意されてい る。 | - | 電子申請・届出システムの作りこみをすれば対応可能である。 | - | 他システムとの連携はできな い。または具体性がなく確証がない。 | |||
2.2.5.3 決済サービス | 利用可能な決済サービス(クレジットカード、 Pay-easy、コード決済(PayPay等)など)を記載してください。 また、今後利用可能となる決済サービスの予定があれば、スケジュールを記載してください。 | クレジットカードの他、様々な決済サービスが利用できること。 | 50 | クレジットカードに加えてその他の決済サービスが複数利用できること。(予定含む) | - | クレジットカードに加えてその他の決済サービスが1種類利用できること。 (予定含む) | - | クレジットカードが利用できること。 | |||
3 非機能要件の実現 | |||||||||||
3.1 運用保守、監視、サポートセンター | |||||||||||
3.1.1 運用保守、監視要件 | |||||||||||
3.1.1.1 運用保守要件 | 運用保守(運用管理、障害対応その他バックアップ方法や過去データの保管方法等も含む。)及び監視について、貴社の考えを記載してください。 | 運用保守(運用管理、障害対応その他バックアップ方法や過去データの保管方法等も含む。)及び監視の考え方や体制が適正かつ具体的であるこ と。 | 50 | 考え方及び体制が具体的に示されており、非常に優れている。 | 考え方及び体制が具体的に示されており、優れている。 | 考え方及び体制が具体的に示されており、適正である。 | 考え方及び体制が具体的に示されているが、適正であるとは言えない。 | 考え方及び体制が具体性に欠けている。 | |||
3.1.1.2 監視保守要件 | 市民サービスに直結するシステムであることを踏まえ、サービス提供が滞る障害をなくすために、貴社がとられている仕組みや対策を具体的に記載してください。 また、障害発生時やメンテナンス時の対応の周知や連絡体制についても記載してください。 | 負荷や重要性に応じ、サービス提供が滞る障害がないような仕組みや対策が具体的であること。 障害発生時やメンテナンス時における対応や体制が具体的であること。 | 50 | 内容が具体的であり、非常に優れている。 | 内容が具体的であり、優れている。 | 内容が具体的かつ適正であると言える。 | 内容は具体的だが、適正であるとは言えない。 | 内容が具体性に欠けている。 |
評価項目 | 記述内容(要求要件) | 評価の着眼点 | 配点 | 評価基準 | ||||||
A | B | C | D | E | ||||||
3.1.2 サポートセンター | サポートセンターの体制を記載してください。サポートセンターの運用には利用者の利便性や満足度を高めるために、どのような工夫がされているか記載してください。 | サポートセンターの体制が本市の想定利用規模 (月間300件)に対して十分であること。 利用者が利用しやすい提供方法等の提案がされており、業務内容等が適正かつ具体的であること。新技術(AI等)の活用による効果的な問合せ対応や、呼損率などの状況から定期的に人員体制の見直しや研修を行うなど、利用者の満足度を高める取り組みがされていること。 | 50 | 業務内容等が適正かつ具体的 で、利用者の利便性や満足度向上が期待でき る。 | - | 業務内容等が適正かつ具体的な内容となっている。 | - | 具体的な内容となっていない。または、適正であるとは言えない。 | ||
3.1.3 ファシリティ | システムを提供するデータセンター等のファシリティについて記載してください。 また、JDCC(日本データセンター協会)のデータセンターファシリティスタンダードにおけるティア1から4までのいずれに該当するかを提示してください。 | 災害時を含め、安定的にサービスを提供できるファシリティとなっているか。 | 50 | 非常に高度な ファシリティ で、安定した サービス提供が期待できる。 (ティア4相当) | - | ファシリティが具体的で、安定したサービス提供が期待でき る。(ティア2又は3相当) | - | ファシリティが示されており、サービス提供可能である。 (ティア1相当) | ||
3.2 セキュリティ管理 | ||||||||||
3.2.1 個人情報保護対策 | 個人情報保護マネジメント、情報セキュリティマネジメントの内容、特に個人情報保護対策(個人情報取扱方法、監査方法など)について記載してください。 | 個人情報保護マネジメント、情報セキュリティマネジメントの内容、特に個人情報保護対策(個人情報取扱方法、監査方法など)が具体的であること。 | 50 | 具体的かつ適正で充実した内容だと言える。 | - | 具体的かつ適正な内容だと言える。 | - | 具体的な内容となっていない。または、適正であるとは言えない。 | ||
3.2.2 セキュリティ対策 | 物理的、技術的、人的にどのようなセキュリティ対策を施すかを具体的に記載してください。ま た、セキュリティに対する社員教育、守秘義務の社内基準やセキュリティ監査の仕組みがあれば記載してください。 データの保管について、どのようなセキュリティ対策を講じているか記載してください。 また、サービスを本市サブドメイン(〇 x.xxxx.xxxxxxxx.xx.xx)で提供できるか記載してください。 | 物理的、技術的、人的なセキュリティ対策が実施されており、セキュリティ対策が明確かつ適正であること。 申請データなどの個人情報を含むデータについて、十分なセキュリティ対策が取られていること。 | 50 | セキュリティ対策が実施されており、内容も明確かつ適正である。 かつ、個人情報を含むデータについて、イン ターネット上から直接接続できない領域に保存される。 かつ、本市サブドメインでの サービス提供が可能である。 | セキュリティ対策が実施されており、内容も明確かつ適正である。 かつ、個人情報を含むデータについて、イン ターネット上から直接接続できない領域に保存される。 | セキュリティ対策が実施されており、内容も明確かつ適正である。 かつ、本市サブドメインでの サービス提供が可能である。 | セキュリティ対策が実施されており、内容も明確かつ適正である。 | セキュリティ対策が十分実施されていない。 |
評価項目 | 記述内容(要求要件) | 評価の着眼点 | 配点 | 評価基準 | |||||||
A | B | C | D | E | |||||||
3.3 移行・運用 | |||||||||||
3.3.1 移行作業 | 円滑にサービスを開始し、運用できるよう、移行作業をどのように行うのか、移行作業内容と職員対応が必要な内容、移行作業を行う職員への支援内容を具体的に提案してください。また、現行システムとの並行稼働も考慮し、職員の負担の少ない移行方法を提案してください。 | 移行作業が具体的で、職員負担が少ないものとなっていること。 移行期間における現行システムとの並行稼働を考慮し、職員にとって手間がかかる方法ではないこと。 | 100 | 具体的な対応策があり、職員の移行業務の負担低減ががかなり期待できる。 | - | 具体的な対応策があり、職員の移行業務の負担低減が期待できる。 | - | 職員の業務負担の低減が期待できない。 | |||
3.3.2 職員支援 | 円滑にサービスを開始し運用できるよう、運用業務において、職員(管理部署職員及び手続所管課職員)へどのような支援を行えるのか、支援計 画、項目を、それぞれの業務について具体的に提案してください。 また、機構改革及び人事異動で大多数の登録情報の変更作業及び手続等資産の移動作業を行う際 の、職員の負担が少ない具体的な方策を記載してください。 | ・本市管理部署職員への支援計画、項目について具体的であり、職員負担が少ないこと。 ・委託者が提供する機構・異動情報を元にシステムに登録できるよう受託者が加工し登録する、資産移動は管理部署職員を経由せず申請フォームから受付して処理を行うなど、職員の負担が少ないこと。 | 100 | 具体的な対応策があり、支援による職員負担の低減ががかなり期待できる。 | - | 具体的な対応策があり、支援による職員負担の低減が期待できる。 | - | 支援による職員負担の低減が期待できない。 | |||
3.3.3 職員研修 | 移行業務及び運用業務において実施する、本市職員を対象とした研修のスケジュール、研修方法、内容を具体的に記載してください。 | 運用開始後の早い時期に職員へ事前研修を実施すること。職員の業務範囲に応じた研修を実施するための具体的かつ計画的提案がされていること。 | 50 | 具体的な研修スケジュール及び内容が提案されている。また、業務範囲に応じた非常に効果的な内容だと言える。 | 具体的な研修スケジュール及び内容が提案されている。また、業務範囲に応じた効果的な内容だと言える。 | 具体的な研修スケジュール及び内容が提案されている。また、業務範囲に応じた内容だと言える。 | 具体的な研修スケジュール及び内容が提案されているが、業務範囲に応じた内容だとは言えない。 | 研修スケジュール及び内容に具体性がない。 | |||
3.4 拡張性と将来性 | |||||||||||
3.4.1 拡張性とコスト | |||||||||||
3.4.1.1 動作環境拡大への対応 | 新しいOSやブラウザ等のリリースについて、どのように対応するかを記載してください。また、その場合の対応経費の考え方についても記載してください。 | 新しいOSやブラウザ等がリリースによって、利用者の動作環境が拡大された際の対応が保守内で実施できるような、本市の対応負担軽減及びランニングコスト抑制に繋がる対応が可能であるか。 | 50 | 動作環境拡大の対応は保守内で実施し、迅速な対応が期待できる。 | 動作環境拡大の対応は保守内で実施される。 | 主な動作環境拡大の対応は保守内で実施する が、一部保守外となる部分がある。 | 全ての動作環境拡大対応に費用負担が必須となる | 動作環境の拡大は実施しない。 | |||
3.4.1.2 リソースの柔軟な配分 と保守費の抑制 | 手続数の増加等を考慮したリソース配分の考え方について記載してください。 本市に導入した場合に保守経費の抑制が期待できる点があれば提案してください。 | 手続数の増加等を考慮した柔軟なシステムリソースの配分が可能であること。 本市に導入した場合に保守経費の抑制が期待できるか。 | 50 | 手続の増加等に柔軟にリソース配分が可能であり、保守経費の抑制がかなり期待できる。 | 手続の増加等に柔軟にリソース配分が可能であり、保守経費の抑制が期待できる。 | 手続の増加等に柔軟にリソース配分が可能であり、保守経費の抑制が多少期待できる。 | 手続の増加等に柔軟にリソース配分が可能であるが、保守経費の抑制が期待できない。 | 柔軟なリソース配分が不可能である。 | |||
3.4.1.3 改修・機能追加のしや すさ | 利用者(市民、職員)からの要望を改修や機能追加によって実現させられる仕組みがあるかどう か、またその仕組みについて記載してください。 | 委託者や利用者(市民、職員)からの要望を改修や機能追加することで実現できる仕組みになっているか。 | 50 | 委託者の要望を実現できる仕組みがあり、さらに、利用者の要望をもとに実現方法を委託者に提案する仕組みがある。 | - | 委託者の要望を実現できる仕組みはある。 | - | 要望を実現できる仕組みはな い。 | |||
3.4.1.4 提案に対する経費の妥 当性 | 5年間(令和3年度~7年度)の総経費について記載してください。 | 5年間(令和3年度~7年度)の総経費が提案に対して適正か | 200 | 経費に対し非常に高度な技術提案を行ってい る。 | 経費に対して高度な技術提案を行っている。 | 経費に対して相応な技術提案となっている。 | 技術提案内容に対して経費が高い。 | 技術提案内容に対して経費が高すぎる。 |
評価項目 | 記述内容(要求要件) | 評価の着眼点 | 配点 | 評価基準 | ||||||
A | B | C | D | E | ||||||
4 | プロジェクトマネジメント | |||||||||
4.1 プロジェクト運用 | ||||||||||
4.1.1 実施体制 | 運用体制図と各部門に携わる人数(概数で構いません)について、現在の想定値を記載してください。 | ・実施体制が明確にされていること。 ・業務遂行に必要な責任体制(意思決定者の明確化、位置付け)となっていること。 ・移行に係る本市管理者職員及び手続所管課職員との連携が考慮されていること。 ・移行だけでなく、運用保守時の体制が考慮されていること。 | 50 | 体制が明確で、十分整っていると言える。 | - | 体制が明確で、整っていると言える。 | - | 体制が明確に示されていない。または十分とは言えない。 | ||
4.1.2 実施計画 | 準備、データ移行、運用開始まで、円滑に現行システムから次期システムに移行ができる実施計画を記載してください。 | ・実施計画が明確にされていること。 ・現行システムとの並行稼働を考慮し、市民及び職員にとって分かりやすい、スムーズに移行できる計画となっていること。 | 50 | 計画が明確で、十分整っていると言える。 | - | 計画が明確で、整っていると言える。 | - | 計画が明確に示されていない。または、十分とは言えない。 | ||
4.2 スケジュール | ||||||||||
4.2.1 想定スケジュール | 移行業務から運用業務までの全体計画スケジュールを記載してください。準備作業、データ移行作業、運用等も含めて、何を、いつ、どのくらいの期間行うのか具体的な提案をしてください。 | サービス利用開始時期に合わせた、サービス開始前までの準備作業、運用等も含めた想定スケ ジュール及び運用期間中の全体計画について具体的な提案がされていること。なお、データ移行作業に必要な期間が考慮されたものであること。 | 50 | 想定スケジュール及び全体計画が具体的で、作業期間が十分に考慮されていると言える。 | - | 想定スケジュール及び全体計画が具体的で、作業期間が考慮されていると言える。 | - | 想定スケジュールに具体性がない。または、作業期間が考慮されたものとは言えない。 | ||
5 | 品質保証 | |||||||||
5.1 サービス品質保証 | ||||||||||
5.1.1 SLA | 提供されるサービスのSLA(サービスレベルアグリーメント)について記載してください。 SLAには少なくとも以下の項目を記載してください。 ・稼働率 ・オンライン応答時間 ・サポートセンターの問題解決率 ・障害発生時の平均復旧時間 | サービスレベルが十分であり、安定したサービス提供が期待できるか。 本市が要求するSLA ・稼働率:99.5%以上 ・オンライン応答時間:3秒以内 ・サポートセンター問題解決率:90%以上 ・障害発生時の平均復旧時間:6時間以内 | 50 | 稼働率、オンライン応答時間、サポートセン ター問題解決率の全てが本市の要求を大きく上回っている。 | - | 稼働率、オンライン応答時間、サポートセン ター問題解決率の全てが本市の要求を上回っている。 | - | 稼働率、オンライン応答時間、サポートセン ター問題解決率の中で、本市の要求を下回っているものがあ る。 |
評価項目 | 記述内容(要求要件) | 評価✰着眼点 | 配点 | 評価基準 | |||||
A | B | C | D | E | |||||
6 企業として✰取り組み | |||||||||
6.1 ワーク・ライフ・バランスに関する取組 | ワーク・ライフ・バランスに関する取組について、取得している認定を記載してください。(要領ー1) | 次✰いずれかを取得しているか。 ①次世代育成支援対策推進法に基づく認定(xxxんマーク、プラチナxxxんマーク) ②女性✰職業生活における活躍✰推進に関する法律に基づく認定(えるぼし) ③若者雇用促進法に基づく認定(ユースエール) ④よこはまグッドバランス賞 | 30 | 2件以上取得している。 | - | 1件取得している。 | - | 取得していない。 | |
6.2 障害者雇用に関する取組 | 障害者雇用に関する取組として、従業員数、障害者雇用数、障害者雇用率を記載してください。 (要領ー2) | 障害者雇用促進法に基づく法定雇用率2.3%✰達成をしているか。 | 30 | 達成している (従業員43.5人以上)、又は障害者を1人以上雇用している(従業員43.5人未 満) | - | - | - | 達成していない(従業員 43.5人以 上)、又は障害者を1人以上雇用していない(従業員 43.5人未満) | |
6.3 健康経営に関する取組 | 健康経営に関する取組について、取得している認定を記載してください。(要領ー3) | 健康経営銘柄、健康経営優良法人(大規模法人・中小規模法人)✰取得、又は、横浜健康経営認証 ✰AAAクラス若しくはAAクラス✰認証を取得しているか。 | 30 | 健康経営銘 柄、健康経営優良法人(大規模法人・中小規模法人) ✰取得、又 は、横浜健康経営認証クラ スAAA)✰取得 | - | 横浜健康経営認証クラスAA ✰取得 | - | 取得していない。 | |
合計 | 2730 |
項番 | 大項目 | 必須/任意 | 小項目(概要) | 対応 | 備考 |
1 | 基本 | 必須 | 原則として24時間365日サービスが利用可能であること。 | ||
2 | 基本 | 必須 | 1時間に10,000件以上の申請等を受け付けられること。 | ||
3 | 基本 | 必須 | 職員側利用者の機能について、PC利用におけるウェブブラウザは少なくともChrome、Edgeを動作保証すること。 | ||
4 | 基本 | 任意 | 職員側利用者の機能について、PC利用におけるウェブブラウザはinternet explorerを動作保証すること。 | ||
5 | 基本 | 必須 | 市民側利用者のウェブブラウザは少なくともChrome、Edge、Safari、Firefoxを動作保証すること。 | ||
6 | 基本 | 必須 | 市民側利用者がオンラインで申請・届出等の手続を行うことができ、職員側利用者は申 請・届出等について、受付や審査などを行うことができる申請・届出システムを実現するこ と。 | ||
7 | 基本 | 必須 | 市民側利用者は、パソコン、スマートフォン等、多くの利用者が利用する端末を利用して、申請・届出等の市民側利用者機能が利用できること。 | ||
8 | 基本 | 必須 | 申請途中での一時保存や過去の入力データの再利用、入力内容のチェックが可能 など、ユーザビリティに優れ、申請する手続の入力項目が最小限にできること | ||
9 | 基本 | 任意 | 一度の入力で複数の手続き申請が同時に作成できること | ||
10 | 基本 | 必須 | 市民側利用者が必要とする手続について、市民側利用者がわかりやすく簡便に検索・選択できる仕組みを備えていること | ||
11 | 基本 | 必須 | 職員側利用者は、業務用パソコンを利用して、利用者管理及び手続管理等の職員側利用者機能が利用できること。 | ||
12 | 基本 | 必須 | 利用者の誤入力を防止するための対策を施すこと。(範囲内の日付や数字しか入力不可とする、郵便番号を入力したら住所が自動入力されるなど) | ||
13 | 基本 | 必須 | 電子申請を行わない手続(手続の説明と様式ダウンロードのみ)が作成できること。 | ||
14 | 基本 | 必須 | 公的個人認証(JPKI)による電子署名・認証が使用できること。 | ||
15 | 基本 | 必須 | 電子収納の手段として、クレジットカード決済に対応できること | ||
16 | 基本 | 任意 | 代理申請(代理人に対し申請者が委任をして、代理人が申請者の代わりに申請すること)が可能であること。 | ||
17 | 基本 | 任意 | 電子マネー決済(Xxxxx、Xxx,Waon,Xxxxxx等)、キャリア決済(ドコモ、au、ソフトバンク)、ID決済(Pay Pay、R Pay、LINE Pay等)などクレジットカード以外の電子決済手段に対応できること。またはこれら決済サービスの接続モジュールを標準サービスとして用意でき、本シ ステムのための個別開発を伴わないこと | ||
18 | 基本 | 必須 | 市民側利用者が利用者登録を行ってサービスを利用できること。 | ||
19 | 基本 | 必須 | 市民側利用者の本人認証にIDパスワードによる認証が可能であること。 | ||
20 | 基本 | 必須 | 市民側利用者の登録・登録情報変更時に、登録メールアドレスへの発信通知ができること。 | ||
21 | 基本 | 任意 | 市民側利用者の登録・登録情報変更時の本人の携帯電話番号の確認に、SMSによる認証が実装可能であること。 | ||
22 | 基本 | 任意 | 市民側利用者(企業)の本人認証に、GビズIDの利用ができること。 | ||
23 | 基本 | 必須 | 職員側利用者の本人認証にIDパスワードの利用ができること。なお、職員側利用者のアカウントは共有せず、発行は個人に対して行うこととする。 | ||
24 | 基本 | 必須 | 手続の作成・変更時において、本番公開前にテストを行える環境があること。 | ||
25 | 基本 | 必須 | 登録データ(ユーザ情報や機構・部署情報)及び申請データがCSV形式で出力できること。申請データに紐づけて申請に添付されたファイルも抽出できること。 | ||
26 | 基本 | 必須 | システムの利用状況が分かる統計資料(指定期間の手続別の申請件数、様式のダウンロード数など)を出力できること。 | ||
27 | 基本 | 必須 | レスポンシブデザイン(端末情報を認識して最適化されたデザインを表示する)となっていること。 | ||
28 | 基本 | 必須 | ポータル画面を備え、障害情報やお知らせの表示、利用者登録、手続の検索などが行えること。 | ||
29 | 基本 | 必須 | システム内から、利用者に対して利用者登録時や手続の申請・受付・審査・結果通知時などに設定に基づいた通知メールを送信できる機能があること。 | ||
30 | 市民側機能 | 必須 | 市民側利用者向けの機能として、申請書様式取得機能(様式のファイルをダウンロードする機能)、申請機能(様式の各項目に入力して申請を行う機能)、書類添付機能(申請時に電子ファイルで書類を添付する機能)、署名付与機能、電子決済機能、到達確認機能(申請データがシステムに到達したことを確認できる機能)、申請状態確認機能(自分の行った申請の状態を確認する機能)、交付文書取得機能(申請を元に業務担当者が交付する交付文書のデータを取得する機能)等を実現すること。 | ||
31 | 市民側機能 | 必須 | 市民側利用者がインターネットから送付する電子ファイルについては、職員側利用者がLG WANで受け取る前に無害化する機能を提供すること。無害化対象ファイルは、少なくとも PDFファイル、Officeファイル(Word、Excel、PowerPoint)、画像ファイルに対応すること。 | ||
32 | 職員側機能 | 必須 | 職員側利用者機能として、申請様式作成機能(項目や入力タイプ(数字、全角文字など)等を選択して申請様式を作成する機能)、申請データ到達機能(市民側利用者が申請した データを格納し、到達データとして管理・通知する機能)、納付情報登録機能(電子収納が必要な手続において、納付先や金額などの納付に必要となる情報を登録する機能)、問合せ応答機能(申請内容の不備などについて、申請者に対して問い合わせを行う機能)、審 査支援機能(職員が申請データの審査を行うにあたり、申請データを表示・確認できる機 能)、結果通知機能(申請データの審査結果について通知する機能)、交付文書発送機能等を実現すること。 | ||
33 | 職員側機能 | 必須 | 作成した手続について市民側利用者が申請を行った際に、申請データに対して以下のフローの処理が行えること。 「到達」:申請データがシステムに格納され、受付処理ができる状態。 「受付」:申請データの内容を確認できる。受付処理を行うことで、審査処理ができる状態となる。 「審査」:申請データの内容を確認できる。審査処理を行うことで、結果通知発行ができる状態となる。 「結果通知発行」:交付文書を発行し、申請者に通知すること。交付文書には職責証明の電子署名を付与することが可能であること。 また、必要なフローのみに限定した手続を作成できること(「到達」「受付」のみで完了する手続など) 各フローにおいて、業務担当者及び申請者に対してEメールなどによる通知が可能であること。 |
別紙1 機能要件対応表(必須及び任意項目)
項番 | 大項目 | 必須/任意 | 小項目(概要) | 対応 | 備考 |
34 | 職員側機能 | 任意 | 他の業務システムおよびワークフローシステムとのデータ連携機能、API連携機能を持つこと。 | ||
35 | 職員側機能 | 任意 | GUIによる使いやすい設計画面でワークフローを設定できる業務処理機能および外部の業務システムとの連携機能を持つこと。 | ||
36 | 職員側機能 | 必須 | 職員側利用者機能として、受付等の一括処理ができること。交付文書発送機能は文書ファイルを一括で登録できること。(申請者それぞれに対して、個別に異なる交付文書を登録で きること) | ||
37 | 職員側機能 | 必須 | 手続作成及び登録を職員側利用者がGUI等による使いやすい設計画面で自由にできること。また、登録できる手続数には基本的に制限がないこと。 | ||
38 | 職員側機能 | 必須 | システムを利用する職員各々のIDに対して、管理者もしくは業務担当者としてのシステム利用の権限設定ができること。 | ||
39 | 職員側機能 | 必須 | 職員はグループ(部署)ごとに管理し、所属するグループの手続が利用できること。 | ||
40 | アクセスxx | 任意 | 本人開示請求等に対応するため、市民側利用者のアクセスログの開示ができること。 | ||
41 | アクセスxx | 必須 | 本人開示請求等に対応するため、職員側利用者のアクセスログの開示ができること。 | ||
42 | アクセスxx | 必須 | 管理者・業務担当者の操作ログは3年間保存すること。保存できない場合は外部記憶媒体等で電子データとして提供すること。 | ||
43 | 手続 | 必須 | 直接手続にアクセスできるURL(手続URL)が作成できること。 | ||
44 | 手続 | 必須 | ポータルからの検索等ができない手続を作成できること。(市民に公開しない職員の内部利用を想定) | ||
45 | 手続 | 必須 | 手続URLの二次元バーコード作成ができること。 | ||
46 | 手続 | 必須 | 本人認証が必要な手続と必要ない手続のどちらも作成できること。 | ||
47 | 手続 | 必須 | 設定の自由度が高く、様式のデザイン(様式が決まった申請書の作成を想定した配置デザイン)や項目間チェック(複数項目の入力内容の相関で不整合が無いことのチェック)等が可能な様式を作成する方式と、設定の自由度は低いものの、項目の選択程度の簡単な操作で様式が作成できる方式を利用できること。(両方の性質を備えている方式でも良い) | ||
48 | 手続 | 必須 | 交付文書をシステム内で簡単にデザインし作成できること。また、システム外で作成した交付文書のファイルを登録できること。 | ||
49 | 手続 | 任意 | 手続URL は60文字以内に収まる URL 設計であること (xxxxxxxxxxxxxxxx.xxxx.xxxxxxxx.xx.xx(x部分は9文字を想定)としたときに、 xxxxx://xxxxxxxxx.xxxx.xxxxxxxx.xx.xx/で始まるURL全体が60文字以内に収まること) ※手続URLをメール本文に記載して対象者に送付する際に改行が入らないようにするため | ||
50 | 手続 | 必須 | 申請内容に応じて申請データを適切な提出部署に振り分けることができること。 | ||
51 | 手続 | 必須 | 到達制限機能(セミナーの申込等、選択肢ごとの申込みが締切に達した際にその選択肢を選択できなくなる機能)のある手続きを作成できること。 | ||
52 | 手続 | 必須 | 受付期間開始日時、受付期間終了日時を設定することにより、自動的に手続の受付を開始、終了できること。 | ||
53 | 手続 | 任意 | 申請様式上に画像を掲載できること。 | ||
54 | 手続 | 必須 | 申請に添付するファイルの数量と1ファイルあたり又は申請あたりの容量の上限を設定できること。 | ||
55 | 手続 | 必須 | 本人認証情報(IDパスワードであれば登録した利用者情報、マイナンバーカードであれば証明書情報など)が申請書様式への転記に利用できること。 | ||
56 | 手続 | 必須 | 過去の申請書情報を引用選択することで過去の申請書入力状態を再現できること。 | ||
57 | 手続 | 必須 | 業務担当者あての通知メールの送信先メールアドレスを設定できること。 | ||
58 | 手続 | 必須 | 申請書に入力途中の内容を一時保存できること。 | ||
59 | 手続 | 必須 | サービス利用にあたって、少なくとも1回は利用規約に同意する又は同意したとするプロセスを通過するようにできること。 | ||
60 | 手続 | 任意 | 申請書様式の項目間で2段階以上の条件設定(例:項目1でAを選択した場合のみ項目2が選択可能となり、さらに項目2でBを選択した場合のみ項目3が選択可能となる)が可能であること。 | ||
61 | 手続 | 必須 | 同一の申請者からの申請を不可とする設定が可能であること。 | ||
62 | 手続 | 必須 | 申請の取下げ、補正指示・訂正が行えること。 | ||
63 | 手続 | 任意 | 既存の手続をコピーして新しい手続を作成できること。 | ||
64 | 手続 | 必須 | クラウドサービスのシステムは国内のデータセンターにあること。 | ||
65 | 手続 | 必須 | 災害等でデータセンターが使用できなくなる事態に備えたディザスタリカバリの体制が取られていること。 | ||
66 | 手続 | 任意 | クラウドサービスのシステムは同一データセンター内で冗長化されており、片方のシステム停止時はもう一方のシステムからサービス提供されること。 | ||
67 | 手続 | 任意 | クラウドサービスのシステムは異なる2か所以上の立地場所もしくは電源設備が異なる データセンターで冗長化されており、片方のデータセンター停止時はもう一方のデータセンターからサービス提供されること。 |
「対応」欄については以下の基準で記入してください。
〇 : 稼働開始(令和3年12月予定)までに対応可能
△ : 対応可能だが、稼働開始(令和3年12月予定)までには対応不可。(備考欄に対応予定時期を記載してください)
× : 対応不可(必須項目の場合、対応不可が1項目でもある場合不合格)
「備考」欄については以下に該当する場合に記入してください。
・「対応」欄で「△」とした場合に、対応予定時期を記入してください。
・その他、補足事項がある場合に記入してください。
項番 | 大項目 | 必須/任意 | 小項目(概要) | 対応欄の記載 | ||
〇 | △ | × | ||||
1 | 基本 | 必須 | 原則として24時間365日サービスが利用可能であること。 | - | - | - |
2 | 基本 | 必須 | 1時間に10,000件以上の申請等を受け付けられること。 | - | - | - |
3 | 基本 | 必須 | 職員側利用者の機能について、PC利用におけるウェブブラウザは少なくともChrome、Edgeを動作保証すること。 | - | - | - |
4 | 基本 | 任意 | 職員側利用者の機能について、PC利用におけるウェブブラウザはinternet explorerを動作保証すること。 | 30 | 15 | 0 |
5 | 基本 | 必須 | 市民側利用者のウェブブラウザは少なくともChrome、Edge、Safari、Firefoxを動作保証すること。 | - | - | - |
6 | 基本 | 必須 | 市民側利用者がオンラインで申請・届出等の手続を行うことができ、職員側利用者は申 請・届出等について、受付や審査などを行うことができる申請・届出システムを実現すること。 | - | - | - |
7 | 基本 | 必須 | 市民側利用者は、パソコン、スマートフォン等、多くの利用者が利用する端末を利用して、申請・届出等の市民側利用者機能が利用できること。 | - | - | - |
8 | 基本 | 必須 | 申請途中での一時保存や過去の入力データの再利用、入力内容のチェックが可能 など、ユーザビリティに優れ、申請する手続の入力項目が最小限にできること | - | - | - |
9 | 基本 | 任意 | 一度の入力で複数の手続き申請が同時に作成できること | 20 | 10 | 0 |
10 | 基本 | 必須 | 市民側利用者が必要とする手続について、市民側利用者がわかりやすく簡便に検索・選択できる仕組みを備えていること | - | - | - |
11 | 基本 | 必須 | 職員側利用者は、業務用パソコンを利用して、利用者管理及び手続管理等の職員側利用者機能が利用できること。 | - | - | - |
12 | 基本 | 必須 | 利用者の誤入力を防止するための対策を施すこと。(範囲内の日付や数字しか入力不可とする、郵便番号を入力したら住所が自動入力されるなど) | - | - | - |
13 | 基本 | 必須 | 電子申請を行わない手続(手続の説明と様式ダウンロードのみ)が作成できること。 | - | - | - |
14 | 基本 | 必須 | 公的個人認証(JPKI)による電子署名・認証が使用できること。 | - | - | - |
15 | 基本 | 必須 | 電子収納の手段として、クレジットカード決済に対応できること | - | - | - |
16 | 基本 | 任意 | 代理申請(代理人に対し申請者が委任をして、代理人が申請者の代わりに申請すること)が可能であること。 | 30 | 15 | 0 |
17 | 基本 | 任意 | 電子マネー決済(Xxxxx、Xxx,Xxxx,Nanaco等)、キャリア決済(ドコモ、au、ソフトバンク)、ID決済(Pay Pay、R Pay、LINE Pay等)などクレジットカード以外の電子決済手段に対応できること。またはこれら決済サービスの接続モジュールを標準サービスとして用意でき、本システムのための個別開発を伴わないこと | 20 | 10 | 0 |
18 | 基本 | 必須 | 市民側利用者が利用者登録を行ってサービスを利用できること。 | - | - | - |
19 | 基本 | 必須 | 市民側利用者の本人認証にIDパスワードによる認証が可能であること。 | - | - | - |
20 | 基本 | 必須 | 市民側利用者の登録・登録情報変更時に、登録メールアドレスへの発信通知ができること。 | - | - | - |
21 | 基本 | 任意 | 市民側利用者の登録・登録情報変更時の本人の携帯電話番号の確認に、SMSによる認証が実装可能であること。 | 20 | 10 | 0 |
22 | 基本 | 任意 | 市民側利用者(企業)の本人認証に、GビズIDの利用ができること。 | 30 | 15 | 0 |
23 | 基本 | 必須 | 職員側利用者の本人認証にIDパスワードの利用ができること。なお、職員側利用者のアカウントは共有せず、発行は個人に対して行うこととする。 | - | - | - |
24 | 基本 | 必須 | 手続の作成・変更時において、本番公開前にテストを行える環境があること。 | - | - | - |
25 | 基本 | 必須 | 登録データ(ユーザ情報や機構・部署情報)及び申請データがCSV形式で出力できること。申請データに紐づけて申請に添付されたファイルも抽出できること。 | - | - | - |
26 | 基本 | 必須 | システムの利用状況が分かる統計資料(指定期間の手続別の申請件数、様式のダウンロード数など)を出力できること。 | - | - | - |
27 | 基本 | 必須 | レスポンシブデザイン(端末情報を認識して最適化されたデザインを表示する)となっていること。 | - | - | - |
28 | 基本 | 必須 | ポータル画面を備え、障害情報やお知らせの表示、利用者登録、手続の検索などが行えること。 | - | - | - |
29 | 基本 | 必須 | システム内から、利用者に対して利用者登録時や手続の申請・受付・審査・結果通知時などに設定に基づいた通知メールを送信できる機能があること。 | - | - | - |
30 | 市民側機能 | 必須 | 市民側利用者向けの機能として、申請書様式取得機能(様式のファイルをダウンロードする機能)、申請機能(様式の各項目に入力して申請を行う機能)、書類添付機能(申請時に電子ファイルで書類を添付する機能)、署名付与機能、電子決済機能、到達確認機能(申請データがシステムに到達したことを確認できる機能)、申請状態確認機能(自分の行った申請の状態を確認する機能)、交付文書取得機能(申請を元に業務担当者が交付する交付文書のデータを取得する機能)等を実現すること。 | - | - | - |
31 | 市民側機能 | 必須 | 市民側利用者がインターネットから送付する電子ファイルについては、職員側利用者がLG WANで受け取る前に無害化する機能を提供すること。無害化対象ファイルは、少なくとも PDFファイル、Officeファイル(Word、Excel、PowerPoint)、画像ファイルに対応すること。 | - | - | - |
項番 | 大項目 | 必須/任意 | 小項目(概要) | 対応欄の記載 | ||
〇 | △ | × | ||||
32 | 職員側機能 | 必須 | 職員側利用者機能として、申請様式作成機能(項目や入力タイプ(数字、全角文字など)等を選択して申請様式を作成する機能)、申請データ到達機能(市民側利用者が申請した データを格納し、到達データとして管理・通知する機能)、納付情報登録機能(電子収納が必要な手続において、納付先や金額などの納付に必要となる情報を登録する機能)、問合せ応答機能(申請内容の不備などについて、申請者に対して問い合わせを行う機能)、審査支援機能(職員が申請データの審査を行うにあたり、申請データを表示・確認できる機 能)、結果通知機能(申請データの審査結果について通知する機能)、交付文書発送機能等を実現すること。 | - | - | - |
33 | 職員側機能 | 必須 | 作成した手続について市民側利用者が申請を行った際に、申請データに対して以下のフローの処理が行えること。 「到達」:申請データがシステムに格納され、受付処理ができる状態。 「受付」:申請データの内容を確認できる。受付処理を行うことで、審査処理ができる状態となる。 「審査」:申請データの内容を確認できる。審査処理を行うことで、結果通知発行ができる状態となる。 「結果通知発行」:交付文書を発行し、申請者に通知すること。交付文書には職責証明の電子署名を付与することが可能であること。 また、必要なフローのみに限定した手続を作成できること(「到達」「受付」のみで完了する手続など) 各フローにおいて、業務担当者及び申請者に対してEメールなどによる通知が可能であること。 | - | - | - |
34 | 職員側機能 | 任意 | 他の業務システムおよびワークフローシステムとのデータ連携機能、API連携機能を持つこと。 | 20 | 10 | 0 |
35 | 職員側機能 | 任意 | GUIによる使いやすい設計画面でワークフローを設定できる業務処理機能および外部の業務システムとの連携機能を持つこと。 | 20 | 10 | 0 |
36 | 職員側機能 | 必須 | 職員側利用者機能として、受付等の一括処理ができること。交付文書発送機能は文書ファイルを一括で登録できること。(申請者それぞれに対して、個別に異なる交付文書を登録できること) | - | - | - |
37 | 職員側機能 | 必須 | 手続作成及び登録を職員側利用者がGUI等による使いやすい設計画面で自由にできること。また、登録できる手続数には基本的に制限がないこと。 | - | - | - |
38 | 職員側機能 | 必須 | システムを利用する職員各々のIDに対して、管理者もしくは業務担当者としてのシステム利用の権限設定ができること。 | - | - | - |
39 | 職員側機能 | 必須 | 職員はグループ(部署)ごとに管理し、所属するグループの手続が利用できること。 | - | - | - |
40 | アクセスxx | 任意 | 本人開示請求等に対応するため、市民側利用者のアクセスログの開示ができること。 | 30 | 15 | 0 |
41 | アクセスログ | 必須 | 本人開示請求等に対応するため、職員側利用者のアクセスログの開示ができること。 | - | - | - |
42 | アクセスxx | 必須 | 管理者・業務担当者の操作ログは3年間保存すること。保存できない場合は外部記憶媒体等で電子データとして提供すること。 | - | - | - |
43 | 手続 | 必須 | 直接手続にアクセスできるURL(手続URL)が作成できること。 | - | - | - |
44 | 手続 | 必須 | ポータルからの検索等ができない手続を作成できること。(市民に公開しない職員の内部利用を想定) | - | - | - |
45 | 手続 | 必須 | 手続URLの二次元バーコード作成ができること。 | - | - | - |
46 | 手続 | 必須 | 本人認証が必要な手続と必要ない手続のどちらも作成できること。 | - | - | - |
47 | 手続 | 必須 | 設定の自由度が高く、様式のデザイン(様式が決まった申請書の作成を想定した配置デザイン)や項目間チェック(複数項目の入力内容の相関で不整合が無いことのチェック)等が可能な様式を作成する方式と、設定の自由度は低いものの、項目の選択程度の簡単な操作で様式が作成できる方式を利用できること。(両方の性質を備えている方式でも良い) | - | - | - |
48 | 手続 | 必須 | 交付文書をシステム内で簡単にデザインし作成できること。また、システム外で作成した交付文書のファイルを登録できること。 | - | - | - |
49 | 手続 | 任意 | 手続URL は60文字以内に収まる URL 設計であること (xxxxxxxxxxxxxxxx.xxxx.xxxxxxxx.xx.xx(x部分は9文字を想定)としたときに、 xxxxx://xxxxxxxxx.xxxx.xxxxxxxx.xx.xx/で始まるURL全体が60文字以内に収まること) ※手続URLをメール本文に記載して対象者に送付する際に改行が入らないようにするため | 20 | 10 | 0 |
50 | 手続 | 必須 | 申請内容に応じて申請データを適切な提出部署に振り分けることができること。 | - | - | - |
51 | 手続 | 必須 | 到達制限機能(セミナーの申込等、選択肢ごとの申込みが締切に達した際にその選択肢を選択できなくなる機能)のある手続きを作成できること。 | - | - | - |
52 | 手続 | 必須 | 受付期間開始日時、受付期間終了日時を設定することにより、自動的に手続の受付を開始、終了できること。 | - | - | - |
53 | 手続 | 任意 | 申請様式上に画像を掲載できること。 | 20 | 10 | 0 |
54 | 手続 | 必須 | 申請に添付するファイルの数量と1ファイルあたり又は申請あたりの容量の上限を設定できること。 | - | - | - |
55 | 手続 | 必須 | 本人認証情報(IDパスワードであれば登録した利用者情報、マイナンバーカードであれば証明書情報など)が申請書様式への転記に利用できること。 | - | - | - |
56 | 手続 | 必須 | 過去の申請書情報を引用選択することで過去の申請書入力状態を再現できること。 | - | - | - |
57 | 手続 | 必須 | 業務担当者あての通知メールの送信先メールアドレスを設定できること。 | - | - | - |
58 | 手続 | 必須 | 申請書に入力途中の内容を一時保存できること。 | - | - | - |
項番 | 大項目 | 必須/任意 | 小項目(概要) | 対応欄の記載 | ||
〇 | △ | × | ||||
59 | 手続 | 必須 | サービス利用にあたって、少なくとも1回は利用規約に同意する又は同意したとするプロセスを通過するようにできること。 | - | - | - |
60 | 手続 | 任意 | 申請書様式の項目間で2段階以上の条件設定(例:項目1でAを選択した場合のみ項目2が選択可能となり、さらに項目2でBを選択した場合のみ項目3が選択可能となる)が可能であること。 | 20 | 10 | 0 |
61 | 手続 | 必須 | 同一の申請者からの申請を不可とする設定が可能であること。 | - | - | - |
62 | 手続 | 必須 | 申請の取下げ、補正指示・訂正が行えること。 | - | - | - |
63 | 手続 | 任意 | 既存の手続をコピーして新しい手続を作成できること。 | 20 | 10 | 0 |
64 | 手続 | 必須 | クラウドサービスのシステムは国内のデータセンターにあること。 | - | - | - |
65 | 手続 | 必須 | 災害等でデータセンターが使用できなくなる事態に備えたディザスタリカバリの体制が取られていること。 | - | - | - |
66 | 手続 | 任意 | クラウドサービスのシステムは同一データセンター内で冗長化されており、片方のシステム停止時はもう一方のシステムからサービス提供されること。 | 20 | 10 | 0 |
67 | 手続 | 任意 | クラウドサービスのシステムは異なる2か所以上の立地場所もしくは電源設備が異なる データセンターで冗長化されており、片方のデータセンター停止時はもう一方のデータセンターからサービス提供されること。 | 20 | 10 | 0 |
合計 | 340 |