システムアーキテクト試験 2017年 午後1 問01

模範解答の核心キーワードと論点整理

• マイナンバー申告書の印刷制御
• 契約管理システムと新システム間の連携
• 顧客番号の送信
• マイナンバー登録・削除の反映

なぜその解答になるのか（論理的説明）

・マイナンバーを登録又は削除した顧客の顧客番号を、契約管理システムに送信する。

顧客番号と顧客氏名を記載したマイナンバー申告書を印刷する。既に新システムにマイナンバーを登録済みの顧客のマイナンバー申告書は印刷しない。

• 新システムでマイナンバーが登録された顧客は申告書の印刷が不要
• マイナンバーを削除した場合は再度申告書が必要になる可能性があるため、契約管理システムにその情報を伝える必要がある

受験者が誤りやすいポイントと注意点

• 「マイナンバーを契約管理システムで直接管理する」と誤解しやすい
  → 契約管理システムはマイナンバーを直接扱わず、あくまで新システムの情報をもとに申告書印刷制御を行う。マイナンバーの管理は新システムが行う。
• 連携の目的を「データの同期」など曖昧に理解すると、具体的な目的がつかみづらい
  → 送信目的は「印刷制御」に限定されていることを明示的に押さえることが大切。
• 契約管理システムに渡すのは「顧客番号」のみであり、マイナンバーの情報自体は送らない点にも注意。

試験対策として覚えておくべきポイント

• マイナンバーを含む個人情報は厳格な管理が求められるため、マイナンバー情報を扱えるシステムを限定し、それ以外はその情報の有無で業務調整（例：申告書印刷の要否）を行う場合が多い。
• システム間の連携では、「どの情報を誰に伝えるのか」「その目的は何か」を明確に把握することが重要。
• 一般に、個人番号（マイナンバー）制度対応では、顧客番号などのID情報をキーにして関連業務の調整情報を提供し、業務システムの動作制御を行うことが多い。
• 設問は「目的」を問うているので、表層的な機能説明ではなく「なぜ連携が必要か＝業務上の理由・意図」を意識して答えること。

まとめ

1. 模範解答の核心となるキーワードや論点の整理

• キーワード：
  • 「支払調書データのレコード」
  • 「登録」
  • 「訂正支払調書」
  • 「CD作成」
• 論点：
  • 登録される支払調書データのレコードは単に保存のためではなく、「訂正支払調書」を作成するために必要な履歴データの活用を目的としている。
  • 支払調書データは履歴として保存され、マイナンバーが未記載又は誤記の場合に訂正支払調書として再提出される。
  • このように、訂正支払調書を作成し、税務署へ提出するために利用される。

2. なぜその解答になるのか（問題文抜粋と論理的説明）

「支払調書データは、レコードを履歴で保存する」
「①該当する顧客の支払調書データのレコードが存在し、最新のレコードのマイナンバーが空白である場合に、再度、支払調書データのレコードを作成し、登録する。」

「支払調書データから訂正支払調書として税務署に提出するレコードを抽出し、訂正支払調書を格納したCDを作成する。」

3. 受験者が誤りやすいポイントやひっかけの理由

• 誤りやすいポイント：
  「支払調書データ」と聞くと単に提出するためのデータと思いがちで、「訂正支払調書」のために複数の履歴レコードを管理し再提出するイメージを持ちにくい点。
• ひっかけになりやすい選択肢例：
  「税務署に提出する支払調書を作成するため」
  これは正しいが、設問の下線①の文脈は「レコードを再度作成し登録する場面」。この場面はマイナンバー空白時に訂正用として作成するものであり、単に初回提出用ではない。したがって、より正確には「訂正支払調書」のための利用目的を問うている。
• マイナンバー管理の重要性を軽視しやすい点：
  登録された支払調書レコードがマイナンバーの有無で区別されていることに注意。

4. 試験対策として覚えておくべきポイントや知識

• 支払調書データは単一の提出用データではなく、「履歴データ」としての性格を持つこと。マイナンバーの提供状況に応じて複数の調書データを管理する仕組みが必要。
• マイナンバー記載の問題による「訂正支払調書」の再提出が義務付けられており、そのために訂正用レコードを新規登録・管理する。
• 「登録」したデータの利用目的を問う問題では、単に作成・提出だけでなく「訂正」や「履歴管理」の目的があることを理解する。
• 個人番号（マイナンバー）等の重要情報を伴うシステムは、関連業務フローと機能の連携を正確に把握し、業務要件に合致した処理の意図を読み取る力が求められる。

模範解答の核心キーワード・論点整理

• 督促が必要な顧客番号の条件
  → 支払調書データの最新レコードにおいて
  → 「契約者マイナンバー」または「受取人マイナンバー」が空白である
