SOW EXPERIENCEのエンジニアリングのご紹介

完全子会社となったSOWのエンジニアリングに関して

こんにちは。CTOの柳瀬です。既報の通り、3/12付でソウ・エクスペリエンス株式会社(以下SOW)に弊社グループに加わって頂きました。 SOWは、体験ギフトを取り扱う会社です。店頭や通販で売られている体験ギフトのカタログをギフトとして渡し、受け取られた方は、カタログから好きな体験を選び体験できる、という仕組みになっています。

ギフティのエンジニアリング組織は、自己組織的、自律的であることや、お互いに知見を贈り合うことを大事にしたいと考えています。そのため、SOWに関しても引き続き独立的に運営して頂くことを期待しつつも、エンジニア目線での知見の共有などは上手くやっていければと考えています。

そのために、SOWのエンジニアリングについて理解すべく、マネージャーの山村さん(以下、敬称略)にオンラインでお話を伺いました。この記事ではそちらの内容をシェアさせて頂ければと思います。

柳瀬 : 本日はどうぞよろしくお願いします。早速ですが、SOWさんにはどんなプロダクトがあるのか教えていただけますか？

山村 : プロダクトは1つなのですが、以下の4つの機能があります。

• ECサイト
• 社内向けの業務システム
• プレゼントを受け取った側の体験を予約するシステム
• 体験施設側の予約を管理するシステム

また、機能別の業務の割合としては、社内向けの業務システムが6割を占めており、ECサイトが3割、残りで1割というようなイメージですね。

柳瀬 : 1つのプロダクトに複数の機能があるんですね。機能の中ですと、ECサイトはイメージしやすいのですが、社内の業務システムについて詳しく教えていただきたいです。

山村 : 社内の業務システムの役割は3つあります。

• 商品や体験の定義（どのカタログが何の枠組みなのか）を管理する機能
• 購入商品を発送するフローの機能
• 予約を受け付けて、加盟店とやりとりをして確定するまでの機能

柳瀬 : 発送するまでの業務を自社で対応していると伺っているのですが、発送関連の業務は苦労も多いと思います。3PLへのアウトソースなどは検討したりはされなかったのでしょうか？

山村 : パッケージのデザインにこだわる社風なのもありつつ、アウトソーシングすると費用の問題が発生してしまうという点もあり、 社内で内製化していく流れができていました。社内のスペースも半分ぐらいが、発送スペースになっています。

特に問題になるのが、発送時に紙のチケットに有効期限を印字するため、カタログの作り置きができない点です。他にもラッピングへのこだわりや、メッセージカード、熨斗への対応なども必要になることから、内製の方が合理的という判断をしています。

参考までに、現在の業務フローの概要は下記です。

柳瀬 : そのあたりは物を扱っている業務ならではの悩みですよね。ギフトを受け取られた方が受け取るカタログは、基本は紙のカタログになるのでしょうか？

山村 : カタログには大きく分けて2種類あって、様々な体験が含まれている総合版と、それ以外のいわば特別版（個室スパシリーズなど）に分かれています。

総合版にはご利用可能な体験を網羅する冊子が同梱されていて一覧性が高いのですが、業務としては、内容に変更が合った場合は、刷り直さないといけないというデメリットもあったりします。こちらについてはデジタル移行を議論しているところです。 特別版では、必ずしも全ての体験を冊子上に掲載することはせず、ウェブでの閲覧がメインとなっています。

柳瀬 : なるほど、デジタル移行を進めていこうとしていらっしゃるところなんですね。

山村 : はい、その流れもあり、2年前に予約システムをVue.jsで一から作り直しました。ギフトを受け取った方が使う仕組みということで、引き続きよりよいものにしていきたいなと思っています。

柳瀬 : ギフトサービスとしては受け取られた方の体験はとても大事ですしね。ちなみに、ギフトを受け取った側の方が体験の予約を入れた後、SOWさんのほうで施設側に予約を取るということをされているんですよね？

山村 : そうですね。お客様が体験を予約(リクエスト)したら、予約チームが施設側に連絡をとって予約を確定させています。

柳瀬 : そこの業務結構大変そうですよね・・・

