令和4年度 春期 システムアーキテクト試験 午後I問題 問3 生命保険の窓口販売におけるタブレットを活用したペーパーレス申込手続の設計

業務上の理由

本文〔現在の業務とK社の保険申込システムの概要〕の (4) 保険申込書作成業務 には、以下の記載があります。

• 「申込書には提案書番号が記載されており，申込書の基になった提案書の内容と不整合にならないようにしている。」

募集人が同じ顧客に過去の提案書を利用して新たな提案書を再作成する場合、保険条件を変更して再作成します。もしこのとき、同じ提案書番号 で 異なる保険条件 の提案書が印刷されてしまうと、その提案書番号を用いて申込書を作成した際に、どちらの保険条件に基づくものかシステム上や手続上で区別できなくなります。
その結果、申込書の内容と、実際に顧客に提示した（基になった）提案書の内容との間に 不整合 が生じるリスクが発生します。これを防ぐために、同じ提案書番号で保険条件が異なる印刷物が存在しないように制限しています。

高得点のポイント

• 申込書と提案書の内容の不整合 を防ぐという目的が明記されていること。
• 指定された40字以内で、簡潔かつ論理的に理由がまとめられていること。

書面手続への切替え条件

本文〔新システムへの要望〕の2番目の項目に、ペーパーレス手続から書面手続への切り替えに関する以下の条件が記載されています。

• 「ペーパーレス手続の場合，手続の途中でも書面手続に切り替えられるようにしたいが，告知書に署名した後 は，切り替えられないようにしてほしい。」

この条件から、書面手続への切り替えが可能なのは、告知書に署名する前 の状態であることがわかります。

該当する申込ステータスの特定

表1「新システムの機能概要」を確認し、ペーパーレス手続が選択されてから告知書に署名するまでの機能と、それに対応する 申込ステータス を特定します。

1. 申込書作成: ペーパーレス手続が選択されると、申込ステータスは “ペーパレス手続選択済” となります。
2. 申込確認: 申込確認が完了すると、申込ステータスは “申込確認済” となります。
3. 申込書入力: 申込書の内容を確認し署名が完了すると、申込ステータスは “申込書入力済” となります。
4. 告知手続: 告知内容を確認し署名が完了すると、申込ステータスは “告知手続済” となります。

告知書への署名が行われるのは「告知手続」機能の中です。したがって、切り替えが不可能なのは“告知手続済”以降であり、切り替え可能な状況にあるのは、それよりも前の段階である “ペーパレス手続選択済”、“申込確認済”、“申込書入力済” の3つのステータスです。

高得点のポイント

• 表1に記載されている正確な字句を使用していること。
• 該当する3つのステータスを過不足なく全て挙げていること。

改ざん検知が必要な対象

本文〔新システムへの要望〕の3つ目の項目に、以下の記載があります。

• 「電子書類のうち顧客控え書類は，申込手続完了後に募集人が印刷して，顧客に手渡しする。」
• 「保存する電子書類の真正性を確保するために，顧客控え書類 に 改ざん検知の仕組み を導入してほしい。」

この要望から、改ざん検知の仕組みが必要となるのは、システム上で 顧客控え用の書類 を作成し、保存する機能であると分かります。

該当する機能の特定

表1「新システムの機能概要」から、顧客控え用の書類を作成して保存している機能を探します。

• 申込書入力: 「署名完了後，顧客控え用の申込書を作成し，保存する。」と記載されています。
• 告知手続: 「署名完了後，顧客控え用の告知書を作成し，保存する。」と記載されています。

その他の機能では、電子書類の作成や表示（例：提案書作成）はあっても、顧客控え書類の作成・保存は行われていません。したがって、改ざん検知を考慮した設計が必要な機能は 申込書入力 と 告知手続 の2つです。

高得点のポイント

• 要望と機能概要を正しく結びつけ、対象となる書類を特定できていること。
• 表1に記載されている機能名（「申込書入力」「告知手続」）を過不足なく解答していること。

