地方公共団体の基幹業務システムの統一・標準化に関する共通機能等技術要件検討会 申請管理ワーキングチーム（第1回）
概要
- 日時：令和4年（2022年）11月4日（金）15時00分から16時50分まで
- 場所：オンライン会議
- 議事次第：
- 開会
- 議題
- 検討概要
- 申請管理に関する課題
- その他
- 閉会
資料
関連政策
議事概要
日時
令和4年（2022年）11月4日（金）15時00分から16時50分まで
場所
オンライン会議
議事概要
1. 検討概要
- 特に議論なし
2. 申請管理に関する課題
1. ぴったりサービスでプリセットが規定されている手続きについての個別APIの要否
1.1.1 ぴったりサービスに対応する個別APIの規定の必要性
オブザーバ： 考え方として、申請管理から基幹業務システムへのエンドポイントにあたるAPIを汎用的なものとする点について異論はない。一方で、標準化の趣旨や連携要件との整合を考える上では、プリセット有無に限らず、項目レベルで対応が整理されるべきであると考えている。言い換えると、基幹業務システムとしてどのようなデータを管理することができるのか整理し、申請管理からどのようなデータを受け取ることとするのかという考え方で整理すべきと考える。申請として必要な項目、審査に必要な項目と、基幹業務システムに取り込む項目には違いがあるという観点も考慮が必要。
事務局： ご認識の通りと考えている。1.1.2.にも記載した通り、プリセット項目についてはプリセットされた申請データ項目と基本データリストの管理項目の紐付けをリスト化し、リファレンスとして示すことを考えている。また、プリセットがない項目、独自施策としての手続きについても別途、紐づけの方法等を検討し、次回以降提示していく予定である。
1.1.2 ぴったりサービスと基幹業務システムの項目対応の整理
オブザーバ： 項目の対応は、リファレンスではなく、強制力のある連携要件として定義すべき。
事務局： 承知した。いただいたご意見を踏まえて検討する。
2. 申請管理に関する仕様の疑義や不足の解消
2.1.1 申請管理の運用フロー・機能要件の規定
構成員： 運用フローは各手続きで共通的なものを1つ作成することを想定しているか、個々の手続きごとの作成を想定しているか。＜3.2.1.申請受付後の紙処理の取扱い（不在者投票）＞には「手続きごと」という記載がある。
事務局： 共通的な運用フローを提供することを想定している。ご指摘の3.2.1.については、＜3.1.1.申請処理状況登録APIの追加＞とあわせて検討を行う想定であり、こちらは移行支援期間にあたる2025年度までの対応は予定していない。
2.1.2 申請管理の例外パターンの運用フロー・機能要件の規定
構成員： 例外パターンとしては、取り下げだけでなく、申請内容の修正やぴったりサービスでの保持期間内にデータを取得できなかった場合の対応も想定される。
事務局： 承知した。いただいたご意見を踏まえて検討する。
構成員： 申請者が意図せず2回申請（2重登録）した場合の対応も想定すべき。
事務局： 承知した。いただいたご意見を踏まえて検討する。
2.1.3 オンライン申請全体の役割分担・流れの整理
オブザーバ： 申請管理機能において審査機能は規定されるか。総務省仕様においては、申請データや添付書類をビュアーで表示するような機能が規定されている。
事務局： 申請管理機能の射程としては、宛名番号の紐づけと形式審査を想定している。
オブザーバ： 介護保険の認定など、基幹業務システムでの審査が想定されるものもあるが、窓口業務で受け取った時点で実施している必要な項目が記載されているか等のチェックは申請管理機能で実装されるものと考えている。一方で、業務的な決裁権限者が申請管理機能において、審査を実施できるようにするかの検討が必要と考える。
事務局： 介護保険の認定等の実質的な審査も想定した場合に、申請管理機能の審査機能でどこまで規定する想定であるかを確認したい趣旨と理解した。基本的な考え方として、総務省仕様と同様の機能を共通機能の標準仕様書としても最低限の機能要件として規定する想定であり、各システムでの役割分担は変わらないものとご認識おきいただきたい。
オブザーバ： 申請管理機能の機能要件等が規定された後の総務省仕様との関係性はどのようになると理解すればよいか。
事務局： 総務省仕様と共通機能の仕様書の2つの仕様書が存在することで、わかりにくくなることを懸念されているものと理解した。文書の取扱いについても読みやすい形となるように引き続き検討する。
2.1.4 申請データ受領時の基幹業務システム側の対応内容の明確化
構成員： 検討結果を横並び調整方針に反映されるとの記載があるが、各基幹業務システムの標準仕様書改定はいつのタイミングを想定しているか。
事務局 スケジュール感は検討中であるが、ご指摘を踏まえ、改めて年度末の改定に間に合うような段取りとなるように関係府省と協議・調整を行うこととしたい。
2.1.5 差分データ取得仕様（「取得対象年月日」「取得対象時間」）の明確化
オブザーバ： データ連携WTでも議論があったとおり、申請の日時、申請管理機能の取り込み日時、データベースへの書き込み時間など、事業者間で認識齟齬が発生する可能性があるため用語定義を明確にすべきと考える。
事務局： 承知した。いただいたご意見を踏まえて検討する。
2.1.7 総務省仕様準拠のIF利用の方針明確化
構成員： 取り扱いとして、実装必須機能とされているが、住民記録システムとの連携においてファイル連携が必須となるわけではないと考えてよいか。
事務局： ご認識の通りである。ファイル連携は過渡的な対応として可能としているものであり、必須の対応として求めるものではない。
2.2.5 申請データ照会APIのリクエストパラメータの利用想定
オブザーバ： 対応方針（案）に記載があるが、API認証においてアクセスコントロールを行い、その後の制御は申請管理機能にて行う想定であるか。
事務局： この点、考慮が不十分であったため改めて検討し方針を提示したい。
3. 申請管理機能と基幹業務システム間の連携最適化
3.1.1 申請処理状況登録APIの追加
構成員： 申請処理状況登録APIについては、2025年度末の共通機能の標準仕様書の改定範囲には入らないという認識でよいか。
事務局： ご認識の通り。
構成員： 横並び調整方針にある「取得した項目等を表示、出力等できること」とあるが、これは申請管理機能から取得した項目を画面表示できれば良いのか。
事務局： 取得した項目の表示、または基幹業務システムでの審査結果等を表示する必要があり、当該機能を用いて、申請管理機能において申請処理状況を登録することを想定している。
構成員： 事務局の説明の中で、申請処理状況登録APIは2025年度末まで標準仕様の策定は行わないとの説明があった。一方で、住民記録システムの引越しOSSに関する要件として、申請管理に審査結果を返却できることという規定をされているものと認識している。その点も他の基幹業務システムの対応と同様のスケジュール感として2025年度の移行期限までの実装範囲には入らないという理解でよいか。
事務局： 該当の要件の内容を確認した上で、横並び調整方針を含めて全体の整合を取った記載となるように検討する。
オブザーバ： 全体的に申請管理と基幹業務側の分担が整理され、フロー化されると不明点が解消されると考える。引越しOSSについては、申請の受付を住民記録システムにて実施する想定になっていることが、わかりにくさの原因と考えるため、その点のフローの整理を行うのが望ましい。
事務局： 承知した。いただいたご意見を踏まえて検討する。
3. その他
- 特に議論なし
以上