システムアーキテクト試験 2022年 午後1 問03

模範解答

解説

解答の論理構成

1. 問題文の事実確認
   • 現行システムの保険提案書再作成業務では「①同じ提案書番号で保険条件が異なる印刷物がないようにしている。」
   • 保険申込書作成業務では「申込書には提案書番号が記載されており、申込書の基になった提案書の内容と不整合にならないようにしている。」
2. 提案書番号の役割
   • 提案書番号は提案フェーズから申込フェーズまで一貫して利用される識別子。
   • 異なる保険条件の印刷物が同一番号で存在すると、後続の申込書や告知書と内容照合できずリスクが生じる。
3. 業務上の影響
   • 顧客説明・契約成立後の苦情対応、監査対応で整合性が取れないとコンプライアンス違反。
   • 不整合防止こそが番号重複を禁じる直接の理由であり、設問の答えとなる。

誤りやすいポイント

• 「番号重複＝システム障害防止」とだけ捉え、後続書類の整合性という業務的視点を漏らす。
• 「同じ顧客・同じ商品だから番号を変えない」と誤読し、再作成後の新番号付与ルールを見逃す。
• 設問が求めるのは“理由”であり、“方法”や“仕組み”を説明してしまう。

FAQ

模範解答

解説

模範解答

解説

解答の論理構成

1. 書面切替え可否条件の読み取り
   • 【問題文】「…手続の途中でも書面手続に切り替えられるようにしたいが、告知書に署名した後は、切り替えられないようにしてほしい。」 ⇒ 告知書署名前までが対象。
2. 告知書署名に対応するステータスの特定
   • 表1「告知手続」の説明に「告知手続の完了後、…申込ステータスを"告知手続完了"とする。」
     ⇒ “告知手続完了” 以降は切替え不可。
3. 告知手続開始までに到達するステータスを抽出
   • 表1の流れ
     ① “ペーパレス手続選択済”
     ② “申込確認済”
     ③ “申込書入力済”
     ④ “告知手続完了”
   • ①〜③はいずれも告知書署名前。
4. 申込ステータスを正確に列挙
   ⇒ “ペーパレス手続選択済”，“申込確認済”，“申込書入力済”。

誤りやすいポイント

• “告知手続完了” を含めてしまう。告知書署名後なので条件外です。
• “払込方法選択済” 以降を選ぶミス。これらは告知完了後の工程です。
• ステータス名を略記・誤記する。設問は「表1中の字句を用いて」と明示しています。

FAQ

模範解答

解説

解答の論理構成

1. 改ざん検知が要求される対象を特定
   • 要望より引用：
     「顧客控え書類に改ざん検知の仕組みを導入してほしい。」
     ⇒ 改ざん検知は“顧客控え書類”に対してのみ必要。
2. 顧客控え書類を生成する機能を抽出
   • 表1「申込書入力」：
     「署名完了後、顧客控え用の申込書を作成、保存する。」
   • 表1「告知手続」：
     「署名完了後、顧客控え用の告知書を作成、保存する。」
3. 他機能の確認
   • 「書類印刷」は既存の電子書面を出力するだけで新規作成しない。
   • 「取扱報告書作成」は“顧客控え”の記載がなく内部向け。
     よって改ざん検知を要する機能は該当せず。
4. 結論
   改ざん検知を考慮した設計が必要なのは「申込書入力」「告知手続」で確定。

誤りやすいポイント

• 「書類印刷」が関係すると勘違いする
  ⇒ 印刷のみで電子保存を行わないので対象外。
• 「取扱報告書作成」も署名が絡むので必要と思い込む
  ⇒ 顧客控え書類ではなく、改ざん検知要件が記載されていない。
• “電子書類＝すべて改ざん検知”と短絡的に考える
  ⇒ 要件範囲（顧客控え書類）を読まないと誤答。

FAQ

模範解答

解説

解答の論理構成

1. 要望の確認
   • 新システムへの要望では「②その不備対応の時間を短縮したい。」と示されています。
2. 不備発生の主原因
   • 手入力ミスや確認漏れが原因で書類に不備が残ると責任者チェック後に差戻しが発生し時間を浪費します。
3. 機能仕様の照合
   • 表1「申込確認」：
     「顧客が確認をして入力できるようにする。入力時に入力内容をチェックし、確認漏れがある場合は画面に表示する。」
   • 表1「申込書入力」：
     「入力時に入力内容をチェックし、誤りがある場合は、画面にその内容を表示する。」
   • 表1「告知手続」：
     「入力時に入力内容をチェックし、誤りがある場合は、画面にその内容を表示する。」
   • 表1「取扱報告書作成」：
     「入力時に入力内容をチェックし、誤りがある場合は、画面にその内容を表示する。」
