経路検索サービスのパイオニア「駅すぱあと」。1988年のMS-DOS版の発売以降、時代の変遷に合わせてサービスの形を変えながら、成長を続けてきた。同サービスを運営する株式会社ヴァル研究所では、駅すぱあとが好調だった90年代後半以降、新しい技術を社内に取り入れる気運が低かったのだという。Service(以下、AWS)の導入による、サーバーのクラウド化だった。孝太さんの周囲を巻き込んだ呼び掛けで、社内の空気が変化。Apps、Slack、esa、CircleCI、GitHubなど様々な外部ツールを導入するまでに変わったという。前編では、同社がAWSを導入するまでの経緯を見川さんにお伺いした。ひかるさんを迎えてお伺いした。実際にサーバーをAWSに切り替える際には、互換性を保ちながら全部一気に変えてしまうことにしました。最初にまず、駅すぱあとWebサービスの無償版だけを移行して試してみようと。自力でAWSの各サービスの勉強を始めて、AWSのアーキテクトの方に相談しながら、6ヶ月ほどかかって準備しました。いざ切り替える時は、それはもう不安でした。お客様がいる中で、無言で切り替えるわけにはいかない。営業とも相談しないといけない。お客様にもそれぞれの都合がありますし...。そんな感じで泥臭く作業して、2013年の初めに最初の切り替えを行いました。サービスが巨大なので、やはりすんなりはいかなくてですね...。結局のところ、障害の発生があって、お客様には本当に申し訳なかったです。結局その障害は、技術的には正当性がある部分で起きていたんですよね。データ構造の部分で、結論から言うとお客様の方でこちらで想定していない使い方でデータを取っていたので、切替によってそれができなくなって障害につながって。技術的に正しいことが直接通用するわけではない、ということを身をもって学びました。私は2006年に新卒で入社して、AWSへの切り替えの際には、見川と一緒のチームで開発を行っていました。AWSに移行したことで一番大きかったメリットは、運用負荷が下がったことです。以前は、サーバーが落ちる、ということは大問題でした。クラウドであれば、1台死んでもすぐ復活する。心理的なプレッシャーは10分の1くらいになりました。作業の自動化もしやすくなったので、以前は月に2、3回、2時間ほどかけてデータ更新作業をしていたのですが、今は5分ほどで終わります。AWSを使うと、サーバーの入れ替えがすぐにできるからですね。RubyからC言語へ実装の改善を本番に適用できたのは、AWSに移行してからです。それでようやく、問題だったレスポンス速度もかなり改善しました。夜間にバッチ処理を流しているお客様から「4時間かかっていたのが1時間もかからなくなったけど、何があったんだ」と、逆に心配されました(笑)。他にもポジティブなことはたくさんあって。社内的なインフラへの理解が進んだこと。インフラまでしっかり見て問題を解決していこう、という意識を持つエンジニアが増えましたね。AWS導入で新しい物を取り入れやすい雰囲気が生まれたので、今のチームでも色々と新しいことに挑戦しています。先日からSlackをチームで使っています。以前はGoogleハングアウトなどを使っていたのですが、チャットベースのコミュニケーションをもっと良くしたいなという話があって。Slackを導入して最初に連携させたのは、GitHubの通知でした。プルリクエストやコメント、リポジトリへのpush等の通知がSlack来るというベーシックな使い方です。▼SlackにGitHubの通知を集約(内容はイメージです)チャットに通知が入ってくるので、特にプルリクエストへのコメントに対するレスポンス速度が、感覚的にはチャットレベルの早さになりました。この部分は開発フローの中でボトルネックになりがちなのですが、回答待ちが減ったので効率的なりましたね。他には、チームのドキュメント共有にesaを利用しているのですが、そのドキュメントの作成・更新通知もSlackで受け取っています。Slack用のbotをひとつ動かしています。駅すぱあとWebサービスを利用したサンプルのようなbotなのですが、「帰りたい」とつぶやくと帰りの電車を案内してくれたり、開発に必要な駅コードの情報を教えてくれたり、結構便利に使っています。私は2014年に新卒で入社して、見川と田邊のチームに入りました。私が取り組んでいるプロジェクトのひとつに、駅すぱあとWebサービスの使い方が記載されている「リファレンス」をより良くしていこうというものがあります。GitHubを選択した理由は、リファレンスのソースコードをバージョン管理したい、リファレンスの文言確認を簡潔にしたい、デプロイを自動化したい、という3つの要望を解決できるからです。営業チーム、カスタマーサポートチーム、開発チームから少人数で構成されたプロジェクトメンバーがGitHubのアカウントを持っています。更新作業は開発者がするので、文言もこちらから提案するのが早いんですよね。実際にお客さんに会っているメンバーにも意見をもらいたいので、それを効率的に行うためにこのような方法を取っています。リファレンスの文言を変更する時に、いちいちチャットやメールにコピペして確認するのは、想像しただけで大変そうです...。実際にマージされるソースコードをベースに文章を決めていったほうが、漏れも無駄もありません。▼ソースコードを見ながら、GitHub上で営業やカスタマーサポートとやりとり開発者ではない人がソースコードを見てプルリクエストを確認するのはハードルが高いのかもしれないのですが、その点はテスト用サイトを用意することで解決しています。テスト用サイトと本番用サイトのデプロイは、CIツールを利用してGitHubと連携させています。操作や見た目を確認してほしいときは、ボタンひとつでプルリクエストの内容がテスト用サイトに反映されます。マージされれば自動的に本番用サイトのデプロイが行われるため、運用は楽になりました。チームで運用するにあたって、「いつ」「誰が」「なぜ」ソースコードを変更したのか管理することは必須だと思います。GitHubは、バージョン管理+αで、運用が楽になる工夫を沢山盛り込むことができるので今のところ満足しています。今の駅すぱあとWebサービスの状態は「ようやくクラウドの上に乗って動き出した」という感じなんですよね。今後はより一層、クラウドネイティブな形で、サービスの質や運用の形態を変えていきたいです。私は今リファレンスの改善を行っていることもあって、よりユーザーにとって使いやすいサービスを追求していきたいです。エンジニアとしても、ユーザーの声をしっかり聞いていくことを目指しています。今後は駅すぱあとというサービスをより一層成長させてゆくために、新しい可能性をどんどん探っていきたいですね。あとはプロダクトポリシーとして、技術的に真っ当なものを作る。ここはチームでしっかりと取り組んでいきたいと思っています。情報の構造化はマインドマップ生成AIツール「Mapify」一択。毎週の新着記事を無料でお届けします!プライバシーポリシーに同意しました。情報の構造化はマインドマップ生成AIツール「Mapify」一択。