融資りん議ワークフローシステムの構築に関する次の記述を読んで,設問1〜3に答えよ。
X銀行は,メインフレーム上で顧客情報,預金情報及び融資情報を管理するシステム(以下,基幹システムという)を利用してきた。
このたび,紙の帳票を回付していた融資りん議をペーパレス化するための融資りん議ワークフローシステム(以下,WFシステムという)を,基幹システムとは別に新規に構築することにした。
〔現状の融資りん議の業務〕
X銀行での融資りん議の業務の流れは次のとおりである。
(1)融資申込受付業務顧客は,営業店の窓口に融資案件(以下,案件という)の申込書を提出する。申込書を受け付けた営業店(以下,担当営業店という)の担当者(以下,案件担当者という)は,基幹システムで案件番号を発番し,基幹システムの顧客番号とともに申込書に記載する。取引実績のない新規顧客の場合には,基幹システムで顧客番号を発番してから記載する。
(2)議書作成業務:案件担当者は,案件番号を発番した日を作成基準日としてりん議書を作成する。りん議書には,融資対象の顧客の担保不動産の評価データ(以下,担保明細という)を記載した不動産担保評価帳票を,不動産担保評価システム(以下,担保評価システムという)から出力して必ず添付する。資金使途及び返済財源を確認し,基幹システムにある信用格付,財務分析結果及び過去のりん議結果を調査し,必要な検討をした上で,案件情報をりん議書に記載する。りん議書には基幹システムと担保評価システム以外の情報も必要であり,りん議書を作成するために複数のシステムを操作する。
(3)りん議書付業務:案件担当者は,業務規程に従い回付経路を記載した回付書を添付して,りん議書を承認者へ回付する。承認者はりん議書に対して意見を付し,承認又は差戻しの判断をする。承認されたりん議書は決裁者へ回付される。決裁者は案件担当者,承認者の意見を踏まえ,融資の決裁,却下,又は差戻しの判断をする。決裁者が決裁又は却下の判断をすると,りん議が完了する。承認者及び決裁者は,可能な限り最新の情報を基に判断をする。りん議書の修正が必要な場合,承認者又は決裁者は修正せずに案件担当者に差し戻した後,案件担当者がりん議書を修正して再度回付する。申込書を受け付けてからりん議書の回付の開始までの標準的な所要日数及び回付されてから承認及び決裁の判断までの標準的な所要日数を踏まえ,回付の開始,承認及び決裁の期限(以下,目標期日という)を定めている。
担保明細は必要に応じて評価替えしている。承認者及び決裁者は,判断の際に融資対象の顧客の担保明細が更新されていないか,担保評価システムの評価日を確認する。りん議書には最新の不動産担保評価帳票を添付する必要があるので,担保明細が更新されている場合は案件担当者に差し戻す。
融資希望金額が担当営業店の決裁可能金額を超える案件の場合,回付経路には担当営業店に加え本部が含まれる。担当営業店内での承認の後に本部に回付され,本部で承認・決裁される。
〔現状の問題点〕
情報システム部のY課長は,WFシステム構築に当たり融資部にヒアリングをし,次の問題点を抽出した。
・回付経路に本部が含まれる場合,担当営業店で作成したりん議書一式を本部に送付し本部での決裁完了後に担当営業店に決裁書類一式を返送する流れとなっている。担当営業店と本部ではお互いの処理状況が分からず,本部ではどの顧客のどの案件をいつまでに決裁する必要があるかが本部に回付されるまで分からないので,担当営業店内での回付状況を踏まえて承認決裁の体制を整えておくことができていない。
・目標期日の到来に気付かず期限を超過することがある。
・りん議書が案件ごとの管理となっているので,同一顧客の別案件の調査で確認した延滞発生などによる顧客の信用格付の変化に,案件担当者が即座に気付けない。
〔WFシステムの概要〕
Y課長はヒアリング結果を基にして,WFシステムを次のように設計した。
りん議書作成に必要な主なデータは複数の既存システムにある。これらのデータは,引き続き既存システムで管理する。①WFシステムは,既存システムの機能をサービスとして利用し,りん議書作成に必要なデータを一括で取得できる方式にした。
WFシステムの主な機能は次のとおりである。
(1)融資申込の受付機能
顧客から受領した申込書を案件担当者がWFシステムに取り込むと,WFシステムは基幹システムから案件番号と顧客番号を取得し,案件データを作成して受付を完了する。この時点で案件ステータスは“受付”になる。WFシステムは案件の進行状況をりん議の完了まで管理する。
(2)議書の作成機能
案件一覧画面で案件担当者が案件番号を選択すると,りん議書入力画面に遷移し,案件ステータスは“作成中”になる。りん議書入力画面の起動時に,WFシステムは必要なデータを複数の既存システムから一括で取得し,WFシステムに保存した後,りん議書入力画面に案件データとともに表示する。案件担当者は,必要に応じて不足している情報を入力し,りん議書をWFシステムに保存する。
(3)議書の回付機能
案件担当者は,りん議書に回付経路を設定する。回付経路にはりん議書を処理する担当者(以下,回付先担当者という)の順番を定義する。回付経路の最初の回付先担当者には,案件担当者が自動的に設定される。最後の回付先担当者が決裁者,途中の回付先担当者は承認者になる。②ある条件を満たすりん議書の回付経路に本部の回付先担当者が含まれていない場合,WFシステムは案件担当者に修正を要求する。
りん議書に対し,処理が求められている案件担当者又は回付先担当者を処理者という。
案件担当者が回付の開始の操作をすると案件ステータスは“回付中”となり,りん議書を修正できなくなる。回付経路に本部の回付先担当者が含まれている場合,WFシステムは,顧客情報と融資期日を本部の回付先担当者に電子メールで通知する。
WFシステムは,回付経路に沿ってりん議書を順次回付し,回付したことを次の処理者に電子メールで通知する。
承認者は,りん議書審査画面でWFシステムに保存されたりん議書を閲覧し,承認又は差戻しの操作をする。承認者が承認の操作をするとWFシステムはりん議書を次の回付先担当者に回付する。差戻しの操作をするとWFシステムは案件担当者にりん議書を差し戻し,案件ステータスは“作成中”に戻り,案件担当者がりん議書を修正することができるようになる。
決裁者は,りん議書審査画面でWFシステムに保存されたりん議書を閲覧し,決裁,却下又は差戻しの操作をする。決裁者が決裁の操作をすると案件ステータスは“決裁”になる。却下の操作をすると案件ステータスは“謝絶”になる。決裁者が差戻しの操作をした場合,WFシステムは承認者が差戻しの操作をした時と同じ処理をする。
りん議書審査画面起動時にはWFシステムが担保評価システムに担保明細の最新情報を問い合わせる。担保評価システムの情報が,③ある条件に該当する場合,WFシステムは承認者が差戻しの操作をした時と同じ処理をする。
(4)アラーム通知機能
WFシステムは,顧客の信用格付の更新があったことや目標期日までの残り日数が3営業日以下になっていることを,処理者に通知する。
顧客の信用格付の更新があったことは,りん議書入力画面及びりん議書審査画面起動時に画面上で通知する。そのために,アラーム通知機能は, a にある最新の信用格付を問い合わせ,WFシステムに保存した案件ファイルの信用格付と比較する。
目標期日までの残り日数が3営業日以下になっていることは,りん議書入力画面及びりん議書審査画面起動時に画面上で通知するだけでなく,日次で処理者に電子メールで通知する。
WFシステムの主要なファイルを表1に示す。
ファイル | 主な属性(下線は主キーを示す) |
案件 | 案件番号,顧客番号,店番,融資希望金額,融資期日,融資期間,資金使途,返済財源,金利,貸出方法,返済方法,信用格付,財務分析番号,案件ステータス |
回付経路 | 案件番号,回付通番,回付先店番,回付先担当者,目標期日 |
案件状況管理 | 案件番号,処理通番,処理者,処理開始日時,処理開始時案件ステータス,処理完了日時,処理完了時案件ステータス,処理者判断,処理者意見 |
店 | 店番,店名,郵便番号,住所,決裁可能金額 |
財務分析 | 財務分析番号,決算年度,財務分析結果 |
担保評価 | 案件番号,担保明細番号,担保評価額,担保物件,評価日 |
〔追加要望への対応〕
Y課長が,WFシステムの設計内容のレビューを融資部に依頼したところ,大規模な顧客では複数の案件のりん議が並行することがあり,その場合はりん議の優先順位を協議するので,同一顧客で進行中の他の案件の内容を参照しやすくしてほしいという追加要望が提示された。
Y課長は追加要望を実現するために,④案件ファイルの当該案件番号を持つレコード以外の該当レコードを抽出する条件を検討した。その上で,該当レコードの案件番号をりん議書入力画面とりん議書審査画面に追加し,案件番号を選択することで必要な案件情報を参照できるようにした。
設問1 本文中の下線①によって,ある業務の一部の作業が不要になる。不要になる作業を30字以内で述べよ。
解答・解説
解答例
りん議書を作成するために複数のシステムを操作する作業
解説
ー
設問2 〔WFシステムの概要〕について,(1)〜(4)に答えよ。
(1)本文中の下線②の条件を表1中のファイル名と属性を用いて40字以内で述べよ。
解答・解説
解答例
案件ファイルの融資希望金額が店ファイルの決裁可能金額を超えている場合
解説
ー
(2)本文中の下線③の条件を表1中のファイル名と属性を用いて40字以内で述べよ。
解答・解説
解答例
担保評価ファイルの評価日より担保評価システムにある評価日が新しい場合
解説
ー
(3)アラーム通知機能によって解決される現状の問題点は二つある。一つは,同一顧客の別案件の調査で確認した延滞発生などによる顧客の信用格付の変化に,案件担当者が即座に気付けないことである。もう一つの問題点を25字以内で述べよ。
解答・解説
解答例
目標期日の到来に気付かず期限を超過すること
解説
ー
(4) a に入れる字句を10字以内で答えよ。
解答・解説
解答例
基幹システム
解説
ー
設問3 〔追加要望への対応〕について,本文中の下線4の条件は三つある。一つは“案件番号が当該案件の案件番号と異なること”である。他の二つの条件を,表1中の案件ファイルの属性を用いてそれぞれ35字以内で述べよ。
解答・解説
解答例
顧客番号が当該案件の顧客番号と同一であること
案件ステータスが“受付”,“作成中”又は“回付中”であること
解説
ー
IPA公開情報
出題趣旨
デジタルトランスフォーメーションの一環としてペーパレス化が進められている。システムアーキテクトには,既存業務のペーパレス化に当たり,業務及び情報システムの両面の課題を分析した上で,要件を定義し最適な処理方式を検討する能力が求められる。
本問では,銀行の融資りん議業務のペーパレス化を実現するために導入するワークフローシステムの新規構築を題材として,現行業務の課題を正しく把握した上で,システム化後の新業務を定義し,処理方式を検討する能力を問う。
採点講評
問 3 では,銀行の融資りん議業務のペーパレス化を実現するワークフローシステム(以下,WF システムという)の新規構築を題材に,現行業務の課題を正しく把握した上でのシステム化後の新業務の定義と処理方式の検討について出題した。全体として正答率は平均的であった。
設問 1 は,正答率がやや低かった。システム全体に影響するアーキテクチャの決定事項に関する問題であったが,一部の業務に限定して解答した受験者が多かった。システムアーキテクトは,情報システム全体を俯瞰して検討する立場であることを認識してほしい。
設問 2(2)は,正答率が低かった。業務要件を踏まえ,WF システムのデータと外部システムである担保評価システムのデータを比較する際のシステム上の判断基準を問う問題であったが,WF システム内のデータ同士を比較している解答や,担保評価システムのデータを判定する条件を明確にしていない解答が多かった。複数のシステムが連携して業務を実現するケースが増えてきており,そのような中でも業務と情報システムの機能及びデータの関係を正確に把握して設計することを心掛けてほしい。