不備対応に関する要望と現状の業務

本文中の下線②「その不備対応の時間を短縮したい」は、〔新システムへの要望〕の5つ目の項目にあります。

• 「責任者 が書類の記載内容をチェックして不備があった場合，対応に時間が掛かっているので，②その不備対応の時間を短縮したい。」

現行業務の「(6) 申込手続事後業務」を確認すると、責任者がチェックする対象の書類は以下の4点です。

1. 申込書
2. 告知書
3. 意向確認書
4. 取扱報告書

該当する機能の特定

新システムにおいて、不備対応の時間を短縮するためには、これらの書類に相当するデータを入力する段階でシステムによるチェックを行い、不備を未然に防ぐ必要があります。表1「新システムの機能概要」から、これらの書類に関わる入力機能を探します。

• 申込確認: 意向確認などの説明に対する確認を入力する際、「入力内容をチェックし，確認漏れがある場合は画面に表示する。」
• 申込書入力: 申込書に必要な内容を入力する際、「入力内容をチェックし，誤りがある場合は，画面にその内容を表示する。」
• 告知手続: 告知書に必要な内容を入力する際、「入力内容をチェックし，誤りがある場合は，画面にその内容を表示する。」
• 取扱報告書作成: 取扱報告書データを登録する際、「入力内容をチェックし，誤りがある場合は，画面にその内容を表示する。」

なお、「提案書作成」でも入力チェックが行われますが、提案書は責任者のチェック対象書類に含まれていないため除外されます。したがって、該当する機能は 申込確認、申込書入力、告知手続、取扱報告書作成 の4つです。

高得点のポイント

• 責任者が確認する書類を現行業務から正しく特定できていること。
• それらに対応する新システムの機能名を、表1から過不足なく抜き出せていること。

不備対応の短縮を実現する仕組み

前半で特定した4つの機能（申込確認、申込書入力、告知手続、取扱報告書作成）の機能概要には、共通して以下のような処理が記述されています。

• 「入力する際に 入力内容をチェックし，誤り（または確認漏れ）がある場合は，画面にその内容を表示する。」

従来の業務では、手続後に責任者が書類をチェックして初めて不備が発覚し、その対応に時間がかかっていました。新システムでは、データをシステムに入力する時点（入力時）でシステムが自動的に 入力内容をチェックする ように設計することで、不備のある状態での登録を防ぎ、事後の不備対応にかかる時間を大幅に短縮しています。

高得点のポイント

• 表1の機能概要に共通する「入力内容のチェック」という具体的な考慮内容を捉えられていること。
• 指定された20字以内で簡潔にまとめられていること。

手続の順番を把握するための要望

本文中の下線③は、〔新システムへの要望〕の10番目の項目に記載されています。

• 「③手続を円滑に進めるために募集人が 手続の順番を把握できる ようにしてほしい。」

ペーパーレス手続では、画面上で複数のステップを順番に進めていく必要があります。そのため、システム側で現在の進行状況に合わせて、次に実施すべき手続を募集人に明示する機能が求められています。

該当する機能の特定

表1「新システムの機能概要」の中で、手続の順番やナビゲーションに関する記述を探します。

• ペーパレス手続メニュー: 機能概要に「実施する作業のメニューを画面に表示する。次に実施すべき作業メニューだけ活性化する。」と記載されています。

この機能により、募集人は次にどのメニューを選択すればよいかが視覚的に分かり、手続の順番に迷うことなく円滑に業務を進めることができます。したがって、この要望に対応して設計された機能は ペーパレス手続メニュー です。

高得点のポイント

• 要望の内容（順番の把握）と合致する機能を、表1の機能概要から正しく見つけ出せていること。

考慮した具体的な設計内容

前半で特定した「ペーパレス手続メニュー」の機能概要において、募集人に手続の順番を把握させるためにどのような工夫が組み込まれているかを確認します。

表1には以下のように記述されています。

• 「次に実施すべき作業メニューだけ活性化する。」

