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

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

• 処理3の開始時刻の見直し：処理3は「月曜日6:30〜7:00」に行われ、D社代行した取引のE銀行元帳への反映処理などを行う。
• 代行処理取引件数の上限：D社元帳の更新処理性能が「3,000件／分」であること。
• 代行処理時間終了後の取引反映：D社からE銀行への送信時間は「1件／秒」で、7:00までに送信完了可能。
• 処理3の時間帯（30分）に反映可能な最大件数の計算。
• 【問題文】から、「代行処理した取引の件数が増加した場合、図2の処理3の開始時刻の見直しを行う」とあり、不整合回避に関連。

2. なぜ「1,800件」が正解になるのか（論理的な説明）

【ポイントの引用と説明】

• D社元帳の更新処理性能：3,000件／分
  → これはバッチでE銀行から送信されるデータをD社元帳に反映する処理速度です。ただし、この性能は「土曜0:00～2:00や日曜0:00～2:00の送信バッチ」に関わるものであり、処理3の内容と直接の計算ではありません。
• 処理3の内容（図2の説明）
  処理3では「代行処理として成立した出金取引及び事故カードの設定」を取引発生順にE銀行システム宛にトランザクション送信し、E銀行元帳を更新します。
  ここで重要なのは、「D社からの送信時間は1件／秒で、7:00までに処理3を完了可能」であること。
• 処理3の時間帯
  処理3の開始時刻は「月曜日6:30から7:00までの30分間」です。30分 = 1800秒。
• 送信速度と可能件数の計算
  1件／秒 × 1800秒 = 1800件
  つまり、処理3の30分間で反映できる最大取引件数は1,800件。
• 問題文の記述の意味
  「代行処理した取引の件数が増加した場合、処理3の開始時刻の見直しを行わない場合は不整合が発生する」とあります。
  処理3で扱う代行取引数が1,800件を超えると、30分で全件を反映できず、元帳整合性が保てなくなるため、開始時刻を早めたり処理時間を伸ばす必要があります。

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

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

• 時間帯ごとの処理分離と性能制限
  銀行の勘定系や代行処理では処理時間帯を区分し、それぞれに処理性能制限が存在することを理解する。
• 取引件数と処理速度から利用可能な処理量を算出する力
  取引件数制限やシステム性能（件数／秒や件数／分）を基に最大処理可能件数を計算できるスキルは重要。
• リアルタイム処理とバッチ処理の違いを正確に把握する
  代行システムによるバッチ処理と、リアルタイムの即時更新の違いを区別し、処理時間帯を正しく認識すること。
• 代行処理から本体（E銀行システム）への反映処理の仕組み
  代行した取引は最終的に本体システムに反映されるため、反映可能な時間帯・速度に制約があること。
• 追加要望による仕様変更の影響分析
  ノウハウ問題として、仕様変更が処理速度・タイミングに与える影響にも注意が必要。

まとめ表：処理関連時間・性能のポイント

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

• 「代行処理した取引と国内ATM取引の順序が逆転する可能性」
• 処理3の開始時刻の見直しが行われない場合に起きる
• E銀行元帳の整合性保持が損なわれるリスク

2. なぜこの解答になるのか（論理的説明）

• 代行処理時間帯（日曜日21:00～月曜日7:00）は、D社システムが海外ATM取引を一時的に処理し、その取引をE銀行元帳に反映するのは「代行処理時間終了後の処理3の時間帯（月曜6:30～7:00）」で行うこと。

  「代行処理として成立した出金取引及び事故カードの設定を、取引発生順にE銀行システム宛てにトランザクションとして送信し、E銀行元帳を更新する」（図2 処理3の説明）

• この反映処理は１件／秒のペースで行われるため、代行処理されていた多くの取引を順次E銀行元帳に反映するのに時間を要します。
• 代行処理の反映が終了した口座や代行処理のなかった口座については、リアルタイム取引が開始されることになっています。

  「代行処理した取引の反映完了した口座に対して、6:30以降に海外ATMから発生した取引をリアルタイムでE銀行システム宛てに送信し、E銀行元帳を更新する」

• もし処理3の開始時刻が早まりすぎて、リアルタイム取引が代行処理の反映より先にE銀行元帳に入ってしまうと、元帳の取引記録において「代行処理で行われた取引よりも後に発生した取引」が、先に記録されてしまい、時系列順が逆転してしまいます。
• また、代行処理時間外（処理1）に発生する国内ATMや海外のリアルタイム取引も同様の順序整合性を保つ必要があります。

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

