3チームが絡む運用のリードタイムを半分にした話
はじめに
こんにちは、G2です。
ナビタイムジャパンで描画地図データの運用、保守を担当しています。
今回お話する業務とその状況
今回お話するのは当社で更新運用をしている、住所検索データについてです。こちらのデータは法人向け『NAVITIME API』の住所検索機能に利用されているデータとなります。
こちらのデータは、
描画データ運用チーム
住所データ運用チーム
検索改善チーム
の３チームが連携して更新をしているのですが、各チームの担当者が何度か変わるうちに運用があいまいになっているという状態でした。
今回『NAVITIME API』の担当エンジニアから、社内の更新リードタイムを短縮できないかと相談をうけて対応をしたものです。
認識合わせ
まず認識を合わせるため、3チームの担当者に声をかけ、打合せを実施することになりました。打合せの冒頭では住所検索データの更新リードタイムが長いという課題を共有して、各チームのリードタイムや現状の更新で困っていることなどを話し合いました。
打合せの中で運用に関して下記の状況である事が分かりました。
描画データ更新チームのデータ作成が終わってから連絡があるので、急な依頼となり、住所データ運用チームが予定を立てられず困っていた（遅れの要因だった）。
リードタイム、作業ボリュームの多くは住所データ運用チームだった。
作成フロー全体を簡単に図にまとめてみると下図のようになります。
問題点の整理
住所データ運用チームで予定が立てられず困っていた
こちらの問題は、データサプライヤーから納品スケジュールの提供を受けている描画地図担当者から、事前に住所データ運用チームへデータ更新予定を連絡することで解消できました。もともとおおよその予定は分かっているので、先の予定まで伝えてスケジューリングに活用いただきました。
住所データ運用チームのリードタイム、作業ボリュームが多い
こちらに関しては、最初の打合せで内容を確認するのは準備も時間も足りなかったので、次の項目で説明する「処理フロー共有会」を次回の打合せで実施する事にしました。
処理フロー共有会の実施
事前に処理内容と処理時間が分かる資料を作成して、３チームで順番に発表することで処理内容の共有を行うようにしました。関係者が全員集まってVSM（バリューストリームマッピング）を作成する事も検討しましたが、VSMは処理内容を深く理解することができる一方で、時間がかかる問題があると感じていました。今回どこまで改善をするかはチーム毎の事情もあり、あくまでアドバイスをするというスタンスだったので、簡易的に処理フローを共有することで時間短縮をしつつ、お互いの処理フローを共有し、どのように進めるのが良いのか共通認識を持つことができました。共有会の中では特にリードタイム、作業ボリュームの大きい住所データ更新チームのフローに対して質問と改善のアドバイスが多数出ました。
出てきたアドバイスの一つとして、『NAVITIME API』で参照している環境は、他のサービスで利用している環境と同一のデータベースを参照しているので、そのサービスの影響を受けてリリースが遅れてしまうことが多くありました。データベースを分離する事で、『NAVITIME API』の環境のリリースをより早くすることができるのではという意見がでました。
連絡手段を一つのチャンネルに集約
また当社ではビジネスチャットツールとしてSlackを利用しているのですが、住所検索データ作成のチャンネルに関係者を集め、作業連絡、予定の共有、データコンバートジョブの実行結果の通知等をチャンネルに共有するようにしました。
このチャンネルには『NAVITIME API』のエンジニアにも入ってもらい、更新の状況を把握できるようにしました。
さいごに
当初全体で２ヵ月かかっていた住所検索データの更新ですが、最終的には１ヵ月を切るリードタイムでリリースすることでができました。取り組む前はどんな技術的課題があるのだろうか？と思っていたのですが、蓋を開けてみるとコミュニケーションの問題が大半を占めていました。
またコミュニケーション不足による待ちの発生で、こんなにもリードタイムが伸びるのかという部分にも驚きました。課題にしっかり向き合わないとチーム間の問題には気づきづらいのかもしれません。
今後は技術的な課題を解消しつつ、まだまだ作業ボリュームの大きい、住所データ運用チームの部分について改善できればと思っています。