STORES でWebエンジニアをしている kitapashi です。この記事は STORES Advent Calendar 2025 の 18 日目の記事です。

STORES のプロダクト開発にとって、2025年は非常にドラスティックな変化を伴う1年だったと思います。この変化の中心にあったのは、下の記事にもある「ひとつの STORES」というキーワードでした。変化の詳細は以下の記事に詳しいのでここでは割愛します。

product.st.inc

また、この変化を起こすに先立って、社内のメンバーも「Webエンジニア」となり、多くのメンバーが特定の技術領域/プロダクトには紐づかない形で開発業務に携わるようになりました。

採用ポジションについても基本的 *1 には「Webエンジニア」となっています。↓

product.st.inc

自分自身も、このタイミングでWebエンジニアというポジションになりました。かつ直近は特にプロダクト横断の機能開発を多く求められるプロジェクトにて開発業務を行ってきました。

今回は、自身が開発したモバイルオーダーでの客数入力/客単価の分析機能を例として、STORES の「Webエンジニア」の働き方と、この働き方をする自分の感じていることを紹介します。

自分の来歴

この後のブログの内容にリアリティが出ることを期待して、簡単に自分の来歴を書いておきます。

2022年: STORES に入社
- 最初はID基盤のSREとしてJoin, インフラ中心に運用/改善業務に携わる
2024年: STORES データ分析の開発チームに異動
- ここではバックエンド(Go)/インフラをメインとしつつ、プロダクト全体に関わる
2025年: 「分析」を軸に複数のプロジェクトチームで開発業務に携わる
- ここで今回紹介する「Webエンジニア」としての働き方に

今回取り上げる機能の概要

今回例として挙げる開発アイテムは、STORES モバイルオーダーに新設した客数取得機能です。

管理画面から店舗ごとに客数を取得するかどうかを設定でき、設定された場合は提供形態に応じて以下のような画面で利用者の客数を入力してもらえるようにする機能です。

取得した客数はリアルタイムに分析ページに反映され、期間ごとの客数と客単価を確認することができるようになります。

この開発の中で何をやったか

A.機能開発に関わるほぼ全てです！

〜〜fin〜〜

...

これだけだと雑すぎるので、以下のセクションに分けて順に紹介していきます。

顧客体験の設計
細かい要件の調整
バックエンドの設計/実装
フロントエンドの設計/実装
動作確認/リリース

顧客体験の設計

今回の機能開発開始時にPdMから受け取っていた要求は以下のみです。

分析ダッシュボードの指標として客数/顧客単価を出せるようにしたい
そのために客数をオーダーごとに取れるようにしたい

なのでまずはモバイルオーダーの注文フローの中でどうやって客数を取得するかを設計します。

STORES モバイルオーダーにおいては事業者さんの業態に応じて、テイクアウト/イートイン, モバイルオーダー上での決済/退店時のレジ決済など運用方法を切り替えられる機能があります。

その各パターンごとに既存注文フローをまとめ、その中で

どのタイミングで客数を入力するか
どのような体験だと使用者が違和感なく客数入力することができるか

などをPdM/Designer交えて議論を行いました。

その中で決定した体験をもとに、以下のような要件へと落とし込みます。

テイクアウトの場合は客数をお客様には入力させたくない
- → 裏側で暗黙的に1人分のオーダーとし、入力画面は表示させない。
イートインかつ退店時レジ決済のケースでは、複数人がそれぞれの端末で同じテーブルでのオーダーを送りたいケースがある
- → 最初の1人だけが客数を入力するようにする。その後は会計が終わりテーブルが空いたと判定されるまでは客数入力画面はスキップする。

細かい要件の調整

↑の体験設計と地続きではありますが、細かい要件の設計も自身で行い、PdM等とのレビューを通して確定させます。

今回で言うと、例えば以下のような内容について検討/仕様決定しました。

客数入力画面は一律で表示するか事業者ごとに設定で選択できるようにするか
- ユーザーの体験に変化が生じるため導入したくない事業者さんもいるだろう
- また複数店舗を運営する際、店舗ごとに運営方法が異なるケースも発生するだろう
- →店舗単位で客数入力を行わせるかどうかを設定できるようにする
客単価を計算する際、客数が入っていないオーダーの売上を計算対象に含めるべきか
- → 可能な限り正確な客単価を求めたいので、客数が入っていない(=実態がわからない)オーダーは客単価の計算対象には含めない

あくまでシステム的な都合ではなく、利用いただく事業者さんが活用しやすい仕組みにするにはどのような要件だと望ましいかを考え、議論の上で要件を確定させていきました。

