コストを小さく、時間を大きく　旅行検索No.1のノウハウで開発したSaaSサービス

フォルシアのメインプロダクト「Spook」とSaasサービス「webコネクト」

龍島広人氏（以下、龍島）：「受託メインだった会社がSaaSの自社サービスを作る時にどんなことを考えたか」を龍島から発表します。よろしくお願いします。

まず、自己紹介をします。龍島広人と申します。フォルシア株式会社でWebエンジニアをやっていて、自社SaaSプロダクトの「webコネクト」の開発チームのリーダーをやっています。フォルシアには新卒で入って、今は丸5年で、2021年に新卒6年目になります。

実際に仕事で使っている技術は、WebアプリケーションではTypeScriptやNode.js、React、Next.jsなどJavaScript系のものを使っていて、データベースではPostgreSQLを使っています。アプリケーションのインフラ部分のコンテナ技術にすごく興味があって、KubernetesやDockerを積極的に採用しています。

DevOpsは、社内ではGitLabを使っていて、GitLabを使い倒すためにGitLab CIをがんばって動かしています。

今日はどんな話をするかというと、フォルシアのメインプロダクトの「Spook」と、あとはSaaSのサービスで「webコネクト」というものを立ち上げたので、開発の経緯などをお話できればと思います。

旅行業界の検索部分に特化した「Spook」

まずメインプロダクトのSpookですが、アプリの画面があるとわかりやすいと思ったので、ちょっと出してみます。これはJTBさまのサイトですが、イメージは左側に絞り込む条件があって、ポチポチ押すと右の画面がどんどん絞り込まれていって、旅行の宿や旅行先のツアー検索ができるというのがメインの機能のプロダクトです。

旅行のデータは複雑なんですが、速く、パフォーマンス良く検索することを得意としています。今お見せしたJTBさまをはじめとして、旅行系のお客さまの導入が多いです。それ以外もあるんですが、多くを旅行系が占めています。

SpookはECサイトで、特に旅行の検索部分に特化したプロダクトです。いろいろな旅行会社のプロダクトを作っているのでノウハウが溜まってきていて、短納期でより高品質なアプリを作れることを売りにしています。売り切りではなく、運用・保守、その先の提案までしっかりとサポートしていくことで、お客さまの検索部分の課題をトータルで解決しています。

このあとお話しすることと関わってくるんですが、Spookの場合、インフラは基本的には自社で持っていません。インフラ部分は管理せずに、自分たちの強みである検索のアプリケーションにリソースを集中して、より質の高いアプリケーションを作っているのがSpookです。

旅行検索の知見を活かした共通プラットフォーム「webコネクト」

これ（Spook）は半ばオーダーメイドで作っていたんですが、これまで培ってきた旅行検索の知見もあって、もっと共通のプラットフォームみたいなものができるんじゃないかなと常々考えていました。それをなんとか実現しようとしているのが、旅行検索のプラットフォームである「webコネクト」というSaaSのプロダクトです。「webコネクト」はSaaS型の旅行検索プラットフォームで、共通化された機能を提供しています。

これは名鉄観光さまのサイトなんですが、宿だけではなくて、航空便やその下の宿を選んで、一緒に予約できます。これをポチポチ押すと画面が絞られる、というプロダクトです。

「共通化」「変化への対応」「インフラの管理」3つの課題

このSaaSのサービスを作っていくうえで難しかった点や、どういう課題があったかというと、一番は共通化です。

これまで、なぜ共通のプロダクトができなかったというと、各お客さんの旅行データは膨大で複雑でデータのもち方や、運用方法や扱っている商品も違うので、それを1つのプロダクトとして、統一のフォーマットで扱うのはなかなか難しいものがありました。共通化して扱うのが1つの大きな課題です。

