GENZ, Inc.

公開判断の根拠を残す 保険代理店アプリの品質を、開発とは別の目で確かめる

保険代理店アプリの公開前の確認を、開発ベンダーとは別の立場で担います。確認した範囲と結果は第三者が読める記録として残し、公開判断の材料にそのまま使えます。

支援事例

支援実績5,000件以上

支援実績を示す企業ロゴ 01
支援実績を示す企業ロゴ 02
支援実績を示す企業ロゴ 03
支援実績を示す企業ロゴ 04
支援実績を示す企業ロゴ 05
支援実績を示す企業ロゴ 06
支援実績を示す企業ロゴ 07
支援実績を示す企業ロゴ 08
支援実績を示す企業ロゴ 09
支援実績を示す企業ロゴ 10
支援実績を示す企業ロゴ 11
支援実績を示す企業ロゴ 12
支援実績を示す企業ロゴ 13

この記事はソフトウェアテストの専門家が監修しています

監修枡井 愼治株式会社GENZ 代表取締役

GENZは創業以来、5,000件以上のソフトウェアテスト・第三者検証を手がけてきたプロフェッショナルです。品質に関する課題やお悩みに、真摯に寄り添います。

代表取締役 枡井 愼治 株式会社GENZ 〒101-0062 東京都千代田区神田駿河台2-3-11 ヒューリック御茶ノ水ビル3F TEL:03-5244-4711
01 ISSUES

保険代理店アプリの開発で、確認が抜けやすいところ

保険代理店アプリは、募集人向けと契約者向けで画面が分かれ、扱う保険会社と商品の組み合わせも増えていきます。限られた受け入れ期間で全体を見きれず、確認の抜けが公開後の問合せとして返ってくる箇所を整理します。

募集人向けと契約者向けで画面が分かれ、確認する範囲が広がる

募集人向けの面談記録の登録と、契約者向けの契約一覧や証券の取り込みで画面が分かれます。片側だけの確認では、もう片側の表示崩れを見落とします。

対象画面の範囲

複数の保険会社の商品を扱うため、表示の組み合わせが増える

種別をまたぐ契約を管理するアプリでは、保険会社ごとに商品データの様式が異なります。組み合わせが増えるほど、想定すべき表示パターンも増えます。

表示パターン

証券の撮影取り込みは、入力の条件で結果が変わる

証券を撮影してデータ化する機能は、角度や明るさなどの条件で読み取り結果が変わります。条件を定めずに確認すると、本番の画像で取り込みに失敗します。

撮影の入力条件

通知や予定の登録は、端末の設定によって動きが変わる

相談予約の通知や次回予定の登録は、端末の設定や基本ソフトの版で動作が変わります。手元の数台で動いても、現場の端末で通知が届かないことがあります。

端末と基本ソフト

確認した範囲が記録に残らず、公開判断の説明ができない

限られた期間で確認を進めると、使った端末と観点が記録に残りません。公開可否の説明が担当者の所感になり、稟議で十分性を示す材料が作れなくなります。

確認記録の不足
02 RISK

確認が足りないまま公開すると、何が起きるか

受け入れ期間内にすべての画面と商品の組み合わせを確認しきれないまま公開すると、見落とした不具合は公開後に別のかたちで表面に出ます。

業務上の問題対応を行う担当者の様子を写した写真。
03 REVIEW

保険代理店の開発現場から寄せられる相談

保険代理店アプリの確認は、募集人向けと契約者向けで画面が分かれ、保険会社と商品の組み合わせも増えるため、限られた受け入れ期間で全体を見きれない状態になりがちです。現場からは次のような相談が寄せられています。

業務の流れに沿った確認が抜けたまま公開すると、募集人の契約者対応の現場で不具合が表面化するおそれがあります。

社内にテストの専任がおらず、企画担当が一人で確認している

開発ベンダーは実装した機能の動作確認までは進めますが、代理店側の業務の流れに沿った確認は誰の担当にもなりません。企画担当者が一人で確認を繰り返し、抜け漏れに気づくのが受け入れ直前になります。

