バスターミナルを運営するC社は，再開発に伴い，これまで散在していた小規模なバスターミナルを統合した，新たなバスターミナル(以下，新バスターミナルという)を運営することになった。
　C社が運営する新バスターミナルには，複数のバス運行事業者(以下，運行事業者という)の高速バス，観光バス，路線バスが発着する。このうち高速バスと観光バスは指定席制又は定員制であり，空席がない場合は乗車できない。乗車券の販売は，各運行事業者が用意する販売端末やホームページで行う。
　新バスターミナルでは，新バスターミナルシステムとして，バスの発着を管理する運行管理システム，及びバスの発車時刻，発車番線，空席の有無などを利用者に案内する案内表示システムを導入することになり，C社の情報システム部に所属するD君が，運行事業者から空席の情報を取得するデータ連携方式の設計を行うことになった。

〔新バスターミナルシステムの概要〕
　新バスターミナルシステムの概要を図1に示す。　運行管理システムがもつ案内表示に関連する機能を表1に，案内表示システムがもつ機能を表2に，表示器の表示項目の例を表3に示す。〔運行事業者の概要と連携機能の有無〕
　運行事業者データ連携機能の空席情報を取得する処理について，運行事業者が空席情報を含むデータの連携機能をもつ場合には，それを活用する方針とした。そこで，D君は，高速バス，観光バスの運行事業者であるE社，F社，G社，H社について，運行している全てのバスの種別と連携機能の有無を調査した。調査結果を表4に示す。
　なお，高速バス，観光バスの運行事業者は上記の4社だけであるが，路線バスだけを運行する運行事業者であるS社，T社が存在する。　E社，F社，G社の空席情報の連携機能が提供しているデータ項目の書式と例を表5に示す。〔データ項目の検討〕
　D君は，表5の情報を基に，運行管理システムが運行事業者から取得する空席情報ファイルのレコード構成，データ項目を検討した。

• 空席情報ファイルは，ヘッダレコード1件と必要な数のデータレコードから成り，ヘッダレコードには，作成日，作成時刻に加え，データレコード件数を含めることにした。
• 路線コード，便コードが運行事業者間で重複しないよう，二つのコードを結合し，運行事業者ごとのコードを付加した一つのコード(以下，統合便コードという)として取り扱うことにした。この統合便コードは，新バスターミナルシステム全体で使用する。この検討において，①表5の運行事業者以外の情報も調査し，問題がないことを確認した。
• ②ファイル形式はCSV形式，文字コードはUTF-8とし，各項目の書式を揃えた。

　空席情報ファイルのデータレコードの内容を表6に示す。〔連携方法の検討〕
　D君は，連携方法について，それぞれの運行事業者と調整を行った。H社については運行する便数が少ないこともあり，開発費用が比較的安価である③Webページから情報を抽出する方法を用いることにした。連携方法に関する調整結果を表7に示す。〔空席情報取得機能と空席情報設定機能の処理について〕
　D君が検討した空席情報取得機能と空席情報設定機能を用いた空席情報ファイルの取得から設定の処理について，図2に示す。　表7及び図2で検討した処理について，情報システム部内でレビューを実施したところ，次のような指摘があった。
(ⅰ) 運行事業者とのデータ連携においてFTPによるファイル転送を用いる場合は，ファイル全体が正しく転送されたことを確認する必要がある。
(ⅱ) 特定の運行事業者から空席情報が取得できなかった場合，その運行事業者のバスについて表示器に古い空席記号が表示され続けてしまう。
　D君は，(ⅰ)の指摘に対して運行事業者データ連携機能に空席情報ファイルのaとbが一致することを確認する処理を追加する対策案，及び(ⅱ)の指摘に対して④図2の処理(3)の最初に新たな処理を追加する対策案の検討を行い，再度レビューを実施した。
　D君は対策案が承認された後，後続の開発作業に着手した。