こんにちは。STORES のykpythemindです。先日STORES社主催のTech Conference 2025 “What Would You Do?” が開催されました。
弊社VPoEのhogelogからイントロダクションとして今年の大きな変化について話があり、イベント自体にもそれに付随するコンテンツが多くありました。
私はClosing Keynoteとして変化に対するソフトウェアエンジニアの諦念のようなトークを行いましたが、そのエピソードの実体となるSTORESで今年起きたことは多くは語っていません。今年のまとめとして、あらためて今年の変化と混沌について発信しようと思います。
辛抱強く1つの会社に向かう
STORES は様々なスタートアップが経営統合されてできた会社です。
中小事業者様の業務を支える「ネットショップ」「レジアプリ」「予約システム」「キャッシュレス決済端末」のような、お店で使っていただくプロダクト群を作っています。これを聞くと、それぞれのプロダクトに対してチームがあり、営業活動がされ、開発されているようなイメージがわくかなと思います。
実際に2023年までは、事業部制であり、ネットショップに紐づく事業と開発チーム、予約に紐づく事業と開発チーム、のようにバラバラに別れていました。
ここから、2024年、2025年と、徐々に機能部制の組織に変化してきました。
我々は単体の製品を売るのではなく、複数のプロダクトを提供して独自の価値を産んでいくことに、ある程度長いスパンを経て投資をしてきました。各プロダクト専任の開発チームはモバイルオーダーなどの新規プロダクト以外には存在せず、基本的にプロジェクトベースでチームを組成する形に変化してきました。
2018年のヘイ株式会社(旧名称) 創業時からプロダクト単体を磨き続け、ラインナップを増やし、それらをつなげるプラットフォームを開発してきました。
そして今年2025年の3月27日に、悲願であるパッケージプラン(スタンダードプラン)の提供を開始しました。
キャッシュレス決済・POSレジ・予約システム・ネットショップなどをまとめて月額3300円で利用できるという価格設定は、業界内でもインパクトがある価格設定です。
このパッケージ販売への転換で、売り方だけでなく作り方も大きく変化しました。
これまでの着実(?)なシステム間の開発
2021年にSTORES の事業者アカウントとしてのID基盤を内製し、2023年に事業者データ（我々における「テナント」です）を管理する事業者基盤をGoで内製しました。この基盤を用いて10年運用しているRailsアプリ群とつなぎ、データの統合を進めてきました。
開発チーム体制については、基本的にはシステムごとに専属のチームがあり、何かの開発が必要であれば依頼するというのが自然なプロセスになっていました。だいたいバックエンドエンジニアが全社で60名ほどいて、5-10数名程度のチームがシステム専属になり活動しているイメージです。
さて、2025年3月のスタンダードプランに向けて、STORESのプロダクトオンボーディング画面や統合された管理画面を扱うシステムをRailsで新規に立ち上げようということになりました、このシステムを bongo と言います。
1つに統合したリリース、そして混沌へ
スタンダードプランのリリースは2025年3月27日にピン留めしていました。1月-3月は統合されたプラン自体の実装（とそれに従った予約・ネットショップ・決済といったそれぞれのシステムの実装）、統合された管理画面ホームの実装、ナビゲーションの実装、新しいアカウント登録からオンボーディングの実装、といった各システムの改修を急ピッチで進めていきました。
実際にリリースにこぎつけ、無事パッケージ販売が開始されたのですが、様々な問題が発生しました。
代表的なものでいうと、(1) 新しいオンボーディングはシステムを4つまたぐため、状態のトラッキングや体験のブラッシュアップが困難である (2) パッケージ販売されることでシステム的にも統合された運用機能が必要であるのに、システム管理者が使えるadmin画面が存在しない。 といったことでした。
難易度が高かったこととしては、今までSTORESで独立していたシステムであるSTORES 決済 の利用が前提となるプランになることで、STORES利用の中心地にSTORES 決済 のシステムが突如として出現したことです。ネットショップや予約、ブランドアプリなどはクロスユースが促進されており、システム間の連携も少なからずありましたが、決済との連携が急激に進んだことで、どのエンジニアも今まで以上のシステム理解、ドメイン理解が必要になりました。
実際、分散システムを運用するためにシステム投資しきれていなかった実状がありました。10を超えるプロダクト群を品質を担保しながら我々がうまく開発するには、システム間の壁がボトルネックになりやすい状態になっていました。
もちろん諸問題は予期できたものもあります。ユーザー様にもご迷惑をおかけしたところがあると考えています。申し訳なかったです。
1つのSTORESなんだから、1つにすると作りやすい
このカオスの中、諸々のシステムに分散していたオンボーディング時のアンケート・決済利用審査情報などを、先述の bongo Rails に集約する実装をしました。ここでの開発はphayacellがTech Confで話してくれた内容ですね。
また、事業者基盤も片桐さんの力をふんだんに借り、徐々にこのbongo Railsに統合されていくことになります。
待望されていた統合admin機能も、bongo上にRailsのテンプレートエンジンで素朴に作り、日々少しずつ必要な機能を足して、運用対応や問い合わせ対応をなんとかこなすことができ始めました。
完全に逆コンウェイの法則になりますが、1つのSTORESの開発なので、1つのモノリスになるべく統合されていたほうが作りやすいです。このアイデアに沿って、1つの大きな方針を立てました。これは想像するよりもはるかにスムーズに受け入れられました。実際に分散システムになっている状態があまりに辛くなっていたのだと思います。
すでにこの統合による開発メリットが大きく感じられる場面があります。開発において必要なシステムを1人が複数触る、ということが自然に行われるようになりました。bongo は10ヶ月ほどの開発ですでに7,000PRに迫るPull Requestがマージされています。
また、チーム規模も最大6名ほどの小さなチームで1つのトピック/機能を開発する体制に移行しました。
今後の展望と課題
現状は複数のRailsアプリ, Goアプリをとりあえず1つのRailsアプリにまとめた、という段階であるので、非常にカオスなコードが存在していたりします。しかしながらbongoの開発者は常に一定の人数が存在していて、定期的にメンテナンスがされやすい体制となっています。
最終的にすべてを1つのモノリスにしたいわけではなく、ネットショップ・予約・決済など独立して存在し続ける、統合するには大きすぎるドメインを抱えたシステムがあります。 母艦となるシステムはできたところですが、引き続き開発が難しいポイントは存在しつづけています。
最後に
STORESは今年これらのソフトウェア・プロダクト・組織の変化を乗り越えて、システムの内部データや運用体制を変え、新しい価値を積み上げていくフェーズに近づいています。たびたび変化が起こり、挑戦機会にあふれています。変化だけではなく、来年にはもう少し各々が腰を据えて1つのシステムの深い開発や研鑽に取り組めるようになりそうです。
読んでいただきありがとうございました！面白そうだと思った方はぜひ採用サイトなどからお声がけください。より詳細に踏み入った話ができると思います。
