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

問1　データ連携システムの構築に関する次の記述を読んで，設問1～4に答えよ。 　A社は，生命保険事業，クレジットカード事業など，各種の事業を展開している企業である。A社では，これまで事業部ごとに業務システムを構築してきた。このたび，全社共通で利用する，金融機関とのデータ連携システムを，経理部主導で構築することになった。 〔金融機関とのデータ連携システム構築の目的〕 　A社では，多くの業務システムで口座振替を利用して請求を行っているが，金融機関とのデータ連携は，これまでそれぞれの業務システムで独自に実施していた。 　今後，口座振替を利用する業務システムが増加することが見込まれるので，金融機関とのデータ連携を全社で一括して行うシステム（以下，新システムという）を構築することにした。 　新システム構築後の概念図を図1に示す。 図1　新システム構築後の概念図 〔金融機関とのデータ連携の概要〕 　現在の各業務システムで口座振替による請求を行う際，委託先の金融機関とのデータ連携の概要は，次のとおりである。 ・それぞれの事業部で金融機関と口座振替基本契約を締結している。口座振替基本契約単位に，口座振替で使用する委託者コード，並びに収納口座の金融機関番号，支店番号，預金種目及び口座番号（以下，収納口座情報という）を決定している。 ・顧客から提出された口座振替依頼書に記入されている，引落口座の金融機関番号，支店番号，預金種目及び口座番号（以下，引落口座情報という）を業務システムに登録する。 ・引落しは，毎月10日又は20日に行う。ただし，金融機関の休業日に当たる場合は，翌営業日が引落日となる。 ・引落日の7営業日前までに顧客ごとの請求金額を確定し，業務システムに請求データとして登録する。同一顧客が複数の契約を結んでいる場合などには，同じ引落日に複数の請求データを登録することも可能である。 ・業務システムでは，引落日の5営業日前に，登録されている請求データから，金融機関に口座振替を依頼するデータ（以下，振替依頼データという）を，金融機関単位に作成して送信する。振替依頼データのフォーマットは，全ての金融機関で共通である。 　振替依頼データのフォーマットを図2に示す。 図2　振替依頼データのフォーマット ・振替依頼データの個別コードは，請求レコードを一意に特定する属性である。業務システムでは，自システム内の請求データを一意に特定する値（以下，請求コードという）を個別コードに設定している。 ・振替依頼データの引落結果コードには，空白を設定する。 ・引落日の2営業日後までに，金融機関から振替依頼の結果データ（以下，振替結果データという）を受領する。振替結果データは，振替依頼データと同じフォーマットであり，引落結果コードに引落結果が設定されている。引落口座から収納口座に全額振り替えられた場合は，請求レコードの引落結果コードに，“引落済み”が，資金不足によって振り替えられなかった場合は，“資金不足”が設定されている。 ・業務システムでは，金融機関から受領した振替結果データの個別コードの値から請求データを特定し，引落結果を反映する。 ・振り替えられなかった請求は，それぞれの事業部で顧客と調整した上で，別途請求する。 〔新システムへの要望〕 　新システムの構築に当たり，それぞれの事業部及び経理部からの要望は次のとおりである。 ・業務システムは，現在各金融機関に送信している振替依頼データを，全て新システムに送信するので，新システムから各金融機関に送信してほしい。 ・金融機関からの振替結果データは，全て新システムで受領し，業務システムに送信してほしい。その際，業務システムから新システムに送信した，全ての振替依頼データの処理結果を送信してほしい。 ・事業部ごとに管理している委託者コードと収納口座を金融機関ごとに集約し，新システムで一元管理してほしい。 ・当月に振り替えられた業務システム別の引落金額合計を，新システムから帳票に出力してほしい。 ・新システムを利用する際には，利用者が担当する業務システムのデータだけが表示されるようにしてほしい。 〔新システムの機能設計〕 　現在の各業務システムの仕様と新システムへの要望を踏まえ，新システムの機能設計を次のように進めてきた。 (1)　データ受付機能 　引落日の7営業日前までに，各業務システムで作成した振替依頼データを受領する。受領した振替依頼データの請求レコードに，どの業務システムから受領したかを表すシステムコード及び処理状況を表すステータスの二つの属性を追加し，集約請求データとして登録する。ステータスには，“振替依頼待ち”を設定する。集約請求データには，全業務システムのデータが格納される。 (2)　振替依頼データ送信機能 　引落日の5営業日前に，集約請求データからステータスが“振替依頼待ち”のデータを金融機関単位に抽出し，図2のフォーマットに編集して金融機関に送信する。ヘッダレコードの委託者コードと収納口座情報は，新システムで管理する金融機関データの値を設定する。請求レコードの個別コードには，集約請求データのシステムコードと請求コードとを結合して設定する。送信した集約請求データのステータスを“振替依頼中”に変更する。 (3)　振替結果データ受信機能 　引落日の2営業日後までに，金融機関から振替結果データを受領する。受領した振替結果データの個別コードの値から集約請求データを特定し，引落結果コードの値を集約請求データの引落結果コードに設定する。また，ステータスを“振替結果受領”に変更する。 (4)　データ返却機能 　引落日の3営業日後に，ステータスが“振替結果受領”の集約請求データを業務システム単位に抽出し，図2のフォーマットで業務システムに送信する。 　なお，業務システムに送信する請求レコードの個別コードには請求コードを設定する。業務システムに送信したデータに対応する集約請求データのステータスを“振替結果返却済み”に変更する。 (5)　認証機能 　事業部のPCから新システムを利用する際，利用者IDとパスワードによって利用者を認証する。利用者IDは利用者個人に割り当て，新システムで利用者データとして管理する。利用者データのパスワードは，暗号化した値を管理する。また，利用者が担当している業務システムのシステムコードを，担当システムデータとして管理する。 (6)　集約請求データ照会機能 　集約請求データの任意の属性を検索条件として，照会画面から照会する。ただし，ある属性の値は，暗黙の検索条件として新システムで設定する。 (7)　振替金額帳票出力機能 　毎月末に，当月振り替えられた業務システム別の引落金額合計を新システムから帳票として出力する。 　新システムで管理する主要なデータとその属性を表1に，新システムの各機能で変更するステータスの値を表2に示す。 表1　新システムで管理する主要なデータとその属性 表2　新システムの各機能で変更するステータスの値 〔新システムへの追加要望〕 　新システムの機能設計内容を事業部に説明したところ，金融機関への振替依頼データの送信を，集約請求データ1件単位で停止する機能を追加してほしいという要望が提示された。 　追加要望に対応するために，ステータスの値を追加して振替依頼停止機能を追加した。振替依頼停止機能の設計では，停止可能な集約請求データのステータスを“振替依頼停止”に変更することで，振替依頼データ送信機能で抽出対象外となる。しかし，この機能追加によって〔新システムの機能設計〕で行ったある機能設計では〔新システムへの要望〕を満たせなくなるので，設計を一部変更する必要がある。 設問1　振替依頼データ送信機能で，各業務システムから受領した請求コードを個別コードにそのまま設定しなかった理由を，35字以内で述べよ。 設問2　集約請求データ照会機能で，暗黙の検索条件として新システムで値を設定している属性名を答えよ。また，設定する目的を30字以内で述べよ。 設問3　振替金額帳票出力機能で，帳票に出力する際，対象となる集約請求データの抽出条件に用いる属性を表1中から二つ挙げ，その属性が満たすべき条件をそれぞれ15字以内で述べよ。 設問4　〔新システムへの追加要望〕について，(1)，(2)に答えよ。 (1)　振替依頼停止機能の設計で停止可能な集約請求データとは，どのようなデータか。表1中の属性名を用いて答えよ。 (2)　設計を一部変更する必要がある機能を挙げ，その変更内容を40字以内で述べよ。