システムアーキテクト 2017年 午後1 問01
生命保険会社のシステムの構築に関する次の記述を読んで、設問1~4に答えよ。
A社は、多くの個人保険の契約を保有する大手生命保険会社である。保険金などを顧客に支払った場合に支払調書を税務署に提出している。社会保障・税番号制度(以下、マイナンバー制度という)の導入に伴い、支払調書にマイナンバーの記載が必要になることから、マイナンバーを含むデータを処理するための専用の情報システム(以下、新システムという)を構築することにした。
〔現在の業務と関連システムの概要〕
A社では、顧客から保険金請求の連絡があった場合、保険金部で契約管理システムを利用して手続書類を印刷し、送付する。顧客から記入済みの手続書類の提出を受け、内容を確認して保険金を支払う。一定金額以上の保険金を支払った顧客については、契約管理システムを利用して支払調書を作成し、CDに格納して税務署に提出する。支払調書には、契約者の氏名、契約者の住所、受取人の氏名、受取人の住所、支払金額、支払年月日などが記載されている。
現在のシステム概念図を図1に示す。
〔マイナンバーに関する業務とシステム化の方針〕 マイナンバー制度導入後は、現在の支払調書に契約者及び受取人のマイナンバーを記載するマイナンバー記載欄が追加される。それに伴い、A社では、マイナンバーに関する業務とシステム化の方針を、次のように決定した。 ・顧客のマイナンバーを取り扱う部署として、マイナンバー管理部を新設する。 ・一定金額以上の保険金を支払った顧客については税務署に支払調書を提出する必要があるので、保険金請求の連絡を受けた際に、契約者及び受取人双方にマイナンバーの提供を依頼する。そのために、マイナンバー提供のお願い、マイナンバー申告書、マイナンバー申告書記入例、返信用の封筒などを含んだマイナンバーの提供に関する書類(以下、マイナンバー提供依頼書類という)をA社から顧客に送付する。 ・顧客からのマイナンバーの提供が遅れても、手続書類を確認でき次第、保険金を顧客に支払う。 ・マイナンバーを含むデータは、新システムだけで扱うこととする。また、マイナンバー管理部だけが新システムを利用できることとし、業務はセキュリティレベルの高い執務室で行う
〔マイナンバー制度導入後の業務概要〕
A社では、マイナンバー制度導入後、現在の業務に加えて次のような業務を実施することを検討している。
(1)マイナンバー取得業務
契約管理システムで、顧客番号と顧客氏名を記載したマイナンバー申告書を印刷する。既に新システムにマイナンバーを登録済みの顧客のマイナンバー申告書は印刷しない。顧客番号は、A社の顧客を一意に特定する値であり、1人の顧客が複数の保険契約に関係している場合でも、顧客番号は一つである。
保険金額は、保険金の支払に必要な手続書類に、マイナンバー提供依頼書類を同封して顧客に送付する。顧客は、送付されたマイナンバー申告書にマイナンバーを記入してA社に提出する。マイナンバー管理部は、顧客から提出されたマイナンバ一申告書の内容に不備がないことを確認した後、新システムにマイナンバーを登録する。不備があった場合は、マイナンバー管理部で顧客に連絡し、対応する。
顧客からマイナンバーが変更になった旨の連絡があった場合は、新システムで管理しているマイナンバーを即時削除し、再度マイナンバー提供依頼書類を顧客に送付する。支払調書を税務署に提出した後にマイナンバーの変更があっても、支払調書の再提出は行わない。
(2)マイナンバー申告書進捗管理業務
マイナンバー管理部は、マイナンバー申告書の状態(以下、申告書ステータスという)を新システムで照会し、進捗状況を管理する。
(3)支払調書提出業務
契約管理システムで作成した支払調書に、新システムでマイナンバーを追記して、毎月1回、CDに格納して税務署に提出する。まだマイナンバーが提供されていない場合又は書類に不備があった場合は、該当する契約者又は受取人のマイナンバー記載欄を空白で提出する。その後、マイナンバーが提供されたら、マイナンバーを記載した支払調書を、訂正支払調書として再度提出する。マイナンバーの誤登録によって、提出済みの支払調書を訂正する必要があった場合は、担当者が個別に確認して対応する。
(4)マイナンバー申告書督促業務
支払調書提出時までにA社にマイナンバー申告書が届かず、支払調書の契約者又は受取人のマイナンバー記載欄を空白で提出した場合は、対象の顧客にマイナンバ一申告書の提出を促する。新システムから促対象の顧客リストを出力し、マイナンバー管理部から顧客に督促書類を送付する。その際、顧客に督促書類を送付したことを把握するために、新システムに督促履歴を登録する。
(5)マイナンバー削除業務
顧客から提供されたマイナンバーは、支払調書を最後に提出してから7年経過した際に新システムで一括削除する。また、提出後7年を経過した支払調書も削除する。
〔新システムの設計〕
マイナンバー制度導入後の業務を踏まえ、新システムの設計を次のように検討している。マイナンバー制度導入後のシステム概念図を図2に、新システムで利用する主要なデータを表1に示す。
(1)システム間連携機能
・マイナンバー提供依頼書類を送付した顧客の顧客番号、送付年月日、顧客氏名及び送付先住所をマイナンバー提供依頼書類情報として契約管理システムから受領し、申告書データに登録する。
・マイナンバーを登録又は削除した顧客の顧客番号を、契約管理システムに送信する。
・現在の支払調書情報に契約者及び受取人の顧客番号を追加した支払調書情報(以下、支払調書基本情報という)を、毎月1回契約管理システムから受領する。
(2)マイナンバー取得管理機
・マイナンバー申告書に記入されている情報を用いて、登録画面からマイナンバーデータのレコードを登録する。
・マイナンバーデータのレコードを登録する際、①該当する顧客の支払調書データのレコードが存在し、最新のレコードのマイナンバーが空白である場合に、再度、支払調書データのレコードを作成し、登録する。支払調書データは、レコードを履歴で保存する。
(3)マイナンバー申告書進捗管理機能
・申告書データに申告書ステータスを保有し、画面から照会、変更する。申告書ステータスの値は、“取得中”、“不備対応中”、“登録済み”又は“削除済み”である。申告書ステータスの初期値は“取得中”である。不備があった場合は、画面から申告書ステータスの値を“不備対応中”にする。不備がなくマイナンバーが登録された場合は、申告書ステータスは”登録済み”になる。
(4)支払調書提出機能
・契約管理システムから支払調書基本情報を受領後、支払調書番号を採番し、支払調書データのレコードを作成して、登録する。その際、契約者及び受取人のマイナンバーを設定する。登録した支払調書データのレコードから、税務署に提出する支払調書を格納したCDを作成する。
・支払調書データから訂正支払調書として税務署に提出するレコードを抽出し、訂正支払調書を格納したCDを作成する。
(5)マイナンバー申告書督促機能
・支払調書提出機能の処理完了後に、支払調書データの各支払調書番号について最新の履歴であるレコードを対象に、促が必要な願容番号を抽出する。抽出した顧客番号に該当する申告書データを参照し、②申告書ステータスが特定の値であるレコードを除外し、督促対象の顧客リストとして帳票に出力する。
・促書類を送付した願客については、画面から促履歴情報を促履歴データに登録する。
(6)削除機能
・削除予定年月日を過ぎているマイナンバーデータのレコードを一括で削除し、対応する顧客の申告書ステータスを“削除済み”にする。なお、削除予定年月日は、マイナンバーデータのレコードを登録する際、システムで計算して設定する。また、削除予定年月日は、ある機能で変更する。
・マイナンバーデータのレコードを一括で削除する処理に加えて、画面から1件ずつ削除可能とする。
・提出後7年経過している支払調書データのレコードを一括で削除する。