不要なメニューやまだ実施できないメニューを非活性（選択不可）にし、直ちに行うべき操作のみを活性化（選択可能）することで、システムが自然に次の手続へと誘導します。これが、手続の順番を把握させるために考慮された具体的な設計内容です。

高得点のポイント

• 表1の機能概要に記載されている「次に実施すべき作業メニューだけ活性化する」という仕組みを抜き出し、または要約して解答に含めていること。
• 指定された25字以内で適切に記述されていること。

「手続所要時間」の定義

現行業務の「(5) 申込手続業務」の最後に、手続所要時間の定義が以下のように記載されています。

• 「申込書を作成開始 してから 申込手続業務を完了 するまでの時間を手続所要時間と呼ぶ。」

算出に用いる日時の特定

新システムにおいて、「申込書の作成開始」と「申込手続業務の完了」がどの日時に該当するかを表1から特定します。

1. 開始日時（申込書を作成開始）:
   表1の「申込書作成」機能に「登録した際，申込書データの 申込日時 を登録した際の日時にする。」とあります。

2. 完了日時（申込手続業務を完了）:
   現行業務の(5)を読むと、申込手続業務の最後の作業は「保険料の口座振替依頼書の記入を依頼して記入内容を確認する」ことです。ペーパーレス手続では、これが表1の「払込方法選択」機能に該当します。この機能では「完了後，申込書データの 払込方法選択日時 を完了した際の日時にし」とあります。

したがって、手続所要時間は 「払込方法選択日時」 と 「申込日時」 の差を計算することで求められます。

対象データの絞り込み条件

下線④には「当月に 申込手続業務が完了した申込」と指定されています。業務の完了日時は「払込方法選択日時」であるため、集計対象となるデータは 「払込方法選択日時が当月である申込書データ」 となります。

以上をまとめると、「払込方法選択日時が当月である申込書データの、払込方法選択日時と申込日時の差」を算出することになります。

高得点のポイント

• 手続の開始日時（申込日時）と完了日時（払込方法選択日時）を正しく特定し、その「差」を求めると記述していること。
• 集計対象が「払込方法選択日時が当月である」データに限定されていることを論理的に示していること。

「申込書到着所要時間」の定義

現行業務の「(7) 契約手続業務」に、申込書到着所要時間の定義が以下のように記載されています。

• 「申込書を作成開始 してからK社へ書類一式が到着し，契約管理システムに入力する までの時間を申込書到着所要時間と呼ぶ。」

新システムでの対応業務と日時の特定

ペーパーレス手続においては、物理的な書類の郵送と手入力が不要になります。本文の〔新システムへの要望〕の7番目の項目には「ペーパーレス手続の場合，（中略）申込書の内容をデータとイメージファイルの両方で 契約管理システムに連携してほしい。」とあり、これがシステム入力の代わりとなります。

これを踏まえ、表1から該当する日時を特定します。

1. 開始日時（申込書を作成開始）:
   設問3(1)と同様、表1の「申込書作成」機能で登録される 「申込日時」 です。

2. 完了日時（契約管理システムに連携）:
   表1の「申込書データ連携」機能に「連携後，申込書データの 連携日時 を連携した際の日時にする。」とあります。

したがって、申込書到着所要時間は 「連携日時」 と 「申込日時」 の差として算出できます。

対象データの絞り込み条件

下線⑤には「当月に 契約管理システムに連携が完了した申込」と指定されています。連携が完了した日時は「連携日時」であるため、集計対象となるデータは 「連携日時が当月である申込書データ」 となります。

以上をまとめると、「連携日時が当月である申込書データの、連携日時と申込日時の差」を算出することになります。

高得点のポイント

• ペーパーレス手続における書面到着・入力の代替が「システムへの連携」であることを理解し、完了日時（連携日時）と開始日時（申込日時）の「差」を求めると記述していること。
• 集計対象が「連携日時が当月である」データに限定されていることを論理的に示していること。