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

静的テスト(レビュー)でおさえるべき観点

ダイヤ編成システムの受け入れでは、実行前にドキュメントを照合する静的テストで検出できる不整合が多く残ります。GENZがレビューで確認する観点を、照合先の資料とともに整理します。

届出内容と公開時刻表の不一致が改正日に表面化し、訂正の周知と問い合わせ対応が同時に発生するおそれがあります。

区間時分と停留所のマスタ定義を届出・周知資料と照合する

停留所と区間時分のマスタ定義が、自治体への届出書類や周知資料の記載と一致しているかを照合します。改定マスタの一部が反映されないまま届出へ出る不整合を、出力前に検出します。

確認する資料
  • 運行計画届出書
  • 周知資料
  • マスタ定義書
労働条件に適合しない仕業が実行され、是正報告と監査対応の負担が生じるおそれがあります。

作成ルールの仕様を労働時間・休憩の条件と労使協定に照合する

仕業の作成ルールが、連続運転時間や休憩の条件と労使協定へ適合するかを仕様書の段階で照合します。判定ロジックの根拠を文書で示せる状態にし、担当者の手作業確認への依存を減らします。

確認する資料
  • 労使協定
  • 仕業作成仕様書
  • 労働条件一覧
日付が変わる前後の表記規則の不整合が、車載器の表示誤りとして乗務の現場で発生するおそれがあります。

日をまたぐ便と深夜便の時刻表記規則を、境界値の一覧と照合する

日をまたぐ便や深夜便について、終電後や日付が変わる前後の境界値の一覧を作り、時刻表記の規則と照合します。表示規則の不整合が公開用データまで及ぶ不具合を設計の段階で検出します。

確認する資料
  • 時刻表記規則書
  • 境界値一覧
  • 便マスタ定義
識別コードの不一致が連携先への取り込みエラーとなり、原因の切り分けに時間がかかるおそれがあります。

系統と便の識別コード体系を、DB設計書とAPI定義の項目と照合する

系統と便の識別コードの体系が、DB設計書とAPI定義の項目と一致しているかを照合します。マスタ移行時に項目定義の対応が未確認のまま進むリスクを、定義書同士の照合で表面化させます。

確認する資料
  • DB設計書
  • API定義
  • コード体系表
出力項目の欠落が下流システムで判明し、再出力と差し戻しが発生するおそれがあります。

帳票と公開用データの出力項目仕様を、連携先の取り込み要件と照合する

時刻表・帳票・公開用データの出力項目仕様が、車載器や取り込み先システムの要件を満たすかを照合します。仕様が変わらない更新でも影響を受ける出力物の範囲を、文書上で決められます。

確認する資料
  • 出力項目仕様書
  • 連携先取込要件
  • 帳票レイアウト定義
  • 公開用データ仕様
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

GENZが代行するダイヤ編成システムのテスト

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

OUTSOURCING RATIONALE THIRD-PARTY VERIFICATION

必要な時に必要な分だけ

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

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

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

専門ノウハウを即戦力で

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

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

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

  • 改定マスタの反映を出力物まで確認する手順とテスト項目書を整備する
  • 自社にない受け入れテストの検証範囲を第三者の視点で設計する
  • 改正日までに間に合わせる検証の優先順位づけを行なう
  • リリース判断に使える検証範囲と不具合収束状況の報告書を作成する
06 SERVICE

運行業務に即したGENZのテスト支援

ダイヤ改正の検証は、製品の機能一覧からではなく、運行計画の業務ルールから設計する必要があります。GENZは開発と検証を分けた第三者の視点で、テスト設計から実行、報告までを担います。

SVC 01

テスト設計の起点は業務ルールにある

停留所と区間時分の編集ルール、仕業作成の条件をテスト観点へ翻訳し、自社で基準を作れない検証範囲を第三者の視点で設計します。

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

マスタ編集から出力までを検証する

改定したマスタが山ダイヤ、時刻表ダイヤ、仕業ダイヤ、連携データのどこまで反映されているかを、テスト項目書にもとづき確認します。

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

既存のベンダー体制に合わせて伴走する

ベンダーの設定や改修と並行してテストを進め、改正日に合わせて検証範囲の優先順位を決め、全量検証を前提としない進め方を組み立てます。

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

テスト結果をリリース判断に使える形で報告

検証範囲と不具合票の収束状況、残存不具合の評価を報告書にまとめ、部門の承認と経営会議でのリリース判断の材料としてご利用いただけます。

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

ご相談から納品までの流れ

ダイヤ改正や更改の日程に合わせ、検証範囲の確認から報告書の納品までを順に進めます。

ヒアリングで対象範囲と改正時期を確認する

改正予定日と対象範囲、マスタ構成、連携する周辺システムを確認します。

テスト設計と見積もり

確認した範囲をもとにテスト項目を設計し、期間と工数を見積もります。

テストを実行し不具合を共有

設計した項目に沿って検証し、検出した不具合を不具合票として随時共有します。

報告書の納品と再確認

検証結果を報告書として納品し、修正後の再確認の範囲と条件を取り決めます。

ダイヤ改正・更改を控えた事業者様へ

ダイヤ改正までの検証範囲と優先順位をGENZにご相談ください

ご相談では、運行計画の業務内容に沿った検証範囲の整理、改正日に合わせた優先順位づけ、必要工数の考え方を、部門の承認と経営会議の資料に使える水準でお示しします。