改定した区間時分が停留所時刻表に反映されない
区間時分の改定が一部の停留所時刻表に反映されないと、改正後も旧時刻のまま掲出され、利用者からの問い合わせと訂正の周知が発生します。
改正日までの検証範囲を、運行計画の業務内容から設計します。優先順位づけと、社内承認に使える報告書まで、GENZがテストの設計と実施を担います。
支援実績5,000件以上













ダイヤ改正では、改定したマスタを時刻表・仕業ダイヤ・車載器データ・公開用データへ一貫して反映させる必要があります。規模が大きい改正ほど、反映漏れが残ったまま改正日を迎えるおそれがあります。
区間時分の改定が一部の停留所時刻表に反映されないと、改正後も旧時刻のまま掲出され、利用者からの問い合わせと訂正の周知が発生します。
日付をまたぐ便を前日の仕業として扱う設定のままだと、乗務割当に担当が表示されず未割当の便が残り、割当表の修正と再連絡が必要になります。
系統の分割で到着時刻と出発時刻が再計算されないと、折返し時間が負の値になり、同じ車両が二つの運用へ重複して割り当てられます。
連続運転時間と休憩の計算順序が労使協定の解釈と異なると、条件を満たさない仕業が適合と判定され、労務担当の手作業での全件確認に戻ります。
廃止した停留所のコードが残ったまま出力されると、車載器や公開用データ側で存在しない停留所として不整合になり、取り込み自体ができなくなります。
確認が期日に間に合わない改正では、不具合が残った時刻表と仕業が運用に使われます。残った不具合は、公開後の訂正や行政対応として表面化します。
ダイヤ編成システムの受け入れでは、実行前にドキュメントを照合する静的テストで検出できる不整合が多く残ります。GENZがレビューで確認する観点を、照合先の資料とともに整理します。
停留所と区間時分のマスタ定義が、自治体への届出書類や周知資料の記載と一致しているかを照合します。改定マスタの一部が反映されないまま届出へ出る不整合を、出力前に検出します。
仕業の作成ルールが、連続運転時間や休憩の条件と労使協定へ適合するかを仕様書の段階で照合します。判定ロジックの根拠を文書で示せる状態にし、担当者の手作業確認への依存を減らします。
日をまたぐ便や深夜便について、終電後や日付が変わる前後の境界値の一覧を作り、時刻表記の規則と照合します。表示規則の不整合が公開用データまで及ぶ不具合を設計の段階で検出します。
系統と便の識別コードの体系が、DB設計書とAPI定義の項目と一致しているかを照合します。マスタ移行時に項目定義の対応が未確認のまま進むリスクを、定義書同士の照合で表面化させます。
時刻表・帳票・公開用データの出力項目仕様が、車載器や取り込み先システムの要件を満たすかを照合します。仕様が変わらない更新でも影響を受ける出力物の範囲を、文書上で決められます。
動的テストは、設計・ユニット・統合・システムの順に進めます。境界値を軸に項目を組分けし、改正前に不整合を検出します。
停留所マスタの編集条件と、発車時刻・所要時分の境界値を組み合わせてテスト項目書を作成します。改定マスタが時刻表・車載器データ・公開用データへ反映されるかを項目として定義します。
区間時分の加算処理と、仕業の休憩・拘束時間に対する労働条件の判定を境界値で検証します。時分の端数処理や日またぎの便で計算されない条件を発生させ、判定ロジックの誤りを検知します。
マスタ編集から山ダイヤ・時刻表ダイヤ・仕業ダイヤの生成まで、モジュール間の連携を検証します。入力条件の変更が帳票と連携データへ反映されない不整合を検出し、再出力と差し戻しを防ぎます。
既存ダイヤへの影響を確認するため、改正後の運用を想定したシステムテストと回帰テストを実施します。前回改正の訂正箇所で不具合が再発しないことを確認し、改正後の対応負荷を抑えます。
固定費を抱えない人日単位のアサイン、監査にも使える独立した検証の記録、育成期間なしに活かせる専門ノウハウなど、第三者へのアウトソースには複数のメリットがあります。
人日単位のアサインで固定費を抱えず、繁忙期に増減できます。
独立した検証で偏りを排し、監査に使える客観的な記録を残せます。
JSTQB認定エンジニアが在籍し、対象領域固有の検証知見を育成期間なしに活用できます。
ダイヤ改正の検証は、製品の機能一覧からではなく、運行計画の業務ルールから設計する必要があります。GENZは開発と検証を分けた第三者の視点で、テスト設計から実行、報告までを担います。
停留所と区間時分の編集ルール、仕業作成の条件をテスト観点へ翻訳し、自社で基準を作れない検証範囲を第三者の視点で設計します。
改定したマスタが山ダイヤ、時刻表ダイヤ、仕業ダイヤ、連携データのどこまで反映されているかを、テスト項目書にもとづき確認します。
ベンダーの設定や改修と並行してテストを進め、改正日に合わせて検証範囲の優先順位を決め、全量検証を前提としない進め方を組み立てます。
検証範囲と不具合票の収束状況、残存不具合の評価を報告書にまとめ、部門の承認と経営会議でのリリース判断の材料としてご利用いただけます。
ダイヤ改正や更改の日程に合わせ、検証範囲の確認から報告書の納品までを順に進めます。
改正予定日と対象範囲、マスタ構成、連携する周辺システムを確認します。
確認した範囲をもとにテスト項目を設計し、期間と工数を見積もります。
設計した項目に沿って検証し、検出した不具合を不具合票として随時共有します。
検証結果を報告書として納品し、修正後の再確認の範囲と条件を取り決めます。
ダイヤ改正・更改を控えた事業者様へ
ご相談では、運行計画の業務内容に沿った検証範囲の整理、改正日に合わせた優先順位づけ、必要工数の考え方を、部門の承認と経営会議の資料に使える水準でお示しします。