SAシステムアーキテクト試験 午後Ⅰ

平成29年度秋期 システムアーキテクト 午後Ⅰ 問1

事例を読んで設問の答えを考えてから、解説のポイントとIPA公式の解答例・採点講評で確認しましょう。

問題

問1 生命保険会社のシステムの構築に関する次の記述を読んで,設問1~4に答えよ。 A社は,多くの個人保険の契約を保有する大手生命保険会社である。保険金などを顧客に支払った場合には支払調書を税務署に提出している。社会保障・税番号制度(以下,マイナンバー制度という)の導入に伴い,支払調書にマイナンバーの記載が必要になることから,マイナンバーを含むデータを処理するための専用の情報システム(以下,新システムという)を構築することにした。 〔現在の業務と関連システムの概要〕 A社では,顧客から保険金請求の連絡があった場合,保険金部で契約管理システムを利用して手続書類を印刷し,送付する。顧客から記入済みの手続書類の提出を受け,内容を確認して保険金を支払う。一定金額以上の保険金を支払った顧客については,契約管理システムを利用して支払調書を作成し,CDに格納して税務署に提出する。 支払調書には,契約者の氏名,契約者の住所,受取人の氏名,受取人の住所,支払金額,支払年月日などが記載されている。 現在のシステム概念図を図1に示す。 図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年経過している支払調書データのレコードを一括で削除する。 図2 マイナンバー制度導入後のシステム概念図 表1 新システムで利用する主要なデータ 設問1 システム間連携機能について,マイナンバーを登録又は削除した顧客の顧客番号を契約管理システムに送信する目的を,35字以内で述べよ。 設問2 本文中の下線①で登録した支払調書データのレコードの利用目的を,25字以内で述べよ。 設問3 マイナンバー申告書督促機能について,(1),(2)に答えよ。 (1)支払調書データの最新の履歴であるレコードの中から,督促が必要な顧客番号を抽出する。督促が必要な顧客番号の抽出条件を,表1の属性を用いて35字以内で述べよ。 (2)本文中の下線②で除外しているレコードの申告書ステータスの値を答えよ。また,除外している理由を35字以内で述べよ。 設問4 削除機能について,(1),(2)に答えよ。 (1)削除予定年月日を変更している機能を答えよ。また,その理由を35字以内で述べよ。 (2)画面から1件ずつ削除可能とした目的は,二つある。一つは,誤登録時に再度登録可能とするためである。もう一つの目的を35字以内で述べよ。
図1 現在のシステム概念図。顧客、手続書類、契約管理システム、支払調書、税務署の間で書類や情報が流れる現在の業務システム構成図。
図1 現在のシステム概念図。顧客、手続書類、契約管理システム、支払調書、税務署の間で書類や情報が流れる現在の業務システム構成図。
図2 マイナンバー制度導入後のシステム概念図。顧客、契約管理システム、新システム、各種機能、データベース、支払調書、税務署の連携関係を示す概念図。
図2 マイナンバー制度導入後のシステム概念図。顧客、契約管理システム、新システム、各種機能、データベース、支払調書、税務署の連携関係を示す概念図。
表1 新システムで利用する主要なデータ。申告書データ、督促履歴データ、マイナンバーデータ、支払調書データと、それぞれの主要属性を一覧化した表。
表1 新システムで利用する主要なデータ。申告書データ、督促履歴データ、マイナンバーデータ、支払調書データと、それぞれの主要属性を一覧化した表。
解き方のヒントを見る

情報の扱いを検討する範囲の確認

情報の扱いを考えるときは、まず検討の対象となる範囲を確かめましょう。業務全体の話と、その一部分の話を混ぜず、与えられた条件がどこまでを対象としているかを意識すると、論点を整理しやすくなります。

この問題で問われていること

この問題では、扱う情報や業務について、どの範囲の条件を検討しているのかに注目しましょう。ある部分についての記述を全体へ広げて捉えていないか、対象の範囲をそろえて考えることが、整理の手掛かりになります。

視点

情報や業務に関する条件を整理する際は、その条件が対象とする範囲を意識します。一部分について述べられた内容を、範囲を確かめずに全体へ広げて解釈していないかを振り返りましょう。

確認ポイント

  • 検討の対象はどこまでか
  • 条件が当てはまる範囲を意識しているか
  • 一部の話を全体の話として捉えていないか
正解と解説を見る

解説

本問は、マイナンバー制度への対応を題材に、業務要件をシステムの機能へ結び付ける問題です。申告書の印刷制御、訂正支払調書の作成、未着の申告書への督促、最後の提出日を基準とする保存期間を、本文の条件に沿って読み取ることが要点となる。

問題の全体像

A社は、マイナンバー制度の導入に伴い、契約者及び受取人のマイナンバーを支払調書に追加する必要がある。マイナンバーを含むデータは新システムだけで扱い、既存の契約管理システムと必要な情報を連携する構成です。提供が遅れても保険金を支払い、支払調書は番号欄を空白で提出できるため、後日の訂正提出や申告書の督促も必要になる。公式の出題趣旨では、業務とシステムを正しく理解し、業務要件を基に利用者が求める機能を定義する能力を問うとしている。各設問では、機能の処理内容を、その処理が必要になる業務上の理由と対応付けて読むことが重要です。