確認する資料
  • 業務フロー
  • 差し戻し履歴
  • 仕様確認表
端末ごとの差異を確認できないまま公開すると、外出先での動作不良として問合せが集中し、対応に人手を取られるおそれがあります。

端末や基本ソフトの版ごとの確認まで手が回らない

通知や予定登録、証券の撮影取り込みは、端末の設定や基本ソフトの版で結果が変わります。手元の数台で確認しても、現場の募集人が使う端末までは追えず、外出先での動作不良として報告が届きます。

確認する資料
  • 対象端末一覧
  • 基本ソフト版
  • 動作確認記録
保険会社ごとの差異を確認観点へ落とし込めないと、改定対象外の商品の表示誤りを見逃し、契約者への誤った案内につながるおそれがあります。

保険会社ごとの違いを、確認の観点に落とし込めない

保険会社ごとに商品データの様式や改定の予定が異なり、情報の粒度もまちまちです。どの表示パターンを確認対象に含めるかを整理できないまま要件へ進むと、改定対象外の商品への影響を読み切れません。

確認する資料
  • 商品データ様式
  • 改定連絡履歴
  • 表示観点一覧
確認の省略が記録なしに積み重なると、商品改定のような外部要因が入った際に影響範囲を読み切れず、作り直しに近い改修へ発展するおそれがあります。

機能追加のたびに同じ確認を人手で繰り返している

機能追加や画面改善のたびに既存機能の確認が必要になりますが、同じ確認を人手で繰り返すうちに省略の判断が増えます。省略した箇所が記録に残らず、次の改修でどこまで確認したかを遡れなくなります。

確認する資料
  • 確認項目表
  • 省略判断記録
  • 改修履歴表
確認結果を説明できる形で残せないと、公開判断が担当者の所感に依存し、意向確認や面談記録を扱う募集プロセスの説明責任を果たせないおそれがあります。

確認した結果を、経営会議で説明できる形にしたい

役員会で公開可否の材料を説明する際、確認に使った端末と観点の記録が手元にないと、担当者の所感による報告になります。テスト外注費の稟議でも、実施しない場合の影響を示す根拠が作れません。

確認する資料
  • 確認端末記録
  • 確認観点記録
  • 結果報告書
  • 稟議添付資料
04 TEST DESIGN

発注側の立場で確認し、記録を残すテストの進め方

受け入れ期間が限られる状況で、発注側の立場として確認の範囲と結果を読める形に整える進め方を整理します。

STEP 01 対象と範囲を聞き取る対象機能と連携先、確認する端末の範囲を把握
どう確かめるか

開発ベンダーの進行に伴走しながら確認を進める

開発ベンダーの進行に合わせ、仕様確定の段階から確認の観点を並行して整理します。納品後に限られた期間で全体を追う負担を、事前の計画で軽くする進め方です。

  • 01対象となる画面群と連携先、外部システムを洗い出す
  • 02確認する端末と基本ソフトの版、設定の範囲を決める
  • 03業務への影響をもとに確認の優先順位の材料を揃える
OUTPUTテスト計画書と項目表
STEP 02 確認の観点とテスト計画をまとめる代理店の業務の流れに沿った観点を整理
どう確かめるか

画面数が多い対象でも、範囲を区切って進める

募集人向けの画面と契約者向けの画面、管理側画面を、機能のまとまりごとに区切って順に確認します。画面数が多い対象でも、優先順位を決めて抜けを減らす進め方です。

  • 01代理店の業務の流れに沿った確認の観点を組み立てる
  • 02確認の範囲に応じて必要になる工数の考え方を整理する
  • 03確認の観点と範囲、進め方をテスト計画書にまとめる
OUTPUT確認する観点の一覧表
STEP 03 テストを実施し、見つかった内容を報告する意図的に条件を発生させて動作を検証
どう確かめるか

開発を担う側とは別の立場で確認の目を入れる