• 関連データ
  支払調書データ（最新履歴）から対象顧客番号を抽出
• 督促理由
  マイナンバー未提供または不備のため、マイナンバー記載欄が空白となっている

なぜこの解答になるのか：論理的解説

1. 【マイナンバー申告書督促業務】では以下が示されています。

支払調書提出時までにマイナンバー申告書が届かず、支払調書の契約者又は受取人のマイナンバー記載欄を空白で提出した場合は、対象の顧客に督促を行う。

2. 【新システムの設計（5）マイナンバー申告書督促機能】には、

支払調書データの各支払調書番号について最新の履歴であるレコードを対象に、促が必要な顧客番号を抽出する。

促が必要な顧客番号とは申告書ステータスにより除外されるものがあるが、基本はマイナンバー未提供の顧客を抽出する意図である。

3. **支払調書データ表（表1）**には以下の主要属性があります。

受験者が誤りやすいポイント・ひっかけ選択肢

• 契約者マイナンバーと受取人マイナンバーの両方が空白の場合に限定する誤り
  → 問題文では「契約者又は受取人のマイナンバー」が空白であれば督促対象です。どちらか片方だけでも空白なら督促が必要です。
• 申告書データや督促履歴データの属性を条件に絡める誤り
  → 督促対象抽出の条件は「支払調書データ（最新）」のマイナンバー空白で判断します。申告書ステータスや督促履歴情報は除外条件や記録用であり、抽出条件には含まれません。
• 支払調書の履歴全件を対象にする誤り
  → 最新の履歴のみが対象です。古い履歴は除外されます。

試験対策として覚えておくべきポイント

• マイナンバー制度導入に伴う督促業務は、マイナンバー未提供の顧客（契約者または受取人）を把握し、督促することが目的である。
• 最新の支払調書データのマイナンバー欄が空白かどうかが督促対象抽出の基本条件
• 申告書ステータスや督促履歴は業務管理のための情報で、「抽出条件」と混同しないようにする
• マイナンバー管理システムでは履歴管理が重要だが、督促対象抽出は常に最新の履歴を対象に行う
• マイナンバーは契約者・受取人両面で管理されるため、両者のマイナンバーの空白チェックが必要

「契約者マイナンバー又は受取人マイナンバーが空白である顧客番号」

1. 模範解答の核心となるキーワードや論点の整理

• 申告書ステータスの値：「不備対応中」
• 除外理由：「A社にマイナンバー申告書が届いていない顧客を対象とするから」
• 対象業務は、「マイナンバー申告書督促機能」における、督促対象顧客リスト作成時のレコード抽出条件
• 申告書ステータスによって督促対象が制御されていること
• 「不備対応中」の顧客の申告書は督促リストから除外されている

2. なぜその解答になるのか（問題文の引用を交え論理的に説明）

• 申告書ステータスの種類は以下の通り：
  • “取得中”
  • “不備対応中”
  • “登録済み”
  • “削除済み”
• マイナンバー申告書督促機能の説明部分（設計(5)）では、
  「申告書データを参照し、②申告書ステータスが特定の値であるレコードを除外し、督促対象の顧客リストとして帳票に出力する」
  とある。

• 「不備があった場合は、画面から申告書ステータスを“不備対応中”にする」
• つまり「不備対応中」は、顧客から申告書が既に届いているが、不備があるため修正・再提出を促している状態。

3. 受験者が誤りやすいポイントやひっかけ選択肢

• 「取得中」というステータスの誤解
  「取得中」は初期状態で、申告書をまだ提出していない可能性が高い状態です。督促対象となるのは「取得中」の顧客であるため、誤ってこれを除外対象と考えると誤答になります。
• 「登録済み」は提出済みで問題なしとして除外される可能性が高い
  ただし問題文では「不備対応中」を除外したとありますので、「登録済み」は督促不要として除外だが「不備対応中」も除外対象であることに注意。
• 「削除済み」は管理上の区分であり、督促の対象外で当然
  これは除外されて当然と理解しやすいが、「不備対応中」も除外されることを見落とさないことが重要。
• 抽出対象外とする申告書ステータスの説明部分が曖昧に感じて混乱しやすいので、どの段階で督促対象になるか明確に認識することが重要。

4. 試験対策として覚えておくべきポイントや知識

• マイナンバー申告書の進捗管理で利用されるステータス（取得中、不備対応中、登録済み、削除済み）それぞれの意味と状態を正確に理解すること。
• 督促業務のためのリスト作成では、既に申告書が届いている段階（不備対応中、登録済みなど）は督促対象から除外し、「未提出（取得中）」状態の顧客のみ督促対象とする。
• 業務プロセスやシステム設計において、「ステータスによる処理分岐」がある場合は、それぞれのステータスがどのような意味を持つかを押さえておくこと。
• 問題文中に「除外しているのは②申告書ステータスが特定の値であるレコード」と書かれている場合は、その値（「不備対応中」）に注目し、なぜ除外されるか論理的に説明できるように準備する。

