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

評価に用いる前提をそろえる

処理の仕組みを検討するときは、評価の前提がそろっているかに注目しましょう。対象とする範囲や状況が途中で変わっていないかを確かめ、同じ条件の下で考えられるように情報を整理することが出発点です。

この問題で問われていること

この問題では、評価の対象にしている範囲や状況を、自分の思い込みで補っていないか確認しましょう。ある条件での判断を別の条件へそのまま広げず、与えられた条件に立ち返って考えることが検討の軸になります。

視点

前提とは、判断を行うときに置いている条件です。考えがまとまらないときは、根拠として与えられた条件と、自分が追加した想定を分けて整理し、評価の途中で前提が変わっていないか確かめましょう。

確認ポイント

• 与えられた条件と自分の想定を区別できているか。
• 判断の途中で、対象の範囲や状況を変えていないか。
• 判断の根拠を、与えられた条件に結び付けられるか。

解説

海外ATMサービスを継続するための代行処理を題材に、取引の反映順序、バッチとリアルタイム更新の競合、事故カード設定の優先反映による影響、対象口座拡大時の処理能力を検討する問題です。

問題の全体像

E銀行は、国内普通預金口座に24時間365日の海外ATMサービスを追加します。国内ATMの停止時間帯にはD社が出金や事故カード設定を代行し、後からE銀行元帳へ反映するため、二つの元帳の整合性を保つ設計が必要です。図2は代行取引をE銀行へ戻す処理、表1・表2は代行に備えてD社元帳を更新する処理、表3は追加要望による変更を示しています。公式の出題趣旨では、業務要件を踏まえた機能配置とシステム間連携、処理能力を考慮した設計が問われています。どちらの元帳を、いつ、どの順序で更新するかを分けて読むことが解答の軸になります。

設問1(1)

図2の処理3①では、代行処理した取引を月曜日6:30から7:00までに送信し、D社からの送信時間は1件／秒とされています。利用できる時間は30分なので、送信できる件数は30×60×1＝1、800件です。したがって、1日の代行取引件数が1、800件を超える場合に開始時刻の見直しが必要となり、公式解答例も「1、800」です。図2の注記により、①の送信時間は②の処理の影響を受けないので、②の処理量を差し引く必要はありません。

設問1(2)

着目するのは、代行取引の送信を完了させる期限と、国内ATMが再開する時刻がともに月曜日7:00である点です。代行取引の反映が7:00以降まで残ると、後から発生した国内ATM取引が、先に発生した代行取引より先にE銀行元帳へ反映される可能性があります。この順序の逆転が、元帳の不整合につながります。公式解答例では「代行処理した取引と国内ATM取引の順序が逆転する可能性があるから」としています。35字以内の答案では、二種類の取引と順序の逆転を押さえます。採点講評では、単に「処理時間内に終了しないから」とする解答が見られたと指摘しており、時間超過が起こす具体的な影響まで説明する必要があります。

設問2(1)属性

表2では、日曜日0:00～21:00に変更が発生した対象口座のデータをリアルタイム送信し、その際に三つの属性を省略するとしています。本文の〔E銀行の勘定系システム及び海外ATMサービスのシステム概要〕(3)と照合すると、顧客名、顧客住所、顧客電話番号の変更は平日の支店窓口でだけ受け付けられます。日曜日には変更されないため、この三つが省略対象となり、公式解答例も「顧客名，顧客住所，顧客電話番号」です。支払可能残高やカード暗証番号、事故カードの設定情報は日曜日にも変わり得るため、同じ理由では省略できません。

設問2(1)理由

省略できる理由は、三つの属性が不要だからではなく、リアルタイム送信を行う日曜日には更新されないからです。顧客名、顧客住所、顧客電話番号は、D社ヘルプデスクが事故カード設定を受け付ける際の確認にも使うため、D社元帳には必要です。ただし、日曜日の変更通知で再送しなくても、既に保持している値を使えます。公式解答例では「三つの属性は，日曜日には更新されないから」または「三つの属性の変更は，平日だけ可能だから」としています。25字以内では、属性が変わらない曜日の条件を簡潔に示します。採点講評でも、関係のない時間帯を理由に記述した解答が指摘されています。

設問2(2)

表2のバッチ送信データは、抽出日の0:00時点の取引までを反映した情報です。一方、日曜日0:00以降の変更はリアルタイムで送信され、受信後すぐにD社元帳へ反映されます。このため、先にリアルタイム更新した口座を、後からバッチで届いた0:00時点の情報で更新すると、新しい情報が古い情報で上書きされます。公式解答例では「リアルタイムで更新した口座は，バッチ処理で受信したデータで更新しない」としています。40字以内では、対象口座とバッチによる上書きの防止を示します。採点講評では、バッチ終了後にリアルタイム処理を行うなど、本文で定めた更新タイミングを変更する解答が指摘されています。指定されたタイミングを保ったまま、古いデータによる更新を防ぐ対応が必要です。

設問3(1)口座

表3の要望1への対応では、取引発生順の送信から、事故カードの設定を出金取引より先に送信する方式へ変更しています。影響を受けるのは、代行処理時間中に出金が成立し、その後で事故カードが設定された口座です。実際の出金時点では事故カードの設定がなくても、E銀行元帳には設定が先に反映されるため、出金取引の再チェック時には事故カードありと判断されてしまいます。公式解答例は「代行処理時間中に出金，事故カードの設定の順で取引をした口座」です。35字以内の答案では、代行処理時間中という条件と、出金から事故カード設定へ進む順序を明記します。

設問3(1)変更内容

本文では、D社で代行処理した出金取引をE銀行元帳へ反映する際にも、暗証番号などの一致、事故カード設定の有無、支払可能残高のチェックを再度行うとしています。しかし、事故カード設定を優先して反映すると、D社で既に成立して現金が払い出された出金まで、再チェックで拒否される可能性があります。その影響を避ける変更として、公式解答例では「事故カードの設定の有無をチェックしない」としています。25字以内では、このチェックの省略を示します。変更の対象は、代行処理済みの出金をE銀行元帳へ反映する際の再チェックであり、出金を受け付ける時点の事故カードチェックとは区別して理解します。

設問3(2)

表2では土曜日に全ての対象口座を抽出し、D社では全データ受信後の2:00から、3、000件／分で元帳を更新します。当初の25万口座なら更新時間は250、000÷3、000≒83分ですが、全500万口座を対象にすると5、000、000÷3、000≒1、667分、約27時間47分となり、更新処理だけで24時間を超えます。したがって、対象口座の拡大によってD社元帳の更新処理が1日では完了しなくなることが問題です。公式解答例では「D社元帳の更新処理時間が大幅に増加し，1日では更新できなくなる」としています。40字以内の答案では、更新処理時間の増加と1日以内に完了できない結果を押さえます。設問が指定するD社元帳の更新処理に焦点を合わせて説明します。

学習のポイント

業務上の変更可能時間とシステムの処理時間を区別し、元帳の更新順序と処理能力から整合性を判断する力を身に付けます。