10年以上稼働しているサービスをリニューアル 仕様検討で工夫したこと
はじめに
こんにちは、むらさきしきぶです。ナビタイムジャパンの公共交通事業部で、電鉄・バス事業者向けサービスの開発・運用を担当しています。
公共交通事業部では、バス・鉄道事業者向けに、乗換案内、時刻表、バス接近情報が検索可能なWebサイトの運用を支援する『乗換・時刻表サービス』を提供しています。
2024年2月5日（月）より、その『乗換・時刻表サービス』の名称を、『乗換時刻表クラウド by NAVITIME』へ変更し、サービスをリニューアルしました。
▼2024/02/05配信のプレスリリース
今回は『乗換・時刻表サービス』を『乗換時刻表クラウド by NAVITIME』へリニューアルするにあたって、仕様の検討をした際に開発チームとして工夫したことをご紹介します。
リニューアルの背景
『乗換・時刻表サービス』は、多くのバス・公共交通事業者に導入いただき、各事業者の要望に向き合って、運用してきました。
一方で、要望に応え続けた結果、各事業者固有の仕様・実装が増えていき、機能追加や改修を行うと、各事業者固有の仕様・実装の考慮が足りず、不具合や障害につながる問題が発生していました。
安定したサービスを提供すること
各事業者の要望に応え続けること
当社の研究開発資産を機能追加すること
が難しくなり、リニューアルをすることを決断しました。
リニューアルで導入したこと
『乗換時刻表クラウド by NAVITIME』へのリニューアルにあたり『乗換・時刻表サービス』で発生した課題に対するアプローチとして以下2つの手法を導入しました。
実例マッピング・・・仕様整理
Architectural Decision Records（以後ADRと略）・・・チームの決定事項を記録
実例マッピング
実例マッピングとは、あるユーザーストーリーに対して、その要件と要件に対する実際の例を書き出しながら、仕様を整理していく手法です。
仕様についての議論では、各々の関心によって、様々な観点の話が同時に発生し、発散しやすく、検討した範囲や決定事項が後々わかりにくくなってしまうことがあります。
実例マッピングは、ユーザーストーリー単位で議論を進められるため、その場で検討したいスコープが絞られます。また、ユーザーストーリーの単位で決定した最終的な仕様のみを記載するので決定事項がわかりやすいです。
ADR
ADRとは、サービスに対するチームの決定事項を記録したドキュメントです。意思決定だけでなく、そのコンテキストも記載します。
同じサービスを長年に渡って運用していくと、チームメンバーの入れ替わりによって、サービスの技術選定や仕様についての決定の経緯がわからないことがあります。当時の経緯がわからないと、新しい技術を導入したり、仕様を変更したりすることが難しくなります。
ADRに、サービスに影響を与えるチームの決定事項、背景、経緯を記載したドキュメントを残しておくことで、今後チームに新しいメンバーが入った時も当時の状況を容易に知ることができます。
ADRにはいくつかテンプレートがありますが、私たちのチームでは『Decision record template by Michael Nygard』をベースにしています。
また、ADRは意思決定の数に比例して増えていくため、後から一覧で確認した際、意思決定が承認されたか否かが一目で判断できるようなタイトルをつけるように工夫しました。
リニューアル前のサービスの仕様を整理するにあたって、過去にその仕様に至った経緯がわからなく、リニューアル後も引き継ぐべき仕様かの判断が難しいことが多々ありました。
今後『乗換時刻表クラウド by NAVITIME』を運用し続けるためには、現在の仕様と至った経緯を未来に残す必要があると判断し、ADRを導入しました。
同じメンバーが残っていても1年ほど前の内容だと記憶が曖昧になっていることもありました。
開発を進めていく中で、当初決定していた仕様から変更する際にも経緯を思い出すことに役立ちました。
まとめ
実例マッピングとADRを導入したことで、サービスをアップデートしながら、運用し続けるための基盤作りができました。
実例マッピングとADRはサービスの運用が長くなればなるほど、より効果を発揮していきます。
これからも実例マッピングとADRを活用しながら、『乗換時刻表クラウド by NAVITIME』がユーザーの皆様が便利にお使いいただけるようなサービスになるように日々邁進して行きます。