また市場や顧客環境の変化に対応するというのもあります。特に旅行業界は早く変化をしていて、旅行業界自体に大きな変革があったり、コロナ禍で旅行の需要が落ち込んだと思えば、いきなりGo To キャンペーンが始まったりと、システムの対応をその都度しなきゃいけないこともありました。

そういった環境変化で、機能を追加したり変更したり、新しい機能が必要になったりということがよく起こります。なので、それに対していかに素早く対応していけるか、素早く機能を提供できるかが重要になってきます。変化に対応して、かつお客さまがどういうものを欲しがっていて、それをどう提供すればwebコネクトが採用されるのかという見極めも非常に重要で、難しいところだと考えています。

また、これはどちらかというと弊社独自の気がしますが、運用する範囲が拡大していく中で、SaaSのサービスをインフラもきちんと自分たちで管理していくととなると、新たにやるべきことが増えるので、そこをどうやっていくかが課題でした。この3つの課題をどう考えていったかを話していければと思います。

オリジナルで作る部分を小さく、共通化できるところを大きく

まず共通化ですが、webコネクトのサービスのイメージとしていろいろな旅行会社があります。いろいろなデータをもっているんですが、それらを取り込める共通のフォーマットに変換して、webコネクトの中に入れて、いろいろな設定をすると、各社用に画面がカスタマイズされて、各社が出したい画面が出せます。

結局この部分を一個一個作ったのがSpookだったのですが、このコアの部分を1個のプラットフォームとして作りたいとなると、各社独自で作る部分をいかに小さくして、webコネクトという真ん中の部分をいかに大きくしていくかが課題になります。

これをどう実現してきたかというと、これまでの旅行の検索で培ってきた、「旅行会社さんはこういうことができたら、検索部分で満足するはずだよね」「旅行データはだいたいここのポイントだけを押さえておけばなんとか共通化できるよね」など、ドメインの知識やこれまでのノウハウの蓄積を使いながら、これだったらできるだろうというフォーマットを作って、それを用いて共通化しているという、かなり泥臭い共通化をしています。

リファクタリングと顧客との対話で変化に対応する

また、変化への対応のところで、技術的な面ではマイクロサービスアーキテクチャを採用しています。これは、先ほどのものだと航空便と宿を組み合わせる、みたいなことをやっていたんですが、例えば他の会社で乗車券と宿泊予約を一緒に売りたいですとなったときに、我々は部屋を検索するコンポーネントと、宿を検索するコンポーネントをマイクロサービスとして分けていて、列車なら、列車のマイクロサービスのコンポーネントを作れば、あとは組み合わせればそのサービスが実現できますねみたいなことをうまくやろうとしています。

それぞれのコンポーネントの責任を明確化して、変化に強く、拡張性の高いものを作ろうとしています。ちなみに、このOpenAPIについては私が2020年のアドベントカレンダーで書いたので、「フォルシア OpenAPI」などで調べてもらえれば出てくると思います。

また、継続的なリファクタリングというところで、技術的負債を溜め過ぎると結局変化に弱い、すぐに手を入れられないアプリになってしまうので、それは常に意識しています。これはいろいろなところで語られることだと思いますが、リファクタリングをするためにテストを充実化したり、TypeScriptを導入したりしています。

いかに容易に変更できるようにしていくかはきちんとリファクタリングの時間を取って、次の機能を開発するように意識しています。

また、変化への対応というところで、将来的なニーズはどういうものが出るんだろうというところですが、これはフォルシアの非常に特徴的な部分だと思うんですが、顧客との対話を重視しています。開発者や、実際に手を動かすエンジニアが顧客と話すことですね。実際に手を動かすエンジニアが顧客の考えやニーズを深く理解することが大事だと思っています。

今後起こりうる変化や要望を先回りできるというのはもちろん、開発の方向性や技術選定をきちんと「お客さんはこう考えているし、こういうニーズがあって、プロダクトとしてもこう作っていくべきだよね」とそれぞれのエンジニアが理解した上で、大小の設計をします。例えば「この部分の文言はお客さんが分けたがると思うから、少し柔軟なフォーマットにしておこう」など細かい部分もお客さまと話したりして、ビジネスを深く理解しているということが大事だと考えています。

