現在はCTO 兼 アートディレクター！始まりはバンド活動から

今はCTOですが、もともとキャリアの始まりはデザイナーでした。以前はバンドをやっていたので、フライヤーやWEB、グッズなどを他のバンドのものも含めてデザインしていたんですよね。WEB制作のコーディングはエンジニアさんに頼んでいたんですが、ある日自分の作ったデザインを元にアニメーションをつけてもらったんです。その仕上がりを見て「もっとこう、滑らかに！」という想いが湧いてしまい、自分でもプログラミングをやりたくなって。そこからエンジニアとしてのキャリアが始まりました。

当時、少ない予算で付き合ってもらってたエンジニアさんにはこの上なく感謝しているんです。なので今は開発もやってデザインもやる、CTO兼アートディレクターをやらせてもらっています。

シンプルなチャットから始まった「接客ツール・Flipdesk」

SocketではFlipdeskというECサイトの接客ツールを開発しているのですが、一番最初のバージョンは3ヶ月ほどで3人で作ったECサイト向けのチャットツールだったんです。さっさとベースを作ってしまって、協力していただいていたクライアントさんと共に実際の効果検証をするところから始めました。

同時進行で「本当にチャット機能だけでいいのか？」「担当者がつけられないECサイトにはどう訴求する？」など、様々な議論を重ね、現在の「接客ツール」という形を作っていくことになったんです。チャット機能に加えて、お客様がサイトに来店した時に、条件に応じたメッセージを自動で提示する機能を備えているサービスです。具体的に言うと、特定のページを30秒以上見ている人にクーポンを発行していくような仕組みになります。当時はまだ名前もありませんでしたが、これがFlipdeskの始まりでしたね。

EC上でリアルな店舗の接客を実現するには、インフラ環境が課題

「シンプルなチャット」から「接客ツール」への方針転換が決まった時に、システムが受け入れる負荷の性格や種類がかなり変わりました。ユーザーのアクセス状況をリアルタイムに解析してそれに応じたアクションを実行するため、チャット機能に比べて考慮しなければならないことがぐっと増えたんです。ただサイトに商品が並んでいるだけではなくて、リアルな店舗のように絶妙なタイミングで「あなたにはこれがオススメです」「今年のトレンドはこれです」といったコミュニケーションが生まれることを目指していたので、それを実現できるインフラ環境の実現は急務でしたね。

そこで、それまで使っていたHerokuではこれから先は難しいのではないかと考えました。ただリリースして半年ほどは、機能追加に注力していて。開発体制も4人ほどでしたし、管理コストもほとんどフリーで簡単に使えるHerokuは非常に助かるんですよね。なので、いずれ迎える限界を理解しながらも騙し騙し使っていました。

ついにレスポンスが落ち始めた！AWSへの移行を決意

Herokuから何に移ろうかと考えた時にIBM、MS Azureなど様々なサービスを見ていたのですが、ちょうどInfinity Ventures SummitでAWSのサポートの方と知り合って。AWSの強いところだけではなくウィークポイントも含め、ざっくばらんにいろいろな話を聞かせてもらいました。そしてちょうどその頃、Flipdeskのコンテンツ配信レスポンスが鈍くなりはじめており、「Herokuも限界かな」と感じ始めたんですね。

ECサイトのレスポンス速度って非常に重要なんです。クライアントさんは秒単位で接客の計画を立てています。離脱率を下げるのがFlipdeskを導入いただく目的の一つですから、離脱する前にコンテンツを出さないといけません。2秒で帰ってしまうかもしれないお客様にどれだけ早くレスポンスを返せるかはツールのキモでした。そのキモの部分が遅くなってしまったんです。これは早く解決しなければならない、今こそAWSを導入するタイミングだろうと思い、導入を決定しました。インフラを担当する開発者も1人つけて、一気に入れ替えをしていきましたね。

レスポンス速度は、WEBであればどんなサービスでも重要な指標だと思うのですが、HerokuからAWSに移行することでこの課題は解決に向かうだろうと確信していました。Herokuはアメリカのバージニアにリージョンがあって日本にはないんです。 AWSは東京にもリージョンがあるので、そこに移せば大きく改善が見込めるだろうと。

パフォーマンスは100倍に！将来を見据えた投資が成功

今後の事業の進め方の観点から言っても、AWSを選んだことは正解だったと思います。Flipdeskの今後にとって重要なのは、いかに継続してデータを分析し、より良い接客につなげていくのかということです。得たデータをどう今後のサービスに活かしていくかを考えていく上で、例えばビッグデータを扱うかもしれません。その時に、インフラがAWSだとRedshiftも含めてどの分析プラットフォームを使うのかをハンドリングしやすいんです。

もちろん、HerokuからAWSに変更する上でのハードルもありました。例えばAWSの管理コストをいかにHerokuの水準まで下げるかという点です。今回はAWS Elastic Beanstalkを使うことで主要な運用業務を自動化したため、管理コストは20％程度の増加に抑えることができました。今後より柔軟性が求められるフェーズになった際には、AWS OpsWorksでの環境自動構築に切り替えることもできます。 このように状況に応じた様々な選択肢がとれることもAWSの良さだと思います。
実際にAWSに変えてからレスポンスも100倍ほどに上がり、僕たちとしては安心しました。クライアントさんにも「キャンペーンやってもサクサクじゃないですか！」という声をいただいています。パフォーマンスチューニングに対しても柔軟なインフラなので、今までは「この分析はリアルタイムでは重くて無理だろうな … 」と考えていたアイデアも、どんどん試せる土壌ができましたね。

ECサイトならではの接客を確立するプラットフォームを目指す

Flipdeskを開発する上でもともと持っていた課題意識として、リアル店舗であんなに丁寧に接客しているのに、ECでは全く接客要素がないなんておかしいと考えていたことがあります。接客のないECサイトって、自動販売機と同じようなものですよね。僕らがまだ提供できていないものも含めて、様々なアクションを試すことができるフェーズにあると思っています。

ただ、リアル店舗とECサイトでは、訪れるお客さんの数も性質も全く違います。リアルな接客の中にもヒントを見出しながら、ECならではの接客方法を確立していくためのプラットフォームになりたいですね。そのためにはやはり、いかにレスポンスを上げて気持ちの良いアクションをお客様に提供できるかという視点は非常に重要です。多少インフラコストがかかったとしても、お客さんの求める「サクサク動く」パフォーマンスを実現していくことは、今後も非常に大事になってくると考えています。