設問1

着目するのは、〔マイナンバー制度導入後の業務概要〕(1)の「登録済みの顧客のマイナンバー申告書は印刷しない」という条件です。申告書を印刷する契約管理システムには、新システムでの登録・削除の結果を知らせる必要がある。顧客番号を送信すれば、対象顧客の登録状況を印刷制御に反映できる。公式解答例では「契約管理システムでマイナンバー申告書の印刷を制御するため」としており、35字以内の答案では、対象システム、対象書類、印刷制御という目的を押さえる。採点講評では、「支払調書の印刷」とした誤答が指摘されている。制度導入後の支払調書は、新システムでマイナンバーを追記してCDを作成するため、連携の目的を申告書の印刷と結び付ける必要がある。

設問2

下線①は、既存の支払調書データの最新レコードでマイナンバーが空白だった顧客について、番号の登録時に新たなレコードを作成する処理です。業務概要(3)には、空白で提出した後に番号が提供された場合、番号を記載した訂正支払調書を再提出するとある。また、支払調書提出機能は、訂正提出するレコードを抽出してCDを作成する。したがって、下線①で登録するレコードは、この訂正提出に利用される。公式解答例では「訂正支払調書を格納したCDを作成するため」としている。25字以内では、訂正支払調書とCD作成を端的に示す。採点講評では、「履歴データを管理するため」という誤答が指摘されている。履歴保存は設計上の方法であり、問われているのは作成したレコードの利用目的です。

設問3(1)

業務概要(4)では、契約者又は受取人のマイナンバー記載欄を空白で提出した場合に、対象顧客へ申告書の提出を督促するとある。表1の属性に置き換えると、確認するのは「契約者マイナンバー」と「受取人マイナンバー」であり、どちらかが空白なら、その空白に対応する顧客番号を抽出する。契約者側が空白なら契約者顧客番号、受取人側が空白なら受取人顧客番号が対象になる。公式解答例では「契約者マイナンバー又は受取人マイナンバーが空白である顧客番号」としている。35字以内では、二つの属性を「又は」で結び、空白という条件を示します。最新の履歴を対象とするのは、後から番号が登録された場合に、過去の空白レコードを理由として督促しないためです。

設問3(2)

除外する申告書ステータスは、公式解答例では「不備対応中」です。業務概要(3)によれば、番号欄が空白になる原因には、番号が未提供の場合と、届いた書類に不備がある場合がある。一方、業務概要(4)の督促対象は、A社に申告書が届いていない顧客です。「不備対応中」の顧客は申告書が既に届いており、マイナンバー管理部が不備について連絡・対応しているため、未着者向けの督促対象から除外する。公式解答例の理由は「A社にマイナンバー申告書が届いていない顧客を対象とするから」です。理由の35字以内の答案では、督促対象を未着の顧客に限定する点を示します。採点講評では、ステータスの意味を説明するだけの答案が指摘されており、督促業務の対象条件との関係まで書くことが必要です。

設問4(1)

変更する機能は、公式解答例では「支払調書提出機能」です。業務概要(5)には、マイナンバーを「支払調書を最後に提出してから7年経過した際」に削除するとある。登録時に削除予定年月日を設定しても、その後に支払調書を提出すれば、保存期間の基準となる最後の提出日が変わる。したがって、提出を行う支払調書提出機能で、対象顧客の削除予定年月日を更新する必要がある。公式解答例の理由は「支払調書を提出してから7年後の日付を設定する必要があるから」です。理由の35字以内の答案では、支払調書の提出日と、その7年後の日付を設定する必要性を押さえる。取得年月日だけを基準にすると、最後の提出から7年という業務要件を満たせない。

設問4(2)

着目するのは、業務概要(1)の、顧客からマイナンバー変更の連絡があった場合には、管理中の番号を即時削除して再度提供を依頼するという規定です。保存期間後の一括削除とは別に、変更連絡のあった顧客だけを直ちに削除できる必要があり、画面から1件ずつ削除する機能がこれに対応する。公式解答例では「顧客からマイナンバーの変更の連絡があった場合に削除するため」としている。35字以内では、顧客からの変更連絡という契機と、番号を削除する目的を示します。採点講評では、「契約終了」や「不具合」など、本文の業務要件にない理由を挙げた誤答が指摘されている。設問で既に示された誤登録への対応とは別に、本文に明記された変更時の即時削除を根拠にする。

学習のポイント

処理方法と利用目的を区別し、業務の対象条件、状態、実行時点を根拠に、必要な機能とデータ条件を説明する力を養う。

出典:独立行政法人 情報処理推進機構(IPA)平成29年度秋期 システムアーキテクト試験 午後Ⅰ 問1(公式資料:問題冊子(PDF) / 解答例 / 採点講評)

関連する過去問一覧

IPA Advancedは非公式の学習サイトです。解説にはAIによる補助生成を含む場合があります。公式の問題冊子・解答例・採点講評を優先し、誤りは確認後に訂正します。運営・編集方針