バックエンドの設計/実装

ここまでで確定させた要件を実現するためのバックエンドでのデータ構造およびデータの流れを設計します。

ここでのポイントは、システム間でのデータ連携の設計です。

今回、取得した客数を分析結果に反映させるまで、以下のようなデータ連携を行うことにしました。

モバイルオーダー画面で取得したデータについてはモバイルオーダーのbackendに保持しています。

が、分析画面は以下の理由から連携された基盤の情報をデータソースとしています。

プラットフォームにおける分析機能はこの画面に集約させていきたい
既存の分析画面はプロダクト横断(= STORES プラットフォーム全体)の分析結果を集計するものであり、モバイルオーダーのbackendを直接参照するのは避けたい

この設計をもとにそれぞれのbackendに対して実装を行い、モバイルオーダー画面で取得した客数の情報を使用し、基盤側で客単価を計算できるクエリが作成されました。

フロントエンドの設計/実装

「今回取り上げる機能の概要」の章で提示した画面を実際に作成していきます。

新しい要素をどこに配置するか/UIとして違和感がないかなどについてはDesignerとの議論を交えつつ、実際にUIの構築および各API/queryとの繋ぎこみを実施していきました。

動作確認/リリース

機能実装が一通り完了した段階で、自身含むチームで実際に機能を触り、機能面/性能面/デザイン面などで問題がないことを確認します。

確認でき次第、実際に機能をリリースします🎉 これにて完遂です。

と、今回この機能を開発するまでに進めた内容について簡単にまとめました。

こうまとめてみると一般的な機能開発ではありますが、これを分業せず、実作業は1人で完結させているのが肝かなと思います。

自分としては、この働き方を良いと思っています。なぜでしょう？深掘りしてみます。

自分が感じるこの働き方の良さ

プロダクト開発の”手触り感”とオーナーシップ

自身が設計した体験を自分の手で実装する、という仕事の中には、「このプロダクトを作っている/前に進めているのは自分だ」という確かな”手触り感”があると思っています。

もちろん従来の技術領域/プロダクトカットの開発においてはそういったものがない、というわけでは一切ありません。が、実際現在の働き方のほうがこの”手触り感”を強く感じている自分がいます。

また、機能について全ての領域を作りきっているので、「この機能のことならなんでも聞いてくれ」という感情が芽生えてきます。これはこの機能に対するオーナーシップと言えるでしょう。

今回はあくまで1機能でしたが、開発を続けることでオーナーシップを持つ領域は増えていきます。継続して行った先では各プロダクトからプラットフォーム全体、そして STORES の事業全体へとオーナーシップを拡大していけそうだと(少なくとも今の自分は)思えています。

越境して開発することのスピード感

今回この機能開発には、おおよそ2週間ほどかかりました。

早いでしょうか？遅いでしょうか？

私は早いと思っています。理由は1人が越境して開発をしたことで、技術領域/プロダクトの境界線での仕様調整/実装待ちが無かったからです。

今回この機能を開発するために、以下の5箇所に手を入れています。

backend
- モバイルオーダー
- 顧客管理基盤
frontend
- モバイルオーダーの設定画面
- モバイルオーダーのユーザー使用画面
- データ分析の画面

従来の技術領域/プロダクトカットのチーム分けでは、このそれぞれに紐づくチームが存在していたことになります。*2

この場合の開発を想像してみます。どこかのチームがこの開発プロジェクトを指揮することになるでしょう。境界部分のinterfaceとなる仕様を決め、5チームの代表で議論を行います。合意した上でそれぞれのチームに持ち帰り、各チームのメンバーがIssueとして処理することになります。この仕様調整に加え、チーム間でのタスクの依存関係に伴う実装待ちが発生するでしょう。

このようにチームを分け分業する、ということは、それだけ実現にかかるコストは増えることを意味します。今回、1人で実現することでこのコストを省略できたと思っています。

もちろん周囲のメンバーやステークホルダーへの共有などは都度行いますが、より本質的な議論と実装に集中できたように思います。待ちも発生しないので結果としてこのスピードで機能提供を実現できました。

プラットフォームとしてのあるべき姿への意識

今 STORES のシステムにおいては、「ひとつの STORES」を実現すべく、機能開発にあたってプラットフォームとしてのあるべき姿を描き、そこに向かうための開発を行うことが求められています。「ひとつの STORES」へ向かう道の中では、プラットフォームとしての全体最適を意識する必要があります。

