GENZ, Inc.

テスト外注サービス 見守りアプリの品質を、開発の当事者ではない立場から確かめる

対応端末とセンサーの組み合わせが増え続け、検証範囲の優先順位づけに追われる状況に、GENZが開発の当事者ではない立場からテスト範囲を整理します。

支援事例

支援実績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

テストの範囲を点検するときに確かめる観点

点検の際は、実施済みの項目を並べるだけでは足りません。生活シーンの選定、端末とセンサーの組み合わせ、通知の許容基準、権限と記録の扱い、判定会議へ出せる記録を確かめると、検証しない範囲の説明材料が揃います。

生活シーンの選定根拠がないと、検証範囲の妥当性を説明できず、判定の説得力が下がるおそれがあります。

利用者の生活のどの場面を検証の条件として選んだか

見守りアプリの不具合は、外出・就寝・端末の充電切れといった生活動線に依存して現れます。どの生活シーンを代表として選んだか、その根拠を記録しておくと、検証範囲の妥当性を説明できます。

確認する資料
  • 生活シーン一覧
  • 選定根拠の記録
  • 対象者の行動パターン
組み合わせの取捨基準がないと、検証しなかった範囲が「なぜ外したか」を説明できないまま残るおそれがあります。

端末とセンサーの組み合わせのどこまでを試すか

対応端末と連携する見守り端末・センサーの組み合わせは増え続け、すべてを社内要員で回すことは困難です。どこまでを今回の範囲に含めるか、優先順位の基準を明確にしておく必要があります。

確認する資料
  • 端末組み合わせ表
  • 優先順位の基準
  • 対象外範囲の一覧
許容基準がないと、通知の欠落が導入先からの申告として初めて表面化するおそれがあります。

通知の遅延と欠落を何をもって許容と判断するか

センサーやGPS端末から通知基盤を経て見守り者の端末へ届くまでに、遅延や欠落が生じうる区間があります。どの程度の遅延を許容と判断したか、物差しを定めておかないと、判定会議で説明ができません。

確認する資料
  • 通知経路の構成図
  • 許容基準の定義
  • 遅延計測の記録
権限と表示範囲の記録がないと、個人情報の取り扱いに関わる事象で監査対応が長期化するおそれがあります。

権限区分と記録の表示条件を手順に組み込めているか

介護事業者の職員が管理画面から複数の被見守り者を確認する運用では、権限区分と表示範囲の設計が業務の可否を左右します。位置情報や介護記録の表示条件を手順に組み込み、記録に残す形にしておきます。

確認する資料
  • 権限区分の定義表
  • 表示範囲の確認手順
  • 監査用の操作記録
記録が残っていないと、リリース可否を合議体で決める材料がなく、判断がその場の感覚に委ねられるおそれがあります。

公開の可否を決める判定会議に出せる記録が残るか

リリース判定会議で問われるのは、実施した項目よりも実施しなかった範囲の妥当性です。検証の結果と判断の根拠が記録として残っていれば、公開の可否を合議で決める材料としてそのまま提出できます。

確認する資料
  • テスト結果報告書
  • 未検証範囲の一覧
  • 判断根拠の記録
  • 判定会議の議事録
04 TEST DESIGN

GENZが引き受けるテストの範囲

GENZは、見守りシステムの開発から公開後の記録整備まで、検証の各局面を貴社の開発体制と伴走して引き受けます。

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

相談からテスト開始までの流れ

相談からテスト開始までは段階を追って進みます。社内稟議の材料となる範囲の整理も、契約前の段階で行います。

相談内容と対象のシステムを伺う

対象のアプリと見守り端末、連携する通知基盤の構成を伺います。

テストの範囲を整理して提案する

端末と連携先の組み合わせを一覧化し、未検証範囲と優先順位を整理します。

受け入れ体制と契約の条件を決める

対象範囲の境界と受け入れ体制、成果物の形を合意して契約します。

合意した範囲でテストを開始する

結果は記録に残し、リリース判定会議や監査で使える粒度で報告します。

開発の当事者ではない立場からの相談窓口

見守りアプリのテスト体制について相談する

相談では、対象となる端末と連携先の組み合わせをもとに、テスト範囲の切り分けと優先順位、必要な工数の見立てを整理してお返しします。社内稟議に使える粒度でお渡しします。