A collection of notes and resources
K社は生命保険会社で、金融機関の窓口を通じて保険を販売しています。この問題は、紙ベースの保険申込業務を、タブレット端末での電子的な手続(ペーパレス手続)に置き換える、というシステム再構築の話です。保険業務になじみがなくても読めるよう、まず登場する書類と役割を整理します。
提案書と申込書の違い
保険を売る流れには、大きく2段階あります。
つまり「提案書=見積り」「申込書=契約の申込み」という関係です。同じ顧客に同じ商品で提案書を作り直す(保険提案書再作成業務)こともありますが、その場合も元の提案書の内容を引き継いで新しい提案書を作る、という設計になっています。
申込手続に必要な書類
申込書のほかに、重要事項説明書(保険商品の重要な条件の説明)、告知書(健康状態を記載する書類。保険は健康状態によって加入できるかどうかが変わるため、正直に申告してもらう必要がある)、意向確認書(顧客が希望した内容と実際の契約内容が一致しているかを確認する書類)を準備します。これらに顧客が記入・署名し、責任者がチェックした上でK社に郵送され、契約管理システムに入力される、という流れが現行業務です。
ペーパレス手続と申込ステータス
新システムでは、これらの書類をタブレット端末上で電子的に完成させる「ペーパレス手続」が導入されます。ただし顧客の希望によって従来どおりの「書面手続」も選べます。
ここでのポイントは、ペーパレス手続は複数のステップ(申込確認→申込書入力→告知手続→払込方法選択→取扱報告書作成→申込書承認)を順番に進む必要があり、その進み具合を管理するために「申込ステータス」という状態(ステータス)の概念が使われていることです。例えば「申込確認済」→「申込書入力済」→「告知手続済」→「払込方法選択済」→「承認待ち」→「承認済」というように、今どこまで進んでいるかをシステムが把握します。
この「ステータス管理」という考え方は業務システム設計で非常によく出てきます。ある手続きが複数のステップからなり、途中で切り替えや中断が起こりうる場合、「今どの状態か」を明示的にデータとして持つことで、業務ルール(例えば「告知書に署名した後は書面手続に切り替えられない」)をシステムで判定できるようになります。
改ざん検知
電子的に保存する書類(顧客控え書類など)について、後から中身が書き換えられていないかを検証できる仕組みです。紙の書類なら手書き署名やハンコで真正性(本人が確かに合意したという証拠)を担保しますが、電子データではそれができないため、改ざん検知という技術的な仕組みで代替する必要があります。
生命保険会社K社の、保険提案・申込業務の電子化(ペーパレス手続化)を題材にした問題です。提案書(見積り)と申込書(契約申込み)の関係、告知書署名後は書面手続に切り替え不可という業務制約、申込ステータスによる進捗管理、改ざん検知が必要な機能の特定、責任者チェック時間短縮のための機能設計、実績集計の算出ロジックが出題の中心です。設問2・3は表1(新システムの機能概要)の各機能の役割と、申込ステータスの遷移ルールを正確に対応づけて読む力が問われます。
状況設定は要点を要約しています。表1は原文の要点を掲載します。
K社は、代理店や金融機関などを通じて保険商品を販売する大手生命保険会社である。金融機関で顧客に保険商品を販売する際の業務効率化、利便性向上を目的として、保険申込システムを見直し、新たな保険申込システム(新システム)を構築することにした。
〔現在の業務とK社の保険申込システムの概要〕
金融機関窓口の募集人は、K社の保険申込システム(現行システム)を利用して業務を行う。
(1) ニーズ喚起業務: 募集人は取扱いのある保険商品から顧客に最適なプランを提案する。 (2) 保険提案書作成業務: 現行システムに保険条件を入力し、提案書を作成・印刷して顧客に説明する。提案書番号(一意)が付与される。 (3) 保険提案書再作成業務: 同じ顧客・同じ商品で過去に作成した提案書があれば、その保険条件を引き継いで新しい提案書を作成する。K社では①同じ提案書番号で保険条件が異なる印刷物がないようにしている。 (4) 保険申込書作成業務: 印刷済み提案書の提案書番号を入力し、提案書の内容から申込書を作成・印刷する。申込書には提案書番号が記載され、提案書の内容と不整合にならないようにしている。重要事項説明書、告知書、意向確認書も準備する。 (5) 申込手続業務: 申込書等を顧客に提示し、必要事項の記入と署名を依頼する。契約者と被保険者が別人の場合は両者の署名が必要。記入完了後、顧客控え書類を渡す。作成開始から完了までを手続所要時間と呼ぶ。 (6) 申込手続事後業務: 募集人は取扱報告書に記入。責任者が申込書、告知書、意向確認書、取扱報告書を確認・チェックし、問題なければK社に郵送する。 (7) 契約手続業務: K社は郵送された書類を契約管理システムに入力・査定し、保険証券を郵送する。申込書作成開始からK社への書類到着・入力までを申込書到着所要時間と呼ぶ。
〔新システムへの要望〕
〔新システムで実装する機能〕(表1、抜粋)
設問1 〔現在の業務とK社の保険申込システムの概要〕について、本文中の下線①のようにしている理由を業務上の観点から40字以内で述べよ。
設問2 新システムの設計について、(1)~(4)に答えよ。
(1) ペーパレス手続から書面手続に切替え可能な状況にある申込書データの申込ステータスを表1中の字句を用いて全て答えよ。 (2) 改ざん検知を考慮した設計が必要な新システムの機能を、表1中の機能名を用いて全て答えよ。 (3) 本文中の下線②の不備対応時間の短縮を考慮して設計した新システムの機能を表1中の機能名を用いて全て答えよ。また、考慮した内容を20字以内で述べよ。 (4) 本文中の下線③の要望を考慮して設計した新システムの機能を表1中の機能名を用いて答えよ。また、考慮した内容を25字以内で述べよ。
設問3 実績集計機能について、(1)、(2)に答えよ。
(1) 表1中の下線④は、どのような値を算出すればよいか。表1中の機能概要中の字句を用いて40字以内で述べよ。 (2) 表1中の下線⑤は、どのような値を算出すればよいか。表1中の機能概要中の字句を用いて35字以内で述べよ。
設問1 解答例:「申込書と基になった提案書の内容が不整合にならないようにしているから」
概念解説で触れたとおり、提案書は見積り、申込書は契約の申込みで、申込書には提案書番号が記載されます。もし同じ提案書番号なのに保険条件が違う印刷物が複数存在すると、「どの内容で契約するつもりだったのか」が分からなくなってしまいます。本文にも「申込書には提案書番号が記載されており、申込書の基になった提案書の内容と不整合にならないようにしている」と、ほぼそのままの表現があります。設問文をよく読むと解答の骨格が本文にすでに書かれているタイプの設問です。
設問2(1) 解答例:「“ペーパレス手続選択済”、“申込確認済”、“申込書入力済”」
要望に「告知書に署名した後は、切り替えられないようにしてほしい」とあります。つまり告知書に署名する前、すなわち「告知手続済」になる前の各ステータスでは切替え可能ということです。申込ステータスの遷移順は、ペーパレス手続選択済→申込確認済→申込書入力済→告知手続済→…なので、告知手続済より前の3つのステータスが答えになります。ステータスの遷移順を正しく把握できているかがポイントです。
設問2(2) 解答例:「申込書入力、告知手続」
改ざん検知が必要なのは「顧客控え書類」に対してです。要望に「保存する電子書類の真正性を確保するために、顧客控え書類に改ざん検知の仕組みを導入してほしい」とあります。表1を見ると、顧客控え用の書類を作成しているのは「申込書入力」(顧客控え用の申込書を作成)と「告知手続」(顧客控え用の告知書を作成)の2機能だけなので、この2つが対象です。
設問2(3) 解答例: 機能名「申込確認、申込書入力、告知手続、取扱報告書作成」、内容「入力内容をチェックすること」
「不備対応時間の短縮」というのは、そもそも「不備」が発生しなければ対応時間もゼロになる、という発想です。表1の各機能に共通して「入力する際に入力内容をチェックし、誤りがある場合は画面にその内容を表示する」という記述があります。入力の時点で誤りをその場で本人に直させることができれば、後から責任者が書類をチェックして不備を見つけて差し戻す、という手間自体が減ります。「後工程でのチェックを減らすために前工程でエラーを防ぐ」という設計思想です。
設問2(4) 解答例: 機能名「ペーパレス手続メニュー」、内容「次に実施すべき作業メニューだけ活性化すること」
「手続の順番を把握できるようにしてほしい」という要望に対応する機能は、表1のペーパレス手続メニューです。「次に実施すべき作業メニューだけ活性化する」ということは、それ以外のメニューは押せない(グレーアウトなどになる)ということなので、募集人は自然と「今どれをやればいいか」が分かります。ステータス管理の仕組みを、UI上の「次にやるべきことの提示」に変換している、という設計です。
設問3(1) 解答例:「払込方法選択日時が当月である申込書データの、払込方法選択日時と申込日時の差」
「手続所要時間」は本文の定義で「申込書を作成開始してから申込手続業務を完了するまでの時間」です。ペーパレス手続では、申込手続業務の完了は「払込方法選択」の完了に相当します(払込方法選択後は取扱報告書作成に進むため)。開始時点は申込書データの登録時、つまり「申込日時」です。よって「払込方法選択日時 − 申込日時」を、当月に払込方法選択が完了したデータについて計算し平均する、という設計になります。
設問3(2) 解答例:「連携日時が当月である申込書データの、連携日時と申込日時の差」
「申込書到着所要時間」は本文の定義で「申込書作成開始からK社へ書類一式が到着し契約管理システムに入力するまでの時間」です。ペーパレス手続では、これに相当するのは「申込書データ連携」の完了(連携日時)です。開始時点は同じく申込日時なので、「連携日時 − 申込日時」を、当月に連携が完了したデータについて平均します。設問3(1)・(2)は、業務上の定義(所要時間の始点・終点)を、システムの機能名・日時項目に正しく対応づけられるかを問うており、採点講評では正答率が低かったと指摘されています。現行業務の「手続所要時間」「申込書到着所要時間」の定義を、新システムのどのステータス変化に対応させるかを丁寧に追う必要があります。