予約と点呼記録が別々に確かめられ、一日の流れとして通されていない
予約と点呼記録を別々に確かめるだけでは、予約から点呼、帰着までを一日の流れで通したとき、前の操作の結果が次の画面へ引き継がれず記録が欠けます。
GENZ, Inc.
社用車を持つ企業の
車両管理アプリの
社用車を持つ企業の
車両管理アプリのテストを業務の流れで設計し第三者が実行
車両管理アプリの導入・更改では、業務の流れに沿って検証範囲を決めることが受け入れ判断の根拠になります。GENZが設計から実行までを第三者の視点で担います。
支援事例
支援実績5,000件以上
車両管理アプリの受け入れ前に残りやすい確認の抜け
車両管理アプリの受け入れでは、機能ごとの確認は済んでいても、運用の流れや現場の環境に関わる確認が抜けがちです。公開したあとに紙の控えの併走や記録の欠落につながる、受け入れ前に残りやすい確認の抜けを示します。
予約と
アルコール検知器との接続が実機の組み合わせで確かめられていない
アルコール検知器との接続を実機の組み合わせで確かめていないと、本番の拠点で測定値がアプリへ渡らず、酒気帯び確認の記録だけが残りません。
電波が届きにくい場所での入力の保持と送信が試されていない
電波の届きにくい場所での動作を試していないと、山間部や地下の駐車場で入力した点検や位置情報が送信されず、運行記録に空白の時間帯ができます。
拠点ごとに異なる運用が要件に載らず、確認の対象からも外れている
点呼の時間帯や代車の扱いなど、拠点ごとに異なる運用が要件に載らないと、テストの対象から外れたまま公開され、その拠点では紙の控えが復活します。
保存した記録の出力が、画面の表示と一致するか確かめられていない
画面の記録と、保存された記録の出力が一致するか確かめていないと、業務監査で提出した帳票と画面の内容が食い違い、保存状況を説明できなくなります。
確認が届かないまま公開したあとに起きること
受け入れ前の確認が届かないまま公開へ進むと、問題は運用が始まってから、記録の欠落や紙の併走という形で表面化します。
車両管理アプリのテスト外注で寄せられるご相談
車両管理アプリの導入・受け入れの局面では、テストの範囲や判断の根拠に関する相談が繰り返し寄せられます。以下は、推進担当やテスト取りまとめのご担当者から実際に挙がる声を整理したものです。
拠点ごとの運用差が要件に載らないまま公開されると、記録の欠落として表面化し、切り分けができないため紙の控えが復活します。
受け入れ試験の範囲をどこまで自社で決めるべきか判断できない
ベンダーから工程見直しの提案として検証範囲の削減候補が示されても、削ってよい範囲かを発注側で判断する根拠がなく、工程の都合で線が引かれてしまいます。
確認する資料
- 要件定義書
- 開発工程表
- 検証範囲案
ベンダーの自己検証だけで判断すると、残った指摘の影響を確かめられないまま公開され、記録欠落が起きたときの説明責任が発注側に残ります。
開発を担当したベンダーの検証結果だけで判断してよいか迷う
開発を担当したベンダー自身のテスト結果だけでは、残った指摘が暫定対応で許容できるかを確かめる手段がありません。第三者に出すとしても、どこまで出せば足りるかが見えないまま期日が迫ります。
確認する資料
- テスト結果一覧
- 指摘一覧
- 暫定対応方針
実機と環境に依存する確認を机上の確認で済ませると、現場で記録が残らない事象が起き、あとから再現できず原因を確定できません。
端末と連携機器の組み合わせをどこまで試すか線を引けない
アルコール検知器との接続や、電波の届きにくい場所での位置情報の取得は実機と環境に依存します。端末と機器の組み合わせを増やせば工数が膨らみ、減らせば公開後の欠落を説明できません。
確認する資料
- 端末一覧
- 連携機器仕様
- 組合せ表
費用の根拠が示せないままだと、テスト外注が保留され、更改投資が想定した削減効果に届かず次の投資判断も遅れます。
稟議に出す費用の根拠をどう書けばよいか分からない
稟議の場では、外部にテストを出す理由と、出さない場合に何が残るかを同時に問われます。公開前の確認責任と公開後の説明責任が束ねられ、費用の根拠をどう書けばよいか分からなくなります。
確認する資料
- 社内稟議書
- 相見積書
- 費用対効果案
確かめられていない組み合わせが積み上がると、アプリの仕様と実際の運用が食い違ったまま変更が重ねられ、記録を電子で残すという導入目的が達成されません。
端末やアプリの更新のたびに同じ範囲を再度試すべきか決められない
定常運用では端末の入れ替えや権限変更のたびに、確かめられていない組み合わせが少しずつ増えます。同じ範囲を再度試すべきかどうかを、更新のたびに判断する基準がありません。
確認する資料
- 運用手順書
- 端末配備台帳
- 権限変更履歴
- 過去の障害記録
テストの設計から報告までの進め方
拠点ごとの運用差や実機との連携を対象に載せるには、業務の流れから範囲を組み立てる設計が要ります。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テスト結果報告書と総括
車両管理の業務を踏まえて、確かめる範囲を決めます
固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。
OUTSOURCING RATIONALE
THIRD-PARTY VERIFICATION
01
必要な時に必要な分だけ
人日単位のアサインで固定費を抱えず、繁忙期に増減できます。
02
独立した視点で品質を底上げ
独立した検証で偏りを排し、監査に使える客観的な記録を残せます。
03
専門ノウハウを即戦力で
JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。
専門知識を持ったテストエンジニアが、第三者の視点でテストするメリット
- 業務の流れに沿って試す範囲の線引きが決まります
- 実機と連携機器を含む確認が社外の手で回ります
- 上程と業務監査にそのまま使える記録が残ります
- 公開後の切り分けに使える再現手順が揃います
対応する業務領域と検証の対象
車両管理アプリのテストでは、業務の流れに沿って検証範囲を切り分けます。GENZは予約から点呼、運行記録、日常点検までを検証の単位として扱い、受け入れ判断に足る範囲を整理して第三者の視点で実行します。
社用車の予約申請と利用の承認
車両の予約から利用承認までを対象に、予約の重複や承認漏れが起きた場合の画面表示と通知の動きを、拠点の運用に沿って検証します。
点呼の記録とアルコール検知器の連携
乗車前後の点呼入力と検知器との連携を対象に、測定値がアプリへ渡るか、接続が切れた場合に記録がどう残るかを実機で検証します。
運行の記録と走行の位置情報の取得
運行の開始から帰着までの記録と位置情報の取得を対象に、走行データの欠落や機種差による抜けがないかを配備端末の組み合わせで検証します。
日常点検の報告と車両台帳の管理
点検の報告と車両台帳の管理を対象に、点検結果の保存と出力、車両やドライバー情報の更新が反映されるかを検証し、監査で示せる形に整えます。
お問合せからテスト開始までの流れ
車両管理アプリの検証は、運用の実情の共有から始まります。お問合せから開始までの流れは次のとおりです。
お問合せと現在の導入状況の共有
導入の進捗と拠点ごとの運用差をお聞かせください。点呼記録の扱いも伺います。
対象範囲のご提案とお見積の提示
工数を試算し、外部に出す範囲を整理します。見積の依頼単位を作れます。
ご契約の締結とテスト計画の確定
委託の範囲と金額を合意のうえ契約し、比較の軸でテスト計画を確定します。
合意した計画に沿ったテストの開始
開発の遅延で検証期間が圧縮されても、削る順序の合意に沿って開始します。
テスト範囲の無料相談・お見積はこちら
車両管理アプリの検証範囲について、まずはご相談ください
ご相談の場では、業務の流れに沿ったテスト範囲の整理、優先順位の考え方、必要な工数の目安、連携機器に関わる関連テストの要否まで、受け入れ判断に使える形でお示しします。