www.youtube.com 本動画では、令和5年度春期システムアーキテクト試験の午後Ⅰ問3「融資保証システムの再構築」を、問題文・解答例・採点講評の観点に沿って解説します。題材は大手クレジットカード会社L社が運用してきた融資保証システムの老朽化対応で、現行業務がFAXを前提に成立している制約、情報セキュリティ規則による接続制限、そして新システムへの要望を矛盾なく機能設計へ落とし込む能力が問われます。午後Ⅰとしての読みどころは、与件に散らばる業務ルールが「データの導出条件」「状態遷移のトリガ」「集計対象の範囲」「マスタで管理すべき属性」としてそのまま問われる点で、一般的な金融システム像に寄せず、本文に書かれている制約と用語定義に忠実に解答を構成できるかが合否を分けます。 全体の業務フローは、金融機関からの保証委託申込みを受け付け、L社が保証審査・承諾を行い金融機関が融資を実行し、顧客返済が滞ればL社が代位弁済を行うという流れです。現行では申込みがFAXで行われること、申込種別ごとに受信用FAX番号を分けて運用していること、担当者の割当が金融機関と申込種別の組合せで決まること、契約状態が複数段階で管理されることなど、アナログ運用に起因するが確立した業務ルールが存在します。これを新システムに移す際、単に入力画面を作るのではなく、手作業で暗黙に行われていた判定や振分を、ヘッダー情報やマスタ、状態項目として形式知化し、システムの処理に落とすことが求められます。 設問1は、要望の取捨選択を情報セキュリティ規則に基づいて行えるかを問うています。与件では、外部信用機関との接続は特定の端末である外信端末に限定され、社内ネットワークおよび社内システムとの接続を許可していないという制約が明記されています。この制約の下で、新システムに外部信用機関から情報を取得する機能を設け、新システム上で確認したいという要望をそのまま実装すると、外部信用機関と社内システムの直接接続になり規則違反になります。したがって見送るべき要望は外部信用機関からの情報取得を新システムで確認したいという内容であり、理由は外部信用機関との接続が外信端末に限定されているから、という形でまとめます。午後Ⅰでは、単に「セキュリティ上できない」では弱く、どの規則のどの条件に抵触するのかを与件語で示すことが採点講評の意図に合致します。 設問2は、FAX受信管理において、FAXサーバが提供するヘッダー情報から業務上必要な情報を導出して担当者割当につなげる設計力が問われます。現行業務のルールとして、申込種別ごとにL社側の受信FAX番号を分けており、担当者は金融機関と申込種別の単位で割り当てるとされています。FAXサーバが取得できる代表的なヘッダー情報は送信元FAX番号と受信FAX番号であるため、送信元FAX番号からは「どの金融機関から来た申込みか」を特定でき、受信FAX番号からは「どの申込種別宛てに送られたか」を特定できます。したがって、ヘッダー情報の受信FAX番号を起点に申込種別を導出し、送信元FAX番号を起点に金融機関を導出し、その組合せで担当者を決定する、というマッピングが成立します。午後Ⅰの読解ポイントは、担当者割当の単位が「金融機関×申込種別」と明記されている以上、その二要素を必ず導出できる情報源を選ぶ必要があり、そこにFAX番号の分け方という運用設計が直結している点を見抜くことです。 設問3は、契約状態を実行待ちから実行中へ変える条件判定が、どの機能の更新情報を参照すべきかを問うています。与件では実行中へ移す条件が二つあり、保証料が全額入金されていることと、金融機関から保証契約書類を受領していることが揃ったときに状態を変えるとされています。新システムではこれを入金状態と書類受領状態として管理する方針が示され、表の機能から該当状態を更新するコンポーネントを特定すると、入金状態を入金済に更新するのは保証料管理であり、書類受領状態を受領済に更新するのは書類管理です。結局、実行管理機能が参照すべきは保証料管理と書類管理が更新した二つの状態であり、この二機能が揃って初めて契約状態を実行中へ遷移できる、という整理になります。午後Ⅰでは「条件」をそのまま文章で繰り返すのではなく、条件を担保する状態項目がどの機能で更新されるかまで落とし込むことが求められています。 設問4は、融資残高管理が何のためにあり、集計値をどの範囲で算出すべきかという業務目的と状態理解が焦点です。融資残高ゼロ一覧の利用目的は、完済された融資が発生した際に対応する保証案件の契約状態を終了へ更新し、外部信用機関に保証完了を報告するという業務に直結しています。ここは一覧が単なる参照レポートではなく、終了判定と外部報告という後続業務のトリガとして使われる点を押さえる必要があります。次にレポートに記載する金額の算出は、全ての保証案件が代位弁済になった場合にL社が金融機関へ支払う金額、すなわち最大リスク額を求めるという意図です。代位弁済は残債の全額支払いである以上、対象は「現在保証が有効に稼働している案件」の融資残高の合計になります。ここで採点講評が問題視しやすいのは、契約状態の意味を曖昧にして実行待ちや終了まで含めてしまう誤りで、与件上、融資残高が更新されるのは契約状態が実行中の案件であるため、合計対象も実行中の案件に限定する必要があります。午後Ⅰでの得点ポイントは、なぜ実行中のみなのかを、残高更新の対象範囲と契約状態の定義に基づいて説明できることです。 設問5は、商品管理機能として新たに管理すべき内容を、複数の要望から漏れなく抽出できるかを問うています。要望の中には、必要な申込書類がそろっているかどうかのチェックを新システムで行いたいというものと、保証審査業務で必要な保証料を新システムで算出したいというものがあり、どちらも商品ごとの差が前提になります。現行業務では商品ごとに必要書類が異なり、保証料も商品ごとの利率を用いて計算しているため、システムで自動化するには、商品単位で「必要書類を判定するためのルール」と「保証料算出に用いる利率」をマスタとして保持する必要があります。採点講評が指摘しがちな典型は、どちらか片方の要望しか拾わず、必要書類だけ、あるいは利率だけを答えてしまう欠落で、本問は二要素を同時に満たす属性追加を言い切ることが重要です。 この問3の核心は、手作業で成立していた判断や統制を、データ項目と機能配置に変換する能力にあります。FAX番号を申込種別判定に使うのは現行運用の工夫であり、それをヘッダー情報導出ロジックへ落とすのが設計です。入金と書類受領という二条件は現行業務の統制であり、それを入金状態と書類受領状態として管理し、どの機能が更新し、どの機能が判定に使うかを整理するのが設計です。さらに、外部信用機関との接続制限というセキュリティ規則は、要望をそのまま実装できない制約として現れ、実装可否の判断が設計に含まれます。集計や一覧も、単なる帳票ではなく、外部報告や最大リスク把握といった業務目的を踏まえて対象範囲を限定しなければ誤答になります。 最後に、この動画を見る意義をまとめると、令和5年度春期システムアーキテクト午後Ⅰ問3を通じて、業務の制約とセキュリティ規則が機能要件をどのように縛るか、アナログ運用のルールをどのようにデータ導出や状態管理として実装要件に落とすか、そして契約状態の定義に基づいて集計対象を正しく限定する読み方を、採点講評が求める観点で身に付けられる点にあります。与件の条件語を一つずつ根拠として拾い、機能・状態・マスタ属性へ変換する作法を徹底することで、同種の業務システム再構築問題でも再現性高く得点できる力を固めてください。