1. 模範解答の核心となるキーワードや論点

• 機能名：支払調書提出機能
• 削除予定年月日の設定はこの機能が行う
• 削除予定年月日は「支払調書を提出してから7年後」の日付であることが必要
• 理由：マイナンバーや支払調書データの保管期間が「7年」で法的に定められているため

2. 解答理由の論理的説明

「削除予定年月日は、マイナンバーデータのレコードを登録する際、システムで計算して設定する。また、削除予定年月日は、ある機能で変更する。」

「契約管理システムから支払調書基本情報を受領後、支払調書番号を採番し、支払調書データのレコードを作成して登録する。その際、契約者及び受取人のマイナンバーを設定する。」

「顧客から提供されたマイナンバーは，支払調書を最後に提出してから7年経過した際に新システムで一括削除する。」

• 削除予定年月日は「支払調書提出時点」を基準に計算・設定する必要があり、
• このタイミングは「支払調書提出機能」の中で支払調書作成時に定めるのが自然である。

3. 受験者が誤りやすいポイントと注意点

• 誤りやすいひっかけ：
  • 削除機能が「削除予定年月日を設定・変更する」と勘違いしがち
  • マイナンバー取得管理や進捗管理機能など、「マイナンバーに関する処理を行う」機能群と混同する
• なぜ誤るか：
  • 削除機能は「一括削除や1件削除を実行」する機能であり、「削除予定日の設定」は行わないことを本文で明示
  • 削除予定日は支払調書の提出年月日を基準に計算するので、「支払調書提出機能」と関連する
• 対策：
  • 機能の役割や処理タイミングに注目すること
  • 表示されたステップやコメントを根拠に落ち着いて判断することが重要

4. 試験対策ポイントまとめ

模範解答の核心となるキーワードや論点

• 「画面から1件ずつ削除可能とした目的」
• 「誤登録時に再度登録可能とするため」（既に問題文で示されている目的の一つ）
• もう一つの目的は、「顧客からマイナンバーの変更の連絡があった場合に削除するため」
• マイナンバーの変更対応のための個別削除の必要性

なぜその解答になるのか（問題文の引用に基づく論理的説明）

（〔マイナンバーに関する業務とシステム化の方針〕）
「顧客からマイナンバーが変更になった旨の連絡があった場合は、新システムで管理しているマイナンバーを即時削除し、再度マイナンバー提供依頼書類を顧客に送付する。」

（〔新システムの設計〕）
「マイナンバーデータのレコードを一括で削除する処理に加えて、画面から1件ずつ削除可能とする。」

• マイナンバー誤登録の修正に個別削除が必要
• そして顧客からのマイナンバー変更連絡を受けて、即時かつ個別に該当マイナンバーを削除することが必要だが、これも個別削除機能の目的である

受験者が誤りやすいポイントとひっかけ選択肢

1. 一括削除があるため個別削除は不要と誤認する点
   新システムでは7年経過したマイナンバー等を一括削除する運用もありますが、変更があった場合は即時かつ個別に対応しなければならないため、一括だけでは不十分です。一括削除は期限管理に基づく削除であり、個別の変更には対応できません。
2. 誤登録対応だけが目的と誤解する点
   誤登録対応は個別削除の目的の一つですが、顧客からの変更連絡に対応することも重要な目的です。問題の問われ方で「二つある」と指示されているのに一つしか答えない誤りを注意してください。
3. マイナンバーの変更があっても支払調書の再提出がないため削除不要と誤解する点
   「支払調書を税務署に提出した後にマイナンバーの変更があっても、支払調書の再提出は行わない」という文と混同し、システムから削除する必要がないと誤解することがあります。提出済み支払調書への反映はしませんが、システム内の個人情報保護や更新上は変更時の削除が必須です。

試験対策として覚えておくべきポイント・知識

• マイナンバーの厳重管理と変更対応は別建ての重要な業務要件である。
  システムは誤登録対応と顧客からの変更対応の双方を支援する必要があるため、削除機能は一括だけでなく個別も可能にする。
• マイナンバー削除は、税務署提出とは独立した運用管理である。
  つまり、支払調書の提出後に変更があっても再提出はしないが、システム内データの更新（削除）は行う。
• システム設計上、「画面から1件ずつ削除する機能」の存在意義は、誤登録・変更対応など個別ケースに即応するため。
• 企業の個人情報管理やマイナンバー制度対策では、変更・削除の履歴管理や即時対応が求められる点は非常に重要。

まとめ