STORES, STORES レジでバックエンドエンジニアをしている @charlie です。
先日 STORES から新しいプロダクト STORES レジ がリリースされました。 プロジェクト発足からリリースまで開発に実は1年9ヶ月かかっています。
全体像は @ide も公開しているので読んでみてください。 https://ideyuta.com/stores_regi
ここではバックエンドエンジニア目線で約2年弱のプロジェクトを振り返りたいと思います。
POSレジという未知の世界
レジプロジェクトにアサインされたのは2019年10月頃。 社内にはオフラインやPOSレジの知見はほとんどなかったため、キャッチアップから始まりました。
例えば、複数の店舗やシフトといった概念はオフライン特有のものです。 オフラインでは何が必要なのかを調査し、STORES でどのように実現していくのかを検討していく必要がありました。
最低要件はどこなのか
既にPOSレジシステムは世の中にいくつも存在します。 STORES としては新しいプロダクトですが業界としては後発です。 そのようなシステムと同等のものをはじめから作るとなると何年かかるか分かりません。
現実的に運用できるレベルで、なるべく早く世の中へリリースできるものを作るために、最低限必要なものを洗い出しました。 例えば、店舗や現金での決済、レシート発行、精算という概念は今までECには存在しなかった概念ですが、オフラインでの運用では必須な要素です。
※実際にファーストリリースで作成した機能一覧です。 https://stores.jp/regi/features
ここでようやく全体は見えてきましたが、まだ各機能をどう実現するかまでは議論しきれていません。 各機能のボリューム・影響度によって、優先順位を決定し順番に着手していくようにしました。
STORES っぽさを出したい
やらなければならないことの全体像の把握はできました。 これらを STORES ならどのように実現し提供できるのかという議論もなされていたと記憶しています。 直感的にかつ簡単にPOSレジを使えることを意識して要件を固めていきました。 やろうと思えばできるところを制限している部分もあります。
例えば在庫共有機能。 商品単位 or バリエーション単位で在庫を共有すべきか。 複数店舗間で在庫共有することもシステム的には可能ですが、複数の実店舗で在庫を共有することはより煩雑になりえます。 そこで EC と店舗の在庫のみを共有できるようにしています。
職種に限らず、このようにしたら使いやすいのではないか、こういう仕組みにできないか、など議論を重ねることで STORES っぽさを出せたのではないかと思います。
また、どのように提供すべきか詰め切れなかったり、スケジュールの制約上今回のスコープからは除外された機能もいくつかあります。
ここまでの全体要件を洗い出す工程で半年ほど議論に費やしました。
COVID-19 による影響
2020年からは COVID-19 による働き方の影響もありました。 3月頃にはプロジェクトメンバーが全員フルリモートになり、対面での議論ができなくなりました。
プロジェクトのメンバー構成ですが、最低でも開発に11人が関わっています。 その他にもスポットで何人か参加していたこともあります。
- プロダクトオーナー 1人
- プロジェクトマネージャー 1人
- デザイナー 2人
- EM 1人
- バックエンドエンジニア 4人
- モバイルエンジニア 2人
Discord でのチーム開発
多くの社員は Google Meet や Slack call を利用してミーティングを行っています。 しかしこれらのツールでは下記のような場合にうまく働かない場合があると感じました。
- ミーティングを開催するほどではないが、テキストだとコミュニケーションコストがかかる
- さっと聞いて解決しそうなこと
- 雑談
2020年以前ではほとんどの人たちが、対面で仕事をしていたと思います。 普段から顔を合わせ、仕事中も質問や業務の軽い議論や相談など、ミーティング以外での会話もありました。 新規プロダクトなので決めるべき事柄が多く、バックエンドエンジニア内で都度ミーティングをセットするよりその場ですぐ話して決める方が開発速度が上がると判断しチームで Discord の導入をしました。
結果、エンジニアチーム内ではすぐに相談できる状態になったと思います。 通常ミーティングは Google Meet を利用しています。
余談ですが、弊社の Slack でも Huddles が使えるようになったので、積極的に使っていきたいです。
ECシステムにオフラインの概念を盛り込む
STORES は "EC" のシステムです。 POSレジを作っていくとどうしても既存のデータ構造では対応できない部分がでてきます。
例えば在庫データはバリエーション(サイズや色など)単位でのデータであるものに加え、そこから複数店舗在庫に対応する必要があります。 既存構造でも対応できますが、そのままだと技術的負債になりえる箇所だったので、新しく構造を変えることにしました。 2020年3月、実店舗での在庫管理ができるように商品データの構造を変更しています。
その後の2020年11月にリリースした品番機能は EC で以前から要望があったので EC の機能としてリリースしています。 https://officialmag.stores.jp/entry/201105/hinban
他にも先ほどもお伝えした店舗、カスタム決済手段、精算等のPOSレジで新たにでてきたものも多数追加していきました。
GraphQL
2020年4月、在庫のデータ構造変更が一段落し、ここからようやくPOSレジの実装が始まります。 エンジニアにとって何か新しいことをということで API の実装には REST ではなく GraphQL を検討し始めました。
チームでは経験者がいなかったため 初めてのGraphQL の読書会をモバイルチームと実施したり、 Ruby on Rails で実装されている GitLab の実装を読み合わせしたりして知見を深めていきました。
怒濤の開発期間
2020年5月から2021年5月までの1年間は、ざっくり洗い出された各機能を詳細な仕様までに落とし込みひたすら作っていく期間でした。 これらはおおまかなやったこと一覧です。
- 店舗機能
- レシート設定
- アイテム販売設定
- 決済手段の追加
- 現金
- カスタム決済手段
- STORES 決済
- 在庫共有機能
- 注文データ
- データ設計
- ステータスの管理
- 割引
- 返金・キャンセル
- POSレジ端末機能
- 精算機能
- EC ダッシュボードの改修
- STORES レジの開始フロー追加
- 店舗在庫の設定画面追加
- 在庫共有機能追加
- GraphQL API の監視設定
この間にも QA チームからの不具合報告だったり、仕様変更や再び別データの移行だったり対応しています。 これらを1年間で実装してリリースまで成し遂げられてよかったと思います。
チームでの試行錯誤
チーム開発でもいくつかチャレンジしました。
プロジェクト管理
プロジェクト管理ツールは各チームで使いやすいものを使っていますが、これというものが見つかっていませんでした。 チームで最初に試したのは asana でした。 UIが分かりやすく、直感的でロードマップも引きやすかったのですが GitHub Issues にエンジニアのタスクをまとめていたため、進捗の同期コストが負担になっていました。
その後、フロントチームで採用していた ZenHub を試してみました。 ZenHub は GitHub をベースにしたサービスなので GitHub で作成した issues や Pull Request をシームレスに反映させることが可能です。
最終的に ZenHub でのタスク管理にすることで同期コストがなくなりました。 GitHub から Project planning for developers が発表されたので、使えるようになったら試してみたいと思います。
タスクの見積もり
最近はスクラムでの開発を行うチームが社内外でもよく散見されます。 バックエンドチームでもスクラム開発を採用し、週一のスプリント期間で運用していました。 はじめはお互いの感覚値やタスクの複雑さ等が分からないので、このタスクにはどれくらいかかるのかという時間によるストーリーポイントで見積もりを行っていきました。
見積もりやすいように、「店舗一覧を返すAPI作成」といった一つタスクでも設計と実装でタスクを分割するようにしています。
ある程度タスクをこなし不透明だった部分が少なくなってきたタイミングで、基準となるタスクを設定しそこから算出する相対見積もり方式に変更しました。 変更する前からある程度安定したタスク量をこなすことができていましたが、メンバー全員の見積もりの精度が高くなったと思います。
リリースブランチは用意しない
通常プロジェクトではリリースブランチを用意し、開発したものをリリースブランチへマージしていきます。 機能のリリース日もしくは事前にメインブランチへリリースブランチをマージし、リリース作業をするという流れが STORES での開発フローです。
しかし、長期プロジェクトにおいてリリースまでの期間が長いと差分が大量に発生し、コンフリクトの嵐になってしまうのは自明です。
今回モデルや API の実装は、メインブランチへマージしていく手法をとることにしました。 都度メインブランチへマージしていくことによって、常に最新コードでの開発が可能になりました。 また API は本番から利用できないようにしておくことで、本番運用に影響のないような状態で開発を進められるようになりました。
おわりに
新規プロダクトの開発でやってきたことを振り返ってみました。 POSレジという普段関わったことのない業界のプロダクト開発は、自分にとってとてもいい経験になりました。 チームとしても2年間という長期間のプロジェクトは開発体制やチームプレイとしての知見が得られたと思います。 これからオンラインとオフラインとの境界をなくすことによって、ひとつのお商売体験を提供していくことへの先駆けとなり、STORES プラットフォームとして提供できる価値が増えていくように日々頑張っていきます。
STORES レジはリリースされましたが、生まれたてのプロダクトです。 提供していきたい機能のアイディアはたくさんありますが、現状ではまだまだ足りていません。 hey や STORES の各プロダクト、開発について知るきっかけになれば幸いです。
