1988年に生まれた「駅すぱあと」

駅すぱあとが生まれたのは1988年。最初はMS-DOSという、マイクロソフトのWindowsの前のOSに対してのスタンドアローンのアプリケーションでした。その後、今も続いているWindows版を出し、その周囲にモバイル系のアプリや、提携Webサービスを作っていきました。

サービスの内容としては、乗り換え案内、経費精算、そして不動産会社向けの「新宿駅から20分以内の物件を探す」というような機能提供などがありますね。

サービスの裏側としては、事業者からの情報提供や自分たちの足で調べている部分が多いです。弊社の場合は駅の出口やその周囲は、実際に社員が歩きまわって確認します。

####▼経路検索システムのパイオニア「駅すぱあと」

弊社は基本的になんでも内部でまかなっています。開発、営業、マーケ、カスタマーサポート、すべて内部にありますね。社員の割合としては新卒がかなり多く、8割ほどはいると思います。40年続いているソフトウェアベンダーで、こういう会社ってなかなかないですよね。

AWS導入を機に「外のサービスをブロック」していた会社が変化

弊社は、好調だった時期が長かったこともあって、新しいことを取り入れる感度が鈍っていた時代がありました。90年代後半から2000年代中ごろですね。それをどうにかしなくてはいけない、という気持ちがあったので、AWSを導入する時には周囲にも興味を持ってもらう努力をしました。

まず社内のライトニングトーク大会で長めに話す枠をもらって説明したことで、興味をもってくれる人が増えました。

よく言われたのは「それでどれだけ安くなるの？」って。でもそうじゃない。お金のことだけじゃないわけですよ。クラウド化することで業務を効率化できるはずだ、という確信があったので、それをきちんと説明しました。

新しいことを取り入れたい時には、それをきちんと説明できるかどうかも大事ですね。

AWS導入がひとつのきっかけになって、会社が変化していきました。以前は外部サービス利用のハードルが高く、エンジニアの選択肢を狭めていたというか。でもそれじゃダメだ、という危機感はすごくありました。

結果的にAWS導入をきっかけに社内の考え方も変化して、新しいものを導入する敷居が下がりました。そしてその後、Google Appsが全社導入されたり、GitHub、Jenkins、Slackなどを導入して、どんどん効率化・自動化を進めていきました。

ニーズに合わせてまずはスピード重視でサービスを開発

私は2000年に新卒で入社してから、ずっとエンジニアをしています。最初は企業向けのサービスの開発保守、その後iモードのアプリケーション開発などを経て、現在はサービスプラットフォーム開発のチームでリーダーをしています。

入社した時は、駅すぱあとが企業向けにサービスを拡張するタイミングでした。1998年からYahoo!さんの乗り換え案内のエンジンを提供し始めたのですが、他の個別の企業さんのニーズにも応えていくためのサービスが必要でした。

そこでWindowsアプリケーションに組み込むSDKと、ブラウザベースで企業内で利用するイントラネットを用意して、それが形になって出てきた頃でしたね。

私たちの企業向けサービスは「経路を調べて交通費を精算できる」という機能を皮切りに発売して、一気に導入企業数が伸びていきました。

その後転機になったのが、APIベースのサービス「駅すぱあとWebサービス」の開発を始めたことです。2009年ごろに営業のニーズから企画が立って2010年にローンチし、今に至るという感じです。

弊社には法人のお客様が数多くいらっしゃるので、新しいサービスを作る時もまずはざっと形を作って、お客さんと一緒にぐりぐり回して、ようやくまともなものが1年くらい後に出来上がる。思い返せばいつもそういう感じなんです。

駅すぱあとWebサービスの時も同じで、結果的にはリーン・スタートアップ的な発想で最初はスモールスタートし、お客様のニーズを聞きながらあるタイミングでスケールのためにすべて作り変える、という変遷を辿りました。

最初は少ない人数で、いかに早く開発するかを重視した

