ホーム > システムアーキテクト試験 > 2015年
システムアーキテクト試験 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字以内で述べよ。
模範解答
請求コードは複数の業務システムで同じ値になる可能性があるから
解説
模範解答の核心キーワードと論点整理
- 請求コードが複数の業務システムで同じ値を持ちうること
- 複数システムのデータを集約管理する際の識別子の一意性確保
- 振替依頼データの個別コードに一意性を持たせる必要性
- 新システムでの「システムコードと請求コードの結合」による重複排除
なぜこの回答になるのか（問題文からの引用と論理的説明）
問題文の【新システムの機能設計】の（2）振替依頼データ送信機能に次の記述があります。
「請求レコードの個別コードには、集約請求データのシステムコードと請求コードとを結合して設定する。」
これに続けて、【小問説明】では「各業務システムから受領した請求コードを個別コードにそのまま設定しなかった理由」が問われています。
重要ポイント
- A社では、複数の事業部（つまり複数の業務システム）から振替依頼データを新システムへ送信しており、全データを新システムに集約します。
- 請求コードは業務システム内での一意の識別子ですが、業務システムが異なれば同じ請求コードが存在する可能性があります。
- そのため、単純に請求コードを個別コードとして使うと、複数の業務システムの同じ請求コード同士が重複し、請求データが正しく特定できなくなります。
- これを防ぐために、「システムコード（業務システムを識別するコード）」と「請求コード」を結合し、一意の個別コードとすることが必要となりました。
受験者が誤りやすいポイント・ひっかけの可能性
-
「請求コードは元々一意だからそのまま使える」という誤解→ 各業務システム毎には一意でも、全社統合の新システムでは重複する可能性があるため注意。
-
「個別コードは請求コード以外の何か別の値を使う」という誤解→ 個別コード自体は請求コードベースでよいが、複数システム間で重複しないようにシステムコードと結合する必要がある。
-
データフォーマットのフォーマット的制約を誤解して、単に形式の問題だと考える場合。
試験対策として覚えておくべきポイント・知識
これらは、システム統合やデータ連携に関する問題で頻出の基本的な考え方です。試験問題でもよく問われるので、必ず理解しておきましょう。
以上の内容を踏まえると、小問の模範解答は「請求コードは複数の業務システムで同じ値になる可能性があるから」となります。
設問2
集約請求データ照会機能で、暗黙の検索条件として新システムで値を設定している属性名を答えよ。また，設定する目的を30字以内で述べよ。
模範解答
属性名：システムコード
目的：利用者が担当する業務システムのデータだけを表示するため
解説
模範解答の核心キーワード・論点整理
- 属性名：「システムコード」
- 目的：「利用者が担当する業務システムのデータだけを表示するため」
- 関連機能：集約請求データ照会機能における暗黙の検索条件設定
- 背景：新システムの利用者認証と権限管理において、利用者が担当する業務システムのデータ以外は表示しない制御を行うこと
解答が「システムコード」である理由の論理的説明
問題文では以下のように記述されています。
- 「集約請求データ照会機能では、集約請求データの任意の属性を検索条件として照会できる。ただし、ある属性の値は暗黙の検索条件として新システムで設定する。」
- 「利用者が担当している業務システムのシステムコードを担当システムデータとして管理する。」（認証機能）
- 「利用者が担当する業務システムのデータだけが表示されるようにしてほしい。」（全社要望）
これらを合わせて考えると、利用者が照会した際に意図しない他の業務システムのデータが見えてしまうことを防ぐために、「システムコード」を暗黙の検索条件として設定し、利用者の担当している業務システムからのデータのみを抽出・表示しています。
具体的には、
- 利用者認証機能で利用者IDとパスワードが検証され、利用者に紐づく担当システムコードが特定される。
- 集約請求データの主な属性の一つに「システムコード」があり、どの業務システムからのデータか示す。
- 集約請求データ照会機能では利用者に許可されたシステムコードでフィルタをかけることで、担当システム以外の請求データが検索結果に出ないように制御される。
これにより、閲覧制限・アクセス制御の要望を満たし、データ漏えいリスクや操作ミスを防止しています。
受験者が誤りやすいポイント・ひっかけの可能性
- 暗黙の条件の対象属性を間違える
「ステータス」や「利用者ID」など、他の属性を想定しがちですが、照会対象の請求データの管理単位として「システムコード」が適切です。 - 目的の表現が曖昧になる
単に「表示制限」や「データ制限」と書いてしまい、誰のための制限か、何を対象にしたものかが不明確になる場合があります。 - 利用者と担当業務システムの関係がわからないと理解が難しい
「担当システムデータ」という概念が、利用者ごとに複数の業務システムコードを管理し、照会時のフィルタ条件になる点がポイントです。
試験対策のポイント・覚えておくべき知識
これらを整理し、問題文の要望を正確に読み取り、システム要素間の関係を把握することが高得点獲得のカギとなります。
まとめ
- 暗黙の検索条件は「システムコード」で、目的は「利用者が担当する業務システムのデータだけを表示するため」
- これは、認証情報と担当業務システム情報を利用してセキュリティと利便性を両立するための設計である
- 選択肢でデータ属性名を迷ったら、業務システム単位かつ利用者権限管理に関係するものを意識するのが良い
- 問題文の要望や機能設計の関連箇所を丁寧に結び付けて理解することが重要
このように解説を踏まえて理解を深めることで、同種のアクセス制御設計問題への対応力が向上します。
設問3
振替金額帳票出力機能で、帳票に出力する際，対象となる集約請求データの抽出条件に用いる属性を表1中から二つ挙げ、その属性が満たすべき条件をそれぞれ15字以内で述べよ。(①と②は順不同)
模範解答
①：属性：引落日
条件：出力対象月内の日であること
②：属性：引落結果コード
条件：“引落済み”であること
解説
模範解答の核心となるキーワードや論点整理
- 引落日：当月の振替が対象なので「出力対象月内の日」であることが必要。
- 引落結果コード：「引落済み」の結果のみを集計対象とし、振り替え成功のデータに限定。
解答の論理的説明
1. 引落日について
問題文の〔振替金額帳票出力機能〕の説明において、
「毎月末に、当月振り替えられた業務システム別の引落金額合計を新システムから帳票として出力する。」
とあります。これは「当月」という期間内のデータに限定して集計を行うことを意味します。
したがって、帳票の集計対象となる集約請求データの抽出条件として、対象期間を特定するために「引落日」が必要となり、その値は**「出力対象月内の日」**である必要があります。
2. 引落結果コードについて
さらに、
「当月に振り替えられた業務システム別の引落金額合計」
とあるため、単に引落日が当月内だけではなく「振替に成功した請求のみ」を対象にする必要があります。
前述の〔金融機関とのデータ連携の概要〕より、
「引落口座から収納口座に全額振り替えられた場合は、請求レコードの引落結果コードに、“引落済み”が、資金不足によって振り替えられなかった場合は、“資金不足”が設定されている。」
とあり、成功データは「引落済み」で表現されます。
そのため、振替金額を集計するためには「引落結果コードが“引落済み”であること」が必要です。
受験者が誤りやすいポイントや注意点
-
引落結果コードに“資金不足”や空白を含める誤り
- 空白や「資金不足」も引落結果コードには設定されているが、それらは振替が成功したデータではないので、集計対象外です。
-
基準期間の特定を誤る
- 「当月の振替」とは問題文にある「出力対象月」なので、引落日を基準に集計範囲を定めることが重要です。
- 「請求日」や「データ登録日」など、他の日時属性を選んでしまうと集計結果がずれます。
-
他の属性と混同する
- 「ステータス」や「システムコード」は集計の抽出条件ではないため、目的に合致しません。
試験対策として押さえておくべきポイント
- 帳票出力や集計処理の対象期間は必ず「日付属性（今回なら引落日）」を基準にすることが多い。
- 振替結果コードなどの結果判定項目は、成功・失敗等の区分により処理対象を限定するため重要である。
- 問題文に明示された要件（今回は“当月振り替えられた”）を正確に把握し、その要件を満たすための属性・条件を選択すること。
- 定義されている用語やコードの意味（例：引落済みは振替成功、資金不足は失敗）を正確に理解する。
- 属性の条件は「○○であること」「○○であるべき」という形で簡潔に記述できるよう練習する。
以上の点を理解すると、この設問の解答は納得でき、同様の帳票設計や抽出条件の設定問題で確実に得点できます。
設問4（1）：〔新システムへの追加要望〕について、（1），（2）に答えよ。
振替依頼停止機能の設計で停止可能な集約請求データとは、どのようなデータか。表1中の属性名を用いて答えよ。
模範解答
ステータスが“振替依頼待ち”の集約請求データ
解説
1. 模範解答の核心となるキーワードや論点
- 「振替依頼停止機能の設計で停止可能な集約請求データ」
- 「ステータスが ‘振替依頼待ち’ のもの」
- 新システムのステータス管理と振替依頼データ送信の関連
- ステータス変更による振替依頼データ送信対象からの除外
2. なぜその解答になるのか（論理的説明）
問題文の〔新システムへの追加要望〕では、「金融機関への振替依頼データの送信を、集約請求データ１件単位で停止する機能」の追加が求められています。
これに対応するために、ステータスに「振替依頼停止」という新たな値を追加し、**「ステータスを ‘振替依頼停止’ に変更した集約請求データは、振替依頼データ送信機能で抽出されなくなる（＝送信対象外となる）」**という設計にしたと明記されています。
ここで振替依頼データ送信機能の処理内容を〔新システムの機能設計〕（2）データ送信機能より確認すると、
「集約請求データからステータスが ‘振替依頼待ち’ のデータを抽出し、金融機関に送信」
となっています。
つまり、新システムでは、
- 振替依頼データ送信前は対象データのステータスは ‘振替依頼待ち’
- 送信後はステータスを ‘振替依頼中’ に変更
です。
この設計に追加要望の振替依頼停止機能を組み込む場合、
- 停止できるデータは、まだ送信されておらず送信対象の段階である必要があるため、
- ステータスが「振替依頼待ち」のデータのみを停止可能とするのが妥当である、と考えられます。
なぜなら、
- 既に振替依頼データ送信済みの「振替依頼中」や
- 振替結果データを受領済みの「振替結果受領」、返却済みの「振替結果返却済み」
のステータスのデータに対しては、振替依頼停止を適用しても機能的に意味がないからです。
したがって、設問の「停止可能な集約請求データとはどのようなデータか？」への回答は、
- 表1の「集約請求データ」の属性で、
- ステータスが「振替依頼待ち」のもの
となります。
集約請求データの主な属性（表1より一部抜粋）
3. 受験者が誤りやすいポイント・ひっかけ
-
「振替依頼中」や「振替結果受領」など、すでに送信済みや結果受領済みのデータを停止可能と誤解する点。
これらのステータスはすでに振替依頼データ送信後の状態であり、送信停止する意味がありません。 -
「振替依頼停止」は新たに追加されたステータスなので、設問を読む際にこの新ステータスの意味と運用の意図を誤解する可能性。
→ 「停止可能なステータス」ではなく、「停止のために変更するステータス」であることに注意。 -
ステータス管理の意味合いを理解せずに、単に「集約請求データの任意のステータス」と答えるなどの曖昧な回答をする。
4. 試験対策として覚えておくべきポイント
-
システム開発・設計での「ステータス管理」の重要性と、機能ごとのステータス遷移を正確に理解すること。
-
「振替依頼待ち」「振替依頼中」「振替結果受領」「振替結果返却済み」のステータスが新システムの振替処理の進捗を表し、どの段階でどんな処理ができるかを把握すること。
-
「機能追加」で新しく加わるステータスは、「そのステータスの意味」と「システム内の処理フロー」への影響を考えながら設計変更を検討すること。
-
本問題のように「停止機能」は処理前のデータに限定することが多い（例：送信待ちのデータのみ停止可能）。
-
表や設計内容を読解し、条件に合致するレコード（データ）の状態を正確に答えられるようにする練習が必要。
以上の点を理解すれば、「振替依頼停止機能で停止可能なデータはステータスが‘振替依頼待ち’の集約請求データである」という模範解答の意味が納得できます。
設問4（2）：〔新システムへの追加要望〕について、（1），（2）に答えよ。
設計を一部変更する必要がある機能を挙げ、その変更内容を40字以内で述べよ。
模範解答
機能：データ返却機能
変更内容：ステータスが“振替結果受領”と“振替依頼停止”の集約請求データを抽出する。
解説
1. 模範解答の核心となるキーワードや論点
- 変更が必要な機能：データ返却機能
- 変更内容：ステータスが「振替結果受領」と「振替依頼停止」の両方の集約請求データを抽出する
- 追加要望の内容：「振替依頼停止」ステータスを導入し、振替依頼データ送信処理からの除外
- 新システムでのステータス管理と抽出条件の見直し
2. なぜその解答になるのか（問題文の引用含む論理的説明）
(1) 追加要望の概要
問題文の「〔新システムへの追加要望〕」には、
「振替依頼データの送信を、集約請求データ1件単位で停止する機能を追加してほしい」
「停止可能な集約請求データのステータスを“振替依頼停止”に変更し、振替依頼データ送信機能で抽出対象外にする」
と記載されています。
これは、特定の請求データについて振替依頼を「送信させない」ようにするための機能です。
(2) 既存のデータ返却機能の設計
「〔新システムの機能設計〕」の（4）「データ返却機能」には、
「引落日の3営業日後に、ステータスが“振替結果受領”の集約請求データを業務システム単位に抽出し…」
「送信後、ステータスを“振替結果返却済み”に変更する」
とあります。
つまり、データ返却機能は「振替結果データ受信機能」でステータスが“振替結果受領”に更新された請求データのみを対象にしています。
(3) 問題点の発生理由
「振替依頼停止」が追加されると、送信されなかった請求データのステータスは“振替依頼停止”となり、振替依頼データ送信機能では抽出から除外されます。
しかし、振替依頼データが金融機関に送信されない以上、振替結果データも当然受領できません。ゆえに、“振替結果受領”になりません。
ここで従来のデータ返却機能の設計通りに“振替結果受領”のみ抽出対象とすると、“振替依頼停止”データは返却されません。
しかし、追加要望により、
「業務システムから新システムに送信した、全ての振替依頼データの処理結果を送してほしい」
という要望があります。
ここで「全て」とは“振替依頼停止”で送信しなかったものも含みます。
ここで「全て」とは“振替依頼停止”で送信しなかったものも含みます。
(4) 変更内容の必要性と意味
したがって、データ返却機能は下表のように、
両方のステータスの集約請求データを抽出し、それぞれの状況に応じた処理・返却を行う設計に変更する必要があります。
3. 受験者が誤りやすいポイント・ひっかけの解説
-
「振替依頼停止」は振替依頼を送らないため、振替結果は受領できないと思い込み、返却処理対象外と誤認する点
→ しかし問題文の要望は「全ての振替依頼データの処理結果を返すこと」。送信停止分も何らかの結果扱い（例えば「停止済み」など）として返す必要がある。 -
ステータス管理が複数あり混乱する点
→ それぞれの機能で更新するステータスを正確に把握し、機能間のデータフローの整合性に注意することが重要。 -
従来の振替依頼中や振替結果受領だけを返却条件と考え、追加されたステータスを反映し忘れること
4. 試験対策として覚えておくべきポイント・知識
-
データ連携システムにおけるステータス管理は業務フロー設計の柱であり、途中で追加される要望により条件を見直す必要があることを理解する。
-
データ送受信と結果返却の処理連携を踏まえ、処理対象の抽出条件や状態遷移を一貫させる設計変更が不可欠になる問題が多い。
-
システム間連携では「全ての送信データについて結果を返す」設計は一般的であり、それを満たすために例外的な状態も考慮する必要がある。
-
問題文から要望や仕様変更を正確に読み取り、「どの機能のどの設計が影響を受けるか」を整理し、問われている箇所を見抜く練習を行う。
まとめ：主要なポイント
このように、変更の本質と理由を順序立てて押さえ、設問の趣旨に合致した簡潔な答えをまとめることが合格への近道です。