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

模範解答

解説

解答の論理構成

1. 処理速度の前提を確認
   【問題文】の図2処理3説明に
   「D社からの送信時間は、1件／秒である。」
   と明示されています。
2. 処理に充てられる時間を把握
   同じく図2処理3説明に
   「代行処理した取引の送信は、6:30から開始し、国内ATMサービスが開始する7:00までに完了させる。」
   とあります。よって送信可能な時間は
   7:00 − 6:30 ＝ 0.5 時間 ＝ 30 分 ＝ 1,800 秒。
3. 送信可能件数を計算
   送信速度 1件／秒 × 1,800秒 ＝ 1,800件。
4. 境界の決定
   「代行処理した取引の件数が増加した場合，図2の処理3の開始時刻の見直しを行う。」
   との注意書きにより、1,800件を超えると完了できず E銀行元帳に不整合 が生じる危険があるため、見直し条件は “1,800件を超える場合” となります。

誤りやすいポイント

• 30分＝30秒と読み違え、30件と計算してしまう。
• “1取引ごとに送信” をバッチ送信と誤解し、同時並列送信を想定して件数を過大評価する。
• 見直し条件を「1,800件ちょうど」ではなく「1,799件」を超えた時点と勘違いする。

FAQ

模範解答

解説

解答の論理構成

1. 処理3の前提
   • 「代行処理した取引の送信は、6:30から開始し、国内ATMサービスが開始する7:00までに完了させる。」
   • 送信速度は「1件／秒」。
2. 背景イベント
   • 国内ATMは「月曜日7:00」から稼働し、出金等を「リアルタイムでE銀行元帳を更新」する。
3. 潜在的な問題
   • もし6:30〜7:00で送り切れず、7:00を過ぎても D社側の送信が残っていると、
     ①国内ATM→元帳書込み
     ②その後に遅延した代行取引→元帳書込み
     の順となり、実際の発生順（②→①）と逆になります。
4. 帳尻が狂う理由
   • 出金額は“支払可能残高”で判定します。順序が逆だと、残高が足りる／足りないの評価が変わるケースが生じ、元帳の整合性が破綻します。
5. したがって
   • 開始時刻を見直さなければ「代行処理した取引と国内ATM取引の順序が逆転する可能性があるから」という解答になります。

誤りやすいポイント

• 件数の大小に目を奪われ、1件／秒×30分＝1,800件という送信能力を計算し忘れる。
• 「海外ATM取引が少ないから問題なし」と早合点し、国内ATMの即時書込みを軽視する。
• 不整合＝データ欠落と誤解し、「未反映だから」と書いてしまう。実際は“順序”が論点です。

FAQ

模範解答

解説

解答の論理構成

1. 送信対象となる全属性の確認
   表1には送信データとして「顧客名，顧客住所，顧客電話番号」などが列挙されています。
2. リアルタイム送信が行われる時間帯
   表2の「日曜日の0:00〜21:00」にリアルタイム送信を行う旨を確認します。
3. 顧客属性の更新が行われる時間帯
   【問題文】(3) に「平日の8:00から21:00まで支店窓口で受け付けている」と明記されています。
4. 両者を突き合わせて結論
   リアルタイム送信が行われる「日曜日」には顧客名・住所・電話番号が更新されないため、送信を省略しても整合性を損なわないと判断できます。
5. したがって、電文長削減の対象は「顧客名」「顧客住所」「顧客電話番号」となります。

誤りやすいポイント

• 「事故カードの設定情報」も平日窓口業務と勘違いして省略候補に入れてしまう
  → 代行処理時間帯に「事故カードの設定」を受け付けるため、省略不可です。
• 「支払可能残高」を省略しても良いと考える
  → 出金可否判定に必須なので送信必須です。
• 平日と休日の区分を日本時間で考え忘れる
  → 全て「曜日・時間はすべて日本を基準」に示されている点に注意します。

FAQ

模範解答

解説

解答の論理構成

