フレンバシーのシステムをどのようにして作ってきたか語ります（その３）

前回までにフレンバシーの初期からどのようにシステムの導入や開発をしてきたのかについて説明してきました。一部副業エンジニアに手伝ってもらったこともありましたが基本ほとんど高見沢とデザイナーさくらちゃんで作ってきました。エンジニアリソースでいうと私だけなのでいろんなことが勉強になる反面、障害が起きれば自力で解決せざるをえない状況で何度もピンチに追い込まれました。他所で仕事をしながらフレンバシーの開発もしていたので、エンジニアを採用できる会社が本当に羨ましくて仕方がなかったです。

RailsのオープンソースEC・Spreeの導入

次の話もほぼほぼ一人で開発を行ったのですが、2019年についにVegewelに第3の事業であるECを導入することになったので様々なECパッケージの比較を行いました。ECのオープンソースというとEC Cubeが有名ですが、こちらはPHPのツールです。ここまでオールRubyで作ってきているVegewelにはRubyやRailsに組み込めるオープンソースのECが必要でしたし、お金をかけないソリューションはもはやほぼ一択しかなかったといえます。

それがSpreeです。Solidusというのもありますが、Spreeの後継なので中身は大分一緒です。ただ、2019年当時で情報が枯れているのはSpreeの方だったので迷わずSpreeにしました。

オープンソースとはいえ、そのまま使うことは出来ず、モンキーパッチやクラスのオーバーライドを多用することでなんとか思っているような挙動に持っていくことが出来ました。決済システムに関してはBASEが運営するPAY.JPを使いたいと考えていたのですが、色々機能が足りずSpreeに組み込めないので断念しました。VegewelMarchéのローンチは2019年の5月初旬を目指してましたがギリギリまで導入にチャレンジしたけど難しくて結局Stripeにしました。StripeはSpreeのデフォルトで決済システムが用意されていたのでなんとかなります。加えてSpreeにはspree-i18nという多言語対応機能もあるのですがURLのルーティングに微妙に不具合があって修正するのにかなり苦労しました。このときの話もQiitaに書いています。

RailsにオープンソースECのSpreeを導入と注意点（2019年度版） - Qiita

カードだけじゃなくてコンビニ決済や銀行振込もKomojuというサービスを導入して使えるようにしました。KomojuはRailsのGemは存在するのですがバージョンが古くて、Komoju運営するデジカ社でもメンテを放棄している状態だったので手作業でソースを修正しました。導入に苦労をしたにも関わらず、サービスがスタートしてから気がついたのですが、コンビニ決済（銀行振込も）というのはユーザーが購入してから実際にコンビニで入金したかを追わないと発送ができないので正直管理コストが半端ないので、早急に後払い決済に切り替えることになりました。

後払いドットコム

後払い決済はコンビニ決済、銀行振込を選択してもらってから当社で商品を発送しますが、後追いで後払いドットコムという会社から入金用の通知書を送ってもらってこちらの書類を持って銀行・コンビニで入金してもらうという流れになります。つまり購入代金を保証してくれるサービスなのです。ちなみにこちらの組み込みは後払いドットコムがサポートしてくれてKomojuよりも簡単にできました。サブスクリプション機能もSpreeにはspree_product_subscriptionsというGemがあるのでこれを導入しようとしましたが、バッチなどで動かない箇所があり、中身の改修に踏み切りました。オープンソースではよくあることですが、ソースの中身について質問して答えてくれるコミッタと言われる人がきちんとしていればサポートもしてもらえるのですが、多くの場合GithubにIssueとして上げてもスルーされてしまうことが大半です。そうなると自分でソースを追いかけることができないと厳しいといえます。サブスクリプション機能を導入してリリースしたプラントベース定期便は2020年にリリースして売上向上に大変貢献しました。大変だったけど導入してよかった機能になります。ECの導入で苦労したものがもう一つあって、在庫の管理システムにNEXT ENGINEというものを利用しています。いろんなAPIを提供しており、足りない機能は自分たちで開発したりすることができるのがメリットなのですが、ECの注文後の処理ステータスの管理をしており、伝票印刷済み・発送済みというところに行って在庫を減らしたりという仕組みなのでAPIで厳格なステータス管理を行いたいのですが、APIを動かすためにTokenが必要になります。こちらの更新ルールが厳しくて、バッチの自動処理だけでは更新するのが難しいため結局手動で更新するはめになったりしました。サポートの質は高くなく、質問しても1週間後に返事が返ってきたりなどかなり苦労したのを思い出します。

GoodGoodMartでも追加開発

話はGoodGoodMartに移ります。
上記にあげた通りSpreeには大分苦労しました。プラントベース食品だけでなく、ソーシャルグッド商品のECを始めるに当たり、この開発の負担をどのようにして減らすかを考えたときに、アウトソースでEC Cubeの開発やShopifyの導入、他のECカートエンジンの導入をテーブルに乗せて比較してみました。その結果、機能と価格、導入の容易さを考えてEC FORCEにすることにしました。
EC FORCEは画面やUIの流れは全て決まっているので、修正できるのはデザインテンプレートのみになります。この部分はLiquidというShopifyが開発した言語で行うようになっています。Liquidを勉強するのもなかなか大変で、オブジェクト指向言語とは作りが違うので最初は馴染めませんでした。
VegewelMarchéからGoodGoodMartを立ち上げる際には臨時エンジニアも入れてみんなで総力戦でデザインを修正しました。

しかしこのままだとサービスとしてはコンテンツが弱いため、診断コンテンツを入れることにしました。SUPER STUDIOでは1D COLORという診断コンテツ用ツールが有るのですが、こちらも導入にお金がかかることから自前で構築することにしました。ここでもAWSのElasticBeansTalkにRailsアプリを載せる形をとっています。

世の中の診断系ツールというのは調べる限り、ポイント制にして、各質問の答えの評価点を合算するもの、マインドマップのような分岐をさせるものが大半なのですが、当社もこれを組み合わせて結果を出すようにしています。診断ツールは信ぴょう性というか結果の妥当感は大事なので設計には時間をかけたほうがいい気がします。場合によっては監修をつけて作ってもらうというものアリだと思います。
ちょっと前にあった参議院選挙で各メディアが投票マッチングというツールを作って各候補者と有権者間で考え方の一致するところを可視化するものがありましたが、アレは出口調査に代わる投票行動予測診断とも言えるし、誰に投票すべきかを明示することで投票率向上につなげる狙いがあるとも言えます。出口調査のデジタル化とも言えますが、非常にうまく設計されていると思います。もちろん各議員候補の協力あっての話ですが。

あとはEC FORCEが弱い、商品検索機能の代替を作ったり、裏では在庫管理システムのNEXT ENGINEとの同期機能作ったりとかいくつか補完機能を用意しています。結構ECって商品買って代金の支払いをして終了ではないところでいろいろなプロセスが発生するので、こういうのがまとまっているBASEとかって便利だろうなって思います。

こんな感じで地味に色々な機能や裏側の仕組みを作ってフレンバシーを下支えしてきています。今は人が少なくて意思決定もほぼ高見沢で完結していますが、仲間がいれば作れるものの幅は間違いなく広がります。
最後に宣伝ですみませんが、エンジニア募集も始めたので、これを見て興味持ってくれたらどんなことでもいいのでお声がけください。