▼左から 見川さん、丸山さん、田邊さん

実際のサービス切り替えは、やはり一筋縄ではいかない

見川　実際にサーバーをAWSに切り替える際には、互換性を保ちながら全部一気に変えてしまうことにしました。最初にまず、駅すぱあとWebサービスの無償版だけを移行して試してみようと。自力でAWSの各サービスの勉強を始めて、AWSのアーキテクトの方に相談しながら、6ヶ月ほどかかって準備しました。

いざ切り替える時は、それはもう不安でした。お客様がいる中で、無言で切り替えるわけにはいかない。営業とも相談しないといけない。お客様にもそれぞれの都合がありますし…。もうナーバスでしたね。そんな感じで泥臭く作業して、2013年の初めに最初の切り替えを行いました。

サービスが巨大なので、やはりすんなりはいかなくてですね…。結局のところ、障害の発生があって、お客様には本当に申し訳なかったです。ただ結局その障害は、技術的には正当性がある部分で起きていたんですよね。

データ構造の部分で、結論から言うとお客様の方でこちらで想定していない使い方でデータを取っていたので、切替によってそれができなくなって障害につながって。技術的に正しいことが直接通用するわけではない、ということを身をもって学びました。

AWSの導入によって、運用負荷もレスポンス速度も大幅改善

田邊　私は2006年に新卒で入社して、AWSへの切り替えの際には、見川と一緒のチームで開発を行っていました。

AWSに移行したことで一番大きかったメリットは、運用負荷が下がったことです。以前は、サーバーが落ちる、ということは大問題でした。でもクラウドであれば、1台死んでもすぐ復活する。心理的なプレッシャーは10分の1くらいになりました。

作業の自動化もしやすくなったので、以前は月に2、3回、2時間ほどかけてデータ更新作業をしていたのですが、今は5分ほどで終わります。AWSを使うと、サーバーの入れ替えがすぐにできるからですね。

RubyからC言語へ実装の改善を本番に適用できたのは、AWSに移行してからです。それでようやく、問題だったレスポンス速度もかなり改善しました。夜間にバッチ処理を流しているお客様から「4時間かかっていたのが1時間もかからなくなったけど、何があったんだ」と、逆に心配されました（笑）。

他にもポジティブなことはたくさんあって。例えば社内的なインフラへの理解が進んだこと。インフラまでしっかり見て問題を解決していこう、という意識を持つエンジニアが増えましたね。

Slackに開発周りのツールを結集させ、業務をどんどん効率化

田邊　AWS導入で新しい物を取り入れやすい雰囲気が生まれたので、今のチームでも色々と新しいことに挑戦しています。たとえば先日からSlackをチームで使っています。以前はGoogleハングアウトなどを使っていたのですが、チャットベースのコミュニケーションをもっと良くしたいなという話があって。

Slackを導入して最初に連携させたのは、GitHubの通知でした。プルリクエストやコメント、リポジトリへのpush等の通知がSlack来るというベーシックな使い方です。

▼SlackにGitHubの通知を集約（内容はイメージです）

チャットに通知が入ってくるので、特にプルリクエストへのコメントに対するレスポンス速度が、感覚的にはチャットレベルの早さになりました。この部分は開発フローの中でボトルネックになりがちなのですが、回答待ちが減ったので効率的なりましたね。

他には、チームのドキュメント共有にesaを利用しているのですが、そのドキュメントの作成・更新通知もSlackで受け取っています。

また、Slack用のbotをひとつ動かしています。駅すぱあとWebサービスを利用したサンプルのようなbotなのですが、「帰りたい」とつぶやくと帰りの電車を案内してくれたり、開発に必要な駅コードの情報を教えてくれたり、結構便利に使っています。

営業とGitHubでコミュニケーションし、サービスを改善する

丸山　私は2014年に新卒で入社して、見川と田邊のチームに入りました。私が取り組んでいるプロジェクトのひとつに、駅すぱあとWebサービスの使い方が記載されている「リファレンス」をより良くしていこうというものがあります。お客様と直接関わる営業チームとカスタマーサポートチームのメンバーを巻き込んで進めているのですが、そこのコミュニケーションに GitHub を使っています。

GitHubを選択した理由は、リファレンスのソースコードをバージョン管理したい、リファレンスの文言確認を簡潔にしたい、デプロイを自動化したい、という3つの要望を解決できるからです。

営業チーム、カスタマーサポートチーム、開発チームから少人数で構成されたプロジェクトメンバーがGitHubのアカウントを持っています。更新作業は開発者がするので、文言もこちらから提案するのが早いんですよね。でも実際にお客さんに会っているメンバーにも意見をもらいたいので、それを効率的に行うためにこのような方法を取っています。

リファレンスの文言を変更する時に、いちいちチャットやメールにコピペして確認するのは、想像しただけで大変そうです…。実際にマージされるソースコードをベースに文章を決めていったほうが、漏れも無駄もありません。

▼ソースコードを見ながら、GitHub上で営業やカスタマーサポートとやりとり

開発者ではない人がソースコードを見てプルリクエストを確認するのはハードルが高いのかもしれないのですが、その点はテスト用サイトを用意することで解決しています。

テスト用サイトと本番用サイトのデプロイは、CIツールを利用してGitHubと連携させています。操作や見た目を確認してほしいときは、ボタンひとつでプルリクエストの内容がテスト用サイトに反映されます。マージされれば自動的に本番用サイトのデプロイが行われるため、運用は楽になりました。

チームで運用するにあたって、「いつ」「誰が」「なぜ」ソースコードを変更したのか管理することは必須だと思います。GitHubは、バージョン管理+αで、運用が楽になる工夫を沢山盛り込むことができるので今のところ満足しています。

今後も新しい物を取り入れながら、あるべき技術の形を追求する

田邊　今の駅すぱあとWebサービスの状態は「ようやくクラウドの上に乗って動き出した」という感じなんですよね。今後はより一層、クラウドネイティブな形で、サービスの質や運用の形態を変えていきたいです。

丸山　私は今リファレンスの改善を行っていることもあって、よりユーザーにとって使いやすいサービスを追求していきたいです。エンジニアとしても、ユーザーの声をしっかり聞いていくことを目指しています。

見川　今後は駅すぱあとというサービスをより一層成長させてゆくために、新しい可能性をどんどん探っていきたいですね。あとはプロダクトポリシーとして、技術的に真っ当なものを作る。ここはチームでしっかりと取り組んでいきたいと思っています。