STORES レジリリースの舞台裏〜バックエンド編〜
先日リリースを迎えたSTORES レジ。その舞台裏ではどのようなことが起きていたのでしょうか。全4本にわたるシリーズでSTORES レジのお話を聞いていきます。第4回目は、バックエンドを担当したちゃろさん(以下、ち)、打越大成(うちこし・だいせい)さん(以下、う)にお話を聞きます。
聞き手:坂田 晃一(テクノロジー部門CTO室)
ポシャることも考えて始まった
──おふたりは今どんなお仕事をされているのでしょうか?
ち:もともとSTORESのバックエンドを担当していて、その後STORES レジのバックエンドを担当しリリースしました。
う:基本ちゃろさんと同じです。以前もちゃろさんと同じチームにいて、今も同じチームで同じことをやっています。
──ということは、STORES レジのプロジェクトに加わったのも同じタイミングで?
ち:そこは違うんですよ。最初は僕らの上司にSTORES レジについての相談があり、そこでやりたいことや世界観を共有されていたんだそうです。その後にまず僕が加わりました。しばらくはひとりでやっていましたが、その後打越くんが入ってくれて。今思えば、僕は新規プロジェクトをよく任されがちだったので、いけるだろうという算段があったのでしょうね。打越くんは声がかかった時どうだったんですか?
う:やるとなったらやる、という感じで、参加する時には不安などはありませんでした。データの汚い部分などの技術的負債を直したいと思っていたこともあり、チャンスかもしれないと思いました。仕様ががっちり決まっておらず、自分たちで決めていけるのもいいなと思って。
──アサインされた後はどんな仕事から手をつけていったんですか?
ち:はじめの構想期間でやりたいことが大量にリストアップされていたので、後から参加したメンバーにSTORES レジの構想を説明することに時間をかけていました。
う:そうでしたね。ほぼ(2019年の)冬ごろでしたよね。
ち:そうそう。まずは必要な土台をどう作るかを考えました。POSシステムを作るためには商品の在庫情報が必要になるのですが、ECのデータはオンラインを前提にしたものなのでそのまま使うことができません。店舗に置いてある、店舗在庫の概念など欠けているものをどう作るか考えるところから始めていきました。店舗在庫の情報が必要になるが、ECのデータにそれを組み込むのは良くないだろう、など様々なケースを考えながら思索していくのが最初のフェーズでしたね。
う:これよりも前にやっていた新規事業のsoiが短い期間でクローズしてしまったこともあって、このPOSシステムを作るプロジェクトも最後まで走るのだろうか?ということも考えていました。途中でプロジェクトそのものが中断してしまっても他に影響を与えないようにという配慮のもと、ECのデータを親として店舗の在庫をつくる方法をとったりしました。けれど、この段階ではまだやるべきことの全体像が見えているというよりは、「これはいるよね?」とパーツを揃えていくような段階でした。
ち:やることが多すぎて、全体像が見えたとしてもきりがないような量でした。最初僕らが見積もった期間は3年でしたが、上からは1年で作ってくれと言われていて、さすがに無理でしょうと思っていました。それでも、少しずつわかるところから始めていくしかないので、打越くんが話してくれている在庫の部分から着手していきました。
う:時には思い切ったことをしたこともあります。「魔のPR(プルリク )」と呼んでいるやつ。全て書き換えてしまえば少なくとも抜け漏れはないだろうと考えて150ファイル、変更量は3700行におよぶプルリクエストを出しました。当時は出社していたので、55インチの大きなモニターにコードを写して毎日3時間ずつみんなでレビューしました。3週間くらいかかりましたね。
ち:みんなで把握するには良かったけどあれは多かったよね。
う:またやりたくはない、ですね(笑)
初めて想定するオフライン店舗での決済
──開発期間中はちょうどリモートワークに移行した期間と重なるのでしょうか?
う:そうなんですが、あまり影響を感じませんでしたね。
ち:みんなリモートワークに慣れていましたし、顔を合わせなくても大丈夫なタイプの人がたまたま多かったんだと思います。ミーティングをわざわざ設定して話す時間は増えましたが、その分通勤時間が減っているし。
う:そうですね。Discordのボイスチャットを常時つないで話せる状態にしていたのも役に立ちました。出社時はオフィスで近くの席に座っていて気軽に話しかけることができますが、それをボイスチャットをつなぎっぱなしにすることで再現したのです。話せない時はミュートにしておいて、業務時間中は基本的につないでおく。たまたま僕らのチームはゲームをするのにボイスチャットを使うことに慣れていたので、抵抗がなかったのが良かったんだと思います。
──なるほど。では、技術的にチャレンジになった部分はどんなところでしたか?
う:heyの社内ではオンラインとオフラインの垣根なくどちらでも使えるサービスをという方向で動いているなかで、ECとSTORES レジのバックエンドを混ぜるのかどうかはよく議論されていました。
ち:社の方向に沿って、データも垣根なく考えていこうとすると、中のデータが分かれていた時にどっちが主なのかが問題になったり。STORES レジはheyがリリースしたサービスの中で唯一複数のプロダクトをまたいだものなので、障害が起きたらどうするかなどの社内オペレーションの構築も大変でしたね。
う:さらに、複数のプロダクトをまたぐだけではなく、STORES レジにだけ存在する概念というのもあるんですよね。シフトとか、1日の締め作業時に印刷する精算レシートとか。
ち:精算レシートなどは僕らも見たことすらない状態だったので、どんな項目があるものなのかなどをアパレル店でアルバイトの経験がある人に聞いたりしながら作りました。商業施設に入っている場合は締め作業が厳密で必要な項目があるとか、キャンセルした場合の税率はどうなるか、軽減税率はどうなるか、など考えて定義しなければならないことが多かったのは大変でしたね。
──なるほど、物理的な店舗で使われるためにはECにない概念を考える必要があったのですね。技術的なことでは、APIにはGraphQLを採用していますよね。このあたりも大変だったのではないかと思います。
う:僕は技術を採用した時はまだチームに入っていなかったんですよね。どうやって決まったんですか?
ち:技術選定はエンジニア主体で提案できる環境だったので、GraphQLにチャレンジしたいと話して使うことになりました。土台をGraphQLで用意しておけば好きなAPIの書き方を自由に作れるので相性が悪くないという判断でした。GraphQLではサーバーの監視でシステム異常を見つけるのが難しいのでそのあたりは悩みました。
う:あとはGraphQLでもN+1問題は発生するのですが、RESTful の時とは違うアプローチで解決する必要があるので、そのあたりは模索しながらすすめた記憶があります。
ち:GraphQLを採用している例が少ないので、問題に当たったときに解決方法を調べるのは大変でしたが、それが普及が進んでいない新しい技術を使ったときならではの楽しみでもあります。わからないことが出てきたらひとつずつ試して解決していきました。
「出してから本番でしょ」
──実際にリリースできた時はどんな気持ちでしたか?
ち:実は、そこまで感慨のようなものがなかったかもしれません。バックエンドはちょっとずつリリースを進めていって本番と同じ状態にしていたので「ここからがリリースだ!」という実感が薄いのかもしれません。また、まだまだ機能が足りていないと思っていたのでこんなに注目されるとも思っていなかったんです。だから、出してからが本番でしょ、と思っています。
う:僕もそんな感じですね。リリース時は想定外の使われ方をしてエラーが出たりしないかびびっていましたけど。思ったより登録されているのを見てだんだん実感が湧いていきて、うれしかったです。動いてみて初めてわかることがたくさんあると思うので、これからもっといいプロダクトにブラッシュアップしていきたいですね。
ちゃろさんのお気に入り:PATISSERIE ASAKO IWAYANAGI
等々力にあるケーキ屋さんです。ネットショップやInstagramにあがっている写真が美しく、どのケーキも美味しいです。いつも売り切れているので定期的にチェックしています。
打越さんのお気に入り:MALGA GELATO
能登のジェラート屋さん。実はECでは買ったことないんですよねえ…@naokoさん*が買って会社の冷蔵庫に入れていただいていたのをたくさん食べたのは私です。能登の本店には何度かドライブがてら行ったことありますけど、ど田舎なのに連休だと車が結構止まっててびっくりします。変わった味のジェラートが売られているのでECよりお店まで行くのがおすすめです。
*佐俣奈緒子さんのこと
(文:出川 光)
STORESレジに関わる記事をもっと読みたい方はこちらからどうぞ!
\ heyでは一緒にはたらく仲間を募集中です!/