テスト駆動開発(TDD)が公共交通データ作成(運用)に向いていると思った話
こんにちは、Masaヤンです。noteは初めての投稿になります。
ナビタイムジャパンでは公共交通データ(主に鉄道・航空)の作成・運用改善の業務を担当しています。また、所属するプロジェクトではスクラムマスターの役割も担当しております。
アジャイル開発、特にXPで推奨されているプラクティスのひとつに「テスト駆動開発(TDD)」があり、筆者の所属するプロジェクトでも数年前から公共交通データの開発業務に取り入れております。
今回は筆者のメイン業務である公共交通データの作成(運用)にテスト駆動開発がなぜフィットしたのか、筆者なりの観点で考察してみたいと思います。
最後までお付き合いいただけますと嬉しいです。
テスト駆動開発は公共交通データの作成になぜフィットしたのか？
テスト駆動開発には、アジャイル開発のもつ「チームの認識を揃えつつ、変化に強い開発を実現する」という要素が含まれていることは皆さまご存知の通りかと思います。
ここでは筆者が法人向け鉄道時刻表データ(のコンバータ)を開発する中で実際に感じた、公共交通データとテスト駆動開発の相性が良いと思ったポイントを、経験談を交えてご紹介したいと思います。
①鉄道に関する複雑なルール・規則を整理しやすい
時刻表データを作成する際には、発着時刻や行先情報はもちろん、
駅毎の列車～列車への乗継にかかる時間の設定や
経路検索画面に表示される乗車・降車時の番線情報、
また一部法人向けサービスでは、時刻表画面にて表示される
「○○駅で△△行きの列車にお乗り換えできます」のような案内情報データも作成をしています。
これらは駅・番線・列車の種別・先方の要望、など様々な条件が絡み合っており、条件に応じて適切な値を設定する必要があります。
テストコードを先に実装することで、複雑な鉄道規則(ルール)を仕様として落とし込むことができ、実装後の関数が仕様に準拠している(テストコードが通る)ことを担保できるようになりました。
②仕様変更に強い
法人向けの案件では、どの鉄道会社様も自社のサービスに情熱とこだわりをもって取り組まれているため、開発中に「ここの情報を○○のように直して欲しい」という仕様変更を依頼されることは珍しくありません。
また、公共交通機関という特性上、ダイヤ改正や臨時ダイヤによって新しく考慮すべき条件が出てきたり、今まで適用していたルールに変更が発生することもあります。
実際の例で見てみましょう。
「平日」「土休日」のような曜日種別を表す文字列を、データとして格納される値にマッピングする関数を改修したときの話です。
サービス開始後、年末年始ダイヤに初めて対応することになった際、「越年」という新しい曜日種別をマッピングに追加する必要があることが分かりました。
まず筆者が行ったことはテストケースの追加です。（上記画像）
その後新しいテストケースを含め、全てのテストケースが通るように
対象の関数の実装を行いました。
このように
①テストコードを新しい仕様に適用するようにアップデート
②テストコードが通るように関数を実装
というテスト駆動開発の基本ステップを踏むことで、
新しい仕様に素早く適応することができました。
（筆者個人としては、この仕様変更への強さがテスト駆動開発と公共交通データの最も相性が良いポイントだと考えています。）
③一日の進捗目標が立てやすい
これは公共交通データの開発に限った話ではないと思いますが、テストコードがあることによって「今日はこことここのテストを通すまでは進めよう」という、一日当たりの業務の進捗目安を立てやすくなったことも、筆者が実際に感じたメリットとして挙げられます。
一日の業務の目標をテスト単位で設定したことで、通るテストコードが増えていく（開発が進んでいる）ことが目に見える形で現れるため、日々の開発にリズムが生まれ、法人案件という大きな開発アイテムでも、モチベーションを維持しながら日々進捗を出すことができたのではないかと今は感じています。
まとめ
いかがでしたでしょうか？
テストコードとは、単に実装した関数が意図した通り動くかどうかをテストするだけではなく、
「仕様の整理」
「変化に強い開発」
を手助けしてくれるとても頼もしい味方であることを感じていただけましたでしょうか。
本記事が読者の皆様の「変化に強い開発」に少しでも貢献できたら嬉しいです。
最後までお付き合いいただきありがとうございました。