• 「代行処理とリアルタイム処理の違い」を意識しない
  取引は常にリアルタイムで処理されるイメージが強いため、代行処理があることやその処理とE銀行元帳への反映が別のタイミングである点を見落としやすいです。
• 「処理3の役割」を理解しない
  処理3は単なる起動時間ではなく、代行処理のトランザクションを正しい順番でE銀行元帳に反映し、整合性を保つ重要な処理です。これを知らないと、開始時刻変更の意味が理解できません。
• 不整合の意味を抽象的にとらえる
  「不整合」が取引件数の増加による機械的負荷と勘違いしがちですが、実際は「取引の記録順が逆になる」という論理的な問題です。

4. 試験対策として押さえておくべきポイント

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

• 省略された属性：顧客名、顧客住所、顧客電話番号
• 省略理由：
  • これらの属性は日曜日には変更されない
  • 顧客属性の変更受付は平日の8:00～21:00のみであるため
• 関連箇所：リアルタイム通信時の属性省略の判断基準

解答に至る論理的説明

• 顧客属性は平日の営業時間内にしか変更できない

  〔E銀行システム〕（3）「口座の開設、及び顧客名、顧客住所、顧客電話番号などの顧客属性の変更は、平日の8:00から21:00まで支店窓口で受け付けている。」

• リアルタイムでの送信時に電文長制約があり、一部属性を省略することを許容している

  〔D社元帳の更新処理の概要〕（日曜日の0:00〜21:00）「リアルタイムでの送信時には、電文長に制約があるので、表1の送信データの属性のうち、送信を省略しても問題がないと判断した三つの属性を省略する。」

誤りやすいポイント・ひっかけについて

• 「カード暗証番号」や「事故カードの設定情報」も省略できそうに見えるが、省略しない点
  → これらは出金取引の認証やカード事故対応に直結するため、必ず最新の情報を送信する必要がある。
• 「支払可能残高」も省略不可
  → 取引の可否判断に直接必要な情報なので、省略すると誤出金のリスクがある。
• 平日の属性変更受付時間の認識不足
  → 顧客名・住所・電話の変更は支店窓口の営業時間に制限があり、休日・夜間は原則できないことを把握していないと間違う。
• リアルタイム送信が日曜日も含まれている点の見落とし
  → 日曜日の顧客属性変更がないことと関連づけて理解することが重要。

試験対策のポイントまとめ

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

• 「リアルタイムで更新した口座は、バッチ処理で受信したデータで更新しない」
• 口座元帳の整合性確保
• データ更新の二重・競合を防止するための排他管理
• 「バッチ処理」と「リアルタイム処理」のデータ反映の衝突回避

2. 解答の論理的説明

• バッチ処理の更新データがリアルタイム更新より古い状態のため、データの逆戻りや情報の上書きが起こり、整合性が崩れる。
• これによりD社元帳とE銀行元帳間で食い違いが生じる可能性が高まる。

• D社元帳の状態は常に最新で一貫したものとなる。
• 古く重複したバッチ処理データが、最新のリアルタイム更新を上書きしない。
• 取引の信頼性と障害発生時の復旧が確実になる。

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

• 「二重更新を許しても問題ない」誤解
  データの更新が重複すると古い情報に上書きされるため整合性が崩れるが、これを見落としがちです。
• リアルタイム・バッチ処理の違いを理解していない
  どちらも更新するが役割とタイミングが異なるため、処理範囲の分離が必要なことを認識してください。
• D社側での整合性対応はE銀行側だけが対応すべきと誤解すること
  D社元帳を管理するD社自体が、どのデータを更新するかを正しく制御する必要があります。

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

• 複数のシステム間（今回の場合はE銀行システムとD社システム）でリアルタイム処理とバッチ処理が混在するときは、データの整合性確保が最重要。
• *「リアルタイム処理が優先され、バッチ処理は重複更新を避ける」*という設計ルールはよく出題される典型パターン。
• 代行システム（ここではD社システム）が複数の更新経路を持つ場合の排他制御や更新対象の限定の必要性を理解すること。
• 出題文中の「抽出日時」や「更新性能（件/分）」などの条件は、整合性管理を考察する際の重要ヒントとなるため、見落としなく読むこと。
• 時間帯によって処理が切り替わる場合の処理の重複・食い違い回避措置の設計・運用は情報処理技術者試験で頻繁に問われる。

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