これはSaaSのサービスだから意識しているという話ではまったくなくて、フォルシアの基本的なスタンスです。Spookを受託開発でやっている時もまったく同じ考え方なので、それをwebコネクトでも受け継いでいます。

運用のコストを小さく、開発に割く時間を大きく

最後に、運用範囲の拡大についてです。運用する部分が増えたためにインフラを自分でもたないといけないという、先ほどの話ですね。これに関しては、クラウドをうまく利用しているのはもちろんのこと、開発環境と本番環境をできるだけ近づけるために、コンテナファーストで本番環境はKubernetes、開発環境はDocker Composeを使って、同じイメージを使って開発しています。

これで差を小さくすることで、デプロイを楽にしたり、本番でしか起きない問題のリスクを減らしたり、運用負荷を軽減しようとしています。またDevOps面では、CIをクリーンな状態に保って、検証用の環境へはCDでうまくデプロイしています。

これもやろうとすると時間がかかってしまうんですが、こういうことを投資して、時間を作って整備していったほうが、結果的に運用にかける時間を短くできるだろうと考えています。

まとめとしては、共通で利用できる部分を増やして、より多くの顧客に届けようと考えています。どう共通化していくかは、フォルシアは旅行の検索において一番経験やノウハウがあると自負しているので、受託で培ってきたそのノウハウとドメインの知識をフル活用しています。

変化に強いというところでは、変更容易性の高い状態を保つ。技術的なところでもそうですし、お客さんときちんと対話をして、我々が進める方向は合っているのだろうかとか、このプロダクトの向かう先はこれで合っていて、だからここではこういう設計にしよう、こう作っていこうと考えることで、より変化に強い状態を保てるんじゃないかなと考えています。

インフラまでやると運用コストが増えるんですが、開発に割く時間を大きくするために、コンテナ技術を使ったりCIの投資というところを削減せずに、実際に開発する時間をがんばって確保するという意識でやっています。では発表としては終了したいと思います。ありがとうございました。

（一同拍手）

司会者：龍島さんありがとうございました。私から1つ聞きたいなと思うんですが、Spookからwebコネクトへという流れの中で、プロダクトのオーナーシップが顧客から自社に移っていると思うんですね。そうなった中で、一番違うおもしろさってどこにありますか？

龍島：もちろん自分たちで決めていけるのがおもしろいところで、逆に言うとそれは決めていかなければいけないという部分です。どういうものを作っていくのか、イニシアチブが自分たちにあるのは大変なところですが、いろいろなお客さんに満足してもらう、良いサービスをユーザーに提供するために考えて、それを実現していけるというのはすごくおもしろいところだなと思います。

それが受け入れられなければ、もちろん使われないんですが、リスクに応じたメリットがあるのかなと感じています。

司会者：ありがとうございます。じゃあもう1問です。「チームリーダーとして、社内事例の少ないSaaSを進めるうえで気にかけたことはありますか？」。

龍島：チームの士気を高く保っていくというところなんですが、正直全部手探りです。わからないことだらけ、決まっていないことだらけで、あまり社内でも事例がありませんでした。ただそれは自分たちが開拓していけるということだと思うので、この会社の1例目、ゼロからイチのイチを作るんだという強い気持ちを持って行こうというところになる、フロンティア精神みたいなところですかね（笑）。

司会者：なるほど。

龍島：なのでチームとしてもけっこうそういうところに共感してくれる人が多く集まっていたので、なんとか今もリリースができています。今のところはうまくいけているかなと思っています。

司会者：開拓者精神溢れるチームメンバーで、そういう雰囲気のチームを作っていったということですね。

龍島：そうですね。

司会者：ありがとうございました。