駅すぱあとWebサービスを開発した時には、3人という少人数のチームで、いかに早く作るかということを重視しました。他のサービスが使っているサーバを間借りして、ありあわせのような感じで。

開発にはRubyを使いました。内部エンジンとの関係でC言語の方が親和性が高かったのですが、実装コストがかなりかかるんですよ。最初からそうすると3人では回らないし、タイミングを逃してしまう。

あとは作りながら仕様を決めていた部分も大きかったので、レスポンスを見ながら「こうしよう、ああしよう」と作りやすいRubyを選びました。当時、社内のプロダクトではまだあまりRubyは使われていませんでしたね。

外部エンジニアにもお願いせず、すべて社内で開発しました。というのも、駅すぱあとのノウハウがちょっと特殊で、新しい方を教育するだけで半年くらいはかかってしまう…。

「経路検索」というビジネスが独特なんですよね。分解するとかなり細かくて、時刻表、運賃、区間、徒歩…ひとつの部品だけで見てもよくわからなくて、まずは構造を理解しないといけない。

説明だけで理解するのは難しくて、SDKでも何でも、まずは何か作ってみないとよくわからないという。マニュアル化もあまりされていないですね。コアなエンジンの部分なんて、もうプロ中のプロ、みたいなベテランが2人で支えていますし。

スピード重視で作ったものを、いつスケールに向けて作り変える？

3人で半年ほどひたすら開発して、リリースしたのですが、お客様が増えていく中でどんどん問題が出てきました。不具合が出たり、レスポンスが遅くなったり。間借りしているサーバーがスケールに耐えられないのではないかとう不安もありました。

これって、スタートアップとかでよく聞くお話ですね。最初にスピード重視で作ったものを、どのタイミングでリファクタリングするか。

一番大きかったのは、とにかくレスポンスが遅かったこと。社内向けのエンジンをRubyからHTTPで叩いていたのですが、お客様からのリクエストに対して内部では複数のリクエストをせざるを得ない部分があって。そこがボトルネックになっていました。

そこで、結果的にまずはレスポンス速度を改善するために、実装を変えていこうと。処理すべきところをすべて静的言語でまとめて、エンジンを直接叩いた方が早くなるので。

裏側がもともとC言語で書かれていたので、こちらもC言語に、ほぼ全部書き直して再実装していきました。大体5人で作業して、1年以上かかりましたね。

サーバーの間借りはもう限界！社内を説得し、AWS導入へ

サーバーも同様の問題を抱えていて、他のサービスも使っているサーバーに間借りしていていたんですよね。そうするとより優先度の高いサービスに引きずられて、こちらの意思が通りにくかったり…。本当はこうすればサービスが良くなるのに、という時に足踏みしてしまう部分がありました。

大規模な障害がトリガーとなって全体が止まってしまったことも一度だけあって。サービスが1ヶ所に集中しすぎていたんですね。そこで2012年終わり頃から、サーバーをクラウド化するためにAWSを導入する取り組みを始めました。

当時はAWSが東京リージョンをオープンして、東京で初めてのサミットを開催したばかりの頃でした。調べてみて、いけるという手応えがあったんですね。ただこれまで10年以上続けて来た仕組みを大きく変える、ということで、社内の説得は簡単ではありませんでした。

AWSのアーキテクトの方に来ていただいて、3回社内向けに説明会をしてもらって。あとは少しずつ、各部署の技術的に明るい人を巻き込んでいきました。実際、当時の社内エンジニアは皆同じところで困ってたんですよ。

サーバー周りのスケールや、負荷の部分。モバイル系のサービスもオンプレに近い形で運用していたので、瞬間的な不可の増大に耐えられなかったり。

それをAWSで解決できるかもしれない、ということで一気にAWSファンが増えて、導入が後押しされた感じですね（笑）。

※実際にAWSへの切り替えの時に起こった問題、導入効果、そしてそれをきっかけに社内がどう変わったかということを具体的にお伺いした後編はこちらです。