1. リアルタイム更新の性質
   • 【問題文】「(2）E銀行がリアルタイムで送したデータについては、受信後、即時にD社帳を更新する。」
   • よって 0:00 以降に発生した残高変動は即座に D社元帳へ反映される。
2. バッチ更新の性質
   • 【問題文】「(1）E銀行がバッチ処理で送信したデータ…抽出日の0:00時点で完了している取引までを反映」
   • バッチデータはリアルタイム更新より“古いスナップショット”である。
3. 不整合が起こるケース
   • 同一口座に対し，①0:30 にリアルタイム送信→最新残高に更新
     ②1:30 に同日のバッチデータ受信→0:00 時点の残高で上書き
   • これでは「D社元帳」と「E銀行元帳」で差異が生じる。
4. 必要な対応策
   • 古いスナップショットであるバッチデータを適用する際，直近の「抽出日時」またはフラグを確認し，「リアルタイム更新済み」口座のバッチ適用をスキップする。
5. 結論として「リアルタイムで更新した口座は，バッチ処理で受信したデータで更新しない」が正答となる。

誤りやすいポイント

• 「バッチが後に来る＝最新」と思い込み，時点管理を見落とす。
• バッチとリアルタイムの重複検知を「口座番号だけで判定する」とし，取引時刻を考慮しない。
• 「D社元帳の更新処理性能は3,000件／分」を速度調整の根拠と誤解し，論点を性能に寄せてしまう。

FAQ

模範解答

解説

解答の論理構成

1. 通常チェックの確認
   【問題文】(4)②では「事故カードの設定という）がないこと」を出金実行条件にしています。
2. 送信順序の変更
   表3 要望1の対応内容で「事故カードの設定…出金取引よりも先に送信」と仕様変更しました。
3. 時系列の食い違い
   代行処理時間帯では実際の発生順が「出金→事故カード」ですが、送信順が「事故カード→出金」になります。
4. 影響が出る口座
   この順序逆転が存在する口座だけが、E銀行側チェック(4)②により出金が否認されるため「影響が出る口座」となります。
5. 回避策
   送信対象が代行処理済みの取引であることを前提に、反映時は「事故カードの設定有無をチェックしない」ようにチェックロジックを緩和します。これにより実際の取引順を尊重しつつ整合性を確保できます。

誤りやすいポイント

• 「事故カード設定が先→出金が後」と誤解し、影響口座を逆に書いてしまう。
• チェックを全面的に廃止と勘違いし、通常時間帯の出金まで対象に含めてしまう。
• 送信順序の変更が「同時送信」だと考え、影響がないと判断してしまう。

FAQ

模範解答

解説

解答の論理構成

1. 対象口座数の確認
   • 【問題文】「キャッシュカードを保有している全口座（約500万口座）」
2. 処理時間枠の確認
   • 表2「土曜日の0:00〜2:00及び日曜日の0:00〜2:00」でバッチ抽出・送信
   • （1）「全データ受信後に D社元帳を更新する。…終了予想時刻は2:00」
     → 更新処理自体に確保できるのは 120 分。
3. 更新性能の確認
   • （1）「D社元帳の更新処理性能は3,000件／分」
     → 120 分 × 3,000 件／分 ＝ 360,000 件
4. ボトルネックの導出
   • 必要件数 5,000,000 件 ＞ 処理能力 360,000 件
     → 未処理 4,640,000 件が残る
5. 影響
   • バッチが翌日にずれ込み、リアルタイム反映や国内 ATM の開始前整合確認に間に合わず、データ不整合・サービス停止リスクが発生
     → 模範解答のとおり「1日では更新できなくなる」。

誤りやすいポイント

• 「抽出は土曜・日曜に分割されるから大丈夫」と考え、更新処理性能を無視する。
• 更新性能 3,000 件／分を「送信速度」と誤認し、重複計算してしまう。
• 「25 万口座→500 万口座」で 20 倍と気付きながら、処理時間枠も 20 倍必要と気付かない。

FAQ