4. 不備削減メカニズム
   • すべての入力画面で即時バリデーションを実施し誤りをその場で修正できるため，後工程での差戻しが激減→「不備対応時間の短縮」を達成します。
5. 以上より，列挙すべき機能名と20字以内の内容は「入力内容をチェックすること」と結論づけられます。

誤りやすいポイント

• 「書類印刷」や「申込書承認」にも品質向上効果があると誤解し列挙してしまう。入力チェックが記載されていないため不正解です。
• 要件「②」を“責任者承認機能”と短絡し，「申込書承認」だけを書いてしまう。根本的な不備発生箇所（入力段階）に注目できていないミスです。
• 20字以内の考慮内容を長文で書き減点される。

FAQ

模範解答

解説

解答の論理構成

1. 下線③の要望確認
   • 【問題文】に「③手続を円滑に進めるために募集人が手続の順番を把握できるようにしてほしい。」と記載。
   • 必要機能：募集人が今どの工程かを視覚的に認識できる仕組み。
2. 表1で該当する機能を探索
   • 「ペーパレス手続メニュー」の説明に「・ペーパレス手続が選択された申込書データに対して、実施すべき作業のメニューを画面に表示する。」
   • 同じ箇所で「・次に実施すべき作業メニューだけ活性化する。」と明記。
3. 要望との整合
   • 活性化済みメニューは「次に行う工程」を示すため、募集人は自然に手続の順番を把握でき、要望③を満たす。
4. したがって
   • 解答は機能名「ペーパレス手続メニュー」。
   • 考慮内容は25字以内で「次に実施すべき作業メニューだけ活性化すること」。

誤りやすいポイント

• 「申込ステータス表示」で答えてしまう
  →ステータスは状況を示すだけで“順番のガイド”とは別。
• 「書類印刷」や「申込確認」など、画面を伴う他機能を選択
  →表1本文に「順番」や「活性化」の記述がない。
• 考慮内容で「手続の順番を把握」など問題文をそのまま引用
  →25字以内にまとめられず減点対象。

FAQ

模範解答

解説

解答の論理構成

1. 開始時刻の特定
   【問題文】「申込書作成 … 申込書データの申込日付を登録し、申込日付を登録した際の日時を示す。」
   ここで“申込日付”が申込手続開始時刻となる。
2. 完了時刻の特定
   【問題文】「払込方法選択 … 払込方法選択の完了後、申込書データの払込方法選択日時を完了した際の日時に…」
   “払込方法選択日時”が申込手続完了時刻となる。
3. 手続所要時間の定義
   【問題文】「申込書を作成開始してから申込手続業務を完了するまでの時間を手続所要時間と呼ぶ。」
   よって手続所要時間＝払込方法選択日時−申込日付。
4. 当月条件の付加
   【問題文】「④当月に申込手続業務が完了した申込の手続所要時間…を収集」
   完了判定の基準となる“払込方法選択日時”が当月に含まれる申込書データを抽出する。
5. 以上より算出対象は
   「払込方法選択日時が当月の申込書データの，払込方法選択日時と申込日付の差」

誤りやすいポイント

• 完了時刻を“告知手続完了日時”や“取扱報告書作成日時”と勘違いする
• 開始時刻を“申込確認日時”や“申込書入力日時”と取り違える
• 「当月」の判定を“申込日付”で行ってしまう
• 機能概要にない語句（例：開始日時）を使ってしまい減点される

FAQ

模範解答

解説

解答の論理構成

1. 対象データの特定
   • 【問題文】表1「申込書データ連携」に「連携後、申込書データの連携日時を連携した際の日時にする」とあり，連携が完了した時点を示すタイムスタンプが取得できます。
2. 差を取る２つの時刻
   • 同じく表1「申込書作成」に「申込日付を登録し、申込日付を登録した際の日時を示す」と明示され，申込開始時点の時刻も保持できます。
3. 実績集計で求める指標
   • 【問題文】表1「実績集計」に「②当月に契約管理システムに連携が完了した申込の申込書到着所要時間」を収集とあるため，当月かつ連携完了済みのレコードに限定し，(連携日時 − 申込日時) を算出することが要件となります。

誤りやすいポイント

• 「告知手続完了日時」や「承認日時」と取り違え，誤った差分を計算してしまう。
• 当月判定を「申込日時」ではなく「連携日時」で行う必要がある点を見落とす。
• ペーパレス限定指標④と混同し，書面手続データまで含めて集計してしまう。

FAQ