例えば今回で言うと、バックエンド設計の意思決定がこれに該当します。

今回実現したい顧客単価の表示について、この機能のスコープに閉じるならば、必ずしも顧客基盤経由で分析画面に結果を表示する必要はありません。

例えば、以下のようにモバイルオーダーbackendからデータを取得できる場所(モバイルオーダーの管理画面など)に分析ページを出せば十分に要求を満たせます。このような部分最適の課題解決はプロダクトカットの組織ではしばしば発生してしまうと思います。自分もそうしがちです。

機能は提供できているので悪いことでは無いのですが、「ひとつの STORES」へ向かう道においては横に逸れてしまうような動きだと捉えています。

プラットフォームとしての全体最適を考え、事業者さんがプロダクトを使う際にどのような状況だとより「ひとつの STORES」として使いやすくなるかを考えて今回の構成を採用しました。

こういったことを自然に考えられるのはプロダクトに紐づかない今の働き方だからこそできることだと思っています。

シンプルに楽しい

これはあくまで個人的な感想なので最後ですが、以前よりも楽しく仕事ができているな〜と思います。

自分自身、元々触れるならフルスタックになんでもやりたい志向ではありましたが、これまでの組織体制の中ではなかなか踏み出しづらい部分もありました。

ポジションの変化とともに組織文化にも変化が生じ、より多くの領域、ひいてはプラットフォーム全体に関わることがますます奨励されるような空気感になっています。

この空気感の中で働けることはとても楽しいです。

FAQ

とはいえこの働き方に対して気になる点はあると思います。(勝手に類推して)お答えします！

Q. いやこれ大変じゃないの？

A.ご明察。大変です！

技術的に言うと、自分は来歴で書いた通りSRE出身で、Go backend / Terraformあたりが元々の専門領域です。一方今回はRuby on Rails / Next.js / Nuxtあたりの技術を使用しています。専門領域外の技術を扱いながら開発を行うケースも多々あるので、都度調べながら開発を進めています。

またドメイン的にもモバイルオーダーの運用形態ごとのフローの差やオーダーの細かい仕様など、わからないことが多数あります。これも都度調べながら設計を行いました。

こういった知識のインプットと開発でのアウトプットのサイクルを高速に回すことは、やはり大変ではあります。

これは事実です…

一方、この大変さを和らげる解決策もあります。AI Agentの助けを借りることです。

今回も既存仕様理解のためのコードリーディング/設計の壁打ち/実装等、全面的にAgentの助けを借りながら実現しています。

結果として「大変だけどまあ実現はできる」と言う程度には和らぎ、程よくチャレンジングな課題となりました。

Q. 体験設計なんてできるの？

A.今は1人ではできない。が、エンジニアもできるようになるべきだと思います。

より良い体験を作り込むためには、利用者の解像度を高めることが必要不可欠です。その意味で、現状は自分よりも事業者の皆さんと直接会話しているPdMであったり、UXについて日々学び考えているDesignerとの議論は重要です。そういった考えもあり、今回も叩き台は自身が作ったが、その上で細かい体験や仕様の議論の際にはPdM/Designerの皆さんとも議論を行いながら体験を考えました。

ではこのままエンジニアは利用者の解像度を上げなくても良いのでしょうか？そういうわけではありません。よりこの働き方の中でより良いシステムを作るために、解像度を高めていく必要があると思っています。

具体的な活動として、利用してくださっている事業者への訪問があります。自分もモバイルオーダーを使用してくれているカフェに訪問し、実際にシステムを使ってくれている現場を目にしました。

この経験で、課題をリアルに認識できるようになったと思います。今後も都度訪問の機会は設けたいと思っています。

モバイルオーダーチームの店舗訪問については↓のsomeziさんの記事でも詳しく触れられていますので是非。

product.st.inc

おわりに

この記事では STORES の「Webエンジニア」における、今の働き方とそれを行う本人がどう思っているのか、を紹介しました。

この働き方について、今年から本格的に変化が始まったタイミングで、まだ絶賛過渡期の中にあります。 FAQでも書いた通りまだまだこの働き方を実現するのは大変で、より良く、楽に大きな価値を生み出すために解くべき課題も多いです。

例えばシステムのアーキテクチャについて。歴史的経緯でプロダクトが複数に分かれていますが、本来ゼロベースで考えるなら1つになっている方が嬉しいはずです。ただ統合には工数もかかり、統合後のプロダクトの複雑性なども加味する必要があります。今の STORES におけるベストなアーキテクチャはどんなものでしょう？考えなければなりません。