SA午後2 H23-1 複数のシステムに跨ったシステム構造の見直しについて

IPA情報処理試験のSA午後２の論文を過去に書いてみたものです。このレベルの論文を何本か練習して合格しました。あくまで参考までにご覧ください。

SA午後2 H23-1 複数のシステムに跨ったシステム構造の見直しについて

プロジェクトの略称：生命保険会社の口座登録システムの更改

１－１　私が設計に携わったシステムの概要
　Ａ社は、日本全国に約1,000店舗の窓口を運営する生命保険会社である。Ａ社は顧客に保険金の支払を銀行口座に振込することを推奨している。その一環として、一部に保険金については、事前に顧客から口座情報を受領し、その銀行口座に自動で振込するシステム（以下、口座登録システムという）を利用していた。しかし、銀行口座の情報が、保険期間中に変更になった場合等は、銀行口座に正常に振込が出来ない。当問題により、自動で銀行口座に振込した件数が、全保険金の内５割を想定していたのに対して、２割程度に落ち込んでいた。Ａ社経営層は、自動で銀行口座に振込する件数を増加すべく、事前に振込先んの口座を取得、最新化するシステム（以下、口座登録システムという）の開発を決定した。私はＡ社の情報システム部の課長であり、システムアーキテクトとして、口座登録システムの見直しの設計チームのリーダに任命された。
１－２　見直しの対象となった複数システムの概要
　見直しの対象となったシステムは以下の２点である。
①：口座登録システム
　Ａ社が口座登録システムを担当している。顧客は保険契約の締結時にＡ社に口座情報に関する書類を提出している。また、保険期間中に口座情報の変更があった場合もＡ社に提出する必要がある。しかし、顧客が口座情報の変更をＡ社に連絡せいないケースが存在していた。そのため、銀行のシステム（以下銀行システムという）に口座情報が最新化確認するする業務（以下、口座確認業務という）を追加した。口座確認業務で最新化した銀行口座に自動で保険金を振込する業務（以下、自動振込業務という）を実施する。
②：銀行システム
　各銀行を口座情報を一括で１箇所の銀行が銀行システムで管理している。
見直し前は、口座登録システムからの振込データを基に、顧客の口座に振込を行っていた。見直し後は、口座登録システムからの確認データをもとに、顧客の銀行口座が最新確認も実施する。

２－１　業務とシステムの分析
　私は、見直し後に追加した口座登録システムの口座確認業務とシステムを分析した。なぜなら、私は機能やデータの配置などのシステム構造を全体最適の観点より、見直し、機能追加の容易性の確保や変更時の影響範囲の限定が大切であると判断したためである。そのため、私は、以下の２点の観点から業務とシステムを分析した。２－１－１　新たな業務に対応する際の追加機能の傾向
　私は、口座登録システムに追加した口座確認業務の追加内容の傾向を確認した。なぜならば、私は口座確認業務が口座登録システムの他の業務と関連している場合、関連する業務と整合させる必要がると考えたためである。私は、口座登録システムを分析し、口座カ確認業務にて銀行に口座情報の変更有無を確認する点に着眼した。自動振込業務も口座登録システムから銀行システムに振込データを連携し銀行システムにて顧客の銀行口座に振込する。私は、銀行システムにデータを連携する点が共通化の可能性があると判断した。
２－１－２　データの配置や流れ
　私は、口座登録システムのデータの配置内容を確認した。なぜならば、口座確認業務と自動振込業務を共通化する場合に共通化が可能な範囲を確認するためである。確認した結果、銀行システムに連携するデータの項目の内容が自動振込システムと口座登録システムで相違していた。口座確認業務は銀行口座の情報のみである。一方で自動振込システムは振込金額等の詳細な項目が追加で必要であり、差異があった。
２－２　口座登録システムの構造の選定
　私は分析の結果からシステム構造案を２点挙げ、どちらを選択するか検討した。システム構造案は、口座確認業務と自動振込業務の銀行システムへデータを連携するコンポーネントの統合の有無が相違した。２点のシステム構造案のメリットは以下の通りである。①：銀行システムへデータを連携するコンポーネントを統合する案（以下、Ｃ案という）…銀行システムとのデータ連携では、日本国内の銀行において共通の振込のデータ様式（以下、全銀フォーマットという）を利用する。そのため、銀行との認識相違を防止しやすい。また、今後も追加で銀行にデータ連携が必要になった場合も機能追加が用意である。②：銀行システムへデータ連携するコンポーネントを統合しない案…口座確認業務にて銀行システムに不要な項目を削除し連携できる。全銀フォーマットだと口座確認業務では不要な項目もあり、それらの項目の編集が不要になることから、口座確認業務のデータ項目の編集内容が簡易になる。
　２点のシステム構造案のうち、私はコンポーネントを統合する案を採用した。私は、全銀フォーマットを利用することで、今後の機能追加が用意になる点の方が保守性で優位だと考えたからだった。なぜなら、今後も銀行システムを含む他のシステムとのデータ連携が追加になる可能性が高いためである。

３－１　Ｃ案のデメリットについて
　私は、設問イに記載したＣ案のデメリットについて検討した。なぜなら、デメリットが許容できない場合はＣ案を採用できないためである。私は、Ｃ案のデメリットを複数あげ口座登録システムへの影響度合いが大きいデメリットを検討することにした。その結果、私は、今回の見直しの中で一番大きい影響として性能の懸念を検知した。全銀フォーマットにより必須で編集すべき項目が多くなる。現在想定していた設計で処理時間を試算したところ、口座確認業務は１日に実施可能なが時間が10時間であるのに対して、Ｃ案では13時間を要した。私は口座確認業務の時間を短縮する方法を検討した。
３－２　デメリットに対する軽減策
　私は、Ｃ案を採用した場合のデメリットに対する軽減策を検討するため、以下の２作業を実施した。
３－２－１　処理時間を要した原因の確認
私は、改善策を出す前に口座確認業務の処理時間が13時間を要している原因を確認した。なぜなら、処理時間を改善するのであれば、一番時間を要している原因に対して対策するのが、一番効率的なためである。私は、口座確認業務を分割し、分割した業務ごとに要する時間を確認した。その結果、口座確認業務を実施するために要する13時間のうち、6時間は、全銀フォーマットに必要な情報を設定する業務（以下、設定業務という）に要していることが判明した。全銀フォ－マットに設定が必要な項目は、口座登録システムが管理している５種類のマスタテーブルと４種類の業務用のテーブルにある項目であった。全ての項目を最初に取得するため、時間を要しているが原因であった。
３－２－２　処理時間の改善
　私は、設定業務を複数の日付で処理する設計とした。情報の変更がないマスタテーブルと３種類の業務用のテーブルを口座確認業務で最初で統合した。結合した情報をもとに全銀フォーマットに沿って項目を編集することで、設定業務に要していた時間を6時間から2時間に短縮した。その結果、口座確認業務全体の時間を13時間から9時間に短縮し、上限の10時間以内にした。