設問1:
システム間連携機能について、マイナンバーを登録又は削除した顧客の顧客番号を契約管理システムに送信する目的を、35字以内で述べよ
模範解答
契約管理システムでマイナンバー申告書の印刷を制御するため
解説
解答の論理構成
-
業務要件の確認
- 問題文には、「契約管理システムで、顧客番号と顧客氏名を記載したマイナンバー申告書を印刷する。既に新システムにマイナンバーを登録済みの顧客のマイナンバー申告書は印刷しない。」とある。
- つまり契約管理システムは「この顧客は申告書を印刷すべきか否か」を判断する必要がある。
-
設計方針の確認
- 新システム側の「システム間連携機能」では、「マイナンバーを登録又は削除した顧客の顧客番号を、契約管理システムに送信する。」と定義されている。
- 登録・削除どちらの場合も送信するのは、「印刷可否フラグ」を常に最新に保つためである。
-
両者の関係整理
- 新システムでマイナンバーを“登録”したら、その顧客の申告書は「印刷不要」。
- 新システムでマイナンバーを“削除”したら、再び「印刷対象」になる可能性がある。
- したがって最新状態を契約管理システムへ通知し、「マイナンバー申告書」の印刷処理を制御することが目的となる。
誤りやすいポイント
- 「登録時のみ送信」と誤解し、“削除”を見落とす。
- 送信目的を「顧客情報更新」や「データ同期一般」とぼかしてしまい、“印刷制御”という具体的業務を示さない。
- 契約管理システム側が自動で削除を検知できると誤認し、新システムからの通知不要と考えてしまう。
FAQ
Q: なぜ削除時も送信するのですか?
A: 削除後は再取得が必要になるため、契約管理システムで再び「マイナンバー申告書」を印刷し、顧客へ送付する必要があるからです。
A: 削除後は再取得が必要になるため、契約管理システムで再び「マイナンバー申告書」を印刷し、顧客へ送付する必要があるからです。
Q: 送信内容は顧客番号だけで十分ですか?
A: 問題文では顧客番号のみを送信すると規定されています。顧客番号で一意に顧客を特定できるため、追加情報は不要と設計されています。
A: 問題文では顧客番号のみを送信すると規定されています。顧客番号で一意に顧客を特定できるため、追加情報は不要と設計されています。
Q: 契約管理システムが判断ミスをしないようにする仕組みは?
A: 新システムが登録・削除の度に即時通知することで、契約管理システム内の状態をリアルタイムに保ち、印刷処理を確実に制御します。
A: 新システムが登録・削除の度に即時通知することで、契約管理システム内の状態をリアルタイムに保ち、印刷処理を確実に制御します。
関連キーワード: システム間連携、データ同期、帳票制御、状態管理
設問2:
本文中の下線①で登録した支払調書データのレコードの利用目的を、25字以内で述べよ
模範解答
訂正支払調書を格納した CD を作成するため
解説
解答の論理構成
-
下線①の動作
- 【問題文】「①該当する顧客の支払調書データのレコードが存在し、最新のレコードのマイナンバーが空白である場合に、再度、支払調書データのレコードを作成し、登録する」
- ここで “再度” =既存レコードとは別に新レコードを作成する点が重要です。
-
支払調書提出機能との連携
- 【問題文】「支払調書データから訂正支払調書として税務署に提出するレコードを抽出し、訂正支払調書を格納したCDを作成する。」
- 訂正対象となるのは「マイナンバーが後から提供された契約」であり、①の条件に合致します。
-
結び付け
- ①で追加したレコードがないと、訂正支払調書を生成できません。
- よって①のレコードの利用目的=「訂正支払調書 CD 作成」に帰結します。
誤りやすいポイント
- 「履歴保存のため」とだけ答えるミス
→ 履歴保存は副次的効果であり、目的は訂正提出です。 - 「再提出」ではなく「再登録」と答えてしまう
→ 問われているのは“利用目的”なので提出行為(CD 作成)まで言及する必要があります。 - 「支払調書提出機能」と「マイナンバー取得管理機能」の関連を見落とす
→ 2つの機能をセットで読むことが必須です。
FAQ
Q: 履歴番号が付くのに、なぜ履歴保存が主目的ではないのですか?
A: 履歴保存はマイナンバー訂正の過程で結果として行われる処理です。訂正支払調書を提出しなければ税務署側のデータが更新されないため、主目的は提出用データ生成となります。
A: 履歴保存はマイナンバー訂正の過程で結果として行われる処理です。訂正支払調書を提出しなければ税務署側のデータが更新されないため、主目的は提出用データ生成となります。
Q: CD 以外の媒体でも提出できる場合、答案はどう書くべきですか?
A: 本問は【問題文】が「CD」を明示しているので、解答にも必ず「CD」を含める必要があります。
A: 本問は【問題文】が「CD」を明示しているので、解答にも必ず「CD」を含める必要があります。
Q: 「再度、支払調書データのレコードを作成」とあるが、どのタイミングで作られますか?
A: 顧客からマイナンバー申告書が届き、取得管理機能でマイナンバーを登録する瞬間に同時生成されます。
A: 顧客からマイナンバー申告書が届き、取得管理機能でマイナンバーを登録する瞬間に同時生成されます。
関連キーワード: マイナンバー、支払調書、履歴管理、訂正処理、データ登録
設問3:マイナンバー申告書促機能について、(1)、(2)に答えよ。
(1)支払調書データの最新の履歴であるレコードの中から、督促が必要な顧客番号を抽出する。促が必要な顧客番号の抽出条件を、表1の属性を用いて35字以内で述べよ。
模範解答
契約者マイナンバー又は受取人マイナンバーが空白である顧客番号
解説
解答の論理構成
- 最新履歴に限定
【問題文】「支払調書データの各支払調書番号について最新の履歴であるレコードを対象」にすると明記されています。 - 空白提出が督促トリガ
【問題文】「支払調書の契約者又は受取人のマイナンバー記載欄を空白で提出した場合は…督促書類を送付する」。 - したがって、抽出条件は「契約者マイナンバー又は受取人マイナンバーが空白」であり、そのレコードに含まれる顧客番号が督促リストとなります。
- 表1の属性名を用いると「契約者マイナンバー又は受取人マイナンバーが空白である顧客番号」と表現できます。
誤りやすいポイント
- 「申告書ステータス」で除外するのは次の工程であり、抽出条件そのものではありません。
- 「顧客番号」ではなく「支払調書番号」を条件にしてしまう誤り。最新履歴は支払調書番号単位で特定し、抽出後に顧客番号を得ます。
- 空白判定を「NULL」と混同し、空文字やスペースを扱わない実装上のミス。
FAQ
Q: 契約者と受取人の両方が空白でない場合は督促対象になりますか?
A: いいえ。どちらも登録済みなら対象外です。「契約者マイナンバー又は受取人マイナンバーが空白」の“又は”が鍵です。
A: いいえ。どちらも登録済みなら対象外です。「契約者マイナンバー又は受取人マイナンバーが空白」の“又は”が鍵です。
Q: 既に「申告書ステータス」が“登録済み”でも空白なら督促しますか?
A: 抽出後に「②申告書ステータスが特定の値であるレコードを除外」するため、“登録済み”など除外条件に該当すれば最終的にリストから外れます。
A: 抽出後に「②申告書ステータスが特定の値であるレコードを除外」するため、“登録済み”など除外条件に該当すれば最終的にリストから外れます。
関連キーワード: 主キー、空白判定、履歴管理、データ抽出
設問3:マイナンバー申告書促機能について、(1)、(2)に答えよ。
(2)本文中の下線②で除外しているレコードの申告書ステータスの値を答えよ。また、除外している理由を35字以内で述べよ
模範解答
申告書ステータスの値:不備対応中
理由:A社にマイナンバー申告書が届いていない顧客を対象とするから
解説
解答の論理構成
- 督促対象の定義
- 【問題文引用】「A社にマイナンバー申告書が届かず…提出を促する」
⇒ 督促は“まだ届いていない”顧客のみ。
- 【問題文引用】「A社にマイナンバー申告書が届かず…提出を促する」
- ステータスの意味
- 【問題文引用】「不備があった場合は…申告書ステータスの値を“不備対応中”にする」
- 【問題文引用】「申告書ステータスの初期値は“取得中”」
⇒ “取得中”=未着、“不備対応中”=着荷済み(内容に不備)。
- 除外すべきステータス
- 督促対象は“未着”の“取得中”。
- “不備対応中”は着荷済みで督促対象外。
⇒ 「申告書ステータスが特定の値であるレコードを除外」の“特定の値”は「不備対応中」。
- 理由
- 【問題文引用】「A社にマイナンバー申告書が届いていない顧客を対象とするから」
⇒ 到着済み(不備対応中)は抽出リストに入れる必要がないため。
- 【問題文引用】「A社にマイナンバー申告書が届いていない顧客を対象とするから」
誤りやすいポイント
- “取得中”を除外と早合点しやすい
ステータスの初期値=未着なので督促対象に含める側です。 - “登録済み”や“削除済み”に着目しすぎる
督促抽出前段階でマイナンバーが空白の支払調書番号だけを対象にしているため、登録済み・削除済みはそもそも候補に挙がりません。 - 「不備対応中 = まだ提出されていない」と誤認
文面で“届いたが不備あり”と明示されている点を見落としがちです。
FAQ
Q: “取得中”を除外しないと重複督促になりませんか?
A: 取得中はそもそも未着の状態なので、督促すべき対象として正しいです。重複督促は督促履歴で管理します。
A: 取得中はそもそも未着の状態なので、督促すべき対象として正しいです。重複督促は督促履歴で管理します。
Q: “登録済み”は除外条件に入らないのですか?
A: 支払調書作成時にマイナンバーが空白でなければ督促抽出対象外になるため、追加の除外判定は不要です。
A: 支払調書作成時にマイナンバーが空白でなければ督促抽出対象外になるため、追加の除外判定は不要です。
Q: 不備解消後の再督促はどう制御しますか?
A: 不備が解消されれば“登録済み”へ変更され、次回抽出時に自動的に対象外になります。
A: 不備が解消されれば“登録済み”へ変更され、次回抽出時に自動的に対象外になります。
関連キーワード: 顧客番号、マイナンバー、申告書ステータス、支払調書、データ削除
設問4:削除機能について、(1)、(2)に答えよ。
(1)画面から1件ずつ削除可能とした目的は、二つある。一つは、誤登録時に再度登録可能とするためである。もう一つの目的を35字以内で述べよ。
模範解答
機能:支払調書提出機能
理由:支払調書を提出してから7年後の日付を設定する必要があるから
解説
解答の論理構成
- 【問題文】「削除予定年月日は…システムで計算して設定する。また、削除予定年月日は、ある機能で変更する。」
- 同じ段落内で削除予定年月日を再設定する作業が発生するのは、支払調書提出機能が「支払調書を最後に提出してから7年後」を計算し、各顧客のマイナンバーに反映する局面。
- したがって(1)の回答は「支払調書提出機能/支払調書を提出してから7年後の日付を設定するため」。
- 【問題文】「顧客からマイナンバーが変更になった旨の連絡があった場合は、新システムで管理しているマイナンバーを即時削除し…」
- この“即時削除”は一括処理では対応できず、画面での個別削除が不可欠。よって(2)の回答は「顧客からの変更連絡時に速やかに削除するため」となる。
誤りやすいポイント
- 削除予定年月日を「削除機能」が変更すると勘違いしやすい。実際は提出機能で再計算する。
- 単体削除の二つ目の目的を“再度登録可能とするため”と重複回答してしまう。もう一つは“変更連絡への即時対応”である。
- 「7年経過後の自動削除」と「即時手動削除」を混同して記述が散漫になる。
FAQ
Q: 削除予定年月日はどのタイミングで初期設定されますか?
A: 支払調書提出機能がマイナンバーを登録する際に「提出年月日+7年」を計算して設定します。
A: 支払調書提出機能がマイナンバーを登録する際に「提出年月日+7年」を計算して設定します。
Q: 単体削除は誰が行いますか?
A: 【問題文】の「マイナンバー管理部だけが新システムを利用できる」に基づき、マイナンバー管理部の担当者が画面操作で実施します。
A: 【問題文】の「マイナンバー管理部だけが新システムを利用できる」に基づき、マイナンバー管理部の担当者が画面操作で実施します。
Q: 提出後に誤登録が見つかった場合、削除と再登録だけで済みますか?
A: 誤登録が支払調書提出後に判明した場合は、削除・再登録に加え「訂正支払調書」を作成し、税務署へ再提出する必要があります。
A: 誤登録が支払調書提出後に判明した場合は、削除・再登録に加え「訂正支払調書」を作成し、税務署へ再提出する必要があります。
関連キーワード: 個人情報保護、マイナンバー、データ削除、履歴管理、単体処理
設問4:削除機能について、(1)、(2)に答えよ。
(2)画面から1件ずつ削除可能とした目的は、二つある。一つは、誤登録時に再度登録可能とするためである。もう一つの目的を35字以内で述べよ。
模範解答
顧客からマイナンバーの変更の連絡があった場合に削除するため
解説
解答の論理構成
- 問題文は、個別削除機能の背景として
“削除機能・・画面から1件ずつ削除可能とする。”
と定めています。 - また、業務フローには
“顧客からマイナンバーが変更になった旨の連絡があった場合は、新システムで管理しているマイナンバーを即時削除し、再度マイナンバー提供依頼書類を顧客に送付する。”
という運用が明示されています。 - すなわち、顧客が変更を届け出た時点でただちに旧番号を抹消しないと、誤ったマイナンバーを基に支払調書を作成・提出するリスクが生じます。
- バッチで一括削除する仕組みだけでは「即時削除」の要件を満たせません。そこで、人手による“1件ずつ削除”オプションを設け、変更届が届いた瞬間に迅速な対応を可能にしています。
- 以上より、個別削除機能の第二の目的は「顧客からマイナンバー変更連絡があった際に直ちに削除できるようにすること」と結論付けられます。
誤りやすいポイント
- 「一括削除で十分」と考え、業務上の“即時削除”要件を読み落とす。
- “訂正支払調書”の提出タイミングと混同し、削除ではなく訂正処理だと誤解する。
- “誤登録時の再登録”を唯一の理由と決めつけ、変更届という別シナリオをイメージできない。
FAQ
Q: 個別削除が間に合わず誤った支払調書を提出したらどうなりますか?
A: 問題文の“支払調書データから訂正支払調書として税務署に提出する”機能で訂正します。ただし、個別削除で未然に防ぐほうが効率的です。
A: 問題文の“支払調書データから訂正支払調書として税務署に提出する”機能で訂正します。ただし、個別削除で未然に防ぐほうが効率的です。
Q: 顧客が同日に複数契約を解約した場合でも個別削除が必要ですか?
A: はい。顧客番号は“一つ”と定義されているため、その顧客に紐づくマイナンバーを1回の個別削除で抹消できます。
A: はい。顧客番号は“一つ”と定義されているため、その顧客に紐づくマイナンバーを1回の個別削除で抹消できます。
Q: 削除予定年月日は誰が変更できますか?
A: 問題文では“ある機能で変更する”とだけ記載されており、具体的な権限者は設計時に要件定義する必要があります。
A: 問題文では“ある機能で変更する”とだけ記載されており、具体的な権限者は設計時に要件定義する必要があります。
関連キーワード: 個別削除, マイナンバー管理, 顧客通知, データライフサイクル