ベンダーの自社内テストは実装した機能の確認に寄ります。代理店側の業務の流れを通した確認は、開発を担う側とは別の立場で実施することで、見落としを抑えられます。

  • 01意図的に条件を発生させ、動作の結果をひとつずつ検証する
  • 02見つかった不具合を、影響の度合いを添えて報告する
  • 03再現の手順と使った端末、基本ソフトの版を記録に残す
OUTPUT不具合報告書と再現手順
STEP 04 結果を整理し、次の改修へ引き継ぐ結果を整理し、次の改修の確認へ引き継ぐ
どう確かめるか

確認の範囲と結果を、第三者が読める形で残す

確認に使った端末と観点、結果を文書として残します。役員会や業務部門へ説明する際に、担当者の所感ではなく記録を根拠にできる状態にします。

  • 01確認の結果を、第三者が読める形の報告書として整える
  • 02確認した範囲と使った端末、観点をすべて記録に残す
  • 03一度作った確認の型を、次の改修での確認へ引き継ぐ
OUTPUT確認結果の記録文書
05 RATIONALE

第三者テストを取り入れたあとの体制の姿

固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。

OUTSOURCING RATIONALE THIRD-PARTY VERIFICATION

必要な時に必要な分だけ

人日単位のアサインで固定費を抱えず、繁忙期に増減できます。

独立した視点で品質を底上げ

独立した検証で偏りを排し、監査に使える客観的な記録を残せます。

専門ノウハウを即戦力で

JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。

ノートPCを前に担当者同士が相談しているオフィスの写真。

専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット

  • 確認範囲と結果を第三者が読める記録として残せます
  • 端末と版の組み合わせを揃えた動作確認が受けられます
  • 保険商品の組み合わせを踏まえた確認観点で検証できます
  • 一度作った確認の型を次の改修へ引き継げます
06 SERVICE

保険代理店アプリに向けて提供するテスト

保険代理店アプリの確認では、募集人向けと契約者向け、保険会社ごとに異なる商品データ、端末や版の組み合わせが重なります。GENZは発注側の立場でテストを設計して実施し、確認の範囲と結果を記録として残します。

SVC 01

画面と業務の流れに沿った機能の確認

募集人の面談記録の登録から、契約者による契約一覧の閲覧や証券の撮影登録まで、業務の流れに沿って画面遷移と表示内容を検証します。

リスク要因と優先順位を示す無文字の図解。
SVC 02

端末と版の組み合わせによる動作の確認

手元にない機種と基本ソフトの版の組み合わせを含めて動作を検証します。外出先での利用でも、表示崩れが起きないかを確認します。

複数のシステムや連携先にまたがる確認範囲を示す無文字の図解。
SVC 03

権限や情報の取り扱いに関する確認

募集人と契約者で参照できる情報が分かれているか、権限の設定どおりに画面が制御されるかを検証します。契約者情報の表示の妥当性も確認します。

計画から報告までの流れを示す無文字の図解。
SVC 04

受け入れ確認の設計と実施の支援

受け入れ期間に合わせて、テスト項目の作成から実施までを担います。確認した範囲と結果は報告書に整理し、公開判断の根拠にご利用いただけます。

確認対象の領域を区分して示す無文字の図解。
07 FLOW

お問合せからテスト開始までの流れ

お問合せからテスト開始までの流れです。開発の進行に合わせ、範囲が変わる場合にも対応します。

フォームまたはお電話でのお問合せ

フォームまたはお電話でご連絡ください。確認したい範囲をお聞かせください。

打ち合わせと対象範囲のすり合わせ

開発の予定と受け入れ期間を伺い、テストの対象範囲と優先順位を整理します。

お見積の提示とご契約の手続き

整理した範囲にもとづき必要な工数と費用を提示し、ご契約となります。

開発の進行に合わせたテストの開始

着手の予定を開発の進行に合わせて調整し、テストを開始します。

公開判断の根拠を残す相談窓口

保険代理店アプリのテスト体制について相談する

確認したい範囲と優先順位、必要になる工数の考え方、開発ベンダーの自社内テストとの重なりまで、初回のご相談で整理します。社内の稟議に使える形で、何をどこまで確認するかをお渡しします。