解答がそのようになる理由の論理的説明

1. 影響が出る口座の特定理由

「事故カードの設定については、代行処理時間終了後、即時にE銀行元帳へ反映してほしい。」

• 代行処理した取引は取引発生順に送信していた仕様を見直し、
• 事故カードの設定を出金取引よりも「先に送信する」ように変更しています。

• 代行処理時間中に「出金取引が先、事故カード設定が後」の順で実行された口座の元帳更新の順序と実際の取引発生順がズレるため、
• この口座ではE銀行元帳更新に影響（不整合など）が出る可能性がある

2. 影響回避のためのチェック方法の変更

「代行処理した出金取引をE銀行元帳に反映する際のチェック方法を変更し、事故カードの設定の有無をチェックしない」

(4)①ATMから送信された出金取引の情報と口座元帳データベースの店番号、口座番号及びカード暗証番号が一致すること
(4)②事故カードの設定がないこと
(4)③出金額が支払可能残高の範囲内であること

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

• 取引順序の理解不足
  代行処理時間中の取引は「出金」と「事故カード設定」の順序がもともと取引発生順だったが、対応後は「事故カード設定が先に元帳へ反映」するため、実際の処理順とズレること。
• チェック方法変更の意図の誤認
  事故カード設定の有無をチェックしない理由は、不整合回避のためであり、セキュリティが甘くなるわけではない。出金取引は最終的に元帳反映時に別途チェックされるため安心。
• 発生する影響範囲の限定
  影響が出るのは「代行処理時間中に両方の取引を行った口座のみ」であり、これ以外の口座は影響を受けない点の理解。

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

• 海外ATMの代行処理時間帯の特殊性を理解する
  代行処理時間（日曜日21:00〜月曜7:00）はD社システムが取引を代行し、E銀行元帳は後日まとめて更新される。
• 取引の反映順序と元帳整合性の確保
  代行処理で送信される取引の順序が元帳の更新に影響を与える可能性があるため、順序の変更が必要な場合がある。
• 取引チェックの段階の違いを把握する
  リアルタイム処理時・代行処理後の元帳反映時に複数回チェックが行われるが、一部チェックをスキップして不整合を防ぐ工夫もある。
• 業務委託によるシステムの複雑性
  別会社D社が代行処理を行うため、システム間の整合性維持やタイミング調整が重要である。

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

• D社元帳の更新処理時間の増加
• 対象口座数の増加による処理負荷の爆発的増大
• 1日での更新完了が不可能となる制約

解答の根拠・論理的説明

• 現状の対象口座は約5%の25万口座（全500万口座のうち）に限定している。
• D社元帳の更新処理性能は「3,000件／分」
• 「土曜日0:00〜2:00」、「日曜日0:00〜2:00」にバッチ処理で対象口座を抽出し、送信・更新している。
• 送信データには1日のうちに完了した取引までの情報をセットする。

500万口座 ÷ 3,000 件/分 = 1667 分 ≈ 27.78 時間

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

• 「処理能力が不足する」とだけ述べる表現との混同
  　単に「処理能力が足りない」ではなく「D社元帳の更新処理時間が大幅に増加し、1日での更新が不可能に」なる点が重要。
• 「リアルタイム処理」か「バッチ処理」かの混同
  　更新処理時間の問題はバッチ処理時間帯（深夜の2時間）に関わるため、リアルタイム処理の頻度とは直接の因果関係が薄い。
• 「顧客利便性が向上する」だけを強調し、処理負荷の問題を見落とすこと
  　本問題はシステム処理負荷に焦点があり、業務面の利便性だけで判断しないこと。

試験対策としてのポイント・重要知識

• 処理性能の限界とシステム設計の最適化
  　大規模データのバッチ処理時間やリアルタイム処理性能は必ず計算で検証し、無理なら設計変更が必要。
• システム処理範囲拡大時の影響予測能力
  　部分対象から全体対象への拡大が性能に与える影響を数値で理解できることが評価される。
• 処理切替時間帯（バッチ処理時間帯など）や更新処理方法の理解
  　処理時間帯による処理方式やデータ同期方法を正確に把握しておくこと。
• 設計変更時の影響範囲を述べる問題が多い
  　設問1～3ともシステム改修や運用変更に伴う影響を問われるため、論点整理が必要。

まとめ