システムアーキテクト 2015年 午後1 問01
データ連携システムの構築に関する次の記述を読んで、設問1~4に答えよ。
A社は、生命保険事業、クレジットカード事業など、各種の事業を展開している企業である。A社では、これまで事業部ごとに業務システムを構築してきた。このたび、全社共通で利用する、金融機関とのデータ連携システムを、経理部主導で構築することになった。
〔金融機関とのデータ連携システム構築の目的〕
A社では、多くの業務システムで口座振替を利用して請求を行っているが、金融機関とのデータ連携は、これまでそれぞれの業務システムで独自に実施していた。
今後、口座振替を利用する業務システムが増加することが見込まれるので、金融機関とのデータ連携を全社で一括して行うシステム(以下、新システムという)を構築することにした。
新システム構築後の概念図を図1に示す。
〔金融機関とのデータ連携の概要〕 現在の各業務システムで口座振替による請求を行う際、委託先の金融機関とのデータ連携の概要は、次のとおりである。 ・それぞれの事業部で金融機関と口座振替基本契約を締結している。口座振替基本契約単位に、口座振替で使用する委託者コード、並びに収納口座の金融機関番号、支店番号、預金種目及び口座番号(以下、収納口座情報という)を決定している。 ・顧客から提出された口座振替依頼書に記入されている、引落口座の金融機関番号、支店番号、預金種目及び口座番号(以下、引落口座情報という)を業務システムに登録する。 ・引落しは、毎月10日又は20日に行う。ただし、金融機関の休業日に当たる場は、翌営業日が引落日となる。 ・引落日の7営業日前までに顧客ごとの請求金額を確定し、業務システムに請求データとして登録する。同一顧客が複数の契約を結んでいる場合などには、同じ引落日に複数の請求データを登録することも可能である。 ・業務システムでは、引落日の5営業日前に、登録されている請求データから、金融機関に口座振替を依頼するデータ(以下、振替依頼データという)を、金融機関単位に作成して送信する。振替依頼データのフォーマットは、全ての金融機関で共通である。 振替依頼データのフォーマットを図2に示す。
・振替依頼データの個別コードは、請求レコードを一意に特定する属性である。業務システムでは、自システム内の請求データを一意に特定する値(以下、諸求コードという)を個別コードに設定している。
・振替依頼データの引落結果コードには、空白を設定する。
・引落日の2営業日後までに、金融機関から振替依頼の結果データ(以下、振替結果データという)を受領する。振替結果データは、振替依頼データと同じフォーマットであり、引落結果コードに引落結果が設定されている。引落口座から収納口座に全額振り替えられた場合は、請求レコードの引落結果コードに、“引落済み”が、資金不足によって振り替えられなかった場合は、“資金不足”が設定されている。
・業務システムでは、金融機関から受領した振替結果データの個別コードの値から請求データを特定し、引落結果を反映する。
・振り替えられなかった請求は、それぞれの事業部で顧客と調整した上で、別途請求する。
〔新システムへの要望〕
新システムの構築に当たり、それぞれの事業部及び経理部からの要望は次のとおりである。
・業務システムは、現在各金融機関に送信している振替依頼データを、全て新システムに送信するので、新システムから各金融機関に送信してほしい。
・金融機関からの振替結果データは、全て新システムで受領し、業務システムに送信してほしい。その際、業務システムから新システムに送信した、全ての振替依頼データの処理結果を送してほしい。
・事業部ごとに管理している委託者コードと収納口座を金融機関ごとに集約し、新システムで一元管理してほしい。
・当月に振り替えられた業務システム別の引落金額合計を、新システムから帳票に出力してほしい。
・新システムを利用する際には、利用者が担当する業務システムのデータだけが表示されるようにしてほしい。
〔新システムの機能設計)
現在の各業務システムの仕様と新システムへの要望を踏まえ、新システムの機能設計を次のように進めてきた。
(1)データ受付機能
引落日の7営業日前までに、各業務システムで作成した振替依頼データを受領する。受領した振替依頼データの請求レコードに、どの業務システムから受領したかを表すシステムコード及び処理状況を表すステータスの二つの属性を追加し、集約請求データとして登録する。ステータスには、”振替依頼待ち”を設定する。集約請求データには、全業務システムのデータが格納される。
(2)振替依頼データ送言機能
引落日の5営業日前に、集約請求データからステータスが“振替依頼待ち”のデータを金融機関単位に抽出し、図2のフォーマットに編集して金融機関に送信する。ヘツダレコードの委託者コードと収納口座情報は、新システムで管理する金融機関データの値を設定する。請求レコードの個別コードには、集約請求データのシステムコードと請求コードとを結合して設定する。送信した集約請求データのステータスを“振替依頼中”に変更する。
(3)振替結果データ受信機能
引落日の2営業日後までに、金融機関から振替結果データを受領する。受領した振替結果データの個別コードの値から集約請求データを特定し、引落結果コードの値を集約請求データの引落結果コードに設定する。また、ステータスを“振替結果受領”に変更する。
(4)データ返却機能
引落日の3営業日後に、ステータスが“振替結果受領”の集約請求データを業務システム単位に抽出し、図2のフォーマットで業務システムに送信する。
なお、業務システムに送信する請求レコードの個別コードには請求コードを設定する。業務システムに送信したデータに対応する集約請求データのステータスを“振替結果返却済み”に変更する。
(5)認証機能
事業部のPCから新システムを利用する際、利用者IDとパスワードによって利用者を認証する。利用者IDは利用者個人に割り当て、新システムで利用者データとして管理する。利用者データのパスワードは、暗号化した値を管理する。また、利用者が担当している業務システムのシステムコードを、担当システムデータとして管理する。
(6)集約請求データ照会機能
集約請求データの任意の属性を検索条件として、照会画面から照会する。ただし、ある属性の値は、暗黙の検索条件として新システムで設定する。
(7)振替金額帳票出力機能
毎月末に、当月振り替えられた業務システム別の引落金額合計を新システムから帳票として出力する。
新システムで管理する主要なデータとその属性を表1に、新システムの各機能で変更するステータスの値を表2に示す。
〔新システムへの追加要望〕
新システムの機能設計内容を事業部に説明したところ、金融機関への振替依頼データの送信を、集約請求データ1件単位で停止する機能を追加してほしいという要望が提示された。
追加要望に対応するために、ステータスの値を追加して振替依頼停止機能を追加した。振替依頼停止機能の設計では、停止可能な集約請求データのステータスを”振替依頼停止”に変更することで、振替依頼データ送信機能で抽出対象外となる。しかし、この機能追加によって〔新システムの機能設計〕で行ったある機能設計では〔新システムへの要望〕を満たせなくなるので、設計を一部変更する必要がある。
設問1:
振替依頼データ送信機能で、各業務システムから受領した請求コードを個別コードにそのまま設定しなかった理由を、35字以内で述べよ。
模範解答
請求コードは複数の業務システムで同じ値になる可能性があるから
解説
解答の論理構成
- 個別コードの役割
- 【問題文】「振替依頼データの個別コードは、請求レコードを一意に特定する属性」である。
- 集約による重複リスク
- 【問題文】データ受付機能で「集約請求データには、全業務システムのデータが格納される。」
- よって同じ値の請求コードが別システムから届く可能性がある。
- 設計方針
- 【問題文】「請求レコードの個別コードには、集約請求データのシステムコードと請求コードとを結合して設定する。」
- システムコードを付与すれば、異なる業務システム由来の請求でも一意性を保持できる。
- 結論
したがって「請求コードは複数の業務システムで同じ値になる可能性があるから」となる。
誤りやすいポイント
- 「個別コードだから必ずユニーク」と思い込み、重複リスクを見落とす。
- 「重複してもシステム内で区別できる」と考え、外部(金融機関)との一意性要件を忘れる。
- 「セキュリティ目的で変更」と誤解し、設計意図を取り違える。
FAQ
Q: 個別コードをハッシュ値にする案は適切ですか?
A: 一意性を満たせば可能ですが、要件には「システムコードと請求コードを結合」と明記されているため、仕様変更が必要です。
A: 一意性を満たせば可能ですが、要件には「システムコードと請求コードを結合」と明記されているため、仕様変更が必要です。
Q: システムコードの桁数が増えた場合、個別コード桁数制限は問題になりませんか?
A: フォーマット設計時に最大桁数を見積もり、金融機関と合意しておく必要があります。
A: フォーマット設計時に最大桁数を見積もり、金融機関と合意しておく必要があります。
関連キーワード: 一意性、主キー、コード設計、データ集約、データ連携
設問2:
集約請求データ照会機能で、暗黙の検索条件として新システムで値を設定している属性名を答えよ。また、設定する目的を30字以内で述べよ。
模範解答
属性名:システムコード
目的:利用者が担当する業務システムのデータだけを表示するため
解説
解答の論理構成
- 要件確認
- 【新システムへの要望】
「利用者が担当する業務システムのデータだけが表示されるようにしてほしい」
- 【新システムへの要望】
- データ設計の確認
- 表1で「集約請求データ」の主キーに「システムコード」が含まれる。
- 【認証機能】
「利用者が担当している業務システムのシステムコードを、担当システムデータとして管理する」
- 機能仕様との整合
- 【集約請求データ照会機能】
「ある属性の値は、暗黙の検索条件として新システムで設定する」
- 【集約請求データ照会機能】
- 推論
- 目的は「担当外データの非表示」なので、フィルタすべき属性は業務システムを示す「システムコード」。
- まとめ
よって、暗黙条件に用いる属性名は「システムコード」であり、目的は「利用者が担当する業務システムのデータだけを表示するため」です。
誤りやすいポイント
- 「部署コード」や「利用者ID」を条件に選んでしまう
→ 表1の「集約請求データ」に含まれていないため不適切です。 - 「ステータス」を条件と勘違い
→ ステータスは処理状況の分類であり、担当範囲の制御には使いません。 - 暗黙条件=自動入力と早合点
→ ここでは「裏側で必ず付与される検索フィルタ」を指しています。
FAQ
Q: 暗黙の検索条件は複数設定してもよいのですか?
A: 可能ですが、本要件では担当業務システムでの絞り込みが最優先なので「システムコード」だけで十分です。
A: 可能ですが、本要件では担当業務システムでの絞り込みが最優先なので「システムコード」だけで十分です。
Q: 「システムコード」はどこで設定されるのですか?
A: 【認証機能】で利用者認証後、利用者IDに紐づく担当システムデータから自動設定されます。
A: 【認証機能】で利用者認証後、利用者IDに紐づく担当システムデータから自動設定されます。
Q: もし担当システムが複数ある場合の実装方法は?
A: 担当システムデータに複数行登録し、検索時にIN句やOR条件で一括抽出するのが一般的です。
A: 担当システムデータに複数行登録し、検索時にIN句やOR条件で一括抽出するのが一般的です。
関連キーワード: アクセス制御、フィルタ条件、主キー、データ抽出、認証
設問3:
振替金額帳票出力機能で、帳票に出力する際、対象となる集約請求データの抽出条件に用いる属性を表1中から二つ挙げ、その属性が満たすべき条件をそれぞれ15字以内で述べよ。(①と②は順不同)
模範解答
①:属性:引落日
条件:出力対象月内の日であること
②:属性:引落結果コード
条件:“引落済み”であること
解説
解答の論理構成
- 帳票が扱う対象を確認
- 【問題文】「当月振り替えられた業務システム別の引落金額合計」
⇒ “当月”かつ“振り替えられた”データのみが対象。
- 【問題文】「当月振り替えられた業務システム別の引落金額合計」
- 当月判定に必要な属性
- 表1「集約請求データ」に「引落日」がある。日付で月を判定できる。
- 振替完了判定に必要な属性
- 【問題文】「引落結果コードに、“引落済み”」
- 表1「集約請求データ」に「引落結果コード」が存在。
- よって
- 属性1:引落日/条件:出力対象月内の日であること
- 属性2:引落結果コード/条件:“引落済み”であること
誤りやすいポイント
- ステータス=“振替結果受領”を条件にし、結果コードを見落とす。
- 「引落日」ではなく「請求データ登録日」など他の日付を使ってしまう。
- “当月”判定を「システム処理日」で代用し、月を跨ぐ振替を取り逃す。
FAQ
Q: ステータス“振替結果受領”では不足するのですか?
A: 受領した時点で“資金不足”データも含むため、完了判定には「引落結果コード」が必要です。
A: 受領した時点で“資金不足”データも含むため、完了判定には「引落結果コード」が必要です。
Q: 「引落日」が翌営業日にずれた場合でも当月判定は正しい?
A: はい。判定はあくまで「引落日」の値で行うため、実際の処理日が月末付近でも問題ありません。
A: はい。判定はあくまで「引落日」の値で行うため、実際の処理日が月末付近でも問題ありません。
関連キーワード: データ抽出、属性設計、集約請求データ、集計処理
設問4:〔新システムへの追加要望〕について、(1)、(2)に答えよ。
(1)振替依頼停止機能の設計で停止可能な集約請求データとは、どのようなデータか。表1中の属性名を用いて答えよ。
模範解答
ステータスが“振替依頼待ち”の集約請求データ
解説
解答の論理構成
- 【問題文】「(2)振替依頼データ送言機能 … ステータスが“振替依頼待ち”のデータを金融機関単位に抽出し、…送信する」
→ 送信対象=“振替依頼待ち”。 - 追加要望では「停止可能な集約請求データのステータスを“振替依頼停止”に変更」すると記載。
→ 変更前の状態が“振替依頼待ち”でなければ抽出対象にならないため、そもそも停止操作の対象になり得ない。 - よって、停止機能が適用できるのは「ステータス」が“振替依頼待ち”の集約請求データとなる。
誤りやすいポイント
- “振替依頼中”や“振替結果受領”を選んでしまう
→ これらは既に金融機関へ送信済み、または結果受領後で停止の意味を成さない。 - 「引落日」や「システムコード」で判定すると誤解する
→ 停止機能の条件はステータスのみ。 - “振替依頼停止”を回答に書いてしまう
→ これは変更後の値であって、停止可能かどうかを判断する属性値ではない。
FAQ
Q: “振替依頼停止”に変更した後は再開できますか?
A: 設問文に再開手順の記載はなく、本問の範囲外です。
A: 設問文に再開手順の記載はなく、本問の範囲外です。
Q: 「引落日」が過ぎても“振替依頼待ち”のままなら停止できますか?
A: 原則、引落日の5営業日前に送信処理が実行されるため、その時点以前に停止を行う運用を想定しています。
A: 原則、引落日の5営業日前に送信処理が実行されるため、その時点以前に停止を行う運用を想定しています。
関連キーワード: ステータス管理、トランザクション制御、抽出条件、口座振替、データ連携
設問4:〔新システムへの追加要望〕について、(1)、(2)に答えよ。
(2)設計を一部変更する必要がある機能を挙げ、その変更内容を40字以内で述べよ。
模範解答
機能:データ返却機能
変更内容:ステータスが“振替結果受領”と“振替依頼停止”の集約請求データを抽出する。
解説
解答の論理構成
- 追加要望の影響を確認
【問題文】「ステータスの値を追加して振替依頼停止機能を追加した」とあり、 新たに “振替依頼停止” が設定される。 - 返却機能の既存仕様
【問題文】「ステータスが“振替結果受領”の集約請求データを…送信」と規定。 - 要望とのズレを特定
【要望】「全ての振替依頼データの処理結果を送してほしい」。
“振替依頼停止” も処理結果の一種なので、漏れは許されない。 - 設計変更内容
データ返却機能の抽出条件を
“振替結果受領” OR “振替依頼停止” に修正し、 両ステータスを業務システムへ返却する。
これで追加要望と既存要件を同時に満たす。
誤りやすいポイント
- 「振替依頼データ送信機能」を修正すると勘違いしやすい
→ 送信前ではなく返却時に漏れが生じる点に注意。 - ステータス値の名称を勝手に省略・誤記する
→ “振替依頼停止” などは原文どおりに記載する。 - 抽出条件に “振替依頼中” を含めてしまう
→ 振替未実施データを返却すると業務システム側で整合が取れない。
FAQ
Q: 返却対象に “振替依頼中” を含めるべきでは?
A: “振替依頼中” は結果未判明の状態なので処理結果には該当しません。要望は「処理結果」を返すため、対象外です。
A: “振替依頼中” は結果未判明の状態なので処理結果には該当しません。要望は「処理結果」を返すため、対象外です。
Q: 新機能追加で他のテーブル定義は変わらないのですか?
A: ステータス値を増やすだけなので、表1の項目追加や主キー変更は不要です。
A: ステータス値を増やすだけなので、表1の項目追加や主キー変更は不要です。
Q: 抽出条件をアプリ側で持つのとSQLで持つのはどちらが良い?
A: 運用保守性を考えるとSQL側(ビューやストアド)で条件を管理し、アプリはステータスの列挙体のみ持つ設計が推奨されます。
A: 運用保守性を考えるとSQL側(ビューやストアド)で条件を管理し、アプリはステータスの列挙体のみ持つ設計が推奨されます。
関連キーワード: ステータスマネジメント、データ抽出条件、要件トレーサビリティ、仕様追加、データ返却