山村 : 予約件数的にもかなり多いので、そこは大変ですね。ただ、ギフトを受け取られた方の体験を良くするためなので、僕らが汗をかくべき所かなとも思います。

柳瀬 : 確かにそうですね。ちなみに、施設側のキャパの問題で予約取れなさそうな状況ではどう対応されているんですか？

山村 : 施設と連絡して別の日のご案内などをする場合もあります。また、空きがないとわかっているケースでは、予約サイト側で申し込みができないように調整しています。

柳瀬 : なるほど、そこでコントロールしてるんですね。僕らもそうなんですが、折角のギフトを受け取った方にはいい体験をして頂く必要がありますものね。

技術面

柳瀬 : システム目線での課題感や改善したい点は何かありますか？

山村 : システムとしてはもう10年経っているものなので、不自然な設計になっている部分があったりしますね。 大きなリファクタリングをしたい気持ちもあるのですが、なかなか難しいところです。 また、新規で一気に作り直したい気持ちもありますが、それも難しいので、少しずつリファクタリングしていくのが良いのかなと思っています。

柳瀬 : そのへん悩みますよね。ギフティの場合は、機能単位での刷新を行うアプローチを取ることが多いです。

山村 : 確かにそれがいいかなとも思っています。 あと、システム面ですと実店舗でもギフト売っており、購入されてからの有効期限を印字する必要があります。そのため、購入されたタイミングで実店舗からSOWに連絡をいただくのですが、その連絡手段がFAXなんですよね・・・。 OCRで番号を読み込んで取り込むということはしているのですが、FAX周りをもうちょっとどうにかできないかは考えたいところですね。

柳瀬 : サーバサイドにRailsを使っていらっしゃいますけど、そのへんを選定された理由や継続される理由はありますか？

山村 : 創業当初からRailsを利用していたので、その流れから利用しているという側面もありますが、バックエンドとしては、Railsが便利だなと感じています。

柳瀬 : なるほど。インフラはAWSですか？

山村 : AWSのOpsWorksを利用しています。 かなり安定して良さは感じているのですが、Rubyのバージョンアップへの対応が難しいケースなどがあり、将来的にはコンテナ移行などを検討していたりもします。

柳瀬 : そういった技術選定はどう進められているんですかね？

山村 : Vue.jsを選んだときは、社内にモダンフロントの知見がそこまで強くない中、CTO遠藤さんの知り合いがVue.jsに詳しかったため、短期で業務委託で入ってもららいつつ、Vue.jsに関して他メンバーの育成含めご協力頂きました。

開発手法など

柳瀬 : 開発手法としては、スクラムで進められている形でしょうか？

山村 : 簡易的なスクラムを組んでいるイメージです。 流れとしては、四半期に一回、システム部が各部署を回って、どんな機能が欲しいかをヒアリングする場を設けています。 そこでリストアップしたものを、スケジューリングして、案件をTrelloで管理をして、進めてみています。

悩んでしまうものについては、どんな構成にするかのラフを描いてみて、チーム内で相談してから、ざっくりスケジュールを立てて進めるというイメージですね。

柳瀬 : 見積もりは、タスクをメンバーにアサインした段階で、その方にお任せというイメージですかね？

山村 : そうですね。 以前までは、チーム内で相談しながら工数を見積もっていたのですが、なかなか上手くはまらなかったので、今は作りながら、見積もりを立てていくような流れになっていますね。

柳瀬 : 四半期ごとのヒアリングのタイミングと、個別のスケジュール見積もりの整合性を取るのが難しいように感じるのですが、そのあたりはどういう動きを取られているんですか？

山村 : ディレクターの業務範囲になってくるのですが、まず大きめのタスクをカレンダーに入れて、そこに対して遅れているようであれば、他の方にアサインを変更するなどして微調整をしてなんとかやってますね。スケジュールから遅れるということもたまにあります。 一番最初の本当にざっくりとした工数見積もりは、私の方で行っています。

まとめ

という訳で、SOWのエンジニアリングについて色々とお話を伺う事ができました。ギフトを受け取られた方への体験に気を使う部分など、同じギフトサービスとして共感する部分が色々とありました。また技術的にも共通点が多く、技術的な交流も今後進めて行ければと考えています。

山村さん、ありがとうございました! そしてSOWの皆様、改めてよろしくお願いします!