契約単位で組まれた処理が、商品をまたぐ確認から抜け落ちる
契約管理は契約単位で処理とデータが組まれるため、商品や特約をまたぐ組み合わせの確認が観点から抜け、加入の条件によっては支払額の計算が狂います。
GENZ, Inc.
開発を担わない
保険基幹システム更改を
開発を担わない
保険基幹システム更改を支払まで見届ける第三者検証
契約管理から保険金支払、代理店の手数料、財務への反映まで、業務の流れに沿って検証の範囲を設計します。開発とは別の立場で、上程と監査に示せる記録を残します。
支援事例
支援実績5,000件以上
保険基幹システムのテストで見落としが生まれる理由
保険基幹システムは、契約管理・保険金支払・代理店手数料・財務管理が契約単位で連なって動きます。一部分だけを確認するテストでは見落としが残り、更改や改修のたびに同じ箇所で不具合が表に出ます。
契約単位で
レガシー資産の仕様が文書に残らず、確認すべき箇所を導けない
改修を重ねたシステムは内部仕様が文書に残らず、商品と特約のどの組み合わせを確かめるべきかが担当者の記憶に委ねられ、確認すべき箇所を導けません。
保険金支払の例外処理が、正常系の裏に置かれたまま残る
保険金支払では二重払いや支払期限の超過といった例外処理が正常系の裏に隠れ、本番で誤った金額が出力され、照会対応と訂正処理が同時に発生します。
代理店手数料と財務の突き合わせが目視のまま積み上がる
代理店の手数料と財務への反映を突き合わせる作業が目視にとどまり、件数が増えるほど差異の見逃しが積み上がり、決算処理の手戻りとして表に出ます。
制度改定への対応ごとに、回帰テストの範囲がぶれる
商品改定のたびに回帰テストの範囲を経験則で決めるため、回を追うごとに範囲がぶれ、前回通っていた処理が壊れたことに稼働後まで気づけません。
見落としが本番で表に出たときに何が起きるか
更改や改修で残った見落としは、本番で支払・計算・連携の誤りとして表に出ます。ここでは、誤りが起きたときに社内で何が起きるかを整理します。
保険基幹システムのテストを第三者が点検する観点
保険基幹システムは契約単位で処理とデータが構成され、支払や手数料計算、財務への反映が連続して動きます。第三者が点検する際は、開発主体とは別の立場から、契約の流れに沿った観点で検証の抜けを洗い出します。
確認すべき商品と特約の組み合わせが抜けたままリリースすると、特定の契約条件で処理が誤り、契約者への通知や支払に影響が出るおそれがあります。
契約の状態遷移を、商品と特約の組み合わせで洗い出す
契約の新規・変更・失効という状態の遷移を、商品と特約の組み合わせごとに洗い出します。内部仕様が文書に残らない場合でも、遷移の観点から確認すべき組み合わせを並べ、記憶に依存しない観点を作ります。
確認する資料
- 状態遷移表
- 組合せ一覧
- 観点一覧
支払の判定分岐に抜けがあると、支払うべき保険金が支払われない、または過払いが生じ、照会対応と訂正処理の費用が短期のコスト増として現れます。
保険金支払の判定分岐を、約款の条件に沿ってたどる
保険金と給付金の支払は、約款の条件で判定が分かれます。支払事由の成立と不成立、免責、支払額の計算という分岐をたどり、判定ごとに確認するケースを定めます。抜けは支払の誤りとして本番に出ます。
確認する資料
- 判定分岐表
- 支払条件表
- 計算確認表
画面と基幹データの食い違いを見落とすと、代理店の手数料照会や契約者の手続き結果が誤って表示され、代理店と契約者からの信頼を損ないます。
代理店と契約者の画面と、基幹側データの整合を確かめる
代理店向け画面での申込入力や手数料の照会、契約者向け画面からの手続きが、基幹側の契約データへ反映されるかを確かめます。画面の表示と基幹のデータが食い違うと、代理店や契約者の照会が増えます。
確認する資料
- 連携確認表
- 照合結果表
- 画面遷移表
基盤移行の影響範囲を絞る根拠がないまま進むと、対象から外れた処理で挙動のずれが起き、原因の切り分けが完了するまで暫定運用が長引きます。
仕様が変わらない基盤の移行でも、影響する範囲を見る
稼働基盤をクラウドへ移す更改など機能仕様が変わらない変更でも、環境が変わる範囲を洗い出して回帰の対象を決めます。全機能を対象にすれば工数が収まりません。影響が及ぶ処理に絞り、根拠を残します。
確認する資料
- 影響範囲表
- 回帰対象表
- 環境差分表
検証記録が揃っていないと、監査や会議体への報告のたびに整理作業が発生し、実施した検証の妥当性を説明できず、リリース判断が保留されます。
実施した検証が、求めに応じて説明できる形で残っているかを見る
検証の内容が個人の作業記録にしか残っていないと、監査や会議体への説明のたびに整理の作業が生じます。テスト範囲、実施結果、不具合の扱い、承認の経緯を統一した様式で残し、提示できる状態にします。
確認する資料
- テスト計画書
- 実施記録
- 不具合管理表
- 承認記録
保険基幹システムのテストを外部に任せる進め方
ベンダーの自社検証と重ならない発注側の検証として、範囲をどう決め、記録をどう残すかを整理し、稟議で説明できる材料を揃えます。
STEP 01
現行の仕様と改修範囲の読み合わせ文書に残らない仕様は稼働中の画面で確かめる
どう確かめるか
開発の進行に伴走してテストの体制を組み立てる
設計の変更が出るたびにテストの担当範囲を見直し、ベンダーの自社検証と発注側の検証の重なりをどちらが担うかを文書で決めます。二重の支払いと見なされない根拠を工程の早い段階で作ります。
- 01現行の契約管理の機能構成とデータの保持の仕組みを棚卸しする
- 02更改後のスコープと既存契約への影響範囲を切り分ける
- 03仕様書に残らない部分を稼働中の環境の動作で確認する
OUTPUTテスト範囲の合意書
STEP 02
テスト計画と確認する観点の設計層ごとの担当と合否の基準を先に決める
どう確かめるか
大規模な機能の範囲を抜けなく洗い出して確認する
契約単位で処理とデータが構成される前提を崩さずに、商品や特約の追加が既存契約へ及ぼす影響を洗い出します。文書に残らないレガシー仕様は稼働中の動作で補い、回帰の対象を抜けなく決めます。
- 01テストの層ごとの担当と範囲、合否基準を文書化する
- 02業務の流れに沿った受け入れテストのシナリオを設計する
- 03クラウド移行など環境が変わる範囲の回帰対象を決める
OUTPUT不具合の追跡台帳
STEP 03
テストの実施と不具合の追跡不具合の原因切り分けを主体別に並行して進める
どう確かめるか
発注する側の立場でテストの進行を取り仕切る
テストの層ごとの担当と範囲、合否の基準、不具合の扱いを、発注側の判断として文書化します。範囲の合意が抽象語のまま進み、後工程で担当の空白が見つかる事態を防ぎます。
- 01契約の新規・変更・失効から支払、手数料計算までを検証する
- 02不具合を業務条件と環境、実装の別に切り分けて追跡する
- 03修正の優先順位を業務への影響の大きさで並べ替える
OUTPUT受け入れ判断用の報告書
STEP 04
受け入れ判断に向けた報告と引き継ぎ残存不具合の業務影響を判断材料へまとめる
どう確かめるか
監査と社内への説明にそのまま使える記録を残す
実施した検証の内容と承認の経緯を、担当者の作業記録ではなく提示できる形で残します。システム監査や会議体への報告のたびに、整理作業をやり直さずに済む状態を作ります。
- 01実施済みと未実施の範囲、残存不具合を報告書にまとめる
- 02リリース可否を諮る会議体向けに業務の言葉で説明する
- 03検証記録を監査に提示できる形式にまとめて引き継ぐ
OUTPUT監査に提示できる検証記録
保険業務の領域ごとに求められる検証の違い
固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。
OUTSOURCING RATIONALE
THIRD-PARTY VERIFICATION
01
必要な時に必要な分だけ
人日単位のアサインで固定費を抱えず、繁忙期に増減できます。
02
独立した視点で品質を底上げ
独立した検証で偏りを排し、監査に使える客観的な記録を残せます。
03
専門ノウハウを即戦力で
JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。
専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット
- 契約単位で構成される商品と特約の組み合わせを網羅できる
- 保険金支払の査定分岐と計算結果を業務の流れで検証できる
- 代理店の成績と手数料計算まで基幹内で連続して確認できる
- 契約者向け画面と基幹の連携を手続き単位で通して確かめられる
テストを任せる相手を選ぶときに確かめたい点
検証を外部に任せるとき、比較の軸は価格や規模だけでは足りません。保険基幹システムの検証では、業務への理解の深さと、開発から独立した立場で動けるかが結果を分けます。発注前に確かめたい点を整理します。
保険業務の用語と帳票を前提に話が進むか
契約・査定・手数料といった用語の説明から始めなくて済む相手かを確かめます。業務の前提が共有できれば、観点の洗い出しから任せられます。
契約管理と保険金支払の双方をたどれるか
契約の新規・変更から保険金支払の分岐まで、業務の連なりに沿って検証範囲を設計できるかを確かめます。機能単位の確認では空白が残ります。
発注する側に代わって進行を管理できるか
開発と並行して検証を進める体制と、計画・進捗・不具合の管理を発注側に代わって担えるかを確かめます。繁忙期に左右されない進行が必要です。
検証の成果を文書として受け取れるか
テスト計画から結果の記録まで、上程や監査にそのまま提示できる文書として受け取れるかを確かめます。材料を改めて集める作業がなくなります。
お問合せから検証を開始するまでの流れ
ご依頼前に、対象の業務範囲と改修の日程、社内で残す作業を共有いただくところから始めます。
お問合せと抱えている課題の共有
対象システムの範囲、改修の日程、懸案をお聞きします。
検証の範囲と体制のすり合わせ
社内で残す作業との切り分けと、検証の体制を合わせます。
お見積のご提示とご契約の締結
合意した範囲と体制にもとづき、お見積のご提示とご契約へ進みます。
テストの準備と検証作業の開始
業務条件を確認し、テスト計画を立てて着手します。
ご相談・お見積のご依頼はこちらから
保険基幹システムのテスト体制について相談する
テストの範囲と優先順位、必要工数の考え方、関連テストの要否まで、開発を担わない立場で整理してご提示します。更改の日程が決まる前の段階からでもご相談いただけます。